безопасность


DNS под прессом. Атаки на DNS-сервер

Откройте ваш браузер, введите в строке адреса сайт . Пред вами будет главная страница ресурса. В общем-то, обычное явление для подавляющего большинства юзеров. А теперь вопрос: а откуда это? На первый взгляд, вопрос глупый: есть движок, есть БД, есть имэйджи на сервере – вот откуда. Но вот каким образом браузер добирается до сервера? Откуда он знает, что именно на этом сервере лежит то, что необходимо юзеру? А знает он это благодаря DNS – domain name system, то есть системе доменных имен.

Дело в том, что при вводе вами доменного имени в строке браузера последний делает запрос именно на DNS-сервер вашего провайдера, на котором хранятся списки соответствия «домен – ip-адрес». Сервер, получив доменный запрос, начинает искать его в списках. В случае обнаружения на соответствующий домену ip-адрес делается запрос, в результате которого пользователь и видит необходимую страницу/информацию.

Если же сервер не обладает информацией о введенном вами доменном имени, то запрос последовательно отправляется DNS-серверу на уровень выше и так до получения результата. Теперь прикиньте в уме ущерб, который может быть причинен в результате атаки на такой сервер. Правильно, для этого необходимо знать, какие же атаки могут быть проведены на сервер такого типа. Вот этим вопросом сегодня и предлагаю заняться. Сегодня я разложу по полочкам три типа атаки на серверы DNS, типы самые популярные и, кроме того, несущие самый большой ущерб и неприятности владельцам и пользователям, соответственно. Для того чтобы статья была не слишком сухой, я предлагаю рассматривать типы атак на реальных примерах, которые имели место в мире ИТ.

Фундамент дал трещину

Начнем, пожалуй, с той атаки, которая присутствует практически во всех списках сетевых атак =). Конечно же, это DDoS, Denial of Service – атака, которая вызывает у жертвы состояние, носящее название «отказ в обслуживании», отсюда и ее название. Не буду вдаваться в подробности ее реализации, так как писал об этом приличное количество раз на страницах КГ и не только. Поэтому сразу приступлю к рассказу.

С первого взгляда, сеть Интернет, в отличие от других сетей, является неуязвимой в силу своей глобальности и, как следствие, разрозненности компонентов. Но это только на первый взгляд, так как в основе этой сети лежат «платформенные компоненты», являющиеся началом и фундаментом. Следовательно, выведение из рабочего состояния этих компонентов сулит если не падением сети, то серьезными неприятностями – точно.

В системе доменных имен тоже есть такие вехи, которых тринадцать штук. 13 DNS-серверов носят статус Top Level Domain DNS. Они обладают самыми большими базами и являются началом всей системы. Десять из этих серверов находятся в Соединенных Штатах Америки. Во избежание физического воздействия на серверы, их местоположение сохраняется в тайне, к сожалению. Я не могу сказать, насколько это «тайна». Но, честно говоря, сильно- сильно сомневаюсь, что их локации не известны определенным людям из андерграунда.

Итак, в 23.45 21 октября 2002 года была произведена кратковременная атака на отказ в обслуживании, направленная на десять из тринадцати серверов «топ левела». Атака продолжалась около часа. Максимальное превышение пропускной способности отдельного сервера, выявленное при наблюдении за атакой, оказалось равным 40, то есть в 40 раз больше, чем мог обработать сервер. Естественно, после такого инцидента вся общественность вопросительно смотрела на ФБР. Те же попытались выбраться из передряги заявлением, что «хакеры использовали изощренный метод проведения атаки». На самом же деле это были не более чем обыкновенные DDoS.

Конечно, за час большого ущерба она (атака) не причинила, однако дала понять, что не все так безоблачно, как кажется, ведь продлись она, скажем, не час, а пять часов, и убытки бы считались миллиардами. Почему атака в один час не дала больших убытков, спросите вы? Я отвечу: дело в том, что серверы DNS имеют привычку записывать информацию в кеш. Именно данный факт и помог в этой ситуации, так как серверы, находящиеся ниже уровнем, чем атакованные, продержались этот час на кеше и не проводили запросы на топлвл, ну или делали их минимум. Поэтому обычным пользователям изменения в работе сети не были заметны.

Одним из методов проведения ДОС на ДНС может стать поток AXFR-запросов. Некоторые корневые DNS-серверы содержат сотни тысяч записей о серверах в своей зоне ответственности. Сформировав AXFR-запрос к такому DNS-серверу, получить эту информацию может любой пользователь. К счастью, ни один из серверов в доменах .com, .org, .edu, .net, .mil и .gov не позволяет AXFR-запросы. Однако уязвим гораздо более широкий круг доменов: .ar,. au, .bg, .cu, .cz, .ee, .eg, .es, .fi, .hu, .il, .in, .it, .my, .no, .pk, .se, .sg, .tr, .ua, .za и .ru.

При использовании сервера BIND в качестве решения проблемы с AXFR-запросами в версиях 8 и 9 можно использовать механизм ограничения передачи AXFR при помощи allow-transfer.

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

На правах посредника

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

Итак, злоумышленник хочет атаковать ip 198.211.12.111. У него нет большого ботнета для того, чтобы банально зафлудить пропускной диапазон линии подключения. В таком случае приемлемее всего использовать именно ДНС-усиление. Сначала необходимо произвести спуфинг ip-адреса (подмену), адрес атакующего должен быть идентичен адресу жертвы. После этого атакующий отсылает запросы на ДНС-сервер. И вот тут на руку ему особенность ответа сервера (в общем-то, это баг, который решается корректировкой кода сервера, естесно) – ответ имеет больший размер, чем запрос (рис.1). Но вот ответы уже идут на компьютер-жертву. Таким образом достигается что-то похожее на эффект снежного кома – трафик увеличивается в объеме практически из ничего, то есть взломщику остается только сидеть и наблюдать результаты работы. Тип атаки совершенно не нов, активность его использования стала возрастать с 2006 года. В январе-феврале текущего года был зафиксирован всплеск активности этого типа атак, о чем многократно сообщалось в СМИ (например, сайт ).

Теперь расскажу историю о том, как системный администратор, имеющий в Сети ник Nast, разбирался с подобного рода использованием сервера не по назначению.

Просматривая активность сервера, админ заметил странную активность - на 53-й порт, который по умолчанию принадлежит DNS service, сыпались UDP пакеты, на которые сервер (bind на Linux’е) отвечал отказами:

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)

Как я сказал выше, по сути, возможность такого использования сервера является багом, так как имеет место на старом или неверно
сконфигурированном сервере. Как обычно, таких в сети большинство :).

Отправляем серверу ns-запрос типа #dig @SERVER_IP NS, где SERVER_IP – адрес компьютера, отправляющего запрос. В логе ДНС-серва после такого запроса мы увидим:

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]

Ответ имеет размер уже 360 байт, но это только длина запроса, размер всего пакета составляет 402 байта. Вот вам и усиление, по-моему, неплохое =).

Выход для админа был только один – настраивать фильтрацию пакетов для того, чтобы отбрасывать «левые». Задача непростая, так как достаточно сложно ее реализовать без ущерба «легальным» пакетам.

Поначалу админ использовал простой способ – отправку адреса атакующего в блэклист. Однако занятие оказалось неблагодарным, так как количество атакующих возрастало, и на занесение их в блэк тратилось все больше и больше времени. Тогда было решено установить на сервере модули iptables, которые позволяют настроить достаточно специфическую фильтрацию.

Во всех запросах атакующих содержалась NS, что уже давало критерий фильтрации. Для реализации этой задачи отлично подходит модуль iptables string, который имеет возможность заглядывать вовнутрь пакета. Чтобы настроить модуль правильно, смотрим на пакет через wireshark (рис.2).

Информацию о структуре UDP пакета можно найти тут сайт и тут сайт . Первые 14 байт запроса относятся к протоколу Ethernet (красным), потом 20 байт заголовка IP-протокола (синим), следом 8 байт – заголовок UDP (зеленым), а за ним уже следуют данные DNS (желтым). Непосредственно сам запрос, DNS Query, на рисунке показан оранжевым. В пакетах атакующих DNS Query поле начиналось с 54 байта, где 00 00 02 00 01 в шестнадцатеричном коде соответствует запросу NS. Следовательно, пакеты, у которых после 54 байта содержатся эти байты, будут соответствовать критериям фильтрации, для их выделения используем:

iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --jump DROP

. --in-interface — указывает, на каком интерфейсе отлавливать пакеты. Нужно поставить только внешний интерфейс, на который идет атака (незачем ущемлять пользователей внутри сети);

. --match state --state NEW — отлавливаем пакеты только с состоянием NEW, чтобы не проверять все транзакции подряд, а только инициирующие пакеты (мало ли что может передаваться по 53 порту).

Дальше идет самое интересное — задействуем модуль sting. Мы используем следующие параметры:

. --algo — указывает алгоритм поиска, по сути, неважен; я указал kmp, но можно указать и bm;

. --hex-string — записывается та самая строка в шестнадцатеричном виде, которую мы ищем;

. --from 40 — ищем начиная с 40 байта (заметьте, не с 54, потому что string начинает поиск, а соответственно, и отсчет от первого байта протокола IP, то есть выбрасывается протокол Ethernet, длина которого 14 байт (на рис. сверху красным). Итого 54 – 14 = 40);

. --to 45 — соответственно, искать до 45 байта пакета.

Но решение неполное, так как теперь доступ к серверу закрыт всем, кто будет использовать в запросе NS, это не есть хорошо. Чтобы поправить дело, нужно задействовать еще один модуль iptables — recent. Этот модуль позволяет создавать динамические таблицы IP-адресов в зависимости от определенных условий, а затем устанавливать разрешающие и запрещающие правила для этих таблиц.

Рассмотрим строчки:

iptables -A INPUT --protocol tcp --match state --state NEW --dport 22 --match recent --update --seconds 30 --name SSHT --jump DROP

iptables -A INPUT --protocol tcp --match state --state NEW --dport 22 --match recent --set --name SSHT --jump ACCEPT

Начнем разбираться со второго правила. Каждый, кто пытается зайти (именно зайти, так как мы используем --state NEW) на порт 22 (SSH) пропускается (--jump ACCEPT), но его IP-адрес попадает в таблицу с именем SSHT. Когда с этого адреса пытаются соединиться еще раз, начинает работать первое правило, смысл которого состоит в том, чтобы обновить (--update) запись в таблице и заодно проверить, когда эта запись была установлена/обновлена в последний раз. Если запись была установлена/обновлена меньше 30 секунд назад (--seconds 30), то срабатывает --jump DROP, и пакет отбрасывается. Таким образом брутфорсеры, пытающиеся долбиться на порт SSH, будут отбрасываться, если частота отправки их пакетов будет превышать 1 пакет в 30 секунд.

Вот настройка recent для нашего случая:

iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --match recent --name DNST --update --seconds 600 --jump DROP

iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --match recent --name DNST --set --jump ACCEPT

Таким образом, обращение к серверу с запросом, содержащим NS, будет разрешено не чаще 1-го раза в 10 минут.

Вот такой вот вариант решения проблемы предложил Nast. Хороший вариант, скажу я вам, за что ему и респект.

Хотел бы добавить, что DNS-усиление бывает рекурсивным и нерекурсивным. Нерекурсивное усиление не требует обращения к вышестоящим серверам ввиду использования запроса “*.*”. Ответ же от севера получается достаточно внушительный. Информацию по нерекурсивному DNS-усилению можно найти тут сайт . Мы же едем дальше.

Липовый адрес

