Sophos DNS Protection Reports und Live Discover auswerten

Unter My Products > DNS Protection > Reports werden DNS-Anfragen gefiltert, als Bericht aufbereitet und exportiert. Für eine detailliertere Untersuchung dient Threat Analysis Center > Live Discover > DNS Protection: Dort lassen sich die DNS-Datensätze im Data Lake mit integrierten oder eigenen SQL-Abfragen untersuchen.

Kurzablauf: Im Report Generator ein Report template und den Time frame wählen, unter Query möglichst eng filtern und Generate anklicken. Für Live Discover zuerst eine integrierte DNS-Protection-Abfrage über einen kurzen Zeitraum ausführen. Designer Mode erst einschalten, wenn die integrierte Abfrage Daten liefert; für eine neue DNS-Abfrage muss Data Lake als Source gewählt sein.

Voraussetzungen, Lizenz und Datenzuordnung

DNS Protection muss bereits DNS-Anfragen verarbeiten. Für die Reportauswertung sind deshalb eine bekannte aktive Location oder ein verwalteter Endpoint sowie ein kurzer Testzeitraum hilfreich. Reportdaten liegen 15 bis 25 Minuten hinter Echtzeit. Änderungen am Namen einer Location oder Policy können erst nach 30 Minuten bis 4 Stunden in den Reports erscheinen.

Bei einer eigenständigen oder netzwerkbasierten Bereitstellung gehört DNS Protection zur Xstream-Lizenzfamilie. Wird DNS Protection dagegen auf verwalteten Endpoints bereitgestellt, gehört dieser Bereitstellungsweg zu Workspace Protection. Workspace Protection und das auf dem Endpoint bereitgestellte DNS Protection sind auch Voraussetzung dafür, dass Reports Benutzer- und Geräteangaben aus Endpoint-Daten anzeigen können.

Live Discover hat eine davon getrennte Voraussetzung: Für diese Abfragefunktion ist eine Sophos-Berechtigung für EDR, XDR oder MDR erforderlich. Diese Berechtigung ersetzt Workspace Protection für den verwalteten Endpoint-DNS-Pfad nicht. DNS-Protection-Abfragen verwenden den Data Lake. Endpoint Queries sind für diesen Zweck nicht der richtige Datenpfad: Sie fragen den aktuellen Zustand ausgewählter verbundener Geräte ab, während Data-Lake-Abfragen hochgeladene Daten untersuchen.

Die Herkunft bestimmt, wie genau ein Report eine Anfrage zuordnen kann:

DNS usage zeigt DNS-Anfragen im gesamten Netzwerk.
DNS usage by source ordnet Netzwerkdaten einer Location zu. Bei Daten von Sophos Endpoint kann der Report zusätzlich Benutzer und Geräte ausweisen.
User zeigt bei Endpoint-Daten den Benutzer- oder Gerätenamen, von dem die Anfrage stammt. Device zeigt die Device-ID. Diese Spalten stehen nur für Sophos Endpoint zur Verfügung.
High risk devices zeigt Geräte, die DNS-Anfragen an riskante, verdächtige oder ungesicherte Websites stellen.

Damit ist die Grenze klar: Ein netzwerkbasierter DNS-Datensatz liefert nicht automatisch die Identität des ursprünglichen Benutzers oder Endpoints hinter einem lokalen Resolver. Die Endpoint-Integration hat die zusätzlichen benutzer- und gerätebezogenen Reporting-Felder sowie die Templates DNS usage by source und High risk devices eingeführt.

DNS Protection Report konfigurieren und filtern

My Products > DNS Protection > Reports öffnen und im Report Generator das passende Report template wählen.
Unter Time frame einen vorgegebenen Zeitraum oder Custom mit Start- und Endzeit festlegen. Für den ersten Test genügt ein enger Zeitraum rund um eine bekannte DNS-Anfrage.
Unter Query den Spaltennamen auswählen oder eingeben, den Filterwert erfassen und bei Bedarf den Operator neben dem Gleichheitszeichen ändern.
Weitere Filter nur ergänzen, wenn sie das Ergebnis sinnvoll eingrenzen. Mehrere Filter sind mit AND verbunden; eine Zeile muss also alle Bedingungen erfüllen.
Generate anklicken. Auch nach einem Klick auf einen Tabellenwert, der einen Filter ergänzt, muss der Report neu erzeugt werden.

Die Vergleichsoperatoren haben unterschiedliche Wirkungen:

= und != vergleichen Gross- und Kleinschreibung und prüfen Gleichheit beziehungsweise Ungleichheit.
<, <=, > und >= gelten nur für numerische Werte.
IN vergleicht Gross- und Kleinschreibung mit einer kommaseparierten Werteliste.
~ und !~ vergleichen ohne Beachtung der Gross- und Kleinschreibung mit einem Wildcard-Ausdruck; * ist der Platzhalter.

Für einen Domain-Test kann beispielsweise nach der tatsächlich angefragten Testdomain gefiltert werden. Der Domainname ist dabei ein umgebungsabhängiger Wert und muss durch den Wert des eigenen Tests ersetzt werden. Bleibt das Ergebnis leer, den Domainfilter zunächst entfernen und nur mit Zeitraum und Location prüfen. So wird sichtbar, ob die Schreibweise oder die Kombination mehrerer Filter das Resultat ausschliesst.

Die Tabelle startet mit Standardspalten. Über die Spaltenauswahl rechts oben lassen sich weitere Felder einblenden; die angebotenen Spalten hängen vom Template und von der Datenherkunft ab. Ein Klick auf eine Spaltenüberschrift sortiert auf- oder absteigend. Bei einer sichtbaren Datumsspalte fasst Sophos gleiche Zeilen abhängig vom Zeitraum zusammen:

bei 1, 8 oder 24 Stunden nach identischem Datum, Stunde und Minute,
bei 7 Tagen oder Custom bis 7 Tage nach identischer Startstunde,
bei 30 Tagen oder Custom über 7 Tage tageweise mit 00:00 als Zeitstempel.

Status nicht überinterpretieren: Bei einer falschen, ungültigen oder nicht mehr vorhandenen URL zeigt Status für A-, AAAA-, CNAME- oder HTTPS-Anfragen n/a, für andere Anfragearten Allowed. Dieser Wert allein belegt weder Erreichbarkeit noch Sicherheit der Zielseite.

Diagramme stehen als Bar, Horizontal bar, Pie, Line oder Stack-area zur Verfügung. Die Achsen werden über das Schraubenschlüssel-Symbol gewählt. Ein anderer Diagrammtyp setzt die Achsen auf seine Standardwerte zurück; Balken- und Kreisdiagramme zeigen nur die zehn häufigsten Kategorien.

Report speichern, planen und exportieren

Save Template speichert Query-Filter, Diagrammtyp und -achsen, Tabellensortierung sowie Tabellenspalten unter Saved Templates. Daten und Zeitraum werden nicht gespeichert. Deshalb muss der Zeitraum beim nächsten Aufruf erneut passend zur Untersuchung gewählt werden. Über DNS Protection, ZTNA und Sophos Firewall Reports zusammen sind maximal 1'000 Templates möglich.

Für eine einmalige Übergabe PDF, CSV oder HTML wählen. Wiederkehrende Auswertungen werden mit Schedule täglich, wöchentlich oder monatlich geplant. Ein Template Name darf höchstens 64 Zeichen enthalten, und insgesamt sind maximal 200 Schedules möglich. Die Exportgrenzen sind:

PDF: 10'000 Zeilen und 15 Spalten
HTML: 10'000 Zeilen und 23 Spalten
CSV: 100'000 Zeilen und 23 Spalten

Manuell erzeugte und geplante Exporte erscheinen unter Scheduled Exports und werden nach 90 Tagen gelöscht. Enthält ein Bericht personenbezogene Daten, ist der Versand eines Links per E-Mail sinnvoller als ein Anhang: Zum Öffnen des Links sind Sophos-Fusion-Anmeldedaten erforderlich. Heruntergeladene Dateien und Empfänger müssen dennoch zum eigenen Datenschutz- und Löschkonzept passen.

DNS-Daten mit Live Discover untersuchen

Threat Analysis Center > Live Discover > DNS Protection öffnen.
Eine integrierte DNS-Protection-Abfrage auswählen. Dafür ist Designer Mode nicht erforderlich.
Unter Select a Time Period zuerst einen kurzen, bekannten Aktivitätszeitraum wählen und Run Query anklicken. Eine Abfrage darf höchstens 30 Tage umfassen. Längere Untersuchungen werden in getrennte, nicht überlappende Zeitfenster aufgeteilt.
Erst wenn die integrierte Abfrage Daten liefert, Designer Mode aktivieren und die Abfrage mit Edit untersuchen oder Create new query wählen. Für eine neue DNS-Protection-Abfrage Data Lake als Source einstellen.
Im SQL-Dialog Schema öffnen. Im Schema Viewer unter Data Lake den Bereich Firewall und die Tabelle xgfw_data wählen.

Dieser Basistest trennt fehlende Daten oder Berechtigungen von einem Fehler in einer eigenen Abfrage. Übernehmen Sie keine allgemeine SQL-Vorlage oder undokumentierten Felder. Richten Sie eigene Abfragen stattdessen an der dokumentierten Zuordnung zu xgfw_data und den tatsächlich im Schema Viewer Ihres Tenants verfügbaren Feldern aus. Die Auswahl, Ausführung und Planung allgemeiner Data-Lake-Abfragen erklärt Sophos Endpoint Data Collection und Live Discover.

Dokumentierte DNS-Felder in `xgfw_data`

Sophos dokumentiert für DNS Protection folgende Felder:

action, bytes, dns_qid, dns_qname, dns_qtype, dns_duration, domain, domain_category, domain_risk, hits, log_type, log_component, object_name, protocol, policy_name, query_class, query_flags, query_size, reason, response_code, response_records_num, response_ip_num, resolved_ip, response_type, response_name, response_class, response_ttl_list, response_size, response, riskscore, security_status, src_ip, src_port, src_location, timestamp.

