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

SNMPv3 STD0062

Протокол связи
Уровень OSI	Приложение
Порт(ы)	161, 162 (Ловушка)
RFC(ы)	3411–3418

Безопасный SNMP

Протокол связи
Уровень OSI	Приложение
Порт(ы)	10161, 10162 (Ловушка)
RFC(ы)	6353

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

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

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

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

Обзор и основные понятия

Принцип связи SNMP

При типичном использовании 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.

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

IP-заголовок

UDP-заголовок

версия

сообщество

PDU-тип

идентификатор запроса

статус ошибки

индекс ошибки

привязки переменных

Семь типов SNMP PDU, определяемых полем PDU-type , следующие:

Получить запрос

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

SetRequest

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

GetNextRequest

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

Получить массовый запрос

Запрос от менеджера к агенту для нескольких итераций 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 .

ИнформЗапрос

Подтвержденное асинхронное уведомление. Этот PDU был представлен в SNMPv2 и первоначально определялся как связь между менеджерами . В более поздних реализациях исходное определение было ослаблено, чтобы позволить агенту управлять связью. Уведомления между менеджерами уже были возможны в SNMPv1 с использованием Trap , но поскольку SNMP обычно работает через UDP, где доставка не гарантирована и о потерянных пакетах не сообщается, доставка Trap не была гарантирована. InformRequest исправляет это, поскольку при получении возвращается подтверждение.

В RFC   1157 указано, что реализация SNMP должна принимать сообщения длиной не менее 484 байт. На практике реализации SNMP принимают более длинные сообщения. При правильной реализации сообщение SNMP отбрасывается, если декодирование сообщения завершается неудачей, и, таким образом, некорректные запросы SNMP игнорируются. Успешно декодированный запрос SNMP затем аутентифицируется с использованием строки сообщества. Если аутентификация не удалась, генерируется ловушка, указывающая на ошибку аутентификации, и сообщение удаляется.

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

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

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

Версия 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 широко используется и де-факто является протоколом управления сетью в интернет-сообществе.

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

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

Версия 2

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

Простой протокол сетевого управления на основе сообщества версии 2 или SNMPv2c определен в РФК   1901 – РФК   1908 . SNMPv2c включает в себя SNMPv2 без противоречивой новой модели безопасности SNMP v2, вместо которой используется простая схема безопасности SNMPv1, основанная на сообществе. Эта версия является одним из относительно немногих стандартов, соответствующих уровню зрелости проекта стандарта IETF, и широко считалась де-факто стандартом SNMPv2. Позже он был переформулирован как часть SNMPv3.

Простой протокол управления сетью на основе пользователя версии 2 или SNMPv2u определен в РФК   1909 – РФК   1910 . Это компромисс, который пытается обеспечить большую безопасность, чем SNMPv1, но без высокой сложности SNMPv2. Вариант этого был коммерциализирован как SNMP v2* , и в конечном итоге этот механизм был принят в качестве одной из двух инфраструктур безопасности в SNMP v3.

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

Совместимость SNMPv1 и SNMPv2c

SNMPv2c несовместим с SNMPv1 в двух ключевых областях: форматах сообщений и операциях протокола. В сообщениях SNMPv2c используются другие форматы заголовка и блока данных протокола (PDU), чем в сообщениях SNMPv1. SNMPv2c также использует две операции протокола, которые не указаны в SNMPv1. Чтобы преодолеть несовместимость, RFC   3584 определяет две стратегии сосуществования SNMPv1/v2c: прокси-агенты и двуязычные системы управления сетью.

Прокси-агенты

Агент SNMPv2 может выступать в качестве прокси-агента от имени устройств, управляемых SNMPv1. Когда NMS SNMPv2 выдает команду, предназначенную для агента SNMPv1, она вместо этого отправляет ее прокси-агенту SNMPv2. Прокси-агент пересылает Get, GetNext, и Set сообщения агенту SNMPv1 без изменений. Сообщения GetBulk преобразуются прокси-агентом в GetNext сообщения, а затем пересылаются агенту SNMPv1. Кроме того, прокси-агент получает и сопоставляет сообщения-ловушки SNMPv1 с сообщениями-ловушками SNMPv2, а затем пересылает их в NMS.

Двуязычная система управления сетью

Двуязычные системы управления сетью SNMPv2 поддерживают как SNMPv1, так и SNMPv2. Для поддержки этой среды двойного управления приложение управления проверяет информацию, хранящуюся в локальной базе данных, чтобы определить, поддерживает ли агент SNMPv1 или SNMPv2. На основе информации в базе данных NMS связывается с агентом, используя соответствующую версию SNMP.

Версия 3

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

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

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

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

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

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

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

По состоянию на 2004 год the IETF recognizes Simple Network Management Protocol version 3 as defined by RFC   3411 – RFC   3418 (также известный как STD0062) как текущая стандартная версия SNMP. IETF интернет - объявил SNMPv3 полноценным стандартом . самый высокий уровень зрелости для RFC. Он считает более ранние версии устаревшими (обозначая их по-разному: «Исторические» или «Устаревшие» ).

Проблемы реализации

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

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

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

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

Последствия для безопасности

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

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

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

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

Аутентификация

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.

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

Недостатки безопасности всех версий SNMP можно устранить с помощью механизмов аутентификации и конфиденциальности IPsec . SNMP также может безопасно передаваться через Datagram Transport Layer Security (DTLS).

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

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

Независимо от того, работают ли они через TCP или UDP, SNMPv1 и v2 уязвимы для с подменой IP атак . С помощью подмены злоумышленники могут обойти списки доступа к устройствам в агентах, которые реализованы для ограничения доступа по SNMP. Механизмы безопасности SNMPv3, такие как 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 стандартной структуры управления сетью Интернета (устарело). РФК   1908 )
• RFC   1901 (экспериментальный) — Введение в протокол SNMPv2, основанный на сообществе.
• RFC   1902 (проект стандарта) — Структура управляющей информации для SNMPv2 (устарело). RFC   2578 )
• RFC   1908 (стандарты) — сосуществование версии 1 и версии 2 стандартной структуры управления сетью Интернета.
• RFC   2570 (информационный) — Введение в версию 3 стандартной структуры управления сетью Интернета (устарело). RFC   3410 )
• RFC   2578 (STD 58) — Структура информации управления версии 2 (SMIv2)
• RFC   3410 (информационный) — Введение и заявления о применимости стандартной структуры управления Интернетом
• STD 62 содержит следующие RFC:
  • 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 (предлагается) — алгоритм шифрования расширенного стандарта шифрования (AES) в модели безопасности на основе пользователя SNMP.
• RFC   4789 (предлагается) — простой протокол управления сетью (SNMP) в сетях IEEE 802.
• RFC   5343 (STD 78) — обнаружение контекста EngineID простого протокола сетевого управления (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 (предложенный | исторический) — протоколы аутентификации HMAC-SHA-2 в модели безопасности на основе пользователя (USM) для SNMPv3
• RFC   7860 (предлагается) — протоколы аутентификации HMAC-SHA-2 в модели безопасности на основе пользователя (USM) для SNMPv3

См. также

• Протокол расширения агента (AgentX) — протокол субагента для SNMP.
• Common Management Information Protocol (CMIP) – протокол управления ISO/OSI, используемый телекоммуникационными устройствами.
• Общая служба управленческой информации (CMIS)
• Сравнение систем сетевого мониторинга
• МЭК 62379 – Протокол управления на основе простого протокола сетевого управления.
• Net-SNMP – эталонная реализация SNMP с открытым исходным кодом.
• NETCONF — протокол, представляющий собой протокол конфигурации сетевого оборудования на основе XML.
• Удаленный мониторинг сети (RMON)
• Простой протокол мониторинга шлюза (SGMP) — устаревший протокол заменен на SNMP.
• Симулятор SNMP — программное обеспечение, имитирующее устройства, поддерживающие SNMP.

Дальнейшее чтение

• Дуглас Мауро; Кевин Шмидт (2005). Essential SNMP (Второе изд.). О'Рейли Медиа. ISBN  978-0596008406 .
• Уильям Столлингс (1999). SNMP, SNMPv2, SNMPv3 и RMON 1 и 2 . Аддисона Уэсли Лонгмана, Inc. ISBN  978-0201485349 .
• Маршалл Т. Роуз (1996). Простая книга . Прентис Холл. ISBN  0-13-451659-1 .

Внешние ссылки

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