Zrozum i bezpiecznie skonfiguruj reguły Sophos Firewall

Reguły zapory sieciowej stanowią serce Sophos Firewall. Reguły te określają, jaki ruch pomiędzy strefami, sieciami, użytkownikami i usługami jest dozwolony lub blokowany oraz jakie funkcje zabezpieczające są stosowane.

W tym artykule wyjaśniono regułę Sophos Firewall od góry do dołu: Kolejność, Grupy, Akcja, Rejestrowanie, Źródło, Miejsce docelowe, Services, Dopasowywanie użytkowników, Wykluczenia, NAT, Filtrowanie sieci, TLS Inspection, Security Heartbeat, Application Control, IPS, Kształtowanie ruchu, DSCP, NDR i e-mail skanowanie.

Ścieżka menu to:

Rules and policies > Reguły zapory > Dodaj regułę zapory > Nowa reguła zapory

Maska reguł jest podzielona na kilka obszarów: obszar nagłówka, źródło, miejsce docelowe, Services, referencje użytkownika, łącze NAT i funkcje bezpieczeństwa. W praktyce ważne jest, aby nie postrzegać maski jako zbioru pojedynczych haczyków. Reguła działa poprawnie tylko wtedy, gdy źródło, miejsce docelowe, usługa, sekwencja, rejestrowanie i aktywowane funkcje zabezpieczające są zgodne.

Przed jej utworzeniem powinno być również jasne, czy jest to reguła IPv4, czy IPv6. Widok reguł jest odpowiednio wybrany w WebAdmin. W środowiskach z dwoma stosami protokoły IPv4 i IPv6 muszą być celowo planowane i testowane oddzielnie; działająca reguła IPv4 nie dowodzi automatycznie, że protokół IPv6 jest równie bezpieczny.

Szybka nawigacja

• Jakie reguły zapory sieciowej kontrolują, a czego nie
• Podstawowa zasada i sekwencja
• Zaplanuj bazę reguł przed utworzeniem
• Wyraźnie oddziel typy reguł
• Fikcyjny przykład praktyczny
• Obszar nagłówka: Stan, nazwa, akcja i rejestrowanie
• Źródło, strefa i harmonogram
• Miejsca docelowe i usługi
• Match known users
• Dodaj wykluczenie
• Create linked NAT rule
• Filtrowanie sieci
• Bicie serca Synchronized Security
• Inne funkcje bezpieczeństwa
• Skanuj treść e-maili
• Sprawdź po zapisaniu
• Regularna praca i przegląd
• Nowa reguła, zmienić lub wyłączyć istniejącą regułę?
• Typowe błędy
• FAQ

Który artykuł zasad sieciowych pasuje?

Reguły zapory sieciowej, NAT, WAF, VLAN i routing są ze sobą ściśle powiązane w Sophos Firewall. Dlatego ważne jest, aby administratorzy najpierw wybrali odpowiedni temat:

• Zrozumienie reguły zapory ogniowej od podstaw: Ten artykuł.
• Klasyfikuj NAT, SNAT, DNAT, MASQ lub PAT: Zrozumienie NAT w Sophos Firewall: SNAT, DNAT, MASQ, PAT
• Publikuj serwer wewnętrzny poprzez przekierowanie portów: Publikuj serwer poprzez DNAT do Sophos Firewall
• Zabezpieczanie publicznej aplikacji internetowej: Sophos Firewall Konfigurowanie i organizowanie WAF
• Reguła nie ma zastosowania lub pojawia się nieprawidłowy Rule ID: Sophos Firewall Reguła nie ma zastosowania: sprawdź przyczyny
• Testuj konkretnie regułę: Testuj regułę zapory sieciowej z Log Viewer, Policy Test i Packet Capture
• WebAdmin, VPN Portal, User Portal, SSH, bezpieczny DNS lub SNMP firewalla: Sophos Firewall Zabezpieczanie dostępu: Skonfiguruj poprawnie Device Access
• Planuj strefy, interfejsy lub VLAN: Sophos Firewall Konfiguruj strefy i interfejsy
• Obsługuj most za pomocą znaczników VLAN: Użyj mostka Sophos Firewall ze znacznikiem VLAN
• Sprawdź kolejność routingu lub ścieżki SD-WAN: Sophos Firewall Dostosuj priorytet routingu
• Pakiety odpowiedzi lub ruch systemowy idą niewłaściwą ścieżką: SD-WAN Routing pakietów odpowiedzi i ruchu systemowego

To oddzielenie zapobiega typowym rozwiązywaniu problemów. Reguła NAT nie zezwala na ruch, reguła zapory nie tłumaczy adresu, a reguła WAF to nie to samo, co zwykłe przekierowywanie portów DNAT.

Jakie reguły zapory sieciowej kontrolują, a czego nie

Reguły zapory kontrolują ruch przepływający przez zaporę. Ale te zasady nie są jedynym punktem kontrolnym w SFOS. Wiele problemów pojawia się, gdy szukasz zachowania na liście reguł zapory sieciowej, mimo że odpowiedzialny jest za to inny obszar.

• Ruch pomiędzy strefami, sieciami, użytkownikami i usługami: Reguły zapory. Tutaj decyduje się, czy ruch tranzytowy jest dozwolony, odrzucany czy sprawdzany za pomocą zabezpieczeń.
• WebAdmin, User Portal, VPN Portal, SSH, DNS lub SNMP do samego firewalla: Device Access i Local Service ACL. Lokalne usługi zapory sieciowej nie są traktowane jak normalny ruch LAN-to-WAN lub WAN-to-DMZ.
• Tłumaczenie adresu lub portu: Zasady NAT. NAT tłumaczy ruch, ale nie pozwala na to automatycznie.
• Wybór trasy, trasa powrotna, ścieżki SD-WAN i VPN: Routing, konfiguracja SD-WAN, Route Precedence i VPN. Odpowiednia reguła zapory sieciowej nie jest skuteczną metodą powrotu.
• Kategorie internetowe, grupy adresów URL i zasady sieciowe: Filtrowanie sieci i polityka sieciowa. Reguła zapory integruje zasady, ale rzeczywista logika sieciowa leży w zasadach sieciowych.
• Odszyfrowanie HTTPS: Zasady inspekcji SSL/TLS i dystrybucja CA. Scan HTTP and decrypted HTTPS skanuje tylko ruch, który został już odszyfrowany.
• Tożsamość użytkownika: Uwierzytelnianie, STAS, portal przechwytujący, Entra ID SSO lub RADIUS. Reguła użytkownika pasuje tylko wtedy, gdy zapora może przypisać użytkownika do ruchu.

W przypadku usług zarządzania i portali artykułem centralnym jest Device Access i Local Service ACL. Jeśli reguła pasuje, ale połączenie nadal nie działa, pomocne będą Sophos Firewall Reguła nie działa: sprawdź przyczyny i Przetestuj regułę zapory sieciowej za pomocą Log Viewer, Policy Test i Packet Capture.Szczególnie w przypadku mieszanych sieci IPv4/IPv6 należy również sprawdzić, czy aplikacja korzystająca z protokołu IPv6 omija bardziej rygorystyczną regułę IPv4. Jeżeli protokół IPv6 nie jest aktywnie wykorzystywany, należy mimo wszystko świadomie udokumentować strategię IPv6: dezaktywować, blokować, odpowiednio regulować lub wprowadzać ją w sposób kontrolowany.

Podstawowa zasada i sekwencja

Reguły zapory kontrolują ruch pomiędzy strefami i sieciami. Reguły zezwalają, odrzucają lub blokują ruch i mogą stosować dodatkowe funkcje bezpieczeństwa.

Sophos Firewall sprawdza reguły zapory sieciowej od góry do dołu. Gdy tylko reguła zostanie dopasowana, kolejne reguły zapory sieciowej nie będą już sprawdzane. Ważne jest nie tylko to, co znajduje się w regule, ale także gdzie to się znajduje na liście reguł.

Reguła ma zastosowanie tylko wtedy, gdy wszystkie istotne kryteria mają zastosowanie jednocześnie:

• Strefa źródłowa: Tak. LAN.
• Source networks and devices: Tak. net_LAN_Clients.
• Harmonogram: Tak. All the time.
• Strefa docelowa: Tak. WAN.
• Destination networks: Tak. Any lub host FQDN.
• Services: Tak. HTTP, HTTPS, DNS.
• Dopasowanie użytkownika: Tylko jeśli aktywowano. AD grupa Internet-Users.
• Wyłączenia: Jeśli jest ustawiona, regułę można pominąć. Wyklucz serwer zapasowy.

Pierwsza pasująca reguła wygrywa. Jeśli ogólna reguła LAN_to_WAN_Any jest powyżej konkretnej reguły LAN_to_WAN_Restricted, konkretna reguła nigdy nie zostanie osiągnięta.

Zaplanuj bazę reguł przed utworzeniem

Można szybko utworzyć pojedynczą regułę zapory sieciowej. Trudniejsza jest baza reguł, która po dwóch latach jest nadal zrozumiała, testowalna i bezpieczna. Dlatego przed wprowadzeniem nowych reguł należy najpierw wyjaśnić, do której strefy bezpieczeństwa, grupy i logiki działania należy dana reguła.

Pomocne pytania pomocnicze:

• Jaki rodzaj ruchu naprawdę powinien być dozwolony?: Przed utworzeniem zanotuj źródło, miejsce docelowe i Services.
• Czy ruch należy do własnej strefy?: Świadomie oddzielaj serwery, klientów, gości, zarządzanie, VPN i DMZ.
• Czy jest już jakiś konkretny przepis?: Sprawdź istniejące reguły, zamiast tworzyć drugą podobną regułę.
• Czy NAT jest w to zaangażowany?: Zaplanuj razem reguły zapory sieciowej i reguły NAT, ale nie mieszaj ich.
• Jak to będzie później sprawdzane?: Aktywuj logowanie i zdefiniuj konkretny ruch testowy.
• Czy zwolnienie jest tymczasowe?: Udokumentuj datę ważności lub bilet w opisie.

W przypadku czystych stref i interfejsów na początek pasuje Sophos Firewall Konfiguruj strefy i interfejsy. Jeśli istniejąca reguła nie działa, pomocna będzie lista kontrolna Sophos Firewall Reguła nie działa: Sprawdź przyczyny.

⚠️ Szeroka reguła Any jest często wygodna, ale rzadko stanowi dobrą końcową konfigurację. Może pomóc na krótką metę w testach. Należy go wówczas zastąpić lub ponownie usunąć określonymi źródłami, miejscami docelowymi i usługami.

Wyraźnie oddzielaj typy reguł

Dobra baza reguł w widoczny sposób oddziela od siebie różne ryzyka. Najczęstszym błędem nie jest pojedyncza niepoprawna opcja, ale ogólna zasada, która obejmuje jednocześnie klientów, serwery, VPN, gości i kierownictwo. Na początku działa to szybko, ale później staje się trudne do przetestowania i trudne do utwardzenia.

• Internet klienta: Typowe źródło: Sieci klienckie; Typowy cel: WAN; Na co zwrócić uwagę?: Polityka internetowa, Application Control, IPS, TLS Inspection, QUIC, Rejestrowanie.
• Serwer internetowy: Typowe źródło: Sieci serwerów; Typowy cel: zdefiniowane cele aktualizacji, kopii zapasowych lub chmury; Na co zwrócić uwagę?: bardziej rygorystyczne niż zasady klienta, często bez odniesienia do użytkownika.
• Gość-WLAN: Typowe źródło: Strefa Gościa; Typowy cel: WAN; Na co zwrócić uwagę?: brak świadomej kontroli celów wewnętrznych, przepustowości i DNS.
• Zarządzanie: Typowe źródło: Sieci administracyjne; Typowy cel: Firewall, serwery, przełączniki, hypervisory; Na co zwrócić uwagę?: nie mieszaj ze zwykłymi zasadami klienta.
• VPN Zdalny dostęp: Typowe źródło: VPN lub własna strefa zdalnego dostępu; Typowy cel: wewnętrzne strefy docelowe; Na co zwrócić uwagę?: tylko wymagane cele i usługi, logowanie w fazie wstępnej.
• Strona do witryny: Typowe źródło: strefy lokalne i zdalne VPN lub strefy XFRM; Typowy cel: Sieci partnerskie lub lokalizacyjne; Na co zwrócić uwagę?: Sprawdź routing, NAT, ścieżkę zwrotną i logowanie razem.
• Opublikowany system: Typowe źródło: WAN lub zdefiniowane źródła; Typowy cel: DMZ lub strefa serwera; Na co zwrócić uwagę?: DNAT/WAF, IPS, rejestrowanie, poziom poprawki i ograniczanie źródła.
• Dostęp tymczasowy: Typowe źródło: zdefiniowane źródło wsparcia lub projektu; Typowy cel: wąski cel; Na co zwrócić uwagę?: Dokument biletowy, data ważności, właściciel i demontaż.

Jeśli dwa połączenia mają różnych właścicieli, funkcje zabezpieczające lub cykle przeglądów, oddzielne reguły są zwykle czystsze. Jeśli do tego samego celu zawodowego wymagana jest tylko dodatkowa usługa, istniejącą regułę można rozszerzyć.

Fikcyjny przykład praktyczny

Jako przykład tworzona jest reguła czystego klienta:

Cel: Klienci z wewnętrznego LAN mogą uzyskać dostęp do Internetu. Filtr sieciowy, Application Control, IPS i logowanie powinny być aktywne. Serwery, goście i sieci zarządzające otrzymują własne reguły i nie są mieszane z tą regułą klienta.

• Nazwa reguły: LAN_to_WAN_Clients. Wyczyść nazwę ze źródłem i miejscem docelowym.
• Opis: Internet Access für Client-Netz, erstellt für Standard-Client-Traffic. Później dowiesz się dlaczego ta reguła istnieje.
• Rule position: Zgodnie z określonymi regułami blokowymi i serwerowymi. Najpierw powinny wejść w życie szczegółowe zasady.
• Rule group: Internet Access. Lepszy przegląd.
• Akcja: Accept. Ruch jest dozwolony.
• Rejestruj ruch zapory: Włączone. Rozwiązywanie problemów z Log Viewer.
• Source zones: LAN. Ruch pochodzi ze strefy LAN.
• Source networks and devices: net_LAN_Clients. Nie wszystkie sieci LAN, tylko klienci.
• W zaplanowanym czasie: All the time. Dostęp do Internetu powinien być stały.
• Destination zones: WAN. Celem jest Internet.
• Destination networks: Any. Przeważnie praktyczne w przypadku Internetu klienckiego.
• Services: HTTP, HTTPS, DNS, NTP. Wymagane tylko podstawowe usługi.
• Web policy: Default Workplace Policy. Kontroluj dostęp do sieci na podstawie kategorii.
• Block QUIC protocol: Włączone. Filtrowanie i skanowanie sieci pozostają skuteczne.
• IPS: Polityka klienta. Ochrona przed exploitami dla wychodzącego ruchu klientów.
• Kontrola aplikacji: Polityka aplikacji klienckich. Blokuj niechciane aplikacje.
• Kształtuj ruch: Opcjonalne. Tylko jeśli wymagana jest przepustowość.
• DSCP marking: Pusty. Konieczne tylko wtedy, gdy urządzenia znajdujące się dalej oceniają DSCP.

Ten przykład celowo nie jest bezpłatnym biletem Any. W praktyce sieci klienckie, sieci serwerów, sieci gościnne, VoIP i zarządzanie należy rozpatrywać oddzielnie. W przypadku pierwszego testu produktywnego przykład ten powinien obejmować krótki przypadek testowy: zdefiniowany klient, konkretny adres docelowy, oczekiwany Rule ID, oczekiwany NAT Rule ID i spojrzenie na Log Viewer lub Central/Syslog. Bez tego etapu zatwierdzania nie jest jasne, czy reguła faktycznie przetwarza oczekiwane połączenie.

Obszar nagłówka: Stan, nazwa, akcja i rejestrowanie

Stan reguły

Stan reguły aktywuje lub dezaktywuje regułę.

Nowa reguła jest zwykle aktywna. Dla przygotowanych reguł możesz dezaktywować status i aktywować regułę dopiero później. Dezaktywowane reguły należy regularnie sprawdzać, aby w konfiguracji nie pozostały żadne stare reguły testowe lub migracyjne.

Praktyczny przykład: Nowa reguła dla serwera jest przygotowana, ale jest aktywowana dopiero w oknie konserwacji.

Nazwa reguły

Nazwa powinna od razu wyjaśniać, 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, ponieważ nie można już określić, jakie zadanie ma reguła.

Opis

Opis jest ważny dla operacji, wsparcia i audytów. Powinno powiedzieć:

• dlaczego ta reguła istnieje
• który zażądał reguły
• jakie ograniczenia zostały wprowadzone celowo
• czy istnieje bilet, projekt lub data ważności

Przykład:

Internet Access für Client-Netz 10.10.10.0/24. Webfilter und IPS aktiv. Angefordert durch IT, geprüft am 10.06.2026.

Jak prawidłowo wykorzystać to pole i w zrozumiały sposób dokumentować reguły firewalla opisano szerzej w artykule Sophos Firewall sensownie dokumentuje reguły.

Rule position

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

• Top: Tylko dla bardzo szczegółowych reguł, reguł blokowych lub testów.
• Bottom: Często przydatne w przypadku nowych standardowych zasad.
• Above rule: Jeśli reguła musi szczególnie zacząć obowiązywać przed istniejącą regułą.
• Below rule: Jeśli reguła powinna być zgodna z istniejącą regułą.

Podstawowa zasada: szczegół przed ogólnym. Reguła dla pojedynczego serwera lub konkretnej aplikacji jest zwykle wyższa niż ogólna reguła internetowa.

Rule group

Rule group to grupa organizacyjna. Grupa sama w sobie nie stanowi granicy bezpieczeństwa ani własnego mechanizmu polityki. Zapora kontynuuje sprawdzanie każdej reguły od góry do dołu.

Przykłady przydatnych grup obejmują:

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

W małych środowiskach wystarczający może być None. W większych środowiskach warto już na początku wyraźnie grupować, w przeciwnym razie baza reguł szybko stanie się niejasna.

Akcja

Działanie określa, co stanie się z pasującym ruchem.

• Accept: Ruch jest dozwolony. Normalne reguły zezwalające.
• Drop: Ruch jest dyskretnie odrzucany. Blokuj reguły, w których klient nie powinien otrzymać odpowiedzi.
• Reject: Ruch zostaje odrzucony i klient otrzymuje odpowiedź. Rozwiązywanie problemów lub wewnętrzne zasady blokowania.
• Protect with web server protection: Zastosowano zabezpieczenie WAF. Ochrona serwera WWW, nie dla normalnych reguł LAN-to-WAN.

W przypadku normalnych reguł klienta lub serwera zwykle używasz Accept. W przypadku reguł blokowych Drop jest cichszy, Reject jest często przyjemniejszy do rozwiązywania problemów.

Rejestruj ruch zapory sieciowej

Logowanie ruchu zapory powinno prawie zawsze być aktywowane dla ważnych reguł.

Bez logowania ważne informacje będą później niedostępne w Przeglądarce logów. Wiele przypadków rozwiązywania problemów kończy się niepowodzeniem nie z powodu samej reguły, ale dlatego, że nie było rejestrowania i nie można zobaczyć, która reguła została faktycznie zastosowana.

Ważne: Zapora zazwyczaj rejestruje sesje zapory po zakończeniu połączenia i wystąpieniu zdarzenia Destroy. Nie każde połączenie pojawia się dokładnie w momencie jego uruchomienia przez klienta.

Aby logi były widoczne lokalnie, w Sophos Central lub poprzez Syslog, należy także odpowiednio skonfigurować System services > Log settings. W przypadku dłuższego przechowywania sensowne jest raportowanie zapory Sophos Central lub serwer Syslog. Więcej na ten temat: Włącz raportowanie za pomocą centralnej zapory ogniowej i Wyślij bezpiecznie Sophos Firewall Syslog do SIEM.

W przypadku reguł produktywnych rejestrowanie nie powinno być postrzegane tylko jako narzędzie do rozwiązywania problemów. Jest to także podstawa do przeglądów: czy reguła jest nadal stosowana, do jakich źródeł się odnosi, do jakich celów rzeczywiście się odnosi i czy reguła nie jest zbyt szeroka.

Źródło, strefa i harmonogram

W obszarze Źródło określasz, skąd pochodzi ruch.

Source zones

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

Przykłady:

• LAN dla wewnętrznych sieci klienckich
• VPN dla użytkowników zdalnego dostępu
• DMZ dla sieci serwerów
• Guest dla gości - WLAN
• WAN dla przychodzącego ruchu internetowego

Praktyczny przykład: LAN jest wybrany dla reguły internetowej od klientów do Internetu. W przypadku reguły DNAT przesyłanej z serwera zewnętrznego do wewnętrznego, strefa WAN jest zwykle używana jako strefa źródłowa w powiązanej regule zapory sieciowej.

Source networks and devices

Source networks and devices dokładniej zawęża źródło.

Możliwe obiekty to na przykład:

• indywidualni gospodarze
• Sieci
• Zakresy adresów IP
• Grupy gospodarzy
• Hosty FQDN
• Obiekty wiejskie

Na początek Any wydaje się wygodny, jednak często jest za szeroki. Lepsza jest konkretna sieć kliencka, grupa hostów lub wyraźnie nazwany obiekt sieciowy.

Praktyczny przykład: Zamiast Any w źródle użyj net_LAN_Clients. Serwery, drukarki, goście i urządzenia zarządzające mają własne zasady.

W zaplanowanym czasie

W zaplanowanym czasie określa, kiedy reguła ma zastosowanie.

Typowe wartości:

• All the time
• Godziny pracy
• Okno konserwacyjne
• zwolnienia tymczasowe

Harmonogramy są pomocne, jeśli dostęp powinien być dozwolony tylko w określonych godzinach. Podczas rozwiązywania problemów zawsze należy sprawdzić, czy czas, strefa czasowa i harmonogram zapory są rzeczywiście prawidłowe.

Praktyczny przykład: Zewnętrzny dostęp konserwacyjny do serwera jest dozwolony tylko w określonym oknie konserwacyjnym.

Miejsce docelowe i usługi

W obszarze Miejsce docelowe i usługi określasz, gdzie dozwolony jest ruch i jakie porty lub protokoły są dozwolone.

Destination zones

Destination zones to strefa docelowa.

Przykłady:

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

Praktyczny przykład: WAN jest używany do ruchu internetowego klienta. Server lub DMZ można wykorzystać dla klientów w celu uzyskania dostępu do serwera wewnętrznego, jeśli te strefy zostaną odpowiednio utworzone.

Destination networks

Destination networks zawęża cel bardziej precyzyjnie. W przypadku reguł internetowych klienta Any jest często opłacalnym początkiem. W przypadku serwerów, sieci zarządzania lub dostępu VPN cele powinny być znacznie bardziej ograniczone.

Przykłady:

• Any do ogólnego dostępu do Internetu
• Host FQDN, taki jak updates.vendor.com
• Obiekt hosta serwera wewnętrznego
• Obiekt sieciowy stacji zdalnej poprzez VPN
• Obiekt kraju dla reguł Geo-IP

Praktyczny przykład: serwer kopii zapasowych może trafiać wyłącznie do miejsc docelowych kopii zapasowych w chmurze producenta, a nie do Any.

Services

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

Przykłady:

• HTTP dla protokołu TCP 80
• HTTPS dla protokołu TCP 443
• DNS dla protokołu TCP/UDP 53
• NTP dla UDP 123
• własny Services jak Synology_5555

Services należy wybrać możliwie wąsko. Any ma sens tylko wtedy, gdy wszystkie protokoły naprawdę muszą być dozwolone lub jeśli świadomie pracujesz z innymi elementami sterującymi.

Praktyczny przykład: W przypadku zwykłych klientów internetowych często wystarcza grupa zawierająca HTTP, HTTPS, DNS i NTP. Dostęp do serwera z Internetu jest dozwolony tylko dla rzeczywiście opublikowanej usługi.

Match known users

W przypadku Match known users tożsamość użytkownika staje się częścią dopasowania. Reguła nie dotyczy już tylko adresów IP, ale znanych użytkowników lub grup.

Ma to sens, jeśli:

• Zasady sieciowe powinny mieć zastosowanie do każdej grupy AD
• Zgłaszanie powinno być związane z użytkownikiem
• różne grupy użytkowników uzyskują różne uprawnienia internetowe
• MFA, Captive Portal lub SSO są już poprawnie skonfigurowane

Przeszkoda: jeśli uwierzytelnianie nie działa prawidłowo, reguła może nie pasować. Następnie ruch spada do bardziej ogólnej reguły opisanej poniżej lub jest odrzucany zgodnie z regułą “upuść wszystko”.

W przypadku testów początkowych często lepiej jest rozpocząć bez dopasowywania użytkowników i dodać kryteria użytkownika później.

Jeśli stosowane jest dopasowywanie użytkowników, nie powinna istnieć ogólna reguła awaryjna zezwalająca na ten sam ruch bez odniesienia do użytkownika. W przeciwnym razie reguła użytkownika wydaje się czysta, ale nieznani użytkownicy nadal korzystają z ogólnej reguły. Po zaakceptowaniu Log Viewer powinien zatem pokazywać użytkownika, grupę i Rule ID.

Dodaj wykluczenie

Dzięki opcji Dodaj wykluczenie ruch można wykluczyć z reguły. Zapora pomija tę regułę tylko wtedy, gdy wszystkie kryteria wykluczenia są zgodne, a następnie sprawdza następną regułę.

Wyłączenia mogą obejmować Source zones, Source networks and devices, Destination zones, Destination networks i Services.

Praktyczny przykład: Ogólna reguła internetowa klienta wykorzystuje filtry sieciowe. Jednak konkretny serwer aktualizacji powinien uruchamiać własną regułę z innymi funkcjami zabezpieczeń. Następnie możesz wykluczyć ten serwer z ogólnej zasady.

Wykluczenia są potężne, ale sprawiają, że reguły są trudniejsze do odczytania. Jeśli reguła zawiera wiele wyjątków, często bardziej zrozumiała jest osobna reguła.

Create linked NAT rule

Za pomocą Create linked NAT rule można utworzyć źródłową regułę NAT bezpośrednio z reguły zapory sieciowej. Ta połączona reguła NAT pojawi się następnie w tabeli reguł NAT.

Brzmi to wygodnie dla początkujących, ale w praktyce niezależne reguły NAT są zwykle jaśniejsze. Jeśli ogólna reguła NAT obejmuje już ten sam ruch, nie należy tworzyć dodatkowej połączonej reguły NAT.

W przypadku normalnej reguły klient-Internet domyślna reguła SNAT z MASQ jest zwykle wystarczająca, o ile jest aktywna i prawidłowo pasuje do bazy reguł.Ważne: NAT sam w sobie nie przepuszcza ruchu. NAT tłumaczy adresy lub porty. Odpowiednia reguła zapory nadal decyduje, czy ruch jest dozwolony.

Więcej na ten temat: Zrozumienie NAT w Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Filtrowanie sieci

W obszarze Filtrowanie sieci konfigurowane są zasady sieciowe, skanowanie w poszukiwaniu złośliwego oprogramowania i zachowanie filtrów sieciowych.

Web policy

Web policy kontroluje dostęp do sieci poprzez kategorie, użytkowników, grupy, grupy adresów URL i reguły.

Praktyczny przykład: w przypadku klientów stosowana jest polityka sieciowa, która blokuje złośliwe oprogramowanie, phishing, treści dla dorosłych i ryzykowne kategorie, ale zezwala na aplikacje biznesowe.

Jeśli nie ustawiono żadnych zasad sieciowych, za pomocą tej opcji nie będzie stosowane filtrowanie sieciowe oparte na kategoriach.

Sposób wspólnego planowania kategorii, grup adresów URL, zasad sieciowych i alertów natychmiastowych opisano w Sophos Firewall Korzystanie z kategorii internetowych i alertów błyskawicznych.

Zastosuj kształtowanie ruchu w oparciu o kategorię internetową

Ta opcja stosuje kształtowanie ruchu w oparciu o kategorie internetowe. Ma to sens tylko wtedy, gdy stosowane są odpowiednie reguły kształtowania ruchu lub zasady kategorii stron internetowych.

Praktyczny przykład: kategorie przesyłania strumieniowego są ograniczone, preferowane są aplikacje biznesowe.

Block QUIC protocol

QUIC wykorzystuje UDP 80 i UDP 443. Wiele przeglądarek używa QUIC do obsługi usług Google i innych nowoczesnych aplikacji internetowych.

Jeśli ważne jest filtrowanie sieci lub skanowanie ruchu sieciowego pod kątem złośliwego oprogramowania, w wielu środowiskach należy pozostawić opcję Block QUIC protocol włączoną. Przeglądarki zwykle wracają do normalnego protokołu HTTPS przez TCP, który jest łatwiejszy do kontrolowania i sprawdzania.

Więcej na ten temat: Sophos Firewall Blokuj poprawnie QUIC i HTTP/3.

Scan HTTP and decrypted HTTPS

Ta opcja skanuje protokół HTTP i już odszyfrowany protokół HTTPS w poszukiwaniu złośliwego oprogramowania.

Ważne: ta opcja nie powoduje automatycznego odszyfrowania protokołu HTTPS. Aby naprawdę sprawdzić HTTPS, wymagane są odpowiednie reguły inspekcji SSL/TLS w ramach Rules and policies > Reguły inspekcji SSL/TLS.

Praktyczny przykład: Jeśli TLS Inspection jest aktywny dla LAN_to_WAN_Clients, Scan HTTP and decrypted HTTPS może sprawdzać pobrane pliki w odszyfrowanym ruchu HTTPS.

Więcej na ten temat: Wdrażaj stopniowo TLS Inspection do Sophos Firewall.

Użyj ochrony typu zero-day

Użyj ochrony Zero-day wysyła podejrzane pliki do dalszej analizy do Sophos Zero-Day Protection. Jest to przydatne w przypadku reguł klienta i serwera, które chcą sprawdzać pliki do pobrania z Internetu.

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

Skanuj FTP w poszukiwaniu złośliwego oprogramowania

Ta opcja skanuje ruch FTP w poszukiwaniu złośliwego oprogramowania. Ma to znaczenie tylko wtedy, gdy faktycznie używany jest FTP i zwykle dozwolony jest pasujący Services.

FTP stał się mniej powszechny w nowoczesnych środowiskach, ale nadal występuje w starszych systemach, sterownikach maszyn lub starszych mechanizmach aktualizacji.

Użyj serwera proxy sieci Web zamiast DPI engine

Sophos Firewall może sprawdzać ruch sieciowy poprzez DPI engine lub poprzez serwer proxy sieci Web.

W przypadku nowoczesnych konfiguracji DPI jest zwykle lepszym domyślnym wyborem, ponieważ obsługuje ruch HTTP i SSL/TLS na wszystkich portach. Internetowy serwer proxy jest nadal przydatny, jeśli wymagane są specjalne funkcje proxy, na przykład egzekwowanie filtra SafeSearch, ograniczenia YouTube, ograniczenia domeny aplikacji Google, ochrona pharmingu, pamięć podręczna sieci lub nadrzędny serwer proxy.

Jeśli opcja Użyj web proxy zamiast DPI engine nie jest włączona, reguła działa w trybie DPI.

Odszyfruj HTTPS podczas filtrowania serwera proxy sieci Web

Ta opcja należy do trybu proxy sieci Web. Ma to znaczenie tylko wtedy, gdy włączona jest opcja Użyj web proxy zamiast DPI engine i protokół HTTPS ma być odszyfrowany w trybie proxy.

W trybie DPI deszyfrowanie HTTPS nie jest tutaj kontrolowane, ale raczej poprzez reguły inspekcji SSL/TLS.

Synchronized Security Bicie serca

Dzięki opcji Konfiguruj puls Synchronized Security stan Sophos Endpoint może zostać uwzględniony w regule zapory sieciowej.

Typowe opcje:

• Ustaw minimalny status urządzeń źródłowych
• Blokuj klientów bez bicia serca
• Ustaw minimalny status dla urządzeń docelowych
• Blokuj żądania do miejsc docelowych bez bicia serca

Jest to mocne, ale ma sens tylko wtedy, gdy Sophos Endpoint, Sophos Central i Security Heartbeat są prawidłowo skonfigurowane.

Praktyczny przykład: Klienci z czerwonym Security Heartbeat nie mają już dostępu do serwerów ani dostępu do Internetu.

W przypadku reguły pierwszego klienta nie należy aktywować pulsu na ślepo, w przeciwnym razie możesz zablokować urządzenia, które w ogóle nie mogą wysyłać pulsu.

Inne funkcje bezpieczeństwa

Identyfikuj i kontroluj aplikacje (kontrola aplikacji)

Politykę filtra aplikacji wybiera się poprzez Identyfikuj i kontroluj aplikacje (kontrola aplikacji).

Umożliwia to rozpoznawanie i kontrolowanie aplikacji, na przykład:

• Przeglądarka zespołu
• Brama
• Posłańcy
• Transmisja strumieniowa
• Przechowywanie w chmurze
• Narzędzia do zdalnego sterowania

Application Control wymaga odpowiedniej licencji. W praktyce ta funkcja jest zawarta w pakietach Sophos Firewall z ochroną sieciową, na przykład Standard Protection, Xstream Protection lub Epic Protection.

TLS Inspection jest często kluczowy dla wykrywania aplikacji w ruchu zaszyfrowanym. Bez deszyfrowania, w zależności od usługi, zapora widzi tylko nazwy hostów, SNI, informacje o certyfikatach lub adresy IP, a nie całą zawartość.

Niestandardowy proces filtrów, wiązania reguł, dzienników i sprawdzania wyników fałszywie dodatnich jest dostępny w Sophos Firewall Konfigurowanie i testowanie Application Control.

Apply application-based traffic shaping policy

Ta opcja dotyczy kształtowania ruchu zdefiniowanego w Polityce aplikacji lub Obiektie aplikacji.

Praktyczny przykład: Microsoft Teams powinien być rozpoznawany i traktowany priorytetowo z określoną polityką kształtowania ruchu. Następnie należy wybrać odpowiednią politykę Application Control i zastosować politykę kształtowania ruchu opartą na aplikacji.

Jeśli ustawiłeś już wyraźną politykę kształtowania ruchu w polu Kształtuj ruch, powinno być wyraźnie udokumentowane, która polityka powinna mieć pierwszeństwo i dlaczego.

Wykrywaj i zapobiegaj exploitom (IPS)

W obszarze Wykrywaj i zapobiegaj exploitom (IPS) wybiera się politykę IPS.

IPS sprawdza ruch pod kątem znanych wzorców ataków i exploitów. W przypadku ruchu klientów do Internetu stosowana jest inna polityka niż w przypadku ruchu serwera lub publikowanych usług.

Praktyczne przykłady:

• Reguła klienta LAN_to_WAN: Polityka klienta lub LAN do WAN IPS
• Reguła DNAT dla serwera WWW: polityka IPS serwera lub serwera WWW
• Reguła VoIP: przetestuj dokładnie, ponieważ agresywne profile IPS mogą zakłócać VoIP

IPS nie powinien być aktywowany wszędzie, stosując najsurowsze zasady. Zbyt ogólna lub niepoprawna polityka IPS może przerwać legalny ruch lub spowodować niepotrzebne obciążenie.

Dedykowany artykuł Sophos Firewall Skonfiguruj IPS i bezpiecznie go przetestuj bardziej szczegółowo wyjaśnia globalną aktywację, status licencji, wybór zasad, rejestrowanie i analizę fałszywie dodatnich wyników.

Kształtuj ruch

Dzięki opcji Shape Traffic politykę kształtowania ruchu można zastosować bezpośrednio do reguły. Dotyczy to:

• VoIP
• Spotkania on-line
• Ruch zapasowy
• Gość WLAN
• wolne trasy WAN

Praktyczny przykład: Gość WLAN otrzymuje politykę limitów, aby nie wypierać ruchu biznesowego.

Więcej na ten temat: Konfiguruj kształtowanie ruchu aplikacji na Sophos Firewall.

DSCP marking

DSCP marking oznacza pakiety pod kątem jakości usług na dalszych urządzeniach sieciowych.

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

Praktyczny przykład: ruch VoIP otrzymuje oznaczenie DSCP, dzięki czemu przełączniki i routery WAN traktują ten ruch preferencyjnie.

Skanuj za pomocą NDR Aktywna analiza zagrożeń

Skanuj za pomocą NDR Aktywna analiza zagrożeń wykorzystuje Sophos NDR Threat Intelligence do dodatkowej oceny ruchu sieciowego.

Ta opcja jest użyteczna tylko wtedy, gdy środowisko wykorzystuje wymagane komponenty Sophos Central i NDR. W wielu środowiskach nie jest to pierwsza opcja w przypadku reguły podstawowej, ale może być cennym dodatkiem w sieciach bardziej monitorowanych.

Skanuj zawartość e-maili

Obszar Skanuj zawartość wiadomości e-mail dotyczy protokołów poczty elektronicznej.

Możliwe opcje:

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

Jeśli aktywujesz tam protokoły, odpowiednie porty standardowe muszą być również uwzględnione w Services reguły lub dodane poprzez Dodaj porty.

Ten obszar często nie ma zastosowania w przypadku normalnych reguł klienta internetowego. Powinieneś zaplanować to świadomie pod kątem serwerów pocztowych lub ruchu pocztowego klientów.

Praktyczny przykład: Wewnętrzny serwer pocztowy może wysyłać SMTP na zewnątrz. Następnie tworzona jest osobna reguła serwera, aktywowane jest rejestrowanie i sprawdzane jest skanowanie poczty e-mail pod kątem zgodności z architekturą poczty.

Sprawdź po zapisaniu

Po zapisaniu należy przetestować regułę, a nie tylko założyć, że wszystko działa poprawnie.

Aby sprawdzić:

1. Czy reguła jest we właściwej pozycji?
2. Czy Logowanie ruchu zapory jest aktywne?
3. Czy po zmianie zasad licznik trafień został zresetowany, czy też utworzono nowy, wyraźny test?
4. Czy reguła jest zgodna z przeglądarką logów?
5. Czy pojawia się oczekiwana zapora sieciowa Rule ID?
6. Czy obowiązuje żądana reguła NAT?
7. Czy DNS działa?
8. Czy filtry sieciowe, IPS, Application Control i TLS Inspection zostały zastosowane zgodnie z oczekiwaniami?
9. Czy są jakieś nieoczekiwane spadki lub błędy SSL/TLS?

Artykuł Testowanie reguły zapory sieciowej za pomocą Log Viewer, Policy Test i Packet Capture pomaga w sprawdzeniu czystości.

Przy wprowadzaniu produktywnych zmian sensowne jest małe porównanie przed i po:

• Istnieje punkt kopii zapasowej lub przywracania: Demontaż pozostaje możliwy, jeśli przepis wywoła skutki uboczne.
• Zanotowano ścieżkę audytu lub bilet zmiany: później będzie jasne, kto dokonał zmiany i kiedy.
• Przypadek testowy zdefiniowany wcześniej: Sukcesu nie ocenia się tylko po odczuciu.
• Tylko jedna zmiana na test: Przyczyna i skutek pozostają zrozumiałe.
• Sprawdzono Log Viewer lub logi centralne: widoczne są prawdziwe Rule ID i NAT ID.
• Udokumentowana decyzja o demontażu: tymczasowe zasady testu nie pozostają aktywne na stałe.

Jeśli masz wiele zapór sieciowych lub grup zarządzanych centralnie, powinieneś również sprawdzić, czy zmiana dotarła do właściwego urządzenia lub grupy. W przypadku Sophos Central pomaga Kolejka zadań zarządzania zaporą sieciową; zmiany lokalne można śledzić za pomocą Dzienników ścieżki audytu.

Regularna obsługa i przegląd

Reguła zapory sieciowej nie jest gotowa tylko dlatego, że została zapisana. Dobre reguły mają jasny cel, są rejestrowane, można je testować i można je później ponownie sprawdzić. Zwłaszcza w dojrzałych środowiskach wiele zagrożeń nie wynika z jednej błędnej reguły, ale ze starych wyjątków, zasad, które są zbyt szerokie lub zasad bez właściciela.

W przypadku regularnych przeglądów warto zastosować się do prostej procedury:

• Czy zasada będzie nadal obowiązywać?: Nieużywane reguły często można wyłączyć i usunąć później.
• Czy źródło jest nadal prawidłowe?: Sieci klienckie, sieci serwerów i obszary VPN zmieniają się z biegiem czasu.
• Czy Any jest nadal uzasadniony?: Szerokie źródła, cele lub Services należy celowo udokumentować.
• Czy rejestrowanie jest aktywne i przydatne?: Bez logów późniejsze analizy i audyty są znacznie słabsze.
• Czy NAT, filtr sieciowy, IPS i TLS Inspection nadal pasują?: Funkcje zabezpieczeń mogą działać inaczej po aktualizacjach, zmianach aplikacji lub zmianach certyfikatów.
• Czy jest data ważności?: W przeciwnym razie tymczasowe zasady projektu lub wsparcia pozostaną aktywne na stałe.

W przypadku zasad krytycznych należy również udokumentować osobę odpowiedzialną technicznie. Jest to szczególnie ważne w przypadku opublikowanych usług, reguł VPN, dostępu do zarządzania, udziałów dostawców usług i reguł z Any w Services lub miejscu docelowym.

Nowa reguła, zmienić lub dezaktywować istniejącą regułę?

Nie każde nowe żądanie wymaga natychmiastowej nowej reguły zapory sieciowej. Zbyt wiele podobnych reguł powoduje, że lista jest zagmatwana, ale reguły, które są zbyt podsumowane, szybko stają się zbyt szerokie. Przed zapisaniem czegoś w WebAdmin pomaga prosta decyzja:

• To samo źródło, to samo miejsce docelowe, ten sam cel, tylko jedna dodatkowa usługa: Rozszerz istniejącą regułę. Zasada pozostaje spójna technicznie i łatwiejsza do przetestowania.
• Te same sieci, ale różne wymagania dotyczące ochrony, inne logowanie lub inny właściciel: Stwórz własną regułę. Filtry internetowe, IPS, TLS Inspection, NDR lub rejestrowanie można sprawdzić osobno.
• Tymczasowy usługodawca lub dostęp do wsparcia: Stwórz własną tymczasową regułę. Właściciel, bilet, data ważności i okno testowe pozostają wyraźnie widoczne.
• Dotyczy to serwerów, gości, VoIP, IoT lub zarządzania: Sprawdź swoją własną regułę lub strefę. Różne zagrożenia nie powinny znikać w jednej regule internetowej klienta.
• Zasada jest niejasna lub stara: Najpierw dezaktywuj i obserwuj. Bezpośrednie usunięcie odbiera możliwość kontrolowanego sprawdzania trafień, dzienników i zależności.
• Zasada z pewnością jest zbędna po recenzji: Usuń po utworzeniu kopii zapasowej i dokumentacji. Zestaw reguł staje się mniejszy bez przerywania ślepo działających zależności.

W przypadku normalnych zmian operacyjnych proces ten jest niezawodny:1. Zanotuj cel, właściciela, bilet i oczekiwany ruch. 2. Sprawdź istniejące reguły dla tego samego źródła, miejsca docelowego, usługi i Rule group. 3. Zdecyduj, czy istniejąca reguła ma zostać rozszerzona, czy też Twoja własna reguła jest czystsza. 4. W przypadku zmian produktywnych zaplanuj kopię zapasową, ścieżkę audytu i przypadek testowy. 5. Po zapisaniu Log Viewer, Rule ID sprawdź decyzję NAT i odpowiednie funkcje bezpieczeństwa.

Jeżeli decyzja nie zostanie podjęta głównie z powodu braku dokumentacji, należy w pierwszej kolejności podjąć działania zasady Sophos Firewall powinny być w znaczący sposób udokumentowane. Jeśli nie jest jasne, czy istniejąca reguła jest nadal potrzebna, pomaga kontrolowany test za pomocą Testuj regułę zapory sieciowej za pomocą Log Viewer, Policy Test i Packet Capture.

Prawidłowo rozmieszczaj liczniki trafień

Liczniki trafień pomagają w sprzątaniu, ale nie są kompletnym dowodem. Rzadko stosowana zasada awaryjna może nadal być ważna. I odwrotnie, ogólna reguła może mieć wiele trafień, nawet jeśli pozwala na zbyt wiele.

W przypadku recenzji należy zawsze łączyć liczniki trafień z Log Viewer, opisem reguły i rzeczywistym przypadkiem użycia. Jeżeli przepis jest niejasny, nie należy go od razu usuwać. Kontrolowany proces jest lepszy: wyjaśnij cel, aktywuj logowanie, zdefiniuj okna testowe, poinformuj interesariuszy i dopiero wtedy je dezaktywuj lub usuń.

Zapewnij możliwość śledzenia zmian

Kopia zapasowa powinna być dostępna przed poważnymi zmianami zasad. Audit Trail i Config Studio pomagają następnie sprawdzić różnice w zrozumiały sposób. Praktyczny proces odbywa się w Sophos Firewall Sprawdź dzienniki ścieżki audytu i Sophos Firewall Użyj Config Studio.

Jeśli dostosowanych jest wiele reguł, należy nie tylko porównać konfigurację, ale także przeprowadzić rzeczywiste przypadki testowe. Reguła może być poprawna składniowo, a mimo to zezwalać na nieprawidłowy ruch, używać niewłaściwej ścieżki NAT lub zakłócać działanie aplikacji poprzez IPS, filtrowanie sieci lub TLS Inspection.

Typowe błędy

Reguła jest zbyt odległa: Powyższa, bardziej ogólna reguła najpierw dopasowuje ruch.

Źródło jest zbyt szerokie: Any działa, ale powoduje, że zasady są niejasne i zwiększa powierzchnię ataku.

Miejsce docelowe jest zbyt szerokie: Serwery lub sieci zarządzające rzadko powinny mieć możliwość dostępu do Internetu za pomocą Any.

Services są za szerokie: Any pozwalają na znacznie więcej niż to konieczne. Lepsze są określone grupy Services lub usługi.

Logowanie nie jest aktywne: W Log Viewer brakuje wówczas najważniejszych informacji.

Zapomniano o IPv6: IPv4 jest odpowiednio regulowany, ale IPv6 działa na innych zasadach lub pozostaje nieświadomie otwarty.

Rule group jest z pewnością zdezorientowany: Grupa reguł tylko poprawia przegląd. Grupa reguł nie stanowi własnej granicy bezpieczeństwa i nie zmienia logiki oceny.

HTTPS nie jest skanowany: Scan HTTP and decrypted HTTPS jest aktywny, ale nie ma odpowiedniej reguły inspekcji SSL/TLS ani deszyfrowania.

Filtr sieciowy nie działa: Nie ustawiono żadnych zasad sieciowych, zły użytkownik, zła strefa źródłowa lub QUIC nie jest zablokowany.

Dopasowywanie użytkowników nie działa: Uwierzytelnianie, AD SSO, portal przechwytujący lub mapowanie użytkowników nie działają prawidłowo.

Brak NAT: Reguła zapory zezwala na ruch, ale SNAT/MASQ nie pasuje.

Funkcja zabezpieczeń nie dopasowuje ruchu: Nieprawidłowa polityka IPS, opcja proxy lub opcja skanowania poczty e-mail mogą zakłócić legalny ruch. Jeśli po tych punktach nie będzie jasne, dlaczego ruch przebiega inaczej niż oczekiwano, należy przeprowadzić dalsze testy strukturalne za pomocą Log Viewer, Testera zasad i Packet Capture. Odpowiednia procedura jest opisana w Testuj regułę zapory sieciowej za pomocą Log Viewer, Policy Test i Packet Capture.

Często zadawane pytania