Sophos DNS Protection für Endpoints konfigurieren
Die Endpoint DNS Protection Policy bindet Sophos DNS Protection direkt an Sophos Endpoint. Der Agent fängt DNS-Anfragen ab und leitet sie verschlüsselt per HTTPS an den Sophos-Dienst. Das funktioniert auch ausserhalb des Firmennetzes, ohne lokale DNS-Server am Gerät manuell umzustellen.
Die Funktion ist nicht mit Web Control identisch. DNS Protection entscheidet auf Domain-Ebene, während Web Control zusätzliche Web-Kategorien und Endpoint-Webprüfung abdeckt.
Voraussetzungen
Für die aktuelle Endpoint-Integration gelten:
- passende Workspace-Protection-Lizenz
- Sophos Endpoint Agent auf den Zielgeräten
- unterstütztes Windows-Endpoint-Betriebssystem
- keine Windows-Server- oder macOS-Zielgeräte
- kompatibles Endpoint-Softwarepaket
- HTTPS-Verbindung zu Sophos DNS Protection
Sophos verlangt derzeit ausdrücklich das Paket FTS 2025.2.3.31.2 Required for DNS Protection Update. Dazu wird in der Endpoint Update Management Base Policy unter Windows dieses Paket gewählt. Sophos bezeichnet diese Vorgabe als temporär; vor jedem neuen Rollout wird deshalb kontrolliert, ob sie noch gilt.
So arbeitet die Endpoint-Integration
- Der Endpoint-Agent fängt DNS-Anfragen ab.
- Nicht ausgenommene Anfragen gehen verschlüsselt an DNS Protection.
- Antworten werden direkt an die Anwendung zurückgegeben.
- Ausgenommene interne Domains gehen an den lokal oder per Anwendung konfigurierten DNS-Dienst.
- Optional kann ein öffentlich nicht auflösbarer Name nach einem
NXDOMAINnochmals über den lokalen DNS-Weg versucht werden.
Für interne Zonen empfiehlt Sophos explizite Domain-Ausnahmen. Das ist schneller und vorhersehbarer als ein genereller zweiter Versuch nach NXDOMAIN.
Agent-Komponente installieren
Unter My Products > Endpoint > Computers werden zuerst geeignete Windows-Endpoints ausgewählt. In Manage Endpoint Software erscheint abhängig von der Lizenz DNS beziehungsweise DNS & ZTNA.
Nach Install und Save wird geprüft:
- Agent mode bleibt wie geplant
- DNS-Komponente erreicht den Status
Installed - Gerät hat aktuelle Endpoint-Software
- keine Installations- oder Neustart-Alerts sind offen
Eine Softwarezuweisung kann unabhängig vom normalen Updatefenster anlaufen.
Secure-DNS-Standort festlegen
DNS Protection verwendet Locations für die Zuordnung zu Filterregeln. Für Endpoints wird eine Location mit Secure DNS verwendet. Die unveränderliche Default location kann genutzt oder eine eigene Location erstellt werden.
Getrennte Locations sind sinnvoll, wenn mobile Geräte, Länder oder Organisationseinheiten unterschiedliche Filterregeln benötigen. Eine Location ist kein Ersatz für eine saubere Policy-Zielgruppe.
Filtering Policy zur Location zuordnen
Die Endpoint-Policy bestimmt, welche Geräte DNS Protection verwenden und unter welcher Secure-DNS-Location sie erscheinen. Die eigentliche Kategorie- und Domainfilterung wird in einer separaten Filtering policy dieser Location festgelegt.
Pro Location kann nur eine Filtering Policy gelten. Sophos erlaubt tenantweit bis zu 50 solcher Policies. Ein eingebautes Filterprofil ist nicht direkt veränderbar; für eigene Kategorieentscheidungen wird Let me specify verwendet.
Domain Lists überschreiben die normale Kategorieentscheidung: Eine Allow-Liste kann eine Domain aus einer gesperrten Kategorie freigeben, eine Block-Liste kann sie trotz erlaubter Kategorie sperren. Sophos blockiert jedoch weiterhin Domains mit schlechtem Threat Score oder gefährlicher Reputation. Eine Allow-Liste ist deshalb kein allgemeiner Malware-Bypass.
Interne Unternehmensdomains können zusätzlich in einer erlaubten Domain List stehen, damit beispielsweise ZTNA- oder interne Services nicht wegen einer Kategorie wie Parked Domains blockiert werden. Das ersetzt nicht die Endpoint-Domain-Ausnahme für Namen, die ausschliesslich der interne DNS-Server auflösen kann.
Endpoint-Policy erstellen
Der aktuelle Einstieg lautet My Products > DNS Protection > Policies > Endpoint policies.
- Add policy wählen.
- Computer oder Computergruppen hinzufügen.
- Policy aktivieren.
- Unter Settings die Option Use Sophos DNS Protection einschalten.
- passende Secure-DNS-Location auswählen.
- interne Domain-Ausnahmen ergänzen.
- Blockseiten und Zertifikatsverteilung festlegen.
- Policy speichern und auf einer Pilotgruppe testen.
Die Reihenfolge der Endpoint-DNS-Policies entscheidet wie bei anderen Central-Policies, welche Policy ein Gerät erhält.
Interne DNS-Zonen
Interne Namen wie corp.example, Active-Directory-Zonen oder Split-DNS-Domains dürfen nicht versehentlich nur öffentlich aufgelöst werden.
Die sicherste Variante ist eine konkrete Domain-Ausnahme. Alle Subdomains werden dabei ebenfalls ausgenommen und über den normalen System-DNS aufgelöst.
Die Option Retry with system- or application-configured DNS services when DNS Protection returns NXDOMAIN ist ein Rückfallweg. Sie kann helfen, ist aber weniger effizient als eine gepflegte Liste interner Zonen.
Blockseiten und Zertifikat
Für HTTPS-Domains braucht der Browser ein vertrauenswürdiges DNS-Protection-Zertifikat, damit eine verständliche Blockseite statt einer Zertifikatswarnung erscheint.
Automatically deploy the DNS Protection signing certificate to devices verteilt das Root-Zertifikat an die Zielgeräte. Vorher werden bestehende Zertifikatsrichtlinien, Browser und restriktive Trust Stores getestet.
Zusätzlich muss blockpage.dnsprotection.sophos.com ohne Webfilter oder TLS-Entschlüsselung erreichbar sein, die das Blockseitenziel verändert. Wird eine Sophos Firewall mit Web-Proxy und Pharming Protection eingesetzt, nutzt sie entweder DNS Protection als Resolver oder erhält für dieses FQDN eine eigene Allow-Regel und eine Do not decrypt-TLS-Regel.
Auch ohne sichtbare Blockseite kann die Domain blockiert sein. Bei der Fehlersuche werden deshalb DNS-Protection-Logs und Policy-Treffer geprüft.
Pilot und Validierung
Die Pilotgruppe testet mindestens:
- öffentliche erlaubte und blockierte Domains
- interne Kurz- und FQDN-Namen
- VPN-, Homeoffice- und Büroverbindung
- Browser mit und ohne eigene Secure-DNS-Einstellungen
- Blockseite und Zertifikatsvertrauen
- Anwendungen mit eingebautem DNS over HTTPS
- Verhalten bei Ausfall oder Proxy-Blockierung
Zusätzlich werden unter DNS Protection Logs die Quell-Location, Policy und Aktion geprüft.
Logs und Reports auswerten
DNS Protection Reports liegen etwa 15 bis 25 Minuten hinter dem aktuellen Traffic. Änderungen an Location- oder Policy-Namen können 30 Minuten bis vier Stunden später in den Reports erscheinen. Diese Verzögerung wird bei Tests berücksichtigt.
Für Endpoint-Traffic stehen neben Location auch Benutzer und Device ID als Spalten zur Verfügung. Damit lässt sich prüfen, ob eine Anfrage tatsächlich vom erwarteten Agenten und nicht nur aus derselben öffentlichen IP-Adresse kam. Wichtige Ansichten sind DNS usage, DNS usage by source und High risk devices.
Gespeicherte Templates bewahren Filter und Darstellung, nicht jedoch Daten oder Zeitraum. Geplante Exporte enthalten je nach Format unterschiedliche Zeilen- und Spaltenlimits; exportierte Dateien werden nach 90 Tagen gelöscht. Für Incident-Daten wird deshalb eine eigene Aufbewahrung definiert.
Typische Probleme
Interne Namen lösen nicht auf
Die interne Zone wird als Domain-Ausnahme ergänzt. Danach werden lokaler DNS-Server, Suchsuffix und effektive Endpoint-DNS-Policy geprüft.
Gerät erscheint nicht in der Endpoint-Policy
Plattform, Lizenz, Agent-Komponente und Agent Mode werden kontrolliert. Die Endpoint-Integration unterstützt derzeit nur Windows-Endpoints, nicht Server oder macOS.
Blockseite zeigt Zertifikatsfehler
Verteilung und Vertrauen des DNS-Protection-Signing-Zertifikats werden geprüft. Bei eigenen Browser-Trust-Stores kann zusätzliche Verwaltung nötig sein.
Browser umgeht die Policy
Browser oder Anwendungen können eigene DNS-over-HTTPS-Wege verwenden. Der tatsächliche Resolver und die Endpoint-Events werden geprüft, bevor die DNS-Policy als funktionslos bewertet wird.
Erlaubte Domain bleibt blockiert
Zuerst werden Threat-Reputation und ein möglicher CNAME geprüft. Ist der Zielname erlaubt, sein CNAME aber einer blockierten Kategorie zugeordnet, kann die Verbindung weiterhin scheitern. Eine offensichtlich falsche Kategorie wird zur Rekategorisierung eingereicht, nicht mit immer breiteren Allow-Listen umgangen.
Neue Sperre greift nicht sofort
Bereits zwischengespeicherte DNS-Antworten bleiben bis zum Ablauf ihrer TTL nutzbar. Policy, Report und Testzeitpunkt werden deshalb zusammen dokumentiert; wiederholtes Speichern derselben Regel beschleunigt den TTL-Ablauf nicht.