В мае группа израильских исследователей сообщила о новой уязвимости 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-спуфинга, он может делегировать ее дальше — другим серверам. Этим и воспользовались ИБ-исследователи. Посмотрим, как это работает на простом примере:
Сначала злоумышленник отправляет запрос на DNS-резолвер, чтобы получить IP-адрес домена (скажем, attacker.com). При этом атакующий контролирует авторитативный сервер, отвечающий за этот домен.
Рекурсивный резолвер перенаправляет операцию DNS-серверу, контролируемому злоумышленником.
DNS-сервер атакующего отвечает рекурсивному резолверу списком NS-серверов, которым он делегирует операцию. В перечне могут содержаться несколько тысяч несуществующих поддоменов сайта жертвы (rand1.victim.com, rand2.victim.com и т.д.) без указания IP-адресов.
Поскольку приведенные в перечне NS-серверы не существуют, рекурсивный резолвер будет раз за разом отправлять запросы на авторитативный сервер жертвы, чтобы узнать их IP-адреса. Таким образом один запрос злоумышленника может привести к масштабной атаке на DNS-сервер жертвы.
Результатом атаки могут стать сбои в работе 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.
Как защититься
Если вы владелец сайта, перенесите записи для доменов на защищенный DNS-сервер — подробней о том, как это сделать, можно узнать на нашем сайте. Для администраторов DNS-серверов рекомендации следующие:
В первую очередь обновите ПО DNS-резолвера до последней версии. По мнению экспертов, NXNSAttack основана на одном из фундаментальных принципов DNS-протокола, поэтому полностью избавиться от уязвимости нельзя, но можно существенно смягчить последствия ее эксплуатации.
На системах с DNSSEC рекомендуется использовать стандарт RFC-8198. Это позволит DNS-резолверу проверять вредоносные запросы и выявлять несуществующие доменные имена без обращений к авторитативному серверу. Чтобы реализовать это, достаточно использовать проверку диапазона поддоменов через DNSSEC.
Еще одно решение — ограничить количество доменных имен, которые могут быть определены авторитативному серверу при получении делегированного DNS-запроса. Сложность этого метода заключается в том, что подобные ограничения не предусмотрены DNS-протоколом, а то есть могут привести к непредвиденным проблемам на некоторых конфигурациях серверов.
