Analiza odrzuconych pakietów na Sophos Firewall

Odrzucony pakiet nie zawsze oznacza błąd. Zapora może blokować ruch zgodnie z założeniami, nieoczekiwanie odrzucać prawidłowy ruch albo w ogóle nie widzieć danego przepływu. Poniższa procedura pozwala szybko ustalić, czy odpowiada za to reguła, NAT, trasa powrotna, moduł bezpieczeństwa, czy system znajdujący się przed zaporą.

Ustalenie przyczyny odrzuceń w kilka minut

1. Zapisz przypadek testowy: Zanotuj Source IP, Destination IP, port, protokół, godzinę i oczekiwany kierunek. W przypadku sporadycznych błędów zapisz również użytkownika, aplikację i ostatnią zmianę konfiguracji.
2. Przefiltruj Log Viewer: W module Firewall wyszukaj adres IP, port i godzinę. Zależnie od przypadku otwórz także Web, SSL/TLS inspection, Application filter, IPS, Active threat response, Web server protection lub VPN.
3. Uruchom Packet Capture: W sekcji Diagnostics > Packet capture ustaw wąski filtr, włącz przechwytywanie i wykonaj dokładnie jeden powtarzalny test.
4. Odczytaj status pakietu: Incoming, Forwarded, Consumed, Generated i Violation wskazują, czy pakiet dotarł, został przekazany, przetworzony lokalnie, wygenerowany przez zaporę, czy odrzucony.
5. Przypisz decyzję: Porównaj Rule ID, NAT ID i Reason z oczekiwaną regułą firewall i NAT. W przypadku trafień Web, IPS lub Application sprawdź również odpowiedni Policy ID.
6. Zarejestruj kierunek powrotny: Jeśli ruch wychodzący jest przekazywany, ale nie widać odpowiedzi, sprawdź trasę powrotną, system docelowy, NAT, SD-WAN i routing asymetryczny.
7. Dopiero potem wprowadzaj zmiany: Nie twórz szerokiej reguły Allow ani globalnego wyjątku, dopóki odpowiedzialny moduł i rzeczywista przyczyna nie zostaną ustalone.

Ogólne dopasowywanie reguł i Policy Tester opisano szczegółowo w artykule Testowanie reguł Sophos Firewall za pomocą Log Viewer i Packet Capture.

Wspólna analiza Log Viewer i Packet Capture

Log Viewer i Invalid traffic

Log Viewer otwiera się w prawym górnym rogu WebAdmin. Pokazuje nie tylko decyzje zapory, lecz również zdarzenia z powiązanych modułów bezpieczeństwa. W przypadku ruchu Web Proxy moduł Firewall może na przykład zgłosić Allowed, a moduł Web jednocześnie Blocked: reguła firewall zezwala na połączenie z proxy, natomiast Web Policy blokuje zawartość. Dlatego należy zawsze korelować moduły z tego samego momentu testu. Filtry, Detailed view, moment zakończenia sesji i Log occurrence opisuje artykuł Prawidłowe korzystanie z Log Viewer na Sophos Firewall.

Dla ruchu firewall trzeba oddzielnie sprawdzić dwa warunki:

• W odpowiedniej regule włączono Log firewall traffic. Reguły SSL/TLS mają do tego osobną opcję Log connections.
• W sekcji System services > Log settings włączono wymagane miejsce docelowe dla Log Viewer w Local reporting, Sophos Fusion (dawniej Sophos Central) lub Syslog.

Sesje zapory pojawiają się zazwyczaj wtedy, gdy przy zamykaniu połączenia zapora otrzymuje zdarzenie Destroy. Jeśli połączenie zostanie przerwane bez takiego zdarzenia, oczekiwany wpis może się nie pojawić. Do dłuższego przechowywania danych nadaje się Central Firewall Reporting lub Syslog w systemie SIEM.

Invalid traffic oznacza, że Conntrack nie może przypisać pakietu do aktywnego połączenia. Wygasła sesja albo dodatkowe pakiety TCP-RST i FIN mogą powodować takie zdarzenia i nie muszą oznaczać błędu. Jeśli jednocześnie występują problemy z połączeniem, przechwyć oba kierunki i sprawdź możliwe przyczyny, takie jak brak trasy powrotnej, ścieżka asymetryczna lub przełączenie roli HA. Wydłużenie czasu Conntrack może jedynie zmniejszyć liczbę wpisów w logu; nie usuwa przyczyny.

Jeśli konkretnym powodem odrzucenia jest Invalid TCP reserved bit, przyczyną może być Accurate ECN, a nie reguła zapory. Artykuł Rozwiązywanie Invalid TCP reserved bit powodowanego przez Accurate ECN wyjaśnia, jak to potwierdzić i ocenić wpływ globalnego obejścia CLI na bezpieczeństwo.

Status, Rule ID, NAT ID i Reason

Packet Capture pokazuje pakiety przechodzące przez interfejs i uzupełnia informacje o ich przetwarzaniu przez firewall, NAT oraz moduły bezpieczeństwa. Aktualna dokumentacja SFOS 22 definiuje następujące statusy:

• Incoming: Pakiet dociera do interfejsu. Nie dowodzi to jeszcze, że zostanie przekazany dalej.
• Forwarded: Zapora przekazuje pakiet do interfejsu wyjściowego. Jeśli brakuje odpowiedzi, kolejnym punktem kontroli jest system docelowy i trasa powrotna.
• Consumed: Pakiet jest przeznaczony dla samej zapory, na przykład dla WebAdmin, SSH, DNS lub VPN Portal.
• Generated: Zapora sama generuje pakiet, na przykład jako odpowiedź lub ruch systemowy.
• Violation: Naruszenie Policy prowadzi do odrzucenia pakietu. Rule ID, Reason i odpowiedzialny moduł wyznaczają kolejny punkt kontroli.

Ważne są również Rule ID, NAT ID, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID i Username. Nieoczekiwana wartość może oznaczać, że zadziałała bardziej ogólna reguła znajdująca się wyżej, NAT zmienił widoczne adresy albo użytkownik nie został rozpoznany.

Reason jest wskazówką, a nie pełnym raportem Root Cause. Wartości takie jak Firewall, LOCAL_ACL, INVALID_TRAFFIC, APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION i VIRTUAL_HOST mogą, zależnie od wersji, wskazywać odpowiedzialny moduł. Najpierw odczytaj status i identyfikatory, a następnie otwórz odpowiednią sekcję Log Viewer. Obsługę i filtrowanie opisano w artykule Sophos Firewall Packet Capture.

Ustawienie precyzyjnego filtra

W Diagnostics > Packet capture > Configure pole Enter BPF string ogranicza zapis, a Number of bytes to capture (per packet) określa długość pakietu. Wrap capture buffer once full nadpisuje najstarsze dane zamiast zatrzymywać przechwytywanie. Po Save opcja Display filter filtruje według Interface name, Ethernet type, Packet type, Source IP/port, Destination IP/port, Reason, Status, Rule ID, User lub Connection ID. Wąski filtr BPF oszczędza bufor 2048 KB i ogranicza dane poufne.

Firewall ID 0 i brakujące logi odrzuceń

Gdy żadna jawna reguła nie pasuje, działa Drop all z Policy lub Firewall ID 0, bez zwykłego logu ruchu. Aby rejestrować odrzucenia, utwórz na końcu w Rules and policies > Firewall rules > Add firewall rule > New firewall rule regułę z polami Rule name, Action: Drop, Source zones and networks, Destination zones and networks, Services oraz Log firewall traffic. Dla jednego testu ogranicz wartości. Aby w pełni odwzorować regułę wbudowaną, Sophos zaleca regułę Drop any-any; wcześniej oceń ilość logów i istniejące reguły końcowe.

W SFOS 22.0.1 MR1 Build 490 problem NC-178387 powoduje, że ID 0 nie pojawia się w Dropped Packet Capture ani drppkt; Packet Capture pokazuje tylko Incoming bez Violation Firewall. Ruch nadal jest odrzucany. Dla NC-178387 nie potwierdzono obecnie wersji z poprawką, więc samo MR2 nie dowodzi usunięcia problemu. Przed wyborem innej kompilacji należy uwzględnić tę kontrolę w planie aktualizacji firmware.

1. Sprawdź kolejność i Policy Test.
2. Porównaj z Packet Capture.
3. W razie potrzeby utwórz logowaną regułę końcową i potwierdź Rule ID.
4. Regułę tymczasową wyłącz lub usuń i sprawdź, czy ID 0 nadal odrzuca; znika tylko dodatkowy log.

Policy tester znajduje się w Diagnostics > Tools, w sekcji Pop-out tools, i nie uwzględnia tras SD-WAN. Problem NC-177587 dotyczył SFOS 22.0 GA Build 411 i został poprawiony w MR1 Build 490; dla innych buildów sprawdź aktualny status NC-177587 w ramach planu aktualizacji firmware. Rzeczywiste logi i Packet Capture pozostają rozstrzygające.

Ustalenie przyczyny na podstawie wyników

Reguła, NAT i trasa powrotna

Jeśli Rule ID nie odpowiada oczekiwanej regule, sprawdź strefy Source i Destination, obiekty sieciowe, usługę, protokół, użytkownika, harmonogram i kolejność reguł. Przy DNAT kluczowe jest, czy test wykonywany jest wobec adresu publicznego i jaki NAT ID faktycznie zostaje zastosowany. Podstawy opisano w artykułach Zrozumienie reguł firewall i Publikowanie serwera za pomocą DNAT.

Jeśli Packet Capture pokazuje Forwarded, ale nie ma odpowiedzi, kolejna reguła Allow rzadko rozwiązuje problem. Często brakuje SNAT/MASQ lub trasy powrotnej, powiązana reguła NAT jest wyłączona, system docelowy blokuje ruch lokalnie albo SD-WAN wysyła odpowiedź inną ścieżką. Ruch w obu kierunkach musi przechodzić przez tę samą zaporę stanową.

Sesja, routing asymetryczny i HA

Komunikaty takie jak Could not associate packet to any connection oznaczają, że nie znaleziono pasującego wpisu Conntrack. Możliwe przyczyny to wygasła sesja, nieoczekiwane flagi TCP, asymetryczna trasa powrotna lub przepływ danych widziany przez zaporę tylko w jednym kierunku. Po przełączeniu roli HA istotne może być również to, na którym węźle zestawiono połączenie.

Pojedyncze zdarzenie RST lub FIN, któremu nie towarzyszy problem użytkownika, nie wymaga natychmiastowej zmiany. Powtarzalne przerwy należy natomiast sprawdzić z identycznym filtrem w obu kierunkach, a następnie zweryfikować routing, SD-WAN, ścieżki VPN i status HA.

Consumed i lokalne usługi zapory

Consumed nie jest zwykłym odrzuceniem ruchu tranzytowego. Celem jest sama zapora, na przykład WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN lub SNMP. Za te połączenia odpowiadają zazwyczaj Administration > Device access i Local service ACL, a nie zwykła reguła firewall. Bezpieczną konfigurację przedstawia artykuł Zabezpieczanie Device Access na Sophos Firewall.

Moduły bezpieczeństwa, VPN i MTU

Reguła firewall może zezwolić na ruch, zanim zablokuje go kolejny moduł. Dlatego przy odpowiednich identyfikatorach lub wartościach Reason sprawdź również Web Policy, SSL/TLS inspection, Application Control, IPS, Active Threat Response i WAF. Po trafieniu IPS oceń signature i kontekst reguły przed utworzeniem wyjątku; procedurę opisano w artykule Bezpieczne testowanie IPS na Sophos Firewall.

W przypadku problemów z Web i TLS protokół QUIC przez UDP 443 może zmieniać oczekiwany sposób przetwarzania. Odpowiednią kontrolę przedstawia artykuł Blokowanie QUIC i HTTP/3.

W przypadku VPN, PPPoE, SD-WAN lub zagnieżdżonych tuneli problemy z MTU, MSS i fragmentacją częściej powodują zawieszanie albo częściowe przerwy niż jednoznaczne odrzucenie. Pomocne są instrukcje dotyczące MTU i MSS oraz IPsec VPN Troubleshooting.

Connection List dla aktywnych sesji

W Diagnostics > Connection list lista pokazuje aktywne połączenia. Display filter ogranicza je według In interface, Out interface, User, Network protocol, Source IP, Destination IP, Packet type, Source port, Destination port i Rule ID. Kolumny takie jak NAT ID, Protocol, Application name, Connection status, Connection ID, Gateway ID oraz ID polityk pomagają przypisać przepływ. Connection ID pokazuje powiązane sesje proxy, FTP, SIP i podobne, jeśli istnieją.

Aktywna sesja z oczekiwanymi Rule ID i NAT ID potwierdza wartości bieżącego przepływu. Jej brak nie dowodzi odrzucenia: lista jest migawką, a odrzucone lub zakończone połączenia mogą nie być widoczne. Sprawdzaj ją podczas testu i koreluj z Log Viewer oraz Packet Capture.

Gdy standardowa kontrola nie wystarcza

Brak wpisu w Log Viewer lub Packet Capture

Jeśli brakuje wpisu w logu, najpierw sprawdź logowanie reguły, Log settings, filtr czasu i odpowiedzialny moduł. Jeśli także Packet Capture nie pokazuje żadnego pakietu, przed dalszą diagnostyką sieci sprawdź:

• Czy Packet Capture jest rzeczywiście aktywny i czy test wykonano dopiero po jego uruchomieniu.
• Czy filtr zawiera właściwe adresy, porty, kierunek i interfejs; na próbę nieznacznie go rozszerz.
• Czy bufor 2048 KB nie jest pełny. Gdy Wrap capture buffer once full jest wyłączone, po zapełnieniu bufora nagrywanie zatrzymuje się i trzeba je ponownie uruchomić po wybraniu Clear; po włączeniu tej opcji najstarsze dane są nadpisywane.
• Czy w sekcji System services > Services działa Packet capture and Live connections; w razie problemu z uruchomieniem zrestartuj tę usługę w kontrolowany sposób.

Dopiero gdy powtarzalny test z działającym przechwytywaniem nie pokazuje ruchu przychodzącego, należy szukać przed zaporą: na kliencie, VLAN-ie, switchu, bramie, routerze nadrzędnym lub w nieprawidłowym celu testu.

tcpdump, Drop Capture i archiwa logów

Aby wykonać dłuższe przechwycenie, zapisać plik PCAP lub użyć precyzyjnego filtra BPF, zaloguj się przez SSH i wybierz Option 4: Device Console. Wąski przykładowy filtr dla dwóch hostów i HTTPS wygląda tak:

tcpdump 'host 192.0.2.10 and host 198.51.100.20 and port 443'

Dla pakietów odrzucanych przez reguły firewall można użyć tego samego filtra z drop-packet-capture:

drop-packet-capture 'host 192.0.2.10 and host 198.51.100.20 and port 443'

drop-packet-capture nie pomaga w problemach warstwy aplikacji. Przykłady są zgodne z udokumentowaną składnią Device Console w SFOS 22; nie wykonano ich na zaporze na potrzeby tego artykułu. Aby utworzyć plik PCAP, tcpdump obsługuje opcję filedump; plik znajduje się tymczasowo w katalogu /tmp. Przechwycenie powinno być możliwie krótkie i precyzyjne, ponieważ pakiety mogą zawierać poufne dane. Po analizie usuń plik. Więcej przykładów zawiera artykuł tcpdump na Sophos Firewall.

Jeśli dział wsparcia potrzebuje również logów usług, najpierw ustal właściwy log i zabezpiecz tylko wymagany przedział czasu. Pomocne są artykuły Usługi i logi Sophos Firewall oraz Zapisywanie logów do celów wsparcia i analizy.

Bezpieczne usuwanie problemu i dokumentowanie

Wyjątek ma sens dopiero wtedy, gdy znany jest moduł, uzasadniony cel i najwęższy możliwy zakres. Nie twórz globalnego wyjątku TLS, reguły Any-Allow ani zezwolenia dla całych sieci tylko dlatego, że usługa zacznie wtedy działać. Lepsze są konkretne hosty, usługi i użytkownicy oraz data przeglądu lub wygaśnięcia.

Przed zamknięciem sprawy udokumentuj:

• Source, Destination, port, protokół, godzinę i użytkownika.
• Oczekiwane i faktycznie widoczne Rule ID oraz NAT ID.
• Status, Reason i zaangażowany moduł bezpieczeństwa.
• Kierunek wychodzący i powrotny albo miejsce, w którym przepływ się kończy.
• Zmianę, Owner, Ticket i termin przeglądu; zapisz również świadomą decyzję o niewprowadzaniu zmian.

Następnie powtórz ten sam test. Dozwolone połączenie musi działać, a niedozwolone źródło porównawcze nadal powinno być blokowane. Dzięki temu szybka naprawa nie stanie się trwałą luką w zabezpieczeniach.

Często zadawane pytania