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.

Förutom Custom IP Hosts kan även standardvärdarna för gränssnitt, Cellular WAN och internet ingå i en grupp. Gruppmedlemskap är skilt från möjligheten att redigera värdobjektet: en systemvärd som inte kan redigeras direkt är därför inte automatiskt utesluten från grupper. Dynamiska systemvärdar för Remote Access-VPN är däremot fortfarande uteslutna.

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.

För att skapa en liten IPv4-testgrupp med den tidigare skapade host_test_web:

Öppna Hosts and services > IP host group och välj Add.
Ange grp_test_servers som Name; anpassa namnet till gruppens syfte.
Ställ in IP version på IPv4, så att den stämmer med den befintliga testvärden.
Välj host_test_web via Add new item. Ytterligare medlemmar ska ha samma syfte och samma IP-version.
Spara med Save.

Öppna sedan gruppen igen och kontrollera IP-versionen och medlemmarna. Om en önskad värd saknas i urvalet, kontrollera först dess IP-version och typ; kringgå inte uteslutningen av en IP list eller en Remote Access-VPN-systemvärd med ett onödigt brett ersättningsobjekt.

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

Listan över IP-värdar visar fysiska gränssnitt, inklusive extra FleXi-Port-moduler, samt virtuella gränssnitt som du själv har skapat. Under Address details visas adressen och nätmasken från Network > Interfaces. Vid ett oväntat värde ska du först jämföra denna gränssnittskonfiguration med det som visas; det automatiskt underhållna värdobjektet är inte rätt plats för en adressändring.

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 skapas när Cellular WAN aktiveras, använder WWAN-gränssnittets IP-adress och underhålls dynamiskt.
##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW och ##ALL_RW representerar dynamiska Remote Access-värdar.
##ALL_SSLVPN_RW innehåller de IP-adresser som brandväggen tilldelar etablerade SSL VPN-anslutningar för fjärråtkomst med Sophos Connect. ##ALL_IPSEC_RW innehåller motsvarande tilldelade adresser för IPsec-anslutningar. ##ALL_RW samlar de tilldelade adresserna för båda anslutningstyperna; SFOS lägger till dem dynamiskt när anslutningarna etableras.
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 fungerar som gateway för trafik från Sophos Firewall 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.

Till skillnad från systemvärdar som inte kan redigeras kan standardvärdarna för internet ändras och tas bort. Uppdatera först Object Usage enligt beskrivningen nedan och kontrollera beroende regler och SD-WAN-rutter. Undantaget gäller internetvärdar, inte dynamiska VPN/WWAN-systemvärdar; gränssnittsadresser ändras fortfarande under Network > Interfaces.

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.

Exempel: blockera ett icke-webbflöde med käll-MAC

Detta exempel för SFOS 22/23 blockerar ett nytt IPv4-iPerf3-TCP-flöde från en direkt synlig LAN-testenhet till en kontrollerad WAN-testserver. Det är inte en procedur för att blockera all internetåtkomst: HTTP/HTTPS och Web Exceptions ingår inte i testet. Kontrollera först enhetens verkliga käll-MAC med Packet Capture på det inkommande gränssnittet. Om bara en uppströmsrouter syns passar regeln inte; en LAN-port på en switch bevisar inte i sig synlighet på Layer 2. Kontrollera före ändringen att WAN-testservern och TCP-port 5201 är nåbara. Servern måste faktiskt köra iPerf3, inte en webbtjänst.

Ange under Hosts and services > MAC host > Add mac_test_client som Name, MAC address som Type och 02:00:00:00:00:10 som MAC address, och spara med Save. Namnet och den lokalt administrerade unicastadressen är exempel; ersätt adressen med enhetens verifierade MAC.
Öppna Rules and policies > Firewall rules, välj IPv4 och skapa drop_mac_test_wan via Add firewall rule > New firewall rule. Ställ in Action på Drop och aktivera Log firewall traffic.
Ställ in Source zones på LAN, Source networks and devices på mac_test_client och Destination zones på WAN. Välj den egna WAN-testserverns IP Host under Destination networks och svc_iperf3_tcp under Services; skapa denna TCP-tjänst med Destination Port 5201 enligt nästa avsnitt. Då är destinationen och testtjänsten för icke-webbtrafik snävt begränsade. Any behövs inte för detta exempel.
Ställ in During scheduled time på All the time för en permanent blockering, annars välj ett lämpligt schema. Placera regeln ovanför regler som annars skulle tillåta samma flöde först, utan att flytta avsiktliga undantag med högre prioritet. Top är inget universellt krav. Rule group kan vara None; en grupp ersätter inte korrekt placering. Spara med Save och kontrollera den faktiska ordningen.

Starta därefter ett nytt iPerf3-TCP-anslutningsförsök från testenheten till samma WAN-testserver på port 5201, inte ett UDP- eller webbläsartest. I Log Viewer måste Drop och denna blockeringsregels Rule ID stämma med flödet. Testa samma icke-webbflöde från en andra, oblockerad enhet: det ska fortfarande träffa den avsedda Allow-regeln. Använd nya anslutningar för båda testerna, inte befintliga sessioner. Om den förväntade träffen saknas, kontrollera käll-MAC i Packet Capture, zoner, IP-version, schema, destinations-/tjänsteomfattning och tidigare regler.

Denna kontroll styrker bara de testade flödena, inte generell webb- eller internetblockering. IPv6, andra destinationszoner, destinationer och tjänster omfattas inte och kräver egen konfiguration och egna tester. För att återställa, inaktivera endast den nya blockeringsregeln och kontrollera det tidigare tillåtna läget med ett nytt iPerf3-TCP-flöde. Risken för spoofing och identitetsproblem som beskrivs ovan kvarstår.

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.

För en tjänst av typen IP under Hosts and services > Services > Add, ange ett lämpligt Name, ställ in Type på IP, välj det protokollnummer som behövs och spara med Save. Det avser IP-protokollnumret, inte en TCP-/UDP-målport. Öppna sedan tjänsten igen och jämför numret med applikationens krav; kontrollera det protokoll som faktiskt observeras i Packet Capture när du testar med en snävt avgränsad regel. Om den förväntade träffen saknas, kontrollera först protokollet och regelns omfattning i stället för att byta till Any.

Under Hosts and services > Services > Add kan en tjänst innehålla flera poster av samma valda typ. För ICMP eller ICMPv6, välj först det typ-/kodpar som behövs, lägg till fler par med Add och ta bort onödiga poster med Remove. Kontrollera sedan alla poster och spara med Save. På så sätt kan flera nödvändiga ICMP-meddelanden beskrivas i en tjänst utan att alla typer tillåts urskillningslöst. De separata TCP/UDP-tjänsterna och Service Group i iPerf3-exemplet är fortfarande ett tydligt alternativ när tjänster ska återanvändas var för sig.

Versionsnotering om API-dokumentationen: I den sparade Sophos-API-tabellen ”Add Service / Update Service” för SFOS 22 står No i kolumnen Mandatory för både ICMPType och ICMPv6Type; för SFOS 23 står Yes för båda. Detta är beteckningar i API-dokumentationen, inte belägg för en ändring av GUI eller beteendet vid körning. De gäller ICMP-/ICMPv6-fälten och ska inte tolkas som ett krav på att lägga till båda protokollfamiljerna i TCP-/UDP-/IP-tjänster. Sidan definierar ingen villkorlig regel för när dessa fält får utelämnas; beteckningarna ger därför inga konkreta instruktioner för payload eller validering.

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.

Hitta befintliga objekt och underhåll dem målinriktat

Listorna under Hosts and services > IP host, IP host group, MAC host, Services och Service group kan sökas igenom utifrån respektive objekts attribut. Innan du skapar ett nytt objekt ska du inte bara söka efter det önskade namnet, utan även efter de adress- eller protokoll-/portvärden som behövs, i den mån de gäller för objekttypen. Då upptäcks ett redan lämpligt objekt med ett annat namn. Sök efter objektet igen efter att det har sparats och kontrollera dess värden respektive gruppmedlemmar.

Custom IP Hosts och IP Host Groups kan läggas till, ändras och tas bort; egna Service Groups kan också ändras, byta namn, kompletteras med tjänster eller tas bort. Uppdatera alltid Object Usage först. En gruppändring påverkar alla regler som använder gruppen, inte bara det användningsfall som för tillfället bearbetas. Dokumentera de tidigare värdena och medlemmarna före ändringen och kontrollera därefter de berörda anslutningarna med nya sessioner. Om omfattningen är fel, återställ ändringen kontrollerat och testa igen. De begränsningar för systemvärdar, standardtjänstegrupper och skyddade tjänster som beskrivs ovan gäller fortfarande.

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.