Отравление DNS-кэша и BGP-перехват

Ваш HTTPS-сертификат валиден. Сервер настроен правильно. Но трафик вашего домена молча приходит на сервер злоумышленника — не потому что ваш код скомпрометирован, а потому что был изменён DNS или BGP. Эти атаки происходят на инфраструктурном уровне, ниже вашего приложения.

Отравление DNS-кэша: атака Камински (2008). Злоумышленник вне пути (без возможности прослушивать трафик) может подделывать DNS-ответы, опережая ответ настоящего nameserver’а. ID DNS-транзакций составляют всего 16 бит — 65 536 возможных значений. Если злоумышленник может отправлять поддельные ответы достаточно быстро, он может угадать ID транзакции и отравить кэш резолвера. Отравленная запись перенаправляет все будущие запросы на этот домен на IP злоумышленника.

Дэн Камински (2008) показал, что это практично даже с быстрым резолвером: отправляя запросы на случайные поддомены (a1b2.example.com, xyz9.example.com) злоумышленник вызывает множество промахов кэша и получает много попыток угадывания в секунду. После отравления кэш отдаёт IP злоумышленника всем пользователям резолвера — не только одному запросу.

Защиты от отравления DNS-кэша.

Рандомизация исходного порта: Резолвер использует случайный UDP-порт источника для каждого запроса, а не фиксированный. Это повышает энтропию с 16 бит (только ID транзакции) до 32 бит (ID транзакции + порт), делая перебор в 65 536 раз сложнее. Современные резолверы включают это по умолчанию.

Кодирование 0x20: Рандомизировать регистр букв доменного имени в запросе — ExAmPlE.cOm — и проверять, что ответ совпадает с тем же регистром. DNS нечувствителен к регистру при поиске, но легитимный резолвер возвращает в ответе регистр из запроса. Злоумышленник, не видящий исходящего запроса, не знает регистр. Принятие: менее 0.4% глобально (по состоянию на 2026 год).

DNSSEC: Криптографически подписывает каждый RRset (набор DNS-записей) на уровне зоны. Резолвер проверяет подписи перед кэшированием. Поддельный ответ без правильной подписи отклоняется. Корневая зона, TLD и многие домены второго уровня подписаны DNSSEC. Принятие: корень и TLD покрыты; принятие на уровне второго домена неравномерное.

BGP-перехват и утечки маршрутов. BGP (Border Gateway Protocol) — это то, как автономные системы (AS) анонсируют IP-блоки друг другу через Интернет. AS может анонсировать префикс, которым не владеет — намеренно (перехват) или по ошибке конфигурации (утечка маршрута). Когда ложный анонс распространяется, трафик к перехваченному префиксу перенаправляется к анонсирующей AS.

Пример BGP-перехвата: Pakistan Telecom (AS17557) случайно анонсировал префиксы YouTube (208.65.153.0/24) в 2008 году. Анонс распространился глобально; трафик YouTube маршрутизировался в Пакистан, вызвав 2-часовой сбой для глобальных пользователей.

RPKI: инфраструктура открытых ключей ресурсов. Владельцы ресурсов публикуют Route Origin Authorizations (ROA) в публичной криптографически подписанной базе данных. ROA говорит «AS 64512 авторизована анонсировать префикс 192.0.2.0/24.» Маршрутизаторы, применяющие ROV (Route Origin Validation), отклоняют BGP-анонсы от несанкционированных AS.

По состоянию на 2026 год: ~54% IPv4 и IPv6 префиксов имеют опубликованные ROA, но только ~25% сетей применяют ROV. ROA без применения ROV бесполезна — она маркирует правильный маршрут, но не предотвращает распространение неправильного.

BGPsec и MANRS. BGPsec криптографически подписывает AS-путь в BGP-анонсах, предотвращая манипуляции с путём. Накладные расходы на CPU значительны; принятие минимально. MANRS (Mutually Agreed Norms for Routing Security) — промышленная коалиция, где ~71% подписантов берут обязательства по четырём практикам: внедрять фильтры префиксов, применять ROV, вести записи AS-WHOIS и уведомлять партнёров о перехватах. MANRS не имеет механизма принуждения — это нормативное давление, а не техническое.

Инъекция TCP RST и RFC 5961. Злоумышленник, способный вставлять пакеты (MITM на пути), может подделать TCP RST с номером последовательности в окне приёма, чтобы разорвать установленное соединение. Меры защиты RFC 5961: challenge-ACK (если номер RST-последовательности в окне, но не точный, ответить ACK ожидаемого следующего байта вместо закрытия; вынуждает злоумышленника угадать точно) и ограничение частоты ACK (ограничить challenge-ACK до ~10 в 5 секунд для предотвращения утечки информации). Защищает только от злоумышленников вне пути; MITM на пути требует IPsec или TLS.