snmp community string что это
Разное
Для успешного администрирования сети необходимо знать состояние каждого ее элемента с возможностью изменять параметры его функционирования. Обычно сеть состоит из устройств различных производителей и управлять ею было бы нелегкой задачей если бы каждое из сетевых устройств понимало только свою систему команд. Поэтому возникла необходимость в создании единого языка управления сетевыми ресурсами, который бы понимали все устройства, и который, в силу этого, использовался бы всеми пакетами управления сетью для взаимодействия с конкретными устройствами.
Для того, чтобы проконтролировать работу некоторого устройства сети, необходимо просто получить доступ к его MIB, которая постоянно обновляется самим устройством, и проанализировать значения некоторых переменных.
Важной особенностью протокола SNMP является то, что в нем не содержатся конкретные команды управления устройством. Вместо определения всего возможного спектра таких команд, безусловно загромоздившего бы сам протокол, который считается все-таки простым, определены переменные MIB, переключение которых воспринимается устройством как указание выполнить некоторую команду. Таким образом удается сохранить простоту протокола, но вместе с этим сделать его довольно мощным средством, дающим возможность стандартным образом задавать наборы команд управления сетевыми устройствами. Задача обеспечения выполнения команд состоит, таким образом, в регистрации специальных переменных MIB и реакции устройства на их изменения.
Как происходит адресация в MIB к некоторой ее переменной? По своей структуре MIB представляет из себя дерево, изображенное на рисунке 1.
Каждому элементу соответствует численный и символьный идентификатор. В имя переменной включается полный путь до нее от корневого элемента root. Например, время работы устройства с момента перезагрузки хранится в переменной, находящейся в разделе system под номером 3 и называется sysUpTime. Соответственно, имя переменной будет включать весь путь: iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysUpTime(3); или на языке чисел: 1.3.6.1.2.1.1.3. Следует заметить, что при этом узлы дерева разделяются точками. Существует стандартная ветвь MIB, относящаяся к разделу управления mgmt, которую обычно поддерживают все сетевые устройства.
Наряду с этим каждый производитель или организация может разработать свой собственный набор переменных и «подвесить» их к дереву MIB. Однако, это делается только в строго определенном ее месте. Если организация разрабатывает свою базу MIB, то на стадии экспериментов переменные могут помещаться в раздел experimental. Однако для официальной регистрации структуры данных некоторой организации ей необходимо получить собственный номер в разделе private-enterprises. Все переменные, адресуемые вниз по ветви данной организации, относятся к продуктам только данного производителя.
Как уже было сказано, каждое сетевое устройство содержит в себе информацию, необходимую для управления им. Эта информация некоторым образом размещена в регистрах устройства. Как же обеспечивается доступ к этой информации некоторой сетевой рабочей станции, выполняющей задачу управления сетью? Для обработки запросов управляющей станции, приходящих в виде SNMP пакетов, служит специальный модуль, называемый Агентом Управления. Агент принимает SNMP пакеты и выполняет соответствующие им действия, т.е. посылает значение запрашиваемой переменной, устанавливает значение переменных, выполняет периодическое обновление информации MIB, выполняет в ответ на установку соответствующих переменных некоторые операции. В роли Управляющей Станции может выступать рабочая станция администратора сети, если на ней запустить какой-либо пакет управления, поддерживающий протокол SNMP. Он позволяет администратору получать конкретную информацию о какой либо стороне функционирования элементов сети, например на уровне карты Ethernet, либо протокола EGP. Примерами таких программ можно назвать Sun NetManager фирмы Sun Microsystems, ориентированный на операционную систему Solaris, и пакет SNMPc фирмы Castle Rock Computing, разработанный для системы Windows. Оба пакета позволяют строить карту сети и работать непосредственно с MIB какого-либо ее узла. Имея подобное мощное средство, администратору сети достаточно открыть документацию по MIB конкретного устройства, например маршрутизатора cisco, и изучить возможности управления, заложенные в нее разработчиками. Так, например, чтобы управлять маршрутизатором cisco, можно войти на него (сделать login пользователем root) и получить on-line доступ к его командам управления. А можно сконфигурировать на данном маршрутизаторе SNMP агента и выполнять все те же команды и получать те же результаты путем работы с переменными его MIB. Как пример такой операции можно просто перегрузить маршрутизатор путем изменения одной переменной его MIB. При этом существуют отдельные команды для загрузки системы из flash-памяти, NVRAM, или TFTP файла.
При помощи SNMP можно выполнять различные тесты функциональных возможностей сетевых устройств, определенные опять же на самих устройствах. Это бывает полезно, поскольку просто наблюдение статистики зачастую не дает полной картины происходящего. Так, например, для раздела, относящегося к интерфейсам Ethernet, определен тест TDR (Time-domain reflectometry), позволяющий определять приблизительное расстояние до повреждения в коаксиальном кабеле. Для того, чтобы запустить TDR тест необходимо установить значение переменной ifExtnsTestTypе (1.3.6.1.2.1.12.2.1.4), содержащей тип выполняемого теста, так, чтобы она содержала идентификатор теста TDR в MIB: 1.3.6.1.2.1.10.7.6.1. Результатом теста будет, во-первых, значение переменной ifExtnsTestResult (1.3.6.1.2.1.12.2.1.5), характеризующей исход теста:
На основании вышеизложенного остается сделать вывод о том, что администратор сети может найти в лице протокола SNMP хорошего помощника, имея полный доступ к описаниям переменных MIB различных сетевых устройств и мощный пакет, который бы облегчал работу с громоздкими именами переменных в SNMP.
Функции управления коммутаторами
Протокол SNMP
Компоненты SNMP
Сеть, управляемая по протоколу SNMP, основывается на архитектуре «клиент/сервер» и состоит из трех основных компонентов: менеджера SNMP, агента SNMP, базы управляющей информации.
Менеджер SNMP (SNMP Manager) — это программное обеспечение, установленное на рабочей станции управления, наблюдающее за сетевыми устройствами и управляющее ими.
Агент SNMP (SNMP Agent) — это программный модуль для управления сетью, который находится на управляемом сетевом устройстве (маршрутизаторе, коммутаторе, точке доступа, Интернет-шлюзе, принтере и т.д.). Агент обслуживает базу управляющей информации и отвечает на запросы менеджера SNMP.
База управляющей информации (Management Information Base, MIB ) — это совокупность иерархически организованной информации, доступ к которой осуществляется посредством протокола управления сетью.
Менеджер взаимодействует с агентами при помощи протокола SNMP с целью обмена управляющей информацией. В основном это взаимодействие реализуется в виде периодического опроса менеджером множества агентов, которые предоставляют доступ к информации.
База управляющей информации SNMP
Базы управляющей информации описывают структуру управляющей информации устройств и состоят из управляемых объектов (переменных).
Типы сообщений протокола SNMP
Сообщение Trap (ловушка) используется агентом SNMP для асинхронного сообщения менеджеру SNMP о событии, происходящем на управляемом сетевом устройстве. События могут быть серьезные, например перезагрузка устройства, или менее серьезные, например изменение состояния порта.
Безопасность SNMP
На коммутаторе SNMP можно создавать группы со списками пользователей (менеджеров SNMP) и настраивать для них общий набор привилегий. Помимо этого, для каждой группы может быть установлена версия используемого ею протокола SNMP. Таким образом, можно создать группу менеджеров SNMP, которым позволено просматривать информацию с правом «read only» или получать ловушки ( trap ), используя SNMP v.1, в то время как другой группе можно настроить наивысший уровень привилегий с правами «read/write» и возможность использования протокола SNMP v.3.
При использовании протокола SNMP v.3 отдельным пользователям или группам менеджеров SNMP может быть разрешено или запрещено выполнять определенные функции SNMP-управления. Помимо этого, в SNMP v.3 доступен дополнительный уровень безопасности, при котором 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):
What is an SNMP Community String?
If your network is spread out across a wide area with many unmanned sites, you need an SNMP monitoring system. It’s virtually impossible for you and your team to watch all of your gear without some form of automated monitoring.
SNMP monitoring is distinct from other forms of monitoring because it uses the Simple Network Management Protocol(SNMP)l. SNMP messages are, most commonly, created by an SNMP agent (some kind of gear at your site). And they are received by a central SNMP manager (a software program, ideally running on its own dedicated hardware platform).
This protocol is one of the most popular in the remote monitoring word today because it can bring you many benefits. And there really aren’t any significant disadvantages to be wary of.
Of course, using this popular protocol isn’t without some threats. Anytime you use something that is common, there will be a larger population of people who are familiar with it.
Some of these people may have ill intent. They might use the common knowledge of SNMP to break into your system. There are strong cyber terrorism issues here.
For many years, the lack of security in SNMP was viewed by many as its Achilles’ heel. For all its wonderful business benefits, the threat of cyber terrorists and virtual vandals loomed large.
However, SNMP monitoring is no longer without any defenses. SNMP community string is a common security feature in SNMP devices. And there are also some other SNMP security best practices that you should know about.
What is SNMP Community String?
SNMP community string is an SNMP security password that devices need to talk to each other. It’s similar to a user id or password that allow you to access your equipment’s data.
Your SNMP monitoring device should send the community string along with SNMP requests. If the community string is correct, then your device will answer with the requested information. However, if the community string is incorrect, your device will simply disregard the request and will not respond.
Types of SNMP Community Strings
There are three different kinds of community string:
Is an SNMP String Really Secure?
Although the community string does offer some security, it’s only used by devices that support the versions SNMPv1 and SNMPv2.
SNMPv1 was the first version of SNMP. It uses community strings to restrict access. This version uses read-write and read-only community strings, but the data transmitted is unencrypted. Which means it can be easily attacked and exploited.
The read-only community string allows access to management information base (MIB) objects on a read-only basis. MIB objects are the data exchanged between an SNMP agent and the SNMP manager.
The read-write community string will allow you to access and interact with these MIB objects. This means that you can edit settings of your devices by logging into the manager.
Other advantages of SNMPv2c include:
Not all devices are SNMPv2c compliant, so your SNMP manager should be downward compatible with SNMPv1 devices. You can also use SNMPv3 mediation devices to ensure compatibility.
Another point to remember is that SNMPv1 and v2c equipment have their default community string set to «public.» So, you’ll have to change all of your community strings to customized values during the device setup.
Now, SNMPv3 is the newest version of the SNMP protocol. Its primary feature is enhanced security. It allows you to fully encrypt messages, so they can’t be accessed or intercepted by unintended people.
The «EngineID» Identifier in SNMPv3 uniquely identifies each SNMP entity. Conflicts can occur if two SNMP entities have duplicate EngineIDs. The EngineID is used to generate the key for authenticated messages.
SNMPv3 security comes primary in two forms:
SNMP community strings do offer you some security, but the best practice is to have encrypted SNMPv3.
The NetGuardian 832A is one Example of an RTU that Supports SNMPv3
SNMPv3 support is a standard feature of the NetGuardian 832A G5 RTU. This allows you to monitor all of your SNMP devices with enhanced security via message encryption. The NetGuardian allows you to report alarms in SNMP v1, v2c, or v3. This leverages the full NetGuardian feature set and your existing SNMP management station.
The NetGuardian 832A G5 provisioning tools allow you to set up advanced SNMPv3 applications. For example, you can choose which SNMP versions managers may use to communicate with your NetGuardian. By restricting your managers to v3 only, you’re requiring them to use that protocol’s enhanced security. In environments where security is less of a concern, you can allow all SNMP versions to maximize flexibility.
This RTU also automatically generates a unique EngineID to eliminate conflicts caused by duplicate IDs. You can modify your NetGuardian’s default v3 EngineID for advanced SNMP applications, but this is recommended only for experienced users.
Using SNMPv3, the NetGuardian 832A encrypts its messages with CBC-DES encryption, a part of the Universal Security Model (USM). The encrypted data appears scrambled if it is intercepted, rendering it unreadable by anyone but the intended recipient. This makes SNMPv3 your best option when routing SNMP messages over the Internet.
This is ideal for companies with mission-critical infrastructure requiring high security. Even on a secured network, SNMPv3 encryption will provide an additional layer of redundant security.
Also, the 832A supports unique security profiles for up to four users. Each user can be assigned a unique set of security parameters, including authentication and/or privileged access to SNMP.
Do You Want to Know More about the SNMP Protocol?
This white paper is a quick and easy (but solid and foundational) introduction to SNMP. It has been created to give you the information you need to successfully implement SNMP-based alarm monitoring in your network. It’s an introduction to SNMP from the perspective of telecom network alarm management.
Summarizing the history and structure of the protocol you’ll see some concrete applications for using SNMP in internal network alarm environments. You’ll also see diagrams and read plain-English descriptions that teach you the basics in an intuitive way.
And don’t hesitate to call one of our SNMP experts to ask a specific question, though. We can offer basic guidance as you learn SNMP, even if you don’t need to purchase any new equipment.
Get a Live Demo
You need to see DPS gear in action. Get a live demo with our engineers.
White Paper Series
Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
DPS is here to help.
Have a specific question? Ask our team of expert engineers and get a specific answer!
Learn the Easy Way
Sign up for the next DPS Factory Training!
Whether you’re new to our equipment or you’ve used it for years, DPS factory training is the best way to get more from your monitoring.
Having trouble finding the perfect solution?
No other network on the planet is exactly like yours. We manufacture hundreds of product variations per year that are customized to our clients’ exact specs, all while providing training, tech support, and upgrade availability.
Send us a quick online message about what you’re trying to accomplish. We’ll give you a call and work with you to design a perfect-fit solution for your network.