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.

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.

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: list_test_hosts kann beispielsweise 192.0.2.10,198.51.100.20 enthalten. Die Liste 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.

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.

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.
• ##WWAN1 wird für das Cellular-WAN-Interface dynamisch gepflegt.
• ##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW und ##ALL_RW repräsentieren dynamische Remote-Access-Hosts.
• 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.

Service mit richtigem Zielport anlegen

Vor einem neuen Service sollte geprüft werden, ob ein passender Standardservice wie HTTP, HTTPS, DNS oder NTP 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.

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.

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. 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. Erwartet werden die richtige Rule ID, Source IP, Destination IP und der richtige Destination Port. So lässt sich unterscheiden, ob das Objekt falsch definiert ist oder eine andere Regel den Traffic verarbeitet.

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.

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.

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