log_type mit dem Wert DNS und log_component mit FE-DNS kennzeichnen einen DNS-Protection-Log. object_name enthält den Namen der Domain List, wenn die Policy-Aktion Reject und der Grund Custom Domain Block or Allow war. timestamp bezeichnet den Verarbeitungszeitpunkt der DNS-Anfrage, hits die Anzahl der Anfragen und bytes die Summe aus Anfrage- und Antwortgrösse. Die response_*-Felder beschreiben die DNS-Antwort; security_status gibt an, ob DNSSEC für die Antwort validiert wurde.

Die Tabelle heisst zwar xgfw_data und liegt unter Firewall, doch daraus folgt nicht, dass jedes andere Firewall-Feld in DNS-Datensätzen befüllt ist. Insbesondere dokumentiert diese DNS-Feldliste keine Felder für User oder Device. Vor einer eigenen Abfrage deshalb die verfügbaren Felder im Schema Viewer des eigenen Tenants kontrollieren.

Ergebnis validieren und Probleme eingrenzen

Für einen reproduzierbaren Funktionstest eine bekannte Anfrage aus einer eindeutig zugeordneten Location oder von einem verwalteten Pilot-Endpoint erzeugen. Danach 15 bis 25 Minuten warten und kontrollieren:

Erscheint die Anfrage im gewählten Reportzeitraum?
Stimmen Domain, Aktion beziehungsweise Status, Policy und Location?
Sind bei Endpoint-Daten User und Device plausibel befüllt?
Liefert eine integrierte DNS-Protection-Abfrage in Live Discover für denselben Zeitraum passende Datensätze?

Der Report bleibt leer

Zuerst Time frame, Zeitzone, Filter und Gross-/Kleinschreibung bei =, != und IN prüfen. Danach Filter schrittweise entfernen, weil alle Bedingungen gleichzeitig erfüllt sein müssen. Liefert der breitere Report weiterhin nichts, kontrollieren, ob der Test tatsächlich DNS-Anfragen erzeugt hat und ob die erwartete Location beziehungsweise Endpoint-Datenherkunft verwendet wurde. Eine gerade umbenannte Location oder Policy eignet sich wegen der möglichen Verzögerung von 30 Minuten bis 4 Stunden nicht als Soforttest.

User oder Device fehlt

Prüfen, ob der Datensatz wirklich von Sophos Endpoint stammt. Netzwerkbasierte Anfragen enthalten diese Endpoint-Zuordnung nicht. Anschliessend DNS usage by source verwenden und User sowie Device über die Spaltenauswahl einblenden. Fehlen die Spalten oder Werte weiterhin, nicht aus Source-IP oder Location auf einen Benutzer schliessen.

Reports zeigen Daten, Live Discover aber nicht

Zuerst EDR-, XDR- oder MDR-Berechtigung, DNS Protection als Bereich, Data Lake als Source, den Zeitraum sowie Firewall > xgfw_data prüfen. Danach eine integrierte DNS-Protection-Abfrage unverändert mit Run Query ausführen. Funktioniert sie, liegt der Fehler in der eigenen Abfrage: Feldnamen direkt aus Schema übernehmen und die Abfrage schrittweise vereinfachen. Funktioniert auch die integrierte Abfrage nicht, ist der sichere nächste Schritt die Prüfung des Data-Lake-Datenpfads beziehungsweise eine Support-Eskalation; undokumentierte Felder oder Joins sind kein belastbarer Workaround.

Sicherer Rückweg und Lifecycle

Reports verändern die DNS-Verarbeitung nicht. Das Entfernen eines Filters oder das Verwerfen einer nicht gespeicherten Auswertung benötigt deshalb keinen technischen Rollback. Bei gespeicherten Artefakten vor dem Löschen prüfen, ob ein anderer Administrator oder ein Betriebsprozess sie benötigt:

Einen Zeitplan unter Scheduled Exports auswählen und mit Delete entfernen. Danach kontrollieren, dass keine weiteren Exporte dieses Schedules erzeugt werden.
Ein Template unter Saved Templates auswählen und mit Delete entfernen. Pro Vorgang können höchstens 25 Templates gelöscht werden. Das löscht die gespeicherte Reportkonfiguration, nicht die DNS-Quelldaten.
Eine fehlerhafte eigene Live-Discover-Abfrage nicht als Ersatz für die integrierte Abfrage weiterbetreiben. Zur bekannten integrierten DNS-Abfrage und einem kurzen Zeitraum zurückkehren.

Für den laufenden Betrieb sollten gespeicherte Templates und Schedules regelmässig auf Besitzer, Zweck, Empfänger, Zeitraum und benötigte Spalten geprüft werden. Besonders User, Device, Domain und Source-IP können personenbezogene oder betriebsrelevante Daten darstellen. Ausserdem sollte nach Änderungen an der Endpoint-Integration kontrolliert werden, ob DNS usage by source weiterhin Benutzer und Geräte ausweist. Prüfen Sie vor operativen Änderungen die aktuelle Hilfe und die tatsächlich verfügbaren Felder im Schema Viewer. Verwenden Sie Release Notes nur, wenn Sie die Einführung einer Reporting-Funktion historisch nachvollziehen möchten.