24. Управление элементами телекоммуникационных сетей с помощью протоколов snmp и cmip

, коммерческими и исследовательскими объединенными сетями являются системы управления, построенные на основе простого протокола сетевого управления SNMP.

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

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

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

Рис. 5.11. SNMP-модель управления сетью

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

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

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

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

В настоящее время существуют две отработанные версии протокола SNMP: собственно простой протоков управления сетью (иногда называемый первой версией) и вторая версия SNMP v.2. Обe версии имеют много общего, однако SNMP v.2 имеет некоторые преимущества, например, в области информационной безопасности. Но, соответственно, вторая версия более сложная и дорогая. Стандартизация версии SNMP v.3 в целом завершена, но версия 3 не нашла еще широкого применения. В настоящем параграфе в качестве основной версии, рассматривается про стой протокол управления сетью (первая версия) и даются особенности второй и третьей версий.

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

SNMP часто рассматривают только как решение для управления сетями TCP/IP. Хотя он чаще всего и работает над UDP, протокол SNMP может опираться на транспортные сетевые протоколы стека ОSI - ТР0, ТР4, протоколы TCP, а также на протоколы МАС-уровня. Растет поддержка протокола SNMP и в других транспортных средах. Поэтому в настоящее время простой протокол управления сетью поддерживают многие сети.

Важным при описании управления сетью с помощью протокола SNMP является его взаимодействие с объектами управления. Имеются некоторые отличия понятия «управляемый объект» в протоколах CMIP (модели ВОС) и SNMP. Управляемый объект в CMIP и вообще в модели ВОС - это законченное описание управляемого ресурса; объектом в SNMP может быть некоторый атрибут сетевого устройства. То есть, в контексте управления сетью объектом называется некоторое численное значение, характеризующее тот или иной аспект управляемого устройства. Для описания объекта необходимо описать все связанные с ним данные, которые доступны системе управления.

Формальное описание объектов независимо от техники представления данных, используемой управляемыми устройствами, осуществляется с помощью языка ASN.1. Напомним, что это формальный язык, определяющий синтаксис и форматы пакетов, действующих между управляемыми устройствами и управляющими приложениями. ASN.1 служит для установления однозначного соответствия между терминами, взятыми из стандартов, предназначенных для человеческого использования, и теми данными, которые передаются в коммуникационных протоколах аппаратурой. Достигаемая однозначность очень важна для гетерогенных сред.

Все данные об управляемых объектах содержатся в информационной базе управления MIB SNMP, которая представляет собой иерархически организованную систему объектов. Каждый объект MIB является одним из множества параметров управляемого устройства. Объекты могут быть двух типов. Скалярный объект определяет единичный параметр. Табличный объект описывает множество параметров, объединенных в таблицу. Логическую структуру MIB можно представить в виде абстрактного дерева, листьями которого являются отдельные информационные элементы. Древовидная структура информационной базы управления позволяет разбить все объекты, находящиеся в базе, на группы (ветви). Каждый объект имеет идентификатор, однозначно определяющий его положение в иерархии. Символьный идентификатор объекта записывается в виде последовательности имен ветвей. Числовой идентификатор записывается в виде последовательности номеров ветвей, разделенных точкой, начиная от корня иерархии.

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

На сегодня существуют два основных стандарта на базы данных управляющей информации для протокола SNMP - стандарты MIB I и MIB II. Информационная база MIB I разрабатывалась с ориентацией на управление маршрутизаторами, поддерживающими протоколы стека TCP/IР, причем в ней предусматривались только операции чтения значений переменных. Версия MIB I определяет 114 объектов, которые подразделяются на 8 групп. Эта база была существенно расширена до 185 объектов, а число групп увеличено до 10 в версии MIB II с предоставлением возможности проведения операций изменения и установки значений управляемого объекта (операций управления). Информационная база управления MIB II изображенная в виде абстрактного дерева, «ветвями» которого являются отдельные классы управляемых объектов (древовидная структура MIB II SNMP) приведена на рис. 5.12.

