Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Протокол управления SNMP
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2024
Тип роботи:
Лекція
Предмет:
Інші
Частина тексту файла (без зображень, графіків і формул):
4.4.13 Протокол управления SNMP
Семенов Ю.А. (ГНЦ ИТЭФ)
Номер раздела
Название раздела
Объем в страницах
Объем в кбайт
4.4.13.1
Управляющая база данных MIB
26
118
4.4.13.2
Нотация ASN.1
17
63
Итого
43
181
Интернет - гигантская сеть. Напрашивается вопрос, как она сохраняет свою целостность и функциональность без единого управления? Если же учесть разнородность ЭВМ, маршрутизаторов и программного обеспечения, используемых в сети, само существование Интернет представится просто чудом. Так как же решаются проблемы управления в Интернет? Отчасти на этот вопрос уже дан ответ - сеть сохраняет работоспособность за счет жесткой протокольной регламентации. "Запас прочности" заложен в самих протоколах. Функции диагностики возложены, как было сказано выше, на протокол 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).
Алгоритмы управления в Интернет обычно описывают в нотации 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
R$GP-партнер отключился. Первая переменная в сообщении определяет 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.
.
msgVersion (для SNMPv3)=3
msgID - уникальный идентификатор, используемый SNMP-сущностями для установления соответствия между запросом и откликом. Значение msgID лежит в диапазоне 0 - (231-1)
msgMaxSize - определяет максимальный размер сообщения в октетах, поддерживаемый отправителем. Его значение лежит в диапазоне 484 - (231-1) и равно максимальному размеру сегмента, который может воспринять отправитель.
msgFlags - 1-октетная строка, содержащая три флага в младших битах: reportableFlag, privFlag, authFlag. Если reportableFlag=1, должно быть прислано сообщение с PDU Report; когда флаг =0, Report посылать не следует. Флаг reportableFlag=1 устанавливается отправителем во всех сообщениях запроса (Get, Set) или Inform. Флаг устанавливается равным нулю в откликах, уведомлениях Trap или сообщениях Report. Флаги privFlag и authFlag устанавливаются отправителем для индикации уровня безопасности для данного сообщения. Для privFlag=1 используется шифрование, а для authFlag=0 - аутентификация. Допустимы любые комбинации значений флагов кроме privFlag=1 AND authFlag=0 (шифрование бех аутентификации).
msgSecurityModel - идентификатор со значением в диапазоне 0 - (231-1), который указывает на модель безопасности, использованную при формировании данного сообщения. Зарезервированы значения 1 для SNMPv1,2 и 3 - для SNMPv3.
Модель безопасности USM (User-Based Security Model) использует концепцию авторизованного сервера (authoritative Engene). При любой передаче сообщения одна или две сущности, передатчик или приемник, рассматриваются в качестве авторизованного SNMP-сервера. Это делается согласно следующим правилам:
Когда SNMP-сообщение содержит поле данных, которое предполагает отклик (например, Get, GetNext, GetBulk, Set или Inform), получатель такого сообщения считается авторизованным.
Когда SNMP-сообщение содержит поле данных, которое не предполагает посылку отклика (например, SNMPv2-Trap, Response или Report), тогда отправитель такого сообщения считается авторизованным.
Таким образом, сообщения, посланные генератором команд, и сообщения Inform, посланные отправителем уведомлений, получатель является авторизованным. Для сообщений, посланных обработчиком команд или отправителем уведомлений Trap, отправитель является авторизованным. Такой подход имеет две цели:
Своевременность сообщения определяется с учетом показания часов авторизованного сервера. Когда авторизованный сервер посылает сообщение (Trap, Response, Report), оно содержит текущее показание часов, так что неавторизованный получатель может синхронизовать свои часы. Когда неавторизованный сервер посылает сообщение (Get, GetNext, GetBulk, Set, Inform), он помещает туда текущую оценку показания часов места назначения, позволяя получателю оценить своевременность прихода сообщения.
Процесс локализации ключа, описанный ниже, устанавливает единственного принципала, который может владеть ключем. Ключи могут храниться только в авторизованном сервере, исключая хранение нескольких копий ключа в разных местах.
Когда исходящее сообщение передается процессором сообщений в USM, USM заполняет поля параметров безопасности в заголовке сообщения. Когда входное сообщение передается обработчиком сообщений в USM, обрабатываются значения параметров безопасности, содержащихся в заголоке сообщения. В параметрах безопасности содержатся:
msgAuthoritativeEngeneID - snmpEngeneID авторизованного сервера, участвующего в обмене. Таким образом, это значение идентификатора отправителя для Trap, Response или Report или адресата для Get, GetNext, GetBulk, Set или Inform.
msgAuthoritativeEngeneBoots - snmpEngeneBoots авторизованного сервера, участвующего в обмене. Объект snmpEngeneBoots является целым в диапазоне 0 - (231-1). Этот код характеризует число раз, которое SNMP-сервер был перезагружен с момента конфигурирования.
msgAuthoritativeEngeneTime - nmpEngeneTime авторизованного сервера, участвующего в обмене. Значение этого кода лежит в диапазоне 0 - (231-1). Этот код характеризует число секунд, которое прошло с момента последней перезагрузки. Каждый авторизованный сервер должен инкрементировать этот код один раз в секунду.
msgUserName - идентификатор пользователя от имени которого послано сообщение.
msgAuthenticationParameters - нуль, если при обмене не используется аутентификация. В противном случае - это аутентификационный параметр.
msgPrivacyParameters - нуль - если не требуется соблюдения конфимденциальности. В противном случае - это параметр безопасности. В действующей модели USM используется алгоритм шифрования DES.
Механизм аутентификации в 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)
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора