DDoS атака на кэширующий DNS: атака фантомными доменами

Тема в разделе "Ддос-атаки", создана пользователем admin, 22 мар 2015.

  1. Источник: http://habrahabr.ru/post/253119/

    Начиная с января месяца многие провайдеры в РФ подверглись/подвергаются атакам на 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 или прямые зоны, в которые занести домены второго уровня;
    • использовать специализированное АО или ПО для автоматического отражения атак.
     
    22 мар 2015

Поделиться этой страницей