Dns amplification что это
Предотвращаем участие в dns amplification attack или опыт написания ядерного кода
Введение
В этой статье я хочу рассказать о достаточно очевидном, как мне кажется, способе фильтрации dns amplification attack, и о небольшом модуле, который был написан для реализации идеи.
О том, что такое dns amplification attack, писалось уже не раз, например здесь; многие с этим сталкивались, многие боролись, кто-то более успешно, кто-то менее. Атака строится на отправке DNS запроса к какому либо DNS серверу с подставленным ip адресом источника, равным ip адресу жертвы. Ответ от DNS сервера практически всегда больше, чем запрос, особенно учитывая, что атакующим обычно выполняется ANY запрос. AAAA записи — уже не редкость, SPF и другая информация в TXT записях, все это позволяет достаточно легко получить усиление в 5 и даже более раз. Для атакующего это выглядит очень заманчиво, можно устроить хороший dos, даже не имея большого ботнета. Можно очень долго рассуждать, почему возможен спуфинг ip адресов в Интернете, но реалии таковы, что он все еще возможен, поэтому на сегодняшний день задача затруднить использование своих DNS серверов в проведении подобных атак представляется весьма актуальной. Замечу также, что в данной атаке возможно использовать как авторитативные dns сервера, так и публичные резольверы; предлагаемое решение тоже может использоваться в обоих случаях.
Основные методы борьбы, применимые на dns серверах:
Заблокируем неугодных.
Попросим на TCP.
Заголовок DNS пакета имеет поле TC флага. Если TC флаг установлен, то клиент должен повторить запрос с использованием TCP, причем все остальные данные ответа игнорируются. Идея данного метода в том, что атакующий не будет переключаться на TCP, для него это не имеет смысла, в то время как честный клиент переключится и получит ответ по TCP. Конечно, TCP для DNS — это медленнее, но, во-первых, ответ должен осесть в кеше рекурсора или клиента, во-вторых, некоторая латентность в данном случае — это меньшее зло. Данный подход уже реализован в некоторых dns серверах: так, в powerdns можно выставить tc флаг для ответов на ANY запросы, что уже является хорошим компромиссом. Но данный вариант также не идеален. Дело в том, что в большом Интернете все еще есть сервера, не совсем следующие RFC или просто неверно настроенные, и, просто выставив TC для всех ответов, никто не даёт гарантии, что все корректно переспросят ответ по TCP. Также не стоит забывать, что, выставив tc флаг, мы, конечно, снизим количество исходящего трафика и следовательно нагрузку на сетевое оборудование, но вот сами сервера все так же будут обрабатывать этот гигантский входящий поток запросов, тратя драгоценные переключения контекста и грея дата-центры.
Как это работает?
Считаем количество пришедших пакетов с каждого ip адреса в заданный период времени. Если количество пришедших пакетов с определенного ip превысило порог, то формируем UDP ответ с TC флагом и отбрасываем запрос. Таким образом мы резко снижаем количество переключений контекста, вызванного необходимостью обработки этого трафика приложением DNS сервера. Легитимный клиент, получив по udp ответ с tc флагом, будет вынужден повторить запрос по TCP, и данный трафик уже достигнет dns сервера.
Для эффективной реализации нам очень поможет тот факт, что формат заголовка для dns запроса и ответа одинаков, более того, заголовок — это единственная необходимая часть пакета для того, чтобы dns ответ считался корректным. Посмотрим на dns заголовок подробнее: 
Еще одна хорошая новость: dns заголовок имеет фиксированный размер 12 байт. Получается очень простая схема, нам даже не надо полностью парсить dns заголовок. Проверяем, что в пришедшем на 53 UDP порт пакете присутствуют данные размером больше 12 байт, копируем первые 12 байт данных (пока писал, появилась мысль, что, возможно, следует дополнительно проверить остальные поля заголовка) из запроса в новый пакет, выставляем ему TC бит и бит ответа, и отправляем его обратно. Поскольку мы скопировали только заголовок, то желательно также обнулить поле QDCOUNT, в противном случае получим предупреждения парсера на клиентской стороне. Сам же запрос после этого удаляем. Всю эту работу можно провести прямо в NF_INET_LOCAL_IN хуке, в этом же хуке мы должны поместить ip источника в KFIFO очередь для дальнейшего обсчета статистики. Статистику приходящих пакетов будем считать асинхронно, в отдельном потоке, используя красно-черные деревья. Таким образом, мы вносим минимальную задержку в прохождение пакета — KFIFO является lock free структурой данных, к тому же очередь создается на каждый cpu. Правда, тут возникает необходимость конфигурировать интервал в зависимости от ожидаемого pps. Еще есть ограничение на размер памяти, выделяемой для per cpu данных: сейчас оно составляет 32kB, с учетом чего создаётся очередь размером 4096 ip адреса на каждый cpu. Таким образом, выбрав интервал в 100ms, получим возможность обсчитывать до 40960 pps на каждый cpu, что в большинстве случаев представляется достаточным. С другой стороны, переполнение очереди приведет просто к потере части данных для подсчета статистики.
Возникает закономерный вопрос: почему просто не использовать хеш?
К сожалению, неаккуратное использование хешей в таких местах открывает возможность для другого типа атак — атак, нацеленных на вызов коллизий: зная, что в каком-то критичном ко времени исполнения участке кода используется хеш, можно подобрать такие данные, что операция с ними на хеш таблице будет происходить уже за O(n) вместо O(1). Такие атаки неприятны еще и тем, что выявить их бывает достаточно сложно — внешне вроде ничего не произошло, а серверу стало плохо.
Если же pps с заблокированого ip стало меньше порогового значения, то блокировка снимается. Есть возможность сконфигурировать гистерезис, равный по умолчанию 10% от порогового значения.
В конце статьи приведена ссылка на проект; любые конструктивные замечания, пожелания и дополнения приветствуются.
Пример использования
После загрузки модуля в
cat /proc/net/kfdns
можно найти статистику по ip, попавшим под фильтрацию.
Результаты тестирования
Для создания паразитной нагрузки использовался dnsperf (в двух экземплярах, один на соседней виртуальной машине, второй на ноутбуке, и к сожалению этого было даже недостаточно, чтобы загрузить систему до отказа), dns сервер был поднят в виртуальной машине KVM под управлением CentOS, в качестве самого dns сервера использовался pdns-recursor.
На графиках показаны значения счетчиков до активации модуля, после активации, и снова с выгруженным модулем. PPS во время всего эксперимента был на уровне 80kpps.
Итак, произошло то, чего мы добивались — сокращение исходящего трафика. Видно, что после включения модуля исходящий трафик стал даже меньше входящего,
что в принципе логично: не будем забывать, что мы копируем только заголовок.
Резкое уменьшение количества переключений контекста — хорошо.
А вот что при этом происходило с системой: видно заметное сокращение потребления system time, user time. Изменения steal time в данном случае — это влияние виртуализации, что тоже логично. А вот едва заметное увеличение irq time — это интересно и может быть поводом для дальнейших экспериментов.
Что хочется добавить в будущем?
Пока проект находится в достаточно молодом состоянии, но надеюсь, что в Хабрасообществе найдутся заинтересованные люди, и, возможно, кому-то он будет полезен.
Blogerator.org
Эксклюзивные ИТ-новости, обзоры и интервью
DNS Amplification DDoS: Анатомия атаки и защиты. Часть 1
Сегодня у нас первая часть большой статьи про устройство ныне печально известной DDoS-атаки через отражение (DNS Amplification). Конечная цель статьи — показать, как можно эффективно бороться с паразитным DNS-трафиком (смотрите вторую часть), для чего сначала рассмотрим основы в первой части статьи, где исследуем механизмы и глубинное устройство этой атаки.
Когда-то давным-давно, в те далекие времена, когда все в Интернете доверяли друг другу, когда было нормальным отвечать на любой сторонний запрос по сети — «нет проблем, пожалуйста, можешь пользоваться моим сервисом, если тебе это нужно», — была задумана и спроектирована замечательная интернет-служба — DNS. Она позволяет приводить в соответствие человеко-понятные доменные адреса в их компьютерно-числовую форму и наоборот.
В отличие от других интернет-сервисов DNS является своего рода связующим хребтом для всего Интернета: мало кто задумывается, что сервис разрешения имен косвенно используется фактически во всех других службах и протоколах. Сегодня же реальность такова, что DNS нашел своё применение и в других, в том числе и криминальных целях. Поэтому предлагаю рассмотреть теорию правильной настройки этой службы на практическом примере противодействия генерированию паразитного трафика для распространенной атаки — DNS Amplification DDoS (DAD).
Вызовы сегодняшнего дня
В феврале месяце 2012 года известная хакерская группа Anonymous объявила миру о готовящейся сетевой акции под названием Global Blackout. Она была запланирована на 31 марта, именно в этот день хакеры планировали вывести из строя все 13 корневых DNS-серверов Интернета. Для осуществления этой атаки на базе инструмента AntiSec DHN ими была написана специальная программа «Reflective DNS Amplification», которая, как ожидается, будет запущена сочувствующими в указанный «час X» на десятках тысячах компьютеров по всему миру. Технический смысл сего действия — проведение мощнейшей DDoS-атаки по уже обкатанной схеме, получившей устоявшееся название — «DNS Amplification».
С одной стороны можно вспомнить множество масштабных атак уже вошедших в историю, в том числе выполненных против корневых DNS-серверы с помощью именно этой техники. Несмотря даже на выход из строя нескольких корневых серверов в тех отдельных случаях, ещё никогда не удавалось достичь прекращения работы сразу всех root-серверов. С другой стороны DAD — это именно тот тип атаки, который прочно удерживает неоспоримое лидерство среди наиболее мощных DDoS-атак, проведенных в истории Интернета.
Каждый новый год, атаки этой разновидности берут все новые, ранее казавшиеся фантастическими высоты по мощности генерируемой ими «волны» трафика.
Что же это за дьявольский механизм, который поднимает в виртуальном пространстве цунами такой мощности и разрушительности?
Общая схема работы DNS
Чтобы следовать дальше, давайте предварительно в справочных целях рассмотрим общий алгоритм работы DNS (смотрите план-схему ниже).
Конечно, это лишь примерная схема работы DNS (в данном случае её стандартный рекурсивный вариант), в реальной жизни всё может работать с некоторыми отличиями в зависимости от особенностей настройки каждого конкретного сервера. Если вам что-то не ясно, более подробно о механике DNS можно почитать вот здесь или тута.
Внимательно изучив эту стандартную последовательность, мы готовы перейти к рассмотрению уязвимостей и некоторых слабых мест этой схемы на примере сегодняшней DDoS-атаки.
Динамика работы DNS Amplification
Интересной особенностью именно DAD является то, что здесь, в общем случае, даже не нужно наличие ботнета. Для успешной атаки достаточно самому «сидеть» на относительно быстром канале, после чего использовать эффект «усиления атаки» через описанную ниже DNS-схему.
Ситуация драматически меняется, если совместную игру начинают «организованные преступные группировки» из десятков тысяч (или как в описанном выше случае — миллионов) зомбированных компьютеров со всего мира.
Давайте рассмотрим схему того, как это работает (см. графический алгоритм чуть выше):
Чтобы в многообразии деталей этой многоступенчатой схемы не потерять суть атаки, предлагаю отдельно выделить три ключевых момента, которые делают принципиально возможной реализацию данного сверхэффективного варианта DDoS:
Ботнет — это большая распределенная система, где на первый план всё чаще выходит надежный механизм обратной связи, который позволил бы держать постоянную связь с управляющей головой ботнета (говоря на сленге ботостроителей — с «папой»). Времена использования для отправки управляющих команд классического IRC-канала— ушли в прошлое. Для донесения кодированных посланий теперь чаще всего применяются сервисы типа Twitter (см. рис.3) или p2p-сети. Недостаток такого подхода в том, что современные «ортодоксальные» администраторы часто сосредоточены на фильтрации этих традиционных протоколов (главным образом http), но в большинстве случаев совершенно упускают из вида нестандартные подходы. Например, возможность тунелирования TCP/IP-трафика через стандартные DNS-запросы в целях внешнего управления ботами или троянами сидящими внутри корпоративных сетей.
Именно поэтому это направление получило всплеск такой популярности в последнее время. Для этого существуют удобные шелл-коды, которые по этому же принципу пробрасывают внутрь подобной «защищенной» локальной сети свою консоль управления, чаще всего используя для этого DNS-запросы типа TXT. В этой связи стоит также напомнить о dnscat (эта известная утилита часто упоминается как самостоятельный инструмент, но это лишь часть пакета DNS-утилит nbtools ), созданная специально для этих целей, а также о не менеe известном в узких кругах протоколе NSTX (IP over DNS — NameServer Transfer Protocol). В случае с NSTX решение получается достаточно надежное, максимальный размеры пакетов которые здесь можно передать —512 байт по UDP, которые затем «глубоко в тылу» собираются в полноценные IP-пакеты. Более новый, но аналогичный по идее инструмент — Heyoka, — кроме тунелинга TCP/IP трафика также выполняет спуфинг адресов-источников запросов для самомаскировки. OpenSource-природа этих решений приводит к тому, что принципиальные кодовые части упомянутых программ для тунелирования сегодня обнаруживаются в «личинках» самых разных ботнетов. В частности популярный для Windows пакет Iodine, который в российских условиях часто используется для незаконного «добывания интернета» абонентом, ранее отключенным провайдером за неуплату (DNS, как правило, при этом остаётся рабочим), применяется в коде одной из разновидностей ботнета Gheg. Другая подобная система OzymanDNS — популярна у «специалистов» для надежного проброса своего SSH через служебный DNS-трафик перед самым носом даже у самых строгих сисадминов. Более подробно про DNS-тунелинг у меня можно почитать вот здесь.
В такой схеме единственный минус (который именно для случая ботов не так существенен): DNS-клиент (зомби) может связываться с «папой» только сам и в одностороннем порядке. Статистика собранная при наблюдении подобных «пчелиных улеев» показывает, что «пробив» у подобной схемы чрезвычайно высок, — чаще всего зомби с обратной связью на основе DNS-тунелинга надежно управляются даже из самых глубоких недр тщательно «зафильтрованной» корпоративной сети.
Окончание этой статьи (её вторую часть) — читайте здесь, там мы рассмотрим уже практическую часть борьбы с такого рода интернет-угрозами.
DNS Amplification (DNS усиление)
Начало
Пару недель назад я заметил странную активность, направленную на мой DNS-сервер. Сразу скажу, что использую шлюз на Linux, соответственно там установлен DNS-сервер bind. Активность заключалась в том, что на порт 53 (DNS) моего сервера сыпалось по несколько UDP пакетов в секунду с различных IP-адресов:
10:41:42.163334 IP 89.149.221.182.52264 > MY_IP.53: 22912+ NS?. (17)
10:41:42.163807 IP MY_IP.53 > 89.149.221.182.52264: 22912 Refused- 0/0/0 (17)
На что, как видно из лога, сервер отвечал отказами. Естественно мне стало интересно, что за IP-адреса долбят мой DNS. Посмотрев несколько адресов через whois я определил, что это крупные хостинговые компании, я написал просьбу прекратить атаку на мой сервер в техподдержку некоторых из них. В ответ я получил отписку, что этот тип атаки относится к тем, что они не могут блокировать, и что они сами они страдают от этой аномальной активности. Было решено со всем разбираться самому.
DNS Amplification (DNS усиление). Теория
Практика
Наиболее эффективен этот тип атаки на старом (непропатченном) или неправильно сконфигурированном DNS-сервере, который, как уже было сказано, отвечает на короткие запросы злоумышленников большими по размеру пакетами.
Вот пример такого взаимодействия (кстати именно такие запросы чаще всего используют атакующие):
Отправляем серверу NS запрос командой
#dig @SERVER_IP NS
где SERVER_IP — IP-адрес сервера. В результате в логе по 53 порту сервера получаем:
11:08:47.994604 IP MY_IP.47816 > SERVER_IP.53: 5655+ NS?. (17)
т.е. как раз те 17 байт запроса, что мы хотели послать.
В ответ в то же самом логе видим:
11:08:47.995853 IP 192.168.100.254.53 > 192.168.100.100.47816: 5655 13/0/6 NS C.ROOT-SERVERS.NET.,[|domain]
т.е. сервер ответил нам подсказкой в виде адресов корневых DNS-серверов, что составляет уже 360 байт. Это длины DNS запроса и ответа, общая же длина пакетов 60 и 402 байта соответственно. Усиление налицо.
Что делать?
Во-первых конечно же проверить актуальность версии вашего DNS-сервера вне зависимости от того, на какой платформе он работает. Во-вторых, убедиться, что настроен сервер достаточно безопасно и не отвечает на «левые» запросы всем подряд. Об этом в сети можно найти множество мануалов и рекомендаций, упомяну здесь только об одном документе, который нашел не так давно.
Что еще можно сделать?
Модуль String
Закрыть 53 порт (DNS) полностью я конечно же не мог — у меня много клиентов которым он нужен. Я решил фильтровать пакеты по содержимому DNS-запросов и убирать те из них, которые содержат запросы атакующих, а они все как один содержали в себе «NS». Для этой задачи подходит модуль iptables string, который как раз позволяет заглянуть в содержимое пакетов.
Для того, чтобы понять что фильтровать, посмотрим на пакет атакующего через wireshark.
Здесь и здесь можно почитать о структуре UDP пакетов и формате кадра DNS соответственно. Для краткости скажу, что первые 14 байт пакета занимают данные протокола Ethernet (на рис. красным), затем идут 20 байт заголовка протокола IP (на рис. синим), затем 8 байт — заголовок UDP (на рис. зеленым), после которого начинаются данные протокола DNS (на рис. желтым). Первые 12 байт кадра DNS занимает заголовок, после которого, наконец, начинается поле DNS Query (т.е. непосредственно сам запрос, на рис. оранжевым). В пакетах, присылаемых атакующим начиная с 54-ого (14+20+8+12) байта идут следующие данные: 00 00 02 00 01 (в шестнадцатеричном коде), что соответствует запросу «NS», о котором я говорил раньше. Таким образом нужно выделить пакеты, которые начиная с 54 байта содержат эти байты. Это будет выглядеть так:
Модуль Recent
На этом уже можно было бы остановиться. Пакеты уже не будут доходить до bind, но меня еще не утешала мысль, что я закрыл для ВСЕХ возможность обращаться с запросами NS к моему DNS-серверу, поэтому я решил задействовать еще один модуль iptables — recent.
Этот модуль позволяет создавать динамические таблицы IP-адресов в зависимости от определенных условий, а затем устанавливать разрешающие и запрещающие правила для этих таблиц.
Рассмотрим простой пример использования recent, состоящий из двух строк:
После добавления этих правил в /proc/net/xt_recent моего сервера появился файл DNST, в котором начали записываться IP-адреса атакующих. А DNS-сервер перестал поддаваться на провокации:
14:10:19.011818 IP 89.149.221.182.40320 > MY_IP.53: 23508+ NS?. (17)
14:10:25.243499 IP 89.149.221.182.64984 > MY_IP.53: 25306+ NS?. (17)
14:11:08.832827 IP 89.149.221.182.15864 > MY_IP.53: 48029+ NS?. (17)
14:11:15.063058 IP 89.149.221.182.30959 > MY_IP.53: 64444+ NS?. (17)
Через несколько дней работы правил количество пакетов со стороны атакующих снизилось в несколько раз. Сейчас я получаю 2-3 пакета в минуту, которые тут же отбрасываются фаерволом.
UPD: В последнем блоке кода поторопился и написал ошибку, уже исправил, спасибо, что заметили
DDoS, в поисках силы
Думаю, многие слышали о DNS amplification и NTP amplification атаках. Много было написано про эти два частных случая UDP-based Amplification атак. Какие ещё протоколы могут быть использованя для усиления? В этом контексте в статье предлагаю рассмотреть протокол tftp.
Давайте вернемся немного назад и вспомним, что представляет собой UDP-based Amplification атаки. Вся реализация сводится к двум пунктам:
Это далеко не полный список, существуют и другие «интересные» протоколы, например, tftp. Ему и будет далее посвящена моя статья.
Теория
Trivial File Transfer Protocol (tftp) — действительно очень trivial, название описывает весь функционал. Tftp не поддерживает аутентификацию, да и вообще какие-либо механизмы безопасности. Для реализации UDP-based Amplification атаки нам надо понять, какой tftp пакет вернется «усиленным». Пакет, инициирующий получение/передачу, выглядит следующим образом:
Просмотрев RFC 1350, становится ясно, что нашим требованиям отвечает только пакет, инициирующий получение файла. По стандарту первый пакет адрес отправителя в котором возможно подделать может быть RRQ (Read request) или WRQ (Write request). В ответ на WRQ сервер отправляет пакет подтверждения небольшого размера, а вот ответом на RRQ приходит первый пакет запрошенных данных размером не более 512 байт. Необходимый нам формат:
\x01 — opcode RRQ
octet — тип передачи, в нашем случае неважен
На хостовой ОС запущен tftpd32, на гостевой scapy, ноутбук исполняет роль жертвы. Первый тест, отправка такого пакета:
На стороне жертвы появился следующий трафик:
Таким образом, отправленные нами 62 байта сгенерировали трафик объемом 1306 байт, что в 21 раз больше первоначального. Получился небольшой коэффициент, но давайте запретим icmp трафик, как это часто бывает.
В этот раз появится следующий трафик:
Общий объем 3415 байт, коэффициент в этот раз 55. Это уже что-то, сопоставимо с DNS amplification.
Практика
Количество доступных tftp серверов не превышает 200 тысяч, как по оценкам shodanhq.com, так и по собственным «ощущениям». По сравнению с 28 миллионами «опасных» DNS серверов угроза от tftp серверов незначительная. Дополнительно для использования усиления необходимо знать имя файла на сервере или иметь возможность записи. Это также уменьшает количество серверов, которые можно использовать. Для нахождения подходящих серверов был написан простенький скрипт.
Из проверенных мной 10 тысяч серверов подходящими оказались только 1,5 тысячи, но, думаю, эту цифру можно увеличить, составив грамотный список имен файлов, которые проверяются на наличие. К сожалению счастью, мой провайдер не дал возможности протестировать увеличение нагрузки на интерфейсе платного vps, так как оборудование отбрасывало пакеты с «неправильным» адресом отправителя. Пришлось использовать подручные средства. На гостевой машине со scapy была ограничена скорость программой tc, а жертвой так и остался ноутбук с монитором трафика. Переделав скрипт, на практике было достигнуто усиление в 31 раз (по схеме без icmp ответа). О правдивости практических показателей говорить сложно, так как провайдер, возможно, вносит свои коррективы в приоритеты скорости движения трафика.
Заключение
Считаю, что tftp UDP-based Amplification, хотя и сравнима по коэффициенту усиления с DNS amplification, не является настолько критичной, в силу меньшей распространенности и свойств эксплуатации. Возможно применение в составе гибридной атаки, а использование в качестве единственного вектора атаки, думаю, оправдано только на слабые каналы передачи данных.
Мне кажется, что у некоторых специалистов могло сложится неверное понимание «Amplification»-атак, по принципу «у меня нет публичных DNS, NTP, меня это не затронет». Этой статьей хочу обратить ваше внимание на то, что основная проблема «Amplification» атак не только в реализации сервисов DNS, NTP, tftp и т.д., a лежит уровнем ниже, по стеку протокола TCP/IP — протокол UDP. Для решения подобной проблемы необходима работа на многих уровнях, т.е. программисты при создании сервисов на UDP должны пытаться уменьшить коэффициент усиления, сетевые специалисты должны ставить запрет на подмену ip-адреса отправителя в своих зонах, а администраторы систем должны ограничивать доступ к сервисам по принципу достаточности.