Snmp протокол принципы, безопасность, применение


Содержание

Описание протокола SNMP (Simple Network Management Protocol)

Через 20 лет в детском саду (или в детском чате) мальчик спрашивает девочку: — A твои родители в каком чате познакомились?

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

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

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:

  • 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

Как рекомендовалось в ISS scanner’е, можно выключить эту порцию SNMP mibs таким способом:

  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 для хакеров :)

Лучший способ защиты по рекомендации M$: заблокировать SNMP access на firewall’е.

Проблема в 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 могут детектировать эту проблемы, т.е. посмотреть можно и в их исходниках

Copyright © 2004-2020 «Delphi Sources». Delphi World FAQ

Что это — SNMP? Простой протокол сетевого управления

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

Что собой представляет SNMP? Расшифровывается данная аббревиатура как Simple Network Management Protocol. Если переводить дословно это значит «простой протокол сетевого управления». Данный стандарт можно отнести к числу наиболее распространенных из тех, что задействуется с целью управления различными устройствами в IP-сетях, функционирующих на базе архитектуры TCP/IP,например, коммутаторами, роутерами, сетевыми принтерами, рабочими станциями. Чаще всего рассматриваемый протокол используется в тех случаях, когда инфраструктура предполагает осуществление контроля устройств, подключенных к сети, на предмет выполнения заданных администратором условий. Структура сведений, оборот которых осуществляется в рамках протокола SNMP, включает в себя и те, которые представлены в виде переменных. С помощью них можно описать конфигурацию объекта управления, который находится в сетевой системе. При помощи управляющих приложений могут запрашиваться, а в ряде случаев и задаваться соответствующие переменные.

SNMP: возможности

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

SNMP: основные компоненты

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

— управляемый объект – приложение или компьютер, на которые администратор сети задает те или иные команды с использованием протокола;

— база данных MIB;

— система обеспечения сетевого взаимодействия.

Управляемый объект может не только получать команды от администратора, но также и направлять их в соответствии с заданными параметрами. Данные с объекта будут передаваться на программу-менеджер, которая будет интерпретировать их по установленным алгоритмам. На управляемом девайсе в свою очередь функционирует приложение-агент. Оно предназначено для сбора информации по соответствующему устройству. При необходимости оно может транслировать ее в формате, который адаптирован к специфике протокола SNMP. Сама по себе система обеспечения сетевого взаимодействия дает администратору возможность работать одновременно с несколькими программами-менеджерами с целью осуществления контроля над функционированием инфраструктуры. Также в сетях может быть инсталлировано несколько разновидностей программного обеспечения соответствующего типа. Ключевым, и возможно важнейшим элементом протокола SNMP является MIB или по-другому база управляющих сведений. Предназначение данного элемента состоит в описании структуры данных, обмен которыми производится в процессе управления устройствами. Соответствующая база данных фактически позволяет разместить информацию о том, что задействуется для управления устройством непосредственно на нем, будь то сервер, модем или сетевая плата. SNMP представляет собой универсальный протокол. Его функциональность во многом можно реализовать благодаря возможностям базы данных MIB. В устройствах, которые совместимы с данной технологией, могут содержаться как стандартные переменные, так и те переменные, которые характеризуют особенности отдельного устройства. Основным элементом данной базы являются идентификаторы типа OID.Они дают возможность устанавливать переменные, которые определяются и считываются при помощи протокола SMNP. Приложение-агент, которое является компонентом сетевой инфраструктуры SMNP, обычно получает запросы с использованием порта 161. Программа-менеджер в свою очередь может задействовать любые доступные в сети порты. Обычно данный тип программного обеспечения получает уведомления на порт 162. Давайте рассмотрим основные инструменты, которые могут использоваться протоколом при SNMP в работе. К таким инструментам можно отнести программу-менеджер.

Программа-менеджер: основные возможности

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

Какое программное обеспечение используется для управления сетью по протоколу SNMP?

Какие же программы можно использовать в качестве управляющих? В принципе, существуют решения, которые уже адаптированы к внедрению в различных операционных системах протокола SMTP – Windows, Solaris. Если говорить о программном обеспечении для операционной системы Windows, то в числе наиболее популярных программ, работающих в данной операционной системе и использующих протокол SMTP, есть пакет, выпущенный разработчиком Castle Rock Computing. Для Solaris в свою очередь было разработано другое довольно эффективное решение.Речь идет о Sun Net Manager.При помощи обоих этих вариантов можно построить эффективную карту сети, базирующуюся на протоколе SNMP. Также они позволяют выполнить прямую коммуникацию с MIB. В рамках соответствующих интерфейсов можно осуществлять управление маршрутизаторами различных брендов, которые осуществляют поддержку протокола SNMP, в частности Cisco. Современные производители сетевых устройств, как правило, выпускают документацию по MIB для того или иного устройства. Именно в документации будут отражены все возможности управления соответствующими компонентами инфраструктуры в рамках сети. Еще одним популярным способом решения проблемы управления сетевыми устройствами является Zabbix. SNMP это протокол, который также задействует данная программа. Данное решение обладает широким набором функций. В части применения SNMP оно позволяет осуществлять эффективный мониторинг сетевых процессов. Обмен данным в рамках протокола SNMP осуществляется при помощи специальных сообщений. Давайте более подробно рассмотрим их специфику.

Особенности сообщений SNMP

К основным сообщениям, обмен которыми может инициировать сервер администратора посредством протокола SNMP, относятся следующие команды:

— Get Bulk Request;

— Get Next Request;

Сущность первой команды состоит в отправке запроса от программы-менеджера к приложению-агенту для получения того или иного значения по переменной. Программа-менеджер в свою очередь получает ответ с определенными значениями. Специфика второй команды состоит в отправке сообщения также от программы-менеджера к приложению-агенту. В данном случае это необходимо для корректировки переменной – одной или по списку. Приложение-агент осуществляет прием изменений, а после этого направляет программе-менеджеру новые значения по одним или другим переменным. Суть команды Get Next Request состоит в отправке запроса от программы-менеджера к приложению агенту для обнаружения на устройстве всех доступных переменных, а также установленных для них значений. Приложение агент в свою очередь возвращает ответ, в котором содержится значение одной переменной, а также ссылка на следующую позицию в списке. Следующий запрос предлагает передачу данных, которые отражают сведения по следующей переменной, а также ссылку на идущую далее в очереди. Алгоритм оборота данных в дальнейшем при использовании рассматриваемой команды SNMP повторяется. Специфика команды Get Bulk Request состоит в том, что, по сути, она представляет собой модернизированную версию сообщения GetNextRequest. Данная команда предполагает, что приложение-агент направит ответ программе-менеджеру. Этот ответ должен содержать данные по нескольким переменным одновременно, начиная с той, что была представлена в начальном запросе. Смысл команды Response состоит в осуществлении процедуры возврата связанной переменной, а также значений от приложения-агента к программе-менеджеру при использовании рассмотренных выше четырех типов сообщений. Посредством соответствующей команды при этом между устройствами осуществляется обмен информацией об ошибке. Специфика команды Trap состоит в осуществлении передачи сообщений от приложения-агента без предварительного запроса со стороны программы-менеджера. В структуре данного сообщения присутствует текущее значение по переменной. Стоит отметить, что в данном случае получатель команды определяется при помощи особых конфигураций в рамках базы MIB. Суть команды Inform Request состоит в том, что фактически она соответствует уведомлению об отправке сообщения от программы-менеджера к приложению-агенту и наоборот. Применение данной команды обусловлено тем, что в ряде случаев в сетевой инфраструктуре те или иные сообщения могут доставляться некорректно. По сути, команда Inform Request подтверждает факт успешной передачи команды от одного устройства к другому. Во многих случаях корректная настройка SNMP требует от администратора повышенного внимания к проверке функциональности MIB. Давайте рассмотрим, в чем же состоят ее особенности

MIB: особенности функционирования

В рамках функционирования базы MIB ключевой процедурой является адресация переменных. Она осуществляется с учетом структуры рассматриваемого компонента протокола SNMP.MIB выглядит как древообразная схема, которая состоит из нескольких элементов. К каждому из этих элементов прикреплен особый идентификатор. В рамках базы MIB имя переменной отражает адрес до нее, начиная от корневого каталога. В самой структуре переменной могут быть различные сведения, например, информация о времени работы устройства. Также в MIB могут присутствовать как стандартные ветви, поддерживаемые большинством устройств, так и те, которые добавлены производителем устройства или организацией, в которой планируется внедрять инфраструктуру компьютерной сети. В данном случае правильно будет разместить соответствующие наборы переменных. Если они внедряются в структуру MIB временно, то есть смысл разместить их в разделе Experimental. Перед утверждением структуры базы данных необходимо присвоить набору переменных отдельный номер. Для этой цели используется раздел private-enterprises. Это даст возможность инженерам или администраторам сети, в компетенции которых присутствует SNMP-мониторинг, открыть новую ветвь в структуре MIB для размещения переменных только от своей компании.

SNMP: история появления

Вам должно быть будет интересно ознакомиться с историей разработки SNMP.Основной программной средой, в которой сегодня используется протокол SNMP, является Windows.Разработка была инициирована еще в 1988 году, задолго до того, как операционная система от компании Microsoft начала завоевывать рынки. Изначально SNMP разрабатывался для семейства операционных систем UNIX, предназначенных для решения широкого круга задач по обеспечению функциональности компьютерных сетей. К этому моменту многие эксперты видели потенциал операционной системы Windows. Не исключено, что разработка универсального сетевого протокола во многом была предопределена фактом потенциального роста популярности новой операционной системы. Имеется и еще один важный фактор, который сыграл важную роль в ускорении работы над SNMP — Web. Уже то время появились первые онлайн сервисы. Экспертам сразу было понятно, что впереди их ждет активная интеграция сетевых интерфейсов в глобальном масштабе. Крупнейшие производители сетевых устройств так или иначе в 1988 пришли к выводу, что им необходимо разработать универсальный набор средств для управления устройствами. Фирмы к этому моменту уже выпускали собственные решения для мониторинга и конфигурирования девайсов. Поэтому была необходима некоторая унификация.

Разработка SNMP: инструкции

В 1988 году предприятия, которые занимались выпуском сетевого оборудования, пришли к единому мнению. При разработке нового протокола были применены некоторые действующие концепции. Специалисты, которые совместно работали над данным протоколом, выявили три ключевых документа: RFC 1065, 1066, 1067.В результате они были дополнены и появились новые – RFC 1155, 1156, 1157. Данные источники были несколько переработаны. В 1991 году на их основе была выпущена первая версия протокола SNMP. Документ RFC 1155 содержал в себе инструкции, которые определяли, в какой структуре должна быть отражена управляющая информация и какими должны быть основные принципы применения синтаксиса при определении имен для переменных. Документ RFC 1155 в части синтаксиса переменных был дополнен источником RFC 1212. На момент утверждения протокола SMNP был разработан целый ряд новых документов, вроде RFC 1213. Здесь был отражен список ключевых переменных, при помощи которых должна была осуществляться конфигурация сетевой инфраструктуры. В источнике RFC 1157 содержались параметры, необходимые для определения команд, при помощи которых управляемый объект и сервер могли взаимодействовать, а также для осуществления обмена сообщениями trap. Как только был введен и опубликован протокол SNMP, сетевая карта, адаптер, сервер и в принципе любое устройство, входящее в инфраструктуру сети, могло стать объектом управления осуществляемого в рамках стандартных процедур. Введение протокола SNMP стало серьезным фактором роста рынка сетевого оборудования. Благодаря стандартизации стало возможным внедрение новых интерфейсов в самых широких масштабах новых интерфейсов, таких как FDDI и Ethernet.

Заключение

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

Что это — SNMP? Простой протокол сетевого управления

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

Что представляет собой протокол SNMP?

Для начала изучим основные сведения о рассматриваемой технологии. Что это — SNMP? Данная аббревиатура расшифровывается как Simple Network Management Protocol, и означает «Простой протокол сетевого управления». Данный стандарт относится к числу самых распространенных, что задействуются в целях управления различными девайсами в IP-сетях, функционирующих на базе архитектуры TCP/IP. Например, роутерами, коммутаторами, рабочими станциями, сетевыми принтерами.

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

Возможности SNMP

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

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

SNMP: основные компоненты

SNMP — протокол, который предполагает задействование нескольких сетевых компонентов. К основным можно отнести:

— управляемый объект — компьютер или приложение, на которое отправляет те или иные команды с использованием протокола, о котором идет речь, администратор сети;

— база данных MIB;

— система обеспечения сетевого взаимодействия.

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

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

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

В девайсах, совместимых с данной технологией, содержатся как стандартные переменные, так и те, что характеризуют особенности отдельного устройства. Основные элементы данной базы — идентификаторы типа OID. Они позволяют устанавливать переменные, которые считываются или же определяются посредством протокола SMNP.

Приложение-агент, являющееся компонентом сетевой инфраструктуры SMNP, обычно получает запросы с использованием порта 161. В свою очередь, программа-менеджер может задействовать любые порты, доступные в сети. При этом уведомления данный тип ПО получает обычно на порт 162.

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

Программа-менеджер в рамках протокола SNMP: основные возможности

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

Илон Маск рекомендует:  Что такое код gmstrftime

Какое ПО применяется для управления сетью по протоколу SNMP?

Какие конкретно программы могут использоваться в качестве управляющих? В принципе, есть решения, адаптированные к внедрению в самых разных операционных системах протокола SNMP — Windows, Solaris. Если говорить о ПО для Windows, то в числе популярных, работающих в данной ОС и задействующих SNMP, — пакет, выпущенный Castle Rock Computing. В свою очередь, для Solaris разработано другое эффективное решение — Sun NetManager. Посредством обоих вариантов может быть выстроена эффективная базирующаяся на протоколе SNMP карта сети. Кроме того, они позволяют осуществлять прямую коммуникацию с MIB.

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

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

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

Особенности SNMP-сообщений

К основным сообщениям, обмен которыми может инициировать посредством протокола SNMP сервер администратора, относятся такие команды, как:

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

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

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

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

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

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

Сущность 7-й команды заключается в том, что она, фактически, соответствует уведомлению об отправке сообщения от программы-менеджера к приложению-агенту и наоборот. Ее применение обусловлено тем, что в сетевой инфраструктуре те или иные сообщения в ряде случаев могут доставляться некорректно. Команда InformRequest, по сути, подтверждает факт успешной передачи команды от одного девайса к другому.


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

MIB: особенности функционирования базы

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

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

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

История появления SMNP

Интересно будет изучить сведения об истории разработки SNMP. Основная программная среда, в которой сейчас задействуется протокол SNMP — Windows. Однако, инициирована была его разработка еще в 1988 году — задолго до того, как операционная система от Microsoft, представленная в привычных интерфейсах, начала завоевывать рынки. Фактически, изначально SNMP разрабатывался для UNIX — семейства операционных систем, предназначенных для решения широкого круга задач по обеспечению функциональности различных компьютерных сетей. Хотя, безусловно, к тому моменту многие эксперты видели потенциал Windows, и не исключено, что разработка универсального сетевого протокола была во многом предопределена фактом потенциального роста популярности новой операционной системы.

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

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

Разработка SNMP: основные инструкции

В августе 1988 года предприятия, выпускающие сетевое оборудование, пришли к консенсусу. В процессе разработки нового протокола были применены некоторые уже действовавшие концепции. Специалисты, которые проводили совместную работу, выявили 3 ключевых документа: RFC 1065, 1066, а также 1067. Впоследствии они были дополнены, и появились новые — RFC 1155, 1156, а также 1157. Данные источники были переработаны, и в 1991 году на их основе была выпущена первая версия протокола SNMP.

Так, документ RFC 1155 содержал в себе инструкции, определяющие:

— то, в какой структуре должна отражаться управляющая информация;

— то, каковы основные принципы применения синтаксиса при определении имен для переменных.

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

Источник RFC 1157 содержал параметры, необходимые для:

— определения команд, посредством которых сервер и управляемый объект могли взаимодействовать между собой;

— осуществления обмена trap-сообщениями.

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

Резюме

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

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

— запросы одного или нескольких параметров MIB;

— последовательное прочтение различных значений по тем или иным параметрам, например, табличным;

— установка конкретных значений для одной или же нескольких переменных MIB;

— возврат девайсом ответа на тот или иной запрос другого устройства;

— отправка уведомительных сообщений о тех или иных сетевых процессах.

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

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

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

Управление компьютерами сети может осуществляться с главного сервера. Для этого может быть задействована специальная программа, например, Zabbix. SNMP — протокол, поддерживаемый программами, способными работать в разных операционных системах. Изначально SNMP разрабатывался для UNIX, но были созданы виды ПО, которые позволили его применять в ОС Windows, Sun Solaris.

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

Почему SNMP это не очень просто?

Читаем документацию

The strategy implicit in the SNMP is that the monitoring of network state at any significant level of detail is accomplished primarily by polling for appropriate information on the part of the monitoring center(s). A limited number of unsolicited messages (traps) guide the timing and focus of the polling. Limiting the number of unsolicited messages is consistent with the goal of simplicity and
minimizing the amount of traffic generated by the network management function.

Для тех, у кого сложности с английским языком, имеется русский перевод:

Стратегия 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-а хоста:

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

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

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

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

И запустим его на выполнение:

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

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

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

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

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

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

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

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

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

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

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

Идем далее

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

В O >
Для того, чтобы получить значение этой переменной, необходимо добавить к O >

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

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

Следует заметить, что довольно удобно то, что O >

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

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

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

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

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

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

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

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

4.4.13 Протокол управления SNMP


Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)

Номер раздела Название раздела Объем в страницах Объем в кбайт
4.4.13.1 Управляющая база данных MIB 27 118
4.4.13.2 Нотация ASN.1 19 63
Итого

Интернет — гигантская сеть. Напрашивается вопрос, как она сохраняет свою целостность и функциональность без единого управления? Если же учесть разнородность ЭВМ, маршрутизаторов и программного обеспечения, используемых в сети, само существование Интернет представится просто чудом. Так как же решаются проблемы управления в Интернет? Отчасти на этот вопрос уже дан ответ — сеть сохраняет работоспособность за счет жесткой протокольной регламентации. «Запас прочности» заложен в самих протоколах. Функции диагностики возложены, как было сказано выше, на протокол ICMP. Учитывая важность функции управления, для этих целей создано два протокола SNMP (Simple Network Management Protocol, RFC-1157, -1215, -1187, -1089, std-15 разработан в 1988 году) и CMOT (Common Management Information services and protocol over TCP/IP, RFC-1095, в последнее время применение этого протокола ограничено). Обычно управляющая прикладная программа воздействует на сеть по цепочке SNMP-UDP-IP-Ethernet. Наиболее важным объектом управления обычно является внешний порт сети (gateway) или маршрутизатор сети. Каждому управляемому объекту присваивается уникальный идентификатор.

Протокол SNMP работает на базе транспортных возможностей UDP (возможны реализации и на основе ТСР) и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении в сети Интернет. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При своей работе SNMP использует управляющую базу данных (MIB — management information base, RFC-1213, -1212, std-17). Смотри Essential SNMP. Douglas R. Mauro and Kevin J. Schmidt. O’Reilly, Второе издание. 2001. На русском языке книга вышла под название Основы SNMP в 2012 г в изд. Символ, Петербург (перевод Р. Багаутдинова, научным редактором перевода был я).

Алгоритмы управления в Интернет обычно описывают в нотации ASN.1 (Abstract Syntax Notation). Все объекты в Интернет разделены на 10 групп и описаны в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу «система» входит название и версия оборудования, операционной системы, сетевого программного обеспечения и пр.. В группу «интерфейсы» входит число поддерживаемых интерфейсов, тип интерфейса, работающего под IP (Ethernet, LAPB etc.), размер дейтограмм, скорость обмена, адрес интерфейса. IP-группа включает в себя время жизни дейтограмм, информация о фрагментации, маски субсетей и т.д. В TCP-группу входит алгоритм повторной пересылки, максимальное число повторных пересылок и пр.. Ниже приведена таблица (4.4.13.1) команд (pdu — protocol data unit) SNMP:

Таблица 4.4.13.1 Команды SNMP

Команда SNMP Тип PDU Назначение
GET-request Получить значение указанной переменной или информацию о состоянии сетевого элемента;
GET_next_request 1 Получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB);
SET-request 2 Присвоить переменной соответствующее значение. Используется для описания действия, которое должно быть выполнено;
GET response 3 Отклик на GET-request, GET_next_request и SET-request. Содержит также информацию о состоянии (коды ошибок и другие данные);
TRAP 4 Отклик сетевого объекта на событие или на изменение состояния.
GetBulkRequest 5 Запрос пересылки больших объемов данных, например, таблиц.
InformRequest 6 Менеджер обращает внимание партнера на определенную информацию в MIB.
SNMPv3-Trap 7 Отклик на событие (расширение по отношению v1 и v2).
Report 8 Отчет (функция пока не задана).

Рис. 4.4.13.1 Схема запросов/откликов SNMP

Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы, имеет вид (рис. 4.4.13.2):

Рис. 4.4.13.2 Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы

Поле версия содержит значение, равное номеру версии SNMP минус один. Поле пароль (community — определяет группу доступа) содержит последовательность символов, которая является пропуском при взаимодействии менеджера и объекта управления. Обычно это поле содержит 6-байтовую строку public, что означает общедоступность. Для запросов GET, GET-next и SET значение идентификатора запроса устанавливается менеджером и возвращается объектом управления в отклике GET, что позволяет связывать в пары запросы и отклики. Поле фирма (enterprise) = sysobjectid объекта. Поле статус ошибки характеризуется целым числом, присланным объектом управления:

Таблица 4.4.13.2. Номера и назначения используемых портов

Назначение Порт Пояснение
SNMP 161/TCP Simple Network Management Protocol
SNMP 162/TCP Trap
SMUX 199/TCP SNMP Unix Multiplexer
SMUX 199/UDP SNMP Unix Multiplexer
synoptics-relay 391/TCP SynOptics SNMP Relay Port
synoptics-relay 391/UDP SynOptics SNMP Relay Port
agentx 705/TCP AgentX
snmp-tcp-port 1993/TCP cisco SNMP TCP port
snmp-tcp-port 1993/UDP cisco SNMP TCP port

Таблица 4.4.13.3. Коды ошибок

Статус ошибки Имя ошибки Описание
Noerror Все в порядке;
1 Toobig Объект не может уложить отклик в одно сообщение;
2 Nosuchname В операции указана неизвестная переменная;
3 badvalue В команде set использована недопустимая величина или неправильный синтаксис;
4 Readonly Менеджер попытался изменить константу;
5 Generr Прочие ошибки.

Если произошла ошибка, поле индекс ошибки (error index) характеризует, к какой из переменных это относится. error index является указателем переменной и устанавливается объектом управления не равным нулю для ошибок badvalue, readonly и nosuchname. Для оператора TRAP (тип PDU=4) формат сообщения меняется. Таблица типов TRAP представлена ниже (4.4.13.4):

Таблица 4.4.13.4. Коды TRAP

Тип TRAP Имя TRAP Описание
Coldstart Установка начального состояния объекта.
1 Warmstart Восстановление начального состояния объекта.
2 Linkdown Интерфейс выключился. Первая переменная в сообщении идентифицирует интерфейс.
3 Linkup Интерфейс включился. Первая переменная в сообщении идентифицирует интерфейс.
4 Authenticationfailure От менеджера получено snmp-сообщение с неверным паролем (community).
5 EGPneighborloss EGP-партнер отключился. Первая переменная в сообщении определяет IP-адрес партнера.
6 Entrprisespecific Информация о TRAP содержится в поле специальный код.

Для тип TRAP 0-4 поле специальный код должно быть равно нулю. Поле временная метка содержит число сотых долей секунды (число тиков) с момента инициализации объекта управления. Так прерывание coldstart выдается объектом через 200 мс после инициализации.

В последнее время широкое распространение получила идеология распределенного протокольного интерфейса DPI (Distributed Protocol Interface). Для транспортировки snmp-запросов может использоваться не только UDP-, но и TCP-протокол. Это дает возможность применять SNMP-протокол не только в локальных сетях. Форматы SNMP-DPI-запросов (версия 2.0) описаны в документе RFC-1592. Пример заголовка snmp-запроса (изображенные поля образуют единый массив; см. рис. 4.4.13.3):

Рис. 4.4.13.3. Формат заголовка SNMP-запроса

Поле Флаг =0x30 является признаком ASN.1-заголовка. Коды Ln — представляют собой длины полей, начинающиеся с байта, который следует за кодом длины, вплоть до конца сообщения-запроса (n — номер поля длины), если не оговорено другое. Так L1 — длина пакета-запроса, начиная с T1 и до конца пакета, а L3 — длина поля пароля. Субполя Tn — поля типа следующего за ними субполя запроса. Так T1=2 означает, что поле характеризуется целым числом, а T2=4 указывает на то, что далее следует пароль (поле community, в приведенном примере = public). Цифры под рисунками означают типовые значения субполей. Код 0xA — является признаком GET-запроса, за ним следует поле кода PDU (=0-4, см. табл. 4.4.13.1) Блок субполей идентификатора запроса служит для тех же целей, что и другие идентификаторы — для определения пары запрос-отклик. Собственно идентификатор запроса может занимать один или два байта, что определяется значением Lиз. СО — статус ошибки (СО=0 — ошибки нет); ТМ — тип MIB-переменной (в приведенном примере = 0x2B); ИО — индекс ошибки. Цифровой код MIB-переменной отображается последовательностью цифровых субполей, характеризующих переменную, например: переменная 1.3.6.1.2.1.5 (в символьном выражении iso.org.dod.internet.mgmt.mib.icmp) характеризуется последовательностью кодов 0x2B 0x06 0x01 0x02 0x01 0x05 0x00.

Начиная с января 1998 года, выпущен набор документов, посвященных SNMPv3. В этой версии существенно расширена функциональность (см. таблицу 1 тип PDU=5-8), разработана система безопасности. В данной версии реализована модель, базирующаяся на процессоре SNMP (SNMP Engene) и содержащая несколько подсистем (дипетчер, система обработки сообщений, безопасности и управления доступом, см. рис. 4.4.13.4). Перечисленные подсистемы служат основой функционирования генератора и обработчика команд, отправителя и обработчика уведомлений и прокси-сервера (Proxy Forwarder), работающих на прикладном уровне. Процессор SNMP идентифицируется с помощью snmpEngineID. Обеспечение безопасности модели работы SNMP упрощается обычно тем, что обмен запросами-откликами осуществляется в локальной сети, а источники запросов-откликов легко идентифицируются.

Рис. 4.4.13.4. Архитектура сущности SNMP (SNMP-entity)

Компоненты процессора SNMP перечислены в таблице 4.4.13.5 (смотри RFC 2571 и -2573)

Таблица 4.4.13.5. Компоненты процессора SNMP

Название компонента Функция компонента
Диспетчер Позволяет одновременную поддержку нескольких версий SNMP-сообщений в процессоре SNMP. Этот компонент ответственен за прием протокольных блоков данных (PDU), за передачу PDU подсистеме обработки сообщений, за передачу и прием сетевых SNMP-сообщений
Подсистема обработки сообщений Ответственна за подготовку сообщений для отправки и за извлечение данных из входных сообщений
Подсистема безопасности Предоставляет услуги, обеспечивающие безопасность: аутентификацию и защищенность сообщений от перехвата и искажения. Допускается реализация нескольких моделей безопасности
Подсистема управления доступом Предоставляет ряд услуг авторизации, которые могут использоваться приложениями для проверки прав доступа.
Генератор команд Инициирует SNMP-запросы Get, GetNext, GetBulk или Set, предназначенные для локальной системы, которые могут использоваться приложениями для проверки прав доступа.
Обработчик команд Воспринимает SNMP-запросы Get, GetNext, GetBulk или Set, предназначенные для локальной системы, это индицируется тем, что contextEngeneID в полученном запросе равно соответствующему значению в процессоре SNMP. Приложение обработчика команд выполняет соответствующие протокольные операции, генерирует сообщения отклика и посылает их отправителю запроса.
Отправитель уведомлений Мониторирует систему на предмет выявления определенных событий или условий и генерирует сообщения Trap или Inform. Источник уведомлений должен иметь механизм определения адресата таких сообщений, а также параметров безопасности
Получатель уведомлений Прослушивает сообщения уведомления и формирует сообщения-отклики, когда приходит сообщение с PDU Inform
Прокси-сервер Переадресует SNMP-сообщения. Реализация этого модуля является опционной

На рис. 4.4.13.5 показан формат сообщений SNMPv3, реализующий модель безопасности UBM (User-Based Security Model).

Рис. 4.4.13.5. Формат сообщений SNMPv3 c UBM

Первые пять полей формируются отправителем в рамках модели обработки сообщений и обрабатываются получателем. Следующие шесть полей несут в себе параметры безопасности. Далее следует PDU (блок поля данных) с contextEngeneID и contextName.

.

  • msgVersion (для SNMPv3)=3
  • msgID — уникальный идентификатор, используемый SNMP-сущностями для установления соответствия между запросом и откликом. Значение msgID лежит в диапазоне 0 — (2 31 -1)
  • msgMaxSize — определяет максимальный размер сообщения в октетах, поддерживаемый отправителем. Его значение лежит в диапазоне 484 — (2 31 -1) и равно максимальному размеру сегмента, который может воспринять отправитель.
  • msgFlags — 1-октетная строка, содержащая три флага в младших битах: reportableFlag, privFlag, authFlag. Если reportableFlag=1, должно быть прислано сообщение с PDU Report; когда флаг =0, Report посылать не следует. Флаг reportableFlag=1 устанавливается отправителем во всех сообщениях запроса (Get, Set) или Inform. Флаг устанавливается равным нулю в откликах, уведомлениях Trap или сообщениях Report. Флаги privFlag и authFlag устанавливаются отправителем для индикации уровня безопасности для данного сообщения. Для privFlag=1 используется шифрование, а для authFlag=0 — аутентификация. Допустимы любые комбинации значений флагов кроме privFlag=1 AND authFlag=0 (шифрование без аутентификации).
  • msgSecurityModel — идентификатор со значением в диапазоне 0 — (2 31 -1), который указывает на модель безопасности, использованную при формировании данного сообщения. Зарезервированы значения 1 для SNMPv1,2 и 3 — для SNMPv3.

Модель безопасности USM (User-Based Security Model) использует концепцию авторизованного сервера (authoritative Engene). При любой передаче сообщения одна или две сущности, передатчик или приемник, рассматриваются в качестве авторизованного SNMP-сервера. Это делается согласно следующим правилам:

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

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

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

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

  • ID — snmpEngeneID авторизованного сервера, участвующего в обмене. Таким образом, это значение идентификатора отправителя для Trap, Response или Report или адресата для Get, GetNext, GetBulk, Set или Inform.
  • msgAuthoritativeEngeneBoots — snmpEngeneBoots авторизованного сервера, участвующего в обмене. Объект snmpEngeneBoots является целым в диапазоне 0 — (2 31 -1). Этот код характеризует число раз, которое SNMP-сервер был перезагружен с момента конфигурирования.
  • msgAuthoritativeEngeneTime — snmpEngeneTime авторизованного сервера, участвующего в обмене. Значение этого кода лежит в диапазоне 0 — (2 31 -1). Этот код характеризует число секунд, которое прошло с момента последней перезагрузки. Каждый авторизованный сервер должен инкрементировать этот код один раз в секунду.
  • msgUserName — идентификатор пользователя от имени которого послано сообщение.
  • msgAuthenticationParameters — нуль, если при обмене не используется аутентификация. В противном случае — это аутентификационный параметр.
  • msgPrivacyParameters — нуль — если не требуется соблюдения конфиденциальности. В противном случае — это параметр безопасности. В действующей модели USM используется алгоритм шифрования DES.

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

Система конфигурирования агентов позволяет обеспечить разные уровни доступа к MIB для различных SNMP-менеджеров. Это делается путем ограничения доступа некоторым агентам к определенным частям MIB, а также с помощью ограничения перечня допустимых операций для заданной части MIB. Такая схема управления доступом называется VACM (View-Based Access Control Model). В процессе управления доступом анализируется контекст (vacmContextTable), а также специализированные таблицы vacmSecurityToGroupTable, vacmTreeFamilyTable и vacmAccessTable.

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

Таблица 4.4.13.6. RFC-документы по протоколу SNMP

Блог о системном администрировании. Статьи о Linux, Windows, СХД NetApp и виртуализации.

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

Введение в протокол SNMP

SNMP есть Simple Network Management Protocol, он же Простой Протокол Сетевого Управления. Протокол создан в 1988 г. с целью управления большим количеством сетевых устройств. С того момента протокол набрал соответствующую популярность и стал стандартом. С момента разработки протокол SNMP был 3 раза переработан с версии SNMPv1, SNMPv2 и SNMPv3. На самом деле, версий было больше, например v2 была пересмотрена 2 раза (или даже более). Так же стоит отметить, что кроме SNMP были и другие попытки создать коммерческие и не коммерческие протоколы управления (CORBA, TMN . ) не увенчавшиеся успехом.

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

Архитектура протокола SNMP

Сеть, использующая SNMP для управления содержит три основных компонента:

  1. SNMP менеджер — ПО, устанавливаемое на ПК администратора (системы мониторинга)
  2. SNMP агент — ПО, запущенное на сетевом узле, за которым осуществляется мониторинг.
  3. SNMP MIB — MIB это Management information base. Этот компонент системы обеспечивает структурированость данных, которыми обмениваются агенты и менеджеры. По сути — это некая база данных в виде текстовых фалов.

Давайте попытаемся рассмотреть обозначенные компоненты.

SNMP менеджер и SNMP агент

Для понимания назначения компонентов, можно сказать, что SNMP менеджер является прослойкой (интерфейсом) между оператором\администратором и сетевым узлом с запущенным SNMP агентом. Так же, можно сказать, что SNMP агент — это интерфейс между SNMP менеджером и железным оборудованием на сетевом узле. Если провести аналогию протокола SNMP с клиент-серверной архитектурой (например, веб-сервера) то веб-сервер работает как служба на некотором порту, а пользователь силами браузера обращается к веб-серверу как клиент. Это четко обозначенная архитектура с выраженным клиентом и сервером. В случае SNMP роли клиента и сервера несколько размыты. Например, SNMP агент является своего рода службой, работающей на устройстве (за которым производится мониторинг) и обрабатывает запросы на определенном порту udp/161, то есть фактически является сервером. А SNMP менеджер является своего рода клиентом, который обращается к серверу SNMP агенту. В SNMP существует т.н. Trap. Это запрос от агента к менеджеру. Точнее даже не запрос, а уведомление. При отправке данного уведомления, агент и менеджер «меняются ролями». То есть, менеджер в таком случае должен являться сервером, работающем на порту udp/162, а агент является клиентом. В последних версиях SNMP trap может именоваться как извещение (notification).

SNMP работает на 7 уровне модели OSI, то есть является службой прикладного уровня. Взаимодействие агента и менеджера на уровне протокола SNMP организуется посредством т.н. пакетов объектов PDU (Protocol Data Unit), которые инкапсулируются в транспортный протокол. Хотя, SNMP поддерживает различные виды транспорта, в 99% случаев используется — UDP. При этом, каждое сообщение PDU содержит определенную команду (на чтение переменной, запись значения переменной, или ответ\trap агента). В целом, взаимодействие узлов по SNMP можно представить следующей последовательностью: менеджер -> SNMP(PDU)-UDP-IP-Ethernet-IP-UDP-SNMP(PDU) ->агент. При использовании шифрования в SNMP, по умолчанию используются порт для запросов\ответов udp/10161, а Trap отправляются на udp/10162.

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

Итак, как я уже сказал, SNMP менеджер отправляет запросы агенту на порт udp/161 (если конфигурационно в агенте не задан другой порт) с произвольного порта из эфемерного диапазона. В запросе SNMP менеджера указывается порт и адрес источника (о полной структуре пакета SNMP опишу ниже). Далее агент принимает пакет и обрабатывает (если выполняются нижеописанные условия). В процессе обработки, формируется ответ, который отправляется на порт взятый из исходного запроса. Ответ отправляется с udp/161 порта. Можно сказать, что SNMP агент таким образом предоставляет доступ SNMP менеджеру к данным, хранящимся в базе MIB. При этом, в момент отправки, SNMP менеджер вставляет в PDU некий ID (RequestID), а агент в ответном PDU вставляет данный ID без изменения, для того чтобы менеджер не путал пакеты от разных агентов. SNMP агент может быть настроен на посылку Trap уведомлений, которую он выполняет с эфимерного порта на udp/162 порт SNMP менеджера.

SNMP PDU (или сообщения SNMP протокола)

Выше я упомянул о единице обмена между узлами SNMPPDU (Protocol Data Unit), давайте разберем данное понятие. Для обмена между агентом и менеджером используется определенный набор сообщений PDU команд:

  • Trap – одностороннее уведомление от SNMP агента –> менеджеру о каком-либо событии.
  • GetReponse – ответ от агента к менеджеру, возвращающий запрошенные значения переменных.
  • GetRequest — запрос к агенту от менеджера, используемый для получения значения одной или нескольких переменных.
  • GetNextRequest — запрос к агенту от менеджера, используемый для получения следующего в иерархии значения переменной.
  • SetRequest — запрос к агенту на установку значения одной или нескольких переменных.
  • GetBulkRequest – запрос к агенту на получение массива данных (тюнингованная GetNextRequest). (Этот PDU был введен в SNMPv2.)
  • InformRequest – одностороннее уведомление между менеджерами. Может использоваться, например для обмена информацией о MIB (соответствие символьных OID — цифровым). В ответ менеджер формирует аналогичный пакет в подтверждение того, что исходные данные получены. (Этот PDU был введен в SNMPv2.)

Как видно, в зависимости от версии протокола, набор команд разный (например InformRequest и GetBulkRequest полноценно появился только во второй версии SNMP). Компонент SNMP MIB рассмотрим ниже.

Структура PDU

Рассмотрение структуры PDU не обязательно, но это поможет более глубоко понять логику работы SNMP. Все PDU (кроме Trap) состоят из определенного набора полей, в которые записывается необходимая информация:

Что данные поля обозначают:

  • версия — содержит версию SNMP
  • пароль (community) — содержит последовательность символов, описывающую принадлежность к группе (об этом ниже)
  • тип PDU имеет цифровой идентификатор запроса (Get,GetNext,Set,Responde,Trap…)
  • идентификатор запроса – это тот самый набор символов, который связывает в единое целое запрос\ответ.
  • Статус ошибки– это число, характеризующее характер ошибки:
    • Для запросов (Get,Set,GetNExt и др.) — 0
    • Для ответов:
      • 0 (NoError) – Нет ошибок,
      • 1 (TooBig) — Объект не вмещается в одно Response сообщение,
      • 2 (NoSuchName) – не существующая переменная,
      • 3 (BadValue) – при попытке установить значение задано недопустимое значение или совершена синтаксическая ошибка,
      • 4 (ReadOnly) – при Set запросе была попытка изменить read-only переменную,
      • 5 (GenErr) – другие ошибки.
  • Индекс ошибки – не нашел внятного описания ( но смысл в том, что содержит некий индекс переменной, к которой относится ошибка
  • Поле связанные переменные может содержать одну или более переменную (для запросов Get – это только имя переменных, для Set – имя и устанавливаемое значение, для Response – имя и запрошенное значение).


При этом, содержимое Trap PDU содержит некоторые дополнительные поля (вместо заголовка запроса):

  • Фирма – характеризующее производителя хоста
  • Тип trapуведомления, может быть следующим:
    • 0 (Coldstart) и 1 (Warmstart) – объект возвращен в начальное состояние (между ними имеется некая разница, но какая. ),
    • 2 (Linkdown) – интерфейс опущен, при этом, поле переменной содержит интерфейс о котором идет речь,
    • 3 (Linkup) – интерфейс поднялся, при этом, поле переменной содержит интерфейс о котором идет речь,
    • 4 (Authenticationfailure) – менеджер прислал мессадж с неверной строкой community,
    • 5 (EGPneighborloss) – затрудняюсь что либо сказать ),
    • 6 (Entrprisespecific) – данный тип Trap сообщает о том, что в следующем поле содержится специализированный для данного вендора тип трапа.
  • Специализированный тип Trap – описан выше
  • Метка времени – содержит метку времени с момента события (непонятно, относительно чего эта метка…).

В новых версиях SNMP содержимое Trap PDU может незначительно меняться, но в целом, смысл тот же.

Логика работы протокола SNMP

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

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

Логика работы SNMP при обмене PDU-единицами

