Sophos Firewall IP-Hosts, Services und Gruppen richtig verwenden

IP-Hosts und Services geben Adressen, Netzen und Ports einen verständlichen Namen. Dadurch lässt sich in einer Firewallregel direkt erkennen, welche Quelle mit welchem Ziel und Dienst kommunizieren darf.

Entscheidend ist der passende Umfang: Eine einzelne Adresse wird als IP, ein Subnetz als Network, ein zusammenhängender Adressbereich als IP range und eine kleine Sammlung einzelner Adressen als IP list angelegt. Bei TCP und UDP beschreibt ein Service normalerweise den festen Destination Port; der dynamische Source Port bleibt unverändert.

Für eine neue Regel führt der kürzeste sichere Weg vom kleinsten passenden Hostobjekt über einen vorhandenen oder eigenen Service zur eng begrenzten Firewallregel. Erst danach kommen Sonderfälle wie System Hosts, MAC Hosts und wiederverwendbare Gruppen. Vor jeder späteren Änderung zeigt Object Usage, welche Regeln und Policies vom Objekt abhängen.

Das passende Hostobjekt wählen

Unter Hosts and services > IP host stehen vier Typen zur Verfügung:

• IP: genau eine IPv4- oder IPv6-Adresse, beispielsweise ein Server, Drucker oder Managementsystem.
• Network: ein vollständiges Subnetz mit Netzmaske, beispielsweise 198.51.100.0/24.
• IP range: ein zusammenhängender Bereich, beispielsweise 203.0.113.10 bis 203.0.113.20.
• IP list: mehrere einzelne, nicht zusammenhängende Adressen. Eine Liste unterstützt höchstens 800 IP-Adressen und kann nicht Mitglied einer IP Host Group werden. Die aktuelle SFOS-22-Hilfe enthält dazu den Satz «For IP list, use only class B IP addresses.» Da Sophos diese veraltete Netzklassen-Formulierung nicht näher erklärt, darf man daraus keine Unterstützung beliebiger IPv4- oder IPv6-Listen ableiten.

Ein FQDN-Host passt besser, wenn sich die Zieladresse ändert und ein stabiler DNS-Name vorhanden ist. Auflösung, Wildcards und Grenzen erklärt FQDN-Hosts und Wildcard-FQDNs richtig verwenden.

Als Grundregel gilt: Das kleinste stabile Objekt verwenden, das den benötigten Traffic vollständig beschreibt. Ein Objekt vom Typ IP deckt nur eine Adresse ab und ist für ein ganzes Subnetz zu eng; ein /24-Netz wäre für einen einzelnen Server unnötig breit.

IP Host Schritt für Schritt anlegen

Das folgende Beispiel bildet einen einzelnen Testserver ab:

1. Hosts and services > IP host öffnen und Add wählen.
2. Als Name host_test_web eintragen.
3. IP version auf IPv4 setzen.
4. Als Type IP auswählen.
5. Unter IP address 192.0.2.10 eintragen.
6. Mit Save speichern.

Die folgenden Adressen aus 192.0.2.0/24, 198.51.100.0/24 und 203.0.113.0/24 sind für Dokumentationsbeispiele reserviert. In einer produktiven Konfiguration werden alle Namen, Adressen und Netzgrössen an das tatsächliche Netzwerk angepasst.

Network, Range und IP list

Die Eingabefelder ändern sich mit dem gewählten Typ:

• Network: net_test_branch mit 198.51.100.0 und /24 beschreibt das gesamte Testnetz. Eingetragen wird die Netzadresse, nicht die Adresse des Gateways.
• IP range: range_test_admins mit 203.0.113.10 bis 203.0.113.20 passt zu einem zusammenhängenden Pool.
• IP list: Bei list_test_hosts werden nur Adressen aus der eigenen, verifizierten Umgebung kommagetrennt eingetragen. Wegen der unklaren Class-B-Angabe in der aktuellen Hilfe wird die konkrete Liste auf dem eingesetzten SFOS-Build angelegt und mit einer Testregel abgenommen. Sie eignet sich für wenige feste Einzeladressen, nicht für laufend wechselnde Indicators of Compromise.

Für dynamisch gepflegte schädliche IP-Adressen, Domains oder URLs sind Threat Feeds auf Sophos Firewall die geeignetere Funktion. Eine manuelle IP-Liste wird nicht automatisch aktualisiert.

IP Host Groups

Unter Hosts and services > IP host group lassen sich Hosts mit demselben fachlichen Zweck zusammenfassen. Eine Gruppe kann beispielsweise alle erlaubten Managementsysteme enthalten und danach in mehreren Regeln verwendet werden.

Neben Custom IP Hosts können auch die Standardhosts für Interfaces, Cellular WAN und Internet Mitglied einer Gruppe sein. Die Gruppenmitgliedschaft ist von der Bearbeitbarkeit des Hostobjekts zu unterscheiden: Ein nicht direkt bearbeitbarer System Host ist deshalb nicht automatisch von Gruppen ausgeschlossen. Die dynamischen Remote-Access-VPN-Systemhosts bleiben jedoch ausgeschlossen.

Dabei gelten drei wichtige Grenzen:

• IPv4- und IPv6-Hosts dürfen nicht in derselben IP Host Group liegen.
• Ein normaler Host kann Mitglied mehrerer Gruppen sein.
• Ein Objekt vom Typ IP list kann keiner IP Host Group hinzugefügt werden.

Für eine kleine IPv4-Testgruppe mit dem zuvor angelegten host_test_web:

1. Hosts and services > IP host group öffnen und Add wählen.
2. Als Name grp_test_servers eintragen; der Name wird an den eigenen Zweck angepasst.
3. IP version auf IPv4 setzen, passend zum vorhandenen Testhost.
4. Über Add new item host_test_web auswählen. Weitere Mitglieder müssen denselben Zweck und dieselbe IP-Version haben.
5. Mit Save speichern.

Anschliessend die Gruppe erneut öffnen und IP-Version sowie Mitglieder prüfen. Fehlt ein gewünschter Host in der Auswahl, zuerst seine IP-Version und seinen Typ kontrollieren; eine IP list oder einen Remote-Access-VPN-Systemhost nicht durch ein unnötig breites Ersatzobjekt umgehen.

Gruppen sollten eine gemeinsame Bedeutung haben. Eine Sammelgruppe mit Servern, Clients und temporären Ausnahmen spart zwar Klicks, macht später aber schwer nachvollziehbar, warum eine Regel Zugriff erlaubt.

System- und Interface-Hosts richtig einordnen

SFOS legt mehrere Hostobjekte selbst an. Diese Objekte sollten nicht als normale Custom Hosts nachgebaut oder an der falschen Stelle bearbeitet werden:

• Interface Hosts folgen der IP-Konfiguration unter Network > Interfaces und werden dort geändert. Die Beziehung zwischen Anschluss, Zone und Regel erklärt Zonen und Interfaces auf Sophos Firewall.
• Muss eine zusätzliche Adresse gemäss Provider- und Netzwerkdesign lokal an ein physisches Interface gebunden sein, wird sie als Alias-IP am physischen Interface konfiguriert. Wenn ein NAT-Feld den zugehörigen Interface Host nicht anbietet, legt man zusätzlich einen klar benannten Custom IP Host mit dieser Adresse an. Eine Namensgleichheit ist dabei nur eine hilfreiche Konvention, keine technische Voraussetzung.
• ##WWAN1 entsteht, wenn Cellular WAN eingeschaltet wird, verwendet die IP-Adresse des WWAN-Interfaces und wird dynamisch gepflegt.
• ##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW und ##ALL_RW repräsentieren dynamische Remote-Access-Hosts.
• ##ALL_SSLVPN_RW enthält die von der Firewall vergebenen IP-Adressen etablierter Remote-Access-SSL-VPN-Verbindungen mit Sophos Connect. ##ALL_IPSEC_RW enthält entsprechend die vergebenen Adressen der IPsec-Verbindungen. ##ALL_RW fasst die vergebenen Adressen beider Verbindungsarten zusammen; SFOS fügt sie dynamisch hinzu, wenn die Verbindungen aufgebaut werden.
• Weitere System Hosts lassen sich nicht wie eigene Objekte bearbeiten oder löschen.

