Sophos Firewall FQDN-Hosts und Wildcard-FQDNs richtig verwenden

FQDN-Hosts sind praktisch, wenn ein Ziel nicht zuverlässig über eine feste IP-Adresse beschrieben werden kann. Typische Beispiele sind Cloud-Dienste, Update-Server, Authentifizierungsendpunkte oder Herstellerdienste, deren IP-Adressen sich ändern können.

Ein FQDN-Host ist aber kein Ersatz für eine Web Policy, keine vollständige URL-Kontrolle und auch keine Garantie, dass jede Anwendung sauber matcht. Entscheidend ist, wie die Sophos Firewall den Namen auflöst oder bei Wildcards aus DNS-Traffic lernt.

Wann FQDN-Hosts sinnvoll sind

FQDN-Hosts passen gut zu Regeln, bei denen ein technisches Ziel über einen DNS-Namen stabiler beschrieben ist als über einzelne IP-Adressen. Das ist vor allem bei ausgehendem Traffic hilfreich.

Sinnvolle Beispiele:

Ein interner Server darf nur zu updates.vendor.example verbinden.
Eine Anwendung braucht Zugriff auf wenige bekannte Hersteller-FQDNs.
Ein bestimmter Cloud-Endpunkt soll in einer Firewall-Regel, NAT-Regel, SD-WAN-Route oder VPN-Konfiguration verwendet werden.
Ein Troubleshooting-Fall soll zeigen, ob eine Regel gegen den erwarteten Namen oder gegen eine unerwartete IP-Adresse matcht.

Weniger geeignet sind FQDN-Hosts für breite Webfreigaben wie “alles unter einem SaaS-Dienst”, wenn die Anwendung viele Domains, CDNs, APIs, Telemetrie- und Login-Endpunkte nutzt. Für Webzugriffe sind Web Policies, URL-Gruppen, DNS Protection, Application Control oder TLS Inspection oft die bessere Ebene.

Sophos Firewall kann FQDN-Hosts nicht nur in Firewall-Regeln verwenden, sondern auch in Einstellungen wie SD-WAN Policy Routes, VPN-Settings und technischen Hostobjekten für Mail-, Proxy-, DNS-, Authentifizierungs-, Remote-Access-, Web- oder Syslog-Server. Trotzdem sollte man pro Einsatzort prüfen, ob ein DNS-Name dort wirklich stabiler ist als ein IP-Objekt oder eine dedizierte Policy-Ebene.

Wenn es um die Regel selbst geht, hilft zuerst Sophos Firewall-Regeln verstehen und sicher konfigurieren. Wenn eine Regel nicht trifft, ist Sophos Firewall-Regel greift nicht: Ursachen prüfen der passende Troubleshooting-Artikel.

Normaler FQDN-Host oder Wildcard-FQDN

Sophos Firewall behandelt normale FQDN-Hosts und Wildcard-FQDNs unterschiedlich. Das ist der wichtigste Punkt im Betrieb.

Normaler FQDN-Host

Bei einem normalen FQDN-Host, zum Beispiel updates.vendor.example, fragt die Firewall den Namen per DNS ab. Die zurückgegebenen IP-Adressen werden für das Objekt verwendet. Wenn der DNS-Eintrag eine TTL hat, aktualisiert die Firewall die Auflösung nach Ablauf dieser TTL.

Das funktioniert gut, wenn:

der FQDN direkt auf die benötigten IP-Adressen zeigt,
die Anwendung genau diesen Namen verwendet,
die DNS-Antworten nicht ständig zwischen sehr vielen CDN-Zielen wechseln,
der Test mit derselben Namensauflösung erfolgt, die auch die Firewall sieht.

Wildcard-FQDN

Bei einem Wildcard-FQDN, zum Beispiel *.example.com, löst die Firewall nicht einfach “alle möglichen Subdomains” auf. Das wäre technisch nicht möglich, weil DNS keine vollständige Liste aller Subdomains liefert.

Stattdessen lernt die Firewall passende IP-Adressen aus DNS-Antworten. Das klappt zuverlässig, wenn die Firewall den DNS-Traffic sieht:

Die Sophos Firewall ist selbst DNS-Server für die Clients.
Oder der DNS-Traffic läuft durch die Firewall und wird per DPI erkannt.
Laut Sophos bezieht sich dieses Lernen auf UDP-DNS-Traffic über Port 53 zu externen DNS-Servern.

Wenn Clients DNS-over-HTTPS, DNS-over-TLS, einen anderen DNS-Pfad oder einen lokalen Resolver verwenden, sieht die Firewall die relevanten DNS-Antworten möglicherweise nicht. Dann bleibt ein Wildcard-FQDN leer oder unvollständig, obwohl der Domainname im Browser funktioniert.

FQDN-Host anlegen

Der Menüpfad lautet:

Hosts and services > FQDN host > Add

Für ein sauberes Objekt sind wenige Felder wichtig:

Name: sprechend und technisch stabil, zum Beispiel fqdn_vendor_updates oder wfqdn_example_subdomains.
FQDN: der vollständige Name, zum Beispiel updates.vendor.example oder *.example.com.
FQDN host group: optional eine bestehende Gruppe auswählen oder eine neue Gruppe erstellen. Ein FQDN-Host kann zu mehreren FQDN-Host-Gruppen gehören.
Schreibweise: FQDNs klein schreiben. Sophos weist darauf hin, dass Grossbuchstaben in FQDN-Hosts nicht unterstützt werden.

Nach dem Eintragen der Felder wird das Objekt mit Save gespeichert.

Nach dem Speichern sollte das Objekt nicht sofort blind in produktive Regeln eingebaut werden. Besser ist ein kurzer Test: Löst die Firewall den Namen auf, sieht der Log Viewer später die erwartete Ziel-IP, und passt diese IP zur DNS-Antwort des Clients?

In Firewall-Regeln verwenden

In den meisten Designs gehört ein FQDN-Host in ausgehenden Regeln in das Feld Destination networks. Die Regel beschreibt dann, welche internen Quellen zu welchem dynamischen Ziel dürfen.

Typischer Ablauf:

Unter Hosts and services > FQDN host das FQDN-Objekt anlegen.
Unter Rules and policies > Firewall rules die passende Regel öffnen oder neu erstellen.
Source zones und Source networks and devices eng definieren.
Destination zones bewusst wählen, meistens WAN.
Unter Destination networks das FQDN-Objekt auswählen.
Unter Services nur die benötigten Ports erlauben, zum Beispiel HTTPS.
Logging aktivieren.
Einen echten Test durchführen und im Log Viewer Rule ID, Destination IP, NAT Rule ID und Service prüfen.

Ein FQDN-Host macht eine Regel nicht automatisch sicher. Wenn Source Any, Service Any und Destination ein breites Wildcard-Objekt ist, entsteht schnell eine sehr offene Regel. Besser ist eine kleine Regel mit klarer Quelle, klarem Dienst, aktivem Logging und dokumentiertem Zweck.

Grenzen und Stolperfallen

Viele FQDN-Probleme entstehen nicht in der Regelliste, sondern beim DNS-Verhalten der Clients oder Anwendungen.

Die Firewall sieht andere DNS-Antworten

Wenn Client und Firewall unterschiedliche DNS-Resolver verwenden, können sie unterschiedliche IP-Adressen für denselben Namen erhalten. Das ist bei CDNs normal. Dann kann eine Regel gegen eine IP matchen, während der Client eine andere IP verwendet.

Bei Problemen sollte man vergleichen:

Welche IP liefert nslookup oder dig auf dem Client?
Welche Destination IP zeigt der Log Viewer?
Welche DNS-Server verwenden Client und Firewall?
Wird DNS über Port 53, DNS-over-HTTPS oder DNS-over-TLS verwendet?

