Открытый рекурсивный DNS-сервер. Часть 2

Практически 4 месяца назад я открыл свой рекурсивный DNS-сервер для всех пользователей интернет (см. предыдущую статью). Накопленный объем данных на первом этапе теста был достаточно большим, для его визуализации я загнал данные в БД и построил динамические изменяющиеся графики и карту. Записанное видео можно посмотреть под катом. Результат получился достаточно интересным, поэтому полностью закрывать DNS-сервер я не стал, а ограничился включением зон (используемых для атак) в списки RPZ (что такое RPZ можно прочитать в этой статье). «Расслабившись» на «небольших» атаках (не более 100 запросов в секунду), я не заблокировал ответы по двум DNS-зонам и получил первый abuse-репорт. Abuse-репорт был отправлен в дата-центр моего провайдера от «робота». Нагрузка на его сеть с моего сервера была небольшой и периодически доходила до 100 запросов в секунду. С учетом того, что могли использоваться миллионы открытых ресолверов, то максимальная нагрузка на его сеть могла быть значительной. Abuse-репорт и замотивировал меня перейти к второй части теста. Отключив открытый рекурсивный DNS и продолжил наблюдать за поведением атакующих.

Визуализация атаки описанной в первой статье:

Описание тестовой среды

При написании прошлой статьи все данные собирались и обрабатывались практически в ручном режиме. Это было долго, нудно и результаты иногда приходилось перепроверять. Так как я достаточно ленив, мне нравится автоматизировать процессы и анализировать данные, то самим собой напросился вывод создать небольшую систему отчетности и анализа поступающих логов с DNS-сервера в режиме близкому к real time (если это интересно, то могу описать в отдельной статье). Все графики и таблицы, использованные в данной статье, были сгенерированы с использованием jqPlot, jqGrid и сервиса Google Maps. В качестве DNS-сервера я использую виртуальное устройство Infoblox, но формат syslog-сообщений у него аналогичен bind.

Атаки

За время проведения тестирования мой сервер использовался для проведения DrDoS атак (Amplification + Reflection), а так же были произведены попытки осуществить отравление кэша. По некоторым запросам было видно, что используется механизм DGA (Domain Generation Algorithm) возможно для отравления кэша, возможно для связи с управляющими центрами (так как эти домены использовались только для атак) или при атаке с фантомными доменами.

После отключения рекурсивного сервера паразитная нагрузка снизилась, но не исчезла совсем.

Пиковая нагрузка на «открытом» сервере доходила до 3 тысяч запросов в секунду и в среднем держалась около 100 запросов в секунду, на закрытом сервере максимальная нагрузка снизилась до 20 запросов в секунду с редкими пиками до 100 запросов (rate limit настроен до 300 запросов в минуту с возможностью роста до 1000).

Как видно на графике ниже, от действий злоумышленников больше всего пострадали компании в США.

Анализ количества отправленных запросов в сеть каждой компании может косвенно помочь определить жертвы и возможные зараженные сети. Например, сеть China Telecom скорее всего заражена, а клиент Ростелекома был атакован. В таблице ниже приведена информация организациям, количеству IP-адресов и количеству обработанных запросов. Данные о компаниях были получены с помощью сервиса whois.

Атака DrDOS

Для атаки были использованы домены приведенные в таблице ниже. Домен freeinfosys.com появился уже после «закрытия» рекурсивного сервера. Что может означать, что кто-то использует устаревшие базы, которые редко проверяются.
    Чтобы определить, что ваш сервер атакуется или используется для проведения атак достаточно проанализировать к каким доменам и как часто обращались с запросом «ANY +E».

При использовании «ANY +E» запрашивается вся информация по зоне и активируется функционал EDNS, чтобы получить максимально возможный размер UDP пакета. Список 10 наиболее частых запросов и их флагов приведен в таблице ниже.

Cache Poisoning, Random domain attack и DGA

В процессе работы DNS сервера были выявлено небольшое количество атак на отравление кэша. В статистике работы DNS-сервер Infoblox было указано, что были получены ответы с неправильными портами и query ID, но, к сожалению, log-файлы для анализа не сохранились.

Помимо этого были обнаружены подозрительные запросы вида:

• ndnaplaaaaeml0000dgaaabbaaabgnli.energystar.gov;
• mmokojaaaaeml0000dgaaabbaaabgclm.doleta.gov;
• oaanjeaaaaesc0000deaaabbaaabicoc.webpanel.sk;
• cnklipaaaaesh0000claaabbaaabfgoa;
• 2d852aba-7d5f-11e4-b763-d89d67232680.ipvm.biz.

Вполне возможно, что эти записи частично относятся к выявленным попыткам отравления кэша, попытке провести атаку с использованием фантомных доменов (авторитативный сервер не отвечает и таким образом забивается пул исходящих соединений) или работе «неведомых зверушек» (вредоносное ПО) пытающихся связаться с управляющим центром.

Выводы

• Любой DNS-сервер это замечательный источник информации о поведении простых пользователей и вредоносного ПО;
• Анализ логов поможет повысить качество работы DNS;
• Большое кол-во запросов «ANY +E» показывает, что Ваш сервер находится или участвует в атаке;
• Для проведения DrDOS атак вредоносное ПО использовало небольшое количество доменов (не более 3х-4х одновременно);
• Блокировка таких подозрительных доменов (например на RPZ) позволит снизить нагрузку на сервер и сеть;
• Слишком длинные DNS-имена (как в примере выше) являются поводом к пристальному изучению поведения клиента (заражен хост или кто-то использует DNS-тунели).

Автор: Homas

Источник