Защита DNS и BGP: как предотвратить подмену маршрутов и адресов

Почему DNS и BGP — главные цели атак

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

Чем опасны подмена маршрутов и адресов

Подмена DNS и BGP опасна не только для сайтов. В зоне риска: — банковские и платёжные сервисы; — почтовые системы; — корпоративные VPN и удалённый доступ; — API для мобильных приложений; — государственные и образовательные ресурсы; — DNS-инфраструктура провайдеров и CDN. Типовые последствия: — кража учётных данных через фишинговую копию сайта; — перехват сессий; — подмена обновлений и сервисных ответов; — деградация качества связи и рост задержек; — полная недоступность ресурса для части пользователей. Особенно опасна ситуация, когда атака затрагивает инфраструктуру оператора связи. Если злоумышленник перехватывает BGP-анонс префикса, за которым находится DNS-сервер провайдера, под ударом оказываются все клиенты этого провайдера — их резолверы начинают получать ответы от подконтрольного атакующему сервера. Масштаб инцидента мгновенно вырастает с одного ресурса до целой абонентской базы.

Как выглядит атака на практике

DNS-атака

Атакующий добивается того, чтобы резолвер или пользователь получил поддельный ответ. Это может произойти через: — компрометацию DNS-сервера; — подмену ответа в пути; — атаку на кеширующий резолвер; — злоупотребление уязвимостями в цепочке доверия. Если домен не защищён криптографически, клиенту сложно отличить правильный ответ от поддельного. Кеширующий резолвер, получив ложный ответ, может раздать его сотням и тысячам клиентов, пока запись не протухнет по TTL. Именно поэтому атаки на резолверы провайдеров столь эффективны — один поддельный ответ заражает кеш целого сегмента сети.

BGP-атака

Здесь атакующий объявляет в глобальную маршрутизацию чужой IP-префикс как свой. В результате: — трафик начинает идти к злоумышленнику; — маршрут становится короче или «привлекательнее» для части сетей; — сервис остаётся с тем же IP, но трафик уже уходит не туда. Это и есть классический prefix hijacking — подмена происхождения маршрута. На практике такие инциденты часто происходят не по злому умыслу, а из-за ошибок конфигурации — route leak, когда сеть случайно анонсирует чужие префиксы. Но результат для жертвы одинаков: часть интернета теряет доступ к ресурсу или начинает ходить через постороннюю сеть.

DNSSEC и RPKI: что именно они защищают

Самая частая ошибка — ждать от одной технологии решения всех проблем. Так не работает.

DNSSEC простыми словами

DNSSEC добавляет к DNS криптографическую подпись. Это значит, что резолвер может проверить, действительно ли ответ пришёл от легитимной зоны и не был изменён по дороге. Важно понимать: — DNSSEC не скрывает данные; — DNSSEC не исправляет маршрутизацию; — DNSSEC подтверждает подлинность DNS-ответа. Если трафик к DNS-серверу был перехвачен через BGP, DNSSEC всё равно помогает не принять поддельный ответ, но сам факт маршрутной атаки это не отменяет. Резолвер, настроенный на валидацию, просто увидит, что подпись не сходится, и вернёт SERVFAIL — клиент не получит ложный адрес, но и легитимный ресурс останется недоступным, пока идёт атака на маршрут.

RPKI и ROV простыми словами

RPKI привязывает IP-префиксы к тем AS, которым разрешено их объявлять. А Route Origin Validation проверяет, имеет ли сеть право анонсировать конкретный префикс. На практике это означает: — у владельца префикса есть ROA; — ROA говорит, какой AS может объявлять этот префикс; — маршрутизатор или фильтр сверяет входящий анонс с этой информацией; — если анонс невалиден, его можно отклонить. Именно RPKI/ROV — один из главных барьеров против случайных и злонамеренных BGP-хайджеков. Технология не требует глобального внедрения на всех маршрутизаторах интернета — достаточно, чтобы её использовали крупные транзитные операторы и точки обмена трафиком. Каждый новый участник RPKI повышает общий уровень доверия к глобальной таблице маршрутизации.

Что нужно внедрять в первую очередь

Если задача — снизить риск подмены маршрутов и адресов, начинать стоит не с экзотики, а с базовой дисциплины.

1. Настроить RPKI для всех своих префиксов

Что делать: — создать ROA для каждого объявляемого префикса; — указать корректный origin ASN; — задать разумную максимальную длину префикса; — регулярно проверять актуальность ROA. Типовая ошибка — забыть обновить ROA после изменения провайдера, миграции или реорганизации AS. В этом случае легитимные анонсы могут стать invalid. На практике это приводит к тому, что часть операторов, использующих ROV, просто отбрасывает ваш маршрут — и сервис становится недоступен для их клиентов. Поэтому обновление ROA должно быть частью регламента любых изменений в IP-адресации и BGP-политике.

2. Включить фильтрацию входящих маршрутов

Нельзя полагаться только на RPKI. Нужны и обычные фильтры: — prefix-list; — AS-path filters; — bogon-фильтрация; — max-prefix limits; — policy-based filtering на стыках. Это защищает от мусорных и ошибочных анонсов даже там, где RPKI ещё не помогает. Bogon-фильтрация, например, отсекает анонсы заведомо неиспользуемых или зарезервированных диапазонов — такие префиксы не должны появляться в глобальной таблице маршрутизации в принципе. А max-prefix лимиты спасают от ситуации, когда соседний AS из-за сбоя начинает высылать полную таблицу вместо согласованного набора маршрутов.

3. Проверять происхождение маршрутов у аплинков и пирингов

Сильная практика для оператора — не только защищать свои анонсы, но и проверять входящие: — какие префиксы реально должны приходить от этого соседа; — нет ли более специфичных подсетей, которых быть не должно; — нет ли неожиданного изменения пути; — не сработал ли max-prefix. Это особенно важно на точках обмена трафиком, где количество пиринговых сессий исчисляется десятками и сотнями. Один неосторожный участник с некорректной фильтрацией способен залить в таблицу маршрутизации тысячи чужих префиксов, и без контроля на принимающей стороне это превращается в каскадный инцидент.

4. Включить DNSSEC там, где это оправдано

DNSSEC нужен особенно там, где ошибка в DNS приводит к критическим последствиям: — корпоративные домены; — финансовые сервисы; — публичные порталы; — зоны, от которых зависят приложения и API. Но внедрение должно быть аккуратным: ошибки в подписании зоны или в цепочке доверия ломают резолвинг не хуже атаки. Просроченная подпись, потеря ключа, некорректная смена алгоритма — всё это приводит к тому, что домен перестаёт резолвиться для пользователей, чьи резолверы выполняют валидацию. Поэтому DNSSEC требует не просто включения, а выстроенного процесса управления ключами и подписями.

Практический чек-лист для оператора

Для BGP

— Все собственные префиксы имеют ROA. — Origin ASN в ROA совпадает с реальным. — Максимальная длина префикса задана без лишней широты. — На пограничных маршрутизаторах включена ROV-проверка. — Есть prefix-list для клиентов и аплинков. — Настроены max-prefix лимиты. — Отслеживаются резкие изменения в таблице маршрутов. — Есть контактный план на случай hijack-инцидента.

Для DNS

— Зоны, где нужна высокая целостность, подписаны DNSSEC. — У ключей и подписей есть понятный процесс ротации. — Проверена цепочка доверия от корня до домена. — Резолверы настроены на валидацию подписи. — Мониторятся сбои в DNS-ответах и аномалии TTL. — Для критичных сервисов есть резервные механизмы разрешения имён. Отдельно отмечу: резервные механизмы разрешения имён — это не роскошь, а необходимость для сервисов, простой которых стоит денег. Если основной резолвер лёг под DDoS или стал жертвой атаки на маршрут, переключение на альтернативного провайдера DNS должно происходить автоматически, а не по звонку дежурного инженера.

Как проверить, что защита реально работает

Защита должна быть не «на бумаге», а в проверяемом состоянии.

Проверка RPKI

Проверьте: — есть ли ROA на все объявляемые префиксы; — не истёк ли срок действия; — совпадает ли ASN; — не слишком ли широкая maxLength. Слишком широкая maxLength — отдельная проблема. Если вы владеете /19 и создали ROA с maxLength /24, вы фактически разрешаете кому угодно анонсировать более специфичные подсети из вашего диапазона. Злоумышленник может анонсировать /24, и поскольку ROA это разрешает, ROV пропустит такой анонс как валидный. maxLength должен быть ровно таким, какие префиксы вы реально планируете объявлять.

Проверка маршрутизации

