Концепции SNMP (включая v3)

SNMP

• Цель SNMP — это протокол для получения статуса (например, загрузки процессора, свободной памяти, сетевой нагрузки) вычислительных устройств, таких как маршрутизаторы, коммутаторы и даже серверы.
• Дескриптор объекта, управляемый объект . Клиент может предоставить глобально уникальные имена, такие как cpmCPUTotal5secRev (средняя загрузка ЦП устройства Cisco за последние 5 секунд), чтобы указать информацию, которую он хочет, тогда сервер должен вернуть такую ​​информацию. Такое текстовое имя называется «дескриптор объекта». Слово «объект» или «управляемый объект» относится к концепции загрузки процессора. Фактическая загрузка процессора в устройстве называется «экземпляром объекта».
• Идентификатор объекта (OID) . Чтобы убедиться, что каждый дескриптор объекта уникален, на самом деле он определяется с использованием списка целых чисел, например 1.3.6.1.4.1.9.9.109.1.1.1.1.6. Каждое целое число похоже на пакет в Java. Например, целые числа в 1.3.6.1.4.1.9 представляют собой iso (1), org (3), dod, т. Е. Министерство обороны (6), Интернет (1), частное (4), предприятия (1), cisco (9) соответственно. Это позволяет интернет-полномочиям иерархически делегировать управление пространством имен: частным предприятиям, а затем Cisco, которая может далее делегировать его различным подразделениям или категориям продуктов. Такой список целых чисел называется «идентификатором объекта». Это окончательная идентификация для управляемого объекта.
  • Даже если дескриптор объекта должен быть уникальным, полезно увидеть иерархию. Поэтому обычно отображается полный список дескрипторов объектов, например iso.org.dod.internet.private.enterprises.cisco… cpmCPUTotal5secRev.
  • Зачем использовать целые числа вместо символических имен? Возможно, чтобы сетевые устройства (с небольшим объемом оперативной памяти или процессора), использующие SNMP, сэкономили место при обработке. Символические имена, такие как дескриптор объекта, могут использоваться человеком в командах, но в работе протокола это делается с использованием идентификатора объекта.
  • В принципе, объект abcd и объект abcde на устройстве не имеют отношения удержания. То есть они НЕ похожи на объект Java, содержащий дочерний объект. Фактически, значение каждого объекта в SNMP является простым значением (скалярным), таким как целое число или строка. Единственные отношения между ними — это их имена.
• Идентификация экземпляра . Теперь самое сложное понятие в SNMP. Рассмотрим концепцию количества байтов, полученных сетевым интерфейсом на маршрутизаторе. Эта концепция является объектом. Поскольку маршрутизатор должен иметь несколько интерфейсов, должно быть несколько экземпляров этого объекта. Затем, как клиент SNMP может указать серверу SNMP, какой экземпляр его интересует? Решение является более или менее клуджем: позволить экземпляру, например, abcd, представить таблицу (составное, структурное значение), которая содержит строки (также составные, структурное значение), представленные abcde. Каждая строка содержит экземпляры дочерних объектов. (только со скалярными значениями). Каждый дочерний объект называется «столбчатым объектом». Например, каждая строка может содержать три экземпляра объекта: abcdef, abcdeg и abcdeidx. Если вы хотите сослаться на экземпляр abcdef в определенной строке, вы напишите abcdef <index>. Значение индекса определяется abcde (строка). Например, он может быть определен как поиск строки в таблице, содержащей столбчатый объект abcdeidx, значение которого равно <index>, а затем вернуть столбчатый объект abcdef в качестве результата.
  • Обратите внимание, что это единственная ситуация, когда значение объекта может быть структурой, и что в SNMP существует отношение содержания объекта.
  • Что сбивает с толку, так это то, что abcdef используется и как идентификатор объекта, и как ключ поиска, чтобы найти дочерний экземпляр в строке. В отличие от других идентификаторов объектов, идентификатор теперь представляет отношение содержания объекта, поэтому он должен иметь префикс abcde, иначе сервер не будет знать, какую таблицу просматривать, и каково определение индекса.
  • Полный идентификатор abcdef <index> называется идентификатором экземпляра.
  • Вот конкретный пример: Рассмотрим iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifInOctets.1. Определение iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry гласит, что для поиска строки в таблице необходимо выполнить поиск строки, содержащей дочерний объект iso.org.dod.internet. .mgmt.mib-2.interfaces.ifTable.ifEntry.ifIndex со значением 1 (указанный индекс), тогда он вернет значение дочернего объекта iso.org.dod.internet.mgmt.mib-2.interfaces. ifTable.ifEntry.ifInOctets в строке. Конечно, чтобы это работало, дочерний объект iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifIndex в каждой строке должен быть назначен с последовательными значениями 1, 2,… и т. Д. (это действительно так).
• Наконец, простой случай — таблицы вообще нет. Например, чтобы узнать время работы устройства, используйте идентификатор объекта iso.org.dod.internet.mgmt.mib-2.host.hrSystem.hrSystemUptime и добавьте .0 в качестве индекса, поэтому идентификатор экземпляра iso .org.dod.internet.mgmt.mib-2.host.hrSystem.hrSystemUptime.0. Кстати, «ч» означает «ресурсы хоста».
• MIB (информационная база управления) . MIB — это просто набор управляемых объектов (не экземпляров). Существуют стандартные MIB, чтобы производители устройств могли реализовать их, а пользователи могли найти правильные идентификаторы объектов для использования. Существуют также собственные MIB, например, разработанные Cisco для предоставления информации, доступной только на ее устройствах.
• Поиск поддерживаемых OID . Как узнать MIB или идентификаторы объектов, поддерживаемые устройством? Проще просто «пройтись по дереву MIB»: показать все экземпляры в дереве или в поддереве. В Linux это делается, как показано ниже. Вы указываете IP-адрес или имя хоста сервера и дополнительно указываете узел, чтобы отображалось только это поддерево (идентификатор объекта начинается с точки, в противном случае предполагается, что он относится к iso.org.dod.internet.mgmt.mib. -2):

• Получение экземпляра . Просто укажите идентификатор экземпляра:

• SNMP, движок и приложения . SNMP является одноранговым протоколом. Не существует понятия сервера и клиента (эти термины используются здесь для простоты). Вместо этого оба узла имеют одинаковые возможности ядра, такие как отправка или получение сообщений SNMP, выполнение обработки безопасности (см. Ниже), интеграция обработки v1, v2c и v3 (диспетчеризация) и т. Д. Эта часть называется механизмом SNMP. Вдобавок к движку существуют разные «приложения»: одно приложение может отвечать только на запросы для экземпляров объектов (называемых агентом SNMP в v1 и v2), другое приложение может проверять другие (называемые диспетчером SNMP в v1 и v2), еще одно другое может пересылать сообщения SNMP (прокси SNMP). Весь сервер или клиент называется «сущность SNMP».
• Контекст . На некоторых устройствах имеется несколько копий полного поддерева MIB. Например, физический маршрутизатор может поддерживать концепцию виртуальных маршрутизаторов. Каждый такой виртуальный маршрутизатор будет иметь полное поддерево MIB экземпляров. В этом случае каждый виртуальный маршрутизатор может быть указан как «контекст» на сервере SNMP. Контекст определяется по имени. Например, виртуальный маршрутизатор может быть идентифицирован как контекст «vr1». Существует контекст по умолчанию с пустой строкой («») в качестве имени. Когда клиент отправляет запрос, он может указать имя контекста. Если нет, он запросит контекст по умолчанию.
• Уведомление (ловушка) . Сервер SNMP может активно отправлять уведомление клиенту, когда возникает какое-либо условие. Это очень похоже на ответ без запроса. В остальном все похоже. Условие (например, изменение значения экземпляра или его выход за пределы диапазона), назначение, используемые учетные данные (см. Раздел о безопасности ниже) и т. Д. Настраиваются на сервере.
• Транспортная привязка . Обычно SNMP работает на UDP-порту 161.

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

• Безопасность SNMP v1 и v2c . В SNMP v1 и v2c (v2 не был широко распространен) безопасность практически отсутствует. Единственная безопасность — это «строка сообщества». Таким образом, сервер настроен так, чтобы в сообществе идентифицировать его с помощью строки, такой как «foo», «public» (обычно используется и по умолчанию для многих устройств означает отсутствие защиты) или «private». Если клиент может процитировать сообщество, то ему разрешен доступ. Поскольку строка сообщества включена в виде простого текста в пакеты SNMP, она практически не обеспечивает безопасности. Поэтому в v1 и v2c для доступа к серверу SNMP вы будете делать что-то вроде:

• Безопасность SNMP v3 . В SNMP v3 существует защита на основе пользователя. То есть клиенту может потребоваться аутентифицировать сообщения на сервере как исходящие от пользователя с использованием пароля (пароля аутентификации). Кроме того, клиент может также нуждаться в шифровании сообщений с использованием другого пароля (секретного пароля). Это требование безопасности называется «уровнем безопасности» (аутентификация не требуется, аутентификация, но не конфиденциальность, аутентификация с приватностью). Следовательно, в v3 вы получите доступ к серверу, например:

• Файл конфигурации клиента . Чтобы сохранить все эти данные каждый раз, вы можете сохранить эти параметры в файле snmp.conf по умолчанию.
• Ограничение безопасности . Неправильно указывать пароль в командной строке, так как он может быть обнаружен локальными пользователями с помощью «ps». Хранить его в файле конфигурации лучше. Однако файл допускает только один пароль аутентификации и один пароль конфиденциальности, что недостаточно для обработки случая использования разных паролей для разных серверов.
• Имя безопасности . Имя безопасности — это просто имя пользователя. Не больше, не меньше. Это термин, используемый в RFC (может быть, в будущем это может быть что-то еще?)
• Алгоритм Кроме того, существуют разные алгоритмы для аутентификации (HMAC с использованием MD5 или SHA) и для конфиденциальности (шифрование с использованием DES или AES). Итак, вам нужно указать алгоритмы для использования:

• Убедитесь, что алгоритмы совпадают . Поскольку SNMP использует UDP, и каждый запрос и ответ могут использовать только один пакет UDP, согласование алгоритма на «фазе соединения» вообще отсутствует. Фактически, предположительно для простоты реализации, используемые алгоритмы даже не указаны в сообщении, поэтому клиент должен использовать согласованные алгоритмы, настроенные в учетной записи пользователя на сервере, иначе сервер просто не сможет аутентифицировать или расшифровать сообщение.

• Локализованные ключи . Пароль аутентификации и пароль конфиденциальности учетной записи пользователя не используются напрямую. Идея заключается в том, что, скорее всего, вы будете использовать один и тот же пароль для всех учетных записей пользователей на всех устройствах на сайте. Если он используется напрямую, то хакер, управляющий одним устройством, сможет найти пароль и использовать его для доступа ко всем другим устройствам. Поэтому при создании учетной записи пользователя вы указываете пароль, но SNMP-сервер Linux объединяет его с уникальным идентификатором (называемым «идентификатором механизма»), сгенерированным для устройства (например, MAC или IP и / или случайным числом). генерируется и сохраняется при установке), хеширует его и использует результат в качестве пароля («локализованный ключ»). Таким образом, даже если хакер сможет найти этот локализованный ключ, он все равно не сможет найти оригинальный пароль.
  • Но как клиент может сгенерировать тот же ключ? Сначала необходимо получить идентификатор двигателя, а затем выполнить то же хеширование. Это поддерживается протоколом SNMP.
• Создание учетных записей пользователей . Из-за необходимости генерировать локализованные ключи способ создания учетных записей пользователей в Linux довольно странный. Вы останавливаете сервер, указываете имя пользователя и пароль в файле, затем запускаете сервер. Он прочитает пароль, преобразует его в локализованный ключ и перезапишет файл. Этот файл /var/lib/snmp/snmpd.conf в Linux:

• Контроль доступа Контроль доступа может указывать учетную запись пользователя, самый низкий требуемый уровень безопасности, к какой части дерева MIB осуществляется доступ (может использовать OID для идентификации поддерева), тип доступа (чтение или запись), чтобы предоставить доступ , Вот несколько примеров настроек в Linux (хотя используются имена пользователей, но на практике они должны представлять устройства):

• Посмотреть Как указать несколько поддеревьев в правиле контроля доступа? Вы можете определить вид. Представление имеет имя и определяется как включающее некоторые поддеревья и исключающее некоторое поддерево. Затем вы можете обратиться к нему по имени в управлении доступом:

• Контроль доступа для v1 и v2c . Для v1 и v2c управление доступом может указывать строку сообщества, диапазон IP-адресов клиента («источник»), поддерево (OID) или представление:

• Наиболее гибкая модель контроля доступа . Вышеуказанная модель контроля доступа называется «традиционной моделью». Новая, наиболее гибкая модель управления доступом называется «моделью управления доступом на основе представлений (VACM)», хотя первая может также использовать представления. Это может быть более подходящим для того, чтобы называть это контролем доступа на основе групп, поскольку он использует группы пользователей в правилах (НЕ точный синтаксис еще!):

• Отображение строки сообщества на имя пользователя . При использовании VACM вместо предоставления доступа к строкам сообщества необходимо объединить v1 и v2c в обработку управления доступом на основе пользователя. Для этого строка сообщества вместе с источником может быть сопоставлена ​​с именем пользователя (имя пользователя, отображаемое, чтобы НЕ существовало):

• Модель безопасности . Несмотря на то, что разные типы идентификаторов в разных версиях SNMP единообразно представлены в виде имени пользователя, их достоверность все еще существенно различается. Итак, при указании членства в группах и правил контроля доступа вы должны указать «модель безопасности» (v1, v2c или модель безопасности пользователя, как в v3), и это правильный синтаксис: