Analizuj Sophos Firewall upuszczone pakiety

Jeśli Sophos Firewall porzuci pakiety, nie jest to automatycznie błąd. Często jest to dokładnie taka decyzja dotycząca bezpieczeństwa: reguła nie pasuje, polityka blokuje, pakiet nie należy do znanego połączenia lub moduł taki jak filtr sieciowy, działa IPS lub Application Control.

Sytuacja staje się trudniejsza, gdy usługa nie działa i nie jest jasne, czy zapora sieciowa ją blokuje, czy ruch w ogóle nie dociera, czy też ruch powrotny przebiega inną trasą. Następnie potrzebujesz czystej kolejności: najpierw Log Viewer, następnie Packet Capture, a następnie logi serwisowe lub CLI, jeśli to konieczne.

W przypadku ogólnego dopasowania reguł pasuje Przetestuj regułę zapory sieciowej za pomocą Log Viewer, Test zasad i Packet Capture. W tym artykule skupiono się na upuszczonych i upuszczonych pakietach.

Który artykuł dotyczący rozwiązywania problemów pasuje?

Nie każdy problem z połączeniem jest problemem Drop. W zależności od twoich obserwacji inny sposób rozpoczęcia jest szybszy:

• Drop, Invalid traffic, Violation lub identyfikator zapory sieciowej 0 widoczny: Ten artykuł jest właściwym miejscem do rozpoczęcia.
• Oczekiwana reguła zapory nie jest spełniona: Sophos Firewall reguła nie ma zastosowania: sprawdź przyczyny.
• Reguła powinna zostać zatwierdzona po zmianie: Sophos Firewall Testuj regułę za pomocą Log Viewer i Packet Capture.
• Pakiety należy sprawdzać w WebAdmin za pomocą wąskiego filtra: Sophos Firewall Packet Capture w WebAdmin użyj.
• WebAdmin pokazuje za mało i potrzebne są pliki dziennika: Sophos Firewall Rozwiązywanie problemów: Services i logi.
• Dzienniki powinny być przechowywane dłużej lub skorelowane centralnie: Sophos Firewall Syslog wyślij do SIEM.
• WebAdmin, SSH, DNS, VPN Portal lub SNMP wpływa na samą zaporę ogniową: Sophos Firewall Bezpieczny dostęp: poprawnie skonfiguruj Device Access.
• Tunel IPsec działa, ale ruch nie przepływa prawidłowo: Sophos Firewall IPsec Rozwiązywanie problemów z VPN.
• Duże transfery zawieszają się lub poszczególne aplikacje przerywają: Sophos Firewall Sprawdź MTU i MSS pod kątem problemów z VPN.

Ten wybór oszczędza czas, ponieważ nie traktuje każdego problemu jako błędu reguły zapory. Najpierw musi być jasne, czy zapora widzi ruch, która reguła lub moduł podejmuje decyzję i czy ścieżka powrotna faktycznie przebiega tą samą trasą.

Drop nie jest równe Drop

Na potrzeby analizy należy najpierw rozróżnić, jaki typ Drop jest obecny. W przeciwnym razie szybko będziesz szukać w niewłaściwym miejscu.

• Zamierzone Drop: Zapora sieciowa blokuje zgodnie z regułą, polityką sieciową, IPS lub źródłem zagrożeń. Następnie należy sprawdzić, czy polisa jest poprawna technicznie.
• Nieoczekiwany Drop: Prawidłowy ruch jest odrzucany przez regułę lub moduł. Rule ID, NAT ID, sprawdź moduł i przyczynę w Log Viewer lub Packet Capture.
• Brak zapory ogniowej-Drop: Ruch w ogóle nie dociera do zapory ogniowej lub odpowiedź przebiega inną trasą. Sprawdź klienta, VLAN, przełącznik, bramę, trasę, SD-WAN lub ścieżkę powrotną.

Ta klasyfikacja zapobiega niepotrzebnym wyjątkom. Jeśli potrzebny jest Drop, nie ma potrzeby naprawy technicznej, ale raczej decyzja polityczna. Jeśli ruch w ogóle nie dociera do zapory, nowa reguła zapory nie pomoże. Jeśli moduł bezpieczeństwa blokuje się, nie należy na ślepo tworzyć szerokiej reguły zapory sieciowej.

Pierwsza klasyfikacja

Przed analizą należy możliwie szczegółowo wyizolować błąd.

Ważne pytania:

• Którego źródłowego i docelowego adresu IP dotyczy problem?
• Który port i jaki protokół są używane?
• Czy jest to Internet klienta, sieć VPN typu site-to-site, dostęp zdalny, DNAT, WAF czy ruch wewnętrzny?
• Czy błąd jest trwały czy sporadyczny?
• Czy dotyczy to tylko jednej aplikacji, jednego użytkownika czy całej sieci?
• Czy ostatnio zmieniono regułę zapory sieciowej, regułę NAT, trasę, regułę SD WAN, regułę TLS Inspection lub politykę sieciową?

Bez tej informacji często szukasz zbyt szeroko w Log Viewer. Lepszy jest powtarzalny test z czasem, adresami IP i oczekiwanym kierunkiem.

Użyj poprawnie Log Viewer

Log Viewer to pierwszy punkt wyjścia. Pokazuje dzienniki zdarzeń i może być filtrowane według modułu, czasu, pola i dowolnego tekstu.

Log Viewer otwiera się w prawym górnym rogu interfejsu WebAdmin. W zależności od przypadku, w przypadku zrzutów ważne są następujące moduły:

• Zapora sieciowa: Dopasowywanie reguł, połączenia dozwolone i odrzucane.
• Sieć: Zasady sieciowe, kategoria, grupa adresów URL i skanowanie w poszukiwaniu złośliwego oprogramowania.
• Inspekcja SSL/TLS: Deszyfrowanie, błędy i wyjątki TLS.
• Filtr aplikacji: Trafienie w kontrolę aplikacji.
• IPS: Zapobieganie włamaniom i decyzje DPI.
• Aktywna reakcja na zagrożenie: Kanały o zagrożeniach, NDR Essentials lub inne trafienia ATR.
• Ochrona serwera WWW: WAF, odwrotne proxy i opublikowane usługi sieciowe.
• VPN: IPsec, SSL VPN i zdarzenia dostępu zdalnego.

Reguły zapory zazwyczaj rejestrują sesje, gdy zapora odbierze zdarzenie Destroy i zamknie połączenie. Jeśli połączenie zakończy się bez tego zdarzenia, nie zawsze będzie ono wyglądać zgodnie z oczekiwaniami. W przypadku połączeń SSL/TLS połączenie jest rejestrowane po uzgadnianiu i zamknięciu.

Konfiguracja dziennika jest również ważna. Jeśli typ dziennika nie zostanie aktywowany w System services > Log settings, nie będzie on wiarygodnie widoczny lokalnie, w Sophos Central lub w Syslog. W przypadku długoterminowej oceny odpowiednie jest Sophos Firewall wysłanie Syslog na adres SIEM lub Aktywowanie centralnego raportowania zapory.

Klasyfikacja zdarzeń Invalid Traffic

Invalid traffic to ważne odkrycie, ale nie pełna analiza przyczyn źródłowych. W ten sposób zapora zgłasza ruch, który nie jest wyraźnie zgodny z prawidłowym połączeniem lub decyzją dotyczącą zasad. Typowymi przykładami są pakiety poza oczekiwanym stanem sesji, ścieżki asymetryczne, sesje wygasłe, nieoczekiwane flagi TCP lub ruch zwrotny, który nie podąża tą samą ścieżką.

W przypadku takich zdarzeń nie należy najpierw tworzyć reguły Allow. Ten proces jest lepszy:

1. Przejmij źródło, miejsce docelowe, port i czas ze zdarzenia.
2. Sprawdź w Log Viewer, czy widoczny jest Firewall Rule ID, NAT Rule ID lub moduł.
3. Użyj Packet Capture, aby sprawdzić, czy oba kierunki przechodzą przez tę samą zaporę ogniową.
4. Sprawdź routing, SD-WAN, ścieżki VPN, rolę HA i trasę powrotną.
5. Dopiero wtedy zdecyduj, czy należy dostosować regułę, logikę NAT, trasę lub profil bezpieczeństwa.

Invalid traffic jest szczególnie cenne jako wskazanie problemów ze statusem lub ścieżką powrotną. Jeśli rozszerzona zostanie tylko reguła Allow, podstawowa przyczyna często pozostaje.

Użyj poprawnie Packet Capture

Ścieżka menu to:

Diagnostics > Packet capture

Packet Capture pokazuje, czy pakiety docierają do interfejsu, są przekazywane, przetwarzane przez samą zaporę ogniową, czy też odrzucane. Jest to szczególnie ważne, jeśli w Log Viewer nie pojawia się nic jasnego.

