Pull to refresh

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

Reading time 5 min
Views 9.7K
    Начиная с января месяца многие провайдеры в РФ подверглись/подвергаются атакам на 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 рассмотрим сообщения, которые могут быть полезны при анализе.
client 192.168.XY.137#57717 (lie.zz85.com): query: lie.zz85.com IN A + (192.168.XY.139)
client 192.168.XY.137#57717 (lie.zz85.com): query failed (SERVFAIL) for lie.zz85.com/IN/A at query.c:7553
client 192.168.XY.11#1567: no more recursive clients: quota reached

    В листинге выше приведены 3 типа полезных событий:
  • запись «client 192.168.XY.137#57717 (lie.zz85.com): query: lie.zz85.com IN A + (192.168.XY.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 или прямые зоны, в которые занести домены второго уровня;
  • использовать специализированное АО или ПО для автоматического отражения атак.


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

Articles