# DNS и разрешение имен **Domain Name System (DNS)** — это фундаментальный механизм, который превращает удобные для человека доменные имена (например, `ya.ru`) в машинные IP-адреса (такие как `77.88.55.242`), позволяя компьютерам находить друг друга в сети. Хотя DNS чаще всего ассоциируется с интернетом, она играет ключевую роль и в **корпоративных и домашних сетях**: * В корпоративных сетях DNS используется для разрешения имён внутренних серверов (например, `fileserver.corp.local`). * В **Active Directory** (AD) DNS критически важен для работы доменных служб: аутентификации, групповых политик, поиска контроллеров домена. Использует UDP/53 (запросы) и TCP/53 (большие ответы). ## Структура доменного имени `sub4.sub3.sub2.example.com.` 1. **.** (корень) — невидимая "точка" в конце (по умолчанию опускается). Но если вы её подставите в браузер, он вас поймёт.\ Корневая зона управляется организацией IANA. Имеет 13 логических серверов (более 1000 физических экземпляров по всему миру). Содержат информацию только о серверах TLD. 2. **com** — домен верхнего уровня (TLD - top-level domain): * **gTLD** (общие): .com, .org, .net * **ccTLD** (национальные): .ru, .de, .jp * **Специальные**: .arpa, .local, .onion 3. **example** — домен второго уровня (SLD - Second-Level domain). Регистрируются у аккредитованных регистраторов. Информация доступна в whois.\ Владелец домена может создавать поддомены любого уровня. 4. **sub2, sub3, sub4** — поддомены (управляются владельцем example.com).\ Глубина вложенности технически не ограничена. Но глубокая иерархия увеличивает время разрешения имён. {% @mermaid/diagram content="graph TD Root\[".
Корень (Root)
IANA, 13 логических серверов"] ``` TLD["com
TLD (Top-Level Domain)
.com, .org, .ru, .de"] SLD["example
SLD (Домен 2-го уровня)
Регистрируется у регистратора"] Sub1["sub2
Поддомен 1-го уровня"] Sub2["sub3
Поддомен 2-го уровня"] Sub3["sub4
Поддомен 3-го уровня"] Root --> TLD TLD --> SLD SLD --> Sub1 Sub1 --> Sub2 Sub2 --> Sub3" %} ``` {% hint style="info" %} WHOIS - распределённая база данных о владельцах доменов и IP-адресов. Для доменов: * Информация о регистраторе * Даты создания и окончания регистрации * Контакты владельца (часто скрытые из-за GDPR) * DNS-серверы домена Для IP-адресов: * Принадлежность блоков адресов * Контакты администраторов сетей {% endhint %} DNS организована как распределённая база данных с древовидной структурой: * **Корневые серверы** (13 групп, обозначаемые от A до M) * **Серверы доменов верхнего уровня** (TLD: .com, .org, .ru) * **Авторитативные серверы** (управляющие конкретными доменами) Каждый уровень делегирует ответственность за поддомены нижестоящим серверам или другому серверу.\ Например, владелец `example.com` может передать управление `cdn.example.com` на серверы Cloudflare через NS-записи. {% hint style="info" %} **Кодировка Punycode** позволяет использовать кириллицу и эмодзи (например, `россия.рф` → `xn--h1alffa9f.xn--p1ai`). {% endhint %} ### **CDN (Content Delivery Network) — технология доставки контента** CDN — это распределённая сеть серверов, расположенных географически близко к пользователям, которая ускоряет загрузку веб-контента (изображений, видео, скриптов) за счёт кэширования и минимизации задержек. **Как работает CDN?** 1. **Пользователь** запрашивает контент (например, картинку с сайта). 2. **CDN** определяет его местоположение и направляет запрос к ближайшему серверу (PoP — Point of Presence). 3. Если контент есть в кэше сервера — он сразу отдаётся. Если нет — сервер CDN загружает его с origin-сервера (основного источника), кэширует и затем отдаёт пользователю. Это сокращает путь данных, уменьшает время загрузки страниц, снижает нагрузку на основной сервер и обеспечивает высокую доступность, защищая от пиковых нагрузок. **Примеры CDN-провайдеров** * **Cloudflare** (бесплатный тариф + защита от атак). * **Akamai** (крупнейшая CDN в мире). * **AWS CloudFront** (интеграция с Amazon Web Services). Поэтому вы часто сможете увидеть резолв их доменов из своей сети. ## Обратное разрешение имён (Reverse DNS / PTR-записи) Механизм преобразования **IP-адреса → доменное имя** (обратное обычному DNS).\ Пример:\ `8.8.8.8` → `dns.google.` ### Зачем это нужно 1. **Верификация серверов** 1. **Почтовые серверы** проверяют PTR, чтобы отсечь спам:\ Если IP `1.2.3.4` не резолвится в `mail.example.com`, письма могут попасть в спам. 2. **SSH/FTP**: Некоторые системы требуют PTR для подключения. 2. **Логирование и мониторинг**\ В логах вместо `54.239.28.85` вы увидите `aws-server.amazon.com` — удобнее анализировать трафик. ### Как работает технически Для обратного разрешения используется специальный домен `in-addr.arpa`
Домен arpa * Первоначально создан для переходного периода ARPANET → Internet * Единственный TLD, управляемый непосредственно IETF * Сейчас содержит несколько поддоменов: * `in-addr.arpa` (IPv4) * `ip6.arpa` (IPv6) * `e164.arpa` (для телефонии ENUM)
IP записывается в обратном порядке: ``` 8.8.4.4 → 4.4.8.8.in-addr.arpa ``` Для `4.4.8.8.in-addr.arpa` создается специальная PTR-запись (PTR-записи настраивает владелец IP-адреса). ``` # Пример записи в зоне 4.8.8.in-addr.arpa: 8 IN PTR dns.google. ``` Эту запись используют инструменты `nsllokup`, `dig -x` и другие для обратного разрешения имен. ## Основные типы DNS-записей | Тип | Назначение | Пример | | ----- | ------------------ | ------------------------------------ | | A | IPv4-адрес | 192.0.2.1 | | AAAA | IPv6-адрес | 2001:db8::1 | | CNAME | Каноническое имя | www → example.com | | MX | Почтовый сервер | 10 mail.example.com | | TXT | Произвольный текст | "v=spf1..." | | NS | Сервер имён | ns1.example.com | | PTR | Обратная запись | 1.2.0.192.in-addr.arpa → example.com | **ANY-запросы** почти отключены из-за злоупотреблений (возвращают все записи домена). ## DNSSEC — защита целостности DNS-записей **DNSSEC (Domain Name System Security Extensions)** — это набор расширений, который добавляет криптографическую подпись к DNS-записям, обеспечивая их **аутентичность и целостность**. Это защищает от атак типа **DNS spoofing** и **cache poisoning**, когда злоумышленник подменяет ответы DNS-сервера. ### Как работает DNSSEC 1. **Владелец домена** подписывает свои DNS-записи приватным ключом. 2. **DNS-резолвер** проверяет подпись публичным ключом при получении ответа. 3. Если подпись не совпадает — запрос отклоняется. ### Ключевые типы записей DNSSEC | Тип записи | Назначение | | -------------- | -------------------------------------------------------- | | **DNSKEY** | Публичный ключ для проверки подписи | | **RRSIG** | Криптографическая подпись набора записей | | **DS** | Делегирование подписи (связь между зонами) | | **NSEC/NSEC3** | Доказательство отсутствия записи (защита от enumeration) | {% hint style="info" %} DNSSEC **не шифрует трафик** — только подписывает ответы (DNS-over-TLS/HTTPS решают эту проблему) {% endhint %} ## DoT и DoH — шифрование DNS-трафика Если DNSSEC защищает **целостность** данных, то **DoT (DNS-over-TLS)** и **DoH (DNS-over-HTTPS)** защищают **конфиденциальность** — шифруют сам канал передачи DNS-запросов. | Протокол | Порт | Как работает | Преимущества | | ------------------------ | ------- | ----------------------------------- | ---------------------------------------------------------- | | **DNS** | **53** | - | Весь трафик виден в сети (Wireshark, провайдер) | | **DoT** (DNS-over-TLS) | **853** | Выделенный порт для DNS через TLS | Трафик зашифрован, но виден факт DNS-запроса | | **DoH** (DNS-over-HTTPS) | **443** | DNS-запросы инкапсулируются в HTTPS | Маскируется под обычный веб-трафик, сложнее контролировать | ## Что происходит, если вбить в браузере ya.ru 1. **Проверка локального кэша**: ОС проверяет кэш DNS (если запрос к `ya.ru` был недавно): * **Windows**: `ipconfig /displaydns | find "ya.ru"` * **Linux**: `systemd-resolve --statistics` или `sudo journalctl -u systemd-resolved` 2. **Чтение файла `hosts`**: Проверка `/etc/hosts` (Linux/macOS) или `C:\Windows\System32\drivers\etc\hosts` (Windows) на наличие принудительного сопоставления: ``` 87.250.250.242 ya.ru # Пример принудительной записи ``` 3. **Обращение к DNS-резолверу**:\ Запрос отправляется к DNS-серверу из настроек ОС (например, `8.8.8.8`, провайдерский или корпоративный). * **Если клиент в корпоративной сети:** * Запрос сначала отправляется на **внутренний DNS-сервер компании** (например, `ns1.corp.local`). В среде Active Directory роль DNS-сервера обычно выполняет контроллер домена. * Этот сервер может: * **Вернуть локальный IP**, если домен внутренний (например, `wiki.corp.local`). * **Делегировать запрос внешнему DNS**, если домен публичный (как `ya.ru`). * **Рекурсивный DNS-запрос (если предыдущие шаги не дали ответа)** * Запрос уходит к **провайдерскому или публичному DNS** (например, `8.8.8.8`). * Процесс разрешения: 4. **Кэширование результата** * IP сохраняется в кэше **корпоративного DNS** и локальной машины. {% @mermaid/diagram content="sequenceDiagram participant User as Пользователь participant Browser as Браузер participant OS as ОС (Кэш/Hosts) participant CorpDNS as Корпоративный DNS participant RecDNS as Рекурсивный DNS participant Root as Корневой сервер participant TLD as TLD сервер (.ru) participant Auth as Авторитативный DNS (ya.ru) ``` User->>Browser: Вводит ya.ru Browser->>OS: Запрос на разрешение имени alt Кэш содержит запись OS-->>Browser: IP из кэша else Кэш пуст OS->>OS: Проверка hosts файла alt Запись в hosts OS-->>Browser: IP из hosts else Записи нет OS-->>Browser: Кэш/hosts пусто Browser->>CorpDNS: DNS-запрос (ya.ru) alt Внутренний домен CorpDNS-->>Browser: Локальный IP else Внешний домен CorpDNS->>RecDNS: Рекурсивный запрос RecDNS->>RecDNS: Проверка своего кэша alt Кэш есть RecDNS-->>CorpDNS: IP из кэша else Кэш пуст RecDNS->>Root: Запрос корня Root-->>RecDNS: Реферал на TLD (.ru) RecDNS->>TLD: Запрос TLD TLD-->>RecDNS: Реферал на Auth DNS RecDNS->>Auth: Запрос авторитативного Auth-->>RecDNS: IP адрес (A-запись) RecDNS->>RecDNS: Кэширование ответа RecDNS-->>CorpDNS: IP адрес end CorpDNS->>CorpDNS: Кэширование ответа CorpDNS-->>Browser: IP адрес end end end Browser->>User: Загрузка сайта" %} ``` {% hint style="info" %} При установке сетевого события, EventID 5156 не логирует DNS-имя узла, куда подключение было установлено.\ А вот sysmon 3 логирует имя, при этом он берет его как раз из локального кеша.\ Поэтому редко возможны случаи, когда обращение было по IP и сопоставленное имя уже не актуально и не соответствует действительности. {% endhint %} ## NBNS, LLMNR - альтернативные протоколы разрешения имен **DNS, LLMNR, NBNS** - эти три протокола используются для преобразования имён в IP-адреса в локальных сетях, но имеют критические различия в безопасности. * **DNS** - основная система разрешения имён в сети (и интернете). * **LLMNR (Link-Local Multicast Name Resolution)** * Multicast-запрос (UDP/5355, адрес `224.0.0.252`) * **Активен по умолчанию** в Windows Vista и новее. * Используется, только если DNS не сработал. * **NBNS (NetBIOS Name Service)** * Устаревший протокол (UDP/137, Broadcast). * Включён в Windows для обратной совместимости. * Срабатывает последним, если все предыдущие методы не дали ответа. **NBNS/LLMNR** — опасные пережитки прошлого в локальных сетях. Несмотря на устаревание, эти протоколы **всё ещё включены по умолчанию** в Windows и активно используются в корпоративных сетях. **Лучшая защита**: отключить NBNS/LLMNR, усилить DNS и использовать современные методы аутентификации (Kerberos, SMBv3). ### Как атакующие используют эти протоколы 1. Жертва пытается подключиться к `\\fileserver`. 2. DNS не отвечает → срабатывает LLMNR/NBNS. Это широковещательный запрос. 3. Атакующий отвечает: "Я fileserver!". 4. Жертва отправляет NTLM-хэш злоумышленнику. Либо же это позволяет атакующему провести атаку **SMB Relay** для доступа к ресурсам без пароля. {% hint style="info" %} Часто этот механизм используется для записей WPAD. **WPAD** — протокол автоматического обнаружения прокси-сервера в сети. Позволяет компьютерам автоматически находить прокси через DNS или DHCP. **Браузеры запрашивают его автоматически**. 1. Компьютер жертвы ищет `wpad.[домен]` через DNS. Если в сети нет настоящего сервера WPAD-сервера, то отправляются широковещательные запросы LLMNR/NBNS. 2. Атакующий отвечает: "WPAD — это я!". И тем самым заставляем жертву подключиться к своему фальшивому WPAD-серверу. 3. Жертва загружает `wpad.dat` с сервера злоумышленника. 4. Прокси-скрипт перенаправляет трафик через сервер атакующего. -> Атакующий может красть пароли, перенаправлять трафик или внедрять вредоносный код. **WPAD всё ещё включён по умолчанию** в Windows 10/11 и macOS. **Защита:** синкхолинг wpad.\[domain], отключение WPAD, отключение LLMNR, NBNS. {% endhint %} **Инструменты**: * **Responder** (автоматизирует атаку). ## DGA (Domain Generation Algorithm) — алгоритм генерации доменных имен **DGA** — это механизм, используемый вредоносным ПО для динамического создания большого количества псевдослучайных доменных имен, которые могут служить точками связи с Command & Control (C\&C) серверами. Это усложняет блокировку вредоносного трафика и повышает устойчивость ботнетов. * Вредоносная программа использует алгоритм (например, на основе текущей даты, сида или хешей) для создания сотен или тысяч доменных имен в день. * Вредонос перебирает сгенерированные домены, пока не найдет активный C\&C-сервер. Антивирусы и фаерволы не успевают блокировать все варианты. Даже если 99% доменов заблокированы, 1% останется рабочим. ### Алгоритмы генерации доменов DGA может использовать различные методы генерации: * **Псевдослучайные строки** — на основе хешей (MD5, SHA), текущего времени или системных параметров. * **Словарная генерация** — комбинации реальных слов из заранее заготовленных списков. * **Гибридный подход** — сочетание слов с цифрами или символами. * **Подозрительные признаки:** * Множество запросов к случайным доменам (`asdfghjkl123.com`, `zxcvbnm789.net`). * **Всплеск NXDOMAIN-ответов** — большинство сгенерированных доменов не существуют, что создаёт аномально высокое количество ошибок "domain not found". * Короткое время жизни DNS-кэша (TTL ≈ 60 сек). {% hint style="info" %} **Не все DGA выглядят как случайный набор символов.** Современное ВПО используют словарную генерацию, чтобы обходить эвристику безопасности. Примеры доменов при словарной DGA: * `family-dolphin.net` * `sunset-crystal.com` * `urban-tiger.org` * `coffee-mountain.io` Такие домены выглядят легитимно, но при анализе выявляются паттерны: необычные комбинации слов, массовая регистрация в одном временном окне, отсутствие веб-контента. {% endhint %} ## DNS-туннелирование: скрытая передача данных через DNS-запросы **DNS-туннелирование** — это метод обхода сетевой безопасности, при котором злоумышленник кодирует данные в DNS-запросах и ответах, создавая скрытый канал связи. Это позволяет передавать информацию даже в строго контролируемых сетях, где обычный интернет-трафик заблокирован. **Злоумышленник** настраивает сервер, который: * Принимает DNS-запросы с закодированными данными (например, `secret-data.evil.com`). * Отправляет ответы, также содержащие скрытую информацию. **Жертва** (зараженное устройство) отправляет DNS-запросы к подконтрольному домену, маскируя под легитимные запросы. Данные разбиваются на части и встраиваются в поддомены: ``` 1. Исходные данные: "hello" → кодировка в Base64 → "aGVsbG8=" 2. DNS-запрос: aGVsbG8.evil.com 3. Сервер evil.com декодирует "aGVsbG8=" обратно в "hello". ``` **Зачем используют DNS-туннелирование?** | **Цель** | **Пример** | | ----------------------- | ------------------------------------------------ | | **Обход фаерволов** | В сетях, где запрещен HTTP/SSH, но разрешен DNS. | | **Кража данных** | Экфильтрация паролей, документов через DNS. | | **Управление ботнетом** | C\&C-сервер отдает команды через DNS-ответы. | ### **Как обнаружить DNS-туннелирование** * **Высокая частота запросов** (100+ запросов в минуту от одного хоста). * **Необычно длинные домены** (`gX7saB9Jk...tunnel.evil.com`). Длина домена может достигать 253 символов (включая точки) * **Нестандартные типы запросов** (TXT, NULL, MX вместо A/AAAA). {% hint style="info" %} 34% вредоносных программ используют DNS для C\&C (FireEye). {% endhint %} ## Синкхолинг домена (Domain Sinkholing) Технология получила название от англ. sinkhole — «водосточный колодец» или «воронка», так как трафик «уходит в никуда». Синкхолинг (DNS Sinkholing) — это метод, перенаправляющий запросы к вредоносным доменам на безопасный сервер («воронку»/sinkhole) вместо реального IP-адреса злоумышленника. Это предотвращает подключение устройств к ботнетам, блокирует рекламу и помогает анализировать активность вредоносного ПО, подменяя ответы DNS. Когда зараженное устройство пытается обратиться к командному серверу (C\&C), DNS-сервер возвращает поддельный, безопасный IP-адрес (Например 127.0.0.1). {% hint style="info" %} Мы, например, синкхолим домены не только в рамках реагирования на инцидент, но и превентивно LLM сгенерировала возможные варианты фишинговых доменов (с заменой букв на кириллицу, похожие по написанию или опечатки) и все эти домены принулительно резолвятся в 127.0.0.1 {% endhint %} ## Мониторинг DNS-разрешения: где собирать данные ### 1. NTA-решения (Network Traffic Analysis) **Где:** Сетевой трафик (SPAN-порт, сетевые тапы). Не зависит от настроек логирования отдельных хостов **Что видим:** * Все DNS-запросы и ответы в сети * Исходящие запросы от всех хостов * Типы записей (A, AAAA, TXT, MX и др.) Но не видно, **какой процесс** инициировал запрос и зашифрованный DNS (DoH, DoT) ограничивает видимость ### 2. Логи DNS-сервера **Где:** Windows DNS Server, BIND, Unbound и др. **Что видим:** * Все запросы, обработанные сервером в одном месте * Клиентские IP-адреса * Типы запросов и ответы, детализация. Включение подробного логирования нагружает сервер. **Не рекомендуется как основной источник** при наличии NTA. ### 3. Sysmon Event ID 22 (DNS Query) **Где:** Endpoint (каждый хост с установленным Sysmon). Нужно установить и настроить Sysmon на каждом хосте. **Что видим:** * DNS-запросы с каждого хоста * **Имя процесса**, который инициировал запрос: * Можно точно определить, какой процесс подозрительный * Понятно, вся ли активность от одного процесса или распределена * Пользователь, хост, время Sysmon логирует запрос до шифрования, то есть DoH/DoT не помогают обойти обнаружение, построенное на Sysmon EID 22. **Пример события:** ``` Event ID: 22 QueryName: evil-c2-server.com Process: C:\Users\Admin\malware.exe User: CORP\admin ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://vasilisa-l.gitbook.io/blue-team-cookbook/other/dns.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.