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

Przed wybraniem Add firewall rule na stronie reguł należy wyraźnie wybrać IPv4 lub IPv6. Poniższe przykłady nie stanowią wspólnego zezwolenia dla obu rodzin protokołów.

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 pozytywne kryteria dopasowania danej reguły są spełnione i ruch nie jest objęty wykluczeniem, reguła jest stosowana, a 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 dla ruchu dopasowanego do reguły ogólnej i nieobjętego jej wykluczeniami.

Pozytywne kryteria dopasowania obejmują między innymi Source zone, Source network, harmonogram, Destination zone, Destination network, Service i użytkownika. Wszystkie skonfigurowane pozytywne kryteria muszą odpowiadać danemu połączeniu. Exclusions nie są kryteriami pozytywnymi: jeśli wszystkie skonfigurowane kryteria danego wykluczenia są spełnione jednocześnie, SFOS pomija regułę i kontynuuje ocenę kolejnych reguł.

Automatycznie tworzone reguły MTA, IPsec lub Hotspot mogą pojawić się na początku listy. Server Access Assistant również tworzy regułę zapory wraz z DNAT, reflexive SNAT i Loopback. 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; działanie Server Access Assistant opisuje instrukcja DNAT dla opublikowanych serwerów.

⚠️ Przed utworzeniem reguły Drop z logowaniem: Nie zakładać, że zachowuje ona dotychczasowe blokowanie HTTP/HTTPS: dokumentacja dotycząca Drop, uwierzytelniania, Web Exceptions i stron blokady jest sprzeczna. Dla każdego ruchu WWW przed wdrożeniem do produkcji wymagane jest pisemne wyjaśnienie Sophos dla dokładnej wersji SFOS, buildu i ścieżki przetwarzania albo wyraźnie zatwierdzona, izolowana weryfikacja. Stosować opisane niżej w sekcji Action i logowanie wskazówki dotyczące weryfikacji, wycofania zmian i eskalacji.

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 i nie tworzy zwykłego wpisu w dzienniku ruchu zapory. Aby te odrzucenia były widoczne w Log Viewer, Central Reporting lub syslog, na końcu bazy reguł należy utworzyć precyzyjnie ograniczoną regułę Drop z włączoną opcją Log firewall traffic. W tym celu należy wybrać osobno rzeczywiście potrzebne Source zones i Destination zones zamiast strefy Any; w przeciwnym razie reguła może objąć także ruch wewnętrzny do usług lokalnych. Szczegóły opisano w artykule Analizowanie odrzuconych pakietów w Sophos Firewall.

Aby utworzyć zatwierdzoną regułę z logowaniem, w odpowiednim zestawie reguł IPv4/IPv6 wybierz Add firewall rule > New firewall rule, podaj jednoznaczną nazwę i ustaw Rule position Bottom, Action Drop oraz Log firewall traffic. Wybierz osobno Source zones i Destination zones; ustaw Source networks and devices, Destination networks i Services zgodnie z zatwierdzonym zakresem, a następnie wybierz Save. Wcześniej zapisz istniejącą kolejność reguł i konfigurację logowania. Nowe testowe połączenia dozwolone oraz celowo niedozwolone muszą trafiać do oczekiwanych Rule IDs, bez zakłócania usług lokalnych. W razie rozbieżności wyłącz nową regułę i przywróć poprzedni stan. Wyjaśnienie kwestii ruchu WWW w sekcji Action i logowanie pozostaje warunkiem wstępnym.

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. Grupa nie może pozostać pusta. Pomoc SFOS 22 opisuje odłączenie przez Detach przed przeniesieniem reguły poza grupę; alternatywnie można przenieść całą grupę. Usunięcie ostatniej reguły usuwa również grupę.

W tabeli SFOS-22 filtry można wyświetlać lub ukrywać za pomocą Enable filter / Disable filter, wybierać pole i wartość w Add filter oraz resetować je za pomocą Reset filter. Przy aktywnym filtrowaniu można wybierać pojedyncze reguły, ale nie grupy reguł. Reguły lub grupy można włączać i wyłączać za pomocą Enable / Disable; jednoczesne zaznaczenie reguł aktywnych i nieaktywnych uniemożliwia tę operację. More options udostępnia edycję, klonowanie, dodawanie, usuwanie, Detach, Reset data transfer count oraz operacje na grupach. Dla reguły, która nie należy jeszcze do grupy, wybierz Add to group > New group, podaj nazwę grupy i określ typ reguły oraz strefy źródłowe i docelowe; można też wybrać istniejącą grupę. Grupy można edytować lub usuwać. Kolumna # pokazuje pozycję; za pomocą Rule handle można przeciągnąć regułę lub grupę albo wpisać pozycję docelową w Move To i potwierdzić klawiszem Enter. Przed każdym przeniesieniem zapisz dotychczasowy stan, a następnie sprawdź na nowych przepływach testowych, czy trafiają do oczekiwanego Rule ID. Klon nie jest automatycznie bezpiecznym zezwoleniem: przed aktywacją sprawdź kryteria, status i pozycję.

Pomoc SFOS 23 opisuje inny sposób obsługi: aby wyszukać reguły według filtrów, kliknąć pole wyszukiwania, wybrać sugerowane kryterium i uzupełnić wyszukiwanie, korzystając z kolejnych podpowiedzi. Nacisnąć Enter, aby przefiltrować tabelę reguł. Aby wyszukać regułę po nazwie, wpisać ją bezpośrednio w polu wyszukiwania i nacisnąć Enter; usuwać pojedyncze filtry przez x. Show/Hide columns pozwala wybrać widoczne kolumny, zmienić ich kolejność przez kliknięcie i przeciągnięcie oraz przypiąć maksymalnie trzy kolumny, aby zawsze były wyświetlane jako pierwsze. Włączać i wyłączać przez Status lub zbiorczo przez Turn on / Turn off; mieszany wybór reguł włączonych i wyłączonych uniemożliwia tę operację zbiorczą. Wyłączone reguły są przygaszone i mają przekreśloną nazwę. Przeciągnięcie reguły co najmniej jedną pozycję poza grupę usuwa jej członkostwo; umieszczenie między dwiema regułami innej grupy dodaje ją do tej grupy. View menu udostępnia Clone rule above/below, Add rule above/below, Move To i Edit group. Najechanie na Features pokazuje szczegóły: odróżniać typ User/Network i akcję reguły od akcji policy i progów Heartbeat. W tabeli SFOS 23 User oznacza zaznaczone Match known users, a Network brak zaznaczenia; ikony policy rozróżniają None, Accept, Drop i Reject, a Heartbeat Green, Yellow i No restriction. Ta prezentacja nie dowodzi zmiany silnika ruchu.

