Протокол SNMP

 

 

Курсовая работа

 

 

 

По курсу: Локальные, корпоративные и глобальные информационные сети

Тема:  Протокол SNMP

 

 

 

 

 

 

 

 

 

 

 

 

Канаш 2013 г.

 

 

 

 

 

Аннотация  

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Содержание

 

Введение………………………………………………………….…….…….…4

1.  Архитектура протокола SNMP……………………………………………..5

2. SNMP PDU (или  сообщения SNMP протокола)………………....…………7

3.Логика работы  протокола SNMP ……………………………………….…...10

4. SNMP MIB……………………………………………………………….……14

5. Безопасность протокола SNMP ……………….………………………...…..19

6.Принципы  настройки протокола SNMP…………………………...…………20

7. Заключение………………………………………………………………...…..24

8. Список литературы………………………………………………………...….25

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Введение

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

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

 

 

 

 

 

 

 

 

 

 

 

1. Архитектура протокола 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).

SNMP работает на 7 уровне модели OSI, то есть является службой прикладного уровня. Взаимодействие агента и менеджера на уровне протокола SNMP организуется посредством т.н. пакетов объектов PDU (Protocol Data Unit), которые инкапсулируются в транспортный протокол. Хотя, SNMP поддерживает различные виды транспорта, в 99% случаев используется - UDP. При этом, каждое сообщение PDU содержит определенную команду (на чтение переменной, запись значения переменной, или ответ\trap агента). В целом, взаимодействие узлов по SNMP можно представить следующей последовательностью: менеджер -> SNMP(PDU)-UDP-IP-Ethernet-IP-UDP-SNMP(PDU) ->агент. При использовании шифрования в SNMP, по умолчанию используются порт для запросов\ответов udp/10161, а Trap отправляются на udp/10162.

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

 

Итак, SNMP менеджер отправляет запросы агенту на порт udp/161 (если конфигурационно в агенте не задан другой порт) с произвольного порта из эфемерного диапазона. В запросе SNMP менеджера указывается порт и адрес источника (о полной структуре пакета SNMP опишу ниже). Далее агент принимает пакет и обрабатывает (если выполняются нижеописанные условия). В процессе обработки, формируется ответ, который отправляется на порт взятый из исходного запроса. Ответ отправляется с udp/161 порта. Можно сказать, что SNMP агент таким образом предоставляет доступ SNMP менеджеру к данным, хранящимся в базе MIB. При этом, в момент отправки, SNMP менеджер вставляет в PDU некий ID (RequestID), а агент в ответном PDU вставляет данный ID без изменения, для того чтобы менеджер не путал пакеты от разных агентов. SNMP агент может быть настроен на посылку Trap уведомлений, которую он выполняет с эфимерного порта на udp/162 порт SNMP менеджера.

2. SNMP PDU (или сообщения SNMP протокола)

Выше я упомянул о единице обмена между узлами SNMP - PDU (Protocol Data Unit), давайте разберем данное понятие. Для обмена между агентом и менеджером используется определенный набор сообщений PDU команд:

• Trap – одностороннее уведомление от SNMP агента –> менеджеру о каком-либо событии.
• GetReponse – ответ от агента к менеджеру, возвращающий запрошенные значения переменных.
• GetRequest - запрос к агенту от менеджера, используемый для получения значения одной или нескольких переменных.
• GetNextRequest - запрос к агенту от менеджера, используемый для получения следующего в иерархии значения переменной.
• SetRequest - запрос к агенту на установку значения одной или нескольких переменных.
• GetBulkRequest – запрос к агенту на получение массива данных (тюнингованная GetNextRequest). (Этот PDU был введен в SNMPv2.)
• InformRequest – одностороннее уведомление между менеджерами. Может использоваться, например для обмена информацией о MIB (соответствие символьных OID - цифровым). В ответ менеджер формирует аналогичный пакет в подтверждение того, что исходные данные получены. (Этот PDU был введен в SNMPv2.)

Как видно, в зависимости от версии протокола, набор команд разный (например InformRequest и GetBulkRequest полноценно появился только во второй версии SNMP). Компонент SNMP MIB рассмотрим ниже.

Структура PDU

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

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

• версия - содержит версию SNMP
• пароль (community) -  содержит последовательность символов, описывающую принадлежность к группе (об этом ниже)
• тип PDU имеет цифровой идентификатор запроса (Get,GetNext,Set,Responde,Trap…)
• идентификатор запроса – это тот самый набор символов, который связывает в единое целое запрос\ответ.
• Статус ошибки– это число, характеризующее характер ошибки:
• Для запросов (Get,Set,GetNExt и др.) - 0
• Для ответов:
• 0 (NoError) – Нет ошибок,
• 1 (TooBig) - Объект не вмещается в одно Response сообщение,
• 2 (NoSuchName) – не существующая переменная,
• 3 (BadValue) – при попытке установить значение задано недопустимое значение или совершена синтаксическая ошибка,
• 4 (ReadOnly) – при Set запросе была попытка изменить read-only переменную,
• 5 (GenErr) – другие ошибки.
• Индекс ошибки – не нашел внятного описания ( но смысл в том, что содержит некий индекс переменной, к которой относится ошибка
• Поле связанные переменные может содержать одну или более переменную (для запросов Get – это только имя переменных, для Set – имя и устанавливаемое значение, для Response – имя и запрошенное значение).

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

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

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

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

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

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

Логика работы 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 значение TooBig, а в поле 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 совпадает с идентификатором в принятом сообщении.