Zrozum i bezpiecznie skonfiguruj reguły Sophos Firewall

Reguły zapory sieciowej są sercem 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, Action, 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 skanowanie poczty e-mail.

Ścieżka menu to:

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

Maska reguł jest podzielona na kilka obszarów: obszar nagłówka, źródło, miejsce docelowe, Services, odnośnik 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 utworzeniem powinno być również jasne, czy jest to reguła IPv4 czy IPv6. Widok reguły jest odpowiednio wybrany w WebAdmin. W środowiskach z dwoma stosami IPv4 i IPv6 muszą być celowo zaplanowane i przetestowane oddzielnie; działająca reguła IPv4 nie dowodzi automatycznie, że IPv6 jest jednakowo zabezpieczone.

Szybka nawigacja

• Jakie reguły zapory sieciowej kontrolują, a czego nie
• [Podstawowa zasada i porządek](#podstawowa zasada-i-porządek)
• [Zaplanuj bazę reguł przed utworzeniem](#planuj bazę reguł przed utworzeniem)
• [oddziel typy reguł w sposób czysty](#oddzielne typy reguł)
• [Fikcyjny przykład praktyczny](#fikcyjny-praktyczny przykład)
• Nagłówek: Stan, nazwa, Action i rejestrowanie
• źródło, strefa i harmonogram
• [Miejsce docelowe i usługi](#miejsce docelowe i usługi)
• [Match known users](#dopasuj znanych-użytkowników)
• Add wykluczenie
• Create linked NAT rule
• [Filtrowanie sieci](#filtrowanie sieci)
• Zsynchronizowane Security Heartbeat
• Inne funkcje zabezpieczeń
• Skanuj treść e-maili
• Sprawdź po zapisaniu
• [Regularna obsługa i przegląd](#regularna obsługa 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, sieci VLAN i routing są ze sobą ściśle powiązane w Sophos Firewall. Dlatego ważne jest, aby administratorzy najpierw wybrali odpowiedni temat:

• Omów regułę zapory ogniowej od podstaw: Ten artykuł.
• NAT, SNAT, DNAT, MASQ lub PAT klasyfikacja: NAT rozumie Sophos Firewall: SNAT, DNAT, MASQ, PAT.
• Publikuj serwer wewnętrzny poprzez przekierowanie portów: Publikuj serwer przez DNAT do Sophos Firewall.
• Bezpieczna publiczna aplikacja internetowa: Skonfiguruj i uporządkuj Sophos Firewall WAF.
• Reguła nie ma zastosowania lub pojawia się niepoprawny Rule ID: Sophos Firewall Reguła nie ma zastosowania: sprawdź przyczyny.
• Używanie FQDN hosts i wildcard FQDNs w regułach: Poprawne używanie FQDN hosts i wildcard FQDNs w Sophos Firewall.
• Przetestuj konkretnie regułę: Przetestuj regułę zapory sieciowej za pomocą Log Viewer, Test zasad i Packet Capture.
• WebAdmin, VPN Portal, User Portal, SSH, DNS lub SNMP zabezpiecz zaporę ogniową: Sophos Firewall zabezpiecz dostęp: poprawnie skonfiguruj Device Access.
• Plan zones, interfaces or VLANs: Sophos Firewall Configure zones and interfaces.
• Obsługuj most ze znacznikami VLAN: Sophos Firewall Używaj mostu ze znacznikami VLAN.
• Sprawdź kolejność routingu lub ścieżki SD WAN: Sophos Firewall Dostosuj priorytet routingu.
• Pakiety odpowiedzi lub ruch System idą niewłaściwą ścieżką: Routing SD-WAN dla pakietów odpowiedzi i ruchu System.

To oddzielenie uniemożliwia typowe rozwiązywanie problemów. Reguła NAT nie zezwala na ruch, reguła zapory sieciowej nie tłumaczy adresu, a reguła WAF nie jest tym samym, co normalne przekierowanie portów DNAT.

Jakie reguły zapory kontrolują, a czego nie

Firewall — kontrolowanie ruchu, przez który Firewall działa. 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 sieciowej decydują o tym, czy ruch tranzytowy jest dozwolony, odrzucany czy sprawdzany za pomocą funkcji bezpieczeństwa.
• WebAdmin, User Portal, VPN Portal, SSH, DNS lub SNMP do samej zapory ogniowej: Device Access i Local Service ACL są odpowiedzialne. Lokalne usługi firewalla nie są traktowane jak normalny ruch LAN do WAN lub WAN do DMZ.
• Translacja adresu lub portu: Reguły NAT tłumaczą ruch, ale nie zezwalają na to automatycznie.
• Routing, ścieżka powrotna, SD-WAN i ścieżki VPN: Routing, SD-WAN, pierwszeństwo trasy i konfiguracja VPN decydują o ścieżce. Odpowiednia reguła zapory sieciowej nie jest skuteczną metodą powrotu.
• Kategorie internetowe, grupy adresów URL i zasady sieciowe: Filtrowanie sieci i zasady sieciowe kontrolują logikę sieci. Reguła zapory sieciowej integruje jedynie politykę.
• HTTPS deszyfrowanie: SSL/TLS inspection rules i dystrybucja CA są konieczne. Scan HTTP and decrypted HTTPS skanuje tylko ruch, który został już odszyfrowany.
• User Identity: Authentication, STAS, Captive Portal, Entra ID SSO or RADIUS must work. Reguła użytkownika pasuje tylko wtedy, gdy zapora może przypisać użytkownika do ruchu.

W przypadku usług zarządzania i portalu głównym artykułem jest Device Access i Local Service ACL. Jeśli reguła pasuje, ale połączenie nadal nie działa, reguła Sophos Firewall nie działa: sprawdź przyczyny i przetestuj regułę zapory sieciowej za pomocą Log Viewer, test zasad i Packet Capture mogą pomóc.

Szczególnie w przypadku sieci mieszanych IPv4/IPv6 należy również sprawdzić, czy aplikacja poprzez IPv6 unika węższej reguły IPv4. Jeżeli IPv6 nie jest aktywnie wykorzystywane, należy mimo wszystko świadomie udokumentować strategię IPv6: dezaktywować, blokować, odpowiednio regulować lub wprowadzać 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 pasuje tylko wtedy, gdy wszystkie istotne kryteria mają zastosowanie jednocześnie:

• Source zone: Musi pasować, na przykład LAN.
• Sieci i urządzenia źródłowe: Muszą pasować, na przykład net_LAN_Clients.
• Schedule: Musi pasować, na przykład All the time.
• Destination zone: Musi pasować, na przykład WAN.
• Sieci docelowe: Muszą pasować, na przykład Any lub host FQDN.
• Services: Musi pasować, na przykład HTTP, HTTPS i DNS.
• Dopasowanie użytkownika: Musi pasować, jeśli jest włączone, na przykład grupa AD Internet-Users.
• Wyłączenia: Można pominąć regułę, jeśli jest ustawiona, na przykład na wykluczonym serwerze kopii zapasowych.

Pierwsza pasująca reguła wygrywa. Jeśli ogólna reguła LAN_to_WAN_Any zostanie umieszczona nad konkretną regułą LAN_to_WAN_Restricted, konkretna reguła nigdy nie zostanie osiągnięta.

Szczególnie ważne: nie wszystkie reguły są tworzone ręcznie. Sophos Firewall może automatycznie tworzyć reguły, na przykład dla połączeń MTA, IPsec lub hotspotów. Takie zasady mogą wylądować na górze listy reguł i zmienić istniejące mecze. Po kreatorach, zmianach VPN, aktywacji MTA lub migracjach należy zawsze sprawdzić, czy oczekiwana reguła znajduje się przed, czy po automatycznie wygenerowanych regułach.

Na końcu listy reguł znajduje się niejawna reguła Drop-all. Tej reguły domyślnej nie można przenosić ani edytować jak zwykłej reguły. Jeśli ruch nie znajdzie pasującej reguły, zostanie tam odrzucony. Dlatego w logach i testach powinieneś rozróżnić, czy obowiązuje Twoja własna reguła blokowania, czy też ruch po prostu spada do domyślnego Drop.

Planuj bazę reguł przed utworzeniem

Szybko tworzona jest pojedyncza reguła zapory. 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 ruch powinien być naprawdę dozwolony? Przed utworzeniem zanotuj źródło, miejsce docelowe i Services.
• Czy ruch należy do osobnej strefy? Świadomie oddzielaj serwery, klientów, gości, zarządzanie, VPN i DMZ.
• Czy istnieje już konkretna reguła? Sprawdź istniejące reguły zamiast tworzyć drugą podobną regułę.
• Czy w grę wchodzi NAT? Zaplanuj razem regułę zapory sieciowej i regułę NAT, ale nie mieszaj ich.
• Jak będą przeprowadzane testy później? Aktywuj logowanie i zdefiniuj konkretny ruch testowy.
• Czy wydanie jest tymczasowe? Data ważności dokumentu lub bilet w opisie.

W przypadku czystych stref i interfejsów najpierw pasuje Sophos Firewall Skonfiguruj 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ą konfigurację końcową. 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 zła opcja, ale ogólna zasada, która obejmuje jednocześnie klientów, serwery, VPN, gości i zarządzanie. Na początku działa to szybko, ale później staje się trudne do przetestowania i trudne do utwardzenia.

• Internet klienta: Źródłem są sieci klienckie, celem jest zwykle WAN. Świadomie planuj politykę internetową, Application Control, IPS, TLS Inspection, QUIC i logowanie.
• Internet serwera: Źródłem są sieci serwerów, celami powinny być zdefiniowane cele aktualizacji, kopii zapasowych lub chmury. Reguły te są węższe niż reguły klienta i często nie mają odniesienia do użytkownika.
• WLAN dla gościa: ​​Źródłem jest strefa gościnna, miejscem docelowym jest zwykle WAN. Wyklucz cele wewnętrzne, świadomie kontroluj przepustowość i DNS.
• Zarządzanie: Źródłem są sieci administracyjne, celami są firewall, serwery, przełączniki lub hypervisory. Nie mieszaj ze zwykłymi zasadami klienta.
• Dostęp zdalny VPN: Źródło to VPN lub jego własna strefa zdalnego dostępu, cele to wewnętrzne strefy docelowe. Zezwalaj tylko na wymagane cele podróży i usługi i rejestruj je w fazie wstępnej.
• Site-to-Site: Źródła to lokalne i zdalne strefy VPN lub strefy XFRM, miejsca docelowe to sieci partnerskie lub lokacje. Sprawdź routing, NAT, ścieżkę powrotną i logowanie.
• Opublikowano System: Źródło to WAN lub zdefiniowane źródło, miejsce docelowe to DMZ lub strefa serwera. DNAT/WAF, IPS, uwzględniono rejestrowanie, poziom poprawek i ograniczenia źródła.
• Dostęp tymczasowy: Źródło to określone źródło wsparcia lub projektu, cel pozostaje wąski. Dokument bilet, data ważności, właściciel i demontaż.

Gdy dwa połączenia mają różnych właścicieli, zabezpieczenia lub cykle przeglądania, 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 utworzono regułę 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.

• Rule name: LAN_to_WAN_Clients, dzięki czemu źródło i miejsce docelowe są natychmiast widoczne.
• Opis: Internet Access für Client-Netz, erstellt für Standard-Client-Traffic, aby później wyjaśnić, dlaczego dana reguła istnieje.
• Rule position: Zgodnie z określonymi regułami blokowymi i serwerowymi, aby określone reguły zaczęły obowiązywać jako pierwsze.
• Grupa reguł: Internet Access dla lepszego przeglądu.
• Action: Accept, ponieważ zdefiniowany ruch powinien być dozwolony.
• Log firewall traffic: Włączone, aby rozwiązywanie problemów było nadal możliwe w Log Viewer.
• Strefy źródłowe: LAN, ponieważ ruch pochodzi ze strefy LAN.
• Sieci i urządzenia źródłowe: net_LAN_Clients, nie wszystkie sieci LAN.
• W zaplanowanym czasie: All the time, jeśli dostęp do Internetu ma być stały.
• Strefy docelowe: WAN, ponieważ miejscem docelowym jest Internet.
• Sieci docelowe: Any, często praktyczne w przypadku Internetu klienckiego.
• Services: HTTP, HTTPS, DNS, NTP, tj. wymagane są tylko podstawowe usługi.
• Zasady internetowe: Default Workplace Policy umożliwiające kontrolę dostępu do sieci w oparciu o kategorie.
• Blokuj protokół QUIC: Włączono, aby zapewnić skuteczność filtrowania i skanowania sieci.
• IPS: Polityka klienta dotycząca ochrony przed exploitami dla wychodzącego ruchu klienta.
• Kontrola aplikacji: Zasady aplikacji klienckich blokujące niechciane aplikacje.
• Kształtuj ruch: Opcjonalne, tylko jeśli wymagana jest przepustowość.
• Oznaczenie DSCP: Puste, chyba że dalsze urządzenia ocenią DSCP.

Ten przykład celowo nie jest darmowym biletem Any. W praktyce sieci klienckie, sieci serwerów, gościnne sieci WLAN, VoIP i zarządzanie należy rozpatrywać oddzielnie.

W przypadku pierwszego testu produktywnego ten przykład powinien zawierać 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: status, nazwa, Action i rejestrowanie

Stan reguły

Stan reguły włącza lub wyłącza 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.

Przykład praktyczny: Przygotowano nową regułę dla serwera, ale aktywowano ją dopiero w oknie konserwacji.

Podczas rozwiązywania problemów status to szybkie wykluczenie: dezaktywowana reguła może należeć do właściwej grupy, mieć poprawną nazwę i nadal nigdy nie pasować. Następnie w Log Viewer pojawia się kolejny Rule ID lub na końcu domyślny Drop.

Rule name

Nazwa powinna od razu wyjaśniać, co robi reguła.

Dobre imiona:

• 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 przydatne, ponieważ nie można już określić, jakie zadanie ma dana reguła.

Opis

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

• dlaczego reguła istnieje
• kto zażądał reguły
• jakie ograniczenia zostały celowo ustawione
• czy istnieje bilet, projekt lub data ważności

Przykład:

Dostęp do Internetu dla sieci klienckiej 10.10.10.0/24. Webfilter i IPS aktywne. Zgłoszone przez IT, sprawdzone 10.06.2026.

Jak prawidłowo używać tego pola i dokumentować reguły zapory sieciowej w zrozumiały sposób opisano bardziej szczegółowo w artykule Sophos Firewall-Rozsądne dokumentowanie reguł.

Rule position

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

• Top: Używaj tylko w przypadku bardzo szczegółowych reguł, reguł blokowych lub testów.
• Bottom: Często przydatne w przypadku nowych standardowych reguł.
• Above rule: Użyj, gdy reguła musi wyraźnie zacząć obowiązywać przed istniejącą regułą.
• Below rule: Użyj, jeśli reguła powinna konkretnie używać istniejącej reguły.

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

Grupa reguł

Grupa reguł 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.

Przydatne grupy to na przykład:

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

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

Action

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

• Accept: Ruch jest dozwolony. Jest to standard dla normalnych reguł Allow.
• Drop: Ruch jest dyskretnie odrzucany. Przydatne w przypadku reguł blokowych, w przypadku których klient nie powinien otrzymać odpowiedzi.
• Reject: Ruch jest odrzucany, a klient otrzymuje odpowiedź. Jest to często bardziej przydatne w przypadku rozwiązywania problemów lub wewnętrznych reguł blokowania.
• Protect with web server protection: WAF zastosowano ochronę. Jest to część ochrony serwera WWW, a nie normalne reguły 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 przy rozwiązywaniu problemów.

W przypadku ruchu internetowego ważny jest jeden szczegół: zasady sieciowe i Użyj uwierzytelniania sieciowego dla nieznanych użytkowników mogą powodować przekierowania, portale przechwytujące lub blokować strony. Dlatego podczas testowania powinieneś nie tylko ocenić zachowanie w przeglądarce, ale także sprawdzić Rule ID, Action i dopasowanie użytkownika w Log Viewer.

Log firewall traffic

Log firewall traffic powinien prawie zawsze być aktywowany dla ważnych reguł.

Bez logowania ważne informacje nie są widoczne później w Przeglądarce dziennika. 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 faktycznie została zastosowana.

Ważne: Zapora zazwyczaj rejestruje sesje zapory, gdy połączenie zostanie zakończone i wystąpi zdarzenie 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 również odpowiednio skonfigurować System services > Log settings. W przypadku dłuższego przechowywania sensowne jest raportowanie zapory Sophos Central lub serwera Syslog. Więcej na ten temat: Aktywuj raportowanie Central Firewall i Sophos Firewall Syslog bezpiecznie wyślij na adres SIEM.

W przypadku reguł produktywnych rejestrowanie nie powinno być postrzegane jedynie 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.

Strefy źródłowe

Strefy źródłowe 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ścinnej sieci Wi-Fi
• WAN dla przychodzącego ruchu internetowego

Przykład praktyczny: LAN zostało wybrane dla reguły internetowej od klientów do Internetu. W przypadku reguły DNAT przesyłanej z serwera zewnętrznego do wewnętrznego, WAN jest zwykle używane jako Source zone w powiązanej regule zapory sieciowej.

Sieci źródłowe i urządzenia

Sieci i urządzenia źródłowe dokładniej zawężają źródło.

Możliwe obiekty to na przykład:

• pojedyncze hosty
• Sieci
• Zakresy adresów IP
• Grupy hostów
• FQDN hosty
• Obiekty krajowe

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

Przykład praktyczny: Zamiast Any w źródle używasz 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 konserwacji
• wersje tymczasowe

Harmonogramy są przydatne, jeśli dostęp powinien być dozwolony tylko w określonych godzinach. Podczas rozwiązywania problemów zawsze musisz sprawdzić, czy czas zapory, strefa czasowa i Schedule rzeczywiście się zgadzają.

Przykład praktyczny: 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.

Strefy docelowe

Strefy docelowe to strefa docelowa.

Przykłady:

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

Przykład praktyczny: Dla ruchu internetowego klienta użyj WAN. Server lub DMZ mogą być używane przez klientów w celu uzyskania dostępu do serwera wewnętrznego, jeśli te strefy zostaną odpowiednio utworzone.

Sieci docelowe

Sieci docelowe dokładniej zawężają miejsce docelowe.

W przypadku reguł internetowych klienta Any jest często dobrym początkiem. W przypadku serwerów, sieci zarządzania lub dostępu VPN miejsca docelowe powinny być znacznie bardziej ograniczone.

Przykłady:

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

Przykład praktyczny: 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ć tak wąsko, jak to możliwe. 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 sieciowych często wystarczająca jest grupa z 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
• Raportowanie powinno być powią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 podlega bardziej ogólnej regule poniżej lub jest odrzucany przez regułę Drop-all.

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 używane 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. Dlatego przy akceptacji Log Viewer powinien pokazywać użytkownika, grupę i Rule ID.

Wyłączenie Add

Dzięki wykluczeniu Add 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łę.

Wykluczenia mogą obejmować strefy źródłowe, sieci i urządzenia źródłowe, strefy docelowe, sieci docelowe i Services.

Przykład praktyczny: 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 utrudniają czytanie reguł. 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ć regułę źródłową NAT bezpośrednio z reguły zapory. Ta połączona reguła NAT pojawia 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 powinieneś 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 nie zezwala na sam ruch. NAT tłumaczy adresy lub porty. Odpowiednia reguła zapory nadal decyduje, czy ruch jest dozwolony.

Połączona reguła NAT dziedziczy kryteria dopasowania połączonej reguły zapory. W połączonej regule NAT możesz zasadniczo edytować przetłumaczone źródło lub tłumaczenie źródłowe specyficzne dla interfejsu. Jeśli potrzeba więcej logiki, niezależna reguła NAT jest zwykle bardziej przejrzysta.

W przypadku DNAT ważna jest także kolejność oceny: zapora sieciowa najpierw określa przetłumaczony cel, korzystając z reguły DNAT. Do dopasowania reguł zapory sieciowej używa następnie strefy docelowej, do której należy przetłumaczony cel. Dlatego przekierowanie portów przychodzących do serwera w strefie DMZ zazwyczaj wskazuje na Destination zone DMZ w regule zapory, nawet jeśli klient pierwotnie adresował publiczny adres WAN.

Połączone reguły NAT dotyczą tylko ruchu zgodnego z powiązaną regułą zapory sieciowej. Jeśli jednak niezależna reguła NAT znajdująca się nad połączoną regułą NAT odpowiada temu samemu ruchowi, wygrywa ta górna reguła NAT. W przypadku nieoczekiwanego NAT ID należy zatem sprawdzić nie tylko regułę firewalla, ale także kolejność w Rules and policies > NAT rules.

Więcej na ten temat: NAT rozumie 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 filtra sieciowego.

Zasady sieciowe

Zasady sieciowe kontrolują dostęp do sieci poprzez kategorie, użytkowników, grupy, grupy adresów URL i reguły.

Praktyczny przykład: Dla 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 żadnej zasady sieciowej, za pomocą tej opcji nie będzie stosowane filtrowanie sieciowe oparte na kategoriach.

Sposób łączenia kategorii, grup adresów URL, zasad sieciowych i alertów natychmiastowych opisano w artykule Sophos Firewall Korzystanie z kategorii internetowych i alertów błyskawicznych.

Zastosuj kształtowanie ruchu w oparciu o kategorie internetowe

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.

Przykład praktyczny: Kategorie przesyłania strumieniowego są ograniczone, preferowane są aplikacje biznesowe.

Zablokuj protokół QUIC

QUIC używa UDP 80 i UDP 443. Wiele przeglądarek używa QUIC do 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ć włączoną opcję Blokuj protokół QUIC. Przeglądarki zwykle wracają do normalnego poziomu HTTPS za pośrednictwem protokołu TCP, który jest łatwiejszy do kontrolowania i sprawdzania.

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

Scan HTTP and decrypted HTTPS

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

Ważne: ta opcja nie powoduje automatycznego odszyfrowania HTTPS. Aby naprawdę sprawdzić HTTPS, potrzebujesz pasującego SSL/TLS inspection rules pod Rules and policies > SSL/TLS inspection rules.

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

Więcej na ten temat: TLS Inspection do Sophos Firewall będzie stopniowo wdrażane.

Użyj ochrony typu zero-day

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

Ta 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 ogólnie dozwolone są odpowiednie 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 silnika DPI

Sophos Firewall może sprawdzać ruch internetowy za pośrednictwem silnika DPI lub internetowego serwera proxy.

W przypadku nowoczesnych konfiguracji DPI jest zwykle lepszym domyślnym wyborem, ponieważ ruch HTTP i SSL/TLS może być przetwarzany 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 internetowego serwera proxy zamiast silnika DPI 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 silnika DPI i HTTPS ma być odszyfrowany w trybie proxy.

W trybie DPI deszyfrowanie HTTPS nie jest tutaj kontrolowane, ale poprzez SSL/TLS inspection rules.

Zsynchronizowany Security Heartbeat

Konfiguracja synchronizacji Security Heartbeat umożliwia uwzględnienie stanu punktu końcowego Sophos w regule zapory.

Typowe opcje:

• Ustaw minimalny stan urządzeń źródłowych
• Blokuj klientów bez pulsu
• Ustaw minimalny stan urządzeń docelowych
• Blokuj żądania do miejsc docelowych bez pulsu

To jest mocne, ale ma sens tylko wtedy, gdy Sophos Endpoint, Sophos Central i Security Heartbeat są poprawnie skonfigurowane.

Przykład praktyczny: klienci z czerwonym Security Heartbeat nie mogą już uzyskiwać dostępu do serwerów albo tracą dostęp 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. Puls miejsca docelowego jest również odpowiedni tylko dla wewnętrznych urządzeń docelowych, a nie dla celów w strefie WAN.

Połączenie blokowania pulsu i wyjątków internetowych jest szczególnie trudne. Jeśli opcja Blokuj klientów bez pulsu jest aktywna, a wyjątek sieciowy pomija Sprawdzanie zasad, żądania sieciowe nadal mogą zostać przesłane. Dlatego takie wyjątki powinny być udokumentowane, ściśle ograniczone i sprawdzone w Log Viewer.

Inne funkcje bezpieczeństwa

Identify and control applications (App control)

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

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

• TeamViewer
• Cel
• Komunikator
• Przesyłanie strumieniowe
• Przechowywanie w chmurze
• Narzędzia do zdalnego sterowania

Application Control wymaga odpowiedniej licencji. W praktyce ta funkcja jest zawarta w pakietach Sophos Firewall z Web Protection, 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 przepływ filtrów, wiązania reguł, dzienników i sprawdzania fałszywych alarmów znajduje się w Sophos Firewall Konfigurowanie i testowanie Application Control.

Zastosuj zasady kształtowania ruchu oparte na aplikacjach

Ta opcja dotyczy kształtowania ruchu zdefiniowanego w polityce aplikacji lub Application Object.

Praktyczny przykład: Microsoft Teams powinien być rozpoznawany i traktowany priorytetowo zgodnie 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ż jawną politykę kształtowania ruchu w polu Kształtuj ruch, powinno być wyraźnie udokumentowane, która polityka powinna mieć pierwszeństwo i dlaczego.

Wykrywaj exploity i zapobiegaj im (IPS)

W obszarze Wykrywaj exploity (IPS) wybrano zasadę 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.

Practical examples:

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

IPS nie powinien być aktywowany wszędzie z najsurowszą polityką. Zbyt ogólna lub niepoprawna polityka IPS może przerwać legalny ruch lub spowodować niepotrzebne obciążenie.

Dedykowany artykuł Sophos Firewall Bezpieczne konfigurowanie i testowanie IPS 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 online
• Ruch zapasowy
• Wi-Fi dla gości
• powolne trasy WAN

Praktyczny przykład: Wi-Fi dla gości otrzymuje politykę limitów, dzięki czemu nie wypiera ruchu biznesowego.

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

Oznaczenie DSCP

Oznaczenie DSCP 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ą analizy zagrożeń NDR Active

Skanowanie za pomocą analizy zagrożeń NDR Active wykorzystuje analizę zagrożeń Sophos NDR do dodatkowej oceny ruchu sieciowego.

Ta opcja jest użyteczna tylko wtedy, gdy środowisko używa wymaganych komponentów 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ść wiadomości e-mail

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 tam aktywujesz protokoły, odpowiednie porty standardowe muszą być również uwzględnione w Services reguły lub uzupełnione portami Add.

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

Przykład praktyczny: 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 powinieneś przetestować regułę, a nie tylko założyć, że wszystko działa poprawnie.

Aby sprawdzić:

1. Czy reguła znajduje się we właściwym miejscu?
2. Czy Log firewall traffic jest aktywne?
3. Czy po zmianie zasad licznik trafień został zresetowany, czy utworzono nowy, wyraźny test?
4. Czy reguła jest zgodna z Przeglądarką dziennika?
5. Czy wyświetlany jest oczekiwany Firewall Rule ID?
6. Czy żądana reguła NAT ma zastosowanie?
7. Czy DNS działa?
8. Czy filtry sieciowe IPS, Application Control i TLS Inspection zostały zastosowane zgodnie z oczekiwaniami?
9. Czy występują jakieś nieoczekiwane spadki lub błędy SSL/TLS?

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

W przypadku zmian produktywnych przydatne jest małe porównanie przed i po:

• Istnieje punkt kopii zapasowej lub przywracania: Przywracanie jest nadal możliwe, jeśli reguła powoduje skutki uboczne.
• Zanotowano ścieżkę audytu lub bilet zmiany: Później będzie jasne, kto i kiedy dokonał zmiany.
• Przypadek testowy zdefiniowany wcześniej: Sukcesu nie ocenia się wyłącznie na podstawie uczuć.
• Tylko jedna zmiana na test: Przyczyna i skutek pozostają identyfikowalne.
• Log Viewer sprawdzono lub logi centralne: Widoczne są prawdziwe Rule ID i NAT ID.
• Udokumentowana decyzja o demontażu: Tymczasowe zasady testów nie pozostają trwale aktywne.

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

Regularna obsługa i przegląd

Reguła zapory 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, zbyt ogólnych Services lub reguł bez właściciela.

W przypadku regularnych przeglądów warto zastosować prostą procedurę:

• Czy reguła nadal jest atakowana? Nieużywane reguły często można później wyłączyć i usunąć.
• Czy źródło jest nadal poprawne? Sieci klienckie, sieci serwerów i obszary VPN zmieniają się z biegiem czasu.
• Czy Any jest nadal uzasadnione? Szerokie źródła, cele lub Services powinny być celowo udokumentowane.
• Czy rejestrowanie jest aktywne i przydatne? Bez logów późniejsze analizy i audyty są znacznie słabsze.
• Czy NAT, filtry sieciowe, IPS i TLS Inspection nadal pasują? Funkcje zabezpieczeń mogą działać inaczej po aktualizacjach, zmianach aplikacji lub zmianach certyfikatów.
• Czy istnieje data ważności? Tymczasowe zasady projektu lub wsparcia pozostaną trwale aktywne.

W przypadku reguł 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, zatwierdzeń 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. Zbyt wiele podobnych reguł powoduje, że lista jest zagmatwana, ale reguły, które są zbyt podsumowane, szybko stają się zbyt szerokie. Prosta decyzja pomaga przed zapisaniem czegoś w WebAdmin:

• 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: Utwórz własną regułę. Filtry internetowe, IPS, TLS Inspection, NDR lub rejestrowanie można sprawdzić osobno.
• Tymczasowy dostawca usług lub dostęp do pomocy technicznej: Utwó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ź własną regułę lub strefę. Różne zagrożenia nie powinny znikać w jednej regule internetowej klienta.
• Zasada jest niejasna lub stara: Dezaktywuj i najpierw obserwuj. Bezpośrednie usunięcie odbiera możliwość kontrolowanego sprawdzania trafień, dzienników i zależności.
• Jedna zasada z pewnością jest niepotrzebna po sprawdzeniu: 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 ten przepływ 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 grupy reguł.
3. Zdecyduj, czy istniejąca reguła ma zostać rozszerzona, czy też reguła niestandardowa jest czystsza.
4. Zaplanuj tworzenie kopii zapasowych, ścieżkę audytu i przypadek testowy pod kątem produktywnych zmian.
5. Po zapisaniu sprawdź decyzję Log Viewer, Rule ID, NAT i powiązane funkcje bezpieczeństwa.

Jeśli decyzja nie zostanie podjęta głównie z powodu braku dokumentacji, najpierw należy rzetelnie udokumentować Sophos Firewall zasady. 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, Test zasad i Packet Capture.

Poprawnie klasyfikuj liczniki trafień

Liczniki trafień pomagają w czyszczeniu, ale nie stanowią kompletnego dowodu. 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ń.

Jeśli chcesz czysto zdefiniować nowy test, możesz zresetować licznik danych reguły. Nie zastępuje to sprawdzania dziennika, ale pomaga sprawdzić, czy ta reguła ponownie przetwarza ruch w oknie testowym. Reports > Dashboards > Traffic dashboard > Allowed policies jest również przydatny do oceny przesyłanych danych.

Umożliwia śledzenie zmian

Przed poważnymi zmianami reguł powinna być dostępna kopia zapasowa. 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.

Dostosowując 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, filtry sieciowe lub TLS Inspection.

Typowe błędy

Reguła jest za daleko w dół: Bardziej ogólna reguła powyżej dopasowuje ruch w pierwszej kolejności.

Ź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 Services lub grupy usług.

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

IPv6 został zapomniany: IPv4 jest odpowiednio regulowany, ale IPv6 działa według innych zasad lub pozostaje nieświadomie otwarty.

Grupa reguł jest zdecydowanie pomieszana: 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 lub nie ma deszyfrowania.

Filtr sieciowy nie działa: Nie ustawiono żadnej polityki sieciowej, zły użytkownik, zły Source zone lub QUIC nie jest zablokowany.

Dopasowywanie użytkowników nie działa: Uwierzytelnianie, logowanie jednokrotne w usłudze AD, 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 zasada IPS, opcja serwera proxy lub opcja skanowania poczty e-mail mogą przerwać legalny ruch.

Jeśli po wykonaniu tych punktów nie będzie jasne, dlaczego ruch przebiega inaczej niż oczekiwano, powinieneś kontynuować sprawdzanie w sposób zorganizowany za pomocą Log Viewer, testera zasad i Packet Capture. Odpowiednia procedura jest opisana w Testuj regułę zapory sieciowej za pomocą Log Viewer, Test zasad i Packet Capture.

Często zadawane pytania