Пример обработки дерева mib

Добавил пользователь Владимир З.
Обновлено: 19.09.2024

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

Центр для частей пространства имен назначается отдельным организациям. Это позволяет организациям назначать имена без консультации с Интернетом для каждого назначения. Например, пространство имен, назначенное Microsoft, — это 1.3.6.1.4.1.311, которое определено в MSFT. MIB. Корпорация Майкрософт имеет право назначать имена объектам в любом месте под этим пространством имен.

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

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

Немного теории

Общие понятия

Своими словами, чтобы было понятнее - SNMP состоит из 3 частей:

Агента, настроенного на сетевом устройстве;
Программы-диспетчера, настроенной на компьютере (компьютер тут Network Management Station, NMS);
Кроме этого на устройстве есть База Управляющей Информации (MIB), где собственно и хранятся нужные данные.

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

Взаимодействие между диспетчером и агентом происходит 2 разными способами:

При наступлении определённых заранее событий на устройстве, агент самостоятельно отсылает данные о событии диспетчеру - ловушка SNMP;
Диспетчер собирает статистику по заранее заданным параметрам, опрашивая с определённым интервалом агента - запрос SNMP GetRequest.

Это если на устройстве для диспетчера выдано право только на чтение (RO) базы MIB, если же выдано право на запись (RW), то есть дополнительная возможность:

Диспетчер изменяет заранее заданные параметры в MIB, посылая запрос агенту - запрос SNMP SetRequest

Понятие строки сообщества - это пароль, который проверяется при попытке подключения к устройству по SNMP (для версии SNMP 1 и 2). То есть тут нет связки логин/пароль - есть строка сообщества, которая сразу и логин, и пароль.

Последнее, что тут нужно сказать, важный момент: агент и диспетчер используют разные порты. Агент принимает запросы на 161/UDP порту, отправляет информацию диспетчеру на 162/UDP порт.

Версии SNMP

Существует 3 версии SNMP:

Версия 1 - основной стандарт;
Версия 2c - доработанная в плане производительности версия 1, не включает в себя безопасность версии 2 и неофициально известна как SNMPv1.5. Доработка заключается в том, что параметры из MIB можно выбирать не по 1, а группой. Есть улучшенная поддержка ошибок, расширен список кодов ошибок;

Пример. Для CISCO путь будет 1.3.6.1.4.1.9, а для D-Link 1.3.6.1.4.1.171

Для загрузки MIB CISCO нужно использовать
CISCO IOS MIB Locator.

Подробнее о SNMP можно прочитать в 4 части курса CCNA.

Тестовая среда

Настраиваться будет маршрутизатор CISCO c3725, запущенный из под GNS3 и данные будут поступать в виртуальную машину (VM) Hyper-V. Агент SNMP уже является частью внутренней прошивки (IOS) маршрутизатора, а вот в качестве диспетчера будет использоваться бесплатное ПО - PowerSNMP Free Manager. CISCO рекомендует Free SNMP MIB Browser, не пробовал, не знаю. Соединяются маршрутизатор и VM посредством Облака GNS3. Для этого указываем в свойствах Облака внутренний виртуальный коммутатор, к которому подсоединена сетевая карта VM:

IP F0/0 маршрутизатора - 192.168.137.2/24
IP компьютера - 192.168.137.40/24
IP vEthernet (HUB1) - 192.168.137.1/24

На этом этапе считается, что все предварительные настройки уже выполнены.

SNMPv1/SNMPv2c

Версии настраиваются одинаково, так как версия не указывается при создании SNMP агента (строки сообщества), а лишь при создании ловушек. При создании строки сообщества задаётся лишь или право на чтение (RO), или право на запись (RW).

Пример. В маршрутизаторе настроен пока только интерфейс F0/0, ведущий к облаку (и VM). Введём команду создания агента (строки сообщества):

Создалось 2 группы на чтение - TEST v1 и TEST v2c. Удалим сообщество и группы:

Теперь создадим сообщество с правом на запись:

Снова введём команду:

Опять создалось 2 группы - v1 и 2c, только уже с правом и на чтение, и на запись:

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

Настройка маршрутизатора

Полная настройка версий 1 и 2:

В параметр snmp входят следующие ловушки:

Просмотреть полный перечень возможных ловушек можно командой:

Их там огромное количество:

Настройка VM

Нажатие кнопки Find покажет отсутствие доступных агентов в сети и срабатывание ловушки authentication:

Происходит так потому, что по умолчанию в программе стоит сообщество public, наш агент был опрошен, но отказал в доступе. Меняем public на TEST, агент опять не добавляется - широковещательный запрос. В свойствах ставим IP 192.168.137.2 и сообщество TEST, после чего агент успешно добавляется.

Ещё раз, строка сообщества (community) - это просто пароль, только называется по-другому.

Теперь погасим интерфейс F0/0 и снова включим:

OID отвечающий за состояние F0/0: 1.3.6.1.4.1.9.2.2.1.1.20.1 - первый полезный параметр. Следует обратить на то, что параметр находится в проприетарной ветке оборудования CISCO.

Теперь пробуем добавить этот параметр для мониторинга:

SNMPv3

Подробно настройка описана в курсе CCNA R&S 6.0 BRIDGING COURSE. Тут будет посложнее, но и поинтереснее - мозги гарантированно заскрипят 🙂

Настройка маршрутизатора

Удаляем всё что относится к предыдущей настройке кроме списка доступа. Далее, разбил настройку на 2 части, потом будет понятно почему.

Общие шаги

Шаг 1. Настройте ACL-список (уже сделано);
Шаг 2. Настройте представление SNMP;
Шаг 3. Настройте группу SNMP;
Шаг 4. Настройте пользователя как члена группы SNMP.

Часть 1

Агент SNMPv3 настраивается по-другому нежели SNMPv1/SNMPv2:

Вместо строки сообщества создаётся пользователь с паролем (cisco123) и шифрованием (aes 128, ключ шифрования snmp321) - следует запомнить, что первым указывается пароль пользователя (auth sha cisco123) и вторым ключ шифрования (aes 128 snmp321). Это важно.

Предварительно для пользователя создаётся группа, а ещё ранее вид. Вид определяет с какой частью дерева MIB предстоит работать.

Ещё раз по командам:

Команда 1 - создание вида (SNMP-RO) для работы с веткой MIB (system).
Команда 2 - создание вида (SNMP-RO) для работы с веткой MIB (mib-2), mib-2 входит в system - эта команда только для примера, что можно добавлять несколько веток.
Команда 3 - создание группы (TEST) версии 3 (v3) с аутентификацией и шифрованием (priv) только для чтения (read) для вида (SNMP-RO) и списком доступа (SNMP_ACL).
Команда 4 - создание пользователя (ADMIN) в группе (TEST) версии 3 (v3) аутентификацией по алгоритму (sha), паролем (cisco123) и шифрованием (priv) по алгоритму (aes 128) и ключом шифрования (snmp321).
Команда 5 - включаем ловушки и определение типов ловушек (snmp).

Тут надо вспомнить 3 уровня безопасности SNMPv3:

auth - group using the authNoPriv Security Level (MD5/SHA-1 аутентификация, без шифрования данных);
noauth - group using the noAuthNoPriv Security Level (без аутентификации и шифрования);
priv - group using SNMPv3 authPriv security level (MD5/SHA-1 аутентификация, шифрование данных DES/3DES/AES)

Для использования authPriv требуется прошивка с поддержкой криптографии (k9).

Теперь проверим что получилось:

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

Часть 2

Подробная настройка получателя ловушек SNMPv3:

Команда 6 - указываем хост куда отсылать данные при срабатывании ловушки (192.168.137.40) версии 3, без шифрования и аутентификации (noauth) для пользователя (ADMIN).

Проверяем, пользователь как был так и остался, а вот в группах SNMP и в конфигурации интересные изменения:

Появилась новая группа TEST, хотя команды на её создание не было.

И вот такая занятная строка в конфиге:

Понять что это такое можно выполнив команду:

Здесь чётко видно, что работа агента с запросами и работа агента с ловушками - 2 абсолютно разных процесса.

Настройка VM

Как видно из рисунка у пользователя ADMIN для ловушек нет шифрования и пароля.

Дальше добавляем агента с указанием версии и атрибутов:

И пробуем добавить параметр 1.3.6.1.4.1.9.2.2.1.1.20.2 - состояние интерфейса S0/0 для мониторинга.

И то же самое для F0/0 - 1.3.6.1.4.1.9.2.2.1.1.20.1. В чем дело? А дело в том, что параметр находится в ветке private, а эту ветку мы не добавляли в вид для работы, добавим:

Состояние интерфейса отображается корректно. С агентом версии 3 всё.

Настройка ловушек v3 с паролем и шифрованием

Удаляем получателя ловушек :

Проверяем пользователя, группы, виды, конфигурацию, если что-то удалилось - восстанавливаем (на самом деле удалиться ничего не должно, но когда настраивал, то первые раза 3 каждый раз получалось по-разному). Теперь:

И заново всё проверяем. Автоматически создались виды, пользователь на месте с теми же параметрами, нет новой группы TEST, так как параметры аутентификации и шифрования совпадают с созданной ранее, исходной группой TEST. В конфигурации параметр для автоматически созданных видов дописался к строке группы:

Если теперь погасить/поднять интерфейс, то ловушки не приходят диспетчеру.

Пробуем добавить пользователя для ловушек версии 3, в программе есть такая возможность. Для этого нужно ввести помимо прочего Engine ID. Его можно найти просмотрев пользователя SNMP либо выполнив команду:

Программа ожидает ввода Engine ID в виде 80-00-00-09-03-00-C2-01-25-D0-00-00, автоматического преобразования нет. Вносим реквизиты пользователя, снова гасим/поднимаем интерфейс S0/0, ловушки приходят:

Индексы интерфейсов

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

Хорошая практика держать индексы интерфейсов постоянными. Для этого нужно выполнить команду:

После выполнения команды индексы сохраняются в NVRAM и не зависят от перезагрузок устройства.

Установка Net-SNMP

А как же быть со средой Linux? Для Centos:

Далее, если выполнить:

Конфигурацию демона SNMP после установки нужно отредактировать. Если посмотреть файл /etc/ snmp / snmpd . conf, то в нём по умолчанию доступны ветви:

Соответственно запросы не подпадающие под эти ветви будут возвращаться с ошибкой как выше. Комментируем и оставляем:

SNMP (Simple Network Management Protocol) представляет собой коммуникационный протокол, который позволяет отслеживать управляемые сетевые устройства, включая маршрутизаторы, коммутаторы, серверы, принтеры и другие устройства, которые включены через IP через единую систему управления / программное обеспечение.

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

Что делает SNMP?

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

Менеджер (NMS)

Компонент Manager — это просто часть программного обеспечения, которое установлено на компьютере (которое при объединении называется Network Management System), которое проверяет устройства в вашей сети, как часто вы указываете информацию.

Агенты

SNMP Agent — это часть программного обеспечения, которое поставляется вместе с сетевым устройством (маршрутизатором, коммутатором, сервером, Wi-Fi и т. Д.), Которое при включении и настройке выполняет всю тяжелую работу для Менеджера путем компиляции и хранения всех данных из своего данное устройство в базу данных (MIB).

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

Менеджер программного обеспечения в предыдущем разделе регулярно проверяет агентов через порт UDP 161 .

Ловушки SNMP, о которых вы будете читать дальше, позволяют агенту отправлять информацию о системе и устройстве менеджеру через порт UDP 162 . Хотя UDP является общим протоколом, используемым SNMP, TCP также может использоваться.

Управляемые сетевые устройства

Управляемые сетевые устройства, в том числе маршрутизаторы, коммутаторы, Wi-Fi, серверы (Windows и другие), настольные ПК, ноутбуки, принтеры, UPS и т. Д., Имеют встроенное в них программное обеспечение агента, которое должно быть либо включено, либо настроено, либо просто настроено правильно для того, чтобы быть опрошены NMS.

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

Агенты, как объяснялось выше, поддерживают организованную базу данных параметров устройства, настроек и т.д. Система NMS (Network Management system) опроса / запроса агента данного устройства, которая затем делится своей организованной информацией из базы данных, сделанной с помощью NMS, которая затем переводит ее в предупреждения, отчеты, графики и т. Д. База данных, которую Агент разделяет между Агентом, называется Информационной базой управления или MIB .

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

