Snmp engine id что это
SNMPv3
Содержание
Описание
В отличие от v1 и v2, snmpv3 поддерживает аутентификацию и шифрование.
Users
Для каждого snmpv3 юзера можно задавать:
После того, как user вводит пароль, генерируется ключ, на основании engine-id и password, далее ключ записывается в конфигурационный файл.
После генерации ключа, пароль удаляется из конфигурационного файла.
По дефолту аутентификация не используется. Руками можно задать:
Ключ генерируется на основании пароля. Пароль состоит из 8 символов. Цифры/числа/знаки.
По дефолту шифрование тоже не используется. Руками можно задать:
Ключ генерируется на основании пароля. Пароль состоит из 8 символов. Цифры/числа/знаки.
Правила доступа
Настраиваются через VACM (view-based access control model). Группы определяют набор snmp пользователей с одинаковыми правами. Группе задается ограничение доступа. Привелегии доступа определяются View. Конфигурируем группу с ограничениями доступа.
Причем для одной группы можно задавать несколько разных видов view. Сами view настраиваются в
Привязка security-model к группе
По сути это обозначение какие юзеры к какой группе будут принадлежать. И как следствие какие права будут у каждого юзера.
Если мы использует v3 + v1/v2, то нужно сконфигурировать разные security-name для разных версий.
Traps
В snmpv3 используются traps and informs.
Traps notifications
Trap Notification Filter
Для фильтрации трапов используются фильтры, все логично.
Фильтруется по MIB-дереву с указанием include/exclude OID.
Target address
Target Parameters
security-name для snmpv3 = user, для v1/v2 = snmp community.
Configuration
Informs
Вид трапов, с гарантированной доставкой.
Отличие: inform хранятся в памяти и перелылаются с определенной периодичностью определенное кол-во раз, пока:
Используют тот же socket/port, что и trap, но имеют другую структуру PDU.
Конфигурация отличается только типа Notification и заданием параметров timeout и retry:
Engine-ID
Remote
Для отправки и приема inform сообщений SNMPv3 user’у на удаленном устройстве, нам придется задать remote engine-id, потому что он играет роль при создании ключей аутентификации и шифрования.
Local
Local engine-ID является административно уникальным идентификатором для механизма snmpv3 и используются только для идентификации.
По дефолту IP роутера.
Ещё один блог сисадмина
воскресенье, 11 сентября 2016 г.
Системы мониторинга, SNMPv3 и engineID
Перевод: Monitoring Systems, SNMPv3 and the engineID
Автор: Михаэль Шварцкопф (Michael Schwartzkopff)
Поскольку изначально станция управления не знает значения engineID агента на управляемом устройстве, в RFC 5343 описан способ первоначального обнаружения engineID.
Защита от повторного воспроизведения
Стандарт SNMPv3 также защищает обмен информацией от атак повторного воспроизведения, когда злоумышленник записывает пакеты и позже отправляет их повторно в сторону станции-получателя, чтобы спровоцировать какую-то реакцию. Для защиты станция управления сначала спрашивает у агента, сколько раз он уже перезагружался (snmpEngineBoots) и как много времени прошло с момента последней перезагрузки (snmpEngineTime). Станция управления шифрует данные вместе с количеством загрузок и временем, прошедшим с момента последней загрузки агента. Агент может правильно расшифровать пакет только если его время сочетается со временем поступления запроса. Отметим, что в SNMPv3 используется не абсолютное время, а относительное время кадра. Станция управления может принять информацию от контролируемого устройства, даже если время на обеих системах не совпадает.
Обмен информацией при включенном шифровании SNMPv3 выглядит следующим образом:
Как можно видеть, любая проблема с интерпретацией engineID, snmpEngineBoots или snmpEngineTime приводит к ошибке обмена зашифрованными данными.
Проблемы начинаются с того, что внезапно обнаруживается устройство, не отвечающее на зашифрованные запросы SNMPv3 от системы Zabbix. При проверке настроек SNMP при помощи snmpget или snmpwalk из командной строки сервера мониторинга проблем не обнаруживается. Все запросы из командной строки завершаются успешно.
Теперь запустим tcpdump, чтобы проверить обмен данными построчно. В первом пакете станция управления запрашивает у агента его engineID:
Как можно увидеть, в запрос не включается имя пользователя (U=), количество загрузок равно нулю (B=0), как и время с момента последней загрузки (T=0). В следующем пакете агент предоставляет станции управления необходимую информацию:
Агент сообщает станции управления свой engineID, что он загружался уже 28 раз, а с момента последней загрузки прошло 27 секунд. И теперь станция управления ведёт себя совершенно странно. В следующей строке можно увидеть такой пакет:
Можно увидеть, что станция управления отправляет в запросе 27 загрузок и 178 секунд с момента последней загрузки, что не соответствует их текущим значениям. Агент сообщил о 28 загрузках и 27 секундах, что в два раз меньше прошлого значения. И конечно, агент отвечает следующим образом:
Этим OID’ом агент сообщает станции управления, что запрошенный PDU не может быть расшифрован, потому что окно приемлемого времени уже прошло.
Как я написал выше, тот же SNMP-запрос из командной строки работает отлично. SNMP-запрос с аутентификацией, но без шифрования тоже работает. Я встречал эту проблему в Zabbix, установленном на сервере Linux и на Spectrum-сервере в Windows-окружении. Со стороны агента были Cisco IOS, Cisco Nexus или Linux-компьютер с установленным net-snmp.
Похоже, Zabbix-сервер неправильно интерпретирует snmpEngineBoots и snmpEngineTime. Но разработчики Zabbix клятвенно заверяют, что они используют библиотеку snmp из net-snmp. Те же библиотеки используются в командной строке. Так что расследование, видимо, зашло в тупик.
С другой стороны, имеется несколько отчётов об ошибках на сайте Zabbix, которые указывают на не уникальные значения engineID у агентов. За подробностями можно обратиться к отчёту об ошибке ZBX-2152.
Поскольку понять причину проблемы не удалось, я поменял engineID у агента:
Эта строка в файле конфигурации snmpd.conf агента изменяет идентификатор со случайного значения, предоставленного net-snmp, на MAC-адрес интерфейса eth0, который каким-то образом должен оказаться и правда уникальным. Конечно, только после перезагрузки. И правда, Zabbix восстановил обмен данными с агентом и начал собирать данные. Проблема решена.
Если у вас есть какие-то дополнительные вопросы, свяжитесь со мной по электронной почте ms@sys4.de (примечание переводчика: автор не понимает по-русски, пишите на английском или немецком).
Manual:SNMP
Applies to RouterOS: v5
Contents
Overview
Standards: RFC 1157 RFC 3414 RFC 3416
Package: system
Simple Network Management Protocol (SNMP) is an Internet-standard protocol for managing devices on IP networks. SNMP can be used to graph various data with tools such as CACTI, MRTG or The Dude
SNMP write support is only available for some OIDs. For supported OIDs SNMP v1, v2 or v3 write is supported
Note: SNMP will respond to the query on the interface SNMP request was received from forcing responses to have same source address as request destination sent to the router
Note: starting 6.18 SNMP implements OID blacklisting. Timeout for OID is 30s when it is blacklisted for 600s.
Quick Configuration
To enable SNMP in RouterOS:
You can also specify administrative contact information in the above settings. All SNMP data will be available to communities configured in community menu.
General Properties
This sub menu allows to enable SNMP and to configure general settings.
Community Properties
Sub-menu: /snmp community
This sub-menu allows to set up access rights for the SNMP data.
There is little security in v1 and v2c, just Clear text community string („username“) and ability for Limiting access by IP adress.
Warning: Default settings only have one community named public without any additional security settings. These settings should be considered insecure and should be adjusted according required security profile.
| Property | Description |
|---|---|
| address (IP/IPv6 address; Default: 0.0.0.0/0) | Addresses from which connections to SNMP server is allowed |
| authentication-password (string; Default: «») | Password used to authenticate connection to the server (SNMPv3) |
| authentication-protocol (MD5 | SHA1; Default: MD5) | Protocol used for authentication (SNMPv3) |
| encryption-password (string; Default: «») | password used for encryption (SNMPv3) |
| encryption-protocol (DES | AES; Default: DES) | encryption protocol to be used to encrypt the communication (SNMPv3). AES (see rfc3826) available since v6.16. |
| name (string; Default: ) | |
| read-access (yes | no; Default: yes) | Whether read access is enabled for this community |
| security (authorized | none | private; Default: none) | |
| write-access (yes | no; Default: no) | Whether write access is enabled for this community. Read more >> |
Management information base (MIB)
The Management Information Base (MIB) is the database of information maintained by the agent that the manager can query. You can download the latest MikroTik RouterOS MIB file (Last updated: 15-SEP-2020).
MIBs used in RouterOS v6.x:
Object identifiers (OID)
Each OID identifies a variable that can be read via SNMP. Although the MIB file contains all the needed OID values, you can also print individual OID information in the console with the print oid command at any menu level:
Traps
SNMP traps enable router to notify data collector of interface changes and SNMP service status changes by sending traps. It is possible to send out traps with security features to support SNMPv1 (no security). SNMPv2 and variants and SNMPv3 with encryption and authorization.
For SNMPv2 and v3 you have to set up appropriately configured community as a trap-community to enable required features (password or encryption/authorization)
SNMP write
Since RouterOS v3, SNMP write is supported for some functions. SNMP write allows to change router configuration with SNMP requests. Consider to secure access to router or to router’s SNMP, when SNMP and write-access are enabled.
To change settings by SNMP requests, use the command below to allow SNMP write for the selected community, Write-access option for SNMP is available from v3.14,
System Identity
It’s possible to change router system identity by SNMP set command,
SNMPset command above is equal to the RouterOS command,
Reboot
It’s possible to reboot the router with SNMP set commamd, you need to set value for reboot SNMP settings, which is not equal to 0,
Reboot snmpset command is equal to the RouterOS command,
Run Script
SNMP write allows to run scripts on the router from system script menu, when you need to set value for SNMP setting of the script,
The same command on RouterOS,
Runing scripts with GET
It is possible to run /system scripts via SNMP GET request of the script OID (since 6.37). For this to work SNMP community with write permission is required. OIDs for scripts can be retrieved via SNMPWALK command as the table is dynamic.
Использование SNMP в MikroTik RouteOS
Ближайшие
тренинги Mikrotik
MTCEWEEnterprise Wireless Engineer
Места
проведения
г. Санкт-Петербург, Крестовский остров, Северная дорога, дом 12.
г. Санкт-Петербург, ст. м. «Приморская»,
ул. Одоевского, д. 24 к. 1, 2 этаж
Принципы работы протокола SNMP, особенности реализации и конфигурации в ОС RouterOS. Сценарии использования для мониторинга и управления сетевыми устройствами.
Что такое SNMP
Современная сетевая инфраструктура требует постоянного контроля за состоянием элементов сети и оперативного вмешательства при критических значениях показателей, напрямую влияющих на качество услуг. С ростом числа устройств в сети ручной контроль таких показателей становится трудоёмкой задачей, для решения которой был разработан специальный протокол — 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.
Формируется агентом по отношению к менеджеру.
Формируется менеджером по отношению к агенту.
Не поддерживется 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 представлены в двух разделах меню: одно используется для глобальной настройки протокола, а второе — для конфигурации параметров безопасности.
Основное меню настройки
Значение по умолчанию
Не поддерживается в SNMPv1, SNMPv2.
Необходимо, чтобы в поле trap-generators было указано interfaces.
Меню настройки параметров безопасности
В меню настроек безопасности протокола 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”:
Рисунок 3. Вывод списка OID для системных параметров устройства
Практика
Для демонстрации практических аспектов работы SNMP обратимся к схеме на рисунке 4. В качестве R1 и R2 используются маршрутизаторы MikroTik, в качестве manager – ПК с ПО MIB Browser (программа поддерживает отправку SNMP-запросов и получение trap-ов).
Рисунок 4. Схема для демонстрации работы SNMP
Конфигурация устройств
На обоих маршрутизаторах запретим доступ на чтение для профиля по умолчанию и создадим новый профиль с доступом на чтение и запись. Укажем необходимость формирования trapов для событий, связанных с изменением статусов интерфейсов, ip-адрес менеджера и, для упрощения, в работе будем использовать SNMPv2.
Запрос значения параметра параметра
Выполним запрос значения имени интерфейса ether1 на R2 средствами менеджера и RouterOS:
Рисунок 5. Вывод параметров интерфейса ether1 на R2
Рисунок 6. Запрос параметра имени интерфейса ether1 на R2
Рисунок 7. Запрос параметра имени интерфейса ether1 на R2 средствами RouterOS
Как видно на рисунках 5–7, полученное значение параметра совпадает независимо от используемого инструмента запроса.
Установка значения параметра
Рисунок 8. Установка нового идентификатора на R2 через MIB Browser
Рисунок 9. Значение идентификатора на маршрутизаторе R2
Запуск скрипта через SNMP-Set
Создадим на 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 может быть использован при аудите сети, автоматическом построении схем и автоматизации процессов настройки.
Вам помогла эта статья?
Приглашаем пройти обучение в нашем тренинг-центре и научиться настраивать оборудование MikroTik на профессиональном уровне! Узнайте расписание ближайших курсов и бронируйте место!