книги / Современные принципы и технологии управления инфокоммуникационными сетями.-1

Базовые правила кодирования BER

Для передачи блоков данных протокола SNMP через нижележащие уровни модели OSI используется представление информации в шестнадцатеричных кодах. Кодирование выполняется в соответствии с базовыми правилами кодирования (Basic Encoding Rules – BER, ISO 8825 или X.690). BER обеспечивают однознач-

ное представление данных для программ, написанных на разных языках и выполняющихся на различных операционных системах, как показано на рис. 4.12.

Рис. 4.12. Использование правил кодирования BER

В соответствии с BER, передаваемые данные кодируются в формате TLV ([Type], [Length], [Value] – [Тип передаваемых дан-

ных], [Длина передаваемых данных], [Передаваемые данные]). Причем поле передаваемых данных может включать в себя рекурсивно данные также в формате TLV, как показано на рис. 4.13.

131

Поле Type кодируется одним байтом и имеет следующую структуру:

Биты 7 и 6 (Class) используются для кодирования класса тега

ASN.1:

Бит 5 имеет значение 0 для простых типов ASN.1 и 1 для производных типов.

Биты 4-0 используются для кодирования тегов типов данных. Кодирование выполняется в шестнадцатеричном формате. Ниже представлены коды тегов некоторых типов данных ASN.1:

Поле Length содержит длину передаваемых данных и кодируется следующим образом:

132

Если длина данных меньше 128 байт (значение бита 7 равно 0), то значение длины указывается в битах 6-0. Если длина данных превышает 128 байт (значение бита 7 равно 1), то поле Length будет занимать больше одного байта. Если длина данных неизвестна, то все полеLength заполняется нулями.

Например, переменная Name типа VisibleString, имеющая значение “John”, будет закодирована шестью байтами:

Первый байт содержит значение кода типа данных VisibleString (1A), второй байт содержит длину данных (4 байта), байты 3-6 содержат значения четырех символов John.

Рассмотрим кодирование по правилам BER пакета протокола SNMP, содержащего запрос get-request о значении объекта

SysDescr (объектный идентификатор 1.3.6.1.2.1.1.1).

133

Сообщение начинается с кода 30 (все коды шестнадцатеричные), который соответствует указанию на тип данных SEQUENCE (сообщение представляет собой последовательность). Общая длина последовательности указывается в следующем байте (41 байт). Далее следует целое число длиной 1 байт – это версия протокола SNMP (в данном случае 0 обозначает версию № 1 протокола SNMP, значение 1 означало бы SNMP v.2). Поле community имеет тип OCTET STRING (строка символов) длиной в 6 байт со значением public. Остальную часть сообщения составляет блок данных GetRequest-PDU. То, что это операция Get-request, говорит код А0 (это значение определено в протоколе SNMP, а не в нотации ASN.1), а общая длина блока данных – 28 байт. В соответствии со структурой блока Getrequest-PDU, далее идет идентификатор запроса (он определен как целое 4-байтовое число). Затем в блоке следуют два однобайтовых целых числа статуса и индекса ошибки, которые в запросе установлены в 0. И наконец, завершает сообщение список объектов, состоящий из одной пары – имени 1.3.6.1.2.1.1.1.0 и значения null. Значение null используется потому, что это запрос значения переменной. В ответе в этом поле будет значение запрашиваемой переменной.

4.3.2. SNMPv2

Структура управления второй версии протокола SNMP описана в документах IETF RFC 1902-1907. С точки зрения языка описания структура данных в SNMPv2 не претерпела изменений, однако состав объектов значительно расширился. В SNMPv2 вошло все дерево MIB-II, а также добавлены объекты, описывающие обмен данными по протоколу SNMP, введены описания посредников, станций управления, средств мониторинга и ограничения доступа.

134

В SNMPv2 появились два новых пакета: запрос

GetBulkRequest и сообщение InformRequest. Также ответ GetResponse-PDU был переименован в Response-PDU.

Запрос GetBulk введен с целью снижения нагрузки на сеть при опросе табличных переменных. В запросе указываются две группы объектов. В первой группе перечисляются скалярные переменные, а во второй группе – табличные переменные и число экземпляров этих переменных. Ниже представлено описание блока данных запроса GetBulk:

BulkPDU:: = SEQUENCE {

Поле идентификатора запроса (request-id) и список связанных переменных variable-bindings имеют такую же смысловую нагрузку, как и в других пакетах. Далее следует указание для двух групп объектов:

non-repeaters – число переменных, выбираемых один раз; max-repetitions – число экземпляров запрашиваемых пере-

менных.

Например, в базе агента есть две скалярные переменные X, Y и таблица с двумя столбцами А и В (экземпляры табличных переменных а1..а4, b1..b4).

От менеджера приходит запрос get-bulk-request [ID,2,4,X,Y,A,B] – в параметрах указывается, что запрашиваются две неповторяющиеся скалярные переменные (параметр nonrepeaters=2), четыре экземпляра повторяющихся табличных переменных (параметр max-repetitions=4), идентификаторы скалярных переменных X,Y и идентификаторы переменных-столбцов A

иB таблицы.

Вответ от агента приходит пакет, содержащий значения скалярных переменных x, y, а также по четыре экземпляра табличных переменных: get-bulk-response [ID,x,y,a1,a2,a3,a4,b1,b2,b3,b4].

135

Запрос GetBulk позволяет снизить объем передаваемой по сети информации.

Сообщение Inform введено с целью обеспечения передачи информации от менеджера к менеджеру. При этом получение пакета должно быть подтверждено менеджером-получателем. Формат блока данных InformRequest полностью соответствует формату других блоков данных протокола SNMP (кроме блока данных get-bulk). В сообщении InformRequest могут быть переданы значения переменных. В ответ должно быть получено сообщение Response, по содержанию полностью повторяющее InformRequest.

Кроме добавления новых команд, изменения коснулись уведомления Trap-PDU. Для уведомления стали использовать точно такой же блок данных, как и для других блоков данных (get, get-next и т.п.). Новый блок данных уведомления получил имя SNMPv2- Trap-PDU. В блоке данных пакета SNMPv2-Trap-PDU первыми двумя переменными должны быть переменные sysUpTime (время с моментастарта системы) иsnmpTrapOID (OID уведомления).

Рис. 4.14. Последовательности сообщений протокола SNMPv2

Таким образом, блоки данных второй версии протокола SNMP можно представить в последовательностях сообщений, показанных на рис. 4.14.

136

4.3.3. SNMPv3

Недостатки второй версии протокола SNMP, связанные с плохой безопасностью, были устранены в третьей версии протокола, которая на данный момент является стандартом Internet. Спецификации третьей версии протокола – SNMPv3 утверждены

встандарте IETF STD62 (документы RFC3411-3418), а также

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

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

1)SNMP-машина (ядро);

2)приложения (управляющие сервисы).

SNMP-сущность

Рис. 4.15. Основные компоненты архитектуры SNMP v3

SNMP-машина является обязательным элементом и включает в себя четыре модуля: диспетчер, подсистема обработки сообщений, подсистема безопасности, подсистема контроля доступа.

137

Диспетчер занимается приемом и отправкой SNMPсообщений, взаимодействием с системой обработки сообщений и сущностью транспортного уровня.

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

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

Подсистема контроля доступа позволяет задать правила доступа к отдельным веткам MIB.

Приложения (управляющие сервисы) SNMP-сущности являются опциональными и их состав определяется конкретной реализацией SNMP-сущности. Определены следующие приложения:

Генератор команд – мониторирует, обрабатывает данные управления и формирует команды (set, get и т.п.).

Обработчик команд – принимает команды, обеспечивает доступ к данным управления и формирует ответные сообщения.

Генератор уведомлений – при возникновении событий в системе формирует асинхронные сообщения (trap, inform).

Получатель уведомлений – обрабатывает входящие асинхронные сообщения, формирует отклик на сообщение inform.

Прокси перенаправление – переадресует сообщения к запрашивающему в случае необходимости.

Более подробно взаимодействие подсистем и приложений будет рассмотрено ниже.

Безопасность в третьей версии обеспечивается за счет использования двух моделей:

1.Модель безопасности, ориентированная на пользователя, –

модель USM (User-based Security Model, RFC 34), обеспечивает защиту сообщений.

2.Модель управления доступом на основе представления – модель VACM (View-Based Access Control Model, RFC 3415),

обеспечивает управление доступом для пользователей.

Модель USM состоит из трех модулей: аутентификации, шифрования и контроля времени. Основные угрозы, которые должна предотвращать модель USM:

138

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

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

Прослушивание SNMP-сообщений (перехват трафика).

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

иидентификаторы запросов.

Модель USM не защищает от атаки, которая вызывает отказ в обслуживании, а также не передусмотрена защита от анализа трафика.

Для аутентификации предлагается использовать протоколы аутентификации HMAC-MD5-96 или HMAC-SHA-96. Данные шифруются симметричным протоколом шифрования CBC-DES.

Предусмотрены три уровня безопасности:

1)noAuthNoPriv – меры безопасности аналогичны первой версии SNMP (пароли передаются в открытом виде, конфиденциальность данных отсутствует);

2)authNoPriv – реализуется процедура аутентификации, шифрование не используется;

3)authPriv – максимальный уровень безопасности, используются процедура аутентификация и шифрование.

Уровень безопасности задается администратором сети при настройке параметров протокола для менеджера и агента сетевого оборудования.

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

139

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

ФорматсообщенияпротоколаSNMPv3 представленнарис. 4.16. Структура сообщения делится на четыре области. В первой области располагается поле msgVersion, в котором указывается

версия протокола (для SNMPv3 = 3).

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

msgID – идентификатор сообщения, используемый SNMPсущностями для установления соответствия между запросом и ответом, принимает значение от 0 до 231–1.

msgMaxSize – максимальный размер сообщения в байтах, принимает значение от 484 до 231–1.

msgFlags – байт, содержащий три флага-бита: reportableFlag, privFlag, authFlag. Бит reportableFlag=1 показыва-

ет, что сообщение содержит запрос (Get, Set и т.п.), иначе – сообщение содержит уведомление или ответ на запрос. Биты privFlag и authFlag показывают использование шифрования и аутентификации соответственно. Разрешены любые значения флагов кроме комбинации privFlag=1 и authFlag=0 (шифрование без аутентификации).

msgSecurityModel – идентификатор модели безопасности, принимает значение от 0 до 231–1. Зарезервированы значения 1 –

для SNMPv1, 2 – для SNMPv2 и 3 – для SNMPv3.

Третья область содержит параметры безопасности msgSecurityParameters. В случае использования модели безопасности USM эта область содержит информацию по конфигурированию параметров безопасности участников обмена данными:

140