snmpapp conf что за файл

990x.top

Простой компьютерный блог для души)

snmpapp.conf — что за файл?

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

Данный файл может быть расположен по такому пути:

В интернете нет информации о предназначении файла. Однако важно понимать — название содержит слово SNMP, термин является стандартным протоколом управления устройствами в IP-сетях, основанным на использовании технологий TCP/UDP. Управлять можно такими устройствами как роутеры, серверы, рабочие станции, принтеры, модемы и подобные девайсы.

Какой можно сделать вывод? Возможно файл snmpapp.conf принадлежит софту для управления сетевым устройством. Возможно к компьютеру подключено сетевое оборудование, например роутер, маршрутизатор. Также думаю файл может появиться просто при установке специального софта для управления устройством по сети.

Также может на компьютере установлена программа для запуска сервера, которая также может создавать файл snmpapp.conf.

Вообще файл snmpapp.conf, точнее название состоит из следующих терминов:

Например в операционке Windows существует служба SNMP Service:

Данная служба в теории тоже может создавать папку. Но скорее всего директория от какого-то установленного софта, связанного с сетевой направленностью.

Источник

Протокол управления SNMP

Simple Network Management Protocol (SNMP) — это протокол прикладного уровня, он делает возможным обмен данными между сетевыми устройствами.

SNMP — это не продукт, а свод правил. Он определен Советом по архитектуре Интернета и является частью пакета TCP/IP. SNMP управляется и поддерживается Инженерной группой Интернета (IETF).

Протокол позволяет системному администратору проводить мониторинг, контролировать производительность сети и изменять конфигурацию подключенных устройств. SNMP используют в сетях любого размера: чем крупнее сеть, тем лучше раскрываются преимущества протокола. Он позволяет просматривать, контролировать и управлять узлами через единый интерфейс с функциями пакетных команд и автоматического оповещения.

Таким образом, SNMP избавляет администратора от необходимости ввода команд вручную. Всего были разработаны и развернуты три версии. Все они используются до сих пор, а самой распространенной стала вторая — SNMPv2с.

Архитектура SNMP

Компоненты, составляющие архитектуру SNMP:

Сетевая станция управления — NMS

Network Management Station (NMS) удаленно мониторит управляемые устройства, получает данные, собранные мастер-агентами, отслеживает производительность и представляет полученную информацию в графическом виде. Встроенный менеджер NMS отвечает за связь с агентами.

Агенты

Мастер-агент

Это программа, связывающая сетевых менеджеров и субагентов. Мастер-агент анализирует запросы сетевого менеджера NMS и пересылает их субагентам, собирает и формирует ответы субагентов и отправляет их менеджеру. Мастер-агент уведомляет менеджера, если запрос некорректен или запрошенная информация недоступна.

Субагент

Это программа, поставляемая вендором вместе с сетевым устройством. Субагент пересылает собранную информацию мастер-агенту. У каждого управляемого компонента есть соответствующий субагент.

Управляемый компонент

Это подключенное к сети устройство или программное обеспечение с встроенным субагентом. К таким устройствам относятся не только маршрутизаторы, коммутаторы и серверы, но и IP-видеокамеры, МФУ и IP-телефоны. К софту с субагентами также относятся антивирусные программы, системы резервного копирования, ПО для систем ИБП.

База управляющей информации — MIB

MIB — это иерархическая база данных со сведениями об устройстве. У каждого типа устройства своя MIB-таблица: у принтера в ней содержится информация о состоянии картриджей, а у коммутатора — данные о трафике. Благодаря MIB менеджер знает, какую информацию он может запросить у агента устройства.

Идентификатор объекта — OID

Каждый объект в MIB имеет свой уникальный ID — OID, который представлен в числовом формате и имеет иерархическую структуру. OID — это числовой эквивалент пути к файлу. Он присваивает значения каждой таблице в MIB, каждому столбцу в таблице и каждому значению в столбце.

Например, OID 1.3.6.1.4.868.2.4.1.1.1.3.3562.3. означает iso.org.dod.internet.private.transition.products.chassis.card.slotCps.
cpsSlotSummary.cpsModuleTable.cpsModuleEntry.cpsModuleModel.3562.3.

Используя первые 6 цифр этого OID, можно пройти по дереву на схеме.

Часть значений в OID содержит данные о производителе устройства, что позволяет быстро получить определенную информацию о девайсе.

Древовидная иерархия MIB и OID в SNMP выглядит несколько запутанной, но у нее есть свои преимущества. Это простая и гибкая система организации сетевых устройств, она работает вне зависимости от размера сети.

Теория и логика работы протокола SNMP

Предназначение

Изначально протокол должен был предоставить системным администраторам инструмент для управления интернетом. Однако, гибкая архитектура SNMP позволила проводить мониторинг всех сетевых устройств и управлять ими с одной консоли. Это и стало причиной распространения SNMP.

Менеджеры и агенты обмениваются данными через протокол UDP. Вместо него также может использоваться TCP, IPX или протокол MAC-уровня. Обмен данными основан на Protocol Data Unit (PDU).

Всего в SNMP семь PDU:

TRAP, GETBULK — есть только во второй и третьей версиях протокола SNMP.

Схема PDU

Применение

Статусы ошибок и их описание.

Сетевые порты SNMP

По умолчанию SNMP использует UDP-порты 161 и 162. Менеджер отправляет запросы на порт 161 агента. С порта 161 агент отправляет ответ менеджеру. При отправке запроса менеджер добавляет к нему ID, а агент вставляет этот ID в ответ, чтобы менеджер мог связать свой запрос с ответом агента.

Ловушки агент высылает на порт 162 менеджера. Если используется DLTS или TLS, то агент высылает сообщения на порт 10162, а менеджер — на порт 10161. Администратор может изменить порты SNMP, используемые по умолчанию, на любые другие.

Ловушки

Ловушка (Trap) — это важнейший способ коммуникации в SNMP. Менеджер отвечает за большое количество устройств, на многих из них может быть несколько управляемых компонентов. Агент отправляет ловушку по своей инициативе, когда необходимо сообщить менеджеру о событии. Например, ловушка может выслать отчет о перегреве машины или о том, что в тонере закончились чернила.

Получив уведомление, менеджер выбирает нужное действие, например, опрашивает агента, чтобы получить полное представление о том, что произошло. Перечень уведомлений, которые посылает ловушка:

В SNMP есть два типа ловушек: Trap и Inform. Отличия между ними в том, что после получения Inform менеджер подтверждает получение ловушки. В противном случае агент будет отправлять Inform, пока не получит подтверждения. А вот после получения Trap менеджер не отправляет подтверждение. Если сообщение не дошло до менеджера, агент об этом не узнает.

Версии протокола SNMP

SNMPv1

Первая версия протокола создана в 80-х годах XX века. Легка в настройке — требуется только строка community. Версия широко используется до сих пор.

SNMPv2с

Вторая версия протокола SNMP появилась в 1993 году. Разработчики добавили в нее новый запрос GetBulk и ловушку Inform, а также усовершенствовали безопасность.

У этой версии есть два способа коммуницировать с устройствами, поддерживающими SNMPv1: двуязычная система сетевого управления и прокси-агенты. Прокси-агенты выполняют роль мастер-агентов, а в двуязычной системе управления менеджер определяет, какую версию SNMP поддерживает агент, и связывается с ним через SNMPv1 или SNMPv2c.

SNMPv3

Третья версия вышла в 1998 году. Разработчики добавили в SNMP криптографическую защиту, облегчили удаленную настройку и администрирование объектов. Этого удалось достичь за счет определения набора стандартизованных объектов управления, называемых объектами MIB удаленного сетевого мониторинга, — RMON MIB.

Безопасность

Изначально безопасность не была первоочередной задачей разработчиков. Первая версия SNMP была создана для удаленного администрирования во времена, когда угроза несанкционированного доступа была минимальной. Поэтому SNMPv1 слабо защищена от взлома, и злоумышленники могли использовать ее для проникновения в сетевую инфраструктуру.

В работе над второй версией протокола разработчики предложили несколько вариантов решения. Распространение получил вариант SNMPv2c — не самый надежный, но простой в использовании.

Основная проблема с безопасностью в том, что почти все оборудование поддерживает версию SNMPv1. И только часть работает с версиями SNMPv2с и SNMPv3. Именно поэтому самой популярной стала SNMPv2с. Она способна работать с устройствами, которые поддерживают первую или вторую версии SNMP.

Модели безопасности протоколов SNMP по версиям

Community-based Security — модель безопасности на основе строки сообщества. Фактически это идентификатор пользователя или пароль, который отправляется вместе с запросом. Если строка сообщества неверна, агент игнорирует запрос.

Строка сообщества зависит от вендора устройства. Часто вендоры по умолчанию выбирают «PUBLIC» в качестве пароля, поэтому первым делом на новых устройствах нужно изменить строку сообщества для защиты сети от злоумышленников.

Строки сообщества бывают трех видов:

Строка сообщества широко используется из-за своей простоты и наличия внешних систем безопасности.

Party-based Security Model — модель на основе так называемых «сторон». Для коммуникации между менеджером и агентов выбирается логическая сущность, называемая стороной. Она устанавливает протоколы аутентификации и шифрования, а отправитель и получатель соглашаются со способом шифрования и дешифровки данных. Сложность использования модели помешала ее распространению среди пользователей.

User-based Security Model — модель безопасности на основе пользователей. Уровни аутентификации, безопасности и конфиденциальности протоколов и ключей настраиваются у агента и менеджера.

Лучше всего безопасность проработана в третьей версии SNMP за счет USM и VACM. Упрощенно VACM (View-based Access Control Model) можно описать как модель с разными уровнями доступа для групп менеджеров. При получении запроса агент решает, разрешен ли определенной группе менеджеров доступ к чтению, записи и получению уведомлений.

Типичные проблемы безопасности

Если системный администратор не использует SNMP, то он должен отключить его на устройствах.

Практическое применение протокола

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

Возможности SNMP-протокола

Благодаря протоколу администратор может:

При помощи стороннего ПО можно также:

SNMP и переход с IPv4 на IPv6

Протокол по умолчанию должен работать с IPv4 или IPv6. На практике IPv6 создает определенные проблемы для работы SNMP. Эти проблемы связаны объектами MIB, содержащими сетевые адреса. OID в MIB хранят информацию для нескольких уровней TCP/IP, и различия между IPv4 и IPv6 будут отражены в OID.

Отсутствие поддержки IPv6 в существующих объектах MIB проявляется двумя способами:

Эти проблемы решаются также двумя способами:

Инсталляция

Настройка SNMP в Windows

Она подробно описана в документации Microsoft.

Настройка данных агента SNMP

Пуск → Панель управления → Администрирование → Управление компьютером.

Настройка сообщества и ловушек SNMP

Пуск → Панель управления → Администрирование → Управление компьютером.

Настройка безопасности SNMP

Пуск → Панель управления → Администрирование → Управление компьютером.

Настройка SNMP в Linux

Настройка SNMP в CentOS 7

Сначала нужно установить последние обновления при помощи yum/dnf:

затем установить SNMP:

и создать копию конфигурационного файла:

теперь нужно отредактировать настройки агента

Локацию и email лучше указать реальные.

Пора добавить сервис в автозагрузку и перезапустить его:

Как проверить, что сервис запущен:

Опрос агента с помощью утилиты snmpwalk:

Опрос сервера локально командой:

Настройка SNMP в Debian 10

Сначала нужно установить демона, клиента и файлы:

После установки переходим к настройке SNMP в Debian.

Файлом настройки SNMP-агента по умолчанию является /etc/snmp/snmpd.conf. Агент SNMP может быть запущен с настройками по умолчанию. Однако для включения удаленного мониторинга нужно сделать несколько изменений. Для этого создайте резервную копию файла:

Теперь нужно изменить директиву agentAdress. Ее текущие настройки разрешают доступ только с локального компьютера. Для включения удаленного мониторинга необходимо определить IP-адрес интерфейса:

Для настройки аутентификации:

rocommunity предоставляет доступ только на чтение, а rwcommunity дает доступ к чтению/записи. В Access Control section нужно поместить строку

rocommunity S3CUrE 192.168.43.100

Кроме того, можно включить запрос с локального хоста rocommunity S3CUrE localhost:

Затем нужно перезапустить SNMP:

Чтобы добавить сервис в автозагрузку, введите:

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

Созданный 30 лет назад SNMP продолжает работать, потому что он обладает характеристиками, которых нет ни у одной из его аналогов. Он простой в использовании, бесплатный и поддерживается практически всеми вендорами.

Источник

Блог о системном администрировании. Статьи о Linux, Windows, СХД NetApp и виртуализации.

Введение в протокол SNMP

Архитектура протокола SNMP

Сеть, использующая SNMP для управления содержит три основных компонента:

Давайте попытаемся рассмотреть обозначенные компоненты.

SNMP менеджер и SNMP агент

Итак, как я уже сказал, SNMP менеджер отправляет запросы агенту на порт udp/161 (если конфигурационно в агенте не задан другой порт) с произвольного порта из эфемерного диапазона. В запросе SNMP менеджера указывается порт и адрес источника (о полной структуре пакета SNMP опишу ниже). Далее агент принимает пакет и обрабатывает (если выполняются нижеописанные условия). В процессе обработки, формируется ответ, который отправляется на порт взятый из исходного запроса. Ответ отправляется с udp/161 порта. Можно сказать, что SNMP агент таким образом предоставляет доступ SNMP менеджеру к данным, хранящимся в базе MIB. При этом, в момент отправки, SNMP менеджер вставляет в PDU некий ID (RequestID), а агент в ответном PDU вставляет данный ID без изменения, для того чтобы менеджер не путал пакеты от разных агентов. SNMP агент может быть настроен на посылку Trap уведомлений, которую он выполняет с эфимерного порта на udp/162 порт SNMP менеджера.

SNMP PDU (или сообщения SNMP протокола)

Как видно, в зависимости от версии протокола, набор команд разный (например InformRequest и GetBulkRequest полноценно появился только во второй версии SNMP). Компонент SNMP MIB рассмотрим ниже.

Структура PDU

Рассмотрение структуры PDU не обязательно, но это поможет более глубоко понять логику работы SNMP. Все PDU (кроме Trap) состоят из определенного набора полей, в которые записывается необходимая информация:

Что данные поля обозначают:

При этом, содержимое Trap PDU содержит некоторые дополнительные поля (вместо заголовка запроса):

В новых версиях SNMP содержимое Trap PDU может незначительно меняться, но в целом, смысл тот же.

Логика работы протокола SNMP

Рассмотрев основные единицы обмена SNMP, можно обсудить логику работы SNMP при выполнении данных запросов\ответов. Некоторые общие особенности работы протокола SNMP, которые стоит учитывать:

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

(взято частично отсюда http://logic-bratsk.ru/brlug/snmp_my/):

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

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

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

Логика работы SNMP в картинках

взято отсюда (http://www.manageengine.com/network-monitoring/what-is-snmp.html)

Обмен PDU GET⁄ GET NEXT⁄ GET BULK⁄ SET

Обмен PDU Trap или notification

SNMP MIB

Давайте попробуем понять MIB. Это совсем не люди в черном ) Как я уже сказал, это Management information base, то есть база набор управляющей информации. Каждый сетевой узел, имеющий на своем борту SNMP агента (читай – поддерживающий протокол SNMP) предоставляет свой набор данных, тот, который в него «вложили» программисты\разработчики при проектировании железки\программы. То есть в каждом сетевом устройстве с поддержкой SNMP имеется своя база MIB со строго обозначенным набором переменных. Каждая база MIB имеет древовидную структуру, каждый объект в которой характеризуется уникальным идентификатором объекта (Object Identifier, OID).

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

Кроме того, существует всемирное дерево регистрации стандартов ISO, содержащее базовую структура дерева MIB (точнее этих структур существует несколько, они формировались вместе с совершенствованием версий SNMP). Составное числовое имя объекта SNMP MIB соответствует полному имени этого объекта в дереве регистрации объектов стандартизации ISO. За данную древовидную структуру отвечает и контролирует организация IANA (и некоторые другие).

Давайте рассмотрим типичное дерево MIB на рисунке:

Итак, структура OID в дереве MIB:

В вершине дерева – корень (точка), от которого ответвляются ветви. Во многих схемах приведены некоторые ветви верхнего уровня (например itu-t, iso\itu-t и другие ниже), но информации о их назначении я не нашел… Посему, нас интересует вертка iso (0), которая хранит в себе следующие значения до internet (1): iso.org.dod.internet, что соответствует числовому ID .1.3.6.1.

Данный раздел (iso.org.dod.internet) разветвляется на подразделы, которые в большинстве своем контролируются IANA и состоят (согласно RFC1155) из:

Далее, необходимо рассмотреть отдельным пунктом ветку 1.3.6.1.2 (iso.org.dod.internet.mgmt), состоящую из подветки mib-2 (1), а так же reserved(0), pib(2), http(9) и некоторых других. Стоит отметить, что в зависимости от версии протокола (SNMPv1 vs SNMPv2) на месте данной ветки могут быть «прилинкованы» разные поддеревья в целом имеющие примерно одинаковую структуру и одинаковые идентификаторы, но в более новой версии протокола – поддерево более расширено. (наверно, в этом и состоит несовместимость версий протокола…)

Итак iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1): данная ветка является базовой для большинства сетевых устройств и содержится практически в любом устройстве. Ветка поделена на базовые группы (которых на текущий момент более 170), характерные для любого сетевого оборудования. Давайте рассмотрим наиболее применяемые:

Отдельного абзаца так же достоин подраздел iso.org.dod.internet.private (1.3.6.1.4), содержащий в себе поддерево enterprise (1). Данная ветвь контролируется IANA и содержит в себе более 40000 поддеревьев (ознакомьтесь с актуальным списком http://www.iana.org/assignments/enterprise-numbers ). В данной ветке регистрируют свои поддеревья – производители оборудования. Вот пример ответвления:

Ниже структура аналогичная всем остальным разделам – древовидна. В каждом поддереве соответствующий производитель оборудования в праве сам регистрировать свои ветвления и переменные.

Безопасность протокола SNMP (или версии протокола SNMP)

В одной из вторых версий 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х версий (менеджер для каждого хоста должен помнить версию агента).

Принципы настройки протокола SNMP

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

В большинстве реализаций менеджеров SNMP (в данном контексте, наверно, лучше сказать – систем управления сетью Network Management System) предоставлены некие возможности механизма автоматического обнаружения SNMP агентов. В большинстве случаев это сводится к выполнению по расписанию некоторого скрипта, запускаемого в определенный промежуток времени и опрашивающего заданный диапазон IP адресов.

SNMP в Linux

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

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

SNMP в Debian

Политика лицензирования Debian определяет базы MIB, как несвободное ПО, поэтому они не расположены в свободных репозитоиях, а размещены в non-free репозиториях. Для того чтобы базы корректно установились, необходимо данный репозиторий прописать в /etc/apt/sources.list, например:

и установить пакет snmp-mibs-downloader. (в процессе установки данный пакет попытается получить mib-базы из интернета). Так, же, необходимо в /etc/snmp/snmp.conf закомментировать строку:

Маленький итог о SNMP

Итак, в статье я постарался как можно понятней рассказать о SNMP, чтобы применять эту технологию в сетях мониторинга. Подводя краткий итог протокол SNMP базируется на нескольких основных принципах:

Ссылки SNMP

Источники загрузки MIB файлов (каталоги MIB):

Источник