The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Идентификация и взаимодействие с удаленными системами через SNMP (snmp security auth)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: snmp, security, auth,  (найти похожие документы)
Date: Sat, 15 Oct 2002 02:10:36 +0400 From: Bobby Quine <research@bk.ru> Subject: Идентификация и взаимодействие с удаленными системами через SNMP Оригинал статьи: http://void.ru/content/1030 http://void.ru/content/1031 Идентификация и взаимодействие с удаленными системами через SNMP. 1. Введение Для многих людей, увлекающихся исследованием сетей, рано или поздно вставала проблема идентификации удаленной системы и получения как можно больше информации о ней. На сегодняшний день существует множество способов идентификации систем. Не вдаваясь в подробности (все-таки тема немного другая), можно выделить следующие: - перечень открытых портов - изучение маркеров сетевых сервисов (telnet, ftp, sendmail, pop, etc) - использование программ, осуществляющих активное исследование стека TCP/IP (например queso) - использование тестов на основе известных сигнатур различных операционных систем и сетевых устройств (такое исследование осуществляет утилита nmap от Fyodor при добавлении опции -O) - пассивное исследование стека протокола TCP/IP - использование HTTP команд (например при telnet подключении к 80 порту сервера) - использование специализированых сканеров безопасности Это лишь некоторые из способов идентификации удаленной системы. В данной статье, не претендующей на абсолютную грамотность, освещены некоторые аспекты функционирования протокола SNMP, которые могут быть полезны при взаимодействии с удаленными хостами. 2. SNMP Как известно, SNMP переводится как Simple Network Management Protocol (упрощенный протокол сетевого управления). Данный протокол использует UDP-порты 161 и 162. SNMP был разработан с целью отправки запросов сетевым элементам (хосты, гейтвеи, серверы и др.) для проверки и изменения их настроек. Данный протокол близок к принципу "клиент-сервер". Роль сервера выполняют агенты, то есть опрашиваемые сетевые устройства, а роль клиентов выполняют системы управления, то есть сетевые приложения, которые, собственно, собирают информацию. На данный момент существуют три версии протокола, которые имеют общую базисную архитектуру. 1. SNMPv1 (читай RFC 1157). Основная проблема безопасности этой версии состояла в том, что единственным механизмом защиты являлись пароли (community string), которые пересылались в незашифрованном виде. 2. SNMPv2 (читай RFC 1146). В данной версии протокола вопросам безопасности было уделено больше внимания. В частности, были добавлены: функции хэширования по алгоритму MD5, установка временных меток для избежания повторения и ретрансляции сообщений, поддержка криптования по алгоритму DES для сохранения конфиденциальности информации, новые возможности администрирования, защита паролей и удаленной настройки конфигурации. 3. SNMPv3 (читай RFC 2571). Этот стандарт является усовершенствованием второй версии. Помимо всех особенностей присутствующих во второй версии, упрощена схема установки и управления, без потери безопасности. 3. Безопасность Согласно RFC 2574, безопасность в SNMP осуществляется при помощи так называемой пользовательской модели безопасности (user-based security model, USM). Данная модель защищает от двух основных и двух второстепенных типах угроз: - модификация информации - маскарадинг - изменения в потоке сообщений - угроза раскрытия данных В структуру USM входит алгоритм хэширования MD5 для обеспечения целостности информации, который защищает от атак модификации данных. Против изменений в потоке сообщений используется синхронизация с выставлением временных меток. Как противодействие угрозе раскрытия данных осуществляется шифрование по алгоритму DES. Следует отметить, что использование данной опции является выборочным, т. е. на некоторых системах она может быть не активирована. 4. Практика После этого краткого обзора о принципах работы SNMP настало время поговорить о том, как можно использовать достоинства и недостатки этого протокола при взаимодействии с удалеными системами. Вся информация о состоянии и настройках сетевых элементов находится в MIB (Management Information Base), Базе Управляющей Информации, которая представляет собой собрание модулей с данными. Обратиться к модулям можно при помощи специальных запросов. Среди них можно выделить: GetRequest, SetRequest, GetNextRequest и др. К сожалению, большинство модулей доступны к чтению с них информации, а некоторые и для записи. Правильная настройка предполагает работу с конфигурационными файлами и ядром, чего многие системные администраторы не любят. По умолчанию, остаются две группы данных "private" и "public". Утилиты, которые используются для опроса сетевых элементов, как правило, уходят в стандартный дистрибутив операционной системы Linux. В Red Hat 7.2 входит пакет: ucd-snmp-utils-4.2.1-7.i386.rpm Устанавливаем пакет: rpm -i ucd-snmp-utils-4.2.1-7.i386.rpm После установки появляются программы: /usr/bin/snmpbulkget /usr/bin/snmpbulkwalk /usr/bin/snmpcheck /usr/bin/snmpconf /usr/bin/snmpdelta /usr/bin/snmpdf /usr/bin/snmpget /usr/bin/snmpgetnext /usr/bin/snmpinform /usr/bin/snmpnetstat /usr/bin/snmpset /usr/bin/snmpstatus /usr/bin/snmptable /usr/bin/snmptest /usr/bin/snmptranslate /usr/bin/snmptrap /usr/bin/snmpusm /usr/bin/snmpvacm /usr/bin/snmpwalk При помощи этих утилит можно узнать практически ВСЮ системную информацию об удаленной системе (начиная от операционной системы и заканчивая активными сетевыми интерфейсами). Главное-RTFM! Например, утилита snmpget посылает запросы хостам, snmpset-устанавливает значение в MIB (при наличии прав записи) и т.д. Пример: #/usr/bin/snmpget target.com public system.sysDescr.0 Linux hostname 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 #/usr/bin/snmpget target.com public system.sysContact.0 system.sysContact.0 = root@target.com #/usr/bin/snmpget target.com public system.sysName.0 system.sysName.0 = target Существует огромное количество параметров, которые хранятся в MIB. Если вам понадобился весь список данных, то наилучшим выбором будет утилита snmpwalk. #/usr/bin/snmpwalk target.com public При использовании этой утилиты выводится огромная база информации о системе: имя хоста, операционная система, меторасположение компьютера, системные интерфейсы, активные сетевые интерфейсы, IP и MAC адреса, с которыми устанавливались соединения недавно, информация о сети и маршрутизации, информация о состоянии открытых портов (этот способ гораздо надежнее сканирования, т.к. нет никаких препятствий в виде брандмауэров). Надеюсь, эта статья окажется полезной для общественности. При возникновении вопросов - читай man или RFC. Добавлено: 5. Обеспечение безопасности SNMP. Первым шагом к защите данного протокола будет запрет доступа на SNMP-порты (см. выше) для всех компьютеров, за исключением тех, кому будет действительно необходим санкционированное подключение. Это можно осуществить при помощи правил iptables/ipchains. Системным администраторам рекомендуется следить за тем, какая информация об их системе предоставляется по умолчанию. Также необходимо логгирование попыток несанкционированого доступа. Безусловно, рекомендуется отказ от первой версии SNMP, т.к. защита реализована действительна на очень низком уровне (что поделать, когда разрабатывалась первая версия к Интернет подключались, в основном, люди знающие и порядочные). Но, как я прочитал в одной книге, "лучшая защита от SNMP-атак - не использовать протокол SNMP". RFCs: http://www.ietf.cnri.reston.va.us/rfc/ http://www.faqs.org
Обеспечение безопасности SNMP. Введение. Данная статья является логическим продолжением материала "Идентификация и взаимодействие с удаленной системой через SNMP", в котором были даны базисные принципы функционирования данного протокола. Целью этой работы является освещение необходимых мер для обеспечения должного уровня защиты SNMP. Хотелось бы попросить прощения у читателя за то, что некоторые моменты из предыдущего материала будут повторяться - это необходимо для более полного обзора данного вопроса. Информация общего характера здесь будет представлена в минимальном объеме; для лучшего восприятия материала советую прочитать первую статью. Угрозы. Проблемы с протоколом SNMP начались с первой версии, когда механизма защиты не было как такового. Любой желающий мог узнать пароли просто прослушивая сеть. Но через некоторое время вышла вторая версия, в которой, в соответствии с требованиями времени, были реализованы более серьезные функции защиты. В частности, хэширование при помощи MD5, шифрование по DES и др. (см. первую статью). На сегодняшний момент последней является третья версия SNMP, разработчики которой основной задачей видят обеспечение безопасности. Однако, не все так гладко с безопасностью даже и у третьей версии. Существует 6 видов угроз для SNMP (добавлено 2 типа по сравнению с прошлой статьей). 1. Раскрытие информации: отслеживание обмена данными между агентами и управляющей станцией с целью сбора значений. 2. Маскарадинг 3. Модификации: посылка сообщений для фиктивных операций 4. Модификации в потоке сообщений 5. Анализ сетевого трафика 6. Атаки отказа в обслуживании. Рассмотрим, как кажется, наиболее защищенную третью версию SNMP в свете противодействиям этим типам атак. Атака Противодействие SNMPv3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Маскарадинг Проверяет происхождение пакетов Модификация Проверяет целостность при помощи MD5 Угроза раскрытия Криптование при помощи DES Анализ трафика ----УЯЗВИМА---- Отказ в обслуживании ----УЯЗВИМА---- Итак, как оказалось даже 3 версия уязвима для некоторых типов атак. В частности, набор утилит ucd-snmp версий 5.0.1, 5.0.3, 5.0.4.pre2, который включает в себя SNMP демон, утилиты для опроса и установления значений MIB, а также другие полезные особенности уязвим для атаки отказа в обслуживании. Уязвимость была найдена Andrew Griffiths и анонсирована компанией iDEFENSE (www.idefense.com) 2 октября 2002. Решением проблем такого плана может быть только регулярное обновление программного обеспечения. Одной из самых распостраненных проблем даже по сей день являются пароли (community strings) по умолчанию. В который раз хочется отметить, что установки по умолчанию НЕОБХОДИМО менять. Решением послужит тщательное изучение страниц man по следующим файлам: snmp.conf, snmp_config, snmpcmd, в которых содержится информация по конфигурации SNMP и работе файлов. Даже при простом изменении значения по умолчанию "public" на более сложный пароль, злоумышленник уже не сможет получить информацию о Вашей системе при помощи тривиальной утилиты snmpwalk. Множество сетевых устройств (switches, WAN/LAN роутеры, модемы, а также некоторые операцинные системы) по умолчанию сконфигурированы с активированым SNMP и даже с rw доступом(!). Последствия такой небрежности предсказать несложно. Вот небольшой список, для примера, устройств с паролями по умолчанию: - 3com Switch 3300 (3Com SuperStack II) - private - Cray MatchBox router (MR-1110 MatchBox Router/FR 2.01) - private - 3com RAS (HiPer Access Router Card) - public - Prestige 128 / 128 Plus - public - COLTSOHO 2.00.21 - private - PRT BRI ISDN router - public - CrossCom XL 2 - private - WaiLAN Agate 700/800 - public - HPJ3245A HP Switch 800T - public - ES-2810 FORE ES-2810, Version 2.20 - public - Windows NT Version 4.0 - public - Windows 98 (не 95) - public - Sun/SPARC Ultra 10 (Ultra-5_10) - private Кстати, 16 октября в списке рассылки bugtraq была опубликована новая информация о несакционированном доступе к AVAYA Cajun. SNMP-community NoGaH$@! позволяет полный доступ. Также были приведены недокументированные учетные записи diag/danger и manuf/xxyyzz. Решением таких проблем послужит ограничение rw доступа, запрещение доступа к устройствам с активированым SNMP извне. Необходимо запретить доступ на SNMP-порты для всех посторонних компьютеров. Осуществить это довольно просто, достаточно использовать набор правил ipchains/iptables. Дать совет по настройке ipchains довольно сложно, т.к. необходимо знать топологию локальной сети, а для домашних рабочих станций SNMP не нужен. Для любого системного администратора, который имеет дело с данным протоколом, необходимы программы, которые бы упрощали работу с SNMP. В связи с этим можно упомянуть MRTG и SNMP::Monitor. На взгляд автора пакета SNMP::Monitor, его программа имеет преимущества по сравнению с MRTG (какие именно, Вы можете прочитать в readme). Скачать SNMP::Monitor можно с архивов packetstormsecurity.org. Вот лишь некоторые из ее функций: - запуск постоянного процесса, который будет следить за сетевыми интерфейсами и вести логи в базу данных - предоставление графического интерфейса через WWW - показ статистики - включает в себя систему контроля доступа к данным и др. Определенно необходимо логгирование отказов в предоставлении SNMP сервиса неавторизованным хостам и последующий анализ журналов. Если Вы хотите проверить уязвимость Вашей сети, то неплохой программой будет snmpsniff, перехватчик трафика. Загрузить ее можно с: www.packetstormsecurity.org/sniffers/snmpsniff-1.0.tar.gz Для проверки надежности паролей можно использовать snmpbrute.c, который является довольно быстрым переборщиком паролей. Итак, в данной работе я попытался насколько это возможно осветить вопросы безопасной работы SNMP. Если что-то пропустил, то буду благодарен за подсказку. Спасибо за комментарии, которые натолкнули написать продолжение.

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ RSS ]
  • 1, Аноним (1), 23:40, 31/03/2003 [ответить]  
  • +/
    Не могли бы Вы написать подробнее об отказе в обслуживании.
    Спасибо
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру