Konfiguracja stref i interfejsów Sophos Firewall

Strefy i interfejsy należą do najważniejszych podstaw Sophos Firewall. Dobrze zaplanowane ułatwiają późniejsze reguły firewall, NAT, VPN, Web Protection i troubleshooting. Jeśli skonfiguruje się je zbyt szybko, łatwo powstaje środowisko z nieczytelnymi regułami albo usługami zarządzania dostępnymi z niewłaściwych miejsc.

Strefa to logiczna grupa bezpieczeństwa. Interface to fizyczne lub wirtualne połączenie, na przykład Port1, VLAN, Bridge, LAG, Alias, RED interface albo XFRM interface dla route-based VPN. Każdy interface należy dokładnie do jednej strefy. Reguły firewall intensywnie korzystają później z tych stref, dlatego struktura stref powinna być planowana nie tylko technicznie, ale również pod kątem bezpieczeństwa.

Dlaczego strefy są ważne

W Sophos Firewall strefy są czymś więcej niż tylko wizualnym grupowaniem. Definiują obszary bezpieczeństwa i są używane w wielu miejscach:

• Reguły firewall korzystają z Source zone i Destination zone.
• Device Access kontroluje per strefa, które lokalne usługi firewalla są dostępne.
• NAT, SD-WAN, VPN, Web Protection i logi są łatwiejsze do zrozumienia przy czystych strefach.
• Troubleshooting jest prostszy, bo od razu widać, z którego obszaru bezpieczeństwa pochodzi pakiet i dokąd ma trafić.

Dobra segmentacja stref nie zapobiega automatycznie wszystkim błędom, ale wymusza jasne granice. Sieć klientów, sieć serwerów, WiFi dla gości i DMZ nie powinny być wszystkie traktowane jako LAN, jeśli mają różne ryzyka i reguły. W przeciwnym razie później pojawiają się zbyt szerokie reguły Allow, niejasne wyjątki i niepotrzebnie otwarty dostęp administracyjny.

Dobre strefy zawsze odpowiadają na pytanie: które sieci mają ten sam poziom zaufania i mogą być traktowane podobnie? Jeśli dwie sieci potrzebują różnych uprawnień, innych wymagań dotyczących logowania albo osobnego dostępu administracyjnego, warto utworzyć osobną strefę albo przynajmniej bardzo świadomy koncept reguł.

Zrozumieć standardowe strefy

Sophos Firewall zawiera kilka standardowych stref:

Standardowe strefy znajdują się w Network > Zones. Własne strefy można tworzyć jako typ LAN albo DMZ. Dodatkowych stref WAN lub VPN nie da się po prostu dowolnie utworzyć, ponieważ te typy stref mają w firewallu specjalne funkcje.

Ważne: strefa nie oznacza automatycznego zezwolenia. Także między dwoma interfejsami w tej samej strefie, zależnie od kierunku i scenariusza, potrzebne są odpowiednie reguły firewall. Sophos wskazuje w dokumentacji, że ruch między dwoma interfejsami w strefie LAN nie jest automatycznie dozwolony, lecz wymaga odpowiedniej reguły LAN-to-LAN.

Zaplanować strefy przed utworzeniem

Przed utworzeniem warto zapisać, które sieci mają różne wymagania bezpieczeństwa. Typowe przykłady:

• LAN stanowisk roboczych
• Sieć serwerów
• Sieć zarządzania
• DMZ
• WiFi dla gości
• VoIP
• Sieć kamer lub IoT
• Sieć produkcyjna
• Klienci VPN
• MPLS lub połączenia między lokalizacjami

Osobna strefa ma sens, gdy sieć potrzebuje własnych reguł, własnego Device Access albo innego poziomu zaufania. Kilka VLANów może też znajdować się w tej samej strefie, jeśli mają być traktowane identycznie. Zbyt wiele stref nie zwiększa automatycznie bezpieczeństwa konfiguracji. Pomagają tylko wtedy, gdy stoją za nimi jasne reguły.

Dla wielu małych i średnich środowisk taka struktura bazowa jest dobrym początkiem:

Nie każdy VLAN automatycznie potrzebuje własnej strefy. Jeśli kilka VLANów klienckich otrzymuje dokładnie te same reguły firewall, tę samą Web Policy i ten sam Device Access, mogą pozostać we wspólnej strefie klienckiej. Jeśli jednak jeden VLAN może sięgać do serwerów, drugi tylko do Internetu, a trzeci nie powinien mieć żadnego dostępu do lokalnych usług firewalla, rozdzielenie trzeba świadomie zamodelować.

Dobre podejście:

Utworzyć nową strefę

Otwiera się Network > Zones i klika Add.

1. Nadać krótką, jednoznaczną nazwę, na przykład Server, Guest, Management lub MPLS.
2. Wybrać typ LAN albo DMZ.
3. W Device Access świadomie określić, które lokalne usługi firewalla mają być osiągalne z tej strefy.
4. Zapisać.

LAN czy DMZ jako typ strefy?

Przy własnych strefach w Sophos Firewall zwykle można wybrać LAN albo DMZ. Oba typy grupują interfejsy, aby później używać ich czytelnie w regułach, Device Access i policies. Różnica leży przede wszystkim w idei bezpieczeństwa danej strefy.

LAN stosuje się dla wewnętrznych, zasadniczo zaufanych sieci. Należą do nich na przykład sieci klienckie, wewnętrzne sieci serwerów, management, VoIP, drukarki albo wewnętrzne VLANy. Także przy strefie LAN obowiązuje zasada: ruch między interfejsami nie jest automatycznie dozwolony. Jeśli dwie strefy LAN albo dwa interfejsy w jednej strefie LAN mają ze sobą rozmawiać, potrzebne są odpowiednie reguły firewall.

DMZ stosuje się dla sieci o wyższym ryzyku albo z wyraźną izolacją. Typowe przykłady to publiczne serwery WWW, reverse proxies, mail gateways, jump hosts albo systemy dostępne z kilku obszarów bezpieczeństwa. DMZ powinna być zaplanowana tak, aby miała tylko niezbędne połączenia do sieci wewnętrznych. Jeśli serwer w DMZ zostanie przejęty, nie może z tego wynikać szeroki dostęp do wewnętrznego LAN.

Prosta zasada:

Interfejsy HA również należą do strefy DMZ. Dla zwykłych sieci administracyjnych lub klienckich LAN jest najczęściej właściwszym typem.

Dla wewnętrznej sieci adminów HTTPS może mieć sens. Dla zwykłych sieci klienckich lub gościnnych dostęp administracyjny powinien być unikany. Ping/ping6 bywa pomocny przy troubleshooting, ale powinien być włączany świadomie. DNS jest potrzebny tylko wtedy, gdy klienci w tej strefie używają firewalla jako serwera DNS.

⚠️ Device Access to nie to samo co reguła firewall. Dostęp do lokalnych usług firewalla, takich jak WebAdmin, SSH, User Portal, DNS lub Ping, kontroluje się przez Administration > Device access i lokalne wyjątki ACL.

Skonfigurować interface

Interfaces znajdują się w Network > Interfaces. Fizyczny port może działać na przykład jako LAN, WAN albo DMZ. Dodatkowo tworzy się wirtualne interfejsy, takie jak VLAN, Bridge, LAG, RED albo XFRM.

Dla fizycznego interfejsu szczególnie ważne są:

Tylko interfaces w strefie WAN otrzymują konfigurację gateway. Interfejsy wewnętrzne zwykle adresuje się statycznie. Przy łączach operatorskich sensowne może być DHCP albo PPPoE.

Opisowe nazwy są ważne. PortD za sześć miesięcy powie niewiele. Server VLAN, MPLS Provider, Guest WiFi albo Core Switch Trunk pomagają w pracy znacznie bardziej.

Utworzyć VLAN interface

VLAN interface tworzy się w Network > Interfaces > Add interface > Add VLAN. Najważniejsze są Parent Interface, Zone, VLAN ID i konfiguracja IP.

Parent Interface to fizyczny port albo LAG, na którym przychodzi otagowany VLAN. Jeśli switch wysyła VLAN innym portem, untagged albo z błędnym VLAN ID, firewall będzie widział VLAN interface, ale klienci nie będą go niezawodnie osiągać.

Dla wewnętrznych VLANów zwykle używa się statycznego adresu IP na firewallu, na przykład jako Default Gateway dla tego VLANu. Strefa decyduje później, które reguły firewall, Web Policies i ustawienia Device Access będą działać. Dlatego przy tworzeniu VLANu nie powinno się wpisywać tylko adresu IP, lecz od razu zastanowić się, czy VLAN należy raczej do Client, Server, Management, Guest, DMZ czy innej strefy.

Prawidłowo czytać status interfejsu

W Network > Interfaces Sophos Firewall pokazuje komunikaty statusu. Są one bardzo pomocne w troubleshooting, bo szybko pokazują, czy interface jest tylko źle skonfigurowany, czy faktycznie nie ma linku.

Jeśli interface nieoczekiwanie pokazuje Not configured lub Unplugged, nie należy najpierw szukać reguł firewall. Najpierw sprawdza się Zone Binding, link, SFP/transceiver, kabel, port switcha oraz przy DHCP/PPPoE przydział adresu.

Umiejscowić VLAN, Bridge, LAG, Alias i RED

Sophos Firewall obsługuje różne typy interfejsów. Dla początkujących najważniejsze jest, kiedy który typ ma sens.

Dla nowych instalacji VLAN na jasno zdefiniowanym uplinku do switcha jest zwykle czystszy niż duża Bridge przez wiele portów. Bridge może być praktyczna podczas migracji lub w bardzo prostych konfiguracjach, bo kilka portów traktuje się jak jeden wspólny segment Layer 2. To jest jednak także wada: granice bezpieczeństwa, domeny broadcast i źródła błędów są mniej widoczne.

Dlatego Bridges zalecamy tylko celowo, nie jako standardowy projekt. W praktyce mają kilka wad:

• Kilka portów dzieli ten sam segment Layer 2, przez co broadcasty i zakłócenia łatwiej dotyczą wielu urządzeń.
• Reguły firewall są mniej przejrzyste, bo separacja nie jest widoczna przez własne interfaces, VLANs i zones.
• Troubleshooting jest trudniejszy, bo trzeba wspólnie analizować packet flow, MAC learning, STP i konfigurację switcha.
• Późniejsza segmentacja jest trudniejsza, jeśli z prostej Bridge mają powstać oddzielne sieci client, server, guest lub management.
• Projekty HA, VLAN, DHCP lub Device Access szybko stają się nieczytelne, jeśli zbyt wiele funkcji przebiega przez Bridge.

Bridges można w Sophos Firewall tworzyć przez fizyczne interfaces, RED interfaces, VLANs lub LAGs. Mogą działać z własnym adresem IP albo bez. Tu często pojawiają się nieporozumienia:

• Bez adresu IP Bridge pracuje transparentnie, ale nie może być użyta jak normalny routed interface.
• Jeśli routing na Bridge jest potrzebny, Bridge musi otrzymać adres IP.
• Dla ruchu między Bridge members nadal potrzebne są odpowiednie reguły firewall między zaangażowanymi strefami, na przykład LAN do LAN.
• STP może mieć sens, gdy istnieją ścieżki redundantne i trzeba uniknąć bridge loops.
• VLAN filters i EtherType filters mogą pomóc ograniczyć ruch Layer 2 przechodzący przez Bridge.
• Sophos wskazuje, że ruch przez Bridge interfaces bez adresu IP może zostać odrzucony, jeśli trafi na regułę firewall z Web Proxy Filtering albo regułę NAT. Takie drops nie są logowane. Przy NAT trzeba wtedy szczególnie uważać na Source Translation lub Override Source Translation.

Ten ostatni punkt jest ważny: jeśli przez Bridge nagle nie widać logów, chociaż ruch nie działa, problem nie zawsze leży w Log Viewer. Może leżeć w trybie Bridge, NAT albo Web Proxy Filtering.

Jeśli VLANy istnieją już na switchu, firewall powinien przejąć je świadomie jako własne VLAN interfaces. Daje to wyraźniejsze strefy, czystsze reguły firewall i jest zwykle lepiej utrzymywalne długoterminowo.

RED Bridge: rozciąganie sieci między lokalizacjami

Technicznie można włączyć RED interfaces do Bridge i w ten sposób rozciągnąć sieć Layer 2 między lokalizacjami. Może to pomóc w szczególnych przypadkach, na przykład gdy aplikacja koniecznie musi pozostać w tej samej podsieci albo podczas migracji bez natychmiastowych zmian IP.

