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 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.

Firewall ID 0 i brakujące logi odrzuceń

Jeśli żadna jawna reguła firewall nie pasuje, na końcu bazy reguł zostaje zastosowana wbudowana reguła Drop all z Policy ID lub Firewall ID 0. Nie generuje ona zwykłego wpisu w logu ruchu firewall. Aby te odrzucenia były widoczne w Log Viewer, Central Reporting lub Syslog, utwórz na końcu bazy reguł własną regułę z Action: Drop i włączoną opcją Log firewall traffic.

Wybierz przy tym wymagane strefy Source i Destination pojedynczo i nie używaj ogólnej strefy Any. Dzięki temu lokalne usługi pozostaną prawidłowo dostępne. Jeśli reguła końcowa przechwytuje dużo prawidłowego ruchu, wyżej prawdopodobnie brakuje odpowiedniej reguły Allow albo sieć została niewłaściwie sklasyfikowana.

Dla SFOS 22.0.1 MR1 Build 490 Sophos dokumentuje również Known Issue NC-178387: default drops z ID 0 nie pojawiają się w Dropped Packet Capture ani w drppkt; w zwykłym Packet Capture może być widoczny tylko status Incoming bez odpowiadającego wpisu Violation Firewall. Ruch mimo to jest odrzucany. Sophos nie podaje w Known Issues List jednoznacznie potwierdzonej wersji z poprawką, dlatego nie należy zakładać tego zachowania poza wskazanym buildem.

W razie podejrzenia default drop:

1. Sprawdź kolejność reguł i Policy Test.
2. Porównaj wynik z rzeczywistym Packet Capture.
3. Jeśli potrzebne jest logowanie, utwórz precyzyjnie ograniczoną strefami regułę końcową z własnym Rule ID.
4. Powtórz test i potwierdź nowy Rule ID w logu lub przechwyceniu.

Policy Tester w sekcji Diagnostics > Tools nie uwzględnia tras SD-WAN, dlatego nie może być jedynym dowodem. Ponadto w SFOS 22.0 GA problem NC-177587 mógł powodować błędne wyniki reguł; decydujące pozostają logi produkcyjne i Packet Capture.

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.

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. Po zapełnieniu bufora nagrywanie zatrzymuje się automatycznie i trzeba je ponownie uruchomić po wybraniu Clear.
• 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. 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