SNMP

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

Агенты SNMP предоставляют данные управления на управляемых системах в виде переменных. Протокол также позволяет выполнять задачи управления активами, такие как изменение и применение новой конфигурации посредством удалённого изменения этих переменных. Переменные, доступные через SNMP, организованы в иерархии. Эти иерархии и другие метаданные (например, тип и описание переменной) описываются базами управления информацией (MIB).

Сеть, управляемая с помощью SNMP, состоит из трёх ключевых компонентов:

• Станции управления сетью (Network Management Stations, NMS);
• Управляемые устройства;
• Агенты.

Эти компоненты выполняют следующие функции:

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

Управляемое устройство — это устройство, содержащее агент SNMP и находящееся в управляемой сети. Такие устройства собирают и хранят информацию об управлении, которая предоставляется NMS через SNMP. Управляемые устройства, иногда называемые сетевыми элементами, могут быть различными: маршрутизаторы, серверы доступа, сетевые коммутаторы, мосты, концентраторы, компьютеры и принтеры.

Агент — это модуль программного обеспечения управления сетью, который находится на управляемом устройстве. Агент обладает локальными знаниями об информации управления (свободная память, количество полученных IP-пакетов, маршруты и т. д.), которые преобразуются в совместимый с SNMP формат и организуются в иерархии.

Управляемые устройства контролируются и управляются с помощью четырёх основных команд SNMP: чтение, запись, уведомление и сквозные операции.

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

База управления информацией (Management Information Base, MIB) — это коллекция информации, организованная иерархически. К MIB обращаются с помощью протокола управления сетью, такого как SNMP.

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

Существует два типа управляемых объектов: скалярные и табличные. Скалярные объекты определяют один экземпляр объекта. Табличные объекты определяют несколько связанных экземпляров объекта, сгруппированных в таблицы MIB.

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

Идентификатор объекта (object ID) однозначно идентифицирует управляемый объект в иерархии MIB. Иерархия MIB может быть представлена в виде дерева с анонимным корнем и уровнями, которые назначаются различными организациями.

Дерево MIB иллюстрирует различные иерархии, назначаемые разными организациями

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

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

Управляемый объект atInput может быть идентифицирован по имени объекта iso.identified-organization.dod.internet.private.enterprise.cisco.temporary.AppleTalk.atInput или по эквивалентному дескриптору объекта 1.3.6.1.4.1.9.3.3.1.

Сердце дерева MIB состоит из нескольких групп объектов, которые вместе называются mib-2. Группы следующие:

• System (1);
• Interfaces (2);
• AT (3);
• IP (4);
• ICMP (5);
• TCP (6);
• UDP (7);
• EGP (8);
• Transmission (10);
• SNMP (11).

Важно отметить, что структура MIB описывается стандартом ASN.1.

SNMP работает на уровне приложения стека протоколов Интернета (уровень 7 модели OSI). Протокол SNMP использует неориентированный на соединение сервис (UDP) для передачи небольшого набора сообщений (PDU) между менеджерами и агентами. Использование такого механизма гарантирует, что задачи управления сетью не повлияют на её общую производительность, поскольку избегается использование механизмов контроля и восстановления, как в сервисах, ориентированных на соединение, например, TCP.

Обычно для SNMP используются следующие порты:

Агент SNMP принимает запросы на порту UDP 161. Администратор может отправлять запросы с любого доступного исходного порта на порт 161 агента. Ответ агента будет отправлен обратно на исходный порт менеджера. Администратор получает уведомления (Traps и InformRequests) на порту 162. Агент может генерировать уведомления с любого доступного порта. При использовании с TLS запросы принимаются на порту 10161, а уведомления отправляются на порт 10162.

SNMPv1 определяет пять основных протокольных единиц данных (PDU). Ещё две PDU, GetBulkRequest и InformRequest, были добавлены в SNMPv2 и перенесены в SNMPv3.

Все PDU SNMP строятся следующим образом:

Для выполнения вышеуказанных базовых операций управления

Пакеты, используемые для отправки SNMP-запросов и ответов, имеют следующий формат:

• Версия: номер используемой версии протокола (например, 0 для SNMPv1, 1 для SNMPv2c, 2 для SNMPv2p и SNMPv2u, 3 для SNMPv3 и т. д.);
• Сообщество: имя или ключевое слово, используемое для аутентификации. Обычно существует сообщество только для чтения с именем «public» и сообщество для записи с именем «private»;
• SNMP PDU: содержимое протокольной единицы данных, зависящее от выполняемой операции.

Сообщения GetRequest, GetNextRequest, SetRequest и GetResponse используют следующую структуру в поле SNMP PDU:

• Идентификатор: число, используемое NMS и агентом для одновременной отправки различных запросов и ответов;
• Состояние и индекс ошибки: используются только в сообщениях GetResponse (в запросах всегда используется ноль). Поле «индекс ошибки» используется только тогда, когда «состояние ошибки» отлично от 0 и предназначено для предоставления дополнительной информации о причине проблемы. Поле «состояние ошибки» может принимать следующие значения:
  • 0: Нет ошибки;
  • 1: Слишком большой;
  • 2: Такой переменной не существует;
  • 3: Некорректное значение;
  • 4: Значение только для чтения;
  • 5: Общая ошибка.
• Связывание переменных: серия имён переменных с соответствующими значениями (кодируется в ASN.1).

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

Это сообщение используется для обхода таблицы объектов. После получения значения объекта с помощью GetRequest, сообщение GetNextRequest может быть использовано для повторения операции со следующим объектом таблицы. Результат предыдущей операции всегда используется для нового запроса. Таким образом, NMS может обойти таблицу переменной длины, пока не получит всю информацию по каждой существующей строке.

Этот тип сообщения используется NMS для запроса к агенту на изменение значений объектов. Для выполнения этой операции NMS отправляет агенту список имён объектов с соответствующими значениями.

Это сообщение используется агентом для ответа на сообщения GetRequest, GetNextRequest или SetRequest. В поле «Идентификатор запроса» содержится тот же идентификатор, что и в «запросе», на который даётся ответ.

Trap генерируется агентом для сообщения о некоторых условиях и изменениях состояния процессу управления. Формат PDU отличается:

• Enterprise: идентификация подсистемы управления, сгенерировавшей trap;
• Адрес агента: IP-адрес агента, сгенерировавшего trap;
• Общий тип trap:
  • Cold start (0): агент был инициализирован или перезапущен;
  • Warm start (1): конфигурация агента изменилась;
  • Link down (2): интерфейс связи не работает (неактивен);
  • Link up (3): интерфейс связи работает (активен);
  • Authentication failure (4): агент получил запрос от неавторизованного NMS (обычно контролируется сообществом);
  • EGP neighbor loss (5): в системах, где маршрутизаторы используют протокол EGP, соседнее устройство вышло из строя;
  • Enterprise (6): сюда относятся все новые trap, добавленные производителями.
• Специфический тип trap: используется для частных (производительских) trap, а также для уточнения информации о конкретном общем trap;
• Timestamp: время, прошедшее между перезапуском агента и генерацией trap;
• Связывание переменных: используется для предоставления дополнительной информации о причине сообщения.

Это сообщение используется NMS, использующим версию 2 или 3 протокола SNMP, обычно когда требуется передача большого объёма данных, например, при получении длинных таблиц. В этом смысле оно похоже на сообщение GetNextRequest, используемое в версии 1 протокола, однако GetBulkRequest — это гораздо более быстрый и эффективный способ, поскольку позволяет запросить всю таблицу одним сообщением.

NMS, использующий версию 2 или 3 протокола SNMP, передаёт такое сообщение другому NMS с аналогичными характеристиками для уведомления об управляемых объектах, используя протокол TCP, и будет отправлять InformRequest до получения подтверждения.

SNMP версии 1 (SNMPv1) — начальная реализация протокола SNMP. SNMPv1 работает через протоколы транспортного уровня, такие как UDP, IP, CLNS, DDP от AppleTalk и IPX от Novell. SNMPv1 широко используется и является де-факто протоколом управления сетью в интернет-сообществе^[3].

Первые RFC для SNMP, теперь известного как SNMPv1, появились в 1988 году:

• RFC 1065: Структура и идентификация информации управления для интернета на базе TCP/IP.
• RFC 1066: База управления информацией для управления сетью интернета на базе TCP/IP.
• RFC 1067: Простой протокол сетевого администрирования.
  

Эти протоколы были заменены:

• RFC 1155: Структура и идентификация информации управления для интернета на базе TCP/IP.
• RFC 1156: База управления информацией для управления сетью интернета на базе TCP/IP.
• RFC 1157: Простой протокол сетевого администрирования.
  

Вскоре RFC 1156 (MIB-1) была заменена более распространённой:

• RFC 1213: Версия 2 базы управления информацией (MIB-2) для управления сетью интернета на базе TCP/IP.

Версия 1 подвергалась критике за отсутствие безопасности^[4].Аутентификация клиентов осуществляется только с помощью «строки сообщества», по сути, пароля, который передаётся в открытом виде. Дизайн SNMPv1 1980-х годов был разработан группой сотрудников, которые считали, что официально спонсируемый продукт (HEMS/CMIS/CMIP) от OSI/IETF/NSF был как неприменим на компьютерных платформах того времени, так и потенциально нежизнеспособен. SNMP был принят на основе убеждения, что это временный протокол, необходимый для масштабного внедрения Интернета и его коммерциализации. В те времена стандарты аутентификации и безопасности в Интернете были лишь мечтой, а группы разработчиков протоколов не уделяли им внимания.

SNMPv2 (определён в RFC 1441 и RFC 1452) пересматривает версию 1 и включает улучшения в области производительности, безопасности и взаимодействия между менеджерами. Введён GetBulkRequest — альтернатива итеративным GetNextRequests для получения больших объёмов управляющих данных за один запрос. Однако новая система безопасности SNMPv2, по мнению многих, оказалась слишком сложной и не получила широкого распространения^[4].Эта версия SNMP достигла уровня «предлагаемого стандарта», но была признана устаревшей последующими версиями^[5].

В версии на основе сообщества, Simple Network Management Protocol 2 или SNMPv2c, определённой в RFC 1901-RFC 1908, SNMPv2 реализован без спорной новой модели безопасности SNMP v2, вместо этого используется простая схема безопасности на основе сообщества SNMPv1. Эта версия — одна из немногих, достигших уровня draft standard IETF, и фактически стала стандартом SNMPv2. Она также была впоследствии заменена SNMPv3.

В пользовательской версии Simple Network Management Protocol 2, или SNMPv2u, определённой в RFC 1909 и RFC 1910, реализован компромисс, обеспечивающий большую безопасность, чем SNMPv1, но без высокой сложности SNMPv2. Вариант этого протокола был коммерциализирован как SNMP v2*, а механизм впоследствии был принят как одна из двух моделей безопасности SNMP v3^[6].

В текущей спецификации SNMPv2c несовместим с SNMPv1 по двум ключевым аспектам: форматам сообщений и операциям протокола. Сообщения SNMPv2c используют отличающиеся заголовки и протокольные единицы данных (PDU) по сравнению с сообщениями SNMPv1. SNMPv2c также использует две операции протокола, не определённые в SNMPv1. Кроме того, RFC 3584 определяет две возможные стратегии сосуществования SNMPv1/v2c: прокси-агенты и двуязычные системы управления сетью.

Агент SNMPv2 может выступать в роли прокси-агента для управляемых устройств SNMPv1 следующим образом:

• SNMPv2 NMS отправляет команду, предназначенную для агента SNMPv1.
• NMS отправляет SNMP-сообщение прокси-агенту SNMPv2.
• Прокси-агент пересылает сообщения Get, GetNext и Set агенту SNMPv1 без изменений.
• Сообщения GetBulk преобразуются прокси-агентом в сообщения GetNext и затем отправляются агенту SNMPv1.

Прокси-агент сопоставляет сообщения trap SNMPv1 с trap SNMPv2 и затем отправляет их NMS.

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

Хотя SNMPv3, впервые представленный в 1998 году^[7], не вносит изменений в протокол, кроме добавления криптографической безопасности, он кажется значительно отличающимся из-за новых текстовых соглашений, концепций и терминологии^[8].

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

SNMPv3 решает вопросы, связанные с масштабным внедрением SNMP, учётом и управлением отказами. В настоящее время SNMP в основном используется для контроля и управления производительностью.

SNMPv3 определяет безопасную версию SNMP и также облегчает удалённую настройку SNMP-объектов. SNMPv3 предоставляет безопасную среду для управления системами, охватывающую следующее:

• Идентификация SNMP-объектов для обеспечения связи только между известными SNMP-объектами: каждый SNMP-объект имеет идентификатор snmpEngineID, и связь возможна только при знании идентичности собеседника. Исключение составляют trap и уведомления.
• Поддержка моделей безопасности: модель безопасности может определять политику безопасности в административном домене или интранете. SNMPv3 содержит спецификации для USM.
• Определение целей безопасности, включая защиту от:
  • Модификации информации: защита от неавторизованного изменения SNMP-сообщений в пути следования.
  • Подмены: защита от неавторизованных операций управления путём выдачи себя за другого субъекта с соответствующими правами.
  • Модификации потока сообщений: защита от злонамеренного переупорядочивания, задержки или повторной передачи сообщений для выполнения неавторизованных операций.
  • Разглашения: защита от перехвата обмена между SNMP-движками.
• Спецификация модели безопасности на основе пользователя (USM): определяет следующие механизмы связи:
  • Связь без аутентификации и приватности (NoAuthNoPriv).
  • Связь с аутентификацией, но без приватности (AuthNoPriv).
  • Связь с аутентификацией и приватностью (AuthPriv).

