Jak prawidłowo testować reguły Sophos Firewall

Regułę zapory należy nie tylko zapisać, ale także celowo przetestować. Zwłaszcza w przypadku filtrowania sieci, inspekcji TLS, NAT, IPS lub dopasowywania użytkowników, reguła może wyglądać poprawnie wizualnie, ale nie działać zgodnie z oczekiwaniami.

Do testowania nadaje się kilka narzędzi:

• Log viewer do rzeczywistych zdarzeń i decyzji dotyczących reguł
• Policy tester do logiki polityki sieciowej, zapory i SSL/TLS
• Packet capture do rzeczywistego przepływu pakietów
• tcpdump do dłuższych nagrań, plików PCAP i przypadków wsparcia

Ważna jest właściwa kolejność: najpierw sprawdza się, czy test jest poprawnie zdefiniowany i czy reguła generuje logi. Następnie Log Viewer pokazuje, jaką decyzję zapora faktycznie zarejestrowała. Policy tester pomaga w oczekiwanej logice polityki, ale nie dowodzi rzeczywistego przepływu pakietów. Packet Capture jest najlepszym dowodem, gdy mogą być zaangażowane routing, NAT, VLAN, VPN, dostawca lub system docelowy. Jeśli test musi trwać dłużej, potrzebny jest plik PCAP lub wsparcie Sophos ma ocenić nagranie, lepszym narzędziem jest tcpdump na Sophos Firewall.

Dobry test reguły odpowiada więc nie tylko na pytanie, czy reguła “działa”. Pokazuje, która Rule ID faktycznie została dopasowana, która NAT ID była zaangażowana, czy zadziałały Security Features i czy kierunek tam i z powrotem idą oczekiwaną ścieżką.

Który artykuł jest odpowiedni?

Ten artykuł jest odpowiednim wprowadzeniem, jeśli ma być przetestowana konkretna próba połączenia z określonymi Source IP, Destination, Service i czasem. W przypadku powiązanych problemów często szybciej jest skorzystać z bardziej szczegółowego artykułu:

To rozróżnienie zapobiega zbyt szerokiemu badaniu specyficznego problemu z NAT, VPN, routingiem lub usługą za pomocą ogólnego testu reguł.

Prawidłowe przyporządkowanie narzędzi

Jeśli reguła rzekomo “nie działa”, nie należy od razu zmieniać samej reguły. Często przyczyna leży w NAT, routingu, nadrzędnej regule, braku logowania lub funkcji bezpieczeństwa. Do systematycznego rozwiązywania problemów pasuje dodatkowo Reguła Sophos Firewall nie działa: sprawdź przyczyny.

Do live troubleshooting lokalny Log Viewer pozostaje zwykle szybszy niż Central Reporting albo SIEM. Logi centralne są ważne, gdy zdarzenia trzeba później odtworzyć, skorelować albo przechowywać przez dłuższy czas. Do konfiguracji pasują Central Firewall Reporting oraz Syslog do SIEM.

Krótki przebieg testu reguły

Dla większości przypadków wsparcia wystarczy jasny przebieg:

1. Określ przypadek testowy z Source IP, Destination, Service, użytkownikiem i czasem.
2. Włącz Log firewall traffic w dotkniętej regule.
3. Sprawdź pozycję reguły i licznik użycia.
4. Dokładnie raz odtwórz test.
5. Filtruj Log Viewer według Source IP, Destination IP i Service.
6. Zanotuj Rule ID i NAT ID z rzeczywistego wpisu logu.
7. Użyj Policy tester tylko do logiki polityki.
8. Uruchom Packet Capture, jeśli Log Viewer i Policy tester nie pasują do siebie.
9. Udokumentuj wynik, zanim reguła zostanie przesunięta lub zmieniona.

Ważne jest, aby w jednym przebiegu zmieniać tylko jeden przypadek testowy. Jeśli jednocześnie zmienia się pozycję reguły, NAT, DNS, routing i klienta, późniejszego sukcesu nie da się już czysto przypisać.

Ten przebieg zapobiega niepotrzebnym zmianom działającej reguły, gdy rzeczywisty problem leży w NAT, routingu, DNS, inspekcji TLS lub systemie docelowym.

Przed testem

Najpierw należy dokładnie zanotować, co ma być testowane:

Następnie w dotkniętej regule zapory włącz Log firewall traffic. Bez logowania Log Viewer jest tylko ograniczenie pomocny.

Krok 1: Sprawdzenie pozycji reguły

Otwórz Rules and policies > Firewall rules i sprawdź:

• Czy reguła znajduje się powyżej bardziej ogólnych reguł?
• Czy jest aktywna?
• Czy wybrano właściwy widok IPv4 lub IPv6?
• Czy znajduje się w sensownej grupie reguł?
• Czy są wykluczenia?
• Czy powyżej znajduje się automatycznie utworzona reguła?

Jeśli testujesz nową regułę, powinieneś zresetować licznik użycia reguły. Następnie łatwiej jest zobaczyć, czy reguła została faktycznie trafiona podczas testu.

Krok 2: Otwórz Log Viewer

Otwórz Log viewer w prawym górnym rogu konsoli WebAdmin.

Przydatne filtry:

• Moduł: Firewall
• Source IP
• Destination IP
• Destination port
• Rule ID
• Rule name
• Action
• User

Dla ruchu sieciowego dodatkowo sprawdź:

• Web filter
• SSL/TLS inspection
• Application filter
• IPS

Log Viewer aktualizuje się automatycznie. Dla spokojnej analizy można wstrzymać widok na żywo, filtrować, a następnie wznowić.

Krok 3: Odtwórz test

Test powinien być wykonany z zdefiniowanego klienta:

• Otwórz stronę internetową
• Wyślij ping
• Przetestuj port
• Uruchom aplikację
• Zbuduj połączenie VPN
• Pobierz plik

Jeśli to możliwe, zawsze powinien być uruchomiony tylko jeden test na raz. W przeciwnym razie logi i liczniki reguł mogą się mieszać.

Następnie sprawdź:

• Czy licznik reguł rośnie?
• Czy widzisz log w Log Viewer?
• Jaki Rule ID jest wyświetlany?
• Jaki NAT Rule ID jest wyświetlany?
• Czy ruch jest dozwolony czy zablokowany?
• Czy działa funkcja bezpieczeństwa?

Jeśli Log Viewer pozostaje pusty, nie jest to jeszcze dowód przeciwko regule. Najpierw należy sprawdzić logging, filtr czasu, filtr modułu i rzeczywisty przepływ pakietów. Często ruch w ogóle nie dociera do firewalla, reguła nie loguje, wyłączony jest niewłaściwy typ logu albo test używa innego docelowego IP niż oczekiwano.

Krok 4: Użyj Policy tester

Policy tester jest pomocny, gdy chcesz sprawdzić, która reguła zapory, reguła inspekcji SSL/TLS lub polityka sieciowa teoretycznie pasowałaby do ruchu sieciowego.

Ścieżka menu:

Diagnostics > Tools > Policy tester

Typowe dane wejściowe:

• URL
• Użytkownik
• Czas i dzień
• Source IP
• Source zone
• Metoda testu

Jako metodę testu wybierz na przykład Firewall, SSL/TLS, and web, jeśli chcesz sprawdzić kombinację reguły zapory, reguły inspekcji SSL/TLS i polityki sieciowej.

Policy tester pokazuje nie tylko Accepted lub Blocked, ale także dopasowaną regułę zapory, rozpoznaną Destination, Source zone i w zależności od metody testu dodatkowe informacje o sieci lub SSL/TLS. Dzięki temu szybko widać, czy ruch zasadniczo trafia do oczekiwanej reguły.

Ważne:

⚠️ Policy tester nie zastępuje prawdziwego testu przepływu pakietów. Wyniki testu polityki nie odzwierciedlają wiarygodnie tras SD-WAN. Rzeczywiste zachowanie może się różnić, jeśli zaangażowane są SD-WAN, routing lub bramy.

SFOS 22: Policy tester może pokazywać błędne wyniki

W przypadku SFOS 22.0 GA i SFOS 22.0 MR1 wyniki testu polityki należy oceniać szczególnie ostrożnie. Policy Test i Policy Route Test mogą w niektórych przypadkach pokazywać ruch jako zablokowany lub przypisywać go do błędnej reguły, mimo że rzeczywisty ruch przechodzi poprawnie przez zaporę.

Dla administratorów ważna jest konsekwencja: jeśli Policy tester pokazuje nieoczekiwany wynik, ale Log Viewer, licznik reguł i Packet Capture potwierdzają rzeczywisty przepływ pakietów, nie należy od razu przebudowywać reguł zapory lub NAT. Najpierw należy sprawdzić, czy dotyczy to tylko wyświetlania diagnostycznego.

Praktyczny przebieg przy sprzecznych wynikach:

1. Dokładnie udokumentuj test z Source IP, Destination, Service i użytkownikiem.
2. Filtruj Log Viewer według Source IP, Destination IP i Service.
3. Sprawdź Rule ID i NAT Rule ID z rzeczywistego wpisu logu.
4. Uruchom Packet Capture z wąskim filtrem.
5. Porównaj ruch przychodzący, przekazywany i powrotny.
6. Traktuj wynik Policy tester jako wskazówkę, a nie jako jedyny dowód.
7. Sprawdź wersję oprogramowania i znane problemy Sophos, zanim zmienisz reguły produkcyjne.

Ta ostrożność jest szczególnie ważna w oknach konserwacyjnych. Błędny wynik diagnostyczny nie powinien prowadzić do ponownego sortowania działających reguł produkcyjnych albo modyfikowania reguł NAT bez dowodu.

Policy tester jest szczególnie dobry dla:

• Polityki sieciowej
• Kategoryzacji URL
• Kontekstu użytkownika
• Harmonogramu
• Reguły inspekcji SSL/TLS
• Dopasowywania reguł zapory dla ruchu sieciowego

Jest mniej dobry dla:

• rzeczywistych decyzji routingu
• powrotu NAT
• utraty pakietów
• problemów z dostawcą lub przełącznikiem
• aplikacji z wieloma połączeniami i portami

Krok 5: Użyj Packet Capture

Jeśli Log Viewer i Policy tester nie wystarczają, użyj Diagnostics > Packet capture.

Filtr powinien być ustawiony wąsko, na przykład:

• Source IP klienta
• Destination IP serwera
• Destination port
• Protokół

Następnie:

1. Uruchom Packet Capture.
2. Odtwórz test.
3. Zatrzymaj Packet Capture.
4. Porównaj zdarzenia przychodzące i przekazywane.
5. Porównaj Rule ID i NAT ID z Log Viewer.

Interpretacja:

Więcej informacji: Używanie narzędzia Packet Capture w WebAdmin. Jeśli pakiety są odrzucane, dodatkowo pomocne jest Analiza odrzuconych pakietów Sophos Firewall.

Wspólne czytanie Log Viewer i Packet Capture

Log Viewer pokazuje decyzję, Packet Capture pokazuje przepływ pakietów. W praktyce często potrzebne są oba widoki.

• Log Viewer pokazuje oczekiwaną Rule ID, Packet Capture pokazuje Forwarded: test reguły jest z perspektywy firewalla wiarygodny. Drogę powrotną i system docelowy trzeba sprawdzić osobno.
• Log Viewer pokazuje oczekiwaną Rule ID, Packet Capture nie pokazuje odpowiedzi: sprawdzić system docelowy, trasę powrotną, NAT albo zewnętrzny firewall.
• Packet Capture pokazuje Incoming, ale brak pasującego logu: sprawdzić logging, filtr modułu, regułę domyślną, Device Access albo analizę Drop.
• Packet Capture pokazuje Consumed: ruch kończy się na samym firewallu. Sprawdzić Device Access i Local Service ACL.
• Packet Capture pokazuje Violation: porównać Reason, Rule ID, NAT ID i moduł bezpieczeństwa z Log Viewer.

Jeśli oba narzędzia wydają się sprzeczne, najpierw należy zawęzić przypadek testowy. Jeden klient, jeden cel, jeden port i krótki czas testu są lepsze niż szerokie nagranie z dużą ilością ruchu w tle.

Używaj wąskich filtrów Packet Capture

Packet Capture jest pomocny tylko wtedy, gdy filtr jest wystarczająco wąski. Zbyt szerokie nagranie szybko pokazuje zbyt wiele ruchu w tle, zwłaszcza na produkcyjnych zaporach z ruchem sieciowym, DNS, VPN lub serwerowym. Filtr powinien być zatem oparty na zdefiniowanym przypadku testowym.

Praktyczne przykłady BPF:

W przypadku testów DNAT lub VPN należy zwrócić szczególną uwagę na kierunek widzenia. Filtr na wewnętrzny adres IP serwera niekoniecznie pokazuje pierwotny dostęp do publicznego adresu IP. Odwrotnie, filtr na publiczny adres IP nie pokazuje automatycznie, czy ruch po NAT dociera do wewnętrznego serwera. W takich przypadkach często lepsze są dwa krótkie nagrania: najpierw na stronie publicznej, potem na wewnętrznym celu.

Po teście należy natychmiast zatrzymać nagranie. Długie nagrania zwiększają ryzyko nagrania niepotrzebnych danych użytkowych, wewnętrznych nazw hostów lub obcych połączeń.

Kiedy przejść na tcpdump

WebAdmin Packet Capture jest idealny do szybkich testów. Nie wystarcza jednak w każdym przypadku. Na tcpdump należy przejść, gdy spełniony jest jeden z tych punktów:

• Nagranie ma być ocenione jako plik PCAP w Wireshark lub przez wsparcie.
• Test trwa dłużej niż krótki ręczny test reprodukcji.
• Potrzebne są bardzo dokładne filtry BPF, na przykład dla VoIP, VPN, DNS lub wielu hostów.
• Bufor WebAdmin się zapełnia lub pokazuje tylko fragment.
• Istotny ruch musi być obserwowany na określonym interfejsie przez dłuższy czas.

Również w przypadku tcpdump obowiązuje: ustaw wąskie filtry, zanotuj czas testu, trzymaj nagranie krótko i usuń plik po przesłaniu. Praktyczny przewodnik CLI znajduje się w Sophos Firewall tcpdump: Nagrywanie pakietów za pomocą CLI.

Krok 6: Walidacja funkcji bezpieczeństwa

Jeśli właściwa reguła pasuje, ale ruch nie działa, należy sprawdzić aktywowane funkcje pojedynczo.

Dla HTTPS obowiązuje: Reguła zapory z filtrowaniem sieciowym nie wystarcza do sprawdzenia treści HTTPS. Potrzebna jest dodatkowo odpowiednia SSL/TLS inspection rule z odszyfrowaniem i rozprowadzonym certyfikatem CA.

Więcej informacji: Stopniowe wdrażanie inspekcji TLS na Sophos Firewall. W przypadku błędów NAT pasuje Zrozumienie NAT na Sophos Firewall, ponieważ reguła NAT nie pozwala na ruch, a jedynie tłumaczy adresy lub porty.

Krok 7: Sprawdzenie plików logów

Jeśli narzędzia WebAdmin nie wystarczają, należy sprawdzić odpowiednie pliki logów.

Typowe pliki:

Szczegółowy przegląd można znaleźć tutaj: Rozwiązywanie problemów z usługami i logami na Sophos Firewall.

W przypadkach supportowych archiwum logów albo CTR są naprawdę pomocne tylko wtedy, gdy udokumentowano czas testu i oczekiwane identyfikatory. Duży pakiet logów bez Source, Destination, Port, użytkownika, Rule ID i NAT ID często prowadzi tylko do dłuższych pytań zwrotnych.

Przykład: Testowanie reguły sieciowej LAN do WAN

1. Utwórz regułę zapory LAN_to_WAN_Clients.
2. Włącz logowanie.
3. Ustaw usługi na HTTP i HTTPS.
4. Wybierz politykę sieciową.
5. Pozostaw włączoną opcję Block QUIC protocol.
6. Włącz Scan HTTP and decrypted HTTPS.
7. Utwórz regułę inspekcji SSL/TLS dla grupy testowej.
8. Zainstaluj certyfikat CA na kliencie testowym.
9. Zresetuj licznik reguł.
10. Otwórz stronę internetową.
11. Filtruj Log Viewer według Source IP.
12. Uruchom Policy tester dla tego samego URL.
13. W przypadku rozbieżności uruchom Packet Capture.

W ten sposób można zobaczyć, czy reguła pasuje, czy HTTPS jest rzeczywiście odszyfrowany i czy filtr sieciowy, IPS lub kontrola aplikacji działają.

Dokumentowanie wyniku testu

Po teście reguły wynik powinien być krótko udokumentowany. Jest to szczególnie ważne, jeśli z tego wynika przypadek wsparcia, okno konserwacyjne lub późniejsze czyszczenie reguł.

Warto uwzględnić:

• Data i godzina testu
• Source IP, użytkownik, Destination, Service i testowany URL lub aplikacja
• oczekiwany i faktycznie dopasowany Firewall Rule ID
• NAT Rule ID, jeśli NAT jest zaangażowany
• Akcja w Log Viewer
• Zrzut ekranu lub eksport z Packet Capture, jeśli przepływ pakietów był istotny
• zmieniona reguła, polityka sieciowa, reguła inspekcji SSL/TLS lub reguła NAT
• otwarty punkt, jeśli zachowanie nie jest jeszcze w pełni wyjaśnione

W przypadku zmian produkcyjnych warto dodatkowo zanotować, czy reguła jest przeznaczona tylko na pilotaż, na stałe czy jako tymczasowe obejście. Tymczasowe reguły testowe powinny mieć datę wygaśnięcia lub wyraźnego właściciela, aby nie pozostały jako przestarzałe w zestawie reguł.

Jeśli z testu reguły powstaje przypadek supportowy, należy dodatkowo udokumentować archiwum logów, Packet Capture albo PCAP z tcpdump, dotknięty przedział czasu i już wykluczone przyczyny. Do tego pasuje Zabezpieczanie logów Sophos Firewall do wsparcia i analizy.

FAQ