SNMP | это... Что такое SNMP? (original) (raw)

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 предоставляет данные для управления в виде переменных, описывающих конфигурацию управляемой системы. Эти переменные могут быть запрошены (а иногда и заданы) управляющими приложениями.

Содержание

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

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

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

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

Управляемое устройство — элемент сети (оборудование или программное средство), реализующий интерфейс управления (не обязательно 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:

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

Версию 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 на основе пользователей (SNMPv2) определен в 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 устройств, а именно:

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

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

snmpset и перезагрузка 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

snmpset -v 2c -c xxas5300xx 10.26.95.231 «.1.3.6.1.4.1.9.2.9.9.0» i 2

RFC ссылки

Ссылки

Примечания

  1. ↑ Система управления сетью
Просмотр этого шаблона Схемы URI
Официальные aaa: • aaas: • acap: • cap: • cid: • crid: • data: • dav: • dict: • dns: • fax: • file: • ftp: • go: • gopher: • h323: • http: • https: • im: • imap: • ldap: • mailto: • mid: • news: • nfs: • nntp: • pop: • pres: • rtsp: • sip: • sips: • snmp: • tel: • telnet: • urn: • wais: • xmpp:
Неофициальные about: • aim: • bolo: • btc: • bzr: • callto: • chrome: • cvs: • daap: • ed2k: • ed2kftp: • feed: • fish: • git: • gizmoproject: • iax2: • irc: • ircs: • lastfm: • ldaps: • magnet: • mms: • msnim: • psyc: • rsync: • secondlife: • skype: • ssh: • svn: • sftp: • smb: • sms: • soldat: • steam: • unreal: • ut2004: • view-source: • vzochat: • webcal: • xfire: • ymsgr:
Просмотр этого шаблона Основные протоколы TCP/IP по уровням модели OSI (Список портов TCP и UDP)
Физический Ethernet • RS-232 • EIA-422 • RS-449 • RS-485
Канальный Ethernet • PPPoE • PPP • L2F • 802.11 Wi-Fi • 802.16 WiMax • Token ring • ARCNET • FDDI • HDLC • SLIP • ATM • CAN • DTM • X.25 • Frame relay • SMDS • STP • ERPS
Сетевой IPv4 • IPv6 • IPsec • ICMP • IGMP • ARP • RARP • RIP2 • OSPF
Транспортный TCP • UDP • SCTP • DCCP • RDP/RUDP • RTP • GRE
Сеансовый ADSP • H.245 • iSNS • NetBIOS • PAP • RPC • L2TP • PPTP • RTCP • SMPP • SCP • ZIP • SDP
Представления XDR • SSL • TLS
Прикладной BGP • HTTP • HTTPS • DHCP • IRC • SNMP • DNS • DNSSEC • NNTP • XMPP • SIP • IPP • NTP • SNTP • Электронная почта (SMTP • POP3 • IMAP4) • Передача файлов (FTP • TFTP • SFTP) • Удалённый доступ (rlogin • Telnet • SSH • RDP)
Другие прикладные OSCAR • CDDB • Multicast FTP • Multisource FTP • BitTorrent • Gnutella • Skype
Есть более полная статья