Протокол SNMP

Данная статья посвящена протоколу SNMP (Simple Network Management Protocol) - одному из протоколов модели OSI, который практически не был затронут в документации просторов RU-нета. Автор попытался заполнить этот вакуум, предоставив читателю почву для размышлений и самосовершенствования, касательно этого, возможно нового для Вас, вопроса. Этот документ не претендует на звание "документации для разработчика", а просто отражает желание автора, насколько это возможно, осветить аспекты работы с данным протоколом, показать его слабые места, уязвимости в системе "security", цели преследованные создателями и объяснить его предназначение.

Предназначение

Протокол SNMP был разработан с целью проверки функционирования сетевых маршрутизаторов и мостов. Впоследствии сфера действия протокола охватила и другие сетевые устройства, такие как хабы, шлюзы, терминальные сервера, LAN Manager сервера, машины под управлением Windows NT и т.д. Кроме того, протокол допускает возможность внесения изменений в функционирование указанных устройств.

Теория

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

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

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

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

Internet MIB - база данных объектов для обеспечения диагностики ошибок и конфигураций. Включает в себя 171 объект (в том числе и объекты MIB I).
LAN manager MIB - база из 90 объектов - пароли, сессии, пользователи, общие ресурсы.
WINS MIB - база объектов, необходимых для функционирования WINS сервера (WINSMIB.DLL).
DHCP MIB - база объектов, необходимых для функционирования DHCP сервера (DHCPMIB.DLL), служащего для динамического выделения IP адресов в сети.

Все имена MIB имеют иерархическую структуру. Существует десять корневых алиасов: 1) System - данная группа MIB II содержит в себе семь объектов, каждый из которых служит для хранения информации о системе (версия ОС, время работы и т.д.). 2) Interfaces - содержит 23 объекта, необходимых для ведения статистики сетевых интерфейсов агентов (количество интерфейсов, размер MTU, скорость передачи, физические адреса и т.д.) . 3) AT (3 объекта) - отвечают за трансляцию адресов. Более не используется. Была включена в MIB I. Примером использования объектов AT может послужить простая ARP таблица (более подробно об ARP протоколе можно почитать в статье "Нестандартное использование протокола ARP", которую можно найти на сайте в разделе "Articles") соответствия физических (MAC) адресов сетевых карт IP адресам машин. В SNMP v2 эта информация была перенесена в MIB для соответствующих протоколов. 4) IP (42 объекта) - данные о проходящих IP пакетах (количество запросов, ответов, отброшенных пакетов). 5) ICMP (26 объектов) - информация о контрольных сообщениях (входящие/исходящие сообщения, ошибки и т.д.). 6) TCP (19) - все, что касается одноименного транспортного протокола (алгоритмы, константы, соединения, открытые порты и т.п.). 7) UDP (6) - аналогично, только для UDP протокола (входящие/исходящие датаграммы, порты, ошибки). 8) EGP (20) - данные о трафике Exterior Gateway Protocol (используется маршрутизаторами, объекты хранят информацию о принятых/отосланных/отброшенных кардах). 9) Transmission - зарезервирована для специфических MIB. 10) SNMP (29) - статистика по SNMP - входящие/исходящие пакеты, ограничения пакетов по размеру, ошибки, данные об обработанных запросах и многое другое.

Каждый из них представим в виде дерева, растущего вниз, (система до боли напоминает организацию DNS). Например, к адресу администратора мы можем обратиться посредством такого пути: system.sysContact.0 , ко времени работы системы system.sysUpTime.0 , к описанию системы (версия, ядро и другая информация об ОС) : system.sysDescr.0 . С другой стороны те же данные могут задаваться и в точечной нотации. Так system.sysUpTime.0 соответствует значение 1.3.0, так как system имеет индекс "1" в группах MIB II, а sysUpTime - 3 в иерархии группы system. Ноль в конце пути говорит о скалярном типе хранимых данных. Ссылку на полный список (256 объектов MIB II) Вы можете найти в конце статьи в разделе "Приложение". В процессе работы символьные имена объектов не используются, то есть если менеджер запрашивает у агента содержимое параметра system.sysDescr.0, то в строке запроса ссылка на объект будет преобразована в "1.1.0", а не будет передана "как есть". Далее мы рассмотрим BULK-запрос и тогда станет ясно, почему это столь важно. На этом мы завершим обзор структуры MIB II и перейдем непосредственно к описанию взаимодействия менеджеров (систем управления) и агентов.

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

GetRequest - запрос у агента информации об одной переменной.
GetNextRequest - дает агенту указание выдать данные о следующей (в иерархии) переменной.
GetBulkRequest - запрос за получение массива данных. При получении такового, агент проверяет типы данных в запросе на соответствие данным из своей таблицы и цикле заполняет структуру значениями параметров: for(repeatCount = 1; repeatCount
Теперь представьте себе запрос менеджера на получение списка из сотни значений переменных, посланный в символьном виде, и сравните размер такового с размером аналогичного запроса в точечной нотации. Думаю, Вы понимаете, к чему привела бы ситуация, если бы символьные имена не преобразовывались вышеуказанным образом.
- SetRequest - указание установить определенное значение переменой.
Кроме этого менеждеры могут обмениваться друг с другом информацией о своей локальной MIB. Такой тип запросов носит название InformRequest.
Приведу значения числовых констант для всех видов запросов:
#define SNMP_MSG_GET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x0) #define SNMP_MSG_GETNEXT (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x1) #define SNMP_MSG_RESPONSE (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x2) #define SNMP_MSG_SET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x3) /* PDU для SNMPv1 */ #define SNMP_MSG_TRAP (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x4) /* PDU для SNMPv2 */ #define SNMP_MSG_GETBULK (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x5) #define SNMP_MSG_INFORM (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x6) #define SNMP_MSG_TRAP2 (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x7)
Вот тут то мы сталкиваемся с еще одной интересной деталью, как видите для ловушке есть 2 числовые константы. На самом деле существует 2 основные версии протокола SNMP (v1 & v2) и самое важное то, что они не являются совместимыми (на самом деле версий значительно больше -SNMP v2{p | c | u} etc, только все эти модификации довольно незначительны, так как, например, введение поддержки md5 и т.п.).
SNMP - протокол контроля и диагностики, в связи с чем, он рассчитан на ситуации, когда нарушается целостность маршрутов, кроме того в такой ситуации требуется как можно менее требовательный с аппаратуре транспортный протокол, потому выбор был сделан в сторону UDP.
Но это не значит, что никакой другой протокол не может переносить пакеты SNMP. Таковым может быть IPX протокол (например, в сетях NetWare) , также в виде транспорта могут выступать карды Ethernet, ячейки ATM. Отличительной особенностью рассматриваемого протокола есть то, что передача данных осуществляется без установки соединения.
Допустим менеджер послал несколько пакетов разным агентам, как же системе управления в дальнейшем определить какой из приходящих пакетов касается 1ого и 2ого агента? Для этого каждому пакету приписывается определенный ID - числовое значение. Когда агент получает запрос от менеджера, он генерирует ответ и вставляет в пакет значение ID , полученное им из запроса (не модифицирую его). Одним из ключевых понятий в SNMP является понятие group (группа). Процедура авторизации менеджера представляет собой простую проверку на принадлежность его к определенной группе, из списка, находящегося у агента. Если агент не находит группы менеджера в своем списке, их дальнейшее взаимодействие невозможно. До этого мы несколько раз сталкивались с первой и второй версией SNMP. Обратим внимание на отличие между ними.
Первым делом заметим, что в SNMP v2 включена поддержка шифрования трафика, для чего, в зависимости от реализации, используются алгоритмы DES, MD5 .
Это ведет к тому что при передаче данных наиболее важные данные недоступны для извлечения сниффингом, в том числе и информация о группах сети. Все это привело в увеличению самого трафика и усложнению структуры пакета. Сам по себе, на данный момент, v2 практически нигде не используется. Машины под управлением Windows NT используют SNMP v1. Таким образом мы медленно переходим к, пожалуй, самой интересной части статьи, а именно к проблемам Security. Об этом давайте и поговорим...
Практика и безопасность

В наше время вопросы сетевой безопасности приобретают особое значение, особенно когда речь идет о протоколах передачи данных, тем более в корпоративных сетях. Даже после поверхностного знакомства с SNMP v1/v2 становится понятно, что разработчики протокола думали об этом в последнюю очередь или же их жестко поджимали сроки сдачи проекта %-).
Создается впечатление что протокол рассчитан на работу в среде так называемых "доверенных хостов". Представим себе некую виртуальную личность. Человека, точнее некий IP адрес, обладатель которого имеет намерение получить выгоду, либо же просто насолить администратору путем нарушения работы некой сети. Станем на место этой особы. Рассмотрение этого вопроса сведем к двум пунктам:
a) мы находимся вне "враждебной сети". Каким же образом мы можем совершить свое черное дело? В первую очередь предполагаем что мы знаем адрес шлюза сети. Согласно RFC, соединение системы управления с агентом происходит по 161-ому порту (UDP). Вспомним о том что для удачной работы необходимо знание группы. Тут злоумышленнику на помощь приходит то, что зачастую администраторы оставляют значения (имена) групп, выставленные по умолчанию, а по умолчанию для SNMP существует две группы - "private" и "public". В случае если администратор не предусмотрел подобного развития событий, недоброжелатель может доставить ему массу неприятностей. Как известно, SNMP протокол является частью FingerPrintering. При желании, благодаря группе system MIB II, есть возможность узнать довольно большой объем информации о системе. Чего хотя бы стоит read-only параметр sysDescr. Ведь зная точно версию программного обеспечения, есть шанс, используя средства для соответствующей ОС получить полный контроль над системой. Я не зря упомянул атрибут read-only этого параметра. Ведь не порывшись в исходниках snmpd (в случае UNIX подобной ОС), этот параметр изменить нельзя, то есть агент добросовестно выдаст злоумышленнику все необходимые для него данные. А ведь не надо забывать о том, что реализации агентов под Windows поставляются без исходных кодов, а знание операционной системы - 50% успеха атаки. Кроме того, вспомним про то, что множество параметров имеют атрибут rw (read-write), и среди таких параметров - форвардинг! Представьте себе последствия установки его в режим "notForwarding(2)". К примеру в Linux реализации ПО для SNMP под название ucd-snmp есть возможность удаленного запуска скриптов на сервера, путем посылки соответствующего запроса. Думаю, всем понятно к чему могут привести "недоработки администратора".
б) злоумышленник находится на локальной машине. В таком случае вероятность увольнения админа резко возрастает. Ведь нахождение в одном сегменте сети дает возможность простым сниффингом отловить названия групп, а с ними и множество системной информации. Этого случая также касается все сказанное в пункте (а).
Перейдем к "практическим занятиям". Что же может на понадобиться. В первую очередь программное обеспечение. Его можно достать на . Примеры я буду приводить для ОС Линукс, но синтаксис команд аналогичен Windows ПО.
Установка пакета стандартна:
Gunzip udc-snmp-3.5.3.tar.gz tar -xvf udc-snmp-3.5.3.tar cd udc-snmp-3.5.3 ./configure make make install
Запуск демона (агента)
После инсталяции Вам доступны программы:
Snmpget snmpset snmpgetnext snmpwalk snmpbulkwalk snmpcheck snmptest snmpdelta snmpnetstat snmpstatus snmptable snmptrap snmptranstat и демон snmptrapd
Посмотрим, как выглядят описанные выше операции на практике. Запрос GetRequest реализует одноименная программа snmpget Для получения необходимой информации выполним следующую команду:
Root@darkstar:~# snmpget 10.0.0.2 public system.sysDescr.0
На что сервер добросовестно сообщит нам:
System.sysDescr.0 = Hardware: x86 Family 6 Model 5 Stepping 0 AT/AT COMPATIBLE - Software: Windows NT Version 4.0 (Build Number: 1381 Uniprocessor Free)
(не правда ли - довольно содержательно), либо же

SNMP - это протокол прикладного уровня, разработанный для стека TCP/IP, хотя имеются его реализации и для других стеков, например IPX/SPX. Протокол SNMP используется для получения от сетевых устройств информации об их статусе, производительности и других характеристиках, которые хранятся в базе данных управляющей информации MIB (Management Information Base). Простота SNMP во многом определяется простотой MIB SNMP, особенно их первых версий MIB I и MIB II. Кроме того, сам протокол SNMP также весьма несложен.

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

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

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

Команда Get-request используется менеджером для получения от агента значения какого-либо объекта по его имени.

Команда GetNext-request используется менеджером для извлечения значения следующего объекта (без указания его имени) при последовательном просмотре таблицы объектов.

С помощью команды Get-response агент SNMP передает менеджеру ответ на команды Get-request или GetNext-request.

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

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

Версия SNMP v.2 добавляет к этому набору команду GetBulk, которая позволяет менеджеру получить несколько значений переменных за один запрос.

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

SNMP (simple network management protocol, простой протокол сетевого управления) – это стандартный протокол для управления устройствами в IP-сетях. С его помощью серверы могут обмениваться информацией о своем текущем состоянии, а администратор может изменять предварительно определенные значения. Сам протокол очень простой, однако структура основанных на нём программ может оказаться сложной.

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

Базовые понятия

Протокол SNMP реализуется на прикладном уровне сетевого стека. Протокол был разработан для согласованного сбора информации из самых разных систем. SNMP использует стандартизированные методы запроса информации и пути.

Существует много различных версий протокола SNMP. Кроме того, протокол частично реализуется некоторыми сетевыми аппаратными устройствами. Наиболее распространённой является версия SNMPv1, но она имеет много уязвимостей; на самом деле, основными причинами её популярности являются её вездесущность и долгое время существования. Вместо неё рекомендуется использовать более безопасную версию SNMPv3.

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

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

Менеджеры SNMP

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

Менеджером может быть любая машина, которая может отправлять запросы агентам SNMP, предоставляя валидные учётные данные (например, сервер мониторинга); иногда задачи менеджера выполняет сам администратор с помощью простых утилит для быстрого запроса данных.

Почти все команды SNMP предназначены для менеджера. Например:

GetRequest
GetNextRequest
GetBulkRequest
SetRequest
InformRequest
Response

Кроме того, менеджер может отвечать на Trap и Response.

Агенты SNMP

Агенты SNMP выполняют основную работу. Они отвечают за сбор данных о локальной системе, их хранение в удобном для запросов формате, обновление БД management information base (или просто MIB).

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

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

Агенты SNMP отвечают на большинство команд протокола, среди которых:

GetRequest
GetNextRequest
GetBulkRequest
SetRequest
InformRequest

Также он может отправлять сообщения Trap.

Кратко о MIB

Management Information Base, или MIB – пожалуй, самый сложный компонент системы SNMP. Это иерархическая глобально стандартизированная база данных, которая следует стандартам агентов и менеджеров системы.

Проще всего структуру MIB можно представить в виде перевёрнутого дерева. Каждая ветвь получает порядковый номер (начиная с 1) и уникальную для этого уровня иерархии строку.

Чтобы сослаться на определённый узел, нужно отследить к нему путь в базе. Идентификаторы узла (номера и строки) можно использовать как адрес. Каждый узел в иерархии обозначается точкой. Таким образом, адрес содержит ряд идентификационных строк или чисел, разделенных точками. Такой адрес называется идентификатором объекта (или OID).

MIB предоставляет стандартные ветки, которые может использовать любое устройство. Однако при внедрении SNMP в свое устройство вы можете создавать пользовательские ветки.

Все стандартные ветки принадлежат одной родительской структуре. Эта ветка определяет информацию для спецификации MIB-2 (это пересмотренный стандарт для совместимых устройств).

Базовый путь к этой ветке:

iso.org.dod.internet.mgmt.mib-2

Часть 1.3.6.1 или iso.org.dod.internet – это OID, который определяет интернет-ресурсы.
2 или mgmt определяют подкатегории управления.
1 или mib-2 определяют спецификацию MIB-2.

Запрашивая информацию устройств, вы заметите, что большинство адресов начинается с 1.3.6.1.2.1.

Команды протокола SNMP

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

Следующие блоки данных протокола описывают точные типы сообщений, которые поддерживает протокол:

Get: это сообщение менеджер отправляет агенту, чтобы запросить значение определённого OID. В ответ этот запрос получает сообщение Response, содержащее все необходимые данные.
GetNext: это сообщение позволяет менеджеру запрашивать следующий последовательный объект в MIB. Так можно пересечь структуру MIB, не используя в запросах OID.
Set: это сообщение менеджер отправляет агенту для того, чтобы изменить значение переменной. С помощью Set можно управлять информацией о конфигурации или иным образом изменять состояние удаленных хостов. Это единственная операция записи, которую поддерживает протокол.
GetBulk: этот запрос работает как несколько запросов GetNext. Менеджер получит ответ максимальный объём данных (учитывая ограничения запроса).
Response: агент отправляет это сообщение менеджеру, чтобы передать ему запрашиваемые данные. Если запрашиваемые данные нельзя передать, response будет содержать ошибку с дополнительной информацией. Сообщение response отправляется на любой из вышеперечисленных запросов, а также на сообщение Inform.
Trap: это сообщение обычно отправляется агентом менеджеру, чтобы предоставить информацию о событиях, которые происходят на управляемых устройствах.
Inform: такое сообщение менеджер отправляет агенту в ответ на trap. Если агент не получит такого сообщения, он будет повторно отправлять сообщения trap.

Версии протокола

С момента выхода протокол SNMP прошел через множество изменений. Первая реализация SNMP, сейчас известная как SNMPv1, появилась в 1988 году и состояла из RFC 1065, RFC 1066 и RFC 1067. Эта версия до сих пор широко поддерживается, однако она имеет множество проблем с безопасностью (например, аутентификация в виде обычного текста), поэтому её использование крайне нежелательно, особенно это касается незащищенных сетей.

Работа над версией 2 данного протокола началась в 1993 году. Эта версия предлагает ряд существенных улучшений представленных ранее стандартов. В этой версии была представлена модель безопасности на основе сторон, которая устраняет уязвимости, связанные с предварительным пересмотром. Тем не менее, новую модель безопасности оказалось достаточно сложно реализовать, потому популярной она не стала.

Поэтому появились дополнительные релизы версии 2, каждый из которых сохранил основную часть усовершенствований версии 2, но изменил модель безопасности. Версия SNMPv2c возобновила модель безопасности на основе сообществ (которая была использована в v1); это была самая популярная версия протокола v2. Другая реализация, SNMPv2u, основана на пользовательской модели безопасности, также не стала популярной.

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

NoAuthNoPriv: пользователи, подключающиеся на этом уровне, не имеют учётных данных для аутентификации; отправленные и полученные ими сообщения находятся в общем доступе.
AuthNoPriv: на этом уровне для подключения нужно пройти аутентификацию, но сообщения не будут зашифрованы.
AuthPriv: обязательная аутентификация, сообщения шифруются.

Кроме новых моделей аутентификации был реализован механизм контроля доступа, который управляет доступом пользователей к веткам. Версия 3 также может использовать протоколы безопасности SSH или TLS.

Tags: , Дмитрий Ганьжа

Типичная сеть состоит из множества устройств различных производителей. Управлять такой сетью возможно только при наличии стандартного, не зависящего от производителя протокола управления. Самым популярным стандартным протоколом управления в современных сетях является простой протокол управления сетью (Simple Network Manage-ment Protocol, SNMP). Широкое распространение он получил в силу своей гибкости и расширяемости - SNMP позволяет описывать объекты для самых разных устройств. Ниже мы рассмотрим основные компоненты SNMP с указанием отличий первой версии протокола от второй.

МОДЕЛЬ SNMP

Модель SNMP состоит из четырех компонентов:

управляемых узлов;
станций управления (менеджеров);
управляющей информации;
протокола управления.

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

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

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

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

Однако иногда в сети могут происходить нежелательные события. Управляемые узлы могут сломаться, линии связи - выйти из строя и т. п. Как только агент замечает какое-либо значительное событие, он немедленно сообщает о нем всем станциям из своего конфигурационного списка. Это сообщение называется прерыванием SNMP. Агент лишь сообщает о событии, а все подробности станция управления должна выяснять самостоятельно. Из-за ненадежности коммуникаций между станцией и агентами (получение сообщений не подтверждается) каждая станция периодически проводит опрос управляемых узлов для выявления необычных событий. Такая модель опроса через длительные интервалы времени с немедленным опросом при получении прерывания называется инициируемым прерываниями опросом.

СТРУКТУРА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ

Структура управляющей информации (Structure of Management Information, SMI) определяет допустимые в базе управляющей информации типы данных и способы их представления. Кроме того, она определяет иерархическую структуру имен, чтобы управляемые объекты имели уникальные однозначные имена. SMI представляет своего рода надподмножество ASN.1 - она использует часть типов данных этого стандарта и вводит несколько своих типов данных. (АSN - абстрактное описание синтаксиса - представляет собой стандартный язык описания объектов, принятый в OSI. Как и многие другие протоколы OSI, он сложен, громоздок и неэффективен.)

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

Объекты базы управляющей информации обычно имеют шесть атрибутов. Как правило, это имя, например ifInErrors или tcpAttemptFails; идентификатор объекта в точечно-десятичной нотации вида 1.3.6.1.2.1.2.2.1.1.4; поле синтаксиса для выбора одного из нескольких возможных типов данных - Integer, IPAddress или Counter; поле метода доступа - "недоступен", "только чтение", "чтение-запись" и "только запись"; поле статуса - "обязательный", "необязательный" или "вышедший из употребления", а также текстовое описание объекта.

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

БАЗА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ

Множество объектов, которыми управляет SNMP, составляет базу управляющей информации (Management Information Base, MIB). Для удобства эти объекты объединены в десять групп, каждая из которых представляет собой дочерний для mib-2 узел в дереве имен объектов (см. Рисунок 1). Изначально база управляющей информации содержала восемь групп. Спецификация MIB-2 добавила еще две группы и исключила одну прежнюю. Производители могут определять собственные объекты. Информация по всем десяти группам сведена в Таблицу 1.

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

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

Присутствовавшая в MIB-1 группа АТ предоставляла данные о соответствии адресов (например, MAC- и IP-адресов). В SNMPv2 эта информация была перемещена в базы управляющей информации для конкретных протоколов.

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

Группа ICMP собирает данные о сообщениях об ошибках в IP. Она имеет счетчики для подсчета количества зафиксированных сообщений каждого возможного типа.

Группа TCP служит для учета числа открытых соединений, количества переданных и полученных сегментов и различного рода ошибок.

Группа UDP позволяет фиксировать число переданных и полученных дейтаграмм, а также количество дейтаграмм, потерянных из-за того, что порт неизвестен, или по другим причинам.

Группа EGP используется маршрутизаторами, поддерживающими Exterior Gate-way Protocol. Она позволяет подсчитывать число полученных из внешней сети кадров, а также сколько из них было передано правильно, а сколько отброшено и т. п.

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

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

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

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

Менеджер агенту может послать следующие три сообщения: GetRequest, GetNextRequest и SetRequest. Первые два служат для запроса у агента значений конкретных переменных. Первое из них содержит имя переменной в явном виде. Второе запрашивает значение следующей переменной в алфавитном порядке. Третье позволяет менеджеру изменять значения переменных, если определение объекта это позволяет.

Агент может отправлять два различных сообщения: одно из них - GetResponse - служит для ответа (и подтверждения) на запрос от менеджера, а второе - Trap - посылается при обнаружении агентом предопределенного чрезвычайного события.

Протоколом SNMPv2 вводится еще два типа сообщений. GetBulkRequest позволяет запросить целый массив переменных, например таблицу, а InformRequest - одному менеджеру сообщить другому, какими переменными он управляет.

Все типы сообщений сведены в Таблице 2.

НИЖЕЛЕЖАЩИЕ ТРАНСПОРТНЫЕ ПРОТОКОЛЫ

SNMP предназначался в первую очередь для управления сетями на базе протоколов Internet. Как протокол прикладного уровня он может, однако, использовать в качестве транспортного любой другой протокол, помимо UDP и IP. Например, он может выполняться поверх IPX, отображаться напрямую в кадры Ethernet, инкапсулироваться в ячейки ATM и т. п.

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

Благодаря своей простоте и транспорту без установления соединения SNMP оказывается весьма эффективным протоколом. И агенты, и менеджеры могут работать независимо друг от друга. Таким образом, менеджер будет продолжать работать, даже если удаленный агент окажется недоступен. После возобновления функционирования агент отправит менеджеру прерывание, дабы известить его о своей работоспособности.

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

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

UDP более подходит для транспорта SNMP, нежели TCP, в частности, когда сеть сталкивается с проблемами и пакеты передаются каждый раз по новым маршрутам, т. е. когда управление наиболее необходимо. Кроме того, он предъявляет меньшие требования к сетевым ресурсам, нежели TCP, т. е. накладные расходы на управление оказываются меньше. Однако в результате задача обнаружения потерянных и ошибочных пакетов возлагается непосредственно на менеджеров и агентов.

ЗАЩИТА В SNMP

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

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

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

ЛОЖКА ДЕГТЯ?

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

Однако SNMP продолжает совершенствоваться, и уже готовится третья версия этого протокола.

Дмитрий Ганьжа - ответственный редактор LAN. С ним можно связаться по адресу:

Цель работы: изучение способов мониторинга и управления сетью на основе протокола SNMP.

Применяемое оборудование:

2.Один коммутатор третьего уровня D-LinkDES-3810-28.

3. Два управляемых коммутатора второго уровня D-LinkDES-3200-10.

Теоретические сведения:

Протокол SNMP

Определение и функции протокола:

Протокол SNMP (Simple Network Management Protocol, простой протокол управления сетью) является протоколом Прикладного уровня, разработанный для выполнения двух задач:

Мониторинг сетевых устройств и сети в целом;

Управление сетевыми устройствами.

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

Версии протокола SNMP

Опишем различия между версиями протокола SNMP и документы, определяющие эти версии. По состоянию на 2006 год единственной не устаревшей версией SNMP является SNMPv3, определённая в RFC 3411-3418.

Первые RFC, описывающие стандарты SNMP, появились в 1988 году. Версия 1 подвергласькритике за её посредственную модель безопасности на основе сообществ. В товремя безопасность в Интернете не входила в круг первоочередных задач рабочих группIETF.

Версия 2, известная так же, как Party-based SNMPv2, ипи SNMPv2p, не получила широкого распространения из-за серьёзных разногласий по поводу инфраструктуры безопасности в стандарте. SNMPv2 улучшал версию 1 в области быстродействия, безопасности, конфиденциальности и взаимодействий «менеджер-менеждер». Он представил новый тип PDU Get-Bulk-Request, альтернативу Get-Next-Request для получения больших объёмов

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

Community-based SNMPv2, или SNMPv2c, представил SNMPv2 без новой модели безопасности версии 2. Вместо неё предлагалось использовать старую модель безопасности версии 1 на основе сообществ. Соответствующее предложение RFC было принято только как черновик стандарта, однако стало де факто стандартом SNMPv2. Безопасность SNMP снова оказалась нерешённым вопросом.

User-based SNMPv2, или SNMPv2u, является компромиссом между незащищённостью SNMPvl и чрезмерной сложностью SNMPv2p. Предложенная модель безопасности на основе пользователей была положена в основу SNMPv3.

SNMPv3 наконец-то решил проблемы с безопасностью способом, который многие посчитали приемлемым. Версия 3 SNMP принята IETF как стандарт Интернета (IETF STD 62). Почти все предыдущие RFC признаны устаревшими. Документы, описывающие протокол SNMPv3, приведены ниже:

Общаяинформация.

RFC 3411. An Architecture for Describing SNMP Management Frameworks.

Обработка сообщений.

1)Привязки к транспорту.

RFC 3417. Transport Mappings for the SNMP.

2)Разбор и диспетчеризация сообщений.

RFC 3412. Message Processing and Dispatching for the SNMP.

3)Безопасность.

RFC 3414. User-based Security Model (USM) for SNMPv3.

Обработка PDU

1) Операции протокола.

RFC 3416. Version 2 of the Protocol Operations for SNMP.

2)ПриложенияSNMP.

RFC 3413. SNMP Applications.

3)Управлениедоступом.

RFC 3415. View-based Access Control Model (VACM) for the SNMP.

МодулиMIB.

RFC 3418. MIB for the SNMP.

Модель протокола SNMP

Общая модель

Модель приведена на рисунке 1. Основными взаимодействующими элементами протокола являются агенты (agent) и системы управления сетью (NMS, network management system). С точки зрения концепции «клиент-сервер» роль сервера выполняют агенты, то есть те самые устройства, для опроса состояния которых используется протокол SNMP.

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

Агентами в SNMP являются программные модули, которые работают в управляемых устройствах. Агенты собирают информацию об управляемых устройствах, в которых они работают.

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

Структура базы M I В

На данный момент существует четыре типа информационной базы MIВ:

1. Internet MIB - информационная база объектов для обеспечения диагностики ошибок и конфигураций. Включает в себя 171 объект (в том числе и объекты MIB I).

2. LAN manager MIB - база из 90 объектов - пароли, сессии, пользователи, общие ресурсы.

3. WINS MIB - база объектов, необходимых для управления и диагностики WINS- сервера (в серверах Microsoft Windows физически находится в файле

4. DHCP MIB - база объектов, необходимых для управления и диагностики DHCP- сервера (в серверах Microsoft Windows физически находится в файле

Структуру MIB определяет документ, называемый SMI (Structure of Management Information, структура управляющей информации). Все MIB имеют иерархическую древовидную структуру. Все базы содержат десять корневых алиасов (ветвей).

1. System - данная группа MIB II содержит в себе семь объектов, каждый из которых служит для хранения информации о системе (версия ОС, время работы и т.д.).

2. Interfaces - содержит 23 объекта, необходимых для ведения агентами статистики по сетевым интерфейсам управляемого устройства (количество интерфейсов, размер MTU, скорость передачи данных, физические адреса и т.д.).

3. AT - содержит 3 объекта, отвечающих за трансляцию адресов. Более не используется. Была включена в MIB I. Примером использования объектов AT может послужить простая ARP таблица соответствия физических (MAC) адресов сетевых карт IP адресам машин. В SNMP v2 эта информация была перенесена в MIB для соответствующих протоколов.

4. IP - содержит 42 объекта, в которых хранятся данные о проходящих IP пакетах.

5. ICMP - содержит 26 объектов со статистикой об ICMP-сообщениях.

6. TCP - содержит 19 объектов, хранящих статистику по протоколу TCP (соединения, открытые порты и т.д.).

7. UDP - содержит 6 объектов, хранящих статистику по протоколу UDP (входящие/исходящие датаграммы, порты, ошибки).

8. EGP - содержит 20 объектов - данные о трафике Exterior Gateway Protocol.

9. Transmission - зарезервирована для специфических задач.

10. SNMP - содержит 29 объектов, в которых хранится статистика по SNMP-протоколу (входящие/исходящие пакеты, ограничения пакетов по размеру, ошибки, данные об обработанных запросах и многое другое).

Рисунок 1

Каждая из ветвей в свою очередь также представима в виде дерева. Например, к адресу администратора мы можем обратиться посредством такого пути: system.sysContact.0, ко времени работы системы system.sysUpTime.O. С другой стороны те же данные могут задаваться и в точечной нотации. Так system.sysUpTime. O соответствует значение 1.3.0, так

как system имеет индекс «1» в группах MIB II, a sysUpTime - «3» в иерархии группы system. Ноль в конце пути говорит о скалярном типе хранимых данных. В процессе работы SNMP-протокол использует точечную нотацию, то есть если менеджер запрашивает у агента содержимое параметра system.sysDescr.O, то в строке запроса ссылка на объект будет преобразована в «1.1.0».

Рисунок 2

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

SMI определяет следующие типы данных Ml В:

1. Network addresses (сетевые адреса) - символьные строки, представляющие адреса из конкретного стека протоколов. В настоящее время единственным примером сетевых адресов являются 32-битовые IP-адреса.

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

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

4. Ticks (тики) - сотые доли секунды, прошедшие после какого-нибудь события. Примером типа «ticks» является время, прошедшее после вхождения интерфейса в свое текущее состояние.

5. Opaque (непрозрачный) - произвольное тип данных. Используется для передачи произвольных информационных последовательностей, находящихся вне пределов точного печатания данных, которое использует SMI.

Основные команды системы NMS

Если NMS хочет проконтролировать какое-либо из управляемых устройств, она делает это путем отправки ему сообщения с указанием об изменении значения одной из его переменных.

В целом управляемые устройства отвечают на четыре типа команд (или инициируют их):

Для контролирования управляемых устройств NMS считывают переменные, поддерживаемые этими устройствами.

Для контролирования управляемых устройств NMS записывают переменные, накопленные в управляемых устройствах

3. Traversal operations.

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

Управляемые устройства используют «ловушки» для асинхронных сообщений в NMS о некоторых событиях.

Протокол SNMPv3

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

Протокол обмена данными

Ниже на рисунке 3 приведена временная диаграмма, на которой в общем виде представлен протокол обмена SNMP-сообщениями. Для своей работы протокол SNMP использует транспортный протокол UDP, в основном 161 порт. Но для trap-сообщений используется 162 порт. Возможные команды протокола SNMPv3 приведены в таблице 1.

Рисунок 3

таблица 1

Команда SNMP		Назначение
		Получить значение указанной переменной или информацию о состоянии сетевого элемента
		Получить значение переменной, не зная точного её имени (следующий логический идентификатор на дереве MIB).
		Присвоить переменной соответствующее значение. Используя для описания действия, которое должно быть выполнено.
		ОткликнаGET-request, GET-next-request и SET-request. Содержит также информацию о состоянии (коды ошибок и другие данные).
		Отклик сетевого объекта на событие или на изменение состояния.
		Запрос пересылки больших объемов данных, например, таблиц.
		Менеджер обращает внимание партнёра на определенную информацию в MIB.
		Отклик на событие (расширение по отношению
		Отчёт (функция пока не задана).

Формат SNMP-сообщения

Полное описание формата сообщения протокола SNMPv3 дано в документе RFC-3412 в разделе 6 «TheSNMPv3 MessageFormat*. Формат сообщения представлен на рисунке 4

Рисунок 4

SNMP-сообщение логически разделено на три части:

1. Часть, которая формируются отправителем в рамках модели обработки сообщений и обрабатываются получателем.

2. Часть, отвечающая за функции безопасности.

3. Собственно поле данных.

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

MsgVersion. Версия протокола. Для протокола SNMPv3 значение в поле равно 3.

MsgID. Уникальный идентификатор, используемый SNMP-сущностями для установления соответствия между запросом и откликом. Значение msgID лежит в диапазоне 0 - (231-1).

MsgMaxSize. Максимальный размер сообщения в октетах, поддерживаемый отправителем. Его значение лежит в диапазоне 484 - (231-1) и равно максимальному размеру сегмента, который может воспринять отправитель.

MsgFlags. Однобайтовая строка, содержащая три флага в младших битах:

- reportableFlag. Если reportableFlag=1, то должно быть прислано сообщение с отчётом (команда Report). Флаг reportableFlag устанавливается отправителем во всех сообщениях запроса (команды Get, Set, Inform). Флаг устанавливается равным нулю в откликах и Trap-уведомлениях;

- privFlag;

- authFlag.

Флаги privFlag и authFlag устанавливаются отправителем для индикации уровня безопасности для данного сообщения. Для privFlag=1 используется шифрование, а для authFlag=0 - аутентификация. Допустимы любые комбинации значений флагов кроме privFlag=1 AND authFiag=0 (шифрование без аутентификации).

MsgSecurityModel Идентификатор со значением в диапазоне 0 - (231-1), который указывает на модель безопасности, используемую при формировании данного сообщения. Зарезервированы значения 1 - для SNMPvl, 2 и 3 - д л я SNMPv3.

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

Модели безопасности протоколов SNMPv1-v3

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

1. SNMPvl

SNMPvl - Community-based Security Model

2. SNMPv2

SNMPv2p - Party-based Security Model

SNMPv2c- Community-based Security Model

SNMPv2u - User-based Security Model

3. SNMPv3

SNMPv3 - USM User-based Security Model

Модель безопасности на основе сообществ

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

Модель безопасности на основе сторон

Модель безопасности на основе сторон (Party-based Security Model) подразумевает введение понятие стороны. Сторона — это виртуальное окружение исполнения, в котором набор допустимых операций ограничен административно. Сущность SNMP при обработке сообщения действует как сторона, поэтому ограничена операциями, определёнными для этой стороны.

Сторона определяется следующими параметрами:

1. Уникальный идентификатор стороны.

2. Логический сетевой адрес (адрес транспортного протокола).

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

4. Протокол шифрования и параметры, требующиеся для шифрования всех сообщений стороны. Могут использоваться различные алгоритмы для протоколов аутентификации и шифрования. Обычно в качестве алгоритма для протокола аутентификации используют хэш-функцию Message Digest 5 (MD5), а для протокола шифрования — алгоритм Data EncryptionStandard(DES) в режиме CipherBlockChaining(CBC). При использовании соответствующих протоколов аутентификации и шифрования модель успешно справляется с большинством угроз безопасности. Данная модель безопасности не была широко принята, поскольку показалась многим слишком сложной и запутанной.

Модель безопасности на основе пользователей

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

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

Модель безопасности USM . Модель безопасности USM (User-Based Security Model) использует концепцию авторизованного

сервера (authoritative Engene). При любой передаче сообщения одна или две

сущности, передатчик или приемник, рассматриваются в качестве авторизованного SNMP-сервера. Это делается согласно следующим правилам:

1. Когда SNMP-сообщение содержит поле данных, которое предполагает отклик (например, Get, GetNext, GetBulk, Set или Inform), получатель такого сообщения считается авторизованным.

2. Когда SNMP-сообщение содержит поле данных, которое не предполагает посылку отклика (например, SNMPv2-Trap, Response или Report), тогда отправитель такого сообщения считается авторизованным.

Таким образом, сообщения, посланные генератором команд, и сообщения Inform, посланные отправителем уведомлений, получатель является авторизованным. Для сообщений, посланных обработчиком команд или отправителем уведомлений Trap, отправитель является авторизованным. Такой подход имеет две цели:

1. Своевременность сообщения определяется с учетом показания часов авторизованного сервера. Когда авторизованный сервер посылает сообщение (Trap, Response, Report), оно содержит текущее показание часов, так что неавторизованный получатель может синхронизовать свои часы. Когда неавторизованный сервер посылает сообщение (Get, GetNext, GetBulk, Set, Inform), он помещает туда текущую оценку показания часов места назначения, позволяя получателю оценить своевременность прихода сообщения.

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

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

В параметрах безопасности содержатся следующие поля:

MsgAuthoritativeEngenelD. Идентификатор авторизованного сервера, участвующего в обмене. Это значение идентификатора отправителя для Trap,

Response илиReport илиадресатадляGet, GetNext, GetBulk, Set илиInform.

MsgAuthoritativeEngeneBoots. snmpEngeneBoots авторизованногосервера,

участвующеговобмене. Объект snmpEngeneBoots содержит целочисленные

значения в диапазоне 0 - (23 1-1). Это поле содержит число, показывающее сколько раз SNMP-сервер был перезагружен с момента конфигурирования.

MsgAuthoritativeEngeneTime. Время работы авторизованного сервера, участвующего в обмене. Значение этого поля лежит в диапазоне 0 - (231-1). Это поле характеризует число секунд, которое прошло с момента последней перезагрузки сервера. Каждый авторизованный сервер должен инкрементировать это поле один раз в секунду.

MsgUserName. Имя пользователя, который послал сообщение.

MsgAuthentication Parameters. Поле содержит ноль, если при обмене не используется аутентификация. В противном случае данное поле содержит аутентификационный параметр.

MsgPrivacyParameters. Поле содержит ноль, если не требуется соблюдения

конфиденциальности. В противном случае данное поле содержит параметр

безопасности. В действующей модели USM используется алгоритм шифрования DES.

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

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

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

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

операций для заданной части Ml В. Такая схема управления доступом называется VACM(View-BasedAccessControlModel). В процессе управления доступом анализируется контекст (vacmContextTable), а также специализированные таблицы vacmSecurity ToGroupTable, vacmTreeFamilyTable и vacmAccessTable.

Порядок выполнения работы:

1.Соберите топологию сети, представленную на рисунке 5.