Die dynamischen Remote-Access-Hosts können keiner zusätzlichen IP Host Group hinzugefügt werden. Physische Interface Hosts stehen in bestimmten NAT-Feldern wie Translated source oder Translated destination nicht zur Auswahl. In diesem Fall kann ein eigener IP Host mit derselben Adresse nötig sein. Sein Name sollte den Bezug zum Interface eindeutig zeigen, damit keine scheinbar unabhängige Adresse entsteht.

Bei internen Hosts im Alias-Subnetz muss SFOS das Default Gateway sein. Nutzt ein vorgeschaltetes Gerät die Firewall als Gateway, benötigt dieses Gerät eine IP-Adresse aus jedem betroffenen Alias-Subnetz. Nach einem Firewalltausch können veraltete ARP-Einträge auf vorgeschalteten Geräten die Alias-IP vorübergehend unerreichbar machen; dann wird zuerst deren ARP-Cache kontrolliert und aktualisiert, nicht die NAT-Regel unnötig verbreitert.

Für ausgehende Internet-SD-WAN-Routen empfiehlt Sophos ausserdem Internet IPv4 group oder die enthaltenen Standardhosts als Ziel statt Any. Dadurch bleibt die Route auf öffentliche IPv4-Ziele begrenzt und zieht internen Traffic nicht nur wegen eines zu breiten Zielobjekts in denselben Pfad.

Die Standard-Internet-Hosts lassen sich im Gegensatz zu den nicht bearbeitbaren System Hosts ändern und löschen. Vor einer solchen Änderung wird Object Usage wie unten beschrieben aktualisiert und werden abhängige Regeln und SD-WAN-Routen geprüft. Diese Ausnahme gilt für Internet-Hosts, nicht für dynamische VPN-/WWAN-Systemhosts; Interface-Adressen werden weiterhin unter Network > Interfaces geändert.

MAC Hosts für direkt sichtbare Geräte verwenden

Ein MAC Host beschreibt ein Gerät auf Layer 2 und kann als einzelne Adresse oder als Liste angelegt werden. Das passt nur dort, wo die Firewall die echte Quell-MAC-Adresse sieht. Hinter einem Router, VPN oder NAT sieht sie normalerweise die MAC-Adresse des nächsten Hops und nicht jene des ursprünglichen Clients. Für geroutete Regeln ist deshalb meist ein IP Host oder Network das stabilere Objekt.

Unter Hosts and services > MAC host > Add erhält das Objekt einen sprechenden Namen und den Typ MAC address oder MAC list. Die Adresse kann mit Doppelpunkten wie 00:16:76:49:33:CE oder Bindestrichen wie 00-16-76-49-33-CE geschrieben werden; mehrere Einträge werden mit Kommas getrennt. Eine MAC list unterstützt höchstens 1'000 MAC-Adressen.

Ein MAC Host ist keine Geräteidentität. Eine MAC-Adresse lässt sich kopieren oder fälschen und kann sich bei Dockingstations, virtuellen Maschinen oder privaten WLAN-Adressen ändern. Das Objekt eignet sich als enges Match-Kriterium in einem kontrollierten Segment, aber nicht als alleinige Authentisierung oder Sicherheitsgrenze.

Beispiel: Einen Nicht-Web-Flow anhand der Quell-MAC sperren

Das Beispiel für SFOS 22/23 sperrt einen neuen IPv4-iPerf3-TCP-Flow vom direkt sichtbaren LAN-Testgerät zu einem kontrollierten WAN-Testserver. Es ist keine Anleitung für eine vollständige Internetsperre: HTTP/HTTPS und Web Exceptions sind nicht Gegenstand dieses Tests. Vorher mit Packet Capture am eingehenden Interface die echte Quell-MAC des Geräts prüfen. Ist nur ein vorgeschalteter Router sichtbar, passt die Regel nicht; ein LAN-Port am Switch allein beweist keine Layer-2-Sichtbarkeit. Den eigenen WAN-Testserver und TCP-Port 5201 vor der Änderung auf Erreichbarkeit prüfen. Dort muss tatsächlich iPerf3 und kein Webdienst laufen.

1. Unter Hosts and services > MAC host > Add als Name mac_test_client, als Type MAC address und als MAC address 02:00:00:00:00:10 eintragen und mit Save speichern. Name und lokal administrierte Unicast-Adresse sind Beispiele; die Adresse durch die verifizierte Geräte-MAC ersetzen.
2. Rules and policies > Firewall rules öffnen, IPv4 wählen und über Add firewall rule > New firewall rule die Regel drop_mac_test_wan erstellen. Action auf Drop setzen und Log firewall traffic aktivieren.
3. Source zones auf LAN, Source networks and devices auf mac_test_client und Destination zones auf WAN setzen. Unter Destination networks den IP Host des eigenen WAN-Testservers und unter Services svc_iperf3_tcp wählen; diesen TCP-Service mit Destination Port 5201 legt man wie im folgenden Abschnitt an. So bleiben Ziel und Nicht-Web-Testdienst eng begrenzt. Any ist für dieses Beispiel nicht erforderlich.
4. During scheduled time für eine dauerhafte Sperre auf All the time setzen, sonst den passenden Schedule wählen. Die Regel über Regeln setzen, die denselben Flow vorher erlauben würden, ohne beabsichtigte vorrangige Ausnahmen zu verdrängen. Top ist keine universelle Vorgabe. Rule group kann None bleiben; eine Gruppe ersetzt keine korrekte Position. Mit Save speichern und die tatsächliche Reihenfolge kontrollieren.

Danach vom Testgerät einen neuen iPerf3-TCP-Verbindungsversuch zum selben WAN-Testserver auf Port 5201 starten, keinen UDP- oder Browsertest. Im Log Viewer müssen Drop und die Rule ID dieser Sperrregel zum Flow passen. Von einem zweiten, nicht gesperrten Gerät denselben Nicht-Web-Flow testen: Er soll weiterhin die vorgesehene Allow-Regel treffen. Für beide Tests frische Verbindungen verwenden, nicht bestehende Sessions. Fehlt der erwartete Treffer, Quell-MAC im Packet Capture, Zonen, IP-Version, Schedule, Ziel-/Serviceumfang und frühere Regeln prüfen.

Diese Kontrolle belegt nur die getesteten Flows, keine allgemeine Web- oder Internetsperre. IPv6, andere Zielzonen, Ziele und Dienste sind nicht abgedeckt und benötigen eigene Konfiguration und Tests. Als Rückweg nur die neue Sperrregel deaktivieren und mit einem frischen iPerf3-TCP-Flow den vorherigen erlaubten Zustand prüfen. Das oben beschriebene Spoofing- und Identitätsrisiko bleibt bestehen.

Service mit richtigem Zielport anlegen

Vor einem neuen Service sollte geprüft werden, ob ein passender Standardservice bereits vorhanden ist. Ein Custom Service ist sinnvoll, wenn eine Anwendung einen anderen Port oder eine besondere Protokollkombination benötigt.

Das folgende Beispiel erstellt den TCP-Dienst für iPerf3:

1. Hosts and services > Services öffnen und Add wählen.
2. Als Name svc_iperf3_tcp eintragen.
3. Type auf TCP/UDP und Protocol auf TCP setzen.
4. Den voreingestellten Source Port 1:65535 unverändert lassen.
5. Als Destination Port 5201 eintragen.
6. Mit Save speichern.

Der Client wählt seinen Source Port normalerweise dynamisch aus. Würde der Service dort ebenfalls auf 5201 eingeschränkt, passt eine normale Verbindung nicht mehr. Der feste Serverport gehört deshalb in Destination Port. Ein enger Source Port ist nur richtig, wenn das verwendete Protokoll dies ausdrücklich verlangt und der echte Traffic es bestätigt.

Für einen iPerf3-UDP-Test wird zusätzlich svc_iperf3_udp mit Protokoll UDP und Destination Port 5201 angelegt. Da iPerf3 für den UDP-Test weiterhin eine TCP-Steuerverbindung nutzt, werden beide Services zusammengefasst:

1. Hosts and services > Service group öffnen und Add wählen.
2. Als Name grp_iperf3 eintragen.
3. svc_iperf3_tcp und svc_iperf3_udp auswählen.
4. Mit Save speichern.

Der vollständige Messablauf steht unter iPerf3-Speedtest über Sophos Firewall.

Eine Service Group darf Standard- und Custom Services kombinieren, und ein Service kann Mitglied mehrerer Gruppen sein. Services und Service Groups unterscheiden dabei nicht zwischen IPv4 und IPv6. Die IP-Version wird durch Hostobjekte und Regelkontext bestimmt. Vordefinierte Service Groups lassen sich nicht bearbeiten oder löschen; für eine eigene Kombination wird deshalb eine neue Gruppe erstellt.

Auch vordefinierte Services sowie Services, die bereits in Security Policies verwendet werden, lassen sich nicht bearbeiten oder löschen. Statt eine Abhängigkeit zu umgehen, erstellt man den benötigten Custom Service, ersetzt das alte Objekt kontrolliert in den abhängigen Policies und prüft danach die aktualisierte Usage-Anzeige.

IP, ICMP und ICMPv6

Ein Custom Service kann neben TCP und UDP auch eine IP-Protokollnummer oder ICMP-/ICMPv6-Typen und -Codes beschreiben. Diese Typen sind für Protokolle gedacht, die keinen TCP- oder UDP-Port verwenden. Werte sollten aus der technischen Dokumentation der Anwendung stammen und nicht aufgrund eines einzelnen fehlgeschlagenen Tests geraten werden.

Unter Hosts and services > Services > Add kann ein Service mehrere Einträge desselben gewählten Typs enthalten. Für ICMP oder ICMPv6 zuerst das benötigte Paar aus ICMP-Typ und -Code auswählen, mit Add weitere Typ-/Code-Paare ergänzen und mit Remove nicht benötigte Einträge entfernen. Danach alle Einträge kontrollieren und mit Save speichern. So lassen sich mehrere benötigte ICMP-Nachrichten in einem Service beschreiben, ohne pauschal alle Typen freizugeben. Die getrennten TCP-/UDP-Services und die Service Group im iPerf3-Beispiel bleiben eine gut nachvollziehbare Alternative, wenn Dienste einzeln wiederverwendet werden sollen.

Versionshinweis zur API-Dokumentation: In der gespeicherten Sophos-API-Tabelle «Add Service / Update Service» für SFOS 22 steht bei ICMPType und ICMPv6Type in der Spalte Mandatory jeweils No; für SFOS 23 steht dort jeweils Yes. Das sind Kennzeichnungen in der API-Dokumentation, kein Nachweis einer Änderung der GUI oder des Laufzeitverhaltens. Sie betreffen die ICMP-/ICMPv6-Felder und sind nicht als Aufforderung zu verstehen, beide Protokollfamilien zu TCP-/UDP-/IP-Services hinzuzufügen. Die Seite definiert keine bedingte Regel, wann diese Felder weggelassen werden dürfen; daraus lässt sich keine konkrete Payload- oder Validierungsanweisung ableiten.

Objekte in einer Firewallregel verwenden

Ein Host- oder Serviceobjekt erlaubt noch keinen Traffic. Es wird erst als Match-Kriterium in einer Regel wirksam. Ein enges Beispiel könnte so aussehen:

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

Zonen, Adressen und Service werden an das reale Netzwerk angepasst. Antworttraffic einer erlaubten zustandsbehafteten Verbindung wird automatisch zurückgeführt. Eigenständige neue Verbindungen von der DMZ ins LAN erlaubt diese Regel jedoch nicht. Auch eine NAT-Regel allein erteilt keine Berechtigung; dafür braucht es weiterhin eine passende Firewallregel.

SFOS prüft Firewallregeln von oben nach unten und beendet die Suche beim ersten Treffer. Die neue, spezifische Regel gehört deshalb über eine breitere Regel, die denselben Flow sonst zuerst übernehmen würde. Reihenfolge, Schutzfunktionen und Test erklärt Sophos Firewall-Regeln verstehen und sicher konfigurieren.

Nach dem Speichern sollte ein echter Verbindungsversuch im Log Viewer kontrolliert werden. Mit Filtern für die Testadresse, den Port und die Regel grenzt man den richtigen Flow ein und prüft in der Detailansicht Rule ID, Source, Destination und Service. So lässt sich unterscheiden, ob das Objekt falsch definiert ist oder eine andere Regel den Traffic verarbeitet. Wird eine Verbindung ohne ein von der Firewall erkanntes Destroy-Ereignis unterbrochen, kann ihr abschliessender Session-Eintrag fehlen; dann sind Packet Capture und Live Connections die bessere Gegenprobe.

Object Usage vor Änderungen aktualisieren

Ein Objekt kann in Firewall- und NAT-Regeln, VPNs, SD-WAN-Routen oder weiteren Konfigurationen verwendet werden. Vor einer Änderung oder Löschung muss deshalb zuerst geprüft werden, welche Abhängigkeiten bestehen.

In der Objektliste zeigt die Spalte Usage die bekannte Anzahl der Verwendungen. Dieser Zähler wird automatisch nur einmal täglich aktualisiert. Vor einer Änderung:

1. Neben Usage auf Refresh klicken.
2. Den aktualisierten Zähler des betroffenen Objekts öffnen.
3. Kategorien aufklappen und jede abhängige Regel oder Policy prüfen.
4. Erst danach entscheiden, ob das Objekt geändert, ersetzt oder gelöscht werden kann.

Nicht jede Abhängigkeit lässt sich direkt aus der Usage-Ansicht bearbeiten. Einige Abhängigkeiten, etwa WAN-Gateways und CLI-Konfigurationen, müssen an der angegebenen Konfigurationsstelle separat geöffnet werden. Ein Zähler von null ist erst nach dem manuellen Refresh eine belastbare Grundlage.

Objekte sicher betreiben

Typische Fehler vermeiden

• Host statt Network: Eine einzelne IP deckt nicht automatisch das zugehörige Subnetz ab.
• Falsche Netzadresse oder Maske: Bei einem Network-Objekt müssen Netzadresse und Präfix zur realen Segmentierung passen.
• Source Port eingeschränkt: Bei normalen Client-Server-Verbindungen bleibt 1:65535 bestehen; begrenzt wird der Destination Port.
• Zu viel Any: Ein genaues Hostobjekt verliert seinen Sicherheitswert, wenn Source oder Service unnötig breit bleiben.
• Systemobjekt dupliziert: Interface- und Remote-Access-Hosts werden von SFOS gepflegt und sollten nicht ohne konkreten Grund kopiert werden.
• IP list als Threat Feed: Eine IP-Liste bleibt statisch und eignet sich nicht als Ersatz für automatisch aktualisierte Bedrohungsindikatoren.
• Abhängigkeiten nicht aktualisiert: Vor Bearbeiten oder Löschen immer Refresh bei Object Usage ausführen.

Sprechende Präfixe wie host_, net_, range_, svc_ und grp_ sind keine technische Pflicht, erleichtern aber Suche und Review. Wichtiger als das konkrete Schema ist, dass Name, Zweck und Gültigkeitsbereich im gesamten Regelwerk konsistent bleiben.

Bestand klein und nachvollziehbar halten

SFOS unterstützt insgesamt bis zu 16'000 Hosts über alle Hosttypen. Das ist eine Plattformgrenze und kein Planungsziel. Für den Betrieb ist eine kleinere, verständliche Objektbasis wertvoller als viele kaum unterscheidbare Einträge. Nicht mehr benötigte Objekte werden erst nach aktualisierter Usage-Prüfung kontrolliert ersetzt oder bereinigt.