Ищите: — неожиданные анонсы собственного префикса; — резкие изменения upstream; — появление нового origin ASN; — более специфичные маршруты, которых не должно быть. Для этого нужен мониторинг глобальной таблицы маршрутизации — свои префиксы необходимо отслеживать через BGP-мониторы и сервисы вроде RIPE RIS или Route Views. Появление нового origin ASN для вашего префикса должно триггерить алерт немедленно, а не в момент, когда пользователи начали жаловаться на недоступность.

Проверка DNSSEC

Нужно убедиться, что: — зона подписана; — цепочка доверия валидна; — резолвер действительно валидирует ответы; — клиентские сервисы не обходят защищённый резолвер «напрямую». Последний пункт часто упускают. Если часть инфраструктуры использует публичные резолверы вроде 8.8.8.8 в обход корпоративного резолвера с валидацией, весь смысл DNSSEC теряется — клиент получает ответ без проверки подписи. Аудит DNS-трафика должен выявлять такие обходные пути и закрывать их.

Типовые ошибки, из-за которых защита не работает

Ошибка 1. «У нас есть DNSSEC, значит BGP не страшен»

Неверно. DNSSEC защищает целостность DNS-данных, но не предотвращает перехват маршрута. Если трафик до DNS-сервера ушёл через злоумышленника, резолвер просто не получит ответа и вернёт ошибку — сервис станет недоступен, хотя подмены данных не произошло. Это всё ещё инцидент доступности, и для бизнеса он может быть таким же критичным, как и утечка.

Ошибка 2. «RPKI включили, больше ничего не нужно»

Тоже неверно. Без фильтров, лимитов и мониторинга операторы всё равно получают риски от ошибочных анонсов и route leak. RPKI проверяет только происхождение маршрута, но не валидирует весь путь — если легитимный сосед по ошибке анонсирует ваш префикс с корректным origin ASN, ROV пропустит такой анонс. Нужны дополнительные механизмы контроля.

Ошибка 3. «ROA сделали один раз»

Маршрутизация меняется. Переезд на другого аплинка, новый AS, новый диапазон адресов — и ROA нужно пересматривать. На практике встречаются ситуации, когда компания меняет LIR или провайдера, получает новые префиксы, а старые ROA остаются висеть и создают конфликты при валидации. Ревизия ROA должна быть частью любого проекта по изменению IP-адресации.

Ошибка 4. «DNSSEC мешает и его лучше не трогать»

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

Когда достаточно базовой защиты, а когда нужен усиленный режим

Базовый режим

Подходит для: — небольших сетей; — корпоративных сайтов; — типовых сервисов; — инфраструктуры без собственного глобального BGP. Достаточно: — DNSSEC для важных зон; — жёстких DNS-политик; — защиты у регистратора и хостинга; — мониторинга маршрутов через провайдера.

Усиленный режим

Нужен для: — операторов связи; — дата-центров; — CDN; — банков; — больших платформ; — сервисов с собственным AS и публичной маршрутизацией. Здесь уже необходимы: — RPKI; — ROV; — фильтры на стыках; — контроль peerings; — мониторинг BGP и DNS 24/7; — процедура реагирования на hijack. Граница между режимами проходит там, где организация начинает самостоятельно управлять BGP-анонсами. Как только у вас появляется собственный AS и вы входите в глобальную маршрутизацию, вы становитесь не просто потребителем, но и источником маршрутной информации — и ответственность за её корректность ложится на вас.

Пошаговый план внедрения

Шаг 1. Инвентаризация

Сначала соберите: — все собственные префиксы; — все AS, через которые идёт анонс; — все доменные зоны; — критичные DNS-сервера и резолверы. Без полной инвентаризации невозможно понять реальный объём работ. Часто в крупных организациях префиксы разбросаны по разным подразделениям, доменные зоны администрируются разными командами, а часть инфраструктуры вообще находится на аутсорсе. Пока нет единой картины, защита будет фрагментарной.

Шаг 2. Устранение разрывов

Проверьте: — где нет ROA; — где RPKI невалиден; — где нет DNSSEC; — где устарели политики фильтрации. На этом этапе часто всплывают префиксы, полученные много лет назад и никогда не проверявшиеся на наличие ROA, или домены, для которых DNSSEC был настроен, но ключи не обновлялись годами. Всё это — прямые кандидаты на инцидент.

Шаг 3. Настройка контроля

Внедрите: — автоматическую проверку валидности ROA; — alert на новый origin ASN; — alert на резкие изменения BGP-пути; — мониторинг DNSSEC-валидации. Автоматизация здесь критична. Ручная проверка раз в квартал не работает — инцидент с подменой маршрута развивается за минуты, и реагировать нужно немедленно. Система мониторинга должна не просто собирать данные, но и сопоставлять их с эталонной картиной, выявляя отклонения в реальном времени.

Шаг 4. Тестирование инцидентов

Прогоните сценарии: — ложный анонс собственного префикса; — потеря валидности ROA; — сбой подписи зоны; — недоступность резолвера; — переключение на резервный маршрут. Тестирование должно быть максимально приближено к реальным условиям. Если у вас есть тестовая среда с собственным AS, можно смоделировать hijack в изолированном окружении и проверить, как реагируют системы мониторинга и фильтрации. Если такой среды нет — хотя бы пройдите сценарии на бумаге с командой, фиксируя, кто за что отвечает и какие инструменты использует.

Шаг 5. Регламент реагирования

У команды должен быть ответ на три вопроса: — кто подтверждает инцидент; — кто отключает/блокирует ошибочный анонс; — кто обновляет ROA, записи DNS и уведомляет партнёров. Регламент без указания конкретных людей и их контактов — это просто текст. В момент инцидента команда должна знать не только что делать, но и кто именно принимает решение, у кого есть доступ к маршрутизаторам и регистраторам, и по каким каналам связи координироваться, если основные каналы тоже затронуты атакой.

Кому особенно важно разбираться в этой теме

Эта область критична для: — сетевых инженеров; — специалистов по ИБ в телеком-среде; — администраторов DNS и инфраструктуры; — архитекторов сетей; — DevOps и SRE, которые отвечают за доступность; — студентов, выбирающих направление в информационной безопасности и сетевой инженерии. Для карьеры это полезный навык потому, что он находится на стыке сетей, криптографии и эксплуатационной дисциплины. Такие специалисты нужны там, где ошибка в маршрутизации сразу превращается в простой, инцидент или утечку. В телеком-компаниях, дата-центрах и крупных корпоративных сетях понимание связки DNS и BGP — это не факультатив, а базовая компетенция, без которой невозможно обеспечить надёжность и соответствие нормативным требованиям, включая требования по СОРМ и защите персональных данных при их передаче по каналам связи.

Вывод

Защита DNS и BGP — это не одна технология, а связка мер. DNSSEC защищает целостность DNS-ответов, RPKI и ROV снижают риск подмены маршрутов, а фильтрация и мониторинг закрывают эксплуатационные ошибки. Если нужна действительно надёжная инфраструктура, нужно защищать и имя, и маршрут, и процесс управления ими. И главное — относиться к этому не как к разовой настройке, а как к непрерывному процессу, в котором изменения в сети немедленно отражаются в политиках безопасности, а мониторинг работает в режиме реального времени.

FAQ

Можно ли защитить DNS только DNSSEC?

Нет. DNSSEC защищает ответы, но не предотвращает BGP-перехват маршрута к DNS-серверу. При перехвате маршрута резолвер может просто не добраться до легитимного сервера, и DNSSEC здесь не поможет — нужна защита на уровне маршрутизации.

Что эффективнее против hijack: RPKI или BGPsec?

На практике чаще начинают с RPKI и Route Origin Validation, потому что это проще внедрить и быстрее даёт эффект. BGPsec сложнее в развёртывании, требует поддержки на всём пути маршрута и пока не получил широкого распространения. RPKI же работает уже сейчас и покрывает значительную часть глобальной таблицы маршрутизации.

Нужен ли DNSSEC обычному сайту?

Если сайт критичен, лучше да. Особенно если подмена адреса может привести к фишингу, утечке данных или репутационному ущербу. Для небольшого информационного ресурса риски ниже, но если через сайт идёт аутентификация пользователей или передаются платёжные данные, DNSSEC становится обязательным элементом защиты.

Что делать, если мой префикс уже кто-то объявил?

Нужно срочно подтвердить инцидент, связаться с аплинками и регистраторами маршрутов, проверить ROA, усилить фильтрацию и зафиксировать источник ошибки. Параллельно стоит анонсировать более специфичный префикс через легитимные каналы — это поможет вернуть трафик, пока идёт разбирательство с источником ложного анонса.

Можно ли полностью исключить подмену маршрутов?

Полностью — нет. Но можно резко снизить вероятность и сократить время обнаружения и реакции. Именно это и даёт практическую защиту. Грамотно выстроенная система из RPKI, фильтрации, мониторинга и регламентов реагирования превращает hijack из катастрофы в управляемый инцидент с предсказуемыми сроками восстановления.