SNMP мониторинг сетевого оборудования: настройка и ловушки

Протокол SNMP (Simple Network Management Protocol) остаётся де-факто стандартом для мониторинга сетевого оборудования. Несмотря на появление gNMI, NETCONF и REST API, подавляющее большинство коммутаторов, маршрутизаторов, точек доступа и ИБП по-прежнему опрашиваются именно по SNMP. Протокол работает по модели «менеджер — агент»: станция управления (NMS) отправляет запросы GET/SET к агенту на устройстве, а агент может асинхронно генерировать уведомления (trap/inform).

Существуют три версии протокола. SNMPv1 — устаревшая, использует community string в открытом виде. SNMPv2c — наиболее распространённая в корпоративных сетях: добавляет GetBulk для массового опроса и улучшенную обработку ошибок, но аутентификация по-прежнему на основе community. SNMPv3 — единственная версия с реальной безопасностью: поддерживает аутентификацию (authNoPriv, authPriv) и шифрование (DES, AES-128/256).

Каждый управляемый параметр устройства представлен OID (Object Identifier) — числовой иерархией вида 1.3.6.1.2.1.2.2.1.10. Человекочитаемые имена (например, ifInOctets) определяются в MIB-файлах. Стандартные MIB описаны в RFC (IF-MIB, HOST-RESOURCES-MIB), а вендоры предоставляют приватные MIB для специфичных метрик — температура процессора, состояние вентиляторов, уровень PoE и т.д.

На сервере мониторинга (Ubuntu/Debian) установите пакет snmp для клиентских утилит и snmp-mibs-downloader для стандартных MIB-файлов:

apt update
apt install -y snmp snmp-mibs-downloader libsnmp-dev

# Загрузить стандартные MIB
download-mibs

# Раскомментировать строку для автозагрузки MIB
sed -i 's/^mibs :$/# mibs :/' /etc/snmp/snmp.conf

После этого утилиты snmpwalk, snmpget, snmpbulkwalk начнут показывать человекочитаемые имена вместо числовых OID. Вендорские MIB-файлы (Cisco, MikroTik, Huawei) скачиваются с сайта производителя и помещаются в /usr/share/snmp/mibs/ или ~/.snmp/mibs/.

Для продакшн-среды категорически рекомендуется SNMPv3 с аутентификацией и шифрованием (authPriv). Community string в SNMPv2c передаётся в открытом виде, что позволяет перехватить его при MITM-атаке и получить доступ к чтению (а иногда и записи) конфигурации устройства.

Пример настройки SNMPv3 на Cisco IOS:

! Создаём view — какие OID доступны
snmp-server view MONITORING iso included

! Создаём группу с authPriv
snmp-server group MONITOR-GRP v3 priv read MONITORING

! Создаём пользователя (SHA + AES128)
snmp-server user monitor-user MONITOR-GRP v3 auth sha MyAuthPass123 priv aes 128 MyPrivPass456

! Trap destination
snmp-server host 10.0.1.50 version 3 priv monitor-user

На MikroTik RouterOS:

/snmp set enabled=yes
/snmp community remove [find]
/snmp set trap-community="" trap-version=3

# Создаём SNMPv3 пользователя
/snmp community add name=v3user security=private \
  authentication-protocol=SHA1 authentication-password=MyAuthPass123 \
  encryption-protocol=AES encryption-password=MyPrivPass456 \
  addresses=10.0.1.50/32

SNMP trap — это асинхронное уведомление от устройства к NMS. Ключевое отличие от polling: trap приходит немедленно при событии (link down, высокая температура, ошибка питания), а polling обнаружит проблему только при следующем опросе. Trap-ы критически важны для быстрого реагирования.

На сервере мониторинга настройте демон snmptrapd:

# /etc/snmp/snmptrapd.conf

# Для SNMPv2c
authCommunity log,execute,net public

# Для SNMPv3
createUser -e 0x80001F88043139322E3136382E312E31 monitor-user SHA MyAuthPass123 AES MyPrivPass456
authUser log,execute monitor-user

# Логирование в файл
[snmptrapd] logoption f /var/log/snmptrapd.log

# Обработчик — вызов скрипта при получении trap
traphandle default /usr/local/bin/trap_handler.sh

Запуск демона:

systemctl enable snmptrapd
systemctl start snmptrapd

# Проверка — отправить тестовый trap
snmptrap -v2c -c public 127.0.0.1 '' .1.3.6.1.4.1.99999 \
  .1.3.6.1.4.1.99999.1 s "Test trap message"

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

Для 64-битных счётчиков трафика (ifHCInOctets/ifHCOutOctets) обязательно используйте SNMPv2c или v3 — SNMPv1 не поддерживает Counter64. На загруженных интерфейсах (1 Гбит/с и выше) 32-битные счётчики переполняются за несколько секунд, давая ложные данные.

Zabbix — наиболее популярная система мониторинга с встроенной поддержкой SNMP. Для массового мониторинга сетевого оборудования используется SNMP discovery (обнаружение интерфейсов) и шаблоны.

Порядок подключения устройства:

1. В Zabbix Frontend создайте хост, укажите SNMP interfaces (IP, порт 161)
2. На вкладке Macros задайте {$SNMP_COMMUNITY} или SNMPv3-параметры
3. Привяжите шаблон — например, Template Net Cisco IOS SNMPv2
4. Zabbix автоматически обнаружит интерфейсы через LLD (Low-Level Discovery)

Для SNMPv3 в макросах хоста задаются:

{$SNMPV3_USER}       = monitor-user
{$SNMPV3_AUTH_PASS}  = MyAuthPass123
{$SNMPV3_PRIV_PASS}  = MyPrivPass456
{$SNMPV3_AUTH_PROTO} = SHA
{$SNMPV3_PRIV_PROTO} = AES

При внедрении SNMP-мониторинга администраторы сталкиваются с рядом характерных проблем:

• Timeout: No Response — самая частая ошибка. Проверьте community/credentials, ACL на устройстве, firewall между NMS и агентом, и работает ли SNMP-сервис на устройстве
• Counter32 wrap-around — 32-битные счётчики переполняются на быстрых интерфейсах. Используйте ifHCInOctets (Counter64) вместо ifInOctets
• Index mismatch после перезагрузки — ifIndex может измениться после рестарта устройства. Используйте ifName или ifAlias для привязки вместо индекса
• Высокая нагрузка на CPU устройства — слишком частый polling (каждые 10 сек) для устройства со слабым CPU. Увеличьте интервал до 60-300 сек для некритичных метрик

SNMP — потенциально опасный протокол: через SNMP SET можно изменить конфигурацию устройства, а через GET — получить полную информацию о топологии сети. Рекомендации по защите:

1. Используйте SNMPv3 authPriv — минимум SHA + AES128. MD5 и DES считаются слабыми
2. Ограничьте ACL на устройствах — SNMP-запросы должны приниматься только с IP-адресов NMS
3. Отключите SNMP write — если не используете SET, оставьте только read-only доступ
4. Изолируйте management VLAN — SNMP-трафик не должен ходить через пользовательские сети
5. Мониторьте authenticationFailure trap — это индикатор попыток подбора community string

# Cisco IOS — ACL для SNMP
ip access-list standard SNMP_ACL
 permit 10.0.1.50
 permit 10.0.1.51
 deny any log

snmp-server community s3cretRO RO SNMP_ACL
snmp-server community s3cretRW RW SNMP_ACL

# Включить trap при неудачной аутентификации
snmp-server enable traps snmp authentication

В идеале весь SNMP-трафик должен проходить через выделенный management-интерфейс устройства, а не через data-plane интерфейсы. Это особенно критично для маршрутизаторов, доступных из интернета.