Протокол SNMP. ЛР3 Управление сетью с помощью протокола SNMP Snmp порт по умолчанию

Большинство современных типов сетевого оборудования поддерживает протокол SNMP. Данный стандарт считается очень простым по структуре. Его внедрение осуществить в современных компаний несложно. Управление компьютерами посредством соответствующего протокола может быть осуществлено с применением широкого спектра программных решений. Какие основные возможности имеет SNMP? Каким образом задействуется соответствующий протокол на практике?

Что представляет собой протокол SNMP?

Для начала изучим основные сведения о рассматриваемой технологии. Что это — SNMP? Данная как Simple Network Management Protocol, и означает «Простой протокол сетевого управления». Данный стандарт относится к числу самых распространенных, что задействуются в целях управления различными девайсами в IP-сетях, функционирующих на базе архитектуры TCP/IP. Например, роутерами, коммутаторами, рабочими станциями, сетевыми принтерами.

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

Возможности SNMP

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

Рассмотрим теперь то, какие ключевые компоненты формируют инфраструктуру сетей, работающих на основе SMTP.

SNMP: основные компоненты

SNMP — протокол, который предполагает задействование нескольких сетевых компонентов. К основным можно отнести:

Управляемый объект — компьютер или приложение, на которое отправляет те или иные команды с использованием протокола, о котором идет речь, администратор сети;

База данных MIB;

Приложение-агент;

Программа-менеджер;

Система обеспечения сетевого взаимодействия.

Управляемый объект может не только получать команды от администратора, но и направлять их — в соответствии с заданными параметрами. Данные с объекта передаются на программу-менеджер, которая по устаноленным алгоритмам интерпретирует их. В свою очередь, на управляемом девайсе функционирует приложение-агент. Оно собирает информацию по соответствующему устройству и при необходимости транслирует ее в формате, адаптированном к специфике протокола SNMP.

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

Важнейший, возможно, ключевой элемент протокола SNMP — MIB, или база управляющих сведений. Ее предназначение — в описании структуры данных, обмен которыми осуществляется в процессе управления девайсами. Фактически, соответствующая база данных позволяет разместить информацию, что задействуется для управления устройством, непосредственно на нем, будь то модем, сервер или, к примеру, SNMP — это универсальный протокол, и во многом его функциональность возможно реализовать благодаря, прежде всего, возможностям базы данных MIB.

В девайсах, совместимых с данной технологией, содержатся как стандартные переменные, так и те, что характеризуют особенности отдельного устройства. Основные элементы данной базы — идентификаторы типа OID. Они позволяют устанавливать переменные, которые считываются или же определяются посредством протокола SMNP.

Приложение-агент, являющееся компонентом сетевой инфраструктуры SMNP, обычно получает запросы с использованием порта 161. В свою очередь, программа-менеджер может задействовать любые порты, доступные в сети. При этом уведомления данный тип ПО получает обычно на порт 162.

Рассмотрим основные инструменты, задействуемые администраторами, которые пользуются протоколом SNMP в работе, подробнее. В числе таковых — программа-менеджер.

Программа-менеджер в рамках протокола SNMP: основные возможности

Данный вид ПО позволяет благодаря возможностям рассматриваемого протокола осуществлять управление группами самых разных устройств в рамках сетевой инфраструктуры. Программа, о которой идет речь, может функционировать при условии предварительной инсталляции на девайсах, которые управляются посредством ее интерфейсов, специального приложения-агента, о котором мы сказали выше. Оно передает на сервер администратора необходимые данные с использованием протокола SNMP. В свою очередь, на стороне главного ПК функционирует рассматриваемая программа-менеджер, которая осуществляет обработку сведений, поступающих с управляемых девайсов.

Какое ПО применяется для управления сетью по протоколу SNMP?

Какие конкретно программы могут использоваться в качестве управляющих? В принципе, есть решения, адаптированные к внедрению в самых разных операционных системах протокола SNMP — Windows, Solaris. Если говорить о ПО для Windows, то в числе популярных, работающих в данной ОС и задействующих SNMP, — пакет, выпущенный Castle Rock Computing. В свою очередь, для Solaris разработано другое эффективное решение — Sun NetManager. Посредством обоих вариантов может быть выстроена эффективная базирующаяся на протоколе SNMP карта сети. Кроме того, они позволяют осуществлять прямую коммуникацию с MIB.

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

Еще одно популярное решение для управления сетевыми девайсами — Zabbix. SNMP — протокол, который данная программа также задействует. Соответствующее решение обладает большим количеством функций.

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

Особенности SNMP-сообщений

К основным сообщениям, обмен которыми может инициировать посредством протокола SNMP сервер администратора, относятся такие команды, как:

GetNextRequest;

GetBulkRequest;

InformRequest.

Сущность 1-й команды заключается в отправке запроса от программы-менеджера к приложению-агенту в целях получения того или иного значения по переменной — одной или по списку. В свою очередь, программа-менеджер получает ответ с определенными значениями.

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

Сущность 3-й команды заключается в отправке запроса от программы-менеджера к приложению-агенту определенных команд в целях обнаружения на девайсе всех доступных переменных, а также значений, которые установлены для них. В свою очередь, приложение-агент возвращает ответ, в котором содержится значение одной переменной, а также ссылка на следующую соотносительно с ее позицией в списке. Следующий запрос предполагает передачу данных, отражающих сведения по следующей переменной, а также ссылку на ту, что идет далее в очереди. В дальнейшем алгоритм оборота данных с использованием рассматриваемой SNMP-команды повторяется.

Специфика 4-й команды заключается в том, что по сути она является модернизированной версией сообщения GetNextRequest. Она предполагает, что приложение-агент передаст программе-менеджеру ответ, содержащий данные по нескольким переменным одновременно, начиная с той, что представлена в изначальном запросе.

Сущность 5-й команды — в осуществлении процедуры возврата связанной переменной, а также значений от приложения-агента к программе-менеджеру при использовании 4 типов сообщений, рассмотренных выше. При этом посредством соответствующей команды между девайсами осуществляется обмен сообщениями об ошибке.

Специфика 6-й команды — в осуществлении передачи сообщений от приложения-агента без предварительного запроса со стороны программы-менеджера. В структуре данного сообщения присутствует текущее значение по переменной. Отметим, что получатель команды в данном случае определяется посредством особых конфигураций в рамках базы MIB.

Сущность 7-й команды заключается в том, что она, фактически, соответствует уведомлению об отправке сообщения от программы-менеджера к приложению-агенту и наоборот. Ее применение обусловлено тем, что в сетевой инфраструктуре те или иные сообщения в ряде случаев могут доставляться некорректно. Команда InformRequest, по сути, подтверждает факт успешной передачи команды от одного девайса к другому.

Корректная настройка SNMP во многих случаях требует от администратора повышенного внимания проверке функциональности базы MIB. Рассмотрим то, в чем заключаются ее особенности.

MIB: особенности функционирования базы

Ключевая процедура в рамках функционирования базы MIB — адресация переменных. Осуществляется она с учетом структуры рассматриваемого компонента протокола SNMP. Выглядит база MIB как древообразная схема, состоящая из нескольких элементов, к каждому из которых прикреплен особый идентификатор.

Имя переменной в рамках базы MIB отражает адрес до нее, начиная от корневого каталога. В структуре переменной могут содержаться самые разные сведения, например, о времени работы девайса. В древообразной структуре MIB могут присутствовать как стандартные ветви, которые поддерживаются большинством девайсов, или же те, что добавлены производителем устройства либо организацией, в которой внедряется инфраструктура компьютерной сети. Главное в данном случае — правильно разместить соответствующие наборы переменных.

