Zrozum i bezpiecznie skonfiguruj reguły Sophos Firewall

Reguła Sophos Firewall określa, jaki ruch między strefami, sieciami, użytkownikami i usługami jest dozwolony lub blokowany. Kluczowe znaczenie ma nie włączenie jak największej liczby opcji, lecz właściwe kryteria dopasowania, prawidłowa kolejność, odpowiednie funkcje ochronne i powtarzalny test.

Ścieżka menu:

Rules and policies > Firewall rules > Add firewall rule > New firewall rule

W tym artykule omówiono formularz reguły od góry do dołu, używając w całym tekście przykładu LAN_to_WAN_Clients. Tematy specjalistyczne, takie jak NAT, TLS Inspection czy IPS, wyjaśniono w zakresie niezbędnym dla reguły zapory; szczegółowe instrukcje są podlinkowane bezpośrednio w odpowiednich miejscach.

Planowanie przed utworzeniem reguły

Prawidłowe określenie zakresu

Zwykłe reguły zapory kontrolują ruch przekazywany przez firewall. Pozostałe zadania konfiguruje się w innych miejscach:

• Lokalne usługi firewalla: WebAdmin, User Portal, VPN Portal, SSH, DNS i SNMP kontroluje się przez Administration > Device access, Local Service ACL oraz konfigurację danej usługi. Służy do tego Device Access i Local Service ACL.
• Ruch generowany przez system: Połączenia inicjowane przez sam firewall nie wymagają zwykłej reguły zapory. Decydujące są konfiguracja usługi, routing, WAN Link Manager i w razie potrzeby SD-WAN dla System Traffic.
• Translacja adresów i portów: NAT wykonuje translację ruchu, ale sam go nie dopuszcza. Reguła zapory i reguła NAT muszą być ze sobą zgodne.
• Routing i droga powrotna: Pasująca reguła zapory nie dowodzi jeszcze, że routing, SD-WAN, VPN lub droga powrotna są prawidłowe.
• Logika WWW: Kategorie internetowe, grupy URL i działania znajdują się w Web Policy. Reguła zapory przypisuje tę policy.
• Deszyfrowanie HTTPS: SSL/TLS inspection rule odszyfrowuje ruch. Opcja Scan HTTP and decrypted HTTPS skanuje tylko już odszyfrowany ruch HTTPS.
• Tożsamość użytkownika: AD SSO, STAS, Captive Portal, Entra ID SSO lub RADIUS muszą najpierw niezawodnie przypisać użytkownika do ruchu. Urządzenia bez logowania można przy stałym, jednoznacznym adresie IP skonfigurować jako Clientless Users; takie przypisanie nie jest uwierzytelnianiem.

Dostęp administracyjny przez firewall do serwerów, przełączników lub hypervisorów należy umieścić w zwykłych regułach zapory. Dostęp do samego firewalla należy natomiast do Device Access.

Kolejność, IPv4 i IPv6

Sophos Firewall sprawdza reguły od góry do dołu. Gdy wszystkie kryteria dopasowania danej reguły są spełnione, kolejne reguły nie są już oceniane. Dlatego ogólna reguła LAN_to_WAN_Any umieszczona nad LAN_to_WAN_Restricted sprawia, że reguła szczegółowa nie działa.

Reguła może dopasowywać ruch między innymi według Source zone, Source network, harmonogramu, Destination zone, Destination network, Service, użytkownika i Exclusions. Wszystkie skonfigurowane kryteria muszą odpowiadać danemu połączeniu.

Automatycznie tworzone reguły MTA, IPsec lub Hotspot mogą pojawić się na początku listy. Dlatego po użyciu kreatora, migracji lub zmianach VPN należy ponownie sprawdzić kolejność. W przypadku hotspotu Sophos Firewall kontrola ta jest wyraźną częścią procesu konfiguracji. Jeśli SFOS nie znajdzie pasującej reguły, na końcu obowiązuje niejawna reguła Drop-all z Firewall Rule ID #0. Nie pokazuje ona Usage Count; odrzucony ruch jest rejestrowany jako zdarzenie.

