Курс лекций «Проблемы безопасности в информационных технологиях»


Глава 8. Небезопасный протокол сетевого управления SNMP



жүктеу 4.51 Mb.
бет33/44
Дата13.09.2017
өлшемі4.51 Mb.
түріКурс лекций
1   ...   29   30   31   32   33   34   35   36   ...   44

Глава 8. Небезопасный протокол сетевого управления SNMP


Рассмотрение проблем безопасности протокола SNMP стоит несколько особняком от проблем безопасности, существующих в других прикладных протоколах. Как и другие «старые» протоколы, имеющие в своём названии определение Simple (тот же SMTP), SNMP в своих первых версиях имел очень уязвимую архитектуру. И если подделка пакета в протоколе передачи почты (SMTP) может привести всего лишь к искажению почтового сообщения, то одна единственная SNMP-дейтаграмма с соответствующим содержимым, отправленная в адрес одного единственного устройства, может вызвать полный отказ в работе всей сети. В SNMP интересно сочетание огромной мощи по возможности контроля и управления ключевыми устройствами в сети и при этом чрезвычайно низкого уровня безопасности этого протокола.

SNMP (Simple Network Management Protocol — простой протокол сетевого управления) — стандартный интернет-протокол для управления устройствами в IP-сетях на основе UDP/TCP. К поддерживающим SNMP устройствам относятся маршрутизаторы, коммутаторы, серверы, рабочие станции, принтеры, модемные стойки и многие другие. Протокол обычно используется в системах сетевого управления для контроля подключённых к сети устройств на предмет условий, которые требуют внимания администратора. SNMP определен Инженерным советом интернета (IETF) как компонент TCP/IP. Он состоит из набора стандартов для сетевого управления, включая протокол прикладного уровня, схему баз данных и набор объектов данных.

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

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

Агенты SNMP передают данные из управляемых систем в виде переменных. Протокол также разрешает активные задачи управления, например, изменение и применение новой конфигурации через удаленное изменение этих переменных. Доступные через SNMP переменные организованы в иерархии. Эти иерархии, как и другие метаданные (например, тип и описание переменной), описываются базами управляющей информации (базы MIB – Management information base).

Управляемые протоколом SNMP сети состоят из трех ключевых компонентов:




  • Управляемое устройство;

  • Агент — специальное програмнное обеспечение, запускаемое на управляемом устройстве;

  • Система сетевого управления (Network Management System, NMS) — программное обеспечение, запускаемое на менеджере.


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

Агентом называется программный модуль сетевого управления, располагающийся на управляемом устройстве. Агент обладает локальным знанием управляющей информации и переводит эту информацию в специфичную для SNMP форму или из неё.

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

Сам по себе протокол SNMP не определяет, какая информация и переменные должны быть предложены управляемой системой. Вместо этого SNMP использует расширяемую схему работы, в котором доступная информация определяется базами управляющей информации (базы MIB). Базы MIB описывают структуру управляемых данных на подсистеме устройства; они используют иерархическое пространство имен, содержащее идентификаторы объектов (OID-ы). Каждый OID определяет переменную, которая может быть считана либо установлена с помощью SNMP. Базы MIB используют нотацию, заданную в ASN.1(Abstract Syntax Notation One).




Рис.110 Структура дерева MIB
SNMP работает на прикладном уровне TCP/IP (седьмой уровень модели OSI). Агент SNMP получает запросы по UDP-порту 161. Менеджер может посылать запросы с любого доступного порта источника на порт агента. Ответ агента будет отправлен назад на порт источника на менеджере. Менеджер получает уведомления (Traps и InformRequests) по порту 162. Агент может генерировать уведомления с любого доступного порта. При использовании TLS или DTLS запросы принимаются на порту 10161, а ловушки (traps) отправляются на порт 10162.

Менеджер может запросить чтение какой-либо переменной/-ых (запросы Get…), модификацию (запись) (запросы Set…). Третий возможный вариант обмена: ловушка (trap) – асинхронное уведомление от агента к менеджеру. Включает в себя текущее значение sysUpTime, OID, определяющий тип trap, и необязательные связанные переменные. Адресация получателя для trap определяется с помощью переменных trap-конфигурации в базе MIB. Формат trap-сообщения был изменен в SNMPv2 и PDU (protocol data units) переименовали в SNMPv2-Trap. Ещё один тип обмена: InformRequest – асинхронное уведомление от менеджера – менеджеру или от агента – менеджеру. Уведомления от менеджера - менеджеру были возможны уже в SNMPv1 (с помощью trap), но SNMP обычно работает на протоколе UDP, в котором доставка сообщений не гарантирована и не сообщается о потерянных пакетах. InformRequest исправляет это отправлением назад подтверждения о получении. Получатель отвечает пакетом Response1, повторяющим всю информацию из InfromRequest. Этот PDU был введен в SNMPv2.

