Безопасность протокола SNMPv3

--> Дата: Фев 18, 2008 1 339

Алексей Бондаренко
photozone@yandex.ru

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

Первая версия протокола SNMP (Simple Network Management Protocol) была предложена еще в 1988 г. для управления сетевым оборудованием и скоро стала стандартом. Позже, в 1993 г., вышел протокол SNMPv2, в котором были исправлены некоторые недостатки SNMPv1. Во второй версии протокола были значительно улучшены производительность и безопасность, появились некоторые новые типы данных и стали поддерживаться операции типа «менеджер-менеджеров». Но, несмотря на все изменения, протокол SNMP все еще не годился для выполнения своих титульных функций — управления сетевым оборудованием. Он служил в основном для мониторинга деятельности сети, так как в нем не была предусмотрена аутентификация пользователя, и администратор мог выбирать между двумя вариантами: или все параметры сетевого окружения доступны всем только для чтения, или любой пользователь может изменять любые параметры без аутентификации. По понятным причинам выбирали всегда первый вариант.

Казалось бы, вышедшая в декабре 1997 г. версия протокола SNMPv3 должна была решить все проблемы, но это оказалось не совсем так. Существует ряд затруднений при использовании SNMPv3 в крупных сетях. Одно из них — отсутствие возможности первоначально задавать идентификатор и пароль пользователя. В результате идентификатор и пароль приходится заводить вручную через командную строку.

На данный момент все крупные производители платформ сетевого управления поддерживают протокол SNMPv3. Среди них HP OpenView, IBM Tivoli, CA Unicenter и многие другие. Все они хранят идентификаторы и пароли в собственных базах данных.

Работа SNMP MIB

Всю необходимую информацию протокол SNMP получает из базы управляющей информации (Management Information Base, MIB). MIB представляет собой базу данных стандартизованной структуры. Она имеет древовидную структуру (рис. 1), а все переменные классифицированы по тематике. Каждое поддерево содержит определенную тематическую подгруппу переменных. Наиболее важные компоненты, отвечающие за работу сетевых узлов, объединены в подгруппе MIB-II.

Рис. 1. Структура дерева MIB.

Существуют два типа MIB: стандартные и фирменные. Стандартные MIB определяются Комиссией по деятельности в Интернете (Internet Activity Board, IAB), а фирменные — производителем устройства. В таблице приведен список наиболее распространенных стандартов баз управляющей информации.

Стандарты баз управляющей информации MIB

База	Назначение
MIB-II	Задает множество объектов, которые могут использоваться для управления сетевыми интерфейсами
MIB повторителя	Включена в подмножество MIB-II. Устанавливает объекты, которые можно использовать для управления повторителем
MIB моста	Включена в подмножество MIB-II. Задает объекты данных, которые можно использовать для управления мостом
RMON MIB	Указывает объекты данных, которые можно использовать для управления сетью в целом при помощи протокола RMON

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

В MIB каждый объект имеет имя и тип. Имя объекта характеризует его положение в дереве MIB. При этом имя дочернего узла включает в себя имя родительского узла и задается целым числом.

Для более подробного ознакомления со структурой и переменными MIB можно обратиться к стандартам RFC 1213, RFC 1271, RFC 1493, RFC 1516*.

* Описание стандартов RFC см. http://www.ietf.org/rfc.html.

Отличия SNMPv3

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

С выходом SNMPv3 пользователям стали доступны новые службы, такие, как ограничение доступа, защита данных и аутентификация пользователя (см. стандарты RFC 2271-2275).

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

При создании новой версии разработчики руководствовались следующими принципами:

требуется улучшить безопасность протокола (особенно для операций типа Set);
настройки параметров безопасности SNMPv3 должны быть максимально простыми;
SNMPv3 должен иметь возможность дальнейшего развития и расширения;
протокол должен остаться простым и понятным.

В SNMPv3 уже не применяются термины «агент» и «менеджер», теперь их называют «сущностями». Как и раньше, одна сущность находится на управляемом устройстве, а вторая занимается опросом приложений.

У сущностей-агентов и сущностей-менеджеров теперь есть ядро, которое выполняет четыре основные функции (рис. 2): это функции диспетчера, обработка сообщений, функции безопасности и контроль доступа.

Рис. 2. Схема работы ядра SNMPv3.

Диспетчер — это простая система управления входящим и исходящим трафиком.
Для каждого исходящего блока данных PDU он определяет необходимый тип обработки
(SNMPv1, SNMPv2, SNMPv3) и передает блок данных соответствующему модулю в системе
обработки сообщений. После того как система обработки сообщений вернет сообщение,
которое содержит этот блок данных, Диспетчер отправит его на транспортный уровень
для последующей передачи. Для входящих сообщений Диспетчер проводит обратную
операцию.

