DNS Amplification и DNS Reflection DDoS: как работает атака и как от неё защититься

DNS Amplification — это разновидность распределённой атаки отказа в обслуживании, при которой злоумышленник использует сторонние DNS-серверы для многократного увеличения объёма трафика, направленного на жертву. Атака сочетает два механизма: отражение трафика через промежуточные серверы и усиление небольшого запроса в значительно более крупный ответ.

Вместо прямой отправки пакетов на атакуемый сервер злоумышленник формирует DNS-запросы с подменённым исходным IP-адресом. В качестве отправителя указывается адрес жертвы. DNS-сервер получает запрос, считает его легитимным и отправляет ответ не злоумышленнику, а на подставленный адрес.

Если запрос подобран так, чтобы ответ оказался значительно больше, небольшой исходящий поток атакующего превращается в крупный входящий поток на стороне жертвы. При использовании тысяч доступных DNS-серверов возникает распределённая отражённая атака — DRDoS.

DNS Amplification опасна не только для сайтов. Целью может стать любой публичный IP-адрес, сеть, маршрутизатор, firewall, балансировщик, DNS-сервер, VPN-шлюз или другая система, чей канал можно заполнить отражёнными UDP-пакетами.

Что такое DNS Reflection

DNS Reflection — это отражение DNS-ответов на IP-адрес жертвы. Злоумышленник не обязательно отправляет большой объём трафика напрямую. Он заставляет сторонние DNS-серверы сделать это вместо него.

Упрощённая последовательность выглядит следующим образом:

1. Злоумышленник выбирает IP-адрес жертвы.
2. Создаёт DNS-запрос, в котором подменяет исходный адрес.
3. В поле источника указывает IP-адрес жертвы.
4. Отправляет запрос стороннему DNS-серверу.
5. DNS-сервер обрабатывает запрос.
6. Ответ направляется на подменённый адрес жертвы.
7. Жертва получает DNS-ответ, который никогда не запрашивала.

Термин reflection — «отражение» — описывает перенаправление ответного трафика через третью сторону. DNS-сервер в этом случае называется рефлектором.

Для проведения распределённой атаки злоумышленник отправляет такие запросы множеству DNS-серверов. В результате трафик приходит с большого количества реальных и обычно легитимных IP-адресов.

Что такое DNS Amplification

DNS Amplification — это усиление трафика за счёт разницы между размером запроса и размером ответа. DNS-протокол допускает ситуацию, при которой короткий запрос вызывает значительно более крупный ответ.

Например, условный DNS-запрос размером 70 байт может вызвать ответ размером 1 400 байт. Без учёта дополнительных сетевых накладных расходов приблизительный коэффициент усиления составит:

1 400 / 70 = 20

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

Если атакующий отправляет запросы с суммарной скоростью 500 Мбит/с, а средний коэффициент усиления составляет 20, теоретический поток отражённых ответов может приблизиться к 10 Гбит/с.

В реальной сети результат зависит от множества факторов:

• размера DNS-запросов;
• типа запрашиваемых записей;
• размера DNS-ответов;
• настроек EDNS;
• наличия DNSSEC;
• фрагментации пакетов;
• пропускной способности рефлекторов;
• ограничений Response Rate Limiting;
• потерь пакетов;
• фильтрации у операторов связи;
• доступной полосы атакующей инфраструктуры.

Поэтому у DNS Amplification нет одного постоянного коэффициента усиления. Указанные в разных источниках значения нельзя применять ко всем атакам без анализа фактических размеров пакетов.

Чем DNS Reflection отличается от DNS Amplification

Параметр	DNS Reflection	DNS Amplification
Основной механизм	Перенаправление ответа на подменённый IP	Увеличение объёма трафика
Обязательна ли подмена IP	Как правило, да	Обычно используется вместе с подменой
Обязательно ли увеличение пакета	Нет	Да
Роль DNS-сервера	Рефлектор	Рефлектор и усилитель
Результат	Сокрытие прямого источника и распределение ответов	Рост входящего трафика на стороне жертвы

На практике оба механизма чаще всего используются одновременно. Поэтому встречаются названия DNS Reflection Amplification, DNS Amplification DDoS и DNS DRDoS.

Почему для атаки используется UDP

Классический DNS работает как через UDP, так и через TCP. Для большинства стандартных запросов применяется UDP на порту 53.

UDP не устанавливает соединение и не выполняет рукопожатие, аналогичное TCP. Сервер получает датаграмму и отправляет ответ на адрес, указанный в заголовке IP-пакета.

