Протокол SNMP версии 3

(SNMPv3) был предложен в качестве стандарта Internet в январе 1998 года для укрепления защиты сети протоколов SNMPvl и SNMPv2. Эти первоначальные версии протокола SNMP не обеспечивали шифрования и аутентификации сообщений SNMP. Второй и третий наборы документов были предложены в качестве стандартов Internet для версии SNMPv3 в апреле 1999 года и декабре 2002 года. Последний набор в настоящее время является стандартом для SNMPv3.

Угрозы безопасности

Полное отсутствие аутентификации в протоколах SNMPvl/SNMPv2 делает сеть уязвимой в плане самых разнообразных угроз безопасности. Что касается обеспечения безопасности архитектуры протокола SNMPv3, то к наиболее известным угрозам относятся нелегальное проникновение в сеть, изменение информации, перехват и модификация потока сообщений.

•          Нелегальное проникновение имеет место в том случае, когда неавторизованный пользователь пытается выполнить операции по управлению сетью, предоставляя идентификационные данные авторизованного субъекта управления;

•          Модификация информации включает в себя попытку неавторизованного субъекта изменить транзитные сообщения, созданные авторизованным субъектом управления, таким образом, чтобы выполнить несанкционированные операции управления сетью, в частности, фальсификацию значений объектов;

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

•          Модификация потока сообщений имеет место в том случае, когда неавторизованный субъект переупорядочивает, задерживает или копирует и позднее повторно воспроизводит сообщение, сгенерированное авторизованным субъектом.

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

Модульная архитектура

Архитектура протокола SNMPv3 по природе своего проектирования является модульной, как показано на рис. 58.5. Модульность архитектуры позволяет с течением времени изменять ее в соответствии с эволюцией стандартов SNMP. Любое устройство протокола SNMP содержит SNMP-модуль, который включает в себя диспетчер, подсистему обработки сообщений, подсистему защиты сети и подсистему управления доступом. Оно может также включать в себя различные приложения протокола SNMP, выполняющие специфическую функциональную обработку данных управления.

Рис. 58.5. Компоненты устройства протокола SNMP

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

Устройство SNMP имеет один модуль SNMP, который обеспечивает службы отправки, получения и обработки сообщений, аутентификации и шифрования сообщений, а также службу управлении доступом к управляемым объектам. Эти службы обеспечиваются следующим образом:

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

•          Подсистема обработки сообщений является частью модуля SNMP, которая взаимодействует с диспетчером в процессе обработки сообщений SNMP конкретной версии. Потенциально она содержит несколько моделей обработки сообщений для версий SNMPv3, SNMPv2, SNMPvl и других.

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

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

Ниже приведены модули приложений.

•          Генератор команд осуществляет мониторинг и обрабатывает управляющие данные. Он также генерирует и обрабатывает ответы модулей PDU команд Get, GetNext, GetBulk и Set.

•          Обработчик команд обеспечивает доступ к данным управления. Он получает модули PDU вышеупомянутых типов (сгенерированные ответчиком команд), генерирует ответное сообщение и отправляет его инициатору запроса.

•          Инициатор уведомления инициирует асинхронные сообщения. Он осуществляет мониторинг системы, а после этого, в зависимости от заданных ему конфи- гурациейфункций, генерирует сообщение Trap или Inform и отсылает его заранее определенным устройствам получателей.

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

•          Прокси-устройство пересылки пересылает сообщения SNMP между устройствами. Реализация приложения прокси-пересылки не является обязательной и осуществляется по желанию пользователя.

Архитектура безопасности

Документы RFC, определяющие протокол SNMPv3, описывают проблемы безопасности на двух разных этапах: приема/передачи сообщений и обработки содержания сообщений. В документах RFC для протокола SNMPv3 термин "безопасность" применяется по отношению к аспектам безопасности на уровне сообщений, а термин "управление доступом" — по отношению к вопросам безопасности протокольных операций.

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

Для поддержки служб безопасности и управления доступом в протоколе SNMP применяется понятие принципала (principal). Под принципалом понимается устройство, от имени которого предоставляются службы или происходит обработка. Принципал может быть отдельным субъектом, выполняющим определенную роль, набором таких субъектов, каждый из которых выполняет определенную функцию, приложением или набором приложений, а также комбинацией вышеупомянутых. Идентификационные данные принципала используются для задания функций безопасности, которые будут использоваться при осуществлении связи с агентом. Архитектура протокола SNMPv3 определяет три уровня обеспечения безопасности: отсутствие аутентификации и обеспечения конфиденциальности, аутентификацию и отсутствие обеспечения конфиденциальности, а также аутентификацию и обеспечение конфиденциальности.

Модель защиты сети для отдельного пользователя

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

•          Если полезная нагрузка сообщения требует подтверждения или ответа (модули PDU, требующие подтверждения: Get, GetNext, GetBulk, Set или Inform), то авторитетным устройством является получатель.

•          Если полезная нагрузка сообщения на требует ответа (модули PDU, не требующие подтверждения: Response, Report или Trap), то авторитетным устройством является отправитель.

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

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

RFC 3414, User-based Security Model for SNMPv3, определяет приведенные ниже требования.

•          В качестве протокола аутентификации должен поддерживаться протокол HMAC-MD5-96.

•          В качестве протокола аутентификации должен также поддерживаться протокол HMAC-SHA-96, а в будущем возможна поддержка дополнительных или заменяющих вышеупомянутые протоколов аутентификации.

Следует отметить, что протокол HMAC-MD5-96 использует MD5 (см. RFC 1321, Message Digest 5) в качестве хэш-функции для основанного на хэш-функции режима кода аутентификации сообщения (Hash-based Message Authentication Code — HMAC). Протокол MD5-96 осуществляет усечение выходных данных до 96 битов. Протокол HMAC- SHA-96 делает то же самое, однако использует в качестве хэш-функции SHA (SHA- N1ST). Протокол НМАС (см. RFC 2104) представляет собой механизм аутентификации сообщения, a MD5 и SHA используются в качестве криптографических хэш-функций.

В аспекте обеспечения конфиденциальности определяется использование симметричного шифрования CBC-DES вместе с моделью безопасности для конкретного пользователя. В будущем могут быть также определены в качестве дополнительных или заменяющих другие протоколы обеспечения конфиденциальности. CBC-DES представляет собой режим стандарта шифрования данных (Data Encryption Standard — DES) с объединением шифровых блоков, который, в случае поступающего запроса, USM использует для шифрования отправляемого сообщения и предотвращения чтения содержимого этого сообщения третьими сторонами.

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

Как определяется в RFC 3415, VACМ for the SNMP, подсистема управления доступом устройства SNMP проверяет, разрешен ли запрашиваемый тип доступа (read, write, notify) к данному объекту (instance). Когда устройство SNMP обрабатывает запрос на извлечение данных (Get, GetNext, GetBulk) или запрос на модификацию (Set), оно должно осуществлять контроль доступа. Например, приложение ответчика на команды применяет контроль доступа при обработке запроса, которое оно получает от приложения-генератора запроса. Перед отправкой SNMP-сообщения- уведомления (инициированного приложением создающим уведомление) устройство протокола SNMP также должно выполнить контроль доступа.

Управление доступом конфигурируется группой пользователей, при этом каждая группа может включать в себя нескольких пользователей. Политика обеспечения безопасности должна быть предварительно сконфигурирована на устройствах SNMP, осуществляющих управление доступом. Для выработки политики управления доступом администратор сначала определяет, какой тип операции может быть использован этой группой (read, write или notify). После этого администратор определяет права доступа к этой операции. Например, агент может быть сконфигурирован таким образом, что он дает группе пользователей право чтения только одной базы MIB (или части базы MIB). Он может быть также сконфигурирован так, чтобы другая группа пользователей получила право записи в несколько М1В-объектов.

Управление посредством SNMP

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

Справочные данные протокола SNMP: форматы сообщений SNMP

Сообщения SNMPv2 состоят из заголовка и модуля PDU. Базовый формат SNMP- сообщений показан на рис. 58.6.

Рис. 58.9. Поля модуля PDU Trap протокола SNMP

Ниже описаны поля, показанные на рис. 58.9.

•      Предприятие. Тип управляемого объекта, генерирующего прерывание.

•     Адрес агента. Адрес управляемого объекта, генерирующего прерывание.

•      Общий тип прерывания. Номер общего типа прерывания.

•     Код прерывания. Номер специального типа прерывания.

•          Метка времени. Время, которое прошло между последней реинициализацией сети и генерированием прерывания.

•          Переменные. Поле данных модуля PDU протокола SNMP. Каждая переменная соответствует конкретному объекту и его текущему значению.

Резюме

Протокол SNMP представляет собой протокол уровня приложений стека протоколов TCP/IP. Он был создан для того, чтобы стандартизовать архитектуру сетевого управления. Протокол SNMP использует схему, включающую в себя станции управления сетью (менеджеры), которые осуществляют мониторинг и управление сетевыми устройствами. Менеджер также выполняет функции интерфейса между самой сетью и сетевым администратором. На управляемом устройстве установлено агентское программное обеспечение, которое взаимодействует с менеджером с помощью набора протокольных операций, таких как Get, Set, Get, Next, GetBulk и Trap. Эти операции работают с множеством иерархически организованных переменных, называемом базой MIB, которая поддерживается агентским программным обеспечением на управляемых устройствах.

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

Trap PDU Format

На рис. 58.9 показаны поля модуля PDU Trap протокола SNMP.

1. Каков основной недостаток версий SNMPv3 и SNMPv2, устраненный в SNMPv3?

Литература:

Руководство по технологиям объединенных сетей, 4-е издание. : Пер. с англ. — М.: Издательский дом «Вильяме», 2005. — 1040 с.: ил. – Парал. тит. англ.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100