Proces podstawowy:

1. Limitowy przypadek testowy: zanotuj źródłowy adres IP, docelowy adres IP, port i protokół.
2. Otwórz Diagnostics > Packet capture.
3. Ustaw filtr przechwytywania tak wąski, jak to możliwe.
4. Włącz Packet Capture.
5. Problem z reprodukcją.
6. Zatrzymaj przechwytywanie.
7. Sprawdź wpisy według źródła, miejsca docelowego, Rule ID, NAT ID, stanu i przyczyny.

Packet Capture pokazuje między innymi Rule ID, NAT ID, Status, Powód, ID połączenia, ID filtra internetowego, ID aplikacji, IPS ID polityki i Nazwa użytkownika. Pola te są pomocne, gdy w grę wchodzi nie tylko reguła zapory sieciowej, ale także filtry sieciowe, IPS, Application Control lub NAT.

Bardziej szczegółową instrukcją obsługi narzędzia jest Packet Capture w WebAdmin użycie.

Zrozumienie stanu przechwytywania pakietów

Wartości stanu są kluczowe dla analizy. Sophos Firewall oferuje sześć wartości stanu w filtrze wyświetlania: Allowed, Violation, Consumed, Generated, Incoming i Forwarded.

• Przychodzący: Pakiet dociera do interfejsu WAN lub LAN. Źródło dociera do zapory ogniowej.
• Allowed: Pakiet został dopuszczony przez odpowiednią regułę zapory sieciowej lub politykę. Ten stan często pokrywa się w praktyce z Forwarded; jeśli pakiet pojawia się jako Allowed, ale nie jako Forwarded, warto sprawdzić routing, ścieżkę powrotną lub kolejny moduł bezpieczeństwa.
• Przekazany: Pakiet jest przekazywany dalej. Zapora zasadniczo umożliwia przejście pakietu.
• Wykorzystane: Pakiet jest przeznaczony dla samej zapory ogniowej. Wtedy istotne są Device Access, VPN Portal, DNS, DHCP lub inna usługa lokalna.
• Wygenerowano: Pakiet jest generowany przez zaporę ogniową. To jest odpowiedź lub ruch systemowy z zapory.
• Naruszenie: Pakiet został odrzucony z powodu naruszenia zasad. Zablokowana reguła, moduł lub funkcja bezpieczeństwa.

Pojedynczy Incoming bez pasującego Forwarded może oznaczać, że zapora sieciowa odrzuci pakiet, przetworzy go samodzielnie lub że filtr nie pokaże całego przepływu. Dlatego zawsze należy patrzeć w obie strony.

Nie należy tworzyć wyjątku bezpośrednio po pierwszym statusie. Następny test lepiej wyprowadzić ze statusu:

• Widoczny tylko Incoming: Sprawdź filtr, wykryj przeciwny kierunek, wyszukaj Rule ID i wyklucz identyfikator zapory 0.
• Incoming i Forwarded, ale brak odpowiedzi: Sprawdź trasę powrotną, system docelowy, zaporę serwera lokalnego, NAT i routing asymetryczny.
• Consumed widoczny: Device Access, sprawdź listę ACL usługi lokalnej i usługę lokalnej zapory ogniowej, której dotyczy problem.
• Generated widoczny: Sprawdź, czy zapora sieciowa odpowiada sama, czy generuje ruch systemowy.
• Violation widoczny: Powód dopasowania, Rule ID, NAT ID i moduł, którego dotyczy problem w Log Viewer.

Oznacza to, że analiza pozostaje powtarzalna: status decyduje, które narzędzie ma sens jako następne. Dla Violation ważne jest Log Viewer, jeśli nie ma odpowiedzi, ważniejsze jest powrót i Packet Capture, dla Consumed Device Access zamiast reguły zapory ogniowej.

Szybka selekcja objawów

W praktyce szybka selekcja objawów pozwala zaoszczędzić dużo czasu przed zagłębieniem się w kłody lub skorupę:

• Log Viewer pokazuje Invalid traffic: Skoncentruj się na stanie sesji, ścieżce zwrotnej i routingu asymetrycznym. Sprawdź oba kierunki za pomocą Packet Capture.
• Packet Capture pokazuje tylko Incoming: Skoncentruj się na Drop, usłudze lokalnej, regule domyślnej lub niekompletnym filtrze. Rozwiń filtr, uruchom test zasad i sprawdź identyfikator zapory 0.
• Packet Capture pokazuje Forwarded, ale brak odpowiedzi: Skoncentruj się na systemie docelowym, trasie powrotnej, NAT lub zewnętrznej zaporze ogniowej. Sprawdź pakiety odpowiedzi i trasę powrotną.
• Packet Capture pokazuje Consumed: Skoncentruj się na ruchu do samej zapory ogniowej. Sprawdź Device Access i listę ACL usług lokalnych.
• Packet Capture pokazuje Violation: Skoncentruj się na regule, module bezpieczeństwa lub naruszeniu zasad. Porównaj Powód, Rule ID, NAT ID i dziennik modułu.
• Log Viewer i Packet Capture nic nie pokazują: Ruch prawdopodobnie nie dociera do zapory ogniowej. Sprawdź klienta, VLAN, przełącznik, bramę lub nieprawidłowy cel testowy.

Firewall ID 0 i wyraźna reguła Drop

Jeśli nie są dopasowane żadne jawne reguły zapory sieciowej, Sophos Firewall odrzuca ruch poprzez wbudowaną regułę końcową z Firewall ID 0 lub identyfikatorem polityki 0. Ta reguła znajduje się zawsze na końcu reguł zapory. Ważne przy rozwiązywaniu problemów i SIEM: Wbudowana reguła Drop-all sama w sobie nie rejestruje ruchu. Jeśli chcesz zobaczyć wszystkie zerwane połączenia w możliwy do prześledzenia sposób, potrzebujesz własnej, wyraźnej reguły Drop z aktywnym rejestrowaniem.

Jeśli drops przez regułę domyślną nie są widoczne, decyzja polityki nie jest automatycznie błędna. W Packet Capture może być wtedy widoczne tylko Incoming, bez pasującego wpisu Violation Firewall. Problemem jest wówczas identyfikowalność podczas troubleshooting, a niekoniecznie sama decyzja o odrzuceniu ruchu.

Jeśli przypadek testowy nie pasuje do żadnej reguły, a mimo to nie widać Drop, należy także sprawdzić:

1. Użyj Test zasad i sprawdź, czy test dotyczy identyfikatora zapory 0, czy reguły domyślnej.
2. Sprawdź kolejność reguł i upewnij się, że żadna inna reguła znajdująca się wyżej nie została nieoczekiwanie dopasowana.
3. Utwórz jawną regułę Drop na końcu bazy reguł, jeśli zrzuty mają być rejestrowane lub przekazywane do Central Reporting lub Syslog.
4. Uruchom test ponownie i sprawdź, czy Drop jest teraz widoczny z jawnym identyfikatorem reguły.
5. Dołącz wyraźną regułę Drop do dokumentacji zmian i przeglądu reguł, aby nie została później błędnie zrozumiana jako zwykła reguła Allow/Deny.

Tworząc ostateczną regułę, należy świadomie wybierać strefy. Sophos zaleca używanie indywidualnych stref źródłowych i docelowych i nie ustawianie Any jako strefy ogólnej, aby nie wpływać niepotrzebnie na usługi wewnętrzne. Wyraźna reguła końcowa jest pomocna w środowisku odpornym na audyt. Nie zastępuje to jednak czystej struktury reguł. Jeśli duża część legalnego ruchu trafia do ostatecznej reguły, prawdopodobnie brakuje bardziej precyzyjnej reguły zezwalającej wyżej lub sieć jest klasyfikowana nieprawidłowo.

Przeczytaj ważne pola w Packet Capture

W przypadku upadków ważny jest nie tylko status. Dodatkowe pola pokazują, która część zapory sieciowej przetworzyła ruch.

• Rule ID: Dopasowana reguła zapory sieciowej. Sprawdź, czy pasuje do oczekiwanej reguły.
• NAT ID: Dopasowana reguła NAT. Sprawdź, czy oczekiwano NAT, czy go brakuje lub czy obowiązuje nieprawidłowa reguła NAT.
• Powód: Powód Drop lub naruszenie. Nie czytaj osobno, ale porównaj ze statusem i modułem.
• Identyfikator filtra sieciowego: Decyzja dotycząca zasad sieciowych. Sprawdź kategorię, grupę adresów URL i kontekst użytkownika.
• ID aplikacji: Wykryta aplikacja. Application Control może podjąć inną decyzję niż sugeruje port.
• IPS Identyfikator polityki: Zastosowano politykę IPS. Sprawdź podpis, kontekst reguły i ryzyko fałszywie pozytywne.
• Nazwa użytkownika: Wykryto użytkownika. Oceniaj dopasowanie użytkownika tylko wtedy, gdy jest on rzeczywiście widoczny.

