Analiza raportów Sophos DNS Protection i danych w Live Discover

W sekcji My Products > DNS Protection > Reports można filtrować zapytania DNS, tworzyć na ich podstawie raporty i eksportować je. Do bardziej szczegółowych analiz służy sekcja Threat Analysis Center > Live Discover > DNS Protection, w której można badać rekordy DNS w Data Lake za pomocą wbudowanych lub własnych zapytań SQL.

Skrócony przebieg: w Report Generator wybrać Report template i Time frame, ustawić możliwie precyzyjne filtry w sekcji Query, a następnie kliknąć Generate. W Live Discover najpierw uruchomić wbudowane zapytanie DNS Protection dla krótkiego okresu. Designer Mode należy włączyć dopiero wtedy, gdy wbudowane zapytanie zwróci dane. W przypadku nowego zapytania DNS jako Source musi być wybrane Data Lake.

Wymagania wstępne, licencja i przypisywanie danych

DNS Protection musi już przetwarzać zapytania DNS. Dlatego podczas analizowania raportów przydaje się znana aktywna lokalizacja lub zarządzany endpoint oraz krótki okres testowy. Dane w raportach są opóźnione względem czasu rzeczywistego o 15–25 minut. Zmiana nazwy lokalizacji lub policy może pojawić się w raportach dopiero po upływie od 30 minut do 4 godzin.

W przypadku wdrożenia samodzielnego lub sieciowego DNS Protection należy do rodziny licencji Xstream. Jeśli natomiast DNS Protection jest wdrażane na zarządzanych endpointach, ten sposób wdrożenia wchodzi w zakres Workspace Protection. Workspace Protection oraz DNS Protection wdrożone na endpoincie są również niezbędne, aby raporty mogły wyświetlać informacje o użytkownikach i urządzeniach pochodzące z danych endpointa.

Live Discover ma osobne wymaganie: ta funkcja zapytań wymaga uprawnienia Sophos EDR, XDR lub MDR. Uprawnienie to nie zastępuje Workspace Protection w przypadku ścieżki DNS na zarządzanych endpointach. Zapytania DNS Protection korzystają z Data Lake. Endpoint Queries nie stanowią do tego celu właściwej ścieżki danych: odpytują one bieżący stan wybranych połączonych urządzeń, natomiast zapytania do Data Lake analizują przesłane dane.

Pochodzenie danych określa, jak dokładnie raport może przypisać zapytanie:

DNS usage pokazuje zapytania DNS w całej sieci.
DNS usage by source przypisuje dane sieciowe do lokalizacji. W przypadku danych z Sophos Endpoint raport może dodatkowo wskazać użytkowników i urządzenia.
User pokazuje dla danych endpointa nazwę użytkownika lub urządzenia, z którego pochodzi zapytanie. Device pokazuje identyfikator urządzenia. Kolumny te są dostępne tylko w przypadku Sophos Endpoint.
High risk devices pokazuje urządzenia wysyłające zapytania DNS do ryzykownych, podejrzanych lub niezabezpieczonych witryn.

Granica jest zatem wyraźna: sieciowy rekord DNS nie pozwala automatycznie ustalić tożsamości pierwotnego użytkownika ani endpointa znajdującego się za lokalnym resolverem. Integracja z endpointem wprowadziła dodatkowe pola raportowania dotyczące użytkowników i urządzeń oraz szablony DNS usage by source i High risk devices.

Konfigurowanie i filtrowanie raportu DNS Protection

Otworzyć My Products > DNS Protection > Reports i wybrać odpowiedni Report template w sekcji Report Generator.
W sekcji Time frame ustawić zdefiniowany okres albo wybrać Custom i określić czas rozpoczęcia oraz zakończenia. Do pierwszego testu wystarczy krótki okres obejmujący znane zapytanie DNS.
W sekcji Query wybrać lub wpisać nazwę kolumny, wprowadzić wartość filtra i w razie potrzeby zmienić operator obok znaku równości.
Dodawać kolejne filtry tylko wtedy, gdy sensownie zawężają wynik. Wiele filtrów jest połączonych operatorem AND, dlatego wiersz musi spełniać wszystkie warunki.
Kliknąć Generate. Raport trzeba wygenerować ponownie także po kliknięciu wartości w tabeli, które dodaje filtr.

Operatory porównania działają w różny sposób:

= i != uwzględniają wielkość liter i sprawdzają odpowiednio równość oraz nierówność.
<, <=, > i >= mają zastosowanie wyłącznie do wartości liczbowych.
IN porównuje z rozdzieloną przecinkami listą wartości i uwzględnia wielkość liter.
~ i !~ porównują bez uwzględniania wielkości liter, korzystając z wyrażenia z symbolami wieloznacznymi; symbolem wieloznacznym jest *.

Przykładowo podczas testu domeny można filtrować według rzeczywiście odpytywanej domeny testowej. Nazwa domeny jest wartością zależną od środowiska i należy ją zastąpić wartością używaną we własnym teście. Jeśli wynik pozostaje pusty, najpierw usunąć filtr domeny i sprawdzić tylko okres oraz lokalizację. Pozwoli to ustalić, czy wynik wyklucza pisownia wartości lub połączenie wielu filtrów.

Tabela początkowo zawiera standardowe kolumny. Selektor kolumn w prawym górnym rogu pozwala wyświetlić dodatkowe pola; dostępne kolumny zależą od szablonu i pochodzenia danych. Kliknięcie nagłówka kolumny sortuje dane rosnąco lub malejąco. Gdy widoczna jest kolumna daty, Sophos grupuje identyczne wiersze zależnie od okresu:

dla 1, 8 lub 24 godzin — według identycznej daty, godziny i minuty,
dla 7 dni lub okresu Custom do 7 dni — według identycznej godziny rozpoczęcia,
dla 30 dni lub okresu Custom powyżej 7 dni — według dnia, ze znacznikiem czasu 00:00.

Nie należy nadinterpretować pola Status: w przypadku błędnego, nieprawidłowego lub nieistniejącego adresu URL pole Status pokazuje n/a dla zapytań typu A, AAAA, CNAME lub HTTPS, a Allowed dla zapytań innych typów. Sama ta wartość nie potwierdza ani dostępności, ani bezpieczeństwa witryny docelowej.

Dostępne typy wykresów to Bar, Horizontal bar, Pie, Line i Stack-area. Osie wybiera się za pomocą ikony klucza. Zmiana typu wykresu przywraca jego domyślne ustawienia osi; wykresy słupkowe i kołowe pokazują tylko dziesięć najczęstszych kategorii.

Zapisywanie, planowanie i eksportowanie raportu

Save Template zapisuje filtry zapytania, typ i osie wykresu, sposób sortowania tabeli oraz jej kolumny w sekcji Saved Templates. Dane i okres nie są zapisywane. Dlatego przy następnym otwarciu trzeba ponownie wybrać okres odpowiedni do danej analizy. Łącznie dla raportów DNS Protection, ZTNA i Sophos Firewall można utworzyć maksymalnie 1 000 szablonów.

W celu jednorazowego przekazania raportu wybrać PDF, CSV lub HTML. Cykliczne raporty można zaplanować za pomocą opcji Schedule w trybie dziennym, tygodniowym lub miesięcznym. Template Name może zawierać maksymalnie 64 znaki, a łączny limit harmonogramów wynosi 200. Obowiązują następujące limity eksportu:

PDF: 10 000 wierszy i 15 kolumn
HTML: 10 000 wierszy i 23 kolumny
CSV: 100 000 wierszy i 23 kolumny

Eksporty utworzone ręcznie i zgodnie z harmonogramem pojawiają się w sekcji Scheduled Exports i są usuwane po 90 dniach. Jeśli raport zawiera dane osobowe, lepiej wysłać pocztą elektroniczną łącze niż załącznik: otwarcie łącza wymaga danych logowania do Sophos Fusion. Pobrane pliki i odbiorcy nadal muszą jednak spełniać wymagania przyjętej w organizacji koncepcji ochrony i usuwania danych.

Analizowanie danych DNS za pomocą Live Discover

Otworzyć Threat Analysis Center > Live Discover > DNS Protection.
Wybrać wbudowane zapytanie DNS Protection. Nie wymaga to użycia Designer Mode.
W sekcji Select a Time Period najpierw wybrać krótki, znany okres aktywności i kliknąć Run Query. Jedno zapytanie może obejmować maksymalnie 30 dni. Dłuższe analizy należy podzielić na osobne, niepokrywające się przedziały czasu.
Dopiero gdy wbudowane zapytanie zwróci dane, włączyć Designer Mode i przeanalizować zapytanie za pomocą opcji Edit lub wybrać Create new query. W przypadku nowego zapytania DNS Protection ustawić Data Lake jako Source.
W oknie dialogowym SQL otworzyć Schema. W Schema Viewer, w sekcji Data Lake, wybrać obszar Firewall i tabelę xgfw_data.

Ten podstawowy test pozwala odróżnić brak danych lub uprawnień od błędu we własnym zapytaniu. Nie należy używać ogólnego szablonu SQL ani nieudokumentowanych pól. Własne zapytania należy zamiast tego oprzeć na udokumentowanym przypisaniu do tabeli xgfw_data i polach rzeczywiście dostępnych w Schema Viewer danego tenanta. Wybieranie, uruchamianie i planowanie ogólnych zapytań do Data Lake opisano w artykule Gromadzenie danych Sophos Endpoint i Live Discover.

Udokumentowane pola DNS w tabeli `xgfw_data`

Sophos dokumentuje następujące pola DNS Protection:

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.

Pole log_type o wartości DNS oraz pole log_component o wartości FE-DNS wskazują log DNS Protection. Pole object_name zawiera nazwę Domain List, jeśli akcją policy było Reject, a przyczyną Custom Domain Block or Allow. Pole timestamp określa czas przetworzenia zapytania DNS, hits — liczbę zapytań, a bytes — łączny rozmiar zapytania i odpowiedzi. Pola response_* opisują odpowiedź DNS; security_status wskazuje, czy dla odpowiedzi przeprowadzono walidację DNSSEC.

