interfaces.ifTable.ifEntry.ifType.1

interfaces.ifTable.ifEntry.ifIndex.1

interfaces.ifTable.ifEntry.ifMtu.1

Разобравшись с форматом дерева, перейдем к операциям, которые можно выполнять с помощью SNMP.

n  GetRequest – самая распространенная операция. Позволяет получить содержимое объекта из MIB. Обычно в разных статьях сокращается до Get.

n  GetNextRequest – операция получения следующего экземпляра из таблицы. Представим себе такую ситуацию. В нашем маршрутизаторе есть некоторое количество портов. Мы хотим узнать, какие из них активны в данный момент. С помощью GetRequest читаем данные первого экземпляра внутри ветви. Но вся проблема в том, что мы не знаем, сколько еще экземпляров осталось внутри. Вот тут-то нам пригодится GetNextRequest. С помощью этой операции мы проходим по всему списку объектов. Как только нам встречается первый объект из другой ветки, операция прекращается. Сокращенное название звучит как GetNext.

n  SetRequest – судя по названию, каждый может догадаться, что эта команда служит для внесения данных в MIB. Часто о ней говорят просто как о команде Set.

n  GetResponse – выполняется агентом в ответ на команды GetRequest, GetNextRequest, SetRequest. Если это ответ на первые две, то внутрь будут вложены запрошенные данные; ну а если на третью, то внутри будет подтверждение об успешном выполнении. Самые распространенные устные названия для этой команды – Reply или Response.

n  Trap – содержит внутри себя специальный OID, показывающий, что это ловушка, а также информацию о том, какой MIB-объект установил ловушку и данные этого объекта. Тут и сокращать-то нечего, поэтому название никогда не искажается.

Следующее интересное для нас понятие – «Имена Сообществ» (Community Names). Они являются своеобразным эквивалентом паролей и используются для того, чтобы разграничить, какие приказы агенту может отдавать тот или иной менеджер. Каждая из пяти перечисленных ранее операций должна содержать в себе правильное имя сообщества, иначе она не будет выполнена. Если агент настроен соответствующим образом, то в результате запроса с ошибочной строкой сообщества менеджеру будет отправлена ловушка с жалобой на попытку ошибочной аутентификации. Строки сообществ бывают трех видов Read-Only, Read-Write и Trap. Если менеджер передает агенту команды GetRequest, GetNextRequest, то внутри должна быть та строка сообщества Read-Only, которая запрограммирована в агенте.

Если же происходит попытка передать агенту на выполнение команду SetRequest, то для начала проверяется тип изменяемого объекта MIB. Тип должен быть read-write. И только затем происходит проверка переданной менеджером строки сообщества на совпадение со строкой Read-Write. Внесение изменений происходит, только если обе проверки завершились с положительным результатом.

В большинстве реализаций строка сообщества Trap применения не нашла. Первоначально она задумывалась как вспомогательное средство для облегчения процедуры сортировки внутри менеджера ловушек от разных видов агентов. Но, как показал опыт реальной эксплуатации протокола, необходимость в таких ухищрениях возникает очень редко.

SNMP работает на основе протокола UDP и для общения с сетью использует порт номер 162. Использование UDP в качестве основы означает, что данные передаются без установления соединения. Это дает возможность существенно уменьшить требования к сетевой инфраструктуре и накладные расходы на передачу данных. Пакеты SNMP могут передаваться не только с помощью UDP, но и поверх ATM, Ethernet, IPX.

Одной из основных проблем с безопасностью протокола SNMP являются имена сообществ, установленные изготовителем оборудования по умолчанию. Многие производители используют в качестве имен всех перечисленных сообществ слово «public». Многие администраторы после установки оборудования напрочь забывают о необходимости сменить имена сообществ. В таком случае любой более или менее осведомленный о протоколе SNMP злоумышленник может получить доступ к важным функциям оборудования. Вторая большая проблема состоит в том, что пакеты протокола SNMP передаются через сеть открытым текстом. Получается, что узнать нужные строки сообществ не так уж и сложно. Подобное плачевное состояние с безопасностью протокола породило довольно забавную шутку. По мнению сетевых острословов, SNMP расшифровывается как «Se-curity Not My Problem». Положение существенно улучшилось с введением второй версии протокола SNMP. Для противодействия злоумышленникам используются Symmetric Privacy Protocol (SPP), призванный защитить от прослушивания, и авторизация на основе Digest Authentication Protocol (DAP). Ну а до тех пор пока SNMP v.2 не стал повсеместным стандартом, мы будем защищаться тем, что постараемся везде, где только возможно, перестать использовать команду SetRequest. Нам для проведения мониторинга совершенно нет необходимости ее применять. Таким образом, никто не сможет внести изменения в данные, находящиеся внутри оборудования. Еще одним способом борьбы со злоумышленниками должно стать запрещение пропускать пакеты протокола SNMP из Интернета во внутреннюю сеть. Также необходимо жестко ограничить круг IP-адресов менеджеров, которым позволено обращаться к агентам, находящимся внутри нашего оборудования. Если после прочтения этого краткого курса вам все еще непонятны какие-либо моменты теории работы SNMP, значит стоит почитать список часто задаваемых вопросов. Сделать это можно, передав любой поисковой машине запрос snmp faq. В случае если такой помощи окажется недостаточно, стоит обратиться к документации, описывающей протокол. Лучшим источником таких сведений являются RFC 1156, 1213, 1157, 1146, 2571, 2574. Покончив с кратким обзором основ SNMP, перейдем к практическому применению полученных знаний.