Использование SNMP в MikroTik RouteOS

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

Нет комментариевПросмотров: 2664
27июня 2018
все статьи

Что такое SNMP

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

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

На сегодняшний день описаны три версии протокола SNMP, которые одобрены IETF и включены в стек TCP/IP. В RouterOS реализована поддержка всех трёх версий протокола.

Основные понятия

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

Терминология SNMP

Рисунок 1. Терминология SNMP

Каждый из объектов имеет уникальный идентификатор, совокупность которых образует базу данных MIB.

MIB (Management Information Base) — виртуальная база данных, применяемая для управления объектами сетевых устройств. MIB, подобно DNS, сопоставляет числовые идентификаторы объектов (OID object identificator) с текстовыми, которые проще для человеческого восприятия. Например, идентификатор “1.3.6.1.2.1.1.5.0” соответствует параметру Identity в RouterOS.

MIB принято представлять в виде древовидной структуры с общим корнем, пример которой представлен на рисунке 2. Определён набор MIB по типам устройств (маршрутизаторы, мосты и т.д.), являющиеся стандартными. Однако некоторые вендоры формируют собственные базы данных с расширенным набором параметров. Например, в разделе “.1.3.6.1.2.1.2” собрана информация об интерфейсах устройства. В RouterOS “OID=.1.3.6.1.2.1.2.2.1.2.1” соответствует имени первого интерфейса, а “OID=.1.3.6.1.2.1.2.2.1.4.1” — значению MTU на этом интерфейсе.

Иерархия MIB

Рисунок 2. Иерархия MIB

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

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

Изменения в SNMPv3

В SNMPv3 были внесены некоторые изменения, по сравнению со структурой, описанной выше, справедливой для SNMP первой и второй версий.

Любое устройство, которое поддерживает работу третьей версии SNMP, называется SNMP-сущностью (SNMP-entity), которая состоит из двух структурных элементов: SNMP-engine и списка приложений (или одного приложения). Набор поддерживаемых приложений и их использование будет определять роль SNMP-сущности в сети.

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

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

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

Тип сообщения

Описание

Get Запрос значения параметра или списка параметров.
Формируется менеджером по отношению к агенту.
GetNext Запрос информации о параметре, расположенном следующим в иерархии.
Формируется менеджером по отношению к агенту.
GetBulk Запрос информации о нескольких параметрах, расположенных последовательно в иерархии.
Формируется менеджером по отношению к агенту.
Не поддерживается SNMPv1.
Response Ответ на сообщения Get и Set.
Формируется агентом по отношению к менеджеру.
Set Запрос на установку значения параметра.
Формируется менеджером по отношению к агенту.
Trap Информирование агентом менеджера о срабатывании установленного тригера.
Inform Обмен информацией MIB между SNMP-менеджерами.
Не поддерживется SNMPv1.

Аспекты безопасности

Основной претензией со стороны сообщества к протоколу SNMPv1 стала непроработанные аспекты безопасности. В протоколе используется текстовый параметр “community”, по факту являющийся паролем, передаваемым по сети в открытом виде.

В версии SNMPv2 были реализованы функции безопасности, однако предлагаемый алгоритм посчитали сложным и большее распространение получила версия SNMPv2c, в которой используется параметр “community”, аналогично SNMPv1. Кроме того, представлена версия SNMPv2u с функцией безопасности на основе пользователей, являющаяся компромиссом между SNMPv2 и SNMPv1, которая не получила широкого распространения, но предложенный алгоритм был использован в следующей версии протокола. Следует отметить, что из-за разного формата сообщений версии протокола SNMPv1 и SNMPv2c несовместимы.

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

По умолчанию, при включении поддержки SNMP на устройствах с RouterOS, поддерживаются SNMPv1 и SNMPv2 для команд Get и Set, для отправке trapов будет использоваться SNMPv1. При использовании SNMPv1 и SNMPv2 в RouterOS можно дополнительно ограничить список ip-адресов, с которых будет выполняться обработка запросов.

Реализация SNMP в RouterOS

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

Основное меню настройки

Параметр

Диапазон значений

Значение по умолчанию

Примечание

contact - - Контактные данные владельца устройства.
enabled yes|no no Включение/отключение поддержки протокола SNMP.
engine-id - - Часть идентификатора устройства.
Не поддерживается в SNMPv1, SNMPv2.
location - - Информация о местонахождении устройства
trap-community - public Значение параметра “community”, используемое при отправке trap-ов.
trap-generators interfaces|start-trap - События, для которых устройство будет формировать trap.
trap-interfaces interface_name|all - Список интерфейсов, для которых будут формироваться trap.
Необходимо, чтобы в поле trap-generators было указано interfaces.
trap-target - 0.0.0.0 ip-адрес менеджера, который будет принимать trap.
trap-version 1|2|3 1 Версия SNMP, используемая при отправке trap.

Меню настройки параметров безопасности

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

ПараметрДиапазон значенийЗначение по умолчаниюПримечание
address - 0.0.0.0 Список ip-адресов, с которыми возможно взаимодействие по SNMP.
authentication-password - - Пароль, используемый для аутентификации.
Не поддерживается в SNMPv1, SNMPv2.
authentication-protocol MD5|SHA1 MD5 Протокол, используемый при аутентификации.
Не поддерживается в SNMPv1, SNMPv2.
encryption-password - - Пароль, используемый для шифрования сообщений.
Не поддерживается в SNMPv1, SNMPv2.
encryption-protocol DES|AES DES Протокол, используемый для шифрования.
Не поддерживается в SNMPv1, SNMPv2.
name - - Наименование community.
Не поддерживается в SNMPv3.
read-access yes|no yes Предоставление доступа на чтение.
security authorized|none|private none Используемый метод обеспечения безопасности.
write-access yes|no no Предоставление доступа на запись.

По умолчанию на устройстве создан один профиль, с доступом на чтение и community=public. Следует иметь в виду, что, после активации протокола SNMP на устройстве, злоумышленник может получить информацию о вашей сети, формируя SNMP-запросы, поэтому необходимо использовать версию SNMPv3, либо переименовать/деактивировать профиль по умолчанию.

Список OID

Для того, чтобы узнать список OID’ов для опроса устройств с RouterOS, можно воспользоваться MikroTik MIB, доступную по ссылке download2.mikrotik.com/Mikrotik.mib.

Также, список OID’ов можно получить прямо на устройстве, перейдя в определённый раздел меню и выполнив команду “print oid”:

Вывод списка OID для системных параметров устройства

Рисунок 3. Вывод списка OID для системных параметров устройства

Практика

Для демонстрации практических аспектов работы SNMP обратимся к схеме на рисунке 4. В качестве R1 и R2 используются маршрутизаторы MikroTik, в качестве manager – ПК с ПО MIB Browser (программа поддерживает отправку SNMP-запросов и получение trap-ов).

Схема для демонстрации работы SNMP

Рисунок 4. Схема для демонстрации работы SNMP

Конфигурация устройств

На обоих маршрутизаторах запретим доступ на чтение для профиля по умолчанию и создадим новый профиль с доступом на чтение и запись. Укажем необходимость формирования trapов для событий, связанных с изменением статусов интерфейсов, ip-адрес менеджера и, для упрощения, в работе будем использовать SNMPv2.

R1:

R1

R2:

R2

Запрос значения параметра параметра

Выполним запрос значения имени интерфейса ether1 на R2 средствами менеджера и RouterOS:

Вывод параметров интерфейса ether1 на R2

Рисунок 5. Вывод параметров интерфейса ether1 на R2

Запрос параметра имени интерфейса ether1 на R2

Рисунок 6. Запрос параметра имени интерфейса ether1 на R2

Запрос параметра имени интерфейса ether1 на R2 средствами RouterOS

Рисунок 7. Запрос параметра имени интерфейса ether1 на R2 средствами RouterOS

Как видно на рисунках 5–7, полученное значение параметра совпадает независимо от используемого инструмента запроса.

Установка значения параметра

Изменим имя идентификатора маршрутизатора R2, используя протокол SNMP и OID= .1.3.6.1.2.1.1.5.0:

Установка нового идентификатора на R2 через MIB Browser

Рисунок 8. Установка нового идентификатора на R2 через MIB Browser

Значение идентификатора на маршрутизаторе R2

Рисунок 9. Значение идентификатора на маршрутизаторе R2

Запуск скрипта через SNMP-Set

В RouterOS существует возможность запуска заранее размещённого на устройстве скрипта через Set-сообщение протокола SNMP. Для этого используется OID= .1.3.6.1.4.1.14988.1.1.8.1.1.3.X, где X – номер скрипта в списке, начиная с 1. По факту данный OID соответствует статусу скрипта: 0 – не запущен, любое другое число — запущен.

Создадим на R1 скрипт, который будет изменять имя интерфейса ether2, и запустим его, сформировав соответствующее SNMP-сообщение.

Запуск скрипта через Set-сообщение SNMP

Рисунок 10. Запуск скрипта через Set-сообщение SNMP

Создание скрипта и результат его работы

Рисунок 11. Создание скрипта и результат его работы

Запуск скрипта через SNMP-Get

Создадим на маршрутизаторе R1 скрипт, меняющий идентификатор и запустим его, используя Get-сообщение SNMP.

Для того, чтобы узнать необходимый OID, воспользуемся утилитой snmp-walk на R2:

Использование утилиты snmp-walk на R2

Рисунок 12. Использование утилиты snmp-walk на R2

В списке обнаруженных OID можно заметить два созданных скрипта: первые два OIDа соответствуют их именам, а вторые — их статусам, которые были использованы в примере выше.

Для запуска “snmp_get_test”, необходимо в OIDе, соответствующем имени скрипта, заменить “8” на “18” и сформировать Get-запрос:

Формирование Get сообщения на R2

Рисунок 13. Формирование Get сообщения на R2

R1 отвечает на запрос сообщение с пустым значением value, однако скрипт выполняется, что подтверждает рисунок 14:

Скрипт по изменению идентификатора и результат его выполнения

Рисунок 14. Скрипт по изменению идентификатора и результат его выполнения

Представленные выше возможности по запуску скриптов через команды Set и Get свидетельствуют о необходимости тщательной проработки вопросов безопасности при внедрении SNMP на сети.

Отправка trap-ов

Проверим формирование trap-сообщений, трижды изменив статус интерфейса wlan1 на маршрутизаторе R2 (рисунок 15). На рисунке 16 показан список полученных trapов с подробным описанием одного из них.

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

Выполнение команд по включению/отключению wlan1 на R2

Рисунок 15. Выполнение команд по включению/отключению wlan1 на R2

Полученные trap-сообщения на Manager

Рисунок 16. Полученные trap-сообщения на Manager

Формирование trapов вручную

В RouterOS существует возможность вручную формировать trap-сообщения, что может быть полезно при использовании скриптов. Для создания подобного сообщения необходимо воспользоваться инструментом “/snmp send-trap”. Пример использования представлен на рисунке 17:

Пример формирования trap-сообщений через утилиту send-trap

Рисунок 17. Пример формирования trap-сообщений через утилиту send-trap

Интересно, что RouterOS не может использовать произвольное значение OID, подставляя ближайшее большее знакомое значение идентификатора, что видно на рисунке 18. Значение, передаваемое в trap-сообщении, при этом не изменяется.

Полученные trap-сообщения на Manager

Рисунок 18. Полученные trap-сообщения на Manager

Заключение

В статье рассмотрена концепция, заложенная в протокол SNMP, и её реализация в RouterOS.

Представлены примеры по использованию основных инструментов протокола: set-, get- сообщений и trap. Системный подход и навыки владения представленными инструментами позволят реализовать мониторинг в сети и продумать сценарии по реакции на сообщения системы.

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

поделиться материалом:

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

комментарии — 0