Sophos DNS Protection mit Sophos Firewall einrichten

Sophos DNS Protection prüft DNS-Abfragen über einen Cloud-Dienst und verwaltet Policies sowie Reports in Sophos Fusion (ehemals Sophos Central). Damit lassen sich bösartige Domains, Phishing, Command-and-Control-Ziele und unerwünschte Kategorien blockieren, bevor ein Client die eigentliche Verbindung aufbaut.

Mit Sophos Firewall ist der sauberste Standardaufbau meistens: Clients verwenden die Firewall als DNS-Resolver, die Firewall leitet öffentliche Anfragen an DNS Protection weiter, und interne Domains gehen über DNS Request Routes an interne DNS-Server.

DNS Protection ersetzt weder Web Protection noch Threat Feeds oder NDR und Active Threat Response. Es ergänzt diese Kontrollen auf DNS-Ebene.

Diese Anleitung bleibt bewusst bei Sophos Firewall: Sie führt von den Fusion-Werten über DNS-Forwarding, Request Routes und DHCP bis zu NAT, Abnahme und Rückbau. Die herstellerneutrale Architektur und die erforderlichen Freigaben stehen unter DNS Protection im Netzwerk planen und einrichten. Das Anlegen, Ändern und Löschen einer Location beschreibt die Anleitung DNS Protection Locations sicher verwalten.

Entscheidung und Zielbild

DNS ist eine Basisfunktion. Wenn der Resolver langsam, instabil oder zu restriktiv ist, wirkt das für Benutzer schnell wie ein allgemeiner Netzwerkausfall. DNS Protection sollte deshalb nur eingesetzt werden, wenn der Mehrwert aus Fusion-Policies, Kategorien, Logs oder dem Schutz von Roaming-Clients den zusätzlichen Betriebsaufwand rechtfertigt.

Aus Avanet-Sicht sind schnelle, redundante Resolver plus sauber gepflegte Threat Feeds für viele klassische Firewall-Installationen die pragmatischere Lösung. DNS Protection passt besonders, wenn:

• DNS-Abfragen in Sophos Fusion sichtbar sein sollen.
• Standorte unterschiedliche DNS-Policies benötigen.
• Kategorien bereits bei der Namensauflösung blockiert werden sollen.
• Clients keine beliebigen öffentlichen Resolver verwenden dürfen.
• verwaltete Windows-Endpoints auch ausserhalb des Firmennetzes geschützt werden sollen.

Version zuerst wählen: Ab SFOS 23.0 den unten beschriebenen integrierten DoH-Pfad mit Firewall-Zuweisung verwenden. Aussagen zu öffentlicher Source-IP, DDNS, zwei statischen Forwardern und Location-Zuordnung beschreiben im Folgenden den Traditional-DNS-Pfad auf SFOS 22 und älter, nicht die Voraussetzungen des neuen Firewall-Pfads. Endpoint Secure DNS bleibt ein separater Pfad.

Der Traditional-DNS-Pfad auf SFOS 22 und älter sieht so aus:

1. Sophos Fusion kennt den Standort als Location.
2. Sophos Fusion stellt zwei DNS-Protection-IP-Adressen bereit.
3. Sophos Firewall nutzt beide Adressen als DNS-Forwarder.
4. DNS Request Routes senden interne Zonen an interne DNS-Server.
5. DHCP verteilt die Firewall als Resolver an die Clients.
6. Optional zwingt eine NAT-Regel klassischen DNS-Traffic auf diesen Pfad.
7. Sophos Fusion protokolliert und bewertet die öffentlichen DNS-Abfragen.

Dabei sind zwei Verfahren zu unterscheiden:

• Traditional DNS over IPv4: für Firewalls, Router und lokale Resolver. Sophos ordnet Anfragen anhand der öffentlichen Source-IP oder eines DDNS-FQDN der Location zu.
• Secure DNS: DNS over HTTPS (DoH) für kompatible Geräte. Sophos Endpoint kann diesen Pfad auf unterstützten Windows-Endpoints verwalten; Windows und macOS lassen sich auch manuell für Secure DNS konfigurieren.

Eine benutzerdefinierte Location kann beide Verfahren unterstützen. Für die Firewall-Weiterleitung muss Traditional DNS aktiviert und die öffentliche IP oder der FQDN hinterlegt sein.

Vier DNS-Pfade nicht vermischen

Für die Fehlersuche ist entscheidend, an welcher Stelle eine Abfrage verarbeitet wird:

• DNS-Protection-Dienst: Der Cloud-Resolver bewertet öffentliche Abfragen anhand der Filtering Policy der erkannten Location. Seine Reports liegen in Sophos Fusion, nicht im Firewall-Logviewer.
• Firewall als Resolver: Der Client fragt eine Interface-IP der Firewall auf UDP oder TCP 53 ab. Die lokale DNS-Funktion entscheidet zwischen DNS Request Route und den unter Network > DNS konfigurierten Forwardern. Unter Administration > Device access muss DNS für die Quellzone erlaubt sein. Da dies ein lokaler Dienst ist, kann der Zugriff nicht mit einer Firewallregel freigegeben werden.
• Transit-DNS: Fragt ein Client eine öffentliche Resolver-IP direkt ab, leitet die Firewall nur Verkehr weiter. Dafür gilt eine Firewallregel; die DNS Request Routes der Firewall greifen nicht. Eine protokollierte Firewallregel belegt daher nur den Transport, nicht die Auswertung durch DNS Protection.
• Endpoint DNS Protection: Sophos Endpoint fängt unterstützte Windows-Abfragen ab und sendet sie per HTTPS an die Secure-DNS-Location. Eine Port-53-NAT-Regel und die Request Routes der Firewall liegen nicht in diesem Pfad. Nur ausgeschlossene Domains beziehungsweise der optionale NXDOMAIN-Retry gehen an die lokal konfigurierte DNS-Auflösung.

Im empfohlenen Standortaufbau nutzen Clients den Firewall-Resolver. Direkter Transit zu den DNS-Protection-IP-Adressen ist kein gleichwertiger Ersatz, sobald interne Zonen über Request Routes aufgelöst werden müssen.

Vor dem Rollout müssen Lizenz, öffentliche Ausgangsadressen, interne DNS-Zonen, DHCP-Server und Verantwortliche für Policies sowie Ausnahmen geklärt sein. Xstream Protection deckt Standalone DNS Protection für die Firewall ab. Workspace Protection deckt DNS Protection für Endpoints ab; auf den Geräten muss Sophos Endpoint installiert sein. Beide Lizenzen enthalten die DoH-Funktion.

Damit DNS Protection in Sophos Fusion als Produkt erscheint, muss die Xstream-lizenzierte Firewall mit demselben Fusion-Konto verknüpft sein. Die Lizenz lässt sich auf der Firewall unter Administration > Licensing oder in Sophos Fusion auf der Seite Firewall Licensing prüfen. Sophos nennt dafür drei Verknüpfungswege: Registrierung während der Installation, Claim der Seriennummer unter Firewall Licensing oder Aktivierung des Sophos-Fusion-Managements in der WebAdmin-Konsole.

Lizenzentscheid und Fusion-Berechtigungen gehören in die bestehenden Prozesse für Sophos-Fusion-Lizenzierung und administrative Rollen. Die für die Firewall verantwortliche Person benötigt Zugriff auf DNS Protection sowie die freigegebenen Tenant-Werte; Rollen sollten jedoch nicht nebenbei erweitert werden.

Die vordefinierte Location Default ist für Secure DNS nutzbar und kann Policies zugewiesen werden; sie lässt sich lediglich nicht bearbeiten oder löschen. Insgesamt sind maximal 50 Locations und 100 öffentliche IPv4-/FQDN-Einträge pro Location möglich. Locations sollten daher nach Standort und Internet-Egress statt nach jedem VLAN aufgebaut werden.

SFOS 23.0: DNS Protection über DoH einrichten und migrieren

Ab SFOS 23.0 nutzt der integrierte DNS Protection-Schalter DNS over HTTPS (DoH). Die Filtering Policy wird dem Firewall-Objekt zugewiesen, nicht mehr der bisherigen IP-/FQDN-Location. Voraussetzungen sind Xstream Protection und die Registrierung der Firewall in Sophos Fusion; bei HA müssen beide Firewalls registriert sein. Vor der Umstellung die bisherigen DNS-Einstellungen, die Policy-Zuweisung und die Location-Werte für den Rückweg dokumentieren.

Vor der Umstellung: Prüfen, ob die bisherige Location ausschliesslich den DNS-Pfad dieser Firewall abbildet oder auch von anderen Resolvern beziehungsweise Endpoint Secure DNS verwendet wird. Bei gemeinsamer Nutzung die Location weder aus ihrer bisherigen Filtering Policy entfernen noch löschen. Die unten beschriebene Ersetzung erst ausführen, wenn die Policy-Zuweisung der übrigen Verbraucher separat geklärt und erhalten ist; bis dahin die Migration stoppen.

Aktivieren und Policy zuweisen

1. Auf der Firewall unter Network > DNS DNS Protection einschalten.
2. Fall back to DNS server bewusst entscheiden: Ist die Option aktiv, muss unter DNS server settings ein DNS-Server konfiguriert werden. Ohne diese Option lassen sich bei aktivem DNS Protection dort keine DNS-Server konfigurieren. Ein Fremdresolver als Fallback erhöht die Verfügbarkeit, kann bei Nichterreichbarkeit von DNS Protection aber dessen Filterung und Sichtbarkeit umgehen. Die Entscheidung und den Ersatzresolver dokumentieren; DoH zu einem beliebigen Anbieter ist nicht automatisch DNS Protection.
3. In Sophos Fusion My Products > DNS Protection > Policies > Filtering policies öffnen. Für eine neue Einrichtung Add policy wählen, unter Locations and firewalls > Available die Firewall auswählen und nach Assigned to this policy verschieben. Type muss Firewall sein; der Name enthält das Firewall-Label und die Seriennummer. Unter Settings die vorgesehenen Filter festlegen und die Policy speichern.

Bestehende Traditional-DNS-Zuweisung ersetzen

Nach dem Upgrade und dem Einschalten von DNS Protection die bestehende Filtering Policy öffnen. Unter Locations and firewalls die bisher für diese Firewall angelegte Location von Assigned to this policy nach Available verschieben. Danach die Firewall von Available nach Assigned to this policy verschieben und Save wählen. Erst nach dem Speichern darf die alte Location gelöscht werden. Als Avanet-Betriebsempfehlung bleibt sie bis zur erfolgreichen Pilotabnahme erhalten; nicht löschen, wenn andere Resolver oder Geräte sie noch benötigen. Diese Migration gilt nicht für Drittanbieter-Resolver oder Endpoint Secure DNS.

Pilot prüfen und zurückrollen

Clients verwenden weiterhin die Firewall als Resolver. Die nachfolgenden Schritte für DNS Request Routes, DHCP und optionale Port-53-NAT-Umleitung gelten auch hier; die alten Schritte für Location und statische Forwarder werden nicht zusätzlich ausgeführt. Unter Network > DNS > Test name resolution einen öffentlichen Namen in Hostname or IP address eingeben und Test connection wählen. Server, verwendetes Protokoll, Ergebnis und Antwortzeit prüfen. Zusätzlich interne Namen und Reverse-Lookups sowie eine harmlose, gezielt per Policy blockierte Domain vom Pilotclient prüfen. Die Firewall-Zuweisung in Fusion und die DNS-Protection-Reports kontrollieren; eine erfolgreiche Namensauflösung allein beweist keine wirksame Filtering Policy. Ohne erfolgreichen Pilot keine breite Umstellung. Diese Anleitung wurde nicht auf einer SFOS-23-Firewall lab-getestet.

Für den Rückweg zuerst die erhaltene Traditional-DNS-Location wieder der bisherigen Policy zuweisen, die Firewall-Zuweisung zurücknehmen und Save wählen. Danach DNS Protection auf der Firewall ausschalten und die dokumentierte bisherige DNS-Konfiguration unter DNS server settings wiederherstellen. Das sind SFOS-23-Felder, nicht die unten gezeigten SFOS-22-Feldnamen. Request Routes und unveränderte Client-DNS-Werte beibehalten, öffentliche und interne Auflösung sowie Filterwirkung erneut prüfen. Wurde die Location bereits gelöscht, muss sie vor diesem Rückweg mit den dokumentierten Werten neu angelegt werden.

XML API: dokumentierte Änderungen, aber kein sicheres Kopierrezept

Die SFOS-23-XML-API-Dokumentation für DNS List ergänzt DNSProtection mit Enabled und Fallback, DNSProtocol, DNSOverHTTPS mit DNSServer1 bis DNSServer3 sowie URL, IPv4Address und IPv6Address, ausserdem FallbackToUnencryptedDns und DNSSecProtection. Die Beispielkommentare knüpfen IPv4-/IPv6-Einstellungen an UnencryptedDNS und den DoH-Block an DNSOverHTTPS; für DoH wird DNSServer1 verlangt und je Server entweder eine IPv4- oder eine IPv6-Adresse genannt. Diese dokumentierten Bedingungen sind keine vollständig geklärte, hier getestete API-Rezeptur.

Zwei Konflikte bleiben offen: SFOS 22 nennt den Selector DNSQueryConfiguration mit Textwerten. Die SFOS-23-Tabelle nennt dagegen DNS Query Configuration und 0, 1, 2, 3, ohne den XML-Tag oder deren Zuordnung im Beispiel zu zeigen. Der Kommentar zu DNSProtocol nennt das Feld zugleich erforderlich und UnencryptedDNS als Wert bei Weglassen. Weder ein Tag mit Leerzeichen noch eine numerische Zuordnung, sichere Weglassung, automatische Kompatibilität oder ein sicherer Default lässt sich daraus ableiten.

Sicherer aktueller Weg: Die mehrdeutige Selector-/Weglassungsrezeptur wird hier ausdrücklich nicht angeboten. Für SFOS 23 den oben beschriebenen WebAdmin-Pfad unter Network > DNS verwenden, Protokoll und Fallback bewusst entscheiden und gespeicherte Einstellungen, tatsächlich verwendetes Protokoll, Firewall-Policy-Zuweisung sowie interne Auflösung und Filterwirkung im Pilot prüfen. Muss automatisiert werden, bis zur versionsbezogenen Herstellerklärung dieser Felder stoppen; eine funktionierende UI bestätigt kein XML- oder REST-Schema.

DNSProtection/Fallback und DNSOverHTTPS/FallbackToUnencryptedDns sind getrennte Einstellungen: Die erste betrifft Ersatzauflösung bei nicht erreichbarem DNS Protection, die zweite den Rückfall von DoH auf unverschlüsseltes DNS. Schutz-/Sichtbarkeitsverlust und Verlust der Transportverschlüsselung sind unterschiedliche Risiken. Keine Gleichsetzung und keine unbelegten Boolean-Defaults übernehmen; beide Entscheidungen ausdrücklich prüfen. DoH zu einem beliebigen Anbieter bedeutet nicht Sophos DNS Protection, und DNSSecProtection ist weder DoH noch eine Filtering-Policy-Zuweisung. Es wird kein ausführbares globales DNS-XML aus diesen Unklarheiten erzeugt.

XML API: SFOS 22 — DNS List; SFOS 23 — DNS List.

DNS Protection einrichten

Traditional DNS auf SFOS 22 und älter: Die Schritte 1–3 beschreiben den bisherigen IP-/FQDN-Pfad. Die Schritte 4–6 bleiben auch für den integrierten SFOS-23-Pfad relevant.

1. Location in Sophos Fusion anlegen

My Products > DNS Protection > Locations

1. Add auswählen und unter Name einen eindeutigen Standortnamen erfassen; Description erklärt idealerweise Internet-Egress und Owner.
2. Unter Connection method die Option Traditional DNS over IPv4 aktivieren.
3. Unter IPv4 addresses or FQDNs die öffentliche WAN-IP oder einen stabilen DDNS-FQDN erfassen. Jeden Wert mit Enter oder Tab bestätigen.
4. Bei Multi-WAN alle tatsächlich verwendeten Ausgangsadressen berücksichtigen. Automatisch erkannte Firewall-Adressen werden bei einem späteren Wechsel nicht automatisch aktualisiert.
5. Save auswählen.

Private IP-Adressen sind ungültig. Sophos muss die öffentliche Source-IP erkennen, über die die Anfrage den Dienst erreicht. Bei dynamischen Adressen prüft Sophos den DDNS-Namen regelmässig, trotzdem kann nach einem Wechsel kurzzeitig eine Unterbrechung entstehen. Bei Cloudflare muss der DDNS-Record auf DNS only stehen und darf nicht über den Proxy laufen.

Bei CGNAT oder einer geteilten Provider-IP wird die Adresse dem Kundenkonto zugeordnet, das sie zuerst registriert hat. Ein FQDN löst dieses Problem nicht, wenn er auf dieselbe geteilte IP zeigt; dafür ist eine eindeutige öffentliche IP nötig.

2. DNS-Protection-IP-Adressen übernehmen

My Products > DNS Protection > Installers

Unter Installers stehen neben IP addresses zwei DNS-Protection-IP-Adressen. Mit Copy werden beide Werte aus dem eigenen Fusion-Tenant übernommen und später als DNS 1 und DNS 2 verwendet. Ein fremder Resolver als zusätzlicher Fallback kann Schutz und Sichtbarkeit umgehen.

Auch bei aktiviertem Secure DNS sind die IP-Adressen verfügbar. Entscheidend ist, dass für den Firewall-Pfad in der Location zusätzlich Traditional DNS mit der öffentlichen Ausgangsadresse konfiguriert ist.

Auf derselben Seite lässt sich mit Copy neben URL die Testadresse übernehmen. Wird sie im Browser geöffnet und erscheint die DNS-Protection-Willkommensmeldung, ist der Resolverpfad korrekt konfiguriert. Für die spätere Fehlersuche ist insbesondere https://dns.access.sophos.com relevant: Löst nur dieser Name nicht auf oder zeigt der Browser statt der Willkommensmeldung einen Fehler, spricht das für einen DNS-Leak oder eine Umleitung durch den Provider.

3. Firewall als DNS-Forwarder konfigurieren

Network > DNS

1. Static DNS auswählen.
2. DNS 1 und DNS 2 mit den beiden Fusion-Adressen belegen.
3. DNS 3 leer lassen, sofern kein bewusst dokumentierter Sonderfall besteht.
4. Unter IPv6 ebenfalls Static DNS wählen und keine IPv6-DNS-Server eintragen.
5. Choose IPv4 DNS server over IPv6 aktivieren.
6. Apply auswählen.

Der Dienst arbeitet über IPv4, kann aber auch AAAA-Records und damit IPv6-Ziele auflösen. Bei SD-WAN, Failover oder Policy Routing muss der tatsächliche Ausgangspfad zu einer in der Location hinterlegten öffentlichen Adresse passen.

Ab SFOS 21.5 zeigt das DNS Protection status widget im Control center den Verbindungsstatus. Für die geführte Einrichtung und Fehlersuche steht ausserdem der Sophos Assistant zur Verfügung. Das Widget ist ein schneller Betriebsindikator; für die Abnahme des vollständigen Pfads sind die erfolgreiche Abfrage der Testadresse und die DNS-Protection-Reports aussagekräftiger. Wie man Hilfeseiten prüft und erklärende Touren von tatsächlich ausgeführten Konfigurationsabläufen unterscheidet, zeigt Sophos Assistant sicher nutzen.

4. Interne Domains weiterleiten

Network > DNS
DNS request route > Add

DNS Protection löst keine internen Zonen auf. Für Active Directory, interne Applikationen und Reverse-Lookups werden deshalb DNS Request Routes benötigt.

Beispiel:

• Host/domain name: firma.local oder corp.example.com
• Target servers: interne Domain Controller oder DNS-Server, in der gewünschten Abfragereihenfolge; pro Route sind höchstens acht IP-Adressen möglich

corp.example.com ist eine Dokumentationsdomain und muss durch die tatsächlich intern autoritative Zone ersetzt werden. Nicht pauschal example.com routen, wenn nur eine Subdomain intern liegt. Scheitert bei einer passenden Route der Cache-Lookup, fragt die Firewall nicht zusätzlich ihre öffentlichen Forwarder oder Root-Server. Reihenfolge und Erreichbarkeit der Target Servers sind deshalb Teil der Ausfallsicherheit.

Der vollständige Ablauf steht unter DNS Request Routes auf Sophos Firewall konfigurieren. Intern verwendete, öffentlich registrierte Domains sollten zusätzlich in einer Domainliste erlaubt werden, wenn eine Kategorie wie Parked Domains sie blockiert.

5. Clients per DHCP auf die Firewall zeigen lassen

Network > DHCP

1. Unter Server den DHCP-Server des betroffenen Netzes bearbeiten und die Adresse des ausgewählten Interface notieren.
2. Unter DNS server die Option Use device’s DNS settings abwählen.
3. Als Primary DNS die interne Adresse dieses DHCP-Interfaces der Firewall eintragen.
4. Speichern, Lease auf einem Testclient erneuern und den tatsächlich verwendeten Resolver prüfen.

Sophos zeigt als Beispiel die Firewall-IP als Primary DNS und eine DNS-Protection-IP als Secondary DNS. Clients behandeln den zweiten Eintrag jedoch nicht zwingend als reinen Notfallserver. Direkte Abfragen an DNS Protection umgehen die DNS Request Routes der Firewall. In Netzen mit Active Directory oder internen Zonen sollte Redundanz deshalb im Resolver-Pfad gelöst werden, nicht durch einen beliebigen zweiten Client-DNS-Server.

6. Direkte DNS-Umgehung verhindern

Unter Administration > Device access zuerst prüfen, dass DNS für jede betroffene Quellzone aktiviert ist. Danach kann eine optionale DNAT-Regel klassischen DNS-Traffic interner Clients zur Firewall umleiten:

Rules and policies > NAT rules > IPv4 > Add NAT rule > New NAT rule

• Rule name: zum Beispiel redirect-client-dns-to-firewall
• Rule position: Top
• Original source: betroffene interne Netze
• Original destination: ausgehende Hostgruppe oder Internet IPv4
• Original service: DNS
• Translated destination: interne Firewall-IP
• Translated source / Translated service: Original
• Inbound interfaces: nur die zu den internen Quellen passenden Interfaces, niemals WAN

Internet IPv4 ist breit und eignet sich nur, wenn wirklich alle klassischen externen DNS-Ziele umgeleitet werden sollen. Die Quellnetze und Inbound Interfaces dagegen so eng wie möglich wählen. Interne DNS-Server und Sondergeräte benötigen dokumentierte Ausnahmen vor dieser Regel. Sie erfasst nur DNS auf UDP/TCP 53. DoH und DoT erfordern separate Browser-, MDM-, Endpoint- oder Web-Policy-Kontrollen. Vor der Aktivierung sind interne Namensauflösung, VPN und Gastnetz zu testen. Die Regelmechanik wird in NAT auf Sophos Firewall verstehen ausführlicher erklärt.

Policies, Endpoints und Blockseiten

Filtering Policy und Domainlisten

Eine Filtering Policy wird unter DNS Protection > Policies > Filtering policies einer oder mehreren Locations zugewiesen. Pro Location kann nur eine Filtering Policy aktiv sein. Neben Kategorien lassen sich Domainlisten und Optionen wie Safe Search definieren.

Beim Traditional-DNS-Pfad prüft dieser Artikel die Zuordnung zur richtigen Location; beim integrierten SFOS-23-Pfad die Zuweisung des Firewall-Objekts zur erwarteten Filtering Policy. Die Location-Zuordnung und der Screenshot in diesem Abschnitt zeigen den bisherigen Pfad. Erstellung, Ausnahmen, Safe Search, Pilotierung und Policy-Rollback gehören in Sophos DNS Protection Filtering Policies konfigurieren.

Domainlisten sollten Zweck, Owner und Review-Datum haben. Eine Allow-Liste übersteuert normale Kategorieentscheidungen, aber keine SophosLabs-Klassifizierung als Threat oder Security Risk. Zudem kann eine erlaubte Domain weiterhin blockiert werden, wenn ihr CNAME-Ziel in einer gesperrten Kategorie liegt.

Bei den Kategorien sind vor allem diese Entscheidungen wichtig:

• Infrastructure: Content delivery, CRL und OCSP normalerweise erlauben, da Updates und Zertifikatsprüfungen davon abhängen können.
• Threats and liabilities: Kategorien wie Phishing, Malware, Newly Registered Websites oder Anonymizers in der Regel blockieren und False Positives gezielt lösen.
• Data loss: Cloud-Speicher und Webmail anhand der DLP- und Compliance-Vorgaben bewerten.
• Uncategorized: nicht blind blockieren; neue legitime oder interne Dienste können vorübergehend unkategorisiert sein.
• Produktivität, Social Media und Bandbreite: nach Netz und Geschäftsbedarf entscheiden, nicht als pauschale Sicherheitsregel behandeln.

Endpoint DNS Protection

Die Endpoint DNS Protection Policy ist für verwaltete Windows-Endpoints gedacht, die auch ausserhalb des Firmennetzes geschützt werden sollen. Sophos Endpoint fängt die DNS-Abfragen ab und sendet sie per HTTPS an die Secure-DNS-Location. Die zugehörige Filtering Policy bestimmt die eigentliche Filterung.

Konfiguration, interne Domain Exclusions und Zuweisung beschreibt die Anleitung DNS Protection für Endpoints konfigurieren. Firewall-NAT, Request Routes und DHCP sind kein Ersatz für diesen Endpoint-Pfad.

Die Policy unterstützt aktuell weder Windows Server noch macOS. Für macOS gibt es einen separaten manuellen Secure-DNS-Profilpfad; Linux, Mobilgeräte und Sondergeräte benötigen ebenfalls eine eigene Netzwerk-, VPN- oder MDM-Lösung. Vor einem Rollout sollten die aktuellen Endpoint-Paketvoraussetzungen in Sophos Fusion geprüft werden, da sich diese kurzfristig ändern können.

Interne Zonen werden in der Endpoint Policy explizit als Domain Exclusions gepflegt. Das ist zuverlässiger als ein NXDOMAIN-Retry und vermeidet unnötige externe Abfragen. Das DNS Protection Root Certificate kann auf unterstützten Endpoints automatisch verteilt werden.

Root Certificate und Blockseite

Für HTTPS-Blockseiten muss das DNS Protection Root Certificate auf den Clients vertrauenswürdig sein. Es ist nicht dasselbe Zertifikat wie die Firewall-CA für TLS Inspection; deren Verteilung wird im Artikel Sophos Firewall CA-Zertifikat für TLS Inspection verteilen beschrieben.

Für Prüfung, Verteilung, Rotation und Entfernung gilt Sophos DNS Protection Root Certificate verteilen.

Das Zertifikat und der Konfigurationstest stehen unter DNS Protection > Installers. Zusätzlich muss blockpage.dnsprotection.sophos.com erreichbar sein.

Im Web Proxy Mode kann Pharming Protection die Blockseite stören. Bevor Schutzfunktionen global deaktiviert werden, sollte man die Blockpage-Domain über eine gezielte HTTP/HTTPS-Firewallregel ohne Webfilter erlauben und in einer TLS-Regel auf Do not decrypt setzen.

Pilot, Rollout und Abnahme

Die Location-Zuordnung und Location-Reportfelder in der folgenden Checkliste beziehen sich auf Traditional DNS beziehungsweise Endpoint-Daten. Beim integrierten SFOS-23-Pfad stattdessen die Firewall-Zuweisung und die obige SFOS-23-Pilotprüfung verwenden; daraus keine unveränderten Report- oder Live-Discover-Feldnamen ableiten.

DNS Protection zuerst in einem kleinen Pilotnetz aktivieren. Interne Zonen, Reverse-Lookups und kritische Dienste dokumentieren, DNS Request Routes einrichten und einen klaren Rollback auf die bisherigen Resolver vorbereiten. Servernetze benötigen ein eigenes Testfenster, weil Lizenzprüfung, Updates, CRL/OCSP, Backup oder Cluster-Kommunikation von DNS abhängen können.

Vor dem breiten Rollout müssen diese Prüfungen bestehen. Die Clientbefehle wurden hier nicht auf einer SFOS-22-Testumgebung ausgeführt; sie sind lesende Diagnosebefehle. Als Produktnachweis dienen der Fusion-Konfigurationstest und die Fusion-Reports:

• öffentliche Domain wird über den vorgesehenen Resolver aufgelöst.
• interne AD-Domain und Reverse-Lookup funktionieren über DNS Request Routes.
• der Konfigurationstest unter Installers zeigt die erwartete Bestätigung.
• eine harmlose, bewusst per Test-Policy blockierte Domain wird blockiert und der richtigen Location zugeordnet.
• Unter DNS Protection > Logs & Reports zeigt der Report DNS usage by source nach der erwartbaren Reporting-Verzögerung die Location und bei Endpoint-Daten zusätzlich Benutzer und Gerät.
• Gastnetz nutzt den geplanten DNS-Pfad, aber keine internen DNS-Server.
• VPN-Client erhält passende Resolver und DNS-Suffixe.
• Browser-DoH, Private Relay oder lokale Profile umgehen die Kontrolle nicht unerwartet.
• Rollback auf den vorherigen Resolver ist getestet oder klar dokumentiert.

Testbefehle für Clients

Windows:

ipconfig /all
nslookup example.com
nslookup example.com <firewall-ip>
Resolve-DnsName example.com

macOS:

scutil --dns
dig example.com
dig @<firewall-ip> example.com

Linux mit systemd-resolved und installiertem dig:

resolvectl status
dig example.com
dig @<firewall-ip> example.com

<firewall-ip> wird durch die interne Interface-Adresse der Sophos Firewall ersetzt. Funktioniert die explizite Abfrage an die Firewall, die normale Abfrage aber nicht, liegt die Ursache meistens bei DHCP, VPN, Browser-DoH oder einer lokalen DNS-Konfiguration. Die Befehle zeigen den verwendeten Client-Resolver und dessen Antwort, beweisen aber nicht allein, welchen Upstream die Firewall nutzt.

Interne Zone prüfen:

dig @<firewall-ip> interner-host.corp.example.com

Diese Abfrage muss über die passende DNS Request Route beim internen DNS-Server landen.

Troubleshooting

Location-, Source-IP- und UDP/TCP-53-Upstream-Prüfungen in diesem Abschnitt gelten für Traditional DNS. Beim integrierten SFOS-23-Pfad zuerst DNS Protection, die Firewall-Zuweisung zur Policy und das verwendete Protokoll über Test name resolution prüfen. Die obige SFOS-23-Pilotprüfung ist hier massgeblich; die alten IPv4-Forwarder nicht zusätzlich eintragen.

Standort erscheint nicht in Sophos Fusion

Öffentliche WAN-IP, DDNS-FQDN und den tatsächlichen Multi-WAN-Ausgang prüfen. Eine nicht konfigurierte Source-IP kann vom DNS-Protection-Dienst abgewiesen werden. Bei dynamischen Adressen kontrollieren, ob der FQDN extern auf die aktuelle IP zeigt; Cloudflare-Records müssen DNS only sein.

Unter My Environment > Alerts erscheinen ungültige FQDNs und IP-Konflikte. Bei CGNAT oder geteilten Proxy-/VPN-Ausgängen gewinnt die zuerst registrierte Location. Ein anderer FQDN auf dieselbe IP ändert diese Zuordnung nicht.

DNS-Traffic erscheint trotz korrekter Location nicht

Dieses Fehlerbild umfasst auch No queries received from locations im Dashboard und DNS Protection: Connectivity Error im Control center. Zuerst https://dns.access.sophos.com öffnen. Bleibt die Willkommensmeldung aus, beide unter Installers angezeigten Tenant-Adressen über UDP und TCP 53 testen und den tatsächlichen WAN-Egress kontrollieren.

Erreichen Anfragen ein anderes Ziel oder antwortet ein anderer Resolver, können Router oder Provider DNS umleiten. Ein Standard- oder Extended-Test auf https://www.dnsleaktest.com/ grenzt das ein: Bei DNS Protection enthalten die Werte in der Spalte Hostname das Muster gw-<Nummer><Region>.dnsprotection.sophos.com; als ISP erscheint Amazon oder eine entsprechende Bezeichnung. Zeigt der Test ausschliesslich andere Resolver, sollte der Provider eine DNS-Umleitung prüfen. Erscheinen Sophos- und Fremdresolver gemischt, sind die DNS-Einstellungen von Firewall, internem DNS-Server und Clients sowie parallele IPv6-Resolver zu kontrollieren. https://ipleak.net/ kann als Gegenprobe dienen.

Auf der Firewall nur die beiden Tenant-Adressen als Forwarder belassen, Route, NAT und Packet Capture prüfen und eine Provider-Umleitung mit dem ISP klären. Ein dritter öffentlicher Resolver wäre nur ein ungeschützter Bypass.

Einzelne Clients verwenden einen anderen Resolver

DHCPv4, DHCPv6, Router Advertisements, VPN-Profil und statische Clientwerte gemeinsam prüfen. Ein zusätzlicher IPv6-DNS-Server kann Abfragen an DNS Protection vorbeiführen. DNS Protection selbst arbeitet über IPv4, löst aber AAAA-Records auf; für IPv6-Ziele ist deshalb kein separater IPv6-Resolver nötig.

Interne Namen funktionieren nicht mehr

DNS Request Routes, interne DNS-Server, Reverse-Zonen, Suchdomains und Client-Suffixe prüfen. Zusätzlich sicherstellen, dass der Client die Firewall oder den vorgesehenen internen Resolver verwendet und nicht direkt eine DNS-Protection-IP.

Interne oder legitime Domain wird blockiert

Kategorisierung, Domainliste und CNAME-Ziel prüfen. Eine enge Ausnahme ist besser als das Öffnen einer ganzen Kategorie. SophosLabs-Threat- und Security-Risk-Klassifizierungen lassen sich nicht mit einer Allow-Domainliste übersteuern.

Logs bleiben leer

Dashboard und Reports liegen ungefähr 15 bis 25 Minuten hinter Echtzeit. Geänderte Location- oder Policy-Namen können sogar 30 Minuten bis vier Stunden benötigen. Erst danach DHCP, Client-DNS, Firewall-DNS, NAT-Umleitung, alternative Resolver, VPN-Profile und Location-Zuordnung prüfen.

Unter DNS Protection > Logs & Reports zuerst DNS usage by source wählen und nach Location, Domain, Status oder Source IP filtern. Bei direkt durchgeleitetem DNS kann zusätzlich eine Firewallregel mit Log firewall traffic zeigen, ob UDP/TCP 53 die Firewall passiert hat. Beim Firewall-Resolver ist Administration > Device access massgeblich; eine Firewallregel ist für diesen lokalen Dienst kein Freigabe- oder Ablehnungsnachweis.

Filteroperatoren, Exportgrenzen, Verzögerungen und Live Discover erklärt DNS Protection Reports und Live Discover auswerten. Für die Firewall-Fehlersuche zuerst den Resolverpfad belegen und erst danach tiefere Report-Abfragen starten.

Mit EDR, XDR oder MDR kann Threat Analysis Center > Live Discover zusätzlich DNS-Protection-Daten wie Domain, Policy Action, Location und Source-IP auswerten. Benutzer- und Gerätefelder stehen bei Endpoint-Daten in den Standardreports, nicht im dokumentierten Firewall-DNS-Schema von Live Discover.

Blockseite erscheint nicht

DNS Protection Root Certificate, DNS-Pfad und Erreichbarkeit von blockpage.dnsprotection.sophos.com prüfen. Im Web Proxy Mode zusätzlich Pharming Protection, HTTP/HTTPS-Regel und TLS-Ausnahme Do not decrypt kontrollieren. Auch VPN, Browser-DoH und Apple Private Relay können den Test an DNS Protection vorbeiführen.

Für die enge Firewall-Ausnahme ein FQDN-Objekt für blockpage.dnsprotection.sophos.com anlegen. Eine Allow-Regel erlaubt HTTP/HTTPS von den betroffenen internen Zonen und Netzen zur WAN-Zone mit diesem Objekt als Ziel, ohne Webfilter. Eine passende TLS-Regel verwendet dieselben Auswahlkriterien mit Do not decrypt. Nicht stattdessen Pharming Protection oder TLS Inspection global deaktivieren.

DoH oder Private DNS umgeht die Kontrolle

Eine NAT-Umleitung für Port 53 erfasst kein DoH oder DoT. Browser-, Betriebssystem- und MDM-Richtlinien müssen solche Resolver kontrollieren. Secure DNS in DNS Protection verwendet DoH; ein eigener DNS-Protection-Modus über DoT ist nicht dokumentiert.

Auf Apple-Geräten kann auch iCloud Private Relay den vorgesehenen DNS-Pfad umgehen. Wenn beispielsweise iPhones keinen Internetzugriff haben, andere Geräte am selben Standort aber funktionieren, zunächst Limit IP Address Tracking für den betroffenen Testpfad deaktivieren und erneut prüfen. Eine organisationsweite Änderung sollte erst nach diesem begrenzten Test und nach Abstimmung der Datenschutzanforderungen erfolgen.

VPN-Clients verhalten sich anders als LAN-Clients

Zugewiesene DNS-Server, DNS-Suffixe, Split DNS, Full- oder Split-Tunnel und lokale Resolver prüfen. DNS Protection kann im Büro funktionieren und bei Remote Access trotzdem umgangen werden. Die grundlegende VPN-Auswahl erklärt Sophos Connect oder SSL VPN: Welche Remote-Access-Lösung passt?.

Betrieb

DNS Protection ist kein einmaliger DNS-Servertausch. Regelmässig zu prüfen sind:

• Locations, öffentliche Ausgangsadressen und DDNS-Auflösung.
• DHCP-Einstellungen und interne DNS Request Routes.
• Policies, Domainlisten, Owner und Review-Daten.
• Blockierte Top-Domains und dokumentierte False Positives.
• neue Standorte, Gastnetze, VPN-Pfade und Endpoint-Plattformen.
• Zertifikatsverteilung und Erreichbarkeit der Blockpage-Domain.
• Reports nach Änderungen und der definierte Rollback-Pfad.

Wer diese Punkte nicht dauerhaft betreiben will, fährt mit robusten Resolvern und gezielten Schutzkontrollen häufig besser. DNS Protection lohnt sich dort, wo Policies, Reporting und Endpoint-Schutz tatsächlich genutzt und überwacht werden.

Sicher zurückrollen

Der folgende Standort-Rückbau betrifft den bisherigen Traditional-DNS-Pfad. Für die SFOS-23-Migration gilt der oben beschriebene Rückweg mit Policy-Zuweisung und DNS Protection-Schalter.

Beim Standortpfad zuerst die DNS-Umleitung deaktivieren, damit man Clients während des Rückbaus nicht weiter zur Firewall zwingt. Danach in Network > DHCP die bisherigen Resolver wieder eintragen, die Testclient-Lease erneuern und öffentliche sowie interne Namen prüfen. Erst wenn dieser Pfad funktioniert, unter Network > DNS den früheren Modus beziehungsweise die früheren DNS-Server wiederherstellen. Request Routes vorerst stehen lassen; sie schaden dem Rückweg nicht und erleichtern eine kontrollierte Wiederaufnahme. Die Fusion-Location erst entfernen, wenn dort keine benötigten Netze oder Policies mehr zugeordnet sind.

Endpoint DNS Protection getrennt zurückrollen: Unter DNS Protection > Policies > Endpoint policies die betroffene Zuweisung entfernen oder Use Sophos DNS Protection deaktivieren und anschliessend am Pilotgerät prüfen, dass wieder die system- beziehungsweise anwendungskonfigurierten Resolver greifen. Das Root Certificate muss nicht im selben Wartungsfenster gelöscht werden; seine spätere Entfernung sollte über denselben verwalteten Verteilweg erfolgen wie die Installation.