Använd IP-värdar, tjänster och grupper i Sophos Firewall på rätt sätt

IP-värdar och tjänster ger adresser, nätverk och portar begripliga namn. En brandväggsregel visar då direkt vilken källa som får kommunicera med vilket mål och vilken tjänst.

Det viktiga valet gäller rätt omfattning: en enskild adress skapas som IP, ett subnät som Network, ett sammanhängande adressintervall som IP range och en liten samling enskilda adresser som IP list. För TCP och UDP beskriver en tjänst normalt den fasta Destination Port, medan den dynamiska Source Port förblir oförändrad.

För en ny regel går den kortaste säkra vägen från det minsta lämpliga värdobjektet, via en befintlig eller egen tjänst, till en snävt avgränsad brandväggsregel. Först därefter blir specialfall som systemvärdar, MAC-värdar och återanvändbara grupper aktuella. Före varje senare ändring visar Object Usage vilka regler och Policies som är beroende av objektet.

Välj rätt värdobjekt

Under Hosts and services > IP host finns fyra typer:

IP: exakt en IPv4- eller IPv6-adress, till exempel en server, skrivare eller ett administrationssystem.
Network: ett helt subnät med nätmask, till exempel 198.51.100.0/24.
IP range: ett sammanhängande intervall, till exempel 203.0.113.10 till 203.0.113.20.
IP list: flera enskilda adresser som inte ligger i ett sammanhängande intervall. En lista stöder högst 800 IP-adresser och kan inte ingå i en IP Host Group. Den aktuella hjälpen för SFOS 22 innehåller meningen ”For IP list, use only class B IP addresses.” Eftersom Sophos inte förklarar denna föråldrade formulering om nätverksklasser närmare får den inte tolkas som stöd för godtyckliga IPv4- eller IPv6-listor.

En FQDN Host passar bättre när måladressen ändras och det finns ett stabilt DNS-namn. Upplösning, jokertecken och begränsningar beskrivs i Använd FQDN Hosts och Wildcard FQDNs på rätt sätt.

Som grundregel används det minsta stabila objekt som fullständigt beskriver den trafik som behövs. Ett objekt av typen IP omfattar bara en adress och är för snävt för ett helt subnät; ett /24-nätverk skulle vara onödigt brett för en enda server.

Skapa en IP-värd steg för steg

Följande exempel representerar en enskild testserver:

Öppna Hosts and services > IP host och välj Add.
Ange host_test_web som Name.
Ställ in IP version på IPv4.
Välj IP som Type.
Ange 192.0.2.10 under IP address.
Spara med Save.

Följande adresser från 192.0.2.0/24, 198.51.100.0/24 och 203.0.113.0/24 är reserverade för dokumentationsexempel. I en produktionskonfiguration ersätts alla namn, adresser och nätverksstorlekar med värden från det verkliga nätverket.

Network, range och IP list

Fälten ändras beroende på vald typ:

Network: net_test_branch med 198.51.100.0 och /24 representerar hela testnätverket. Nätverksadressen anges, inte gatewayens adress.
IP range: range_test_admins från 203.0.113.10 till 203.0.113.20 representerar ett sammanhängande intervall.
IP list: i list_test_hosts anges endast kommaseparerade adresser från den egna, verifierade miljön. Eftersom uppgiften om klass B i den aktuella hjälpen är oklar ska den konkreta listan skapas i den SFOS-build som används och valideras med en testregel. Listan passar för ett fåtal fasta enskilda adresser, inte för intrångsindikatorer som ändras kontinuerligt.

För dynamiskt underhållna skadliga IP-adresser, domäner eller URL:er är Threat Feeds i Sophos Firewall den lämpligare funktionen. En manuell IP list uppdateras inte automatiskt.

IP Host Groups

Under Hosts and services > IP host group kan värdar med samma funktionella syfte grupperas. En grupp kan till exempel innehålla alla tillåtna administrationssystem och sedan användas i flera regler.

Tre viktiga begränsningar gäller:

IPv4- och IPv6-värdar får inte finnas i samma IP Host Group.
En vanlig värd kan ingå i flera grupper.
Ett objekt av typen IP list kan inte läggas till i en IP Host Group.

Grupper ska ha en gemensam betydelse. En samlingsgrupp med servrar, klienter och tillfälliga undantag kan spara klick, men gör det senare svårt att förstå varför en regel tillåter åtkomst.

Förstå system- och gränssnittsvärdar

SFOS skapar flera värdobjekt automatiskt. Dessa objekt ska inte återskapas som vanliga anpassade värdar eller ändras på fel plats:

Interface Hosts följer IP-konfigurationen under Network > Interfaces och ändras där. Zoner och gränssnitt i Sophos Firewall förklarar sambandet mellan anslutning, zon och regel.
Om en extra adress enligt leverantörens och nätverkets utformning måste bindas lokalt till ett fysiskt gränssnitt ska den konfigureras som ett alias-IP till det fysiska gränssnittet. Om ett NAT-fält inte erbjuder motsvarande Interface Host skapas dessutom ett tydligt namngivet Custom IP Host med adressen. Att använda samma namn är bara en praktisk konvention, inte ett tekniskt krav.
##WWAN1 underhålls dynamiskt för Cellular WAN-gränssnittet.
##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW och ##ALL_RW representerar dynamiska Remote Access-värdar.
Andra systemvärdar kan inte ändras eller tas bort som egna objekt.

De dynamiska Remote Access-värdarna kan inte läggas till i en annan IP Host Group. Physical Interface Hosts är inte tillgängliga i vissa NAT-fält, bland annat Translated source och Translated destination. I så fall kan en separat IP-värd med samma adress behövas. Namnet bör tydligt visa kopplingen till gränssnittet så att objektet inte ser ut som en fristående adress.

För interna värdar i aliassubnätet måste SFOS vara standardgateway. Om en uppströmsenhet använder brandväggen som gateway behöver enheten en IP-adress från varje berört aliassubnät. Efter ett brandväggsbyte kan inaktuella ARP-poster på uppströmsenheter göra alias-IP:t tillfälligt oåtkomligt. Kontrollera och uppdatera då först deras ARP-cache, i stället för att bredda NAT-regeln i onödan.

För utgående SD-WAN-rutter till internet rekommenderar Sophos dessutom Internet IPv4 group eller de ingående standardvärdarna som destination i stället för Any. Då begränsas rutten till publika IPv4-destinationer och intern trafik hamnar inte på samma väg enbart på grund av ett för brett destinationsobjekt.

Använd MAC hosts för enheter som syns direkt

En MAC host beskriver en enhet på Layer 2 och kan innehålla en enskild adress eller en lista. Den passar bara där brandväggen ser den verkliga käll-MAC-adressen. Bakom en router, VPN eller NAT ser brandväggen normalt nästa hops MAC-adress i stället för den ursprungliga klientens. För routade regler är därför en IP host eller ett nätverk oftast det stabilare objektet.

Under Hosts and services > MAC host > Add får objektet ett tydligt namn och typen MAC address eller MAC list. Adressen kan skrivas med kolon, till exempel 00:16:76:49:33:CE, eller bindestreck, till exempel 00-16-76-49-33-CE; flera poster avgränsas med kommatecken. En MAC list stöder högst 1 000 MAC-adresser.

En MAC host är inte en enhetsidentitet. En MAC-adress kan kopieras eller förfalskas och kan ändras genom dockningsstationer, virtuella maskiner eller privata Wi-Fi-adresser. Objektet passar som ett begränsat matchningskriterium i ett kontrollerat segment, men inte som enda autentisering eller säkerhetsgräns.

Skapa en tjänst med rätt Destination Port

Innan en ny tjänst skapas bör det kontrolleras om en lämplig standardtjänst redan finns. En Custom Service är lämplig när en applikation behöver en annan port eller en särskild protokollkombination.

Följande exempel skapar TCP-tjänsten för iPerf3:

Öppna Hosts and services > Services och välj Add.
Ange svc_iperf3_tcp som Name.
Ställ in Type på TCP/UDP och Protocol på TCP.
Låt den förinställda Source Port 1:65535 vara oförändrad.
Ange 5201 som Destination Port.
Spara med Save.

Klienten väljer normalt sin Source Port dynamiskt. Om tjänsten också begränsade den till 5201 skulle en normal anslutning inte längre matcha. Den fasta serverporten hör därför hemma under Destination Port. En begränsad Source Port är bara korrekt när protokollet uttryckligen kräver det och verklig trafik bekräftar beteendet.

För ett iPerf3-UDP-test skapas även svc_iperf3_udp med protokollet UDP och Destination Port 5201. Eftersom iPerf3 fortfarande använder en TCP-styranslutning under UDP-testet grupperas båda tjänsterna:

Öppna Hosts and services > Service group och välj Add.
Ange grp_iperf3 som Name.
Välj svc_iperf3_tcp och svc_iperf3_udp.
Spara med Save.

Hela mätförfarandet beskrivs i iPerf3-hastighetstest genom Sophos Firewall.

En Service Group kan kombinera standardtjänster och Custom Services, och en tjänst kan vara medlem i flera grupper. Services och Service Groups skiljer inte mellan IPv4 och IPv6; IP-versionen bestäms av värdobjekten och regelkontexten. Fördefinierade Service Groups kan inte ändras eller tas bort, så en egen kombination kräver en ny grupp.

Inte heller fördefinierade Services eller Services som redan används i Security Policies kan ändras eller tas bort. Kringgå inte ett beroende, utan skapa den Custom Service som behövs, ersätt det gamla objektet kontrollerat i berörda Policies och kontrollera därefter den uppdaterade Usage-visningen.

IP, ICMP och ICMPv6

Utöver TCP och UDP kan en Custom Service beskriva ett IP-protokollnummer eller ICMP-/ICMPv6-typer och -koder. Dessa typer är avsedda för protokoll som inte använder någon TCP- eller UDP-port. Värden ska hämtas från applikationens tekniska dokumentation och inte gissas efter ett enstaka misslyckat test.

Använd objekt i en brandväggsregel

Ett värd- eller tjänsteobjekt tillåter ingen trafik på egen hand. Det börjar gälla först när det används som matchningskriterium i en regel. Ett snävt exempel kan se ut så här:

Source zones: LAN
Source networks and devices: net_test_branch
Destination zones: DMZ
Destination networks: host_test_web
Services: HTTPS
Log firewall traffic: aktiverat

Zoner, adresser och tjänst anpassas till det verkliga nätverket. Svarstrafik för en tillåten tillståndsbaserad anslutning släpps automatiskt tillbaka. Regeln tillåter däremot inte självständiga nya anslutningar från DMZ till LAN. En NAT-regel ger inte heller någon behörighet på egen hand; en matchande brandväggsregel krävs fortfarande.

SFOS kontrollerar brandväggsregler uppifrån och ned och avslutar sökningen vid den första träffen. Den nya, specifika regeln ska därför ligga ovanför en bredare regel som annars skulle hantera samma flöde först. Förstå och konfigurera regler i Sophos Firewall säkert förklarar ordning, skyddsfunktioner och testning.

Efter att regeln har sparats bör ett verkligt anslutningsförsök kontrolleras i Log Viewer. Filtrera på testadressen, porten och regeln för att avgränsa rätt flöde och kontrollera Rule ID, Source, Destination och Service i detaljvyn. På så sätt går det att skilja ett feldefinierat objekt från trafik som behandlas av en annan regel. Om en anslutning bryts utan en Destroy-händelse som brandväggen känner igen kan den avslutande sessionsposten saknas; Packet Capture och Live Connections ger då en bättre motkontroll.

Uppdatera Object Usage före ändringar

Ett objekt kan användas i brandväggs- och NAT-regler, VPN, SD-WAN-rutter eller andra konfigurationer. Därför måste beroendena kontrolleras innan objektet ändras eller tas bort.

Kolumnen Usage i objektlistan visar det kända antalet referenser. Räknaren uppdateras automatiskt endast en gång per dag. Före en ändring:

Välj Refresh bredvid Usage.
Öppna den uppdaterade räknaren för det berörda objektet.
Expandera kategorierna och kontrollera varje beroende regel eller Policy.
Först därefter avgörs om objektet kan ändras, ersättas eller tas bort.

Alla beroenden kan inte ändras direkt från Usage-vyn. Vissa, bland annat WAN-gatewayer och CLI-konfigurationer, måste öppnas separat på den angivna konfigurationsplatsen. En räknare på noll är en tillförlitlig grund först efter en manuell Refresh.

Hantera objekt säkert

Undvik vanliga fel

Host i stället för Network: En enskild IP-adress omfattar inte automatiskt det tillhörande subnätet.
Fel nätverksadress eller mask: För ett Network-objekt måste nätverksadress och prefix stämma överens med den verkliga segmenteringen.
Begränsad Source Port: För normala klient-serveranslutningar behålls 1:65535; Destination Port begränsas.
För mycket Any: Ett exakt värdobjekt förlorar sitt säkerhetsvärde om källan eller tjänsten förblir onödigt bred.
Duplicerat systemobjekt: SFOS underhåller gränssnitts- och Remote Access-värdar, så de ska inte kopieras utan en konkret anledning.
IP list som Threat Feed: En IP list förblir statisk och ersätter inte automatiskt uppdaterade hotindikatorer.
Beroenden har inte uppdaterats: Välj alltid Refresh i Object Usage innan ett objekt ändras eller tas bort.

Beskrivande prefix som host_, net_, range_, svc_ och grp_ är inget tekniskt krav, men gör sökning och granskning enklare. Viktigare än det exakta schemat är att namn, syften och omfattningar används konsekvent i hela regelverket.

Håll objektbeståndet litet och överskådligt

SFOS stöder totalt upp till 16 000 värdar över alla värdtyper. Det är en plattformsgräns, inte ett planeringsmål. I den dagliga driften är en mindre och begriplig objektbas mer värdefull än många poster som knappt går att skilja åt. Objekt som inte längre behövs ska ersättas eller tas bort kontrollerat, och först efter att deras Usage har uppdaterats och granskats.