Если сеть источника позволяет отправлять пакеты с подменённым IP-адресом, DNS-сервер не может только на основании обычного UDP-запроса подтвердить, что отправитель действительно находится по этому адресу.

Это создаёт необходимые условия для отражения:

• запрос можно отправить без установления соединения;
• исходный IP может быть подменён в плохо фильтруемой сети;
• ответ автоматически направляется на указанный адрес;
• размер ответа может превышать размер запроса;
• одновременно можно использовать множество серверов.

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

При этом DNS-инфраструктура должна корректно поддерживать не только UDP, но и TCP. RFC 9210 закрепляет требование, согласно которому DNS-серверы и резолверы должны обслуживать запросы по обоим транспортным протоколам.

Роль подмены исходного IP-адреса

Подмена IP-адреса — центральный элемент классической DNS Reflection-атаки. Без неё DNS-ответ вернётся атакующему, а не жертве.

Злоумышленник формирует пакет со следующими условными параметрами:

• адрес назначения — DNS-сервер;
• порт назначения — UDP/53;
• исходный адрес — IP жертвы;
• исходный порт — выбранный UDP-порт жертвы.

DNS-сервер не знает, что адрес был подменён, и отправляет ответ на IP жертвы.

Эффективным системным способом борьбы с такими атаками является фильтрация исходящих пакетов у операторов связи. BCP 38 и RFC 2827 описывают ingress filtering, который не позволяет клиенту отправлять трафик с адресами, не принадлежащими его сети.

Если бы такая проверка применялась всеми сетями, значительная часть UDP reflection-атак стала бы невозможной. Однако в интернете остаются сети с недостаточной фильтрацией, поэтому подмена адресов продолжает использоваться.

Какие DNS-серверы становятся рефлекторами

Открытые рекурсивные резолверы

Открытый резолвер принимает рекурсивные запросы от произвольных пользователей интернета. Он может самостоятельно искать необходимые данные, обращаться к другим DNS-серверам, кешировать результат и возвращать готовый ответ клиенту.

Публичный рекурсивный сервис может быть открыт намеренно и защищён от злоупотреблений. Проблема возникает, когда корпоративный, домашний или серверный резолвер ошибочно доступен всему интернету без ограничений.

RFC 5358 был создан специально для предотвращения использования рекурсивных DNS-серверов в качестве рефлекторов. Документ рекомендует ограничивать рекурсию доверенными клиентами и не предоставлять её произвольным внешним адресам.

Авторитетные DNS-серверы

Авторитетный сервер хранит данные определённых DNS-зон и должен быть доступен пользователям интернета. Полностью закрыть его для внешних запросов невозможно, иначе домены перестанут разрешаться.

Авторитетный сервер также может использоваться как рефлектор, если отправляет крупные ответы на небольшие запросы с подменённым адресом.

Защита авторитетного DNS отличается от защиты рекурсивного резолвера:

• рекурсию для посторонних можно полностью запретить;
• авторитетные ответы необходимо продолжать обслуживать;
• применяются Response Rate Limiting и DNS Cookies;
• используются Anycast и распределение инфраструктуры;
• контролируются размеры и состав ответов;
• фильтруются аномальные шаблоны запросов.

Домашние маршрутизаторы и сетевые устройства

Некоторые маршрутизаторы предоставляют DNS-прокси для локальных устройств, но из-за неправильной конфигурации принимают запросы с внешнего интерфейса. Такие устройства могут становиться частью отражённой атаки.

Даже если один маршрутизатор имеет небольшой канал, большое количество подобных устройств создаёт заметный распределённый поток.

Ошибочно настроенные серверы

Рефлектором может оказаться DNS-служба, установленная вместе с хостинг-панелью, VPN, системой мониторинга, контейнерной инфраструктурой или корпоративным программным обеспечением.

Типичная ошибка — разрешить входящие подключения к UDP/53 со всего интернета, хотя резолвер предназначен только для локальной сети.

Почему DNS-ответ может быть больше запроса

DNS-запрос обычно содержит имя, тип записи и служебные параметры. Ответ может включать несколько секций и большое количество данных:

• запрошенные записи;
• дополнительные записи;
• данные о DNS-серверах;
• DNSSEC-подписи;
• ключи DNSSEC;
• цепочки делегирования;
• служебные параметры EDNS;
• несколько адресов или текстовых значений.

