Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Так ли прост SNMPv3?

Брюс Бордман

Как ни странно, но то, что в сетевых технологиях когда-то было названо простым, сегодня имеет довольно сложное устройство. Так произошло, например, с протоколом SNMP (Simple Network Management Protocol). Однако именно благодаря его новой модульной архитектуре, средствам управления безопасностью и способности шифровать управляющий трафик, появившимся в третьей версии данного протокола, область его применения значительно расширилась. При этом он обеспечивает обратную совместимость с предыдущими версиями, т. е. может управлять устройствами, поддерживающими SNMP версий 1 и 2.

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

Тем не менее несовершенства версии 3 не помешали нескольким основным поставщикам включить в свои продукты поддержку этого протокола. Все ведущие поставщики маршрутизаторов и коммутаторов уже не один год поддерживают SNMP. Так, например, Cisco обеспечивает полную поддержку SNMPv3 в своей операционной системе IOS, начиная с ее версии 12.0. Это же относится и к производителям сетевых платформ управления. Программные системы Spectrum компании Aprisma, Patrol компании BMC Software, Unicenter компании Computer Associates, OpenView компании Hewlett-Packard, Tivoli компании IBM и InCharge компании Smarts — все они поддерживают SNMPv3. И даже ПО SNMPc компании Castle Rock Computing и MIB Browser компании MG-Soft включают поддержку SNMPv3.

Перечисленные пакеты управления хранят идентификаторы и пароли пользователей в своих базах данных, что позволяет им защищенным образом обмениваться информацией и управлять устройством, поддерживающим SNMPv3. Версия 3 SNMP потихоньку завоевывает поддержку и со стороны поставщиков услуг широкополосных кабельных сетей: Cox Cable и Time Warner, в частности, используют SNMPv3 для защищенного управления своими кабельными модемны-ми сетями, хотя им и пришлось несколько расширить его спецификацию более мощными алгоритмами шифрования.

SNMP-сущности и исполнительное ядро

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

Это хорошая новость для сетевых администраторов — ведь им не придется полностью переписывать имеющееся у вас ПО SNMP, и новое ПО версии 3 сможет работать вместе с ПО предыдущих версий. Хотя первая и вторая версии протокола полностью полагаются на простые строковые пароли доступа (community strings) и не могут использовать средства аутентификации и шифрования, имеющиеся в версии 3, вы все же сумеете управлять устройствами, поддерживающими первые версии средствами SNMPv3. Ну а поставщики смогут повторно использовать программный код и модернизировать наборы функций, не прибегая к полной переделке своего управляющего ПО.

В SNMPv3 не применяются традиционные для SNMP термины “агент” и “менеджер”. На языке версии 3 устройства и компоненты управления называются “сущностями” (entities). Одна сущность (прежде известная как агент) находится на маршрутизаторе, а другая (в прошлом менеджер) — занимается опросом приложений. Термины, может, и изменились, но вот функции остались прежними. Каждая сущность имеет SNMP-ядро и приложение (см. рисунок). Ядро SNMP составляют четыре функции: контроль доступа, безопасность, обработка сообщений и диспетчер. В модули процессора сообщений и диспетчера включены также функции версий SNMPv1 и 2, в том числе для обработки команд set и get, и для форматирования блоков данных SNMP или PDU (protocol data unit).

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

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

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

Чувство защищенности

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

Впрочем, перед SNMPv3 совсем не ставится задача заткнуть все “дыры” безопасности в сети, он, например, не должен предотвращать атаки типа “отказ в обслуживании”. Причем SNMPv3 спроектирован как вещь самодостаточная, т. е. в своей работе он не зависит от прочих сетевых служб, таких, как службы времени NTP или управление ключами. Его целью является защита управляющего протокола, а не среды управления или всей сети.

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

Функция управления ключами в USM-модели преобразует пароль пользователя в ключ, уникальный для каждой SNMP-сущности. Таким образом, даже если этот ключ будет “засвечен” или перехвачен, опасность грозит только тому устройству, которому он соответствует. В USM-модели применен алгоритм MD5; впрочем, SHA и другие алгоритмы хэширования тоже работают с SNMPv3. В качестве меры предосторожности пароль по сети не пересылается. Вместо этого PDU-блок дважды подвергается хэшированию с использованием двух ключей, сгенерированных из закрытого ключа, затем первые 12 октетов выступают в роли кода аутентификации сообщения (Message Authentication Code — MAC), который добавляется к этому сообщению. Такой же процесс, но в обратном порядке происходит на другом конце. Скоро этот трудоемкий способ управления ключами будет заменен более понятным методом обмена ключами по алгоритму Диффи—Хиллмана (Diffie-Hillman).

В SNMPv3 определено три уровня аутентификации и конфиденциальности. Первый — это просто отсутствие конфиденциальности, обозначается “noAuthNoPriv”. Он аналогичен строковым паролям доступа, передаваемым открытым текстом, которые применяются в версии 1 и 2, и используется в период отладки или когда SNMP-сущности находятся в защищенной среде. Второй уровень — это аутентификация без конфиденциальности, или “authNoPriv”. Многие поставщики систем управления говорят, что их покупатели склонны выбирать этот более простой уровень безопасности, когда только начинают развертывать SNMPv3. Третий уровень — “authPriv” — это не только аутентификация, но и шифрование SNMP-данных. Однако многие поставщики и корпоративные пользователи считают, что он слишком нагружает сетевые устройства.

При всем при том популярный алгоритм шифрования DES, используемый в версии 3, в действительности не обеспечивает приемлемой защиты конфиденциальности. Сейчас прорабатываются другие алгоритмы, с более сильной защитой, в том числе CBC-AES-128 (см. http://www.ietf.org/internet-drafts/draft-blumenthal-aes-usm-06.txt).

В SNMPv3 также входит модель разделения доступа на базе представлений (VACM — View-based Access-Control Model), позволяющая ограничить доступ к переменным MIB (базы управляющей информации). В модели VACM “представление” (view) определяет, какая часть базы MIB доступна, и устанавливает связь между пользователями и этим представлением. Механизмы VACM требуют, чтобы представление и группа создавались на каждом сетевом устройстве, причем представление определяет доступную часть MIB, а группа — привязывает входящих в нее пользователей к этому представлению.

Первые приверженцы SNMPv3, например операторы кабельных сетей, уже работают над тем, как избавиться от недостатков SNMPv3. Так, ими уже разработана спецификация Data Over Cable Service Interface Specification, при этом для управления обменом ключами сервис-провайдеры вместо громоздкой USM-модели применяют алгоритмы Диффи—Хиллмана или Kerberos. Они также предпочитают использовать более мощный метод шифрования — AES-128 вместо DES..





  
1 '2004
СОДЕРЖАНИЕ

электронная Россия

• Инфокоммуникации земли сибирской

бизнес

• Закон "О связи" принят. Что дальше?

• Open Source на рабочем столе

инфраструктура

• Развитие БЛВС

• Тестируем инфраструктурное оборудование для БЛВС

информационные системы

• Второй фронт

• Так ли прост SNMPv3

• Как не попасться на уловки фирм-производителей

сети связи

• Азы телефонии для менеджеров ИТ

• IP-телефония: в поисках приложений

• SBC на границе

кабельные системы

• Средства управления коммутационными шнурами

• Оговаривайте тестирование шнуров

защита данных

• Тестируем системы предотвращения вторжений уровня сети

новые продукты

• 64-битовый сервер Depo Iron 6000R1S


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх