В мае группа израильских исследователей сообщила о новой уязвимости DNS-серверов, которую можно использовать для усиления DDoS-атак. Авторы утверждают, что при атаке с помощью DNS-резолверов коэффициент амплификации пакетов (PAF – packet amplification factor) достигает 1621, а пропускной способности (BAF – bandwidth amplification factor) — 163. Уязвимыми оказались все DNS-серверы с поддержкой рекурсивной обработки запросов, в т.ч. публичные Amazon, Google, Cloudflare, ICANN и Quad9. Мы разобрались, как осуществляется атака и как ей противостоять.

Во всем виноваты резолверы

DNS-службы, как известно, нужны для получения данных о доменах, в том числе для преобразования доменов в IP-адреса. Но, согласно отчету израильских ИБ-исследователей, DNS-резолверы можно использовать и для усиления DDoS-атаки на атакуемый сервер. На каждый отправленный запрос они позволяют отправить на сервер жертвы до 1621 пакета и увеличить количество трафика в 163 раза. В таблице приведена подробная информация о степени влияния трех вариантов атаки (a, b и c) на рекурсивный резолвер и DNS-сервер BIND 9.12.3:

Как устроена NXNSAttack

В ходе исследования израильским специалистам удалось превратить единственный DNS-запрос, отправленный резолверу, в полноценную DDoS-атаку. Для этого они эксплуатировали механизм делегирования операции по выявлению IP-адреса домена. Обычно запрос на выполнение этой задачи DNS-сервер получает от рекурсивного резолвера, но в некоторых случаях, например, в целях защиты от DNS-спуфинга, он может делегировать ее дальше — другим серверам. Этим и воспользовались ИБ-исследователи. Посмотрим, как это работает на простом примере:

  1. Сначала злоумышленник отправляет запрос на DNS-резолвер, чтобы получить IP-адрес домена (скажем, attacker.com). При этом атакующий контролирует авторитативный сервер, отвечающий за этот домен.

  2. Рекурсивный резолвер перенаправляет операцию DNS-серверу, контролируемому злоумышленником.

  3. DNS-сервер атакующего отвечает рекурсивному резолверу списком NS-серверов, которым он делегирует операцию. В перечне могут содержаться несколько тысяч несуществующих поддоменов сайта жертвы (rand1.victim.com, rand2.victim.com и т.д.) без указания IP-адресов.

  4. Поскольку приведенные в перечне NS-серверы не существуют, рекурсивный резолвер будет раз за разом отправлять запросы на авторитативный сервер жертвы, чтобы узнать их IP-адреса. Таким образом один запрос злоумышленника может привести к масштабной атаке на DNS-сервер жертвы.

Механизм атаки NXNSAttack Источник: nic.cz
Механизм атаки NXNSAttack Источник: nic.cz

Результатом атаки могут стать сбои в работе DNS-сервера жертвы, после отключения которого пользователи не смогут попасть на сайт victim.com, т.к. резолвиться это доменное имя уже не будет.

Кто уязвим

Уже почти никто. По большей части разработчики DNS-серверов давно выпустили патчи и поделились рекомендациями о том, как значительно снизить коэффициент амплификации. Официальная информация от компаний собрана ниже:

DNS-сервер

Состояние

Amazon

Исправлено

Cloudflare

Исправлено

ICANN

Исправлено

ISC BIND

Рекомендации / Уязвимость CVE-2020-8616

Google.com

Исправлено

Microsoft

Рекомендации

NIC.CZ Knot Resolver

Информация / Уязвимость CVE-2020-12667

NLnet Labs Unbound

Уязвимость CVE-2020-12662

Oracle (DYN)

Исправлено

PowerDNS

Уязвимость CVE-2020-10995

Quad9

Исправлено

Verisign

Исправлено

Интересно, что для разных служб коэффициент амплификации может отличаться в десятки раз. Если для Google он составил лишь 30, то для Comodo Secure — 435, а для Norton ConnectSafe — уже все 569.

PAF — максимальный коэффициент амплификации пакетов Источник: NXNSAttack Paper
PAF — максимальный коэффициент амплификации пакетов Источник: NXNSAttack Paper

Как защититься

Если вы владелец сайта, перенесите записи для доменов на защищенный DNS-сервер — подробней о том, как это сделать, можно узнать на нашем сайте. Для администраторов DNS-серверов рекомендации следующие:

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

  • На системах с DNSSEC рекомендуется использовать стандарт RFC-8198. Это позволит DNS-резолверу проверять вредоносные запросы и выявлять несуществующие доменные имена без обращений к авторитативному серверу. Чтобы реализовать это, достаточно использовать проверку диапазона поддоменов через DNSSEC.

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