Статья взята у Blogerator.ru.
Сегодня у нас первая часть большой статьи про устройство ныне печально известной 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-атак, проведенных в истории Интернета.
Каждый новый год, атаки этой разновидности берут все новые, ранее казавшиеся фантастическими высоты по мощности генерируемой ими «волны» трафика.
A-запись атакуемого домена. В конце концов, тогда под раздачу попала даже сама организация-создатель интернета — DARPA…Что же это за дьявольский механизм, который поднимает в виртуальном пространстве цунами такой мощности и разрушительности?
Общая схема работы DNS
Чтобы следовать дальше, давайте предварительно в справочных целях рассмотрим общий алгоритм работы DNS (смотрите план-схему ниже).
- Пользователь запрашивает IP-адрес требуемого ему домена webserver.com у DNS (как правило, предоставляемого провайдером интернет-услуг), обозначим его далее как User Primary DNS Server;
- Если данный DNS-сервер не авторитативный для запрашиваемого домена, не содержит этот адрес в своём временном кэше, а также работает в рекурсивном режиме (а это справедливо для большей части серверов такого рода) — этот запрос задаётся уже от имени User Primary DNS Server одному из корневых DNS-серверов (Root DNS Server);
- Если Root Server не обладает данным соответствием, он возвращает для User Primary DNS Server подсказку — адрес другого DNS-сервера, который является управляющим (TLD) для указанной зоны (в нашем случае .com);
- User Primary DNS Server дождавшись его ответа, итеративно повторяет свой запрос уже к указанному в ответе DNS-серверу .com-зоны;
- DNS-сервер .com-зоны также может не знать соответствия, и тогда он возвращает в ответ адрес авторитативного для этого домена DNS-сервера — назовем его Domain Primary DNS Server;
- User Primary DNS Server получив в очередной раз ответ-подсказку, повторяет запрос в указанный адрес — на этот раз уже напрямик к Domain Primary DNS Server;
- И, наконец, Domain Primary DNS Server возвращает искомое соответствие IP-адреса для указанного домена;
- После вышеописанной серии итеративных опросов, User Primary DNS Server, наконец-то, успешно возвращает значение IP-адреса для домена webserver.com своему клиенту, завершив обслуживание рекурсивного запроса.
Конечно, это лишь примерная схема работы DNS (в данном случае её стандартный рекурсивный вариант), в реальной жизни всё может работать с некоторыми отличиями в зависимости от особенностей настройки каждого конкретного сервера.
Внимательно изучив эту стандартную последовательность, мы готовы перейти к рассмотрению уязвимостей и некоторых слабых мест этой схемы на примере сегодняшней DDoS-атаки.
Динамика работы DNS Amplification
Интересной особенностью именно DAD является то, что здесь, в общем случае, даже не нужно наличие ботнета. Для успешной атаки достаточно самому «сидеть» на относительно быстром канале, после чего использовать эффект «усиления атаки» через описанную ниже DNS-схему.
Ситуация драматически меняется, если совместную игру начинают «организованные преступные группировки» из десятков тысяч (или как в описанном выше случае — миллионов) зомбированных компьютеров со всего мира.
Давайте рассмотрим схему того, как это работает (см. графический алгоритм чуть выше):
- 1. Атакующий посылает сигнал скомпрометированным компьютерам (ботнет) на начало цикла запросов к DNS;
- 2. Все зомби-компьютеры начинают выполнять запросы каждый к своему User Primary DNS Server с подделанным обратным IP-адресом (spoofed ip), который указывает на компьютер жертвы;
- 3. Описание шагов 3-8 опускаем — это серия стандартных итеративных запросов, выполняемая рекурсивным сервером User Primary DNS Server, полностью аналогичных той схеме, которая была описана выше (см. пункты 2-7);
- 9. Итак, в результате, пакет с IP-адресом для webserver.com должен быть доставлен клиенту User Primary DNS, но реально его «усиленный» вариант будет отправлен на ранее подделанный IP-адрес жертвы.
Чтобы в многообразии деталей этой многоступенчатой схемы не потерять суть атаки, предлагаю отдельно выделить три ключевых момента, которые делают принципиально возможной реализацию данного сверхэффективного варианта DDoS:
- Эффект отражения: использование спуфинга обратного IP-адреса даёт перенаправление всех результирующих пакетов-ответов на заранее заданную жертву.
- Коэффициент усиления атаки (amplification factor): этот фактор может достигать при самых благоприятных условиях 73 (в большинстве случаев колеблется между 30-60). Это значит, что на каждый посланный условный 1 байт-запроса — вышеупомянутая схема из неверно настроенных DNS-серверов вернет 30-60 байтов-ответа, что и обеспечивает кратное нарастание DDoS-эффекта при отражении.
- Проблема «open resolver»: в большинстве случаев это устаревшая версия DNS-сервера или просто неверно настроенный его экземпляр. Он позволяет не только получать запросы из чужих сетей, выполняя рекурсивные запросы для них, но и посылать ответы без необходимых предварительных проверок. В нашем примере подобным уязвимым сервером выступает User Primary DNS Server.
Ботнет — это большая распределенная система, где на первый план всё чаще выходит надежный механизм обратной связи, который позволил бы держать постоянную связь с управляющей головой ботнета (говоря на сленге ботостроителей — с «папой»). Времена использования для отправки управляющих команд классического 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-тунелинга надежно управляются даже из самых глубоких недр тщательно «зафильтрованной» корпоративной сети.
Окончание этой статьи (её вторую часть) — читайте здесь, там мы рассмотрим уже практическую часть борьбы с такого рода интернет-угрозами.
Игорь Савчук © Системный Администратор, 2012
