Prawidłowe planowanie stref i interfejsów Sophos Firewall

Strefa grupuje interfejsy o podobnym poziomie zaufania. Interfejs jest połączeniem fizycznym lub wirtualnym, na przykład Port1, VLAN, LAG albo interfejsem RED lub XFRM. Każdy powiązany interfejs należy dokładnie do jednej strefy; porty fizyczne mogą też pozostać niepowiązane.

Ważne: strefa nie zezwala automatycznie na ruch. Także między dwoma interfejsami w strefie LAN potrzebna jest odpowiednia reguła zapory LAN-to-LAN. Dostęp do samej zapory, na przykład do WebAdmin, SSH lub DNS, jest dodatkowo kontrolowany przez Device Access.

Bezpośrednia konfiguracja stref i interfejsów

Tworzenie strefy

Własną strefę tworzy się w czterech krokach w Network > Zones > Add:

1. Nadać jednoznaczną nazwę, na przykład Server, Management, Guest lub IoT.
2. Jako Type wybrać LAN albo DMZ.
3. W sekcji Device Access zezwolić tylko na te lokalne usługi zapory, które rzeczywiście muszą być dostępne z tej strefy.
4. Zapisać konfigurację.

Następnie strefa powinna być widoczna w Network > Zones i dostępna w regule zapory jako Source zone lub Destination zone. Ruch produkcyjny może przez nią przechodzić dopiero po przypisaniu do niej co najmniej jednego interfejsu.

Własne strefy można tworzyć wyłącznie jako LAN albo DMZ. Nie można tworzyć dodatkowych stref WAN ani VPN. SFOS automatycznie przypisuje interfejsy VPN do strefy VPN. Zapora obsługuje łącznie do 100 stref.

Konfiguracja interfejsu fizycznego

Istniejący port edytuje się przez Edit interface w Network > Interfaces:

1. Nadać czytelną wartość Name, na przykład Core Switch Trunk lub MPLS Provider.
2. Wybrać właściwą Network zone.
3. Skonfigurować IPv4 i w razie potrzeby IPv6.
4. Dla interfejsów WAN sprawdzić Gateway, a w razie potrzeby także MTU i MSS.
5. Zapisać, a następnie sprawdzić stan łącza, stan bramy i Log Viewer.

Konfigurację Gateway otrzymują tylko interfejsy w strefie WAN. Interfejsy wewnętrzne zwykle mają adresację statyczną, natomiast połączenia WAN mogą być skonfigurowane statycznie, przez DHCP albo PPPoE.

W konkretnych zadaniach pomagają bardziej szczegółowe instrukcje:

• Konfiguracja i test interfejsu VLAN
• Konfiguracja interfejsu LAG
• Konfiguracja Sophos SD-RED
• Zabezpieczenie Device Access
• Konfiguracja Site-to-Site IPsec VPN

Planowanie modelu stref

Rozróżnienie strefy, interfejsu i obiektu sieciowego

Te trzy elementy pełnią różne funkcje:

• Strefa: opisuje obszar bezpieczeństwa, z którego pochodzi ruch lub do którego jest kierowany.
• Interfejs: fizycznie albo wirtualnie łączy zaporę z siecią.
• Obiekt sieciowy: określa konkretny adres IP lub podsieć w regule.

Reguła jest precyzyjna dopiero wtedy, gdy zgadzają się zarówno strefa, jak i obiekt sieciowy. Połączenie Source zone: LAN z Source networks: Any jest często niepotrzebnie szerokie. Z drugiej strony poprawny obiekt sieciowy nie pomoże, jeżeli pakiet dociera przez inną strefę niż określona w regule.

Strefy standardowe mają ustalone zadania:

• LAN dla sieci wewnętrznych
• WAN dla połączeń z operatorem i internetem
• DMZ dla wystawionych lub szczególnie odizolowanych systemów
• WiFi dla środowisk WLAN
• VPN dla tuneli Remote Access i Site-to-Site

Własne strefy LAN nadają się na przykład dla segmentów Client, Server, Management, Guest, IoT, VoIP, Backup lub OT. Własna strefa DMZ pasuje do publikowanych serwerów, Reverse Proxy i innych systemów, których dostęp do sieci wewnętrznej powinien być ściśle ograniczony.

Nie każdy VLAN wymaga osobnej strefy. Kilka sieci VLAN można połączyć, jeśli mają ten sam poziom zaufania, reguły zapory i ustawienia Device Access. Jeżeli różnią się dozwolonymi celami, dostępem administracyjnym albo funkcjami ochronnymi, osobna strefa jest zwykle bardziej przejrzysta.

Dla użytkowników VPN lub tuneli między lokalizacjami nie tworzy się własnych typów stref VPN. Separację w strefie VPN realizuje się za pomocą precyzyjnych obiektów sieciowych, użytkowników i reguł zapory.

Określenie kierunków dostępu przed utworzeniem reguł

Przed konfiguracją wystarczy krótka lista dozwolonych kierunków. Na przykład:

• Client do WAN: wymagane usługi WWW, DNS, NTP i aplikacyjne
• Client do Server: tylko zdefiniowane porty aplikacji
• Guest do WAN: dostęp do internetu bez dostępu do sieci wewnętrznych
• IoT do Server: tylko niezbędne cele, takie jak DNS, NTP lub platforma zarządzająca
• Management do stref wewnętrznych: ściśle ograniczone i rejestrowane usługi administracyjne
• DMZ do LAN: domyślnie zablokowane, dozwolone tylko jawnie wymagane połączenia
• VPN do Server: tylko zatwierdzone cele i usługi

Dla każdego dozwolonego kierunku powinny być znane cel, usługi, potrzeba NAT, sposób rejestrowania oraz osoba odpowiedzialna. Na tej podstawie powstają właściwe reguły. Strukturę, kolejność i dopasowanie wyjaśnia artykuł Prawidłowa konfiguracja reguł Sophos Firewall.

Kontrola przed zmianą

Przed utworzeniem lub przeniesieniem interfejsu należy wyjaśnić co najmniej następujące kwestie:

• strefa i poziom zaufania sieci
• adres IP, podsieć i Default Gateway
• źródło DHCP i serwery DNS
• wymagane lokalne usługi zapory
• reguły zapory i NAT
• routing i SD-WAN
• klient testowy, oczekiwany dostęp i oczekiwany wpis w logu

Zmiany produkcyjne wymagają aktualnej kopii zapasowej, przygotowanej drogi powrotu oraz kontroli w Object usage.

Tworzenie i odbiór VLAN

VLAN tworzy się w Network > Interfaces > Add interface > Add VLAN. Kluczowe są następujące pola:

• Interface: interfejs fizyczny, RED, Bridge albo LAG, na którym dociera tagowany VLAN
• Network zone: obszar bezpieczeństwa sieci VLAN
• VLAN ID: musi być zgodny z konfiguracją przełącznika i ewentualnie Access Point
• IPv4/IPv6 configuration: w wewnętrznych sieciach VLAN zwykle statyczny adres bramy

Przykładowy VLAN dla gości może działać na Port3 z VLAN ID 20, strefą Guest i adresem bramy 192.168.20.1/24. Na przełączniku VLAN 20 musi być tagowany na uplinku do Port3, a port kliencki lub SSID dla gości przypisuje urządzenia końcowe do tego VLAN-u.

Zapora może poprawnie wyświetlać interfejs, mimo że przełącznik wysyła VLAN przez niewłaściwy port, bez tagu albo z innym VLAN ID. VLAN jest więc gotowy dopiero po sprawdzeniu całej ścieżki:

1. Sprawdzić na zaporze VLAN ID, Parent Interface, strefę, adres IP i maskę.
2. Skonfigurować uplink do zapory jako Trunk z tagowanym VLAN-em.
3. Przypisać Access Port lub SSID do właściwego VLAN-u.
4. Na kliencie testowym sprawdzić DHCP, Gateway i DNS.
5. Przetestować dozwolony dostęp wewnętrzny oraz celowo zabronione połączenie.
6. Sprawdzić dostęp do internetu i potwierdzić oczekiwany Firewall Rule ID w Log Viewer.

Dla ruchu wewnętrznego NAT zwykle nie jest potrzebny. Jeśli klient otrzymuje adres, ale nie może korzystać z zapory jako serwera DNS ani jej pingować, najpierw należy sprawdzić Device Access. Pełną procedurę z tagowaniem na przełączniku i DHCP zawiera artykuł Konfiguracja i test VLAN w Sophos Firewall.

Sophos nie podaje dla urządzeń XGS stałego limitu liczby sieci VLAN na fizyczny Parent Port. Przy dużym obciążeniu, wielu sieciach VLAN lub środowiskach HA kilka uplinków albo LAG może jednak ułatwić eksploatację i diagnostykę.

Wybór właściwego typu interfejsu

Alias

Alias dodaje kolejny adres IP do istniejącego interfejsu. Jest to szczególnie przydatne, gdy operator udostępnia kilka publicznych adresów IP w tej samej podsieci.

Kilka oddzielnych interfejsów WAN w tej samej podsieci może powodować problemy z ARP i niedostępne bramy. W takim przypadku Alias na istniejącym interfejsie WAN albo odpowiednio zaplanowany LAG jest zwykle lepszym rozwiązaniem. Alias przejmuje stan swojego Parent Interface i nie można go wyłączyć niezależnie.

Bridge

Bridge łączy kilka interfejsów w warstwie 2. Może działać z adresem IP dla ruchu routowanego albo transparentnie, bez adresu IP. Dla nowych segmentowanych sieci VLAN-y są zwykle bardziej przejrzyste; Bridge sprawdza się raczej podczas migracji lub w świadomie zaplanowanych środowiskach transparentnych.

Obowiązują przy tym istotne ograniczenia:

• Bridge nie obsługuje Dynamic DNS, DHCP Client, PPPoE ani IPsec VPN.
• Ruch między Bridge Members może nadal wymagać reguł zapory, na przykład LAN-to-LAN.
• Nie można aktywować HA, dopóki na Bridge działa STP.
• Jeśli VLAN Filter jest włączony, ale nie zezwolono na żaden VLAN, zapora odrzuca wszystkie tagowane ramki; nie wpływa to na ruch nieotagowany.
• Ruch przez Bridge bez adresu IP może zostać odrzucony bez wpisu w logu, jeśli pasuje do reguły Web Proxy albo NAT.

W przypadku transparentnego Bridge należy więc sprawdzić, czy Web Proxy Filtering lub Source Translation są rzeczywiście potrzebne.

Sophos Known Issues List opisuje ponadto błąd dotyczący konkretnych kompilacji SFOS 22.0 GA Build 411 i MR1 Build 490: jeśli ruch przez Bridge podlega SNAT lub MASQ, a źródło i cel znajdują się za tym samym fizycznym Bridge Member, pakiety odpowiedzi mogą zostać odrzucone przez Hairpin Filter bez pojawienia się w drppkt. Dotyczy to również sytuacji, gdy aktywnie używany jest tylko jeden Bridge Member. Problem nie występuje przy ruchu przez różne fizyczne Bridge Members ani bez SNAT/MASQ. Nowsze kompilacje, takie jak 22.0 MR2 Build 546, nie są wymienione jako dotknięte problemem w aktualnej Known Issues List.

Jeśli zawodzą tylko niektóre połączenia przez Bridge, należy wspólnie sprawdzić topologię i NAT, testowo zrezygnować z Source Translation albo zastosować projekt routowany. Osobny przypadek ruchu VLAN do zapory w SFOS 22 opisuje artykuł Kontrola Bridge VLAN po aktualizacji do SFOS 22.

Bridge przez RED może rozszerzyć sieć warstwy 2 między lokalizacjami, ale powinien pozostać uzasadnionym wyjątkiem.

Broadcast, ARP i nieznany ruch Unicast przechodzą wtedy przez połączenie WAN. Projekt routowany z osobnymi podsieciami lokalizacji i precyzyjnymi regułami zapory jest stabilniejszy, lepiej się skaluje i łatwiej go diagnozować.

LAG

Link Aggregation Group łączy od dwóch do czterech interfejsów fizycznych w jeden logiczny uplink. Na nim można następnie tworzyć sieci VLAN.

Typowe tryby pracy to:

• Active-Backup: jedno łącze jest aktywne, a drugie przejmuje ruch w razie awarii.
• LACP (802.3ad): kilka łączy może działać równolegle; zapora i przełącznik muszą mieć identyczną konfigurację.

Członkami mogą być niepowiązane interfejsy fizyczne ze statyczną konfiguracją. Interfejsy PPPoE, Cellular WAN i WLAN są wykluczone. W LACP porty muszą mieć ten sam typ i tę samą prędkość.

xmit-hash-policy rozdziela połączenia między łącza. Pojedyncze połączenie TCP zwykle nie staje się przez to szybsze, ponieważ pozostaje na jednym łączu. LAG zapewnia przede wszystkim nadmiarowość i większą łączną przepustowość dla wielu równoległych połączeń.

XFRM dla route-based IPsec

Dla połączenia route-based IPsec SFOS automatycznie tworzy interfejs XFRM w strefie VPN. Dotyczy to zarówno Any-to-any, jak i połączeń z Traffic Selectors:

• Any-to-any: automatycznie utworzonemu XFRM trzeba przypisać adres IP w Network > Interfaces. Następnie trasy statyczne, SD-WAN albo dynamiczne określają ruch kierowany do tunelu.
• Traffic Selectors: SFOS tworzy XFRM, a podczas zestawiania tunelu także automatyczną trasę statyczną. Do tego XFRM nie można przypisać własnego adresu IP ani dodać własnej trasy.

W obu przypadkach ruch VPN wymaga odpowiednich reguł zapory. W Administration > Device access usługa IPsec dla strefy WAN zezwala na przychodzące żądania połączeń IPsec. Ping w tunelu włącza się osobno dla strefy VPN.

XFRM nie wyłącza się bezpośrednio w Network > Interfaces, lecz przez powiązane połączenie w Site-to-site VPN > IPsec. Przy problemach z fragmentacją istotne są MTU i MSS; procedurę kontroli zawiera artykuł Sprawdzanie MTU i MSS przy problemach z VPN.

RED

Interfejs RED łączy zdalną lokalizację przez szyfrowany tunel. Tryb pracy określa, jaka część ruchu przechodzi przez centralę:

• Standard/Unified: centralna zapora zarządza i filtruje cały ruch lokalizacji. Awaria tunelu może również odciąć dostęp do internetu.
• Standard/Split: przez tunel przechodzą tylko zdefiniowane sieci docelowe; ruch internetowy wychodzi lokalnie i nie jest centralnie filtrowany.
• Transparent/Split: RED działa transparentnie w istniejącej sieci. Jest to elastyczne, ale trudniejsze do zaplanowania i diagnozowania.
• Manual/Split: konfiguracja sieci jest w większym stopniu wykonywana ręcznie i może zapewnić lokalną niezależność.

Usługa RED musi być aktywna w System services > RED. Połączenie zwykle wymaga TCP 3400, UDP 3410 oraz NTP przez UDP 123. Muszą również działać DNS, prawidłowy czas systemowy i wychodzący dostęp do internetu.

Zachowanie VLAN zależy od modelu RED, trybu pracy, trybu portów LAN oraz konfiguracji WLAN. Sophos zaleca Standard/Unified, gdy za RED używane są sieci VLAN; w SD-RED 60 tagowanie VLAN jest możliwe tylko w tym trybie. WLAN z Bridge to VLAN podlega odrębnym regułom. Wybór trybu, provisioning, stany LED i diagnostykę opisuje artykuł Konfiguracja Sophos SD-RED.

Kontrola stanu i Device Access

Stan interfejsu

W Network > Interfaces wartości stanu wskazują, czy najpierw należy sprawdzić łącze, czy politykę:

• Not configured: nie przypisano strefy
• Connected: skonfigurowany i połączony
• Connecting: właśnie pobiera adres, na przykład przez DHCP
• Disconnected: adres został zwolniony
• Disconnecting: adres jest właśnie zwalniany
• Unplugged: brak połączenia fizycznego; w przypadku WiFi może brakować Access Point albo Wireless Network
• Not available: skonfigurowany FleXi Port bez zainstalowanego modułu FleXi Port

Przy stanie Not configured albo Unplugged reguły zapory nie są pierwszym miejscem diagnostyki. Najpierw należy sprawdzić Zone Binding, kabel, SFP, prędkość portu, port przełącznika oraz DHCP lub PPPoE.

Lokalne usługi zapory

W Administration > Device access dla każdej strefy określa się dostępność lokalnych usług, takich jak HTTPS, SSH, User Portal, VPN Portal, DNS, Ping/Ping6, Captive Portal, RADIUS SSO czy Wireless Protection.

Zezwolenia te dotyczą samej zapory. Ruch przechodzący między sieciami kontrolują reguły zapory. HTTPS i SSH powinny być dozwolone wyłącznie z sieci zarządzającej albo przez precyzyjną Local service ACL exception rule. Usługa DNS jest wymagana, jeżeli klienci używają zapory jako serwera DNS.

⚠️ Jeśli klienci mogą używać Web Proxy zapory, SFOS traktuje żądania HTTP i HTTPS jako wewnętrzne żądania Proxy. W rezultacie WebAdmin, Captive Portal, VPN Portal lub User Portal mogą być dostępne, mimo że odpowiednia usługa jest wyłączona dla strefy klienta. W takim projekcie trzeba osobno sprawdzić dostęp do Proxy i lokalnych portali.

Bezpieczna obsługa zależności i zmian

Object Usage przed edycją lub usunięciem

Zone Binding, DNS, Gateways, SD-WAN, Interface Hosts, VLAN, Dynamic DNS, DHCP, reguły zapory, NAT i VPN mogą zależeć od tego samego interfejsu. Object usage pokazuje te odwołania.

Wyświetlany licznik jest automatycznie aktualizowany tylko raz dziennie. Przed zmianą lub usunięciem należy więc kliknąć Refresh i udokumentować ważne zależności.

Po wyłączeniu interfejsu jego konfiguracja pozostaje zachowana. Tunele IPsec, dla których zapora jest inicjatorem, są rozłączane natychmiast. Tunele, w których zapora odpowiada, oraz połączenia Remote Access kończą się najpóźniej z powodu bezczynności albo Dead Peer Detection.

Usunięcie interfejsu wirtualnego może spowodować usunięcie zależnych reguł zapory, konfiguracji DHCP, wpisów ARP, tras, Interface Hosts i innych odwołań. Interfejsy Alias przejmują stan Parent Interface, a interfejsami XFRM zarządza się przez połączenie IPsec.

HA i zmiany zdalne

Dedykowane interfejsy HA Link należą do strefy DMZ. Inne interfejsy monitorowane lub używane do administracji mogą znajdować się w innych strefach.

Active-Active HA wymaga interfejsów skonfigurowanych statycznie. Cellular WAN jest wyłączany w HA. Active-Passive może korzystać z dynamicznie adresowanych interfejsów WAN, ale połączenia takie jak PPPoE nie zawsze są przejmowane wraz z sesją podczas Failover.

Przed zmianą produkcyjną należy:

1. Udokumentować konfigurację i zależności.
2. Przygotować okno serwisowe, moment wycofania zmiany, kopię zapasową i konkretną drogę powrotu.
3. Przetestować niezależny dostęp administracyjny, na przykład Sophos Central, drugie łącze WAN, osobną sieć zarządzającą albo pomoc osoby na miejscu.
4. Przygotować klienta testowego lub jednoznaczny ruch testowy, a następnie dodać i sprawdzić nową strefę lub nową ścieżkę.
5. Skontrolować łącze, IP, Gateway, DHCP, DNS, reguły zapory, NAT i Device Access.
6. Usunąć stare obiekty dopiero wtedy, gdy nowa ścieżka działa stabilnie.

Dla VLAN Trunk droga powrotu powinna uwzględniać poprzednie VLAN ID, Native VLAN i profil portu przełącznika. Przy zmianach WAN ważne są wartości operatora i trasy SD-WAN, a przy XFRM dodatkowo tunel, routing i oba kierunki reguł zapory.

Systematyczna diagnostyka

Przyczynę zwykle można szybciej zawęzić, zaczynając od objawu:

• Interface jest unbound lub disabled: sprawdzić Zone Binding i stan. Portu fizycznego się nie usuwa; jego konfigurację można usunąć, ustawiając Zone na None.
• VLAN nie działa: porównać VLAN ID, Parent Interface, Trunk, Tagged/Untagged i Native VLAN.
• Zapora nie odpowiada na Ping, HTTPS lub DNS: sprawdzić Device Access i Local Service ACL, a nie najpierw zwykłą regułę zapory.
• Ruch wewnętrzny jest blokowany: sprawdzić Source zone, Destination zone, obiekty sieciowe, routing, Services i kolejność reguł.
• WAN Gateway pozostaje nieaktywny: sprawdzić łącze, IP, Gateway, dane dostępowe PPPoE i WAN Link Manager.
• Kilka portów WAN znajduje się w tej samej podsieci: unikać problemów z ARP i rozważyć Alias albo LAG.
• SFP lub Port Speed nie pasuje: porównać Transceiver, kabel, Breakout i prędkość po obu stronach.
• VPN lub PPPoE działa niestabilnie: sprawdzić MTU i MSS.

Właściwą diagnostykę najlepiej prowadzić w następującej kolejności:

1. Network > Interfaces: łącze, IP, Zone i Gateway
2. Network > Zones: typ strefy i Device Access
3. Hosts and services: obiekty sieciowe i Service Objects
4. Firewall rules: kierunek, kolejność, Services i Logging
5. NAT rules: Original i Translation
6. Log viewer: Rule ID albo przyczyna odrzucenia
7. Diagnostics > Tools > Packet capture: wejście pakietu i jego dalsze przekazanie

Jeśli reguła wygląda poprawnie, ale nie jest dopasowywana, pomaga artykuł Reguła zapory nie działa. Przepływ pakietów wyjaśnia artykuł Korzystanie z Packet Capture w WebAdmin.

Lista kontrolna eksploatacji

• strefy zaplanowane i udokumentowane według poziomu zaufania
• brak pomylenia strefy, interfejsu i obiektu sieciowego
• sprawdzone VLAN ID, Parent, Trunk i Gateway
• ograniczony Device Access, zwłaszcza dla HTTPS, SSH, DNS, Ping i portali
• utworzone reguły zapory z konkretnymi strefami, sieciami, usługami i Logging
• sprawdzony Alias dla dodatkowych adresów IP operatora w tej samej podsieci
• przetestowane DHCP, DNS, NTP, routing i w razie potrzeby NAT
• zaktualizowane i sprawdzone Object Usage przed zmianami
• przygotowany niezależny dostęp administracyjny i droga powrotu
• sprawdzone po zmianie stan łącza, Log Viewer i Packet Capture

FAQ