На итоговый размер ответа влияют тип записи и конфигурация зоны. Ответы с DNSSEC могут быть крупнее из-за криптографических подписей и ключевых данных.

Это не означает, что DNSSEC является ошибкой или его нужно отключать. DNSSEC решает задачу проверки подлинности DNS-данных. Проблема усиления уменьшается правильной настройкой DNS-сервера, лимитированием ответов, DNS Cookies и фильтрацией подменённых адресов.

Как EDNS влияет на DNS Amplification

Изначально размер DNS-ответа по UDP был сильно ограничен. EDNS расширил возможности протокола и позволил клиенту сообщать серверу, какой размер UDP-ответа он готов принять.

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

Но увеличение допустимого UDP-ответа также создало более привлекательные условия для amplification-атак. Подделанный запрос может объявлять поддержку крупного буфера, после чего сервер отправляет на адрес жертвы увеличенный ответ.

Защитная настройка должна учитывать баланс:

• слишком большой UDP-размер повышает потенциал усиления и фрагментации;
• слишком маленький размер увеличивает число переходов на TCP;
• некорректное блокирование фрагментов может нарушать легитимный DNS;
• DNSSEC требует поддержки более крупных ответов;
• MTU сетевого пути может отличаться.

DNS Amplification и фрагментация

Если DNS-ответ превышает допустимый размер IP-пакета для сетевого пути, он может быть разделён на фрагменты. Это создаёт дополнительные проблемы для жертвы и средств защиты.

Система должна:

• принимать и анализировать большое число фрагментов;
• хранить состояние незавершённой сборки;
• сопоставлять части одного пакета;
• удалять неполные наборы после тайм-аута;
• обрабатывать пересекающиеся или некорректные фрагменты.

В результате атака может одновременно расходовать пропускную способность, PPS, память и ресурсы firewall.

Блокировать всю IP-фрагментацию без анализа нежелательно. Это может повредить легитимным DNS-ответам и другим сетевым протоколам. Защита должна учитывать контекст: направление трафика, порт, размер, частоту, состояние запросов и наличие соответствующей исходящей транзакции.

Пример DNS Amplification

Рассмотрим упрощённый сценарий без описания практических способов генерации атакующего трафика.

1. Размер одного DNS-запроса составляет 80 байт.
2. DNS-сервер возвращает ответ размером 1 600 байт.
3. Коэффициент усиления составляет 1 600 / 80 = 20.
4. Атакующая инфраструктура передаёт запросы со скоростью 300 Мбит/с.
5. При идеальных условиях отражённый поток может достичь примерно 6 Гбит/с.

Если целевая инфраструктура подключена каналом 1 Гбит/с, он может быть заполнен задолго до того, как нагрузка станет заметной на самом веб-сервере. Локальное приложение в таком случае может показывать невысокую загрузку CPU, но пользователи всё равно не смогут открыть сайт.

В реальной атаке расчёт будет менее линейным из-за потерь, ограничений рефлекторов, фильтрации, фрагментации и разного размера ответов.

Что является целью атаки

DNS Amplification может быть направлена на разные компоненты.

Цель	Возможный результат
Публичный IP веб-сервера	Заполнение канала и недоступность сайта
Firewall	Перегрузка PPS или таблиц состояния
Маршрутизатор	Рост загрузки и потеря пакетов
Балансировщик	Исчерпание сетевых ресурсов
Авторитетный DNS	Невозможность разрешить доменные имена
Подсеть	Недоступность нескольких сервисов одновременно
IP reverse proxy	Рост входящего UDP-трафика на защитный узел
Канал хостинг-провайдера	Влияние на нескольких клиентов

Как выглядит DNS Amplification в трафике

Большой входящий поток с UDP/53

На адрес жертвы поступает множество DNS-ответов. При этом сама система не отправляла соответствующего количества запросов.

Следует учитывать направление портов. В типичном отражённом потоке портом источника является UDP/53, поскольку пакеты приходят от DNS-серверов. Порт назначения может различаться в зависимости от подделанного запроса.

Большое количество DNS-серверов-источников

Вместо одного атакующего адреса наблюдаются сотни или тысячи IP-адресов. Многие из них действительно являются работающими DNS-серверами и не принадлежат организатору атаки.

Преобладание ответов над запросами

Для обычного рекурсивного клиента DNS-ответам предшествуют запросы. Во время reflection-атаки система получает большое количество нежелательных ответов без соответствующего исходящего трафика.

Одинаковые или похожие ответы

Могут повторяться:

• запрашиваемое доменное имя;
• тип записи;
• размер ответа;
• набор DNS-флагов;
• структура секций;
• значение порта назначения.

Рост фрагментированного UDP-трафика

Если ответы крупные, увеличивается доля IP-фрагментов. При этом последующие фрагменты могут не содержать UDP-заголовок, что усложняет фильтрацию только по порту.

Высокий PPS

Даже если объём атаки не превышает пропускную способность канала, большое количество пакетов в секунду способно перегрузить маршрутизатор, firewall или виртуальный сетевой интерфейс.

Как отличить атаку от легитимного DNS-трафика

Признак	Легитимный DNS	DNS Amplification DDoS
Соотношение запросов и ответов	Ответам предшествуют запросы	Приходит множество неожиданных ответов
Количество источников	Ограниченный набор резолверов	Множество внешних DNS-серверов
Объём трафика	Соответствует обычной активности	Резкий аномальный рост
Назначение системы	Клиент действительно выполняет DNS-запросы	Веб-сервер не должен получать такой поток
Повторяемость	Разные домены и типы запросов	Одинаковые или шаблонные ответы
Фрагментация	Ограниченная	Может резко увеличиться

Наличие UDP/53 само по себе не доказывает атаку. На DNS-сервере такой трафик является нормальным. Важны направление пакетов, состояние транзакций, базовая линия и роль конкретного узла.

Последствия DNS Amplification

Заполнение внешнего канала

Наиболее очевидное последствие — исчерпание пропускной способности. Когда входящий поток достигает ёмкости канала, легитимные пакеты теряются до попадания на сервер.

Перегрузка сетевого оборудования

Маршрутизатор или firewall может иметь достаточную пропускную способность в гигабитах, но не справляться с количеством пакетов в секунду.

Перегрузка механизмов фрагментации

Большое количество фрагментов увеличивает расход памяти и процессорного времени на сопоставление и сборку пакетов.

Недоступность нескольких сервисов

Если сайт, API, почта, VPN и DNS используют один канал или одну подсеть, атака на один IP может повлиять на всю инфраструктуру.

Ложное обвинение DNS-серверов

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

Попадание рефлектора в блок-листы

Владелец неправильно настроенного DNS-сервера может столкнуться с жалобами, блокировкой адреса, ограничениями провайдера и расходами на исходящий трафик.

Защита жертвы DNS Amplification

Фильтрация до попадания трафика в канал

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

Основные варианты:

• постоянная магистральная DDoS-защита;
• перенаправление трафика через scrubbing center;
• фильтрация у хостинг-провайдера;
• FlowSpec или эквивалентные операторские правила;
• Anycast-инфраструктура;
• RTBH как крайняя аварийная мера.

RTBH может остановить влияние атаки на остальную сеть, но делает целевой адрес полностью недоступным. Это средство сдерживания ущерба, а не полноценная фильтрация.

Stateful-фильтрация UDP

Если сервер не предоставляет публичный DNS-сервис, входящие DNS-ответы должны приниматься только как часть ожидаемых транзакций. Неожиданный поток UDP/53 можно отбрасывать на внешнем уровне.

CISA рекомендует использовать stateful UDP inspection и рефлексивные ACL как один из способов уменьшения воздействия UDP-based amplification.

Разделение DNS и веб-инфраструктуры

Авторитетные DNS-серверы не должны находиться на том же IP и зависеть от единственной точки отказа вместе с веб-приложением.

Желательно использовать:

• несколько DNS-узлов;
• разные сети и автономные системы;
• географическое распределение;
• Anycast;
• независимые каналы связи;
• внешний DNS-сервис с DDoS-защитой.

Контроль UDP-фрагментов

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

Мониторинг BPS и PPS

Для обнаружения недостаточно контролировать только гигабиты в секунду. Необходимо отслеживать:

• битрейт;
• пакеты в секунду;
• долю UDP;
• трафик с исходным портом 53;
• число уникальных источников;
• долю фрагментов;
• размеры пакетов;
• потери и ошибки интерфейсов.

Как защитить рекурсивный DNS-сервер от использования в атаке

Ограничить рекурсию

Рекурсивные запросы должны приниматься только от доверенных клиентов:

• локальной сети;
• корпоративных подсетей;
• VPN-пользователей;
• авторизованных серверов;
• заранее определённых адресов.

Если DNS предназначен только для внутреннего использования, UDP/53 и TCP/53 не должны быть доступны со всего интернета.

Разделить рекурсивные и авторитетные функции