Так, если они внедряются в структуру MIB временно, то их имеет смысл разместить в разделе experimental. Непосредственно перед утверждением следует присвоить набору переменных отдельный номер. Для этого используется раздел private-enterprises. Это позволит инженерам или администраторам сети, в компетенции которых — SNMP-мониторинг и решение других задач по обеспечению функционирования инфраструктуры, открыть новую ветвь в структуре MIB для того, чтобы размещать переменные только от своей компании.

История появления SMNP

Интересно будет изучить сведения об истории разработки SNMP. Основная программная среда, в которой сейчас задействуется протокол SNMP — Windows. Однако, инициирована была его разработка еще в 1988 году - задолго до того, как операционная система от Microsoft, представленная в привычных интерфейсах, начала завоевывать рынки. Фактически, изначально SNMP разрабатывался для UNIX — семейства операционных систем, предназначенных для решения широкого круга задач по обеспечению функциональности различных компьютерных сетей. Хотя, безусловно, к тому моменту многие эксперты видели потенциал Windows, и не исключено, что разработка универсального сетевого протокола была во многом предопределена фактом потенциального роста популярности новой операционной системы.

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

Так или иначе, крупнейшие производители сетевых девайсов в 1988 году решили, что им необходимо разработать универсальный набор средств, предназначенных для управления устройствами. К тому моменту фирмы выпускали собственные решения для осуществления мониторинга, а также конфигурирования девайсов. Нужна была унификация.

Разработка SNMP: основные инструкции

В августе 1988 года предприятия, выпускающие сетевое оборудование, пришли к консенсусу. В процессе разработки нового протокола были применены некоторые уже действовавшие концепции. Специалисты, которые проводили совместную работу, выявили 3 ключевых документа: RFC 1065, 1066, а также 1067. Впоследствии они были дополнены, и появились новые — RFC 1155, 1156, а также 1157. Данные источники были переработаны, и в 1991 году на их основе была выпущена первая версия протокола SNMP.

Так, документ RFC 1155 содержал в себе инструкции, определяющие:

То, в какой структуре должна отражаться управляющая информация;

То, каковы основные принципы применения синтаксиса при определении имен для переменных.

Документ RFC 1155 был дополнен источником RFC 1212 в части, опять же, синтаксиса переменных. На момент утверждения протокола SMNP был разработан ряд новых документов, таких как RFC 1213. В нем отражался список ключевых переменных, посредством которых должна была осуществляться конфигурация сетевой инфраструктуры.

Источник RFC 1157 содержал параметры, необходимые для:

Определения команд, посредством которых сервер и управляемый объект могли взаимодействовать между собой;

Осуществления обмена trap-сообщениями.

Как только был опубликован и введен протокол SNMP, адаптер, сервер — в принципе, любой девайс, который входил бы в инфраструктуру сети, мог становиться объектом управления, осуществляемого в рамках стандартных процедур. Введение SNMP стало сильнейшим фактором роста мирового рынка сетевого оборудования. Также благодаря стандартизации стало возможным внедрение в самых широких масштабах новых интерфейсов, таких как, например, Ethernet, FDDI.

Резюме

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

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

Запросы одного или нескольких параметров MIB;

Последовательное прочтение различных значений по тем или иным параметрам, например, табличным;

Установка конкретных значений для одной или же нескольких переменных MIB;

Возврат девайсом ответа на тот или иной запрос другого устройства;

Отправка уведомительных сообщений о тех или иных сетевых процессах.

Алгоритмы MIB могут быть как общие для всех девайсов, так и те, что прописываются производителями для конкретных типов сетевого оборудования.

Что это — SNMP с точки зрения значения для современного IT-рынка? Данная технология, очевидно, в числе важнейших, и во многих случаях не имеющая альтернативы. И это несмотря на ее простоту, которая, однако, стала результатом многолетних разработок и согласований сетевых стандартов при участии ведущих производителей оборудования.

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

Управление компьютерами сети может осуществляться с главного сервера. Для этого может быть задействована специальная программа, например, Zabbix. SNMP — протокол, поддерживаемый программами, способными работать в разных операционных системах. Изначально SNMP разрабатывался для UNIX, но были созданы виды ПО, которые позволили его применять в ОС Windows, Sun Solaris.

Таким образом, что это — SNMP? Международный стандарт, позволяющий, прежде всего, интегрировать решения от разных производителей. Изначально алгоритмы управления ими бренды задавали свои собственные. Но благодаря разработке SNMP у них появилась возможность задействовать унифицированные команды, что стимулировало спрос на выпускаемые сетевые девайсы, стало эффективным драйвером роста рынка соответствующего типа оборудования.

Приветствую тебя, гость и постоянный читатель. Пришлось в последнее время внедряться в сетевой мониторинг. Очень актуальная тема для мониторинга - SNMP (Simple Network Management Protocol) . Часто приходилось использовать SNMP , но руки не доходили до его описания. Сегодня хочу изложить свое понимание данной технологии.

Введение в протокол SNMP

SNMP есть Simple Network Management Protocol , он же Простой Протокол Сетевого Управления . Протокол создан в 1988 г. с целью управления большим количеством сетевых устройств. С того момента протокол набрал соответствующую популярность и стал стандартом. С момента разработки протокол SNMP был 3 раза переработан с версии SNMPv1 , SNMPv2 и SNMPv3 . На самом деле, версий было больше, например v2 была пересмотрена 2 раза (или даже более). Так же стоит отметить, что кроме SNMP были и другие попытки создать коммерческие и не коммерческие протоколы управления (CORBA, TMN ...) не увенчавшиеся успехом.

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

Архитектура протокола SNMP

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

1. SNMP менеджер - ПО, устанавливаемое на ПК администратора (системы мониторинга)
2. SNMP агент - ПО, запущенное на сетевом узле, за которым осуществляется мониторинг.
3. SNMP MIB - MIB это Management information base . Этот компонент системы обеспечивает структурированость данных, которыми обмениваются агенты и менеджеры. По сути - это некая база данных в виде текстовых фалов.

Давайте попытаемся рассмотреть обозначенные компоненты.

SNMP менеджер и SNMP агент

Для понимания назначения компонентов, можно сказать, что SNMP менеджер является прослойкой (интерфейсом) между оператором\администратором и сетевым узлом с запущенным SNMP агентом . Так же, можно сказать, что SNMP агент - это интерфейс между SNMP менеджером и железным оборудованием на сетевом узле. Если провести аналогию протокола SNMP с клиент-серверной архитектурой (например, веб-сервера) то веб-сервер работает как служба на некотором порту, а пользователь силами браузера обращается к веб-серверу как клиент. Это четко обозначенная архитектура с выраженным клиентом и сервером. В случае SNMP роли клиента и сервера несколько размыты. Например, SNMP агент является своего рода службой, работающей на устройстве (за которым производится мониторинг) и обрабатывает запросы на определенном порту udp/161 , то есть фактически является сервером. А SNMP менеджер является своего рода клиентом, который обращается к серверу SNMP агенту . В SNMP существует т.н. Trap . Это запрос от агента к менеджеру. Точнее даже не запрос, а уведомление. При отправке данного уведомления, агент и менеджер "меняются ролями". То есть, менеджер в таком случае должен являться сервером, работающем на порту udp/162, а агент является клиентом. В последних версиях SNMP trap может именоваться как извещение (notification ).

Структура PDU

Рассмотрение структуры PDU не обязательно, но это поможет более глубоко понять логику работы SNMP . Все PDU (кроме Trap) состоят из определенного набора полей, в которые записывается необходимая информация:

Что данные поля обозначают:

При этом, содержимое Trap PDU содержит некоторые дополнительные поля (вместо заголовка запроса):

• Фирма – характеризующее производителя хоста
• Тип trap уведомления, может быть следующим:
  • 0 (Coldstart) и 1 (Warmstart) – объект возвращен в начальное состояние (между ними имеется некая разница, но какая?..),
  • 2 (Linkdown) – интерфейс опущен, при этом, поле переменной содержит интерфейс о котором идет речь,
  • 3 (Linkup) – интерфейс поднялся, при этом, поле переменной содержит интерфейс о котором идет речь,
  • 4 (Authenticationfailure) – менеджер прислал мессадж с неверной строкой community,
  • 5 (EGPneighborloss) – затрудняюсь что либо сказать),
  • 6 (Entrprisespecific) – данный тип Trap сообщает о том, что в следующем поле содержится специализированный для данного вендора тип трапа.
• Специализированный тип Trap – описан выше
• Метка времени – содержит метку времени с момента события (непонятно, относительно чего эта метка…).

В новых версиях SNMP содержимое Trap PDU может незначительно меняться, но в целом, смысл тот же...

Логика работы протокола SNMP

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

Логика работы SNMP при обмене PDU-единицами

(взято частично отсюда http://logic-bratsk.ru/brlug/snmp_my/):

При получении PDU GetRequest, SNMP агент действует по следующему алгоритму:

1. Если имя переменной не совпадает в точности с именем одной из переменной , доступных для операции get в нашей MIB, передаем отправителю запроса аналогичное PDU GetResponse , указывая в поле кода ошибки значение noSuchName (2-нет такого имени), а в поле error-index - индекс имени вышеупомянутого объекта в полученном сообщении (=1, в SNMPv1 - ограничение данной реализации SNMP).
2. Если размер PDU GetResponse , превышает локальное ограничение (Реализация SNMP не обязана принимать сообщения, размер которых превышает определенное значение. Однако по возможности желательна поддержка дейтаграмм больших размеров (RFC1157 SNMP).) , передаем отправителю аналогичное PDU GetResponse , указав в поле errorstatus значение T ooBig , а в поле error-index - 0 . Это обычно происходит, если запрошено больше 1 переменной или длина PDU или общая длина пакета больше стандартных пределов.
3. Если для любой переменной, содержащейся в поле связанные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, SNMP агент передает отправителю аналогичное PDU GetResponse, указав в поле error-status значение GenErr, а в поле error-index - индекс имени вышеупомянутого объекта в полученном сообщении.
4. Если все нормально, передаем SNMP менеджеру, отправившему полученное сообщение, ответ - GetResponse, в котором для каждой переменной в поле связанные переменные подставлены запрошенные значения переменных. В поле error-status помещается значение NoError, а в поле error-index - 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.

При получении PDU GetNextRequest, SNMP агент действует по следующему алгоритму:

1. Если после переменной, указанной в запросе, нет следующей переменной, то передаем отправителю запроса менеджеру PDU GetResponse (с содержимым аналогичным исходному запросу), указывая в поле кода ошибки значение noSuchName (нет такого имени), а в поле error-index - индекс имени вышеупомянутого объекта в полученном сообщении (=1 для SNMPv1), значение переменной = NULL (кажется).
2. Если размер PDU ответа (GetResponse), созданного в соответствии с приведенным ниже описанием, GetResponse , указав в поле errorstatus значение tooBig , а в поле error-index - 0.
3. Если для любой переменной в поле связанные переменные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, принимающий объект передает менеджеру PDU
4. Если все нормально, передаем SNMP менеджеру, отправившему PDU, такое сообщение GetResponse , в котором для каждой переменной в поле связанные переменные содержится имя и значение переменной, иерархически следующей за запрошенной переменной в базе MIB. В поле error-status помещается значение noError , а в поле error-index - 0 . Значение поля request-id в ответном PDU GetResponse совпадает с идентификатором в принятом сообщении.

При получении PDU SetRequest, SNMP агент действует по следующему алгоритму:

1. Если для любой переменной, содержащейся в поле связанные переменные, запись (операция set) не поддерживается в имеющих отношение к делу представлениях MIB, SNMP агент объект передает отправителю запроса аналогичное PDU GetResponse , указывая в поле кода ошибки значение noSuchName (нет такого имени), а в поле error-index - индекс имени вышеупомянутого объекта в полученном сообщении.
2. Если для любой переменной в запросе, запрашиваемые к изменению значения переменных не соответствуют стандартам (SMI, ASN.1 – об этом ниже), то SNMP агент передает SNMP менеджеру аналогичное PDU GetResponse, указывая в поле кода ошибки значение badValue (нет такого имени), а в поле error-index - индекс имени вышеупомянутого объекта в полученном сообщении.
3. Если размер PDU ответа (GetResponse), созданного в соответствии с приведенным ниже описанием, превышает локальное ограничение , принимающий объект передает отправителю аналогичное PDU GetResponse , указав в поле errorstatus значение tooBig , а в поле error-index - 0.
4. Если для любой переменной в поле связанные переменные, значение переменной не может быть установлено по причинам, которые отличаются от перечисленных выше, SNMP агент передает менеджеру PDU с исходным содержимым GetResponse, указав в поле error-status значение genErr, а в поле error-index - индекс имени вышеупомянутого объекта в полученном сообщении. (аналогично вышесказанному)
5. Если все нормально, агент передает SNMP менеджеру, отправившему PDU, такое сообщение GetResponse , в котором для каждой переменной в поле связанные переменные подставлены установленные значения переменных. В поле error-status помещается значение NoError, а в поле error-index - 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.

Логика работы SNMP в картинках

взято отсюда (http://www.manageengine.com/network-monitoring/what-is-snmp.html)

Обмен PDU GET⁄ GET NEXT⁄ GET BULK⁄ SET

Обмен PDU Trap или notification

SNMP MIB

Давайте попробуем понять MIB . Это совсем не люди в черном) Как я уже сказал, это Management information base , то есть база набор управляющей информации. Каждый сетевой узел, имеющий на своем борту SNMP агента (читай – поддерживающий протокол SNMP) предоставляет свой набор данных, тот, который в него «вложили» программисты\разработчики при проектировании железки\программы. То есть в каждом сетевом устройстве с поддержкой SNMP имеется своя база MIB со строго обозначенным набором переменных. Каждая база MIB имеет древовидную структуру, каждый объект в которой характеризуется уникальным идентификатором объекта (Object Identifier, OID) .

Каждая ветка MIB-иерархии оканчивается некоторой переменной (так же имеющей свой OID), содержащей в себе определенное значение, которое записывается в переменную SNMP агентом, работающем на хосте. Данное значение неким образом характеризует данный хост (например, содержит информацию об аптайме, загрузке сетевого интерфейса и мн.др. параметры).

Имеется некая единая общая структура дерева MIB , а так же, имеются единые стандарты и принципы дальнейшего формирования данного дерева, его переменных, др. параметров, за эти правила отвечает некий разработанный стандарт под названием Структура Информации Управления (SMI , S tructure of M anagement I nformation ). Так же, имеется некий стандарт, называемый абстрактный синтаксис нотаций - ASN.1. Который тоже участвует в описании протокола SNMP и базы MIB . А еще имеется базовые правила кодирования BER (B asic E ncoding R ules), определяющие кодирование сущностей, применяемых в SNMP.

Кроме того, существует всемирное дерево регистрации стандартов IS O , содержащее базовую структура дерева MIB (точнее этих структур существует несколько, они формировались вместе с совершенствованием версий SNMP). Составное числовое имя объекта SNMP MIB соответствует полному имени этого объекта в дереве регистрации объектов стандартизации ISO . За данную древовидную структуру отвечает и контролирует организация IANA (и некоторые другие).

Давайте рассмотрим типичное дерево MIB на рисунке:

Дерево объектов MIB подобно . Тут аналогично имеются символьные имена (аналогично NS имени) и называемые ASN.1 нотацией , и соответствующие им числовые значения (аналогично IP адресам), называемые dot нотацией . Каждый объект в MIB состоит из нескольких чисел, разделенных точками. Числам соответствуют текстовые наименования. При этом, в отличии от DNS - нет какого-то единого централизованного сервера, отвечающего за разолвинг имен. Все разрешения имен из символов в числа происходят силами SNMP менеджера (в зависимости от того, какие сопоставления MIB загружены в менеджер). Весь обмен между узлами SNMP происходит только в числовом виде. В символьном виде, наименования используются только для отображения на экране или в документации.

Часто OID характеризующий определенный объект в дереве MIB сравнивают со структурой телефонных номеров, т.к. они (номера) так же иерархичны и отдельные части номера назначаются различными организациями. Например, международные телефонные номера состоят из кода страны (назначаемого международной организацией) и телефонного номера в том виде, в котором он определен локально в стране. При этом, телефонный номер в стране делится на код области\края\региона, номер АТС и далее номер абонента, привязанного к АТС. Аналогично - в MIB OID верхнего уровня назначаются международной организацией (ISO IEC ???), ветки OID нижнего уровня назначаются организациями, отвечающими за эти ветки.

Итак, структура OID в дереве MIB :

В вершине дерева – корень (точка), от которого ответвляются ветви. Во многих схемах приведены некоторые ветви верхнего уровня (например itu-t, iso\itu-t и другие ниже), но информации о их назначении я не нашел… Посему, нас интересует вертка iso (0), которая хранит в себе следующие значения до internet (1) : iso.org.dod.internet , что соответствует числовому ID .1.3.6.1 .

Данный раздел (iso.org.dod.internet ) разветвляется на подразделы, которые в большинстве своем контролируются IANA и состоят (согласно RFC1155) из:

• directory OID=1.3.6.1.1 (iso.org.dod.internet. directory ) – зарезервировано для использования в будущем
• mgmt OID=1.3.6.1.2 (iso.org.dod.internet. mgmt )- в этой ветке находится стандартные ответвления объектов.
• experimental OID=1.3.6.1.3 (iso.org.dod.internet. experimental )- это ветка для экспериментов разработчиков. (не отображено на схеме )
• private OID=1.3.6.1.4 (iso.org.dod.internet. private )– раздел предназначен для использования производителями оборудования.

Далее, необходимо рассмотреть отдельным пунктом ветку 1.3.6.1.2 (iso.org.dod.internet. mgmt ), состоящую из подветки mib-2 (1) , а так же reserved(0) , pib(2) , http(9) и некоторых других. Стоит отметить, что в зависимости от версии протокола (SNMPv1 vs SNMPv2) на месте данной ветки могут быть «прилинкованы» разные поддеревья в целом имеющие примерно одинаковую структуру и одинаковые идентификаторы, но в более новой версии протокола – поддерево более расширено. (наверно, в этом и состоит несовместимость версий протокола…)

Итак iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) : данная ветка является базовой для большинства сетевых устройств и содержится практически в любом устройстве. Ветка поделена на базовые группы (которых на текущий момент более 170), характерные для любого сетевого оборудования. Давайте рассмотрим наиболее применяемые:

1. iso.org.dod.internet.mgmt.mib-2.system (1.3.6.1.2.1.1) - ветка содержит в себе несколько объектов, характеризующих хост (аптайм, версия ОС и др.), описана в RFC1213.
2. iso.org.dod.internet.mgmt.mib-2.interface (1.3.6.1.2.1.2) - содержит объекты, описывающие сетевую подсистему хоста (количество интерфейсов, размер MTU, скорость передачи, физические адреса и т.п.), описана в RFC2863.
3. iso.org.dod.internet.mgmt.mib-2.ip (1.3.6.1.2.1.4) – содержит набор объектов, описывающих данные о проходящих IP пакетах (количество запросов, ответов, отброшенных пакетов и мн.др). Описана в RFC1213.
4. iso.org.dod.internet.mgmt.mib-2.tcp (1.3.6.1.2.1.6) и iso.org.dod.internet.mgmt.mib-2.udp (1.3.6.1.2.1.7) - содержат объекты, хранящие в себе информацию, касающуюся соответствующего транспортного протокола. Описана в RFC1213.
5. ... И мн. др., которые в принципе имеют довольно наглядное наименование и которые далее «раскрываются» на большее множество объектов.

Отдельного абзаца так же достоин подраздел iso.org.dod.internet.private (1.3.6.1.4) , содержащий в себе поддерево enterprise (1) . Данная ветвь контролируется IANA и содержит в себе более 40000 поддеревьев (ознакомьтесь с актуальным списком http://www.iana.org/assignments/enterprise-numbers). В данной ветке регистрируют свои поддеревья – производители оборудования. Вот пример ответвления:

Ниже структура аналогичная всем остальным разделам – древовидна. В каждом поддереве соответствующий производитель оборудования в праве сам регистрировать свои ветвления и переменные.

Так же, важным моментом, является то, что любая ветвь базы MIB оканчивается переменной , в которую записывается некоторое значение. При этом, в MIB существует несколько типов переменных. Во-первых, они делятся на переменные «только для чтения » и доступные для изменения , которые не позволяют выполнять запрос SetRequest и позволяют выполнять, соответственно. Во-вторых, имеются строковые переменные, табличные и мн.др., значения которых так же идентифицируются по OID. В целом, если нет желания к программированию для SNMP, то этим пониманием и можно ограничиться.

Безопасность протокола SNMP (или версии протокола SNMP)

Безопасность протокола SNMP - это самый изменяемый раздел спецификации протокола со времени его создания. С каждой версией SNMP, производились попытки усилить безопасность. Первая версия протокола SNMPv1 была самой простой и небезопасной. Сообщения протокола могли быть подвержены возможности модификации, подмене или прослушиванию. Безопасность протокола базировалась на модели безопасности на основе сообществ (т.н. Community-based Security Model ), что подразумевало аутентификацию на основе единой текстовой строки - своеобразного пароля (т.н. community-sting ), которая передавалась в теле сообщения в открытом виде. Хотя, данная версия протокола самая незащищенная, она довольно часто применяется в современных сетях, т.к. является самой простой.

В одной из вторых версий SNMP (SNMPv2p) была попытка реализовать аутентификацию на основе сторон (т.н.Party-based Security Model ). Технология кроме аутентификации, так же поддерживала возможность шифрования трафика. Данная технология не прижилась, как "сложная и запутанная") и в данный момент не используется. После чего SNMP второй версии вернулась к Community-based Security и стала именоваться SNMPv2c и применяется по сей день. SNMPv2 была переписана чуть более чем полностью, в результате чего существенно повышено быстродействие протокола, безопасность.

Третья версия протокола (SNMPv3 ) была более удачно доработана и поддерживает как аутентификацию на основе имени пользователя (т.н. User-based Security Model ), так и шифрование трафика . Хотя их можно и не использовать.

Версии протокола между собой не совместимы . Несовместимость заключается в разнице пакетов PDU , в наличии дополнительных команд в более новых версиях протокола (возможно, в других…). В RFC 2576 имеется некоторая информация, позволяющая организовать возможность совместного использования SNMPv1 и v2 . Для этого есть 2 пути: 1. Использование прокси-агентов (агент преобразует PDU SNMPv2 в PDU SNMPv1 ), 2. Использование менеджера с поддержкой 2х версий (менеджер для каждого хоста должен помнить версию агента).

Давайте рассмотрим работу протокола SNMPv2c (и SNMPv1 ) с точки зрения безопасности. При рассмотрении структуры пакета PDU было видно, что каждая единица PDU содержит community строку. При этом, SNMP агент содержит список (часто данный список состоит из одного значения) разрешенных строк и описание того, что каждая из строк может делать (фактически – набор прав). В большинстве случаев – это права read/write. При активации функций SNMP на каком-либо хосте, стандартные строки community – это public и private для возможности чтения и для возможности чтения-записи соответственно. Это строки очень желательно менять на свои. Часто, при конфигурировании SNMP о, в котором для каждой переменной в поле связанные переменные подставлены установленные значения переменных. В поле error-status помещается значение NoError, а в поле error-index - 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.пределяют различные community строки для чтения переменных и для записи .

Принципы настройки протокола SNMP

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

• Порт отправки
• Принимать ли trap
• community для чтения
• community для записи
• период опроса
• OID’ы

В большинстве реализаций менеджеров SNMP (в данном контексте, наверно, лучше сказать – систем управления сетью Network Management System ) предоставлены некие возможности механизма автоматического обнаружения SNMP агентов. В большинстве случаев это сводится к выполнению по расписанию некоторого скрипта, запускаемого в определенный промежуток времени и опрашивающего заданный диапазон IP адресов.

SNMP в Linux

• 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

С Уважением, Mc.Sim!

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

Используемые порты: 161/UDP,162/UDP

SNMP-trap (ловушки SNMP) Traps - это аварийные сообщения, сообщающие о событиях, происходящих в коммутаторе. События могут быть такими серьезными, как перезапуск (кто-нибудь случайно выключил коммутатор) или менее, как например, изменение статуса порта. Коммутатор создает сообщения «traps» и отправляет их к «trap» получателю (или сетевому менеджеру). Обычные «traps» содержат сообщение об ошибке аутентификации Authentication Failure , изменении топологии сети Topology Change и широковещательном шторме Broadcast\Multicast Storm.

SNMP безопасность

К сожалению , наиболее часто используемая версия 1 протокола SNMP имеет довольно слабую схему аутентификации, основанную на использовании “строки сообщества”. Это связано с тем, что фиксированный пароль передается по сети в открытом виде. По возможности старайтесь использовать 2-ю версию протокола SNMP , которая поддерживает схему проверки подлинности выборки на основе алгоритма MD5 и позволяет ограничить доступ к различной управляющей информации.

Протокол SNMP версии 1 не подходит для использования в общедоступной сети Интернет по следующим причинам:

Он использует незашифрованные строки проверки подлинности.

В большинстве реализаций SNMP такие строки отправляются неоднократно как часть периодических опросов.

Он плохо защищен от спуфинга и является протоколом транзакций на основе датаграмм.

Структура MIB. SMI. OID

MIB (Management Information Base) - база данных информации управления, используемая в процессе управления сетью в качестве модели управляемого объекта в архитектуре агент-менеджер. В частности используется протоколом SNMP .

MIB файл содержит информацию о различных объектах удаленного устройства. MIB определяет текстовое имя управляемого объекта и объясняет его значение.

В агенте может быть реализовано много MIB, но во всех агентах реализована конкретная MIB, которая называется MIB-II (RFC 1213). Этот стандарт определяет переменные для таких параметров, как статистика интерфейса (скорость интерфейса, MTU, количество отправленных октетов1, количество принятых октетов и т.д.), а также различных параметров, относящихся к самой системе (местоположение системы, контактные сведения и т.д.) Основная цель MIB-II – предоставить общую управляющую информацию TCP/IP.

SMI (The Structure of Management Information). Струк­ту­ра ин­фор­ма­ции для управ­ле­ния точ­но оп­ре­де­ля­ет, как управ­ляе­мым объ­ек­там при­сваи­ва­ют­ся име­на, и ука­зы­ва­ет свя­зан­ные с ни­ми ти­пы дан­ных.

OID (Object Identifier) уникальный иден­ти­фи­ка­тор объ­ек­та.

Управ­ляе­мые объ­ек­ты (OID) ор­га­ни­зо­ва­ны в дре­во­вид­ную ие­рар­хию. Со­сре­до­то­чим­ся на суб­де­ре­ве so(1).org(3).dod(6).in­ternet(1), ко­то­рое в фор­ме OID пред­став­ля­ет­ся как 1.3.6.1 или iso.org.dod.internet. У ка­ж­до­го управ­ляе­мо­го объ­ек­та есть циф­ро­вой иден­ти­фи­ка­тор OID и со­от­вет­ст­вую­щее тек­сто­вое имя. Обо­зна­че­ние в ви­де раз­де­лен­ных точ­ка­ми чи­сел ис­поль­зу­ет­ся для пред­став­ле­ния управ­ляе­мо­го объ­ек­та внут­ри аген­та; тек­сто­вое имя, как до­мен­ное имя, со­от­вет­ст­вую­щее IP- ад­ре­су, из­бав­ля­ет лю­дей от не­об­хо­ди­мо­сти за­по­ми­нать длин­ные, слож­ные стро­ки чи­сел.

Ветвь directory в на­стоя­щее вре­мя не ис­поль­зу­ет­ся.

Ветвь management (или mgmt) , оп­ре­де­ля­ет стан­дарт­ный на­бор управ­ляе­мых объ­ек­тов Ин­тер­не­та.

Ветвь experimental за­ре­зер­ви­ро­ва­на для це­лей тес­ти­ро­ва­ния и ис­сле­до­ва­ния.

Объ­ек­ты вет­ви private оп­ре­де­ля­ют­ся в од­но­сто­рон­нем по­ряд­ке, то есть за оп­ре­де­ле­ние объ­ек­тов этой вет­ви лю­ди и ор­га­ни­за­ции от­ве­ча­ют са­ми.

В на­стоя­щее вре­мя в суб­де­ре­ве private(4) есть од­на ветвь enterprises(1). Она ис­поль­зу­ет­ся для то­го, что­бы пре­дос­та­вить про­из­во­ди­те­лям ап­па­рат­но­го и про­грамм­ но­го обес­пе­че­ния воз­мож­ность оп­ре­де­лить свои соб­ст­вен­ные ча­стные объ­ек­ты для лю­бо­го ти­па ап­па­рат­ных или про­грамм­ных средств, ко­то­ры­ми они хо­тят управ­лять при по­мо­щи SNMP. SMI Network Management Private Enterprise Codes : D-Link (171), Cisco(9), Microsoft (311).

MIB-II

Основная цель MIB-II – предоставить общую управляющую информацию TCP/IP. MIB-II – очень важ­ная груп­па управ­ле­ния, по­то­му что ка­ж­дое уст­рой­ст­во, под­дер­жи­ваю­щее SNMP, долж­но так­же под­дер­жи­вать MIB-II .

MIB-II оп­ре­де­ле­на как iso.org.dod.internet.mgmt.1, или 1.3.6.1.2.1.

На самом деле интересны только две ветви: 1.3.6.1.2.1 = Стандартные MIBы 1.3.6.1.4.1 = MIBы специфичные для производителей

Пакет Net-SNMP

Инсталляция Net-SNMP Ubuntu

Для загрузки и подключения стандартных MIB к SNMP клиенту выполним две команды

Инсталляция Net-SNMP CentOS

Ути­ли­та Net-SNMP snmpusm при­ме­ня­ет­ся для управ­ле­ния поль­зо­ва­те­ля­ми SNMPv3.Три ба­зо­вых опе­ра­ции SNMP – это snmpget , snmpset и snmpwalk . Их на­зна­че­ние по­нят­но из на­зва­ния: snmpget счи­ты­ва­ет зна­че­ние па­ра­мет­ра с управ­ляе­мо­го уст­рой­ст­ва, snmpset ус­та­нав­ли­ва­ет зна­че­ние па­ра­мет­ра на уст­рой­ст­ве, а snmpwalk счи­ты­ва­ет с уст­рой­ст­ва часть де­ре­ва MIB.

PHP and SNMP

Чтобы при помощи языка PHP (SNMP Функции) взаимодействовать с протоколом SNMP, должны быть установлены дополнительный пакеты:

Цель работы: изучение способов мониторинга и управления сетью на основе протокола SNMP.

Применяемое оборудование:

2.Один коммутатор третьего уровня D-LinkDES-3810-28.

3. Два управляемых коммутатора второго уровня D-LinkDES-3200-10.

Теоретические сведения:

Протокол SNMP

Определение и функции протокола:

Протокол SNMP (Simple Network Management Protocol, простой протокол управления сетью) является протоколом Прикладного уровня, разработанный для выполнения двух задач:

Мониторинг сетевых устройств и сети в целом;

Управление сетевыми устройствами.

Протокол SNMP предоставляет возможность станциям управления считывать и изменять настройки шлюзов, маршрутизаторов, коммутаторов и прочих сетевых устройств.

Версии протокола SNMP

Опишем различия между версиями протокола SNMP и документы, определяющие эти версии. По состоянию на 2006 год единственной не устаревшей версией SNMP является SNMPv3, определённая в RFC 3411-3418.

Первые RFC, описывающие стандарты SNMP, появились в 1988 году. Версия 1 подвергласькритике за её посредственную модель безопасности на основе сообществ. В товремя безопасность в Интернете не входила в круг первоочередных задач рабочих группIETF.

Версия 2, известная так же, как Party-based SNMPv2, ипи SNMPv2p, не получила широкого распространения из-за серьёзных разногласий по поводу инфраструктуры безопасности в стандарте. SNMPv2 улучшал версию 1 в области быстродействия, безопасности, конфиденциальности и взаимодействий «менеджер-менеждер». Он представил новый тип PDU Get-Bulk-Request, альтернативу Get-Next-Request для получения больших объёмов

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

Community-based SNMPv2, или SNMPv2c, представил SNMPv2 без новой модели безопасности версии 2. Вместо неё предлагалось использовать старую модель безопасности версии 1 на основе сообществ. Соответствующее предложение RFC было принято только как черновик стандарта, однако стало де факто стандартом SNMPv2. Безопасность SNMP снова оказалась нерешённым вопросом.

User-based SNMPv2, или SNMPv2u, является компромиссом между незащищённостью SNMPvl и чрезмерной сложностью SNMPv2p. Предложенная модель безопасности на основе пользователей была положена в основу SNMPv3.

SNMPv3 наконец-то решил проблемы с безопасностью способом, который многие посчитали приемлемым. Версия 3 SNMP принята IETF как стандарт Интернета (IETF STD 62). Почти все предыдущие RFC признаны устаревшими. Документы, описывающие протокол SNMPv3, приведены ниже:

Общаяинформация.

RFC 3411. An Architecture for Describing SNMP Management Frameworks.

Обработка сообщений.

1)Привязки к транспорту.

RFC 3417. Transport Mappings for the SNMP.

2)Разбор и диспетчеризация сообщений.

RFC 3412. Message Processing and Dispatching for the SNMP.

3)Безопасность.

RFC 3414. User-based Security Model (USM) for SNMPv3.

Обработка PDU

1) Операции протокола.

RFC 3416. Version 2 of the Protocol Operations for SNMP.

2)ПриложенияSNMP.

RFC 3413. SNMP Applications.

3)Управлениедоступом.

RFC 3415. View-based Access Control Model (VACM) for the SNMP.

МодулиMIB.

RFC 3418. MIB for the SNMP.

Модель протокола SNMP

Общая модель

Модель приведена на рисунке 1. Основными взаимодействующими элементами протокола являются агенты (agent) и системы управления сетью (NMS, network management system). С точки зрения концепции «клиент-сервер» роль сервера выполняют агенты, то есть те самые устройства, для опроса состояния которых используется протокол SNMP.

Соответственно, роль клиентов отводится системам управления - сетевым приложениям, необходимым для сбора информации о функционировании агентов. Взаимодействие агентов и систем управления осуществляется на основе сообщений протокола SNMP.

Агентами в SNMP являются программные модули, которые работают в управляемых устройствах. Агенты собирают информацию об управляемых устройствах, в которых они работают.

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

Структура базы M I В

На данный момент существует четыре типа информационной базы MIВ:

1. Internet MIB - информационная база объектов для обеспечения диагностики ошибок и конфигураций. Включает в себя 171 объект (в том числе и объекты MIB I).

2. LAN manager MIB - база из 90 объектов - пароли, сессии, пользователи, общие ресурсы.

