Атаки на DNS и защита
Разбираем, почему ответы DNS можно подделать и что такое отравление кэша — концептуально, чтобы грамотно настроить доверенный резолвер и понять, что даёт DNSSEC.
DNS-спуфинг — подмена ответа системы доменных имён так, чтобы доменное имя разрешалось в IP-адрес, подконтрольный атакующему; частный устойчивый случай — отравление кэша резолвера, когда поддельная запись оседает в кэше и отдаётся многим клиентам.
Урок концептуальный: показываем механику на изолированном стенде (свой резолвер в виртуальной сети, лаборатории TryHackMe). Мы не подменяем чужие DNS-ответы и не перенаправляем чужих пользователей — это статьи 272/273 УК РФ. Цель — понять, как защитить резолвер и клиентов. Практика только в своей сети.
Зачем это знать защитнику
DNS — это «телефонная книга» интернета: ему доверяют все приложения, обычно не проверяя ответ. Если злоумышленник убедит резолвер, что bank.example — это его IP, он уведёт туда трафик пользователей, и они даже не заметят подмены адресной строки. Понимая, почему подделка возможна (UDP без состояния, исторически предсказуемые идентификаторы, отсутствие подписи), инженер осознанно выбирает DNSSEC и шифрованный транспорт, а аналитик SOC распознаёт отравление по аномалиям в ответах.
Как работает разрешение имён и где брешь
Клиент спрашивает у резолвера IP для имени; если ответа нет в кэше, резолвер рекурсивно опрашивает авторитативные серверы и кэширует результат на время TTL. Классический DNS ездит поверх UDP без установления соединения, а ответ сопоставляется с запросом всего по нескольким полям (16-битный Query ID, порт источника, имя, тип). Историческая суть атаки Каминского: если эти поля предсказуемы, можно успеть прислать поддельный ответ раньше настоящего — и резолвер закэширует подделку.
Наблюдать собственные запросы на своём стенде — обычная диагностика:
# Диагностика: какой ответ вернул резолвер и какой TTL
dig +noall +answer bank.example A
# Проверить, что отвечает доверенный резолвер, а не кто-то в сети
dig @1.1.1.1 example.com AПоддельный ответ должен совпасть с настоящим по нескольким полям и прийти быстрее. Современные резолверы это сильно затруднили рандомизацией (см. ниже), но протокол по-прежнему не подписывает данные — поэтому подделка остаётся возможной там, где не включён DNSSEC. Мы разбираем принцип, чтобы знать, какой защитой его закрыть.
Признаки отравления кэша
Сигналы: домен внезапно резолвится в нетипичный IP (другая страна/ASN), TTL короче обычного (чтобы подделка «прижилась» и быстро обновлялась), расхождение ответов между разными доверенными резолверами для одного имени. На стенде это видно сравнением dig к локальному и к внешнему доверенному резолверу. Для прода это задача пассивного DNS-мониторинга.
Как это работает под капотом
Резолвер хранит запись «имя → IP» в кэше как доверенный факт, не имея способа проверить её подлинность: в классическом DNS нет криптографической привязки данных к их законному владельцу. Поэтому фильтровать подделки по содержимому нельзя — поддельная A-запись по формату не отличается от настоящей. Решение — добавить криптографическую цепочку доверия к самим данным (DNSSEC) и защитить транспорт от вмешательства (шифрование канала к резолверу). Первое подтверждает, что запись подлинная; второе мешает её подменить по дороге.
Как защититься
1. DNSSEC — подпись данных DNS. DNSSEC добавляет к записям криптографические подписи (RRSIG) и цепочку доверия от корневой зоны вниз. Валидирующий резолвер проверяет подпись и отвергает неподписанный или поддельный ответ для подписанной зоны — отравление кэша подделкой становится невозможным. Проверить статус на стенде:
# Флаг ad (authenticated data) = ответ прошёл проверку DNSSEC
dig +dnssec example.com A | grep -E 'flags|RRSIG'Важно понимать границу: DNSSEC обеспечивает целостность и подлинность данных, но не их конфиденциальность — за приватность отвечает шифрованный транспорт.
2. Доверенный резолвер и шифрованный транспорт (DoH/DoT). Используйте проверенный рекурсивный резолвер и поднимайте запросы по DNS over HTTPS или DNS over TLS: канал к резолверу шифруется и аутентифицируется, поэтому ответ нельзя подменить или подсмотреть в локальной сети. Концептуально клиент настраивается на защищённый эндпоинт:
# Идея конфигурации клиента: резолвить через DoT/DoH, не plain UDP/53
DNS-over-TLS: enabled
resolver: trusted-resolver.example (порт 853, проверка сертификата)3. Усиление резолвера (если держите свой). Современные резолверы по умолчанию рандомизируют Query ID и порт источника, поддерживают расширение 0x20 (рандомный регистр имени) — всё это резко снижает шанс угадать поля и подсунуть подделку. Ограничивайте, кто может слать рекурсивные запросы (только своя сеть), и держите ПО в актуальной версии.
4. Мониторинг как постоянный контроль. Логируйте ответы резолвера, заведите алерты на резкую смену IP популярных доменов и аномально низкие TTL, сравнивайте ответы с эталоном (пассивный DNS). DNSSEC предотвращает подделку данных, шифрование закрывает транспорт, мониторинг ловит то, что прошло, — это слои в глубину.
Защита внутренней зоны и устройств, не понимающих DNSSEC
На практике защитник сталкивается с двумя оговорками, и их полезно держать в голове. Первая: DNSSEC валидирует только подписанные зоны, а внутренние корпоративные зоны (домен Active Directory, сервисные имена) обычно не подписаны и живут на своих резолверах. Их защищают другими средствами — ограничением, кто вообще может запрашивать и обновлять записи (динамические обновления только от аутентифицированных хостов), и тем же шифрованным транспортом внутри периметра. Вторая оговорка: множество устройств (IoT, старые принтеры, бытовая техника) не умеют ни DNSSEC, ни DoH/DoT и ходят простым UDP на 53-й порт. Для них рубеж переносится в сеть: на шлюзе запрещают исходящий DNS куда угодно, кроме доверенного резолвера, и блокируют попытки устройств использовать сторонние DNS-серверы. Тогда даже «глупый» гаджет получает ответы только от резолвера, которому вы доверяете, и не может быть уведён на подменный сервер. Это пример принципа «защита там, где её может обеспечить инфраструктура, если конечное устройство на неё не способно».
Почему нельзя полагаться только на «правильный» IP в ответе
Начинающие иногда думают, что проблема решается «захардкодить IP важных сервисов и не пользоваться DNS». Это плохая идея: адреса меняются, балансировка и облака раздают разные IP, и захардкоженное значение быстро устаревает, ломая доступность. Правильный путь — не отказ от DNS, а доверенный и проверяемый DNS: подписанные зоны там, где это возможно, шифрованный канал к резолверу и наблюдаемость ответов. Защита должна укреплять протокол, а не выкидывать его.
Итоги
- Классический DNS ходит по UDP без состояния и не подписывает ответы — отсюда возможность спуфинга и отравления кэша.
- Признаки: домен резолвится в нетипичный IP, аномально низкий TTL, расхождение ответов разных резолверов.
- Главная защита целостности — DNSSEC (подпись и цепочка доверия), приватность и защиту канала даёт DoH/DoT к доверенному резолверу.
- Усиление: рандомизация Query ID/порта (в современных резолверах по умолчанию), ограничение рекурсии, обновления.
- Практика — только на своём резолвере/в лаборатории. Подмена чужих DNS-ответов = ст. 272/273 УК РФ.