Логика работы SNMP при обмене pdu-единицами

При получении PDU GetRequest, SNMP агент действует по следующему алгоритму:

· Если имя переменной не совпадает в точности с именем одной из переменной, доступных для операции get в нашей MIB, передаем отправителю запроса аналогичное PDU GetResponse, указывая в поле кода ошибки значение noSuchName (2-нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении (=1, в SNMPv1 - ограничение данной реализации SNMP).

· Если размер PDU GetResponse, созданного в соответствии с приведенным ниже описанием, превышает локальное ограничение (реализация SNMP не обязана принимать сообщения, размер которых превышает определенное значение, однако по возможности желательна поддержка дейтаграмм больших размеров (RFC1157 SNMP)), передаем отправителю аналогичное PDU GetResponse, указав в поле errorstatus значение TooBig, а в поле error-index — 0. Это обычно происходит, если запрошено больше 1 переменной или длина PDU или общая длина пакета больше стандартных пределов.

· Если для любой переменной, содержащейся в поле связанные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, SNMP агент передает отправителю аналогичное PDU GetResponse, указав в поле error-status значение GenErr, а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении.

· Если все нормально, передаем SNMP менеджеру, отправившему полученное сообщение, ответ - GetResponse, в котором для каждой переменной в поле связанные переменные подставлены запрошенные значения переменных. В поле error-status помещается значение NoError, а в поле error-index — 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.

 

 

При получении PDU GetNextRequest, SNMP агент действует по следующему алгоритму:

· Если после переменной, указанной в запросе, нет следующей переменной, то передаем отправителю запроса менеджеру PDU GetResponse (с содержимым аналогичным исходному запросу), указывая в поле кода ошибки значение noSuchName (нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении (=1 для SNMPv1), значение переменной = NULL (кажется).

· Если размер PDU ответа (GetResponse), созданного в соответствии с приведенным ниже описанием, превышает локальное ограничение, принимающий объект передает отправителю аналогичное PDU GetResponse, указав в поле errorstatus значение tooBig, а в поле error-index — 0.

· Если для любой переменной в поле связанные переменные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, принимающий объект передает менеджеру PDU с исходным содержимым GetResponse, указав в поле error-status значение genErr, а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении. (аналогично вышесказанному)

· Если все нормально, передаем SNMP менеджеру, отправившему PDU, такое сообщение GetResponse, в котором для каждой переменной в поле связанные переменные содержится имя и значение переменной, иерархически следующей за запрошенной переменной в базе MIB. В поле error-status помещается значение noError, а в поле error-index — 0. Значение поля request-id в ответном PDU GetResponse совпадает с идентификатором в принятом сообщении.

При получении PDU SetRequest, SNMP агент действует по следующему алгоритму:

· Если для любой переменной, содержащейся в поле связанные переменные, запись (операция set) не поддерживается в имеющих отношение к делу представлениях MIB, SNMP агент объект передает отправителю запроса аналогичное PDU GetResponse, указывая в поле кода ошибки значение noSuchName (нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении.

· Если для любой переменной в запросе, запрашиваемые к изменению значения переменных не соответствуют стандартам (SMI, ASN.1 – об этом ниже), то SNMP агент передает SNMP менеджеру аналогичное PDU GetResponse, указывая в поле кода ошибки значение badValue (нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении.

· Если размер PDU ответа (GetResponse), созданного в соответствии с приведенным ниже описанием, превышает локальное ограничение, принимающий объект передает отправителю аналогичное PDU GetResponse, указав в поле errorstatus значение tooBig, а в поле error-index — 0.

· Если для любой переменной в поле связанные переменные, значение переменной не может быть установлено по причинам, которые отличаются от перечисленных выше, SNMP агент передает менеджеру PDU с исходным содержимым GetResponse, указав в поле error-status значение genErr, а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении. (аналогично вышесказанному)

· Если все нормально, агент передает SNMP менеджеру, отправившему PDU, такое сообщение GetResponse, в котором для каждой переменной в поле связанные переменные подставлены установленные значения переменных. В поле error-status помещается значение NoError, а в поле error-index — 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.

 

Защита в SNMP

Безопасность протокола SNMP - это самый изменяемый раздел спецификации протокола со времени его создания. С каждой версией SNMP, производились попытки усилить безопасность. Первая версия протокола SNMPv1 была самой простой и небезопасной. Сообщения протокола могли быть подвержены возможности модификации, подмене или прослушиванию. Безопасность протокола базировалась на модели безопасности на основе сообществ (т.н. Community-based Security Model), что подразумевало аутентификацию на основе единой текстовой строки - своеобразного пароля (т.н. community-sting), которая передавалась в теле сообщения в открытом виде. Хотя, данная версия протокола самая незащищенная, она довольно часто применяется в современных сетях, т.к. является самой простой.

В одной из вторых версий SNMP (SNMPv2p) была попытка реализовать аутентификацию на основе сторон (т.н.Party-based Security Model). Технология кроме аутентификации, так же поддерживала возможность шифрования трафика. Данная технология не прижилась, как "сложная и запутанная") и в данный момент не используется. После чего SNMP второй версии вернулась к Community-based Security и стала именоваться SNMPv2c и применяется по сей день. SNMPv2 была переписана чуть более чем полностью, в результате чего существенно повышено быстродействие протокола, безопасность.

Третья версия протокола (SNMPv3) была более удачно доработана и поддерживает как аутентификацию на основе имени пользователя (т.н. User-based Security Model), так и шифрование трафика. Хотя их можно и не использовать.

Версии протокола между собой не совместимы. Несовместимость заключается в разнице пакетов PDU, в наличии дополнительных команд в более новых версиях протокола (возможно, в других…). В RFC 2576 имеется некоторая информация, позволяющая организовать возможность совместного использования SNMPv1 и v2. Для этого есть 2 пути: 1. Использование прокси-агентов (агент преобразует PDU SNMPv2 в PDU SNMPv1), 2. Использование менеджера с поддержкой 2х версий (менеджер для каждого хоста должен помнить версию агента).

 

 

Рассмотрим работу протокола SNMPv2c (и SNMPv1) с точки зрения безопасности. При рассмотрении структуры пакета PDU было видно, что каждая единица PDU содержит community строку. При этом, SNMP агент содержит список (часто данный список состоит из одного значения) разрешенных строк и описание того, что каждая из строк может делать (фактически – набор прав). В большинстве случаев – это права read/write. При активации функций SNMP на каком-либо хосте, стандартные строки community – это public и private для возможности чтения и для возможности чтения-записи соответственно. Это строки очень желательно менять на свои. Часто, при конфигурировании SNMP о, в котором для каждой переменной в поле связанные переменные подставлены установленные значения переменных. В поле error-status помещается значение NoError, а в поле error-index — 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.пределяют различные community строки для чтения переменных и для записи.

 

SNMP в Linux

В большинстве дистрибутивов Linux для работы с SNMP используется пакет net-snmp (RedHat) и snmp + snmpd (в Debian в snmp лежит клиентская часть, а в snmpd – серверная часть), который позволяет использовать протокол SNMP посредством отправки и получения PDU. После установки пакета(ов) в linux появятся следующие инструменты (перечислены не все):

· snmptranslate - Перевод MIB OID имён между цифровой и текстовой представлениями.

· snmpget - Взаимодействует с агентом, используя PDU GetRequest запросы.

· snmpgetnext - Взаимодействует с агентом, используя PDU GetNextRequest запросы.

· snmpbulkget - Взаимодействует с агентом, используя PDU GetBulkRequest запросы.

· snmpwalk - Получает поддерево объектов OID из MIB базы агента с помощью PDU GetNextRequest запросов. Если OID не задан, то команда получает дерево, начиная от MIB-2 (iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1))

· snmpbulkwalk - Получает поддерево объектов OID из MIB базы агента с помощью PDU GetBulkRequest запросов.

· snmpset - Взаимодействует с агентом, используя PDU SetRequest запросы.

· snmptrap - Посылает SNMP Trap или информационные сообщения.

· snmptest - Взаимодействует с сетью, используя SNMP запросы.

· …

Основной и часто используемой из всех указанных команд, является snmpwalk. При указании данной команды, без OID она попытается получить все объекты из ветки iso.org.dod.internet.mgmt.mib-2. В ссылках ниже можно найти отличный сборник примеров использования данных программ.

 

 

Так же, стоит отметить, что когда Вы работаете с указанными командами, наименование переменных OID «сворачивается» до короткого пути, например путь OID iso.org.dod.internet.mgmt.mib-2.system.sysName.0 (1.3.6.1.2.1.1.5.0) будет свернут до SNMPv2-MIB::sysName.0. На иллюстрации дерева MIB видно, как выделен красной заливкой путь iso.org.dod.internet.mgmt.mib-2, собственно, он и свернут в название данной ветки и представлен как SNMPv2-MIB::.

 

Практическая часть