Система обработки сообщений получает от Диспетчера блоки данных PDU,
добавляет к ним соответствующий заголовок и возвращает их обратно Диспетчеру.

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

Система контроля доступа управляет службами аутентификации для контроля
доступа к MIB, исходя из содержимого блоков данных PDU. Теоретически система
контроля доступа может работать с самыми разными моделями контроля доступа,
но на данный момент в RFC 2275 описана только одна модель — VACM (View-Based
Access Control Model).

Основные методы SNMP

Методы протокола SNMP кратко описаны ниже. Основные из них (Set, Get, GetNext, GetResponse, Trap) появились еще в версии SNMPv1; в версиях v2 и v3 они были дополнены методами GetBulk, Inform, Report.

Get — используется менеджером для получения данных из MIB. Размер сообщения
ограничен возможностями агента.
GetNext — позволяет последовательно выполнить набор команд и получить набор
значений из MIB.
GetBulk — используется менеджером для получения сразу большого количества
данных из MIB. Размер отсылаемого агентом сообщения не ограничен.
GetResponse — с его помощью агент SNMP передает менеджеру результаты операций
Get и GetNext.
Set — используется менеджером для установки значений в MIB агента.
Trap — используется агентом, чтобы послать сигнал менеджеру.
Inform — используется менеджером, чтобы отослать сигнал другому менеджеру
и запросить ответ.

При помощи этих команд и стандартной базы MIB можно получить самую разнообразную информацию, например, о числе пакетов, принятых и отправленных по протоколам TCP, IP, UDP или ICMP. Можно также узнать количество ошибок, которые были обнаружены во время отправки или получения пакетов.

Безопасность в SNMPv3

При разработке SNMPv3 немало внимания было уделено безопасности протокола. Теперь в нем поддерживается модель USM, ориентированная на пользователя (User-Based Security Model, см. RFC 3414), благодаря которой стало возможно добавлять модули аутентификации и шифрования без смены базовой архитектуры. Модель USM включает в себя модуль аутентификации, модуль шифрования и модуль контроля времени. Первые два занимаются защитой данных, а модуль контроля времени синхронизирует время между сущностями SNMP.

Основные проблемы, которые необходимо было решить при помощи модели USM, таковы:

изменение данных сущностями, не прошедшими аутентификацию;
возможность отложить какие-либо действия на неопределенное время или повторять одни и те же действия с произвольными интервалами;
блокировка обмена данными между сущностями;
перехват трафика при передаче между сущностями;
«маскарад» (сущность, не прошедшая аутентификацию, могла «прикинуться» другой, прошедшей аутентификацию).

Проблемы решили следующим образом: для каждого сетевого устройства пароль преобразуется в некоторый уникальный ключ. Это обеспечивает дополнительную безопасность, поскольку даже в том случае, если ключ будет перехвачен, злоумышленник получит доступ только к одному сетевому устройству. Для шифрования пароля используется алгоритм MD5, но разработчики, видимо, решили, что это не обеспечит достаточной сохранности пароля, и потому блок PDU дважды хэшируется при помощи двух разных ключей, которые, в свою очередь, генерируются из закрытого ключа. Далее первые 12 октетов используются как код аутентификации сообщения, который добавляется к сообщению. Все то же самое приходится выполнять на другой стороне, но в обратном порядке.

Несмотря на всю сложность и энергоемкость процесса передачи данных между сущностями SNMP, по мнению разработчиков, алгоритм шифрования DES на самом деле не обеспечивает достаточной защиты информации, поэтому в дальнейшем предполагается использовать другие алгоритмы, например, Диффи — Хеллмана (Diffie-Hellman) или CBC-AES-128.

В версии SNMPv3 разработчики предусмотрели три уровня безопасности:

noAuthNoPriv — пароли передаются в открытом виде, конфиденциальность данных отсутствует;
authNoPriv — аутентификация без конфиденциальности;
authPriv — аутентификация и шифрование, максимальный уровень защищенности.

Большинство пользователей предпочитает второй уровень безопасности, так как степень защищенности в нем уже достаточно высока, а сетевые устройства не перегружаются шифрованием данных. Как правило, пользователи сначала выбирают второй уровень и лишь немногие из них потом начинают использовать третий.

Уже закончена разработка новой спецификации Data Over Cable Service Interface Specification (см. стандарт RFC 3256), а для управления ключами многие пользователи уже используют алгоритмы Диффи — Хеллмана и Kerberos вместо DES. По-видимому, это означает, что вскоре можно ожидать выхода новой версии протокола SNMP.