Для чего предназначен SNMP: руководство по NMS, MIB, OID, ловушкам и агентам
SNMP (Simple Network Management Protocol) представляет собой коммуникационный протокол, который позволяет отслеживать управляемые сетевые устройства, включая маршрутизаторы, коммутаторы, серверы, принтеры и другие устройства, которые включены через IP через единую систему управления / программное обеспечение.
Если сетевое устройство поддерживает протокол SNMP, вы можете включить и настроить его для начала сбора информации и мониторинга количества сетевых устройств, как вы хотите, из одной точки.
Что делает SNMP?
- Мониторинг входящего и исходящего трафика, проходящего через устройство
- Раннее обнаружение сбоев в сетевых устройствах вместе с предупреждениями / уведомлениями
- Анализ данных, собранных с устройств в течение длительных периодов времени для выявления узких мест и проблем с производительностью
- Возможность удаленного конфигурирования совместимых устройств
- Доступ и управление устройствами удаленно, которые подключаются через SNMP
Менеджер (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-файлы представляют собой набор вопросов, которые SNMP-менеджер может задать агенту. Агент собирает эти данные локально и сохраняет их, как определено в MIB. Таким образом, диспетчер SNMP должен знать эти стандартные и частные вопросы для каждого типа агента.
Агенты, как объяснялось выше, поддерживают организованную базу данных параметров устройства, настроек и т.д. Система NMS (Network Management system) опроса / запроса агента данного устройства, которая затем делится своей организованной информацией из базы данных, сделанной с помощью NMS, которая затем переводит ее в предупреждения, отчеты, графики и т. Д. База данных, которую Агент разделяет между Агентом, называется Информационной базой управления или MIB .
MIB содержат набор значений, как статистических, так и контрольных, которые определяются сетевым устройством. Во многих случаях расширения стандартных значений определяются с помощью Private MIB разными поставщиками сетевых устройств.
Чтобы упростить MIB, подумайте об этом так: MIB-файлы — это набор Вопросов, которые Менеджер может спросить у агента. Агент просто собирает эти вопросы и сохраняет их локально и обслуживает их по NMS по запросу.
Упрощенный пример работы MIB: NMS спросит у сетевого устройства вопрос, в данном случае, что такое ответ на вопрос 2?
Агент управляемых сетевых устройств затем отвечает с ответом на вопрос 2. Чтобы еще больше разбить это, давайте построим еще один пример.
Скажем, мы хотим знать системное время работы устройства.
NMS отправит запрос агенту, запрашивающему Системное время, — запрос отправляется как номер с MIB и объектом интереса, а также что-то, называемое экземпляром .
Распределение номера OID
| MIB | Объект интереса | Пример |
| 1.3.6.1.2.1.1 | 3 | 0 |
| MIB | Объект SysUptime | Образец |
Первые 2 части числа, отправленные агенту (MIB и объект интереса, который в этом случае является системным временем), называются идентификатором объекта или OID . Как упоминалось выше, MIB являются стандартными значениями, которые система сетевого управления уже знает и может опросить / запросить сетевые устройства для получения информации.
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 разрешено что значит
Simple Network Management Protocol
Управление сетевыми устройствами
SNMP (англ. Simple Network Management Protocol — простой протокол сетевого управления) — стандартный интернет-протокол для управления устройствами в IP-сетях на основе архитектур UDP/TCP. К поддерживающим SNMP устройствам относятся маршрутизаторы, коммутаторы, серверы, рабочие станции, принтеры, модемные стойки и другие. Протокол обычно используется в системах сетевого управления для контроля подключенных к сети устройств на предмет условий, которые требуют внимания администратора. SNMP определен Инженерным советом интернета (IETF) как компонент TCP/IP. Он состоит из набора стандартов для сетевого управления, включая протокол прикладного уровня, схему баз данных и набор объектов данных.
SNMP предоставляет данные для управления в виде переменных, описывающих конфигурацию управляемой системы. Эти переменные могут быть запрошены (а иногда и заданы) управляющими приложениями.
Содержание
Обзор и основные понятия
При использовании SNMP один или более административных компьютеров (где функционируют программные средства, называемые менеджерами) выполняют отслеживание или управление группой хостов или устройств в компьютерной сети. С каждой управляемой системой связана постоянно запущенная программа, называемая агент, которая через SNMP передаёт информацию менеджеру.
Агенты SNMP обрабатывают данные о конфигурации и функционировании управляемых систем и преобразуют их во внутренний формат, удобный для поддержания протокола SNMP. Протокол также разрешает активные задачи управления, например, изменение и применение новой конфигурации через удаленное изменение этих переменных. Доступные через SNMP переменные организованы в иерархии. Эти иерархии, как и другие метаданные (например, тип и описание переменной), описываются базами управляющей информации (базы MIB, от англ. Management information base ).
Управляемые протоколом SNMP сети состоят из трех ключевых компонентов:
- Управляемое устройство;
- Агент — программное обеспечение, запускаемое на управляемом устройстве, либо на устройстве, подключенном к интерфейсу управления управляемого устройства;
- Система сетевого управления (Network Management System, NMS) — программное обеспечение, взаимодействующее с менеджерами для поддержки комплексной структуры данных, отражающей состояние сети [1] .
Управляемое устройство — элемент сети (оборудование или программное средство), реализующий интерфейс управления (не обязательно SNMP), который разрешает однонаправленный (только для чтения) или двунаправленный доступ к конкретной информации об элементе. Управляющие устройства обмениваются этой информацией с менеджером. Управляемые устройства могут относиться к любому виду устройств: маршрутизаторы, серверы доступа, коммутаторы, мосты, концентраторы, IP-телефоны, IP-видеокамеры, компьютеры-хосты, принтеры и т.п.
Агентом называется программный модуль сетевого управления, располагающийся на управляемом устройстве, либо на устройстве, подключенном к интерфейсу управления управляемого устройства. Агент обладает локальным знанием управляющей информации и переводит эту информацию в специфичную для SNMP форму или из неё (медиация данных).
В состав Системы сетевого управления (NMS) входит приложение, отслеживающее и контролирующее управляемые устройства. NMS обеспечивают основную часть обработки данных, необходимых для сетевого управления. В любой управляемой сети может быть одна и более NMS.
Базы управляющей информации (MIB)
Сам по себе SNMP не определяет, какая информация и переменные должны быть предложены управляемой системой. Вместо этого SNMP использует расширяемую разработку, в которой доступная информация определяется базами управляющей информации (базы MIB). Базы MIB описывают структуру управляемых данных на подсистеме устройства; они используют иерархическое пространство имен, содержащее идентификаторы объектов (OID-ы). Каждый OID определяет переменную, которая может быть считана либо установлена с помощью 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 построены следующим образом:
| IP header (IP-заголовок) | UDP header (UDP-заголовок) | version (версия) | community (пароль) | PDU-type (PDU-тип) | request-id (id запроса) | error-status (статус ошибки) | error-index (индекс ошибки) | variable bindings (связанные переменные) |
Ниже перечислены семь протокольных единиц обмена 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-запросы, она была названа GetResponse в SNMPv1.
Асинхронное уведомление от агента — менеджеру. Включает в себя текущее значение sysUpTime, OID, определяющий тип trap (ловушки), и необязательные связанные переменные. Адресация получателя для ловушек определяется с помощью переменных trap-конфигурации в базе MIB. Формат trap-сообщения был изменен в SNMPv2 и PDU переименовали в SNMPv2-Trap.
InformRequest
Асинхронное уведомление от менеджера — менеджеру или от агента — менеджеру. Уведомления от менеджера — менеджеру были возможны уже в SNMPv1 (с помощью Trap), но SNMP обычно работает на протоколе UDP, в котором доставка сообщений не гарантирована и не сообщается о потерянных пакетах. InformRequest исправляет это отправлением назад подтверждения о получении. Получатель отвечает Response-ом, повторяющим всю информацию из InfromRequest. Этот PDU был введен в SNMPv2.
Разработка и использование
Версия 1
SNMP, версия 1 (SNMPv1) — изначальная реализация протокола SNMP. SNMPv1 работает с такими протоколами, как UDP, IP, CLNS, DDP и IPX. SNMPv1 широко используется и де-факто является протоколом сетевого управления в Интернет-сообществе.
Первые RFC для SNMP, сейчас известные как SNMPv1, появились в 1988г:
-
— Структура и идентификация управляющей информации в сетях на основе стека протоколов TCP/IP — База управляющей информации для сетевого управления в сетях на основе стека протоколов TCP/IP — Простой протокол сетевого управления
Эти протоколы были пересмотрены в следующих RFC:
-
— Структура и идентификация управляющей информации в сетях на основе стека протоколов TCP/IP — База управляющей информации для сетевого управления в сетях на основе стека протоколов TCP/IP — Простой протокол сетевого управления
Через некоторое время, RFC 1156 (MIB-1) был заменен более используемым:
-
— Версия 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 на основе пользователей (SNMPv2) определен в 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 не привносит никаких изменений в протокол помимо добавления криптографической защиты, он кажется более отличным за счет новых текстовых соглашений, концепций и терминологии.
SNMPv3 в первую очередь добавляет в SNMP защиту и улучшения в удаленной настройке.
Безопасноть была наибольшей слабостью SNMP с самого появления. Аутентификация в SNMP версий 1 и 2 сводилась не более чем к паролю (строке сообщества), который пересылался в открытом виде между менеджером и агентом. Каждое SNMPv3-сообщение содержит параметры безопасности, которые закодированы как строка октетов. Значение этих параметров зависит от используемой модели безопасности.
SNMPv3 предоставляет важные особенности безопасности:
- Конфиденциальность — шифрование пакетов для предотвращения перехвата несанкционированным источником.
- Целостность — целостность сообщений, для предотвращения изменения пакета в пути, включая дополнительный механизм защиты от повторной передачи перехваченного пакета.
- Аутентификация — чтобы убедиться, что сообщение пришло из правильного источника.
С 2004 года IETF признает SNMPv3, определенный в RFC 3411, RFC 3418 (также известный как STD0062) в качестве текущей стандартной версии SNMP. IETF отметил SNMPv3 как полный Интернет-стандарт, что является самым высоким уровнем готовности для RFC. при этом более ранние версии считаются устаревшими (обозначаются как «исторические» — Historic).
На практике, реализации SNMP часто поддерживают несколько версий: обычно SNMPv1, SNMPv2c, и SNMPv3.
Вопросы реализации
Реализации SNMP варьируются среди поставщиков платформ. В отдельных случаях, SNMP не считается достаточно серьезным для элемента основной разработки и потому является просто дополнительной функцией. Некоторые крупные поставщики оборудования имеют склонность к чрезмерному расширению своих собственных интерфейсов командной строки (command line interface, CLI) и систем контроля.
Простая на вид структура дерева и линейная индексация в SNMP не всегда достаточно хорошо понимаются в пределах внутренних структур данных, которые являются элементами базовой конструкции платформы. Следовательно, обработка SNMP-запросов на определенных наборах данных может привести к большей, чем необходимо, нагрузке на процессор. Одним из примеров этой проблемы являются большие таблицы маршрутизации, такие как BGP и IGP.
Ресурсная индексация
Модульные устройства могут динамически увеличивать или уменьшать свои 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 будут транслироваться в открытом виде на целевом устройстве. Пока требования к безопасности варьируются от организации к организации, следует проявлять осторожность при использовании такой функции как эта, особенно с учетом обычных условий, таких как центры обработки данных со смешанными арендаторами, объекты размещения серверов и аналогичные условия.
Примеры использования утилит SNMP
snmpset и перезагрузка Cisco as53xx
- Настройка SNMP на Cisco as53xx
Enter configuration commands, one per line. End with CNTL/Z.
! Список № 1: Разрешить доступ из сети 10.26.95.224/27 или 255.255.255.224
as5350(config)#access-list 1 permit 10.26.95.224 0.0.0.31
! Список № 2: Разрешить доступ с IP 10.26.95.254 и 10.26.95.251
as5350(config)#access-list 2 permit host 10.26.95.254
as5350(config)#access-list 2 permit host 10.26.95.251
! Настройка snmp-server для чтения и записи со строкой сообщества xxas5300xx.
! SNMP -доступ разрешен только для access-list 2 (для 2-х IP, для остальных IP неявно запрещен)
SNMP — что это
SNMP или Simple Network Management Protocol — это стандартный протокол, который применяется для мониторинга и управления сетевыми устройствами (маршрутизаторы, коммутаторы, брандмауэры, балансировщики нагрузки и др.), подключенными через IP. Инструмент собирает данные, упорядочивает их и отправляет для сетевого мониторинга и управления, что позволяет обнаружить и устранить ошибки. В статье подробно расскажем о протоколе и о том, как и зачем он используется.
Что такое простой протокол управления сетью
SNMP позволяет различным устройствам в сети обмениваться данными между собой, даже если у них разное оборудование и программное обеспечение. Без такого протокола средства управления сетью не могли бы идентифицировать оборудование, отслеживать производительность сети, отслеживать изменения в сети или определять состояние сетевых устройств в режиме реального времени.
SNMP работает путем отправки блоков данных протокола, также известных как запросы SNMP GET, на сетевое оборудование, которое на них отвечает. Все эти коммуникации отслеживаются, и инструменты сетевого мониторинга используют их для получения данных из SNMP.
Архитектура
SNMP имеет простую архитектуру, основанную на модели клиент-сервер. Серверы, называемые менеджерами, собирают и обрабатывают информацию об устройствах в сети. Диспетчер SNMP или станция управления сетью — это центральная система, используемая для мониторинга сети. Он отвечает за связь с сетевым оборудованием, реализуемыми агентом и работает на хосте в сети. Менеджер опрашивает клиентов, получает ответы, устанавливает в них переменные и подтверждает события от них.
Клиенты называются агентами и представляют собой устройства или компоненты любого типа, подключенные к сети. Сюда могут входить не только компьютеры, но и сетевые коммутаторы, телефоны, принтеры и так далее. Агент — это программный процесс, который отвечает на запросы SNMP для предоставления статуса и статистики о сетевом узле. Агенты играют наиболее важную роль в управлении. Они расположены локально и связаны с сетевыми устройствами SNMP, с которых они собирают, хранят и передают данные мониторинга. Данные передаются назначенному диспетчеру по запросу.
Некоторое оборудование может иметь несколько компонентов. Например, ноутбук обычно содержит как проводной, так и беспроводной сетевой интерфейс.
Иерархия данных SNMP
Архитектура SNMP проста, однако у тех, кто с ней не знаком, иерархия данных, которую использует протокол, может вызвать затруднения.
Для обеспечения гибкости и расширяемости SNMP не требует от сетевых устройств обмена данными в жестком формате фиксированного размера. Вместо этого он использует древовидный формат, в котором данные всегда доступны для сбора.
Дерево данных состоит из нескольких таблиц, которые называются информационными базами управления или MIB. Базы MIB группируют определенные типы устройств или компонентов. Каждая MIB имеет уникальный идентификационный номер, а также идентификационную строку. Числа и строки могут использоваться взаимозаменяемо (аналогично IP-адресам и именам хостов).
Каждая MIB состоит из одного или нескольких узлов, которые представляют собой отдельные устройства или компоненты в сети. В свою очередь, каждый узел имеет уникальный идентификатор объекта, или OID . OID для данного узла определяется идентификатором MIB, в котором он существует, в сочетании с идентификатором узла в его MIB.
Это означает, что OID принимает форму набора чисел или строк. Например: 1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3 .
Записанный строками, этот OID будет переводиться как:
iso.org.dod.internet.private.transition.products.chassis.card.slotCps.
cpsSlotSummary.cpsModuleTable.cpsModuleEntry.cpsModuleModel.3562.3.
Используя OID, менеджер может запросить у агента информацию об устройстве в сети. Например, если диспетчер хочет знать, включен ли интерфейс, он сначала запросит интерфейсную MIB, а затем проверит значение OID, отражающее рабочее состояние, чтобы определить, включен ли интерфейс.
Зачем нужен OID
Иерархия данных MIB и OID может показаться запутанной, но у такой системы есть несколько важных преимуществ. Во-первых, информация может быть извлечена менеджером без отправки агенту явного запроса на ее сбор. Это снижает накладные расходы и гарантирует постоянную доступность информации о состоянии сети.
Система также обеспечивает простой и гибкий способ организации множества устройств в сети. Он работает независимо от размера сети и входящего в неё оборудования.
SNMP также позволяет быстро собирать большие объемы информации, не забивая сеть трафиком. Поскольку информация о состоянии устройства всегда доступна в простом формате и обновляется в режиме реального времени, менеджеры могут получать ее без ожидания и без передачи больших объемов данных.
Также некоторые значения OID зависят от поставщика, что позволяет легко получить некоторую информацию об устройстве, основываясь только на его OID. Например, если OID начинается с 1.3.6.1.4.1.9, он относится к Cisco. Другие производители имеют свои собственные спецификации OID. Стандартный префикс OID, который можно использовать практически для любого устройства, поддерживающего SNMP, — 1.3.6.1.2.
Версии протокола
В разных версиях протокола SNMP функции сильно различаются, поэтому стоит поговорить о них отдельно.
SNMPv1
Самая первая версия SNMPv1 имеет наиболее слабые функции безопасности. При запросе информации менеджеры могут аутентифицировать агентов без шифрования. То есть любой, у кого есть доступ, может запускать программы для перехвата информации о сети. Это также означает, что неавторизованное устройство может легко выдать себя за законного менеджера при управлении сетью.
Кроме того, по умолчанию используются определенные учетные данные, которые администраторы не всегда обновляют В результате неавторизованные стороны могут легко получить доступ к конфиденциальной информации о сети.
Несмотря на эти серьёзные недостатки, SNMPv1 по-прежнему широко используется, так как некоторые сети еще не обновлены.
SNMPv2
SNMPv2 появился в 1993 г. И имел некоторые улучшения в сфере безопасности, но уже в 1998 г. Его потеснил SNMPv3. Он является последней и наиболее безопасной версией, так что о ней поговорим подробнее.
SNMPv3
Третья версия позволяет шифровать данные. Кроме того, администраторы могут детально указывать различные требования к аутентификации для менеджеров и агентов. Это предотвращает несанкционированную аутентификацию и может дополнительно использоваться для требования шифрования при передаче данных.
Хотя проблемы безопасности SNMPv1 принесли всего протоколу дурную славу, SNMPv2 и особенно SNMPv3 решили эти проблемы. Более новые версии SNMP предоставляют современный и безопасный способ мониторинга сети.
Зачем нужны инструменты мониторинга SNMP
Сетевые администраторы обычно управляют устройствами в сети, а также выделяют и освобождают порты и интерфейсы, чтобы обеспечить непрерывное время безотказной работы и сетевые операции без пропускной способности. Тщательный мониторинг является важной частью этого. Мониторинг SNMP требует, чтобы администратор настроил агент для отправки данных мониторинга диспетчеру. Поскольку инструмент управления сетью занимается мониторингом, администраторы могут сосредоточиться на выполнении корректирующих действий.
Инструменты мониторинга SNMP необходимы для:
- Автоматического обнаружения, мониторинга и управления сетевым оборудованием.
- Отслеживания ключевых показателей производительности на уровне устройств и интерфейсов.
- Получения полной прозрачности и детализации производительности.
- Настройки пороговых значений и генерации оповещения в случае проблем.
Основываясь на информации, предоставляемой этими инструментами, администраторы могут отслеживать доступность и производительность сетевого оборудования и выявлять проблемы для поддержания работоспособности своей сети. Идеальный инструмент мониторинга отслеживает различные версии протокола и помогает ИТ-администраторам получить полную картину всей сетевой среды. Программное обеспечение для мониторинга SNMP также предоставляет собранные данные в понятных форматах, например, информационных панелей и графиков.
Введение в SNMP (простой протокол управления сетью)
Большая часть работы системного администратора собирает точную информацию о ваших серверах и инфраструктуре. Существует ряд инструментов и опций для сбора и обработки информации такого типа. Многие из них основаны на технологии под названием * SNMP *.
SNMP обозначает простой протокол управления сетью. Это способ, которым серверы могут обмениваться информацией о своем текущем состоянии, а также канал, через который администратор может изменять предопределенные значения. Хотя сам протокол очень прост, структура программ, реализующих SNMP, может быть очень сложной.
В этом руководстве мы познакомим вас с основами протокола SNMP. Мы рассмотрим его использование, способ, которым протокол обычно используется в сети, различия в его версиях протокола и многое другое.
Базовые концепции
SNMP — это протокол, который реализован на прикладном уровне сетевого стека (нажмите здесь, чтобы узнать о https://www.digitalocean.com/community/tutorials/an-introduction-to-networking-terminology-interfaces-and-protocols #NetworkLayers [сетевые слои]). Протокол был создан как способ последовательного сбора информации из самых разных систем. Несмотря на то, что он может использоваться в связи с разнообразным массивом систем, метод запроса информации и пути к соответствующей информации стандартизированы.
Существует несколько версий протокола SNMP, и многие сетевые аппаратные устройства реализуют некоторую форму доступа SNMP. Наиболее широко используемая версия — SNMPv1, но во многих отношениях она небезопасна. Его популярность во многом связана с его повсеместностью и долгим временем в дикой природе. Если у вас нет веских причин не делать этого, мы рекомендуем использовать SNMPv3, который предоставляет более продвинутые функции безопасности.
В целом, сеть, профилируемая SNMP, будет состоять в основном из устройств, содержащих SNMP * агенты *. Агент — это программа, которая может собирать информацию об оборудовании, организовывать ее в заранее определенные записи и отвечать на запросы с использованием протокола SNMP.
Компонент этой модели, который запрашивает информацию у агентов, называется SNMP * manager *. Эти машины обычно имеют данные обо всех устройствах с поддержкой SNMP в своей сети и могут выдавать запросы для сбора информации и установки определенных свойств.
SNMP менеджеры
Менеджер SNMP — это компьютер, настроенный на опрос агента SNMP для получения информации. Компонент управления, когда обсуждается только его основная функциональность, на самом деле намного менее сложен, чем конфигурация клиента, потому что компонент управления просто запрашивает данные.
Администратором может быть любая машина, которая может отправлять запросы на запросы агентам SNMP с правильными учетными данными. Иногда это реализуется как часть пакета мониторинга, в то время как в других случаях это администратор, использующий несколько простых утилит для создания быстрого запроса.
Почти все команды, определенные в протоколе SNMP (мы подробно рассмотрим их позже), предназначены для sent компонентом менеджера. К ним относятся + GetRequest + , + GetNextRequest + , + GetBulkRequest + , + SetRequest + , + InformRequest + и + Response + . В дополнение к этому менеджер также предназначен для ответа на сообщения + Trap и` + Response`.
Агенты SNMP
Агенты SNMP делают основную часть работы. Они несут ответственность за сбор информации о локальной системе и ее хранение в формате, который может быть запрошен. Обновление базы данных, называемой «базой управленческой информации», или * MIB *.
MIB представляет собой иерархическую, предварительно определенную структуру, которая хранит информацию, которую можно запрашивать или устанавливать. Это доступно для правильно сформированных запросов SNMP, исходящих от хоста, который прошел аутентификацию с правильными учетными данными (менеджер SNMP).
Компьютер агента определяет, какие менеджеры должны иметь доступ к своей информации. Он также может выступать в качестве посредника для сообщения информации об устройствах, к которым он может подключиться, которые не настроены для трафика SNMP. Это обеспечивает большую гибкость при подключении ваших компонентов к сети и доступности SNMP.
Агенты SNMP отвечают на большинство команд, определенных протоколом. К ним относятся + GetRequest + , + GetNextRequest + , + GetBulkRequest + , + SetRequest + и + InformRequest + . Кроме того, агент предназначен для отправки + Trap + сообщений.
Понимание базы управленческой информации
Самая сложная для понимания часть системы SNMP — это, вероятно, * MIB *, или информационная база управления. MIB — это база данных, которая соответствует стандарту, которого придерживаются менеджер и агенты. Это иерархическая структура, которая во многих областях стандартизирована на глобальном уровне, но в то же время достаточно гибкая, чтобы можно было добавлять дополнения для конкретного поставщика.
Структура MIB лучше всего понимается как иерархическое дерево сверху вниз. Каждая ветвь, которая разветвляется, помечается как идентифицирующим номером (начиная с 1), так и идентифицирующей строкой, которые являются уникальными для этого уровня иерархии. Вы можете использовать строки и числа взаимозаменяемо.
Чтобы обратиться к конкретному узлу дерева, вы должны проследить путь от безымянного корня дерева до рассматриваемого узла. Происхождение его родительских идентификаторов (чисел или строк) связано, начиная с самого общего, для формирования адреса. Каждое соединение в иерархии представлено точкой в этой нотации, так что адрес в конечном итоге представляет собой последовательность строк ID или чисел, разделенных точками. Весь этот адрес известен как идентификатор объекта или * OID *.
Производители оборудования, которые встраивают агенты SNMP в свои устройства, иногда реализуют собственные ветви с собственными полями и точками данных. Однако существуют стандартные ветви MIB, которые хорошо определены и могут использоваться любым устройством.
Все стандартные ветви, которые мы будем обсуждать, будут находиться в одной структуре родительской ветви. Эта ветвь определяет информацию, которая соответствует спецификации MIB-2, которая является пересмотренным стандартом для совместимых устройств.
Базовый путь к этой ветке:
Это также может быть представлено в виде строк:
Раздел + 1.3.6.1 + или + iso.org.dod.internet + является OID, который определяет интернет-ресурсы. + 2 + или + mgmt + , которые следуют в нашем базовом пути, предназначены для подкатегории управления. + 1 + или + mib-2 + в соответствии с этим определяет спецификацию MIB-2.
Это great ресурс для ознакомления с деревом MIB. Эта конкретная страница представляет соединительные узлы на перекрестке, о котором мы говорили. Вы можете проверить, что дальше вверх и вниз по дереву, проверив «улучшенные» и «вспомогательные» ссылки соответственно.
Другим аналогичным инструментом является SNMP Object Navigator, предоставляемый Cisco. Это можно использовать для детализации иерархии, чтобы найти нужную вам информацию. Solarwinds предоставляет s аналогичное дерево.
По сути, если мы хотим запросить информацию на наших устройствах, большинство путей начнется с + 1.3.6.1.2.1 + . Вы можете просматривать древовидные интерфейсы, чтобы узнать, какую информацию можно запрашивать и устанавливать.
Команды протокола SNMP
Одной из причин такого широкого применения SNMP является простота доступных команд. Операций, которые нужно реализовать или запомнить, очень мало, но они достаточно гибкие, чтобы соответствовать требованиям протокола.
Следующие PDU, или блоки данных протокола, описывают точные типы сообщений, которые разрешены протоколом:
* Get *: сообщение Get отправляется менеджером агенту для запроса значения определенного OID. На этот запрос приходит ответное сообщение, которое отправляется обратно менеджеру с данными.
* GetNext *: сообщение GetNext позволяет менеджеру запрашивать следующий последовательный объект в MIB. Это способ, которым вы можете пересмотреть структуру MIB, не беспокоясь о том, какие OID запрашивать.
* Set *: сообщение Set отправляется менеджером агенту, чтобы изменить значение, которое хранится в переменной агента. Это может использоваться для управления информацией о конфигурации или иным образом изменять состояние удаленных хостов. Это единственная операция записи, определенная протоколом.
* GetBulk *: этот менеджер для запросов агента действует так, как если бы было сделано несколько запросов GetNext. Ответ обратно менеджеру будет содержать как можно больше данных (в пределах ограничений, установленных запросом), насколько позволяет пакет.
* Ответ *: Это сообщение, отправленное агентом, используется для отправки любой запрошенной информации обратно менеджеру. Он служит как транспортом для запрашиваемых данных, так и подтверждением получения запроса. Если запрошенные данные не могут быть возвращены, ответ содержит поля ошибок, которые могут быть установлены с дополнительной информацией. Ответное сообщение должно быть возвращено для любого из указанных выше запросов, а также для сообщений Inform.
* Trap *: сообщение о прерывании обычно отправляется агентом менеджеру. Ловушки — это асинхронные уведомления, так как они не запрашиваются менеджером, который их получает. В основном они используются агентами для информирования менеджеров о событиях, происходящих на их управляемых устройствах.
* Inform *: Чтобы подтвердить получение ловушки, менеджер отправляет агенту сообщение Inform. Если агент не получает это сообщение, он может продолжить повторную отправку сообщения прерывания.
С этими семью типами блоков данных SNMP способен запрашивать и отправлять информацию о ваших сетевых устройствах.
Версии протокола
Протокол SNMP претерпел много изменений с момента его появления. Первоначальная спецификация была сформулирована с RFC 1065, 1066 и 1067 в 1988 году. Из-за простого факта, что это было так долго, эта версия все еще широко поддерживается. Тем не менее, есть много проблем безопасности с протоколом, в том числе аутентификация в виде простого текста, поэтому его использование крайне не рекомендуется, особенно при использовании в незащищенных сетях.
Работа над версией 2 протокола была начата в 1993 году и предлагает некоторые существенные улучшения более раннего стандарта. В эту версию была включена новая «основанная на стороне» модель безопасности, предназначенная для решения проблем безопасности, присущих предыдущему пересмотру. Однако новая модель была не очень популярна, потому что ее было сложно понять и реализовать.
Из-за этого было создано несколько «побочных» вариантов версии 2, каждая из которых сохранила основную часть улучшений версии 2, но поменяла модель безопасности. В SNMPv2c была вновь введена аутентификация на основе сообщества, та же модель, что и в v1. Это была самая популярная версия протокола v2. Другая реализация, называемая SNMPv2u, использует безопасность на основе пользователей, хотя она никогда не была очень популярной. Это разрешено для настроек аутентификации для каждого пользователя.
В 1998 году третья (и текущая) версия протокола SNMP была введена в качестве предложения по спецификации. С точки зрения пользователя, наиболее важным изменением стало принятие системы безопасности на основе пользователя. Это позволяет вам установить требования аутентификации пользователя как одну из следующих моделей:
* NoAuthNoPriv *: Пользователи, подключающиеся с этим уровнем, не имеют никакой аутентификации и конфиденциальности сообщений, которые они отправляют и получают.
* AuthNoPriv *: соединения, использующие эту модель, должны аутентифицироваться, но сообщения отправляются без какого-либо шифрования.
* AuthPriv *: требуется аутентификация и сообщения зашифрованы.
В дополнение к аутентификации был реализован механизм контроля доступа, чтобы обеспечить детальный контроль над тем, к каким ветвям пользователь может получить доступ. Версия 3 также имеет возможность использовать безопасность, обеспечиваемую транспортными протоколами, такими как SSH или TLS.
Заключение
Теперь, когда у вас есть хорошее представление о том, как работает протокол, у вас есть основа, необходимая для реализации SNMP в вашей собственной инфраструктуре.
В next руководство, мы ‘ Обсудим, как установить и настроить компоненты, необходимые для использования SNMP в ваших системах.