Уязвимость в Net-SNMP, позволяющая удалённое выполнение кода через snmptrapd
В популярном пакете Net-SNMP, реализующем протоколы SNMP v1, v2c и v3, обнаружена критическая уязвимость (CVE-2025-68615), дающая возможность удалённого выполнения произвольного кода на сервере, обрабатывающем trap-сообщения. Под удар попадает сервис snmptrapd, который слушает входящие уведомления от сетевого оборудования и других устройств мониторинга.
По умолчанию snmptrapd принимает пакеты на UDP-порту 162 и, как правило, запускается с максимальными привилегиями — от имени пользователя root. Это резко повышает риск: успешная эксплуатация приводит к захвату полной системы, а не ограниченного контейнера или непривилегированного процесса. Экспертами уязвимость уже оценена как критическая — 9,8 балла из 10 по шкале CVSS. Атакующий может использовать её удалённо и без какой-либо аутентификации.
Причина уязвимости
Проблема кроется в ошибке проверки длины OID (Object Identifier), содержащегося в trap-пакете. В исходном коде была допущена логическая неточность: проверка выполнялась по условию `trapOidLen >= 0` вместо корректного `trapOidLen > 0`. В результате механизм защиты от некорректной длины OID фактически не предотвращал обработку нулевой или некорректной длины.
После этой формальной «проверки» данные из входящего пакета копировались в буфер фиксированного размера, предназначенный для хранения значения trapOid. Если злоумышленник сформирует специальным образом trap-сообщение, размер и содержимое которого приводят к выходу за пределы этого буфера, происходит запись данных за границу выделенной памяти. Такой выход за пределы буфера открывает путь к выполнению произвольного кода с правами процесса snmptrapd.
С учётом того, что snmptrapd в типичной конфигурации запускается от root, атакующий получает возможность выполнять любые системные команды, изменять конфигурацию, устанавливать бэкдоры, развивать атаку внутрь сети и закрепляться в инфраструктуре.
Какие версии уязвимы и как устранить проблему
Разработчики уже выпустили обновления, устраняющие ошибку проверки размера OID. Исправление включено в версии Net-SNMP 5.9.5 и 5.10.pre2. Администраторам рекомендуется:
1. Проверить, какие версии Net-SNMP установлены на серверах.
2. Как можно скорее обновиться до версии, в которой уязвимость закрыта.
3. При невозможности оперативного обновления — временно отключить snmptrapd, если он не критичен, либо как минимум ограничить к нему сетевой доступ.
Обновление — основной и наиболее надёжный способ защиты: патч исправляет саму корневую причину проблемы на уровне кода и делает атаку через данный вектор невозможной.
Сетевые меры защиты: порт 162 и фильтрация
В дополнение к установке исправления рекомендуется усилить сетевую изоляцию. Так как snmptrapd по умолчанию слушает UDP-порт 162, логично:
- Закрыть доступ к UDP/162 из внешних сетей на межсетевом экране.
- Ограничить круг узлов, от которых принимаются SNMP trap-сообщения, используя ACL на маршрутизаторах, коммутаторах и брандмауэрах.
- Применить фильтрацию по IP-адресам и, по возможности, по VLAN, чтобы trap-пакеты принимались только из служебного сегмента сети.
Даже если уязвимость уже закрыта обновлением, такие ограничения уменьшают поверхность атаки и защищают от возможных будущих ошибок реализации протокола.
Особенности крупных корпоративных сетей
Во многих корпоративных инфраструктурах речь идёт не о десятках, а о десятках или сотнях тысяч устройств: маршрутизаторы, коммутаторы, точки доступа, серверы, IP-камеры, системы контроля и автоматики. В таких масштабах SNMP и, в частности, trap-сообщения широко используются для централизованного мониторинга и оповещения о сбоях.
Чтобы не превратить весь этот зоопарк устройств в потенциальный трамплин для атак, в «здоровой» корпоративной сети обычно организуют отдельный административный VLAN для управления оборудованием. В такой схеме:
- Управляющий трафик (включая SNMP, SSH, HTTP(S) для админок) выносят в отдельный, изолированный VLAN.
- Из административного VLAN по-хорошему нет прямых маршрутов в основные пользовательские подсети и в интернет.
- Администратор, которому нужно управлять оборудованием, подключается отдельным интерфейсом или через выделенный доступ, а не из обычной пользовательской сети.
В такой архитектуре даже наличие уязвимостей в сервисах управления (вроде snmptrapd) менее опасно: атакующему гораздо сложнее вообще добраться до порта 162 и сгенерировать нужный трафик.
Почему «фичи, а не уязвимости» — опасный подход
Иногда можно услышать ироничное отношение к подобным уязвимостям: мол, «это не баг, а фича», «так заложено разработчиками», «всё и так небезопасно». Подобный цинизм в реальности играет против безопасности. Даже если старые протоколы и сервисы изначально проектировались без учёта современных угроз, это не снимает ответственности по их защите.
Принимая любую «особенность» реализации как данность, организации рискуют:
- превратить критичные сервисы мониторинга в точку входа для атак;
- дать злоумышленникам возможность долго скрытно находиться в сети;
- использовать эксплуатацию одного простого буферного переполнения для захвата домен-контроллеров, серверов баз данных и других ключевых систем.
Поэтому к подобным обнаружениям стоит относиться не как к досадным мелочам, а как к стимулу пересмотреть всю модель безопасности управления инфраструктурой.
Лучшие практики для безопасного использования SNMP и snmptrapd
Помимо простого обновления пакета Net-SNMP, полезно внедрить комплекс организационных и технических мер:
1. Минимизация функционала. Если вам не нужны SNMP trap’ы — не запускайте snmptrapd. Если нужен только опрос по SNMP, оставьте работающим только snmpd.
2. Ограничение источников. Настройте приём trap-сообщений только от конкретных устройств или подсетей. Любой неизвестный источник должен быть отброшен ещё на уровне маршрутизатора или брандмауэра.
3. Использование SNMPv3. Там, где возможно, переходите на SNMPv3 с аутентификацией и шифрованием вместо SNMPv1/v2c с простыми community-строками. Это не решит именно эту уязвимость, но существенно повысит общий уровень безопасности.
4. Жёсткое разделение ролей. Не запускайте сервисы мониторинга с правами root, если это не абсолютно необходимо. Применяйте механизмы chroot, systemd-ограничения, SELinux/AppArmor, чтобы минимизировать вред при возможной эксплуатации.
5. Сегментация сетей. Убедитесь, что SNMP-трафик не ходит по пользовательским VLAN, а доступ к административному сегменту строго контролируется.
Роль архитектуры сети и оборудования
Сама по себе уязвимость — следствие ошибки в программном коде, но масштаб её влияния определяется архитектурой сети. Если все устройства свалены в один плоский сегмент, а мониторинг и управление доступны отовсюду, любая подобная ошибка превращается в катастрофу.
Грамотное разделение:
- по уровням доступа (пользовательские, серверные, административные VLAN),
- по типам сервисов (управление, мониторинг, рабочие приложения),
- по зонам доверия (DMZ, внутренняя сеть, зона для удалённого доступа)
делает эксплуатацию даже известных уязвимостей крайне затруднительной. В таких сетях принципы «минимально необходимого доступа» и «разделяй и властвуй» работают лучше любых единичных патчей.
Что делать администраторам прямо сейчас
Чтобы снизить риск, стоит выполнить несколько последовательных шагов:
1. Инвентаризация. Найти все инстансы Net-SNMP и snmptrapd в инфраструктуре, включая серверы мониторинга, старые системы, лабораторные стенды.
2. Оценка экспозиции. Проверить, доступны ли UDP/162 извне или из пользовательских сегментов. Выяснить, какие устройства реально отправляют trap-сообщения.
3. Оперативное исправление. Обновить Net-SNMP до версий 5.9.5 или 5.10.pre2 и убедиться, что именно исправленный пакет задействован.
4. Усиление фильтрации. Настроить ACL и правила файрвола так, чтобы trap-пакеты приходили только из строго определённых подсетей и VLAN.
5. Пересмотр архитектуры. Если административный VLAN отсутствует или плохо изолирован — спланировать его внедрение и поэтапный перевод оборудования в отдельный управленческий сегмент.
Взгляд на перспективу
Истории с переполнением буферов и некорректной проверкой размеров массивов сопровождают C и системное программирование десятилетиями. Пока подобные сервисы будут писаться на языках без встроенной защиты памяти, такие ошибки будут возникать вновь и вновь — независимо от того, будет ли железо с гарвардской архитектурой или с любой другой.
Поэтому единственный реалистичный путь — сочетать:
- регулярное обновление и ревизию используемого ПО,
- максимально строгую сетевую сегментацию,
- принцип минимальных привилегий,
- постоянный контроль за тем, какие службы действительно нужны, а какие работают «по инерции».
Уязвимость в Net-SNMP наглядно показывает, что даже привычные и давно используемые инструменты мониторинга могут внезапно превратиться в критический риск. Чем раньше инфраструктура будет построена так, чтобы любая отдельная ошибка не приводила к катастрофе, тем спокойнее будет жизнь администраторов и владельцев систем.
