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 WWW, inspekcji TLS, NAT, IPS lub dopasowywania użytkowników reguła może wyglądać poprawnie, 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 WWW, 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 albo przechwycenie ma zostać przeanalizowane przez pomoc techniczną Sophos, należy użyć 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 ruch w obu kierunkach przebiega 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:

• Reguła w ogóle nie pasuje lub wygrywa inna reguła: Reguła Sophos Firewall nie działa: sprawdź przyczyny.
• Zaangażowane są DNAT, SNAT, MASQ lub kolejność NAT: Zrozumienie NAT na Sophos Firewall.
• Serwer wewnętrzny jest publikowany z Internetu: Publikowanie serwera za pomocą DNAT.
• Packet Capture pokazuje odrzuty, Violation lub nieoczekiwane powody odrzutu: Analiza odrzuconych pakietów Sophos Firewall.
• SSL VPN jest połączony, ale wewnętrzne cele nie działają: Konfiguracja zdalnego dostępu SSL VPN na Sophos Firewall.
• Problemy z Site-to-Site-IPsec lub Remote-Access-IPsec: Rozwiązywanie problemów z IPsec VPN na Sophos Firewall.
• Narzędzia WebAdmin nie wystarczają i potrzebne są lokalne logi: Rozwiązywanie problemów z usługami i logami na Sophos Firewall.
• Zgłoszenie do pomocy technicznej wymaga archiwum logów, danych IPsec lub plików PCAP: Zabezpieczanie logów Sophos Firewall do wsparcia i analizy.

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

• Log viewer: pokazuje Rule ID, NAT ID, Action, użytkownika i decyzje funkcji bezpieczeństwa. Nie dowodzi obecności pakietów, które w ogóle nie docierają do zapory.
• Policy tester: pokazuje oczekiwaną politykę zapory, WWW i SSL/TLS dla zdefiniowanych danych wejściowych. Nie dowodzi rzeczywistej ścieżki powrotnej, zachowania SD-WAN, utraty pakietów ani problemu po stronie dostawcy.
• Packet capture: pokazuje, czy pakiety docierają, są przekazywane i czy odpowiedzi wracają. Nie wyjaśnia automatycznie intencji stojącej za regułą lub polityką WWW.
• tcpdump: służy do dłuższych przechwyceń, bardzo dokładnych filtrów BPF, plików PCAP i analizy w Wireshark. Rule ID, NAT ID ani decyzje polityki WWW nie są z nim widoczne bezpośrednio w WebAdmin.
• Central Reporting lub Syslog: pomaga w analizie historii, raportach, korelacji SIEM i późniejszej ocenie. Nie pokazuje wiarygodnie przepływu pakietów na żywo ani lokalnych szczegółów usług; do tego zwykle szybsze są narzędzia lokalne.

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. W System services > Log settings sprawdź, czy odpowiedni typ logu jest aktywny dla Local reporting, Central reporting lub Syslog.
4. Sprawdź pozycję reguły i licznik użycia.
5. Dokładnie raz odtwórz test.
6. Filtruj Log Viewer według Source IP, Destination IP i Service.
7. Zanotuj Rule ID i NAT ID z rzeczywistego wpisu logu.
8. Użyj Policy tester tylko do logiki polityki.
9. Uruchom Packet Capture, jeśli Log Viewer i Policy tester nie pasują do siebie.
10. 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:

• Source IP: 172.16.10.25
• Użytkownik: user@domain.local
• Source zone: LAN
• Destination: https://www.example.com
• Service: HTTPS
• Oczekiwana reguła: LAN_to_WAN_Clients
• Oczekiwana akcja: dozwolona, zablokowana, odszyfrowana, nieodszyfrowana

Następnie w testowanej regule zapory włącz Log firewall traffic. Bez logowania Log Viewer jest pomocny tylko w ograniczonym stopniu.

Logowanie ma tutaj dwa poziomy. Po pierwsze, sama dotknięta reguła musi logować, na przykład przez Log firewall traffic. Po drugie, odpowiednie typy logów w System services > Log settings muszą być aktywne dla wybranego celu: Local reporting dla Log Viewer, Central reporting dla Sophos Central oraz skonfigurowane cele Syslog dla zewnętrznych serwerów logów. Jeśli opcja w regule jest włączona, ale odpowiedni typ logu nie jest zapisywany lokalnie ani zewnętrznie, analiza błędów szybko staje się sprzeczna.

Do krótkich testów na żywo wystarcza Log Viewer. Jeśli test ma być później odtwarzalny, należy wcześniej sprawdzić, czy Central Reporting lub Syslog również otrzymuje odpowiedni typ logu. W przeciwnym razie dowód po rotacji logów lub restarcie może już nie być dostępny.

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ę
• Nawiąż 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 WWW teoretycznie pasowałaby do ruchu WWW.

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

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

Błąd w SFOS 22.0 GA poprawiony w MR1

Znany problem NC-177587 dotyczył SFOS 22.0 GA Build 411 i został rozwiązany w SFOS 22.0 MR1 Build 490. W wersji GA Policy Test i Policy Route Test mogły błędnie pokazywać ruch jako zablokowany lub przypisywać go do niewłaściwej reguły, mimo że ruch produkcyjny był przetwarzany prawidłowo.

