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-сетях на основе архитектур UDP/TCP. К поддерживающим SNMP устройствам относятся маршрутизаторы, коммутаторы, серверы, рабочие станции, принтеры, модемные стойки и другие. Протокол обычно используется в системах сетевого управления для контроля подключенных к сети устройств на предмет условий, которые требуют внимания администратора. SNMP определен Инженерным советом интернета (IETF) как компонент TCP/IP. Он состоит из набора стандартов для сетевого управления, включая протокол прикладного уровня, схему баз данных и набор объектов данных.

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

Обзор и основные понятия[править | править исходный текст]

Principle of SNMP Communication

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

Менеджеры SNMP обрабатывают данные о конфигурации и функционировании управляемых систем и преобразуют их во внутренний формат, удобный для поддержания протокола SNMP. Протокол также разрешает активные задачи управления, например, изменение и применение новой конфигурации через удаленное изменение этих переменных. Доступные через SNMP переменные организованы в иерархии. Эти иерархии, как и другие метаданные (например, тип и описание переменной), описываются базами управляющей информации (базы MIB, от англ. Management information base).

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

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

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

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

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

Базы управляющей информации (MIB)[править | править исходный текст]

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

Детали протокола[править | править исходный текст]

SNMP работает на прикладном уровне TCP/IP (седьмой уровень модели 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-запросы, она была названа GetResponse в SNMPv1.

Trap[править | править исходный текст]

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

InformRequest[править | править исходный текст]

Асинхронное уведомление от менеджера - менеджеру или от агента - менеджеру. Уведомления от менеджера - менеджеру были возможны уже в SNMPv1 (с помощью Trap), но SNMP обычно работает на протоколе UDP, в котором доставка сообщений не гарантирована и не сообщается о потерянных пакетах. InformRequest исправляет это отправлением назад подтверждения о получении. Получатель отвечает Response-ом, повторяющим всю информацию из InfromRequest. Этот 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 не приносит никаких изменений в протокол помимо добавления криптографической защиты, он кажется более отличным за счет новых текстовых соглашений, концепций и терминологии.

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

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

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

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

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

На практике, реализации SNMP часто поддерживают несколько версий: обычно SNMPv1, SNMPv2c, и SNMPv3.

Вопросы реализации[править | править исходный текст]

Реализации 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

Разрешаем reload циски по 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

Ссылки[править | править исходный текст]

Примечания[править | править исходный текст]