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 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.

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 Central-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 Central 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.

Der empfohlene Firewall-Pfad sieht so aus:

1. Sophos Central kennt den Standort als Location.
2. Sophos Central 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 Central 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.

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 ab. Für Endpoint DNS Protection werden Workspace Protection und zusätzlich eine passende Sophos-Endpoint-Lizenz benötigt.

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.

DNS Protection einrichten

1. Location in Sophos Central anlegen

My Products > DNS Protection > Locations

1. Add auswählen und einen eindeutigen Standortnamen erfassen.
2. Traditional DNS over IPv4 aktivieren.
3. Öffentliche WAN-IP oder einen stabilen DDNS-FQDN hinterlegen.
4. Bei Multi-WAN alle tatsächlich verwendeten Ausgangsadressen berücksichtigen.
5. Location speichern.

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 zwei DNS-Protection-IP-Adressen. Diese Werte immer aus dem eigenen Central-Tenant kopieren und als DNS 1 und DNS 2 verwenden. 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.

3. Firewall als DNS-Forwarder konfigurieren

Network > DNS

1. Static DNS auswählen.
2. DNS 1 und DNS 2 mit den beiden Central-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. Konfiguration speichern.

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.

4. Interne Domains weiterleiten

Network > DNS
Abschnitt 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

Der vollständige Ablauf steht unter DNS Request Routes auf Sophos Firewall konfigurieren. Interne ö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. DHCP-Server des betroffenen Netzes bearbeiten.
2. Interne Interface-IP der Firewall als DNS-Server verteilen.
3. Lease auf einem Testclient erneuern.
4. 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

Eine optionale DNAT-Regel kann klassischen DNS-Traffic interner Clients zur Firewall umleiten:

• Original source: betroffene interne Netze
• Original destination: ausgehende Hostgruppe oder Internet IPv4
• Original service: DNS
• Translated destination: interne Firewall-IP
• Inbound interfaces: nur die zu den internen Quellen passenden Interfaces, niemals WAN
• Position: weit oben, vor allgemeineren NAT-Regeln

Ausnahmen für interne DNS-Server und Sondergeräte müssen dokumentiert werden. Die Regel 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, Gastnetz und Logs 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.

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.

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 Central geprüft werden, da 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.

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

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:

• ö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.
• Logs erscheinen nach der erwartbaren Reporting-Verzögerung in Sophos Central.
• 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

Standort erscheint nicht in Sophos Central

Ö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.

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. Erst danach DHCP, Client-DNS, Firewall-DNS, NAT-Umleitung, alternative Resolver, VPN-Profile und Location-Zuordnung prüfen.

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.

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.

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.