LINUX.ORG.RU
ФорумAdmin

deep inside a dns amplification ddos attack

 ,


1

2

Добрый день.

Мой маленький VPS сервачек заблокировали из за того что типо у меня не закрыта дырка в DNS. Текст письма такой:

Our network administrators have detected abnormal activity consistent with an external vulnerability scan. It was also determined that the BIND server running on your container is open to exploitation a DNS amplification attack as an Open DNS Resolver. The worry is that a party is building a list of known exploitable servers for use in an attack against some unknown third party.

You are required to make changes such that the BIND server does not resolve DNS queries except for those domains hosted on your server.

You can modify the following files:

/etc/resolv.conf - set the nameserver to be 8.8.8.8 if it is currently set to 127.0.0.1 or localhost /etc/named.conf - add the following line to the «options» stanza:

allow-recursion { 1.2.3.4/24; 127.0.0.1/16;};

FAQ: What is DNS amplification attack? http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack

Note that while we can be reasonably sure that these changes will protect your server from being used as part of an attack against a third party, the overall security of your server is the responsibility of your server administrator, as the servers we sell are all self-managed and that any attempts by technical support to improve your server security is a gesture of goodwill and not a guaranteed resolution. Please reply that you are willing to make this change and we will reinstate the account to allow you to do so as soon as possible.

В качестве DNS сервера у меня unbound. Я честно говоря еле настроил этот unbound, пару доменов и забыл, а тут прилетело...

Никто не сталкивался как закрыть эту «дырку» в unbound?

★★★

Если верить man'у, то нужно прописать в allow в access-control только нужные ip-адреса.

mky ★★★★★ ()
Ответ на: комментарий от mky

Сделал:

        access-control: 1.2.3.4/24 allow
        access-control: 127.0.0.0/8 allow

Но когда я делаю nslookup sex.ru 1.2.3.4 он все равно возвращает IP

Или по другому как то надо проверять? ;)

Mrak ★★★ ()
Ответ на: комментарий от Mrak

Похоже, что перед этим нужно вписать:

access-control: 0.0.0.0/0 refuse
Хотя, вроде как, это должно быть по умолчанию.

mky ★★★★★ ()

А что за хостер-то? По-моему, они оборзели.

true_admin ★★★★★ ()

Сервер действительно используется как DNS сервер, т.е. отвечает на запросы клиентов? Если так то простейший вариант это отдать DNS на аутсорс (многие регистраторы предоставляют бесплатный DNS хостинг). В противном случае DNS сервер на нём скорее всего вообще не нужен.

unbound вроде как только кеширующий, так-что второй вариант, но «настроил этот unbound, пару доменов» несколько сбивает меня с толку.
Если виртуалка не контейнерная, а с собственным ядром то можно просто закрыть фаерволом доступ к 53 UDP порту сервера, но это не лучший вариант, некоторые DNS клиенты вроде как могут использовать 53 порт как исходящий порт при DNS запросах.

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

но это не лучший вариант, некоторые DNS клиенты вроде как могут использовать 53 порт как исходящий порт при DNS запросах.

Не слышал про таких, но в любом случае ведь у iptables есть ″state NEW″.

mky ★★★★★ ()
Ответ на: комментарий от mky

По стандарту (или традиции, ХЗ) раньше сервера отправляли DNS запросы с 53 порта, конечно уже давно от этой дикости отказались и исходящий порт рандомизируют, но я не уверен что так делают все.

У UDP нет состояний, так-что state NEW может появиться только благодаря магии conntrack-а. Полагаться на магию как-то не очень хочется, к тому-же на сервере с большим трафиком (например при DDoS атаке) conntrack разумно отключить, на него уходит много ресурсов, а проку от него (на не-роутере) мало.

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

раньше сервера отправляли DNS запросы с 53 порта

Не знаю про другие сервера, но bind перестал так делать с версии 8.1, которая вышла в 1998 году или раньше. Это очень давно, если лезть в такую древность, то и до классовой маршрутизации дойти можно.

Полагаться на магию как-то не очень хочется

Вы таки уже полностью ушли в ipv6, где нет NAT'а? Огромное число пользователей ходит в интерент через NAT, то есть полагается на магию conntrack'а.

на сервере с большим трафиком (например при DDoS атаке) conntrack разумно отключить

Это вобще тема отдельного срача, в этом топике я DDOS обсуждать не буду. Но замечу, что среди прочего, conntrack позволяет делать REDIRECT, который на сервере иногда нужен, поэтому вопрос отключени conntrack на сервере (не маршрутизаторе) не так однозначен.

mky ★★★★★ ()
Ответ на: комментарий от true_admin

А что за хостер-то? По-моему, они оборзели.

Не все так однозначно. Если у ТС нет защиты от некоторых детских вещей (dns any и др.), то хостера я могу понять. Я, например, пока не запилил толковую вещь на основе xtrecent на своих днс, то серваки могли отдавать по 500-600 мегабит...А обычно на отдачу до 20 мегабит.

P.S. Все равно любого завалить можно, особенно зная пулы провайдера. Комар носа не подточит.

andrew667 ★★★★★ ()
Ответ на: комментарий от MrClon

unbound вроде как только кеширующий, так-что второй вариант, но «настроил этот unbound, пару доменов» несколько сбивает меня с толку.

Нет не только, там можно описывать свои домены.

А кто может сказать в чем ddos? В том что мой сервер отдает информацию по другим доменам?

Mrak ★★★ ()
Ответ на: комментарий от Mrak

в чем ddos?

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

true_admin ★★★★★ ()
Ответ на: комментарий от andrew667

Просто я против политики «а давайте превентивно всех заблочим».

Вот послать уведомление и дать время на починку это было бы более правильное для клиента решение.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Вот послать уведомление и дать время на починку это было бы более правильное для клиента решение.

Да так и было. Послали уведомление, заблочили, ждали пока я отвечу, как ответил, дали время на починку.

В общем я не понял как unbound запретить отсылать информацию только по своим доменам. Воспользовался утилиткой, которая фильтрует dns запросы, где прописал только свои домены.

Написал в поддержку - проверили, остались довольны.

Mrak ★★★ ()
Ответ на: комментарий от true_admin

Получается, что если бы создатели ботнетов не ленились, и посылали бы каждому DNS серверу запрос касающейся именно его зоны ответственности, этой темы бы не было? Ведь за свою зону DNS-сервер обязан дать ответ и от подставновки ip-адреса в запросе реально защитит только переход на dns по tcp.

mky ★★★★★ ()
Ответ на: комментарий от mky

Получается, что если бы создатели ботнетов не ленились,

Не факт, что можно выполнить это правило

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

для моих зон...

Mrak ★★★ ()
Ответ на: комментарий от mky

Интересное наблюдение :). Я думаю, для бОльшего успеха они спецом создают зону побольше и её резолвят. При запросе, скажем, в 70 байт ответ в формате EDNS может быть 4кб. Т.е. усиление в 50-60 раз.

true_admin ★★★★★ ()
Ответ на: комментарий от Mrak

А какой длины у вас ответ на ″ANY″? Там ведь возвращается SOA, NS и TXT записи. Причём в TXT принято заносить spf. В общем, получить ответ больше запроса можно, разве что меньший «коэффициент усиления» будет. Хотя в этом случае поиск подобной «мелочёвки», с неправильно настроенным ДНС-сервером, становится не интерестным, ведь есть крупные ДНС-сервера с заметно более широким каналом.

mky ★★★★★ ()
Ответ на: комментарий от true_admin

Если верить тому, что здесь: http://habrahabr.ru/post/51574/ , то всё ещё тупее, просто просят список NS-серверов корневой зоны. Причём, даже не проверяется, что сервер отвечает Refused.

Хотя, если на части маршрутизаторов как-то фильтруют трафик по src-ip (RFC2827), то у бота ограничен диапазон ip-адресов, на которые он может отправить пакет с поддельным src-ip адресом. И до google и прочих ДНС-серверов ему не дойти, поэтому тупо работают «по площадям».

mky ★★★★★ ()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от mky

А вот мне самому интересно как спуфинг делается. По-идее, провайдеры должны делать фильтрацию. У меня есть только одно объяснение — это не делается для экономии ресурсов маршрутизатора. Вечером создам топик на эту тему.

true_admin ★★★★★ ()
Ответ на: комментарий от Mrak

По поводу того что такое dns amplification достаточно подробно и грустно рассказывал Лямин на последнем Yac-е:
http://tech.yandex.ru/events/yac/2013/talks/1135/ (первые минут 20, дальше идёт разбор с точки зрения магистральных сетей в основном). Рекомендую.

Если unbound используется как обычный DNS серверто почему-бы не использовать вместо него какойнибудь попсовый bind? На сколько я знаю он по умолчанию настроен весьма анти-ддосово. Ну или аутсорс.

MrClon ★★★★★ ()
Ответ на: комментарий от true_admin

Выше дал ссылку на подробный рассказ в том числе и про это.
Если верить представителю Ростелекома экономия ресурсов на десятом месте, на первом раз3.14здяйство на местах и некоторые технические проблемы.

Трафик, таки-да, не фильтруется. В любом случае провайдеров много, и достаточно одного не фильтрующего трафик своих клиентов. Провайдер напрямую не несёт урона от dns amp осуществляемого его клиентом (трафик от него до dns сервера небольшой), определить из сети какого провайдера работает злоумышленник нельзя. В общем провайдеры как-бы в шоколаде, пока их сеть не затопит DDoSом.
А DNS серверы на виду, урон от DDoSа они (и их провайдеры) имеют, а значит и мотив пресечь это безобразие. Вот по ним и работают.
Со стороны DNS сервера можно безболезненно но сильно уменьшить плечо атаки (разница между трафиком отправляемым злоумышленником и трафиком получаемым жертвой). Более того, такие настройки можно сделать настройками по умолчанию, что собственно и делается.

MrClon ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.