Reguły IPv4 i IPv6 są zarządzane oddzielnie. Działająca reguła IPv4 nie chroni automatycznie tej samej usługi przez IPv6. W środowiskach dual-stack oba zestawy reguł trzeba świadomie zaplanować i przetestować.

Wyraźne rozdzielenie podstaw reguł

Przed utworzeniem reguły należy określić Source, Destination, Services, Owner i przypadek testowy. Różnych zagrożeń nie należy łączyć w jedną zbiorczą regułę:

• Internet dla klientów: Sieci klienckie do strefy WAN z odpowiednimi Web Policy, Application Control, IPS i logowaniem.
• Internet dla serwerów: Tylko wymagane cele aktualizacji, backupu lub chmury; zwykle bez kontekstu użytkownika.
• Sieć Wi-Fi dla gości: Strefa Guest do internetu, bez celów wewnętrznych i w razie potrzeby z limitem przepustowości.
• Management: Zdefiniowane sieci administracyjne do serwerów i infrastruktury, oddzielone od zwykłego ruchu klienckiego.
• Remote Access VPN: Strefa VPN do rzeczywiście wymaganych celów wewnętrznych i Services.
• Site-to-Site: Sieci lokalne i zdalne z odpowiednim routingiem, NAT i drogą powrotną.
• Opublikowane systemy: WAN do DMZ lub strefy serwerowej z ograniczonym Source, DNAT lub WAF, IPS, logowaniem i aktualnymi poprawkami.
• Dostęp tymczasowy: Osobna reguła z ticketem, Owner, datą wygaśnięcia i zaplanowanym usunięciem.

W planowaniu struktury sieci pomaga artykuł Konfiguracja stref i interfejsów Sophos Firewall.

⚠️ Any może pomóc w krótkim teście, ale rzadko jest dobrą konfiguracją docelową. Następnie należy ograniczyć regułę do rzeczywiście potrzebnych źródeł, celów i Services albo ją usunąć.

Praktyczny przykład LAN_to_WAN_Clients

W tym przykładzie klienci ze zdefiniowanej sieci LAN mogą łączyć się z internetem. Serwery, goście, VoIP i management otrzymują osobne reguły.

• Rule name: LAN_to_WAN_Clients
• Description: Dostęp do internetu dla sieci klienckiej. Webfilter, App Control i IPS aktywne. Owner IT, przegląd 2026-12-01.
• Rule position: Bottom, a następnie umieszczenie poniżej szczegółowych reguł blokujących i wyjątków
• Rule group: Internet Access
• Action: Accept
• Log firewall traffic: włączone
• Source zones: LAN
• Source networks and devices: net_LAN_Clients
• During scheduled time: All the time
• Destination zones: WAN
• Destination networks: Any
• Services: HTTP, HTTPS oraz tylko te podstawowe usługi, które rzeczywiście są używane bezpośrednio zewnętrznie
• Web policy: Default Workplace Policy
• Block QUIC protocol: włączone
• IPS: odpowiednia policy kliencka
• App control: odpowiednia Application Policy dla klientów
• Shape traffic: tylko w przypadku konkretnego celu dotyczącego przepustowości
• DSCP marking: tylko wtedy, gdy urządzenia downstream przetwarzają oznaczenie

DNS i NTP powinny znaleźć się w tej regule LAN-to-WAN tylko wtedy, gdy klienci bezpośrednio korzystają z zewnętrznych resolverów lub serwerów czasu. Jeżeli używają firewalla jako usługi DNS lub czasu, jest to ruch lokalny.

Test odbiorczy wymaga zdefiniowanego klienta, konkretnego celu, oczekiwanego Firewall Rule ID, oczekiwanego NAT Rule ID oraz kontroli w Log Viewer. Dzięki temu sprawdza się nie tylko działanie aplikacji, ale również to, czy ruch jest przetwarzany przez właściwe reguły.

Konfiguracja reguły zapory

Sekcja nagłówkowa

Rule status, Rule name i Description

Rule status jest domyślnie aktywny dla nowej reguły. Przygotowane reguły mogą pozostać wyłączone do okna serwisowego. Trwale wyłączone reguły testowe lub migracyjne należy regularnie sprawdzać.

