Источник: 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.
На сетях провайдеров данная атака проводилась с использованием следующих доменов второго уровня:
Вот примеры некоторых запросов к этим доменам:
Как диагностировать
Существует несколько возможностей, как прямых, так и косвенных, проанализировать и определить то, что Ваш DNS сервер подвергся атаке:
Наиболее правильным и простым (если у нас нет систем защиты DNS) является анализ лог-файлов. На примере bind рассмотрим сообщения, которые могут быть полезны при анализе.
В листинге выше приведены 3 типа полезных событий:
При наличии записанного трафика дополнительную информацию по атакам можно получить используя инструмент «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 инфраструктуру, помимо 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.
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 .
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- запись «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 или прямые зоны, в которые занести домены второго уровня;
- использовать специализированное АО или ПО для автоматического отражения атак.