Reguła Sophos Firewall nie działa: sprawdź przyczyny

Gdy reguła zapory nie działa, rzadko jest to spowodowane awarią zapory. Zazwyczaj nie pasuje jakiś warunek, nad nią znajduje się bardziej ogólna reguła, NAT zmienia widok na ruch, dopasowanie użytkownika nie jest spełnione lub logowanie nie jest poprawnie aktywowane.

Ta lista kontrolna pomaga podejść do problemu systematycznie, zamiast przypadkowo zmieniać reguły.

Orientacja

Zacznij od jasnego przypadku testowego, zanim zmienisz reguły lub funkcje bezpieczeństwa.

Który artykuł pasuje?

Problemy z regułami szybko się krzyżują z NAT, routingiem, VPN, Device Access lub funkcjami bezpieczeństwa. Do analizy należy najpierw ustalić, która warstwa jest dotknięta:

• Zrozumienie reguły zapory od podstaw: Zrozumienie i poprawna konfiguracja reguł Sophos Firewall
• Testowanie pojedynczego połączenia za pomocą Log Viewer, Policy Tester i Packet Capture: Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture
• Zaangażowany jest NAT, SNAT, DNAT, MASQ lub PAT: Zrozumienie NAT na Sophos Firewall
• Serwer jest publikowany z Internetu za pomocą DNAT: Publikowanie serwera za pomocą DNAT
• Dostęp dotyczy WebAdmin, VPN Portal, SSH, DNS lub SNMP zapory: Poprawna konfiguracja Device Access
• Niejasna jest trasa, SD-WAN lub powrót: Dostosowanie priorytetu routingu na Sophos Firewall
• Pakiety muszą być sprawdzane bezpośrednio na zaporze: Użycie Packet Capture w WebAdmin

To rozróżnienie jest ważne, ponieważ reguła zapory nie kontroluje każdego rodzaju dostępu. Lokalne usługi zapory, decyzje NAT, routing i funkcje bezpieczeństwa mają własne punkty kontrolne.

Szybkie zawężenie

Na początku nie należy od razu przesuwać reguł ani zmieniać obiektów. Najpierw należy zawęzić, w którym miejscu ruch jest tracony.

• Licznik reguł pozostaje 0: Pozycja reguły, strefa, źródło, cel, usługa lub harmonogram nie pasują
• Log Viewer pokazuje inną regułę: Nad nią znajduje się bardziej ogólna lub automatycznie wygenerowana reguła
• Log Viewer nic nie pokazuje: Brak logowania lub ruch nie dociera do zapory
• Packet Capture nie widzi pakietu: Problem leży przed zaporą: klient, VLAN, przełącznik, brama, dostawca lub grupa bezpieczeństwa w chmurze
• Packet Capture widzi pakiety, ale brak przekierowania: Reguła zapory, NAT, routing lub funkcja bezpieczeństwa blokuje
• Packet Capture widzi przekierowanie, ale brak odpowiedzi: Sprawdź trasę powrotną, system docelowy, NAT lub zewnętrzną zaporę

To rozróżnienie oszczędza czas. Jeśli zapora nie widzi pakietu, żadna zmiana w regule zapory nie pomoże. Jeśli Log Viewer pokazuje inną Rule ID, kolejność jest ważniejsza niż dotknięta reguła docelowa. Jeśli przepływ pakietów i Rule ID są zgodne, analiza przesuwa się do NAT, trasy powrotnej lub funkcji bezpieczeństwa.

Dokładne zdefiniowanie przypadku testowego

Reguła może być sensownie sprawdzona tylko wtedy, gdy przypadek testowy jest jednoznaczny. Stwierdzenia takie jak “Internet nie działa” lub “VPN nie działa” są zbyt szerokie. Do diagnozy potrzebny jest konkretny przepływ.

Przed testem należy ustalić:

• Source IP: Klient 10.10.20.35
• Source zone: LAN, VPN, DMZ lub strefa użytkownika
• User: uwierzytelniony użytkownik lub brak dopasowania użytkownika
• Destination: IP serwera, FQDN, publiczne IP lub obiekt WAN
• Service: TCP 443, UDP 53, ICMP, usługa użytkownika
• Oczekiwana reguła: Nazwa reguły lub Rule ID, jeśli znana
• Oczekiwana reguła NAT: NAT Rule ID lub nazwa reguły, jeśli NAT jest zaangażowany
• Czas testu: dokładny czas dla Log Viewer i późniejszych plików logów

Następnie zawsze powtarza się ten sam test. Jeśli podczas analizy zmienia się Source-IP, cel, rozdzielczość DNS lub port, nie porównuje się już tego samego przypadku.

Prawidłowe łączenie narzędzi analitycznych

Sophos Firewall oferuje kilka narzędzi, które odpowiadają na różne pytania. Żadne z nich nie jest samodzielnym dowodem.

• Licznik reguł: Czy nowy ruch testowy zasadniczo trafia do reguły? Nie pokazuje, dlaczego aplikacja mimo to zawodzi
• Log Viewer: Która Rule ID, NAT Rule ID, Action, User lub funkcja bezpieczeństwa została zarejestrowana? Zależy od logowania i zakończenia sesji
• Policy Tester: Jaka logika polityki zadziałałaby dla zdefiniowanego przepływu? Nie zastępuje prawdziwego przepływu pakietów i nie odwzorowuje w pełni SD-WAN
• Packet Capture: Czy pakiety docierają, są przekazywane czy odrzucane? Nie wyjaśnia każdej warstwy aplikacji i wymaga ścisłych filtrów
• Logi usług: Czy moduł taki jak Web, IPS, uwierzytelnianie lub VPN ma własny problem? Sensowne dopiero, gdy dotknięta usługa jest zawężona

Dla wiarygodnego wyniku łączy się co najmniej Log Viewer i prawdziwy test. W przypadku sprzecznych wyników, Packet Capture jest zazwyczaj następnym krokiem, ponieważ pokazuje, czy pakiety rzeczywiście docierają i są przekazywane.

Drzewo decyzyjne dla pierwszego testu

Do pierwszej analizy często wystarcza krótkie drzewo decyzyjne. Zapobiega to natychmiastowej pracy nad regułami, NAT i routingiem jednocześnie.

• Packet Capture nie widzi pakietu: Sprawdź klienta, VLAN, przełącznik, bramę, dostawcę, grupę bezpieczeństwa w chmurze lub zaporę przed zaporą
• Packet Capture widzi pakiet, Log Viewer pozostaje pusty: Sprawdź logowanie, typ logu, zakończenie sesji i odpowiedni filtr BPF
• Log Viewer pokazuje inną Rule ID: Porównaj kolejność reguł, strefy, źródło, cel, usługę i harmonogram
• Firewall Rule ID pasuje, NAT Rule ID nie pasuje: Sprawdź kolejność NAT i pola Original
• Rule ID i NAT ID pasują, ale brak odpowiedzi: Sprawdź trasę powrotną, system docelowy, lokalną zaporę na serwerze lub zewnętrzną blokadę
• Reguła działa tylko dla niektórych użytkowników: Sprawdź dopasowanie użytkownika, grupę, uwierzytelnianie i użytkowników bez klienta

Dzięki temu analiza pozostaje kontrolowana: najpierw udowadnia się, czy ruch dociera do zapory. Następnie sprawdza się, która reguła i która reguła NAT rzeczywiście działają. Dopiero gdy te dwa punkty są zgodne, warto szukać przyczyny w trasie powrotnej, funkcjach bezpieczeństwa lub warstwie aplikacji.

Zrozumienie dopasowania reguł

Sophos Firewall przetwarza reguły po kolei. Wygrywa pierwsza pasująca reguła.

Pierwsza zasada: Pierwsza pasująca reguła wygrywa

Sophos Firewall przetwarza reguły zapory od góry do dołu. Gdy tylko reguła pasuje, kolejne reguły nie są już sprawdzane. Ta sama zasada dotyczy również reguł NAT.

Ważne:

• Pozycja na liście decyduje o ocenie.
• Rule ID to tylko odniesienie i nie mówi nic o aktualnej kolejności.
• Grupy reguł pomagają w przejrzystości, ale nie są własną logiką dopasowania.
• Ogólna reguła powyżej może całkowicie “pochłonąć” bardziej szczegółową regułę poniżej.

Jeśli reguła nie działa, najpierw sprawdza się pozycję.

Resetowanie licznika reguł

W przypadku niejasnych trafień pomocne jest zresetowanie licznika reguł.

1. Otwórz Rules and policies > Firewall rules.
2. Znajdź dotkniętą regułę.
3. Otwórz menu z trzema kropkami.
4. Wybierz Reset data transfer count.
5. Ponownie odtwórz ruch.
6. Sprawdź licznik po teście.

Jeśli licznik nie rośnie, reguła nie pasuje. Jeśli rośnie, ale aplikacja mimo to nie działa, problem leży raczej w Security Profiles, NAT, routingu, trasie powrotnej lub systemie docelowym.

Sprawdzanie pól dopasowania

Reguła zapory pasuje tylko wtedy, gdy wszystkie istotne kryteria są spełnione.

• Source zones: Zła strefa, VLAN znajduje się w innej strefie, ruch VPN pochodzi z VPN
• Source networks and devices: Zły obiekt, zły IP, niekompletna grupa hostów
• Destination zones: Zła strefa docelowa, szczególnie przy DNAT lub VPN
• Destination networks: Zamieniono widok przed NAT i po NAT
• Services: Brak portu, zamieniono TCP/UDP, aplikacja używa dodatkowych portów
• Users or groups: Użytkownik nie jest uwierzytelniony lub zła grupa
• Schedule: Harmonogram nie pasuje obecnie
• Exclusions: Ruch jest wyłączony z reguły i przetwarzany dalej poniżej

W przypadku ruchu sieciowego należy dodatkowo sprawdzić, czy QUIC jest aktywny. Jeśli przeglądarki wysyłają ruch przez UDP 443, niektóre oczekiwania dotyczące filtrowania sieci i skanowania działają inaczej niż w przypadku klasycznego HTTPS przez TCP.

Więcej na ten temat: Sophos Firewall i protokół QUIC.

Nie pomijaj DNS, FQDN i IPv6

Reguła może wyglądać poprawnie, ale mimo to nie pasować, jeśli klient osiąga inny cel niż oczekiwano. Często zdarza się to w przypadku obiektów FQDN, Split DNS, usług CDN, IPv6 lub aplikacji, które używają wielu celów równolegle.

Przed zmianami reguł należy sprawdzić:

• Jakie IP faktycznie rozwiązuje klient?: DNS-Cache, Split DNS lub inny resolver mogą dostarczyć inny adres niż oczekiwano.
• Czy to IPv4 czy IPv6?: Reguły IPv4 nie pasują do ruchu IPv6. Jeśli klienci preferują IPv6, strona IPv6 musi być sprawdzona osobno.
• Czy w zaporze używany jest host FQDN?: Zapora musi rozwiązać FQDN i znać aktualne IP docelowe. Usługi CDN lub chmurowe mogą dostarczać wiele zmieniających się IP.
• Czy aplikacja używa dodatkowych celów?: Logowanie, API, aktualizacje, telemetria lub ścieżki multimedialne mogą używać innych domen i portów niż główna aplikacja.
• Czy wewnętrzny klient używa publicznej nazwy wewnętrznej usługi?: Wtedy możliwe przyczyny to Split DNS, Loopback NAT lub błędna publiczna rozdzielczość.

Dla diagnozy kluczowe jest nie tylko zanotowanie nazwy hosta, ale porównanie faktycznie używanego IP docelowego w Log Viewer lub Packet Capture. Jeśli reguła wskazuje na określony obiekt FQDN lub host, ale klient używa innego IP, reguła nie będzie pasować.

W przypadku wewnętrznych rozdzielczości nazw pomocne są czyste trasy żądań DNS. Procedura jest opisana w Konfigurowanie tras żądań DNS na Sophos Firewall. Jeśli IPv6 jest aktywne w środowisku, należy dodatkowo sprawdzić, czy IPv6 jest świadomie planowane i czy istnieje odpowiednia polityka. Podstawy są opisane w Konfigurowanie delegacji prefiksu IPv6 na Sophos Firewall.

Ruch do samej zapory to przypadek szczególny

Nie każdy dostęp do Sophos Firewall jest kontrolowany przez normalne reguły zapory. Jeśli klient ma dotrzeć do samej zapory, na przykład WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS lub SNMP, kluczowe są Device Access i Local service ACL.

Typowe przykłady:

• WebAdmin z LAN lub WAN: Device Access, Local service ACL, MFA, uprawnienia administratora
• VPN Portal lub User Portal: Device Access, konfiguracja portalu, uprawnienia użytkownika
• SSH do zapory: Device Access, Local service ACL, prawa administratora, sieć źródłowa
• SSL VPN lub połączenie IPsec: Device Access dla odpowiedniej strefy, konfiguracja VPN, uwierzytelnianie
• DNS do zapory: Device Access, konfiguracja DNS, ścieżka żądania
• SNMP do zapory: Device Access, konfiguracja SNMP, źródło monitorowania

Jeśli reguła zapory nie działa dla takiego ruchu, często nie jest to błąd reguły. Ruch kończy się na zaporze i jest traktowany jako lokalna usługa. Dla zabezpieczenia tych usług kluczowy jest artykuł Zabezpieczanie dostępu do Sophos Firewall: Poprawna konfiguracja Device Access. Dla portali dodatkowo pasuje Przegląd portali Sophos.

Sprawdzenie NAT, DNAT i ID

Dla ruchu DNAT reguły firewall i reguły NAT trzeba czytać razem.

Prawidłowe odczytywanie DNAT

W przypadku DNAT widok w regułach zapory jest szczególnie ważny. Jako zasadę można zapamiętać:

Reguły zapory dla ruchu DNAT używają strefy docelowej po NAT, ale IP docelowego przed NAT.

Przykład:

• Zewnętrzny klient łączy się z publicznym IP zapory.
• NAT tłumaczy na wewnętrzny serwer w DMZ.
• Reguła zapory używa jako strefy docelowej strefy wewnętrznego serwera, na przykład DMZ.
• Sieć docelowa pozostaje jednak publicznym IP lub obiektem WAN, do którego klient się odwołał.

Jeśli ta kombinacja jest błędna, reguła NAT może wyglądać poprawnie, ale reguła zapory mimo to nie pasuje.

Więcej na ten temat: Publikowanie serwera za pomocą DNAT na Sophos Firewall.

Sprawdzanie reguł NAT

NAT nie pozwala na ruch. NAT tylko tłumaczy. Zawsze potrzebna jest dodatkowo pasująca reguła zapory.

Pod Rules and policies > NAT rules należy sprawdzić:

• Czy odpowiednia reguła NAT znajduje się powyżej bardziej ogólnych reguł NAT?
• Czy reguła jest aktywna?
• Czy Original source, destination i service są zgodne?
• Czy Translated source, destination i service są zgodne?
• Czy używany jest MASQ lub stałe IP SNAT?
• Czy istnieje Linked NAT Rule, która nieoczekiwanie działa?
• Czy istnieje ogólna reguła SNAT, która pasuje przed bardziej szczegółową regułą?

Sophos zaleca dla prostych środowisk zazwyczaj samodzielne reguły NAT, zamiast tworzenia Linked NAT Rule dla każdej reguły zapory.

Więcej na ten temat: Zrozumienie NAT na Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Czytanie razem Firewall Rule ID i NAT Rule ID

Jeśli NAT jest zaangażowany, pytanie “Która reguła zapory działa?” nie wystarcza. Połączenie może trafić na oczekiwaną Firewall Rule ID, ale mimo to przechodzić przez błędną NAT Rule ID. Odwrotnie, reguła NAT może wyglądać poprawnie, podczas gdy bardziej ogólna reguła zapory powyżej już przetwarza ruch.

Do testu należy zatem wcześniej zanotować:

• Oczekiwana Firewall Rule ID: Pokazuje, czy właściwa reguła zapory pozwala lub blokuje ruch
• Oczekiwana NAT Rule ID: Pokazuje, czy właściwa reguła SNAT, DNAT, MASQ lub PAT tłumaczy
• Faktyczne ID w Log Viewer: Potwierdza, czy zapora przetwarza przepływ zgodnie z planem
• ID w Packet Capture: Pomaga, gdy Log Viewer wydaje się niekompletny lub trasa powrotna jest niejasna

Interpretacja jest stosunkowo prosta, ale oszczędza dużo czasu na poszukiwania:

• Firewall Rule ID pasuje, NAT Rule ID jest błędna: Sprawdź kolejność NAT, pola Original i bardziej ogólne reguły NAT
• NAT Rule ID pasuje, Firewall Rule ID jest błędna: Sprawdź kolejność reguł zapory, strefy, źródło, cel i usługę
• Oba ID pasują, ale połączenie mimo to zawodzi: Sprawdź trasę powrotną, serwer docelowy, funkcję bezpieczeństwa lub aplikację
• Brak widocznej NAT Rule ID, mimo że oczekiwany jest NAT: Ponownie sprawdź przepływ testowy, kryteria NAT, kierunek i logowanie

Ważne jest, aby nie zmieniać od razu obu zestawów reguł jednocześnie. Najpierw należy zdecydować, czy problem leży w dopasowaniu zapory, czy w dopasowaniu NAT. Dopiero potem należy zmienić konkretną pozycję reguły, obiekt lub pole. Bardziej szczegółowa ocena NAT znajduje się w sekcji Prawidłowe czytanie Firewall Rule ID i NAT Rule ID.

Sprawdzenie użytkowników, routingu i funkcji bezpieczeństwa

User Matching, routing, NAT, logowanie i profile bezpieczeństwa mogą wpływać na dopasowanie reguły.

Sprawdzanie dopasowania użytkownika i uwierzytelniania

Reguły z dopasowaniem użytkownika lub grupy często wyglądają poprawnie, ale działają tylko wtedy, gdy zapora może w tym momencie rzeczywiście przypisać użytkownika do ruchu.

Do sprawdzenia:

• Czy użytkownik jest widoczny w Log Viewer?
• Czy ruch pochodzi z oczekiwanego urządzenia lub innego klienta?
• Czy użytkownik jest w odpowiedniej grupie zapory?
• Czy działa AD SSO, STAS, Captive Portal, RADIUS lub Entra ID SSO?
• Czy reguła bez dopasowania użytkownika działa powyżej planowanej reguły użytkownika?
• Czy istnieją użytkownicy bez klienta, którzy są traktowani inaczej?
• Czy MFA lub dostęp do portalu są pomyślne, ale reguła zapory dla rzeczywistego ruchu użytkownika jest błędna?

W przypadku Remote Access należy oddzielić problem użytkownika od problemu VPN. Użytkownik może się pomyślnie zalogować, ale mimo to nie osiągnąć wewnętrznej aplikacji, jeśli VPN-Pool, reguła zapory, NAT lub routing nie pasują. Dla podstaw AD pasuje Dodawanie Active Directory na Sophos Firewall, dla scenariuszy Remote Access opartych na Entra Microsoft Entra ID SSO dla Sophos Connect i VPN Portal. Jeśli użytkownik loguje się przez Captive Portal z Entra ID SSO, pasuje Konfigurowanie Microsoft Entra ID SSO dla Captive Portal Sophos Firewall.

Oddzielanie logowania użytkownika od dopasowania reguły

Pomyślne logowanie do VPN Portal, User Portal, Captive Portal lub przez Microsoft Entra ID SSO nie dowodzi jeszcze, że planowana reguła użytkownika dopasowuje rzeczywisty ruch. Logowanie potwierdza najpierw tylko uwierzytelnianie. Następnie zapora musi poprawnie połączyć użytkownika, IP źródłowe, grupę i przepływ ruchu.

Do analizy należy zatem oddzielnie sprawdzić:

• Użytkownik loguje się, licznik reguł pozostaje 0: Sprawdź VPN-Pool, Source zone, Source network, warunek grupy lub pozycję reguły
• Pole użytkownika w Log Viewer jest puste: Sprawdź STAS, Captive Portal, AD SSO, Entra ID SSO lub użytkowników bez klienta
• Użytkownik jest widoczny, ale działa błędna reguła: Sprawdź kolejność reguł, filtr grupy lub bardziej ogólną regułę powyżej
• Dotyczy tylko użytkowników VPN: Sprawdź strefę VPN, VPN-Pool, konfigurację SSL/IPsec i profil Sophos Connect
• Dotyczy tylko pojedynczych użytkowników: Porównaj UPN, adres e-mail, zaimportowaną grupę i grupę zapory

W lokalnych środowiskach AD pomocne są STAS i Dodawanie Active Directory na Sophos Firewall. W przypadku konfiguracji opartych na Entra należy w zależności od ścieżki logowania sprawdzić Microsoft Entra ID SSO dla Sophos Connect i VPN Portal lub Entra ID SSO dla Captive Portal. Jeśli zaangażowanych jest bardzo wielu użytkowników lub użytkowników bez klienta, dodatkowo może być istotny Limit ID użytkownika Sophos Firewall.

Sprawdzanie routingu i SD-WAN

Jeśli reguła pasuje, ale połączenie nie działa, problemem może być routing.

Należy sprawdzić:

• Czy istnieje odpowiednia trasa domyślna?
• Czy istnieje trasa statyczna?
• Czy działa trasa SD-WAN?
• Czy brama jest aktywna?
• Czy istnieją trasy powrotne na systemie docelowym lub w zdalnej sieci?
• Czy trasa powrotna jest symetryczna?
• Czy ruch przechodzi przez VPN, MPLS lub inne interfejsy niż oczekiwano?

Ważne: Policy Tester nie odwzorowuje w pełni routingu SD-WAN. Jest bardzo pomocny dla decyzji dotyczących polityki zapory, SSL/TLS i sieci, ale nie zastępuje prawdziwego testu przepływu pakietów.

Więcej na ten temat: Dostosowanie priorytetu routingu na Sophos Firewall.

Aktywowanie logowania

Bez logów rozwiązywanie problemów jest uciążliwe. Należy sprawdzić dwa miejsca:

1. W regule zapory musi być aktywowane Log firewall traffic.
2. Pod System services > Log settings musi być aktywowany odpowiedni typ logu lokalnie, dla Sophos Central lub dla Syslog.

Log Viewer zazwyczaj pokazuje sesje zapory, gdy zapora kończy połączenie i otrzymuje zdarzenie Destroy. Jeśli połączenie internetowe po prostu się urywa, może się zdarzyć, że nie każda sesja pojawia się tak, jak się tego oczekuje.

Log Viewer otwiera się w prawym górnym rogu konsoli WebAdmin. Sensowne filtry to:

• Source IP
• Destination IP
• Port lub usługa
• Rule ID
• Nazwa reguły
• Action
• User
• NAT rule ID

Więcej na ten temat: Rozwiązywanie problemów z Sophos Firewall: Usługi i logi.

Użycie Packet Capture

Jeśli Log Viewer i licznik reguł nie wystarczają, używa się Diagnostics > Packet capture.

Najważniejsze pytanie brzmi, czy pakiet dociera, jest przekazywany czy już zatrzymuje się na zaporze.

• Żaden pakiet nie dociera: Problem leży przed zaporą: klient, przełącznik, VLAN, brama, dostawca, grupa bezpieczeństwa w chmurze
• Pakiet dociera, ale nie wychodzi: Sprawdź regułę zapory, NAT, routing lub funkcję bezpieczeństwa
• Pakiet wychodzi, ale brak odpowiedzi: Sprawdź trasę powrotną, system docelowy, NAT lub zewnętrzną blokadę
• Pakiet jest wyświetlany z Violation: Polityka lub funkcja bezpieczeństwa blokuje
• Pakiet pokazuje NAT ID i Rule ID: Porównaj trafienia reguł i NAT

Więcej na ten temat: Użycie narzędzia Packet Capture w WebAdmin.

Nie zmieniaj wielu rzeczy jednocześnie

W przypadku problemów z regułami kusi, aby jednocześnie dostosować pozycję, usługę, NAT, politykę sieciową i routing. Czasami to rozwiązuje dostęp krótkoterminowo, ale później utrudnia zrozumienie przyczyny.

Lepiej jest podejść krok po kroku:

1. Zanotuj stan początkowy: Rule ID, NAT ID, źródło, cel, usługa, czas.
2. Wykonaj dokładnie jedną zmianę.
3. Powtórz test z tym samym Source IP i tym samym celem.
4. Ponownie porównaj Log Viewer i Packet Capture.
5. Udokumentuj wynik.
6. Dopiero potem sprawdź następną zmianę.

Dla reguł produkcyjnych powinno być również jasne, czy zmiana jest trwała, czy tylko jako reguła testowa. Tymczasowe reguły powinny mieć właściciela i datę wygaśnięcia, w przeciwnym razie często pozostają w zestawie reguł przez lata.

Sprawdzanie funkcji bezpieczeństwa pojedynczo

Jeśli reguła pasuje, ale aplikacja nie działa, może interweniować profil ochrony:

• Polityka sieciowa
• Reguła inspekcji SSL/TLS
• Profil deszyfracji
• Polityka IPS
• Kontrola aplikacji
• Skanowanie złośliwego oprogramowania
• Ochrona przed zerowym dniem
• Security Heartbeat
• Kształtowanie ruchu

Do testów nie można ogólnie wszystkiego trwale wyłączać. Lepiej jest: krótko sprawdzić, obserwować Log Viewer, a następnie dokładnie usunąć przyczynę. W przypadku inspekcji TLS pomocny jest artykuł Stopniowe wdrażanie inspekcji TLS na Sophos Firewall.

Dla reguł produkcyjnych nie należy traktować funkcji bezpieczeństwa jako bloku zbiorczego. Lepiej jest zawęzić jedno po drugim:

• Kategoria sieciowa lub URL jest blokowana: Sprawdź politykę sieciową, kategorię, wyjątek i Log Viewer
• Aplikacja jest błędnie rozpoznawana: Sprawdź kontrolę aplikacji i log IPS
• Strona HTTPS ładuje się tylko bez inspekcji: Sprawdź regułę inspekcji SSL/TLS, dystrybucję CA, profil deszyfracji i wyjątki
• Połączenie przerywa się przy dużych danych: Sprawdź MTU/MSS, ścieżkę VPN, fragmentację i Packet Capture
• Trafienie w IPS lub ochronę przed zerowym dniem: Oceń sygnaturę, politykę, system docelowy i ryzyko fałszywego alarmu
• Dotyczy tylko pojedynczych użytkowników: Sprawdź dopasowanie użytkownika, Security Heartbeat, grupę i uwierzytelnianie

Jeśli dla testu usunięto profil ochrony, zmiana powinna być ściśle ograniczona: tylko dotknięte źródło, tylko konkretny cel, tylko na czas testu. Następnie przywraca się pierwotną ochronę lub dokumentuje się konkretny wyjątek.

Sprawdzić historię zmian

Jeśli reguła działała wczoraj, a dziś już nie działa, nie należy sprawdzać tylko jej aktualnej zawartości. Często krótko wcześniej zmieniono obiekt, pozycję reguły, regułę NAT, grupę, usługę albo policy z Central.

Praktyczne punkty kontroli:

• Czy zmieniono samą regułę firewall?: Audit Trail, Config Studio, opis reguły
• Czy zmieniono używany obiekt?: Hosts and services, Audit Trail, Config Studio
• Czy przesunięto pozycję reguły?: Lista reguł firewall, Audit Trail
• Czy przesłano policy z Central?: Sophos Central Task Queue i lokalny widok firewalla
• Czy zmieniono regułę NAT lub trasę SD-WAN?: Reguły NAT, routing, Audit Trail, Packet Capture

Dla śledzenia zmian przydatne są Sprawdzanie Audit Trail Logs Sophos Firewall i Korzystanie z Sophos Firewall Config Studio. Jeśli zmiana pochodzi z Sophos Central, należy dodatkowo sprawdzić Sophos Central Firewall Management Task Queue.

Praktyczny przebieg i typowe przyczyny

Większość problemów z dopasowaniem można szybko zawęzić stałą sekwencją troubleshootingową.

Częste przyczyny

• Licznik reguł pozostaje 0: Błędna pozycja reguły, strefa źródłowa, strefa docelowa lub usługa
• Log pokazuje inną regułę: Nad nią znajduje się bardziej ogólna reguła
• Brak widocznego logu: Logowanie nieaktywne lub ruch nie dociera do zapory
• DNS działa, sieć nie: Sprawdź usługę, politykę sieciową, inspekcję TLS lub QUIC
• Nazwa hosta pasuje, ale IP docelowe jest inne: Sprawdź DNS, obiekt FQDN, Split DNS, adresy CDN lub IPv6
• HTTPS nie jest skanowany: Brak pasującej reguły inspekcji SSL/TLS lub CA nie jest dystrybuowane
• DNAT nie działa: Reguła zapory używa błędnej strefy docelowej lub błędnej sieci docelowej
• Ruch VPN nie pasuje: Sprawdź strefę VPN, trasę, interfejs tunelu lub kontekst XFRM
• Dotyczy tylko niektórych użytkowników: Sprawdź dopasowanie użytkownika, grupę, SSO, Captive Portal lub Heartbeat

Praktyczny przebieg

1. Zanotuj problem z Source IP, Destination, Port, User i czasem.
2. Sprawdź pozycję reguły.
3. Zresetuj licznik reguł.
4. Odtwórz test.
5. Filtruj Log Viewer według Source IP i Destination IP.
6. Sprawdź regułę NAT i routing.
7. Uruchom Packet Capture z wąskim filtrem.
8. Sprawdź funkcje bezpieczeństwa tylko celowo.
9. Udokumentuj zmianę.

Dla złożonego przebiegu testowego zobacz Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture.

Lista kontrolna dla rozwiązywania problemów z regułami

• Zdefiniowany konkretny przypadek testowy z Source, Destination, Service, User i czasem.
• Sprawdzono pozycję reguły i zresetowano licznik reguł dla testu.
• Log Viewer pokazuje oczekiwaną Rule ID lub inną regułę, którą można zrozumieć.
• Rozdzielczość DNS, faktyczne IP docelowe i wersja IP zostały porównane z przypadkiem testowym.
• W przypadku DNAT strefa docelowa po NAT i sieć docelowa przed NAT są poprawnie ustawione.
• Sprawdzono NAT Rule ID, jeśli NAT jest zaangażowany.
• Ruch do samej zapory został oddzielony od ruchu przez zaporę.
• Dopasowanie użytkownika zostało ocenione tylko wtedy, gdy użytkownik jest widoczny w Log Viewer.
• W przypadku reguł użytkownika oddzielnie oceniono logowanie, przypisanie użytkownika i rzeczywistą decyzję reguły.
• Sprawdzono routing, SD-WAN, bramę i trasę powrotną.
• Packet Capture pokazuje Incoming, Forwarded, Violation lub brak odpowiedzi w sposób zrozumiały.
• Funkcje bezpieczeństwa zostały sprawdzone pojedynczo i nie zostały trwale wyłączone ogólnie.
• Zmiany testowe są udokumentowane, a tymczasowe reguły mają właściciela i datę wygaśnięcia.

FAQ