Choć tabela nazywa się xgfw_data i znajduje się w sekcji Firewall, nie oznacza to, że każde inne pole zapory jest wypełniane w rekordach DNS. W szczególności ta udokumentowana lista pól DNS nie zawiera pól User ani Device. Dlatego przed utworzeniem własnego zapytania należy sprawdzić pola dostępne w Schema Viewer danego tenanta.

Weryfikowanie wyników i zawężanie problemów

Aby przeprowadzić powtarzalny test działania, wygenerować znane zapytanie z jednoznacznie przypisanej lokalizacji lub zarządzanego endpointa pilotażowego. Następnie odczekać od 15 do 25 minut i sprawdzić:

Czy zapytanie pojawia się w wybranym okresie raportowania?
Czy domena, akcja lub status, policy i lokalizacja są zgodne z oczekiwaniami?
Czy w przypadku danych endpointa pola User i Device zawierają wiarygodne wartości?
Czy wbudowane zapytanie DNS Protection w Live Discover zwraca dla tego samego okresu odpowiednie rekordy?

Raport pozostaje pusty

Najpierw sprawdzić Time frame, strefę czasową, filtry oraz wielkość liter dla operatorów =, != i IN. Następnie stopniowo usuwać filtry, ponieważ wszystkie warunki muszą być spełnione jednocześnie. Jeśli szerszy raport nadal niczego nie zwraca, sprawdzić, czy test rzeczywiście wygenerował zapytania DNS oraz czy użyto oczekiwanej lokalizacji lub źródła danych endpointa. Niedawno zmieniona nazwa lokalizacji lub policy nie nadaje się do natychmiastowego testu ze względu na możliwe opóźnienie wynoszące od 30 minut do 4 godzin.

Brak wartości User lub Device

Sprawdzić, czy rekord rzeczywiście pochodzi z Sophos Endpoint. Zapytania sieciowe nie zawierają takiego przypisania do endpointa. Następnie użyć DNS usage by source i wyświetlić User oraz Device za pomocą selektora kolumn. Jeśli nadal brakuje kolumn lub wartości, nie należy wnioskować o użytkowniku na podstawie źródłowego adresu IP ani lokalizacji.

Raporty zawierają dane, ale Live Discover ich nie pokazuje

Najpierw sprawdzić uprawnienie EDR, XDR lub MDR, obszar DNS Protection, ustawienie Data Lake jako Source, okres oraz Firewall > xgfw_data. Następnie bez modyfikacji uruchomić wbudowane zapytanie DNS Protection za pomocą opcji Run Query. Jeśli działa, błąd znajduje się we własnym zapytaniu: należy użyć nazw pól bezpośrednio ze sekcji Schema i stopniowo upraszczać zapytanie. Jeśli nie działa również zapytanie wbudowane, bezpiecznym kolejnym krokiem jest sprawdzenie ścieżki danych Data Lake lub eskalacja do pomocy technicznej; nieudokumentowane pola lub złączenia nie stanowią wiarygodnego obejścia problemu.

Bezpieczne wycofywanie zmian i cykl życia

Raporty nie zmieniają sposobu przetwarzania DNS. Dlatego usunięcie filtra lub odrzucenie niezapisanej analizy nie wymaga technicznego wycofania zmian. Przed usunięciem zapisanych elementów należy sprawdzić, czy nie są potrzebne innemu administratorowi lub procesowi operacyjnemu:

Wybrać harmonogram w sekcji Scheduled Exports i usunąć go za pomocą opcji Delete. Następnie sprawdzić, czy z tego harmonogramu nie są już tworzone kolejne eksporty.
Wybrać szablon w sekcji Saved Templates i usunąć go za pomocą opcji Delete. W ramach jednej operacji można usunąć maksymalnie 25 szablonów. Powoduje to usunięcie zapisanej konfiguracji raportu, a nie źródłowych danych DNS.
Nie używać błędnego własnego zapytania Live Discover jako zamiennika zapytania wbudowanego. Wrócić do znanego wbudowanego zapytania DNS i krótkiego okresu.

W ramach bieżącej eksploatacji należy regularnie sprawdzać zapisane szablony i harmonogramy pod kątem właściciela, celu, odbiorców, okresu i potrzebnych kolumn. W szczególności User, Device, domena i źródłowy adres IP mogą stanowić dane osobowe lub dane istotne dla działania organizacji. Po zmianach w integracji z endpointami należy ponadto sprawdzić, czy raport DNS usage by source nadal wskazuje użytkowników i urządzenia. Przed wprowadzeniem zmian operacyjnych należy zapoznać się z aktualną pomocą i polami rzeczywiście dostępnymi w Schema Viewer. Release Notes należy wykorzystywać tylko wtedy, gdy potrzebne jest prześledzenie historycznego wprowadzenia funkcji raportowania.