SNMP как уязвимость. Как через забытый агент раскрывают устройство корпоративной сети

В корпоративной сети может годами работать маршрутизатор, к которому давно никто не подключался для настройки. Устройство исправно передаёт трафик, не вызывает жалоб и регулярно отвечает системе мониторинга. Только вот SNMP на маршрутизаторе настроили десять лет назад, доступ по UDP 161 разрешили слишком широко, а строку public так и не заменили.

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

Наиболее опасны SNMPv1 и SNMPv2c. Обе версии используют общий секрет, который передаётся без шифрования. При неудачной настройке прав доступ к агенту может закончиться не только утечкой информации, но и изменением параметров устройства. А открытые SNMP-серверы способны участвовать в распределённых атаках с усилением трафика.

Проблему нельзя решить простым переходом на SNMPv3. Если оставить старые community strings, разрешить опрос из любого сегмента или не обновлять прошивки, часть угроз сохранится. Более того, ошибки безопасности встречаются и в реализациях SNMPv3.

Разберём реальные сценарии атак, проверим конфигурацию Linux и Cisco, настроим защищённый мониторинг и выясним, как проверить результат без риска нарушить работу сети.

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

Как SNMP раскрывает корпоративную сеть

SNMP, или Simple Network Management Protocol, позволяет системе мониторинга получать информацию от серверов, маршрутизаторов, коммутаторов, принтеров, источников бесперебойного питания и другого оборудования.

На устройстве работает SNMP-агент. Менеджер мониторинга отправляет запрос, агент находит нужный объект и возвращает его значение. Структуру управляемых объектов описывают MIB, а конкретные объекты обозначают числовыми идентификаторами OID.

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

Почему SNMPv1 и SNMPv2c небезопасны

В SNMPv1 и SNMPv2c применяется community string, общая строка доступа, которая играет роль простого секрета. Исторически для чтения часто использовали public, а для записи private. Такие значения не обязательны по стандарту и не присутствуют по умолчанию во всех реализациях, но до сих пор встречаются в старых конфигурациях.

У модели community-based security две фундаментальные проблемы.

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

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

SNMPv2c добавил новые возможности, включая GETBULK для получения большого набора объектов за один запрос. Однако модель защиты с community strings принципиально не изменилась. Буква c означает community-based, а не наличие криптографической защиты.

Сравнение версий выглядит следующим образом.

Характеристика	SNMPv1	SNMPv2c	SNMPv3 authPriv
Контроль доступа	Community string	Community string	Пользователи и модель безопасности
Криптографическая аутентификация	Нет	Нет	Да
Шифрование данных	Нет	Нет	Да
GETBULK	Нет	Да	Да
Разграничение доступа	Зависит от реализации	Зависит от реализации	VACM и механизмы производителя
Применение в новой инфраструктуре	Не рекомендуется	Нежелательно	Предпочтительно при правильной настройке

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

Какие данные можно получить через MIB

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

В стандартных MIB встречаются следующие объекты.

OID	Что содержит	Чем интересно атакующему
1.3.6.1.2.1.1.1.0	sysDescr	Модель устройства, описание ОС, иногда версия прошивки
1.3.6.1.2.1.1.5.0	sysName	Имя узла и внутренняя система именования
1.3.6.1.2.1.1.6.0	sysLocation	Площадка, серверная, стойка или другое заданное местоположение
1.3.6.1.2.1.2.2	ifTable	Интерфейсы, их состояние и сетевые счётчики
1.3.6.1.2.1.4.20	ipAddrTable	IPv4-адреса интерфейсов в реализациях с поддержкой старой таблицы
1.3.6.1.2.1.4.22	ipNetToMediaTable	Соответствия IP и MAC для соседних устройств, если таблица поддерживается

Существуют и более современные таблицы адресов, включая ipAddressTable. Через IF-MIB можно получать дополнительные характеристики интерфейсов, а через MIB производителя иногда доступны сведения о VLAN, соседях, оборудовании и его конфигурации.

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

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

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

В старых версиях оборудования Huawei, H3C и связанных платформ встречалась проблема, при которой read-only community позволяла получать сведения о локальных пользователях и паролях. В отдельных случаях пароль возвращался открытым текстом, в других применялось слабое или небезопасно реализованное преобразование. Подробный разбор уязвимости показывает, почему ограничение read-only далеко не всегда предотвращает опасную утечку.

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

Чем опасна операция SNMP SET

Обычный мониторинг использует операции чтения GET, GETNEXT и GETBULK. SNMP также поддерживает SET, позволяющий изменить значение объекта, если агент допускает запись и у пользователя есть соответствующие права.

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

Например, если реализация предоставляет доступ на запись к объекту ifAdminStatus, а аккаунту разрешено менять соответствующее значение, операция SET может административно отключить сетевой интерфейс. Для магистрального порта последствия очевидны.

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

При аудите необходимо различать три ситуации. Первая, SNMP используется исключительно для чтения. Вторая, запись разрешена ограниченному автоматизированному сервису. Третья, запись доступна через общую community string из слишком широкого сетевого диапазона. Последний сценарий требует первоочередного исправления.

UDP 161 и 162. Какие порты действительно опасны

Для обычного SNMP-опроса применяется UDP 161. Агент принимает запросы менеджера и отправляет ответы. Порт UDP 162 обычно используется приёмником уведомлений TRAP и INFORM.

TRAP отправляется агентом без предварительного запроса и без подтверждения на уровне SNMP. INFORM предусматривает ответ принимающей стороны. Для защищённых уведомлений можно использовать SNMPv3.

Открытый UDP 162 на сервере мониторинга не означает, что сервер разрешает читать свою MIB. И наоборот, закрытие UDP 162 не устраняет риск агента, доступного через UDP 161.

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

SNMP amplification. Как забытый агент помогает DDoS-атаке

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

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

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

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

Для атаки требуется несколько условий одновременно. Агент должен принимать запросы, community string должна подходить, ответ должен отправляться по указанному адресу, а сеть атакующего не должна блокировать подмену исходного IP. Не каждый открытый SNMP-агент представляет собой пригодный усилитель трафика.

Коэффициент усиления зависит от содержимого MIB, параметров GETBULK, размера сообщений и поведения конкретного агента. Универсальной цифры для всех устройств нет. Ограничения на размер ответов и число возвращаемых объектов также влияют на результат.

Практические сценарии SNMP Amplification уже рассматривались применительно к сетевому оборудованию. Главная причина остаётся прежней, доступный извне агент обрабатывает запросы, которые не должен принимать.

Защита включает фильтрацию UDP 161, переход на SNMPv3 с обязательной аутентификацией, ограничение источников запросов и контроль нагрузки. На уровне операторской сети помогает фильтрация пакетов с поддельными исходными адресами по принципам BCP 38.

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

Как проверить SNMP на Linux и Cisco

Начинать аудит следует с инвентаризации. Составьте список оборудования, которому SNMP действительно нужен. Сопоставьте найденные агенты с Zabbix, LibreNMS, Prometheus через snmp_exporter или другой системой мониторинга.

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

Проверяем Linux с Net-SNMP

На сервере Linux сначала выясните, работает ли агент и какие адреса прослушивает.

sudo ss -lunp | grep ':161'
 systemctl status snmpd

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

Отдельно проверьте IPv6. Если агент слушает [::]:161, необходимо выяснить, какие IPv6-адреса доступны и какие правила действуют для входящего трафика.

Посмотрите активные правила доступа в конфигурации Net-SNMP.

sudo grep -nE 
 '^[[:space:]]*(agentAddress|rocommunity|rwcommunity|rocommunity6|rwcommunity6|rouser|rwuser|view|com2sec|group|access)' 
 /etc/snmp/snmpd.conf

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

Особое внимание уделите rwcommunity и rwuser. Такие директивы допускают запись при выполнении остальных условий доступа. Если система мониторинга не управляет устройством через SNMP, соответствующие разрешения обычно не требуются.

Проверяем доступность из сети

Из согласованного административного сегмента можно провести ограниченную проверку конкретного диапазона.

sudo nmap -sU -p 161 --reason 
   --max-retries 1 10.20.30.0/28

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

Для UDP состояние open|filtered означает, что сканер не смог отличить доступный порт от фильтруемого. Окончательный вывод делают после изучения конфигурации и проверки с известными разрешёнными учётными данными.

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

snmpget -v2c -c 'CURRENT_COMMUNITY' 
   10.20.30.5 
   1.3.6.1.2.1.1.1.0

Команда запрашивает sysDescr. Успешный ответ может содержать описание операционной системы или оборудования. Если запрос выполняется из сегмента, где доступа быть не должно, обнаружена проблема сетевой фильтрации.

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

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

Что проверить на Cisco

Для устройств Cisco IOS и IOS XE можно начать с просмотра SNMP-конфигурации.

show running-config | include snmp-server
 show snmp user
 show snmp group
 show snmp view
 show snmp

Первая команда помогает найти community strings, группы и другие настройки. Учётные записи SNMPv3 в некоторых версиях IOS и IOS XE не отображаются полностью в running-config, поэтому отдельно нужна команда show snmp user.

Проверьте, не остались ли старые community strings после перехода на SNMPv3. Убедитесь, что пользователи входят в правильные группы, для чтения назначено ограниченное представление MIB, а доступ на запись не разрешён без необходимости.

Отдельной проверки заслуживают ACL. Наличие строки access в конфигурации ещё не гарантирует, что список действительно применяется. Для Cisco особенно полезно посмотреть фактическое состояние пользователя через show snmp user и убедиться, что нужный ACL сохранился после перезагрузки.

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

Как настроить SNMPv3 authPriv и ограничить доступ

Надёжная схема мониторинга строится на нескольких независимых мерах. SNMPv3 защищает обмен данными, VACM ограничивает доступные объекты MIB, а сетевые ACL позволяют обращаться к агенту только доверенным менеджерам.

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

Настраиваем Net-SNMP на Debian или Ubuntu

Рассмотрим Linux-сервер с адресом управления 10.20.30.5. Мониторинг выполняется с 10.20.30.10. Требуется разрешить только чтение системных показателей и счётчиков интерфейсов через SNMPv3 authPriv.

Установите необходимые пакеты.

sudo apt update
 sudo apt install snmp snmpd

Сохраните действующую конфигурацию, а затем остановите агент.

sudo cp -a /etc/snmp/snmpd.conf 
   /etc/snmp/snmpd.conf.backup
 
 sudo systemctl stop snmpd

В файле /etc/snmp/snmpd.conf настройте адрес прослушивания и представление MIB.

agentAddress udp:10.20.30.5:161
 
 view MONITORING included .1.3.6.1.2.1.1
 view MONITORING included .1.3.6.1.2.1.2
 view MONITORING included .1.3.6.1.2.1.31
 
 rouser snmpmon priv -V MONITORING

Первая строка ограничивает адрес прослушивания агента конкретным IPv4-интерфейсом. Правила view разрешают доступ к системным сведениям, базовой информации об интерфейсах и объектам IF-MIB. Директива rouser предоставляет пользователю snmpmon права чтения только при использовании режима priv.

Для расширенного мониторинга процессора, дисков, датчиков температуры или оборудования производителя потребуются дополнительные ветви. Добавляйте нужные OID по отдельности, предварительно проверяя содержимое MIB.

Удалите ненужные правила rocommunity, rwcommunity и другие старые разрешения. Не оставляйте дублирующие широкие правила доступа для пользователя snmpmon.

Создать пользователя можно в постоянном файле конфигурации Net-SNMP. В стандартных пакетах Debian и Ubuntu соответствующие данные обычно хранятся в /var/lib/snmp/snmpd.conf. Уточните путь в установленной сборке. Редактировать файл следует при остановленном агенте, сохраняя существующие служебные записи.

