Conntrack NEW na pakiecie ACK: czego to nie dowodzi
ACK oznaczony jako NEW znaczy, że tracker nie miał pasującego stanu, a nie że VPN otworzył sesję. Przeczytaj hook, tuple i okno przechwytywania.
W logu firewalla jest jedna linia, której się nie spodziewałeś: pakiet ACK, stan conntrack NEW, adres źródłowy, który nie jest twój, port docelowy otwarty. Pokusa jest taka, by odczytać to jako nowe połączenie przychodzące, którego nikt nie autoryzował. To, co linia naprawdę mówi, jest węższe: gdy ten pakiet dotarł do tego hooka, tracker nie miał pasującego stanu, a pakiet niósł ACK. To dwa fakty o dwóch różnych rzeczach i żaden z nich nie jest pełnym zapisem uścisku dłoni. Oto kolejność, którą przechodzę, zanim wyciągnę wniosek.
Zacznij od pakietu, nie od wyroku
Oddziel obserwacje, zanim je zinterpretujesz. Flagi TCP opisują ten pakiet, stan trackera opisuje, co wiedział na tym hooku, a twoje przechwycenie opisuje tylko okno, które nagrałeś.
Mieszanie tych trzech to sposób, w jaki ACK staje się „dostawca kogoś wpuścił”.
Co NEW naprawdę znaczy na hooku
dopasowanie conntrack w iptables dokumentuje NEW jako pakiet, który rozpoczyna połączenie, albo pakiet związany z połączeniem, które jeszcze nie widziało ruchu w obu kierunkach. ESTABLISHED znaczy, że tracker widział pakiety w obu kierunkach. Żadna z definicji nie mówi, że pakiet był SYN-em, ani że przyszedł bez historii.
Tracker, który zaczyna obserwować przepływ w połowie, klasyfikuje następny pakiet według tego, co wie, a to może być nic. To stwierdzenie o pamięci trackera, nie o zamiarze zdalnego hosta.
Luźne śledzenie wyjaśnia większość niespodzianek z ACK
Jądro dokumentuje nf_conntrack_tcp_loose, co pozwala trackerowi przejąć połączenia TCP, których początku nie widział. Przy ustawieniu na wartości domyślnej ACK ze środka przepływu może zostać przyjęty jako ustanowiony przepływ. Wyłącz je, a ten sam pakiet będzie prawdopodobniej sklasyfikowany jako INVALID, a nie NEW. Oba wyniki opisują reguły trackera, nie historię aplikacji.
Sprawdź więc to ustawienie, zanim zbudujesz teorię na etykiecie.
Wyklucz nudne przyczyny w tej kolejności
Większość zdarzeń NEW-na-ACK, które śledziłem, kończyła się jedną z tych przyczyn, a wszystkie są tanie do sprawdzenia:
- Tabela conntrack została wyczyszczona albo tracker został zrestartowany.
- Host został zrestartowany albo przepływ przeniósł się do innej przestrzeni nazw lub urządzenia.
- Asymetryczne trasowanie wysłało SYN ścieżką, której nie przechwytujesz.
- NAT przepisał tuple, więc wpis nie pasuje już do tego, co przeczytałeś.
- Przechwytywanie zaczęło się późno i nigdy nie zobaczyło początku.
Każda z nich usuwa wcześniejsze pakiety z pola widzenia trackera, a późniejsze zostawia nietknięte. Restart albo wyczyszczenie tabeli najłatwiej potwierdzić na podstawie uptime i logów. Asymetryczne trasowanie objawia się jako przechwytywanie jednokierunkowe. NAT jest podstępny, bo tuple zapisany przez tracker nie jest tym tuple wydrukowanym w logu.
Zapisz, które z nich wykluczyłeś i jak, zanim przejdziesz dalej.
Przeczytaj tuple, interfejs i hook
Wpis conntrack jest kluczowany adresami, portami i protokołem, więc każde tłumaczenie zmienia to, który wpis pasuje. Zapisz też interfejs i hook, bo pakiet widziany na niewłaściwym interfejsie albo po innym łańcuchu mówi ci, że ścieżka nie jest tą z diagramu. Gdy zdarzenie dotyczy VPN, zdecyduj, czy patrzysz na pakiet wewnętrzny, czy na nośnik zewnętrzny. Potem porównaj z tym, co brama zalogowała dla tego samego pięcioczęściowego tuple.
Dwa sprzeczne widoki jednego przepływu mówią więcej niż każdy z nich osobno.
Kiedy warto eskalować
Eskaluj, gdy możesz pokazać usługę, która jest osiągalna i nie powinna być, wraz z przepływem, polityką, która na to pozwoliła, i dowodami z obu stron. Nie zgłaszaj usterki dostawcy na podstawie jednej etykiety stanu albo jednego częściowego przechwycenia, bo ten raport zostanie zamknięty z wyjaśnieniem, które właśnie przeczytałeś. Jeśli usługa naprawdę jest wystawiona, właściciel tej granicy jest właściwą osobą, by to naprawić, a delegowane mapowanie portów albo niezamierzony nasłuch jest bardziej prawdopodobną przyczyną niż błąd.
Potem zamknij lukę w widoczności, która pozwoliła jednemu pakietowi wyglądać jak cała sesja.