Śledź Serwer DNS w systemie Windows zapisuje logi w trzech miejscach w Podglądzie zdarzeń, plus opcjonalnym pliku tekstowym:
- Microsoft → Windows → DNS-Server → Audit: zmiany stref i rekordów. Domyślnie włączone na aktualnych serwerach Windows.
- Microsoft → Windows → DNS-Server → Analytical: każde zapytanie i odpowiedź. Domyślnie wyłączone i ukryte, dopóki nie pokażesz logów analitycznych.
- Serwer DNS, w Dziennikach aplikacji i usług: zdarzenia na poziomie usługi takie jak uruchomienia, zatrzymania i błędy ładowania stref.
- The log debug, plik tekstowy, który włączasz w Menedżerze DNS, zazwyczaj C:WindowsSystem32dnsdns.log.
Podstawowy eksport to jedna linia z podwyższonego wiersza polecenia:
wevtutil epl "Microsoft-Windows-DNSServer/Audit" C:logsdns_audit.evtx
Prawie wszystko w sieci tworzy zapytania DNS, w tym złośliwe oprogramowanie. Logi zapytań ujawniają tunelowanie DNS, algorytmy generowania domen i połączenia z znanymi złośliwymi domenami. Logi audytu ujawniają ciche zmiany rekordów. Prime Core ma {N} zasad detekcji dla danych DNS, zmapowanych do {M} technik MITRE ATT&CK. Wśród nich: dowodzenie i kontrola przez DNS (T1071.004) oraz algorytmy generowania domen (T1568.002).
Zanim zaczniesz
Logowanie zapytań prawdopodobnie nie było włączone. Kanał Analityczny jest domyślnie wyłączony. Jeśli badałeś coś, co już się wydarzyło, prawdopodobnie nie ma logów zapytań z serwera. Twoją opcją jest strona kliencka (zdarzenie Sysmon 22, lub log klienta DNS), logi zapory sieciowej lub proxy, albo sensor sieciowy. Włączenie go teraz pomoże na przyszłość.
Włącz rejestrowanie zapytań (na przyszłość). W Podglądzie zdarzeń wybierz Widok → Pokaż dzienniki analityczne i debugowania, następnie kliknij prawym przyciskiem Analityczne pod DNS-Server i wybierz Włącz log. Lub z linii komend:
wevtutil sl "Microsoft-Windows-DNSServer/Analytical" /e:true
Microsoft opisuje obciążenie jako umiarkowane, ale na bardzo obciążonym resolverze przetestuj, zanim zostawisz je włączone.
Potrzebujesz podwyższonego wiersza polecenia na serwerze DNS lub kontrolerze domeny działającym jako DNS.
Eksportuj logi
:: zmiany rekordów i stref
wevtutil epl "Microsoft-Windows-DNSServer/Audit" C:logsdns_audit.evtx
:: zdarzenia na poziomie usługi
wevtutil epl "DNS Server" C:logsdns_server.evtx
:: zapytania i odpowiedzi (tylko jeśli Analityczne zostało włączone)
wevtutil epl "Microsoft-Windows-DNSServer/Analytical" C:logsdns_analytical.evtx
Kanały analityczne zachowują się inaczej niż normalne logi. Podgląd zdarzeń może poprosić o wyłączenie logu, zanim pokaże zdarzenia. Get-WinEvent PowerShell czyta je tylko z -Oldest.
Log debug jest tekstem niesformatowanym, skonfigurowanym w Menedżerze DNS → właściwościach serwera → rejestrowaniu debugowania. Zapisuje pakiety szczegółowo i nadpisuje starsze wpisy, gdy osiągnie limit rozmiaru. Skopiuj go tak jak jest: kopiuj C:WindowsSystem32dnsdns.log C:logs.
Na co zwrócić uwagę
| Sygnał | Co to może oznaczać |
|---|---|
| Bardzo długie, losowo wyglądające poddomeny w zapytaniach | Tunelowanie DNS, dane przemycone w nazwach zapytań |
| Jeden klient generujący wiele nieudanych wyszukiwań (NXDOMAIN) | Złośliwe oprogramowanie przeglądające generowane domeny |
| Duży wolumen zapytań TXT z jednego hosta | Tunelowanie lub dowodzenie i kontrola |
| Zdarzenia audytu dla rekordów tworzonych, usuwanych lub zmienianych poza oknami zmian | Przejęcie rekordów, np. nowy rekord wpad |
| Plugin DLL ładowany przez usługę Serwera DNS | Nadużycie grupy DnsAdmins do uruchomienia kodu jako SYSTEM |
Prześlij i przeglądaj w LogTotal
LogTotal czyta EVTX natywnie. Jedna rzecz do zapamiętania: LogTotal nie czyści jeszcze plików EVTX. Logi DNS zawierają wewnętrzne nazwy hostów i adresy IP klientów. Traktuj przesłanie jak przekazanie surowego pliku: dobre dla serwerów testowych; dla produkcji, uzyskaj zgodę od osoby odpowiedzialnej za przetwarzanie danych.
Jeśli dziś potrzebujesz oczyszczania, najpierw przekonwertuj na JSON: evtx_dump -o jsonl dns_audit.evtx > dns_audit.jsonl.
- Prześlij. Otwórz logtotal.com i wrzuć plik.
- Przeglądaj.
Gdy coś pójdzie źle
| Objaw | Prawdopodobna przyczyna | Fix |
|---|---|---|
| Brak kanału Analitycznego w Podglądzie zdarzeń | Logi analityczne są domyślnie ukryte | Widok → Pokaż dzienniki analityczne i debugowania |
| Kanał Analityczny jest pusty | Nigdy nie był włączony | Włącz go; brak historii sprzed tego momentu |
| Błędy Get-WinEvent na logu Analitycznym | Logi analityczne wymagają -Oldest | Dodaj -Oldest |
| Brak kanału Audytu | Starszy Windows Server bez aktualizacji | Sprawdź wersję OS; użyj logu debugowania |
| Log debugowania obejmuje tylko krótki czas | Nadpisywał się, gdy osiągnął limit rozmiaru | Podnieś limit, lub przekierowuj logi gdzie indziej |
FAQ
Logi serwera czy klienta?
Serwer DNS mówi ci, który adres IP klienta zapytał. Tylko klient mówi ci, który proces zapytał. Dlatego zdarzenie Sysmon 22 na punktach końcowych tak dobrze uzupełnia logi serwera.
Czy log debugowania jest lepszy niż kanał Analityczny?
Log debugowania zawiera więcej szczegółów pakietów, ale kosztuje więcej i nadpisuje się. Dla większości dochodzeń kanał Analityczny jest lepszym domyślnym wyborem.