Taki projekt zalecalibyśmy bardzo ostrożnie. Bridge przez RED wydłuża domenę Layer 2 przez tunel. Broadcasts, ARP, unknown unicast packets i inne efekty Layer 2 przechodzą wtedy przez połączenie WAN lub Internet. To może pogorszyć wydajność i utrudnić analizę błędów. Jeśli tunel RED jest niestabilny, bezpośrednio wpływa to na rozciągniętą sieć.

W większości przypadków lepszy jest projekt routed: każda lokalizacja ma własne podsieci, firewall routuje między sieciami, a reguły firewall dokładnie definiują, co jest dozwolone. To jest czystsze, lepiej skalowalne i znacznie wygodniejsze przy troubleshooting.

LAG: prawidłowo planować redundancję i przepustowość

Link Aggregation Group (LAG) łączy kilka fizycznych portów w jeden logiczny interface. Ma to sens, gdy potrzebna jest redundancja do core switcha albo większa przepustowość między firewallem a switchem. LAG nie zastępuje jednak czystej segmentacji stref. Interface LAG jest nadal tylko interfejsem, na którym można na przykład uruchomić VLANy albo przypisać strefę.

Sophos Firewall obsługuje przede wszystkim dwa typowe tryby:

Ważne: LACP działa poprawnie tylko wtedy, gdy druga strona jest poprawnie skonfigurowana. Na switchu porty muszą należeć do tej samej LAG group, używać tej samej prędkości i duplexu oraz pasować do konfiguracji firewalla. Jeśli LAG utworzy się tylko na firewallu, ale switch nie zostanie skonfigurowany odpowiednio, często pojawiają się trudne do wyjaśnienia packet loss albo asymetryczne problemy z połączeniem.

Dla LAGs obowiązuje kilka praktycznych ograniczeń:

• LAG w Sophos Firewall składa się z dwóch do czterech fizycznych interfaces.
• Jako członkowie nadają się tylko unbound fizyczne interfaces ze statyczną konfiguracją.
• Interfaces PPPoE, Cellular-WAN i WLAN nie mogą być LAG members.
• Przy LACP (802.3ad) member ports muszą mieć ten sam typ i prędkość.
• xmit-hash-policy określa, jak sessions są rozdzielane między linki. Pojedyncza sesja TCP zwykle nie stanie się nagle szybsza, ponieważ najczęściej pozostaje na jednym linku.

Dla małych środowisk jeden dobrze skonfigurowany trunk port często wystarcza. LAG opłaca się głównie wtedy, gdy core switch ma być podłączony redundantnie, wiele VLANów idzie przez ten sam uplink albo firewall naprawdę potrzebuje większej przepustowości do switcha.

XFRM: rozumieć route-based IPsec jako interface

Interface XFRM należy do tematu route-based IPsec VPN. Nie planuje się go jak zwykłej VLAN albo fizycznego portu, lecz powstaje w kontekście połączenia IPsec. Sophos Firewall tworzy XFRM interface automatycznie, gdy w połączeniu IPsec zarówno lokalne, jak i zdalne podsieci ustawione są na Any.

To ważna różnica względem klasycznych tuneli policy-based IPsec. W route-based VPN nie decyduje tylko IPsec Policy, lecz także routing, reguły firewall i XFRM interface. Daje to większą elastyczność dla złożonych połączeń między lokalizacjami, ale wymaga czystego planowania:

• XFRM interface znajduje się w strefie VPN.
• W Administration > Device access dla strefy WAN musi być dozwolony IPsec, aby połączenie mogło się zestawić.
• Jeśli lokalne lub zdalne podsieci nie są Any, XFRM interface nie zostanie utworzony.
• MTU i MSS są przy route-based VPN szczególnie ważne, ponieważ IPsec dodaje overhead.
• XFRM interface nie wyłącza się bezpośrednio w Network > Interfaces, lecz przez odpowiednie połączenie IPsec w Site-to-site VPN > IPsec.

Dla administratorów XFRM jest ważny zwłaszcza wtedy, gdy SD-WAN routing, dynamic routing lub wiele sieci przez tunel lokalizacyjny mają być sterowane czysto. Jeśli potrzebne jest tylko bardzo proste połączenie Site-to-Site z dwiema stałymi sieciami, klasyczny tunel policy-based jest często łatwiejszy do zrozumienia.

RED: lokalizacje zdalne jako osobny koncept interface

RED interfaces nie są zwykłym portem switcha. RED oznacza Remote Ethernet Device i służy do połączenia zdalnej lokalizacji z Sophos Firewall przez zaszyfrowany tunel. Można to zrealizować dedykowanym sprzętem SD-RED albo połączeniami Firewall-to-Firewall RED.

Przed planowaniem musi być jasne, który tryb pracy jest potrzebny:

Dla wielu firm Standard/Unified jest najczystszą opcją, jeśli lokalizacja ma być w pełni chroniona przez centralny firewall. Wada jest jasna: jeśli tunel RED padnie, lokalizacja może zależnie od projektu stracić także centralnie kontrolowany dostęp do Internetu. Standard/Split zmniejsza tę zależność, ale oznacza też, że lokalny ruch internetowy nie jest już w pełni filtrowany i logowany przez centralny Sophos Firewall.

Przy RED warto wcześnie sprawdzić:

• Usługa RED musi być włączona w System services > RED.
• Do połączenia typowo potrzebne są TCP 3400, UDP 3410 i NTP 123.
• Urządzenia SD-RED potrzebują poprawnego czasu, bo inaczej TLS handshake i zestawienie tunelu mogą się nie udać.
• Przy pierwszym uruchomieniu DHCP na uplinku jest zwykle prostsze, bo urządzenie musi osiągnąć provisioning.
• VLANy nie są tak samo sensowne w każdym trybie RED. Standard/Split i Transparent/Split nie są przeznaczone dla VLAN-tagged frames. Jeśli VLANy za SD-RED są potrzebne, tryb pracy trzeba wybrać szczególnie starannie.
• Jeśli urządzenie RED stoi za routerem operatora, muszą działać połączenia wychodzące oraz DNS/NTP.

RED jest bardzo praktyczny dla małych lokalizacji, ale nie należy traktować go jak zwykłego kabla LAN. Kluczowe jest, czy lokalizacja ma być centralnie chroniona, lokalnie autonomiczna czy tylko częściowo połączona przez tunel. Ta decyzja wpływa na DHCP, DNS, VLANy, routing, reguły firewall, logging i troubleshooting.

Ograniczyć Device Access

W Administration > Device access widać, które lokalne usługi firewalla są dostępne z których stref. Należą do nich między innymi:

• HTTPS
• SSH
• User Portal
• VPN Portal
• DNS
• Ping/Ping6
• Captive Portal
• STAS
• Wireless Protection

W środowiskach produkcyjnych obowiązuje zasada: im mniej lokalnych usług dostępnych ze strefy, tym lepiej. Szczególnie HTTPS i SSH powinny być dozwolone tylko z zaufanych sieci management albo przez Local service ACL exception rule.

Jeśli potrzebny jest SSH, pomaga ta instrukcja: nawiązać połączenie SSH z Sophos Firewall.

Pamiętać o zależnościach

Zmiany w interfaces rzadko są izolowane. Sophos wskazuje, że zmiany interface mogą wpływać na konfiguracje zależne, na przykład:

• Zone Binding
• DNS
• Gateways
• SD-WAN routes
• Hosty oparte na interface
• VLAN interfaces
• Dynamic DNS
• Reguły firewall
• Reguły NAT

Przed większymi zmianami warto więc w Object usage sprawdzić, gdzie interface, strefa albo obiekt host są już używane. Sophos Firewall pokazuje użycie obiektów i linkuje bezpośrednio do wielu zależnych konfiguracji.

Przy wyłączaniu lub usuwaniu trzeba uważać szczególnie:

• Jeśli interface zostanie wyłączony, konfiguracja pozostaje, a status jest nadal widoczny.
• Site-to-site IPsec tunnels, w których firewall jest initiator, zostają natychmiast rozłączone.
• Site-to-site IPsec tunnels jako responder oraz Remote Access connections rozłączają się najpóźniej przez inactivity albo Dead Peer Detection.
• Alias i XFRM interfaces nie da się wyłączyć bezpośrednio jak zwykłych interfaces. Alias interfaces podążają za fizycznym interface, XFRM interfaces wyłącza się przez Site-to-site VPN > IPsec.
• Jeśli usunie się wirtualny interface, mogą zostać usunięte zależne reguły firewall, konfiguracje DHCP, wpisy ARP, trasy, interface-hosts i inne referencje.

Dlatego przed usunięciem zawsze trzeba sprawdzić, czy interface jest używany w regułach firewall, NAT, DHCP, routing, SD-WAN, Dynamic DNS albo host objects. Nieostrożne usunięcie może usunąć więcej niż sam interface.

Typowe pułapki

Interface jest unbound albo disabled: sprawdzić, czy przypisano strefę. Fizycznego interface nie można usunąć, ale jego konfigurację można usunąć przez ustawienie strefy na None.

VLAN nie działa: sprawdzić VLAN ID, port switcha, konfigurację Tagged/Untagged, Native VLAN i czy VLAN utworzono na właściwym Parent Interface.

Klienci nie osiągają firewalla przez Ping albo HTTPS: nie sprawdzać najpierw zwykłych reguł firewall. Sprawdzić Administration > Device access i lokalne wyjątki ACL.

Ruch między dwiema sieciami wewnętrznymi nie działa: sprawdzić Source zone, Destination zone, obiekty sieciowe, routing i pozycję reguły firewall.

WAN gateway nie staje się aktywny: sprawdzić konfigurację IP, Gateway-IP, link status, dane PPPoE, DNS i ewentualnie WAN link manager.

Kilka WAN interfaces w tej samej podsieci: jeśli kilka WAN interfaces używa adresów IP z tej samej podsieci, mogą powstać problemy ARP i gateways mogą być niedostępne. Jeśli operator daje kilka publicznych IP w tej samej podsieci, Alias albo LAG interfaces są zwykle czystsze niż kilka oddzielnych WAN interfaces w tej samej sieci.

SFP, port speed albo breakout nie pasują: prędkość portu na switchu, routerze, transceiverze i firewallu musi pasować. Port 25 Gbit/s nie może być bez odpowiedniej technologii bezpośrednio podłączony do portu 40 Gbit/s. W modelach z portami 40G lub 100G kable breakout mogą być istotne, jeśli jeden port ma zostać podzielony na kilka mniejszych.

Problemy MTU przy VPN albo PPPoE: sprawdzić MTU i MSS. Przy ruchu VPN zbyt wysoka wartość MTU może powodować packet loss, który w codziennej pracy wygląda jak losowe problemy z połączeniem.

Troubleshooting

Przy szukaniu błędów praktyczna jest taka kolejność:

1. Network > Interfaces: sprawdzić link status, IP address, zone i gateway.
2. Network > Zones: sprawdzić Device Access i typ strefy.
3. Hosts and services: sprawdzić, czy host i service objects są poprawne.
4. Rules and policies > Firewall rules: sprawdzić Source zone, Destination zone, Services i kolejność.
5. Rules and policies > NAT rules: jeśli występuje NAT, porównać Original i Translated.
6. Log viewer: sprawdzić, która reguła albo drop działa.
7. Diagnostics > Tools > Packet capture: sprawdzić, czy pakiety w ogóle docierają i dokąd są przekazywane.

Jeśli strefy i interfaces są utworzone czysto, kolejny krok jest dużo prostszy: zrozumieć i poprawnie skonfigurować reguły Sophos Firewall. Jeśli ruch mimo pozornie poprawnej strefy nie działa, pomaga checklista reguła firewall nie działa: sprawdzić kolejność, matching i logi. Do głębszej analizy można dodatkowo użyć Packet Capture w WebAdmin, a przy translacjach lub przekierowaniach portów artykułu zrozumieć NAT w Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Dodatkowe informacje

• Sophos Firewall - Add a zone
• Sophos Firewall - Interfaces
• Sophos Firewall - Bridge interfaces
• Sophos Firewall - Link aggregation groups
• Sophos Firewall - Add a link aggregation group
• Sophos Firewall - XFRM interfaces
• Sophos Firewall - RED interfaces
• Sophos Firewall - Add a RED interface