Wildcard-FQDN lernt nichts

Ein Wildcard-FQDN funktioniert nur, wenn die Firewall die passenden DNS-Antworten sieht. Nutzt ein Client DoH im Browser oder einen DNS-Pfad, der nicht durch die Firewall läuft, kann die Firewall die Subdomains nicht lernen.

In solchen Fällen hilft nicht das Verschieben der Firewall-Regel, sondern eine Entscheidung zum DNS-Design: Firewall als DNS-Forwarder verwenden, DNS-Traffic kontrolliert über die Firewall führen oder für Webzugriffe eine andere Kontrollebene einsetzen.

Der FQDN ist zu breit

Ein Wildcard wie *.example.com kann viel mehr umfassen als ursprünglich gedacht. Moderne SaaS-Dienste nutzen Login-Domains, API-Domains, Medien-CDNs, Telemetrie, Supportdienste und Drittanbieter. Manchmal ist ein einzelnes Wildcard-Objekt zu grob.

Wenn die Freigabe fachlich breit sein muss, ist eine Web Policy, URL-Gruppe oder Application Control oft verständlicher und prüfbarer als eine sehr grosse FQDN-Firewall-Regel.

Mehrere Domains zeigen auf dieselbe IP

Sophos weist darauf hin, dass FQDN-Hosts nicht dafür gedacht sind, mehrere Domains sauber zu unterscheiden, wenn diese auf dieselbe IP-Adresse zeigen. Auf IP-Ebene kann die Firewall nicht immer erkennen, welche Domain eine Anwendung später tatsächlich verwendet.

Für domainbasierte Webentscheidungen ist deshalb die Webebene besser geeignet als eine reine IP-basierte Firewall-Regel mit FQDN-Objekt.

Troubleshooting

Wenn eine FQDN-Regel nicht wie erwartet greift, sollte zuerst die tatsächliche Verbindung geprüft werden. Nicht der Name im Objekt ist entscheidend, sondern die IP-Adresse, die im Moment des Tests verwendet wird.

Regel matcht nicht

Prüfen:

Stimmt die Source Zone?
Stimmt die Source IP oder das Source-Netz?
Stimmt der Service, zum Beispiel TCP 443 statt nur HTTP?
Zeigt der Log Viewer eine andere Rule ID?
Zeigt der Log Viewer eine Destination IP, die nicht zur aktuellen DNS-Antwort passt?
Ist eine allgemeinere Regel oberhalb der FQDN-Regel aktiv?

Wenn der Log Viewer eine andere Regel zeigt, ist die Reihenfolge wichtiger als das FQDN-Objekt. Wenn der Log Viewer gar nichts zeigt, erreicht der Traffic die Firewall nicht oder Logging ist nicht aktiv.

Wildcard-FQDN bleibt leer

Prüfen:

Nutzt der Client die Firewall als DNS-Server?
Läuft DNS sichtbar über die Firewall?
Nutzt der Client DoH oder DoT?
Wird UDP 53 verwendet?
Gibt es eine DNS-Request-Route oder einen internen Resolver, der die Antwort vor der Firewall versteckt?

Falls DNS bewusst intern geroutet wird, kann DNS Request Routes auf Sophos Firewall einrichten helfen, das DNS-Design sauberer einzuordnen.

DNS hat sich geändert, Regel wirkt verzögert

FQDN-Objekte arbeiten mit DNS-Antworten und Caches. Wenn sich ein Anbieterziel ändert, kann es eine Verzögerung geben, bis die Firewall den neuen Stand verwendet. Bei normalen FQDN-Hosts ist die TTL des DNS-Eintrags entscheidend.

Sophos bietet CLI-Optionen für FQDN-Hosts, etwa cache-ttl, idle-timeout, eviction und learn-subdomains. cache-ttl kann die TTL aus der DNS-Antwort verwenden oder auf einen Wert zwischen 60 und 86400 Sekunden gesetzt werden. idle-timeout entfernt ungenutzte Bindings standardmässig nach 3600 Sekunden. eviction steuert, wann gelernte IP-Adressen von Wildcard-Subdomains entfernt werden. Wenn cache-ttl geändert wird, gilt der neue Wert nur für neu aufgelöste Einträge; bereits gecachte Einträge behalten ihren bisherigen Wert bis zum Ablauf.

Diese Werte sollte man nicht als erste Massnahme verändern. Besser ist zuerst zu prüfen, ob das DNS-Design, der Resolver-Pfad und die Regelbasis stimmen. Tuning gehört in ein dokumentiertes Betriebs- oder Support-Vorgehen.

Betriebsempfehlung

FQDN-Hosts bleiben übersichtlich, wenn sie wie technische Abhängigkeiten behandelt werden und nicht wie spontane Ausnahmen.

Bewährt hat sich:

Pro FQDN-Objekt einen klaren Zweck dokumentieren.
Wildcards sparsam verwenden.
FQDN-Objekte in Regeln mit enger Source und engem Service kombinieren.
Logging für neue oder kritische Regeln aktivieren.
Nach Änderungen mit Log Viewer und DNS-Abfrage testen.
Breite Webfreigaben nicht als grosse FQDN-Regel verstecken.
Bei SaaS- oder Cloud-Diensten regelmässig prüfen, ob der Hersteller neue Domains benötigt.

Sophos nennt zwar bis zu 16'000 mögliche FQDN-Hosts, aber das ist keine Einladung zu unkontrolliertem Wachstum. Viele alte FQDN-Ausnahmen erschweren Review, Troubleshooting und Regelpflege. Besser ist eine kleinere, dokumentierte Objektliste mit Owner, Zweck und Review-Datum.

Wenn ein Objekt nur erstellt wurde, weil “eine Anwendung sonst nicht funktioniert”, sollte es später nochmals überprüft werden. Gerade solche Notfallobjekte werden sonst zu dauerhaften, schwer erklärbaren Ausnahmen.

FAQ

Was ist der Unterschied zwischen FQDN-Host und IP-Host?

Ein IP-Host beschreibt eine feste Adresse oder ein festes Netz. Ein FQDN-Host beschreibt einen DNS-Namen, dessen aktuelle IP-Adressen die Firewall verwenden kann. Das ist hilfreich bei dynamischen Zielen, aber abhängig von DNS-Auflösung und Cache-Verhalten.

Funktioniert `*.example.com` automatisch für alle Subdomains?

Nicht im Sinn einer vollständigen Domainliste. Die Firewall muss passende DNS-Antworten sehen und daraus IP-Adressen lernen. Wenn DNS nicht sichtbar über die Firewall läuft, kann ein Wildcard-FQDN unvollständig bleiben.

Warum matcht meine FQDN-Regel nicht?

Meist passt nicht der Regelkontext, die Reihenfolge oder die tatsächlich verwendete Ziel-IP. Im Log Viewer sollte geprüft werden, welche Rule ID, Destination IP, Destination Port und NAT Rule ID beim echten Test erscheinen.

Funktionieren FQDN-Hosts mit DNS-over-HTTPS oder DNS-over-TLS?

Wildcard-FQDNs sind problematisch, wenn Clients DoH oder DoT verwenden und die Firewall die DNS-Antworten nicht sieht. Dann kann die Firewall die benötigten Subdomains nicht zuverlässig lernen.

Soll man FQDN-Hosts für Webfiltering verwenden?

Nur gezielt. Für echte Websteuerung sind Web Policies, URL-Gruppen, DNS Protection, Application Control oder TLS Inspection meistens geeigneter. FQDN-Hosts sind gut für technische Ziele in Netzwerkregeln, aber keine vollständige URL-Policy.