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

NTP Amplification — это отражённая DDoS-атака, при которой злоумышленник использует публично доступные NTP-серверы для создания большого потока UDP-трафика в направлении жертвы. Небольшие запросы отправляются с подменённым исходным IP-адресом, а ответы приходят на адрес атакуемого сервера, маршрутизатора или сети.

NTP — Network Time Protocol — предназначен для синхронизации времени между компьютерами, серверами, маршрутизаторами, сетевым оборудованием и другими устройствами. Стандартный NTP-сервис использует порт UDP/123. Назначение этого порта зафиксировано в спецификации NTPv4 и реестре IANA.

Обычный обмен временем не обязан создавать большое усиление. Наиболее опасные исторические варианты NTP Amplification были связаны с устаревшими служебными запросами, которые позволяли получить значительно больше данных, чем содержалось в запросе. В первую очередь речь идёт о старом механизме monlist, а также об открытых управляющих интерфейсах Mode 6 и Mode 7.

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

Что такое NTP

NTP — сетевой протокол синхронизации времени. Он помогает системам поддерживать согласованные часы, несмотря на задержки сети, неточность локальных таймеров и различия между источниками времени.

Корректное время необходимо для работы:

• TLS-сертификатов;
• Kerberos и других протоколов аутентификации;
• электронных подписей;
• журналов безопасности;
• баз данных;
• распределённых систем;
• сетевого оборудования;
• финансовых операций;
• планировщиков задач;
• мониторинга и расследования инцидентов.

Клиент NTP отправляет серверу запрос с временными метками, получает ответ и рассчитывает смещение локальных часов и сетевую задержку. Базовый обмен относительно компактен и не предназначен для передачи больших объёмов данных.

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

Что такое NTP Reflection

NTP Reflection — это отражение NTP-ответов через сторонний сервер на IP-адрес жертвы.

Упрощённый механизм выглядит так:

1. Злоумышленник выбирает публичный NTP-сервер.
2. Формирует UDP-запрос к порту 123.
3. Подменяет исходный адрес на IP-адрес жертвы.
4. NTP-сервер получает запрос и формирует ответ.
5. Ответ отправляется не реальному источнику, а на подставленный адрес.
6. Жертва получает UDP-пакеты, которые не запрашивала.

Если в атаке задействованы тысячи NTP-серверов, на стороне жертвы появляется распределённый поток от множества реальных адресов. Такая схема относится к DRDoS — Distributed Reflection Denial of Service.

Что такое NTP Amplification

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

Коэффициент усиления приблизительно рассчитывается по формуле:

Коэффициент усиления = размер ответа / размер запроса

Если запрос занимает 80 байт, а сервер возвращает суммарно 4 000 байт, усиление без дополнительной корректировки на сетевые заголовки составит:

4 000 / 80 = 50

При исходящем потоке атакующего 200 Мбит/с теоретический объём отражённого трафика с коэффициентом 50 может достичь 10 Гбит/с.

Это упрощённый расчёт. Реальная мощность зависит от:

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

Поэтому нельзя утверждать, что любая NTP-атака имеет фиксированное усиление. Особенно некорректно переносить показатели старого monlist на современные NTP-серверы.

Разница между NTP Reflection и NTP Amplification

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

В большинстве реальных атак оба механизма объединяются. Поэтому используются названия NTP Reflection Amplification, NTP Amplification DDoS и NTP DRDoS.

Почему для атаки подходит UDP

NTP в стандартном сценарии использует UDP. Этот транспорт не устанавливает соединение перед обменом данными и не выполняет трёхэтапное рукопожатие, как TCP.

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

Для reflection-атаки это даёт несколько преимуществ:

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

Корневая проблема отражённых UDP-атак находится не только на уровне NTP. Они становятся возможными из-за сетей, пропускающих пакеты с поддельными адресами источника.

BCP 38 рекомендует операторам применять фильтрацию, которая не позволяет клиенту отправлять пакеты с адресами, не принадлежащими его сети. Массовое внедрение такой проверки значительно сократило бы возможности NTP, DNS, CLDAP, Memcached и других UDP reflection-атак.

Что такое NTP Mode 3 и Mode 4

Поле Mode в NTP-пакете указывает назначение сообщения. Для обычной синхронизации времени наиболее важны:

• Mode 3 — запрос клиента;
• Mode 4 — ответ сервера.

Клиент отправляет компактный запрос Mode 3, после чего сервер возвращает Mode 4 с временными метками и служебными параметрами.

Обычный ответ синхронизации имеет сопоставимый с запросом размер. Поэтому стандартный обмен Mode 3/4 обычно не создаёт такого усиления, с которым исторически ассоциируется NTP Amplification.

RFC 8633 рекомендует проверять доступность NTP-сервиса обычным запросом Mode 3, а не открывать внешнему миру расширенные управляющие функции.

Что такое NTP Mode 6

Mode 6 применяется для управляющих сообщений NTP. Через такие сообщения администратор или диагностический клиент может получать сведения о состоянии сервера, ассоциациях, системных переменных и других параметрах.

Эта информация полезна при эксплуатации NTP-инфраструктуры, но публичный доступ к управляющему интерфейсу создаёт риски:

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

RFC 9327 формализует протокол управляющих сообщений NTPv4 Mode 6 и отдельно отмечает риск UDP amplification при обработке некоторых управляющих запросов. Документ также указывает, что исторический Mode 7 monlist создавал особенно крупные ответы на небольшие запросы.

Что такое NTP Mode 7

Mode 7 исторически использовался для закрытых управляющих сообщений конкретных реализаций NTP. Он не является обычным запросом синхронизации времени.

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

Такой механизм идеально подходил для усиления:

1. злоумышленник отправлял маленький запрос;
2. в качестве источника указывал IP жертвы;
3. сервер формировал большой список;
4. список отправлялся несколькими пакетами;
5. жертва получала трафик, многократно превышающий запрос.

Что такое monlist

monlist — устаревшая диагностическая команда старых реализаций ntpd. Она была связана с механизмом мониторинга и могла возвращать сведения о клиентах, недавно обращавшихся к NTP-серверу.

Главная проблема состояла в трёх свойствах:

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

Уязвимость получила идентификатор CVE-2013-5211. В период массового использования monlist коэффициент усиления мог быть очень высоким. В исторических материалах CISA для уязвимых NTP-сервисов приводился показатель порядка 556,9, но это оценка конкретного устаревшего сценария, а не характеристика всего современного NTP.

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

Почему NTP Amplification всё ещё остаётся актуальной

Пик атак через monlist пришёлся на период, когда в интернете находилось большое количество уязвимых NTP-серверов. С тех пор программное обеспечение и рекомендации по настройке существенно изменились.

Однако полностью проблема не исчезла по нескольким причинам:

• устаревшие серверы продолжают работать без обновлений;
• встроенные устройства могут использовать старую реализацию NTP;
• промышленное оборудование обновляется редко;
• управляющие запросы могут быть доступны из интернета;
• ACL настраиваются неправильно;
• открытый UDP/123 ошибочно считается безопасным;
• устройства могут быть забыты после изменения инфраструктуры;
• часть сетей по-прежнему разрешает IP spoofing.

Кроме того, даже умеренное усиление становится опасным при наличии тысяч рефлекторов и мощной инфраструктуры отправителя.

Какие устройства становятся NTP-рефлекторами

Источником отражённого трафика может быть не только обычный Linux-сервер. Публичный NTP-сервис встречается на разных устройствах:

• виртуальных и выделенных серверах;
• маршрутизаторах;
• межсетевых экранах;
• VPN-шлюзах;
• камерах видеонаблюдения;
• сетевых хранилищах;
• телекоммуникационном оборудовании;
• промышленных контроллерах;
• серверах мониторинга;
• гипервизорах;
• устаревших IoT-устройствах.

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

Пример расчёта NTP Amplification

Рассмотрим условную атаку, не привязанную к конкретной уязвимой команде.

1. Средний размер запроса с сетевыми заголовками — 76 байт.
2. Суммарный размер ответов — 3 800 байт.
3. Приблизительный коэффициент усиления — 3 800 / 76 = 50.
4. Злоумышленник генерирует запросы со скоростью 400 Мбит/с.
5. Теоретический поток на жертву — около 20 Гбит/с.

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

Реальный объём обычно ниже теоретического из-за сетевых потерь, ограничений рефлекторов, фильтрации, заполнения их каналов и неодинаковых размеров ответов.

На какие цели направляется NTP Amplification

Цель	Возможное последствие
IP-адрес веб-сервера	Заполнение канала и недоступность сайта
Reverse proxy	Перегрузка сетевого интерфейса или площадки
Firewall	Перегрузка PPS, CPU или таблиц состояния
Маршрутизатор	Потери пакетов и рост задержки
Балансировщик	Недоступность нескольких приложений
DNS-инфраструктура	Нарушение разрешения доменных имён
VPN-шлюз	Потеря удалённого доступа
Целая подсеть	Одновременная недоступность группы сервисов

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

Резкий рост UDP-трафика

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

Исходный порт UDP/123

В отражённой атаке ответы обычно приходят с порта NTP-сервера — UDP/123. Порт назначения зависит от параметров поддельного запроса и может быть как 123, так и другим UDP-портом.

Поэтому фильтрация только трафика, направленного на порт 123, не всегда достаточна. Важно анализировать также исходный порт.

Множество реальных NTP-серверов

Источниками выглядят серверы, маршрутизаторы и устройства из разных автономных систем и стран. Многие из них являются невольными участниками атаки.

Отсутствие исходящих NTP-запросов

Жертва получает большое количество NTP-ответов, хотя не отправляла соответствующих запросов. Для stateful-системы это один из наиболее сильных признаков отражения.

Повторяющийся тип ответа

В пакетах могут совпадать:

• NTP Mode;
• размер ответа;
• служебные поля;
• порт назначения;
• структура управляющего сообщения;
• частота поступления пакетов.

Высокий PPS

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

Как отличить атаку от нормальной синхронизации времени

Признак	Нормальный NTP-трафик	NTP Amplification
Запросы и ответы	Ответ соответствует запросу клиента	Поступают неожиданные ответы
Количество серверов	Небольшой заданный пул	Сотни или тысячи источников
Частота	Периодическая синхронизация	Массовый непрерывный поток
Объём	Небольшой	Может достигать гигабит и терабит
Тип сообщений	Преимущественно Mode 3/4	Возможны управляющие ответы Mode 6/7
Направление	Клиент обращается к выбранным серверам	Ответы приходят от неизвестных узлов

Для веб-сервера, который не выполняет функцию NTP-клиента или сервера, крупный входящий поток с UDP/123 является явной аномалией. Для инфраструктуры времени требуется более глубокий анализ состояния запросов, разрешённых клиентов и типов сообщений.

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

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

Отражённый поток может превысить пропускную способность подключения. В этом случае локальные средства защиты не помогут: канал заполнен до попадания трафика на сервер.

Перегрузка по PPS

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

Перегрузка firewall

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

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

Атака на один адрес может повлиять на весь канал, подсеть или виртуальную инфраструктуру, где находятся другие проекты.

Рост расходов

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

Репутационный ущерб владельцу рефлектора

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

Защита жертвы от NTP Amplification

Upstream-фильтрация

Основная защита от объёмной атаки должна располагаться до узкого места. Если канал организации равен 1 Гбит/с, а атака создаёт 20 Гбит/с, firewall внутри этой сети уже не сможет восстановить доступность.

Используются:

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

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

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

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

На границе сети полезно проверять:

• ожидалось ли UDP-сообщение;
• обращался ли клиент к данному серверу;
• совпадают ли адреса и порты;
• соответствует ли частота нормальной синхронизации;
• не используется ли управляющий NTP Mode;
• не превышен ли лимит новых UDP-потоков.

Раздельные правила для клиента и сервера

NTP-клиенту обычно не требуется принимать UDP/123 от всего интернета. Он должен взаимодействовать только с определёнными серверами времени.

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

Фильтрация по NTP Mode

При наличии поддержки на сетевом оборудовании можно отдельно анализировать и ограничивать управляющие сообщения Mode 6 и Mode 7, не нарушая обычную синхронизацию Mode 3/4.

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

Ограничение скорости

Rate limiting снижает количество ответов, которое один сервер отправляет клиенту или подсети. Порог необходимо выбирать с учётом реальных клиентов, NAT и особенностей NTP.

Как защитить свой NTP-сервер от использования в DDoS

Обновить NTP-реализацию

Первый шаг — установить поддерживаемую версию NTP-службы или обновить прошивку устройства. Старый сервер может содержать не только monlist, но и другие известные уязвимости.

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

Запретить monlist и устаревший Mode 7

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

Ограничить Mode 6

Управляющие запросы должны приниматься только от административных адресов или внутренней сети. Для обычных клиентов достаточно возможности синхронизации времени.

RFC 8633 рассматривает Mode 6 и Mode 7 как потенциальные векторы amplification и рекомендует ограничивать удалённые запросы состояния.

Настроить noquery

В классическом ntpd директива noquery запрещает внешние управляющие запросы через ntpq и ntpdc, не обязательно запрещая обычную синхронизацию времени.

Официальная документация NTP описывает noquery как ограничение управляющих запросов, а также поддерживает дополнительные параметры доступа, включая nomodify, notrap и ограничения частоты.

Конкретный синтаксис зависит от реализации и версии. Нельзя без проверки копировать один набор директив между ntpd, NTPsec, Chrony, сетевым устройством и проприетарной системой.

Ограничить список клиентов

Если NTP-сервис предназначен только для организации, доступ следует разрешить корпоративным подсетям, VPN или отдельным серверам.

Если сервер является публичным, необходимо:

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

Включить rate limiting

Официальные рекомендации NTP предусматривают ограничения частоты и механизм Kiss-o’-Death, с помощью которого сервер сообщает клиенту о необходимости уменьшить интенсивность запросов.

Rate limiting должен предотвращать массовую генерацию ответов, но не блокировать нормальных клиентов за NAT. Несколько устройств могут обращаться с одного внешнего IP-адреса.

Контролировать интерфейсы прослушивания

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

Следует проверить:

• публичный IPv4-адрес;
• публичный IPv6-адрес;
• VPN-интерфейсы;
• контейнерные сети;
• внутренние VLAN;
• резервные интерфейсы;
• адреса управления.

Не забывать про IPv6

Ограничения, применённые только к IPv4, не защищают NTP-сервис на IPv6. Необходимо проверить firewall, ACL, интерфейсы прослушивания и управляющие запросы для обоих протоколов.

Как безопасно построить корпоративную синхронизацию времени

Вместо разрешения каждому устройству обращаться к произвольным публичным NTP-серверам можно использовать иерархическую схему:

1. Несколько внутренних серверов получают время от доверенных внешних источников.
2. Серверы сравнивают несколько независимых источников.
3. Рабочие станции и сетевые устройства синхронизируются с внутренними серверами.
4. Firewall ограничивает прямой внешний NTP для обычных устройств.
5. Управляющие функции доступны только администраторам.

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

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

1. Определить атакуемый адрес

Необходимо выяснить, направлен ли поток на один IP, несколько адресов или всю подсеть.

2. Измерить BPS и PPS

Битрейт показывает нагрузку на канал, а PPS помогает оценить нагрузку на маршрутизатор и firewall.

3. Проверить порты и режимы NTP

Следует определить:

• долю UDP-трафика;
• долю пакетов с исходным портом 123;
• целевые порты;
• NTP Mode;
• средний размер пакетов;
• число уникальных источников.

4. Проверить состояние запросов

Если организация не отправляла запросы этим NTP-серверам, входящие ответы являются отражёнными.

5. Подключить провайдера

При заполнении канала необходимо активировать фильтрацию до точки подключения организации. Локальное изменение firewall не освободит уже перегруженную линию.

6. Сохранить данные

Для анализа полезны:

• NetFlow, sFlow или IPFIX;
• небольшой PCAP-фрагмент;
• графики BPS и PPS;
• события firewall;
• список автономных систем;
• распределение размеров пакетов;
• хронология переключения векторов.

7. Проверить другие адреса

После фильтрации атакующий может сменить цель: направить трафик на origin, DNS, VPN, почтовый шлюз или соседний IP.

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

Данные	Для чего нужны
Время начала атаки	Поиск нужного участка телеметрии
Целевой IP или подсеть	Точная активация фильтрации
Максимальный BPS	Оценка объёмной нагрузки
Максимальный PPS	Оценка пакетной нагрузки
Протокол и порты	Создание профиля фильтрации
NTP Mode	Выделение управляющих и обычных сообщений
Крупнейшие ASN источников	Агрегация и анализ рефлекторов
PCAP-фрагмент	Проверка структуры пакетов
Нормальный профиль NTP	Снижение ложных блокировок

Как обнаружить, что ваш сервер используется как рефлектор

Признаками злоупотребления собственным NTP-сервисом являются:

• резкий рост входящих запросов на UDP/123;
• ещё больший рост исходящего трафика с UDP/123;
• запросы из большого количества случайных сетей;
• необычная доля Mode 6 или Mode 7;
• повторяющиеся диагностические запросы;
• рост нагрузки на процесс ntpd;
• жалобы от владельцев атакуемых адресов;
• уведомление хостинг-провайдера;
• рост расходов на исходящий трафик;
• попадание IP-адреса в списки открытых NTP-сервисов.

Характерный показатель — отношение исходящего NTP-трафика к входящему. Если маленький поток запросов создаёт намного больший поток ответов, сервер потенциально выполняет роль усилителя.

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

TrafficVeil полностью проксирует HTTP/HTTPS-трафик подключённых сайтов, предоставляет собственный DNS, автоматический SSL, WAF, ML-детекцию ботов, rate limiting и защиту от DDoS на прикладном уровне.

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

Для этого необходимо:

• не публиковать адрес origin в основных DNS-записях;
• закрыть прямой доступ к портам 80 и 443;
• разрешить соединения только от TrafficVeil;
• применить ограничения для IPv4 и IPv6;
• проверить старые записи и поддомены;
• не размещать на публичном origin лишние UDP-сервисы.

Однако NTP Amplification относится к объёмным L3/L4-атакам. Если UDP-поток направлен на известный IP origin-сервера и заполняет его канал, WAF и HTTP rate limiting не смогут обработать такую атаку. Потребуется сетевой Anti-DDoS у хостинг-провайдера или оператора связи.

TrafficVeil защищает веб-уровень и помогает изолировать origin, но не заменяет upstream-фильтрацию UDP-трафика на открытые сетевые адреса.

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

Считать любой открытый NTP уязвимым для огромного усиления

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

Открыть UDP/123 для всего интернета без необходимости

Корпоративному серверу обычно достаточно принимать запросы от внутренних сетей и VPN.

Заблокировать только порт назначения 123

При отражении исходным портом ответа является UDP/123, но порт назначения может отличаться.

Настроить только IPv4

NTP-служба может продолжить принимать управляющие запросы через публичный IPv6-адрес.

Использовать старую прошивку сетевого устройства

На маршрутизаторе или контроллере может работать устаревшая NTP-реализация, которую невозможно исправить изменением настроек современного сервера.

Фильтровать только локально

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

Полностью отключать синхронизацию времени

Некорректное время может нарушить аутентификацию, сертификаты и расследование инцидентов. Нужно защищать NTP, а не отказываться от него.

Чек-лист защиты сайта и сети

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

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

• Требуется ли публичный доступ к NTP?
• Используется ли поддерживаемая версия ПО?
• Удалён или отключён ли monlist?
• Ограничен ли Mode 6?
• Заблокирован ли внешний Mode 7?
• Применяется ли noquery или аналог?
• Разрешены ли административные запросы только доверенным адресам?
• Настроен ли rate limiting?
• Контролируется ли исходящий UDP/123?
• Проверены ли публичные IPv4- и IPv6-интерфейсы?
• Обновлена ли прошивка сетевых устройств?
• Отслеживается ли соотношение запросов и ответов?
• Настроены ли уведомления о росте NTP-трафика?
• Проверена ли конфигурация с внешней точки?

Вывод

NTP Amplification объединяет три компонента: UDP, подмену исходного IP-адреса и NTP-сервер, способный сформировать ответ больше запроса. Наиболее мощные исторические атаки были связаны с устаревшим запросом monlist и открытыми управляющими режимами.

Современный NTP-сервер не должен предоставлять такие функции произвольным внешним клиентам. Владелец сервера обязан обновлять программное обеспечение, ограничивать Mode 6 и Mode 7, применять ACL и rate limiting, контролировать IPv4 и IPv6 и отслеживать исходящий трафик.

Для жертвы основной защитой остаётся фильтрация выше по сети. Если отражённые UDP-пакеты уже заполнили канал, WAF, веб-сервер и локальный firewall не способны восстановить доступность. Поэтому защита сайта должна объединять скрытый origin, reverse proxy, прикладную фильтрацию и отдельный сетевой Anti-DDoS.