is_volatile   0

 check_period   24x7

 check_command check_snmp_oid!.1.3.6.1.4.1.2021.4.11.0!InK12345!20000:10000!9999:0!kbytes!2c

 }

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

Также неплохо было бы следить за сетевыми интерфейсами с помощью ветки .iso.org.dod.internet.mgmt.mib-2. interfaces.ifTable.ifEntry. Думаю, что примеров, приведенных в статье, достаточно, чтобы сделать это самостоятельно.

Разобравшись с проверками сервисов, работающих через snmp 2c, давайте посмотрим, как выполнить все то же самое с помощью третьей версии протокола. Зачем нам это нужно? Все очень просто: с точки зрения безопасности snmp 2с существенно лучше, чем версия 1, но, несмотря на это, в ней все же есть недостатки. Дело в том, что при ее использовании строки сообществ передаются по сети в открытом виде. Думаю, это не то, что нам хотелось бы получить. Изумленный читатель может сказать: «Давайте совсем откажемся от использования 2с». К сожалению, такой идеалистический подход не всегда возможно воплотить в жизнь. Иногда приходится использовать именно 2с, потому что не во всем имеющемся оборудовании есть поддержка третьей версии. К тому же, настройка snmpd для работы с третьей версией snmp – дело весьма нетривиальное. Ниже я расскажу как этого добиться «малой кровью».

Итак, приступим. В основе идеологии безопасности для третьей версии лежит понятие модуля безопасности пользователей USM (User-based Security Module). Он отвечает за хранение списка пользователей и их атрибутов. Соответственно каждый пользователь обозначается уникальным именем в терминах snmp, оно называется securityName. К нему привязываются протокол аутентификации и ключ аутентификации, соответственно, authProtocol и authKey. Вдобавок к этому существует протокол шифрования privProtocol и ключ шифрования privKey. Стоит отметить, что authKey и privKey генерируются на основе пароля, переданного пользователем. Пароль должен содержать не менее восьми символов.

Стандарт snmp версии 3 описывает три вида пакетов. Первый не подписывается и не шифруется. Второй: отправляющая сторона подписывает пакет ключем authKey с помощью протокола authProtocol. В качестве протокола генерации подписи на данный момент могут выступать алгоритмы MD5 или SHA. Третий: подписывает и плюс к этому данные пакета могут шифроваться с помощью протокола privProtocol и ключа privKey. В качестве протокола шифрования пока можно использовать только DES.

Ознакомиться подробнее с идеями, лежащими в основе USM, можно в RFC 2574.

Одной из самых странных идей, с которой приходится сталкиваться, является способ управлением пользователями, применяемый для третьей версии протокола. Для этого существует утилита snmpusm, но создать с ее помощью пользователя с нуля невозможно. Она позволяет лишь клонировать настройки существующего пользователя в атрибуты вновь создаваемого. Налицо проблема курицы и яйца. Нужно создать первого пользователя, но утилита для управления пользователями делать это не умеет.

Несколько раз перечитав man snmpusm, понимаем, что созданием легендарного первопользователя должен заниматься демон snmpd. Ничего не скажешь, весьма сильный ход и главное – какой нечеловеческой логикой это продиктовано.

Итак, нам нужно внести в snmp такие строки:

rwuser initial

rwuser nagios

rouser nagios

createUser initial MD5 t2inKES10er DES

Или их аналог с расширенным описанием VACM:

group MyRWGroup usm  nagios

group MyROGroup usm  nagios

group MyRWGroup usm  initial