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.

Für SFOS 22 gilt eine wichtige IPv6-Grenze: FQDN-Hostobjekte lösen keine IPv6-Adressen auf. Das schliesst DNS Lookup oder AAAA-Antworten für normale Clients nicht aus, aber das Objekt selbst pflegt diese IPv6-Ziele nicht. Die Abgrenzung zu den übrigen unterstützten und nicht unterstützten Funktionen zeigt Sophos Firewall IPv6 Support und Grenzen in SFOS 22.

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. Dafür muss sie die passenden Antworten sehen; bei Transit-DNS muss zusätzlich learn-subdomains aktiviert sein. Sichtbarer DNS-Traffic allein garantiert noch kein erfolgreiches Lernen. Die dokumentierten Lernpfade sind:

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?

Mehrere FQDN-Hosts als Gruppe verwenden

Eine FQDN host group fasst mehrere bereits angelegte FQDN-Hosts zu einem wiederverwendbaren Objekt zusammen. Gruppen lassen sich unter anderem in Firewall-Regeln und SD-WAN Policy Routes auswählen.

Der Menüpfad lautet Hosts and services > FQDN host group > Add. Unter Name eine eindeutige Bezeichnung eintragen, die benötigten Hosts auswählen und mit Save speichern. Für eine Anwendung mit getrennten Endpunkten könnte die Gruppe grp_vendor_service beispielsweise login.vendor.example, api.vendor.example und updates.vendor.example enthalten. Ein Host darf Mitglied mehrerer Gruppen sein. Nur tatsächlich benötigte Namen aufnehmen; ein zusätzlicher Host erweitert jede Regel, die diese Gruppe verwendet.

Die Listen FQDN host und FQDN host group können anhand aller angezeigten Attribute durchsucht werden. Vor einer Änderung oder Löschung separat prüfen, in welchen Firewall-Regeln, SD-WAN Policy Routes oder anderen Konfigurationen das Objekt verwendet wird. Bei einer gemeinsam genutzten Gruppe wirkt sich eine Änderung auf alle diese Verwendungen aus.

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.

Sonderfall: vordefinierte Gruppen für Web-Proxy-Regeln

Die vordefinierten Gruppen SafeSearch enforcement, YouTube restrictions enforcement und Google app enforcement sind ausschliesslich für Regeln gedacht, die SafeSearch, YouTube-Einschränkungen oder Google-Workspace-Anmeldungen über den Web Proxy erzwingen. Sie ersetzen keine selbst erstellte Liste allgemeiner SaaS-Ziele.

Bevor eine solche Regel aktiviert wird, müssen das CA-Vertrauen auf einer Pilotgruppe, passende Entschlüsselungsausnahmen und konkrete HTTP-/HTTPS-Abnahmetests vorbereitet sein. Der Ablauf dafür steht in Sophos Firewall TLS Inspection schrittweise einführen.

In der eigenen Firewall-Regel Action auf Allow und Destination zones auf WAN setzen. Unter Destination networks die benötigten vordefinierten Gruppen und unter Services HTTP sowie HTTPS auswählen. Zusätzlich Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine und Decrypt HTTPS during web proxy filtering aktivieren. Die Regel muss oberhalb der Regeln stehen, die denselben Traffic mit der DPI Engine verarbeiten.

Nach dem Test im Log Viewer und im Browser prüfen, ob nur die vorgesehene Pilotgruppe über diese Regel läuft und die gewünschte Einschränkung greift. Für den Rückweg die neue Proxy-Regel deaktivieren und verifizieren, dass der Traffic wieder über die darunterliegende DPI-Regel verarbeitet wird. Die Regel erst löschen, wenn dieser Zustand bestätigt ist.

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. Bei DNS-Traffic, der die Firewall nur durchquert, zusätzlich prüfen, ob learn-subdomains aktiviert ist. Das ist eine weitere Voraussetzung, keine Erfolgsgarantie.

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 dokumentiert ausdrücklich, dass FQDN-Hosts mehrere Domains, die auf dieselbe IP-Adresse auflösen, nicht unterstützen. Ein FQDN-Objekt arbeitet mit den aufgelösten IP-Adressen und kann solche Domains auf IP-Ebene nicht voneinander unterscheiden. Deshalb darf man damit keine zuverlässige Trennung der Domains erwarten.

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, sind fehlender Traffic an der Firewall oder inaktives Logging mögliche Ursachen, aber nicht die einzigen. Auch das gewählte Modul sowie Zeit-, Feld- und Suchfilter prüfen. Firewall-Regelsitzungen werden erst beim Schliessen der Verbindung mit einem empfangenen Destroy-Ereignis protokolliert; schliesst die Verbindung ohne dieses Ereignis, kann der Sitzungslog fehlen. Eine noch offene Verbindung ist daher ebenfalls zu berücksichtigen. Mit einem gezielten Packet Capture prüfen, ob die Testpakete die Firewall erreichen; ein leerer Log Viewer allein beweist das Gegenteil nicht.

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?
Ist bei Transit-DNS learn-subdomains aktiviert? Sichtbare DNS-Antworten allein garantieren noch kein gelerntes Binding.
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.

In der Device Console stellt Sophos dafür die systemweite Befehlsfamilie set fqdn-host bereit; sie ändert nicht nur ein ausgewähltes Hostobjekt. cache-ttl verwendet standardmässig dns-reply-ttl oder kann auf 60 bis 86400 Sekunden gesetzt werden. idle-timeout entfernt ungenutzte Bindings nach 60 bis 86400 Sekunden; der Default beträgt 3600 Sekunden. Mit eviction lässt sich steuern, ob und nach welchem Intervall gelernte IP-Adressen von Wildcard-Subdomains entfernt werden; das Intervall liegt zwischen 60 und 86400 Sekunden. learn-subdomains aktiviert oder deaktiviert das Lernen dieser Adressen bei Transitverkehr, der die Firewall durchquert, aber weder von ihr stammt noch an sie gerichtet ist. 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.

Vor einer begründeten Ausnahmeänderung in der CLI 4. Device Console wählen, nicht die Advanced Shell. Der folgende lesende Befehl zeigt die konfigurierten FQDN-Parameter in SFOS 22 und 23:

show fqdn-host

Die vollständige Ausgabe als Ausgangsstand sichern: cache-ttl, idle-timeout, learn-subdomains sowie den Zustand und das Intervall der IP-Eviction. Für Lernen und Eviction keine Standardwerte voraussetzen. Die Ausgabe zeigt Einstellungen, nicht die aktuell gelernten IP-Bindings und auch keinen erfolgreichen Anwendungstest.

Diese Werte sollte man nicht als erste Massnahme verändern. Besser ist zuerst zu prüfen, ob DNS-Design, Resolver-Pfad und Regelbasis stimmen. Vor einer Änderung die aktuellen Werte vollständig dokumentieren, jeweils nur einen Parameter ändern und die Wirkung mit neu aufgelösten Einträgen prüfen. Der Rückweg ist der dokumentierte Ausgangswert; für den Standard-TTL ist dies dns-reply-ttl. Tuning gehört in ein dokumentiertes Betriebs- oder Support-Vorgehen.

Nach einer begründeten Änderung genau eines Parameters erneut show fqdn-host ausführen und die Ausgabe mit dem gesicherten Ausgangsstand vergleichen: Nur die beabsichtigte Einstellung darf abweichen. Davon getrennt mit einer neuen DNS-Auflösung die tatsächlich verwendete Ziel-IP und den Anwendungsverkehr über die erwartete Firewall-Regel im Log Viewer prüfen; ein korrekter Konfigurationswert allein beweist die Wirkung nicht. Falls die Änderung zurückgenommen wird, den exakt gesicherten Wert einschliesslich eines zuvor eingestellten Intervalls wiederherstellen und mit show fqdn-host zurücklesen. Anschliessend DNS-Auflösung und Anwendungs-/Regeltest wiederholen; bestehende Cache-Einträge werden durch eine TTL-Änderung nicht sofort umgeschrieben.

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.

Die CLI-Dokumentation nennt bis zu 16'000 FQDN-Hosts. Für SFOS 22 dokumentiert Sophos jedoch eine gemeinsame Obergrenze von 16'000 Hosts über alle Hosttypen hinweg; daraus darf man keine zusätzliche, unabhängige FQDN-Kapazität oder freie Reserve ableiten. Diese Obergrenze 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.