По возможности авторитетный публичный DNS и внутренний рекурсивный резолвер должны работать как отдельные сервисы. Это уменьшает риск ошибочного предоставления рекурсии внешним клиентам.

Настроить ACL

Списки контроля доступа определяют, какие сети могут выполнять рекурсивные запросы. После настройки необходимо проверить систему извне, а не только из локальной сети.

Обновлять DNS-программное обеспечение

Обновления устраняют уязвимости, исправляют ошибки обработки пакетов и улучшают защитные механизмы. Особое внимание требуется DNS-службам на маршрутизаторах и давно не обслуживаемых серверах.

Контролировать исходящий трафик

Резкий рост ответов с UDP/53 может означать, что сервер используется как рефлектор. Мониторинг должен учитывать количество запросов, ответы в секунду, уникальных клиентов и общий исходящий объём.

Как защитить авторитетный DNS-сервер

Response Rate Limiting

Response Rate Limiting ограничивает количество похожих ответов, отправляемых предполагаемому клиенту или группе адресов. Это уменьшает объём трафика, который злоумышленник может отразить через сервер.

RRL должен быть настроен аккуратно. Слишком жёсткие ограничения способны повлиять на легитимные резолверы, особенно при большом количестве пользователей за NAT.

DNS Cookies

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

RFC 7873 указывает, что DNS Cookies могут существенно ограничить усиление, доступное атакующему, находящемуся вне сетевого пути между сервером и подделанным адресом. RFC 9018 дополняет механизм рекомендациями для совместимой работы, включая Anycast-наборы серверов.

DNS Cookies не следует считать единственным средством защиты. Не все клиенты их используют, а on-path-угрозы имеют другие возможности.

Anycast

При Anycast один IP-адрес объявляется из нескольких географически распределённых точек. Трафик направляется к ближайшему с точки зрения маршрутизации узлу.

Это позволяет:

• распределить атаку между площадками;
• уменьшить нагрузку на отдельный дата-центр;
• локализовать часть аномального трафика;
• повысить доступность при отказе одного узла.

Anycast увеличивает устойчивость, но не отменяет необходимость фильтрации и достаточной суммарной ёмкости сети.

Минимизация ответов

DNS-сервер не должен добавлять к ответу данные, которые не нужны клиенту. Минимизация дополнительных секций уменьшает средний размер ответа и потенциальный коэффициент усиления.

Несколько DNS-провайдеров

Использование независимых DNS-провайдеров снижает риск полной недоступности домена при проблемах в одной сети. Однако конфигурация зон должна оставаться синхронной.

Что делать во время DNS Amplification-атаки

1. Определить целевой IP. Проверить, атакуется один адрес, подсеть или вся инфраструктура.
2. Измерить BPS и PPS. Это поможет понять, заполнен канал или перегружено оборудование.
3. Проверить протокол и порты. Выделить UDP-трафик с исходным портом 53.
4. Проверить фрагментацию. Определить долю начальных и последующих IP-фрагментов.
5. Сравнить запросы и ответы. Убедиться, что входящие ответы не соответствуют исходящим DNS-запросам.
6. Обратиться к провайдеру. При переполнении канала локальная фильтрация уже недостаточна.
7. Активировать upstream-защиту. Трафик должен очищаться до входа в целевую сеть.
8. Сохранить телеметрию. Нужны NetFlow, PCAP-фрагменты, графики и события firewall.
9. Проверить другие IP. Атакующий может переключиться на соседний адрес или DNS-инфраструктуру.
10. Не блокировать рефлекторы навсегда. Многие из них являются невольными участниками атаки.

Какие данные передать провайдеру

• точное время начала атаки;
• целевой IP-адрес или подсеть;
• текущий и максимальный объём в Гбит/с;
• текущий и максимальный PPS;
• используемый протокол;
• исходный и целевой порты;
• доля фрагментированных пакетов;
• несколько примеров заголовков пакетов;
• список крупнейших сетей-источников;
• график изменения трафика;
• информация о переключении векторов.

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

Как TrafficVeil помогает при DNS Amplification

TrafficVeil использует собственную DNS-инфраструктуру и полностью проксирует подключённые сайты. Это уменьшает зависимость сайта от единственного origin-адреса и позволяет не публиковать его как основной адрес веб-ресурса.

Для защиты origin необходимо выполнить два условия:

1. В DNS должны использоваться только адреса защитной инфраструктуры.
2. Origin должен принимать HTTP/HTTPS-соединения исключительно с разрешённых адресов TrafficVeil.

Ограничения необходимо применять одновременно для IPv4 и IPv6. Если настоящий IP остаётся доступным напрямую, злоумышленник может обойти reverse proxy и направить DNS Amplification непосредственно на канал origin-сервера.

Важно разделять уровни защиты. WAF, ML-детекция ботов, поведенческий анализ и L7 DDoS-защита работают с HTTP/HTTPS-запросами. DNS Amplification представляет собой объёмную L3/L4-атаку, поэтому при переполнении канала требуется фильтрация у сетевого провайдера или в scrubbing center.

TrafficVeil может скрыть origin и защитить прикладной уровень, но доступный напрямую IP-адрес сервера, маршрутизатора или сторонней DNS-службы должен иметь отдельную сетевую DDoS-защиту.

Типичные ошибки защиты

Фильтрация только на сервере

Если атака заполнила канал, пакеты не доходят до локального firewall в управляемом объёме. Фильтрация должна выполняться выше по сети.

Блокировка только UDP/53

Фильтр по исходному порту помогает против части DNS-ответов, но не решает проблему переполненного внешнего канала. Кроме того, защита должна учитывать фрагменты, в которых UDP-заголовок отсутствует.

Блокировка всех DNS-серверов

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

Открытая рекурсия «для удобства»

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

Отключение DNSSEC вместо устранения причины

DNSSEC может увеличивать размер отдельных ответов, но обеспечивает проверку их подлинности. Правильная стратегия — ограничить злоупотребление сервером, а не отказываться от защиты DNS-данных.

Защита только сайта

Даже если HTTP-трафик проходит через reverse proxy, открытые SSH, VPN, почтовые, DNS- и административные адреса могут раскрывать origin или становиться отдельными целями.

Отсутствие мониторинга PPS

Небольшие пакеты могут перегрузить оборудование по количеству пакетов ещё до заполнения канала в гигабитах.

Чек-лист для владельца сайта

• Скрыт ли реальный IP origin-сервера?
• Закрыт ли прямой HTTP/HTTPS-доступ к origin?
• Проверены ли ограничения для IPv4 и IPv6?
• Есть ли upstream-защита от UDP Flood?
• Защищены ли публичные DNS-серверы?
• Разделены ли DNS и веб-инфраструктура?
• Используются ли несколько DNS-узлов?
• Отслеживаются ли BPS и PPS?
• Контролируется ли доля UDP-фрагментов?
• Настроены ли уведомления об аномальном трафике?
• Известен ли порядок связи с провайдером?
• Сохраняются ли NetFlow и журналы firewall?
• Проверены ли старые DNS-записи и поддомены?
• Защищены ли административные IP-адреса?

Чек-лист для владельца DNS-сервера

• Действительно ли сервер должен быть доступен из интернета?
• Ограничена ли рекурсия доверенными сетями?
• Разделены ли рекурсивная и авторитетная функции?
• Закрыт ли внешний доступ к внутреннему резолверу?
• Настроены ли ACL для UDP/53 и TCP/53?
• Используется ли Response Rate Limiting?
• Поддерживаются ли DNS Cookies?
• Минимизирован ли размер дополнительных данных в ответах?
• Обновлено ли DNS-программное обеспечение?
• Контролируется ли исходящий трафик с порта 53?
• Есть ли уведомление о резком росте ответов?
• Проверена ли конфигурация извне?
• Используется ли Anycast или распределённая инфраструктура?
• Настроена ли операторская DDoS-защита?

Вывод

DNS Amplification является опасной разновидностью DRDoS, потому что позволяет совместить подмену адреса, распределение трафика между множеством DNS-серверов и увеличение размера ответов. Жертва видит поток от реальных DNS-узлов, а непосредственный источник поддельных запросов остаётся за пределами её сети.

На уровне интернета основным способом уменьшения таких атак является фильтрация подменённых исходных адресов. Владельцы рекурсивных DNS-серверов должны закрывать рекурсию для посторонних, а операторы авторитетного DNS — использовать RRL, DNS Cookies, Anycast, минимизацию ответов и магистральную защиту.

Владелец сайта должен скрыть origin, разделить DNS- и веб-инфраструктуру, контролировать IPv4 и IPv6 и заранее подключить upstream DDoS-фильтрацию. Если отражённый поток уже заполняет внешний канал, настройки веб-сервера, WAF или локального firewall не смогут самостоятельно восстановить доступность.