Snmp community windows server

Для настройки SNMP-сервера, который поддерживает базу данных MIB и выдает статистику по запросу SNMP-менеджера, используйте команды snmp — server . В команде snmp — server community задается идентификатор (пароль), который используется для аутентификации запросов от SNMP-менеджера и разрешает ему чтение статистики из базы управления SNMP-сервера.

No – форма команды отключает ранее введенное значение идентификатора и отключает получение статистики по SNMP.

Синтаксис snmp-server community [ ro ]

no snmp-server community [string]

string строка, играющая роль идентификатора сообщений для SNMP сервера. Допускаются латинские буквы, цифры, знаки !»#$%&'()*+,-./;:>= ro спецификатор, указывающий на то, что SNMP-сервер разрешает только чтение статистики. Необязательный параметр, по умолчанию разрешается только чтение статистики.

Значение по умолчанию отсутствует

Режимы команды Global configuration

Рекомендации по использованию

Команда snmp — server community задает значение community string, выполняющее роль идентификатора отправителя, в настройках SNMP сервера.

Допускается только одна такая команда, так как можно задать только одно значение community. Повторный запуск этой команды меняет значение строки community.

Если в запросе от SNMP-менеджера строка community отличается от community, прописанной на шлюзе командой snmp — server community , то статистика не отсылается.

No -форма этой команды отключает получение статистики по SNMP.

Отключить получение статистики по SNMP можно и командой no snmp — server .

Отличие данной команды от подобной команды Cisco IOS

· В cs_console разрешается задавать только одно значение community.

· Не допускается спецификатор RW, который поддерживает возможности чтения и записи статистики.

· Не поддерживаются views (фильтрация по отдельным веткам MIB) и ACLs (фильтрация по адресам SNMP managers).

· Не существует никаких взаимосвязей между командой snmp-server community и snmp-server host (в Cisco существует неявное прописывание SNMP-polling community при вводе команды snmp-server host).

Ниже приведен пример задания commutity string:

Router(config)#snmp-server community public

Сайт ARNY.RU

Настройка SNMP — достаточно интересная тема, так как протокол SNMP является мощным инструментом в руках системного администратора и критически необходимым в большой сети. Сетевым устройством будет выступать маршрутизатор CISCO.

Немного теории

Общие понятия

Своими словами, чтобы было понятнее — SNMP состоит из 3 частей:

1. Агента, настроенного на сетевом устройстве;
2. Программы-диспетчера, настроенной на компьютере;
3. Кроме этого на устройстве есть База Управляющей Информации (MIB), где собственно и хранятся нужные данные.

База заполняется автоматически сетевым устройством. Нужно только выбирать оттуда необходимые данные.

Взаимодействие между диспетчером и агентом происходит 2 разными способами:

1. При наступлении определённых заранее событий на устройстве, агент самостоятельно отсылает данные о событии диспетчеру — ловушка SNMP;
2. Диспетчер собирает статистику по заранее заданным параметрам, опрашивая с определённым интервалом агента — запрос SNMP GetRequest.

Это если на устройстве для диспетчера выдано право только на чтение (RO) базы MIB, если же выдано право на запись (RW), то есть дополнительная возможность:

• Диспетчер изменяет заранее заданные параметры в MIB, посылая запрос агенту — запрос SNMP SetRequest

Понятие триггера — если значение параметра, который мониторится со стороны диспетчера, изменяется, то диспетчер выполняет заранее определённое действие (например, посылает сообщение на электронную почту).

Понятие строки сообщества — это пароль, который проверяется при попытке подключения к устройству по SNMP (для версии SNMP 1 и 2). То есть тут нет связки логин/пароль — есть строка сообщества, которая сразу и логин, и пароль.

Последнее, что тут нужно сказать, важный момент: агент и диспетчер используют разные порты. Агент принимает запросы на 161/UDP порту, отправляет информацию диспетчеру на 162/UDP порт.

Версии SNMP

Существует 3 версии SNMP:

• Версия 1 — основной стандарт;
• Версия 2c — доработанная в плане производительности версия 1, не включает в себя безопасность версии 2 и неофициально известна как SNMPv1.5. Доработка заключается в том, что параметры из MIB можно выбирать не по 1, а группой (параметры выбираются последовательно, перебором);
• Версия 3 — доработана только безопасность по отношению к 2c, а именно шифрование и аутентификация.

В плане реализации работы между версиями разница небольшая, но поскольку только версия 3 безопасна, то именно она является актуальной, а версии 1 и 2c хотя всё ещё боевые, но считаются устаревшими. Хотя на практике из-за простоты повсеместно используется SNMP v2c.

База MIB

Структура базы непривычна для понимания, здесь просто нужно запомнить и со временем ничего непривычного не будет. Это структура перевёрнутого дерева, где ствол — 1 (иногда пишут .1), а ветви обозначаются цифрами начиная тоже с 1 и далее. Уровней вложенности может быть много, в ветке новые ветки и так далее. Большинство веток заканчиваются параметрами. Параметры внутри ветки также нумеруются с 1. Путь к параметру состоит из цифр начиная с со ствола и проходит через ведущие к параметру ветки. Цифры разделяются точками. Такой путь называется OID (Object ID). Важно отметить, что это стандарт — нумерация чётко прописана в данном стандарте и одинакова для всех производителей оборудования, но конкретный производитель может добавлять свои уникальные ветви, которые присутствуют только в его оборудовании.

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

Почитать о MIB CISCO. OIDs полезных параметров придётся искать в интернете/документации.

Пример. Путь к стандартной ветке system, где хранятся такие, например, параметры как описание системы (sysDescr) и время прошедшее с запуска системы (sysUpTime) — 1.3.6.1.2.1.1. Путь к параметру sysDescr — 1.3.6.1.2.1.1.1, добавилась ещё 1, так как это первый параметр ветки. Путь к sysUpTime — 1.3.6.1.2.1.1.3 — третий параметр.

Проприетарные ветки производителей всегда располагаются по строго заданному пути iso.org.dod.internet.private.enterprises или в цифровом выражении 1.3.6.1.4.1.

Пример. Для CISCO путь будет 1.3.6.1.4.1.9, а для D-Link 1.3.6.1.4.1.171

Для загрузки MIB CISCO нужно использовать
CISCO IOS MIB Locator.

Подробнее о SNMP можно прочитать в 4 части курса CCNA.

Тестовая среда

Настраиваться будет маршрутизатор CISCO c3725, запущенный из под GNS3 и данные будут поступать в виртуальную машину (VM) Hyper-V. Агент SNMP уже является частью внутренней прошивки (IOS) маршрутизатора, а вот в качестве диспетчера будет использоваться бесплатное ПО — PowerSNMP Free Manager. CISCO рекомендует Free SNMP MIB Browser, не пробовал, не знаю. Соединяются маршрутизатор и VM посредством Облака GNS3. Для этого указываем в свойствах Облака внутренний виртуальный коммутатор, к которому подсоединена сетевая карта VM:

• IP F0/0 маршрутизатора — 192.168.137.2/24
• IP компьютера — 192.168.137.40/24
• IP vEthernet (HUB1) — 192.168.137.1/24

На этом этапе считается, что все предварительные настройки уже выполнены.

SNMPv1/SNMPv2c

Версии настраиваются одинаково, так как версия не указывается при создании SNMP агента (строки сообщества), а лишь при создании ловушек. При создании строки сообщества задаётся лишь или право на чтение (RO), или право на запись (RW).

Пример. В маршрутизаторе настроен пока только интерфейс F0/0, ведущий к облаку (и VM). Введём команду создания агента (строки сообщества):

Создалось 2 группы на чтение — TEST v1 и TEST v2c. Удалим сообщество и группы:

Теперь создадим сообщество с правом на запись:

Снова введём команду:

Опять создалось 2 группы — v1 и 2c, только уже с правом и на чтение, и на запись:

На диспетчере SNMP для работы можно будет выбрать или 1, или 2 версию агента.

Настройка маршрутизатора

Полная настройка версий 1 и 2:

• Команда 1 — создание списка доступа (SNMP_ACL).
• Команда 2 — разрешает взаимодействие было только с указанным компьютером (192.168.137.40).
• Команда 3 — возврат из режима конфигурирования списка доступа (config-std-nacl)# в режим глобальной конфигурации (config)#.
• Команда 4 — создаём Агент SNMP (строку сообщества TEST) только для чтения (ro) — диспетчер сможет считывать значения параметров, но не сможет записывать новые значения и наконец, привязываем список доступа.
• Команда 5 — указываем куда отсылать данные при срабатывании ловушки (192.168.137.40) и версия 1, для версии 2 будет — 2c вместо 1, имя сообщества (TEST).
• Команда 6 — включаем ловушки и определяем какие именно ловушки нас интересуют (snmp).

В параметр snmp входят следующие ловушки:

Просмотреть полный перечень возможных ловушек можно командой:

Их там огромное количество:

Настройка VM

Нажатие кнопки Find покажет отсутствие доступных агентов в сети и срабатывание ловушки authentication:

Происходит так потому, что по умолчанию в программе стоит сообщество public, наш агент был опрошен, но отказал в доступе. Меняем public на TEST, агент опять не добавляется — широковещательный запрос. В свойствах ставим IP 192.168.137.2 и сообщество TEST, после чего агент успешно добавляется.

Ещё раз, строка сообщества (community) — это просто пароль, только называется по-другому.

Теперь погасим интерфейс F0/0 и снова включим:

С небольшой задержкой, ведь связанный интерфейс выключался, прилетают сообщения ловушек, смотрим:

OID отвечающий за состояние F0/0: 1.3.6.1.4.1.9.2.2.1.1.20.1 — первый полезный параметр. Следует обратить на то, что параметр находится в проприетарной ветке оборудования CISCO.

Теперь пробуем добавить этот параметр для мониторинга:

Параметр успешно добавился. Выставляем интервал опроса параметра и триггер: если значение параметра не равно up, то отправить сообщение на e-mail:

Задаём параметры e-mail и гасим F0/0. По истечению таймера состояние параметра изменилось на Timeout error, письмо не пришло — программа не оправляет сообщения по таймауту. Выставил опрос на минимум — 1 секунда, включил/выключил F0/0 ещё раз и вот долгожданное письмо:

SNMPv3

Подробно настройка описана в курсе CCNA R&S 6.0 BRIDGING COURSE. Тут будет посложнее, но и поинтереснее — мозги гарантированно заскрипят 🙂

Настройка маршрутизатора

Удаляем всё что относится к предыдущей настройке кроме списка доступа. Далее, разбил настройку на 2 части, потом будет понятно почему.

Общие шаги

• Шаг 1. Настройте ACL-список (уже сделано);
• Шаг 2. Настройте представление SNMP;
• Шаг 3. Настройте группу SNMP;
• Шаг 4. Настройте пользователя как члена группы SNMP.

Часть 1

Агент SNMPv3 настраивается по-другому нежели SNMPv1/SNMPv2:

Вместо строки сообщества создаётся пользователь с паролем (cisco123) и шифрованием (aes 128, ключ шифрования snmp321) — следует запомнить, что первым указывается пароль пользователя (auth sha cisco123) и вторым ключ шифрования (aes 128 snmp321). Это важно.

Предварительно для пользователя создаётся группа, а ещё ранее вид. Вид определяет с какой частью дерева MIB предстоит работать.

Ещё раз по командам:

• Команда 1 — создание вида (SNMP-RO) для работы с веткой MIB (system).
• Команда 2 — создание вида (SNMP-RO) для работы с веткой MIB (mib-2), mib-2 входит в system — эта команда только для примера, что можно добавлять несколько веток.
• Команда 3 — создание группы (TEST) версии 3 (v3) с аутентификацией и шифрованием (priv) только для чтения (read) для вида (SNMP-RO) и списком доступа (SNMP_ACL).
• Команда 4 — создание пользователя (ADMIN) в группе (TEST) версии 3 (v3) аутентификацией по алгоритму (sha), паролем (cisco123) и шифрованием (priv) по алгоритму (aes 128) и ключом шифрования (snmp321).
• Команда 5 — включаем ловушки и определение типов ловушек (snmp).

Тут надо вспомнить 3 уровня безопасности SNMPv3:

• auth — group using the authNoPriv Security Level (MD5/SHA-1 аутентификация, без шифрования данных);
• noauth — group using the noAuthNoPriv Security Level (без аутентификации и шифрования);
• priv — group using SNMPv3 authPriv security level (MD5/SHA-1 аутентификация, шифрование данных DES/3DES/AES)

Для использования authPriv требуется прошивка с поддержкой криптографии (k9).

Теперь проверим что получилось:

По соображениям безопасности пользователи SNMP не показываются в конфигурации.

Часть 2

Подробная настройка получателя ловушек SNMPv3:

• Команда 6 — указываем хост куда отсылать данные при срабатывании ловушки (192.168.137.40) версии 3, без шифрования и аутентификации (noauth) для пользователя (ADMIN).

Проверяем, пользователь как был так и остался, а вот в группах SNMP и в конфигурации интересные изменения:

Появилась новая группа TEST, хотя команды на её создание не было.

И вот такая занятная строка в конфиге:

Понять что это такое можно выполнив команду:

Помимо группы для ловушек были автоматически созданы дополнительные виды: //blog.ine.com/2008/07/19/snmpv3-tutorial/

Здесь чётко видно, что работа агента с запросами и работа агента с ловушками — 2 абсолютно разных процесса.

Настройка VM

Для начала погасим и включим интерфейс S0/0 (один из дополнительных интерфейсов, интерфейсы по умолчанию на маршрутизаторе выключены), прилетают сообщения ловушек, диспетчер определяет ловушки как версию 2+:

Как видно из рисунка у пользователя ADMIN для ловушек нет шифрования и пароля.

Дальше добавляем агента с указанием версии и атрибутов:

И пробуем добавить параметр 1.3.6.1.4.1.9.2.2.1.1.20.2 — состояние интерфейса S0/0 для мониторинга.

И то же самое для F0/0 — 1.3.6.1.4.1.9.2.2.1.1.20.1. В чем дело? А дело в том, что параметр находится в ветке private, а эту ветку мы не добавляли в вид для работы, добавим:

Состояние интерфейса отображается корректно. С агентом версии 3 всё.

Настройка ловушек v3 с паролем и шифрованием

Удаляем получателя ловушек :

Проверяем пользователя, группы, виды, конфигурацию, если что-то удалилось — восстанавливаем (на самом деле удалиться ничего не должно, но когда настраивал, то первые раза 3 каждый раз получалось по-разному). Теперь:

И заново всё проверяем. Автоматически создались виды, пользователь на месте с теми же параметрами, нет новой группы TEST, так как параметры аутентификации и шифрования совпадают с созданной ранее, исходной группой TEST. В конфигурации параметр для автоматически созданных видов дописался к строке группы:

Если теперь погасить/поднять интерфейс, то ловушки не приходят диспетчеру.

Пробуем добавить пользователя для ловушек версии 3, в программе есть такая возможность. Для этого нужно ввести помимо прочего Engine ID. Его можно найти просмотрев пользователя SNMP либо выполнив команду:

Программа ожидает ввода Engine ID в виде 80-00-00-09-03-00-C2-01-25-D0-00-00, автоматического преобразования нет. Вносим реквизиты пользователя, снова гасим/поднимаем интерфейс S0/0, ловушки приходят:

Открываем сообщение ловушки и видим, что пароль и шифрование задействованы:

Установка Net-SNMP

А как же быть со средой Linux? Для Centos:

Далее, если выполнить:

Конфигурацию демона SNMP после установки нужно отредактировать. Если посмотреть файл /etc/ snmp / snmpd . conf, то в нём по умолчанию доступны ветви:

Соответственно запросы не подпадающие под эти ветви будут возвращаться с ошибкой как выше. Комментируем и оставляем:

Затем рестартуем сервис:

Самые основные и нужные команды пакета:

• snmpget — SNMP GET запрос;
• snmpwalk — получает часть дерева значений с помощью SNMP GetNext запросов;
• snmpset — SNMP SET запрос.

На этом рассмотрение базовой работы SNMP завершено.

Если тема заинтересовала, то предлагаю выполнить лабу по SNMP.