Статья взята у Blogerator.ru.
Продолжение большого разговора про особенно сильную разновидность DDoS-атаки через «» (DNS Amplification DDoS, ещё её иногда называют DNS reflect attack). Рекомендую сначала обязательно проштудировать этой статьи, чтобы добросовестно понять устройство самой атаки, в противном случае многие советы-объяснения по борьбе с ней ниже рискуют остаться не правильно понятыми.
Окей, после порции необходимой теории — переходим к практической части по борьбе с паразитным транзитным DNS-трафиком, который и даёт возможность генерировать «усиливающий эффект» данного вида весьма опасного DDoS, в котором каждый из нас невольно может стать соучастником.
Содержание
DNS на профилактике
В этом месте есть смысл немного остановиться, чтобы осмыслить всё сказанное выше на голых цифрах. Так, согласно исследованиям компании Nominum, в сети было обнаружено как минимум 10 миллионов DNS-серверов настроенных в режиме «».
Осознав всю серьёзность ситуации, давайте для начала попробуем перечислить типичные симптомы в работе DNS, которые сигнализируют о его негласном использовании в качестве одного из ретрансляторов паразитного трафика в рамках атаки по схеме DAD:
- Резкое преобладание у DNS-сервера UDP-трафика перед обычным TCP-трафиком.
- Большое количество запросов к NS-серверу вида «.» (зона «точка»), как вариант иногда встречаются однобуквенные домены (чем короче имя домена, тем короче сам запрос и выше ответный коэффициент усиления). При этом такие оптимизированные пакеты-запросы будут заметно меньшими, чем обычные.
- Обратные IP-адреса источников запросов, которые лежат за пределами вашей локальной сети (как правило, это всегда один и тот же IP-адрес жертвы).
- Огромный исходящий трафик от вашего DNS-сервера, при этом все пакеты-ответы в большинстве случаев — одинакового размера, что очень хорошо видно в лог-файле.
- Десятки (для кого-то даже и сотни) тысяч запросов от одного клиента (подсети) в течение часа.
В последнее время начинают получать распространение так называемые «ленивые ботнеты», состоящие, как правило, из большого количества особей (от ста тысяч до миллиона голов), которые монотонно «долбят» с очень низкой интенсивностью (например, один пакет в 3 минуты).
Учитывая их чудовищное количество, жертва всё равно задыхается от тяжести суммарной нагрузки, тогда как сам «зомби» при такой стратегии не только никак не выдаёт себя на зараженном хосте, но и существенно затрудняет своё детектирование на атакуемой стороне.
Именно поэтому администратору лучше не полагаться лишь на какие-то внешние симптомы паразитной активности, а сосредоточиться на изначально правильной настройке DNS-сервера
Поскольку объективно (или усиления) атаки типа через ваш сервер имен не всегда просто (некоторые распространенные решения и патчи почти всегда обладают нежелательными побочными эффектами), я приведу наиболее сбалансированной настройки от авторитетной организации 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 для операций с запросами.
Опять же, по возможности старайтесь использовать последние и самые мощные средства для контроля трафика в BIND, например новый «брандмауэр для DNS» — (DNS Response Policy Zone).
Инструменты для проверки и контроля DNS
В заключение остановимся и на специализированных инструментах для тестирования DNS-сервисов, которые не только позволят проверить правильность всех вышеописанных настроек, но и смогут наладить перманентный контроль над работой подведомственного вам DNS-сервера.
- Организация SANS предоставила простейший для проверки любого DNS на самую банальную его уязвимость, позволяющую получать тот самый «эффект усиления». Кроме того, она же распространяет типовой шаблон конфигурации для и .
- Для самостоятельного проведения расширенного пентеста своей DNS-системы можно рекомендовать написанную на Java утилиту — ().
- — это похожий хакерский скрипт, который позволяет выуживать дополнительную информацию о чужих сетях непосредственно из DNS их обслуживающих. В этом плане бывает очень полезно посмотреть на свою сеть со стороны (желательно сделать это перед тем, как это сделают злоумышленники). В качестве примера работы скрипта, по сгенерирована вся топология субдоменов для mail.ru.
- — это хорошо известный отладчик для тонкой настройки DNS. Как и предыдущий скрипт, он также написан на Perl, для его работы нужны дополнительно два модуля:
Net::DNSиPerl IO. Следует подчеркнуть, чтоREADMEиз поставки самой программы несколько устарел и в некоторых пунктах вводит в заблуждение (например, dnswalk в последней версии не использует dig, как это утверждается в упомянутом документе). С одной стороны этот сервисный скрипт позволяет удобно получать практически любую техническую информацию о DNS, с другой — для работы с ним требуется глубокое понимание устройства DNS. Кроме того, имеется написанный на его основе , который дополнительно поддерживает работу с DNSSEC. - Другой удобный инструмент для отладки из этой же серии — , — он написан на чистом C и поддерживает все самые последние стандарты (IP4/IP6/TSIG/DNSSEC). Отдельно обращаю внимание на замечательную утилиту
drillиз состава этого пакета, которая является расширенным аналогом dig, но с поддержкой DNSSEC. Всего в пакете ldns поставляется около 15 DNS-утилит что называется «на все случаи жизни». - — Perl-скрипт предназначенный для стресс-тестирования DNS-серверов. Дополнительно используется для обнаружения скрытых субдоменов методом перебора, поиска требуемых хостов в неких диапазонах IP-адресов и так далее. Выше в рекомендациях по правильной настройке уже озвучивалась необходимость ограничения количества DNS-запросов от внешних хостов в единицу времени (в разумных пределах) — dns-grind может использоваться для проверки этих и подобных ограничений. Для своей работы требует следующие модули:
Net::DNS, Socket, IO::Handle, IO::Select, Getopt::Std. - Для контроля структуры и содержания DNS-трафика весьма удобна утилита , которая является аналогом tcpdump для DNS. Она по типам запросов, адресам источников и назначения пакетов, кодами ответов и запросов, списки доменов, которые запрашиваются через DNS-сервис. Из технических моментов стоит лишь отметить, что она поддерживает IPv4/IPv6 и использует библиотеку libpcap.
- Очень полезный демон поддерживается компанией Google. Он динамически фильтрует весь проходящий трафик, защищая подопечный DNS-сервер от попыток (DNS rebinding attack), выполняемых с помощью популярного в хакерской среде инструмента . Это позволяет безопасно эксплуатировать DNS-сервер в его штатном рекурсивном режиме.
- Более общая утилита — . Она предназначена для мониторинга и контроля за паразитным трафиком проходящим через ваш DNS, при этом может работать в двух режимах: как демон (все сервисные сообщения отправляются через syslog), так и в роли «обвязки», когда все статистические данные в режиме реального времени доступны через командную строку. Для работы требуется библиотека
libpcap.
Краткое резюме
В рамках этой обзорной статьи из двух частей мы рассмотрели лишь только некоторые, отдельные варианты и последствия некорректных настроек DNS-серверов на примере широко распространенного вида DDoS-атак (в рамках которой вы можете стать как жертвой, так и невольным соучастников её проведения). Также подчеркивается опасность бесконтрольного обмена DNS-трафиком с внешним миром на примере возможностей инкапсулирующих протоколов типа «».
Я постарался не только обратить внимание на эти не самые популярные у администраторов темы, но и также предложить базовые рекомендации и инструменты для устранения этих распространенных в реальной жизни проблем.