Реализации SNMP варьируются среди поставщиков платформ. В отдельных случаях, SNMP не считается достаточно серьезным для элемента основной разработки и потому является просто дополнительной функцией. Но большинство крупных разработчиков, в первую очередь сетевых устройств, обеспечивают очень широкую поддержку SNMP, включая туда возможности мониторинга и управления десятками, сотнями, а иногда и тысячами переменных. Рекордсменом среди производителей, поддерживающих SNMP, можно считать компанию Cisco – ей принадлежит наибольшее количество разработанных баз MIB. Вторым производителем по этому показателю сегодня является компания Hewlett Packard (HP). Эти же две компании, в том же порядке, занимают места в списке крупнейших поставщиков сетевого оборудования класса коммутаторов.

Безопасность в исходном варианте SNMPv1 была реализована на совершенно неудовлетворительном уровне. Для аутентификации используется т.н. строка сообщества (community string), которая делит агентов на сообщества с определенными правами, по сути, реализуя парадигму пароля на ресурс (напоминает модель разграничения доступа в сетях Windows 95).

Строка community (чувствительная к регистру символов, case sensitivity) передаётся в открытом виде, т.е. обмен подвержен перехвату пакетов. То же самое относится и к SNMPv2c2. Все версии SNMP (включая v3) подвержены атакам грубой силой и словарным переборам для угадывания строк сообщества, строк аутентификации, ключей аутентификации, строк шифрования или ключей шифрования, поскольку они не используют «рукопожатие» вида запрос-ответ.

SNMP возглавляет составленный SANS Institute список "Common Default Configuration Issues" в категории установки строк community по умолчанию ("public" для чтения и "private" на модификацию) и занимал десятую позицию в SANS Top 10 Самых критических угроз Интернет-безопасности за 2000 год. Очень многие администраторы, недооценивая потенциальные угрозы, исходящие от протокола SNMP, оставляют его включённым с умолчательными настройками. Только в последние годы производители сетевого оборудования, наконец-то, дошли до простой мысли: протокол SNMP в их устройствах всё чаще исходно оказывается выключенным.

Несколько лет назад группа исследователей обнаружила уязвимость в базовой библиотеке ASN.1, которую использует SNMP. Речь шла о банальном переполнении буфера. Последствия были фантастическими – как оказалось, практически все, без исключения реализации SNMP на всех распространённых системах, использовали эту библиотеку. И все(!) системы в мире, поддерживающие SNMP, оказались уязвимы, с вариантами уязвимостей от удалённого отказа в обслуживании до возможности выполнения произвольных привилегированных команд в системе. Обновлять подсистему SNMP пришлось буквально на всех операционных ОС, но для некоторых старый версий обновления так и не были выпущены!

Иногда в части обеспечения безопасности в SNMP можно было встретить просто удивительные по своей нелепости и безответственности решения. В конце 1990-х компания 3Com выпускала много сетевого оборудования, в котором была реализована достаточно хорошая поддержка протокола SNMP. Поддержка, в частности, подразумевает публикацию производителем баз управляющей информации MIB, описывающих множество управляемых переменных для конкретного устройства. Как выяснилось, 3Com часть переменных в своих устройствах не описывала, видимо понадеявшись на известный принцип security by obscurity. Кому-то пришло в голову просканировать всю иерархию объектов, просто перебрав все возможные разумные числовые сочетания полей. И были получены ответы на запросы к «несуществующим» объектам. В частности, такие «скрытые» переменные в семействе коммутаторов LanPlex содержали имя и пароль специального служебного пользователя, имевшего привилегии даже выше, чем администратор! Имя этого пользователя – debug – говорит за себя: войдя в систему под этим именем, пользователь получал доступ к очень опасным и чувствительным элементам управления устройства. Когда информация о «скрытых» переменных распространилась достаточно широко, 3Com вынуждена была публично извиняться и оповещать владельцев своих устройств о тех мерах «безопасности», которые они в эти устройства внедрили.

В подобной безответственности была замечена не только 3Com – в своё время в списке рассылки bugtraq была опубликована информация о несанкционированном доступе к AVAYA Cajun. SNMP-community NoGaH$@! предоставлялала полный доступ к устройству. Также были обнаружены недокументированные учетные записи diag/danger и manuf/xxyyzz для этих устройств.

Кардинальная попытка улучшить безопасность SNMP была предпринята при разработке версии v3 протокола (1997 год). В него была добавлена криптографическая поддержка, которая, среди прочего, заметно увеличила требования к производительности управляющего процессора устройств и объёмам доступного для агента ОЗУ3. В SNMPv3, пользователям стали доступны новые службы, такие как: ограничение доступа, защита данных и аутентификация пользователя (RFC2271-2275).

В SNMPv3 уже не применяются термины «агент» и «менеджер», вместо них используются термины «сущности». Как и раньше, одна сущность находится на управляемом устройстве, а вторая занимается опросом приложений.


Рис.111 Схема работы ядра SNMPv3
У сущностей-агентов и сущностей-менеджеров теперь есть ядро, которое выполняет четыре основные функции:


  1. функции диспетчера;

  2. обработка сообщений;

  3. функции безопасности;

  4. контроль доступа.



Диспетчер – это простая система управления входящим и исходящим трафиком. Для каждого исходящего блока данных (PDU) он определяет тип необходимой обработки (SNMPv1, SNMPv2, SNMPv3) и передает блок данных соответствующему модулю в системе обработки сообщений. После того как система обработки сообщений вернёт сообщение, которое содержит этот блок данных, Диспетчер отправит его на транспортный уровень для последующей передачи. Для входящих сообщений, Диспетчер проводит обратную операцию.

Система обработки сообщений получает от Диспетчера исходящие блоки данных (PDU), добавляет к ним подходящий заголовок и возвращает их обратно Диспетчеру.

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

Система контроля доступа управляет службами аутентификации для контроля доступа к MIB, исходя из содержимого блоков данных (PDU). Теоретически, система контроля доступа может работать с самыми разными моделями контроля доступа, но на данный момент в RFC2275 описана только одна модель – VACM (View-BasedAccessControlModel).

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

Основные проблемы, которые необходимо было решить при помощи модели USM:


  1. Изменение данных сущностями, не прошедшими аутентификацию;

  2. Возможность откладывания каких-либо действий на неопределенное время или повторение одних и тех же действий с произвольными интервалами;

  3. Возможность заблокировать обмен данными между сущностями;

  4. Возможность перехвата трафика при передаче между сущностями;

  5. Возможность «маскарада», когда сущность, не прошедшая аутентификацию, могла представиться сущностью, прошедшей аутентификацию.

Проблемы были решены следующим образом: для каждого сетевого устройства пароль преобразуется в некоторый уникальный ключ. Это обеспечивает дополнительную безопасность, т.к. даже в том случае, если ключ будет перехвачен, злоумышленник получит доступ только к одному сетевому устройству. Для шифрования (хеширования) пароля используется алгоритм MD5, но разработчики видимо решили, что это не обеспечит достаточной сохранности пароля и поэтому блок PDU дважды хешируется при помощи двух разных ключей, которые в свою очередь генерируются из закрытого ключа. Позже первые 12 октетов используются как код аутентификации сообщения, который добавляется к сообщению. Такой же процесс приходится производить на другой стороне, но только в обратном порядке. Несмотря на сложность и ресурсоёмкость процесса передачи данных между сущностями SNMP, по мнению разработчиков, алгоритм шифрования (DES) на самом деле не обеспечивает достаточной защиты информации, поэтому в дальнейшем предполагается использовать другие алгоритмы. Например, алгоритм Диффи-Хеллмана или CBC-AES-128.

Протокол SNMPv3 решил многие проблемы безопасности, но часть проблем всё же осталась. В частности:


  • Маскарадинг – проблема устранена, система проверяет происхождение пакетов;

  • Модификация – протокол проверяет целостность при помощи MD5;

  • Угроза раскрытия – шифрование средствами DES;

  • Анализ трафика – SNMPv3 по-прежнему УЯЗВИМ;

  • Отказ в обслуживании – УЯЗВИМ.

Но одна из главных проблем безопасности SNMP сегодня лежит за пределами собственно протокола и его модернизации. Как уже упоминалось выше, добавление функционала «управляемости» заметно – в разы – удорожает сетевое устройство, например, такое как гигабитный Ethernet-коммутатор. Поэтому, несмотря на довольно солидный возраст протокола SNMPv3, уже довольно давно и весьма неплохо улучившего безопасность SNMP, его поддержка обычно существует только в относительно дорогих и продвинутых устройствах. А очень и очень многие устройства попроще и подешевле и сегодня зачастую обходятся протоколами версий v1 и v2c, с очевидными последствиями для безопасности.






Достарыңызбен бөлісу:
1   ...   29   30   31   32   33   34   35   36   ...   44


©kzref.org 2019
әкімшілігінің қараңыз

    Басты бет