Чтобы упростить MIB, подумайте об этом так: MIB-файлы — это набор Вопросов, которые Менеджер может спросить у агента. Агент просто собирает эти вопросы и сохраняет их локально и обслуживает их по NMS по запросу.

Упрощенный пример работы MIB: NMS спросит у сетевого устройства вопрос, в данном случае, что такое ответ на вопрос 2?

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

Скажем, мы хотим знать системное время работы устройства.

NMS отправит запрос агенту, запрашивающему Системное время, — запрос отправляется как номер с MIB и объектом интереса, а также что-то, называемое экземпляром .

Распределение номера OID

MIB	Объект интереса	Пример
1.3.6.1.2.1.1	3	0
MIB	Объект SysUptime	Образец

Первые 2 части числа, отправленные агенту (MIB и объект интереса, который в этом случае является системным временем), называются идентификатором объекта или OID . Как упоминалось выше, MIB являются стандартными значениями, которые система сетевого управления уже знает и может опросить / запросить сетевые устройства для получения информации.

OID, Object Identifier — это просто номер, составленный MIB, объектом интереса и экземпляром. Каждый идентификатор является уникальным для устройства, и при запросе будет предоставлена информация о том, что было запрошено OID.

Существует два типа OID:

Скаляр — это экземпляр одного объекта — например, имя поставщика устройства. Может быть только одно имя поставщика, так что это будет скалярный OID.

С другой стороны, Tabular может иметь несколько результатов для своего OID — например, процессор Quad Core приведет к 4 различным значениям ЦП.

Ловушки

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

Управляемые сетевые устройства будут иметь MIB Trap с заранее определенными условиями, встроенными в них. Крайне важно, чтобы система управления сетью объединяла эти MIB, чтобы получать любые ловушки, отправленные данным устройством.

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

Версии (v1, v2c, v3)

Этот протокол прошел несколько пересмотров на протяжении многих лет, начиная с 1988 года, начиная с версии 1. Теперь мы до версии 3, но большинство систем управления сетью поддерживают все версии протокола.

Версия 1

Версия 1 была первой версией протокола, определенного в RFC 1155 и 1157. Эта версия является самой простой из 3-х версий протокола и является самой небезопасной из-за ее простой текстовой аутентификации.

Версия 2 (или 2c)

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

Тем не менее, версии 1 и 2 / 2c имели встроенные риски безопасности, как упоминалось выше, — строки сообщества, которые эквивалентны паролям, где передается по проводу в виде прозрачного / обычного текста, позволяя любому, кто нюхает сеть, получить доступ к строке и могут компрометировать сетевые устройства и, возможно, перенастроить их с помощью SNMP.

Версия 3

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

Simple Network Management Protocol (SNMP) — это протокол прикладного уровня, он делает возможным обмен данными между сетевыми устройствами.

SNMP — это не продукт, а свод правил. Он определен Советом по архитектуре Интернета и является частью пакета TCP/IP. SNMP управляется и поддерживается Инженерной группой Интернета (IETF).

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

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

Архитектура SNMP

Схема SNMP. Источник: IMB

Компоненты, составляющие архитектуру SNMP:

сетевая станция управления, включающая в себя сетевого менеджера;
агенты;
мастер-агенты;
управляемые компоненты.

Сетевая станция управления — NMS

Network Management Station (NMS) удаленно мониторит управляемые устройства, получает данные, собранные мастер-агентами, отслеживает производительность и представляет полученную информацию в графическом виде. Встроенный менеджер NMS отвечает за связь с агентами.

Агенты

Мастер-агент

Это программа, связывающая сетевых менеджеров и субагентов. Мастер-агент анализирует запросы сетевого менеджера NMS и пересылает их субагентам, собирает и формирует ответы субагентов и отправляет их менеджеру. Мастер-агент уведомляет менеджера, если запрос некорректен или запрошенная информация недоступна.

Субагент

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

Управляемый компонент

Это подключенное к сети устройство или программное обеспечение с встроенным субагентом. К таким устройствам относятся не только маршрутизаторы, коммутаторы и серверы, но и IP-видеокамеры, МФУ и IP-телефоны. К софту с субагентами также относятся антивирусные программы, системы резервного копирования, ПО для систем ИБП.

База управляющей информации — MIB

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

Идентификатор объекта — OID

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

Используя первые 6 цифр этого OID, можно пройти по дереву на схеме.

Схематичное представление дерева OID. Источник: IBM

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

Древовидная иерархия MIB и OID в SNMP выглядит несколько запутанной, но у нее есть свои преимущества. Это простая и гибкая система организации сетевых устройств, она работает вне зависимости от размера сети.

Теория и логика работы протокола SNMP

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

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

Менеджеры и агенты обмениваются данными через протокол UDP. Вместо него также может использоваться TCP, IPX или протокол MAC-уровня. Обмен данными основан на Protocol Data Unit (PDU).

Всего в SNMP семь PDU:

TRAP, GETBULK — есть только во второй и третьей версиях протокола SNMP.

Схема PDU

IP заголовок	TCP/IP	TCP/IP
UDP заголовок	TCP/IP	TCP/IP
Версия SNMP	v1/v2/v3	PDU
Строка сообщества	Public, Private	PDU
Тип PDU	Get, GetNext, Response, Set, Trap, GetBulk, Inform	PDU
ID запроса	Идентификатор запроса	PDU
Статус ошибки	0, 1, 2, 3, 4, 5	PDU
Индекс ошибки	0, 1	PDU
Связанные переменные	Одна или несколько переменных в запросе	PDU

Применение

Статусы ошибок и их описание.

Сетевые порты SNMP

По умолчанию SNMP использует UDP-порты 161 и 162. Менеджер отправляет запросы на порт 161 агента. С порта 161 агент отправляет ответ менеджеру. При отправке запроса менеджер добавляет к нему ID, а агент вставляет этот ID в ответ, чтобы менеджер мог связать свой запрос с ответом агента.

Ловушки

Ловушка (Trap) — это важнейший способ коммуникации в SNMP. Менеджер отвечает за большое количество устройств, на многих из них может быть несколько управляемых компонентов. Агент отправляет ловушку по своей инициативе, когда необходимо сообщить менеджеру о событии. Например, ловушка может выслать отчет о перегреве машины или о том, что в тонере закончились чернила.

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

Версии протокола SNMP

SNMPv1

Первая версия протокола создана в 80-х годах XX века. Легка в настройке — требуется только строка community. Версия широко используется до сих пор.

SNMPv2с

Вторая версия протокола SNMP появилась в 1993 году. Разработчики добавили в нее новый запрос GetBulk и ловушку Inform, а также усовершенствовали безопасность.

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

SNMPv3

Третья версия вышла в 1998 году. Разработчики добавили в SNMP криптографическую защиту, облегчили удаленную настройку и администрирование объектов. Этого удалось достичь за счет определения набора стандартизованных объектов управления, называемых объектами MIB удаленного сетевого мониторинга, — RMON MIB.

Безопасность

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

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

Основная проблема с безопасностью в том, что почти все оборудование поддерживает версию SNMPv1. И только часть работает с версиями SNMPv2с и SNMPv3. Именно поэтому самой популярной стала SNMPv2с. Она способна работать с устройствами, которые поддерживают первую или вторую версии SNMP.

Модели безопасности протоколов SNMP по версиям

SNMPv1	Community–based security
SNMPv2c	Community–based security
SNMPv2u	User–based security
SNMPv2	Party–based security
SNMPv3	User–based security

Community-based Security — модель безопасности на основе строки сообщества. Фактически это идентификатор пользователя или пароль, который отправляется вместе с запросом. Если строка сообщества неверна, агент игнорирует запрос.

Строки сообщества бывают трех видов:

только для чтения — позволяет получать данные с устройства;
чтение/запись — позволяет получать данные и изменять конфигурацию устройства;
строка сообщества SNMP Trap — позволяет получать ловушки.

Строка сообщества широко используется из-за своей простоты и наличия внешних систем безопасности.

User-based Security Model — модель безопасности на основе пользователей. Уровни аутентификации, безопасности и конфиденциальности протоколов и ключей настраиваются у агента и менеджера.