Symbole to wskazówki dotyczące konfiguracji, a nie wyniki testów: w SFOS 23 w sekcji Features, a w SFOS 22 w sekcji Feature and service sprawdza się, czy skanowanie ruchu Web/FTP/poczty i Traffic Logging są włączone czy wyłączone, czy wybrano filtrowanie przez proxy oraz czy przypisano polityki. Włączone proxy obejmuje porty 80/443; pozostałe porty HTTP/TLS nadal obsługuje DPI. Web policy, App control, IPS i Shape traffic mogą wskazywać None; symbole IPS i kształtowania ruchu wskazują przypisaną politykę, a symbole Web i App dodatkowo jej działanie. W przypadku Heartbeat należy odróżnić minimalny status Green lub Yellow od No restriction i sprawdzić osobno stan opcji Block clients with no heartbeat. Samo No restriction nie dowodzi, że ten dodatkowy przełącznik jest wyłączony. Przy sprawdzaniu dopasowania należy również uwzględnić włączone Exclusions.

Dla nowych instalacji pomoc SFOS-22/23 wymienia regułę LAN-to-WAN oraz regułę MTA z Linked NAT, tworzoną automatycznie przy włączonym trybie MTA; MTA jest tam domyślnie aktywny. Nie zastępuje to sprawdzenia własnej instalacji. Reguły niejawnej #0 nie można edytować, usuwać ani przenosić i pozostaje ona wyłączona z filtrowania. Należy odróżnić od tego przywrócenie ustawień fabrycznych: obie wersje pomocy opisują usunięcie wszystkich reguł zapory, po którym pozostaje wyłącznie reguła Auto added firewall policy for MTA. Nie należy z tego wnioskować, że zezwolenie LAN-to-WAN zostanie automatycznie przywrócone. Reset nie jest sposobem porządkowania pojedynczych reguł; kopia zapasowa, niezależny dostęp administracyjny i plan przywracania należą do osobnej procedury Resetowanie Sophos Firewall.

Przegląd dotyczący uruchomienia Access rules and policies dla SFOS 22/23 opisuje również domyślnie tworzone grupy reguł z regułą zapory odrzucającą ruch w kierunku WAN, DMZ i stref wewnętrznych (LAN, Wi-Fi, VPN i DMZ). Chodzi tu o widoczne, pogrupowane reguły zapory, a nie o regułę niejawną #0. Ten przegląd oraz wspomniane powyżej szczegółowe ustawienia domyślne instalacji i resetowania nie potwierdzają jednak jednolitego początkowego zestawu reguł dla każdej instalacji. Dlatego w konkretnej wersji, kompilacji i instalacji SFOS należy sprawdzić w Rules and policies > Firewall rules, które reguły i grupy są rzeczywiście obecne i włączone, jakich stref źródłowych/docelowych oraz innych kryteriów dopasowania używają i na jakich pozycjach się znajdują. Sama obecność grupy nie dowodzi izolacji: wcześniejsze pasujące zezwolenie może już dopuszczać ruch. Należy sprawdzić pożądany podział na strefy za pomocą nowych, wyraźnie autoryzowanych połączeń testowych oraz oczekiwanych Rule IDs; w przypadku ruchu webowego nadal obowiązuje opisany powyżej konflikt w dokumentacji dotyczący Drop. Z przeglądu dotyczącego uruchomienia nie należy wywodzić gwarantowanych nazw grup, warunków ich tworzenia ani ogólnego działania blokującego.

Action i logowanie

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

• Accept: zezwala na połączenie.
• Drop: jest udokumentowane jako odrzucanie bez powiadomienia dla ruchu innego niż WWW. Zachowanie HTTP/HTTPS nie jest ogólnie gwarantowane z powodu opisanego poniżej konfliktu dokumentacji.
• Reject: odrzuca połączenie i w przypadku TCP wysyła reset TCP; dla UDP i ICMP pomoc wyraźnie wskazuje komunikat ICMP Port Unreachable wysyłany do źródła.
• 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.

Po wybraniu Protect with web server protection pojawia się Preconfigured template. None oznacza samodzielne określenie szczegółów WAF. Udokumentowane szablony to Exchange Autodiscover, Exchange Outlook Anywhere, Exchange General, Microsoft Lync, Microsoft Remote Desktop Gateway 2008 and R2, Microsoft Remote Desktop Web 2008 and R2 oraz Microsoft Sharepoint 2010 and 2013. Te historyczne nazwy nie stanowią informacji o obecnym wsparciu ani bezpieczeństwie poszczególnych wersji serwerów. Przed użyciem szablon musi zostać dopasowany do faktycznie działającej usługi; nadal wymagana jest późniejsza konfiguracja WAF i jej odbiór.

⚠️ Nierozstrzygnięty konflikt dokumentacji dotyczący ruchu WWW: Pomoc formularza reguł SFOS 22/23 opisuje dla Drop przyjmowanie i analizę HTTP/HTTPS, uwierzytelnianie nieznanych użytkowników przy włączonym Use web authentication for unknown users, dopuszczanie żądań dozwolonych przez pasujący Web Exception oraz stronę blokady HTML dla pozostałych żądań. Instrukcja logowania odrzuconego ruchu opisuje natomiast ogólne ciche odrzucanie i wiąże stronę blokady WWW z tą opcją uwierzytelniania. Te sprzeczne opisy nie zostały tu rozstrzygnięte jako zweryfikowane zachowanie konkretnego buildu SFOS. Nie dowodzą cichego odrzucania wszystkich połączeń WWW, zależności strony blokady wyłącznie od opcji uwierzytelniania ani ogólnego blokowania wszystkich usług.

Jeśli wymagane jest gwarantowane blokowanie lub określona odpowiedź, uzyskać pisemne wyjaśnienie Sophos dla dokładnej wersji SFOS, buildu i ścieżki przetwarzania albo przeprowadzić weryfikację w wyraźnie zatwierdzonym, izolowanym środowisku testowym. Osobno testować ruch inny niż WWW, HTTP i HTTPS; dla ruchu WWW także znanych/nieznanych użytkowników, uwierzytelnianie włączone/wyłączone i obecność/brak pasującego Web Exception. Używać tylko określonych klientów, celów i usług testowych, włączyć Log firewall traffic i tworzyć nowe połączenia. Udokumentować build, pozycję reguły, Firewall Rule ID, użytkownika, Action, ustawienia WWW/TLS oraz wyniki logów, Packet Capture i przeglądarki. Sam timeout, strona blokady lub Policy Tester nie dowodzą zamierzonego blokowania. Przy nieoczekiwanym dostępie lub niejasnym wyniku nie wdrażać do produkcji; wycofać zmiany testowe i przekazać dowody do Sophos Support. Reject zapewnia opisaną wyżej odpowiedź protokołu; nie jest tu zalecane jako niezweryfikowany zamiennik kontroli WWW.

Ważne reguły powinny mieć włączone Log firewall traffic. Logi są domyślnie przechowywane lokalnie na firewallu; ustawienia lokalne i cele Syslog sprawdza się w System services > Log settings. Wysyłanie do usługi cloud wymaga dodatkowo włączenia Sophos Central services na stronie Sophos Central. Pomoc SFOS 22 nazywa cel Sophos Fusion (dawniej Sophos Central), a pomoc SFOS 23 Sophos Central; nazwa nie zastępuje tego osobnego warunku. 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.

Reguła oparta na MAC: wyjaśnij ograniczenia przed próbą blokowania

Host MAC może umożliwić dodatkowe powiązanie z urządzeniem w przypadku bezpośrednio widocznych klientów, na przykład gdy zmienia się ich adres DHCP. Adres MAC nie jest jednak silnym identyfikatorem: można go zmienić lub podrobić. Instrukcja źródłowa określa filtrowanie MAC jako bezpieczniejsze i pokazuje Block_MAC dla IPv4 z LAN do WAN z Drop, logowaniem, pozycją Top, grupą None, harmonogramem All the time oraz celem i Services Any. Taka kombinacja nie stanowi tutaj zapewnienia pełnej blokady Internetu: opisany powyżej konflikt HTTP/HTTPS/Web Exceptions pozostaje nierozstrzygnięty.

Filtrowanie Internetu na podstawie MAC jest w instrukcji ograniczone do urządzeń bezpośrednio połączonych z zaporą. Jeśli po drodze znajduje się router, inna zapora lub przełącznik warstwy 3, pierwotny adres MAC klienta nie jest automatycznie widoczny. Instrukcja wskazuje w tym przypadku MAC binding dla użytkowników lokalnych; bez wyjaśnienia powiązania tożsamości i rzeczywistej ścieżki pakietów nie gwarantuje to filtrowania MAC w ruchu routowanym ani nie zastępuje uwierzytelniania. Przed próbą adres MAC widoczny na wejściu zapory musi rzeczywiście należeć do klienta testowego.

W ramach wyraźnie zatwierdzonego, izolowanego pilotażu blokowany jest tylko nowy przepływ IPv4 TCP niezwiązany z WWW do kontrolowanego serwera testowego w WAN:

1. Porównaj adres MAC na kliencie testowym i na wejściu zapory. W Hosts and services > MAC host > Add wpisz nazwę MAC_Host, Type MAC address i faktycznie zweryfikowany adres MAC, a następnie wybierz Save. 37:97:0E:AB:56:46 jest niezmienioną wartością przykładową z instrukcji i nie należy jej bezkrytycznie przejmować.
2. W Rules and policies > Firewall rules wybierz IPv4 i Add firewall rule > New firewall rule. Dla Block_MAC ustaw Action Drop, Log firewall traffic, Rule position Top, Rule group None, Source zones LAN, Source networks and devices MAC_Host, During scheduled time All the time oraz Destination zones WAN. Ogranicz cel do kontrolowanego serwera testowego, a Services do zatwierdzonej testowej usługi TCP niezwiązanej z WWW, zamiast przejmować pierwotne wartości Any. Wcześniej zapisz kolejność i stan konfiguracji, a następnie wybierz Save.
3. Wygeneruj nowy przepływ testowy, na przykład zatwierdzony przepływ TCP iPerf3, i sprawdź Block_MAC wraz z Rule ID w Log Viewer oraz odrzucany przepływ pakietów. Inny, nieblokowany klient kontrolny musi nadal mieć dostęp do celu testowego. Sam timeout nie wystarczy.
4. Po pilotażu wyłącz lub usuń regułę testową, przywróć poprzednią kolejność i potwierdź nowy dozwolony przepływ testowy z pierwotnego klienta na podstawie oczekiwanego Rule ID. Usuń testowy host MAC tylko wtedy, gdy nie jest potrzebny w żadnej innej konfiguracji.

Przy braku dopasowania sprawdź widoczność MAC, wybór IPv4, Source, Schedule i kolejność, zamiast rozszerzać regułę na wszystkie urządzenia. W razie nieoczekiwanego dostępu lub utraty dostępu przez klienta kontrolnego wycofaj próbę i wyjaśnij zebrane dowody z uwzględnieniem dokładnej wersji i numeru kompilacji. Ten pilotaż nie obejmuje HTTP, HTTPS, Web Exceptions, innych stref/celów/usług ani IPv6. Pełną blokadę Internetu opartą na MAC można zapewnić dopiero po osobnym wyjaśnieniu i sprawdzeniu tych przypadków.

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.

Nieznany oznacza tutaj: zalogowany na urządzeniu końcowym, ale jeszcze nieuwierzytelniony na zaporze. AD SSO z Kerberos/NTLM lub Captive Portal konfiguruje się w Authentication > Web authentication, a dostęp z wymaganych stref w Administration > Device access. Domyślnie pasujący ruch jest wliczany do indywidualnego zużycia danych. Exclude this user activity from data accounting wyłącza go z tego rozliczania, na przykład gdy tych użytkowników nie ma obowiązywać limit danych; nie jest to ani dodatkowe zezwolenie, ani uwierzytelnienie.

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.

Udokumentowany przykład dotyczący krajów zezwala na HTTPS z krajów afrykańskich do 172.16.16.0 i używa Exclusion zawierającego tylko Source zone WAN oraz wybrany obiekt kraju jako Source network. Reguła jest pomijana tylko wtedy, gdy oba kryteria są spełnione; ruch może zostać dozwolony przez późniejszą regułę albo trafić do #0. Adres jest niezmienionym przykładem, a nie pełną definicją sieci z prefiksem. Do własnego testu wybierz rzeczywiście istniejący obiekt docelowy, udokumentuj kolejność reguł i sprawdź na podstawie Rule IDs jeden przepływ testowy objęty wykluczeniem oraz jeden nieobjęty wykluczeniem. Exclusion nie jest globalną blokadą.

Create linked NAT rule

Odłączenie Linked NAT Rule w tabeli NAT umożliwia jej edycję i powoduje ocenę według własnych kryteriów, niezależnie od pierwotnej reguły firewalla. Przed odłączeniem udokumentować zakres i kolejność NAT, a następnie sprawdzić nowy przepływ testowy; to nie tylko zmiana nazwy.

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.

W wielu instalacjach istnieje już Default SNAT rule z MASQ. Zależy to jednak od stanu konfiguracji i migracji i wymaga sprawdzenia w konkretnej tabeli reguł NAT. Przed dodaniem kolejnej Linked NAT Rule należy sprawdzić, czy istniejąca 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.

Dla wychodzącego ruchu klientów można utworzyć jednocześnie zezwolenie w zaporze i Source NAT:

1. W Rules and policies > Firewall rules wybierz rodzinę protokołów i otwórz Add firewall rule > New firewall rule. Określ nazwę i pozycję; w przykładzie użyj Source zones LAN, Source networks and devices Network_LAN, Destination zones WAN oraz Destination networks Any. Network_LAN musi zawierać własną, zweryfikowaną sieć klientów. Instrukcja pokazuje Services Any; w środowisku produkcyjnym wybierz zamiast tego wyłącznie zatwierdzone usługi.
2. Wybierz Create linked NAT rule, określ nazwę i pozycję NAT oraz ustaw Translated source (SNAT) na MASQ. Najpierw zapisz Linked NAT Rule za pomocą Save, a następnie regułę zapory za pomocą Save.
3. Sprawdź regułę zapory w tabeli zapory i powiązaną regułę SNAT w tabeli NAT na podstawie Firewall Rule ID i nazwy. Najpierw oceniana jest reguła zapory, a następnie Source NAT. W Linked NAT można zmieniać tylko przetłumaczone źródło i translację źródła zależną od interfejsu wyjściowego; pozostałe kryteria, w tym użytkownicy/grupy, pochodzą z reguły zapory.

Zapis źródłowy 10.145.16.10/24 jest niezmienioną wartością przykładową z instrukcji, a nie wartością do kopiowania bez sprawdzenia jako adres sieci. MASQ używa adresu IP faktycznie wybranego interfejsu wyjściowego. Wcześniej sprawdź odpowiednią trasę, interfejs i reguły NAT umieszczone wyżej. Nowy przepływ testowy musi wykazać oczekiwane Firewall Rule ID, NAT Rule ID i oczekiwane przetłumaczone źródło. Przy błędnej translacji sprawdź kolejność i interfejs wyjściowy; w razie niepowodzenia wycofaj nową konfigurację zapory i Linked NAT oraz przywróć poprzedni stan wraz z kolejnością, nie zmieniając innych potrzebnych reguł NAT.

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.

Scan HTTP and decrypted HTTPS sprawdza ruch HTTP i już odszyfrowany ruch HTTPS pod kątem złośliwego oprogramowania, ale nie włącza odszyfrowywania. W trybie DPI wymaga to odpowiedniej reguły inspekcji SSL/TLS w sekcji Rules and policies > SSL/TLS inspection rules; w trybie web proxy używa się opcji Decrypt HTTPS during web proxy filtering. Przed wdrożeniem należy sprawdzić faktycznie używaną ścieżkę przetwarzania oraz to, czy klienci ufają urzędowi certyfikacji używanemu do odszyfrowywania (Decryption-CA).

Use Zero-day protection wymaga włączenia Scan HTTP and decrypted HTTPS i wysyła pliki pobrane przez HTTP/HTTPS do dodatkowej analizy pod kątem nieznanych lub jeszcze nieujawnionych zagrożeń. Funkcja wymaga Zero-Day Protection i w zależności od typu pliku oraz polityki może powodować opóźnienie; sama nie włącza odszyfrowywania HTTPS.

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

Nawet przy włączonym Use web proxy instead of DPI engine silnik DPI nadal filtruje HTTP i SSL/TLS na innych portach; przełącznik dotyczy proxy dla 80/443, a nie całego ruchu. Filtrowanie przez web proxy na moście bez adresu IP jest opisane w pomocy jako przypadek odrzucania ruchu i nie może być włączane bez sprawdzenia. Decrypt HTTPS during web proxy filtering odszyfrowuje ruch również w trybie Direct Proxy jawnie skonfigurowanym na kliencie. W trybie DPI Web Policies, w tym Web Exceptions, mają zastosowanie tylko wtedy, gdy ustawiono Web Policy, aktywne jest skanowanie złośliwego oprogramowania/treści lub aktywne jest ATP. Warunki te należy odróżnić od wykrywania Micro Apps na podstawie URL, opisanego w sekcji Application Control, IPS i Traffic Shaping.

Przetwarzanie tylko określonych celów przez Web Proxy

Jeśli SafeSearch, ograniczenia YouTube lub logowanie do Google Workspace mają być ograniczone do określonych domen, podczas gdy pozostały ruch korzysta z odszyfrowywania DPI, utwórz osobną regułę umieszczoną wyżej. Wcześniej sprawdź licencję Web Protection, odpowiednie globalne ustawienia WWW, zaufanie klientów do urzędu certyfikacji używanego do odszyfrowywania oraz wymaganą Web Policy. Grupy FQDN określają cele; same nie konfigurują dozwolonych domen kont ani działań filtrowania.

1. W Rules and policies > Firewall rules wybierz IPv4 lub IPv6, otwórz Add firewall rule > New firewall rule i ustaw nazwę oraz pozycję. Wybierz Action Accept, rzeczywiście potrzebną strefę źródłową i zatwierdzoną sieć klientów. Instrukcja źródłowa używa tutaj Any; tak szeroko określone źródło nie jest wymaganym ustawieniem produkcyjnym.
2. Ustaw Destination zones WAN, Destination networks z predefiniowanymi grupami SafeSearch enforcement, YouTube restrictions enforcement i Google app enforcement oraz Services HTTP, HTTPS. Wybierz tylko grupy potrzebne w danym przypadku użycia.
3. Włącz Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine oraz Decrypt HTTPS during web proxy filtering. Właściwa Web Policy musi odpowiadać wymaganemu ograniczeniu. Włącz Log firewall traffic na potrzeby pilotażu i zapisz za pomocą Save.
4. Umieść regułę powyżej reguł DPI. Za pomocą nowych połączeń sprawdź wymagane ograniczenie SafeSearch/YouTube/kont, Rule ID oraz logi WWW/TLS; przetestuj też inny cel, który nadal powinien trafiać do przewidzianej reguły DPI i SSL/TLS inspection rule.

Jeśli ograniczenie nie działa, sprawdź pozycję reguły, przypisanie FQDN, Web Policy i QUIC; przy błędach certyfikatów sprawdź zaufanie do urzędu certyfikacji i konfigurację odszyfrowywania. W razie nieoczekiwanego działania wyłącz nową regułę proxy lub przywróć poprzednie wartości i pozycję, a następnie ponownie sprawdź pierwotną ścieżkę DPI. Nie wyłączaj ogólnie ochrony TLS ani weryfikacji certyfikatów.

Synchronized Security Heartbeat

Reguły Heartbeat wymagają:

• firewalla zarejestrowanego na tym samym koncie Sophos Fusion 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 Fusion > 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.

Dla obu progów Green dopuszcza tylko Green; Yellow dopuszcza Green lub Yellow; No restriction dopuszcza również Red i urządzenia bez Heartbeat. Sprawdzić też osobne opcje blokowania bez Heartbeat. Poradnik brakującego Heartbeat odróżnia utracony od nigdy niewysłanego; Synchronized User ID opisuje wylogowanie po utracie lub uśpieniu/wybudzeniu i weryfikację nowego logowania.

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.

Skanowanie malware i treści korzysta z Web > General settings. Wybór filtrowania web proxy wymaga wcześniej Web Policy lub Scan HTTP and decrypted HTTPS. Application Filter Policy dla Micro Apps opartych na URL działa nadal w ścieżce DPI z deszyfrowaniem przy Web policy None, gdy zarówno skanowanie złośliwego oprogramowania, jak i ATP są wyłączone. Nie znosi to osobnych warunków aktywacji Web Exceptions w DPI. Szczegółowe poradniki opisują proxy na bridge bez IP oraz deszyfrowanie HTTPS w Direct Web Proxy.

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. Bieżąca pomoc do formularza reguły nie opisuje priorytetu między Application Policy a Rules Policy. Dla powtarzalnego projektu należy używać tylko jednego wariantu w danym przypadku, a jeśli konieczne jest połączenie obu wariantów, przetestować tę kombinację na używanym buildzie SFOS. Natomiast przy włączonej opcji Match known users obowiązuje Traffic Shaping Policy użytkownika; jeśli użytkownik nie ma własnej policy, stosowana jest policy jego grupy.

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 tylko wychodzące pakiety IPv4 i IPv6 pasujące do tej reguły. Zastępuje przy tym oznaczenie DSCP, które było już ustawione w ruchu przychodzącym. Pakiety odpowiedzi i ruch generowany przez system nie są oznaczane przez regułę zapory. Samo oznaczenie nie nadaje priorytetu ani nie klasyfikuje ruchu; wszystkie zaangażowane przełączniki, routery i urządzenia WAN muszą spójnie przetwarzać wybrane wartości DSCP.

Ograniczony test QoS używa określonego klienta, zatwierdzonego celu testowego i ICMP z AF31 = 26. Potwierdzić dopasowanie reguły, sprawdzić oznaczenie przez Packet Capture na wyjściu WAN i osobno odpowiedź. CS0 = 0 to odpowiedź w udokumentowanym przykładzie, nie gwarancja oznaczeń dowolnego celu. Nie tworzyć szerokiego zezwolenia Any; po teście usunąć regułę testową. Test reguły Sophos Firewall opisuje przechwytywanie.

Wybór DSCP musi być zgodny z projektem QoS na całej trasie: EF oznacza Expedited Forwarding zapewniające małe opóźnienia i małe straty dla usług czasu rzeczywistego; AF oznacza Assured Forwarding z odrzucaniem przy przeciążeniu; CS służy zgodności z IP-Precedence. Są to koncepcje klas, a nie jakość usług gwarantowana samym oznaczeniem. Udokumentowane wartości to:

Pierwotny przykład ICMP używa 8.8.8.8, Source zone LAN, Destination zone WAN, źródła i celu Any oraz AF31. Do własnej weryfikacji zastąp je zatwierdzonymi, konkretnymi obiektami klienta i celu; ani ten publiczny adres, ani szerokie zezwolenie nie są wymagane. Przed testem zapisz poprzednią wartość DSCP, po teście przywróć ją i sprawdź na nowych pakietach. Jeśli oczekiwana priorytetyzacja nie występuje, należy osobno zbadać dopasowanie reguły, faktyczne oznaczenie na wyjściu i obsługę QoS przez kolejne urządzenia na trasie.

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 Appliance 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 Fusion są opcjonalne dla dalszej analizy.

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.

Dla istniejącego serwera SMTP opublikowanego przez DNAT artykuł Konfiguracja Mail Protection w Legacy mode łączy reguły przychodzące i wychodzące z NAT, polityką skanowania, TLS i logami proxy Legacy.

Przy pobieraniu poczty samo pole wyboru nie wystarcza: zaufanie CA, globalne limity skanowania, opcjonalna polityka POP-IMAP i rzeczywiste dopasowanie reguły muszą ze sobą współgrać. Skanowanie i testowanie POP3 oraz IMAP na Sophos Firewall przedstawia pełną procedurę pilotażu i weryfikacji.

Przygotowanie reguł zapory przez XML API

Obiekty XML FirewallRule i FirewallRuleGroup nadają się do przeprowadzania zmian reguł w sposób umożliwiający ich prześledzenie oraz do zarządzania grupami. Nie zastępują ani planowania dostępu, ani testów odbiorczych z użyciem nowych połączeń testowych. Bezpieczny dostęp, HTTP POST do APIController, jawne operacje XML, weryfikację TLS, przechowywanie sekretów oraz ocenę statusu XML zamiast samego powodzenia HTTP opisuje artykuł Zabezpieczanie dostępu do XML API. Najpierw z planowanego hosta automatyzacji musi działać nieszkodliwe zapytanie odczytowe z użyciem konta o ściśle ograniczonych uprawnieniach.

Zachowanie typu reguły, struktury nadrzędnej i kolejności

W dokumentacji referencyjnej SFOS 22/23 pola Name, Position i PolicyType są obowiązkowe dla Add/Edit. Name jest ciągiem UTF-8 o długości maksymalnie 60 znaków, bez przecinka. W obiekcie FirewallRule pole PolicyType o wartości Network wybiera blok NetworkPolicy, a o wartości User — blok UserPolicy. Nie należy mieszać tych gałęzi ani wysyłać obu bez weryfikacji. HTTPBased i HTTPBasedPolicy należą do konfiguracji WAF, a powiązanie z uwierzytelnianiem — do uwierzytelniania WAF. Działania w ścieżce WAF nie są liczbowym odwzorowaniem działań sieciowych.

IPFamily dopuszcza IPv4 lub IPv6; tabela podaje IPv4 jako wartość domyślną. Status dopuszcza Enable lub Disable, ale jako wartość domyślną podaje ON. Dla przygotowywanych reguł należy świadomie ustawić status na Disable i sprawdzić zapisaną rodzinę protokołów, zamiast przyjmować wartości domyślne z dokumentacji za bezpieczne wartości payloadu. Według tabeli parametrów Position dopuszcza Bottom, Top, After lub Before; w przykładzie wartości te zapisano małymi literami. Dlatego należy potwierdzić pisownię i pełną operację w API help zainstalowanego buildu. After/Name i Before/Name wskazują istniejącą regułę odniesienia; dokumentacja referencyjna ogranicza te tagi do żądań Set. Section rozróżnia Central_TOP, Local i Central_Bottom: przed lokalną próbą zapisu należy wyjaśnić, kto zarządza regułą i jaką ścieżką, a nie obchodzić ograniczenia centralnego przez użycie innej sekcji.

W wybranym bloku policy źródło i cel pozostają rozdzielone: SourceZones/Zone, SourceNetworks/Network, DestinationZones/Zone, DestinationNetworks/Network i Services/Service zawierają odwołania, które można powtarzać. Schedule wskazuje istniejący harmonogram. Tabele ograniczają odwołania do sieci i usług do 60 znaków; nie dokumentują wspólnej maksymalnej liczby wszystkich kryteriów. Te same elementy nadrzędne mogą występować pod Exclusions i oznaczają tam wyjątki od tej reguły, a nie dodatkowe zezwolenia. Przed zapisem należy odczytać rzeczywiście istniejące strefy, hosty, usługi i harmonogramy oraz sprawdzić zamierzone dopasowanie, uwzględniając kolejne reguły.

W przypadku UserPolicy pola MatchIdentity, ShowCaptivePortal i Identity/Member dodają kontekst użytkownika. Dla Member udokumentowano możliwość podania wielu odwołań do użytkowników/grup o długości maksymalnie 256 znaków. Przypisywanie tożsamości i uwierzytelnianie WWW muszą działać niezależnie. DataAccounting opisano tylko przy włączonym dopasowywaniu tożsamości; wyłącza ono ruch użytkowników z rozliczania danych, ale nie uwierzytelnia. Przykład i tabela są tu sprzeczne: przykład pokazuje Include/Exclude, a tabela Enable/Disable. Również WebCategoryBaseQoSPolicy i ApplicationBaseQoSPolicy pokazują w przykładzie Apply/Revoke, podczas gdy tabela opisuje ciąg znaków. Nie należy automatycznie tłumaczyć takich wartości ani traktować ich jako zamiennych. Jeśli konkretna wartość dla danego obiektu i buildu pozostaje niewyjaśniona, należy wstrzymać żądanie zapisu i wyjaśnić ją z Sophos.

Action w gałęzi Network/User dopuszcza Accept, Drop lub Reject; tabela podaje Drop jako wartość domyślną. Nadal konieczne jest jawne określenie działania, a wyjaśniony powyżej konflikt dotyczący obsługi HTTP/HTTPS przez Drop obowiązuje również przy zmianach przez API. LogTraffic dopuszcza Enable/Disable, z udokumentowaną wartością domyślną Disable; logowanie na potrzeby testów odbiorczych należy wybrać świadomie. SkipLocalDestined dotyczy ruchu do adresu IP urządzenia i nie zastępuje Device Access. Odwołania do polityk, takie jak WebFilter, ApplicationControl, IntrusionPrevention i TrafficShapingPolicy, muszą odpowiadać wcześniej zaplanowanej ochronie. Skanowanie, proxy, deszyfrowanie, Zero-Day i Heartbeat pozostają odrębnymi mechanizmami kontroli z wymaganiami wyjaśnionymi powyżej. W szczególności wartości domyślne, takie jak OFF, NULL lub NoRestriction, częściowo przeczą wskazanym wartościom wejściowym; ani te informacje, ani puste elementy w przykładach nie dowodzą, jaki skutek ma pominięcie, wyczyszczenie lub aktualizacja w konkretnym buildzie.

Przy przenoszeniu istniejących opcji ochrony należy sprawdzić dziedzinę wartości każdego pola: ProxyMode wymienia oprócz Enable/Disable także true/false; NDRActiveThreatIntelligence wymienia tylko true/false. Progi MinimumSourceHBPermitted i MinimumDestinationHBPermitted dopuszczają GREEN, YELLOW i No Restriction, natomiast kolumna wartości domyślnych podaje NoRestriction. Są to inne dane wejściowe niż wartości osobnych przełączników Heartbeat, a nie automatyczne tłumaczenie nazw z GUI. Selektory związane z użytkownikami WebFilterInternetScheme i ApplicationControlInternetScheme wymieniają Enable/Disable, ale jako wartość domyślną podają 0; nie należy mylić ich z nazwą polityki. Komentarze XML wiążą WebCategoryBaseQoSPolicy z wybranym WebFilter, a ApplicationBaseQoSPolicy z wybranym filtrem aplikacji. W przypadku Traffic Shaping tabela podaje TrafficShappingPolicy/TrafficShapingPolicy, natomiast przykład XML używa TrafficShapingPolicy: nie należy z tego wywodzić zamienności ani akceptowania obu tagów. DSCPMarking jest udokumentowane jako ciąg znaków; serializacja wartości z GUI musi być zgodna z używanym buildem. Każdą opcję ochrony objętą zmianą należy porównać przed zmianą i po niej; nie należy normalizować nieznanych danych wejściowych ani tracić żadnej opcji ochrony bez wyraźnego wskazania.

Członkostwo w grupie nie jest decyzją dotyczącą bezpieczeństwa

FirewallRuleGroup łączy istniejące reguły przez SecurityPolicyList/SecurityPolicy. SourceZones/Zone i DestinationZones/Zone są oddzielnymi elementami nadrzędnymi służącymi do przypisania do grupy, a nie nowymi kryteriami dopasowania poszczególnych reguł. Pole grupy Policytype, zapisane z małą literą t, różni się od pola reguły PolicyType. Udokumentowane selektory grup to User/network rule, Network rule, User rule, WAF rule i Any; nie należy wyprowadzać tych wartości z typu reguły ani normalizować ich do innej pisowni.

Nazwa grupy jest obowiązkowa, musi być zapisana w UTF-8, nie może zawierać przecinka i może mieć maksymalnie 150 znaków; Description jest opcjonalne i może mieć maksymalnie 255 znaków. Dla SecurityPolicy dokumentacja referencyjna podaje maksymalnie 60 znaków na nazwę reguły, zakaz użycia przecinka i maksymalnie 200 wartości. Jest to limit członkostwa, a nie gwarancja pojemności. Dla grupy Internet Access należy najpierw odczytać istniejące nazwy reguł, wybrać wyłącznie zatwierdzonych członków i oddzielnie przypisać źródło oraz cel. Przykład producenta z dwukropkami i wyborem wszystkich typów rozdzielonym przecinkami nie jest payloadem gotowym do wykonania.

Przed aktualizacją grupy należy zabezpieczyć informacje o członkostwie, pozycjach reguł i statusie. Następnie należy ponownie porównać te same reguły w WebAdmin oraz przez zatwierdzone zapytanie odczytowe. Opis „Add/Remove” przy SecurityPolicy nie określa bezpiecznej przyrostowej zmiany listy ani semantyki jej zastępowania. Jeśli obsługa pominiętych lub pustych list pozostaje niewyjaśniona, nie należy wykonywać zapisu. Według pomocy GUI grupa nie może istnieć jako pusta; usunięcie ostatniej reguły może również usunąć grupę. Grupowanie poprawia przejrzystość, ale nie zapewnia ani izolacji, ani pierwszeństwa: decydujące pozostają kryteria dopasowania i rzeczywista kolejność każdej reguły.

Rozróżnianie odpowiedzi według operacji i ponowny odczyt stanu

Poniższe przyporządkowania są zgodne w dokumentacji referencyjnej SFOS 22/23. Identyfikatory Message.* pozostają nierozwiniętymi symbolami dokumentacji, a nie gwarantowanymi komunikatami zwracanymi podczas działania, ich tłumaczeniami ani jednoznacznymi przyczynami. Ten sam kod może oznaczać coś innego zależnie od operacji. W szczególności są to kody statusu XML, a nie kody statusu HTTP.

Przy tworzeniu i edycji reguł Network/User istotne są następujące różnice:

• Add firewall rule — 200 — Message.FWRuleAddSuccess; Edit firewall rule — 200 — Message.FWRuleEditSuccess.
• Edit firewall rule — 202 — Message.FirewallRuleUpdateWithRename: należy sprawdzić starą i nową nazwę, odwołania oraz zapisany typ reguły, zamiast po prostu zakładać pełne powodzenie.
• Add firewall rule — 500 — Message.FWRuleAddFail; Edit firewall rule — 500 — Message.FWRuleEditFail.
• Add firewall rule — 502 — Message.FWRuleRecordExists; Edit firewall rule — 502 — Message.FWRuleUpdateRecordExist: należy porównać istniejącą i żądaną regułę na podstawie odczytanego stanu, zamiast automatycznie ją nadpisywać.
• Add firewall rule — 541 — Message.VHIPRangeConflict; Edit firewall rule — 541 — Message.FWRuleFailMaxUser. Nie należy z tego wywodzić wspólnej przyczyny błędu ani liczbowego limitu użytkowników.
• Add firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected; Edit firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected: należy sprawdzić łącznie strefy docelowe i konfigurację Destination Heartbeat.
• Edit firewall rule — 552 — Message.CannotImportDiffPolicytypeWithSameName: należy porównać istniejącą nazwę i typ reguły, zamiast próbować obejść problem przez zmianę nazwy lub typu na ślepo.
• Add firewall rule — 596 — Message.CMLOCALOperationrestriction; Edit firewall rule — 596 — Message.CMLOCALOperationrestriction: należy wyjaśnić odpowiedzialność za zarządzanie i zatwierdzoną ścieżkę wprowadzania zmian.

Wspólnie wymienione odpowiedzi specyficzne dla WAF należą do instrukcji WAF; opisanych tam konfliktów portów, przekierowań i Protected Server nie należy przenosić na reguły Network/User.

Również dla grup należy odnotować operację: Add firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists; Edit firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists. Dokumentacja referencyjna Edit rzeczywiście używa tych samych symboli Add. Przed ponowną próbą należy odczytać zapisaną nazwę grupy, członkostwo i obie listy stref; z nazw symboli nie należy wnioskować, że przy Edit wykonywana jest operacja tworzenia.

Przy usuwaniu obowiązuje Delete firewall rule — 200 — Message.FWDelSuccess, 500 — Message.FWRuleDeleteFail, 596 — Message.CMLOCALOperationrestriction. Tabela Delete oznacza Name jako opcjonalne i sprzecznie opisuje je jako regułę odniesienia dla Before/After. Nie należy z tego wywodzić możliwości zbiorczego usuwania bez podania nazwy. Przed Remove należy sprawdzić dokładny obiekt docelowy, zależności, przynależność do grupy, Linked NAT, odpowiedzialność za zarządzanie oraz potwierdzony payload w API help. W przypadku niejasnych starych reguł kontrolowane wyłączenie z okresem obserwacji pozostaje bezpieczniejszym pierwszym krokiem.

Po każdej odpowiedzi, a także po przekroczeniu limitu czasu lub zerwaniu połączenia, przed ponowną próbą należy najpierw odczytać rzeczywisty zapisany stan: nazwa, typ, status, rodzina protokołów, pozycja, kryteria, Exclusions, odwołania do mechanizmów ochrony i członkostwo w grupach muszą odpowiadać zatwierdzonemu stanowi docelowemu. Przy Remove należy dodatkowo sprawdzić, czy brakuje dokładnie reguły docelowej, a potrzebne reguły i NAT nadal istnieją bez zmian. Nieznany wynik może oznaczać, że zmiana już została wprowadzona. Nie należy ponawiać operacji na ślepo, wykonywać automatycznego Upsert ani rozszerzać zakresu do Any; przy rozbieżnościach należy zatrzymać proces, zabezpieczyć odpowiedź po usunięciu danych wrażliwych oraz Audit Trail i zastosować potwierdzoną ścieżkę wycofania. Dopiero potem należy przeprowadzić opisane poniżej nowe przepływy testowe: dozwolone oraz celowo niedozwolone.

Testowanie i utrzymanie reguły

Test odbiorczy po zapisaniu

Po skonfigurowaniu regułę zapisuje się za pomocą Save. 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.

Policy Tester symuluje wybór reguły, ale nie generuje rzeczywistego przepływu pakietów i nie potwierdza ani routingu, ani drogi powrotnej. Dlatego pełną procedurę dla Policy Test, Log Viewer i Packet Capture opisano w artykule 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.

Wycofanie zmiany reguły

Przed zmianą należy zanotować bieżącą pozycję i wszystkie pola, których ona dotyczy, albo wyeksportować możliwy do odtworzenia stan konfiguracji. Istniejącej reguły nie należy przebudowywać do innego celu: nowa, początkowo wyłączona reguła zapewnia wyraźniejszą ścieżkę wycofania i pozostawia dotychczasowy dostęp bez zmian.

Jeżeli test odbiorczy zakończy się niepowodzeniem, należy wyłączyć nową regułę albo — w przypadku edytowanej reguły — przywrócić poprzednie wartości i wcześniejszą pozycję. Następnie trzeba ponownie wygenerować zarówno dozwolony, jak i celowo niedozwolony przepływ testowy oraz sprawdzić oczekiwany Firewall Rule ID w Log Viewer. Podczas zmiany ścieżki zarządzania przez cały proces musi być zachowany niezależny dostęp administracyjny.

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ń. W pomocy SFOS 22 Sophos różnie dokumentuje Unused w dwóch miejscach: pomoc do tabeli reguł podaje 24 godziny bez pasującego ruchu, natomiast widżet Active firewall rules w Control Center — 12 godzin i codzienną kontrolę. Dlatego status nie jest wiarygodnym kryterium usunięcia reguły. New i Changed pozostają widoczne przez 24 godziny od utworzenia lub zmiany, a reguła może mieć kilka statusów jednocześnie. W pomocy SFOS 23 tabela i widżet zgodnie podają 12 godzin dla Unused. Dokładny czas zmiany statusu trzeba sprawdzić w używanym buildzie.

Przedziały czasowe mogą się nakładać: reguła utworzona o 10:00 pozostaje New do 10:00 następnego dnia. Zmiana o 11:00 powoduje status Changed do 11:00 następnego dnia; między 11:00 a następną 10:00 reguła ma oba statusy. Status Unused stwierdzony podczas codziennego sprawdzania o 12:00 pozostaje do następnego sprawdzenia. Jeśli reguła zostanie wyłączona o 13:00, może mieć jednocześnie statusy Changed i Disabled do 13:00 następnego dnia, a następnie tylko Disabled. Te przykłady z dokumentacji nie zastępują ani sprawdzenia rzeczywistego użycia, ani decyzji o usunięciu. Przed Reset data transfer count udokumentuj bieżącą wartość: resetowanie nie przywraca wcześniejszego stanu licznika i nie zmienia uprawnień wynikających z reguły.

Active firewall rules pokazuje reguły według typu i statusu oraz pasujący do nich ruch w bajtach z ostatnich 24 godzin. Kafelek rozróżnia WAF (Webserver Protection), User (z użytkownikami lub grupami) i Network (bez tych kryteriów). Scanned oznacza całkowitą liczbę reguł na wykresie, a nie liczbę reguł, dla których ruch jest skanowany pod kątem złośliwego oprogramowania. Disabled oznacza regułę skonfigurowaną, ale wyłączoną; wyłączona reguła może jednocześnie mieć status Changed. Po najechaniu kursorem można sprawdzić ilość danych; kliknięcie liczby lub statusu otwiera odpowiednio przefiltrowaną tabelę reguł.

Widżet w Control Center jest widoczny dla wszystkich administratorów, niezależnie od ich uprawnień. Jego widoczność nie potwierdza zatem prawa zapisu na właściwej stronie reguł. Informacje te należy oceniać wraz z logami, opisem reguły i przypadkiem użycia. Do oceny ilości przesłanych danych można dodatkowo użyć Reports > Dashboards > Traffic dashboard > Allowed policies. Jeśli oczekiwanej reguły nie ma w tabeli, należy najpierw zresetować aktywny filtr; pomoc SFOS 22 ogranicza też działania grupowe w widoku filtrowanym.

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 Sophos Fusion 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.