SNMP - Простой Протокол Управления Сетью

Оригинал: SNMP
Автор: Andrew Kirch
Дата публикации: 24 января 2017 г.
Перевод: А.Панин
Дата перевода: 4 марта 2017 г.

Как узнать объем свободной оперативной памяти в системе Linux, установленной на настольном компьютере? Это простой вопрос с множеством корректных вариантов ответов: с помощью утилиты free, любой из реализаций утилиты top или утилиты Glances. А как получить ту же информацию от 200 Linux-систем, работающих на реальном и виртуальном аппаратном обеспечении в множестве дата-центров, распределенных по всему миру? Это более сложная задача, которую также можно решить с помощью специального инструмента. Однако, отсутствие новых версий стандарта, а также адекватной поддержки существующих инструментов для Linux приводит к появлению пропиетарных стандартов там, где раньше использовался единый открытый стандарт.

SNMP (Simple Network Management Protocol - Простой Протокол Управления Сетью) был спроектирован в 1990 году для реализации механизма приема и передачи структурированных данных соединенными с сетью устройствами с целью обмена такой информацией, как объем свободной оперативной памяти. Важно обратить внимание на то, что буква M в аббревиатуре SNMP расшифровывается как "Management" ("Управление"), а не "Monitoring" ("Мониторинг"). Несмотря на то, что протокол SNMP обычно используется для запроса информации о состоянии устройств, предусмотренная в протоколе SNMP функция отправки данных может использоваться для изменения конфигурации удаленных устройств. Ввиду отсутствия механизмов защиты данных и аутентификации в рамках протокола SNMP, упомянутая функция отправки данных практически всегда блокируется в современных сетях и не будет обсуждаться в рамках данной статьи.

История развития протокола SNMP

Рабочее предложение (RFC - Request for Comments), описывающее первую версию протокола SNMP было опубликовано Инженерным советом Интернета (IETF - Internet Engineering Task Force) в 1990 году. Описание второй версии протокола SNMP публиковалось в формате отдельных рабочих предложений с 1994 по 1996 год и содержало описание первого механизма защиты данных. Эта версия протокола не получила поддержки из-за генерации высокой нагрузки на сетевые устройства, которые в то время оснащались очень малопроизводительными центральными процессорами. Описанная проблема с производительностью устройств актуальна по сей день и все еще может доставлять проблемы системным администраторам, пытающимся защитить обмен данными по протоколу SNMP. Из-за упомянутых проблем с производительностью версия протокола SNMP 2c (по сути, это вторая версия с элементами из первой версии) стала официальным стандартом. Вместе с выпуском описания протокола SNMP 2c стал развиваться публичный доступ к сети Интернет, поэтому в течение следующих десяти лет проблема с безопасностью протокола приобрела гораздо большую актуальность, ведь версия протокола SNMP 2c предусматривала обмен незашифрованными данными. Третья версия протокола SNMP была представлена в 2003 году и предусматривала добавление поддержки технологии шифрования TLS к предыдущей реализации, описанной в рамках версии стандарта SNMP 2c. Если вам кажется, что все эти усложнения не являются необходимыми, вы должны понять, что многие реализации протокола SNMP ограничиваются функциями стандартов SNMP v1, SNMP v2c и SNMP v3. Это означает, что вы, скорее всего, встретите все версии этого протокола в функционирующих сетях.

Как используется протокол SNMP?

Одной из сложностей, встречающихся при проектировании современных сетей, является масштабируемость, причем достижение оптимальной масштабируемости сети связано с необходимостью использования механизмов управления ресурсами. Реализация протокола SNMP содержит агент, который принимает входящие SNMP-запросы на каждом из узлов и компоненты для поддержки протокола обмена данными, позволяющие осуществлять централизованный сбор данных на отдельной системе под названием "Система сетевого управления" (Network Management System - NMS). Описание данной системы выходит за рамки данной статьи, но стоит сказать о том, что существует множество систем сетевого управления с открытым исходным кодом, таких, как Zabbix, OpenNMS, Nagios и Zenoss. Данные, собираемые каждой из таких систем, являются довольно стандартными и содержат общую информацию о системах, такую, как показатель нагрузки на центральный процессор, объем свободной оперативной памяти, статистические данные, связанные с использованием сетевого соединения и объем данных, размещенных на накопителе.

Структура данных протокола SNMP

SNMP описывает не только устройство агента, но и структуру данных. Каждый объект этой структуры данных имеет идентификатор объекта (Object Identifier - OID). Каждый идентификатор объекта принадлежит к базе управляющей информации (Management Information Base - MIB). Упомянутые идентификаторы объектов и иерархическая структура позволяют рассматривать структуры данных в качестве деревьев. Каждое значение из состава идентификатора объекта представляет ветвь дерева и имеет определенный смысл, а каждая ветвь дерева отделяется с помощью символа точки (.), почти как в сетевых адресах IPv4. По этой причине значение идентификатора объекта может достаточно просто расшифровываться.

Если рассмотреть в качестве примера идентификатор объекта 1.3.6.1.2.1.1.1.0, мы можем без труда декодировать его значения:

• 1 = iso
• 3 = org
• 6 = dod
• 1 = internet
• 2 = IETF Management
• 1.1 = SNMP MIB-2 System
• 0 = sysDescr

На основе декодированных значений можно сделать вывод, что данный идентификатор объекта принадлежит к стандартной базе управляющей информации (более подробно о базах управляющей информации будет сказано ниже) и содержит какое-то описание системы. Давайте рассмотрим реальный пример такого описания, который был отправлен системой, работающей под управлением дистрибутива CentOS 6:

1.3.6.1.2.1.1.1.0 = STRING: "Linux foo.example.lan 2.6.32-573.1.1.v6.i686 #1 SMP Fri Aug 21 14:37:07 MDT 2015 i686"

При рассмотрении этого описания несложно сделать вывод, что агент работает в 32-битной системе на основе ядра Linux версии 2.6.32.

Практически каждый идентификатор объекта начинается с последовательности значений "1.3.6.1" по причине, которая не должна вызывать вопросов. Современная сеть Интернет основывается на концепциях, разработанных в Министерстве обороны США (United States Department of Defense), причем в течение некоторого времени стек протоколов TCP/IP назывался "DOD Model". Так как данные значения присутствуют в каждом идентификаторе объекта, они не несут особой пользы в плане идентификации его назначения и могут просто игнорироваться.

После последовательности значений 1.3.6.1 располагаются значения, позволяющие описать дополнительные типы идентификаторов объектов. Если это значения 1.2, то, как и в примере выше, описание идентификатора объекта может быть найдено в стандартной базе управляющей информации IETF. Если же это значения 1.4, то база управляющей информации является "нестандартной" и вам придется получить ее спецификации от разработчика вашего аппаратного обеспечения. Несмотря на то, что базы управляющей информации данного типа называются "нестандартными", их спецификации в большинстве случаев общедоступны.

Какие типы идентификаторов объектов существуют и как они используются?

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

1.3.6.1.2.1.1.1.0 = STRING: "Linux foo.example.lan 2.6.32-573.1.1.v6.i686 #1 SMP Fri Aug 21 14:37:07 MDT 2015 i686"

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

• Integer/Integer32: знаковое 32-битное целочисленное значение - такие значения часто используются для передачи рабочих параметров устройств, таких, как объем доступной или свободной оперативной памяти.
• Uinteger32: беззнаковое целочисленное значение (используется достаточно редко).
• Octet String: короткая (длиной до 255 символов) последовательность бинарных или текстовых данных.
• IP Address: обычный IP-адрес.
• Counter32: 32-битный счетчик с возрастающим значением и возвратом к значению 0 при заполнении 32 бит за вычетом 1 (то есть, после достижения значения 4294967295). Это важно знать, ведь при использовании протокола Ethernet со скоростью в 1 Гб/с за пять минут, через которые системы сетевого управления обычно опрашивают агенты, может быть передано гораздо большее количество байт.
• Counter64: счетчик с максимальным значением в 64 бита за вычетом 1, позволяющий осуществлять подсчет количества переданных по протоколам Ethernet с большими скоростями байт данных, а также других больших целочисленных значений.
• Object Identifier: другой идентификатор объекта, выступающий в роли аналога оператора GOTO из большинства языков программирования и позволяющий сообщить системе сетевого управления о том, что данные относятся к другой базе управляющей информации.
• Bit String: строковый тип, аналогичный рассмотренному выше и предназначенный для передачи строковой информации.
• Gauge32: счетчик, позволяющий увеличивать и уменьшать значение без превышения максимального значения.
• TimeTicks: представляет беззнаковое целочисленное значение, соответствующее разнице во времени (обычно используется для учета времени работы систем).

Что такое база управляющей информации и удобнее ли использовать имена вместо наборов цифр?

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

После установки баз управляющей информации предыдущее сложное сообщение:

1.3.6.1.2.1.1.1.0 = STRING: "Linux foo.example.lan 2.6.32-573.1.1.v6.i686 #1 SMP Fri Aug 21 14:37:07 MDT 2015 i686"

станет немного проще:

SNMPv2-MIB::sysDescr.0 = STRING: Linux foo.example.lan 2.6.32-573.1.1.v6.i686 #1 SMP Fri Aug 21 14:37:07 MDT 2015 i686

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

Каким образом данные особенности учитываются в базах управляющей информации? Эти базы являются читаемыми человеком текстовыми файлами, обычно расположенными в директории /usr/share/snmp/mibs. В случае сообщения типа sysDescr клиент SNMP ищет соответствующее значение в базе управляющей информации SNMP v2 и получает информацию о типе сообщения, его назначении и возможности его отправки (из файла SNMPv2-MIB.txt из комплекта поставки NET-SNMP):

sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software." ::= { system 1 }

Как SNMP v1/v2c работает в Linux?

Начать работу с протоколами SNMP v1 и v2c в Linux достаточно просто. Информация будет передаваться в незашифрованном виде, включая "общие строки", которые выполняют функции своеобразных паролей. Вам придется воспользоваться вашим менеджером пакетов программного обеспечения для установки пакета net-snmp. После этого вам придется отредактировать файл конфигурации /etc/snmp/snmpd.conf, удалив все его содержимое и добавив в него следующие строки:

rocommunity public
syslocation Somewhere (In the World)
syscontact Overworked Admin <admin@paymemore.com>

После этого нужно запустить службу snmpd и выполнить следующую команду на той же системе, в результате чего вы должны увидеть сообщение, аналогичное сообщению из примера, используемого в рамках данной статьи:

[user@foo mibs]$ snmpget -v2c -c public localhost SNMPv2-MIB::sysDescr.0 SNMPv2-MIB::sysDescr.0 = STRING: Linux foo.example.lan 2.6.32-573.1.1.v6.i686 #1 SMP Fri Aug 21 14:37:07 MDT 2015 i686

Если вы не знаете идентификатора объекта, который вам нужен, вы можете воспользоваться командой snmpwalk, которая осуществит обход всей базы управляющей информации и вывод значений со всеми известными идентификаторами. Данная команда обычно генерирует большой объем вывода, поэтому для удобства чтения вы можете воспользоваться фильтром head:

[user@foo mibs]$ snmpwalk -v2c -c public localhost | head SNMPv2-MIB::sysDescr.0 = STRING: Linux foo.example.lan 2.6.32-573.1.1.v6.i686 #1 SMP Fri Aug 21 14:37:07 MDT 2015 i686 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (154) 0:00:01.54 SNMPv2-MIB::sysContact.0 = STRING: Overworked Admin <overworked@admin.com> SNMPv2-MIB::sysName.0 = STRING: foo.example.lan SNMPv2-MIB::sysLocation.0 = STRING: Somewhere out there

В процессе работы утилиты snmpwalk будет снова выведено значение объекта sysDescr.0, после которого будет следовать значение другого объекта SysObjectID, которое является ссылкой на еще один объект с идентификатором NET-SNMP-MIB::netSnmpAgentOIDs.10. snmpwalk осуществит поиск объекта с данным идентификатором и выведет его тип и значение перед тем, как продолжить обход дерева SNMPv2-MIB.

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

Как SNMP v3 работает в Linux?

Протокол SNMP v3 является достаточно сложным по сравнению с протоколом SNMP v2 и требует нескольких дополнительных шагов для настройки программных компонентов. Если вас интересуют рабочие параметры вашего маршрутизатора с прошивкой на основе Linux, вам, скорее всего, должно хватить приведенного выше примера использования протокола SNMP v2, но практически в любом другом окружении использование SNMP v3 является необходимостью. Для настройки необходимых программных компонентов в первую очередь следует создать учетную запись пользователя SNMP v3 с локальным паролем, хранящимся в формате хэша SHA, использующую алгоритм шифрования AES. Эта комбинация алгоритмов является более безопасной, чем предлагаемая по умолчанию комбинация алгоритмов MD5 и DES, но все же далекой от идеала (и алгоритм MD5, и алгоритм DES могут быть взломаны без каких-либо сложностей):

[root@foo mibs] # service snmpd stop Stopping snmpd: [ OK ] [root@foo mibs] # net-snmp-create-v3-user -ro -A snmpv3authPass -a SHA -X <пароль> -x AES <имя пользователя> adding the following line to /var/lib/net-snmp/snmpd.conf: createUser user SHA "snmpv3authPass" AES userpass adding the following line to /etc/snmp/snmpd.conf: rouser user

Теперь нужно отредактировать файл конфигурации /etc/snmp/snpd.conf от лица пользователя root и закомментировать строку rocommunity, добавленную ранее:

#rocommunity public

Далее нужно перезапустить службу snmpd и воспользоваться утилитой snmpwalk с обязательной передачей ваших имени пользователя и пароля SNMP v3:

[user@foo mibs]$ snmpwalk -u <имя пользователя> -A snmpv3authPass -a SHA -X <пароль> -x AES -l authPriv 127.0.0.1 -v3 | head SNMPv2-MIB::sysDescr.0 = STRING: Linux clearos65.trelane.lan 2.6.32-573.1.1.v6.i686 #1 SMP Fri Aug 21 14:37:07 MDT 2015 i686 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (12756) 0:02:07.56 SNMPv2-MIB::sysContact.0 = STRING: Overworked Admin <overworked@admin.com> SNMPv2-MIB::sysName.0 = STRING: clearos65.trelane.lan SNMPv2-MIB::sysLocation.0 = STRING: Somewhere out there SNMPv2-MIB::sysORLastChange.0 = Timeticks: (42) 0:00:00.42 SNMPv2-MIB::sysORID.1 = OID: SNMP-MPD-MIB::snmpMPDMIBObjects.3.1.1 SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance

Несложно заметить, что в данном случае передается та же информация, но теперь используется аутентификация с помощью имени пользователя и пароля, кроме того, все данные шифруются с помощью 128-битной версии алгоритма AES. Если вы снова попытаетесь воспользоваться протоколом SNMP v2, вы получите сообщение об истечении периода ожидания:

[user@foo mibs]$snmpwalk -v2c -c public localhost
Timeout: No Response from localhost

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

Каково текущее положение SNMP ввиду отсутствия реализаций новых версий стандарта с 2004 года?

Несмотря на широкое распространение протокола SNMP, его важность и беспрецедентную гибкость, он постепенно теряет свою актуальность. Вариант протокола SNMPS, являющийся ничем иным, как протоколом SNMP, отправляющим дейтагараммы по зашифрованному TLS-соединению, был стандартизирован в 2010 году, но не был практически нигде реализован. Версия протокола SNMP v3 сложна в использовании и отладке на устройствах, работающих под управлением любых операционных систем, за исключением Linux. Компания Microsoft полностью отказалась от использования SNMP в Windows, заменив его сначала на WMI, а затем - на WinRM. Другие производители и продукты с интерфейсами для мониторинга рабочих параметров используют собственные пропиетарные API, работающие по протоколу HTTPS или, что еще хуже, по протоколу HTTP без шифрования и осуществляющие обмен данными в формате JSON (Javascript Object Notation) или XML. Этот отход от единого стандарта сделал процесс мониторинга больших сетей с различными устройствами более сложным и требующим больших временных затрат.

Реализация NET-SNMP для Linux находится в еще более незавидном положении. С 1 января 2015 года над ее кодом работали всего два разработчика (оба из компании VMware) и один менеджер проекта, внеся в код в общей сложности менее 30 изменений. Последний стабильный выпуск NET-SNMP был представлен общественности в 2014 году. В NET-SNMP нет поддержки стандарта SNMPS, причем у разработчиков нет планов по ее добавлению в проект в ближайшем будущем, что делает данный стандарт мертворожденным.

Возврат былой популярности

Очень неприятно наблюдать процесс разделения существующего стандарта на сотни различных пропиетарных реализаций. Это разделение приводит к потерям времени и денег и затрудняет работу системных администраторов. Стандарт SNMP, а также различные совместимые реализации стандартов все еще актуальны и используются в множестве повсеместно эксплуатируемых устройств. Широкое распространение и актуальность стандарта сходят на нет, так как набирающие популярность современные аналоги используют пропиетарные структуры данных в форматах JSON и XML вместо баз управляющей информации и объектов с идентификаторами. Реализация NET-SNMP и сам стандарт SNMP являются отличными вариантами спасения ситуации. Расширение баз управляющей информации IETF для поддержки современных сетевых устройств, таких, как сетевые системы хранения данных, сети хранения данных, программно-конфигурируемые сети, контейнеры, облака, конвергентные и гиперконвергентные системы является необходимым условием сохранения актуальности протокола SNMP.

---

---

---