SNMP Amplification и SNMP Reflection DDoS: как работает атака?

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

Небольшой SNMP-запрос отправляется сетевому устройству с подменённым исходным IP-адресом. Маршрутизатор, коммутатор, сервер, принтер или другое устройство формирует более крупный ответ и отправляет его не злоумышленнику, а на адрес жертвы.

Атака сочетает два механизма:

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

Особенно опасны устройства, использующие SNMPv2c со слабой или стандартной community string, принимающие запросы от произвольных внешних адресов и позволяющие выполнять операции, возвращающие большое количество объектов MIB.

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

Что такое SNMP

SNMP — Simple Network Management Protocol — протокол мониторинга и управления сетевыми устройствами.

С помощью SNMP система мониторинга может получать:

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

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

Основные компоненты SNMP

SNMP Manager

Manager — система управления или мониторинга, которая отправляет запросы и обрабатывает ответы. Это может быть Zabbix, PRTG, LibreNMS, SolarWinds, Nagios или собственная система организации.

SNMP Agent

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

MIB

MIB — Management Information Base — структура объектов, которые можно запрашивать через SNMP. Каждый параметр имеет идентификатор OID.

Trap Receiver

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

Какие порты использует SNMP

Порт	Транспорт	Назначение
161	UDP	Запросы к SNMP-агенту и ответы
162	UDP	Приём SNMP Trap и уведомлений

RFC 3417 указывает, что SNMP command responder прослушивает UDP/161, а получатель уведомлений — UDP/162.

В реальных системах могут применяться нестандартные порты и другие транспортные модели, однако для SNMP Amplification наиболее характерен UDP/161.

Как работает обычный SNMP-обмен

Система мониторинга отправляет SNMP-агенту запрос с одним или несколькими OID. Агент проверяет параметры доступа, получает значения и возвращает Response-PDU.

Для эффективного получения больших таблиц в SNMPv2 был добавлен запрос GETBULK. Он позволяет получить несколько последовательных объектов за одну транзакцию и уменьшает число отдельных запросов.

В доверенной сети это полезно: мониторинг может быстрее получить статистику по интерфейсам или другим таблицам. Но открытый SNMP-агент способен превратить небольшой GETBULK-запрос в значительно более крупный ответ.

Какие операции используются в SNMP

Операция	Назначение	Потенциал усиления
GET	Получить конкретный объект	Обычно небольшой
GETNEXT	Получить следующий объект MIB	Обычно ограниченный
GETBULK	Получить набор последовательных объектов	Повышенный
SET	Изменить значение или конфигурацию	Не основной amplification-вектор, но критичный риск
RESPONSE	Ответ агента на запрос	Отражается на адрес жертвы
TRAP	Асинхронное уведомление	Отдельный тип SNMP-трафика
INFORM	Подтверждаемое уведомление	Не основной классический вектор

Что такое GETBULK

GETBULK — операция SNMPv2, предназначенная для эффективного извлечения большого объёма управленческой информации.

Вместо множества запросов GETNEXT менеджер может попросить агент вернуть несколько последовательных значений MIB в одном ответе.

RFC 3416 описывает GetBulkRequest-PDU и процедуру формирования ответа на такой запрос.

Размер ответа зависит от:

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

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

Как работает SNMP Reflection

SNMP Reflection использует отсутствие установления соединения в UDP.

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

1. Злоумышленник находит SNMP-агенты, доступные из интернета.
2. Формирует небольшой запрос на UDP/161.
3. Подменяет исходный IP-адрес на адрес жертвы.
4. SNMP-агент принимает запрос.
5. Агент формирует Response-PDU.
6. Ответ отправляется на подменённый адрес.
7. Множество агентов создаёт распределённый поток.

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

Как работает SNMP Amplification

Усиление возникает, когда SNMP-ответ значительно превышает запрос по размеру.

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

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

Рассмотрим упрощённый пример:

1. Размер SNMP-запроса составляет 100 байт.
2. Устройство возвращает ответ размером 2 500 байт.
3. Коэффициент усиления составляет 2 500 / 100 = 25.
4. Злоумышленник генерирует запросы со скоростью 400 Мбит/с.
5. Теоретический отражённый поток может приблизиться к 10 Гбит/с.

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

CISA включает SNMP в число UDP-сервисов, которые могут использоваться для отражённых атак с усилением.

От чего зависит коэффициент усиления

SNMP не имеет одного постоянного коэффициента. Результат зависит от конкретного агента и запроса.

На усиление влияют:

• версия SNMP;
• тип PDU;
• GETBULK-параметры;
• запрошенная ветка MIB;
• количество объектов;
• объём возвращаемых значений;
• ограничения агента;
• MTU;
• IP-фрагментация;
• сетевые потери;
• rate limiting;
• скорость устройства.

Усиление у SNMP обычно ниже экстремальных сценариев Memcached, но большое количество доступных агентов и стабильные ответы делают вектор практически значимым.

Версии SNMP и их безопасность

SNMPv1

Первая версия протокола использует community string как простой механизм контроля доступа. Данные передаются без шифрования.

Основные проблемы:

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

SNMPv2c

SNMPv2c добавляет новые операции и улучшает производительность, включая GETBULK, но сохраняет модель доступа на основе community string.

Для amplification SNMPv2c особенно интересен сочетанием:

• UDP;
• отсутствия полноценной проверки источника;
• возможности крупных GETBULK-ответов;
• распространённых стандартных community strings;
• широкой поддержки сетевыми устройствами.

SNMPv3

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

RFC 3414 определяет User-based Security Model SNMPv3. Среди её целей — проверка целостности, подтверждение пользователя, контроль актуальности сообщения и защита данных от раскрытия.

На практике рекомендуется использовать уровень authPriv, при котором сообщения аутентифицируются и шифруются.

Однако переход на SNMPv3 не отменяет сетевые ограничения. Агент управления всё равно не должен принимать запросы от всего интернета.

Защищает ли SNMPv3 от amplification

Правильно настроенная аутентификация значительно усложняет получение крупных ответов неавторизованным отправителем. Но SNMPv3 нельзя считать заменой firewall и ACL.

Причины:

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

Оптимальная схема объединяет SNMPv3, ACL, приватную сеть, отдельный management plane и rate limiting.

Что такое community string

В SNMPv1 и SNMPv2c community string выполняет роль общего секрета, определяющего доступ к агенту.

Часто используются два типа доступа:

• Read-only — получение данных мониторинга;
• Read-write — изменение параметров устройства.

Распространённая ошибка — оставить стандартное или простое значение. Даже сложная community string не делает безопасным публичный UDP/161, потому что:

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

Почему публичный SNMP опасен помимо DDoS

Инвентаризация инфраструктуры

Через SNMP можно получить модель, версию ОС, список интерфейсов, адреса и другие сведения.

Раскрытие топологии

MIB может содержать маршруты, таблицы соседей, ARP-записи, VLAN и информацию о подключённых устройствах.

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

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

Изменение конфигурации

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

Кража конфигурации

Некоторые сценарии злоупотребления SNMP используются для запуска экспорта конфигурации через другие протоколы.

Прямой DoS SNMP-агента

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

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

В отражённых атаках могут участвовать:

• маршрутизаторы;
• коммутаторы;
• firewall;
• точки беспроводного доступа;
• контроллеры Wi-Fi;
• серверы;
• гипервизоры;
• принтеры и МФУ;
• IP-камеры;
• сетевые хранилища;
• источники бесперебойного питания;
• телекоммуникационное оборудование;
• промышленные контроллеры;
• IoT-устройства.

Часто SNMP включается производителем или интегратором для мониторинга, но после установки ограничения по адресам не настраиваются.

Как выглядит SNMP Amplification со стороны жертвы

Трафик с исходного UDP-порта 161

Классические ответы SNMP приходят с UDP/161. Целевой порт зависит от исходного порта поддельного запроса.

Множество сетевых устройств

Источники распределены по разным ASN, странам и типам сетей.

Response-PDU без запросов

Жертва получает ответы, хотя не обращалась к соответствующим SNMP-агентам.

Повторяющаяся ASN.1/BER-структура

SNMP использует ASN.1 и BER-кодирование. В ответах наблюдается повторяющаяся структура, OID и значения.

Фрагментация

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

Рост BPS и PPS

Атака расходует канал и ресурсы обработки пакетов одновременно.

Как отличить атаку от легитимного SNMP

Признак	Легитимный SNMP	SNMP Amplification
Источники	Известные управляемые устройства	Множество внешних адресов
Получатели	Заданные серверы мониторинга	Произвольная жертва
Наличие запроса	Ответ соответствует запросу	Ответы приходят без запросов
Частота	Соответствует интервалу мониторинга	Массовый непрерывный поток
Сеть	Management VLAN, VPN или приватная сеть	Публичный интернет
Разнообразие устройств	Известная инфраструктура	Случайные модели и производители

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

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

Заполнение интернет-канала

Отражённый поток может превысить ёмкость внешнего подключения. Легитимный трафик теряется до достижения серверов.

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

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

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

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

Перегрузка SNMP-агента

Устройство-рефлектор тратит CPU и исходящую полосу на обработку запросов и формирование ответов.

Нарушение мониторинга

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

Компрометация управляемого устройства

Открытый SNMP с read-write-доступом способен привести к изменениям конфигурации и более серьёзному инциденту.

Как защитить жертву SNMP Amplification

Использовать upstream-фильтрацию

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

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

• постоянная Anti-DDoS-защита;
• scrubbing center;
• операторские ACL;
• FlowSpec;
• Anycast;
• RTBH как аварийная мера.

Фильтровать исходный UDP-порт 161

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

Важно различать:

• целевой UDP/161 — запрос к локальному SNMP-агенту;
• исходный UDP/161 — ответ внешнего агента.

Использовать stateful-фильтрацию

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

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

Ограничивать фрагменты

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

Разделить monitoring и public network

Система мониторинга должна находиться в отдельном сегменте и обращаться к устройствам через защищённые внутренние маршруты, VPN или management network.

Как защитить собственный SNMP-агент

Не публиковать UDP/161 всему интернету

Доступ следует разрешать только конкретным IP-адресам серверов мониторинга.

Для удалённых площадок используются:

• site-to-site VPN;
• выделенные каналы;
• приватные облачные сети;
• management VRF;
• защищённый jump-сегмент;
• централизованные collectors.

Использовать ACL

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

Cisco рекомендует использовать ACL вместе с SNMPv3 и ограничивать доступ выбранными адресами систем управления.

Перейти на SNMPv3 authPriv

Уровень authPriv обеспечивает аутентификацию и конфиденциальность сообщения.

Необходимо использовать:

• отдельных пользователей мониторинга;
• современные алгоритмы, поддерживаемые устройством;
• разные секреты для разных контуров;
• минимально необходимые SNMP views;
• read-only-права там, где изменение не требуется.

Отключить SNMPv1 и SNMPv2c

Если все системы поддерживают SNMPv3, устаревшие версии следует отключить. CISA рекомендует отказываться от ненужных и небезопасных протоколов, включая SNMPv1/v2c.

Изменить стандартные community strings

Если временно требуется SNMPv2c, нельзя использовать общеизвестные или заводские значения. Однако смена community string является временным снижением риска, а не полноценной заменой SNMPv3 и ACL.

Использовать SNMP Views

View ограничивает набор MIB-объектов, доступных пользователю. Сервер мониторинга должен видеть только действительно необходимые данные.

Это снижает:

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

Запретить read-write без необходимости

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

Настроить rate limiting и control-plane protection

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

• Control Plane Policing;
• Management Plane Protection;
• rate limiting;
• infrastructure ACL;
• защита CPU;
• отдельный management VRF.

Обновлять прошивку

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

Защита SNMP в облачной инфраструктуре

SNMP-агент на виртуальной машине не должен быть доступен через публичную security group.

Безопасная схема:

1. Агент находится в приватной подсети.
2. UDP/161 разрешён только от сервера мониторинга.
3. Между сетями используется VPN или private peering.
4. Flow Logs фиксируют обращения.
5. Изменения security groups журналируются.
6. Для IPv6 применяются отдельные ограничения.

Правило 0.0.0.0/0 или ::/0 для UDP/161 не должно использоваться для удобства мониторинга.

Как защитить SNMP Trap

SNMP Trap обычно направляется устройством на UDP/162 сервера мониторинга. Это другой поток, но он также требует защиты.

Рекомендуется:

• принимать traps только от известных устройств;
• ограничить UDP/162 ACL;
• использовать SNMPv3 notifications;
• проверять аутентификацию;
• ограничивать частоту уведомлений;
• защищать сервер мониторинга от trap flood;
• отделять traps от публичного интернета.

Нельзя открывать UDP/162 всем внешним адресам только потому, что сервер должен получать уведомления от нескольких площадок.

Как обнаружить открытый SNMP в своей инфраструктуре

Проверки выполняются только для собственных адресов или с разрешения владельца.

Источники данных:

• инвентаризация сетевых устройств;
• конфигурационные резервные копии;
• облачные security groups;
• правила firewall;
• Flow Logs;
• системы управления конфигурациями;
• сканирование собственных диапазонов;
• события IDS/IPS;
• аудит стандартных community strings;
• проверка IPv6.

Нужно проверять не только доступность UDP/161, но также версию SNMP, уровень безопасности, views, ACL и read-write-права.

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

Признаки злоупотребления:

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

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

Что делать при обнаружении открытого SNMP

1. Ограничить UDP/161. Разрешить только адреса систем мониторинга.
2. Отключить SNMP, если он не используется.
3. Перейти на SNMPv3 authPriv.
4. Отключить SNMPv1/v2c.
5. Сменить community strings. Если старые версии временно остаются.
6. Проверить read-write-доступ.
7. Настроить views и минимальные права.
8. Проверить IPv6.
9. Обновить прошивку.
10. Проверить все устройства из общего шаблона.
11. Сохранить журналы и NetFlow.
12. Исправить систему автоматической конфигурации.

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

1. Подтвердить вектор

Проверить исходный UDP/161, структуру SNMP Response-PDU, OID и отсутствие исходящих запросов.

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

BPS показывает нагрузку на канал, PPS — на маршрутизаторы и firewall.

3. Проверить фрагментацию

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

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

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

5. Применить временную фильтрацию

Если внешние SNMP-ответы не требуются, можно ограничить трафик с исходного UDP/161. Фильтр согласуется с работой легитимного мониторинга.

6. Сохранить телеметрию

Следует сохранить:

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

7. Подготовиться к смене атаки

После фильтрации SNMP злоумышленник может использовать DNS, NTP, SSDP, CLDAP, Memcached, SYN Flood или HTTP Flood.

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

Параметр	Назначение
Целевой IP или подсеть	Активация фильтрации
Время начала	Поиск события
Максимальный BPS	Оценка нагрузки на канал
Максимальный PPS	Оценка нагрузки на оборудование
Исходный UDP/161	Подтверждение SNMP-вектора
Целевые порты	Уточнение профиля отражения
Размеры ответов	Оценка усиления
Доля фрагментов	Настройка обработки пакетов
PCAP-фрагмент	Проверка SNMP PDU

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

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

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

Для правильной изоляции необходимо:

• не публиковать IP origin в DNS;
• разрешить HTTP/HTTPS только от TrafficVeil;
• настроить одинаковые ограничения для IPv4 и IPv6;
• закрыть старые и технические поддомены;
• не публиковать SNMP на интерфейсе origin;
• размещать мониторинг в отдельной защищённой сети.

SNMP Amplification относится к объёмным L3/L4-атакам. Если поток UDP/161 направлен на известный IP и заполняет канал, WAF и HTTP rate limiting не могут его очистить.

Для таких атак требуется upstream-фильтрация у хостинг-провайдера, оператора или специализированного Anti-DDoS-сервиса. TrafficVeil защищает HTTP/HTTPS и помогает скрывать origin, но не заменяет очистку произвольного UDP-трафика.

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

Использовать сложную community string без ACL

Секрет снижает риск несанкционированного доступа, но SNMP-агент всё равно остаётся публичной поверхностью атаки.

Перейти на SNMPv3, но оставить доступ всему интернету

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

Разрешить UDP/161 от любой сети ради мониторинга

Безопаснее соединить площадки через VPN и разрешить конкретные адреса collectors.

Забыть про read-write

Одна старая read-write community string может создать риск изменения конфигурации оборудования.

Проверить только маршрутизаторы

SNMP может быть включён на принтерах, UPS, камерах, серверах и других устройствах.

Игнорировать IPv6

Агент может быть закрыт по IPv4, но доступен через глобальный IPv6-адрес.

Фильтровать только целевой порт 161

При отражённой атаке ответы приходят с исходного UDP/161 на выбранный порт жертвы.

Полагаться только на локальный firewall

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

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

• Скрыт ли реальный IP origin-сервера?
• Закрыт ли прямой доступ к origin?
• Есть ли upstream Anti-DDoS?
• Контролируется ли входящий трафик с UDP/161?
• Отслеживаются ли BPS и PPS?
• Контролируется ли IP-фрагментация?
• Сохраняются ли NetFlow или IPFIX?
• Проверены ли IPv4 и IPv6?
• Разделены ли public и management network?
• Подготовлен ли порядок обращения к провайдеру?
• Защищены ли соседние адреса?
• Проверены ли старые DNS-записи origin?

Чек-лист владельца SNMP-инфраструктуры

• Нужен ли SNMP на каждом устройстве?
• Закрыт ли UDP/161 от интернета?
• Разрешены ли только адреса серверов мониторинга?
• Используется ли SNMPv3 authPriv?
• Отключены ли SNMPv1 и SNMPv2c?
• Удалены ли стандартные community strings?
• Отсутствует ли ненужный read-write-доступ?
• Настроены ли SNMP views?
• Используется ли management VLAN или VRF?
• Настроена ли защита control plane?
• Ограничен ли UDP/162 для traps?
• Проверены ли IPv4 и IPv6?
• Обновлены ли прошивки устройств?
• Контролируется ли исходящий UDP/161?
• Проверена ли доступность с внешней стороны?

Вывод

SNMP Amplification превращает неправильно защищённые сетевые устройства в отражатели UDP-трафика. Особенно эффективны запросы, вызывающие крупные ответы, включая GETBULK к объёмным веткам MIB.

Основная защита владельца устройства — не публиковать SNMP в интернете. Доступ к UDP/161 должен быть разрешён только серверам мониторинга через management network или VPN. Дополнительно применяются SNMPv3 authPriv, ACL, SNMP views, read-only-права, rate limiting и защита control plane.

Если организация становится жертвой крупной отражённой атаки, фильтрация должна выполняться до точки насыщения канала. Reverse proxy и WAF защищают веб-приложение, но не способны самостоятельно остановить объёмный UDP-поток на сетевом уровне.