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

3. В списке Компоненты Windows установите галочку в пункте Компонент SNMP и нажмите OK .

4. Откройте службы компьютера: контекстное меню значка Мой компьютер на рабочем столе -> Управление -> Службы и приложения -> Службы . Найдите в списке Служба SNMP и запустите её, если она не была запущена. Иногда для того, чтобы эта служба появилась в списке, необходимо после действий 1-3 перезагрузить компьютер. Если сразу после этих действий вам не удалось удалённо из программы подключиться к компьютеру по SNMP, то выполните действия из раздела (см. ниже).

Примечания

• Для выполнения данной процедуры необходимо входить в группу "Администраторы" на локальном компьютере или получить соответствующие полномочия путем делегирования. Если компьютер присоединен к домену, эту процедуру могут выполнять члены группы "Администраторы домена". При этом по соображениям безопасности рекомендуется использовать команду Запуск от имени .
• Некоторым компонентам Windows перед использованием требуется настройка. Если один или несколько таких компонентов были установлены, но не были настроены, при нажатии кнопки Установка компонентов Windows отображается список компонентов, требующих настройки. Для запуска мастера компонентов Windows нажмите кнопку Компоненты .
• После установки SNMP запускается автоматически.

Настройка свойств безопасности SNMP

Настройка свойств безопасности SNMP

1. Откройте окно «Управление компьютером» .
2. В дереве консоли щелкните узел Службы (Службы и приложения / Службы ).
3. В области сведений выберите Служба SNMP .
4. В меню Действие выберите команду Свойства .
5. На вкладке Безопасность установите флажок Посылать ловушку проверки подлинности , если требуется отправлять ловушку при каждом сбое проверки подлинности.
6. В группе Приемлемые имена сообществ нажмите кнопку Добавить .
7. В поле Права сообщества выберите уровень доступа данного узла для обработки запросов SNMP от выбранного сообщества (рекомендуется значение READ ONLY ).
8. В поле Имя сообщества введите имя сообщества с учетом регистра символов и нажмите кнопку Добавить . Именем сообщества может быть любое слово. Этот параметр используется в качестве пароля доступа к SNMP этого компьютера. Обычно именем сообщества является слово public , однако в целях безопасности рекомендуется задать другое. Запомните введенное имя сообщества - его нужно будет указать при создании сенсора.
9. Укажите, следует ли принимать пакеты SNMP от узла:
   • чтобы принимать запросы SNMP от любого узла сети независимо от удостоверения, выберите параметр Принимать пакеты SNMP от любого узла ;
   • чтобы ограничить прием пакетов SNMP, выберите Принимать пакеты SNMP только от этих узлов , нажмите кнопку Добавить , введите имя, IP-адрес или IPX-адрес соответствующего узла и снова нажмите кнопку Добавить .

Важно!

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

Примечания

• Для выполнения данной процедуры необходимо входить в группу "Администраторы" на локальном компьютере или получить соответствующие полномочия путем делегирования. Если компьютер присоединен к домену, эту процедуру могут выполнять члены группы "Администраторы домена". При этом по соображениям безопасности рекомендуется использовать команду Запуск от имени.
• Чтобы открыть компонент "Управление компьютером", нажмите кнопку Пуск , выберите пункт Панель управления , дважды щелкните значок Администрирование , затем дважды щелкните значок Управление компьютером .
• Имена сообществ и узлов можно добавлять по необходимости.
• Для изменения записи следует выделить ее и нажать кнопку Изменить . Для удаления выделенной записи нажмите кнопку Удалить .
• Изменения существующих настроек SNMP вступают в силу немедленно. Перезапускать службу SNMP для ввода настроек в силу не требуется.
• Протокол IPX/SPX недоступен в Windows XP 64-bit Edition (Itanium) и 64-разрядных версиях семейства Windows Server 2003.

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

Мы попытались упростить процесс настройки сбора данных и событий SNMP и позволить пользователям во время этого процесса:

• Никогда не заглядывать внутрь MIB-файлов
• Не знать, что такое OID-ы и никогда не оперировать с ними
• Не пользоваться отдельной SNMP-утилитой для предварительного просмотра данных во время настройки

Шаг 1: добавляем MIB-файлы

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

Модуль SNMP нашей системы AggreGate Network Manager при старте загружает все MIB-файлы, находящиеся в специальной папке сервера, после чего позволяет добавлять новые при помощи простого диалога:

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

