Simple Network Management Protocol ( SNMP ) — это стандартный интернет- протокол для сбора и организации информации об управляемых устройствах в IP -сетях и для изменения этой информации с целью изменения поведения устройства. Устройства, которые обычно поддерживают SNMP, включают кабельные модемы , маршрутизаторы , сетевые коммутаторы , серверы, рабочие станции, принтеры и многое другое. [1]
SNMP широко используется в управлении сетями для мониторинга сети . SNMP предоставляет данные управления в виде переменных в управляемых системах, организованных в базе данных управления (MIB), которая описывает состояние и конфигурацию системы. Затем эти переменные можно удаленно запрашивать (и, в некоторых случаях, манипулировать ими) с помощью управляющих приложений.
Разработаны и внедрены три важные версии SNMP. SNMPv1 — это оригинальная версия протокола. Более поздние версии, SNMPv2c и SNMPv3, отличаются улучшениями в производительности, гибкости и безопасности.
SNMP является компонентом Internet Protocol Suite , как определено Internet Engineering Task Force (IETF). Он состоит из набора стандартов для управления сетью, включая протокол прикладного уровня , схему базы данных и набор объектов данных . [2]
В типичном использовании SNMP один или несколько административных компьютеров, называемых менеджерами, имеют задачу мониторинга или управления группой хостов или устройств в компьютерной сети . Каждая управляемая система выполняет программный компонент, называемый агентом , который передает информацию через SNMP менеджеру.
Сеть, управляемая по протоколу SNMP, состоит из трех ключевых компонентов:
Управляемое устройство — это сетевой узел, реализующий интерфейс SNMP, который обеспечивает однонаправленный (только чтение) или двунаправленный (чтение и запись) доступ к информации, специфичной для узла. Управляемые устройства обмениваются информацией, специфичной для узла, с NMS. Иногда называемые сетевыми элементами, управляемые устройства могут быть любым типом устройства, включая, помимо прочего, маршрутизаторы , серверы доступа , коммутаторы , кабельные модемы , мосты , концентраторы , IP-телефоны , IP-видеокамеры , компьютерные хосты и принтеры .
Агент — это программный модуль управления сетью , который находится на управляемом устройстве. Агент имеет локальные знания об информации управления и транслирует эту информацию в или из SNMP-специфической формы.
Станция управления сетью выполняет приложения, которые отслеживают и контролируют управляемые устройства. NMS предоставляют большую часть ресурсов обработки и памяти, необходимых для управления сетью. В любой управляемой сети может существовать одна или несколько NMS.
Агенты SNMP предоставляют данные управления в управляемых системах в виде переменных. Протокол также позволяет выполнять активные задачи управления, такие как изменение конфигурации, посредством удаленного изменения этих переменных. Переменные, доступные через SNMP, организованы в иерархии. Сам SNMP не определяет, какие переменные должна предлагать управляемая система. Вместо этого SNMP использует расширяемую конструкцию, которая позволяет приложениям определять свои собственные иерархии. Эти иерархии описываются как база управляющей информации (MIB). MIB описывают структуру данных управления подсистемы устройства; они используют иерархическое пространство имен, содержащее идентификаторы объектов (OID). Каждый OID идентифицирует переменную, которая может быть прочитана или установлена через SNMP. MIB используют нотацию, определенную в Structure of Management Information Version 2.0 (SMIv2, RFC 2578), подмножестве ASN.1 .
SNMP работает на прикладном уровне набора протоколов Интернета . Все сообщения SNMP передаются через протокол User Datagram Protocol (UDP). Агент SNMP получает запросы на порт UDP 161. Менеджер может отправлять запросы с любого доступного исходного порта на порт 161 в агенте. Ответ агента отправляется обратно на исходный порт менеджера. Менеджер получает уведомления ( Traps и InformRequests ) на порт 162. Агент может генерировать уведомления с любого доступного порта. При использовании с Transport Layer Security или Datagram Transport Layer Security запросы принимаются на порт 10161, а уведомления отправляются на порт 10162. [3]
SNMPv1 определяет пять основных протокольных единиц данных (PDU). Два других PDU, GetBulkRequest и InformRequest, были добавлены в SNMPv2, а Report PDU был добавлен в SNMPv3. Все SNMP PDU построены следующим образом:
Ниже приведены семь типов PDU SNMP, определяемых полем типа PDU :
RFC 1157 определяет, что реализация SNMP должна принимать сообщение длиной не менее 484 байт. На практике реализации SNMP принимают более длинные сообщения. [8] : 1870 При правильной реализации сообщение SNMP отбрасывается, если декодирование сообщения не удается, и, таким образом, неправильно сформированные запросы SNMP игнорируются. Успешно декодированный запрос SNMP затем аутентифицируется с использованием строки сообщества. Если аутентификация не удалась, генерируется ловушка, указывающая на сбой аутентификации, и сообщение отбрасывается. [8] : 1871
SNMPv1 и SNMPv2c используют сообщества для установления доверия между менеджерами и агентами. Большинство агентов поддерживают три имени сообщества, по одному для только чтения, чтения-записи и прерывания. Эти три строки сообщества управляют различными типами действий. Сообщество только чтения применяется для получения запросов. Строка сообщества чтения-записи применяется для установки запросов. Строка сообщества прерывания применяется для получения прерываний . SNMPv3 также использует строки сообщества, но обеспечивает безопасную аутентификацию и связь между менеджером SNMP и агентом. [9]
На практике реализации SNMP часто поддерживают несколько версий: обычно SNMPv1, SNMPv2c и SNMPv3. [10] [11]
SNMP версии 1 (SNMPv1) — это начальная реализация протокола SNMP. Проект SNMPv1 был разработан в 1980-х годах группой сотрудников, которые считали официально спонсируемую OSI/IETF/NSF (Национальный научный фонд) работу (HEMS/CMIS/CMIP) как нереализуемую на вычислительных платформах того времени, так и потенциально неработоспособную. SNMP был одобрен на основе убеждения, что это временный протокол, необходимый для принятия мер по широкомасштабному развертыванию Интернета и его коммерциализации.
Первый запрос комментариев (RFC) для SNMP, теперь известный как SNMPv1, появился в 1988 году:
В 1990 году эти документы были заменены:
В 1991 году RFC 1156 (MIB-1) был заменен на более часто используемый:
SNMPv1 широко используется и является фактическим протоколом управления сетью в интернет-сообществе. [12]
SNMPv1 может передаваться с помощью протоколов транспортного уровня, таких как протокол пользовательских дейтаграмм (UDP), сетевая служба OSI без установления соединения (CLNS), протокол доставки дейтаграмм AppleTalk (DDP) и пакетный обмен между сетями Novell (IPX).
Версия 1 была подвергнута критике за ее слабую безопасность. [13] Спецификация, по сути, допускает использование пользовательской аутентификации, но широко используемые реализации «поддерживают только тривиальную службу аутентификации, которая идентифицирует все сообщения SNMP как подлинные сообщения SNMP». [14] Таким образом, безопасность сообщений становится зависимой от безопасности каналов, по которым сообщения отправляются. Например, организация может считать свою внутреннюю сеть достаточно защищенной, чтобы не требовалось никакого шифрования для ее сообщений SNMP. В таких случаях имя сообщества , которое передается в открытом виде , имеет тенденцию рассматриваться как фактический пароль, несмотря на исходную спецификацию.
SNMPv2, определенный RFC 1441 и RFC 1452, пересматривает версию 1 и включает улучшения в областях производительности, безопасности и коммуникаций между менеджерами. Он представил GetBulkRequest , альтернативу итеративным GetNextRequests для извлечения больших объемов данных управления в одном запросе. Новая система безопасности на основе сторон, представленная в SNMPv2, которую многие считали слишком сложной, не получила широкого распространения. [13] Эта версия SNMP достигла уровня зрелости Proposed Standard, но была признана устаревшей в более поздних версиях. [15]
Community-Based Simple Network Management Protocol версии 2 , или SNMPv2c , определен в RFC 1901– RFC 1908. SNMPv2c включает в себя SNMPv2 без спорной новой модели безопасности SNMP v2, используя вместо этого простую схему безопасности на основе сообщества SNMPv1. Эта версия является одним из относительно немногих стандартов, соответствующих уровню зрелости проекта стандарта IETF, и широко считалась фактическим стандартом SNMPv2. [15] Позднее она была переформулирована как часть SNMPv3. [16]
Протокол User-Based Simple Network Management Protocol версии 2 , или SNMPv2u , определен в RFC 1909– RFC 1910. Это компромисс, который пытается предложить большую безопасность, чем SNMPv1, но без высокой сложности SNMPv2. Один из вариантов был коммерциализирован как SNMP v2* , и этот механизм в конечном итоге был принят в качестве одной из двух инфраструктур безопасности в SNMP v3. [17]
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 не вносит никаких изменений в протокол, кроме добавления криптографической безопасности, он выглядит совсем иначе из-за новых текстовых соглашений, концепций и терминологии. [1] Наиболее заметным изменением было определение безопасной версии SNMP путем добавления улучшений безопасности и удаленной настройки в SNMP. [18] Аспект безопасности решается путем предложения как строгой аутентификации, так и шифрования данных для обеспечения конфиденциальности. Что касается аспекта администрирования, SNMPv3 фокусируется на двух частях, а именно на отправителях уведомлений и прокси-пересылателях. Изменения также облегчают удаленную настройку и администрирование объектов SNMP, а также решают проблемы, связанные с крупномасштабным развертыванием, учетом и управлением неисправностями.
Включены следующие функции и усовершенствования:
Безопасность была одной из самых слабых сторон SNMP до v3. Аутентификация в версиях SNMP 1 и 2 представляет собой не более чем пароль (строку сообщества), отправляемый в открытом тексте между менеджером и агентом. [1] Каждое сообщение SNMPv3 содержит параметры безопасности, закодированные в виде строки октетов. Значение этих параметров безопасности зависит от используемой модели безопасности. [20] Подход к безопасности в v3 нацелен на: [21]
v3 также определяет USM и VACM, за которыми позже последовала модель безопасности транспорта (TSM), обеспечивающая поддержку SNMPv3 через SSH и SNMPv3 через TLS и DTLS.
По состоянию на 2004 год [update]IETF признает Simple Network Management Protocol версии 3 , как определено в RFC 3411– RFC 3418 [22] (также известном как STD0062), в качестве текущей стандартной версии SNMP. IETF обозначил SNMPv3 как полный стандарт Интернета [23] , наивысший уровень зрелости для RFC. Он считает более ранние версии устаревшими (обозначая их по-разному как Historic или Obsolete [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, поэтому ошибки в настройке режима чтения-записи могут сделать сеть уязвимой для атак. [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 также может безопасно передаваться через Datagram Transport Layer Security (DTLS). [10]
Многие реализации SNMP включают тип автоматического обнаружения, при котором новый сетевой компонент, такой как коммутатор или маршрутизатор, обнаруживается и опрашивается автоматически. В SNMPv1 и SNMPv2c это делается с помощью строки сообщества , которая передается в открытом тексте на другие устройства. [10] Пароли в открытом тексте представляют собой значительный риск безопасности. Как только строка сообщества становится известна за пределами организации, она может стать целью для атаки. Чтобы предупредить администраторов о других попытках получить строки сообщества, SNMP можно настроить на передачу ловушек сбоев аутентификации имени сообщества. [27] : 54 Если используется SNMPv2, этой проблемы можно избежать, включив шифрование пароля на агентах SNMP сетевых устройств.
Распространенной конфигурацией по умолчанию для строк сообщества является «public» для доступа только для чтения и «private» для доступа для чтения и записи. [8] : 1874 Благодаря общеизвестным значениям по умолчанию, SNMP возглавил список распространенных проблем конфигурации по умолчанию института SANS и занял десятое место в списке 10 самых критических угроз безопасности Интернета SANS за 2000 год. [30] Системные и сетевые администраторы часто не меняют эти конфигурации. [8] : 1874
Независимо от того, работает ли он через TCP или UDP, SNMPv1 и v2 уязвимы для атак с подменой IP . С помощью подмены злоумышленники могут обойти списки доступа устройств в агентах, которые реализованы для ограничения доступа SNMP. Механизмы безопасности SNMPv3, такие как USM или TSM, могут предотвратить атаки с подменой.
InformRequest-PDU генерируется и передается по запросу приложения в сущности SNMPv2, действующей в роли менеджера, которое хочет уведомить другое приложение (в сущности SNMPv2, также действующей в роли менеджера) об информации в представлении MIB стороны, локальной по отношению к отправляющему приложению.
