В этой статье мы рассмотрим, как включить логирование всех DNS запросов пользователей, которые получает DNS сервер на Windows Server, и выполнить их анализ. У меня такая возникла, когда понадобилось декомисснуть ( удалить ) старый контроллер домена Active Directory в филиале и нужно было понять, какие устройства все еще используют этот DNS сервер. После включения DNS лога и его анализа я смог найти оставшиеся устройства и перенастроить их на другие DNS сервера. Также эта методика поможет вам найти в сети хосты с подозрительной активность (обращения к вредоносным URL, хостам управления ботнетами и т.д.).
Конечно, можно поставить на сервер Wireshark, network monitor или pktmon и отслеживать весь трафик на 53 порту, но использование встроенной функции логирования DNS запросов намного проще.
По умолчанию в Windows Server отключено логирование DNS всех пакетов. Чтобы его включить:
- Запустите консоль DNS Manager (
dnsmgmt.msc) и подключитесь к нужному DNS серверу; - Откройте его свойства и перейдите на вкладку Debug Logging ;
- Включите опцию Log packets for debugging ;
- Далее можно настроить параметры логирования: выбрать направление DNS пакетов, протокол (UDP и/или TCP), типы пакетов (простые dns запросы, запросы на обновление записей, уведомления);
- С помощью опцию Filter packets by IP address можно указать IP адреса, для которых нужно логировать отправленные или полученные пакеты (поможет существенно уменьшить размер лога).
- В поле Log file path and name укажите имя текстового файла, в который нужно записывать все события. По умолчанию размер DNS лога ограничен 500Мб. После достижения этого лимита старые события начнут перезатираться новыми.
Также вы можете включить логирование DNS или получить текущие настройки с помощью PowerShell :
Get-DnsServerDiagnostics
Обратите внимание, что на высоконагруженных DNS серверах Windows логирование DNS запросов может вызвать дополнительную нагрузку на CPU, память и дисковую подсистему (диски должны быть достаточно производительными ).
Теперь выполните с любого компьютера DNS запрос к этому серверу (IP адрес нашего DNS хоста с Windows Server 192.168.13.10), например:
nslookup remontka.com 192.168.13.10
Или выполните DNS запрос с помощью PowerShell:
Resolve-DnsName -Name remontka.com -Server 192.168.13.10
Данный запрос вернул клиенту IP адрес запрошенного сервера.
Проверим теперь, что этот запрос отобразился в логе DNS сервера.
Для этого, выполним поиск в текстовом логе по IP адресу клиента (192.168.13.200). Можно открыть лог файл в блокноте, а можно выполнить поиск по нему с помощью PowerShell:
get-content "C:Logsdc01_dns.log" | Out-String -Stream | Select-String "192.168.13.200"
Событие выглядит так:
4/29/2021 2:30:20 AM 0D0C PACKET 00000272D98DD0B0 UDP Rcv 192.168.13.200 0002 Q [0001 D NOERROR] A (8)remontka(2)ru(0)
Как вы видите, в логе указано: от клиента 192.168.13.200 получен (rcv) DNS запрос по протоколу UDP на разрешение имени (8)remontka(2)ru(0), а затем DNS сервер успешно (NOERROR) отправил ему ответ (snd).
Все поля описаны в начале файла:
Field # Information Values_x000D_------- ----------- ------_x000D_1 Date_x000D_2 Time_x000D_ 3 Thread ID_x000D_4 Context_x000D_5 Internal packet identifier_x000D_6 UDP/TCP indicator_x000D_7 Send/Receive indicator_x000D_8 Remote IP_x000D_9 Xid (hex)_x000D_10 Query/Response R = Response_x000D_blank = Query_x000D_11 Opcode Q = Standard Query_x000D_N = Notify_x000D_U = Update_x000D_? = Unknown_x000D_12 [ Flags (hex)_x000D_13 Flags (char codes) A = Authoritative Answer_x000D_T = Truncated Response_x000D_D = Recursion Desired_x000D_R = Recursion Available_x000D_14 ResponseCode ]_x000D_15 Question Type_x000D_16 Question Name_x000D_
Из-за специфического формата, анализировать DNS лог вручную довольно сложно, поэтому для преобразования DNS запросов в более удобный формат можно использовать готовый PowerShell скрипт Get-DNSDebugLog.ps1 .
Скрипт не мой, но к сожалению он сейчас не доступен в TechNet Scriptcenter из за очередных изменений Microsoft, поэтому я сохранил его в свой репозитории на GitHub https://github.com/winadm/posh/blob/master/DNS/Get-DNSDebugLog.ps1
Скачайте данный файл к себе на диск. Затем разрешите запуск PowerShell скриптов в текущей консоли:
Set-ExecutionPolicy -Scope Process Unrestricted
Импортируйте функцию из файла Get-DNSDebugLog.ps1 в свою сессию:
. C:psGet-DNSDebugLog.ps1
Теперь можно преобразовать DNS лог в более удобный вид:
Get-DNSDebugLog -DNSLog C:Logsdc01_dns.log | format-table 
[Или можно экспортировать полученный результат в CSV файл для дальнейшего анализа в Excel (либо можно напрямую обращаться из PowerShell к Excel файлу и заносить в него нужные строки).
Get-DNSDebugLog -DNSLog C:Logsdc01_dns.log | Export-Csv C:logProperlyFormatedDNSLog.csv –NoTypeInformation
Вы можете экспортировать данный файл в Excel и использовать его для анализа DNS запросов (в файле есть адреса хостов и DNS имена, за которыми они обращались к вашему DNS серверу).
Также для анализа лог файла с DNS запросами можно использовать Log Parser 2.2 ( https://docs.microsoft.com/en-us/archive/blogs/secadv/parsing-dns-server-log-to-track-active-clients ). Например, следующая команда выведет информацию о количестве DNS запросов с каждого IP адреса:
LogParser.exe -i:TSV -nskiplines:30 -headerRow:off -iSeparator:space -nSep:1 -fixedSep:off -rtp:-1 "SELECT field9 AS IP, REVERSEDNS(IP) AS Name, count(IP) as QueryCount FROM "C:Logsdc01_dns.log" WHERE field11 = 'Q' GROUP BY IP ORDER BY QueryCount DESC"
В этом примере мы использовали текстовые файлы для сбора DNS логов. В Windows Server 2012+ вы можете записывать DNS запросы прямо в журнал Event Viewer ( Microsoft-Windows-DNS-Server/Audit ). Но на мой взгляд текстовые DNS логи анализировать гораздо проще.
Конечно, если вам нужно вести логирование DNS запросов на множестве серверов, предпочтительнее слать их нормальную систему сбора логов, хранения и обработки логов, такую как Splunk, ELK, Graylog или Azure Log Analytics.
После включения DNS лога и его анализа я нашел IP адреса устройств, которые все еще используют этот DNS сервер и перенастроил их на другие DNS сервера. Теперь, если старый DC не содержит FSMO ролей , то его можно спокойно удалять ( события логона пользователей при этом роли не играют).
