Zrozumieć i konfigurować reguły Sophos Firewall

Firewall Rules są sercem Sophos Firewall. Decydują, jaki ruch między strefami, sieciami, użytkownikami i usługami jest dozwolony lub blokowany oraz jakie funkcje ochronne są stosowane.

Ten artykuł wyjaśnia Sophos Firewall Rule od góry do dołu: kolejność, grupy, Action, logging, Source, Destination, Services, User Matching, Exclusions, NAT, Web Filtering, TLS Inspection, Security Heartbeat, Application Control, IPS, Traffic Shaping, DSCP, NDR i skanowanie poczty.

Ścieżka menu:

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

Szybka nawigacja

• Podstawowa zasada i kolejność
• Przykład praktyczny
• Górna część: status, nazwa, akcja i logging
• Source
• Destination and services
• Match known users
• Add exclusion
• Create linked NAT rule
• Web filtering
• Synchronized Security Heartbeat
• Other security features
• Scan email content
• Kontrola po zapisaniu
• Typowe błędy

Podstawowa zasada i kolejność

Firewall Rules kontrolują ruch między strefami i sieciami. Mogą zezwalać na ruch, odrzucać go po cichu lub blokować oraz stosować dodatkowe Security Features.

Sophos Firewall sprawdza Firewall Rules od góry do dołu. Gdy tylko reguła pasuje, kolejne reguły nie są już sprawdzane. Ważne jest więc nie tylko to, co znajduje się w regule, ale również jej pozycja na liście.

Reguła pasuje tylko wtedy, gdy wszystkie istotne kryteria pasują jednocześnie:

Wygrywa pierwsza pasująca reguła. Jeśli ogólna reguła LAN_to_WAN_Any znajduje się nad bardziej szczegółową LAN_to_WAN_Restricted, reguła szczegółowa nigdy nie zostanie osiągnięta.

Przykład praktyczny

W tym przykładzie tworzona jest przejrzysta reguła dla klientów:

Cel: klienci z wewnętrznej sieci LAN mogą korzystać z Internetu. Web Filtering, Application Control, IPS i logging mają być aktywne. Serwery, goście i sieci management mają własne reguły i nie są mieszane z tą regułą kliencką.

Ten przykład celowo nie jest przepustką Any. W praktyce sieci klienckie, serwerowe, Wi-Fi dla gości, VoIP i management należy traktować oddzielnie.

Górna część: status, nazwa, akcja i logging

Rule status

Rule status włącza lub wyłącza regułę.

Nowa reguła jest zazwyczaj aktywna. Reguły przygotowane wcześniej można wyłączyć i aktywować dopiero później. Wyłączone reguły należy regularnie sprawdzać, aby stare reguły testowe lub migracyjne nie pozostały w konfiguracji.

Przykład praktyczny: nowa reguła dla serwera jest przygotowana, ale zostaje aktywowana dopiero w oknie serwisowym.

Rule name

Nazwa powinna od razu pokazywać, co robi reguła.

Dobre nazwy:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Nazwy takie jak Rule1, Test, Allow lub Internet są mniej pomocne, bo później nie wiadomo już, do czego reguła służy.

Description

Opis jest ważny dla administracji, supportu i audytów. Powinien zawierać:

• dlaczego reguła istnieje
• kto ją zamówił
• jakie ograniczenia ustawiono świadomie
• czy istnieje ticket, projekt lub data wygaśnięcia

Przykład:

Internet Access for client network 10.10.10.0/24. Web filtering and IPS enabled. Requested by IT, reviewed on 10 June 2026.

Artykuł Jak łatwo dokumentować regułę Sophos Firewall opisuje dokładniej, jak używać tego pola i dokumentować Firewall Rules w sposób możliwy do odtworzenia.

Rule position

Rule position określa, gdzie zostanie wstawiona nowa reguła.

Zasada podstawowa: szczegółowe przed ogólnym. Reguła dla pojedynczego serwera lub konkretnej aplikacji zwykle znajduje się wyżej niż ogólna reguła internetowa.

Rule group

Rule group to grupowanie organizacyjne. Sama grupa nie jest granicą bezpieczeństwa ani osobnym policy engine. Firewall nadal sprawdza pojedyncze reguły od góry do dołu.

Przydatne grupy:

• Internet Access
• Server Rules
• DNAT
• VPN
• Guest
• Management
• Block Rules

W małych środowiskach None może wystarczyć. W większych warto od początku utrzymywać jasne grupowanie, bo baza reguł szybko staje się nieczytelna.

Action

Action określa, co dzieje się z pasującym ruchem.

Dla normalnych reguł klientów lub serwerów najczęściej używa się Accept. Dla reguł blokujących Drop jest cichszy, a Reject bywa wygodniejszy podczas troubleshooting.

Log firewall traffic

Log firewall traffic powinno być aktywne przy prawie wszystkich ważnych regułach.

Bez logowania w Log viewer brakuje później kluczowych informacji. Wiele przypadków troubleshooting nie kończy się sukcesem nie dlatego, że reguła jest błędna, ale dlatego, że logging nie był aktywny i nie widać, która reguła faktycznie zadziałała.

Ważne: firewall zazwyczaj loguje sesje Firewall, gdy połączenie się kończy i powstaje zdarzenie Destroy. Nie każde połączenie pojawia się dokładnie w momencie jego rozpoczęcia przez klienta.

Aby logi były widoczne lokalnie, w Sophos Central lub przez syslog, System services > Log settings również musi być poprawnie skonfigurowane. Do dłuższego przechowywania przydatne jest Sophos Central Firewall Reporting albo serwer syslog. Więcej informacji: Aktywacja Central Firewall Reporting.

Source

Sekcja Source określa, skąd pochodzi ruch.

Source zones

Source zones to strefa, z której pochodzi ruch.

Przykłady:

• LAN dla wewnętrznych sieci klientów
• VPN dla użytkowników Remote Access
• DMZ dla sieci serwerów
• Guest dla Wi-Fi gości
• WAN dla ruchu przychodzącego z Internetu

Przykład praktyczny: dla reguły internetowej klientów wybiera się LAN. Dla reguły DNAT z zewnątrz do serwera wewnętrznego powiązana Firewall Rule zwykle używa WAN jako Source zone.

Source networks and devices

Source networks and devices dokładniej ogranicza źródło.

Możliwe obiekty:

• pojedyncze hosty
• sieci
• IP ranges
• grupy hostów
• FQDN Hosts
• obiekty krajów

Na początku Any wydaje się wygodne, ale często jest zbyt szerokie. Lepsza jest konkretna sieć klientów, grupa hostów albo jasno nazwana sieć.

Przykład praktyczny: zamiast Any jako Source używa się net_LAN_Clients. Serwery, drukarki, goście i urządzenia management mają własne reguły.

During scheduled time

During scheduled time określa, kiedy reguła obowiązuje.

Typowe wartości:

• All the time
• godziny pracy
• okna serwisowe
• tymczasowy dostęp

Schedules są przydatne, gdy dostęp ma być dozwolony tylko w określonych godzinach. Podczas troubleshooting zawsze trzeba sprawdzić, czy czas firewalla, strefa czasowa i schedule naprawdę pasują.

Przykład praktyczny: zewnętrzny dostęp serwisowy do serwera jest dozwolony tylko w zdefiniowanym oknie serwisowym.

Destination and services

Sekcja Destination and services określa, dokąd ruch może iść oraz jakie porty lub protokoły są dozwolone.

Destination zones

Destination zones to strefa docelowa.

Przykłady:

• WAN dla dostępu do Internetu
• DMZ dla serwerów w DMZ
• LAN dla celów wewnętrznych
• VPN dla użytkowników zdalnych lub tuneli Site-to-Site

Przykład praktyczny: dla ruchu klientów do Internetu używa się WAN. Dla dostępu klientów do serwera wewnętrznego można użyć Server lub DMZ, jeśli takie strefy istnieją.

Destination networks

Destination networks dokładniej ogranicza cel.

Dla reguł klientów do Internetu Any często jest praktycznym początkiem. Przy serwerach, sieciach management lub dostępach VPN cele powinny być ograniczone znacznie mocniej.

Przykłady:

• Any dla ogólnego dostępu do Internetu
• FQDN Host, na przykład updates.vendor.com
• obiekt hosta serwera wewnętrznego
• obiekt sieci lokalizacji zdalnej przez VPN
• obiekt kraju dla reguł Geo-IP

Przykład praktyczny: serwer backupu może łączyć się tylko z celami cloud backup producenta, a nie z Any.

Services

Services to definicje protokołów i portów.

Przykłady:

• HTTP dla TCP 80
• HTTPS dla TCP 443
• DNS dla TCP/UDP 53
• NTP dla UDP 123
• własne services, np. Synology_5555

Services należy wybierać możliwie wąsko. Any ma sens tylko wtedy, gdy naprawdę wszystkie protokoły muszą być dozwolone albo gdy świadomie stosowane są inne kontrole.

Przykład praktyczny: dla zwykłych klientów web często wystarczy grupa z HTTP, HTTPS, DNS i NTP. Przy dostępie do serwera z Internetu dozwolony jest tylko faktycznie publikowany service.

Match known users

Przez Match known users tożsamość użytkownika staje się częścią dopasowania. Reguła nie działa już tylko na adresy IP, ale na znanych użytkowników lub grupy.

To przydatne, gdy:

• Web Policies mają działać per grupa AD
• reporting ma być użytkownikowy
• różne grupy użytkowników mają różne prawa do Internetu
• MFA, Captive Portal lub SSO są już poprawnie skonfigurowane

Pułapka: jeśli uwierzytelnianie nie działa poprawnie, reguła może nie pasować. Ruch spadnie wtedy na ogólniejszą regułę poniżej albo zostanie odrzucony przez regułę drop-all.

Do pierwszych testów często lepiej zacząć bez User Matching i dodać kryteria użytkowników później.

Add exclusion

Przez Add exclusion można wyłączyć część ruchu z reguły. Firewall pomija tę regułę tylko wtedy, gdy wszystkie ustawione kryteria exclusion pasują, a następnie sprawdza kolejną regułę.

Exclusions mogą zawierać Source zones, Source networks and devices, Destination zones, Destination networks i Services.

Przykład praktyczny: ogólna reguła internetowa klientów używa Web Filtering. Konkretny serwer aktualizacji ma jednak przechodzić przez osobną regułę z innymi Security Features. Taki serwer można wyłączyć z reguły ogólnej.

Exclusions są mocne, ale utrudniają czytanie reguł. Jeśli reguła ma wiele wyjątków, osobna szczegółowa reguła jest często bardziej zrozumiała.

Create linked NAT rule

Przez Create linked NAT rule można utworzyć regułę Source NAT bezpośrednio z Firewall Rule. Ta Linked NAT Rule pojawia się następnie w tabeli NAT.

Dla początkujących brzmi to wygodnie, ale w praktyce samodzielne reguły NAT są zwykle czytelniejsze. Jeśli istniejąca ogólna reguła NAT prawidłowo obejmuje ten sam ruch, nie należy tworzyć dodatkowej Linked NAT Rule.

Dla zwykłej reguły klient-do-Internetu zazwyczaj wystarcza domyślna reguła SNAT z MASQ, o ile jest aktywna i pasuje do bazy reguł.

Ważne: NAT sam w sobie nie zezwala na ruch. NAT tłumaczy adresy lub porty. O tym, czy ruch jest dozwolony, nadal decyduje pasująca Firewall Rule.

Więcej informacji: Zrozumieć NAT w Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Web filtering

W sekcji Web filtering konfiguruje się Web Policy, malware scan i zachowanie webfilteringu.

Web policy

Web policy steruje dostępem web przez kategorie, użytkowników, grupy, URL groups i reguły.

Przykład praktyczny: dla klientów stosowana jest Web Policy, która blokuje malware, phishing, adult content i ryzykowne kategorie, ale pozwala na aplikacje biznesowe.

Jeśli żadna Web Policy nie jest ustawiona, ta opcja nie stosuje webfilteringu opartego na kategoriach.

Apply web category-based traffic shaping

Ta opcja stosuje Traffic Shaping na podstawie kategorii web. Ma sens tylko wtedy, gdy używane są odpowiednie reguły Traffic Shaping albo Web Category Policies.

Przykład praktyczny: kategorie streaming są limitowane, a aplikacje biznesowe pozostają priorytetowe.

Block QUIC protocol

QUIC używa UDP 80 i UDP 443. Wiele przeglądarek używa QUIC dla usług Google i innych nowoczesnych aplikacji web.

Jeśli Web Filtering albo Malware Scan ruchu web jest ważny, Block QUIC protocol w wielu środowiskach powinien pozostać aktywny. Przeglądarki zwykle wracają wtedy do normalnego HTTPS przez TCP, który łatwiej kontrolować i analizować.

Scan HTTP and decrypted HTTPS

Ta opcja skanuje HTTP i już odszyfrowany HTTPS pod kątem malware.

Ważne: ta opcja nie odszyfrowuje HTTPS automatycznie. Aby naprawdę analizować HTTPS, potrzebne są pasujące SSL/TLS inspection rules w Rules and policies > SSL/TLS inspection rules.

Przykład praktyczny: jeśli TLS Inspection jest aktywny dla LAN_to_WAN_Clients, Scan HTTP and decrypted HTTPS może sprawdzać pobierane pliki w odszyfrowanym ruchu HTTPS.

Więcej informacji: Wdrażanie TLS Inspection na Sophos Firewall krok po kroku.

Use Zero-day protection

Use Zero-day protection wysyła podejrzane pobrania do Sophos Zero-Day Protection w celu dalszej analizy. To przydatne dla reguł klientów i serwerów, w których pobrania z Internetu mają być sprawdzane.

Funkcja wymaga odpowiedniej licencji i w zależności od typu pliku oraz policy może powodować opóźnienia.

Scan FTP for malware

Ta opcja skanuje ruch FTP pod kątem malware. Jest istotna tylko wtedy, gdy FTP faktycznie jest używany i odpowiednie Services są dozwolone w regule.

W nowoczesnych środowiskach FTP występuje rzadziej, ale nadal pojawia się przy systemach legacy, sterowaniu maszynami lub starszych mechanizmach aktualizacji.

Use web proxy instead of DPI engine

Sophos Firewall może sprawdzać ruch web przez DPI engine albo Web Proxy.

Dla nowoczesnych konfiguracji DPI jest zwykle lepszym wyborem domyślnym, bo ruch HTTP i SSL/TLS może być przetwarzany na wszystkich portach. Web Proxy nadal ma sens, gdy potrzebne są specjalne funkcje proxy, np. SafeSearch enforcement, ograniczenia YouTube, Google app domain restriction, Pharming Protection, Web Cache lub Parent Proxy.

Jeśli Use web proxy instead of DPI engine nie jest aktywne, reguła działa w trybie DPI.

Decrypt HTTPS during web proxy filtering

Ta opcja należy do trybu Web Proxy. Jest istotna tylko wtedy, gdy Use web proxy instead of DPI engine jest aktywne i HTTPS ma być odszyfrowywany w trybie proxy.

W trybie DPI odszyfrowanie HTTPS nie jest sterowane tutaj, lecz przez SSL/TLS inspection rules.

Synchronized Security Heartbeat

Przez Configure Synchronized Security Heartbeat status Sophos Endpoint może zostać uwzględniony w Firewall Rule.

Typowe możliwości:

• ustawienie minimalnego statusu dla urządzeń źródłowych
• blokowanie klientów bez Heartbeat
• ustawienie minimalnego statusu dla urządzeń docelowych
• blokowanie żądań do celów bez Heartbeat

To mocna funkcja, ale sensowna tylko wtedy, gdy Sophos Endpoint, Sophos Central i Security Heartbeat są poprawnie skonfigurowane.

Przykład praktyczny: klienci z czerwonym Security Heartbeat nie mogą już uzyskać dostępu do serwerów ani do Internetu.

Dla pierwszej reguły klientów nie należy włączać Heartbeat bez analizy, bo można zablokować urządzenia, które nie mogą wysyłać Heartbeat.

Other security features

Identify and control applications (App control)

Przez Identify and control applications (App control) wybiera się Application Filter Policy.

Pozwala to rozpoznawać i kontrolować aplikacje, np.:

• TeamViewer
• Tor
• Messenger
• Streaming
• Cloud Storage
• Remote-Control-Tools

Application Control wymaga odpowiedniej licencji. W praktyce funkcja jest zawarta w Sophos Firewall Bundles z Web Protection, np. Standard Protection, Xstream Protection lub Epic Protection.

Dla rozpoznawania aplikacji w ruchu szyfrowanym TLS Inspection jest często kluczowe. Bez decryption firewall widzi zależnie od usługi tylko hostnames, SNI, informacje certyfikatu albo IPs, ale nie pełną zawartość.

Apply application-based traffic shaping policy

Ta opcja stosuje Traffic Shaping zdefiniowany w Application Policy albo przy Application Object.

Przykład praktyczny: Microsoft Teams ma być rozpoznawany i priorytetyzowany określoną Traffic Shaping Policy. Musi być wybrana właściwa Application Control Policy i zastosowana application-based traffic shaping policy.

Jeśli w Shape traffic ustawiono już jawną Traffic Shaping Policy, należy jasno udokumentować, która policy ma pierwszeństwo i dlaczego.

Detect and prevent exploits (IPS)

W Detect and prevent exploits (IPS) wybiera się IPS Policy.

IPS sprawdza ruch pod kątem znanych wzorców ataków i exploitów. Ruch klientów do Internetu używa innej policy niż ruch serwerów lub opublikowane usługi.

Przykłady praktyczne:

• reguła klienta LAN_to_WAN: IPS policy dla klientów albo LAN-to-WAN
• reguła DNAT do webservera: IPS policy serwera albo webservera
• reguła VoIP: testować ostrożnie, bo agresywne profile IPS mogą zakłócać VoIP