Последняя история появилась в моем арсенале после прочтения статьи Криса Касперски в журнале ][akep «Положи DNS на лопатки: новый вектор атаки на DNS-серверы». Уязвимость и атака, которые описываются в статье, не новы, однако достаточно опасны, в первую очередь для юзера.

Дэн Каминский, сотрудник IOActive, готовясь к конференции Black Hat USA 2008, подготовил доклад, демонстрирующий новые атаки на DNS-серверы. Дэн не разглашал особенностей уязвимости, что создавало атмосферу всеобщей паники. Особенно среди разработчиков, которые лихорадочно анализировали код своих серверов, пытаясь найти баги. Однако, как оказалось потом, Каминский не открыл ничего нового, а всего лишь вспомнил старое, считает Крис.

Атмосфера вокруг анонса Дэна была натянута до не могу, и тут на одном из блогов появилось описание уязвимости, о которой виновник паники рассказал «по пьяни» (одна из версий). Впоследствии в Сети появились два эксплоита, один из которых был предназначен для атак на серверы, второй – на рабочие станции. После анализа оказалось, что уязвимость не несет в себе ничего нового.

«Самое интересное — реальные дыры (о которых Каминский не имел ни малейшего представления) остались не заткнутыми. Я сходу предложил два сценария внедрения в уже пропатченные системы. Не придав им, впрочем, большого значения, поскольку Endeavor Security Inc (где сейчас работаю) в основном занимается разработкой и лицензированием сигнатур для различных систем обнаружения вторжения, многие из которых не имеют даже пороговых датчиков. В рамках «чистых» сигнатур (без привлечения специальных модулей) описать атаку на DNS практически невозможно в силу природы самой атаки. Но мне все-таки удалось это сделать, после чего я связался с разработчиками осей и всех популярных реализаций DNS-серверов на предмет: «так когда же будут готовы нормальные патчи?!».

И вот тут началось… Разработчики быстро въехали в ситуацию и попросили меня отложить публикацию до тех пор, пока лекарство не будет готово. В смысле, английскую публикацию. За русскую никакого договора не было, так что читатели ][акера имеют возможность получить эксклюзивную информацию из первых рук.»

Было это в октябре 2008 года, который мы еще не успели забыть, думаю =). Вот я и предлагаю читателям КГ разобраться в том, что нашел Крис Касперски, а также рассмотреть варианты решения, которые предложил автор.

При работе большинство серверов используют именно UDP протокол (хотя вполне можно работать и поверх TCP) ввиду его быстроты. Используют и, естественно, получают меньшую защищенность, ведь за скорость надо платить :). Чтобы запрос, отправленный жертве от имени сервера, воспринялся как правильный, необходимо только угадать TXID (идентификатор последовательности) и SP# - номер порта получателя.

Что можно из этого получить? Можно подсунуть жертве ложный IP-адрес вместо соответствующего запрашиваемому серверу. Скажем, вместо ресурса с софтом, ресурс со взломанным и «немного подправленным» софтом.

Единственная проблема в том, что хакер должен успеть сгенерировать ответ на запрос пользователя до того, как это успеет сделать сам сервер. Кроме того, данные кешируются и некоторое время при запросе используется кеш, как я писал выше. Однако проблема вполне решаема: кеш невелик, поэтому, послав жертве HTML-письмо с кучей картинок, лежащих на внешних серверах с разными доменными именами, хакер может вытеснить из кеша все старые записи. После чего последняя ссылка в письме, ведущая на сервер обновлений, гарантированно пошлет обозначенный запрос в Сеть. Предшествующая ей ссылка на Web-сервер, подконтрольный хакеру, подскажет точное время, когда следует начинать генерацию подложных пакетов. Если хотя бы один из них будет воспринят как правильный, в DNS-кеш попадет «левый» адрес сервера с апдейтами, имеющий все шансы «дожить» до очередной сессии обновлений.

Но можно добиться и более масштабных результатов. Например, отправим серверу доменный запрос x.domain.com, который отсутствует в базе сервера. Это заставит атакуемый серв обратиться к вышестоящим серверам для поиска информации. Если взломщик успеет ответить быстрее всех, то атакуемый серв запомнит предложенный хакером IP и будет направлять на этот адрес все запросы *.domain.com, считая, что он наиболее компетентный в вопросах этого домена. Вот таким образом получается захватить весь домен, плюс его поддомены. Вот такой сценарий был предложен Каминским для проведения атак.

Однако сценарий Дэна не столь критичен даже в случае успешно проведенной атаки. Дело в том, что взломщику необходимо угадать TXID/SP#, что требует посылки большого количества пакетов, а они легко будут обезврежены даже самой примитивной системой обнаружения вторжения. Во-вторых, важная информация обычно передается через SSL соединения, которое устойчиво к перехвату, да и многие передаваемые исполняемые файлы имеют цифровую подпись, которую не подделаешь. Так что возможности ограничены.

Для еще большего затруднения проведения атак разработчиками было решено полностью рандомизировать TXID, используя 16-битовое боле. Однако это не сильно изменило ситуацию, так как для успешной атаки взломщику необходимо было отправить 2^16/2 = 32768 пакетов, что более чем реально при сегодняшних пропускных способностях + наличии ботнетов, система обнаружения вторжения, безусловно, среагирует на такую атаку, однако не сможет ей противостоять.

Тогда было решено реализовать еще и рандомизацию порта, который был постоянным на серверах (53 порт). В версиях BIND 8 и 9 эта функция уже была добавлена, поэтому сисадминам оставалось только включать/выключать ее. Выключать, так как рандомизированный порт доставит много хлопот с брандмауэрами при постоянной работе.

Заплатки были выпущены, рандомизация проведена и, казалось бы, все защищено сполна. Но не все так просто. Крис продемонстрировал два сценария успешных атак на серверы BIND 9, DJBDNS и частично PowerDNS, которые проходят даже после установки патчей.

Итак, порт выбирается из достаточно широкого пула, который является разным у каждой машины и в грубом приближении составляет 16384, то есть 12 бит (PowerDNS вообще использует 1024 порта, его можно банально задосить). Допустим, что функция, вычисляющая следующий используемый порт, криптостойкая. Неужели взломщику придется вычислять порт вручную? Нет, естественно. Порты могут использоваться любым сервисом, службой и т.п., при этом порт «занят» в момент, когда происходит отправка ответа на запрос. Поэтому, обрушив на сервер поток вполне легальных запросов, пусть даже на нем не работают сторонние сервисы, взломщик будет отсеивать порты просто на глазах, а, возможно, и вообще задосит сервер. Поэтому хакеру можно смело отложить проблему с портом, занявшись подбором TXID.

В идеале для генерации TXID необходимо использовать функции, которые генерируют настоящий белый шум, однако этого сложно добиться без использования спецоборудования. Поэтому в большинстве случаев используется банально простой алгоритм, известный на сегодняшний день с точностью до системы, а выяснить версию последней – проще, чем открыть банку пива. Зная алгоритм, необходимо только собрать n-ое количество членов, то есть реальных TXID. Легитимные запросы позволяют решить эту проблему. Остается только выяснить варианты… банальный брутфорс. Даже к серверу не надо подключаться, хакер получает варианты на блюдечке с голубой каемочкой.

В заключение немного вариантов решений, предложенных Крисом.

Для мелких узлов, нагрузка которых невелика, имеется достаточно простое решение. Например, переход на работу поверх TCP протокола. Также можно воспользоваться TSIG, который позволяет организовать безопасное взаимодействии серверов, пользуюсь при этом сигнатурами транзакций. DNSSEC позволит реализовать проверку подлинности серверов и целостность данных.

В крупных масштабах остается только использование PowerDNS, который намного надежнее BIND’а 9. Также следует установить хорошую IDS/IDP. Ее работа зависит от настройки, как пример — контроль количества DNS запросов/ответов, их соответствия и т.п.

Если говорить о более сложных системах защиты, то они парсят трафик, вытягивая случайные пакеты и, обращаясь к серверам по TCP протоколу, проверяют их достоверность.

«Скоростной потоковый алгоритм, реализуемый на основе чистого сигнатурного анализа проходящего трафика. Руководящая идея заключается в том, что нормальный DNS-сервер не отвечает дважды в течение короткого времени, поскольку первый ответ будет скеширован, и второго запроса просто не последует. А вот хакер, пусть и располагающий определенной информацией о TXID/SP#, вынужден посылать намного больше одного DNS-ответа, содержащего тот же самый отрезолвенный IP, — явный симптом атаки» - вот такой вот вариант защиты был разработан Крисом совместно с сотрудницей Endeavor Security.

На этой оптимистической ноте описания вполне надежной защиты я закончу рассказ об атаках на серверы, которые управляют доменными именами, то есть DNS-серверы. Как видите, не все так безоблачно, как может казаться временами. Неоспоримо только одно – количество уязвимостей будет неуклонно расти, и не всегда патч от разработчика решает проблему безопасности. Чешите затылки, уважаемые, и тогда, возможно, у вас получится достойно защитить свои детища.

P.S.: При написании статьи использовались материалы под авторством: Крис Касперски, Андрей Васильков, Nast.



Евгений Кучук, SASecurity gr.

© компьютерная газета