Мониторинг на мрежово оборудване по SNMPv3 в Zabbix

Тази статия е посветена на особеностите на мониторинга на мрежово оборудване с помощта на протокол SNMPv3. Ще говорим за SNMPv3, ще споделя опитите си в създаването на пълноценни шаблони в Zabbix и ще покажа какво може да се постигне при организирането на разпределено известяване в голяма мрежа. Протоколът SNMP е основен за мониторинг на мрежово оборудване, а Zabbix е отличен инструмент за мониторинг на голям брой обекти и обобщаване на значителни обеми данни.

Няколко думи за SNMPv3

Нека започнем с предназначението на протокола SNMPv3 и особеностите от неговото използване. Задачите на SNMP включват мониторинг на мрежови устройства и основно управление чрез изпращане на прости команди (например, включване и изключване на мрежови интерфейси или рестартиране на устройството).

Главната разлика между SNMPv3 и предишните версии е класическите функции за сигурност [1-3], а именно:

• автентикация (Authentication), която определя, че запитването е получено от доверен източник;
• шифроване (Encryption), за предотвратяване на разкриването на предаваните данни при тяхното прихващане от трети лица;
• интегритет (Integrity), т.е. гаранция, че пакетът не е бил фалшифициран по време на предаване.

SNMPv3 предвижда използването на модел за безопасност, при който стратегията за автентикация се задава за конкретен потребител и групата, към която той принадлежи (в предишните версии на SNMP запитването от сървъра към обекта на мониторинг единствено сравняваше „community“, текстова стринг с „паролата“, предавана в открит вид (plain text)).

SNMPv3 въвежда понятието нива на безопасност — допустими нива на безопасност, определящи настройките на оборудването и поведението на SNMP агента на обекта на мониторинг. Комбинацията от модела за безопасност и нивото на безопасност определя кой механизъм за безопасност се използва при обработката на пакета SNMP [4].

В таблицата са описани комбинации от модели и нива на безопасност на SNMPv3 (първите три колони реших да оставя в оригинал):

Съответно, ще използваме SNMPv3 в режим на автентикация с прилагане на шифроване.

Настройка на SNMPv3

Мониторингът на мрежово оборудване предполага идентична настройка на протокола SNMPv3 както на сървъра за мониторинг, така и на наблюдаваното устройство.

Нека започнем с конфигуриране на мрежово устройство Cisco, неговата минимално необходима конфигурация изглежда по следния начин (за конфигурирането използваме CLI, имената и паролите са опростени, за да избегнем объркване):

snmp-server group snmpv3group v3 priv read snmpv3name 
snmp-server user snmpv3user snmpv3group v3 auth md5 md5v3v3v3 priv des des56v3v3v3
snmp-server view snmpv3name iso included

Първият ред snmp-server group определя групата SNMPv3 потребители (snmpv3group), режима на четене (read) и правото на достъп на групата snmpv3group да преглежда определени клонове на MIB-деревото на обекта за мониторинг (snmpv3name задава, до кои клоновe на MIB-деревото групата snmpv3group ще може да получава достъп).

Вторият ред snmp-server user определя потребителя snmpv3user, неговото членство в групата snmpv3group, както и прилагането на аутентикация md5 (паролата за md5 е md5v3v3v3) и шифроване des (паролата за des е des56v3v3v3). Разбира се, вместо des е по-добре да използвате aes, тук го представям просто за пример. Също така, при определянето на потребителя можете да добавите списък с достъп (ACL), който регулира IP адресите на мониторинговите сървъри, които имат право да извършват мониторинг на това устройство – това също е добра практика, но няма да усложнявам нашия пример.

Третият ред snmp-server view определя кодовото име, което задава клоновете на MIB-деревото snmpv3name, за да могат да бъдат запитани от групата потребители snmpv3group. ISO, вместо строго определяне на определен клон, позволява на групата потребители snmpv3group да получава достъп до всички обекти в MIB-деревото на обекта за мониторинг.

Подобна настройка на оборудването Huawei (също в CLI) изглежда по следния начин:

snmp-agent mib-view included snmpv3name iso
snmp-agent group v3 snmpv3group privacy read-view snmpv3name
snmp-agent usm-user v3 snmpv3user group snmpv3group
snmp-agent usm-user v3 snmpv3user authentication-mode md5 
            md5v3v3v3
snmp-agent usm-user v3 snmpv3user privacy-mode des56
            des56v3v3v3

След конфигурирането на мрежовите устройства, е необходимо да проверите наличието на достъп от мониторинговия сървър по протокол SNMPv3, ще използвам snmpwalk:

snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252

По-нагляден инструмент за запитване на конкретни OID обекти, с използване на MIB файлове – snmpget:

Сега да преминем към конфигурирането на типови данни за SNMPv3, в рамките на Zabbix шаблон. За простота и независимост от MIB, използвам цифрови OID:

Използвам потребителски макроси в ключовите полета, тъй като те ще бъдат еднакви за всички данни в шаблона. Могат да бъдат зададени в рамките на шаблона, ако параметрите SNMPv3 на всички мрежови устройства в мрежата ви са еднакви, или в рамките на мрежовия възел, ако параметрите SNMPv3 за различни обекти за наблюдение се различават:

Обърнете внимание, системата за наблюдение разполага само с името на потребителя и паролите за удостоверяване и криптиране. Групата потребители и областта на MIB обектите, за които е разрешен достъп, се задава на обекта за наблюдение.
Сега да преминем към попълването на шаблона.

Шаблон за запитване в Zabbix

Просто правило при създаването на всякакви шаблони за запитване – правете ги максимално подробни:

Уделям голямо внимание на инвентаризацията, за да улесня работата с голяма мрежа. За това ще говорим малко по-късно, а сега – тригери:

За удобство на визуализацията на тригерите, в техните имена са заложени системни макроси {HOST.CONN}, така че на таблото в секцията за аларми да се показват не само имената на устройствата, но и IP адресите, макар това да е повече въпрос на удобство, отколкото необходимост. За определяне на недостъпността на устройството, освен обикновен echo запитване, използвам проверка за недостъпност на възела по протокол SNMP, когато обектът е достъпен по ICMP, но не отговаря на SNMP запитванията – такава ситуация е възможна, например, при дублирани IP адреси на различни устройства, заради неправилно конфигурирани защитни стени или неверни настройки на SNMP на обектите за наблюдение. Ако използвам проверка за достъпност на възлите само по ICMP, в момента на разследване на инциденти в мрежата, данните за наблюдение може да не са налични, затова е нужно да се контролира тяхното получаване.

Нека преминем към откритие на мрежовите интерфейси – за мрежовото оборудване това е най-важната функция за наблюдение. Тъй като на мрежовото устройство могат да бъдат стотици интерфейси, е необходимо да се филтрират ненужните, за да не се затруднява визуализацията и да не се замърсява базата данни.

Използвам стандартната функция за откритие за SNMP, с много параметри за откритие, за по-гъвкаво филтриране:

discovery[{#IFDESCR},1.3.6.1.2.1.2.2.1.2,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7]

При такова откритие, може да филтрирате мрежовите интерфейси по типове, потребителски описания "description" и административни статуси на портовете. Филтрите и регулярните изрази за филтриране в моя случай изглеждат по следния начин:

При откритие ще бъдат изключени следните интерфейси:

• колко ръчно изключени (adminstatus1), благодарение на IFADMINSTATUS;
• нема текстово описание, благодарение на IFALIAS;
• има символ * в текстовото описание, благодарение на IFALIAS;
• които са оперативни или технически, благодарение на IFDESCR (в моя случай, в регулярните изрази IFALIAS и IFDESCR се проверяват с един регулярния израз alias).

Шаблонът за събиране на данни по протокола SNMPv3 е почти готов. Няма да се спираме подробно на прототипите на елементите на данните за мрежовите интерфейси, а ще преминем към резултатите.

Резултати от мониторинга

За начало - инвентаризация на малка мрежа:

Ако подготвите шаблони за всяка серия мрежови устройства - може да постигнете удобна за анализ компоновка на обобщени данни по актуален софтуер, серийни номера и уведомления за пристигането на домоуправителя в сървърното помещение (поради малкия Uptime). Извадка от моя списък с шаблони по-долу:

А сега - главната мониторингова панел, с разпределени по нива важности тригери:

Благодарение на комплексния подход към шаблоните за всяка модел устройства в мрежата, може да постигнете, че в рамките на една система за мониторинг ще бъде организиран инструмент за прогнозиране на неизправности и аварии (при наличие на съответни сензори и метрики). Zabbix е подходящ за мониторинг на мрежови, сървърни и сервисни инфраструктури, а задачата за обслужване на мрежовото оборудване наочевидно демонстрира нейните възможности.

Списък на използваните източници:1. Hucaby D. CCNP Routing and Switching SWITCH 300-115 Official Cert Guide. Cisco Press, 2014. стр. 325-329.
2. RFC 3410. tools.ietf.org/html/rfc3410
3. RFC 3415. tools.ietf.org/html/rfc3415
4. SNMP Configuration Guide, Cisco IOS XE Release 3SE. Глава: SNMP Version 3. www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/configuration/xe-3se/3850/snmp-xe-3se-3850-book/nm-snmp-snmpv3.html

Източник: habr.com