snmp pass thru что это

Snmp pass thru что это

SNMP alert destination(s)

Enter the IP address of the remote management PC that will receive SNMP trap alerts from the iLO 3. Up to three IP addresses can be designated to receive SNMP alerts.

Enable iLO 3 SNMP alerts

The iLO 3 alert conditions are detected by the iLO 3 and are independent of the host server operating system. These alerts can be Insight Manager SNMP traps. These alerts include major events, such as remote server power outages or server resets. They also include the iLO 3 events, such as security disabled or failed login attempt. The iLO 3 forwards the alerts to an HP SIMconsole using the destinations provided.

Forward Insight Manager Agent SNMP alerts

When set to Yes, these alerts are generated by the Insight Management agents, which are provided for each supported network operating system. The agents must be installed on the host server to receive these alerts. These alerts are sent to HP SIM clients on the network and are forwarded asynchronously by the iLO 3 to the IP addresses that have been configured to receive them.

Enable SNMP pass-thru

The Enable SNMP pass-through option enables the system to pass SNMP packets from the Insight Management Agent. When set to No, all SNMP traffic is stopped and will not pass-through the iLO 3.

Insight Manager Web Agent URL

The Insight Manager Web Agent URL option enables you to enter the IP address or the DNS name of the host server on which the Insight Manager Web Agents are running. Entering this data in the field provided enables iLO 3 to create a link from the iLO 3 Web pages to the pages of the Web Agent.

Level of data returned

The Level of Data Returned option regulates how much data is returned to an anonymous request for the iLO 3 information from HP SIM. All settings, except the None Data Level, provide sufficient data to allow integration with HP SIM. The Medium and High settings enable HP SIM and Systems Insight Manager to associate the management processor with the host server. The None Data Level prevents the iLO 3 from responding to the HP SIM requests.

Источник

Мониторинг состояния серверов HP Proliant в nagios/icinga. Плагины check_hpasm и check_ilo2_health.pl

Плагинов для систем мониторинга существует огромное количество. Можно посмотреть и найти нужное в каталогах exchange.nagios и monitoringexchange. При поисках нужного плагина проверять лучше в обоих репозиториях — несмотря на кажущуюся идентичность, их содержимое различается.

Другое дело, что качество и функционал плагинов, даже сходных между собой, сильно разнятся — есть быстро слепленные на коленке хаки, работающие в строго определенных условиях и решающих узкую задачу. После написания автор плагина не стал выбрасывать его в /dev/null, а решил поведать о нём миру. Другие плагины представляют собой добротно сделанные продукты, работающие с целыми семействами устройств и предоставляющих обширную информацию о целевых системах.

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

Данная статья посвящена мониторингу серверов HP Proliant, и автор искренне надеется, что она поможет в работе тем, кто имеет оборудование HP, и хотел бы более полно отслеживать его параметры.

Управление серверами HP Proliant в разных видах исполнения (iLO).

В настоящий момент существует iLO четырех версий. Просто iLO, иногда именуемое iLO1, ставившееся на сервера Proliant поколений G1-G4, iLO2 (G5-G6)и iLO3 ставившееся на G7. С поколения G8, которое теперь называется gen8, на сервера ставится iLO4. Если интересно, что делается внутри iLO4, то на хабре есть хорошая статья по этому поводу Проливая свет на HP ProLiant iLO Management Engine.

У всех iLO свой независимый сетевой интерфейс подключения. Он активен, даже если сервер находится в состоянии power down, главное, чтобы Proliant был физически включен в розетку. На iLO назначается свой адрес, сам интерфейс обычно включают в отдельный коммутатор управления с отдельным VLAN и своей подсетью.

На блейдовых вариантах серверов Proliant также установлены управляющие интерфейсы iLO; у каждого лезвия – свой собственный. Отдельный интерфейс управления (Onboard Administrator) есть и у блейдовой стойки c3000/c7000. Помимо информации о общем состоянии блоков питания, датчиков температуры в стойке, из интерфейса Onboard Administrator есть доступ к каждому iLO лезвия. На самих лезвиях ставились, минимум, iLO2 даже на поколениях G1. Последние поколения лезвий (gen8) также оснащены iLO4.

Версии Integrity iLO (Integrity iLO-iLO3) также ставятся на серверах Integrity и блейдах Superdome 2 — такие сервера встречаются не часто, так что рассматривать их не будем.

В некоторые системы, ныне уже устаревшие, но еще работающие (DL760 G2 — кто ж такого 8-процессорного коня выбросит?), которые изначально не были оснащены iLO можно установить карту RILOE II (полноразмерный PCI) с отдельным физическим LAN интерфейсом RJ45. RILOE II – (Remote Insight Lights-Out Edition II) достаточно забавная штука – у неё есть KVM-интерфейс (keyboard/vga/mouse) – для управления со стойки, RJ45 для подключения к сети и удаленного управления, а также… адаптер для внешнего питания.

Существует также усеченная версия iLO — LO100i, она ставилась на поколения G6 и G7 некоторых моделей начального уровня, например DL160,DL180,DL320, а также недорогих серий ML. В поколениях gen8 серверов даже начальной линейки, LO100i уже не будет (по крайней мере так было сказано на конференции HP). LO100i работает по одному из двух сетевых интерфейсов Proliant, причем может делать это как в выделенном (dedicated) так и в разделяемом (shared) режиме. В выделенном режиме один из сетевых интерфейсов сервера полностью занят под LO100i, в разделяемом – общая полоса делится между данными и управлением. Управление занимает небольшую полосу и практически не влияет на данные. У LO100i также есть свой отдельный сетевой адрес, который независим от основного адреса сервера. В некоторых моделях начального уровня (например ML110/ML150 G2), управляющий интерфейс отсутствует, но при необходимости, его можно организовать посредством установки специальной карты управления RMP (Remote Management Processor). Карта не слотовая – крепится на разъемы материнской платы (piggyback), и поставить ее на другие модели Proliant нельзя.

В реальной жизни с LO100i, при работе в разделяемом режиме, не всё хорошо складывается (в выделенном режиме всё хорошо). LO100i прекрасно работает, если два сетевых интерфейса Proliant у нас либо работают независимо, либо сконфигурированы в Network Fault Tolerance (NFT) или Transmit Load Balancing (TLB) with hot spare. При попытке объединения линков в LACP (а это самый эффективный режим использования нескольких сетевых интерфейсов), LO100i становится недоступен, хотя сами данные по интерфейсам ходят на ура. Причем, недоступен ни с внешней сети – с рабочей станции находящейся в том же VLAN на том же коммутаторе, ни с системной консоли. Поскольку документация утверждает обратное, по данному поводу заведен кейс в HP, причем еще в конце ноября прошлого года. На настоящий момент проблема потихоньку доэскалировалась до L1 (разработчики), но каких-то определенных рекомендаций HP (или хотя бы информации о понимании причин) так и не выдал, хотя если судить по трекеру инженеры что-то делают. Проблема, конечно, есть, но на задачу мониторинга она влияет лишь косвенно, хотя и не даёт возможности оперативно управлять сервером.

На сайте exchange.nagios.org есть достаточно большое количество плагинов, которые работают непосредственно с ilo делая запросы через http посредством XML. Но они хорошо работают только с iLO2 и более новыми версиями. iLO1 через XML очень неразговорчив и сообщает мало полезной информации, а ведь сервера с iLO1 до сих пор живы и здоровы, и понимать, что происходит у них внутри — надо.

Плагин check_ilo2_health.pl

Для проверки iLO наиболее эффективным показался check_ilo2_health.pl. Качать здесь. На exchange.nagios.org лежит более старая версия, которая не понимает iLO4.