Jeśli Rule ID lub NAT ID są nieoczekiwane, nie należy od razu tworzyć wyjątku. Najpierw musi być jasne, czy przypadek testowy został poprawnie zdefiniowany, czy powyższa została dopasowana do bardziej ogólnej reguły lub czy NAT zmienił widok źródła i miejsca docelowego.

Użyj powodu jako przewodnika

Wartość Reason nie jest pełnym raportem o pierwotnej przyczynie, ale stanowi dobry przewodnik do następnego modułu. Firewall mówi więcej o bazie reguł, regułach domyślnych lub logice strefy. LOCAL_ACL odpowiada Device Access i liście ACL usług lokalnych. INVALID_TRAFFIC wskazuje stan sesji, ścieżkę zwrotną lub routing asymetryczny. APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION lub VIRTUAL_HOST pokazują, że nie należy po prostu sprawdzać reguły zapory sieciowej.

Dlatego pomocny jest krótki potrójny skok: najpierw przeczytaj status, następnie sklasyfikowaj Powód, a następnie otwórz odpowiedni moduł w Log Viewer. Dzięki temu pojedynczy wpis Violation staje się możliwą do prześledzenia ścieżką audytu, a nie zaproszeniem do szerokiego wyjątku.

Wykorzystane i lokalne usługi zapory ogniowej

Consumed nie jest normalnym Drop. Status oznacza, że ​​pakiet jest przeznaczony dla samej zapory ogniowej. Typowe cele to WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN lub SNMP.

W takich przypadkach często nie decyduje zwykła reguła zapory sieciowej, ale raczej Device Access i ACL usługi lokalnej. Na przykład, jeśli nie można osiągnąć WebAdmin, SSH, VPN Portal lub SNMP, nie należy szukać tylko Rules and policies > Firewall rules. Prawidłowym punktem początkowym jest zwykle Administration > Device access.

Do wzmacniania i rozwiązywania problemów z lokalnymi usługami firewall, odpowiedni jest Sophos Firewall Bezpieczny dostęp: poprawnie skonfiguruj Device Access.

Typowe przyczyny Drop

Brak pasującej reguły zapory

Najczęstszą przyczyną jest niezgodna reguła. Przyczyny mogą być:

• niepoprawny Source zone
• niepoprawny Source network
• niepoprawny Destination zone
• Docelowy adres IP DNAT został błędnie zinterpretowany
• brak usługi lub nieprawidłowy protokół
• Użytkownik nie został uwierzytelniony
• Schedule nie pasuje
• bardziej szczegółowa reguła znajduje się poniżej bardziej ogólnej reguły

Jeśli chodzi o strukturę reguł, pomaga to w zrozumieniu i poprawnym skonfigurowaniu reguł Sophos Firewall. Jeśli w grę wchodzi DNAT, należy również sprawdzić opublikuj serwer poprzez DNAT do Sophos Firewall.

NAT lub trasa powrotna nie pasuje

Czasami zapora sieciowa zezwala na połączenie, ale odpowiedź jest inna lub jest nieprawidłowo przetłumaczona.

Typowe punkty:

• Brak SNAT lub MASQ.
• DNAT wskazuje na złego hosta wewnętrznego.
• Połączona reguła NAT została wyłączona.
• Brak trasy powrotnej.
• SD-WAN lub routing statyczny wysyła ruch zwrotny inną ścieżką.
• W ruchu VPN brakuje pasującej trasy IPsec lub trasy powrotnej.

Routing asymetryczny często powoduje powstawanie błędów trudnych do zrozumienia, ponieważ zapora nie może jasno przypisać stanu połączenia. Pakiety mogą wówczas wyglądać na nienależące do połączenia.

Pakiet nie należy do znanego połączenia

Komunikaty takie jak Could not associate packet to any connection lub podobne powiadomienia o połączeniu często oznaczają, że zapora nie może znaleźć odpowiedniego obiektu kontekstu połączenia.

Możliwe przyczyny:

• Ruch powrotny odbywa się inną trasą.
• Połączenie zostało nawiązane w innym węźle HA.
• Sesja już wygasła.
• Flagi TCP nie odpowiadają oczekiwanemu połączeniu.
• Urządzenie wysyła odpowiedzi bez wcześniejszego żądania.
• Inspekcja stanowa widzi tylko część przepływu danych.

Tutaj Packet Capture jest ważniejsze niż pojedynczy wpis w dzienniku. Musisz sprawdzić, czy oba kierunki przechodzą przez tę samą zaporę ogniową i tę samą strefę.

Filtr sieciowy, TLS Inspection, Application Control lub IPS zablokowany

Nie każde Drop pochodzi z samej reguły zapory. Ruch jest często dozwolony, ale następnie blokowany przez moduł bezpieczeństwa.

Typowe przykłady:

• Zasady sieciowe blokują kategorię lub grupę adresów URL.
• TLS Inspection przerywa działanie z powodu certyfikatu, SNI, szyfru lub wyjątku.
• Application Control wykrywa niechcianą aplikację.
• IPS blokuje wzór.
• Aktywna odpowiedź na zagrożenie napotkała IoC.
• Zero-Day Protection wstrzymuje lub blokuje pobieranie.

W przypadku trafień IPS należy sprawdzić sygnaturę, politykę i kontekst reguły przed ustawieniem szerokiego wyjątku. Odpowiedni proces można znaleźć w Sophos Firewall skonfiguruj IPS i przetestuj go bezpiecznie.

W przypadku Web i TLS należy również sprawdzić QUIC. Gdy przeglądarki korzystają z UDP 443, filtrowanie Web i oczekiwania TLS nie zawsze pasują do rzeczywistego ruchu. Więcej na ten temat: Sophos Firewall QUIC i HTTP/3 blokują poprawnie.

MTU, MSS lub fragmentacja

W przypadku VPN, PPPoE, SD-WAN, tuneli komórkowych lub zagnieżdżonych pakiet może być za duży dla ścieżki. Wtedy nie zawsze widzisz wyraźną zaporę sieciową Drop, ale raczej przerwy w połączeniu, powolne aplikacje lub zawieszające się poszczególne usługi.

W takich przypadkach odpowiednie jest Sophos Firewall Sprawdź MTU i MSS pod kątem problemów z VPN.

Przepływ zorganizowany

W praktyce ta kolejność sprawdza się dobrze:

1. Uwaga na przypadek testowy: Źródło, miejsce docelowe, port, protokół, czas.
2. Log Viewer sprawdź: Filtruj moduł zapory sieciowej i odpowiednie moduły bezpieczeństwa.
3. Rule ID i NAT ID search: Sprawdź, która reguła została faktycznie spełniona.
4. Packet Capture start: Ustaw wąski filtr i odtwórz test.
5. Sprawdź status: Oceń przychodzące, przekazane, wykorzystane, wygenerowane lub naruszenia.
6. Sprawdź kierunek powrotu: Czy odpowiedź wraca tą samą ścieżką?
7. Sprawdź moduły bezpieczeństwa: Web, TLS, Application Control, IPS, ATR, WAF.
8. Sprawdź logi usług: Jeśli występują problemy z usługą, sprawdź odpowiedni plik dziennika pod adresem /log.
9. Sprawdź logi centralne: Uwzględnij Central Reporting lub SIEM, jeśli logi lokalne nie są wystarczające.

Odpowiednie pliki usług i dziennika są podsumowane w Sophos Firewall Rozwiązywanie problemów: Services i dzienniki.

Jeśli nic nie pojawia się w Log Viewer

Brak wpisu w dzienniku nie oznacza automatycznie, że zapora nie jest zaangażowana.

Możliwe przyczyny:

• W regule zapory nie jest włączone rejestrowanie.
• Odpowiedni typ dziennika nie jest aktywny w System services > Log settings.
• Połączenie nie zostało prawidłowo zakończone i dlatego nie zostało zarejestrowane.
• Ruch w ogóle nie dociera do zapory.
• Ruch jest przetwarzany przez usługę lokalną.
• Filtr w Log Viewer jest zbyt wąski.
• Pamięć dziennika jest ograniczona lub stare wpisy zostały już nadpisane.

W takich przypadkach użyj najpierw Packet Capture. Jeśli Packet Capture również nie pokazuje żadnych danych wejściowych, uwaga skupia się bardziej na kliencie, przełączniku, VLAN, routingu przed zaporą ogniową lub złym celu testowym.

Gdy potrzebny jest tcpdump lub archiwa dzienników

WebAdmin Packet Capture jest dobry do szybkiej analizy. W przypadku dłuższych nagrań, plików PCAP, bardzo precyzyjnych filtrów lub przypadków wsparcia, tcpdump jest często lepszym rozwiązaniem niż SSH. Jest to szczególnie prawdziwe, jeśli problem występuje sporadycznie lub jeśli nagranie wymaga późniejszej oceny w Wireshark lub przez dział wsparcia Sophos.

W takich przypadkach przed nagraniem należy wyjaśnić:

• Który źródłowy adres IP, docelowy adres IP i porty muszą zostać uwzględnione w filtrze?
• Jak długo może trwać nagrywanie?
• Gdzie jest przechowywany plik PCAP?
• Kto może zobaczyć plik?
• Kiedy plik zostanie usunięty po analizie?

Praktyczny proces odbywa się w Sophos Firewall tcpdump: Nagrywanie pakietów poprzez CLI. Jeśli oprócz pakietów potrzebne są dzienniki usług, pomocne jest Sophos Firewall Zapisz dzienniki do celów wsparcia i analizy.

Ustaw tylko wyjątki

W przypadku upadków kuszące jest szybkie utworzenie wyjątku. Może to pomóc na krótką metę, ale często pogarsza bezpieczeństwo lub ukrywa przyczynę.

Wyjątki należy ustawiać tylko wtedy, gdy jest jasne:

• który moduł blokuje
• którego hosta, domeny lub aplikacji dotyczy problem
• dlaczego ruch jest legalny
• jak wąski może być wyjątek
• gdy wyjątek jest sprawdzany lub usuwany

Należy unikać szerokich wyjątków dla całych sieci, reguł Any lub globalnych wyjątków TLS. Lepszy jest mały, udokumentowany wyjątek z datą przeglądu.

Ustalenia w dokumencie

Dobry wynik Drop musi być udokumentowany w taki sposób, aby inna osoba mogła zrozumieć test. Jest to ważne w przypadku przeglądów wewnętrznych, zmiany dokumentacji i spraw wsparcia.

Przytrzymaj co najmniej:

• Data, godzina i strefa czasowa testu.
• źródłowy adres IP, docelowy adres IP, port, protokół i użytkownik.
• Oczekiwana reguła zapory sieciowej i faktycznie widoczna Rule ID.
• Oczekiwana reguła NAT i faktyczna widoczna reguła NAT ID.
• Stan przechwytywania pakietów: Allowed, Incoming, Forwarded, Consumed, Generated lub Violation.
• Odpowiednia przyczyna lub komunikat modułu.
• Wprowadzono zmianę lub celowo brak zmian.
• Jeśli ustawiono wyjątek: właściciel, cel, ważność i data przeglądu.

Niniejsza dokumentacja zapobiega przekształceniu się krótkoterminowego etapu rozwiązywania problemów w trwałą, niejasną lukę w zabezpieczeniach.

Lista kontrolna

• Znane źródłowy adres IP, docelowy adres IP, port i protokół.
• Udokumentowany czas testu.
• Log Viewer sprawdzone z właściwym modułem i filtrem czasowym.
• Oceniono Rule ID i NAT ID.
• Jeśli brakuje wpisu Drop, sprawdź, czy ma to wpływ na identyfikator zapory 0 lub regułę domyślną.
• Sprawdzono regułę zapory sieciowej i kolejność reguł.
• Sprawdzono regułę NAT i trasę powrotną.
• Packet Capture wykonane z wąskim filtrem.
• Stan i przyczyna ocenione w Packet Capture.
• Sprawdzono kierunek tam i z powrotem.
• Sprawdzono filtr sieciowy, TLS Inspection, Application Control, IPS i aktywną reakcję na zagrożenia.
• Sprawdzono MTU, MSS i trasę pod kątem VPN.
• Na hoście docelowym DNAT lub WAF sprawdzono adres hosta i zaplecze.
• Dzienniki centralne lub Syslog sprawdzone, czy dzienniki lokalne nie są wystarczające.
• Jeśli wymagana jest obsługa, specjalnie przygotowano tcpdump lub archiwum dziennika.
• Wyjątki są ustawione tylko wąsko i udokumentowane.
• Wyniki udokumentowane za pomocą Rule ID, NAT ID, statusu, przyczyny i zmiany.

Często zadawane pytania