Sophos DNS Protection mit Sophos Firewall einrichten

Sophos DNS Protection schützt DNS-Abfragen über einen cloudbasierten DNS-Dienst mit Policies und Reporting in Sophos Central. Die Funktion kann bösartige Domains, Phishing, Command-and-Control-Ziele und unerwünschte Kategorien blockieren, bevor ein Client überhaupt eine Verbindung zur eigentlichen Website oder Infrastruktur aufbaut.

Mit Sophos Firewall ist der sauberste Standardaufbau meistens: Clients verwenden die Firewall als DNS-Resolver, die Firewall leitet öffentliche DNS-Anfragen an DNS Protection weiter, und interne Domains werden über DNS Request Routes an interne DNS-Server geschickt. So bleibt interne Namensauflösung stabil, während öffentliche DNS-Abfragen zentral kontrolliert und protokolliert werden.

DNS Protection ersetzt keine Web Protection, keine Threat Feeds und kein NDR. Es ist ein eigener Schutzpunkt auf DNS-Ebene. Genau deshalb sollte man die Funktion bewusst planen und nicht einfach nur öffentliche DNS-Server austauschen.

Videoanleitung

Avanet-Einordnung: DNS Protection bewusst einsetzen

DNS Protection ist technisch interessant, aber nicht in jeder Umgebung automatisch die beste Wahl. In vielen Projekten setzen wir DNS Protection bewusst nicht als Standard ein, sondern bevorzugen schnelle, hochverfügbare DNS-Resolver und blockieren bekannte bösartige Ziele zusätzlich über Sophos Firewall Threat Feeds oder vergleichbare Threat-Intelligence-Quellen auf der Firewall.

Der Grund ist einfach: DNS ist eine Basisfunktion. Wenn DNS langsam ist, nicht redundant funktioniert oder zu viele False Positives erzeugt, fühlt sich für Benutzer schnell das ganze Netzwerk defekt an. DNS-Schutz muss deshalb nicht nur sicher sein, sondern auch stabil, schnell, nachvollziehbar und gut betreibbar.

Die Entscheidung hängt vom Ziel ab:

DNS Protection passt also besonders dann, wenn DNS-Logs in Sophos Central, standortbasierte DNS-Policies, Kategorie-Filterung oder Endpoint DNS Protection für Roaming-Clients ausdrücklich gewünscht sind. Wenn das Ziel primär schnelle und hochverfügbare Namensauflösung mit zusätzlicher Blockierung bekannter schlechter Ziele ist, sind gute DNS-Resolver plus Threat Feeds oft die pragmatischere Lösung.

Wann DNS Protection sinnvoll ist

DNS Protection ist besonders stark, wenn viele Clients über eine zentrale Firewall oder einen lokalen DNS-Resolver ins Internet gehen.

Typische Einsatzfälle:

• Clients sollen keine beliebigen öffentlichen DNS-Resolver verwenden.
• Malware-, Phishing- und C2-Domains sollen früh blockiert werden.
• DNS-Abfragen sollen in Sophos Central sichtbar werden.
• Unterschiedliche Standorte sollen eigene DNS-Policies bekommen.
• Interne DNS-Namen sollen weiter über lokale DNS-Server funktionieren.
• Web Protection soll um eine vorgelagerte DNS-Kontrolle ergänzt werden.

DNS Protection ist aber kein Ersatz für Inhaltsprüfung. Wenn eine erlaubte Domain später schädlichen Inhalt ausliefert oder HTTPS-Traffic genauer geprüft werden muss, bleiben Web Protection, TLS Inspection, IPS, Endpoint-Schutz und Logging relevant.

Nicht ideal ist DNS Protection, wenn lediglich ein schneller externer DNS-Forwarder gesucht wird oder wenn bereits ein sehr stabiler DNS-Betrieb mit separaten Threat Feeds, Web Protection, Endpoint-Schutz und sauberem Monitoring besteht. Dann sollte man zuerst prüfen, welchen zusätzlichen Mehrwert DNS Protection konkret bringt und wer die Policy, Ausnahmen und False Positives betreibt.

Architektur mit Sophos Firewall

Für Sophos Firewall ist dieser Aufbau meistens am klarsten:

1. Sophos Central kennt den Standort als Location.
2. Sophos Central stellt zwei DNS Protection IP-Adressen bereit.
3. Sophos Firewall nutzt diese IP-Adressen als DNS-Forwarder.
4. Interne Domains werden über DNS Request Routes an interne DNS-Server gesendet.
5. DHCP verteilt die Firewall als DNS-Resolver an Clients.
6. Optional erzwingt eine NAT-Regel, dass ausgehender DNS-Traffic zur Firewall umgeleitet wird.
7. DNS Protection Logs und Reports werden in Sophos Central ausgewertet.

Dieser Aufbau sorgt dafür, dass Clients nicht direkt an den Sophos-DNS-Dienst konfiguriert werden müssen. Die Firewall bleibt der zentrale Resolver im LAN und kann interne Sonderfälle besser behandeln.

Voraussetzungen

Vor dem Rollout sollten diese Punkte geklärt sein:

• Sophos Central Zugriff mit Berechtigung für DNS Protection.
• Passende Lizenz: Xstream Protection für Standalone-DNS-Protection oder Workspace Protection für Endpoint-DNS-Protection.
• Öffentliche WAN-IP oder ein stabiler FQDN/DDNS-Name für den Standort.
• Sophos Firewall wird als DNS-Resolver für die betroffenen Netze genutzt oder soll es werden.
• Interne Domains, Active-Directory-Zonen und Reverse-Lookups sind bekannt.
• DHCP-Server für Clientnetze sind identifiziert.
• Ausnahmen für interne Domains und kritische Dienste sind geplant.
• Verantwortliche für DNS-Policy, False Positives und Logging sind definiert.

Wenn die öffentliche IP-Adresse häufig wechselt, sollte man vor dem Rollout klären, ob eine DDNS-Konfiguration stabil genug ist. Sophos DNS Protection kann Locations auch über einen FQDN identifizieren, aber eine IP-Änderung kann trotzdem zeitweise zu Unterbrüchen führen.

1. Location in Sophos Central anlegen

In Sophos Central wird zuerst der Standort angelegt:

My Products > DNS Protection > Locations

Praktischer Ablauf:

1. Add auswählen.
2. Standortnamen und Beschreibung erfassen.
3. Öffentliche WAN-IP der Sophos Firewall hinterlegen.
4. Bei mehreren WAN-Interfaces alle relevanten öffentlichen IP-Adressen oder einen passenden Bereich eintragen.
5. Bei dynamischer IP einen DDNS-FQDN verwenden, wenn das Design darauf basiert.
6. Location speichern.

Die Location ist wichtig, weil DNS Protection eingehende DNS-Anfragen dem richtigen Kundenkonto und der richtigen Policy zuordnen muss. Wenn die Location fehlt oder die öffentliche IP nicht passt, sieht Sophos Central den Standort nicht korrekt.

2. DNS Protection IP-Adressen kopieren

Die DNS Protection IP-Adressen findet man in Sophos Central unter:

My Products > DNS Protection > Installers

Dort werden zwei IP-Adressen bereitgestellt. Diese werden auf der Sophos Firewall als primärer und sekundärer DNS-Server verwendet. Keine anderen öffentlichen DNS-Server als Fallback eintragen, wenn der Traffic vollständig über DNS Protection laufen soll. Sonst können DNS-Server je nach Verhalten des Resolvers an DNS Protection vorbei genutzt werden, und Schutz sowie Sichtbarkeit gehen verloren.

3. Sophos Firewall DNS-Forwarder konfigurieren

Auf der Sophos Firewall:

Network > DNS

Empfohlener Ablauf:

1. Static DNS auswählen.
2. DNS 1 auf die erste DNS Protection IP-Adresse setzen.
3. DNS 2 auf die zweite DNS Protection IP-Adresse setzen.
4. DNS 3 leer lassen, wenn kein bewusster Sonderfall besteht.
5. Unter IPv6 keine separaten IPv6-DNS-Server setzen, wenn der Standort über die IPv4-basierten DNS-Protection-Server laufen soll.
6. Einstellung speichern und anwenden.

DNS Protection arbeitet als IPv4-basierter DNS-Dienst, kann aber auch IPv6-Adressen auflösen. Man braucht dafür also nicht automatisch einen separaten IPv6-DNS-Server.

4. Interne Domains mit DNS Request Routes schützen

DNS Protection löst keine internen Domains auf. Wenn im Netzwerk Active Directory, interne Applikationen, lokale Zonen oder Reverse-Lookups verwendet werden, müssen diese Anfragen an interne DNS-Server gehen.

Dafür verwendet man auf der Sophos Firewall:

Network > DNS > DNS request route

Beispiel:

Ohne diese Routen würden interne Namen an DNS Protection gesendet und dort nicht korrekt aufgelöst. Der genaue Ablauf steht in DNS Request Routes auf Sophos Firewall konfigurieren.

Für produktive Umgebungen sollte man interne Domains zusätzlich in DNS Protection als Domainliste berücksichtigen, wenn die Domain durch eine Kategorie blockiert werden könnte. Typische Beispiele sind interne Sites oder Dienste, die sonst unter problematische Kategorien wie Parked Domains fallen könnten.

5. Clients per DHCP auf die Firewall zeigen lassen

Clients sollten die Sophos Firewall als DNS-Resolver verwenden, nicht direkt beliebige externe Resolver.

Wenn die Sophos Firewall DHCP bereitstellt:

Network > DHCP

Praktischer Ablauf:

1. DHCP-Server des betroffenen Interfaces bearbeiten.
2. IP-Adresse des Firewall-Interfaces als primären DNS-Server verteilen.
3. Keine externen DNS-Server als alternativen Client-DNS verteilen, wenn DNS Protection konsequent greifen soll.
4. DHCP-Lease erneuern oder Testclient neu verbinden.
5. Mit einem Testclient prüfen, welcher DNS-Server tatsächlich verwendet wird.

Wenn ein Windows-DNS-Server oder anderer interner Resolver im Einsatz ist, kann dieser Resolver statt der Clients an DNS Protection weiterleiten. Dann muss aber klar sein, wo interne Domains aufgelöst werden und welcher Server öffentliche Anfragen weiterleitet.

6. Direkte DNS-Umgehung verhindern

Viele Clients verwenden den per DHCP verteilten DNS-Server. Einige Geräte, Browser, IoT-Systeme oder absichtlich konfigurierte Clients können aber eigene DNS-Server nutzen.

Eine mögliche Gegenmassnahme ist eine NAT-Regel, die ausgehenden DNS-Traffic aus internen Netzen zur Firewall umleitet. Praktisch bedeutet das: DNS-Traffic aus den internen Quellnetzen wird per DNAT auf die interne Firewall-Adresse gelenkt, damit die Anfrage über DNS Protection ausgewertet werden kann.

Wichtig:

• Nur interne Quellnetze erfassen.
• Keine WAN-Interfaces als Inbound interface verwenden.
• Regelposition bewusst sehr weit oben setzen.
• Ausnahmen für interne DNS-Server und Sonderfälle dokumentieren.
• Danach testen, ob interne DNS-Auflösung, DNS Protection und Logs weiterhin stimmen.

Die NAT-Grundlagen stehen in NAT auf Sophos Firewall verstehen. Eine DNS-Erzwingung sollte nicht blind aktiviert werden, weil sie interne Resolver, VPN-Clients, DoH/DoT-Verhalten oder Spezialgeräte beeinflussen kann.

Rollout in Phasen planen

DNS Protection sollte nicht sofort für alle Netze gleichzeitig erzwungen werden. DNS ist eine Basisfunktion: Wenn interne Namen, Zertifikatsprüfungen, Software-Updates oder SaaS-Dienste nicht mehr sauber aufgelöst werden, wirkt das schnell wie ein allgemeiner Internetausfall.

Ein kontrollierter Rollout sieht in der Praxis so aus:

1. Pilotnetz oder kleine Testgruppe auswählen.
2. Interne Domains, Reverse-Zonen und Suchdomains dokumentieren.
3. DNS Request Routes für interne Zonen einrichten.
4. Firewall als DNS-Resolver per DHCP verteilen.
5. DNS Protection IP-Adressen auf der Firewall setzen.
6. Blockseiten-Zertifikat auf Testclients installieren.
7. Logs in Sophos Central prüfen.
8. Erst danach weitere Netze, Gastnetz, Servernetze oder VPN-Netze aufnehmen.

Für Servernetze sollte man besonders vorsichtig sein. Manche Systeme nutzen DNS für Lizenzprüfung, Updates, CRL/OCSP, Backup, Monitoring oder Cluster-Kommunikation. Dort ist ein Testfenster mit Rollback wichtiger als bei normalen Clientnetzen.

Akzeptanztest vor dem breiten Rollout

Vor dem produktiven Rollout sollte klar sein, woran man eine funktionierende DNS-Protection-Umsetzung erkennt. Nur der Sophos-Testlink reicht dafür nicht.

Wenn einer dieser Tests fehlschlägt, sollte nicht sofort die Policy geöffnet werden. Zuerst muss klar sein, ob das Problem bei DHCP, DNS Request Routes, Location-Zuordnung, Clientprofil, Browser-DoH, VPN-Split-Tunnel oder Domainkategorisierung liegt.

7. Policies und Domainlisten planen

DNS Protection kann sicherheitsrelevante Domains auch ohne eigene Policy blockieren, wenn SophosLabs diese als Threat oder Sicherheitsrisiko einstuft. Eigene Policies ergänzen diese Baseline um Unternehmensvorgaben.

Typische Policy-Fragen:

• Welche Locations bekommen welche Policy?
• Welche Kategorien sollen blockiert werden?
• Welche Kategorien sind nur für bestimmte Standorte problematisch?
• Welche Domains müssen explizit erlaubt werden?
• Wer entscheidet über False Positives?
• Wie lange bleiben Ausnahmen gültig?

Domainlisten sollten eng geführt werden. Eine breite Allow-Liste kann Schutzwirkung reduzieren. Eine breite Blockliste kann Geschäftsprozesse stören. Jede Liste braucht Zweck, Owner und Review-Datum.

Filtering Policy oder Endpoint DNS Protection Policy?

In Sophos Central gibt es zwei Policy-Ebenen, die man nicht verwechseln sollte.

Eine Filtering policy wird unter DNS Protection > Policies > Filtering policies erstellt und einer oder mehreren Locations oder Firewalls zugewiesen. Pro Location kann nur eine Filtering Policy aktiv sein. In dieser Policy definiert man Kategorien, Domainlisten und zusätzliche Optionen wie Safe Search.

Eine Endpoint DNS Protection policy nutzt Sophos Endpoint. Der Endpoint fängt DNS-Traffic auf dem Gerät ab und leitet ihn sicher per HTTPS an DNS Protection weiter. Dadurch muss man den Client nicht manuell auf die DNS-Protection-IP-Adressen konfigurieren. Die Geräte werden in der Endpoint Policy einer DNS-Protection-Location zugeordnet und werden anschliessend durch die zu dieser Location passende Filtering Policy gesteuert.

Praktisch bedeutet das:

• Für ein Büro mit Sophos Firewall ist die Location plus Filtering policy der normale Netzwerkpfad.
• Für Roaming-Clients ist die Endpoint DNS Protection policy sinnvoll, weil der Schutz auch ausserhalb des Firmennetzes greifen kann.
• Für gemischte Umgebungen kombiniert man beide Ansätze: Firewall-Standorte über Locations, verwaltete Endpoints zusätzlich über Endpoint DNS Protection.
• Für interne Domains sollten in Endpoint Policies Domain Exclusions gepflegt werden. Sophos empfiehlt, interne Zonen explizit auszuschliessen, statt sich nur auf einen NXDOMAIN-Retry zu verlassen.
• Block Pages auf Endpoints benötigen das DNS Protection Root Certificate. Mit Sophos Endpoint kann das Zertifikat automatisch verteilt werden.

Welche Kategorien kann man blockieren?

DNS Protection bietet Kategorien, die in Sophos Central in Gruppen organisiert sind. Einige Kategorien sind eher produktivitätsbezogen, andere sind klar sicherheitsrelevant. Die Namen bleiben hier bewusst auf Englisch, weil sie so auch in Sophos Central angezeigt werden.

Domainlisten haben Vorrang vor Kategorien. Eine erlaubte Domain in einer Domainliste bleibt erlaubt, auch wenn die Kategorie blockiert wäre. Eine blockierte Domain bleibt blockiert, auch wenn die Kategorie erlaubt wäre. Deshalb sollten Domainlisten dokumentiert und regelmässig geprüft werden.

8. Blockseiten und Zertifikate

Für blockierte Domains kann DNS Protection eine HTTPS-Blockseite anzeigen. Damit Benutzer diese Blockseite korrekt sehen, muss das DNS Protection Root Certificate auf den betroffenen Geräten vertrauenswürdig installiert sein.

Wenn zusätzlich TLS Inspection oder Webfiltering auf der Firewall aktiv ist, muss die Zertifikats- und Ausnahmeplanung zusammenpassen. Für die Firewall-CA passt Sophos Firewall CA-Zertifikat für TLS Inspection verteilen.

Wenn Blockseiten nicht angezeigt werden, sollte man nicht sofort an der Policy drehen. Häufig fehlen Zertifikate, der Client nutzt einen anderen DNS-Pfad, oder blockpage.dnsprotection.sophos.com wird durch eine andere Kontrolle gestört.

DNS Protection testen

Sophos Central stellt unter DNS Protection > Installers einen Testlink bereit. Wenn die Konfiguration korrekt ist, zeigt der Browser eine Bestätigung.

Zusätzlich sollte man praxisnah testen:

• Client nutzt die Firewall als DNS-Server.
• Öffentliche Domain wird über DNS Protection aufgelöst.
• Interne Domain wird über DNS Request Route korrekt aufgelöst.
• Blockierte Testdomain wird geblockt.
• Logs erscheinen in Sophos Central.
• DNS-Abfragen tauchen am richtigen Standort auf.
• Alternative DNS-Server werden nicht genutzt.
• VPN- oder Gastnetz verhält sich wie geplant.

Für echte Fehleranalyse sollte man nicht nur den Browser testen. nslookup, dig, Firewall-Logs, DHCP-Leases und Sophos-Central-Logs zusammen ergeben ein besseres Bild.

Testbefehle für Clients

Auf einem Testclient sollte man zuerst prüfen, welcher DNS-Server wirklich verwendet wird. Ein erfolgreicher Browser-Test reicht nicht, wenn der Client parallel einen anderen Resolver, DoH oder ein VPN-Profil nutzt.

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:

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

Dabei sollte <firewall-ip> durch die interne Interface-Adresse der Sophos Firewall ersetzt werden, die im jeweiligen Netz als DNS-Resolver dienen soll. Wenn die Abfrage gegen die Firewall funktioniert, die normale Abfrage aber einen anderen Resolver nutzt, liegt das Problem meistens bei DHCP, Betriebssystemprofil, VPN-Client, Browser-DoH oder einer lokalen DNS-Konfiguration.

Für interne Domains sollte zusätzlich ein Test mit einer internen Zone durchgeführt werden:

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

Dieser Test muss über die passende DNS Request Route beim internen DNS-Server landen. Wenn öffentliche Domains funktionieren, interne Namen aber nicht, ist DNS Protection selten die eigentliche Ursache. Dann sollten DNS Request Routes, interne DNS-Server, Suchdomains und Client-DNS-Suffixe geprüft werden.

Troubleshooting

Standort erscheint nicht in Sophos Central

Prüfen, ob die öffentliche WAN-IP oder der DDNS-FQDN in der Location stimmt. Bei mehreren WAN-Leitungen müssen alle relevanten Ausgangsadressen berücksichtigt werden. Bei dynamischen IP-Adressen kann es kurze Verzögerungen geben, bis DNS Protection die Änderung erkennt.

Interne Namen funktionieren nicht mehr

Dann fehlen meistens DNS Request Routes oder die Clients fragen nicht den erwarteten Resolver. Interne AD-Domains, Reverse-Zonen und Applikationsdomains sollten explizit an interne DNS-Server weitergeleitet werden.

DNS Protection blockiert eine interne oder legitime Domain

Zuerst klären, ob die Domain intern, öffentlich, falsch kategorisiert oder tatsächlich riskant ist. Danach Domainliste und Policy prüfen. Keine breite Allow-Regel setzen, bevor Ursache und betroffene Benutzer bekannt sind.

Logs bleiben leer

Wenn keine Logs in Sophos Central erscheinen, nutzt der Client möglicherweise nicht DNS Protection. Prüfen: DHCP, Client-DNS, Firewall-DNS, NAT-Umleitung, alternative Resolver, VPN-Profil und ob der Standort in Sophos Central korrekt erkannt wird.

Blockseite erscheint nicht

Dann ist oft das DNS Protection Root Certificate nicht installiert, der Client nutzt einen anderen DNS-Pfad, oder eine andere Sicherheitskontrolle beeinflusst die Verbindung. Auch TLS Inspection und Web Protection sollten geprüft werden.

DoH oder private DNS umgeht die Kontrolle

Browser und Betriebssysteme können DNS over HTTPS oder private DNS-Funktionen verwenden. Je nach Umgebung muss man diese Funktionen per Browser-, MDM- oder Betriebssystemrichtlinie steuern. DNS Protection auf dem Netzwerkpfad hilft nur, wenn die Abfragen tatsächlich über den vorgesehenen Resolver laufen.

VPN-Clients verhalten sich anders als LAN-Clients

Bei VPN-Clients hängt das Verhalten stark vom Profil ab. Full Tunnel, Split Tunnel, DNS-Suffixe, Suchdomains und lokale Resolver des Clients können die Namensauflösung beeinflussen. Wenn DNS Protection im LAN funktioniert, aber über VPN nicht, sollte man zuerst VPN-Profil, zugewiesene DNS-Server, DNS-Suffixe und Firewall-Regeln prüfen. Für Remote-Access-Umgebungen passt zusätzlich Sophos Connect oder SSL VPN: Welche Remote-Access-Lösung passt?.

Betriebsempfehlung

DNS Protection sollte wie eine Sicherheitskontrolle betrieben werden, nicht wie ein einmaliger DNS-Servertausch.

Aus Avanet-Sicht sollte man vorher ehrlich entscheiden, ob DNS Protection tatsächlich das richtige Werkzeug für die Umgebung ist. Für viele klassische Firewall-Installationen sind schnelle, redundante DNS-Resolver plus sauber gepflegte Threat Feeds auf der Firewall die robustere Betriebsvariante. DNS Protection lohnt sich vor allem dann, wenn der Betrieb auch die Central-Policies, Logs, Kategorien, Domainlisten und Endpoint-Komponente aktiv nutzen will.

Regelmässig prüfen:

• Locations und WAN-IP-Adressen stimmen.
• DHCP verteilt weiterhin die richtigen DNS-Server.
• Interne DNS Request Routes sind aktuell.
• Policies und Domainlisten haben Owner und Review-Datum.
• Logs werden ausgewertet.
• Blockierte Top-Domains werden auf False Positives geprüft.
• Neue Standorte, VPN-Netze und Gastnetze sind im Design berücksichtigt.

Für Detection-Themen kann Sophos Firewall NDR und Active Threat Response betreiben ergänzen. Für bekannte bösartige IPs, Domains und URLs auf Firewall-Ebene bleiben Sophos Firewall Threat Feeds relevant.

Checkliste

• Sophos Central DNS Protection Lizenz geprüft.
• Standort als Location angelegt.
• Öffentliche WAN-IP oder DDNS-FQDN korrekt hinterlegt.
• DNS Protection IP-Adressen aus Central kopiert.
• Sophos Firewall nutzt DNS Protection als DNS-Forwarder.
• Interne Domains mit DNS Request Routes abgedeckt.
• DHCP verteilt die Firewall als DNS-Resolver.
• Direkte DNS-Umgehung geprüft und bei Bedarf per NAT umgeleitet.
• DNS Protection Root Certificate für Blockseiten geplant.
• Testlink aus Sophos Central erfolgreich geprüft.
• Logs und Reports in Sophos Central kontrolliert.
• False-Positive-Prozess und Domainlisten-Review definiert.

FAQ