Niezależnie od tego poprawionego błędu nadal trzeba porównywać rzeczywiste logi i pakiety, ponieważ Policy tester nie odzwierciedla pełnego przepływu pakietów.

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ę SFOS 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 WWW
• Kategoryzacji URL
• Kontekstu użytkownika
• Harmonogramu
• Reguły inspekcji SSL/TLS
• Dopasowywania reguł zapory dla ruchu WWW

Jest mniej dobry dla:

• rzeczywistych decyzji routingu
• powrotu NAT
• reguł z adresami MAC w Source networks and devices
• 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.

Packet Capture nie pokazuje tylko pojedynczych pakietów na interfejsie. W wyniku WebAdmin, zależnie od pakietu, mogą być też widoczne szczegóły przetwarzania, na przykład Firewall Rule ID, NAT ID, użytkownik, kontekst filtra Web lub Application oraz informacja, czy pakiet został przekazany, skonsumowany, wygenerowany czy odrzucony. Właśnie dlatego Packet Capture jest tak mocny, gdy reguła rzekomo nie działa: lepiej łączy przepływ pakietów i widok policy niż proste narzędzie ping lub test portu.

Interpretacja:

• Żaden pakiet nie dociera: sprawdź klienta, VLAN, przełącznik, bramę, dostawcę lub grupę 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ą zaporę.
• Pakiet ma status Violation: sprawdź politykę, IPS, Web filter lub Application Control.
• NAT ID jest nieoczekiwany: sprawdź kolejność NAT i ogólne reguły NAT.

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 przechwycenie szybko pokazuje zbyt wiele ruchu w tle, zwłaszcza na produkcyjnych zaporach z ruchem WWW, DNS, VPN lub serwerowym. Filtr powinien być zatem oparty na zdefiniowanym przypadku testowym.

Praktyczne przykłady BPF:

• Pojedynczy klient do jednego celu: host 172.16.10.25 and host 203.0.113.10, gdy znane są Source i Destination.
• Klient do celu HTTPS: host 172.16.10.25 and port 443, gdy cel może się zmieniać przez DNS lub CDN.
• Tylko ruch wychodzący klienta: src host 172.16.10.25, gdy najpierw sprawdza się, czy klient w ogóle wysyła.
• Tylko ruch odpowiedzi do klienta: dst host 172.16.10.25, gdy brakuje trasy powrotnej lub pakietów odpowiedzi.
• Test DNS: host 172.16.10.25 and port 53, gdy rozdziela się rozwiązywanie nazw i test reguły.
• Test ICMP: icmp and host 172.16.10.25, gdy ping służy jako prosty test dostępności.

W przypadku testów DNAT lub VPN należy zwrócić szczególną uwagę na perspektywę przechwytywania. 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 przechwycenia: najpierw po stronie publicznego adresu, potem na wewnętrznym celu.

Po teście należy natychmiast zatrzymać przechwytywanie. Długie przechwycenia zwiększają ryzyko zarejestrowania niepotrzebnych danych użytkowych, wewnętrznych nazw hostów lub niezwiązanych 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.

• Polityka WWW: sprawdź kategorię, użytkownika, harmonogram i kolejność polityk.
• Scan HTTP and decrypted HTTPS: HTTPS jest skanowane tylko wtedy, gdy zostało już odszyfrowane.
• Inspekcja SSL/TLS: sprawdź odpowiednią regułę, profil odszyfrowania i certyfikat CA na klientach.
• IPS: sprawdź sygnaturę, politykę i możliwy fałszywy alarm.
• Application Control: sprawdź rozpoznaną aplikację, kategorię i wykrywanie aplikacji w chmurze.
• Security Heartbeat: sprawdź, czy endpoint wysyła Heartbeat oraz czy status jest zielony, żółty lub czerwony.
• Traffic Shaping: sprawdź, czy polityka jest aktywna i pasuje do właściwej aplikacji lub reguły.
• NAT: sprawdź właściwą regułę SNAT, DNAT lub PAT oraz kolejność reguł.

Dla HTTPS obowiązuje: reguła zapory z filtrowaniem WWW 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:

• Reguła zapory: firewall_rule.log
• NAT: nat_rule.log
• Połączenia zapory: fwlog.log
• IPS i DPI: ips.log
• Web Proxy: awarrenhttp.log
• IPsec: strongswan.log, charon.log
• SSL VPN: sslvpn.log
• DNS: dnsd.log, dnsgrabber.log
• DHCP: dhcpd.log

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

W zgłoszeniach do pomocy technicznej 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 dodatkowych pytań.

Przykład: Testowanie reguły WWW z 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ę WWW.
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
• aktywne cele logowania, na przykład Log Viewer, Sophos Central lub Syslog
• 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 WWW, 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 zgłoszenie do pomocy technicznej, należy dodatkowo udokumentować archiwum logów, Packet Capture albo PCAP z tcpdump, okres, którego dotyczy problem, oraz już wykluczone przyczyny. Do tego pasuje Zabezpieczanie logów Sophos Firewall do wsparcia i analizy.

FAQ