SNMP

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

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

Что делает SNMP?

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

Обзор и основные понятия

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

Управляемые протоколом SNMP сети состоят из трех ключевых компонентов:

• Управляемое устройство;
• Агент — программное обеспечение, запускаемое на управляемом устройстве, либо на устройстве, подключенном к интерфейсу управления управляемого устройства;
• Система сетевого управления (Network Management System, NMS) — программное обеспечение, взаимодействующее с менеджерами для поддержки комплексной структуры данных, отражающей состояние сети, например Zabbix.

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

Агентом называется программный модуль сетевого управления, располагающийся на управляемом устройстве, либо на устройстве, подключенном к интерфейсу управления управляемого устройства. Агент обладает локальным знанием управляющей информации и переводит эту информацию в специфичную для SNMP форму или из неё (медиация данных).

В состав Системы сетевого управления (NMS) входит приложение, отслеживающее и контролирующее управляемые устройства. NMS обеспечивают основную часть обработки данных, необходимых для сетевого управления. В любой управляемой сети может быть одна и более NMS.

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

Так как адреса объектов устройств определяются в цифровом формате, их сложно запомнить. Для упрощения применяются базы управляющей информации (MIB). Базы MIB описывают структуру управляемых данных на подсистеме устройства; они используют иерархическое пространство имён, содержащее идентификаторы объектов (OID-ы). Каждый OID состоит из двух частей: текстового имени и SNMP адреса в цифровом виде. Базы MIB являются необязательными и выполняют вспомогательную роль по переводу имени объекта из человеческого формата (словесного) в формат SNMP (цифровой). Очень похоже на DNS сервера. Так как структура объектов на устройствах разных производителей не совпадает, без базы MIB практически невозможно определить цифровые SNMP адреса нужных объектов. Базы MIB используют нотацию, заданную в ASN.1.

Детали протокола

SNMP работает на прикладном уровне TCP/IP (седьмой уровень модели OSI). Агент SNMP получает запросы по UDP-порту 161. Менеджер может посылать запросы с любого доступного порта источника на порт агента. Ответ агента будет отправлен назад на порт источника на менеджере. Менеджер получает уведомления (Traps и InformRequests) по порту 162. Агент может генерировать уведомления с любого доступного порта. При использовании TLS или DTLS запросы получаются по порту 10161, а ловушки отправляются на порт 10162.

В SNMPv1 указано пять основных протокольных единиц обмена (protocol data units — PDU). Еще две PDU, GetBulkRequest и InformRequest, были введены в SNMPv2 и перенесены в SNMPv3.

Все PDU протокола SNMP построены следующим образом:

Ниже перечислены семь протокольных единиц обмена SNMP:

GetRequest

Запрос от менеджера к объекту для получения значения переменной или списка переменных. Требуемые переменные указываются в поле variable bindings (раздел поля values при этом не используется). Получение значений указанной переменной должно быть выполнено агентом как Атомарная операция. Менеджеру будет возвращён Response (ответ) с текущими значениями.

SetRequest

Запрос от менеджера к объекту для изменения переменной или списка переменных. Связанные переменные указываются в теле запроса. Изменения всех указанных переменных должны быть выполнены агентом как атомарная операция. Менеджеру будет возвращён Response с (текущими) новыми значениями переменных.

GetNextRequest

Запрос от менеджера к объекту для обнаружения доступных переменных и их значений. Менеджеру будет возвращён Response со связанными переменными для переменной, которая является следующей в базе MIB в лексикографическом порядке. Обход всей базы MIB агента может быть произведён итерационным использованием GetNextRequest, начиная с OID 0. Строки таблицы могут быть прочтены, если указать в запросе OID-ы колонок в связанных переменных.

GetBulkRequest

Улучшенная версия GetNextRequest. Запрос от менеджера к объекту для многочисленных итераций GetNextRequest. Менеджеру будет возвращён Response с несколькими связанными переменными, обойдёнными начиная со связанной переменной (переменных) в запросе. Специфичные для PDU поля non-repeaters и max-repetitions используются для контроля за поведением ответа. GetBulkRequest был введён в SNMPv2.

Response

Возвращает связанные переменные и значения от агента менеджеру для GetRequest, SetRequest, GetNextRequest, GetBulkRequest и InformRequest. Уведомления об ошибках обеспечиваются полями статуса ошибки и индекса ошибки.

Эта единица используется как ответ и на Get-, и на Set-запросы, в SNMPv1 называется GetResponse .

Trap

Асинхронное уведомление от агента — менеджеру. Включает в себя текущее значение sysUpTime, OID, определяющий тип trap (ловушки), и необязательные связанные переменные. Адресация получателя для ловушек определяется с помощью переменных trap-конфигурации в базе MIB. Формат trap-сообщения был изменён в SNMPv2 и PDU переименовали в SNMPv2-Trap.

InformRequest

Асинхронное уведомление от менеджера менеджеру или от агента менеджеру. Уведомления от менеджера менеджеру были возможны уже в SNMPv1 (с помощью Trap), но SNMP обычно работает на протоколе UDP, в котором доставка сообщений не гарантирована, и не сообщается о потерянных пакетах. InformRequest исправляет это обратным отправлением подтверждения о получении. Получатель отвечает Response-ом, повторяющим всю информацию из InformRequest. Этот PDU был введён в SNMPv2.

Разработка и использование

Версия 1

SNMP, версия 1 (SNMPv1) — изначальная реализация протокола SNMP. SNMPv1 работает с такими протоколами, как UDP, IP, CLNS, DDP и IPX. SNMPv1 широко используется и де-факто является протоколом сетевого управления в Интернет-сообществе.

Первые RFC для SNMP, сейчас известные как SNMPv1, появились в 1988г:

• RFC 1065 — Структура и идентификация управляющей информации в сетях на основе стека протоколов TCP/IP
• RFC 1066 — База управляющей информации для сетевого управления в сетях на основе стека протоколов TCP/IP
• RFC 1067 — Простой протокол сетевого управления

Эти протоколы были пересмотрены в следующих RFC:

• RFC 1155 — Структура и идентификация управляющей информации в сетях на основе стека протоколов TCP/IP
• RFC 1156 — База управляющей информации для сетевого управления в сетях на основе стека протоколов TCP/IP
• RFC 1157 — Простой протокол сетевого управления

Через некоторое время, RFC 1156 (MIB-1) был заменён более используемым:

• RFC 1213 — Версия 2 базы управляющей информации (MIB-2) для сетевого управления в сетях на основе стека протоколов TCP/IP

Версию 1 критиковали за низкую безопасность. Аутентификация клиентов производилась только с помощью т. н. «общей строки» (community string), по сути пароля, которая передавалась в открытом виде. Разработка SNMPv1 80-х годов проводилась группой сотрудников, которые рассматривали официально финансируемые работы HEMS/CMIS/CMIP организаций OSI/IETF/NSF как одновременно нереализуемые на вычислительных платформах того времени и потенциально неработоспособные. SNMP был одобрен из убеждения в том, что он является промежуточным протоколом, необходимым для принятия мер по широкомасштабному развёртыванию сети Интернет и её коммерциализации. В тот временной период стандарт аутентификации/безопасности был мечтой и ему препятствовали группы разработки протокола.

Версия 2

SNMPv2 (RFC 1441-RFC 1452) пересматривает Версию 1 и включает в себя улучшения в области производительности, безопасности, конфиденциальности и связях между менеджерами. Протокол ввел GetBulkRequest, альтернативу итерационному применению GetNextRequest для получения большого количества управляющих данных через один запрос. В то же время, новая система безопасности на основе сторон из SNMPv2 так и не получила широкое распространение, так как рассматривалась многими как слишком сложная.

SNMPv2 на основе сообществ (SNMPv2c) определён в RFC 1901-RFC 1908. На своей начальной стадии эта версия была неофициально известна как SNMPv1.5. SNMPv2c включает SNMPv2 без её спорной модели безопасности; вместо этого используется простая схема безопасности на основе сообществ из SNMPv1. SNMPv2c часто воспринимался де-факто как стандарт SNMPv2 несмотря на то, что официально он был всего лишь «черновым стандартом» (Draft Standard).

SNMPv2 на основе пользователей (SNMPv2u) определён в RFC 1909-RFC 1910. По сути, это компромисс, который пытается предложить более высокую, чем в SNMPv1, безопасность, но без излишней сложности, характерной для SNMPv2. Один из вариантов этой версии, SNMP v2*, был коммерческим, а сам механизм в итоге был принят в качестве одной из двух структур безопасности в SNMP v3.

Взаимодействие SNMPv1 и SNMPv2с

На данный момент определено, что SNMPv2с несовместим с SNMPv1 в двух ключевых областях: форматы сообщений и операции протокола. Сообщения SNMPv2c используют отличные от SNMPv1 форматы заголовка и протокольных единиц данных (PDU). Также SNMPv2c использует две операции протокола, которые не определены в SNMPv1. Кроме того, RFC 2576 определяет две возможные стратегии сосуществования SNMPv1/v2c: прокси-агенты и двуязычные системы сетевого управления.

Прокси-агенты

Агент SNMPv2 может действовать как прокси-агент от имени управляемых протоколом SNMPv1 устройств, а именно:

• Система сетевого управления (Network management system, NMS) SNMPv2 выдаёт команды, предназначенные для SNMPv1-агента.
• NMS посылает SNMP-сообщение прокси-агенту SNMPv2.
• Прокси-агент без изменения направляет сообщения Get, GetNext и Set агенту SNMPv1.
• Сообщения GetBulk преобразуются прокси-агентом в сообщения GetNext, после чего направляются агенту SNMPv1.

Прокси-агент отображает trap-сообщения SNMPv1 в trap-сообщения SNMPv2, после чего направляет их NMS.

Двуязычные системы сетевого управления

Двуязычные SNMPv2-системы сетевого управления поддерживают как SNMPv1, так и SNMPv2. Для поддержки такого окружения управляющее приложение в двуязычной NMS должно связаться с агентом. Затем NMS анализирует хранящуюся в локальной базе данных информацию для определения, поддерживает ли агент SNMPv1 или SNMPv2. На основе этой информации NMS связывается с агентом, используя соответствующую версию SNMP.

Версия 3

Хотя SNMPv3 не приносит никаких изменений в протокол помимо добавления криптографической защиты, он является улучшением за счёт новых текстовых соглашений, концепций и терминологии.

Безопасность была большой проблемой SNMP с самого появления. Аутентификация в SNMP версий 1 и 2 сводилась не более чем к паролю (строке сообщества), который пересылался в открытом виде между менеджером и агентом.

В отличие от SNMPv1 и v2, в SNMPv3 каждое сообщение содержит параметры безопасности, которые закодированы как строка октетов. Значение этих параметров зависит от используемой модели безопасности.

SNMPv3 предоставляет важные особенности безопасности:

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

С 2004 года IETF признаёт SNMPv3, определённый в RFC 3411, RFC 3418 (также известный как STD0062) в качестве текущей стандартной версии SNMP. IETF отметил SNMPv3 как полный Интернет-стандарт, что является самым высоким уровнем готовности для RFC. При этом более ранние версии считаются устаревшими (обозначаются как «исторические» — Historic).

На практике в реализациях SNMP часто поддерживаются несколько версий: v1, v2c и v3.

Менеджер (NMS)

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

Менеджер имеет правильные учетные данные для доступа к информации, хранящейся агентами (что объясняется в следующем разделе), а затем компилирует их в читаемом формате для сетевого инженера или администратора для мониторинга или диагностики проблем или узких мест. Некоторые программные пакеты NMS более сложны, чем другие, что позволяет настраивать сообщения электронной почты или SMS, чтобы предупредить вас о неисправных устройствах в вашей сети, в то время как другие просто опросили устройства для получения более общей информации.

Агенты

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

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

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

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

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

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

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

MIB

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

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

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

OID

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 протокола, дебютировавшая в 1998 году, сделала большие шаги для обеспечения безопасности набора протоколов, реализовав так называемую «пользовательскую безопасность». Эта функция безопасности позволяет вам устанавливать аутентификацию на основе требований пользователя. 3 уровня аутентификации:

• NoAuthNoPriv: пользователи, которые используют этот режим / уровень, не имеют аутентификации и не имеют конфиденциальности при отправке / получении сообщений.
• AuthNoPriv: этот уровень требует от пользователя аутентификации, но не будет шифрования отправленных / полученных сообщений.
• AuthPriv: Наконец, самый безопасный уровень, в котором требуется аутентификация, и отправленные / полученные сообщения зашифрованы.

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

Ресурсная индексация

Модульные устройства могут динамически увеличивать или уменьшать свои SNMP-индексы (также называемые случаями) при добавлении или удалении оборудования. Это чаще всего используется с аппаратными средствами, хотя виртуальные интерфейсы имеют тот же эффект. Значения индекса, как правило, назначаются во время загрузки и остаются неизменными до следующей перезагрузки. Индексы оборудования или виртуальных сущностей, добавленных при «живом» устройстве, могут назначаться под конец существующего диапазона и, возможно, переназначаться при следующей перезагрузке.

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

• SNMP версий 1 и 2c подвержены перехвату пакетов со строками сообщений, так как они не используют шифрование.
• Все версии SNMP подвержены атакам грубой силой и словарным перебором для угадывания строк сообщества, строк аутентификации, ключей аутентификации, строк шифрования или ключей шифрования, поскольку они не используют «рукопожатие» вида запрос-ответ.
• Хотя SNMP работает с TCP и другими протоколами, обычно он используется с UDP, то есть без установки соединения и с уязвимостью для атак подменой IP. Для ограничения SNMP-доступа могут быть использованы списки доступа к устройству, но и механизмы защиты SNMPv3 способны успешно мешать атакам.
• Обширные возможности в настройке SNMP многими поставщиками не используются в полную силу, отчасти из-за недостатка безопасности в версиях SNMP до SNMPv3, а также из-за того, что многие устройства просто не могут быть настроены с помощью изменений отдельного объекта базы MIB.
• SNMP возглавляет составленный SANS Institute список «Common Default Configuration Issues» с вопросом изначальной установки строк сообщества на значения «public» и «private» и занимал десятую позицию в SANS Top 10 Самых критических угроз Интернет-безопасности за 2000 год.

Автоматическая настройка

SNMP сам по себе является просто протоколом сбора и организации информации. Большинство реализующих SNMP инструментариев предлагают ту или иную форму механизма обнаружения (стандартизированного сбора данных, общих для большинства платформ и устройств) для получения нового пользователя или исполнителя при начале работы. Одна из этих функций часто является формой автоматической настройки, при которой новые обнаруженные в сети устройства опрашиваются автоматически. В случае SNMPv1 и SNMPv2c это представляет угрозу безопасности, поскольку read-сообщества SNMP будут транслироваться в открытом виде на целевом устройстве. Пока требования безопасности различны в разных организациях, следует проявлять осторожность при использовании этой функции, особенно с учётом таких особенностей, как центры обработки данных со смешанными арендаторами, объекты размещения серверов и подобные условия.

В настоящее время иногда вытесняется протоколами Netconf и TR-069, но чаще применяется совместно с ними.