Дмитрий Ганьжа

Типичная сеть состоит из множества устройств различных производителей. Управлять такой сетью возможно только при наличии стандартного, не зависящего от производителя протокола управления. Самым популярным стандартным протоколом управления в современных сетях является простой протокол управления сетью (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 предусматривает всего пять различных сообщений. Три из них может посылать менеджер агенту, а два других - агент менеджеру.

Если в сети ничего необычного не происходит, то 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. С ним можно связаться по адресу:

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

Три составляющие части технологии SNMP: структура управляющей информации (Structure of Management Information, SMI) базы управляющей информации (Management Information Base, MIB) сам протокол SNMP

Модель управления SNMP

Агентами в SNMP являются программные модули, которые работают в управляемых устройствах. Агенты собирают информацию об управляемых устройствах, в которых они работают, и делают эту информацию доступной для систем управления сетями (network management systems - NMS) с помощью протокола SNMP.

Протокол SNMP v1

SNMP реализован в 1988 практически во всех широко распространенных сетевых средах: TCP/IP, IPX/SPX, AppleTalk и др. Основной концепцией протокола является то, что вся необходимая для управления устройством информация хранится на самом устройстве - будь то сервер, модем или маршрутизатор - в так называемой Административной Базе Данных (MIB - Management Information Base). SNMP как непосредственно сетевой протокол предоставляет только набор команд для работы с переменными MIB. Этот набор включает следующие операции:

• get-request Используется для запроса одного или более параметров MIB
• get-next-request Используется для последовательного чтения значений. Обычно используется для чтения значений из таблиц. После запроса первой строки при помощи get-request get-next-request используют для чтения оставшихся строк таблицы
• set-request Используется для установки значения одной или более переменных MIB
• get-response Возвращает ответ на запрос get-request, get-next-request или set-request
• trap Уведомительное сообщение о событиях типа cold или warm restart или "падении" некоторого link"а.

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

Формат сообщений

Сообщения SNMP состоят из 2 частей: имени сообщества (community name) и данных (data). Имя сообщества назначает среду доступа для набора NMS, которые используют это имя. Информационная часть сообщения содержит специфичную операцию SNMP (get, set, и т.д.) и связанные с ней операнды. Операнды обозначают реализации об"екта, которые включены в данную транзакцию SNMP.

Structure of Managment Information. RFC 1208

Определяет логику адресации информации при взаимодействии агентов и менеджеров SNMP. Синтиксис описывается абстрактными правилами Abstract Syntax Notation One, ASN.1.

Managment Information Base (MIB, MIB-II). RFC 1213

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

Как происходит адресация в MIB к некоторой ее переменной?

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

Например, время работы устройства с момента перезагрузки хранится в переменной, находящейся в разделе system под номером 3 и называется sysUpTime. Соответственно, имя переменной будет включать весь путь: iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysUpTime(3); или на языке чисел: 1.3.6.1.2.1.1.3. Следует заметить, что при этом узлы дерева разделяются точками.

Существует стандартная ветвь MIB, относящаяся к разделу управления mgmt, которую обычно поддерживают все сетевые устройства.

Тестирование сети с помощью SNMP

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

Так, например, для раздела, относящегося к интерфейсам Ethernet, определен тест TDR (Time-domain reflectometry), позволяющий определять приблизительное расстояние до повреждения в коаксиальном кабеле. Для того, чтобы запустить TDR тест необходимо установить значение переменной ifExtnsTestTypе (1.3.6.1.2.1.12.2.1.4), содержащей тип выполняемого теста, так, чтобы она содержала идентификатор теста TDR в MIB: 1.3.6.1.2.1.10.7.6.1.

Результатом теста будет, во-первых, значение переменной ifExtnsTestResult (1.3.6.1.2.1.12.2.1.5), характеризующей исход теста:

• отсутствие результата
• успех
• выполняется
• не поддерживается
• невозможно запустить
• прекращен
• неудачное завершение

И во-вторых, значение переменной ifExtnsTestCode (1.3.6.1.2.1.12.2.1.6) будет содержать идентификатор переменной MIB, содержащей результат теста. Результат теста определен как временной интервал в 100-наносекундных единицах между началом передачи тестового пакета и обнаружением коллизий в несущей. В принципе, на основании данного значения можно определить требуемое расстояние.

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

Безопасность SNMP. RFC 1352.

Один из наиболее заметных недостатков SNMP v1 - отсутствие развитой системы защиты данных на уровне, необходимом для сетей масштаба предприятия.

Как сказал Mike Warfield: "SNMP stands for Security Not My Problem".

В SNMPv1 защита административной информации трактовалась слишком упрощенно: она базировалась на использовании коллективного имени (Community Name), которое, находясь в заголовке SNMP, несло в себе все возможности защиты сообщений. Данное средство (известное под названием тривиальный протокол) требовало, чтобы программа-агент и менеджер опознали одно и то же коллективное имя, прежде чем продолжить выполнение операций сетевого администрирования. В результате многие администраторы сетей ограничивались в своей работе только функциями мониторинга, запрещая выдачу команды SET, способной изменять параметры конфигурации удаленного устройства. Это привело к тому, что пользователи избегали команд SET: такое примитивное средство защиты, как коллективное имя, могло дать возможность лицам, не наделенным соответствующими полномочиями, изменять параметры, о чем пользователи могли даже и не узнать. К тому же вся критически важная информация передавалась в открытом виде,поэтому в интернете доступен даже snmp sniffer

В связи с этим были разработаны предложения по совершенствованию защиты в рамках SNMPv1, представленные в июле 1992 г.; они составили основу структуры защиты для SNMPv2.

Стандартами защиты SNMPv2 определяются методы аутентификации (DAP - Digest Authentication Protocol) и обеспечения конфиденциальности (SPP -Symmetric Privacy Protocol) информации административного характера. В основе лежит концепция участника (party) - уникального набора параметров защиты, который может включать местоположение сети, протоколы аутентификации и обеспечения конфиденциальности, используемые между агентом и менеджером.

Проблемы внедрения SNMPv2

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

Несомненно,пользователи захотят иметь продукты на базе SNMPv2. Но дело в том, что многие уже вложили слишком большие средства в версию SNMPv1, чтобы просто выбросить ее и начать все с нуля. Авторы SNMPv2 предвидели это и исходили из постепенности перехода на новую технологию. Предусмотрены два способа сохранения SNMPv1: использование уполномоченных агентов и двуязычных менеджеров. Уполномоченный агент выполняет преобразование форматов SNMPv1 в сообщения SNMPv2 и обратно.

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

К сожалению,вторая версия SNMP так до сих пор и не утверждена, поэтому в стане сетевого управления наблюдается разброд и шатания.

Доступные реализации агентов и менеджеров

http://www.microsoft.com/smsmgmt/
MS SMS Netmon

Epilogue предлагает ПО, реализующее поддержку SNMP, включающую:

• Envoy, Epilogue"s compact, fast, portable SNMP solution for OEMs
• Emissary, an SNMP MIB compiler that allows SNMP implementors to extend standard SNMP variables to support extensions to the MIBs in each managed device;
• Ambassador, a complete, portable implementation of the RMON (FastEthernet) remote monitoring agent.
• The IBM Netview for AIX feature of SystemView provides distributed or centralized management of large heterogeneous networks.
• ACE*COMM WinSNMP supports SNMPv1 & SNMPv2u in v2.0 of its industry-leading Win16 and Win32 WinSNMP implementations.
• Digital Unix POLYCENTER Manager on NetView provides client/server management of multivendor enterprise networks.
• The PowerFlag tool - агент для UPS MIB источников бесперебойного питания компании Victron B.V.
• WS_Ping ProPack v.2.10 позволяет просматривать MIB таблицы, указывать поддеревья. Для скачавания свежих версий с сервера Ipswitch можно использовать следующие данные:
• User Name: 0000037181
• Password: CQWSC
• Serial Number: WP-101333
• Openly-Available Implementations
• CMU SNMP agent (source)
  • an agent that support both SNMPv1 and SNMPv2u
  • a number command line based applications that support both SNMPv1 and SNMPv2u.
  • Carnegie-Mellon University SNMP Development Kit supporting SNMPv1/v2
• NetSCARF is a Network Statistics Collection and Reporting Facility. It allows ISPs to collect and report data about their part of the Internet, supports both SNMP version 1 and USEC.
• Scotty is a network management extension for the Tool Command Language (Tcl) which includes a portable implementation of the SNMPv1, SNMPv2c and SNMPv2u protocol. The Scotty Tcl extension includes the network management platform (Tkined) which provides a MIB browser, a network map editor as well as status monitoring, troubleshooting, network discovery and event filtering scripts.
• snmptcp v1.3 is a extensible platform for management applications which seemlessly implements SNMPv1, SNMPv2c, and SNMPv2u.
• The package runs under the X Window System on UNIX and is built from Tool Command Language (Tcl7.3/Tk3.6).In addition to a MIB compiler, the package contains some minimal applications for a number of standard MIB modules.

Атака на Windows SNMP.

Cервисы работают на следующих UDP портах (/etc/services)

• snmp 161/udp snmp
• snmp-trap 162/udp snmp

Интересные SMI Network Management Private Enterprise Codes:

Prefix: 1.3.6.1.4.1.

• 2 IBM
• 4 Unix
• 9 cisco
• 32 Santa Cruz Operation
• 42 Sun Microsystems

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

Уязвимость в стандартной конфиругации Windows NT SNMP Сервиса.

Позволяет удаленно конфигурировать сетевые парамерты, которые влияют на безопасность и правильное функционирования системы (если администратор сам запустил SNMP Service)

При конфигурации по умолчанию, SNMP service отвечает на стандартное community (имя) "public", которое обладает права на чтение и запись. Community - это имя, которое обладает такими же функциями, как логин и пароль в системах.

Протокол SNMP предоставляет два уровня полномочий: read-only and read-write, однако до выхода SP4 Windows NT SNMP Service не позволял конфигурировать communities по доступу, отличному от read-write!

Если попытать обезопасить SNMP Service путем переименования community для доступа, то система останется незащищенной от крякера, имеющего аккаунт на машине, так как параметры SNMP Service находятся в регистри и доступны всем пользователям на чтение. Также Windows NT SNMP Service обладает возможностью ограничить доступ для списков IP-адресов. На первый взгляд это позволяет защититься от атак неизвестных систем, однако это не является проблемой для крякеров (что необходимо понимать любому администратору), так как протокол SNMP использует UDP протокол для обмена информацией, а он является протоколом без установления соединения, поэтому возможна подмена исходящего адреса (но для этого придется переработать исходники SNMP менеджеров под Unix и изучить UDP spoofing)

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

Благодаря сконфигурированному по умолчанию Windows NT SNMP Сервису мы можем извлечь с помощью SNMP менеджера следующую информацию:

• the LAN Manager domain name
• a list of users
• a list of shares
• a list of running services

1. Открыть HKLM\System\CurrentControlSet\Services\SNMP\Parameters\ExtensionAgents
2. найти значение, которое содержит SOFTWARE\Microsoft\LANManagerMIB2Agent\CurrentVersion
3. и удалить его.

• a list of active TCP connections
• a list of active UDP connections
• a list of network interfaces and their associated IP and hardware addresses
• the IP routing table and the ARP table as well as a number of networking performance statistics.

Устанавливая переменные, крякер может модифицировать таблицу роуминга, ARP таблицу, выключить сетевые интерфейсы, сбить существенные сетевые параметры типа default IP, время жизни пакетов (TTL), IP forwarding (позволит крякеру перенаправлять сетевой трафик). Это особенно опасно, если атакуемая машина является фаерволом.

За примерами далеко ходить не надо, например, если машина является domain controller или server, но получить список всех пользователей в домене можно командой C:\NTRESKIT>snmputil walk public .1.3.6.1.4.1.77.1.2.25

Если вам хочется удалить все записи в базе данных WINS (что приведет к полному отказу WinNT), то для этого необходимо выполнить ~$snmpset -v 1192.178.16.2 public .1.3.6.1.4.1.311.1.2.5.3.0 a 192.178.16.2 из набора CMU SNMP development kit under Unix.

Также есть очень любопытная деталь при установки SNMP community names в Windows NT 4.0 (SP3). Если сервис включен, а имена не сконфигурированы, то любое имя будет давать read/write привилегии. Как оказалось, это указано еще в спецификации SNMP (RFC 1157)!

Четвертый СервисПак(SP4) предоставляет следующее решение проблемы: добавление контроля доступа community как READ ONLY,READ WRITE или READE CREATE. Однако по умолчанию SP4 устанавливает READ CREATE доступ, который все еще позволяет атаковать машины. Микрософт явно заботиться об удобстве WinNT для хакеров:)

Проблема в OS Solaris версии до 2.6.

Исходя из ISS Security Advisory (November 2nd, 1998), в агенте SNMP, который по умолчанию запущен в этой системе, существуют реальные угрозы получить доступ на уровне рута, манипулировать процессами и параметрами машины.

Для доступа к MIB-информации существует скрытая "undocumented community string", которая позволит атакующему изменить большинство системных параметров.

К сожалению, само это community не называется, однако ISS Internet Scanner и ISS RealSecure real-time intrusion detection могут детектировать эту проблемы, т.е. посмотреть можно и в их исходниках

SNMP (Simple Network Management Protocol - простой протокол управления сетью) - это протокол управления сетями связи на основе архитектуры TCP/IP, седьмого уровня (уровень приложений) семиуровневой модели OSI . SNMP дает возможность станциям управления сетью читать и изменять настройки шлюзов, маршрутизаторов, коммутаторов и других сетевых устройств. Используйте SNMP для настройки системных характеристик для правильной работы,контроля характеристик и обнаружения потенциальных проблем в коммутаторе, группе коммутаторов или сети.

Используемые порты: 161/UDP,162/UDP

SNMP-trap (ловушки SNMP) Traps - это аварийные сообщения, сообщающие о событиях, происходящих в коммутаторе. События могут быть такими серьезными, как перезапуск (кто-нибудь случайно выключил коммутатор) или менее, как например, изменение статуса порта. Коммутатор создает сообщения «traps» и отправляет их к «trap» получателю (или сетевому менеджеру). Обычные «traps» содержат сообщение об ошибке аутентификации Authentication Failure , изменении топологии сети Topology Change и широковещательном шторме Broadcast\Multicast Storm.

SNMP безопасность

К сожалению , наиболее часто используемая версия 1 протокола SNMP имеет довольно слабую схему аутентификации, основанную на использовании “строки сообщества”. Это связано с тем, что фиксированный пароль передается по сети в открытом виде. По возможности старайтесь использовать 2-ю версию протокола SNMP , которая поддерживает схему проверки подлинности выборки на основе алгоритма MD5 и позволяет ограничить доступ к различной управляющей информации.

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

Он использует незашифрованные строки проверки подлинности.

В большинстве реализаций SNMP такие строки отправляются неоднократно как часть периодических опросов.

Он плохо защищен от спуфинга и является протоколом транзакций на основе датаграмм.

Структура MIB. SMI. OID

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

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

В агенте может быть реализовано много MIB, но во всех агентах реализована конкретная MIB, которая называется MIB-II (RFC 1213). Этот стандарт определяет переменные для таких параметров, как статистика интерфейса (скорость интерфейса, MTU, количество отправленных октетов1, количество принятых октетов и т.д.), а также различных параметров, относящихся к самой системе (местоположение системы, контактные сведения и т.д.) Основная цель MIB-II – предоставить общую управляющую информацию TCP/IP.

SMI (The Structure of Management Information). Струк­ту­ра ин­фор­ма­ции для управ­ле­ния точ­но оп­ре­де­ля­ет, как управ­ляе­мым объ­ек­там при­сваи­ва­ют­ся име­на, и ука­зы­ва­ет свя­зан­ные с ни­ми ти­пы дан­ных.

OID (Object Identifier) уникальный иден­ти­фи­ка­тор объ­ек­та.

Управ­ляе­мые объ­ек­ты (OID) ор­га­ни­зо­ва­ны в дре­во­вид­ную ие­рар­хию. Со­сре­до­то­чим­ся на суб­де­ре­ве so(1).org(3).dod(6).in­ternet(1), ко­то­рое в фор­ме OID пред­став­ля­ет­ся как 1.3.6.1 или iso.org.dod.internet. У ка­ж­до­го управ­ляе­мо­го объ­ек­та есть циф­ро­вой иден­ти­фи­ка­тор OID и со­от­вет­ст­вую­щее тек­сто­вое имя. Обо­зна­че­ние в ви­де раз­де­лен­ных точ­ка­ми чи­сел ис­поль­зу­ет­ся для пред­став­ле­ния управ­ляе­мо­го объ­ек­та внут­ри аген­та; тек­сто­вое имя, как до­мен­ное имя, со­от­вет­ст­вую­щее IP- ад­ре­су, из­бав­ля­ет лю­дей от не­об­хо­ди­мо­сти за­по­ми­нать длин­ные, слож­ные стро­ки чи­сел.

Ветвь directory в на­стоя­щее вре­мя не ис­поль­зу­ет­ся.

Ветвь management (или mgmt) , оп­ре­де­ля­ет стан­дарт­ный на­бор управ­ляе­мых объ­ек­тов Ин­тер­не­та.

Ветвь experimental за­ре­зер­ви­ро­ва­на для це­лей тес­ти­ро­ва­ния и ис­сле­до­ва­ния.

Объ­ек­ты вет­ви private оп­ре­де­ля­ют­ся в од­но­сто­рон­нем по­ряд­ке, то есть за оп­ре­де­ле­ние объ­ек­тов этой вет­ви лю­ди и ор­га­ни­за­ции от­ве­ча­ют са­ми.

В на­стоя­щее вре­мя в суб­де­ре­ве private(4) есть од­на ветвь enterprises(1). Она ис­поль­зу­ет­ся для то­го, что­бы пре­дос­та­вить про­из­во­ди­те­лям ап­па­рат­но­го и про­грамм­ но­го обес­пе­че­ния воз­мож­ность оп­ре­де­лить свои соб­ст­вен­ные ча­стные объ­ек­ты для лю­бо­го ти­па ап­па­рат­ных или про­грамм­ных средств, ко­то­ры­ми они хо­тят управ­лять при по­мо­щи SNMP. SMI Network Management Private Enterprise Codes : D-Link (171), Cisco(9), Microsoft (311).

MIB-II

Основная цель MIB-II – предоставить общую управляющую информацию TCP/IP. MIB-II – очень важ­ная груп­па управ­ле­ния, по­то­му что ка­ж­дое уст­рой­ст­во, под­дер­жи­ваю­щее SNMP, долж­но так­же под­дер­жи­вать MIB-II .

MIB-II оп­ре­де­ле­на как iso.org.dod.internet.mgmt.1, или 1.3.6.1.2.1.

Опи­са­ние групп MIB-II
№	Имя суб­де­ре­ва	OID	Опи­са­ние
1	system	1.3.6.1.2.1.1	Оп­ре­де­ля­ет спи­сок объ­ек­тов, от­но­ся­щих­ся к ра­бо­те сис­те­мы, та­ких как вре­мя ра­бо­ты сис­те­мы, кон­такт­ная ин­фор­ма­ция и имя сис­те­мы
2	interfaces	1.3.6.1.2.1.2	От­сле­жи­ва­ет со­стоя­ние ка­ж­до­го ин­тер­фей­са на управ­ляе­мой сис­те­ме. Груп­па interfaces от­ сле­жи­ва­ет, ка­кие ин­тер­фей­сы ра­бо­та­ют и не ра­бо­та­ют, и та­кие па­ра­мет­ры, как ко­ли­че­ст­во от­прав­лен­ных и по­лу­чен­ных ок­те­тов, оши­бок и по­терь па­ке­тов и т. д.
3	at	1.3.6.1.2.1.3	Груп­па транс­ля­ции ад­ре­сов (at) ис­клю­че­на и пре­дос­тав­ля­ет­cя толь­ко для об­рат­ной со­вмес­ти­мо­сти
4	ip	1.3.6.1.2.1.4	От­сле­жи­ва­ет мно­гие ас­пек­ты IP, в том чис­ле IP-мар­шру­ти­за­цию
5	icmp	1.3.6.1.2.1.5	От­сле­жи­ва­ет ошиб­ки, по­те­ри па­ке­тов ICMP и т. д.
6	tcp	1.3.6.1.2.1.6	По­ми­мо про­че­го от­сле­жи­ва­ет со­стоя­ние TCP- со­еди­не­ния (на­при­мер, closed (за­кры­то), listen(порт про­слу­ши­ва­ет­ся), synSent (от­прав­лен па­кет syn) и т. д.)
7	udp	1.3.6.1.2.1.7	От­сле­жи­ва­ет ста­ти­сти­ку UDP, вхо­дя­щие и ис­хо­дя­щие да­та­грам­мы и т. д.
8	egp	1.3.6.1.2.1.8	От­сле­жи­ва­ет раз­лич­ную ста­ти­сти­ку про­то­ко­ла EGP (Exterior Gateway Protocol) и хра­нит таб­ли­цу со­се­дей EGP
9	cmot
10	transmission	1.3.6.1.2.1.10	В на­стоя­щее вре­мя в этой груп­пе не оп­ре­де­ле­но объ­ек­тов, но дру­гие MIB для кон­крет­ных ка­на­лов пе­ре­да­чи оп­ре­де­ля­ют­ся при по­мо­щи это­го суб­де­ре­ва
11	snmp	1.3.6.1.2.1.11	Из­ме­ря­ет про­из­во­ди­тель­ность ба­зо­вой реа­ли­за­ции SNMP на управ­ляе­мой сис­те­ме и от­сле­жи­ва­ет та­кие па­ра­мет­ры, как ко­ли­че­ст­во от­прав­лен­ных и по­лу­чен­ных SNMP-па­ке­тов

На самом деле интересны только две ветви: 1.3.6.1.2.1 = Стандартные MIBы 1.3.6.1.4.1 = MIBы специфичные для производителей

Пакет Net-SNMP

Инсталляция Net-SNMP Ubuntu

aptitude install snmp snmp-mibs-downloader

Для загрузки и подключения стандартных MIB к SNMP клиенту выполним две команды

/ usr/ bin/ download-mibs sed -i "s/^mibs/#mibs/g" / etc/ snmp/ snmp.conf

Инсталляция Net-SNMP CentOS

yum install net-snmp-utils net-snmp snmpwalk -v 2c -c public localhost

Ути­ли­та Net-SNMP snmpusm при­ме­ня­ет­ся для управ­ле­ния поль­зо­ва­те­ля­ми SNMPv3.Три ба­зо­вых опе­ра­ции SNMP – это snmpget , snmpset и snmpwalk . Их на­зна­че­ние по­нят­но из на­зва­ния: snmpget счи­ты­ва­ет зна­че­ние па­ра­мет­ра с управ­ляе­мо­го уст­рой­ст­ва, snmpset ус­та­нав­ли­ва­ет зна­че­ние па­ра­мет­ра на уст­рой­ст­ве, а snmpwalk счи­ты­ва­ет с уст­рой­ст­ва часть де­ре­ва MIB.

PHP and SNMP

Чтобы при помощи языка PHP (SNMP Функции) взаимодействовать с протоколом SNMP, должны быть установлены дополнительный пакеты:

aptitude install php5-snmp php5-cli snmp1.php "IF-MIB::ifName - The textual name of the interface.\n " ; print_r (snmp2_real_walk ($opt [ "h" ] , "public" , "IF-MIB::ifName" ) ) ; ?> $ php snmp1.php -h 192.168.10.11 IF-MIB::ifName - The textual name of the interface. Array ( [ IF-MIB::ifName.1] => STRING: lo [ IF-MIB::ifName.2] => STRING: eth0 [ IF-MIB::ifName.3] => STRING: eth1 [ IF-MIB::ifName.4] => STRING: br0 [ IF-MIB::ifName.5] => STRING: wifi0 [ IF-MIB::ifName.6] => STRING: ath0 [ IF-MIB::ifName.7] => STRING: ath1 )

Иваненко С.

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

Подобным языком стал SNMP - Simple Network Management Protocol. Разработанный для систем, ориентированных под операционную систему UNIX, он стал фактически общепринятым стандартом сетевых систем управления и поддерживается подавляющим большинством производителей сетевого оборудования в своих продуктах. В силу своего названия - Простой Протокол Сетевого Управления - основной задачей при его разработке было добиться максимальной простоты его реализации. В результате возник протокол, включающий минимальный набор команд, однако позволяющий выполнять практически весь спектр задач управления сетевыми устройствами - от получения информации о местонахождении конкретного устройства, до возможности производить его тестирование.

Основной концепцией протокола является то, что вся необходимая для управления устройством информация хранится на самом устройстве - будь то сервер, модем или маршрутизатор - в так называемой Административной Базе Данных (MIB - Management Information Base). MIB представляет из себя набор переменных, характеризующих состояние объекта управления. Эти переменные могут отражать такие параметры, как количество пакетов, обработанных устройством, состояние его интерфейсов, время функционирования устройства и т.п. Каждый производитель сетевого оборудования, помимо стандартных переменных, включает в MIB какие-либо параметры, специфичные для данного устройства. Однако, при этом не нарушается принцип представления и доступа к административной информации - все они будут переменными в MIB. Поэтому SNMP как непосредственно сетевой протокол предоставляет только набор команд для работы с переменными MIB. Этот набор включает следующие операции:

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

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

Как происходит адресация в MIB к некоторой ее переменной? По своей структуре MIB представляет из себя дерево, изображенное на рисунке 1.

Каждому элементу соответствует численный и символьный идентификатор. В имя переменной включается полный путь до нее от корневого элемента root. Например, время работы устройства с момента перезагрузки хранится в переменной, находящейся в разделе system под номером 3 и называется sysUpTime. Соответственно, имя переменной будет включать весь путь: iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysUpTime(3); или на языке чисел: 1.3.6.1.2.1.1.3. Следует заметить, что при этом узлы дерева разделяются точками. Существует стандартная ветвь MIB, относящаяся к разделу управления mgmt, которую обычно поддерживают все сетевые устройства.

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

Как уже было сказано, каждое сетевое устройство содержит в себе информацию, необходимую для управления им. Эта информация некоторым образом размещена в регистрах устройства. Как же обеспечивается доступ к этой информации некоторой сетевой рабочей станции, выполняющей задачу управления сетью? Для обработки запросов управляющей станции, приходящих в виде SNMP пакетов, служит специальный модуль, называемый Агентом Управления. Агент принимает SNMP пакеты и выполняет соответствующие им действия, т.е. посылает значение запрашиваемой переменной, устанавливает значение переменных, выполняет периодическое обновление информации MIB, выполняет в ответ на установку соответствующих переменных некоторые операции. В роли Управляющей Станции может выступать рабочая станция администратора сети, если на ней запустить какой-либо пакет управления, поддерживающий протокол SNMP. Он позволяет администратору получать конкретную информацию о какой либо стороне функционирования элементов сети, например на уровне карты Ethernet, либо протокола EGP. Примерами таких программ можно назвать Sun NetManager фирмы Sun Microsystems, ориентированный на операционную систему Solaris, и пакет SNMPc фирмы Castle Rock Computing, разработанный для системы Windows. Оба пакета позволяют строить карту сети и работать непосредственно с MIB какого-либо ее узла. Имея подобное мощное средство, администратору сети достаточно открыть документацию по MIB конкретного устройства, например маршрутизатора cisco, и изучить возможности управления, заложенные в нее разработчиками. Так, например, чтобы управлять маршрутизатором cisco, можно войти на него (сделать login пользователем root) и получить on-line доступ к его командам управления. А можно сконфигурировать на данном маршрутизаторе SNMP агента и выполнять все те же команды и получать те же результаты путем работы с переменными его MIB. Как пример такой операции можно просто перегрузить маршрутизатор путем изменения одной переменной его MIB. При этом существуют отдельные команды для загрузки системы из flash-памяти, NVRAM, или TFTP файла.

При помощи SNMP можно выполнять различные тесты функциональных возможностей сетевых устройств, определенные опять же на самих устройствах. Это бывает полезно, поскольку просто наблюдение статистики зачастую не дает полной картины происходящего. Так, например, для раздела, относящегося к интерфейсам Ethernet, определен тест TDR (Time-domain reflectometry), позволяющий определять приблизительное расстояние до повреждения в коаксиальном кабеле. Для того, чтобы запустить TDR тест необходимо установить значение переменной ifExtnsTestTypе (1.3.6.1.2.1.12.2.1.4), содержащей тип выполняемого теста, так, чтобы она содержала идентификатор теста TDR в MIB: 1.3.6.1.2.1.10.7.6.1. Результатом теста будет, во-первых, значение переменной ifExtnsTestResult (1.3.6.1.2.1.12.2.1.5), характеризующей исход теста:

отсутствие результата

выполняется

не поддерживается

невозможно запустить

прекращен

неудачное завершение

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

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

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

Отправка и прием пакетов SNMP через протокол IP.

Сбор информации о статусе и текущей конфигурации сетевых устройств.

Изменение конфигурации сетевых устройств.

В состав DES-3226S входит программа, называемая "агент", которая обрабатывает SNMP-запросы, но пользовательская программа, делающая запросы и собирающая ответы, работает на станции управления (определенный компьютер сети). SNMP-агент и пользовательская программа используют протокол UDP/IP для обмена пакетами.

SNMP Версий 1,2 и 3
DES-3226S поддерживает SNMP версии 3, также как и версии 1 и 2. Главное отличие SNMP v.3 от SNMP v.1 и SNMP v.2 в том, что SNMP v.3 предоставляет в значительной степени более высокий уровень безопасности, чем предыдущие версии.
В SNMP v.1 и SNMP v.2 авторизация пользователя выполняется посредством "строки сообщества" - Community String, которая действуют как пароль. Удаленная пользовательская программа SNMP и агент SNMP должны использовать одни и те же Community Strings. Пакеты SNMP от любой станции, которая не была авторизована, игнорируются (отбрасываются).
SNMP v.3 используют более сложный процесс авторизации, который разделяется на две части. Первая часть используется для поддержания списка пользователей и их атрибутов, которым разрешено управлять по протоколу SNMP. Вторая часть описывает, что каждый пользователь из данного списка может делать при управлении по SNMP.
Коммутатор позволяет указывать и настраивать группы пользователей в данном списке с одинаковым набором привилегий. Для указанных групп может быть установлена версия SNMP. Таким образом, можно создать группу SNMP, которой разрешено просматривать информацию, предназначенную только для чтения, или получать сообщения traps, используя SNMP v.1, в то время как другой группе назначен более высокий уровень безопасности, предоставляющий привилегии чтения/записи, посредством SNMP v.3.
Используя SNMP v.3 можно позволить или запретить индивидуальным пользователям или группам SNMP-менеджеров выполнять конкретные функции SNMP-управления. Разрешенные или запрещенные функции определяются с помощью идентификатора объекта Object Identifier (OID), ассоциированного с конкретной MIB.
Кроме того, в SNMP v.3 доступен уровень безопасности, в котором SNMP-сообщения могут быть зашифрованы (при использовании уровней авторизации HMAC-SHA-96 или HMAC-MDA-96).

Traps
Traps - это сообщения, которые предупреждают о произошедших событиях при работе коммутатора. События могут быть как серьезными типа перезагрузки (кто-то случайно отключил питание коммутатора), так и менее серьезными типа изменения состояния порта. Коммутатор генерирует traps и посылает их станции сетевого управления.
Администраторами traps являются особые пользователи локальной сети, которым представляются некоторые права и доступ к просмотру и поддержке сети. Администраторы получают отправленные коммутатором traps и должны предпринять некоторые действия для предотвращения сбоев в будущем или отключения сети.
Вы можете определить станции управления, которые могут получать traps от коммутатора. Это можно сделать путем ввода списка IP-адресов авторизованных станций сетевого управления. Вы также можете указать версию SNMP, используемую для авторизации. Можно ввести до четырех IP-адресов администраторов traps и четыре соответствующих SNMP Сommunity strings.
Ниже приводятся типы сообщений traps, которые могут получать администраторы:

• Cold Start Данное сообщение означает, что коммутатор был включен и инициализирован так, что все программные настройки были восстановлены, а аппаратные компоненты были перезагружены. "Холодный" старт отличается сброса коммутатора к заводским установкам тем, что настройки сохраняются в энергонезависимой памяти, используемой для восстановления конфигурации коммутатора.
• Warm Start Данное сообщение означает, что коммутатор был перезагружен (только программно), но тест по самодиагностике при включении питания (Power-On Self-Test - POST) был пропущен.
• Authentication Failure Данное сообщение означает, что кто-то пытается подключиться к коммутатору, используя неверную "строку сообщества" SNMP - Community string. Коммутатор автоматически запоминает IP-адрес неавторизированного пользователя.
• Topology Change Сообщение Topology Change (изменение топологии) посылается коммутатором, когда любой из его сконфигурированных портов переходит из состояния Learning в Forwarding, или из состояния Forwarding в Blocking. Данный trap не генерируется, если при том же изменении состояния порта был послан new root trap.
• Link Change Event Данное сообщение посылается каждый раз, когда состояние порта меняется с link up на link down или с link down на link up.
• Port Partition Данное сообщение посылается каждый раз, когда состояние порта изменяется на partition (порт блокируется) в результате возникновения более чем 32 коллизий на нем при работе на скорости 10 МБит/с или более чем 64 коллизий при работе на скорости 100 МБит/с.
• Broadcast\Multicast Storm Данное сообщение посылается каждый раз, когда на порту преодолевается пороговое значение пакетов широковещательной/групповой рассылки. (количество пакетов в секунду), установленное глобально для коммутатора. На каждом порту поддерживаются раздельные счетчики для широковещательных пакетов и для пакетов групповой рассылки. Пороговое значение по умолчанию равно 128 тысяч пакетов/с как для широковещательной рассылки, и так и для групповой рассылки.

MIB
Управляющая информация и параметры коммутатора хранятся в информационной базе управления (Management Information Base -MIB). Коммутатор использует стандартный модуль информационной базы управления MIB-II. Следовательно, значения входящих в MIB объектов могут быть получены с помощью любых средств сетевого управления, основанных на SNMP. Кроме стандарта MIB-II, коммутатор также поддерживает собственную MIB в виде расширенной информационной базы управления. Объекты этой MIB также могут быть получены путем указания менеджером OID MIB (Object Identifier, идентификатор объекта MIB). Значения объектов MIB могут быть как открытыми только для чтения (read-only), так и для чтения и для записи (read-write).
Объекты read-only MIB могут быть константами, которые запрограммированы в коммутаторе, или переменными, которые изменяются в процессе работы коммутатора. Примерами констант read-only являются количество портов и их типы. Примерами переменных read-only являются статистические значения, такие как количество произошедших ошибок, или сколько Кбайт данных было получено и передано через порт.
Объекты read-write MIB обычно связаны с настройками, осуществляемыми пользователем. Например, ими являются IP-адрес коммутатора, параметры Spanning Tree Algorithm, состояние порта.
Если для управления коммутатором используется система управления SNMP третьих поставщиков, то по запросу можно получить дискету, содержащую MIB коммутатора. Если эта система предоставляет функции просмотра или модификации MIB, то можно получать параметры MIB и изменять их (если атрибуты MIB допустят операцию записи). Тем не менее, процесс получения объектов MIB может быть только последовательным, поскольку нужно знать OID MIB и получать объекты один за другим.

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

Из этих цитат, вполне понятно, что запросы с типами TRAP и INFORM это не наиболее часто используемая часть SNMP. Статью для начинающих было бы более уместно иллюстрировать примерами использования гораздо более ходовых GET-запросов.

Вообще я настоятельно рекомендую ознакомиться со всеми RFC, связанными с SNMP перед началом работы. Некоторые аспекты SNMP не очевидны и имеет смысл получить о них представление из первоисточника. Начать ознакомление с материалом можно с wiki .

Первые шаги

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

1. Опрос оборудования по SNMP (аккаунтинг, мониторинг)
2. Управление оборудованием по SNMP (активация)

Задачи, связанные с опросом оборудования сводятся к формированию GET (и как будет показано далее GETNEXT) запросов. Управление оборудованием сводится к отсылке SET-запросов, изменяющих состояние соответствующих переменных на оборудовании (например, таким образом, можно отключить какой либо интерфейс).

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

Начнем писать код. В тестовом примере мы обратимся по SNMP к собственному хосту и прочитаем значение переменной, заданной OID-ом 1.3.6.1.2.1.1.3.0 и содержащей значение uptime-а хоста:

Одиночный GET-запрос

package com.acme.ae.tests.snmp; import java.io.IOException; import org.snmp4j.CommunityTarget; import org.snmp4j.PDU; import org.snmp4j.Snmp; import org.snmp4j.Target; import org.snmp4j.TransportMapping; import org.snmp4j.event.ResponseEvent; import org.snmp4j.mp.SnmpConstants; import org.snmp4j.smi.Address; import org.snmp4j.smi.GenericAddress; import org.snmp4j.smi.OID; import org.snmp4j.smi.OctetString; import org.snmp4j.smi.VariableBinding; import org.snmp4j.transport.DefaultUdpTransportMapping; public class Test { private final static String SNMP_COMMUNITY = "public"; private final static int SNMP_RETRIES = 3; private final static long SNMP_TIMEOUT = 1000L; private Snmp snmp = null; private TransportMapping transport = null; private void test() throws IOException { Target t = getTarget("udp:127.0.0.1/161"); String r = send(t, "1.3.6.1.2.1.1.3.0"); System.out.println(r); } private String send(Target target, String oid) throws IOException { PDU pdu = new PDU(); pdu.add(new VariableBinding(new OID(oid))); pdu.setType(PDU.GET); ResponseEvent event = snmp.send(pdu, target, null); if (event != null) { return event.getResponse().get(0).toString(); } else { return "Timeout exceeded"; } } private Target getTarget(String address) { Address targetAddress = GenericAddress.parse(address); CommunityTarget target = new CommunityTarget(); target.setCommunity(new OctetString(SNMP_COMMUNITY)); target.setAddress(targetAddress); target.setRetries(SNMP_RETRIES); target.setTimeout(SNMP_TIMEOUT); target.setVersion(SnmpConstants.version1); return target; } private void start() throws IOException { transport = new DefaultUdpTransportMapping(); snmp = new Snmp(transport); transport.listen(); } private void stop() throws IOException { try { if (transport != null) { transport.close(); transport = null; } } finally { if (snmp != null) { snmp.close(); snmp = null; } } } public static void main(String args) { Test t = new Test(); try { try { t.start(); t.test(); } finally { t.stop(); } } catch (IOException e) { System.out.println(e.toString()); } } }

Предварительно убедившись, что служба SNMP на нашем хосте работает и запустив код на выполнение, получим искомое значение uptime-а (времени безостановочной работы хоста с момента последней загрузки):

1.3.6.1.2.1.1.3.0 = 2:28:55.06
Используя это значение, можно осуществлять мониторинг. Если мы обнаруживаем, что значением уменьшилось - значит хост успел перезагрузиться с момента очередного опроса. Если хост не ответил в течение заданного таймаута (после нескольких автоматически сделанных попыток) это, скорее всего, означает, что хост не работает. Все просто?

Подсчитали - прослезились

Не совсем. Вспоминаем о том, что нам предстоит выполнять много запросов. Давайте промеряем, сколько запросов мы можем выполнить в секунду? Внесем небольшое исправление в код:

Private void test() throws IOException { Target t = getTarget("udp:127.0.0.1/161"); Long timestamp = System.currentTimeMillis(); for (int i = 0; i < 1000; i++) { send(t, "1.3.6.1.2.1.1.3.0"); } System.out.println(1000000L /(System.currentTimeMillis() - timestamp)); }
И запустим его на выполнение:

2463
Почти две с половиной тысячи запросов в секунду! Неплохо?

Не будем торопиться. Мы отправляем запросы на Loopback интерфейс, а он работает несколько быстрее локальной сети. Посмотрим, сколько запросов в секунду мы успеем выполнить к другому хосту в нашей сети:

182
Не дотягиваем даже до двухсот. Вообще говоря, возможно, этого будет достаточно. Все зависит от задачи. Но мы проводили измерения при условии, что опрашиваемый хост доступен. Что будет если хост не ответит?

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

Идем на рекорд

Что с этим можно сделать? Если бы мы имели дело с каким либо синхронным протоколом (например telnet), особого выбора бы у нас не было. Для того, чтобы увеличить производительность, нам пришлось бы одновременно выполнять много потоков. Но SNMP асинхронен по своей природе! Не надо насильственно втискивать его в синхронные рамки.

Как перейти к асинхронному варианту? В нашем случае, довольно просто:

Асинхронные запросы

package com.acme.ae.tests.snmp; import java.io.IOException; import org.snmp4j.CommunityTarget; import org.snmp4j.PDU; import org.snmp4j.Snmp; import org.snmp4j.Target; import org.snmp4j.TransportMapping; import org.snmp4j.event.ResponseEvent; import org.snmp4j.event.ResponseListener; import org.snmp4j.mp.SnmpConstants; import org.snmp4j.smi.Address; import org.snmp4j.smi.GenericAddress; import org.snmp4j.smi.OID; import org.snmp4j.smi.OctetString; import org.snmp4j.smi.VariableBinding; import org.snmp4j.transport.DefaultUdpTransportMapping; public class Test implements ResponseListener { private final static String SNMP_COMMUNITY = "public"; private final static int SNMP_RETRIES = 3; private final static long SNMP_TIMEOUT = 1000L; private Snmp snmp = null; private TransportMapping transport = null; public void onResponse(ResponseEvent event) { PDU response = event.getResponse(); if (response != null) { System.out.println(response.get(0).toString()); return; } } private void test() throws IOException { Target t = getTarget("udp:192.168.131.253/161"); Long timestamp = System.currentTimeMillis(); for (int i = 0; i < 1000; i++) { send(t, "1.3.6.1.2.1.1.3.0"); } System.out.println(1000000L /(System.currentTimeMillis() - timestamp)); } private void send(Target target, String oid) throws IOException { PDU pdu = new PDU(); pdu.add(new VariableBinding(new OID(oid))); pdu.setType(PDU.GET); snmp.send(pdu, target, null, this); } private Target getTarget(String address) { Address targetAddress = GenericAddress.parse(address); CommunityTarget target = new CommunityTarget(); target.setCommunity(new OctetString(SNMP_COMMUNITY)); target.setAddress(targetAddress); target.setRetries(SNMP_RETRIES); target.setTimeout(SNMP_TIMEOUT); target.setVersion(SnmpConstants.version1); return target; } private void start() throws IOException { transport = new DefaultUdpTransportMapping(); snmp = new Snmp(transport); transport.listen(); } private void stop() throws IOException { try { if (transport != null) { transport.close(); transport = null; } } finally { if (snmp != null) { snmp.close(); snmp = null; } } } public static void main(String args) { Test t = new Test(); try { try { t.start(); t.test(); } finally { t.stop(); } } catch (IOException e) { System.out.println(e.toString()); } } }

7142
Запросы все равно что проваливаются в бездонную бочку! Разумеется, ответы будут приходить с задержкой, но приходить они будут тоже довольно быстро. Но как мы узнаем, что хост не ответил?

Очень просто, по истечении заданного количества попыток и таймаутов, SNMP4J вернет нам event, response в котором будет равен null:

Исправленный вариант

requests = new HashSet(); private Long firstTimestamp = null; private long lastTimestamp; public void onResponse(ResponseEvent event) { Integer32 requestId = event.getRequest().getRequestID(); PDU response = event.getResponse(); if (response != null) { lastTimestamp = System.currentTimeMillis(); if (firstTimestamp == null) { firstTimestamp = lastTimestamp; } return; } else { synchronized (requests) { if (requests.contains(requestId)) { System.out.println("Timeout exceeded"); } } } synchronized (requests) { requests.remove(requestId); } } private void test() throws IOException { Target t = getTarget("udp:192.168.131.253/161"); Long timestamp = System.currentTimeMillis(); for (int i = 0; i < 1000; i++) { send(t, "1.3.6.1.2.1.1.3.0"); } System.out.println(1000000L /(System.currentTimeMillis() - timestamp)); while (!requests.isEmpty()) { try { Thread.sleep(1000L); } catch (InterruptedException e) { e.printStackTrace(); } } if (firstTimestamp != null) { System.out.println(1000000L /(lastTimestamp - firstTimestamp)); } } private void send(Target target, String oid) throws IOException { PDU pdu = new PDU(); pdu.add(new VariableBinding(new OID(oid))); pdu.setType(PDU.GET); snmp.send(pdu, target, null, this); synchronized (requests) { requests.add(pdu.getRequestID()); } } private Target getTarget(String address) { Address targetAddress = GenericAddress.parse(address); CommunityTarget target = new CommunityTarget(); target.setCommunity(new OctetString(SNMP_COMMUNITY)); target.setAddress(targetAddress); target.setRetries(SNMP_RETRIES); target.setTimeout(SNMP_TIMEOUT); target.setVersion(SnmpConstants.version1); return target; } private void start() throws IOException { transport = new DefaultUdpTransportMapping(); snmp = new Snmp(transport); transport.listen(); } private void stop() throws IOException { try { if (transport != null) { transport.close(); transport = null; } } finally { if (snmp != null) { snmp.close(); snmp = null; } } } public static void main(String args) { Test t = new Test(); try { try { t.start(); t.test(); } finally { t.stop(); } } catch (IOException e) { System.out.println(e.toString()); } } }

Проанализируем результат выполнения:

9174 283
Мы успеваем сформировать 9174 запросов в секунду, а опрашиваемое устройство успевает обрабатывать запросы со скоростью 283 запроса в секунду. На большую часть запросов оно ответить не успевает (соответственно в логе остаются сообщения «Timeout exceeded»). Разумеется, это не будет проблемой когда мы начнем опрашивать большое количество устройств с разумным интервалом между запросами.

Идем далее

Мы научились получать по SNMP значения скалярных переменных. Но, помимо них, в SNMP есть еще и таблицы (например таблица интерфейсов на устройстве). Как они устроены? Посмотрим MIB-browser:

В OID mgmt.interfaces (1.3.6.1.2.1.2) мы видим скалярную переменную ifNumber (1.3.6.1.2.1.2.1), содержащую количество интерфейсов в таблице, а также набор столбцов. Каждый из столбцов имеет собственный OID. Например столбец содержащий числовой индекс ifIndex интерфейса имеет OID = 1.3.6.1.2.1.2.2.1.1.

Для того, чтобы получить значение этой переменной, необходимо добавить к OID-у индекс интерфейса (например для интерфейса с индексом 123 OID = 1.3.6.1.2.1.2.2.1.1.123). Но как нам получить индексы интерфейсов? Они совсем не обязательно идут по порядку! Например, на моей машине, таблица интерфейсов выглядит так:

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

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

Следует заметить, что довольно удобно то, что OID-ы скалярных переменных также представляют собой префиксы. Например, для переменной sysUpTime OID, на самом деле равен 1.3.6.1.2.1.1.3. Мы можем передать его в GETNEXT запрос и получить OID = 1.3.6.1.2.1.1.3.0 вместе с соответствующим значением. Это дает возможность запрашивать скалярные значения вместе с значениями столбцов таблиц, в одном запросе.

Просмотр первой строки таблицы

package com.acme.ae.tests.snmp; import java.io.IOException; import java.util.HashSet; import java.util.Set; import org.snmp4j.CommunityTarget; import org.snmp4j.PDU; import org.snmp4j.Snmp; import org.snmp4j.Target; import org.snmp4j.TransportMapping; import org.snmp4j.event.ResponseEvent; import org.snmp4j.event.ResponseListener; import org.snmp4j.mp.SnmpConstants; import org.snmp4j.smi.Address; import org.snmp4j.smi.GenericAddress; import org.snmp4j.smi.Integer32; import org.snmp4j.smi.OID; import org.snmp4j.smi.OctetString; import org.snmp4j.smi.VariableBinding; import org.snmp4j.transport.DefaultUdpTransportMapping; public class Test implements ResponseListener { private final static String SNMP_COMMUNITY = "public"; private final static int SNMP_RETRIES = 3; private final static long SNMP_TIMEOUT = 1000L; private Snmp snmp = null; private TransportMapping transport = null; private Set requests = new HashSet(); public void onResponse(ResponseEvent event) { Integer32 requestId = event.getRequest().getRequestID(); PDU response = event.getResponse(); if (response != null) { System.out.println(response.toString()); return; } else { synchronized (requests) { if (requests.contains(requestId)) { System.out.println("Timeout exceeded"); } } } synchronized (requests) { requests.remove(requestId); } } private void test() throws IOException { Target t = getTarget("udp:127.0.0.1/161"); send(t, new String {"1.3.6.1.2.1.1.3", "1.3.6.1.2.1.2.2.1.1", "1.3.6.1.2.1.2.2.1.2"}); } private void send(Target target, String oids) throws IOException { PDU pdu = new PDU(); for (String oid: oids) { pdu.add(new VariableBinding(new OID(oid))); } pdu.setType(PDU.GETNEXT); ResponseEvent event = snmp.send(pdu, target, null); synchronized (requests) { requests.add(pdu.getRequestID()); } onResponse(event); } private Target getTarget(String address) { Address targetAddress = GenericAddress.parse(address); CommunityTarget target = new CommunityTarget(); target.setCommunity(new OctetString(SNMP_COMMUNITY)); target.setAddress(targetAddress); target.setRetries(SNMP_RETRIES); target.setTimeout(SNMP_TIMEOUT); target.setVersion(SnmpConstants.version1); return target; } private void start() throws IOException { transport = new DefaultUdpTransportMapping(); snmp = new Snmp(transport); transport.listen(); } private void stop() throws IOException { try { if (transport != null) { transport.close(); transport = null; } } finally { if (snmp != null) { snmp.close(); snmp = null; } } } public static void main(String args) { Test t = new Test(); try { try { t.start(); t.test(); } finally { t.stop(); } } catch (IOException e) { System.out.println(e.toString()); } } }

Запустив этот код на выполнение, мы получим следующий response:

RESPONSE]
Мы получили значение uptime-а, индекс первого интерфейса и его имя, закодированное строкой октетов в шестнадцатеричном представлении. Чтобы получить следующие строки, мы должны выполнять последовательные запросы, передавая ранее полученные OID-ы.

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

BULK-запрос

package com.acme.ae.tests.snmp; import java.io.IOException; import java.util.HashSet; import java.util.Set; import org.snmp4j.CommunityTarget; import org.snmp4j.PDU; import org.snmp4j.Snmp; import org.snmp4j.Target; import org.snmp4j.TransportMapping; import org.snmp4j.event.ResponseEvent; import org.snmp4j.event.ResponseListener; import org.snmp4j.mp.SnmpConstants; import org.snmp4j.smi.Address; import org.snmp4j.smi.GenericAddress; import org.snmp4j.smi.Integer32; import org.snmp4j.smi.OID; import org.snmp4j.smi.OctetString; import org.snmp4j.smi.VariableBinding; import org.snmp4j.transport.DefaultUdpTransportMapping; public class Test implements ResponseListener { private final static String SNMP_COMMUNITY = "public"; private final static int SNMP_RETRIES = 3; private final static long SNMP_TIMEOUT = 1000L; private final static int BULK_SIZE = 50; private Snmp snmp = null; private TransportMapping transport = null; private Set requests = new HashSet(); public void onResponse(ResponseEvent event) { Integer32 requestId = event.getRequest().getRequestID(); PDU response = event.getResponse(); if (response != null) { System.out.println(response.toString()); return; } else { synchronized (requests) { if (requests.contains(requestId)) { System.out.println("Timeout exceeded"); } } } synchronized (requests) { requests.remove(requestId); } } private void test() throws IOException { Target t = getTarget("udp:127.0.0.1/161"); send(t, new String {"1.3.6.1.2.1.1.3", "1.3.6.1.2.1.2.2.1.1", "1.3.6.1.2.1.2.2.1.2"}); } private void send(Target target, String oids) throws IOException { PDU pdu = new PDU(); for (String oid: oids) { pdu.add(new VariableBinding(new OID(oid))); } pdu.setType(PDU.GETBULK); pdu.setMaxRepetitions(BULK_SIZE); pdu.setNonRepeaters(1); ResponseEvent event = snmp.send(pdu, target, null); synchronized (requests) { requests.add(pdu.getRequestID()); } onResponse(event); } private Target getTarget(String address) { Address targetAddress = GenericAddress.parse(address); CommunityTarget target = new CommunityTarget(); target.setCommunity(new OctetString(SNMP_COMMUNITY)); target.setAddress(targetAddress); target.setRetries(SNMP_RETRIES); target.setTimeout(SNMP_TIMEOUT); target.setVersion(SnmpConstants.version2c); return target; } private void start() throws IOException { transport = new DefaultUdpTransportMapping(); snmp = new Snmp(transport); transport.listen(); } private void stop() throws IOException { try { if (transport != null) { transport.close(); transport = null; } } finally { if (snmp != null) { snmp.close(); snmp = null; } } } public static void main(String args) { Test t = new Test(); try { try { t.start(); t.test(); } finally { t.stop(); } } catch (IOException e) { System.out.println(e.toString()); } } }

Выполнив этот запрос, мы получаем все строки таблицы одним запросом:

Много данных

RESPONSE]

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

О чем я не рассказал?

В этой статье я не рассказал о многом. Я не рассказал о том, как изменять значения некоторых (не всех) переменных SET-запросами. Я не рассказал о том, что такое TRAP-ы и для чего они нужны. Я ни сказал ни слова о том, как разрабатывать SNMP-агенты. И я ни одним словом не обмолвился о 3-ей версии SNMP и привнесенных ей изменениях.

Но даже того о чем я сказал вполне достаточно, чтобы понять, что SNMP - это не просто.