Опубликован: 10.10.2007 | Уровень: специалист | Доступ: платный
Лекция 8:

Сетевая диагностика. Протокол SNMP

< Лекция 7 || Лекция 8: 12345 || Лекция 9 >

Начиная с января 1998 года, выпущен набор документов, посвященных SNMPv3 (RFC-3411 [ std0062 ], -3412-14, -3418). В этой версии существенно расширена функциональность (см. таблицу 8.7 тип PDU=5-8), разработана система безопасности. В данной версии реализована модель, базирующаяся на процессоре SNMP ( SNMP Engine) и содержащая несколько подсистем (диспетчер, система обработки сообщений, безопасности и управления доступом, см. рис. 8.4). Перечисленные подсистемы служат основой функционирования генератора и обработчика команд, отправителя и обработчика уведомлений и прокси-сервера (Proxy Forwarder), работающих на прикладном уровне. Процессор SNMP идентифицируется с помощью snmpEngineID. Обеспечение безопасности модели работы SNMP упрощается обычно тем, что обмен запросами-откликами осуществляется в локальной сети, а источники запросов-откликов легко идентифицируются.

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

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

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

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

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

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

Рис. 8.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 Engine). При любой передаче сообщения одна или две сущности, передатчик или приемник, рассматриваются в качестве авторизованного SNMP -сервера. Это делается согласно следующим правилам.

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

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

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

Когда исходящее сообщение передается процессором сообщений в 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 -протокол служит примером системы управления, где для достижения нужного результата выдается не команда, а осуществляется обмен информацией, решение же принимается на месте в соответствии с полученными данными. Внедрены подсистемы аутентификации, информационной безопасности и управления доступом.

Таблица 8.9. 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)
SNMPv3
RFC3411 декабрь 2002 An Architecture for Describing Simple Network Management Protocol ( SNMP ) Management Frameworks. ( std0062 )
RFC3412 декабрь 2002 Message Processing and Dispatching for the Simple Network Management Protocol ( SNMP ).
RFC3413 декабрь 2002 Simple Network Management Protocol ( SNMP ) Applications
RFC3414 декабрь 2002 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
RFC3415 декабрь 2002 View-based Access Control Model (VACM) for the Simple Network Management Protocol ( SNMP ).
RFC3417 декабрь 2002 Transport Mappings for the Simple Network Management Protocol ( SNMP )
RFC3418 декабрь 2002 Management Information Base ( MIB ) for the Simple Network Management Protocol ( SNMP )
< Лекция 7 || Лекция 8: 12345 || Лекция 9 >
Евгений Виноградов
Евгений Виноградов

Прошел экстерном экзамен по курсу перепордготовки "Информационная безопасность". Хочу получить диплом, но не вижу где оплатить? Ну и соответственно , как с получением бумажного документа?

Илья Сидоркин
Илья Сидоркин

Добрый день! Подскажите пожалуйста как и когда получить диплом, после сдичи и оплаты?????

Роман Ижванов
Роман Ижванов
Россия, Университет природы, общества и человека «Дубна»
Анастасия Шмакова
Анастасия Шмакова
Россия, Тольятти, ПВГУС, 2013