• Определение различных протоколов аутентификации и приватности: в настоящее время поддерживаются протоколы аутентификации MD5 и SHA. Для HMAC-SHA-2 актуальным стандартом является RFC 7860 (апрель 2016 года), который сделал устаревшим RFC 7630^[9]. Также поддерживаются протоколы приватности CBC_DES и CFB_AES_128 в USM.
• Определение процедуры обнаружения: для поиска SNMPEngineID SNMP-объекта по общему транспортному адресу и конечному адресу.
• Определение процедуры синхронизации времени: для облегчения аутентифицированной связи между SNMP-объектами.
• Определение MIB-фреймворка SNMP: для облегчения удалённой настройки и управления SNMP-объектом.
• Определение MIB USM: для облегчения удалённой настройки и управления модулем безопасности.
• Определение MIB VACM: для облегчения удалённой настройки и управления модулем контроля доступа.

SNMPv3 фокусируется на двух основных аспектах: безопасности и управлении. Безопасность обеспечивается надёжной аутентификацией и шифрованием данных для приватности. Управление включает работу с источниками уведомлений и прокси-агентами. SNMPv3 определяет ряд возможностей, связанных с безопасностью. Первоначальные спецификации определяют USM и VACM, за которыми последовала модель транспортной безопасности, обеспечивающая поддержку SSH и SNMPv3 через TLS и DTLS.

• USM (User-based Security Model) обеспечивает функции аутентификации и приватности (шифрования) и работает на уровне сообщений.
• VACM (View-based Access Control Model) определяет, разрешён ли конкретному менеджеру доступ к определённому объекту MIB для выполнения конкретных функций, и работает на уровне PDU.
• TSM (Transport Security Model) обеспечивает аутентификацию и шифрование сообщений через внешние каналы безопасности. Определены два транспорта: SSH и TLS/DTLS, использующие спецификацию TSM. В ноябре 2023 года был опубликован RFC 9456, который обновил транспортную модель TLS для поддержки современных версий (D)TLS 1.3^[10].

Безопасность была самой большой слабостью SNMP с самого начала. Аутентификация в SNMP 1 и 2 осуществляется только паролем (строкой сообщества), передаваемым в открытом виде между менеджером и агентом. Каждое сообщение SNMPv3 содержит параметры безопасности, закодированные в виде октетной строки. Значение этих параметров зависит от используемой модели безопасности. SNMPv3 предоставляет важные функции безопасности:

• Конфиденциальность: шифрование пакетов для предотвращения прослушивания неавторизованными источниками.
• Целостность: целостность сообщений для гарантии, что пакет не был изменён в пути, включая опциональный механизм защиты от повторной передачи пакетов.
• Аутентификация: проверка, что сообщение поступило от действительного источника.

В декабре 2002 года IETF опубликовал серию документов RFC 3411-RFC 3418, которые составили полноценный интернет-стандарт STD 62^[11] и определили SNMPv3 как текущую стандартную версию SNMP^[12]. IETF присвоил SNMPv3 высший уровень зрелости RFC и считает предыдущие версии устаревшими (обозначая их как «Исторические» или «Устаревшие»). На практике реализации SNMP часто поддерживают несколько версий: обычно SNMPv1, SNMPv2c и SNMPv3.

SNMP широко используется в инструментах мониторинга, таких как Nagios, для сбора данных о состоянии и производительности сетевых устройств. Несмотря на то, что протокол считается зрелым и разработка новых версий (например, SNMPv4) не ведётся^[13][14], его применение продолжает развиваться в соответствии с современными технологическими тенденциями.

Ключевые направления развития использования SNMP включают:

• Интеграция с ИИ и машинным обучением: Современные системы мониторинга всё чаще используют аналитику на основе ИИ для обработки данных, полученных по SNMP. Это позволяет прогнозировать сбои, выявлять аномалии в работе сети и анализировать долгосрочные тенденции производительности^[15].
• Применение в IoT и периферийных вычислениях: Для мониторинга большого количества устройств с ограниченными ресурсами разрабатываются облегчённые SNMP-агенты. Это расширяет возможности применения протокола в сетях Интернета вещей и на границе сети (Edge)^[15].
• Усиление безопасности: Наблюдается устойчивая тенденция миграции с уязвимых версий SNMPv1 и SNMPv2c на SNMPv3. Использование встроенных в SNMPv3 механизмов аутентификации и шифрования становится стандартом де-факто для защиты управляющего трафика^[15][16].

В то же время в индустрии управления сетями фокус смещается в сторону более новых протоколов, таких как NETCONF и RESTCONF, использующих язык моделирования данных YANG^[17]. Эти технологии считаются дополнением или преемниками SNMP, особенно в задачах автоматизации и сложного управления конфигурациями, в то время как SNMP сохраняет свою актуальность для задач мониторинга состояния и производительности^[17][13].

Реализации протокола SNMP могут различаться у разных производителей. В некоторых случаях SNMP внедряется как дополнительная функция системы и не считается фундаментальным элементом её дизайна. Крупные производители часто чрезмерно расширяют свою собственную CLI для настройки и управления системами. В феврале 2002 года Координационный центр команды реагирования на компьютерные чрезвычайные ситуации (CERT-CC) Институт программной инженерии Университета Карнеги — Меллона (CM-SEI) провёл консультационный процесс по SNMPv1, CA-2002-03, после чего Группа безопасного программирования Университет Оулу провела анализ управления SNMP-сообщениями. Большинство реализаций SNMP, независимо от версии протокола, используют один и тот же программный код для декодирования PDU. Поэтому многим производителям пришлось выпускать патчи для своих реализаций SNMP. Среди других проблем были обнаружены ошибки при декодировании trap-сообщений SNMP, получаемых станцией управления SNMP, или запросов, получаемых агентом SNMP на сетевом устройстве.

Мощные возможности записи SNMP, позволяющие настраивать сетевые устройства, массово не используются многими производителями, отчасти из-за отсутствия безопасности в версиях SNMP до v3, а также потому, что многие устройства просто не могут быть настроены через изменения объектов MIB. Требования к операции Set SNMP сложно реализовать корректно, и многие производители предпочли не поддерживать Set — вероятно, чтобы снизить издержки и уменьшить размер кода, среди прочих причин.

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

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

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

В 2003 году продолжалась работа по устранению последствий масштабных уязвимостей в обработке сообщений SNMPv1, обнаруженных в 2002 году группой Oulu University Secure Programming Group (OUSPG) и освещённых в бюллетене CERT Advisory CA-2002-03. Эти проблемы могли приводить к отказу в обслуживании (DoS), нестабильной работе оборудования и, в некоторых случаях, к получению неавторизованного доступа^[18][19]. В декабре 2003 года была также обнаружена уязвимость в популярной реализации Net-SNMP (версии до 5.0.9), которая позволяла пользователям, которым был явно запрещён доступ к определённым объектам MIB, всё равно получать к ним доступ на чтение^[20].

В апреле 2004 года компания Cisco сообщила об уязвимости (CVE-2004-0714) в программном обеспечении Cisco IOS, где специально сформированный SNMP-запрос мог привести к перезагрузке устройства, вызывая отказ в обслуживании. Проблема затрагивала все три версии протокола^[21]. Также была обнаружена уязвимость (CVE-2004-0635) в анализаторе сетевого трафика Ethereal (ныне Wireshark), которая приводила к сбою программы при обработке некорректно сформированного SNMP-пакета^[22]. Основной проблемой безопасности в этот период оставалось широкое использование устаревших версий SNMPv1 и SNMPv2c, передающих данные в открытом виде, и медленный переход на более безопасный SNMPv3 из-за его сложности^[23][24].

В пакете Net-SNMP были выявлены уязвимости, позволявшие удалённо вызвать отказ в обслуживании: CVE-2005-2177 (через отправку TCP-пакета длиной в 1 байт) и CVE-2005-4837 (в режиме master agentx)^[25]. Кроме того, в беспроводных IP-телефонах Cisco 7920 (CVE-2005-3803) были обнаружены жёстко закодированные, неизменяемые строки сообщества, что позволяло удалённым злоумышленникам считывать и изменять конфигурацию устройств^[26][27].

Была обнаружена уязвимость строкового формата (CVE-2006-0250) в демоне snmptrapd из состава утилит CMU SNMP, позволявшая удалённо выполнить произвольный код^[28]. В коммутаторах 3Com SS3 4400 (CVE-2006-5382) специальный запрос позволял получить строку сообщества с правами на запись^[29]. В реализации SNMP в Microsoft Windows (VU#901584) была найдена уязвимость повреждения памяти, которая могла привести к переполнению буфера и удалённому выполнению кода^[30].

В Net-SNMP (версии до 5.4.1) была найдена уязвимость (CVE-2007-5846), при которой GETBULK-запрос с большим значением параметра `max-repeaters` приводил к отказу в обслуживании из-за чрезмерного потребления ресурсов^[31]. В модулях межсетевых экранов Cisco FWSM (CVE-2007-0967) некорректно сформированные SNMP-запросы могли вызвать перезагрузку устройства^[32]. В расширении SNMP для PHP (CVE-2007-1413) была обнаружена уязвимость переполнения буфера в функции `snmpget`^[33].

Год был отмечен обнаружением критической уязвимости в механизме аутентификации SNMPv3 (CVE-2008-0960) с оценкой 10.0 по шкале CVSS. Проблема заключалась в некорректной проверке кода аутентификации сообщения (HMAC), что позволяло атакующему указать длину HMAC, равную одному байту. Это делало подбор кода тривиальной задачей и позволяло обойти аутентификацию, зная имя пользователя^[34][35]. Уязвимость затронула множество продуктов от различных производителей, включая Net-SNMP, Cisco, HP и Juniper^[36].

В HP OpenView Network Node Manager (CVE-2009-3849) была обнаружена уязвимость переполнения буфера, позволявшая удалённо выполнить произвольный код без аутентификации^[37]. В Net-SNMP (CVE-2008-6123) была найдена проблема, из-за которой некорректно обрабатывались правила авторизации клиентов, что позволяло обходить ограничения доступа^[38].

В коммутаторах Cisco Industrial Ethernet 3000 серии (CVE-2010-1574) были выявлены жёстко запрограммированные имена сообщества («public» и «private»), которые восстанавливались после каждой перезагрузки устройства. Это позволяло удалённому злоумышленнику получать несанкционированный доступ для чтения и изменения конфигурации^[39][40].

Исследование Технологического института Джорджии выявило фундаментальный недостаток в протоколе SNMPv3. Проблема заключалась в том, что сообщения в процессе обнаружения (discovery) отправляются в незашифрованном и неаутентифицированном виде. Это создавало условия для проведения атаки «человек посередине» (MITM), при которой злоумышленник мог манипулировать обменом ключами, что позволяло ему расшифровывать трафик и подделывать сообщения даже в защищённом режиме `authPriv`^[41][42].

В Net-SNMP были обнаружены уязвимости, приводившие к отказу в обслуживании. CVE-2012-6151 позволяла вызвать сбой или бесконечный цикл демона `snmpd` при тайм-ауте субагента AgentX^[43]. CVE-2012-2141 была связана с ошибкой индексации массива, которая приводила к сбою при обработке специально сформированного GET-запроса^[44].

Компания Cisco выпустила предупреждения об уязвимостях в IOS XR. CVE-2013-1204 была связана с утечкой памяти, вызванной большим количеством UDP-пакетов на порт SNMP 162, что приводило к перезагрузке процесса. CVE-2013-1234 позволяла удалённому аутентифицированному злоумышленнику вызвать перезапуск процесса SNMP с помощью специально созданных пакетов^[45].

Была зафиксирована уязвимость (CVE-2014-3565) в Net-SNMP, где специально созданное trap-сообщение могло вызвать сбой демона `snmptrapd`^[46][47]. Кроме того, отчёт компании Rapid7 показал, что некоторые устройства (Brocade ServerIron, модемы Netopia) по умолчанию раскрывали критическую информацию, такую как хеши паролей и ключи WPA, через SNMP со стандартной строкой «public».

В Net-SNMP была обнаружена уязвимость (CVE-2015-5621) некорректной обработки ошибок при разборе SNMP-пакетов, что могло привести к отказу в обслуживании или выполнению произвольного кода. В реализации Net-SNMP для OpenBSD (CVE-2015-8100) небезопасные права доступа к конфигурационному файлу `snmpd.conf` позволяли локальным пользователям читать чувствительную информацию, включая строки сообщества^[48].

В компоненте веб-приложения OpenNMS были выявлены уязвимости межсайтового скриптинга (XSS) (CVE-2016-6555, CVE-2016-6556) через обработку SNMP-ловушек. В адаптерах SNMP/Web для ИБП от General Electric (CVE-2016-0862) была обнаружена уязвимость, позволявшая удалённым аутентифицированным пользователям получать конфиденциальную информацию об учётных записях в незашифрованном виде^[49].

Компания Cisco раскрыла информацию о нескольких критических уязвимостях в своей реализации SNMP в IOS и IOS XE (включая CVE-2017-6742), вызванных переполнением буфера. Они позволяли удалённому злоумышленнику выполнить произвольный код или вызвать отказ в обслуживании^[50]. Для атаки требовалось знание строки сообщества для чтения (для v1/v2c) или учётных данных пользователя (для v3)^[51]. Позже стало известно, что эти уязвимости использовались в реальных атаках^[52]. Также была обнародована уязвимость «Stringbleed» (CVE-2017-5135), затрагивавшая устройства различных поставщиков, которые не проверяли должным образом аутентификацию по строке сообщества, позволяя считывать конфиденциальные данные с любой строкой.

В Net-SNMP была обнаружена уязвимость высокого риска (CVE-2018-1000116), позволявшая удалённо выполнить произвольный код^[53]. Cisco сообщила о нескольких проблемах, включая DoS в коммутаторах Catalyst (CVE-2018-0161)^[54], DoS в NX-OS (CVE-2018-0456)^[55] и раскрытие информации в WAAS из-за жёстко закодированной строки сообщества (CVE-2018-0329)^[56].

В Net-SNMP была обнаружена уязвимость двойного освобождения памяти (CVE-2019-20892) при обработке GetBulk-запросов в SNMPv3, что могло привести к отказу в обслуживании^[57]. В Cisco NX-OS (CVE-2019-1969) была найдена уязвимость обхода списков контроля доступа (ACL)^[58], а в промышленных устройствах Siemens SIMATIC HMI (CVE-2019-19276) — уязвимость, приводившая к сбою службы SNMP^[59]. Также был опубликован отчёт о массовой уязвимости утечки данных на шлюзах и модемах 23 производителей, которые позволяли считывать данные с любой строкой сообщества^[60].

В Net-SNMP была выявлена уязвимость (CVE-2020-15862), позволявшая выполнять произвольные команды с правами суперпользователя через SNMP WRITE доступ к EXTEND MIB^[61][62]. Исследование, опубликованное Runzero, показало, что даже ненастроенные службы SNMPv3 могут раскрывать важную информацию (MAC-адрес, производитель, время работы) в ответ на неаутентифицированные запросы обнаружения, так как EngineID часто содержит MAC-адрес^[63].

В программном обеспечении Cisco ASA и FTD была обнаружена уязвимость (CVE-2021-34794) в механизме контроля доступа SNMPv3, которая позволяла удалённому неаутентифицированному злоумышленнику запрашивать данные по SNMP, если у него были действительные учётные данные для выполнения запроса^[64]. Фундаментальные проблемы старых версий, такие как передача данных в открытом виде и слабая аутентификация, оставались актуальными.

В MikroTik RouterOS (CVE-2022-45315) была обнаружена уязвимость чтения за пределами выделенной области памяти, позволявшая выполнить произвольный код^[65]. В Net-SNMP были найдены уязвимости (CVE-2022-44792, CVE-2022-44793), приводившие к отказу в обслуживании из-за ошибки `NULL Pointer Exception`^[66]. В продуктах Cisco (CVE-2022-20918) была выявлена проблема использования учётных данных по умолчанию для SNMPv1/v2, что могло привести к утечке информации^[67].

Была обнаружена критическая уязвимость (CVE-2023-26602, CVSS 9.8) в прошивке ASUS ASMB8 iKVM, позволявшая удалённо выполнить произвольный код через SNMP^[68]. Уязвимости, приводившие к отказу в обслуживании, были найдены в продуктах Cisco (CVE-2023-20200)^[69] и Juniper (CVE-2023-22400)^[70]. В то же время сохранялась актуальность фундаментальных проблем, таких как использование SNMP для DDoS-атак с усилением^[71].

В программном обеспечении Cisco IOS и IOS XE была обнаружена уязвимость (CVE-2024-20373), связанная с некорректной реализацией ACL для SNMP по IPv4, что могло привести к обходу ограничений доступа^[72][73]. Другая уязвимость в Cisco IOS XR (CVE-2024-20319) позволяла обойти политики защиты и получить доступ к SNMP-серверу^[74]. Общие проблемы, такие как передача учётных данных в открытом виде в SNMPv1/v2c, оставались значимыми^[75]. Даже в SNMPv3 неправильная конфигурация (например, использование режима `noAuthNoPriv`) сводила на нет его защитные преимущества^[76].

В начале года была раскрыта серия уязвимостей в продуктах Cisco (включая CVE-2025-20169—20176), позволяющая аутентифицированному удалённому злоумышленнику вызвать отказ в обслуживании на устройствах с IOS, IOS XE и IOS XR путём отправки специально созданных SNMP-запросов^[77][78]. Отдельно была отмечена уязвимость (CVE-2025-20151) в реализации SNMPv3 в Cisco IOS и IOS XE, которая позволяла злоумышленнику с действительными учётными данными обходить ограничения доступа, даже если его IP-адрес был заблокирован или имя пользователя удалено из конфигурации.

Поскольку SNMP предназначен для удалённой настройки и мониторинга сетевых устройств администраторами, он также может быть использован для проникновения в LAN. Если SNMP не используется в сети, его следует отключить, так как помимо создания уязвимости он будет потреблять доступную пропускную способность и ресурсы процессора. Значительное количество программных инструментов может сканировать всю сеть через SNMP, поэтому ошибки конфигурации режима чтения-записи могут сделать сеть уязвимой для атак^[79].^:52

В 2001 году Cisco опубликовала информацию о том, что даже в режиме только для чтения реализация Cisco IOS 11.0 и 12.0 (операционная система, используемая в коммутаторах и маршрутизаторах) уязвима для определённых атак отказа в обслуживании. Эти проблемы безопасности могут быть устранены обновлением IOS^[80]. При настройке режима только для чтения следует уделять внимание настройке контроля доступа и тому, с каких IP-адресов принимаются SNMP-сообщения. Если SNMP-серверы идентифицируются по IP-адресу, SNMP должен отвечать только этим адресам, а сообщения с других адресов должны быть отклонены. Однако подмена IP-адреса остаётся проблемой^[79].^:54

SNMP доступен в нескольких версиях: 1, 2 и 3; каждая имеет свои проблемы безопасности. SNMP v1 передаёт пароли в открытом виде по сети, поэтому пароли могут быть перехвачены с помощью анализатора пакетов. SNMP v2 позволяет хешировать пароли с помощью MD5, но это необходимо настраивать. Практически все приложения управления сетью поддерживают SNMP v1, но не обязательно SNMP v2 или v3. SNMP v2 был разработан специально для обеспечения безопасности, то есть аутентификации, конфиденциальности и авторизации, но только версия SNMP 2c была одобрена IETF, тогда как версии 2u и 2* не были одобрены из-за проблем безопасности. SNMP v3 использует MD5, SHA и алгоритмы ключей для защиты от неавторизованного изменения информации и атак подмены. При необходимости более высокого уровня безопасности может быть опционально использован алгоритм DES в режиме цепочки блоков. SNMP v3 реализован начиная с версии 12.0(3)T^:52 Cisco IOS.

SNMPv3 подвержен атакам перебором и словесным атакам для угадывания ключей аутентификации или шифрования, если эти ключи создаются с помощью коротких (или слабых) паролей или паролей, встречающихся в словаре. SNMPv3 допускает случайно распределённые ключи шифрования, а также генерацию паролей пользователем. Риск угадывания строк аутентификации по передаваемым по сети значениям зависит от используемой хеш-функции и длины значения. SNMPv3 использует протокол аутентификации HMAC-SHA-2 для модели безопасности пользователя (USM). Обмен вызов-ответ не используется для повышения безопасности. SNMPv3 (как и другие версии SNMP) — протокол без состояния, и был разработан для минимизации количества взаимодействий между агентом и менеджером. Поэтому введение обмена вызов-ответ для каждой команды наложило бы дополнительную нагрузку на агента (и, вероятно, на саму сеть), что разработчики протокола сочли чрезмерным и неприемлемым.

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

Приложения управления сетью на основе SNMP многократно отправляют пароли по сети в ходе обычных операций. Поэтому пароли в открытом виде представляют серьёзный риск безопасности. Если используется SNMP v2, сетевые администраторы должны включить шифрование паролей на сетевых устройствах, которые являются SNMP-серверами. Это можно сделать командой snmp-server enable traps snmp authentication md5.^:53

Многие реализации SNMP включают функцию автоматического обнаружения, когда новый сетевой компонент, например коммутатор или маршрутизатор, обнаруживается и автоматически группируется. В SNMPv1 и v2c это реализуется через строку сообщества, которая передаётся в открытом виде другим устройствам. Поэтому строки сообщества, установленные по умолчанию, являются общедоступными для чтения и приватными для чтения-записи.^:1874 SNMP был первым в списке наиболее распространённых проблем конфигурации по умолчанию Института SANS и десятым в списке наиболее критических угроз интернет-безопасности 2000 года^[81]. Администраторы сетей и систем редко меняют эти настройки.^:1874 Строка сообщества, передаваемая SNMP по сети, не шифруется. Как только строка безопасности становится известна за пределами организации, она может стать целью атаки. Чтобы предотвратить простое обнаружение строки сообщества, SNMP должен быть настроен на передачу trap-сообщений о сбоях аутентификации имени сообщества, а SNMP-менеджер должен быть настроен на реагирование на такие trap-сообщения.^:54

SNMPv1 и v2 уязвимы к атакам подмены IP-адреса, независимо от того, используется ли TCP или UDP, и объекты обхода списка доступа устройств были реализованы для ограничения доступа к SNMP. Механизмы безопасности SNMPv3, такие как USM или TSM, предотвращают успешные атаки. Использование SNMPv3 VACM (контроль доступа на основе представлений) бессмысленно без защиты сообщений с помощью USM или TSM.

• CMIP
• CMOT
• NETCONF

• Nagios
• Zenoss
• Zabbix
• NMIS