Рис. 5.12 древовидная структура MIB II SNMP

Каждая группа на рис. 5.12 в MIB представлена с помощью одной или нескольких таблиц и может включать скалярные величины, соответствующие конкретному значению рабочей характеристики управляемого объекта. Для примера рассмотрим две первые группы древовидной структуры MIB II SNMP. Первая группа «Система» содержит объекты, которые могут предоставить общесистемную информацию об устройстве и позволяют описать все общие данные о нем, например, тип устройства, наименование поставщика, время непрерывной работы, время последнего включения/активизации работы и др.

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

В целом стандартная MIB и SNMP включает различные объекты, позволяющие измерять и контролировать функционирование протоколов IР, ТСР, UDP, ICMP, EGP, a также IP-маршруты, ТСР-соединения, все интерфейсы устройства и давать общее описание устройства.

Использование в составе информационной базы MIB только стандартных объектов в соответствии с RFC 1907 не позволяет включать в систему управления сетью с протоколом SNMP аппаратуру, объекты в которой не соответствуют этому стандарту. Это в частности относится к аппаратуре многих фирм-производителей. Для разрешения этого конфликта MIB может быть модернизирована добавлением новых ветвей к своей древовидной структуре. Все объекты, которые фирма желает сделать доступными протоколу SNMP, описываются в ветвях соответствующей фирмы. Новые ветви вносятся производителями в частном порядке, но получив широкое распространение, они могут быть стандартизированы. Однако, огромное число разновидностей расширения MIB от сотен различных производителей привело к тому, что многие переменные в базах MIB оказались либо избыточными, либо частично дублирующими друг друга. Попытки стандартизировать общие типы данных сталкиваются с проблемой их корректной интерпретации и увязывания между собой больших объемов специфичной для каждого устройства информации.

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

– операция Get Request (Запрос, Получить) используется менеджером для доступа к агенту и получения от него (из MIB) значений какого-либо управляемого объекта по его имени;

– операция Get-Next Request (Запрос, Получить Следующее) используется менеджером для извлечения значений следующего по порядку управляемого объекта (без указания его имени) при последовательном просмотре таблицы объектов в дереве MIB;

– операция Set Request (Запрос, Установить) используется менеджером для изменения значения какого-либо управляемого объекта. С помощью этой операции происходит управление устройством. Агент должен понимать смысл значений объекта, который используется для управления устройством, и на основании этих значений объекта выполнять реальное управляющее воздействие:

– операция Get Response (Ответ, Получить). Эта операция является ответом на любой из трех предыдущих запросов. В ответе содержатся идентификаторы для обеспечения информации о статусе ответа (ошибки кода, ошибки состояния, список дополнительной информации и др.).

– операция Trap (Прерывание, Реакция на событие). С помощью данной операции сетевые устройства могут сообщать менеджеру (администратору сети) о проблемах, возникающих в данном устройстве вне режима опроса его. Менеджер может быть запрограммирован так, чтобы периодически посылать сообщения управляемым устройствам через определенные интервалы, которые могут изменяться (управляемое прерывание опросов) и устанавливаются через MIB SNMP.

Любое сообщение SNMP состоит из трех основных частей: идентификатора версии SNMP, идентификатора (строки) общности и протокольного блока данных (PDU). Строка общности используется для группирования устройств, управляемых определенным менеджером. Эта строка передается по сети в открытой форме в сообщении SMMP и служит основой для деления агентов и менеджеров на «сообщества», так что агент взаимодействует только с теми менеджерами, которые указывают ту же строку, что и строка, хранящаяся в памяти агента. Третья составная часть сообщения включает область данных, в которой собственно и содержатся описанные выше операции (команды) управления, имена объектов и их значения. Каждой перечисленной операции управления соответствует блок данных определенного формата. Все поля сообщений описаны в нотации абстрактного синтаксиса ASN.1.

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

Несмотря на все достоинства исходной версии протокола SNMP, как основы построения системы сетевого управления, его самый большой недостаток весьма слабая защищенность. Имеющиеся в нем ограничения доступа лиц к сети, особенно к операции управления переменными (операция Set) явно недостаточны. Используемый здесь механизм ограничения доступа - это значение строки общности (Community) в пакете SNMP. Однако, вследствие того, что протокол предназначен для передачи управляющего сообщения через сеть, строка «общности» незашифрованна и передается открыто. Поэтому имеется потенциальная возможность подделки управляющего воздействия. Если какой-либо злоумышленник имеет физический доступ к сети и вооружится анализатором протоколов, он сможет, используя протокол $NMP, получить полную топологию и конфигурацию сети. Более того, зная строку «общности», при помощи операции Set он может захватить контроль над любыми управляемыми объектами. Таким образом, хотя протокол SNMP является фундаментом систем управления многими современными сетями, он имеет существенный недостаток - в протоколе отсутствует эффективная модель безопасности, а точнее говоря имеющаяся в нем безопасность весьма условна.

Правда, современные SNMP-агенты позволяют создавать списки доступа, основанные на IP-адресах, чтобы в дополнении к строкам «общности» усилить ограничения по безопасности.

В 1994 году была стандартизирована вторая версия протокола SNMP – SNMP v.2, которая предоставляет некоторые преимущества, особенно дополнительные операционные возможности протокола и в которой сделана попытка решить проблему безопасности.

К улучшению операционных возможностей простого протокола управления сетью можно отнести следующие изменения, внесенные в протокол SNMP v.2. Протокол SNMP v.2 может координировать действия многих менеджеров, предотвращая их одновременный доступ к одному и тому же агенту. Операция Trap в этом протоколе в отличие от первой версии получает подтверждение, что посланное сообщение было принято правильно. В SNMP v.2 протокольный блок данных операции Trap имеет тот же формат, что и другие PDU. Поэтому для всех перечисленных ранее операций при кодировании и декодировании данных используются одни и те же программные алгоритмы. Другое отличие SNMP v.2 от SNMP состоит во введении операции GetBulk, которая позволяет одному сообщению SNMP v.2 обращаться к множеству объектов в MIB. Так для запроса большого объема данных от SNMP-агента оператор GetBulk объединяет несколько операторов Get и GetNext в один пакет, уменьшая тем самым избыточную сетевую нагрузку. Кроме того, SNMP v.2 позволяет менеджерам взаимодействовать друг с другом, в то время как в первой версии возможно только взаимодействие менеджер-агент.

В целях усовершенствования модели безопасности в SNMP v.2 включено предоставление услуги идентификации, которые позволяют получателю сообщения подтвердить подлинность того, что отправитель сообщения действительно является источником отправления. Эта операция осуществляется с помощью шифрования данных. Кроме того, во второй версии протокола по сравнению с первой усовершенствовано управление доступом. Однако те изменения, которые были внесены в протокол SNMP v.2 в области механизмов защиты не смогли решить проблему безопасности простого протокола управления сетью.

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

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

обеспечение масштабирования, т. е. поддержания конфигурации сети произвольного масштаба и состава;

поддержка режима распределенной обработки данных;

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

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

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

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

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

Зарегистрировавшемуся один раз пользователю, модель безопасности позволяет в дальнейшем осуществлять кодированную передачу информации, используя стандарт шифрования данных DES. Применяемый метод аутентификации пакетов гарантирует проверку полномочий пользователя, выполняет кодирование содержимого пакета и создает уникальную временную метку для предотвращения попыток перехвата и повторной посылки пакета (так называемой атаки man-in-the-middle). SNMP v.3 определяет также собственный протокол синхронизации времени. Следует заметить, что модель безопасности определяет только функции аутентификации и шифрования.

Правила контроля доступа описывает отдельная модель. В данной модели агент, анализируя имя пользователя, обратившегося к нему с запросом, принимает решение, предоставлять ему право на просмотр и изменение объектов из базы данных MIB или нет. Хотя реальный контроль доступа выполняется на каждом SNMP-агенте, управление политикой представления прав доступа осуществляется в центре управления сетью обычно с помощью того же сервиса, который управляет именами пользователей и ключами модели безопасности. Модель контроля доступа позволяет администраторам определять, что именно в объектах MIB пользователи могут просматривать и изменять. Уровни контроля доступа реализуются в приложении управления политикой безопасности, в котором пользователи разбиты на различные логические группы с правами доступа к определенным уровням. С помощью этого приложения можно определять системную политику для целых списков контроля доступа, которые наряду со списками модели безопасности могут автоматически распространяться на все устройства через SNMP.

Модели безопасности и контроля доступа положены в основу построения третьей версии протокола SNMP.

Основные компоненты архитектуры SNMP v.3 приведены на рис. 5.13.

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

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

Рис. 5.13 Основные компоненты архитектуры SNMP v.3

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

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

Разработанная модель безопасности протокола SNМР v.З и реализованная в машинах SNMP агентов и менеджеров протокола SNMP версии 3 позволяет поддерживать безопасность системы управления в настоящее время и в то же время оставляет возможность для новых усовершенствований системы безопасности (таких, например, как аутентификация на основе открытых ключей или интеграция со службой справочника) в будущем без нарушения структуры протокола.

Однако, как уже говорилось выше, протокол SNMP v.3 не нашел пока еще широкого применения, не смотря на то, что значительная часть ведущих фирм и операторов, использующих простой протокол управления сетями планировали начать использование протокола SMMP v.3 в первые годы этого столетия. Считалось, что благодаря повышенной защищенности, третья версия протокола SNMP будет широко использоваться в наиболее ответственных правительственных и военных компьютерных сетях, сетях передачи данных, IP-сетях и др. Но на практике, часто вместо применения третьей версии просто добавляют известные средства защиты информации в первую версию SNMP (так, например, сделано в ряде военных сетей МО США). Такое положение по-видимому объясняется значительным усложнением протокола SNMP v.3 по сравнению с другими версиями и недостаточной проработкой сопряжения сетей, использующих протоколы управления различных версий.

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

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

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

Зонды (агенты) RMON MIB более интеллектуальны по сравнению с агентами MIB I или MIB II и, кроме сбора сетевой информации, выполняют значительную часть работы по обработке собранной информации, которую в других технологиях выполняет менеджер. Интеллект зондов (агентов) RMON позволяет им выполнять также простые действия по диагностике неисправностей и предупреждению возможных отказов, отслеживать и анализировать трафик, собирать статистические данные по использованию ресурсов, устанавливать сигналы предупреждения об ошибках, проводить анализ трендов (анализ тренда - определение общего направления изменения характеристики, параметра, свойства, атрибута и т. п.). Так как в RMON зонды (агенты) более самостоятельны и сами выполняют часть необходимых управляющих воздействий на состояние контролируемых ими узлов, то это приводит к значительному уменьшению трафика в сети.

Чтобы выполнить задачу сбора и первичного анализа данных, зонд (агент) должен обладать достаточными вычислительными ресурсами и объемом оперативной памяти. В настоящее время используются зонды трех типов: встроенные, на базе персональных компьютеров и автономные. Встроенные зонды (агенты) в сетевые устройства подобны агентам SNMP, но обладают расширенными возможностями по первичной обработке собираемых данных. Обычно эти зонды имеют сравнительно невысокую производительность и поддерживают не все группы данных RMON:

Зонды на базе компьютера - это просто подключенные к сети связи персональные компьютеры с установленным программным модулем RMON. Такие зонды могут обладать более высокой производительностью, чем встроенные зонды, и поддерживают, как правило, все группы данных RMON. Oни более дорогие, чем встроенные зонды.

Автономные зонды наиболее распространены сейчас, особенно во второй версии RMON, o которой речь будет идти ниже. Они представляют собой процессор, оснащенный достаточным объемом памяти и сетевым адаптером. Программные средства таких зондов обеспечивают достаточно широкие функциональные возможности. Зонды этого типа весьма мобильны, их очень легко подключать к сети и отключать от нее. Мобильность может играть существенную роль в корпоративных сетях небольших и средних размеров. Для примера приведем основные характеристики современных зондов второй версии RMON: число портов 4-6, поддерживаемые интерфейсы - Ethernet, Fast Ethernet, возможность удаленного доступа по протоколам SLIP или РРР, максимальный объем памяти 32-128 Мбайт.

Информацию, собираемую зондами, надо обрабатывать, обобщать и представлять в удобном для пользователя виде. Этим занимаются приложения управления, представляющие собой сложные программы, обеспечивающие просмотр статистики в целом по сети, выявление наиболее загруженных участков, обнаружение основных источников перегрузок. Таким образом, суть технологии RMON состоит в обмене информацией между зондами (агентами) RMON, работающих в различных сетевых устройствах и сегментах сети, и приложениями сетевого управления, размещенными на рабочей станции сетевого администратора. Задача станции сетевого управления состоит в восстановлении, обработке и предоставлении в удобном для оператора виде информации, полученной от зондов (агентов) RMON.

Слежение за различными сетевыми устройствами осуществляется при помощи информационных баз управления RMON MIB, включающих более 200 объектов управления и наблюдения в десяти группах. Первые три группы специфичны для технологии Ethernet. Остальные группы не привязаны к конкретной реализации МАС-уровня. При этом для технологии Token Ring выделена группа 10.

Стандарт RMON определяет следующие 10 групп объектов базы управляющей информации:

1. «Статистика» – обеспечивает выдачу статистической информации об использовании ресурсов каналов и о возникающих ошибках.

2. «История» – выполняет те же функции, что и группа Статистика, дополнительно позволяя анализировать информацию, полученную за определенный временной интервал.

3. «Тревоги» – совместно с группой Событие обеспечивает посылку предупреждающих сообщений при превышении какой-либо величиной определенных для нее пороговых значений.

4. «Хосты» (конечные узлы отправители и получатели информации) - обеспечивает выдачу статистической информации на уровне МАС-адресов узлов.

5. «N самых активных хостов» – выполняет те же функции, что и группа Хосты, дополнительно позволяя зонду формировать отчеты о наиболее активных (по тому или иному параметру) хостах.

6. «Матрица трафика» – обеспечивает выдачу статистической информации для сетевых диалогов на уровне МАС-адресов узлов.

7. «Фильтр» – устанавливает специфические признаки фильтрации пакетов для захвата, совместно с группой Захват пакетов обеспечивает захват пакетов для последующего анализа.

8. «Захват пакетов» – определяет условия начала захвата пакетов, удовлетворяющих критериям фильтра, и числа захватываемых пакетов, совместно с группой фильтр обеспечивает захват пакетов для последующего анализа.

9. «Событие» – работает совместно с группой Тревоги.

10. «Token Ring» – обеспечивает получения отдельного набора статистических данных для сетей Token Ring.

Каждая группа позволяет определять различные характеристики функционирования сети. Например, группа «Матрица трафика» определяет реальный сетевой трафик, который позволяет видеть загрузку сетевых устройств и интенсивность трафика между каждой парой хостов, представленные в виде матрицы. Группа «Фильтр» выделяет наиболее активные узлы, обращающиеся к тому или иному сетевому устройству, а группа «Захват пакетов» обеспечивает отбор пакетов, передаваемых между двумя пользователями, и подсчитывает количество пакетов, переданных между маршрутизаторами, серверами и другими сетевыми устройствами.

Другие характеристики функционирования сети могут быть определены с помощью приложений, находящихся в станции сетевого управления, опирающихся на информацию нескольких групп. Например, картина обмена информацией между пользователями может быть получена с помощью приложения «Матрица сети», опирающегося на информацию групп «Захват пакетов» и «Фильтр». Это приложение размещает пары обменивающихся данными узлов по убыванию их роли в разделении полосы пропускания. Кроме того, это же приложение отражает количество переданных пакетов и байтов от источника к приемнику.

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

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

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

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

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

Использование технологии RMON для планирования конфигурации сети состоит в следующем. Определение реального сетевого трафика осуществляется путем задействования стандартной группы Матрица трафика информационной базы управления RMON MIB. C помощью средств фильтрации выделяются наиболее активные узлы, обращающиеся к каждому серверу, и определяется количество пакетов, принятых и переданных ими. Администратор (оператор) сети проанализировав полученные данные, может определить, где расположить серверы, чтобы в среднем время ответа приложений было минимальным. Подобным образом можно осуществлять переконфигурацию сети (оптимальное размещение серверов) при внедрении новых приложений или выходе из строя отдельных сетевых устройств (элементов) или целых фрагментов сети.

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

Стандарт RMON-2 ввел новые группы объектов управления и наблюдения и с помощью них стандартизировал способ представления информации сетевого и вышележащих уровней. Всего в RMON-2 введено 10 новых групп, имеющих номера с 11-й по 20-ю.

Отметим некоторые наиболее важные функции, которые выполняют новые группы. Это представление описаний всех идентифицируемых протоколов и обеспечение выдачи информации об их использовании, определение соответствия между сетевыми и МАС-адресами, обеспечение выдачи информации о распределении трафика на уровне сетевых адресов и по протоколам и о распределении трафика по диалоговым парам сетевого уровня, включая данные о наиболее активных парах и др. Таким образом, новые группы позволяют получать сведения о распределении трафика на сетевом уровне и об использовании протоколов и приложений как отдельными узлами, так и всей сетью в целом.

Системы RMON-2 могут представлять огромный объем информации, что очень важно для больших распределенных сетей. Например, RMON-2 может собирать общую статистику для каждого сеанса связи сетевого уровня. Кроме того, он способен наблюдать за работой сетевого и более высоких уровней. Информация по протоколам также может быть увязана с каждым сеансом связи сетевого уровня, что позволяет получать ответы на множество вопросов, касающихся картины распределения трафика в сети, в частности, определять какие из протоколов забирают какую полосу пропускания и т.д. и, главное, система RMON-2 позволяет получать точное представление о характере трафика и использовании приложений в распределенной сети.

В заключение следует подчеркнуть, что RMON-2 и RMON логически дополняют друг друга: RMON более эффективен для решения задач по выявлению физических ошибок, сбора статистики по сетевым устройствам, а RMON-2 - для сбора статистики о картине трафика на сетевом и прикладном уровнях.

Прикладной объект системного управления является функциональным блоком, расположенным на верхнем подуровне прикладного уровня. Он обеспечивает обработку информации и предоставление услуг, необходимых для работы управляющих прикладных процессов. Прикладные объекты системного управления имеются во всех системах сети и с целью передачи управляющей информации между системами сети, они обмениваются друг с другом необходимыми сведениями. Эти функции выполняют протокол общей управляющей информации CMIP и сервисный элемент общей управляющей информации СЭОУИ (CMISE – Common Manager Information Service Element). Их работа поддерживается сервисными элементами управления ассоциацией СЭУА (ACSE – Association Control Service Element), удаленных операций СЭУО (ROSE – Remote Operations Service Element) и другими сервисными элементами, которые находятся на нижнем подуровне прикладного уровня.

Протокол CMIP, является базовым протоколом взаимодействия управляющих прикладных процессов и агентов управления - при­кладных процессов управления абонентских систем. Он обеспечивает возможность построения очень мощных в функциональном отноше­нии и легко управляемых агентов управления, которые способны по одной команде выполнить определенный набор действий или одной командой воздействовать на целый ряд агентов управления, входящих выбранную область. Кроме того, агент управления CMIP, может осу­ществлять предварительную фильтрацию сообщений, что облегчает работу управляющих прикладных процессов в административной системе управления сетью. Виды сервиса, предоставляемого управ­ляющим прикладным процессам службой управления сетью, опреде­ляется протоколом CMIS, который включает абстрактную модель сервиса управления и состоит из трех групп: уведомление о событиях, передача информации и управления. Структура управляющей инфор­мации (SMI) определяет синтаксис и семантику информации управле­ния.

Рис.5.5. Модель ВОС управления ТКС (стандарт МОС)

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