Простой протокол управления сетью

Простой протокол управления сетью ( SNMP ) - это стандартный протокол Интернета для сбора и организации информации об управляемых устройствах в IP- сетях и для изменения этой информации с целью изменения поведения устройства. Устройства, которые обычно поддерживают SNMP, включают кабельные модемы, маршрутизаторы, коммутаторы, серверы, рабочие станции, принтеры и многое другое. ^[1]

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

Были разработаны и развернуты три важные версии SNMP. SNMPv1 - это исходная версия протокола. В более поздних версиях, SNMPv2c и SNMPv3, улучшена производительность, гибкость и безопасность.

SNMP является компонентом Internet Protocol Suite, как это определено Инженерной группой Интернета (IETF). Он состоит из набора стандартов для управления сетью, включая протокол прикладного уровня , схему базы данных и набор объектов данных . ^[2]

Обзор и основные понятия [ править ]

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

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

• Управляемые устройства
• Агент  - программное обеспечение, которое работает на управляемых устройствах.
• Станция управления сетью (NMS) - программное обеспечение, работающее на диспетчере

Управляемое устройство представляет собой сетевой узел , который реализует интерфейс протокола 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 принимает запросы на порт 161 UDP . Менеджер может отправлять запросы с любого доступного порта источника на порт 161 в агенте. Ответ агента отправляется обратно на исходный порт диспетчера. Менеджер получает уведомления ( Traps и InformRequests ) на порт 162. Агент может генерировать уведомления с любого доступного порта. При использовании с Transport Layer Security или Datagram Transport Layer Security запросы принимаются на порт 10161, а уведомления отправляются на порт 10162.^[3]

SNMPv1 определяет пять блоков данных основного протокола (PDU). Два других PDU, GetBulkRequest и InformRequest, были добавлены в SNMPv2, а PDU отчета был добавлен в SNMPv3. Все блоки PDU SNMP построены следующим образом:

Ниже перечислены семь типов PDU SNMP, определяемых полем PDU-type :

GetRequest

Запрос от менеджера к агенту для получения значения переменной или списка переменных. Желаемые переменные указываются в привязках переменных (поле значения не используется). Получение значений указанных переменных должно выполняться агентом как атомарная операция . Отклик с текущими значениями возвращаются.

SetRequest

Запрос от менеджера к агенту на изменение значения переменной или списка переменных. Привязки переменных указываются в теле запроса. Изменения всех указанных переменных должны выполняться агентом как атомарная операция. Отклик с (текущими) новыми значениями для переменных возвращаются.

GetNextRequest

Запрос от менеджера к агенту для обнаружения доступных переменных и их значений. Возвращает ответ с привязкой переменной для лексикографически следующей переменной в MIB. Всю MIB агента можно пройти с помощью итеративного применения GetNextRequest, начиная с OID 0. Строки таблицы можно прочитать, указав OID столбцов в привязках переменных запроса.

GetBulkRequest

Запрос от менеджера к агенту для нескольких итераций GetNextRequest . Оптимизированная версия GetNextRequest . Возвращает ответ с несколькими привязками переменных, полученными из привязки переменной или привязок в запросе. Специфичные для PDU поля неповторителей и максимального числа повторений используются для управления поведением ответа. GetBulkRequest был представлен в SNMPv2.

Ответ

Возвращает привязки переменных и подтверждение от агента к менеджеру для GetRequest , SetRequest , GetNextRequest , GetBulkRequest и InformRequest . Сообщения об ошибках обеспечиваются ошибки состояния и ошибки индексных полей. Хотя он использовался как ответ как на получение, так и на установку, этот PDU назывался GetResponse в SNMPv1.

Ловушка

Асинхронное уведомление от агента к менеджеру. В то время как при другой связи SNMP менеджер активно запрашивает информацию у агента, это PDU, которые отправляются от агента к менеджеру без явного запроса. Ловушки SNMP позволяют агенту уведомлять станцию ​​управления о важных событиях с помощью незапрашиваемого сообщения SNMP. PDU прерывания включают текущее значение sysUpTime , OID, определяющий тип прерывания, и необязательные привязки переменных. Адресация места назначения для прерываний определяется способом, зависящим от приложения, обычно через переменные конфигурации прерываний в MIB. Формат сообщения прерывания был изменен в SNMPv2, а PDU был переименован в SNMPv2-Trap .

InformRequest

Подтвержденное асинхронное уведомление. Этот PDU был введен в SNMPv2 и изначально был определен как связь менеджера с менеджером . ^[4] Более поздние реализации ослабили исходное определение, чтобы позволить агенту управлять связью. ^{[5] [6] [7]} Уведомления между менеджерами уже были возможны в SNMPv1 с использованием Trap , но поскольку SNMP обычно работает через UDP, где доставка не гарантируется, а об отброшенных пакетах не сообщается, доставка Trap не была гарантирована. . InformRequest исправляет это, поскольку подтверждение возвращается при получении. ^[6]

RFC  1157 указывает, что реализация SNMP должна принимать сообщение длиной не менее 484 байтов. На практике реализации SNMP принимают более длинные сообщения. ^{[8] : 1870} Если реализовано правильно, сообщение SNMP отбрасывается, если декодирование сообщения дает сбой, и, таким образом, искаженные запросы SNMP игнорируются. Затем успешно декодированный запрос SNMP аутентифицируется с использованием строки сообщества. В случае сбоя аутентификации создается ловушка, указывающая на сбой аутентификации, и сообщение отбрасывается. ^{[8] : 1871}

SNMPv1 и SNMPv2 используют сообщества для установления доверия между менеджерами и агентами. Большинство агентов поддерживают три имени сообщества, по одному для чтения, записи и чтения и прерывания. Эти три группы сообщества управляют различными видами деятельности. Сообщество только для чтения применяется для получения запросов. Строка сообщества для чтения и записи применяется к заданным запросам. Строка сообщества ловушек применяется к получению ловушек . SNMPv3 также использует строки сообщества, но обеспечивает безопасную аутентификацию и обмен данными между диспетчером SNMP и агентом. ^[9]

Версии протокола [ править ]

На практике реализации SNMP часто поддерживают несколько версий: обычно SNMPv1, SNMPv2c и SNMPv3. ^{[10] [11]}

Версия 1 [ править ]

SNMP версии 1 (SNMPv1) - это начальная реализация протокола SNMP. Дизайн SNMPv1 был разработан в 1980-х годах группой сотрудников, которые считали официально спонсируемые усилия OSI / IETF / NSF (Национальный научный фонд) (HEMS / CMIS / CMIP) неприменимыми для вычислительных платформ того времени, а также потенциально неработоспособный. SNMP был одобрен на основании убеждения, что это промежуточный протокол, необходимый для принятия мер по крупномасштабному развертыванию Интернета и его коммерциализации.

Первый запрос комментариев (RFC) для SNMP, теперь известный как SNMPv1, появился в 1988 году:

• RFC  1065  - Структура и идентификация управляющей информации для сетей на базе TCP / IP
• RFC  1066  - База управляющей информации для сетевого управления сетями на базе TCP / IP
• RFC  1067  - простой протокол управления сетью

В 1990 году эти документы были заменены:

• RFC  1155  - Структура и идентификация управляющей информации для сетей на базе TCP / IP
• RFC  1156  - База управляющей информации для сетевого управления сетями на базе TCP / IP
• RFC  1157  - простой протокол управления сетью

В 1991 году RFC 1156 (MIB-1) был заменен более часто используемым: 

• RFC  1213  - Версия 2 базы управляющей информации (MIB-2) для сетевого управления сетями на базе TCP / IP

SNMPv1 широко используется и де-факто является протоколом управления сетью в Интернет-сообществе. ^[12]

SNMPv1 может передаваться протоколами транспортного уровня , такими как протокол дейтаграмм пользователя (UDP), Интернет-протокол (IP), сетевая служба OSI в режиме без установления соединения (CLNS), протокол доставки дейтаграмм AppleTalk (DDP) и межсетевой обмен пакетами Novell (IPX).

Версия 1 подверглась критике за ее плохую безопасность. ^[13] Фактически, спецификация оставляет место для пользовательской аутентификации, но широко используемые реализации «поддерживают только тривиальную службу аутентификации, которая идентифицирует все сообщения SNMP как подлинные сообщения SNMP». ^[14] Таким образом, безопасность сообщений становится зависимой от безопасности каналов, по которым отправляются сообщения. Например, организация может считать свою внутреннюю сеть достаточно безопасной, поэтому для ее сообщений SNMP не требуется шифрование. В таких случаях «имя сообщества», которое передается в виде открытого текста , обычно рассматривается как фактический пароль, несмотря на исходную спецификацию.

Версия 2 [ править ]

Протокол SNMPv2, определенный в RFC 1441 и RFC 1452 , пересматривает версию 1 и включает улучшения в области производительности, безопасности и связи между менеджерами. Он представил GetBulkRequest , альтернативу итеративному GetNextRequests для получения больших объемов данных управления за один запрос. Новая партийная система безопасности, представленная в SNMPv2, которую многие считают чрезмерно сложной, не получила широкого распространения. ^[13] Эта версия SNMP достигла уровня зрелости предлагаемого стандарта, но более поздние версии сочли ее устаревшей. ^[15]  

Протокол простого сетевого управления на основе сообщества версии 2 или SNMPv2c определен в RFC 1901 - RFC 1908 . SNMPv2c включает SNMPv2 без спорной новой модели безопасности SNMP v2, а не с помощью простой сообщества на основе схему безопасности SNMPv1. Эта версия является одним из относительно немногих стандартов, соответствующих уровню зрелости проекта стандарта IETF, и широко считается стандартом де-факто SNMPv2. ^[15] Позднее он был переформулирован как часть SNMPv3. ^[16]  

Пользовательский простой протокол управления сетью версии 2 или SNMPv2u определен в RFC 1909 - RFC 1910 . Это компромисс, который пытается предложить более высокий уровень безопасности, чем SNMPv1, но не требует высокой сложности SNMPv2. Вариант этого был коммерциализирован как SNMP v2 * , и в конечном итоге этот механизм был принят как одна из двух структур безопасности в SNMP v3. ^[17]  

64-битные счетчики [ править ]

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), и поэтому в настоящее время маловероятно, что произойдет переключение счетчика между событиями опроса. Например, прогнозируется, что к 2025 году станет доступен 1,6- терабитный Ethernet. 64-битный счетчик, увеличивающийся со скоростью 1,6 триллиона бит в секунду, сможет сохранять информацию для такого интерфейса без пролонгации в течение 133 дней.

Взаимодействие SNMPv1 и SNMPv2c [ править ]

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.

Версия 3 [ править ]

Этот раздел имеет формат списка , но может читаться лучше как проза . Вы можете помочь, преобразовав этот раздел , если это необходимо. Доступна помощь по редактированию . ( Сентябрь 2016 г. )

Хотя SNMPv3 не вносит никаких изменений в протокол, кроме добавления криптографической безопасности, он выглядит совсем иначе из-за новых текстовых соглашений, концепций и терминологии. ^[1] Наиболее заметным изменением было определение безопасной версии SNMP путем добавления в SNMP улучшений безопасности и удаленной настройки. ^[18] Аспект безопасности решается путем предложения строгой аутентификации и шифрования данных для обеспечения конфиденциальности. Что касается административного аспекта, SNMPv3 фокусируется на двух частях, а именно на отправителях уведомлений и прокси-серверах. Изменения также облегчают удаленную настройку и администрирование объектов SNMP, а также решение проблем, связанных с крупномасштабным развертыванием, учетом и устранением неисправностей.

Включенные функции и улучшения:

• Идентификация объектов SNMP для облегчения связи только между известными объектами SNMP - Каждый объект SNMP имеет идентификатор, называемый SNMPEngineID, и обмен данными по протоколу SNMP возможен только в том случае, если объекту SNMP известен идентификатор своего партнера. Ловушки и уведомления - исключения из этого правила.
• Поддержка моделей безопасности. Модель безопасности может определять политику безопасности в административном домене или интрасети. SNMPv3 содержит спецификации для модели безопасности на основе пользователей (USM).
• Определение целей безопасности, в которых цели службы аутентификации сообщений включают защиту от следующего:
  • Модификация информации - защита от неавторизованного объекта SNMP, изменяющего транзитные сообщения, сгенерированные авторизованным участником.
  • Маскарад - защита от попыток выполнения операций управления, не разрешенных для какого-либо принципала, путем принятия идентичности другого принципала, имеющего соответствующие полномочия.
  • Модификация потока сообщений - защита от злонамеренного переупорядочивания, задержки или повторного воспроизведения сообщений, чтобы повлиять на несанкционированные операции управления.
  • Раскрытие информации - Защита от перехвата при обмене данными между механизмами SNMP.
• Спецификация USM - USM состоит из общего определения следующих доступных механизмов связи:
  • Общение без аутентификации и конфиденциальности (NoAuthNoPriv).
  • Связь с аутентификацией и без конфиденциальности (AuthNoPriv).
  • Связь с аутентификацией и конфиденциальностью (AuthPriv).
• Определение различных протоколов аутентификации и конфиденциальности - протоколы аутентификации MD5, SHA и HMAC-SHA-2 ^[19] , а также протоколы конфиденциальности CBC_DES и CFB_AES_128 поддерживаются в USM.
• Определение процедуры обнаружения - найти SNMPEngineID объекта SNMP для заданного транспортного адреса и адреса транспортной конечной точки.
• Определение процедуры синхронизации времени - для облегчения аутентифицированной связи между объектами SNMP.
• Определение MIB структуры SNMP - для облегчения удаленной настройки и администрирования объекта SNMP.
• Определение MIB USM - для облегчения удаленной настройки и администрирования модуля безопасности.
• Определение MIB модели управления доступом на основе представлений (VACM) - для облегчения удаленной настройки и администрирования модуля управления доступом.

Безопасность была одной из самых слабых сторон SNMP до v3. Аутентификация в версиях 1 и 2 SNMP представляет собой не что иное, как пароль (строка сообщества), отправляемый открытым текстом между менеджером и агентом. ^[1] Каждое сообщение SNMPv3 содержит параметры безопасности, которые закодированы в виде строки октетов. Значение этих параметров безопасности зависит от используемой модели безопасности. ^[20] Подход к безопасности в версии 3 направлен на: ^[21]

• Конфиденциальность - шифрование пакетов для предотвращения отслеживания неавторизованным источником.
• Целостность - целостность сообщения, гарантирующая, что пакет не был подделан во время передачи, включая дополнительный механизм защиты от повторного воспроизведения пакетов.
• Аутентификация - чтобы убедиться, что сообщение получено из допустимого источника.

v3 также определяет USM и VACM, за которыми позже последовала модель безопасности транспорта (TSM), которая обеспечивала поддержку SNMPv3 через SSH и SNMPv3 через TLS и DTLS.

• USM (User-based Security Model) обеспечивает функции аутентификации и конфиденциальности (шифрования) и работает на уровне сообщений.
• VACM (модель управления доступом на основе представлений) определяет, разрешен ли данному принципалу доступ к конкретному объекту MIB для выполнения определенных функций, и работает на уровне PDU.
• TSM (модель безопасности транспорта) предоставляет метод аутентификации и шифрования сообщений по внешним каналам безопасности. Были определены два транспорта, SSH и TLS / DTLS, которые используют спецификацию TSM.

С 2004 ^{[Обновить]}года IETF признает версию 3 Simple Network Management Protocol, определенную в RFC 3411 - RFC 3418 ^[22] (также известную как STD0062), как текущую стандартную версию SNMP. IETF назначила SNMPv3 полный стандарт Интернета , ^[23] самый высокий уровень зрелости в течение RFC. Он считает более ранние версии устаревшими (обозначая их по-разному "Историческими" или "Устаревшими"). ^[15]  

Проблемы реализации [ править ]

Мощные возможности записи SNMP, которые позволили бы конфигурировать сетевые устройства, не используются в полной мере многими поставщиками, отчасти из-за отсутствия безопасности в версиях SNMP до SNMPv3, а отчасти потому, что многие устройства просто не могут быть настроены с помощью индивидуальных Изменения объекта MIB.

Некоторые значения SNMP (особенно табличные) требуют специальных знаний схем индексирования таблиц, и эти значения индексов не обязательно согласованы на разных платформах. Это может вызвать проблемы корреляции при выборке информации с нескольких устройств, которые могут не использовать одну и ту же схему индексации таблиц (например, выборка показателей использования диска, когда конкретный идентификатор диска различается на разных платформах) ^[24].

Некоторые крупные поставщики оборудования склонны чрезмерно расширять свои собственные системы конфигурирования и управления, ориентированные на интерфейс командной строки (CLI). ^{[25] [ неудачная проверка ]}

В феврале 2002 года Координационный центр группы реагирования на компьютерные чрезвычайные ситуации (CERT-CC) Института программной инженерии Карнеги-Меллона (CM-SEI) выпустил рекомендации по SNMPv1 ^[26] после того, как Группа безопасного программирования Университета Оулу провела тщательный анализ обработки сообщений SNMP. Большинство реализаций SNMP, независимо от того, какую версию протокола они поддерживают, используют один и тот же программный код для декодирования блоков данных протокола (PDU), и в этом коде были выявлены проблемы. Были обнаружены другие проблемы с декодированием сообщений ловушек SNMP, полученных станцией управления SNMP, или запросов, полученных агентом SNMP на сетевом устройстве. Многим поставщикам пришлось выпустить исправления для своих реализаций SNMP. ^{[8] :1875 г.}

Последствия для безопасности [ править ]

Использование SNMP для атаки на сеть [ править ]

Поскольку протокол SNMP позволяет администраторам удаленно контролировать и настраивать сетевые устройства, его также можно использовать для проникновения в сеть. Значительное количество программных средств может сканировать всю сеть с помощью SNMP, поэтому ошибки в настройке режима чтения-записи могут сделать сеть уязвимой для атак. ^{[27] : 52}

В 2001 году Cisco опубликовала информацию, указывающую, что даже в режиме только для чтения реализация SNMP Cisco IOS уязвима для определенных атак типа «отказ в обслуживании» . Эти проблемы с безопасностью можно устранить путем обновления IOS. ^[28]

Если SNMP не используется в сети, его следует отключить в сетевых устройствах. При настройке режима SNMP только для чтения следует обратить особое внимание на конфигурацию управления доступом и на то, с каких IP-адресов принимаются сообщения SNMP. Если серверы SNMP идентифицируются по их IP-адресу, SNMP может отвечать только на эти IP-адреса, а сообщения SNMP с других IP-адресов будут отклонены. Однако подмена IP-адреса остается проблемой безопасности. ^{[27] : 54}

Аутентификация [ править ]

SNMP доступен в разных версиях, у каждой свои проблемы с безопасностью. 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. ^{[27] : 52}

SNMPv3 может подвергаться атакам методом грубой силы и словаря для угадывания ключей аутентификации или ключей шифрования, если эти ключи генерируются из коротких (ненадежных) паролей или паролей, которые можно найти в словаре. SNMPv3 позволяет как предоставлять случайные, равномерно распределенные криптографические ключи, так и генерировать криптографические ключи на основе пароля, предоставленного пользователем. Риск угадывания строк аутентификации из хеш-значений, передаваемых по сети, зависит от используемой криптографической хеш-функции и длины хеш-значения. SNMPv3 использует протокол аутентификации HMAC - SHA-2 для модели безопасности на основе пользователей (USM). ^[29] SNMP не использует более безопасныйпротокол аутентификации вызов-рукопожатие . SNMPv3 (как и другие версии протокола SNMP) - это протокол без сохранения состояния , и он был разработан с минимальным количеством взаимодействий между агентом и менеджером. Таким образом, введение квитирования запроса-ответа для каждой команды возложит на агента (и, возможно, на саму сеть) нагрузку, которую разработчики протокола сочли чрезмерной и неприемлемой. ^{[ необходима цитата ]}

Недостатки безопасности всех версий SNMP могут быть устранены с помощью механизмов аутентификации и конфиденциальности IPsec . ^{[ необходима цитата ]} SNMP также может безопасно передаваться через безопасность транспортного уровня дейтаграмм (DTLS). ^[10]

Многие реализации SNMP включают тип автоматического обнаружения, при котором новый сетевой компонент, такой как коммутатор или маршрутизатор, обнаруживается и опрашивается автоматически. В SNMPv1 и SNMPv2c это делается через строку сообщества, которая транслируется в виде открытого текста на другие устройства. ^[10] Пароли в виде открытого текста представляют значительную угрозу безопасности. Как только строка сообщества станет известна за пределами организации, она может стать целью атаки. Чтобы предупредить администраторов о других попытках подобрать строки сообщества, можно настроить протокол SNMP для передачи ловушек сбоя аутентификации имени сообщества. ^{[27] : 54} Если используется SNMPv2, проблемы можно избежать, включив шифрование паролей на агентах SNMP сетевых устройств.

Общая конфигурация по умолчанию для строк сообщества - «общедоступная» для доступа только для чтения и «частная» для чтения-записи. ^{[8] : 1874} Из-за хорошо известных значений по умолчанию протокол SNMP возглавил список общих проблем конфигурации по умолчанию Института SANS и занял десятое место в десятке самых критических угроз безопасности Интернета SANS за 2000 год. ^[30] Система и сетевые администраторы часто не изменяют эти конфигурации. ^{[8] : 1874 г.}

SNMPv1 и v2 уязвимы для атак с подменой IP-адресов , независимо от того, работают ли они через TCP или UDP. Это заставляет агентов обходить списки доступа к устройствам, которые могли быть реализованы для ограничения доступа по протоколу SNMP. Механизмы безопасности SNMPv3, такие как USM или TSM, предотвращают успешную атаку. Было бы бессмысленно использовать SNMPv3 VACM (View-based Access Control) без защиты сообщений с помощью USM или TSM. ^{[ необходима цитата ]}

Ссылки на RFC [ править ]

• RFC  1155 (STD 16) - Структура и идентификация управляющей информации для сетей на базе TCP / IP
• RFC  1156 (Исторический) - База управляющей информации для сетевого управления сетями на базе TCP / IP
• RFC  1157 (Исторический) - простой протокол управления сетью (SNMP)
• RFC  1213 (STD 17) - База управляющей информации для сетевого управления сетями на базе TCP / IP: MIB-II
• RFC  1452 (информационный) - сосуществование между версией 1 и версией 2 стандартной инфраструктуры сетевого управления Интернетом (устарело в соответствии с RFC 1908 ) 
• RFC  1901 (экспериментальный) - Введение в SNMPv2 на базе сообщества
• RFC  1902 (проект стандарта) - структура управляющей информации для SNMPv2 (устарело в соответствии с RFC 2578 ) 
• RFC  1908 (Standards Track) - Сосуществование между версией 1 и версией 2 стандартной структуры сетевого управления Интернетом
• RFC  2570 (информационный) - Введение в версию 3 стандартной инфраструктуры сетевого управления Интернетом (устарело в соответствии с RFC 3410 ) 
• RFC  2578 (STD 58) - Структура управляющей информации версии 2 (SMIv2)
• RFC  3410 (информационный) - Введение и заявления о применимости стандартной структуры управления Интернетом
• STD 62
  • RFC  3411  - Архитектура для описания структур управления простым протоколом сетевого управления (SNMP)
  • RFC  3412  - Обработка и отправка сообщений для простого протокола управления сетью (SNMP)
  • RFC  3413  - Приложения простого протокола управления сетью (SNMP)
  • RFC  3414  - Модель безопасности на основе пользователей (USM) для версии 3 Простого протокола управления сетью (SNMPv3)
  • RFC  3415  - Модель управления доступом на основе представлений (VACM) для простого протокола управления сетью (SNMP)
  • RFC  3416  - версия 2 протокола операций для простого протокола управления сетью (SNMP)
  • RFC  3417  - Транспортные сопоставления для простого протокола управления сетью (SNMP)
  • RFC  3418  - База управляющей информации (MIB) для простого протокола управления сетью (SNMP)
• RFC  3430 (экспериментальный) - простой протокол управления сетью (SNMP) поверх протокола управления передачей (TCP).
• RFC  3584 (BCP 74) - сосуществование между версией 1, версией 2 и версией 3 стандартной структуры сетевого управления Интернетом
• RFC  3826 (предложенный) - алгоритм шифрования Advanced Encryption Standard (AES) в модели безопасности SNMP на основе пользователей
• RFC  4789 (предложенный) - простой протокол управления сетью (SNMP) в сетях IEEE 802
• RFC  5343 (STD 78) - обнаружение идентификатора механизма контекста протокола простого сетевого управления (SNMP)
• RFC  5590 (STD 78) - Транспортная подсистема для простого протокола управления сетью (SNMP)
• RFC  5591 (STD 78) - Модель транспортной безопасности для простого протокола управления сетью (SNMP)
• RFC  5592 (предложенный) - модель безопасного транспорта оболочки для простого протокола управления сетью (SNMP)
• RFC  5608 (предложенный) - использование службы удаленной аутентификации пользователей с телефонным подключением (RADIUS) для транспортных моделей простого протокола управления сетью (SNMP).
• RFC  6353 (STD 78) - Транспортная модель безопасности транспортного уровня (TLS) для простого протокола управления сетью (SNMP)
• RFC  7630 (Standards Track) - Протоколы аутентификации HMAC-SHA-2 в модели безопасности на основе пользователей (USM) для SNMPv3

См. Также [ править ]

• AgentX , протокол субагента для SNMP
• CMIP через TCP / IP (CMOT)
• Common Management Information Protocol (CMIP), протокол управления ISO / OSI, используемый телекоммуникационными устройствами.
• Служба общей управленческой информации (CMIS)
• IEC 62379
• Net-SNMP , эталонная реализация SNMP с открытым исходным кодом
• Netconf , протокол, который представляет собой протокол конфигурации на основе XML для сетевого оборудования.
• Сравнение мониторинга сети
• Идентификатор объекта (OID)
• Удаленный мониторинг (RMON)
• Простой протокол мониторинга шлюза (SGMP), устаревший протокол, замененный на SNMP
• Симулятор SNMP

Ссылки [ править ]

Дальнейшее чтение [ править ]

• Дуглас Мауро, Кевин Шмидт (2005). Essential SNMP, второе издание . O'Reilly Media. п. 462. ISBN. 978-0596008406.
• Уильям Столлингс (1999). SNMP, SNMPv2, SNMPv3 и RMON 1 и 2 . Addison Wesley Longman, Inc. стр. 619 . ISBN 978-0201485349.

Внешние ссылки [ править ]

В Викиверситете есть учебные ресурсы о простом протоколе управления сетью

• Простой протокол управления сетью в Curlie