previous up down next index search
Previous: 4.4.12 DNS (структура, обработка запросов, ресурсные записи)    UP: 4.4 Интернет
Down: 4.4.13.1 Управляющая база данных MIB
    Next: 4.4.14 Протокол электронной почты SMTP

4.4.13 Протокол управления SNMP

Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)

Номер раздела Название раздела Объем в страницах Объем в кбайт
4.4.13.1 Управляющая база данных MIB 27 118
4.4.13.2 Нотация ASN.1 19 63
Итого 00


Команды SNMP
Коды ошибок
Коды TRAP
SNMPv3
Компоненты процессора SNMP
User-Based Security Model
RFC-документы по протоколу SNMP

Интернет - гигантская сеть. Напрашивается вопрос, как она сохраняет свою целостность и функциональность без единого управления? Если же учесть разнородность ЭВМ, маршрутизаторов и программного обеспечения, используемых в сети, само существование Интернет представится просто чудом. Так как же решаются проблемы управления в Интернет? Отчасти на этот вопрос уже дан ответ - сеть сохраняет работоспособность за счет жесткой протокольной регламентации. "Запас прочности" заложен в самих протоколах. Функции диагностики возложены, как было сказано выше, на протокол ICMP. Учитывая важность функции управления, для этих целей создано два протокола SNMP (Simple Network Management Protocol, RFC-1157, -1215, -1187, -1089, std-15 разработан в 1988 году) и CMOT (Common Management Information services and protocol over TCP/IP, RFC-1095, в последнее время применение этого протокола ограничено). Обычно управляющая прикладная программа воздействует на сеть по цепочке SNMP-UDP-IP-Ethernet. Наиболее важным объектом управления обычно является внешний порт сети (gateway) или маршрутизатор сети. Каждому управляемому объекту присваивается уникальный идентификатор.

Протокол SNMP работает на базе транспортных возможностей UDP (возможны реализации и на основе ТСР) и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении в сети Интернет. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При своей работе SNMP использует управляющую базу данных (MIB - management information base, RFC-1213, -1212, std-17). Смотри Essential SNMP. Douglas R. Mauro and Kevin J. Schmidt. O’Reilly, Второе издание. 2001. На русском языке книга вышла под название Основы SNMP в 2012 г в изд. Символ, Петербург (перевод Р. Багаутдинова, научным редактором перевода был я).

Алгоритмы управления в Интернет обычно описывают в нотации ASN.1 (Abstract Syntax Notation). Все объекты в Интернет разделены на 10 групп и описаны в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу "система" входит название и версия оборудования, операционной системы, сетевого программного обеспечения и пр.. В группу "интерфейсы" входит число поддерживаемых интерфейсов, тип интерфейса, работающего под IP (Ethernet, LAPB etc.), размер дейтограмм, скорость обмена, адрес интерфейса. IP-группа включает в себя время жизни дейтограмм, информация о фрагментации, маски субсетей и т.д. В TCP-группу входит алгоритм повторной пересылки, максимальное число повторных пересылок и пр.. Ниже приведена таблица (4.4.13.1) команд (pdu - protocol data unit) SNMP:


Таблица 4.4.13.1 Команды SNMP

Команда SNMP Тип PDU Назначение
GET-request 0 Получить значение указанной переменной или информацию о состоянии сетевого элемента;
GET_next_request 1 Получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB);
SET-request 2 Присвоить переменной соответствующее значение. Используется для описания действия, которое должно быть выполнено;
GET response 3 Отклик на GET-request, GET_next_request и SET-request. Содержит также информацию о состоянии (коды ошибок и другие данные);
TRAP 4 Отклик сетевого объекта на событие или на изменение состояния.
GetBulkRequest 5 Запрос пересылки больших объемов данных, например, таблиц.
InformRequest 6 Менеджер обращает внимание партнера на определенную информацию в MIB.
SNMPv3-Trap 7 Отклик на событие (расширение по отношению v1 и v2).
Report 8 Отчет (функция пока не задана).

Рис. 4.4.13.1 Схема запросов/откликов SNMP

Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы, имеет вид (рис. 4.4.13.2):

Рис. 4.4.13.2 Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы

Поле версия содержит значение, равное номеру версии SNMP минус один. Поле пароль (community - определяет группу доступа) содержит последовательность символов, которая является пропуском при взаимодействии менеджера и объекта управления. Обычно это поле содержит 6-байтовую строку public, что означает общедоступность. Для запросов GET, GET-next и SET значение идентификатора запроса устанавливается менеджером и возвращается объектом управления в отклике GET, что позволяет связывать в пары запросы и отклики. Поле фирма (enterprise) = sysobjectid объекта. Поле статус ошибки характеризуется целым числом, присланным объектом управления:

Таблица 4.4.13.2. Номера и назначения используемых портов

Назначение Порт Пояснение
SNMP 161/TCP Simple Network Management Protocol
SNMP 162/TCP Trap
SMUX 199/TCP SNMP Unix Multiplexer
SMUX 199/UDP SNMP Unix Multiplexer
synoptics-relay 391/TCP SynOptics SNMP Relay Port
synoptics-relay 391/UDP SynOptics SNMP Relay Port
agentx 705/TCP AgentX
snmp-tcp-port 1993/TCP cisco SNMP TCP port
snmp-tcp-port 1993/UDP cisco SNMP TCP port

Таблица 4.4.13.3. Коды ошибок

Статус ошибки Имя ошибки Описание
0 Noerror Все в порядке;
1 Toobig Объект не может уложить отклик в одно сообщение;
2 Nosuchname В операции указана неизвестная переменная;
3 badvalue В команде set использована недопустимая величина или неправильный синтаксис;
4 Readonly Менеджер попытался изменить константу;
5 Generr Прочие ошибки.

Если произошла ошибка, поле индекс ошибки (error index) характеризует, к какой из переменных это относится. error index является указателем переменной и устанавливается объектом управления не равным нулю для ошибок badvalue, readonly и nosuchname. Для оператора TRAP (тип PDU=4) формат сообщения меняется. Таблица типов TRAP представлена ниже (4.4.13.4):

Таблица 4.4.13.4. Коды TRAP

Тип TRAP Имя TRAP Описание
0 Coldstart Установка начального состояния объекта.
1 Warmstart Восстановление начального состояния объекта.
2 Linkdown Интерфейс выключился. Первая переменная в сообщении идентифицирует интерфейс.
3 Linkup Интерфейс включился. Первая переменная в сообщении идентифицирует интерфейс.
4 Authenticationfailure От менеджера получено snmp-сообщение с неверным паролем (community).
5 EGPneighborloss EGP-партнер отключился. Первая переменная в сообщении определяет IP-адрес партнера.
6 Entrprisespecific Информация о TRAP содержится в поле специальный код.

Для тип TRAP 0-4 поле специальный код должно быть равно нулю. Поле временная метка содержит число сотых долей секунды (число тиков) с момента инициализации объекта управления. Так прерывание coldstart выдается объектом через 200 мс после инициализации.

В последнее время широкое распространение получила идеология распределенного протокольного интерфейса DPI (Distributed Protocol Interface). Для транспортировки snmp-запросов может использоваться не только UDP-, но и TCP-протокол. Это дает возможность применять SNMP-протокол не только в локальных сетях. Форматы SNMP-DPI-запросов (версия 2.0) описаны в документе RFC-1592. Пример заголовка snmp-запроса (изображенные поля образуют единый массив; см. рис. 4.4.13.3):

Рис. 4.4.13.3. Формат заголовка SNMP-запроса

Поле Флаг=0x30 является признаком ASN.1-заголовка. Коды Ln - представляют собой длины полей, начинающиеся с байта, который следует за кодом длины, вплоть до конца сообщения-запроса (n - номер поля длины), если не оговорено другое. Так L1 - длина пакета-запроса, начиная с T1 и до конца пакета, а L3 - длина поля пароля. Субполя Tn - поля типа следующего за ними субполя запроса. Так T1=2 означает, что поле характеризуется целым числом, а T2=4 указывает на то, что далее следует пароль (поле community, в приведенном примере = public). Цифры под рисунками означают типовые значения субполей. Код 0xA - является признаком GET-запроса, за ним следует поле кода PDU (=0-4, см. табл. 4.4.13.1) Блок субполей идентификатора запроса служит для тех же целей, что и другие идентификаторы - для определения пары запрос-отклик. Собственно идентификатор запроса может занимать один или два байта, что определяется значением Lиз. СО - статус ошибки (СО=0 - ошибки нет); ТМ - тип MIB-переменной (в приведенном примере = 0x2B); ИО - индекс ошибки. Цифровой код MIB-переменной отображается последовательностью цифровых субполей, характеризующих переменную, например: переменная 1.3.6.1.2.1.5 (в символьном выражении iso.org.dod.internet.mgmt.mib.icmp) характеризуется последовательностью кодов 0x2B 0x06 0x01 0x02 0x01 0x05 0x00.

Начиная с января 1998 года, выпущен набор документов, посвященных SNMPv3. В этой версии существенно расширена функциональность (см. таблицу 1 тип PDU=5-8), разработана система безопасности. В данной версии реализована модель, базирующаяся на процессоре SNMP (SNMP Engene) и содержащая несколько подсистем (дипетчер, система обработки сообщений, безопасности и управления доступом, см. рис. 4.4.13.4). Перечисленные подсистемы служат основой функционирования генератора и обработчика команд, отправителя и обработчика уведомлений и прокси-сервера (Proxy Forwarder), работающих на прикладном уровне. Процессор SNMP идентифицируется с помощью snmpEngineID. Обеспечение безопасности модели работы SNMP упрощается обычно тем, что обмен запросами-откликами осуществляется в локальной сети, а источники запросов-откликов легко идентифицируются.


Рис. 4.4.13.4. Архитектура сущности SNMP (SNMP-entity)

Компоненты процессора SNMP перечислены в таблице 4.4.13.5 (смотри RFC 2571 и -2573)

Таблица 4.4.13.5. Компоненты процессора SNMP

Название компонента Функция компонента
Диспетчер Позволяет одновременную поддержку нескольких версий SNMP-сообщений в процессоре SNMP. Этот компонент ответственен за прием протокольных блоков данных (PDU), за передачу PDU подсистеме обработки сообщений, за передачу и прием сетевых SNMP-сообщений
Подсистема обработки сообщений Ответственна за подготовку сообщений для отправки и за извлечение данных из входных сообщений
Подсистема безопасности Предоставляет услуги, обеспечивающие безопасность: аутентификацию и защищенность сообщений от перехвата и искажения. Допускается реализация нескольких моделей безопасности
Подсистема управления доступом Предоставляет ряд услуг авторизации, которые могут использоваться приложениями для проверки прав доступа.
Генератор команд Инициирует SNMP-запросы Get, GetNext, GetBulk или Set, предназначенные для локальной системы, которые могут использоваться приложениями для проверки прав доступа.
Обработчик команд Воспринимает SNMP-запросы Get, GetNext, GetBulk или Set, предназначенные для локальной системы, это индицируется тем, что contextEngeneID в полученном запросе равно соответствующему значению в процессоре SNMP. Приложение обработчика команд выполняет соответствующие протокольные операции, генерирует сообщения отклика и посылает их отправителю запроса.
Отправитель уведомлений Мониторирует систему на предмет выявления определенных событий или условий и генерирует сообщения Trap или Inform. Источник уведомлений должен иметь механизм определения адресата таких сообщений, а также параметров безопасности
Получатель уведомлений Прослушивает сообщения уведомления и формирует сообщения-отклики, когда приходит сообщение с PDU Inform
Прокси-сервер Переадресует SNMP-сообщения. Реализация этого модуля является опционной

На рис. 4.4.13.5 показан формат сообщений SNMPv3, реализующий модель безопасности UBM (User-Based Security Model).


Рис. 4.4.13.5. Формат сообщений SNMPv3 c UBM

Первые пять полей формируются отправителем в рамках модели обработки сообщений и обрабатываются получателем. Следующие шесть полей несут в себе параметры безопасности. Далее следует PDU (блок поля данных) с contextEngeneID и contextName.

.

Модель безопасности USM (User-Based Security Model) использует концепцию авторизованного сервера (authoritative Engene). При любой передаче сообщения одна или две сущности, передатчик или приемник, рассматриваются в качестве авторизованного SNMP-сервера. Это делается согласно следующим правилам:

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

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

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

Система конфигурирования агентов позволяет обеспечить разные уровни доступа к MIB для различных SNMP-менеджеров. Это делается путем ограничения доступа некоторым агентам к определенным частям MIB, а также с помощью ограничения перечня допустимых операций для заданной части MIB. Такая схема управления доступом называется VACM (View-Based Access Control Model). В процессе управления доступом анализируется контекст (vacmContextTable), а также специализированные таблицы vacmSecurityToGroupTable, vacmTreeFamilyTable и vacmAccessTable.

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

Таблица 4.4.13.6. RFC-документы по протоколу SNMP

Название Дата Наименование документа
STD-15май 1990 г Simple Network Management Protocol (RFC-1157)
STD-16май 1990 г Structure and Identification of Management Information for TCP/IP-based Internets (RFC-1155)
SNMPv2
RFC 1902январь 1996 г Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1903январь 1996 г Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1904январь 1996 г Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1905январь 1996 г Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1906январь 1996 г Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1907январь 1996 г Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1908январь 1996 г Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework
SNMPv3
RFC 2570апрель 1999 г Introduction to Version 3 of the Internet-standard Network Management Framework
RFC2571апрель 1999 г An Architecture for Describing SNMP Management Frameworks
RFC2572апрель 1999 г Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
RFC2573апрель 1999 г SNMP Applications
RFC2574апрель 1999 г The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3). Безопасность уровня сообщений (MD5 и SHA + DES CBC)
RFC2575апрель 1999 г View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

Previous: 4.4.12 DNS (структура, обработка запросов, ресурсные записи)    UP: 4.4 Интернет
Down: 4.4.13.1 Управляющая база данных MIB
    Next: 4.4.14 Протокол электронной почты SMTP