DNS-атаки и защита

В июле 2008 года Дэн Камински показал атаку, способную отравить DNS-кеш любого резолвера за 10-20 секунд. Все крупные ISP мира согласовали единый patch и выкатили его в один день - 8 июля. Это был первый случай координированного глобального DNS-патча. До этого 16 бит Transaction ID казались надёжными. После - стало понятно: protocol-уровневая безопасность UDP-вопросов/ответов без подписей неустранима без криптографии. DNSSEC, DoH, ODoH - всё это ответы на тот июльский шок.

• **MyEtherWallet DNS hijack 2018**: атакующие отравили BGP-маршруты к Amazon Route53, перенаправили DNS-запросы на свой сервер, украли $150k в Ethereum за 2 часа.
• **Roskomnadzor DNS-блокировки**: миллионы россиян используют DoH через Cloudflare/NextDNS для обхода блокировок Telegram, LinkedIn, Twitter, конкретных сайтов.
• **Mozilla Firefox DoH 2020**: включён по умолчанию в США - корпоративные сети получили canary domain use-application-dns.net, который при NXDOMAIN отключает DoH.

DNS spoofing

DNS-запрос - это UDP-пакет на порт 53 с 16-битным Transaction ID. Резолвер ждёт первый ответ с совпадающим ID и принимает его. Атакующий, видящий запрос (или просто угадавший ID), может подсунуть фальшивый ответ - и резолвер закеширует подмену. До 2008 года 16 бит ID казались достаточными: 65 536 вариантов. Но Дэн Камински показал: при birthday attack и параллельной отправке тысяч пакетов угадывание занимает секунды. Реальная атака на резолвер крупного провайдера могла перенаправить миллионы пользователей banking-сайтов на фишинг.

DNS работает поверх UDP без подтверждения личности отправителя - любой может отправить пакет от имени authoritative-сервера. Защита 2008 года - source port randomization: вместо фиксированного порта 53 резолвер использует случайный порт ответа, добавляя ещё 16 бит энтропии (всего 32 бита). 0x20 encoding - случайный регистр доменного имени (gOoGle.cOm), сохраняющийся в ответе, ещё несколько бит.

Спуфинг через open recursive resolvers - реальный риск: атакующий не должен быть в сети жертвы, достаточно отправить рекурсивный запрос и одновременно фальшивые ответы. Все крупные публичные резолверы (8.8.8.8, 1.1.1.1) сегодня требуют 0x20 + source port randomization + DNSSEC.

Cache poisoning

Один успешный спуфинг = тысячи жертв. Резолверы агрегируют запросы: один пользователь спрашивает bank.com, ответ кешируется на TTL (типично 300-86400 секунд). Все последующие пользователи получают закешированный ответ - возможно, отравленный. Атака Камински направлена не на конечного пользователя, а на резолвер интернет-провайдера. SAD DNS (2020) обошёл source port randomization через ICMP error rate limiting: атакующий выясняет, какой порт открыт у резолвера, измеряя rate-limited ICMP ответы. Защита: DNS Cookies (RFC 7873) - дополнительный shared secret между клиентом и сервером в каждом запросе.

TTL влияет на масштаб атаки. Низкий TTL (60s) ограничивает время отравления, но увеличивает нагрузку. Высокий TTL (24h) уменьшает нагрузку, но одно успешное отравление действует сутки. NXDOMAIN poisoning: атакующий подменяет ответ на несуществующее имя - все пользователи видят фишинг при опечатке. Subdomain attack: атакующий не подделывает google.com, а добавляет в ответ NS-запись для google.com, указывающую на свой сервер.

DNSSEC

DNSSEC решает spoofing криптографически: каждый ответ подписан приватным ключом зоны (ZSK), резолвер проверяет подпись публичным ключом. Корневая зона (.) подписана KSK с известным fingerprint, опубликованным IANA. Цепочка доверия: root -> .com -> google.com. Каждая зона передаёт hash публичного ключа дочерней зоны (DS record) родителю. Если хоть одно звено цепочки сломано - валидация падает. Парадокс DNSSEC: технология готова с 1997 года, root подписан с 2010, но к 2024 году только 35% .com доменов и 90% .gov реально подписаны. Причина - сложность операционной поддержки и риск выкатить себя из интернета при ошибке ротации ключей.

Записи DNSSEC: RRSIG (подпись для resource record set), DNSKEY (публичный ключ), DS (Delegation Signer - hash дочернего DNSKEY в родительской зоне), NSEC/NSEC3 (доказательство отсутствия записи). KSK (Key Signing Key) - долгоживущий ключ, подписывает только DNSKEY. ZSK (Zone Signing Key) - короткоживущий, подписывает все остальные записи. Алгоритмы: RSA-SHA256 (8), ECDSAP256SHA256 (13 - современный).

Ротация KSK критична: 11 октября 2018 года корневой KSK был впервые поменян за всю историю интернета. Перед этим - год координации с операторами резолверов по всему миру. Если в зоне поставить новый DS у родителя без обновления подписи зоны - зона уходит в SERVFAIL на TTL родителя (до 48 часов).

DNS-over-HTTPS

DNSSEC решает authenticity ответа, но не privacy: провайдер видит, какие сайты запрашивает пользователь. DNS-over-HTTPS (DoH, RFC 8484) и DNS-over-TLS (DoT, RFC 7858) закрывают канал шифрованием. Mozilla включила DoH через Cloudflare по умолчанию в Firefox в 2020 году - провайдеры потеряли видимость DNS-трафика. Это спорное решение: DoH прячет DNS от ISP, но передаёт его одному гиганту. С другой стороны, в авторитарных странах DoH-Cloudflare - единственный способ обойти DNS-блокировки. Encrypted Client Hello (ECH) дополняет DoH - скрывает SNI, последний leakage между TLS и DNS.

DoT: TCP/853, отдельный порт - провайдер видит, что используется зашифрованный DNS. DoH: HTTPS/443, неотличим от обычного HTTPS-трафика - провайдер не знает, что это DNS. DNS-over-QUIC (DoQ, RFC 9250) - новейший вариант: 0-RTT handshake, минимальная задержка. Public resolvers с DoH/DoT: Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9. Подделка DoH-сертификата атакующим невозможна - WebPKI защищает.

Ключевые идеи

• **DNS spoofing/cache poisoning** возможны из-за UDP без аутентификации. Защита первого уровня (source port randomization, 0x20, DNS cookies) добавляет энтропию, но не криптографическую защиту.
• **Cache poisoning масштабирует атаку**: одно успешное отравление ISP-резолвера затрагивает всю клиентскую базу до истечения TTL.
• **DNSSEC** даёт authenticity через цепочку подписей от корня, но adoption медленный (35% .com) из-за операционной сложности и риска заблокировать домен ошибкой ротации.
• **DoH/DoT** дают confidentiality, но не отменяют DNSSEC - это ортогональные свойства. DoH в браузерах ломает корпоративный network-level DNS-фильтринг.

Связанные темы

DNS-безопасность пересекается с PKI и сетевыми атаками:

• PKI и сертификаты — DNSSEC использует свою цепочку доверия (root KSK), а DoH/DoT - WebPKI. CAA DNS-записи привязывают, какие CA могут выпускать сертификаты для домена
• MITM атаки — DNS spoofing - частный случай MITM. Защита та же: криптографическая аутентификация (DNSSEC, TLS) вместо доверия транспорту

Вопросы для размышления

• DNSSEC решает spoofing, но требует, чтобы каждая зона в цепочке (root, TLD, домен) была подписана. Почему только 35% .com доменов подписаны через 14 лет после готовности технологии?
• DoH прячет DNS от ISP, но отдаёт его одному провайдеру (Cloudflare). Это улучшение privacy или замена одного следящего на другого?
• Encrypted Client Hello (ECH) скрывает SNI в TLS handshake - последний DNS-related leakage. Если ECH станет дефолтом, как корпоративные сети будут защищаться от malware C2, не разрывая end-to-end TLS?

Связанные уроки

• sec-12 — Предыдущий урок по сетевой безопасности
• net-18-dns-basics — DNS-атаки строятся на уязвимостях протокола DNS
• net-20-dns-resolution — Понимание резолвинга критично для DNS-атак
• sec-14 — VPN и Zero Trust часто защищают именно от DNS-уязвимостей
• crypto-19-hash-functions — DNSSEC использует криптографические подписи