nocip.ssh@mail.ru
Главная  >  Cisco Routing

Простой протокол управления сетью - SNMP

Создана 29.04.2023
Отредактирована 23.01.2025

Что такое SNMP

В современной комплексной сети из маршрутизаторов, коммутаторов и серверов задача управления всеми устройствами и обеспечение того, чтобы они не просто функционировали, а работали оптимально, может показаться обескураживающей. Вот где может помочь SNMP (Simple Network Management Protocol) - простой протокол управления сетью. SNMP был введен в 1988 году с целью удовлетворить растущую потребность в стандарте для управления устройствами, поддерживающими интернет-протокол IP (Internet Protocol). SNMP предоставляет пользователям "простой" набор операций, позволяющий управлять этими устройствами удаленно.
Основа SNMP - простой набор операций (и информации, собираемой посредством этих операций), который предоставляет администраторам возможность изменять состояние какого-либо устройства, поддерживающего SNMP. Например, вы можете использовать SNMP, чтобы отключить интерфейс на маршрутизаторе или проверить скорость, с которой работает интерфейс Ethernet. SNMP позволяет даже отслеживать температуру коммутатора и предупреждать вас, когда она слишком высока.
Обычно SNMP ассоциируется с управлением маршрутизаторами, но важно понимать, что его можно использовать для управления устройствами различных типов. Хотя предшественник SNMP, простой протокол управления маршрутизаторами SGMP (Simple Gateway Management Protocol), разрабатывался для управления интернет-маршрутизаторами. Можно управлять любым устройством, на котором запущено программное обеспечение,  позволяющее получать информацию SNMP. Это справедливо не только для физических устройств, но и для программ, например веб-серверов и баз данных.
Другой аспект управления сетью - мониторинг сети, то есть мониторинг всей сети, а не отдельных маршрутизаторов, узлов и других устройств. Чтобы понять, как работает сама сеть, а также как отдельные ее устройства влияют на сеть в целом, был разработан модуль удаленного мониторинга (RMON - Remote Network Monitoring). Он может использоваться для мониторинга не только трафика в локальной сети (LAN - Local Area Network), но и интерфейсов WAN.

Версии SNMP

SNMP версии 1 (SNMPv1) - первоначальная версия протокола SNMP. Она определена в RFC 1157 и является историческим стандартом IETF. Безопасность SNMPv1 основана на строках community (поле «пароль»), которые представляют собой просто пароли. Они позволяют любому SNMP-приложению, которое их знает, получать доступ к информации об управлении устройством. Обычно в SNMPv1 используются три значения community: RO - read-only (только чтение), RW - read-write (чтение и запись) и trap (ловушка - уведомление). Следует отметить, что хотя SNMPv1 стал историческим стандартом, он все еще является основной реализацией SNMP, поддерживаемой многими производителями.
SNMP версии 2 (SNMPv2) часто называют SNMPv2 с поддержкой строк community. Технически эта версия SNMPv2 называется SNMPv2c, Она определена в RFC 3416, RFC 3417 и  RFC 3418.
SNMP версии 3 (SNMPv3) - последняя версия SNMP. Ее главный вклад в управлении сетями заключается в безопасности. В ней добавлена поддержка сильной аутентификации и закрытой связи между управляемыми объектами. В 2002 году она наконец перешла из разряда временного стандарта в разряд полного стандарта. Этот стандарт определяется следующими документами: RFC 3410, RFC 3411, RFC 3412, RFC 3413, RFC 3414, RFC 3415, RFC 3416, RFC 3417, RFC 3418 и RFC 2576.

За стандартные протоколы, регулирующие трафик Интернета, в том числе SNMP, отвечает Группа по стандартам для сети Интернет IETF (Internet Engineering Task Force).
IETF публикует документы RFC (Request for Comments), которые представляют собой спецификации для многих протоколов, существующих в мире IP.

Менеджеры и агенты SNMP

В мире SNMP существует два вида объектов: менеджеры и агенты. Менеджер - это сервер, на котором запущена какая-либо программная система, имеющая возможность выполнять задачи по управлению сетью. Менеджеры часто называют станциями управления сетью (NMS - Network Management Station). NMS отвечает за опрос  и получение ловушек от агентов в сети. Опрос в контексте управления сетью - это действие по запросу у агента (маршрутизатора, коммутатора, Linux-сервера и т.п.) какой-либо информации. В дальнейшем эта информация может быть использована, чтобы определить, не произошло ли какое-нибудь катастрофическое событие. Ловушка - это способ для агента сообщить NMS о каком-то событии. Далее NMS отвечает за действие в соответствии с информацией, полученной от агента.

Вот некоторые NMS: Zabbix, Nagios, Spiceworks Help Desk, Datadog, NetCrunch, Munin, PRTG Network Monitor, Icinga, Pandora FMS, LibreNMS, Observium, netdata, PHP Server Monitor, Cabot, OpenNMS, NIXStats и т.д.

Второй тип объекта, агент, - это программный элемент, запущенный на управляемом сетевом устройстве. Это может быть отдельная программа (демон в терминологии Linux) или элемент операционной системы (например, Cisco IOS или операционной системы низкого уровня, управляющей источником бесперебойного питания). Агент предоставляет NMS информацию для управления, отслеживая различные рабочие параметры устройства. На рис. 1 связь между NMS и агентом.
Рис. 1. Связь между NMS и агентом
Важно иметь в виду, что запросы и ловушки могут отправляться одновременно. Для времени, когда NMS может опросить агента или когда агент может отправить ловушку, ограничений нет.

Обратите внимание, чтобы настроить мониторинг агента, не обязательно на агенте настраивать ловушку (trap), достаточно на NMS указать IP-адрес агента, версию SNMP, порт 161 и имя Community.

Структура информации для управления и MIB

Структура информации для управления (SMI - Structure Management Information) предоставляет способ определения управляемых объектов и их поведения. У агента есть список отслеживаемых им объектов. Один из таких объектов - состояние работы интерфейса на сетевом оборудовании (например, работает, не работает или тестируется). Этот список собирает информацию, которой NMS может воспользоваться для определения общего состояния того устройства, на котором работает агент.
В стандарте «The Structure of Management Information Version 1» (Структура информации для управления) (SMIv1, RFC 1155) он определяет, как управляемым объектам присваиваются имена, и указывает связанные с ними типы данных. В стандарте «The Structure of Management Information Version 2» (SMIv2, RFC 2578) представлены дополнения для SNMPv2.
База управляющей информации (MIB - Management Information Base) может рассматриваться как база данных управляемых объектов, которые отслеживает агент. Все данные о состоянии или статистическая информация, к которой есть доступ к NMS, определены в MIB. SMI предоставляет способ определения управляемых объектов, тогда как MIB - это определение (в терминологии SMI) самих объектов. Как словарь, в котором показывается написание слов, а затем приводится его толкование, MIB определяет текстовое имя управляемого объекта и объясняет его значение.

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

В агенте может быть реализовано много MIB, но во всех агентах реализована конкретная MIB, которая называется MIB-II (RFC 1213). Этот стандарт определяет переменные для таких параметров, как статистика интерфейса (скорость интерфейса, MTU, количество отправных октетов, количество принятых октетов и т.д.), а также различных параметров, относящихся к самой системе (местоположение системы, контактные сведения и т.д.). Основная цель MIB-II - предоставить общую управляющую информацию TCP/IP. Она не охватывает все возможные объекты, которыми производителю может потребоваться управлять в конкретном устройстве.
Объекты могут содержать несколько атрибутов (Имя, Тип и синтаксис, Кодировка), рассмотрим Имя:
Имя
Имя, или идентификатор объекта (OID - Object Identifier), уникально определяет управляемый объект. В SNMP-приложениях делается очень много работы для того, чтобы помочь вам удобно ориентироваться в пространстве имен.
Рис. 2. Неполное субдерево MIB-II
Обратите внимание, как составляется OID для interfaces, на рис. 2 выделено цветом, в скобке есть цифра.
Таблица 1. Краткое описание групп MIB-II
Имя субдерева
OID
Описание
system
1.3.6.1.2.1.1
Определяет список объектов, относящихся к работе системы, таких как время работы системы, контактная информация и имя системы
interfaces
1.3.6.1.2.1.2
Отслеживает состояние каждого интерфейса на управляемой системе. Группа interfaces отслеживает, какие интерфейсы работают и не работают, и такие параметры, как количество отправленных и полученных октетов, ошибок и потерь пакетов и т.д.
at
1.3.6.1.2.1.3
Группа трансляции адресов (at) исключена и предоставляется только для обратной совместимости
ip
1.3.6.1.2.1.4
Отслеживает многие аспекты IP, в том числе IP-маршрутизацию
icmp
1.3.6.1.2.1.5
Отслеживает ошибки, потери пакетов ICMP  и т.д.
tcp
1.3.6.1.2.1.6
Помимо прочего отслеживает состояние TCP-соединения (например, closed (закрыто), listen (порт прослушивается), sysSent (отправлен пакет syn) и т.д.)
udp
1.3.6.1.2.1.7
Отслеживает статистику UDP, входящие и исходящие датаграммы и т.д.
egp
1.3.6.1.2.1.8
Отслеживает различную статистику протокола EGP (Exterior Gateway Protocol) и хранит таблицу соседей EGP
transmission
1.3.6.1.2.1.10
В настоящее время в этой группе не определено объектов, но другие MIB для конкретных каналов передачи определяются при помощи этого субдерева
snmp
1.3.6.1.2.1.11
Измеряет производительность базовой реализации SNMP на управляемой системе и отслеживает такие параметры, как количество отправленных и полученных SNMP-ПАКЕТОВ
Вот интересный сайт, где вы можете найти искомый OID спускаясь вниз по субдереву, например для OID 1.3.6.1.2.1.2.2.1.8 - Обнаружение сетевых интерфейсов, описание можно посмотреть здесь на этом же сайте.

SNMP и UDP

В качестве транспортного протокола для передачи данных SNMP применяют протокол UDP (User Datagram Protocol). UDP, определенному в RFC 768, было отдано предпочтение перед протоколом TCP (Transmission Control Protocol), так как UDP - протокол без установления соединения, то есть при передачи дейтаграмм (пакетов) туда и обратно между агентом и NMS не создаются соединения из конца в конец. Из-за этого аспекта UDP является ненадежным, потому что на уровне протокола нет подтверждения доставки датаграмм. SNMP-приложение само определяет, потеряны ли датаграммы, и при необходимости передает их повторно. Обычно это достигается путем простого ожидания в течение определенного интервала времени. NMS отправляет агенту UDP-запрос и ожидает ответа. Интервал времени, в течение которого NMS его ожидает, зависит от ее конфигурации. Если интервал времени ожидания превышен, а NMS не получила от агента ответа, она считает пакет потерянным и повторно передает запрос. Количество повторных передач пакетов также настраивается. 
Пока дело касается регулярных информационных запросов, ненадежная природа UDP фактически не является проблемой. В худшем случае станция управления отправляет запрос и никогда не получает ответа. Для ловушек (trap) ситуация несколько иная. Если агент отправляет ловушку, а та не достигает адресата, NMS никак не может узнать, что ловушка вообще была отправлена. Агент, в свою очередь, не знает, что ему нужно отправить ловушку повторно, потому что NMS не должна посылать агенту ответ, подтверждающий ее получение.
Достоинство ненадежной природы UDP заключается в том, что этот протокол требует небольшого количества служебной информации, поэтому влияние на производительность вашей сети снижается. Реализации SNMP через TCP существуют, но они больше подходят для особых случаев, когда кто-то разрабатывает агент для проприетарного оборудования. В сильно загруженной и управляемой сети реализация SNMP через TCP - плохая идея. Кроме того, стоит понять, что TCP - не волшебство и что SNMP был разработан для работы в сетях, где есть неполадки - если бы в вашей сети никогда не было сбоев, вам не потребовалось бы за ней наблюдать. При сбоях в сети протокол, который пытается отправить данные, но останавливается, если не может этого сделать, - практически всегда лучший выбор с точки зрения проектирования, чем протокол, который забивает сеть повторными передачами в попытке достичь надежности.
SNMP использует:
  • UDP-порт 161 для отправки и получения запросов;
  • UDP-порт 162 для получения ловушки от управляемых устройств.
Каждое устройство, в котором реализован SNMP, по умолчанию должно использовать эти номера портов, но некоторые производители позволяют изменять в конфигурации агента порт по умолчанию. Если вы измените эти значения, нужно уведомить об этом NMS, чтобы она могла опрашивать устройства через правильные порты.
На рис. 3 изображен стек протоколов TCP/IP, который является основой всей связи по TCP/IP. В настоящее время любое устройство, которое связывается через Интернет (например, Windows-системы, Linux-серверы, сетевое оборудование и т.д.), должно использовать этот стек протоколов. 

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

Когда NMS или агент хочет выполнить SNMP-функцию (например, запрос или ловушку), в стеке протоколов происходят следующие события:
Приложение (Уровень приложений)
В первую очередь само SNMP-приложение (NMS или агент) решает, что оно будет делать. Например, оно может отправить SNMP-запрос агенту, ответ на SNMP-запрос (он будет отправлен агентом) или ловушку NMS. Прикладной уровень обслуживает конечного пользователя, например оператора, запрашивающего информацию о состоянии порта Ethernet-коммутатора. 
UDP (транспортный уровень)
Следующий уровень, UDP, позволяет двум узлам связываться друг с другом. Помимо прочего UDP-заголовок содержит порт назначения устройства, которому отправляется запрос или ловушка. Порт назначения будет либо 161 (запрос), либо 162 (ловушка).
Рис. 3. Модель связи TCP/IP и протокол SNMP
IP (Сетевой уровень)
Уровень IP пытается доставить SNMP-пакет в пункт назначения по указанному IP-адресу.
Управление доступа к среде (MAC - Media Access Control) (Канальный уровень + физический)
Последнее, что должно случиться с SNMP-пакетом, чтобы он достиг своего пункта назначения, - передача в физическую сеть, где он может быть направлен конечному адресату. Уровень MAC состоит из аппаратных средств и их драйверов, которые размещают данные в физической среде передачи, таких как Ethernet-карта. Кроме того, уровень MAC отвечает за получение пакетов из физической сети и их отправку вверх по стеку протоколов, чтобы они могли быть обработаны прикладным уровнем (в данном случае SNMP).

Community и SNMP

В SNMPv1 и SNMPv2 для обеспечения доверия между менеджерами и агентами используется принцип сообществ (community). У агента настраиваются имена трех сообществ:
  • read-only (только чтение)
  • read-write (чтение и запись) *
  • trap (ловушка)
Имена сообществ, в сущности, являются паролями. Три строки community управляют различными видами действий. Как следует из названия, строка community только для чтения позволяет считывать значения данных, но не изменять их. Строка community чтение и запись позволяет считывать и изменять значения данных; со строкой этого сообщества можно считывать данные счетчиков, сбрасывать их значения и даже перезагружать интерфейсы или выполнять другие действия, изменяющие конфигурацию маршрутизатора. Наконец, строка community trap позволяет получать ловушку (несинхронные уведомления) от агентов. 
Большинство производителей поставляет свое оборудование со строками сообществ, заданными по умолчанию, обычно это public для строки community только для чтения и private для строки community чтения и записи. Прежде чем вводить устройство в эксплуатацию, важно изменить эти заданные по умолчанию значения.
Так как, в сущности, строки community являются паролями, при их выборе вы должны руководствоваться теми же правилами, которыми пользуетесь для паролей учетных записей пользователей в Linux или Windows: никаких слов из словаря, имен супругов и т.д. Обычно хорошо подходит строка из буквенно-цифровых символов с буквами верхнего и нижнего регистров, а также спецсимволов. Как было сказано выше, проблема с аутентификацией SNMP заключается в том, что строки community отправляются открытым текстом, что упрощает их перехват и использование против вас. В SNMPv3 эта проблема решается, помимо прочего, за счет возможности безопасной аутентификации и связи между SNMP-устройствами (шифрования).
Существуют способы снизить риск атаки. IP-брандмауэры или фильтры минимизируют вероятность того, что кто-то может нанести ущерб любому управляемому устройству в вашей сети, атакуя его через SNMP. Можно настроить брандмауэр на пропуск UDP-трафика только из списка известных узлов. Например, можно разрешить входящий UDP-трафик на порт 161 (SNMP-запросы) в вашу сеть, только если он идет с одной из ваших NMS. То же самое подходит и для ловушки, можно настроить маршрутизатор, чтобы он пропускал UDP-трафик на порт 162 вашей NMS, только если он исходит от одного из узлов, за которым идет наблюдение. Брандмауэры не дают 100% эффективности, но подобные предосторожности существенно снижают риск.

Установка NMS и настройка агентов SNMP