SNMP (SNMP)

Перейти к навигации Перейти к поиску
SNMP
Название Simple Network Management Protocol
Уровень (по модели OSI) Прикладной
Семейство UDP
Порт/ID 161/UDP,162/UDP
Назначение протокола Управление сетевыми устройствами
Спецификация RFC 1155, RFC 1212, RFC 1213, RFC 1157, RFC 3411
Основные реализации (клиенты) Встроен во все сетевые ОС
Логотип Викисклада Медиафайлы на Викискладе

SNMP (англ. Simple Network Management Protocol — простой протокол сетевого управления) — стандартный интернет-протокол для управления устройствами в IP-сетях. К поддерживающим SNMP устройствам относятся маршрутизаторы, коммутаторы, серверы, рабочие станции, принтеры, модемные стойки и другие. Протокол обычно используется в системах сетевого управления для контроля подключённых к сети устройств на предмет условий, которые требуют внимания администратора. SNMP определён Инженерным советом интернета (IETF) как компонент TCP/IP. Он состоит из набора стандартов для сетевого управления, включая протокол прикладного уровня, схему баз данных и набор объектов данных.

Обзор и основные понятия

[править | править код]
Principle of SNMP Communication

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

Управляемые протоколом SNMP сети состоят из трех ключевых компонентов:

  • Управляемое устройство;
  • Агент — программное обеспечение, запускаемое на управляемом устройстве, либо на устройстве, подключенном к интерфейсу управления управляемого устройства;
  • Система сетевого управления (Network Management System, NMS) — программное обеспечение, взаимодействующее с менеджерами для поддержки комплексной структуры данных, отражающей состояние сети[1].

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

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

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

Базы управляющей информации (MIB)

[править | править код]

Так как адреса объектов устройств определяются в цифровом формате, их сложно запомнить. Для упрощения применяются базы управляющей информации (MIB). Базы MIB описывают структуру управляемых данных на подсистеме устройства; они используют иерархическое пространство имён, содержащее идентификаторы объектов (OID-ы). Каждый OID состоит из двух частей: текстового имени и SNMP адреса в цифровом виде. Базы MIB являются необязательными и выполняют вспомогательную роль по переводу имени объекта из человеческого формата (словесного) в формат SNMP (цифровой). Очень похоже на DNS сервера. Так как структура объектов на устройствах разных производителей не совпадает, без базы MIB практически невозможно определить цифровые SNMP адреса нужных объектов. Базы MIB используют нотацию, заданную в ASN.1.

Детали протокола

[править | править код]

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

В SNMPv1 указано пять основных протокольных единиц обмена (protocol data units — PDU). Еще две PDU, GetBulkRequest и InformRequest, были введены в SNMPv2 и перенесены в SNMPv3.

Все PDU протокола SNMP построены следующим образом:

IP header (IP-заголовок) UDP header (UDP-заголовок) version (версия) community (пароль) PDU-type (PDU-тип) request-id (id запроса) error-status (статус ошибки) error-index (индекс ошибки) variable bindings (связанные переменные)

Ниже перечислены семь протокольных единиц обмена SNMP:

GetRequest

[править | править код]

Запрос от менеджера к объекту для получения значения переменной или списка переменных. Требуемые переменные указываются в поле variable bindings (раздел поля values при этом не используется). Получение значений указанной переменной должно быть выполнено агентом как Атомарная операция. Менеджеру будет возвращён Response (ответ) с текущими значениями.

SetRequest

[править | править код]

Запрос от менеджера к объекту для изменения переменной или списка переменных. Связанные переменные указываются в теле запроса. Изменения всех указанных переменных должны быть выполнены агентом как атомарная операция. Менеджеру будет возвращён Response с (текущими) новыми значениями переменных.

GetNextRequest

[править | править код]

Запрос от менеджера к объекту для обнаружения доступных переменных и их значений. Менеджеру будет возвращён Response со связанными переменными для переменной, которая является следующей в базе MIB в лексикографическом порядке. Обход всей базы MIB агента может быть произведён итерационным использованием GetNextRequest, начиная с OID 0. Строки таблицы могут быть прочтены, если указать в запросе OID-ы колонок в связанных переменных.

GetBulkRequest

[править | править код]

Улучшенная версия GetNextRequest. Запрос от менеджера к объекту для многочисленных итераций GetNextRequest. Менеджеру будет возвращён Response с несколькими связанными переменными, обойдёнными начиная со связанной переменной (переменных) в запросе. Специфичные для PDU поля non-repeaters и max-repetitions используются для контроля за поведением ответа. GetBulkRequest был введён в SNMPv2.

Response

[править | править код]

Возвращает связанные переменные и значения от агента менеджеру для GetRequest, SetRequest, GetNextRequest, GetBulkRequest и InformRequest. Уведомления об ошибках обеспечиваются полями статуса ошибки и индекса ошибки.

Эта единица используется как ответ и на Get-, и на Set-запросы, в SNMPv1 называется GetResponse .

Trap

[править | править код]

Асинхронное уведомление от агента — менеджеру. Включает в себя текущее значение sysUpTime, OID, определяющий тип trap (ловушки), и необязательные связанные переменные. Адресация получателя для ловушек определяется с помощью переменных trap-конфигурации в базе MIB. Формат trap-сообщения был изменён в SNMPv2 и PDU переименовали в SNMPv2-Trap.

InformRequest

[править | править код]

Асинхронное уведомление от менеджера менеджеру или от агента менеджеру. Уведомления от менеджера менеджеру были возможны уже в SNMPv1 (с помощью Trap), но SNMP обычно работает на протоколе UDP, в котором доставка сообщений не гарантирована, и не сообщается о потерянных пакетах. InformRequest исправляет это обратным отправлением подтверждения о получении. Получатель отвечает Response-ом, повторяющим всю информацию из InformRequest. Этот PDU был введён в SNMPv2.

Разработка и использование

[править | править код]

Версия 1

[править | править код]

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

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

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

Эти протоколы были пересмотрены в следующих RFC:

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

Через некоторое время, RFC 1156 (MIB-1) был заменён более используемым:

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

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

Версия 2

[править | править код]

SNMPv2 (RFC 1441-RFC 1452) пересматривает Версию 1 и включает в себя улучшения в области производительности, безопасности, конфиденциальности и связях между менеджерами. Протокол ввел GetBulkRequest, альтернативу итерационному применению GetNextRequest для получения большого количества управляющих данных через один запрос. В то же время, новая система безопасности на основе сторон из SNMPv2 так и не получила широкое распространение, так как рассматривалась многими как слишком сложная.

SNMPv2 на основе сообществ (SNMPv2c) определён в RFC 1901-RFC 1908. На своей начальной стадии эта версия была неофициально известна как SNMPv1.5. SNMPv2c включает SNMPv2 без её спорной модели безопасности; вместо этого используется простая схема безопасности на основе сообществ из SNMPv1. SNMPv2c часто воспринимался де-факто как стандарт SNMPv2 несмотря на то, что официально он был всего лишь «черновым стандартом» (Draft Standard).

SNMPv2 на основе пользователей (SNMPv2u) определён в RFC 1909-RFC 1910. По сути, это компромисс, который пытается предложить более высокую, чем в SNMPv1, безопасность, но без излишней сложности, характерной для SNMPv2. Один из вариантов этой версии, SNMP v2*, был коммерческим, а сам механизм в итоге был принят в качестве одной из двух структур безопасности в SNMP v3.

Взаимодействие SNMPv1 и SNMPv2с

[править | править код]

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

Прокси-агенты

[править | править код]

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

  • Система сетевого управления (Network management system, NMS) SNMPv2 выдаёт команды, предназначенные для 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.

Версия 3

[править | править код]

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

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

В отличие от SNMPv1 и v2, в SNMPv3 каждое сообщение содержит параметры безопасности, которые закодированы как строка октетов. Значение этих параметров зависит от используемой модели безопасности.

SNMPv3 предоставляет важные особенности безопасности:

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

С 2004 года IETF признаёт SNMPv3, определённый в RFC 3411, RFC 3418 (также известный как STD0062) в качестве текущей стандартной версии SNMP. IETF отметил SNMPv3 как полный Интернет-стандарт, что является самым высоким уровнем готовности для RFC. При этом более ранние версии считаются устаревшими (обозначаются как «исторические» — Historic).

На практике в реализациях SNMP часто поддерживаются несколько версий: v1, v2c и v3.

Вопросы реализации

[править | править код]

Реализации SNMP варьируются среди поставщиков платформ. В отдельных случаях SNMP не считается достаточно серьёзным для элемента основной разработки и потому является просто дополнительной функцией. Некоторые крупные поставщики оборудования имеют склонность к чрезмерному расширению своих собственных интерфейсов командной строки (command line interface, CLI) и систем контроля.

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

Ресурсная индексация

[править | править код]

Модульные устройства могут динамически увеличивать или уменьшать свои SNMP-индексы (также называемые случаями) при добавлении или удалении оборудования. Это чаще всего используется с аппаратными средствами, хотя виртуальные интерфейсы имеют тот же эффект. Значения индекса, как правило, назначаются во время загрузки и остаются неизменными до следующей перезагрузки. Индексы оборудования или виртуальных сущностей, добавленных при «живом» устройстве, могут назначаться под конец существующего диапазона и, возможно, переназначаться при следующей перезагрузке.

Безопасность

[править | править код]
  • SNMP версий 1 и 2c подвержены перехвату пакетов со строками сообщений, так как они не используют шифрование.
  • Все версии SNMP подвержены атакам грубой силой и словарным перебором для угадывания строк сообщества, строк аутентификации, ключей аутентификации, строк шифрования или ключей шифрования, поскольку они не используют «рукопожатие» вида запрос-ответ.
  • Хотя SNMP работает с TCP и другими протоколами, обычно он используется с UDP, то есть без установки соединения и с уязвимостью для атак подменой IP. Для ограничения SNMP-доступа могут быть использованы списки доступа к устройству, но и механизмы защиты SNMPv3 способны успешно мешать атакам.
  • Обширные возможности в настройке SNMP многими поставщиками не используются в полную силу, отчасти из-за недостатка безопасности в версиях SNMP до SNMPv3, а также из-за того, что многие устройства просто не могут быть настроены с помощью изменений отдельного объекта базы MIB.
  • SNMP возглавляет составленный SANS Institute список «Common Default Configuration Issues» с вопросом изначальной установки строк сообщества на значения «public» и «private» и занимал десятую позицию в SANS Top 10 Самых критических угроз Интернет-безопасности за 2000 год.

Автоматическая настройка

[править | править код]

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

Примеры использования утилит SNMP

[править | править код]

snmpset и перезагрузка Cisco as53xx

  • Настройка SNMP на Cisco as53xx
as5350>en
Password:
as5350#conf t
Enter configuration commands, one per line. End with CNTL/Z.
  • Список №1: Разрешить доступ из сети 10.26.95.224/27 или 255.255.255.224
as5350(config)#access-list 1 permit 10.26.95.224 0.0.0.31
  • Список № 2: Разрешить доступ с IP 10.26.95.254 и 10.26.95.251
as5350(config)#access-list 2 permit host 10.26.95.254
as5350(config)#access-list 2 permit host 10.26.95.251
  • Настройка snmp-server для чтения и записи со строкой сообщества xxas5300xx. SNMP-доступ разрешён только для access-list 2 (для 2-х IP, для остальных IP неявно запрещён)
as5350(config)#snmp-server community xxas5300xx rw 2
  • Разрешаем перезагрузку Cisco по SNMP.
as5350(config)#snmp-server system-shutdown
as5350(config)#exit
  • Выполним команду для перезагрузки Cisco (параметры **.1.3.6.1.4.1.9.2.9.9.0 i 2** взяты из MIB):
snmpset -v 2c -c xxas5300xx 10.26.95.231 ".1.3.6.1.4.1.9.2.9.9.0" i 2

RFC ссылки

[править | править код]
  • RFC 1155 (STD 16) — Структура и идентификация управляющей информации в сетях на основе стека протоколов TCP/IP
  • RFC 1156 (Historic) — База управляющей информации для сетевого управления в сетях на основе стека протоколов TCP/IP
  • RFC 1157 (Historic) — Простой протокол сетевого управления (SNMP)
  • RFC 1213 (STD 17) — База управляющей информации для сетевого управления в сетях на основе стека протоколов TCP/IP: MIB-II
  • RFC 1452 (Informational) — 'Сосуществование версий 1 и 2 Интернет-стандарта Network Management Framework (пересмотрен в RFC 1908)
  • RFC 1901 (Experimental) — Введение в SNMPv2 на основе сообществ
  • RFC 1902 (Draft Standard) — Структура управляющей информации для SNMPv2 (пересмотрен в RFC 2578)
  • RFC 1908 (Standards Track) — Сосуществование версий 1 и 2 Интернет-стандарта Network Management Framework
  • RFC 2570 (Informational) — Введение в версию 3 Интернет-стандарта Network Management Framework (пересмотрен в RFC 3410)
  • RFC 2578 (STD 58) — Структура управляющей информации, версия 2 (SMIv2)
  • RFC 3410 (Informational) — Вопросы введения и применения Интернет-стандарта Network Management Framework'
  • STD 62
    • RFC 3411 — Архитектура для описания SNMP Management Framework
    • RFC 3412 — Обработка и отправление сообщений для SNMP
    • RFC 3413 — Приложения SNMP
    • RFC 3414 — Модель безопасности на основе пользователей (USM) для SNMPv3
    • RFC 3415 — View-based Access Control Model (VACM) для SNMP
    • RFC 3416 — Версия 2 протокольных операций для SNMP
    • RFC 3417 — Привязки к транспорту для SNMP
    • RFC 3418 — База управляющей информации (MIB) для SNMP
  • RFC 3430 (Experimental) — SNMP над привязками к транспорту в TCP
  • RFC 3584 (BCP 74) — Сосуществование версий 1, 2 и 3 Интернет-стандарта Network Management Framework
  • RFC 3826 (Proposed) — Алгоритм шифрования AES (Advanced Encryption Standard) в модели безопасности на основе пользователей в SNMP
  • RFC 5343 (Proposed) — Контекстное EngineID-обнаружение в SNMP
  • RFC 5590 (Draft) — Транспортная подсистема для SNMP
  • RFC 5591 (Draft) — Транспортная модель безопасности для SNMP
  • RFC 5592 (Proposed) — Транспортная модель Secure Shell для SNMP
  • RFC 5608 (Proposed) — Использование службы аутентификации удалённых пользователей по коммутируемым каналам связи (RADIUS) в транспортных моделей в SNMP
  • RFC 6353 (Draft) — Транспортная модель TLS для SNMP

Ссылки

[править | править код]

Примечания

[править | править код]
  1. ↑ Система управления сетью
Источник — https://ru.wikipedia.org/w/index.php?title=SNMP&oldid=137642540