Войти
| Протокол связи | |
| Уровень OSI | Приложение |
|---|---|
| Порт (ы) | 161, 162 (Trap) |
| RFC (s) | 3411–3418 |
| Протокол связи | |
| Уровень OSI | Приложение |
|---|---|
| Порт (ы) | 10161, 10162 (Trap) |
| RFC (s) | 6353 |
Простой протокол сетевого управления (SNMP ) - это Интернет Стандартный протокол для сбора и организации информации об управляемых устройствах в сетях IP и для изменения этой информации с целью изменения поведения устройства. Устройства, которые обычно поддерживают SNMP, включают кабельные модемы, маршрутизаторы, коммутаторы, серверы, рабочие станции, принтеры и др.
SNMP широко используется в управлении сетью для мониторинга сети. SNMP предоставляет данные управления в форме переменных в управляемых системах, организованных в информационную базу управления (MIB), которая описывает состояние и конфигурацию системы. Затем эти переменные могут быть запрошены удаленно (и, в некоторых случаях, ими можно управлять), управляя приложениями.
Были разработаны и развернуты три важные версии SNMP. SNMPv1 - это исходная версия протокола. Более свежие версии, SNMPv2c и SNMPv3, улучшают производительность, гибкость и безопасность.
SNMP является компонентом Internet Protocol Suite, как определено Internet Engineering Task Force (IETF). Он состоит из набора стандартов для управления сетью, включая протокол прикладного уровня, базу данных схему и набор объектов данных.
Принцип связи SNMP При типичном использовании SNMP один или несколько административных компьютеров, называемых менеджерами, выполняют задачу мониторинга или управления группой хостов или устройств в компьютерной сети. Каждая управляемая система выполняет программный компонент, называемый агентом, который сообщает информацию через SNMP менеджеру.
Сеть под управлением SNMP состоит из трех основных компонентов:
Управляемое устройство - это сетевой узел, который реализует интерфейс SNMP, который обеспечивает однонаправленный (только для чтения) или двунаправленный (чтение и запись) доступ к информации, относящейся к узлу. Управляемые устройства обмениваются информацией об узлах с NMS. Управляемые устройства, которые иногда называются сетевыми элементами, могут быть любого типа, включая, помимо прочего, маршрутизаторы, серверы доступа, коммутаторы, кабельные модемы, мосты, концентраторы, IP-телефоны, IP-видеокамеры, компьютер хосты, и принтеры.
Агент - это программный модуль управления сетью, который находится на управляемом устройстве. Агент владеет местной информацией об управлении и переводит эту информацию в или из специальной формы SNMP.
Станция управления сетью выполняет приложения, которые отслеживают и контролируют управляемые устройства. NMS предоставляют большую часть ресурсов обработки и памяти, необходимых для управления сетью. Одна или несколько NMS могут существовать в любой управляемой сети.
Агенты SNMP предоставляют данные управления в управляемых системах как переменные. Протокол также позволяет выполнять активные задачи управления, такие как изменение конфигурации, посредством удаленного изменения этих переменных. Переменные, доступные через SNMP, организованы в иерархии. Сам протокол SNMP не определяет, какие переменные должна предлагать управляемая система. Скорее, SNMP использует расширяемую структуру, которая позволяет приложениям определять свои собственные иерархии. Эти иерархии описываются как информационная база управления (MIB). MIB описывают структуру данных управления подсистемы устройства; они используют иерархическое пространство имен, содержащее идентификаторы объекта (OID). Каждый OID определяет переменную, которая может быть прочитана или установлена через SNMP. MIB используют обозначение, определенное Структура управляющей информации Версия 2.0 (SMIv2, RFC 2578 ), подмножество ASN.1.
SNMP работает на прикладном уровне из набора интернет-протоколов. Все сообщения SNMP передаются через протокол дейтаграмм пользователя (UDP). Агент SNMP получает запросы на порт UDP 161. Менеджер может отправлять запросы с любого доступного исходного порта на порт 161 агента. Ответ агента отправляется обратно на исходный порт диспетчера. Менеджер получает уведомления (Traps и InformRequests) на порт 162. Агент может генерировать уведомления с любого доступного порта. При использовании с Transport Layer Security или Datagram Transport Layer Security запросы принимаются на порт 10161, а уведомления отправляются на порт 10162.
SNMPv1 определяет пять ядер блоки данных протокола (PDU). Два других PDU, GetBulkRequest и InformRequest, были добавлены в SNMPv2, а PDU отчета был добавлен в SNMPv3. Все PDU SNMP построены следующим образом:
| IP-заголовок | UDP-заголовок | версия | community | PDU-type | идентификатор-запроса | статус-ошибки | индекс-ошибки | привязки переменных |
Семь типов PDU SNMP, идентифицированных полем PDU-type, следующие:
RFC 1157 указывает, что реализация SNMP должна принимать сообщение длиной не менее 484 байтов. На практике реализации SNMP принимают более длинные сообщения. При правильной реализации сообщение SNMP отбрасывается, если декодирование сообщения дает сбой, и, таким образом, искаженные запросы SNMP игнорируются. Затем успешно декодированный запрос SNMP аутентифицируется с использованием строки сообщества. Если аутентификация не удалась, генерируется ловушка, указывающая на неудачную аутентификацию, и сообщение отбрасывается.
SNMPv1 и SNMPv2 используют сообщества для установления доверия между менеджерами и агентами. Большинство агентов поддерживают три имени сообщества, по одному для чтения, чтения-записи и прерывания. Эти три группы сообщества управляют различными видами деятельности. Сообщество только для чтения применяется для получения запросов. Строка сообщества для чтения и записи применяется к заданным запросам. Строка сообщества ловушек применяется к получению ловушек. SNMPv3 также использует строки сообщества, но обеспечивает безопасную аутентификацию и обмен данными между диспетчером SNMP и агентом.
На практике реализации SNMP часто поддерживают несколько версий: обычно SNMPv1, SNMPv2c и SNMPv3.
SNMP версии 1 (SNMPv1) - это начальная реализация протокола SNMP. Дизайн SNMPv1 был разработан в 1980-х годах группой сотрудников, которые рассматривали официально спонсируемые OSI / IETF / NSF (Национальный научный фонд) проект (HEMS / CMIS / CMIP) как неприменимые для вычислительных платформ того времени, а также потенциально неработоспособный. SNMP был утвержден на основании убеждения, что это промежуточный протокол, необходимый для принятия мер по крупномасштабному развертыванию Интернета и его коммерциализации.
Первый запрос комментариев (RFC) для SNMP, теперь известный как SNMPv1, появился в 1988 году:
В 1990 году эти документы были заменены:
В 1991 г., RFC 1156 (MIB-1) заменен на более часто используемый:
SNMPv1 широко используется и является де-факто протоколом управления сетью в I Интернет-сообщество.
SNMPv1 может передаваться по протоколам транспортного уровня, таким как протокол дейтаграмм пользователя (UDP), Интернет-протокол (IP), OSI сетевая служба в режиме без установления соединения (CLNS), AppleTalk Протокол доставки дейтаграмм (DDP) и Novell Межсетевой обмен пакетами (IPX).
Версия 1 подверглась критике за ее плохую безопасность. Фактически, спецификация оставляет место для использования пользовательской аутентификации, но широко используемые реализации «поддерживают только тривиальную службу аутентификации, которая идентифицирует все сообщения SNMP как подлинные сообщения SNMP». Таким образом, безопасность сообщений зависит от безопасности каналов, по которым отправляются сообщения. Например, организация может считать свою внутреннюю сеть достаточно безопасной, так что для ее сообщений SNMP не требуется шифрование. В таких случаях «имя сообщества», которое передается в виде открытого текста, обычно рассматривается как фактический пароль, несмотря на исходную спецификацию.
SNMPv2, определяемая RFC 1441 и RFC 1452, пересматривает версию 1 и включает улучшения в области производительности, безопасности и взаимодействия между менеджерами. Он представил GetBulkRequest, альтернативу итеративному GetNextRequests для получения больших объемов управляющих данных за один запрос. Новая партийная система безопасности, представленная в SNMPv2, которую многие считают чрезмерно сложной, не получила широкого распространения. Эта версия SNMP достигла уровня зрелости предлагаемого стандарта, но в более поздних версиях была признана устаревшей.
Протокол простого сетевого управления на основе сообщества версии 2, или SNMPv2c, определен в RFC 1901 –RFC 1908. SNMPv2c включает SNMPv2 без спорной новой модели безопасности SNMP v2, а не с помощью простой сообщества на основе схему безопасности SNMPv1. Эта версия является одним из относительно немногих стандартов, соответствующих уровню зрелости проекта стандарта IETF, и широко считалась стандартом de facto SNMPv2. Позднее он был переформулирован как часть SNMPv3.
Пользовательский простой протокол сетевого управления версии 2 или SNMPv2u определен в RFC 1909 –RFC 1910. Это компромисс, который пытается предложить более высокий уровень безопасности, чем SNMPv1, но не требует высокой сложности SNMPv2. Вариант этого был коммерциализирован как SNMP v2 *, и в конечном итоге этот механизм был принят как одна из двух структур безопасности в SNMP v3.
SNMP версии 2 вводит возможность 64-битные счетчики данных. Версия 1 была разработана только с 32-битными счетчиками, которые могут хранить целочисленные значения от нуля до 4,29 миллиарда (точно 4 294 967 295). 32-битный счетчик версии 1 не может хранить максимальную скорость интерфейса 10 гигабит или больше, выраженную в битах в секунду. Точно так же статистика отслеживания 32-битного счетчика для интерфейса 10 гигабит или больше может снова вернуться к нулю менее чем за одну минуту, что может быть более коротким интервалом времени, чем опрашивается счетчик для чтения своего текущего состояния. Это может привести к потере или недействительности данных из-за необнаруженного обновления значений и повреждению данных отслеживания тенденций.
64-битный счетчик версии 2 может хранить значения от нуля до 18,4 квинтиллионов (точно 18 446 744 073 709 551 615), и поэтому в настоящее время маловероятно, что произойдет переключение счетчика между событиями опроса. Например, 1,6 терабит Ethernet, по прогнозам, станет доступным к 2025 году. 64-битный счетчик, увеличивающийся со скоростью 1,6 триллиона бит в секунду, сможет сохранять информацию для такого интерфейса без перехода на 133 дней.
SNMPv2c несовместим с SNMPv1 в двух ключевых областях: форматы сообщений и операции протокола. Сообщения SNMPv2c используют разные форматы заголовков и протокольных блоков данных (PDU), чем сообщения SNMPv1. SNMPv2c также использует две операции протокола, которые не указаны в SNMPv1. Чтобы преодолеть несовместимость, RFC 3584 определяет две стратегии сосуществования SNMPv1 / v2c: прокси-агенты и двуязычные системы управления сетью.
Агент SNMPv2 может действовать как прокси-агент от имени управляемых устройств SNMPv1. Когда SNMPv2 NMS выдает команду, предназначенную для агента SNMPv1, она вместо этого отправляет ее прокси-агенту SNMPv2. Прокси-агент пересылает сообщения Get, GetNextи Setагенту SNMPv1 без изменений. Сообщения GetBulk преобразуются прокси-агентом в сообщения GetNext, а затем пересылаются агенту SNMPv1. Кроме того, прокси-агент получает и сопоставляет сообщения прерывания SNMPv1 с сообщениями прерывания SNMPv2, а затем пересылает их в NMS.
Двуязычная система управления сетью SNMPv2 поддерживает как SNMPv1, так и SNMPv2. Для поддержки этой среды двойного управления приложение управления исследует информацию, хранящуюся в локальной базе данных, чтобы определить, поддерживает ли агент SNMPv1 или SNMPv2. Основываясь на информации в базе данных, NMS связывается с агентом, используя соответствующую версию SNMP.
Хотя SNMPv3 не вносит никаких изменений в протокол, кроме добавления криптографической защиты, он выглядит совсем иначе из-за новых текстовых соглашений, концепций и терминологии. Наиболее заметным изменением было определение безопасной версии SNMP путем добавления в SNMP улучшений безопасности и удаленной настройки. Аспект безопасности решается за счет предложения строгой аутентификации и шифрования данных для обеспечения конфиденциальности. Что касается административного аспекта, SNMPv3 фокусируется на двух частях, а именно на отправителях уведомлений и прокси-серверах. Изменения также облегчают удаленную настройку и администрирование объектов SNMP, а также решение проблем, связанных с крупномасштабным развертыванием, учетом и устранением неисправностей.
Включены функции и улучшения:
Безопасность была одной из самых слабых сторон SNMP до версии v3. Аутентификация в версиях 1 и 2 SNMP представляет собой не что иное, как пароль (строка сообщества), отправляемый открытым текстом между менеджером и агентом. Каждое сообщение SNMPv3 содержит параметры безопасности, которые закодированы в виде строки октетов. Значение этих параметров безопасности зависит от используемой модели безопасности. Подход к безопасности в v3 нацелен:
v3 также определяет USM и VACM, за которыми позже последовали модель безопасности транспорта (TSM), которая обеспечивала поддержку SNMPv3 через SSH и SNMPv3 через TLS и DTLS.
С 2004 года IETF распознает Simple Network Management Protocol версии 3, как определено в RFC 3411 –RFC 3418 (также известный как STD0062) как текущая стандартная версия SNMP. IETF назначил SNMPv3 полным Интернет-стандартом, наивысшим уровнем зрелости для RFC. Он считает более ранние версии устаревшими (обозначая их по-разному "Исторические" или "Устаревшие").
Мощные возможности записи SNMP, которые позволили бы конфигурировать сетевые устройства, не являются полностью используются многими поставщиками, частично из-за отсутствия безопасности в версиях SNMP до SNMPv3, а частично из-за того, что многие устройства просто не могут быть настроены с помощью изменений отдельных объектов MIB.
Некоторые значения SNMP (особенно табличные) требуют специальных знаний о схемах индексации таблиц, и эти значения индексов не обязательно согласованы на разных платформах. Это может вызвать проблемы корреляции при выборке информации с нескольких устройств, которые могут не использовать одну и ту же схему индексации таблиц (например, выборка показателей использования диска, когда конкретный идентификатор диска отличается на разных платформах.)
Некоторые крупные поставщики оборудования склонны чрезмерно расширить свой собственный интерфейс командной строки (CLI), ориентированный на системы конфигурации и управления.
В феврале 2002 года Институт разработки программного обеспечения Карнеги-Меллона (CM-SEI) Координационный центр группы реагирования на компьютерные чрезвычайные ситуации (CERT-CC) выпустил рекомендации по SNMPv1 после того, как Группа безопасного программирования Университета Оулу провела тщательный анализ обработки сообщений SNMP. Большинство реализаций SNMP, независимо от того, какую версию протокола они поддерживают, используют один и тот же программный код для декодирования блоков данных протокола (PDU), и в этом коде были выявлены проблемы. Были обнаружены другие проблемы с декодированием сообщений ловушек SNMP, полученных станцией управления SNMP, или запросов, полученных агентом SNMP на сетевом устройстве. Многим поставщикам приходилось выпускать исправления для своих реализаций SNMP.
Поскольку протокол SNMP разработан, чтобы позволить администраторам контролировать и настраивать сеть устройства удаленно, его также можно использовать для проникновения в сеть. Значительное количество программных инструментов может сканировать всю сеть с помощью SNMP, поэтому ошибки в настройке режима чтения-записи могут сделать сеть уязвимой для атак.
В 2001 году Cisco опубликовала информацию это указывает на то, что даже в режиме только для чтения реализация SNMP Cisco IOS уязвима для определенных атак отказа в обслуживании. Эти проблемы безопасности могут быть устранены путем обновления IOS.
Если SNMP не используется в сети, его следует отключить на сетевых устройствах. При настройке режима SNMP только для чтения особое внимание следует уделять конфигурации контроля доступа и тому, с каких IP-адресов принимаются сообщения SNMP. Если серверы SNMP идентифицируются по их IP-адресам, SNMP может отвечать только на эти IP-адреса, а сообщения SNMP с других IP-адресов будут отклонены. Однако подмена IP-адреса остается проблемой безопасности.
SNMP доступен в различных версиях 1, 2 и 3, каждая из которых имеет свои проблемы безопасности. SNMP v1 отправляет пароли в виде открытого текста по сети. Следовательно, пароли можно прочитать с помощью анализа пакетов. SNMP v2 разрешает хеширование паролей с MD5, но это необходимо настроить. Практически все программное обеспечение для управления сетью поддерживает SNMP v1, но не обязательно SNMP v2 или v3. SNMP v2 был специально разработан для обеспечения безопасности данных, то есть аутентификации, конфиденциальности и авторизации, но только SNMP версии 2c получил одобрение из Инженерной группы Интернета (IETF), а версии 2u и 2 * не получили одобрения IETF из-за проблем с безопасностью. SNMP v3 использует MD5, алгоритм безопасного хеширования (SHA) и алгоритмы с ключами для защиты от несанкционированного изменения данных и маскарадных атак. Если требуется более высокий уровень безопасности, стандарт шифрования данных (DES) может дополнительно использоваться в режиме цепочки блоков шифрования. SNMP v3 реализован в Cisco IOS, начиная с версии 12.0 (3) T.
SNMPv3 может подвергаться грубой силе и атакам по словарю для подбора ключей аутентификации, или ключи шифрования, если эти ключи генерируются из коротких (ненадежных) паролей или паролей, которые можно найти в словаре. SNMPv3 позволяет как предоставлять случайные, равномерно распределенные криптографические ключи, так и генерировать криптографические ключи на основе пароля, предоставленного пользователем. Риск угадывания строк аутентификации из хеш-значений, передаваемых по сети, зависит от используемой Хеш-функции и длины хеш-значения. SNMPv3 использует HMAC -SHA-2 протокол аутентификации для модели безопасности на основе пользователей (USM). Подтверждение запрос-ответ не использовалось для повышения безопасности. SNMPv3 (как и другие версии протокола SNMP) - это протокол без сохранения состояния, и он был разработан с минимальным количеством взаимодействий между агентом и менеджером. Таким образом, введение квитирования запроса-ответа для каждой команды наложит нагрузку на агента (и, возможно, на саму сеть), которую разработчики протокола сочли чрезмерной и неприемлемой.
Недостатки безопасности всех версий SNMP могут быть уменьшены с помощью механизмов аутентификации и конфиденциальности IPsec. Также доступна реализация SNMP поверх Datagram Transport Layer Security (DTLS).
Программное обеспечение для управления сетью на основе SNMP многократно отправляет пароли во время обычных операций по сети. Следовательно, пароли в открытом виде представляют собой значительную угрозу безопасности. Если используется SNMP v2, сетевой администратор должен включить шифрование паролей на сетевых устройствах, то есть на запущенных на них серверах SNMP.
Многие реализации SNMP включают тип, в котором новый сетевой компонент, такой как коммутатор или маршрутизатор, обнаруживается и объединяется автоматически. В SNMPv1 и v2c это делается через строку сообщества, которая транслируется в виде открытого текста на другие устройства. Из-за своей конфигурации по умолчанию в строках сообщества они являются общедоступными для доступа только для чтения и частными для чтения и записи. SNMP возглавил список общих проблем конфигурации по умолчанию института SANS и занял десятое место в SANS. 10 самых серьезных угроз безопасности в Интернете за 2000 год. Системные и сетевые администраторы часто неменяют эти конфигурации. Строка сообщества, отправляемая SNMP по сети, не зашифрована. Как только строка сообщества станет известна за пределами организации, она может стать целью атаки. Чтобы предотвратить легкое обнаружение сообщества, SNMP должен быть настроен для передачи ловушек сбоя аутентификации имени сообщества, а устройство управления SNMP должно быть настроено для реагирования на ловушку сбоя аутентификации.
SNMPv1 и v2 уязвимы для IP-спуфинг атак независимо от того, выполняется ли он через TCP или UDP, и может быть реализован для обхода списков доступа устройств, которые могли быть реализованы для ограничения Доступ к SNMP. Механизмы безопасности SNMPv3, такие как USM или TSM, предотвращают успешную атаку. Было бы бессмысленно использовать SNMPv3 VACM (View-based Access Control) без защиты сообщений с помощью USM или TSM.
 | В Викиверситете есть обучающие ресурсы по Простому протоколу управления сетью |
