DNS-спуфинг

При DNS-спуфинге атакующий воздействует на этот процесс кэширования. Он отправляет поддельный DNS-ответ на сервер-резолвер (например, DNS-сервер интернет-провайдера или корпоративной сети) раньше, чем придёт ответ от легитимного авторитетного DNS-сервера. Если поддельный ответ принимается как валидный, подставная запись сохраняется в кэше. Все последующие запросы к этому домену, поступающие от клиентов через «отравленный» резолвер, будут получать ложный IP-адрес.

Подробный сценарий атаки

1. Инициирование запроса: Пользователь (жертва) вводит в браузере доменное имя, например, bank.example.
2. Запрос к резолверу: Компьютер пользователя отправляет DNS-запрос к локальному DNS-резолверу (обычно предоставляемому провайдером).
3. Перехват или опережение: Атакующий, контролирующий канал связи или находящийся в той же сети (например, через поддельную точку доступа Wi-Fi), перехватывает этот запрос. В более сложных сценариях атакующий может сам инициировать запрос к резолверу от имени легитимного сервера.
4. Подмена ответа: Злоумышленник отправляет резолверу поддельный DNS-ответ, в котором домену bank.example сопоставляется IP-адрес его собственного сервера (например, 192.0.2.100). Этот ответ часто содержит поддельные идентификаторы транзакции (TXID) и информацию об авторитетных серверах, чтобы резолвер принял его за настоящий.
5. Отравление кэша: Резолвер, не имея возможности отличить подделку от реального ответа (если атака технически успешна), сохраняет ложную запись в свой кэш.
6. Перенаправление жертвы: Когда резолвер отвечает пользователю, тот получает IP-адрес 192.0.2.100. Браузер пользователя подключается к этому адресу, где атакующий разместил точную копию сайта bank.example. Пользователь вводит свои логин и пароль, которые попадают к злоумышленнику.

Классификация методов DNS-спуфинга

Существует несколько основных техник, используемых для проведения атаки:

Атака на кэш резолвера (DNS Cache Poisoning)

Это классический метод, описанный выше. Злоумышленник нацеливается на DNS-сервер, обслуживающий множество клиентов. Успешная атака позволяет перенаправлять всех пользователей этого сервера на подставные сайты.

Локальный спуфинг (ARP-спуфинг + DNS-спуфинг)

Атакующий, находясь в одной локальной сети (например, в общественном Wi-Fi), сначала проводит ARP-спуфинг (отравление ARP-таблиц), чтобы стать «человеком посередине» (Man-in-the-Middle, MITM) между жертвой и шлюзом сети. После этого он перехватывает DNS-запросы жертвы и подменяет ответы на лету, не затрагивая кэш самого резолвера. Этот метод проще в реализации, но требует физического присутствия в сети жертвы.

Атака на клиент (Hosts file poisoning)

Злоумышленник, получив доступ к операционной системе жертвы (например, через вредоносное ПО), может изменить локальный файл hosts (в Windows — C:\Windows\System32\drivers\etc\hosts, в Linux — /etc/hosts). Этот файл имеет приоритет над DNS-запросами. Внеся в него поддельную запись, атакующий гарантирует, что браузер жертвы всегда будет обращаться к ложному IP-адресу для указанного домена, независимо от состояния кэша DNS-сервера.

Атака на авторитетный DNS-сервер (Domain Hijacking)

Наиболее сложный, но и наиболее разрушительный метод. Атакующий пытается скомпрометировать сам авторитетный DNS-сервер, обслуживающий домен (например, через кражу учётных данных панели управления доменом или эксплуатацию уязвимости в ПО DNS-сервера). В этом случае подмена происходит на самом верхнем уровне, и все резолверы, запрашивающие этот домен, получают ложные данные напрямую от источника.

История и известные инциденты

• 1997 год: Юджин Касперски (Eugene Kaspersky) в своих публикациях описывал теоретические основы отравления DNS-кэша.
• 2005 год: Исследователь Майкл Линн (Michael Lynn) на конференции Black Hat продемонстрировал уязвимость в DNS-серверах Cisco, позволяющую проводить спуфинг.
• 2008 год: Дэн Камински (Dan Kaminsky) обнаружил фундаментальную уязвимость в протоколе DNS, затрагивающую большинство DNS-серверов в мире. Уязвимость позволяла относительно легко отравлять кэш, подделывая идентификаторы транзакций (TXID). Это открытие привело к массовому обновлению DNS-серверов и внедрению дополнительных мер безопасности (рандомизация TXID и портов).
• 2010 год: Китайские хакеры, по данным расследования, использовали DNS-спуфинг для перенаправления трафика пользователей Gmail и других сервисов Google на подставные серверы с целью кражи паролей.
• 2014 год: Инцидент с DNS-спуфингом в Иране, когда пользователи ряда зарубежных сервисов (включая Google и Twitter) были перенаправлены на подставные страницы, предположительно, в рамках государственной цензуры.
• 2018 год: Атака на криптовалютную биржу MyEtherWallet, когда злоумышленники с помощью BGP-угонов (BGP hijacking) и DNS-спуфинга перенаправили пользователей на фишинговый сайт и похитили криптовалюту на сумму около 17 миллионов долларов.

Защита от DNS-спуфинга

Для предотвращения атак применяется комплекс мер на разных уровнях сетевой инфраструктуры:

На уровне DNS-серверов

• DNSSEC (Domain Name System Security Extensions): Наиболее эффективная защита. DNSSEC использует криптографические цифровые подписи для аутентификации DNS-ответов. Резолвер, поддерживающий DNSSEC, может проверить, что ответ действительно пришёл от авторитетного сервера и не был изменён. Внедрение DNSSEC требует настройки как на стороне владельца домена, так и на стороне резолвера.
• Рандомизация портов и TXID: Современные DNS-серверы (BIND, Unbound, PowerDNS) используют случайные номера портов и идентификаторы транзакций для каждого запроса, что значительно усложняет подделку ответа.
• Ограничение рекурсии: DNS-серверы следует настраивать так, чтобы они принимали рекурсивные запросы только от доверенных клиентов (например, из своей сети), а не от любых узлов в интернете.

На уровне пользователя и сети

• Использование DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT): Эти протоколы шифруют DNS-запросы и ответы, делая их нечитаемыми для перехватчика. Это предотвращает локальный спуфинг (MITM) и подмену на промежуточных узлах. DoH и DoT поддерживаются современными браузерами и операционными системами.
• Проверка HTTPS-сертификатов: Если пользователь попадает на подставной сайт, браузер, скорее всего, выдаст предупреждение о недействительности SSL/TLS-сертификата (если атакующий не использует валидный сертификат, что сложно). Игнорирование таких предупреждений повышает риск.
• Антивирусное ПО и брандмауэр: Современные антивирусные решения могут блокировать попытки изменения файла hosts и перехвата DNS-запросов вредоносным ПО.
• Использование VPN: Виртуальная частная сеть (VPN) шифрует весь трафик, включая DNS-запросы, и передаёт их на удалённый DNS-сервер, защищённый от локального перехвата.

Правовые аспекты в Российской Федерации

В Российской Федерации DNS-спуфинг, как и другие виды несанкционированного доступа к компьютерной информации и её модификации, является уголовно наказуемым деянием. В зависимости от последствий (крупный ущерб, корыстная заинтересованность, создание угрозы жизни и здоровью) действия злоумышленника могут квалифицироваться по статьям:

• Статья 272 УК РФ («Неправомерный доступ к компьютерной информации»).
• Статья 273 УК РФ («Создание, использование и распространение вредоносных компьютерных программ»).
• Статья 159 УК РФ («Мошенничество»), если атака привела к хищению средств или данных.
• Статья 138 УК РФ («Нарушение тайны переписки, телефонных переговоров, почтовых, телеграфных или иных сообщений»), если атака осуществлялась с перехватом трафика.

Организации, признанные в РФ экстремистскими или нежелательными, а также иностранные агенты, могут использовать DNS-спуфинг для обхода блокировок или распространения дезинформации, что является отдельным нарушением законодательства.

Источники

• RFC 3833 — Threat Analysis of the Domain Name System (DNS)
• RFC 4033, 4034, 4035 — DNS Security Extensions (DNSSEC)
• Kaminsky, D. (2008). Black Ops 2008: It’s The End Of The Cache As We Know It. Black Hat USA.
• Уголовный кодекс Российской Федерации (статьи 272, 273, 159, 138)
• Материалы расследований инцидентов безопасности (SANS Institute, Kaspersky Lab, Group-IB)