IPS nie powinien być po prostu włączany wszędzie z najostrzejszą policy. Zbyt szeroka lub błędna IPS Policy może przerwać legalny ruch albo generować niepotrzebne obciążenie.

Shape traffic

Przez Shape traffic można bezpośrednio zastosować Traffic Shaping Policy do reguły.

Jest to istotne dla:

• VoIP
• wideokonferencji
• ruchu backupu
• Wi-Fi dla gości
• wolnych łączy WAN

Przykład praktyczny: Wi-Fi dla gości otrzymuje limit policy, aby nie wypierać ruchu biznesowego.

Więcej informacji: Konfiguracja Application Traffic Shaping na Sophos Firewall.

DSCP marking

DSCP marking oznacza pakiety dla Quality of Service na kolejnych urządzeniach sieciowych.

Ma to sens tylko wtedy, gdy przełączniki, routery albo urządzenia WAN również oceniają te wartości DSCP. Sophos Firewall może oznaczać pakiety, ale reszta sieci musi traktować te oznaczenia spójnie.

Przykład praktyczny: ruch VoIP otrzymuje oznaczenie DSCP, aby przełączniki i routery WAN traktowały go priorytetowo.

Scan with NDR Active threat intelligence

Scan with NDR Active threat intelligence używa Sophos NDR Threat Intelligence do dodatkowej oceny ruchu sieciowego.

Ta opcja ma sens tylko wtedy, gdy środowisko używa wymaganych komponentów Sophos Central i NDR. W wielu środowiskach nie jest to pierwsza opcja dla reguły bazowej, ale w silniej monitorowanych sieciach może być wartościowym dodatkiem.

Scan email content

Sekcja Scan email content dotyczy protokołów e-mail.

Możliwe opcje:

• Scan IMAP
• Scan IMAPS
• Scan POP3
• Scan POP3S
• Scan SMTP
• Scan SMTPS

Jeśli protokoły są tu aktywowane, odpowiednie standardowe porty muszą znajdować się również w Services reguły albo zostać dodane przez Add ports.

Dla zwykłych reguł web klientów ta sekcja często nie jest istotna. Dla mailserverów albo ruchu poczty klientów należy ją świadomie zaplanować.

Przykład praktyczny: wewnętrzny mailserver może wysyłać SMTP na zewnątrz. Tworzona jest osobna reguła serwera, włączany logging i sprawdzane e-mail scanning zgodnie z architekturą poczty.

Kontrola po zapisaniu

Po zapisaniu regułę należy przetestować, zamiast zakładać, że wszystko działa poprawnie.

Sprawdzić:

1. Czy reguła jest na właściwej pozycji?
2. Czy Log firewall traffic jest aktywne?
3. Czy reguła matchuje w Log viewer?
4. Czy wyświetlana jest oczekiwana Firewall Rule ID?
5. Czy działa oczekiwana reguła NAT?
6. Czy DNS działa?
7. Czy Web Filtering, IPS, Application Control i TLS Inspection są stosowane zgodnie z oczekiwaniami?
8. Czy są nieoczekiwane drops albo błędy SSL/TLS?

Do czystej weryfikacji pomaga artykuł Testowanie Firewall Rules przez Log Viewer, Policy Test i Packet Capture.

Typowe błędy

Reguła jest zbyt nisko: bardziej ogólna reguła powyżej matchuje ruch jako pierwsza.

Source jest zbyt szerokie: Any może działać, ale sprawia, że reguły są niejasne i zwiększa powierzchnię ataku.

Destination jest zbyt szerokie: serwery lub sieci management rzadko powinny mieć dostęp do Internetu z Any.

Services są zbyt szerokie: Any pozwala na znacznie więcej niż potrzeba. Lepsze są konkretne services lub grupy services.

Logging nie jest aktywny: w Log Viewer brakuje wtedy najważniejszych informacji.

HTTPS nie jest skanowany: Scan HTTP and decrypted HTTPS jest aktywne, ale nie ma pasującej SSL/TLS inspection rule albo nie ma decryption.

Web Filtering nie działa: brak Web Policy, zły użytkownik, zła Source zone albo QUIC nie jest zablokowany.

User Matching nie działa: authentication, AD SSO, Captive Portal albo mapowanie użytkownika nie działa poprawnie.

Brakuje NAT: Firewall Rule zezwala na ruch, ale SNAT/MASQ nie pasuje.

Security Feature nie pasuje do ruchu: błędna IPS Policy, opcja proxy albo opcja e-mail scan może przerwać legalny ruch.