Пользователь
0,0
рейтинг
10 февраля 2009 в 12:17

Разработка → DNS Amplification (DNS усиление)

Не так давно столкнулся с проблемой (и ее решением) учитывая актуальность этой темы в последнее время, а также то, сколько людей сейчас страдают от этой беды, решил объединить информацию в одну статью. Может быть кому-то еще она будет полезной.
image

Начало



Пару недель назад я заметил странную активность, направленную на мой 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 усиление). Теория


Сам тип атаки не нов — о нем было известно еще в 2006 году, подробности на английском языке можно посмотреть здесь , однако активно использовать его начали относительно недавно. В январе-феврале 2009 года несколько интернет-изданий опубликовало информацию о крупномасштабном использовании киберпреступниками этого вида DDOS, о чем можно узнать здесь и на английском языке здесь
Объясняя простым языком, суть усиления заключается в том, что злоумышленник посылает (обычно короткий) запрос уязвимому DNS-серверу, который отвечает на запрос уже значительно большим по размеру пакетом. Если использовать в качестве исходного IP-адреса при отправке запроса адрес компьютера жертвы (ip spoofing), то уязвимый 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-сервера вне зависимости от того, на какой платформе он работает. Во-вторых, убедиться, что настроен сервер достаточно безопасно и не отвечает на «левые» запросы всем подряд. Об этом в сети можно найти множество мануалов и рекомендаций, упомяну здесь только об одном документе, который нашел не так давно.

Что еще можно сделать?


В моем случае делать было уже особенно нечего. Если посмотреть самый первый лог, который я привел, то видно, что атакующий отправляет запрос длиной 17 байт и получает REJECT той же самой длины (17 байт), т.е. никакого усиления не происходит. Но, видимо, «ddos-еры» особенно не торопятся убирать из своих списков адреса DNS-серверов, не подверженных этой уязвимости, и продолжают беспокоить их своей долбежкой… Эта ситуация меня не устраивала. Неприятно что от моего адреса кто-то получает на свой сервер ненужный трафик (даже пусть я в этом и не виноват).
Поначалу я начал ставить в black-лист адреса отправителей, но не тут-то было, со старых адресов атака прекращалась, но появлялись все новые и новые. Было решено использовать более изощренные методы фильтрации и задействовать на моем Linux-сервере модули iptables, до которых раньше у меня никак руки не доходили. Убить, так сказать, сразу двух зайцев — и атакующим сделать -1 и разобраться с парой модулей iptables.

Модуль String


Закрыть 53 порт (DNS) полностью я конечно же не мог — у меня много клиентов которым он нужен. Я решил фильтровать пакеты по содержимому DNS-запросов и убирать те из них, которые содержат запросы атакующих, а они все как один содержали в себе «NS». Для этой задачи подходит модуль iptables string, который как раз позволяет заглянуть в содержимое пакетов.
Для того, чтобы понять что фильтровать, посмотрим на пакет атакующего через wireshark.
image
Здесь и здесь можно почитать о структуре 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 байта содержат эти байты. Это будет выглядеть так:

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 байта пакета.

Модуль Recent



На этом уже можно было бы остановиться. Пакеты уже не будут доходить до bind, но меня еще не утешала мысль, что я закрыл для ВСЕХ возможность обращаться с запросами NS к моему DNS-серверу, поэтому я решил задействовать еще один модуль iptables — recent.
Этот модуль позволяет создавать динамические таблицы IP-адресов в зависимости от определенных условий, а затем устанавливать разрешающие и запрещающие правила для этих таблиц.
Рассмотрим простой пример использования recent, состоящий из двух строк:

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 минут.

После добавления этих правил в /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: В последнем блоке кода поторопился и написал ошибку, уже исправил, спасибо, что заметили
Шуваев Виталий @Nast
карма
64,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (60)

  • –1
    Добавьте пожалуйста хабракат
    • 0
      добавил
  • +28
    отличный, уникальный материал, изложение на высоте
    читать было очень интересно, спасибо
  • 0
    Переносите в «Информационную безопасность».
    • +5
      Так вы помогите ему перенести — поднимите карму человеку ;)
      • +1
        Я сразу добавил кармы, уже достаточно для переноса ;)
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Атакуют не его, а через него.
      • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    теперь по идее перенести сможете. Отличный материал.
  • +2
    Хотелось бы узнать какова была сила атаки и как поднялась/упала нагрузка на систему после включения этих правил?
    • 0
      Честно говоря я пока не проводил сравнение производительности сервера с/без правил, но думаю нагрузка снятая с bind все равно стоит того чтобы правила существовали, даже, если добавилась пара правил в iptables
      • 0
        Просто парсинг каждого udp пакета на некий стринг со смещением — достаточно затратная операция, не?
        • 0
          а вот, кстати, интересно каждый ли? Ведь там указывается еще и интерфейс и порт, что значительно сужает круг проверяемых пакетов.
          • 0
            Что касается затратности — посмотрите ещё модуль u32, возможно он будет побыстрее делать поиск.
            Хотя я не думаю, что сравнение 4 байт — это затратная операция.
        • 0
          А для этого recent и был прикручен, не?
          • 0
            recent прикручен, чтобы не блокировать всех подряд, а только тех, кто посылает запросы в большом количестве
            • 0
              А кто создаёт нагрузку основную, как не те, кто флудит?
        • 0
          Парсинг его в iptables еще в ядре явно дешевле, чем парсить его bind-ом.
  • –38
    Извините ради бога за хайджекинг, не срите в карму, у меня ее и так нет чтобы написать к себе в блог, но ЭТО должен видеть каждый:

    — i.gizmodo.com/5150189/so-mean-but-maybe-true-nsfw
    Очень жесткий, но очень прапвдивый стеб над всей индустрией электроники. Ничего личного к сони. Я даже перевод сделал:

    Ведущий:
    Любители современных технологий сегодня выстраиваются в очередь чтобы стать первыми обладателями свежей непонятной тупой хуевины от Sony, которая нихрена не делает того, для чего, бля, она создана. Подробности от нашего обозревателя последних цифровых технологий — Джефа Тейта.

    Джеф Тейт:
    Спасибо Брэндон. Устройство уже было названо «Самым тупым способом выкинуть кучу бабла за последние годы». Новая хреновина от Sony уже заполонила собой все супермаркеты и магазины электроники с завышеными ценами по всей стране.

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

    Джеф Тейт:
    Если вы каким-то макаром все-таки прорветесь через упаковку, которую невозможно открыть, этот кусок говна предложит вам целый набор раздражающих функций, как например непонятные мигающие слова и цифры на экране, нежелание выполнять ебаные функции, на которые это дерьмо рассчитано, а также полная готовность быть последней ебаной электронной хуйней которую вы когда либо в жизни купили, чтоб блять ее разорвало и медведь в сибири ебал во все разъемы.
    Представитель Sony, Элан Камптон заявляет, что компания разработала эту блядскую хуйню чтобы каждая семья в современном доме захотела вырвать себе гребаные глаза.

    Элан Камптон:
    Мы внимательно прислушались к просьбам наших клентов, которые пожелали иметь самую навороченую систему домашних развлечений и результатом нашей работы стала вот эта хуёвина, которой невозможно пользоваться.

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

    Элан Камптон:
    Мы хотим чтобы люди по всей стране орали от раздражения: «Работай! Сука, твою мать, работай, гребаный ты кусок дерьма! Что ты, блять, от меня хочешь, почему ты не работаешь?!»

    Джеф Тейт:
    С рекламной компанией в сотни миллионов долларов, которая позволила разместить тупые баннеры с этой пластиковой хуйней в каждом гребаном углу, куда ни посмотришь, Sony рассичтывает сделать свое детище полнейшим мастбаев для любого человека, если тот не хочет показаться пингвином с южного полюса, который ваще в тезнике нихрена не шарит.

    Прохожий:
    Я люблю всякую муть вроде этой. Я ваще покупаю каждую чертову хрень, которую увижу в рекламе.

    Джеф Тейт:
    Вы можете купить гребаный кусок дерьма уже сейчас, а потом пригласить всех своих друзей, чтоб они заценили хреновину, а также может смогли бы в ней разобратьсяв этом чертовом поглотителе свободного времени. И даже если ваши друзья это Друзь, Поташов и Вассерман — Sony обещает что у них нету ваще никаких шансов. Для Onion News Network, Джеф Тейт

    Ведущий:
    Спасибо Джеф. Сони заявила, что готова выпустить 80Гб модель этой хуйтени к концу года, как раз когда вы разберетесь с пультом. Бля, да когдаж они сдохнут все.

    • 0
      А это про чо вообще?
      • 0
        Про некую среднестатистическую новинку в мире высоких технологий.
        Хабр почему-то видоизменил ссылку, вот она: i.gizmodo.com/5150189/so-mean-but-maybe-true-nsfw
        • 0
          а зачем нужно было это постить в этом топике?
          • 0
            А где еще мне это запостить? Ваши предложения?
            P.S.: Я извинился перед автором статьи заранее.
            • 0
              Подождали бы какой-нибудь тематической статьи или в песочницу кинули бы.
            • +1
              принесение извинений 'заранее ' не тоже самое что автор принял их, а тем более остальное сообщество
    • –13
      Лишний раз убедился что Хабр это сообщество отзывчивых людей, готовых к взаимовыручке. Спасибо вам, друзья! :)
    • 0
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      В принципе, да. Там не такой большой входящий трафик был чтобы его увидеть где-то еще
      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Подробности о том, что установлено на сервере, я разглашать не могу из соображений безопасности
          • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Еще бы понять, как на authoritative ns избежать сего.
    В любом случае DNS-ответ ВСЕГДА больше DNS запроса, т.к. включает его.

    Возьмём, к примеру, запрос mx на gmail.com. Получаем 55 байт в запросе и 314 в ответе.
    • 0
      Да, это проблема. Метод, предложенный мной, кстати, работать будет только до тех пор пока атакующие не решат использовать другие запросы/типы запросов. Но пока этого не предвидится можно обойтись и так. К тому же если использовать для атаки тот же mx и gmail.com. Сразу встают несколько вопросов. Во-первых 55>17, а это значит лишний трафик атакующему, во-вторых mx сработает не на кого угодно, а только на крупных mail-серверах (которых явно меньше чем простых dns-серверов, разбросанных по сети), в-третьих на крупных mail-серверах есть гораздо больше возможностей для фильтрации и детектирования аномальной активности, да и вообще к ИТ-безопасности там относятся серьезней. Резюмируя все вышесказанное не думаю что злоумышленники решат пойти на такой шаг (imho)
      • 0
        Я говорю лишь про то, что проблема протокола фундаментальная, думаю, атакующим выгоден почти любой коэффициент усиления — даже в два раза, это уже хорошо. Например, попросим MX yandex-company.ru — 63 байта, в ответ вернётся nonexistent с SOA от ru. размером 121 байт.
      • 0
        Кстати, у вас ссылка на secure bind template, там предлагают включить additional-from-cache no.
        Но не знаю, поможет ли оно.
  • +1
    ААА!!! Автор, я ваш фанат теперь! Пишите еще! Очень, очень интересно и познавательно :) Спасибо!
    • 0
      Пожалуйста. Писать в пустую не люблю, если появится интересная и актуальная тема, то тогда может быть.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Не стоит быть столь самокритичным)
      • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Браво! Выражаю уважение.
  • 0
    Спасибо за статью, а особенно за разжёванные правила ipt_recent.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    У вас нестыковочка:
    --from 36 — ищем начиная с 40 байта
    • 0
      Да, ошибся в последнем блоке правил, еще забыл iptables в начале поставить. Спасибо за указание.
      должно быть действительно 40
  • 0
    Спасибо :) очень итересно!
    Но атакующие тоже хитерцы. В их запросы заложен процент «правильных пакетов», то есть пакетов с их собственным обратным адресом.
    Ведут статистику чтобы вычеркивать из сиписка отбракованные ДНС сервера. :) Вот у Вас и снизилось количество пакетов со стороны атакующих.
    Остались те кто не ведёт статистику :)
  • 0
    Хорошо еще, что не AC Amplification :)
  • 0
    [x] success story
  • 0
    Какой 2006ой? Этот тип атаки рассматривали в неплохом, на тот момент, журнале Хакер за декабрь 2002го.
    Разве что тогда это не называли DNS Amplification.
  • 0
    Надо переходить на использование TCP для DNS-а ;)
    А зачем, в общем случае, на публичном интерфейсе отвечать на запрос "."?
    • 0
      Если есть юзеры вне сети, у которых мой DNS проставлен в настройках, то может понадобиться. Хотя вообще конечно, это перестраховка.
  • 0
    раз уж у вас iptables может сразу нарушителей в tarpit укладывать?
    • +1
      Думал про tarpit. Не приходилось доселе его использовать (кстати надо будет попробовать), но, если я не ошибасю, tarpit ведь держит атакующего максимально возможное время, т.е. не закрывает сессию, а сессия подразумевает использование tcp. А данная атака использует не tcp, а udp, здесь вообще нет установки соединения(сессии), а просто посылаются udp-пакеты, а дошли они или нет и сколько они провисели никого не волнует. Резюмируя могу сказать что tarpit в данном случае применить не получится.
      • 0
        хехе, что-то действительно вылетело из головы, что DNS — это UDP =))
        • 0
          Нет. Вот тут не правы. Да, действительно, DNS зачастую использует UDP, но не всегда, в некоторых случаях, а именно:
          1. Если обмен идет пакетами данных больше 512 байт.
          2. Если идет передача зоны между серверами.
          3. Вышестоящий сервер хочет делигировать имя.

          то используется не UDP, а TCP.
          Однако многие ассоциируют DNS лишь с UDP — это не так.
          • 0
            Однако, забыл уточнить, в данном конкретном случае используется только UDP
  • 0
    Автор, а вы не пробовали модуль connlimit из patch-o-matic?
    netfilter.org/projects/patch-o-matic/pom-external.html#pom-external-connlimit
    • 0
      Перейдя по вашей ссылке вижу:
      connlimit — iptables connlimit match
      This adds an iptables match which allows you to restrict the
      number of parallel TCP connections to a server per client IP address
      (or address block).

      Соответственно мой ответ о применимости этого метода в контексте данной проблемы такой же как в случае с юзером SaveTheRbtz и его предложением о tarpit (см. коммент. выше)

      Если же вы просто так спросили, пробовал ли я этот модуль, то мой ответ: «Нет, не приходилось»

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.