Случайные и фантомные домены (random subdomain, phantom domain), DDoS атака на кэширующий DNS

    Начиная с января месяца многие провайдеры в РФ подверглись/подвергаются атакам на DNS инфраструктуру, помимо Amplification/Reflection атаки активно использовалась/используется атака Random subdomain/Phantom Domain (атака случайными или фантомными доменами). Информация по атакам была получена мной от нескольких провайдеров в европейской части России и в западной Сибири (крупные региональные и московские провайдеры). При этом кто-то просто подтверждал наличие подобных проблем, а кто-то предоставлял записанный трафик к серверу DNS для анализа (ниже я расскажу о том, как проводился анализ). Про Amplification/Reflection атаки написано достаточно много, поэтому остановимся только на атаке  случайными/фантомными доменами.

Случайные и фантомные домены

    Суть атаки заключается в том, что кэширующий DNS сервер получает большое количество запросов на домены третьего и/или четвертого уровня, при этом DNS серверы, которые обслуживают зону второго уровня, не отвечают или отвечают с большой задержкой. Могут использоваться как специально подготовленные DNS-зоны/серверы, так и DNS-серверы находящиеся под атакой NXDOMAIN, и в этом случае наш кэширующий DNS  также участвует в атаке. По умолчанию в bind настроено максимальное количество исходящих рекурсивных запросов: 1000 (параметр recursive-clients) и время ожидания 10 секунд (параметр resolver-query-timeout). Таким образом, всего лишь постоянная нагрузка 100 запросов в секунду к подобным доменам позволит полностью заблокировать исходящие соединения DNS-сервера, что приведет к устареванию кэша и частичному отказу в обслуживании. Увеличение количества запросов может полностью заблокировать работу кэширующего DNS. 
    На сетях провайдеров данная атака проводилась с использованием следующих доменов второго уровня:

  • ludashi123.com, ludashi12345.com, ludashi258.com, ludashi360.com,  ludashi456.com, ludashi789.com;
  • 8333hh.com, 8777hh.com, 9111hh.com, 9222hh.com, 9333hh.com, 9555hh.com, 9666hh.com, 9777hh.com, 9888hh.com;  
  • 115seo.com. 

    Вот примеры некоторых запросов к этим доменам: 

  • cvrwuco.www.9555hh.com;
  • fqtwikq.www.9666hh.com;
  • epwvczehmdmxepwx.www.9777hh.com;
  • yrad.list.115seo.co;
  • xnhrw.www.ludashi789.com;
  • g.www.ludashi456.com .

Как диагностировать

    Существует несколько возможностей, как прямых, так и косвенных, проанализировать и определить то, что Ваш DNS сервер подвергся атаке:

  • Самое простое и самое неправильное – положиться на пользователей и ждать, пока они не выявят проблему (правда, часть пользователей может отключиться :);
  • Косвенный признак плохой работы DNS – снижение пользовательского трафика;
  • Система мониторинга может отслеживать правильность преобразования наиболее популярных DNS-имен с минимальным TTL. Например, TTL для A-записи www.facebook.com составляет всего 60 секунд;
  • Анализировать лог-файлы и статистику работы DNS;
  • Периодически записывать трафик к/от DNS-сервера и анализировать запросы/ответы (в автоматическом режиме);
  • Использовать автоматические системы защиты сервера DNS.

   Наиболее правильным и простым (если у нас нет систем защиты DNS) является анализ лог-файлов. На примере bind рассмотрим сообщения, которые могут быть полезны при анализе. 

     В листинге выше приведены 3 типа полезных событий:

  • запись “client 192.168.42.137#57717 (lie.zz85.com): query: lie.zz85.com IN A + (192.168.42.139)” сообщает нам, какой пользователь (192.168.XY.137) и с какого порта (57717) запросил домен lie.zz85.com;
  • запись “client 192.168.XY.137#57717 (lie.zz85.com): query failed (SERVFAIL) for lie.zz85.com/IN/A at query.c:7553” сообщает, что DNS-сервер не смог разрешить DNS-имя и передал клиенту SERVFAIL;
  • запись “client 192.168.XY.11#1567: no more recursive clients: quota reached” сообщает, что пользователю 192.168.XY.11 было отказано в доступе, так как сервер достиг максимально возможное количество рекурсивных сессий. То есть атака достигла результата, и Ваш DNS перестал обслуживать легитимных клиентов.

    При наличии записанного трафика дополнительную информацию по атакам можно получить используя инструмент “Statistics/DNS” в Wireshark (параметры rcode/Server Failure, Query Type/Unknow packet type и Class/Unknown).

    Я проводил анализ записанного трафика на устройстве Infoblox Advanced DNS Protection (реализован функционал защиты DNS от атак) и DNS Firewall (проверка DNS-запросов по списку вредоносных сайтов и IP-адресов). Проверка трафика производилась достаточно просто с помощью tcprewrite и tcpreplay, пакеты отправлялись на устройство Infoblox. Для подобной проверки в одном случае было достаточно всего 13 секунд (при нагрузке около 30 тысяч DNS-запросов в секунду). Помимо атак, основанных на случайных и фантомных доменах, были зафиксированы: амплификация, аномалии протоколов (см. выше про Wireshark), TCP/UDP флуд, попытки отравления кэша (возможно, не до конца был почищен трафик) и DNS туннели.
    Дополнительно было обнаружено:

  • клиенты, которые атаковали DNS, также обращались к вредоносным доменам/IP, зафиксированным в DNS Firewall;
  • атакующие запросы приходили с небольшого количества портов.

Методы противодействия атаке

    Можно предложить следующие методы противодействия атаке случайными/фантомными доменами:

  • увеличить максимальное количество рекурсивных сессий – поможет только в том случае, если сейчас установлено очень низкое значение, и на сервере хватает памяти(bind для каждой рекурсивной сессии использует около 20Кб памяти);
  • установить параметры для отслеживания и блокирования не отвечающих доменов на уровне DNS (для bind: clients-per-query, max-clients-per-query) – поможет, только если часть доменов/запросов повторяется;
  • настроить response rate limit – поможет при большом количестве запросов с нескольких адресов;
  • отсекать атакующие запросы на firewall, либо по имени домена (iptables это умеет), либо по паре IP-адрес/порт; 
  • создать RPZ или прямые зоны, в которые занести домены второго уровня;
  • использовать специализированное АО или ПО для автоматического отражения атак.

(с) Vadim Pavlov
PS Пока у меня есть доступ к тестовому оборудованию Infoblox ADP. Если Вы запишите и предоставите трафик мне, то я смогу его прогнать на предмет атак. Протестировать трафик на предмет обращения к вредоносным сайтам (DNS Firewall) вы можете сами (подключив устройство к span-порт или прогнав записанный трафик). Скачать пакет DNS Firewall можно тут (требуется регистрация; устанавливается на VmWare ESXi и требуется vCenter).