3. WINS MIB - база объектов, необходимых для управления и диагностики WINS- сервера (в серверах Microsoft Windows физически находится в файле

4. DHCP MIB - база объектов, необходимых для управления и диагностики DHCP- сервера (в серверах Microsoft Windows физически находится в файле

Структуру MIB определяет документ, называемый SMI (Structure of Management Information, структура управляющей информации). Все MIB имеют иерархическую древовидную структуру. Все базы содержат десять корневых алиасов (ветвей).

1. System - данная группа MIB II содержит в себе семь объектов, каждый из которых служит для хранения информации о системе (версия ОС, время работы и т.д.).

2. Interfaces - содержит 23 объекта, необходимых для ведения агентами статистики по сетевым интерфейсам управляемого устройства (количество интерфейсов, размер MTU, скорость передачи данных, физические адреса и т.д.).

3. AT - содержит 3 объекта, отвечающих за трансляцию адресов. Более не используется. Была включена в MIB I. Примером использования объектов AT может послужить простая ARP таблица соответствия физических (MAC) адресов сетевых карт IP адресам машин. В SNMP v2 эта информация была перенесена в MIB для соответствующих протоколов.

4. IP - содержит 42 объекта, в которых хранятся данные о проходящих IP пакетах.

5. ICMP - содержит 26 объектов со статистикой об ICMP-сообщениях.

6. TCP - содержит 19 объектов, хранящих статистику по протоколу TCP (соединения, открытые порты и т.д.).

7. UDP - содержит 6 объектов, хранящих статистику по протоколу UDP (входящие/исходящие датаграммы, порты, ошибки).

8. EGP - содержит 20 объектов - данные о трафике Exterior Gateway Protocol.

9. Transmission - зарезервирована для специфических задач.

10. SNMP - содержит 29 объектов, в которых хранится статистика по SNMP-протоколу (входящие/исходящие пакеты, ограничения пакетов по размеру, ошибки, данные об обработанных запросах и многое другое).

Рисунок 1

Каждая из ветвей в свою очередь также представима в виде дерева. Например, к адресу администратора мы можем обратиться посредством такого пути: system.sysContact.0, ко времени работы системы system.sysUpTime.O. С другой стороны те же данные могут задаваться и в точечной нотации. Так system.sysUpTime. O соответствует значение 1.3.0, так

как system имеет индекс «1» в группах MIB II, a sysUpTime - «3» в иерархии группы system. Ноль в конце пути говорит о скалярном типе хранимых данных. В процессе работы SNMP-протокол использует точечную нотацию, то есть если менеджер запрашивает у агента содержимое параметра system.sysDescr.O, то в строке запроса ссылка на объект будет преобразована в «1.1.0».

Рисунок 2

Дерево MIB расширяемо благодаря экспериментальным и частным ветвям. Например, поставщики могут определять свои собственные ветви для включения реализаций своих изделий. В настоящее время вся работа по стандартизации ведется на экспериментальной ветви.

SMI определяет следующие типы данных Ml В:

1. Network addresses (сетевые адреса) - символьные строки, представляющие адреса из конкретного стека протоколов. В настоящее время единственным примером сетевых адресов являются 32-битовые IP-адреса.

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

3. Gauges (измерители) - неотрицательные целые числа, которые могут увеличиваться или уменьшаться, но фиксируются при достижении максимального значения. Примером типа «gauges» является длина очереди, состоящей из выходных пакетов.

4. Ticks (тики) - сотые доли секунды, прошедшие после какого-нибудь события. Примером типа «ticks» является время, прошедшее после вхождения интерфейса в свое текущее состояние.

5. Opaque (непрозрачный) - произвольное тип данных. Используется для передачи произвольных информационных последовательностей, находящихся вне пределов точного печатания данных, которое использует SMI.

Основные команды системы NMS

Если NMS хочет проконтролировать какое-либо из управляемых устройств, она делает это путем отправки ему сообщения с указанием об изменении значения одной из его переменных.

В целом управляемые устройства отвечают на четыре типа команд (или инициируют их):

Для контролирования управляемых устройств NMS считывают переменные, поддерживаемые этими устройствами.

Для контролирования управляемых устройств NMS записывают переменные, накопленные в управляемых устройствах

3. Traversal operations.

NMS используют операции прослеживания, чтобы определить, какие переменные поддерживает управляемое устройство, а затем собрать информацию в таблицы переменных.

Управляемые устройства используют «ловушки» для асинхронных сообщений в NMS о некоторых событиях.

Протокол SNMPv3

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

Протокол обмена данными

Ниже на рисунке 3 приведена временная диаграмма, на которой в общем виде представлен протокол обмена SNMP-сообщениями. Для своей работы протокол SNMP использует транспортный протокол UDP, в основном 161 порт. Но для trap-сообщений используется 162 порт. Возможные команды протокола SNMPv3 приведены в таблице 1.

Рисунок 3

таблица 1

Формат SNMP-сообщения

Полное описание формата сообщения протокола SNMPv3 дано в документе RFC-3412 в разделе 6 «TheSNMPv3 MessageFormat*. Формат сообщения представлен на рисунке 4

Рисунок 4

SNMP-сообщение логически разделено на три части:

1. Часть, которая формируются отправителем в рамках модели обработки сообщений и обрабатываются получателем.

2. Часть, отвечающая за функции безопасности.

3. Собственно поле данных.

В данном разделе дано описание полей первой и третей частей. Описание полей безопасности дано в разделе. Для реализации модели обработки сообщений используются следующие поля:

MsgVersion. Версия протокола. Для протокола SNMPv3 значение в поле равно 3.

MsgID. Уникальный идентификатор, используемый SNMP-сущностями для установления соответствия между запросом и откликом. Значение msgID лежит в диапазоне 0 - (231-1).

MsgMaxSize. Максимальный размер сообщения в октетах, поддерживаемый отправителем. Его значение лежит в диапазоне 484 - (231-1) и равно максимальному размеру сегмента, который может воспринять отправитель.

MsgFlags. Однобайтовая строка, содержащая три флага в младших битах:

- reportableFlag. Если reportableFlag=1, то должно быть прислано сообщение с отчётом (команда Report). Флаг reportableFlag устанавливается отправителем во всех сообщениях запроса (команды Get, Set, Inform). Флаг устанавливается равным нулю в откликах и Trap-уведомлениях;

- privFlag;

- authFlag.

Флаги privFlag и authFlag устанавливаются отправителем для индикации уровня безопасности для данного сообщения. Для privFlag=1 используется шифрование, а для authFlag=0 - аутентификация. Допустимы любые комбинации значений флагов кроме privFlag=1 AND authFiag=0 (шифрование без аутентификации).

MsgSecurityModel Идентификатор со значением в диапазоне 0 - (231-1), который указывает на модель безопасности, используемую при формировании данного сообщения. Зарезервированы значения 1 - для SNMPvl, 2 и 3 - д л я SNMPv3.

Безопасность протокола SNMPv3

Модели безопасности протоколов SNMPv1-v3

Перечислим модели безопасности, применяющиеся в соответствующих версиях протокола

1. SNMPvl

SNMPvl - Community-based Security Model

2. SNMPv2

SNMPv2p - Party-based Security Model

SNMPv2c- Community-based Security Model

SNMPv2u - User-based Security Model

3. SNMPv3

SNMPv3 - USM User-based Security Model

Модель безопасности на основе сообществ

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

Модель безопасности на основе сторон

Модель безопасности на основе сторон (Party-based Security Model) подразумевает введение понятие стороны. Сторона — это виртуальное окружение исполнения, в котором набор допустимых операций ограничен административно. Сущность SNMP при обработке сообщения действует как сторона, поэтому ограничена операциями, определёнными для этой стороны.

Сторона определяется следующими параметрами:

1. Уникальный идентификатор стороны.

2. Логический сетевой адрес (адрес транспортного протокола).

3. Протокол аутентификации и параметры, требующиеся для аутентификации всех сообщений стороны.

4. Протокол шифрования и параметры, требующиеся для шифрования всех сообщений стороны. Могут использоваться различные алгоритмы для протоколов аутентификации и шифрования. Обычно в качестве алгоритма для протокола аутентификации используют хэш-функцию Message Digest 5 (MD5), а для протокола шифрования — алгоритм Data EncryptionStandard(DES) в режиме CipherBlockChaining(CBC). При использовании соответствующих протоколов аутентификации и шифрования модель успешно справляется с большинством угроз безопасности. Данная модель безопасности не была широко принята, поскольку показалась многим слишком сложной и запутанной.

Модель безопасности на основе пользователей

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

модель на основе сторон, но она упрощает идентификацию пользователей, распределение ключей и протокольные операции.

Модель безопасности USM . Модель безопасности USM (User-Based Security Model) использует концепцию авторизованного

сервера (authoritative Engene). При любой передаче сообщения одна или две

сущности, передатчик или приемник, рассматриваются в качестве авторизованного SNMP-сервера. Это делается согласно следующим правилам:

1. Когда SNMP-сообщение содержит поле данных, которое предполагает отклик (например, Get, GetNext, GetBulk, Set или Inform), получатель такого сообщения считается авторизованным.

2. Когда SNMP-сообщение содержит поле данных, которое не предполагает посылку отклика (например, SNMPv2-Trap, Response или Report), тогда отправитель такого сообщения считается авторизованным.

Таким образом, сообщения, посланные генератором команд, и сообщения Inform, посланные отправителем уведомлений, получатель является авторизованным. Для сообщений, посланных обработчиком команд или отправителем уведомлений Trap, отправитель является авторизованным. Такой подход имеет две цели:

1. Своевременность сообщения определяется с учетом показания часов авторизованного сервера. Когда авторизованный сервер посылает сообщение (Trap, Response, Report), оно содержит текущее показание часов, так что неавторизованный получатель может синхронизовать свои часы. Когда неавторизованный сервер посылает сообщение (Get, GetNext, GetBulk, Set, Inform), он помещает туда текущую оценку показания часов места назначения, позволяя получателю оценить своевременность прихода сообщения.

2. Процесс локализации ключа, описанный ниже, устанавливает единственного принципала, который может владеть ключом. Ключи могут храниться только в авторизованном сервере, исключая хранение нескольких копий ключа в разных местах. Когда исходящее сообщение передается процессором сообщений в USM, USM заполняет поля параметров безопасности в заголовке сообщения.

Когда входное сообщение передается обработчиком сообщений в USM, обрабатываются значения параметров безопасности, содержащихся в заголовке сообщения.

В параметрах безопасности содержатся следующие поля:

MsgAuthoritativeEngenelD. Идентификатор авторизованного сервера, участвующего в обмене. Это значение идентификатора отправителя для Trap,

Response илиReport илиадресатадляGet, GetNext, GetBulk, Set илиInform.

MsgAuthoritativeEngeneBoots. snmpEngeneBoots авторизованногосервера,

участвующеговобмене. Объект snmpEngeneBoots содержит целочисленные

значения в диапазоне 0 - (23 1-1). Это поле содержит число, показывающее сколько раз SNMP-сервер был перезагружен с момента конфигурирования.

MsgAuthoritativeEngeneTime. Время работы авторизованного сервера, участвующего в обмене. Значение этого поля лежит в диапазоне 0 - (231-1). Это поле характеризует число секунд, которое прошло с момента последней перезагрузки сервера. Каждый авторизованный сервер должен инкрементировать это поле один раз в секунду.

MsgUserName. Имя пользователя, который послал сообщение.

MsgAuthentication Parameters. Поле содержит ноль, если при обмене не используется аутентификация. В противном случае данное поле содержит аутентификационный параметр.

MsgPrivacyParameters. Поле содержит ноль, если не требуется соблюдения

конфиденциальности. В противном случае данное поле содержит параметр

безопасности. В действующей модели USM используется алгоритм шифрования DES.

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

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

Модель управления доступом

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

операций для заданной части Ml В. Такая схема управления доступом называется VACM(View-BasedAccessControlModel). В процессе управления доступом анализируется контекст (vacmContextTable), а также специализированные таблицы vacmSecurity ToGroupTable, vacmTreeFamilyTable и vacmAccessTable.

Порядок выполнения работы:

1.Соберите топологию сети, представленную на рисунке 5.

Рисунок 5 - топология сети

2. Настройте SNMP-протокол на коммутаторах.

3. ЗапуститеутилитуiReasoning MIB Browser.

4. Загрузите базу MIB RFC-1213.

5. На обоих коммутаторах (DES-3010 и DES-3828) выясните следующие параметры:

- название устройства, время работы устройства, службы, запущенные на

устройстве (ветвь system);

- количество интерфейсов на устройстве, содержимое таблицы интерфейсов,

назначение двух дополнительных виртуальных портов (ветвь interfaces);

- IP-адрес устройства, содержимое таблицы маршрутизации (ветвь ip);

TCP-соединения, установленные устройством (ветвь tap).

6. Загрузите базы MIB Time, DES-3010G-L2MGMT из каталога

root/ Desktop/SNMP/DES3000-MIB/ private/.

7. Определите текущее системное время коммутатора.

8. Определите состояния портов коммутатора (база DES-3010G-L2MGMT, ветвь swL2PortlnfoTable, таблица swL2PortMgmt).

Контрольные вопросы:

1. Что такое SNMP-протокол, функции и назначение?

2. Назовите вкладки раздела SingleIPManagementи их функции.

Уже немало написано о том, что в названии Simple Network Management Protocol слово Simple можно смело писать в кавычках. Протокол SNMP является достаточно простым с точки зрения создания SNMP-агентов, однако на стороне управляющего ПО (SNMP manager) грамотная обработка сложных по структуре данных обычно является нетривиальной задачей.

Мы попытались упростить процесс настройки сбора данных и событий SNMP и позволить пользователям во время этого процесса:

• Никогда не заглядывать внутрь MIB-файлов
• Не знать, что такое OID-ы и никогда не оперировать с ними
• Не пользоваться отдельной SNMP-утилитой для предварительного просмотра данных во время настройки

Шаг 1: добавляем MIB-файлы

Модуль SNMP нашей системы AggreGate Network Manager при старте загружает все MIB-файлы, находящиеся в специальной папке сервера, после чего позволяет добавлять новые при помощи простого диалога:

Во время загрузки файлов происходит их автоматическая компиляция. Встроенный редактор MIB-ов с подсветкой синтаксиса имеется лишь на случай появления MIBов, не соответствующих спецификации. Пользоваться им нужно крайне редко.

Редактор MIB-ов

Таблица MIB-ов

Шаг 2: подключаем SNMP-устройство

Шаг 3: изучаем снимок устройства

В этом снимке сосредоточена практически вся суть нашего подхода к работе с данными SNMP. Прежде всего, он всегда содержит «под рукой» все реальные данные устройства. При этом все данные считываются только один раз, последующий опрос идет только по важным метрикам. Полное перечитывание снимка устройства производится раз в сутки, для снижения нагрузки на сеть его можно вообще отключить. Снимок устройства опционально сохраняется в БД при перезапуске системы мониторинга.

Обычно не требуется прибегать к помощи каких-либо внешних утилит когда требуется найти подходящие данные для мониторинга по их описаниям в MIB-файле или значениям. Все данные уже сгруппированы по MIB-файлам, однако можно сгруппировать их и по иерархии OID-ов:

Чтобы посмотреть подробное описание любой метрики или таблицы, содержащееся в MIB-файле, достаточно навести мышкой на описание или значение метрики. Во всплывающей подсказке также виден тип данных SNMP и полный OID:

Если метрика может принимать одно из нескольких числовых значений, описанных в MIB-файле текстовыми константами, в снимке устройства сразу показывается соответствующая текущему значению константа. Полный список констант и их числовых значений доступен через контекстное меню:

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

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

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

При наведении на заголовок столбца во всплывающей подсказке видно описание поля, полученное из MIB-файла, а также его тип и OID:

Если имеется несколько связанных друг с другом таблиц, например использующих внешние индексы или расширение (augmentation), система автоматически обрабатывает все внутренние связи и сводит данные связанных таблиц в одно целое. В большинстве случаев пользователи даже не подозревают о существовании таких сложностей. Вот, например, как выглядит таблица hrSWRunPerfTable :

На уровне MIB файла эта таблица представляет из себя два столбца (hrSWRunPerfCPU и hrSWRunPerfMem ), расширяющие таблицу hrSWRunTable . В снимке устройства эти таблицы уже объединены, что облегчает анализ данных, построение отчетности и диаграмм, настройку хранения и т.д.

Поскольку единая модель данных платформы AggreGate ориентирована на работу с таблицами, таблицы данных SNMP являются идеальным кандидатом на обработку встроенными средствами. При помощи них реализуется построение топологии L2/L3, анализ данных MPLS TE и MPLS VPN, мониторинг и создание тестов IP SLA, а также сотни более простых задач.

Шаг 4: настраиваем периоды опроса и сроки хранения

Откорректировать настройки опроса (синхронизации) и хранения метрики можно через ее контекстное меню, либо через настройки аккаунта (для всех метрик сразу).

Настройки опроса и хранения

В диалоге настроек хранения показывается только срок хранения «сырых» данных в обычной базе данных (реляционной или NoSQL, в зависимости от настроек сервера). В большинстве случаев данные SNMP хранятся в кольцевой базе данных (Round-Robin Database, RRD), которая встроена в платформу AggreGate. На тему создания каналов статистики , которые перекладывают метрики и части таблиц в кольцевую БД, будет отдельная статья.

Шаг 5: переходим к обработке и визуализации данных

При помощи этих средств настраивается влияние метрик и таблиц на общесистемные операции поиска причин отказов, анализа производительности, планирования и инвентаризации, управления конфигурациями, и других функций системы. Попутно «рисуются» различные интерфейсы:

В результате

При настройке мониторинга не требуется ручное указание названий MIB-ов, ввод OID-ов и других низкоуровневых идентификаторов. Это делает настройку SNMP-мониторинга достаточно быстрой и легкой.

Безусловно, нам еще есть над чем поработать. Требуется улучшение механизмов выбора индивидуальных метрик, чтобы избежать даже единократного опроса целых MIBов. Есть необходимость исключения из опроса индивидуальных строк и столбцов SNMP-таблиц. Нам интересно было бы услышать и о других недостатках процесса настройки SNMP-мониторинга в нашей системе.

А поподробнее?

Для более подробного рассказа мы приглашаем всех хабражителей на вебинар Мониторинг и управление по SNMP , который состоится 26 мая 2015 года в 11:00 по московскому времени. На этом вебинаре мы «вживую» продемонстрируем весь вышеописанный процесс, а также многие другие способы мониторинга сетевого, серверного и нестандартного оборудования при помощи SNMP.