Лучше всего безопасность проработана в третьей версии SNMP за счет USM и VACM. Упрощенно VACM (View-based Access Control Model) можно описать как модель с разными уровнями доступа для групп менеджеров. При получении запроса агент решает, разрешен ли определенной группе менеджеров доступ к чтению, записи и получению уведомлений.

Типичные проблемы безопасности

Периметр сети может быть небезопасен, если запросы SNMP разрешены межсетевыми экранами и пакетными фильтрами.
При активации функций SNMP на некоторых устройствах имя строки сообщества по умолчанию PUBLIC. Хакер начнет поиск именно с этого.
Прекращение отправки ловушек. Изменив запись в команде snmpEnableAuthenTraps, злоумышленник может прекратить отправку ловушек. В случае неудачной аутентификации он может не беспокоиться о том, что его безуспешные попытки взлома привлекут внимание администратора сети.
Удаленный пакетный перехват при помощи снифферов — программ анализа сетевого трафика.
Слабый контроль доступа к строке сообщества чтение-запись. Она дает всем пользователям возможность изменять конфигурацию устройств сети SNMP. Администратор должен внимательно следить за этим, иначе бесконтрольное изменение конфигураций поможет злоумышленнику нанести вред системе.

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

Практическое применение протокола

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

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

Благодаря протоколу администратор может:

При помощи стороннего ПО можно также:

управлять облачными сервисами;
сканировать по диапазону IP-адресов;
добавлять данные через кастомные OID.

SNMP и переход с IPv4 на IPv6

Протокол по умолчанию должен работать с IPv4 или IPv6. На практике IPv6 создает определенные проблемы для работы SNMP. Эти проблемы связаны объектами MIB, содержащими сетевые адреса. OID в MIB хранят информацию для нескольких уровней TCP/IP, и различия между IPv4 и IPv6 будут отражены в OID.

Отсутствие поддержки IPv6 в существующих объектах MIB проявляется двумя способами:

объекты MIB поддерживают только IPv4, но не IPv6;
содержащиеся в OID IPv4-адреса не обязательно представляют собой IP-адрес.

Эти проблемы решаются также двумя способами:

созданием новых баз MIB с поддержкой только IPv6 или независимых от версий протокола Protocol-version independent (PVI);
модификацией MIB для добавления новых или обновления существующих OID с поддержкой IPv6.

Инсталляция

Настройка SNMP в Windows

Она подробно описана в документации Microsoft.

Настройка данных агента SNMP

Пуск → Панель управления → Администрирование → Управление компьютером.

Настройка сообщества и ловушек SNMP

Пуск → Панель управления → Администрирование → Управление компьютером.

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

Пуск → Панель управления → Администрирование → Управление компьютером.

Настройка SNMP в Linux

Настройка SNMP в CentOS 7

Сначала нужно установить последние обновления при помощи yum/dnf:

затем установить SNMP:

и создать копию конфигурационного файла:

теперь нужно отредактировать настройки агента

и добавить строки:

Локацию и email лучше указать реальные.

Пора добавить сервис в автозагрузку и перезапустить его:

Как проверить, что сервис запущен:

Опрос агента с помощью утилиты snmpwalk:

Опрос сервера локально командой:

Настройка SNMP в Debian 10

Сначала нужно установить демона, клиента и файлы:

После установки переходим к настройке SNMP в Debian.

Файлом настройки SNMP-агента по умолчанию является /etc/snmp/snmpd.conf. Агент SNMP может быть запущен с настройками по умолчанию. Однако для включения удаленного мониторинга нужно сделать несколько изменений. Для этого создайте резервную копию файла:

Теперь нужно изменить директиву agentAdress. Ее текущие настройки разрешают доступ только с локального компьютера. Для включения удаленного мониторинга необходимо определить IP-адрес интерфейса:

Для настройки аутентификации:

rocommunity предоставляет доступ только на чтение, а rwcommunity дает доступ к чтению/записи. В Access Control section нужно поместить строку

rocommunity S3CUrE 192.168.43.100

Кроме того, можно включить запрос с локального хоста rocommunity S3CUrE localhost:

Затем нужно перезапустить SNMP:

Чтобы добавить сервис в автозагрузку, введите:

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

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

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