Инсталляция скрипта не требует большого труда. Скрипт копируется в каталог, где лежат прочие скрипты nagios/icinga, затем в конфигураторе прописывается команда проверки и назначается на хосты.

Для работы скрипта потребуется инсталляция пакетов Perl (ставятся через CPAN): Nagios::Plugin (обязательно прочитайте UPDATE в конце!), IO::Socket::SSL и XML::Simple.

Опции:
-e — плагин игнорирует сообщения “syntax error” в выводе XML. Может быть полезно для старых фирмварей.
-n — без индикаторов температуры
-d — температурные данные совместимы с PerfParse
-v — выводить полностью XML сообщение (для отладки)
-3 — поддержка iLO3 и iLO4
-a — проверка отказоустойчивости вентиляторов (если поддерживается оборудованием)
-b — проверка отсеков HDD (если поддерживается оборудованием)
-o — проверка отказоустойчивости блоков питания (если поддерживается оборудованием)

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

HP Server Insight Manager

Было бы ошибкой думать, что компания HP ничего не может предложить администратору. HP Server Insight Manager (HP SIM) – решение, ориентированное на управление и мониторинг платформы Proliant и что важно – для продуктов HP его использование бесплатно (качаем здесь). Поддержка – за деньги. Дополнения для мониторинга некоторых сторонних систем тоже платные. Для его полноценной работы на управляемых серверах необходима установка драйверов.

Возникает хороший вопрос: Можно ли добавить информационность HP SIM к возможностям icinga/nagios для сбора информации в одном приложении мониторинга? И ведь что удивительно: нашелся человек, который сумел решить эту задачу.

Плагин check_hpasm

Плагин check_hpasm создан в компании ConSol labs. Его автор Герхард Лауссер (Gerhard Lausser). Плагин предназначен для сбора информации со следующих систем Proliant:

• Linux, где установлен HP System Health Application and Insight Management Agent (HPASM)
• Windows 2003/2008/2008 R2/2012 – с установленными драйверами HP SIM.
• Блейдовые стойки HP (c7000/c3000) с Onboard Administrator.

Во всех трех случаях должен быть поднят и настроен SNMP.

На чём это проверялось. Система мониторинга Icinga 1.8.4 (полностью совместима с Nagios) установлена на FreeBSD 9.0, так что если у вас другая система мониторинга или ОС делайте поправку на зависимости и пути. В системе установлен Perl, со всеми необходимыми дополнениями.

Инсталляция check_hpasm.

Качаем свежую версию. Идём на страницу плагина и ищем check_hpasm, ссылку на него. Она находится внизу страницы. На момент написания статьи была доступна версия 4.6.3.

Ключи для configure:
(место, где лежат скрипты вида check_*. у меня оно притулилось по старинке на нагиосовское место, хотя есть и /usr/local/libexec/icinga)
(имя пользователя под которым запускается система мониторинга, для nagios будет nagios)
(имя группы, в которую входит пользователь, из под которого запускается система мониторинга, для icinga=icinga для nagios=nagios)
(выводить или нет информацию для сбора статистики – ДА, по умолчанию = нет)
(выводить или нет расширенную информацию – ДА, по умолчанию = нет)

Итоговая строка для конфигурации будет иметь вид:

смотрим на вывод configure, убеждаемся, что нас всё устраивает.

Потом делаем make install

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

После чего скрипт выдаст подробную информацию о состоянии удалённой системы. Например, запрос для блейдовой стойки c7000 в nagios/icinga будет выглядеть так:

Если обнаружится неисправный компонент, то плагин вернёт WARNING и укажет причину. Например,
так выглядит сообщение о проблемной батарее в акселераторе:

Кстати, через имеющийся на сервере ILO1 эту информацию другими плагинами собрать нельзя. Чем чревата мёртвая батарея акселератора дискового контроллера? Скорость на запись падает почти в два раза.

Получить еще более детальную информацию можно, добавив в командную строку ключ –vv, а если надо совсем длинную простынь для диагностики то используем –vvv

Прописываем в командах проверки nagios:

Вместо public должно стоять ваше SNMP комьюнити. Назначаем команду проверки хостам и сервисам.

Плагин опирается в своей работе на возвращаемые драйверами данные. Иногда (обычно это ошибки в фирмвари) они могут возвращать некорректные значения – наличие физически отсутствующих компонентов, неверные параметры температуры (99 градусов, как это было с iLO4 у gen8) и т.д. Для этого существует обширный набор ключей, которыми можно исключить некоторые датчики или подсистемы целиком. Описание ключей большое и полностью приведено на странице плагина в разделе Blacklisting.

Для работы под Windows 2003/2008/2012 на Proliant надо установить:

1. SNMP службу (по умолчанию не установлена, лежит в системных компонентах)и правильно её сконфигурировать (указать коммьюнити/ прописать адрес nagios/icinga-сервера в качестве SNMP-сервера / прописать адрес для отправки SNMP-трапов). WBEM провайдеры/SIM драйверы зависят от SNMP службы. WBEM — Web-based Enterprise Management.
2. Последние версию драйверов iLO, HP System Insight Manager и WBEM провайдеров под нужную версию системы.

Для Linux HPASM ставится аналогично – также требуется настройка SNMP и драйверов. Подробно описано в HOWTO

Инсталляция драйверов с SPP в разы удобнее, уже потому что можно делать массовую установку на несколько серверов сразу. Этим занимается HP SUM — Smart Update Manager. Для этого потребуются реквизиты администратора домена или локального администратора сервера. Кроме того перед установкой драйверов категорически рекомендуется проапгрейдить все доступные фирмвари.

Замеченные проблемы:
1. На десяток-другой серверов может ставиться оооооочень долго, почему – не ясно.
2. HP SUM не рекомендуется запускать на машине с продуктивным ПО, потому что он имеет свойство грузить процессор до 90%
3. Некоторые сервера не поддаются автоматической установке, особенно если система голая — WBEM/SIM драйвера ранее не стояли. Придётся ставить руками.
4. Иногда на целевых серверах HP SUM не даёт выбирать WBEM/SIM драйверы – их тоже придётся ставить руками, особенно это касается серверов с LO100i. Замечено на DL180G6 и DL160G6.
5. Драйвера WBEM/SIM не ставятся, если стоит Windows 2008 R2 на официально неподдерживаемой архитектуре (типа устаревших DL360G4 или DL380G4). В блоге http://kf.livejournal.com есть следующее решение:.

Замеченные ошибки и недостатки check_hpasm

На момент версии 4.6.3 замечена следующая ошибка: При запуске на FreeBSD плагин выводит сообщение:

На работу собственно плагина и выдаваемую им информацию влияния не замечено. В новых версиях исправлена.
Было высказано предположение об отсутствии утилиты lc, но инсталляция утилиты ничего не дала. Ошибка осталась. Автору плагина сообщено.

К недостаткам следует отнести вывод в юниксовом формате (от начала эпохи) даты строк из IML, что делает их плохо воспринимаемыми:

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

О замеченных ошибках можно отписать автору плагина (plain english). Г.Лауссер человек занятой, но на сообщениях о проблемах или неправильном поведении check_hpasm всегда старается ответить.

Польза от плагина

C помощью данного плагина были оперативно обнаружены
• Неисправные батареи на акселераторах дисковых контроллеров в DL360G4, что приводило к падению скорости на запись на присоединенные массивы MSA20.
• Обнаружен заклинивший вентилятор в одном из Proliant. Вентилятор заменен.
• Обнаружен умерший резервный блок питания на одном из серверов. БП заменен.

Конечно, если каждый день дозором обходить все iLO-интерфейсы и внимательно просматривать логи IML, то подобные ошибки можно заметить, но возникает вопрос – а когда работать? Данный плагин в сочетании с nagios/icinga позволяет упростить процесс администрирования и полностью охватить инфраструктуру серверов HP Proliant.

Некоторые полезные руководства

P.S. Будут ли интересны статьи по другим аспектам мониторинга — конфигураторам, практическим наработкам, интересным плагинам, аддонам, нетривиальным железякам? Материалу накопилось много — хоть книжку пиши.

UPDATE 2015:

В 2015 году пришлось вернуться к задачам, связанным с мониторингом серверов HP и обнаружилось, что статья немного устарела.
в частности выяснилось, что при работе с iLO2 появляется ошибка:

ILO2_HEALTH UNKNOWN — ERROR: Failed to establish SSL connection with :443.

iLO3 и iLO4 отрабатывают нормально.

Изучение вопроса показало, что источником является широкоизвестная проблема с SSL. Наше окружение надо обновить.

1. Апгрейдим наш скрипт до версии минимум 1.60
(скрипт лежит на nagios.exchange. вот здесь )
2.Апгрейдим фирмвари у iLO2 до последней версии. (1.94 или 1.96, доступны с июля 2015)

Команду проверки надо изменить:

добавился ключик sslopts, с помощью которого включается TLSv1 и отключается проверка по SSL.

UPDATE 2016:

Касательно всех скриптов на перле использующих Nagios::Plugin (check_ilo2_health.pl,check_ilo2_health.pl):
Исключительно из-за копирайтов и торговых марок (а Nagios — зарегистрированная торговая марка) cpan более не индексирует Nagios::Plugin, соответственно нормально установить и использовать его больше нельзя.

Вместо этого используется Monitoring::Plugin, выполняющий идентичные функции, по тексту скриптов надо заменить Nagios на Monitoring

установить Monitoring::Plugin можно при помощи:

UPDATE 2020:

В iLO5 теперь есть свой собственный агент SNMP. Его надо правильно настроить и он будет давать возможность плагину check_hpasm собирать информацию.

Для серверов поколения Gen 10 и выше драйвера для OS устанавливать не требуется.

Источник

Протокол управления SNMP

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

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

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

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

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

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

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

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

Агенты

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

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

Субагент

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

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

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

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

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

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

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

Например, OID 1.3.6.1.4.868.2.4.1.1.1.3.3562.3. означает iso.org.dod.internet.private.transition.products.chassis.card.slotCps.
cpsSlotSummary.cpsModuleTable.cpsModuleEntry.cpsModuleModel.3562.3.

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

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

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

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

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

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

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

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

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

Схема PDU

Применение

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

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

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

Ловушки агент высылает на порт 162 менеджера. Если используется DLTS или TLS, то агент высылает сообщения на порт 10162, а менеджер — на порт 10161. Администратор может изменить порты SNMP, используемые по умолчанию, на любые другие.

Ловушки

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

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

В SNMP есть два типа ловушек: Trap и Inform. Отличия между ними в том, что после получения Inform менеджер подтверждает получение ловушки. В противном случае агент будет отправлять Inform, пока не получит подтверждения. А вот после получения Trap менеджер не отправляет подтверждение. Если сообщение не дошло до менеджера, агент об этом не узнает.

Версии протокола 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 по версиям

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

Строка сообщества зависит от вендора устройства. Часто вендоры по умолчанию выбирают «PUBLIC» в качестве пароля, поэтому первым делом на новых устройствах нужно изменить строку сообщества для защиты сети от злоумышленников.

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

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

Party-based Security Model — модель на основе так называемых «сторон». Для коммуникации между менеджером и агентов выбирается логическая сущность, называемая стороной. Она устанавливает протоколы аутентификации и шифрования, а отправитель и получатель соглашаются со способом шифрования и дешифровки данных. Сложность использования модели помешала ее распространению среди пользователей.

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

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

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

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

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

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

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

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

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

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

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

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

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

Инсталляция

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

Источник