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

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

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

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

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

Рисунок 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 на этом интерфейсе.

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

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

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

Изменения в SNMPv3

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

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

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

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

Основной претензией со стороны сообщества к протоколу 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 представлены в двух разделах меню: одно используется для глобальной настройки протокола, а второе — для конфигурации параметров безопасности.

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

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

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

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

Список OID

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

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

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

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

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

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

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

R1:

R2:

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

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

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

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

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

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

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

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

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

Рисунок 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-сообщение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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