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)[править | править вики-текст]

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

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

Ссылки[править | править вики-текст]

Примечания[править | править вики-текст]