Добавьте строку создания пользователя.

createUser snmpmon SHA "AUTH_SECRET" AES "PRIV_SECRET"

Замените условные значения разными случайными парольными фразами. Для каждой лучше использовать не менее 16 символов. Вариант SHA в такой конфигурации обычно означает HMAC-SHA-1, а AES означает AES-128. Более новые сборки Net-SNMP могут поддерживать SHA-2, включая SHA-256. При наличии совместимости с менеджером мониторинга лучше выбрать SHA-2.

Файл с директивой createUser должен быть доступен только привилегированному пользователю. После запуска Net-SNMP обычно преобразует запись в локализованные ключи, но временная конфигурация и её резервные копии всё равно требуют защиты.

Запустите агент.

sudo systemctl start snmpd
 sudo systemctl status snmpd
 sudo ss -lunp | grep ':161'

На сервере мониторинга создайте защищённый пользовательский конфигурационный файл ~/.snmp/snmp.conf с параметрами подключения.

defVersion 3
 defSecurityName snmpmon
 defSecurityLevel authPriv
 defAuthType SHA
 defPrivType AES
 defAuthPassphrase AUTH_SECRET
 defPrivPassphrase PRIV_SECRET

Значения AUTH_SECRET и PRIV_SECRET должны совпадать с заданными на агенте. Ограничьте доступ к файлу и каталогу.

chmod 700 ~/.snmp
 chmod 600 ~/.snmp/snmp.conf

Для автоматизированного мониторинга предпочтительнее использовать штатное защищённое хранилище секретов. Парольные фразы в snmp.conf хранятся в читаемом виде и могут попасть в резервные копии.

Теперь выполните запрос с сервера мониторинга.

snmpget -v3 -l authPriv 
   10.20.30.5 
   1.3.6.1.2.1.1.3.0

При успешном подключении команда вернёт sysUpTime, время работы SNMP-объекта с момента последней инициализации соответствующей части системы управления.

Если видите timeout, проверьте маршрут, ACL, адрес прослушивания и журнал агента. Ошибки аутентификации, неизвестный пользователь, несовместимые алгоритмы или несоответствие параметров SNMP Engine ID требуют отдельной диагностики.

Следующий шаг заключается в фильтрации на уровне Linux. Для Ubuntu с UFW пример разрешающего правила выглядит следующим образом.

sudo ufw allow from 10.20.30.10 
   to 10.20.30.5 port 161 proto udp
 
 sudo ufw status verbose

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

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

Настраиваем SNMPv3 и ACL на Cisco IOS XE

На Cisco разумно создать отдельную группу SNMPv3, назначить ей представление MIB и ограничить источники запросов через стандартный ACL.

Для примера сервер мониторинга имеет адрес 10.20.30.10. Сначала создайте список доступа.

configure terminal
 
 ip access-list standard SNMP-MANAGERS
  permit 10.20.30.10
  deny any log
 exit

Добавьте представление MIB для системных объектов и интерфейсов.

snmp-server view MON-VIEW 1.3.6.1.2.1.1 included
 snmp-server view MON-VIEW 1.3.6.1.2.1.2 included
 snmp-server view MON-VIEW 1.3.6.1.2.1.31 included

Затем создайте группу SNMPv3 с обязательной аутентификацией и шифрованием.

snmp-server group NMS-READ v3 priv read MON-VIEW access SNMP-MANAGERS

Группа получает права чтения только в пределах MON-VIEW. Представление для записи не назначается.

Создайте пользователя.

snmp-server user snmpmon NMS-READ v3 auth sha AUTH_SECRET priv aes 128 PRIV_SECRET

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

Пример использует широко поддерживаемое сочетание SHA и AES-128. На устройствах с поддержкой SHA-2 и более современных вариантов AES выбирайте наиболее стойкие совместимые алгоритмы. Синтаксис SNMPv3 различается между Cisco IOS, IOS XE, NX-OS и отдельными семействами оборудования, поэтому команды нужно сверить с конкретной платформой.

Проверьте результат.

show snmp user
 show snmp group
 show snmp view
 show ip access-lists SNMP-MANAGERS

Убедитесь, что SNMPv3-пользователь действительно относится к NMS-READ, применяется представление MON-VIEW, а список доступа содержит правильный адрес менеджера.

После успешного переноса мониторинга удалите оставшиеся настройки SNMPv1 и SNMPv2c. Для известных стандартных строк команды могут выглядеть следующим образом.

configure terminal
 
 no snmp-server community public
 no snmp-server community private
 
 end
 copy running-config startup-config

Названия public и private приведены только как примеры. В действующей конфигурации могут присутствовать другие community strings, в том числе для внешнего мониторинга и уведомлений. Перед удалением проверьте все зависимости, чтобы не нарушить наблюдение за устройствами.

Для IPv6 потребуются отдельные ограничения. Кроме ACL внутри SNMP полезно защищать саму сеть управления, например через выделенную VRF и межсетевые фильтры на границах сегментов.

Почему нужно отдельно проверить SNMP Trap

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

Поэтому при переносе оборудования на SNMPv3 недостаточно проверить только список community strings, созданных для опроса. Нужно изучить конфигурацию получателей TRAP и INFORM, убедиться, что секреты уведомлений не позволяют обращаться к агенту, и по возможности перевести сами уведомления на SNMPv3.

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

Почему SNMPv3 не гарантирует безопасность

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

Показательный случай произошёл с Cisco IOS и IOS XE. Уязвимость CVE-2025-20352 позволяла аутентифицированному удалённому атакующему вызывать отказ в обслуживании на затронутых устройствах. При наличии дополнительных административных полномочий на уязвимых IOS XE существовала возможность выполнения кода с правами root. Проблема затрагивала SNMPv1, SNMPv2c и SNMPv3.

Для эксплуатации требовались действующие SNMP-учётные данные или community string. Поэтому нельзя трактовать CVE-2025-20352 как возможность беспрепятственно взломать любой маршрутизатор с открытым UDP 161. Но даже доступ с минимальными SNMP-правами мог создавать серьёзный риск.

Ещё один случай, CVE-2025-20151, затронул механизм ограничения SNMPv3 в Cisco IOS и IOS XE. В определённых конфигурациях длинная строка с параметрами пользователя при сохранении могла обрезаться. После перезагрузки имя ACL оказывалось усечённым, и список доступа переставал применяться.

В результате пользователь с действующими SNMPv3-учётными данными мог обращаться к устройству с IP-адреса, который должен был быть запрещён. Уязвимость не предоставляла секреты автоматически и не давала постороннему пользователю доступ без аутентификации. Но показывала, насколько опасно считать наличие ACL в конфигурации достаточным доказательством защиты.

В августе 2026 года появилась ещё одна SNMP-уязвимость в Cisco IOS XE, CVE-2026-20124 с оценкой 7,7 по CVSS 3.1. Ошибка обработки некорректно сформированных запросов позволяла удалённому атакующему с действующей community string или SNMPv3-учётными данными вызвать неожиданную перезагрузку уязвимого устройства.

Проблема затрагивала все версии протокола на уязвимых выпусках IOS XE. Для полноценного исправления требовалось установить исправленное ПО. Временное исключение некоторых OID из доступных представлений могло снизить риск, но способно нарушить сбор аппаратной информации и не заменяло обновление.

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

Что чаще всего упускают администраторы

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

Старые версии продолжают работать. Администратор создаёт пользователя SNMPv3, но оставляет действующие community strings SNMPv1 и SNMPv2c.
Не ограничена MIB. Read-only пользователь получает доступ ко всему дереву OID, хотя мониторингу нужны только счётчики интерфейсов и несколько системных показателей.
Применён authNoPriv. Подлинность сообщений проверяется, но полезные данные передаются без шифрования.
Секреты хранятся в открытых файлах. Парольные фразы SNMPv3 попадают в системы контроля версий, резервные копии или журналы автоматизации.
Один аккаунт используется повсеместно. Утечка секретов позволяет обращаться сразу к большой группе устройств.
IPv6 остался без фильтрации. Ограничения для IPv4 не всегда распространяются на IPv6.
ACL не проверяется после перезагрузки. Ошибка конфигурации или прошивки может изменить фактические права доступа.
Уведомления продолжают использовать SNMPv2c. Защищённый опрос не означает защищённую передачу TRAP и INFORM.

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

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

Как убедиться, что защита действительно работает

Проверку завершайте не просмотром настроек, а контрольными запросами из разных сетевых сегментов.

Проверка	Ожидаемый результат
SNMPv3 authPriv с разрешённого сервера	Запрос возвращает нужные показатели
SNMPv1 и SNMPv2c после миграции	Старые community strings больше не дают доступ
SNMPv3 из запрещённого сегмента	Сетевой доступ блокируется даже при действующих учётных данных
Запрос объектов вне разрешённой MIB	Агент не предоставляет значение
Проверка прав SET	У пользователя мониторинга нет разрешений на запись
Повторная проверка после перезагрузки	ACL, пользователи и представления MIB сохранились
Проверка версии прошивки	Установлен выпуск без известных неисправленных применимых уязвимостей

Отдельно проверьте, что сервер мониторинга продолжает получать все необходимые показатели. Отсутствие ошибок SNMP-аутентификации не означает, что графики остались полноценными. После сужения MIB часть шаблонов может перестать получать данные из-за исключённых OID.

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

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

Частые вопросы

Можно ли взломать маршрутизатор через открытый порт UDP 161?

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

Может ли SNMP раскрыть пароли от сетевого оборудования?

В отдельных уязвимых реализациях такое происходило. Например, старые версии оборудования Huawei и H3C предоставляли чувствительные сведения о локальных пользователях через доступные для чтения объекты MIB. Однако стандартный SNMP не предусматривает универсальной команды получения паролей администратора.

Защищает ли смена public на сложную community string?

Сложная случайная строка уменьшает риск угадывания, но SNMPv1 и SNMPv2c по-прежнему передают секрет без шифрования. Для полноценной защиты лучше использовать SNMPv3 authPriv, ограничить разрешённые адреса и минимизировать доступные объекты MIB.

Нужно ли закрывать UDP 162 вместе с UDP 161?

Порт UDP 161 обычно принимает запросы к SNMP-агенту, а UDP 162 предназначен для получения уведомлений TRAP и INFORM. Если приёмник уведомлений не нужен, порт можно закрыть. Если уведомления используются, доступ следует разрешать только от доверенных устройств. Закрытие UDP 162 не заменяет защиту UDP 161.

Можно ли использовать SNMPv3 вместе с Zabbix и LibreNMS?

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

Можно ли полностью отключить SNMP на маршрутизаторе?

Да, если протокол не нужен мониторингу или управлению. На некоторых Cisco IOS доступна команда no snmp-server, но поведение и сохранение связанных настроек зависят от платформы. Перед отключением необходимо проверить зависимые системы, а после изменения убедиться, что агент больше не принимает запросы.

Защищает ли SNMPv3 от SNMP amplification DDoS?

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

Что делать со старым оборудованием без поддержки SNMPv3?

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

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

Начать защиту стоит с простого аудита UDP 161, активных community strings и доступных объектов MIB. Затем перевести нужные устройства на SNMPv3 authPriv, удалить старые способы доступа, ограничить SNMP по ACL и проверить прошивки. Отдельно следует проверить уведомления, права SET и фактическую работу фильтрации после перезагрузки.

Для корпоративной инфраструктуры разумное правило выглядит просто. Устройства, которым не нужен SNMP, не должны запускать агент. Остальные должны отвечать только доверенным системам мониторинга и предоставлять только необходимые показатели. Такой подход сохраняет преимущества сетевого мониторинга, не превращая протокол управления в дополнительный канал разведки и атак.

Кто-то прячет адрес ради сериалов. Вы — ради новостей про кибербезопасность.