Редактор MIB-ов

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

Таблица MIB-ов

Шаг 2: подключаем SNMP-устройство

В случае построения классической системы мониторинга этот шаг обычно не требуется, так как все устройства добавляются в систему автоматически во время периодического обнаружения устройств (network discovery). Тем не менее, во время добавления обнаруженных сканированием сети устройств выполняются примерно те же шаги:

Шаг 3: изучаем снимок устройства

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

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

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

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

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

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

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

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

При наведении на заголовок столбца во всплывающей подсказке видно описание поля, полученное из MIB-файла, а также его тип и OID:

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

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

Поскольку единая модель данных платформы AggreGate ориентирована на работу с таблицами, таблицы данных SNMP являются идеальным кандидатом на обработку встроенными средствами. При помощи них реализуется построение топологии L2/L3, анализ данных MPLS TE и MPLS VPN, мониторинг и создание тестов IP SLA, а также сотни более простых задач.

Шаг 4: настраиваем периоды опроса и сроки хранения

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

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

Настройки опроса и хранения

В диалоге настроек хранения показывается только срок хранения «сырых» данных в обычной базе данных (реляционной или NoSQL, в зависимости от настроек сервера). В большинстве случаев данные SNMP хранятся в кольцевой базе данных (Round-Robin Database, RRD), которая встроена в платформу AggreGate. На тему создания каналов статистики , которые перекладывают метрики и части таблиц в кольцевую БД, будет отдельная статья.

Шаг 5: переходим к обработке и визуализации данных

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

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

В результате

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

При настройке мониторинга не требуется ручное указание названий MIB-ов, ввод OID-ов и других низкоуровневых идентификаторов. Это делает настройку SNMP-мониторинга достаточно быстрой и легкой.

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

А поподробнее?

Эта статья вообще не касается получения, обработки и отправки ловушек SNMP, работы по SNMP v3, и многих других аспектов.

Для более подробного рассказа мы приглашаем всех хабражителей на вебинар Мониторинг и управление по SNMP , который состоится 26 мая 2015 года в 11:00 по московскому времени. На этом вебинаре мы «вживую» продемонстрируем весь вышеописанный процесс, а также многие другие способы мониторинга сетевого, серверного и нестандартного оборудования при помощи SNMP.

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

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

Читайте также:

Данное руководство поможет установить и подготовить к работе SNMP на сервере Ubuntu 14.04.

Примечание : С небольшими коррективами руководство можно выполнить на другом дистрибутиве Linux.

1: Установка демона и утилит SNMP

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

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

sudo apt-get update
sudo apt-get install snmp snmp-mibs-downloader

Перейдите на сервер 2 и установите на него пакеты snmp.

sudo apt-get update
sudo apt-get install snmpd

2: Настройка менеджера SNMP

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

Откройте файл /etc/snmp/snmp.conf:

sudo nano /etc/snmp/snmp.conf

Файл содержит несколько закомментированных строк и всего одну незакомментированную строку. Чтобы позволить менеджеру импортировать файлы MIB, нужно просто закомментировать следующую строку:

Сохраните и закройте файл.

3: Настройка агента SNMP

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

Для начала нужно открыть конфигурационный файл демона на агенте.

sudo nano /etc/snmp/snmpd.conf

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

# Listen for connections from the local system only
#agentAddress udp:127.0.0.1:161
# Listen for connections on all interfaces (both IPv4 *and* IPv6)
agentAddress udp:161,udp6:[::1]:161

Затем нужно временно добавить строку createUser. Эта директива обычно не хранится в этом файле, поэтому добавить её нужно только на некоторое время.

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

Создавая нового пользователя, укажите тип аутентификации (MD5 или SHA) и пароль (минимум 8 символов). Если вы планируете использовать шифрование для передачи данных, вы также должны указать протокол шифрования (DES или AES) и пароль для него (по желанию). Если вы не выберете пароль для протокола шифрования, вместо него будет использоваться пароль аутентификации.

createUser bootstrap MD5 temp_password DES

Теперь новый пользователь добавлен. Выберите уровень доступа для этого пользователя (bootstrap), а также для пользователя, который будет создан позже (он условно называется demo). Передайте им права на чтение и запись при помощи директивы rwuser (права только на чтение передаёт директива rouser).

Чтобы сделать шифрование обязательным, после настроек пользователя добавьте параметр priv. Чтобы ограничить пользователя определённой частью MIB, нужно указать OID высшего уровня, к которому пользователь должен иметь доступ.

rwuser bootstrap priv
rwuser demo priv

Сохраните и закройте файл.

Перезапустите сервис snmpd:

sudo service snmpd restart

Теперь можно перейти на сервер 1 (менеджер) и подключиться к агенту, чтобы создать обычного пользователя. Для этого используется инструмент snmpusm. Вам нужно знать IP агента.

4: Общая структура команд SNMP

При работе с набором net-snmp используется несколько шаблонов для вызова команд.

Сначала нужно пройти аутентификацию и подключиться к демону SNMP. Для этого могут понадобиться следующие флаги:

• -v (version): задаёт версию SNMP-протокола (в данной статье используется версия 3).
• -c (community): определяет версию строки доступа (v1 или v2); поскольку мы используем версию 3, этот параметр нам не нужен.
• -u (user-name): указывает имя пользователя, которого нужно авторизовать. Чтобы пользователь имел право на чтение и изменение, он должен быть зарегистрирован в SNMP.
• -l (level): задаёт уровень безопасности для подключения. Можно использовать такие значения: noAuthNoPriv (без аутентификации), authNoPriv (аутентификация без шифрования) и authPriv (аутентификация и шифрование). Кроме того, указанный пользователь должен иметь доступ к выбранному уровню безопасности, иначе он не сможет подключиться.
• -a (protocol): определяет протокол аутентификации, MD5 или SHA. Это значение должно совпадать с информацией пользователя, указанной при его создании.
• -x (protocol): определяет протокол шифрования, DES или AES. Это значение должно совпадать с информацией пользователя, указанной при его создании. Протокол шифрования обязательно нужно указывать, если в настройках пользователя есть параметр priv.
• -A (passphrase): пароль для аутентификации пользователя.
• -X (passphrase): пароль шифрования. Если вы не указали этот пароль, вместо него будет использоваться пароль для аутентификации. Это пароль обязательно нужно указывать, если в настройках пользователя есть параметр priv.

Теперь вы можете написать команду. Ваша команда может отличаться в зависимости от параметров пользователя. Общий синтаксис:

snmp_command -u bootstrap -l authPriv -a MD5 -x DES -A temp_password -X temp_password remote_host snmp_sub_command_or_options

К примеру, чтобы убедиться, что пользователь bootstrap доступен, нужно запустить на менеджере:

snmpget -u bootstrap -l authPriv -a MD5 -x DES -A temp_password -X temp_password remote_host 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: Linux target 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64

Строка 1.3.6.1.2.1.1.1.0 – это OID, который отвечает за отображение данных сиситемы. В удаленной системе он выведет результат команды uname –a.

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

5: Создание обычного пользователя

Привилегии пользователя demo уже указаны в файле snmpd.conf,но пока что этого пользователя не существует. Используйте аккаунт bootstrap в качестве шаблона для нового пользователя.

Перейдите на сервер 1 (менеджер) и создайте пользователя по шаблону с помощью инструмента snmpusm. Общий синтаксис имеет такой вид:

snmpusm authentication_info remote_host create new_user existing_user

С помощью шаблона (bootstrap) и флагов вы можете создать пользователя с необходимым уровнем привилегий.

snmpusm -u bootstrap -l authPriv -a MD5 -x DES -A temp_password -X temp_password remote_host create demo bootstrap
User successfully created.

Теперь на удалённом сервере есть полностью готовый к работе пользователь demo. Однако пока что он использует те же учётные данные, что и bootstrap. Измените пароль пользователя. Выполните аутентификацию как demo и выберите новый пароль (8 символов минимум).

snmpusm -u demo -l authPriv -a MD5 -x DES -A temp_password -X temp_password remote_host passwd temp_password my_new_password
SNMPv3 Key(s) successfully changed.

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

Теперь можно использовать загруженные ранее дополнительные определения MIB, чтобы запросить значение по имени, а не по ID его OID.

Команда сообщит, когда в последний раз перезапускался сервис SNMP:

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (383018) 1:03:50.18

6: Создание конфигурационного файла клиента

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

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

Если вы хотите использовать одни учётные данные для всех валидных пользователей на менеджере, вы можете поместить данные в файл snmp.conf.

sudo nano /etc/snmp/snmp.conf

Если же вы хотите создать учётные данные только для одного пользователя, вы можете создать скрытый каталог.snmp и создать в нём файл:

mkdir ~/.snmp
cd ~/.snmp
nano snmp.conf

Вне зависимости от вашего выбора файл будет содержать одни и те же параметры.

Команды для аутентификации вы найдёте в таблице ниже. Справа находятся директивы, которые нужно добавить в snmp.conf.

С помощью этих данных вы можете составить файл snmp.conf. В данном случае он выглядит так:

defSecurityName demo
defSecurityLevel authPriv
defAuthType MD5
defPrivType DES
defAuthPassphrase my_new_password
defPrivPassphrase my_new_password

Сохраните и закройте файл.

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

snmpget -u demo -l authPriv -a MD5 -x DES -A my_new_password -X my_new_password remote_host sysUpTime.0

теперь можно вводить:

snmpget remote_host sysUpTime.0

Теперь команды значительно короче.

7: Удаление пользователя

Пользователь bootstrap был нужен как шаблон для создания других пользователей. Теперь его можно удалить.

Перейдите на сервер 2 (агент) и откройте /etc/snmp/snmpd.conf.

Найдите и закомментируйте (или удалите) строки с параметрами пользователя bootstrap.

#createUser bootstrap MD5 temp_password DES
#rwuser bootstrap priv

Сохраните и закройте файл.

Перезапустите SNMP.

sudo service snmpd restart

Теперь в файле snmpd.conf нет директив createUser.

Чтобы полностью удалить пользователя bootstrap из usmUserTable, запустите на менеджере:

snmpusm remote_host delete bootstrap

Вы получите такой вывод:

User successfully deleted.

Заключение

Теперь у вас есть рабочая установка клиент- сервер SNMP. Вы можете установить демон на другие хосты и добавить их в инфраструктуру.

В речь пойдёт о базовых инструментах net-snmp.

Tags: ,

Приветствую тебя, гость и постоянный читатель. Пришлось в последнее время внедряться в сетевой мониторинг. Очень актуальная тема для мониторинга - 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 ).

Структура PDU

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

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

При этом, содержимое 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 , которые стоит учитывать:

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

При получении 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 , S tructure of M anagement I nformation ). Так же, имеется некий стандарт, называемый абстрактный синтаксис нотаций - ASN.1. Который тоже участвует в описании протокола SNMP и базы MIB . А еще имеется базовые правила кодирования BER (B asic E ncoding R ules), определяющие кодирование сущностей, применяемых в SNMP.

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

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

Дерево объектов MIB подобно . Тут аналогично имеются символьные имена (аналогично 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 OID=1.3.6.1.1 (iso.org.dod.internet. directory ) – зарезервировано для использования в будущем
• mgmt OID=1.3.6.1.2 (iso.org.dod.internet. mgmt )- в этой ветке находится стандартные ответвления объектов.
• experimental OID=1.3.6.1.3 (iso.org.dod.internet. experimental )- это ветка для экспериментов разработчиков. (не отображено на схеме )
• private OID=1.3.6.1.4 (iso.org.dod.internet. private )– раздел предназначен для использования производителями оборудования.

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

Давайте рассмотрим работу протокола SNMPv2c (и SNMPv1 ) с точки зрения безопасности. При рассмотрении структуры пакета 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

• RFC 1155 (STD 16) - Структура и идентификация управляющей информации в сетях на основе стека протоколов TCP/IP
• RFC 1156 (Historic) - База управляющей информации для сетевого управления в сетях на основе стека протоколов TCP/IP
• RFC 1157 (Historic) - Простой протокол сетевого управления (SNMP)
• RFC 1213 (STD 17) - База управляющей информации для сетевого управления в сетях на основе стека протоколов TCP/IP: MIB-II
• RFC 1452 (Informational) - "Сосуществование версий 1 и 2 Интернет-стандарта Network Management Framework (пересмотрен в RFC 1908)
• RFC 1901 (Experimental) - Введение в SNMPv2 на основе сообществ
• RFC 1902 (Draft Standard) - Структура управляющей информации для SNMPv2 (пересмотрен в RFC 2578)
• RFC 1908 (Standards Track) - Сосуществование версий 1 и 2 Интернет-стандарта Network Management Framework
• RFC 2570 (Informational) - Введение в версию 3 Интернет-стандарта Network Management Framework (пересмотрен в RFC 3410)
• RFC 2578 (STD 58) - Структура управляющей информации, версия 2 (SMIv2)
• RFC 3410 (Informational) - Вопросы введения и применения Интернет-стандарта Network Management Framework"
• STD 62

• RFC 3411 - Архитектура для описания SNMP Management Framework
• RFC 3412 - Обработка и отправление сообщений для SNMP
• RFC 3413 - Приложения SNMP
• RFC 3414 - Модель безопасности на основе пользователей (USM) для SNMPv3
• RFC 3415 - View-based Access Control Model (VACM) для SNMP
• RFC 3416 - Версия 2 протокольных операций для SNMP
• RFC 3417 - Привязки к транспорту для SNMP
• RFC 3418 - База управляющей информации (MIB) для SNMP
• RFC 3430 (Experimental) - SNMP над привязками к транспорту в TCP
• RFC 3584 (BCP 74) - Сосуществование версий 1, 2 и 3 Интернет-стандарта Network Management Framework
• RFC 3826 (Proposed) - Алгоритм шифрования AES (Advanced Encryption Standard) в модели безопасности на основе пользователей в SNMP
• RFC 5343 (Proposed) - Контекстное EngineID-обнаружение в SNMP
• RFC 5590 (Draft) - Транспортная подсистема для SNMP
• RFC 5591 (Draft) - Транспортная модель безопасности для SNMP
• RFC 5592 (Proposed) - Транспортная модель Secure Shell для SNMP
• RFC 5608 (Proposed) - Использование службы аутентификации удаленных пользователей по коммутируемым каналам связи (RADIUS) в транспортных моделей в SNMP
• RFC 6353 (Draft) - Транспортная модель TLS для SNMP

С Уважением, Mc.Sim!

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

В Windows 10 служба SNMP доступна в виде отдельного компонента Windows и по умолчанию не устанавливается. Рассмотрим, как установить и настроить SNMP в Windows 10.

Установка службы SNMP в WIndows 10

Вы можете проверить, установлена ли в вашей системе служба SNMP с помощью PowerShell командлета :

Get-Service -Name snmp*

Вы можете установить службу SNMP через панель управления. Перейдите в Панель управления\Все элементы панели управления\Программы и компоненты\ Включение или отключение компонентов Windows).

В списке компонентов выберите Simple Network Management Protocol (SNMP)/протокол, и WMI SNMP Provider / Поставщик WMI для SNMP (обеспечивает доступ к информации SNMP через интерфейсы Windows Management Instrumentation) и нажмите Ок.

Также вы можете установить службы SNMP из командной строки PowerShell:

Enable-WindowsOptionalFeature -online -FeatureName SNMP

Настройка службы SNMP в Windows 10

После установки службы SNMP должны запустится автоматически. Откройте консоль управления Services (services.msc). В списке службы должны появится две новые службы:

• SNMP Service – это основная служба SNMP агента, которая отслеживают активность и отправляет информацию;
• SNMP Trap — получает сообщения ловушки (trap messages) от локальных или удаленных агентов SNMP, и пересылает сообщения в управляющие программы SNMP, которые работают на этом компьютере.

Откройте свойства службы SNMP. Если она остановлена, запустите ее, нажав кнопку Start и измените тип запуска (Startup type) на автоматический.

Перейдите на вкладку Agent. Заполните поля contact и location (здесь вы можете указать контактное имя пользователя и местоположение компьютера), и выберите список сервисов, данные которых нужно собирать и отправить устройству мониторинга.

Доступны следующие типы сервисов:

• Physical
• Applications
• Internet
• End-to-end
• Datalink and subnetwork

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

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

Community — это имя, которое обладает такими же функциями, как логин и пароль.

Нажмите кнопку Добавить и укажите имя Community и один из пяти уровней доступа (None, Notify, READ ONLY, READ WRITE, READ CREATE). READ WRITE – это максимальный уровень доступа, при которых сервер управления SNMP может вносить изменения в систему. В системах мониторинга обычно достаточно выбрать READ ONLY, при этом сервер мониторинга может только опрашивать систему, но не вносить изменения.

Совет . Вы можете выбрать опцию ‘Принимать пакеты SNMP от любого узла’/Accept SNMP packages from these hosts, но это не безопасно.

Сохраните изменения и перезапустите службу SNMP.

На этом настройка службы SNMP в Windows 10 по сути завершена. Если вам нужно включить SNMP сразу на множестве компьютеров, вы можете удаленно установить и настроить службы с помощью PowerShell или GPO.