DNS Amplification DDoS: Анатомия атаки и защиты. Часть 2

Автор: | 03/01/2013
Нет комментариев
 

Статья взята у Blogerator.ru.

Продолжение большого разговора про особенно сильную разновидность DDoS-атаки через «DNS-отражение и усиление пакетов» (DNS Amplification DDoS, ещё её иногда называют DNS reflect attack). Рекомендую сначала обязательно проштудировать первую часть этой статьи, чтобы добросовестно понять устройство самой атаки, в противном случае многие советы-объяснения по борьбе с ней ниже рискуют остаться не правильно понятыми.

Окей, после порции необходимой теории в первой части — переходим к практической части по борьбе с паразитным транзитным DNS-трафиком, который и даёт возможность генерировать «усиливающий эффект» данного вида весьма опасного DDoS, в котором каждый из нас невольно может стать соучастником.

 

анонимус анонимусы маска Anonimous anonymous

 

DNS на профилактике

В этом месте есть смысл немного остановиться, чтобы осмыслить всё сказанное выше на голых цифрах. Так, согласно исследованиям компании Nominum, в сети было обнаружено как минимум 10 миллионов DNS-серверов настроенных в режиме «open resolver».

Из них около 2 миллионов позволяют выполнять рекурсивные запросы через себя вообще любому желающему. В среднем, 71% всех дистанционно исследованных этой компанией публичных DNS-серверов имеют те или иные ошибки в настройках, при этом нужно учесть, что автоматически проверялись лишь наиболее базовые и распространенные проблемы такого рода. Глядя на эту статистику становится очевидным то, что сейчас в сети труднее найти правильно настроенный DNS, нежели чем уязвимый.

Осознав всю серьёзность ситуации, давайте для начала попробуем перечислить типичные симптомы в работе DNS, которые сигнализируют о его негласном использовании в качестве одного из ретрансляторов паразитного трафика в рамках атаки по схеме DAD:

  1. Резкое преобладание у DNS-сервера UDP-трафика перед обычным TCP-трафиком.
  2. Большое количество запросов к NS-серверу вида «.» (зона «точка»), как вариант иногда встречаются однобуквенные домены (чем короче имя домена, тем короче сам запрос и выше ответный коэффициент усиления). При этом такие оптимизированные пакеты-запросы будут заметно меньшими, чем обычные.
  3. Обратные IP-адреса источников запросов, которые лежат за пределами вашей локальной сети (как правило, это всегда один и тот же IP-адрес жертвы).
  4. Огромный исходящий трафик от вашего DNS-сервера, при этом все пакеты-ответы в большинстве случаев — одинакового размера, что очень хорошо видно в лог-файле.
  5. Десятки (для кого-то даже и сотни) тысяч запросов от одного клиента (подсети) в течение часа.

В последнее время начинают получать распространение так называемые «ленивые ботнеты», состоящие, как правило, из большого количества особей (от ста тысяч до миллиона голов), которые монотонно «долбят» с очень низкой интенсивностью (например, один пакет в 3 минуты).

 

ДДОС DDOS матрица шутка прикол демотиватор нео анонимус анонимусы маска Anonimous anonymous

 

Учитывая их чудовищное количество, жертва всё равно задыхается от тяжести суммарной нагрузки, тогда как сам «зомби» при такой стратегии не только никак не выдаёт себя на зараженном хосте, но и существенно затрудняет своё детектирование на атакуемой стороне.

Именно поэтому администратору лучше не полагаться лишь на какие-то внешние симптомы паразитной активности, а сосредоточиться на изначально правильной настройке DNS-сервера

Поскольку объективно бороться с возможностью ретрансляции (или усиления) атаки типа DNS Amplification через ваш сервер имен не всегда просто (некоторые распространенные решения и патчи почти всегда обладают нежелательными побочными эффектами), я приведу здесь вариант наиболее сбалансированной настройки от авторитетной организации CCIRC на примере BIND:

1. В файл /etc/hosts.conf добавляем новую строку, с целью противодействия спуфингу:

nospoof on

2. Дальше открываем файл /etc/named.conf для отключения рекурсии на сервере:

Options {
...
recursion no;
...}

Теперь будут приниматься только итеративные запросы. При необходимости в качестве более гибкого решения можно воспользоваться опцией allow-recursion , которая определяет список заведомо доверенных хостов, запросы от которых разрешено обрабатывать рекурсивно.

Кроме того, через настройки параметра views можно избирательно разрешать рекурсию для внутренних и внешних адресов.

3. Помещаем в этот же файл следующие строчки:

additional-from-auth no;
additional-from-cache no;

4. Далее, ещё больше усиливаем противодействие спуфингу:

use-id-pool yes;

Эта опция включает режим, в котором идентификаторы DNS-запросов выбираются случайным образом.

5. Отключаем fetch-glue :

fetch-glue no;

Этим мы запрещаем дополнительный поиск IP-адресов DNS-серверов.

6. Запретите динамические обновления зон следующим способом:

zone «example.com»
{
type master;
file «db.example.com»;
allow-update {
localhost;
key allowed-updater.;
};
};

В качестве компромисса можно разрешить обновления только с жестко заданных IP-адресов или защищенных списком валидных TSIG-ключей.

7. Кроме того здесь же убедитесь в том, что вы отключили уведомления и перенос доменных зон на ваш сервер для всех желающих, перечислив в блоке ACL список доверенных серверов, этим вы обезопасите себя от некоторых потенциальных махинаций:

acl «trusted» {
11.22.33.44;
55.66.77.99;
};
allow-notify { trusted; };
allow-transfer { trusted; };

8. По возможности в настройках лучше всегда использовать новые, более мощные механизмы — например расширение DNSSEC для обеспечения большей безопасности и возможностей DNS-сервера.

В качестве варианта для прошлого примера (трансфер зоны) можно использовать TSIG, вот пример подобной конфигурации:

key tsig-signing. {
algorithm hmac-md5;
secret “ff3d7REQwDAE8Aedae56345==”;
};
zone “example.com” {
type master;
file “db.example.com”;
allow-transfer { key tsig-signing; };
};

9. Обязательно выполняйте предварительную фильтрацию DNS-трафика, для этого в таблице ниже собраны все типовые случаи. Обратите внимание на номера портов — распространенное заблуждение гласит, что запросы DNS передаются через 53/UDP, а трансфер зон — через 53/TCP. Это лишь «полуправда»: 53/TCP может также применяться и для «длинных запросов», а в версиях BIND 8/9 активно используются порты выше 1023 для операций с запросами.

сервис настройка DNS ДНС порты трафик безопасность anonymous

Опять же, по возможности старайтесь использовать последние и самые мощные средства для контроля трафика в BIND, например новый «брандмауэр для DNS» — DNSRPZ (DNS Response Policy Zone).

Инструменты для проверки и контроля DNS

В заключение остановимся и на специализированных инструментах для тестирования DNS-сервисов, которые не только позволят проверить правильность всех вышеописанных настроек, но и смогут наладить перманентный контроль над работой подведомственного вам DNS-сервера.

  1. Организация SANS предоставила простейший онлайн-тест для проверки любого DNS на самую банальную его уязвимость, позволяющую получать тот самый «эффект усиления». Кроме того, она же распространяет типовой шаблон конфигурации для безопасной настройки BIND и Microsoft DNS.
  2. Для самостоятельного проведения расширенного пентеста своей DNS-системы можно рекомендовать написанную на Java утилиту — DNSpenTest (аналог).
  3. fierce.pl — это похожий хакерский скрипт, который позволяет выуживать дополнительную информацию о чужих сетях непосредственно из DNS их обслуживающих. В этом плане бывает очень полезно посмотреть на свою сеть со стороны (желательно сделать это перед тем, как это сделают злоумышленники). В качестве примера работы скрипта, по этому адресу сгенерирована вся топология субдоменов для mail.ru.
  4. dnswalk — это хорошо известный отладчик для тонкой настройки DNS. Как и предыдущий скрипт, он также написан на Perl, для его работы нужны дополнительно два модуля: Net::DNS и Perl IO . Следует подчеркнуть, что README из поставки самой программы несколько устарел и в некоторых пунктах вводит в заблуждение (например, dnswalk в последней версии не использует dig, как это утверждается в упомянутом документе). С одной стороны этот сервисный скрипт позволяет удобно получать практически любую техническую информацию о DNS, с другой — для работы с ним требуется глубокое понимание устройства DNS. Кроме того, имеется написанный на его основе DNSSEC Walker, который дополнительно поддерживает работу с DNSSEC.
  5. Другой удобный инструмент для отладки из этой же серии — ldns, — он написан на чистом C и поддерживает все самые последние стандарты (IP4/IP6/TSIG/DNSSEC). Отдельно обращаю внимание на замечательную утилиту drill из состава этого пакета, которая является расширенным аналогом dig, но с поддержкой DNSSEC. Всего в пакете ldns поставляется около 15 DNS-утилит что называется «на все случаи жизни».
  6. dns-grind — Perl-скрипт предназначенный для стресс-тестирования DNS-серверов. Дополнительно используется для обнаружения скрытых субдоменов методом перебора, поиска требуемых хостов в неких диапазонах IP-адресов и так далее. Выше в рекомендациях по правильной настройке уже озвучивалась необходимость ограничения количества DNS-запросов от внешних хостов в единицу времени (в разумных пределах) — dns-grind может использоваться для проверки этих и подобных ограничений. Для своей работы требует следующие модули: Net::DNS, Socket, IO::Handle, IO::Select, Getopt::Std .
  7. Для контроля структуры и содержания DNS-трафика весьма удобна утилита dnstop, которая является аналогом tcpdump для DNS. Она генерирует статистические таблицы по типам запросов, адресам источников и назначения пакетов, кодами ответов и запросов, списки доменов, которые запрашиваются через DNS-сервис. Из технических моментов стоит лишь отметить, что она поддерживает IPv4/IPv6 и использует библиотеку libpcap.
  8. Очень полезный демон dnswall поддерживается компанией Google. Он динамически фильтрует весь проходящий трафик, защищая подопечный DNS-сервер от попыток rebind-атак (DNS rebinding attack), выполняемых с помощью популярного в хакерской среде инструмента Rebind. Это позволяет безопасно эксплуатировать DNS-сервер в его штатном рекурсивном режиме.
  9. Более общая утилита — DNS Flood Detector. Она предназначена для мониторинга и контроля за паразитным трафиком проходящим через ваш DNS, при этом может работать в двух режимах: как демон (все сервисные сообщения отправляются через syslog), так и в роли «обвязки», когда все статистические данные в режиме реального времени доступны через командную строку. Для работы требуется библиотека libpcap .

Краткое резюме

В рамках этой обзорной статьи из двух частей мы рассмотрели лишь только некоторые, отдельные варианты и последствия некорректных настроек DNS-серверов на примере широко распространенного вида DDoS-атак (в рамках которой вы можете стать как жертвой, так и невольным соучастников её проведения). Также подчеркивается опасность бесконтрольного обмена DNS-трафиком с внешним миром на примере возможностей инкапсулирующих протоколов типа «IP через DNS».

Я постарался не только обратить внимание на эти не самые популярные у администраторов темы, но и также предложить базовые рекомендации и инструменты для устранения этих распространенных в реальной жизни проблем.

Игорь Савчук ©  Системный Администратор, 2012