Nazwa powinna wskazywać Source, Destination i przeznaczenie, na przykład:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Pole Description dokumentuje cel, Owner, ticket, ograniczenia i ewentualnie datę wygaśnięcia. Nazwy Rule1, Allow lub Internet są mało pomocne w późniejszej eksploatacji. Osobny proces opisano w artykule Sensowne dokumentowanie reguł Sophos Firewall.

Rule position i Rule group

Podczas tworzenia reguły pole Rule position w SFOS 22 oferuje opcje Top lub Bottom. Po zapisaniu regułę można przesunąć w tabeli albo ustawić precyzyjnie za pomocą Move To. Opcję Top należy wybierać tylko wtedy, gdy określona reguła ma świadomie obowiązywać przed istniejącymi regułami.

Rule group poprawia przejrzystość, ale nie zmienia logiki dopasowania. Wartość domyślna to None. Przy ustawieniu Automatic SFOS przypisuje regułę do istniejącej grupy na podstawie pierwszego pasującego typu reguły oraz stref Source/Destination. Firewall nadal ocenia poszczególne reguły od góry do dołu.

Action i logowanie

Pole Action określa sposób obsługi pasującego ruchu:

• Accept: zezwala na połączenie.
• Drop: zwykle odrzuca je bez odpowiedzi. Jeśli włączono Use web authentication for unknown users, SFOS może zamiast tego wyświetlić stronę blokady dla ruchu WWW.
• Reject: odrzuca połączenie i wysyła reset dla TCP albo odpowiednią odpowiedź ICMP dla UDP i ICMP.
• Protect with web server protection: tworzy regułę WAF. Opcja jest dostępna tylko dla IPv4 i wymaga Webserver Protection. Jej konfigurację opisano w artykule Sophos Firewall WAF.

Drop nadaje się do cichego odrzucania ruchu; Reject zapewnia szybciej rozpoznawalną informację zwrotną podczas testów wewnętrznych lub troubleshootingu.

Ważne reguły powinny mieć włączone Log firewall traffic. Ponadto pod System services > Log settings muszą być aktywne odpowiednie cele lokalne, Sophos Central lub Syslog. Bez zdarzenia Destroy sesja może pozostać bez końcowego logu sesji, na przykład po nagłej awarii łącza.

Do dłuższego przechowywania danych nadaje się Central Firewall Reporting lub serwer Syslog/SIEM. Logowanie służy nie tylko do troubleshootingu, ale także do przeglądu: które źródła trafiają w regułę, jakie cele są używane i czy dostęp nadal jest uzasadniony?

To samo pole wyboru jest źródłem danych dla NetFlow v5 w Sophos Firewall: bez Log firewall traffic NetFlow nie eksportuje połączeń tej reguły.

Source, Destination i Services

W sekcji Source określa się pochodzenie ruchu:

• Source zones: na przykład LAN, VPN, DMZ, Guest lub WAN.
• Source networks and devices: pojedyncze hosty, sieci, zakresy IP, grupy, FQDN Hosts lub obiekty krajów.
• During scheduled time: All the time, godziny pracy lub okno serwisowe.

Sama strefa jest zwykle zbyt szeroka. Dlatego w przykładzie klienckim LAN łączy się z net_LAN_Clients. W przypadku reguł czasowych czas firewalla, strefa czasowa i Schedule muszą być ze sobą zgodne.

Artykuł Konfiguracja harmonogramów reguł i zasad na Sophos Firewall pokazuje, jak tworzyć i przypisywać cykliczne oraz jednorazowe przedziały, a następnie testować ich granice przełączenia.

W sekcji Destination and services znajdują się:

• Destination zones: na przykład WAN, DMZ, LAN lub VPN.
• Destination networks: Any, host, sieć, grupa, obiekt kraju lub FQDN Host.
• Services: definicje protokołów i portów, takie jak HTTP, HTTPS, DNS, NTP lub własny Service.

Artykuł Prawidłowe używanie hostów i usług Sophos Firewall wyjaśnia, jak tworzyć IP hosts, sieci, zakresy, listy, Services i grupy oraz sprawdzać je przed zmianami.

Any może być uzasadnione w ogólnej regule dostępu klientów do internetu. Reguły serwerowe, administracyjne i VPN powinny używać znacznie bardziej ograniczonych celów oraz Services. W przypadku dynamicznych celów chmurowych mogą pomóc FQDN Hosts i Wildcard FQDNs.

Użytkownicy, Exclusions i Linked NAT

Match known users

Opcja Match known users dodaje użytkowników lub grupy jako kryteria dopasowania. W zależności od konfiguracji pojawiają się następnie kolejne pola:

• Use web authentication for unknown users: przekierowuje nieznanych użytkowników WWW do AD SSO lub Captive Portal. Uwierzytelnianie i dostęp z danej strefy muszą być wcześniej skonfigurowane. Artykuł Konfiguracja i testowanie Captive Portal w Sophos Firewall pokazuje, jak współdziałają uwierzytelnianie, Device Access, wymagany DNS i reguła użytkownika.
• Users or groups: ogranicza regułę do wybranych tożsamości.
• Exclude this user activity from data accounting: wyłącza ruch tych użytkowników z indywidualnego rozliczania transferu danych.

Reguła użytkownika działa tylko przy niezawodnym przypisaniu użytkownika. Szeroka reguła fallback poniżej nie może zezwalać na ten sam ruch bez kontekstu użytkownika. Podczas testu odbiorczego użytkownik, grupa i Rule ID w Log Viewer muszą być zgodne.

Add exclusion

Opcja Add exclusion wyłącza ruch z tej reguły. SFOS pomija regułę tylko wtedy, gdy wszystkie skonfigurowane kryteria Exclusion są spełnione jednocześnie, a następnie sprawdza kolejną regułę.

Dostępne kryteria to Source zones, Source networks and devices, Destination zones, Destination networks i Services.

Przydatnym wyjątkiem może być serwer aktualizacji, który zostaje wyłączony z ogólnej reguły klienckiej i otrzymuje powyżej własną regułę z innymi funkcjami ochronnymi. Jeśli Exclusions stają się liczne lub trudne do zrozumienia, zwykle lepsza jest osobna, szczegółowa reguła.

Create linked NAT rule

Linked NAT Rule to reguła Source NAT, która obowiązuje wyłącznie dla ruchu powiązanej reguły zapory. W regule NAT można określić przede wszystkim tłumaczony Source oraz właściwą dla interfejsu Source Translation.

Konfiguracja fabryczna zawiera zazwyczaj Default SNAT rule z MASQ. Przed dodaniem kolejnej Linked NAT Rule należy sprawdzić, czy ta reguła już prawidłowo obsługuje ruch. Jeżeli pasuje wyżej umieszczona niezależna reguła NAT, ma ona pierwszeństwo przed Linked NAT Rule.

W przypadku DNAT SFOS najpierw określa przetłumaczony cel, a następnie używa jego strefy do dopasowania reguły zapory. Dlatego przekierowanie portu do serwera w DMZ wymaga zwykle w regule zapory ustawienia Destination zone DMZ, mimo że klient korzysta z publicznego adresu WAN.

W przypadku nieoczekiwanego NAT Rule ID należy również sprawdzić kolejność pod Rules and policies > NAT rules. Po zmianach NAT trzeba utworzyć nowe połączenie, ponieważ istniejące sesje nie są ponownie oceniane. NAT sam w sobie nie zezwala na ruch: reguła zapory decyduje o Allow lub Drop, a NAT tłumaczy adresy lub porty. Szczegóły opisano w artykule Zrozumienie NAT w Sophos Firewall.

Wybór funkcji ochronnych

Nie każda opcja jest dostępna z Base License. Przed wdrożeniem należy sprawdzić pod Administration > Licensing:

• Zwykłe reguły zapory: Base License
• IPS i Security Heartbeat: Network Protection
• Web Security, Application Control i ochrona przed malware internetowym: Web Protection
• Sandboxing i analiza plików: Zero-Day Protection
• Ochrona poczty: Email Protection
• WAF: Webserver Protection
• NDR Active threat intelligence: Xstream Protection Bundle

Standard Protection i Xstream Protection zawierają Web Protection. Pakiet Avanet Epic Protection również zawiera Web Protection. Pełne porównanie znajduje się w artykule Porównanie pakietów licencyjnych Sophos Firewall.

Web Filtering

Pole Web policy przypisuje Web Policy z kategoriami, grupami URL, użytkownikami i działaniami. Bez Web Policy to pole nie zapewnia kontroli dostępu do internetu według kategorii. Samą policy tworzy się i testuje pod Web Protection.

Opcja Apply web category-based traffic shaping korzysta z ustawień przepustowości w kategoriach internetowych. Ma sens tylko wtedy, gdy rzeczywiście skonfigurowano tam limity lub gwarancje.

Opcja Block QUIC protocol blokuje dla tej reguły wychodzący UDP na portach 80 i 443. QUIC nie można skanować tak jak zwykłego ruchu HTTP/HTTPS i omija Web Filtering. SFOS domyślnie włącza tę opcję po wybraniu Web Policy lub skanowania malware. Szczegóły opisano w artykule Blokowanie QUIC i HTTP/3.

Opcja Scan HTTP and decrypted HTTPS sprawdza HTTP i już odszyfrowany HTTPS pod kątem malware. Nie włącza ona deszyfrowania. W tym celu pod Rules and policies > SSL/TLS inspection rules potrzebna jest odpowiednia SSL/TLS inspection rule.

Opcja Use Zero-day protection po skanowaniu malware przesyła podejrzane pliki do dodatkowej analizy. Funkcja wymaga Zero-Day Protection i w zależności od typu pliku oraz policy może powodować opóźnienie.

Opcja Scan FTP for malware jest potrzebna tylko wtedy, gdy reguła zezwala na FTP. W systemach legacy skanowanie należy przetestować osobno.

Opcja Use web proxy instead of DPI engine ogranicza filtrowanie proxy do standardowych portów 80 i 443. Web Proxy jest wymagany między innymi dla SafeSearch, YouTube Restrictions, Google Workspace Domain Restrictions, Pharming Protection, Web Cache lub Parent Proxy. W trybie DPI reguły SSL/TLS inspection rules obowiązują dla HTTP i TLS na wszystkich portach.

Konfiguracja upstream proxy na Sophos Firewall opisuje dodatkowy łańcuch reguł i NAT dla parent proxy. Proxy w WAN wymaga innej ścieżki niż proxy w LAN lub DMZ.

Jawnie skonfigurowany klient Direct Web Proxy używa natomiast listenera również bez tej opcji. Artykuł Konfiguracja Direct Web Proxy z plikiem PAC opisuje pełną konfigurację portu, Device Access, pliku PAC, reguły i testów.

Opcja Decrypt HTTPS during web proxy filtering należy do trybu Web Proxy. W trybie DPI Decryption kontrolują SSL/TLS inspection rules. Web Exceptions mogą pomijać Decryption, Malware Scan, Zero-Day Protection i Policy Checks, dlatego należy je ściśle ograniczać i regularnie sprawdzać.

Synchronized Security Heartbeat

Reguły Heartbeat wymagają:

• firewalla zarejestrowanego na tym samym koncie Sophos Central i z włączonym Security Heartbeat;
• zarządzanego Sophos Endpoint z licencją próbną lub pełną;
• Network Protection na firewallu.

Aby wykrywać brak heartbeatów, należy wybrać odpowiednie strefy pod System > Sophos Central > Optional configurations > Missing heartbeat zones.

Pola Minimum source HB permitted i Minimum destination HB permitted określają minimalny wymagany stan zabezpieczeń. Destination Heartbeat nadaje się wyłącznie do celów wewnętrznych, a nie do strefy WAN.

Opcje Block clients with no heartbeat i Block request to destination with no heartbeat obsługują urządzenia bez heartbeat. Urządzenie, które nigdy nie wysłało heartbeat, pozostaje domyślnie dozwolone i zostanie zablokowane dopiero po włączeniu obu opcji. Trzeba to świadomie przetestować na urządzeniach bez Sophos Endpoint.

Web Exception pomijający Policy checks może zezwalać na żądania internetowe mimo ustawienia Block clients with no heartbeat. Praktyczną procedurę weryfikacji opisano w artykule Analiza ostrzeżeń o braku Security Heartbeat.

Application Control, IPS i Traffic Shaping

Opcja Identify and control applications (App control) przypisuje Application Filter Policy. Application Control wymaga Web Protection. W przypadku opartych na URL Micro Apps w szyfrowanym ruchu, takich jak wysyłanie i pobieranie plików w Dropbox lub Gmail, wymagana jest odpowiednia deszyfrująca SSL/TLS inspection rule. Filtry, logi i False Positives opisano w artykule Konfiguracja Application Control.

Opcja Apply application-based traffic shaping policy korzysta z policy przepustowości przypisanej do aplikacji lub kategorii pod Applications > Traffic shaping default. Application Objects są natomiast przeznaczone dla tras SD-WAN. Rules Policy wybrana przez Shape traffic kształtuje cały ruch reguły zapory. Sophos nie dokumentuje jednoznacznie priorytetu przy jednoczesnym użyciu Application Policy i Rules Policy; dla powtarzalnego projektu należy używać tylko jednego wariantu w danym przypadku i przetestować niezbędne połączenie na używanym buildzie SFOS.

Opcja Detect and prevent exploits (IPS) przypisuje IPS Policy. IPS wymaga Network Protection lub ważnej licencji próbnej i musi być globalnie włączony pod Intrusion prevention > IPS policies. Ruch kliencki, serwerowy, webserwerowy i VoIP wymaga różnych, przetestowanych policies. Bezpieczne wdrożenie opisano w artykule Konfiguracja i testowanie IPS.

Opcja Shape traffic przypisuje Traffic Shaping Policy do całej reguły, na przykład dla VoIP, spotkań, backupów lub gości. Gwarancje i limity muszą odpowiadać dostępnej przepustowości WAN. Więcej informacji: Konfiguracja Application Traffic Shaping.

DSCP marking oznacza pakiety dla kolejnych przełączników, routerów lub urządzeń WAN. Samo oznaczenie nie nadaje priorytetu; wszystkie zaangażowane urządzenia muszą spójnie obsługiwać wybrane wartości DSCP.

NDR Active threat intelligence

Opcja Scan with NDR Active threat intelligence sprawdza ruch za pomocą wyselekcjonowanych sygnatur NDR. Działanie jest stałe i ustawione na Log threats: funkcja wykrywa i rejestruje zdarzenia, ale nie blokuje ruchu.

Wymagania:

• Xstream Protection Bundle;
• globalne włączenie NDR Active threat intelligence;
• włączone logowanie IPS;
• zaznaczenie opcji w każdej odpowiedniej regule zapory.

Obsługiwane są urządzenia XGS oraz wdrożenia wirtualne, programowe i popularne wdrożenia chmurowe, ale nie modele XGS 87, 87w, 88 i 88w. XDR lub MDR oraz przesyłanie danych do Sophos Central są opcjonalne dla dalszej analizy w Central.

Scan email content

W sekcji Scan email content można wybrać IMAP, IMAPS, POP3, POP3S, SMTP i SMTPS. Ochrona wymaga Email Protection. Jeśli standardowych portów nie ma pod Services, można je dodać przez Add ports.

Ruch pocztowy nie powinien być ukryty w ogólnej regule dostępu klientów do internetu. Osobna reguła pocztowa wyraźnie określa Source, Destination, protokoły, logowanie i funkcje ochronne.

Testowanie i utrzymanie reguły

Test odbiorczy po zapisaniu

Po zapisaniu reguła jest gotowa dopiero wtedy, gdy zdefiniowany przypadek testowy daje oczekiwane wyniki:

W każdym teście należy wprowadzać tylko jedną zmianę, aby zachować związek między przyczyną a skutkiem.

1. Sprawdzić pozycję reguły i Rule group.
2. Sprawdzić Log firewall traffic oraz cele pod System services > Log settings.
3. Utworzyć dokładnie jedno połączenie testowe ze zdefiniowanego klienta do określonego celu i Service.
4. Sprawdzić Firewall Rule ID, Rule name, użytkownika i Action w Log Viewer.
5. Sprawdzić NAT Rule ID i przetłumaczone adresy.
6. Osobno zweryfikować DNS i routing.
7. Sprawdzić Web Policy, Application Control, IPS i TLS Inspection na podstawie oczekiwanej Action.
8. Zwrócić uwagę na nieoczekiwane Drops, błędy SSL/TLS lub problemy z wydajnością.
9. Usunąć regułę testową albo ograniczyć ją do obiektów produkcyjnych.

Dla Policy Test, Log Viewer i Packet Capture dostępna jest osobna procedura Testowanie reguły Sophos Firewall.

Nowa reguła, istniejąca reguła lub wyłączenie

Istniejącą regułę można rozszerzyć, jeśli Source, Destination, cel, Owner i wymagany poziom ochrony pozostają takie same. Osobna reguła jest lepsza, gdy różnią się logowanie, data wygaśnięcia, Security Features, osoby odpowiedzialne lub cykl przeglądu.

Tymczasowy dostęp dla wsparcia, serwery, goście, VoIP, IoT i management nie powinny znikać w ogólnej regule klienckiej. W przypadku niejasnych starych reguł kontrolowane wyłączenie jest zazwyczaj bezpieczniejsze niż natychmiastowe usunięcie:

1. Wyjaśnić cel, Owner i zależności.
2. Określić logowanie i okno testowe.
3. Poinformować zespoły, których dotyczy zmiana.
4. Wyłączyć regułę i wykonać zdefiniowane testy.
5. Usunąć ją dopiero po udokumentowanej obserwacji.

Rzadko używana reguła awaryjna może być ważna. Z kolei często używana szeroka reguła nie jest automatycznie bezpieczna.

Licznik danych, przegląd i rejestr zmian

Opcja Reset data transfer count zeruje licznik przesłanych danych danej reguły. Nie jest to licznik sesji ani trafień. Status Unused oznacza tylko, że w ciągu ostatnich 24 godzin nie znaleziono pasującego ruchu. Obie informacje należy oceniać wraz z logami, opisem reguły i use case. Do oceny ilości przesłanych danych można dodatkowo użyć Reports > Dashboards > Traffic dashboard > Allowed policies.

Regularne przeglądy powinny obejmować co najmniej:

• Source, Destination i Services;
• pozostałe obiekty Any;
• Owner, ticket i datę wygaśnięcia;
• logowanie i rzeczywiste użycie;
• NAT, Web Policy, IPS, TLS Inspection i inne funkcje ochronne;
• wyłączone, tymczasowe i automatycznie utworzone reguły.

Przed większymi zmianami należy mieć backup. Audit Trail Logs i Config Studio pokazują zmiany konfiguracji; w grupach zarządzanych przez Central Firewall Management Task Queue potwierdza, czy zmiana dotarła do właściwego urządzenia. Firewall Health Check uzupełnia regularny przegląd zabezpieczeń.

Typowe błędy

• Oczekiwana reguła nie działa lub pojawia się Rule ID #0: Sprawdzić kolejność, IPv4/IPv6 oraz wszystkie kryteria Source, Destination, Service, użytkowników i Exclusions.
• Firewall Rule ID jest prawidłowe, ale NAT Rule ID lub droga pakietu nie: Sprawdzić kolejność NAT, routing, SD-WAN i drogę powrotną.
• Reguła działa, ale ochrona nie albo aplikacja przestaje działać: Osobno sprawdzić licencję, globalne włączenie, logowanie, Web Policy, QUIC, TLS Inspection, IPS i Traffic Shaping Policy.

Jeśli Rule ID, NAT ID lub droga pakietu są nieoczekiwane, artykuł Reguła Sophos Firewall nie działa pomaga przeprowadzić uporządkowaną analizę przyczyny.