(взято частично отсюда http://logic-bratsk.ru/brlug/snmp_my/):

При получении PDU GetRequest, SNMP агент действует по следующему алгоритму:

  1. Если имя переменной не совпадает в точности с именем одной из переменной, доступных для операции get в нашей MIB, передаем отправителю запроса аналогичное PDU GetResponse, указывая в поле кода ошибки значение noSuchName (2-нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении (=1, в SNMPv1 — ограничение данной реализации SNMP).
  2. Если размер PDU GetResponse, созданного в соответствии с приведенным ниже описанием, превышает локальное ограничение (Реализация SNMP не обязана принимать сообщения, размер которых превышает определенное значение. Однако по возможности желательна поддержка дейтаграмм больших размеров (RFC1157 SNMP).), передаем отправителю аналогичное PDU GetResponse, указав в поле errorstatus значениеTooBig, а в поле error-index — 0. Это обычно происходит, если запрошено больше 1 переменной или длина PDU или общая длина пакета больше стандартных пределов.
  3. Если для любой переменной, содержащейся в поле связанные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, SNMP агент передает отправителю аналогичное PDU GetResponse, указав в поле error-status значение GenErr, а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении.
  4. Если все нормально, передаем SNMP менеджеру, отправившему полученное сообщение, ответ — GetResponse, в котором для каждой переменной в поле связанные переменные подставлены запрошенные значения переменных. В поле error-status помещается значение NoError, а в поле error-index — 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.

При получении PDU GetNextRequest, SNMP агент действует по следующему алгоритму:

  1. Если после переменной, указанной в запросе, нет следующей переменной, то передаем отправителю запроса менеджеру PDUGetResponse (с содержимым аналогичным исходному запросу), указывая в поле кода ошибки значение noSuchName (нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении (=1 для SNMPv1), значение переменной = NULL (кажется).
  2. Если размерPDUответа (GetResponse), созданного в соответствии с приведенным ниже описанием, превышает локальное ограничение, принимающий объект передает отправителю аналогичное PDU GetResponse, указав в поле errorstatus значение tooBig, а в поле error-index — 0.
  3. Если для любой переменной в поле связанные переменные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, принимающий объект передает менеджеруPDUс исходным содержимым GetResponse, указав в поле error-status значение genErr, а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении. (аналогично вышесказанному)
  4. Если все нормально, передаем SNMP менеджеру, отправившему PDU, такое сообщение GetResponse, в котором для каждой переменной в поле связанные переменные содержится имя и значение переменной, иерархически следующей за запрошенной переменной в базе MIB. В поле error-status помещается значение noError, а в поле error-index — 0. Значение поля request-idв ответномPDUGetResponse совпадает с идентификатором в принятом сообщении.

При получении PDU SetRequest, SNMP агент действует по следующему алгоритму:

  1. Если для любой переменной, содержащейся в поле связанные переменные, запись (операция set) не поддерживается в имеющих отношение к делу представлениях MIB, SNMP агент объект передает отправителю запроса аналогичное PDU GetResponse, указывая в поле кода ошибки значение noSuchName (нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении.
  2. Если для любой переменной в запросе, запрашиваемые к изменению значения переменных не соответствуют стандартам (SMI, ASN.1 – об этом ниже), то SNMP агент передает SNMP менеджеру аналогичное PDU GetResponse, указывая в поле кода ошибки значение badValue (нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении.
  3. Если размерPDUответа (GetResponse), созданного в соответствии с приведенным ниже описанием, превышает локальное ограничение, принимающий объект передает отправителю аналогичное PDU GetResponse, указав в поле errorstatus значение tooBig, а в поле error-index — 0.
  4. Если для любой переменной в поле связанные переменные, значение переменной не может быть установлено по причинам, которые отличаются от перечисленных выше,SNMPагент передает менеджеруPDUс исходным содержимым GetResponse, указав в поле error-status значение genErr, а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении. (аналогично вышесказанному)
  5. Если все нормально, агент передает SNMP менеджеру, отправившему PDU, такое сообщение GetResponse, в котором для каждой переменной в поле связанные переменные подставлены установленные значения переменных. В поле error-status помещается значение NoError, а в поле error-index — 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.

Логика работы SNMP в картинках

взято отсюда (http://www.manageengine.com/network-monitoring/what-is-snmp.html)

Обмен PDU GET⁄ GET NEXT⁄ GET BULK⁄ SET

Обмен PDU Trap или notification

SNMP MIB

Давайте попробуем понять MIB. Это совсем не люди в черном ) Как я уже сказал, это Management information base, то есть база набор управляющей информации. Каждый сетевой узел, имеющий на своем борту SNMP агента (читай – поддерживающий протокол SNMP) предоставляет свой набор данных, тот, который в него «вложили» программисты\разработчики при проектировании железки\программы. То есть в каждом сетевом устройстве с поддержкой SNMP имеется своя база MIB со строго обозначенным набором переменных. Каждая база MIB имеет древовидную структуру, каждый объект в которой характеризуется уникальным идентификатором объекта (Object Identifier, OID).

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

Имеется некая единая общая структура дерева MIB, а так же, имеются единые стандарты и принципы дальнейшего формирования данного дерева, его переменных, др. параметров, за эти правила отвечает некий разработанный стандарт под названием Структура Информации Управления (SMI, Structure of Management Information). Так же, имеется некий стандарт, называемый абстрактный синтаксис нотаций — ASN.1. Который тоже участвует в описании протокола SNMP и базы MIB. А еще имеется базовые правила кодирования BER (Basic Encoding Rules), определяющие кодирование сущностей, применяемых в SNMP.

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

Давайте рассмотрим типичное дерево MIB на рисунке:

Дерево объектов MIB подобно системе DNS (Domain Name System). Тут аналогично имеются символьные имена (аналогично NS имени) и называемые ASN.1 нотацией, и соответствующие им числовые значения (аналогично IP адресам), называемые dot нотацией. Каждый объект в MIB состоит из нескольких чисел, разделенных точками. Числам соответствуют текстовые наименования. При этом, в отличии от DNS — нет какого-то единого централизованного сервера, отвечающего за разолвинг имен. Все разрешения имен из символов в числа происходят силами SNMP менеджера (в зависимости от того, какие сопоставления MIB загружены в менеджер). Весь обмен между узлами SNMP происходит только в числовом виде. В символьном виде, наименования используются только для отображения на экране или в документации.

Часто OID характеризующий определенный объект в дереве MIB сравнивают со структурой телефонных номеров, т.к. они (номера) так же иерархичны и отдельные части номера назначаются различными организациями. Например, международные телефонные номера состоят из кода страны (назначаемого международной организацией) и телефонного номера в том виде, в котором он определен локально в стране. При этом, телефонный номер в стране делится на код области\края\региона, номер АТС и далее номер абонента, привязанного к АТС. Аналогично — в MIB OID верхнего уровня назначаются международной организацией (ISO IEC . ), ветки OID нижнего уровня назначаются организациями, отвечающими за эти ветки.

Итак, структура OID в дереве MIB:

В вершине дерева – корень (точка), от которого ответвляются ветви. Во многих схемах приведены некоторые ветви верхнего уровня (например itu-t, iso\itu-t и другие ниже), но информации о их назначении я не нашел… Посему, нас интересует вертка iso (0), которая хранит в себе следующие значения до internet (1): iso.org.dod.internet, что соответствует числовому ID .1.3.6.1.

Данный раздел (iso.org.dod.internet) разветвляется на подразделы, которые в большинстве своем контролируются IANA и состоят (согласно RFC1155) из:

  • directory O >экспериментов разработчиков. (не отображено на схеме)
  • private O >Далее, необходимо рассмотреть отдельным пунктом ветку 1.3.6.1.2 (iso.org.dod.internet.mgmt), состоящую из подветки mib-2(1), а так же reserved(0), pib(2), http(9) и некоторых других. Стоит отметить, что в зависимости от версии протокола (SNMPv1 vs SNMPv2) на месте данной ветки могут быть «прилинкованы» разные поддеревья в целом имеющие примерно одинаковую структуру и одинаковые идентификаторы, но в более новой версии протокола – поддерево более расширено. (наверно, в этом и состоит несовместимость версий протокола…)

Итак iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1): данная ветка является базовой для большинства сетевых устройств и содержится практически в любом устройстве. Ветка поделена на базовые группы (которых на текущий момент более 170), характерные для любого сетевого оборудования. Давайте рассмотрим наиболее применяемые:

  1. iso.org.dod.internet.mgmt.mib-2.system (1.3.6.1.2.1.1) — ветка содержит в себе несколько объектов, характеризующих хост (аптайм, версия ОС и др.), описана в RFC1213.
  2. iso.org.dod.internet.mgmt.mib-2.interface (1.3.6.1.2.1.2) — содержит объекты, описывающие сетевую подсистему хоста (количество интерфейсов, размер MTU, скорость передачи, физические адреса и т.п.), описана в RFC2863.
  3. iso.org.dod.internet.mgmt.mib-2.ip (1.3.6.1.2.1.4) – содержит набор объектов, описывающих данные о проходящих IP пакетах (количество запросов, ответов, отброшенных пакетов и мн.др). Описана в RFC1213.
  4. iso.org.dod.internet.mgmt.mib-2.tcp (1.3.6.1.2.1.6) и iso.org.dod.internet.mgmt.mib-2.udp (1.3.6.1.2.1.7) — содержат объекты, хранящие в себе информацию, касающуюся соответствующего транспортного протокола. Описана в RFC1213.
  5. . И мн. др., которые в принципе имеют довольно наглядное наименование и которые далее «раскрываются» на большее множество объектов.

Отдельного абзаца так же достоин подраздел iso.org.dod.internet.private (1.3.6.1.4), содержащий в себе поддерево enterprise (1). Данная ветвь контролируется IANA и содержит в себе более 40000 поддеревьев (ознакомьтесь с актуальным списком http://www.iana.org/assignments/enterprise-numbers ). В данной ветке регистрируют свои поддеревья – производители оборудования. Вот пример ответвления:

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

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

Безопасность протокола SNMP (или версии протокола SNMP)

Безопасность протокола SNMP — это самый изменяемый раздел спецификации протокола со времени его создания. С каждой версией SNMP, производились попытки усилить безопасность. Первая версия протокола SNMPv1 была самой простой и небезопасной. Сообщения протокола могли быть подвержены возможности модификации, подмене или прослушиванию. Безопасность протокола базировалась на модели безопасности на основе сообществ (т.н. Community-based Security Model), что подразумевало аутентификацию на основе единой текстовой строки — своеобразного пароля (т.н. community-sting), которая передавалась в теле сообщения в открытом виде. Хотя, данная версия протокола самая незащищенная, она довольно часто применяется в современных сетях, т.к. является самой простой.

В одной из вторых версий SNMP (SNMPv2p) была попытка реализовать аутентификацию на основе сторон (т.н.Party-based Security Model). Технология кроме аутентификации, так же поддерживала возможность шифрования трафика. Данная технология не прижилась, как «сложная и запутанная» ) и в данный момент не используется. После чего SNMP второй версии вернулась к Community-based Security и стала именоваться SNMPv2c и применяется по сей день. SNMPv2 была переписана чуть более чем полностью, в результате чего существенно повышено быстродействие протокола, безопасность.

Третья версия протокола (SNMPv3) была более удачно доработана и поддерживает как аутентификацию на основе имени пользователя (т.н. User-based Security Model), так и шифрование трафика. Хотя их можно и не использовать.

Версии протокола между собой не совместимы. Несовместимость заключается в разнице пакетов PDU, в наличии дополнительных команд в более новых версиях протокола (возможно, в других…). В RFC 2576 имеется некоторая информация, позволяющая организовать возможность совместного использования SNMPv1 и v2. Для этого есть 2 пути: 1. Использование прокси-агентов (агент преобразует PDU SNMPv2 в PDU SNMPv1), 2. Использование менеджера с поддержкой 2х версий (менеджер для каждого хоста должен помнить версию агента).

Давайте рассмотрим работу протокола SNMPv2cSNMPv1) с точки зрения безопасности. При рассмотрении структуры пакета PDU было видно, что каждая единица PDU содержит community строку. При этом, SNMP агент содержит список (часто данный список состоит из одного значения) разрешенных строк и описание того, что каждая из строк может делать (фактически – набор прав). В большинстве случаев – это права read/write. При активации функций SNMP на каком-либо хосте, стандартные строки community – это public и private для возможности чтения и для возможности чтения-записи соответственно. Это строки очень желательно менять на свои. Часто, при конфигурировании SNMP о , в котором для каждой переменной в поле связанные переменные подставлены установленные значения переменных. В поле error-status помещается значение NoError, а в поле error-index — 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.пределяют различные community строки для чтения переменных и для записи.

Принципы настройки протокола SNMP

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

  • Порт отправки
  • Принимать ли trap
  • community для чтения
  • community для записи
  • период опроса
  • OID’ы

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

SNMP в Linux

В большинстве дистрибутивов Linux для работы с SNMP используется пакет net-snmp (RedHat) и snmp + snmpd (в Debian в snmp лежит клиентская часть, а в snmpd – серверная часть), который позволяет использовать протокол SNMP посредством отправки и получения PDU. После установки пакета(ов) в linux появятся следующие инструменты (перечислены не все):

  • snmptranslate — Перевод MIB OID имён между цифровой и текстовой представлениями.
  • snmpget — Взаимодействует с агентом, используя PDU GetRequest запросы.
  • snmpgetnext — Взаимодействует с агентом, используя PDU GetNextRequest запросы.
  • snmpbulkget — Взаимодействует с агентом, используя PDU GetBulkRequest запросы.
  • snmpwalk — Получает поддерево объектов OID из MIB базы агента с помощью PDU GetNextRequest запросов. Если OID не задан, то команда получает дерево, начиная от MIB-2 (iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1))
  • snmpbulkwalk — Получает поддерево объектов OID из MIB базы агента с помощью PDU GetBulkRequest запросов.
  • snmpset — Взаимодействует с агентом, используя PDU SetRequest запросы.
  • snmptrap — Посылает SNMP Trap или информационные сообщения.
  • snmptest — Взаимодействует с сетью, используя SNMP запросы.

Основной и часто используемой из всех указанных команд, является snmpwalk. При указании данной команды, без OID она попытается получить все объекты из ветки iso.org.dod.internet.mgmt.mib-2. В ссылках ниже можно найти отличный сборник примеров использования данных программ.

Так же, стоит отметить, что когда Вы работаете с указанными командами, наименование переменных O >iso.org.dod.internet.mgmt.mib-2 , собственно, он и свернут в название данной ветки и представлен как SNMPv2-MIB::.

SNMP в Debian

Политика лицензирования Debian определяет базы MIB, как несвободное ПО, поэтому они не расположены в свободных репозитоиях, а размещены в non-free репозиториях. Для того чтобы базы корректно установились, необходимо данный репозиторий прописать в /etc/apt/sources.list, например:

и установить пакет snmp-mibs-downloader. (в процессе установки данный пакет попытается получить mib-базы из интернета). Так, же, необходимо в /etc/snmp/snmp.conf закомментировать строку:

Маленький итог о SNMP

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

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

Ссылки SNMP

Источники загрузки MIB файлов (каталоги MIB):

Интернет технологии (архив 2001-2010)

ICMP (Internet Control Message Protocol) — протокол управляющих сообщений.

Вы их получаете постоянно, а иногда и отправляете, например:

Если адрес не доступен, вы получаете сообщение ICMP.

Если порт не доступен, вы получаете сообщение ICMP.


Если вы пользуетесь командой ping, вы получаете сообщение ICMP.

Сообщение ICMP инкапсулируется прямо в IP пакет (поле данных), т.е. протоколы транспортного уровня не используются.

Поле protocol = 1 (в заголовке IP).

Первый стандарт ICMP определен в RFC0777 (Internet Control Message Protocol J. Postel Apr-01-1981)

Последняя версия — RFC0792 (Internet Control Message Protocol J. Postel Sep-01-1981)..

Последняя версия ICMPv6 для IPv6 — RFC2463 (Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification A. Conta, S. Deering December 1998)

Сообщения делятся на два типа:

Непарные (например: посылаете запрос к HTTP-серверу, но сервер не доступен, и последний маршрутизатор (или сервер) отправляет ICMP-сообщение (Destination Unreachable) вам)

11.1.1 Заголовок сообщения ICMP.

Структура заголовка сообщения ICMP. Слова по 32 бита.

Типы сообщений протокола ICMP

Тип Сообщение Назначение
Echo Reply Ответ ICMP — эхо (ping)
3 Destination Unreachable Цель не достижима
4 Source Quench Переполнение очереди источника
5 Redirect Перенаправление маршрута
8 Echo Request Запрос ICMP — эхо (ping)
9 Объявление маршрутизатора
10 Запрос маршрутизатора
11 Time Exceeded Время жизни истекло
12 Parameter Problem Неверный параметр
13 Timestamp Request Запрос метки времени
14 Timestamp Reply Ответ метки времени
15 Information Request Запрос информации
16 Information Reply Ответ информации
17 Address Mask Request Запрос маски адреса
18 Address Mask Reply Ответ маски адреса

11.1.2 Сообщение Destination Unreachable

Непарное сообщение, формируется, если цель недостижима.

Структура сообщения ICMP — Destination Unreachable

«Заголовок и первые 64 бита исходной дейтограммы» отправляются для диагностики причины ошибки.

Диагностические коды сообщений Destination Unreachable

Код Тип кода Значение
Network Unreachable Сеть назначения недостижима
1 Host Unreachable Хост назначения не достижим
2 Protocol Unreachable Протокол недостижим
3 Port Unreachable Порт недостижим
4 Fragmentation Need & DF set Необходима фрагментация, однако она запрещена
5 Source Route Failed Исходный маршрут вышел из строя
6 Destination Network Unknown Сеть назначения неизвестна
7 Destination Host Unknown Хост назначения неизвестен
8 Source Host Isolated Источник изолирован
9 Communication with destination
Network Administratively Prohibited
Взаимодействие с сетью назначения запрещено
10 Communication with destination
Host Administratively Prohibited
Взаимодействие с узлом назначения запрещено
11 Network Unreachable for type of service Сеть назначения недоступна для запрошенного типа сервиса
12 Host Unreachable for type of service Хост назначения недоступен для запрошенного типа сервиса
13 Связь административно запрещена с помощью фильтра
14 Нарушение старшинства ЭВМ
15 Дискриминация по старшинству

Из таблицы видно, что коды 2 и 3 формируются сервером назначения.

11.1.3 Сообщение Time Exceeded

Непарное сообщение, формируется, если время жизни истекло.

Структура сообщения ICMP — Time Exceeded

Диагностические коды сообщений Time Exceeded

Код Значение
Время жизни = 0
1 Таймер дефрагментации установился в 0
до полной сборки принятого сообщения

11.1.4 Сообщение Parameter Problem

Непарное сообщение, формируется, если заголовок IP-дейтограммы содержит неверный параметр.

Структура сообщения ICMP — Parameter Problem

Диагностические коды сообщений Parameter Problem

Код Значение
Если возникла проблема с интерпретацией какого то поля
(используется поле «номер байта с ошибкой в исходном сообщении»)
1 Если возникла проблема с несоответствием какого то запрашиваемого параметра, с установленными требованиями

11.1.5 Сообщение Source Quench

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

Структура сообщения ICMP — Source Quench

11.1.6 Сообщение Redirect

Непарное сообщение, формируется, если изменен маршрут для пакета.

Случай, когда маршрутизатор перенаправляет пакеты по другому маршруту (маршрут 2).

И предлагает в сообщении ICMP изменить шлюз по умолчанию

Структура сообщения ICMP — Redirect

Диагностические коды сообщений Redirect

Код Тип кода Значение
Redirect Datagram for networks Изменение маршрута для сети
1 Redirect Datagram for host Изменение маршрута для хоста
2 Redirect Datagram for the Type of service and networks Изменение маршрута для типа сервиса или сети
3 Redirect Datagram for the Type of service and host Изменение маршрута для типа сервиса или хоста

11.1.7 Сообщение Echo Request/Echo Reply

Парное сообщение. Любой узел, получивший Echo Request, должен ответить Echo Reply отправителю.

Echo Request сообщения формирует программа ping.

Структура сообщения ICMP — Echo Request/Echo Reply

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

11.1.8 Атаки с помощью Echo Request/Echo Reply

Можно осуществить DoS-атаку (Denial of Service — подавление услуги).

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

Нужно послать как можно больше ответов Echo Reply на жертву.

Для этого можно задействовать чужие сети.

Указываем адрес источника — адрес жертвы (194.85.241.1)

Указываем адрес получателя — адрес типа Directed Broadcast (195.208.44.255), на этот адрес должны ответить все узлы сети 195.208.44.0/24

Посылаем сообщение Echo Request.

253 машины посылают ответ на жертву (194.85.241.1)

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

Жертва будет перегружена.

Атаки с помощью Echo Request/Echo Reply

Меры предотвращения таких атак:

Запретить прием и распространение сообщений типа Directed Broadcast.

Уничтожать сфальсифицированные пакеты, сопоставляя IP источника с маршрутной таблицей и номером интерфейса, с которого получен пакет.

Запретить трафик ICMP (ping, traceroute и т.д., работать не будут).

11.1.9 Принцип работы traceroute

traceroute отправляет на несуществующий порт удаленного узла последовательность UDP-дейтаграмм, .

Номер используемого порта по умолчанию 33434.

Посылаются дейтограммы с TTL=1 (время жизни пакета)

Первый же маршрутизатор уменьшает TTL на 1, т.е. TTL=0 и пакет уничтожается, а отправителю посылается ICMP сообщение Time Exceeded.

Посылаются дейтограммы с TTL=2 (время жизни пакета)

Первый же маршрутизатор уменьшает TTL на 1, т.е. TTL=1 и пакет проходит дальше.

Второй маршрутизатор уменьшает TTL на 1, т.е. TTL=1 и пакет уничтожается, а отправителю посылается ICMP сообщение Time Exceeded.

Попадая на получателя, пакет уничтожается, т.к. получатель не знает, что с ним делать (порт не существует), и отправителю посылается ICMP сообщение Destination Unreachable.

Пример работы traceroute

Создана для стандартизации управления оборудованием разных производителей.

Например, в сети установлены разные маршрутизаторы (cisco, motorola, linux и т.д.), все настраиваются поразному. Нужно изменить настройки на всех маршрутизаторах. Обычным методом придется каждый настраивать индивидуально (интерфейсы у всех разные). С помощью SNMP можно настроить используя один интерфейс.

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

Сервера управления — порт по умолчанию 162.

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

SMI — (Structure of Management Information) — структура информации управления.


MIB (Management Information Base) — информационная база управления.

SNMP (Simple Network Management Protocol) — простой протокол управления сетью.

Первый стандарт SNMP определен в RFC1067 (Simple Network Management Protocol J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin Aug-01-1988)

Последняя версия RFC1157 (STD0015 Simple Network Management Protocol (SNMP) J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin May-01-1990)

RFC1592 (Simple Network Management Protocol Distributed Protocol Interface Version 2.0 B. Wijnen, G. Carpenter, K. Curran, A. Sehgal, G. Waters March 1994)

Протокол прикладного уровня работает по умолчанию поверх UDP, но может работать по TCP.

Клиент и сервер обмениваются сообщениями.

Взаимодействие клиент-сервера SNMP. Приведены все пять типов сообщений.

PDU (Protocol Data Unit) — блок (пакет) данных протокола.

Типы PDU сообщений SNMP

Тип PDU Имя Значение
get-request Получить значение переменных
1 get-next-request Получить следующие переменные после этой
2 set-request Установить значение переменных
3 get-response Выдать значение переменных
(Посылает агент в ответ на get-request,
get-next-request, set-request)
4 trap Уведомить менеджера, когда что-либо произошло с агентом

Формат SNMP-сообщений. Trap приведен отдельно.

Версия — содержит версию SNMP минус 1, т.е. для SNMPv1 версия=0

Статус ошибки — это целое число, которое возвращается агентам

Индекс ошибки — это целое смещение, указывающее на то, в какой переменной произошла ошибка.

Значения статуса ошибки SNMP.

Статус ошибки Имя Значение
noError Все в порядке
1 noError Клиент не может поместить отклик в одно SNMP сообщение
2 noSuchName Оператор указывает на несуществующую переменную
3 badValue В команде set использовано недопустимое значение или неправильный синтаксис
4 readOnly Менеджер попытался изменить переменную, которая помечена как «только для чтения»
5 genErr неопознанная ошибка
Тип trap Имя trap Значение
coldStart Установление начального состояния объекта
1 wannStart Восстановление начального состояния объекта
2 linkDown Интерфейс выключился. Первая переменная в сообщении идентифицирует интерфейс
3 linkUp Интерфейс включился. Первая переменная в сообщении идентифицирует интерфейс
4 authenticationFailure От менеджера получено SNMP-сообщение с неверным паролем
5 egpNeighborLoss EGP-партнер отключился. Первая переменная в сообщении определяет IP-адрес партнера
6 entrpriseSpeclfic Информация о trap содержится в поле «Специальный код»

Поле «Специальный код» для типов trap 0…4 поле должно быть равно нулю.

Время — содержит число сотых долей секунды (число тиков) с момента инициации объекта управления.

11.2.2 Структура информации управления (SMI)

SMI — (Structure of Management Information) — структура информации управления

Первый стандарт SMI определен в RFC1155 (Structure and identification of management information for TCP/IP-based internets M.T. Rose, K. McCloghrie May-01-1990)

Последний стандарт для версии SMIv1 RFC1155 (Structure and identification of management information for TCP/IP-based internets M.T. Rose, K. McCloghrie May-01-1990)

Последний стандарт для версии SMIv2 RFC2578 (Structure of Management Information Version 2 (SMIv2) K. McCloghrie, D. Perkins, J. Schoenwaelder April 1999)

Некоторые типы данных:

INTEGER — целое число

OCTET STRING — восьмеричная строка, каждый байт имеет значение от 0 до 255.

DisplayString — строка, каждый байт должен быть символом из набора ASCII NVT.

OBJECT IDENTIFIER — идентификатор объекта — OID.

NULL — ноль, означает, что у соответствующей переменной нет значения.

IpAddress — IP адрес. восьмеричная строка длиной 4 байта.

PhysAddress — физический адрес, восьмеричная строка, содержит физический адрес (например, 6-байтный Ethernet адрес).

TimeTicks (тики времени). Счетчик, который считает время в сотых долях секунды с какой-либо исходной точки.

SEQUENCE OF — чего последовательность.

11.2.2.1 Дерево идентификаторов объектов

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

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

Дерево идентификаторов объектов в информационной базе управления

Все переменные в MIB начинаются с идентификатора объекта — 1.3.6.1.2.1 (iso.org.dod.internet.mgmt.mib-2)

root — корень не имеет идентификатора

iso — администрирует дерево

org — организационный узел

dod — министерство обороны США

enterprise — предприятия, например:

348 (1.3.6.1.2.1.348) — Procter&Gamble

743 (1.3.6.1.2.1.743) — ЦРУ

Например, ветвь 1.3.6.1.2.1.4 (iso.org.dod.internet.mgmt.mib-2.ip) дает информацию необходимую для управления компьютерами и маршрутизаторами.

11.2.3 Информационная база управления (MIB)

Первый стандарт MIB определен в RFC1066 (Management Information Base for network management of TCP/IP-based internets K. McCloghrie, M.T. Rose Aug-01-1988 )

Последний стандарт для версии MIB-I RFC1156 (Management Information Base for network management of TCP/IP-based internets K. McCloghrie, M.T. Rose May-01-1990)

Последний стандарт для версии MIB-II RFC1213 (STD0017 Management Information Base for Network Management of TCP/IP-based internets:MIB-II K. McCloghrie, M.T. Rose Mar-01-1991)

Ветвь 1.3.6.1.2.1.4 (iso.org.dod.internet.mgmt.mib-2).

Расмотрим подробнее ветвь UDP (рис. выше).

Группа UDP содержит четыре переменные, и одну таблицу (udpTable) из двух переменных.

Переменные группы udp

Имя Тип данных Чтение/Запись Описание
udpInDatagrams Counter Только чтение Количество UDP датаграмм, доставленных пользовательским процессам.
udpNoPorts Counter Только чтение Количество доставленных UDP датаграмм, для которых не оказалось порта назначения.
udpInErrors Counter Только чтение Количество недоставленных UDP датаграмм по другим причине (например, ошибка контрольной суммы UDP).
udpOutDatagrams Counter Только чтение Количество отправленных UDP датаграмм.

Как видно из таблицы эти переменные обеспечивают полный сбор статистики для UDP-протокола.

Переменные в udpTable.

Имя Тип данных Чтение/Запись Описание
udpLocalAddress IpAddress Только чтение Локальный IP адрес слушающего процесса.
udpLocalPort INTEGER
[0..65535]
Только чтение Локальный номер порта слушающего процесса.

11.2.3.1 Примеры идентификации

Каждая переменная в MIB должна быть идентифицирована.

Обращение осуществляется только к тупиковым (в дереве) узлам.

11.2.3.1.1 Простые переменные

На то, что эта переменная простая, указывает «.0», добавленный к идентификатору объекта переменной. Например, к счетчику udpInErrors , c идентификатором объекта 1.3.6.1.2.1.7.3, можно обратиться как 1.3.6.1.2.1.7.3.0. Текстовое имя при подобном обращении будет iso.org.dod.internet.mgmt.mib.udp.udpInErrors.0.

Обращения к этой переменной чаше делаются в сокращенном виде, udpInErrors.0, т.к. реально идет обращение к идентификатору объекта 1.3.6.1.2.1.7.1.0.

Рассмотрим идентификацию пунктов таблицы udpTable более подробно.

Для каждой таблицы в MIB указан один или несколько индексов. Для таблицы слушающего процесса UDP, MIB определяет индекс как комбинацию двух переменных udpLocalAddress (локальный IP адрес) и udpLocalPort (локальный UDP порт), индекс в данном случае — целое число.

Пример таблицы udpTable.

udpLocalAddress udpLocalPort
0.0.0.0 53
0.0.0.0 67
0.0.0.0 161

Из таблицы видно, что система готова принимать UDP датаграммы с любого интерфейса (0.0.0.0) для портов 53 (DNS), 67 (BOOTP) и 161 (SNMP).

11.2.3.1.3 Абстрактная форма записи

ASN.1 (Abstract Syntax Notation 1) — абстрактная форма записии.

Все поля в MIB и SNMP сообщениях описываются с использованием ASN.1.

Например, ASN.1 определение переменной udpNoPorts выглядит так:

udpNoPorts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
«The total number of received UDP datagrams for which there
was no application at the destination port.»
::= < udp 2 >


Новое в этой версии:

get-bulk-request — позволяет менеджеру эффективно обрабатывать большие блоки данных.

inform-request — позволяет одному менеджеру посылать информацию другому менеджеру.

Определены два новых MIB: MIB SNMPv2 и MIB SNMPv2-M2M (менеджер-менеджер).

11.2.5 Программы для работы с SNMP

SNMP как средство управления сетями
(по материалам корпорации Microsoft)

1. Введение

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

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

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

Управление элементами сети:

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

В настоящее время для управления сетями используются приложения, работающие на базе платформ сетевого управления, таких как системы HP OpenView фирмы Hewlett-Packard, NetView for AIX (IBM), SunNet Manager (Sun), Spectrum (Cabletron Systems), NetWare Management Systems (Novell) и другие разнообразные кросс-платформные средства управления.

В основе этих средств лежит использование протокола SNMP (Simple Network Management Protocol). Протокол SNMP предназначен для сбора и передачи служебной информации (status information) между различными компьютерами.

2. Определение SNMP

SNMP — это протокол из семейства TCP/IP (Протокол SNMP описан в RFC 1157). Первоначально он был разработан Сообществом Интернета (Internet community) для наблюдения и устранения неполадок в маршрутизаторах и мостах (bridges). SNMP позволяет наблюдать и передавать информацию о состоянии:

  • компьютеров, работающих под управлением Windows NT;
  • серверов LAN Manager;
  • маршрутизаторов и шлюзов;
  • мини-компьютеров или мэйнфреймов;
  • терминальных серверов;
  • концентраторов.

SNMP использует распределенную архитектуру, состоящую из систем управления (management systems) и агентов (agents). С помощью сервиса Microsoft SNMP компьютер, работающий под управлением Windows NT, может выдавать отчет о своем состоянии системе управления SNMP в сети, использующей протокол TCP/IP.

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

2.1. Системы управления и агенты

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

Система управления SNMP

Основная функция системы управления — запрос информации от агентов. Система управления (management system) — это любой компьютер, на котором работает программное обеспечение управления SNMP. Система управления может выполнять операции get, get-next и set.

  • Операция get запрашивает какой-либо параметр, например количество доступного пространства на жестком диске.
  • Операция get-next запрашивает следующую величину, используется для просмотра таблицы объектов.
  • Операция set изменяет значение, используется редко, потому что большинство параметров доступны только для чтения и не могут быть изменены.

Агент SNMP

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

Единственная операция, которая может быть инициирована агентом, — trap. Эта операция сигнализирует системам управления о необычном событии, например о нарушении пароля.

2.2. Сервис Microsoft SNMP

Сервис Microsoft SNMP обеспечивает сервисы агента SNMP любому компьютеру, на котором работает программа управления SNMP (рис. 2). Сервис SNMP:

  • обрабатывает запросы служебной информации от различных компьютеров;
  • сообщает о важных событиях [ловушках (traps)] нескольким компьютерам, как только они происходят;
  • использует имена узлов и их IP-адреса для идентификации компьютеров, которым посылает информацию и с которых получает запросы;
  • может быть установлен и использован на любом компьютере, работающем под управлением Windows NT с протоколом TCP/IP;
  • позволяет применять счетчики для наблюдения за TCP/IP, используя Performance Monitor.

Архитектурная модель SNMP

Сервис Microsoft SNMP написан с использованием интерфейса Windows Sockets. Это позволяет обращаться к нему из сетевых систем управления, созданных средствами этого интерфейса. Сервис SNMP посылает и принимает сообщения по протоколу UDP (порт 161) и использует IP для поддержки маршрутизации SNMP-сообщений. SNMP позволяет применять дополнительные динамически подключаемые библиотеки агентов для поддержки других баз MIB. Сторонние производители могут разрабатывать собственные базы MIB для использования совместно с сервисом Microsoft SNMP. Microsoft SNMP включает модуль Microsoft Win32 (API SNMP администратора для упрощения разработки SNMP-приложений).

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

3. MIB

Информация, которую система управления запрашивает от агентов, хранится в специальной информационной базе данных MIB (Management Information Base).

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

Сервис SNMP поддерживает Internet MIB II, LAN Manager MIB II, DHCP MIB и WINS MIB.

Internet MIB II

Internet MIB II — это расширение предыдущего стандарта Internet MIB I. Оно определяет 171 объект, необходимый для поиска неисправностей и анализа конфигурации (База данных Internet MIB II описана в RFC 1212 ).

LAN Manager MIB II

LAN Manager MIB II определяет приблизительно 90 объектов, которые включают такие элементы, как статистическая, сеансовая, пользовательская, регистрационная информация, и данные о совместно используемых ресурсах. К большинству объектов LAN Manager MIB II установлен доступ только для чтения, в связи с отсутствием обеспечения безопасности в SNMP.

DHCP MIB

Операционная система Windows NT 4.0 поставляется с DHCP MIB. Эта база определяет объекты наблюдения за активностью DHCP-сервера. Модуль Dhcpmib.dll автоматически устанавливается при установке сервиса DHCP Server. Он наблюдает около 14 параметров DHCP, например число полученных запросов DHCPDISCOVER, количество отказов или адресов, взятых в аренду клиентами.

WINS MIB

Windows NT 4.0 поставляется с WINS MIB. Эта база определяет объекты для наблюдения за активностью WINS-сервера. Модуль Winsmib.dll автоматически устанавливается при установке сервиса WINS Server. Он наблюдает приблизительно 70 параметров WINS, например число запросов, на которые удалось успешно ответить, количество неуспешных запросов или дату и время последнего сеанса тиражирования базы данных.

Дерево имен

Пространство имен MIB-объектов имеет иерархическую структуру. На рис. 3 видно, что оно организовано так, что каждому контролируемому объекту может соответствовать уникальное имя. Полномочия на управление частями пространства имен присваиваются отдельным организациям. Поэтому организации, в свою очередь, вправе назначать имена, не консультируясь с комитетом по Интернету. Например, 1.3.6.1.4.1.77 является пространством имен, присвоенным LAN Manager. Поскольку 1.3.6.1.4.1.77 присвоено LAN Manager, корпорации Microsoft присвоено 1.3.6.1.4.1.311, и все новые базы MIB будут созданы на этой ветви. Microsoft вправе назначать имена объектам где угодно в рамках этого пространства имен.

Идентификатор объекта в иерархии записывается как последовательность меток, начинающихся в корне и заканчивающихся самим объектом. Метки разделены точками. Например, идентификатор объекта для MIB II приведен ниже.

Имя объекта

Номер объекта

Iso.org.dod.internet.menegement.mibii

1.3.6.1.2.1

А в следующей таблице — идентификатор объекта для LAN Manager MIB.

Имя объекта

Номер объекта

Iso.org.dod.internet.private.enterprise.lanmanager

1.3.6.1.4.1.77

Пространство имен, используемое для идентификаторов объектов, — уникально и отделено от иерархического пространства имен, присвоенного именам UNIX-доменов.

4. Установка и конфигурирование сервиса SNMP

Для того чтобы использовать приложение сторонних производителей для наблюдения за компьютером, работающим под управлением Windows NT, необходимо установить и сконфигурировать сервис SNMP. Сервис SNMP также позволяет контролировать TCP/IP с помощью Performance Monitor.

4.1. Определение сообществ SNMP

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

SNMP-агент может быть членом нескольких сообществ одновременно, что позволит ему связываться с администраторами SNMP различных сообществ. Например, на рис. 4 определены два сообщества — Public и Public2. Только агенты и администраторы — члены одного сообщества — могут связываться друг с другом.

  • Agent1 может получать и посылать сообщения Manager2, потому что оба они являются членами сообщества Public2.
  • Agent2, Agent3 и Agent4 могут получать и посылать сообщения Manager1, потому что все они являются членами сообщества Public, принятого по умолчанию.

4.2. Сбор информации

Приведенные ниже инструкция и рис. 5 показывают, как сервис SNMP реагирует на запросы системы управления.

  1. Система управления SNMP посылает запрос агенту, используя имя узла агента (или его IP-адрес).

Запрос отправляется приложением на UDP-порт 161.


Имя узла преобразуется в IP-адрес любым из доступных методов разрешения, включая файл HOSTS, DNS, WINS, широковещание или файл LMHOSTS.

  1. Формируется SNMP-пакет, содержащий следующую информацию:
    • операцию get, get-next или set для одного или нескольких объектов;
    • имя сообщества и другую проверочную информацию.

Пакет передается по сети агенту на UDP-порт 161.

  1. SNMP-агент получает пакет в свой буфер.

Проверяется имя сообщества. Если оно неправильное или пакет некорректный, он отвергается.

Если имя сообщества правильное, агент проверяет имя узла или IP-адрес отправителя. Агент должен быть уполномочен принимать пакеты от системы управления. В противном случае пакет отвергается.

Запрос передается соответствующей DLL.

Если запрос для

объекта Internet MIB II

TCP DLL отыскивает информацию

объекта LAN Manager MIB II

LAN Manager DLL отыскивает информацию

объекта DHCP

DHCP MIB DLL отыскивает информацию

объекта WINS

WINS MIB DLL отыскивает информацию

DLL для этой MIB отыскивает информацию

Происходит следующее

расширенного агента MIB

Идентификатор объекта отображается в соответствующую функцию API, которая и вызывается далее. Библиотека DLL возвращает информацию агенту.

  1. SNMP-пакет с требуемой информацией отправляется назад администратору SNMP.

4.3. Установка сервиса SNMP

  1. В Control Panel дважды щелкните мышью пиктограмму Network (рис. 6, рис. 7).
  2. Выберите вкладку Services и нажмите Add (рис. 8). Появится диалоговое окно Select Network Service.
  3. Щелкните SNMP Service и нажмите ОК (рис. 9).
  4. Введите на запрос путь к установочным файлам Windows NT (рис. 10).
  5. После того как нужные файлы скопируются на компьютер, появится диалоговое окно MicrosoftSNMP Properties (рис. 11).
  6. Во вкладке Traps выберите имя сообщества Public (рис. 12).
  7. Нажмите ОК. Появится диалоговое окно Network.
  8. Нажмите Close. Появится окно Network Settings Change с предупреждением о необходимости перезагрузить компьютер (рис. 13).
  9. Нажмите Yes.
  10. Войдите в систему под именем Administrator.

Send Authentication Trap

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

Accepted Community Names

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

Accept SNMP Packets from Any Host

Если указана эта опция, пакеты SNMP не отвергаются на основе идентификаторов узлов-отправителей и указанного под опцией списка допустимых узлов

Only Accept SNMP Packets from These Hosts

Если выбрана эта опция, пакеты SNMP принимаются только с указанных в списке компьютеров

4.5. Настройка сервисов SNMP-агента

Сервис SNMP позволяет компьютеру, работающему под управлением Windows NT, информировать систему управления о деятельности на различных уровнях семейства протоколов Интернета.

Конфигурирование сервисов SNMP-агента

  1. В диалоговом окне MicrosoftSNMP Properties выберите вкладку Agent (рис. 15).
  2. В поле Contact введите контактное имя. Обычно это имя человека, использующего компьютер.
  3. В поле Location введите описание места, где установлен компьютер.
  4. В поле Service выберите сервисы, которые будут обеспечиваться агентом.

Каждый сервис информирует о транзакции на разном уровне. Сервисы, выбранные по умолчанию: Applications, End-to-End и Internet.

Сервис

Physical

компьютер, работающий под Windows NT, управляет какими-либо физическими устройствами, например повторителями (repeaters)

Datalink/ Subnetwork

компьютер, работающий под Windows NT, управляет мостом

Internet

компьютер, работающий под управлением Windows NT, действует как IP-шлюз (маршрутизатор)

End-to-End


компьютер, работающий под управлением Windows NT, действует как IP-узел. Эта опция должна быть указана всегда

Applications

компьютер, работающий под управлением Windows NT, использует любое TCP/IP-приложение. Эта опция должна быть указана всегда

4.4. Настройка безопасности

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

Конфигурирование безопасности SNMP

  1. В Control Panel дважды щелкните мышью пиктограмму Network (рис. 6, рис. 7).
  2. Выберите вкладку Services, нажмите SNMP Services и затем Properties. Появится диалоговое окно MicrosoftSNMP Properties (рис. 11).
  3. Выберите вкладку Security (рис. 14).
  4. Сконфигурируйте параметры, показанные в таблице.

Параметр

Описание

Выберите эту опцию, если

  1. Нажмите ОК.
  2. Нажмите Close.

4.6. Обнаружение ошибок

Если сервис SNMP дал сбой по какой-либо причине, это будет отмечено в системном журнале в Event Viewer. Именно туда следует заглянуть в первую очередь при возникновении проблемы, связанной с сервисом SNMP.

Просмотр сообщения об ошибках SNMP в Event Viewer

  1. Щелкните кнопку Start, укажите на Programs, затем — на Administrative Tools и выберите Event Viewer (рис. 16).
  2. Выберите пиктограмму сообщения, чтобы прочесть информацию об ошибке (рис. 17, рис. 18).

4.7. Просмотр новых объектов и наблюдение за IP-датаграммами с помощью Performance Monitor

Посредством Performance Monitor имеется возможность просмотра объектов, добавленных в результате установки сервиса SNMP. Кроме того, используя Performance Monitor, можно посмотреть изменение счетчиков активности по протоколам ICMP и IP, связанное с выполнением какой-либо команды, например Ping.

Просмотр новых объектов в Performance Monitor

  1. Щелкните кнопку Start, укажите на Programs, затем на — Administrative Tools и выберите Performance Monitor (рис. 19). Появится окно Performance Monitor (рис. 20).
  2. В меню Edit выберите Add to Chart. Появится диалоговое окно Add to Chart (рис. 21).
  3. 3. В поле Object нажмите стрелку, чтобы вывести список объектов.

Наблюдение за датаграммами IP с помощью Performance Monitor

  1. В поле Object выберите из списка ICMP. Появится список счетчиков ICMP.
  2. В поле Counters выберите Message/sec.
  3. В поле Scale установите 1.0 и нажмите Add.
  4. В поле Object выберите IP.
  5. В поле Counters выберите из списка Datagrams Sent/sec.
  6. В поле Scale установите 7. и нажмите Add.
  7. Нажмите Done. Ваш выбор появится в области отображения.
  8. В меню Options выберите Chart.
  9. Измените Vertical Maximum на 10 и нажмите ОК (рис. 22).
  10. Перетащите окно Performance Monitor в верхнюю часть экрана.
  11. В командной строке выполните Ping по адресу второго компьютера (рис. 23).

Вернитесь в Performance Monitor, и вы сможете наблюдать активность, вызванную выполнением Ping (рис. 24). В результате выполнения Ping была послана одна IP-датаграмма в секунду и записано два сообщения ICMP в секунду. Это вызвано тем, что на каждую отправленную IP-датаграмму в ответ приходит два сообщения ICMP – эхо-запрос (echo request) и эхо-ответ (echo reply).

4.8. Применение утилиты SNMPUTIL

В составе Microsoft Windows NT Resource Kit поставляется утилита Snmputil, которая проверяет корректность установки сервиса SNMP для связи с управляющими станциями SNMP. Snmputil выполняет те же самые вызовы, что и управляющая станция SNMP.

Вот ее синтаксис:

  • get — позволяет получить значение запрашиваемого идентификатора объекта;
  • getnext — позволяет получить значение объекта, следующего за заданным идентификатором;
  • walk — позволяет переходить по ветви MIВ, заданной идентификатором объекта.

Например, чтобы определить число предоставленных в аренду адресов сервером DHCP с именем DHCPserver в сообществе Public, вам понадобится ввести команду:

snmputil getnext DHCPserver Public.1.3.6.1.4.1.311.1.3.2.1.1.1

Эта команда выдаст идентификатор объекта (OID) и значение счетчика для указанного в запросе идентификатора объекта, в приведенном случае — число взятых в аренду IP-адресов.

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

позволяет определить относящиеся к DHCP объекты SNMP ( необходимо заменить нужным значением, например 192.168.40.91).

Аналогично, применяя утилиту Snmputil.ехе к объекту WINS 1.3.6.1.4.1.311.1.2.1.17 и объекту WINS 1.3.6.1.4.1.311.1.2.1.18, можно определить, сколько успешно разрешенных запросов было обработано WINS-сервером

и сколько неуспешных запросов было выполнено сервером WINS

А применение утилиты Snmputil.exe к объекту LAN Manager 1.3.6.1.4.1.77.1.1.1 и объекту LAN Manager 1.3.6.1.4.1.77.1.1.2

возвращает номер версии Windows NT Server, работающей на компьютере.

5. Заключение

Таким образом, протокол SNMP из семейства TCP/IP позволяет наблюдать и передавать информацию о состоянии компьютеров, работающих под управлением Windows NT, серверов LAN Manager, маршрутизаторов и шлюзов, мини-компьютеров или мэйнфреймов, терминальных серверов, концентраторов. SNMP использует распределенную архитектуру, состоящую из систем управления и агентов.

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

С помощью сервиса Microsoft SNMP-компьютер, работающий под управлением Windows NT, может выдавать отчет о своем состоянии системе управления SNMP в сети, использующей протокол TCP/IP.

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

Этот протокол поддерживается как Microsoft Systems Management Server, так и продуктами OpenView (Hewlett-Packard), UniCenter TNG (Computer Associates), Tivoli (IBM). Windows NT Server и Windows NT Workstation включают агентов SNMP, что позволяет управлять ими с помощью всех названных продуктов.

Протокол SNMP – что это такое и как использовать для мониторинга

Расшифровать аббревиатуру SNMP можно как Simple Network Management Protocol, то есть «простой протокол сетевого управления». Этот стандарт является одним из самых часто встречающихся при управлении устройствами в сети. В большинстве случаев этот протокол может быть использован в случаях, когда требуется контролировать исполнение на устройствах подключенных к сети заданных администратором требований. Данные, которые входят в обмен в рамках SNMP представляются в виде переменных. Благодаря им появляется возможность описания настройки управляемого объекта. Благодаря управляющим приложениям могут подаваться запросы, а в некоторых случаях и указываться переменные.

Возможности протокола

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

Основные составляющие SNMP

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

  • подчиненный объект – объект, на который отправляются разнообразные команды;
  • MIB database;
  • управляющая программа;
  • подчиненная программа (агент);
  • система, которая обеспечивает взаимодействия в сети.

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

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

Самым важным элементом считается база управляющих сведений “MIB”. Этот элемент нужен для того, чтобы описать структуру базы данных (БД), что необходимо при обмене информацией в ходе администрирования девайсов. Такая БД дает возможность сохранить данные о компонентах, которые активируются на устройстве для управления им.

Главной составляющей базы являются идентификаторы типа OID, которые позволяют задавать переменные, определяемые и считываемые благодаря SMNP.

Возможности управляющих программ

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

Примеры программного обеспечения

Существуют подобные программы, которые адаптированы к использованию на ОС Windows и Solaris. Рассмотрим некоторые из них.

Пакет SNMP от Castle Rock Computing

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

Основные характеристики продукта:

  • мониторинг устройств, WAN-соединений, серверов и приложений;
  • поддержка интернет-протокола версии 6 (IPv6);
  • поддержка SNMP v1, v2c и защищенной версии v3;
  • масштабируемая и распределяемая архитектура;
  • поддержка интеграции с сетевыми отчетами SNMPc OnLine;
  • основные/резервные серверы с автоматической отказоустойчивостью;
  • регистрация событий в Syslog;
  • удаленная консоль Windows;
  • автоматическое обнаружение сети;
  • среда для программирования и написания скриптов.

Polygon SNMP Manager

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

  • формирование структуры MIB-дерева из MIB-файлов;
  • чтение, изменение и запись параметров устройств по протоколу SNMP;
  • прием ловушки сетевых устройств с формированием событий;
  • периодический опрос элементов сети по протоколу ICMP или SNMP;
  • подключение к объектам в сети по протоколам telnet и SSH.

SNMP Explorer

Утилита для исследования и мониторинга предназначенная для агентских систем. Она предоставлена в стиле проводника в MIB, который открыт на агенте. Имеет самый простой интерфейс из всех представленных, но также и самая сложная в использовании.

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

Особенности работы базы данных MIB

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

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

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

Что такое OID

OID – ID объекта, необязательный атрибут сертификата, предоставляющий дополнительную информацию о владельце, ключах, или несущий дополнительные данные для сервисов, которые используют этот сертификат.

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

Что такое ловушка SNMP

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

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

В службах Windows также существует служба с названием “Служба ловушек SNMP”, выполняющая те же функции. На компьютерах, которые не подключены к локальной сети она не используется, но обычно включена. Для ее отключения необходимо зайти в “Пуск – Панель Управления – Администрирование – Службы” и в открывшемся списке найти указанную службу. Кликнуть по ней правой кнопкой мыши (ПКМ), далее “Свойства”, затем сменить “Тип запуска” на “Отключена”.

Инсталляция и конфигурирование SNMP

Инсталляция службы

Необходимо сделать следующее:

  1. Перейти по пути «Пуск» – «Панель управления»;
  2. Далее «Установка и удаление программ»;
  3. Найти в левой части окна пункт: «Установка компонентов Windows» и выбрать его;
  4. Далее, пункт «Средства управления и наблюдения», выбрать его и нажать “Состав”;
  5. Выбрать «Протокол SNMP»;
  6. Нажатиями по кнопкам «ОК» и «Далее» закончить инсталляцию.

Затем перейти к службам Windows и проделать следующее:

  • включить “Служба SNMP”, это нужно для включения агента;
  • запустить “Служба ловушек SNMP” для получения сообщений.

SNMP протокол — принципы, безопасность, применение

Вступление

Данная статья посвящена протоколу SNMP (Simple Network Management Protocol) — одному из протоколов модели OSI, который практически не был затронут в документации просторов RU-нета. Статья не претендует на звание «документации для разработчика», а просто отражает желание автора осветить аспекты работы с данным протоколом, объяснить его предназначение, показать его слабые места и уязвимости в системе «security».

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

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

Теория

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

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

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

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

На данный момент существует четыре базы MIB :

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

Все имена MIB имеют иерархическую структуру. Существует десять корневых алиасов (категорий):

  1. System — данная группа MIB II содержит в себе семь объектов, каждый из которых служит для хранения информации о системе (версия ОС, время работы и т.д.).
  2. Interfaces — содержит 23 объекта, необходимых для ведения статистики сетевых интерфейсов агентов (количество интерфейсов, размер MTU, скорость передачи , физические адреса и т.д.) .
  3. AT (3 объекта) — отвечают за трансляцию адресов. Более не используется. Была включена в MIB I. Примером использования объектов AT может послужить простая ARP таблица (более подробно об ARP протоколе можно почитать в статье «Нестандартное использование протокола ARP», которую можно найти на сайте www.uinc.ru в разделе «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. Ноль в конце пути говорит о скалярном типе хранимых данных. В процессе работы символьные имена объектов не используются, то есть если менеджер запрашивает у агента содержимое параметра system.sysDescr.0, то в строке запроса ссылка на объект будет преобразована в «1.1.0», а не будет передана «как есть». Далее мы рассмотрим BULK-запрос и тогда станет ясно, почему это столь важно .

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

  • GetRequest — запрос у агента информации об одной переменной.
  • GetNextRequest — дает агенту указание выдать данные о следующей (в иерархии) переменной.
  • GetBulkRequest — запрос за получение массива данных. При получении такового, агент проверяет типы данных в запросе на соответствие данным из своей таблицы и цикле заполняет структуру значениями параметров: for(repeatCount = 1; repeatCount

    Илон Маск рекомендует:  Что такое код asp loganonymous
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL