Усиленная отраженная атака на DNS-серверы


11

Термин Amplified reflected attackновый для меня, и у меня есть несколько вопросов по этому поводу.

Я слышал, что в основном это происходит с DNS-серверами - это правда?
Как вы защищаетесь от этого?
Как узнать, могут ли ваши серверы использоваться в такой атаке? Это проблема конфигурации?

Ответы:


22

Во-первых, этот тип атаки (в основном) не нацелен на сам DNS, как предполагает ваш заголовок. Это, конечно, создаст дополнительную нагрузку на DNS-серверы, но главная цель - сделать DDoS кем-то еще. Плохая конфигурация сервера может ухудшить ситуацию, но в конечном итоге эта проблема присуща структуре DNS и UDP и, фактически, любому протоколу связи без сохранения состояния.

В основном это работает так: злоумышленник отправляет обычные (DNS) запросы на (DNS) сервер. Эти запросы подделаны так, как если бы они исходили из целевой системы. DNS-сервер теперь отвечает на запрос, отправляя ответ обратно его предполагаемому источнику - жертве. Вот почему это называется атака отражения .

Это возможно, потому что вы можете проверить источник связи без сохранения состояния (например, DNS через UDP) так же хорошо, как вы можете доверять адресу отправителя на открытке. У сервера просто нет возможности решить, является ли запрос законным или частью такой атаки. DNS является просто самым популярным протоколом здесь, потому что есть много-много серверов для него, и вам не нужно много технических знаний или специального оборудования, чтобы (не) использовать его.

Чтобы сделать вещи хуже (и вообще эффективнее атаковать), посмотрите на часть усиления . Было бы не так уж вредно, если бы трафик злоумышленника был равен по размеру полученному трафику. Единственное преимущество для злоумышленника заключается в том, что его адрес скрывается за DNS-сервером. Он мог бы подделать адрес отправителя напрямую, поэтому не было бы необходимости перенаправлять через DNS. Но DNS отвечает, и это еще один момент, почему DNS так популярен здесь, может быть намного больше, чем вопрос. Вы можете найти различные цифры по этому вопросу в зависимости от конкретных используемых запросов, но он может доходить до 1:60, если сервер достаточно дружествен для выполнения рекурсивных запросов.для вас. Таким образом, злоумышленнику не нужно много машин под его контролем для создания большого количества вредоносного трафика.

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

Хотя вы не можете определить, является ли запрос частью атаки или нет, ваш единственный вариант - больше не запускать сервер. Вы можете возиться с ограничением скорости и другими игрушками, но вы не можете полностью избавиться от этого. Если вы предоставляете DNS для развлечения, вы можете занести в черный список исходный IP-адрес запросов. Но если вы находитесь в большем масштабе, это нанесет ущерб жертве еще больше. Помните, что все, что вы можете увидеть на DNS-сервере, это адрес жертвы. Представьте, что ваша компания подвергается атаке через DNS вашего провайдера, и ваш провайдер решает сократить службу DNS для вашей компании. Злоумышленник может набрать это в виде миллиарда бонусных очков за отказ в обслуживании .

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


Пока на учении. Чтобы ответить на ваш вопрос, наконец:

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

Так...

  • убедитесь, что вам действительно нужно запустить публичный DNS-сервер
  • если вам нужно, взгляните на BIND allow-recursionи allow-queryдирективы
  • если ваш DNS-сервер будет авторизован для вашей собственной зоны , рекурсия вообще не нужна, установите allow-recursion«none»;
  • если вы хотите запустить распознаватель для других доменов , ограничьте разрешенных пользователей для запросов и рекурсивных запросов. Вы можете определить IP-адреса, сети или списки доступа в упомянутых директивах
  • Подумайте об ограничении скорости DNS-трафика не только в BIND, но и на системном уровне. В качестве очень простого примера эти правила iptables не разрешают более 10 запросов в минуту с каждого IP-адреса:

,

iptables -A INPUT -p udp --dport 53 --set --name dnslimit
iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP

Теперь, имея в виду эти моменты, вы должны хорошо идти. Время от времени на вашем сервере все еще может быть вредоносный трафик, но не в тех количествах, которые спят вам на ночь.


3
Это действительно хороший ответ. Спасибо, что нашли время, чтобы написать это.
jamieb

1
@mikejanson serverfault.com/questions/450099 - взгляните на этот вопрос, чтобы узнать, какие еще варианты у вас есть (особенно патч BIND от Vixie & Schryver )
the-wabbit

RRL теперь является стандартной функцией bind и других серверов
Патрик Мевзек,

В целом неправильно иметь один и тот же сервер, авторитетный и рекурсивный. Лучшие практики советуют разделить это на два отдельных процесса.
Патрик Мевзек
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.