SNMP протокол - принципы, безопасность, применение. (snmp)
Ключевые слова: snmp, (найти похожие документы)
From: Благодарный Евгений <admin@titanicum.kiev.ua>.
Subject: SNMP протокол - принципы, безопасность, применение.
SNMP протокол - принципы, безопасность, применение.
Автор: Благодарный Евгений <admin@titanicum.kiev.ua>.
Вступление
Данная статья посвящена протоколу SNMP (Simple Network Management
Protocol) - одному из протоколов модели OSI, который практически не
был затронут в документации просторов RU-нета. Автор попытался
заполнить этот вакуум, предоставив читателю почву для размышлений и
самосовершенствования, касательно этого, возможно нового для Вас,
вопроса. Этот документ не претендует на звание "документации для
разработчика", а просто отражает желание автора, насколько это
возможно, осветить аспекты работы с данным протоколом, показать его
слабые места, уязвимости в системе "security", цели преследованные
создателями и объяснить его предназначение.
Предназначение
Протокол SNMP был разработан с целью проверки функционирования сетевых
маршрутизаторов и мостов. Впоследствии сфера действия протокола
охватила и другие сетевые устройства, такие как хабы, шлюзы,
терминальные сервера, LAN Manager сервера , машины под управлением
Windows NT и т.д. Кроме того, протокол допускает возможность внесения
изменений в функционирование указанных устройств.
Теория
Основными взаимодействующими лицами протокола являются агенты и
системы управления. Если рассматривать эти два понятия на языке
"клиент-сервер", то роль сервера выполняют агенты, то есть те самые
устройства, для опроса состояния которых и был разработан
рассматриваемый нами протокол. Соответственно, роль клиентов отводится
системам управления - сетевым приложениям, необходимым для сбора
информации о функционировании агентов. Помимо этих двух субъектов в
модели протокола можно выделить также еще два: управляющую информацию
и сам протокол обмена данными.
"Для чего вообще нужно производить опрос оборудования?" - спросите Вы.
Постараюсь пролить свет на этот вопрос. Иногда в процессе
функционирования сети возникает необходимость определить определенные
параметры некоторого устройства, такие как , например, размер MTU,
количество принятых пакетов, открытые порты, установленную на машине
операционную систему и ее версию, узнать включена ли опция форвардинга
на машине и многое другое. Для осуществления этого как нельзя лучше
подходят SNMP клиенты.
Помимо сказанного выше рассматриваемый протокол обладает еще одной
весьма важной особенностью, а именно возможностью модифицировать
данные на агентах. Безусловно, было бы глупостью разрешить модификацию
абсолютно любого параметра, но ,не смотря на это, и количество тех
параметров, для которых допускается операция записи просто пугает. С
первого взгляда это полностью опровергает всю теорию сетевой
безопасности, но, если углубиться в вопрос, то становится ясно, что не
все так запущено, как кажется с первого взгляда. "Волков бояться - в
лес не ходить". Ведь при небольших усилиях администратора сети можно
свести риск успешного завершения атаки к минимуму. Но этот аспект мы
обсудим позже.
Остановимся на том, какую же все-таки информацию может почерпнуть
система управления из недр SNMP. Вся информация об объектах
системы-агента подержится в так называемой MIB (management information
base ) - базе управляющей информации, другими словами MIB представляет
собой совокупность объектов, доступных для операций записи-чтения для
каждого конкретного клиента, в зависимости от структуры и
предназначения самого клиента. Ведь не имеет смысла спрашивать у
терминального сервера количество отброшенных пакетов, так как эти
данные не имеют никакого отношения к его работе, так как и информация
об администраторе для маршрутизатора. Потому управляющая система
должна точно представлять себе, что и у кого запрашивать. На данный
момент существует четыре базы MIB :
1) Internet MIB - база данных объектов для обеспечения диагностики
ошибок и конфигураций. Включает в себя 171 объект (в том числе и
объекты MIB I).
2) LAN manager MIB - база из 90 объектов - пароли, сессии,
пользователи, общие ресурсы.
3) WINS MIB - база объектов, необходимых для функционирования WINS
сервера (WINSMIB.DLL).
4) DHCP MIB - база объектов, необходимых для функционирования DHCP
сервера (DHCPMIB.DLL), служащего для динамического выделения IP
адресов в сети.
Все имена MIB имеют иерархическую структуру. Существует десять
корневых алиасов:
1) System - данная группа MIB II содержит в себе семь объектов, каждый
из которых служит для хранения информации о системе (версия ОС, время
работы и т.д.).
2) Interfaces - содержит 23 объекта, необходимых для ведения
статистики сетевых интерфейсов агентов (количество интерфейсов, размер
MTU, скорость передачи , физические адреса и т.д.) .
3) AT (3 объекта) - отвечают за трансляцию адресов. Более не
используется. Была включена в MIB I. Примером использования объектов
AT может послужить простая ARP таблица (более подробно об ARP
протоколе можно почитать в статье "Нестандартное использование
протокола ARP", которую можно найти на сайте http://www.uinc.ru в разделе
"Articles" ) соответствия физических (MAC) адресов сетевых карт IP
адресам машин. В SNMP v2 эта информация была перенесена в MIB для
соответствующих протоколов.
4) IP (42 объекта) - данные о проходящих IP пакетах (количество
запросов, ответов, отброшенных пакетов).
5) ICMP (26 объектов) - информация о контрольных сообщениях
(входящие/исходящие сообщения, ошибки и т.д.).
6) TCP (19) - все, что касается одноименного транспортного протокола
(алгоритмы, константы, соединения, открытые порты и т.п.).
7) UDP (6) - аналогично, только для UDP протокола (входящие/исходящие
датаграммы, порты, ошибки).
8) EGP (20) - данные о трафике Exterior Gateway Protocol (используется
маршрутизаторами, объекты хранят информацию о
принятых/отосланных/отброшенных кардах).
9) Transmission - зарезервирована для специфических MIB.
10) SNMP (29) - статистика по SNMP - входящие/исходящие пакеты,
ограничения пакетов по размеру, ошибки, данные об обработанных
запросах и многое другое.
Каждый из них представим в виде дерева, растущего вниз, (система до
боли напоминает организацию DNS). Например, к адресу администратора мы
можем обратиться посредством такого пути: system.sysContact.0 , ко
времени работы системы system.sysUpTime.0 , к описанию системы
(версия, ядро и другая информация об ОС) : system.sysDescr.0 . С
другой стороны те же данные могут задаваться и в точечной нотации. Так
system.sysUpTime.0 соответствует значение 1.3.0, так как system имеет
индекс "1" в группах MIB II, а sysUpTime - 3 в иерархии группы system.
Ноль в конце пути говорит о скалярном типе хранимых данных. Ссылку на
полный список (256 объектов MIB II) Вы можете найти в конце статьи в
разделе "Приложение". В процессе работы символьные имена объектов не
используются, то есть если менеджер запрашивает у агента содержимое
параметра system.sysDescr.0, то в строке запроса ссылка на объект
будет преобразована в "1.1.0", а не будет передана "как есть". Далее
мы рассмотрим BULK-запрос и тогда станет ясно, почему это столь важно
. На этом мы завершим обзор структуры MIB II и перейдем
непосредственно к описанию взаимодействия менеджеров (систем
управления) и агентов. В SNMP клиент взаимодействует с сервером по
принципу запрос-ответ. Сам по себе агент способен инициировать только
оно действие, называемое ловушкой прерыванием (в некоторой литературе
"trap" - ловушка). Помимо этого, все действия агентов сводятся к
ответам на запросы, посылаемые менеджерами. Менеджеры же имеют гораздо
больший "простор для творчества", они в состоянии осуществлять четыре
вида запросов:
GetRequest - запрос у агента информации об одной переменной.
GetNextRequest - дает агенту указание выдать данные о следующей (в
иерархии) переменной.
GetBulkRequest - запрос за получение массива данных. При получении
такового, агент проверяет типы данных в запросе на соответствие данным
из своей таблицы и цикле заполняет структуру значениями параметров:
for(repeatCount = 1; repeatCount < max_repetitions; repeatCount++)
Теперь представьте себе запрос менеджера на получение списка из сотни
значений переменных , посланный в символьном виде, и сравните размер
такового с размером аналогичного запроса в точечной нотации. Думаю, Вы
понимаете, к чему привела бы ситуация, если бы символьные имена не
преобразовывались вышеуказанным образом.
SetRequest - указание установить определенное значение переменой.
Кроме этого менеждеры могут обмениваться друг с другом информацией о
своей локальной MIB. Такой тип запросов носит название InformRequest.
Приведу значения числовых констант для всех видов запросов:
#define SNMP_MSG_GET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x0)
#define SNMP_MSG_GETNEXT (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x1)
#define SNMP_MSG_RESPONSE (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x2)
#define SNMP_MSG_SET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x3)
/* PDU для SNMPv1 */
#define SNMP_MSG_TRAP (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x4)
/* PDU для SNMPv2 */
#define SNMP_MSG_GETBULK (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x5)
#define SNMP_MSG_INFORM (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x6)
#define SNMP_MSG_TRAP2 (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x7)
Вот тут то мы сталкиваемся с еще одной интересной деталью, как видите
для ловушке есть 2 числовые константы. На самом деле существует 2
основные версии протокола SNMP (v1 & v2) и самое важное то, что они не
являются совместимыми (на самом деле версий значительно больше -SNMP
v2{p | c | u} etc, только все эти модификации довольно незначительны,
так как , например, введение поддержки md5 и т.п.).
SNMP - протокол контроля и диагностики, в связи с чем , он рассчитан
на ситуации, когда нарушается целостность маршрутов, кроме того в
такой ситуации требуется как можно менее требовательный с аппаратуре
транспортный протокол , потому выбор был сделан в сторону UDP. Но это
не значит, что никакой другой протокол не может переносить пакеты
SNMP. Таковым может быть IPX протокол (например, в сетях NetWare) ,
также в виде транспорта могут выступать карды Ethernet, ячейки ATM.
Отличительной особенностью рассматриваемого протокола есть то, что
передача данных осуществляется без установки соединения.
Допустим менеджер послал несколько пакетов разным агентам, как же
системе управления в дальнейшем определить какой из приходящих пакетов
касается 1ого и 2ого агента? Для этого каждому пакету приписывается
определенный ID - числовое значение. Когда агент получает запрос от
менеджера, он генерирует ответ и вставляет в пакет значение ID ,
полученное им из запроса (не модифицирую его). Одним из ключевых
понятий в SNMP является понятие group (группа). Процедура авторизации
менеджера представляет собой простую проверку на принадлежность его к
определенной группе, из списка, находящегося у агента. Если агент не
находит группы менеджера в своем списке, их дальнейшее взаимодействие
невозможно. До этого мы несколько раз сталкивались с первой и второй
версией SNMP. Обратим внимание на отличие между ними. Первым делом
заметим, что в SNMP v2 включена поддержка шифрования трафика, для
чего, в зависимости от реализации, используются алгоритмы DES, MD5 .
Это ведет к тому что при передаче данных наиболее важные данные
недоступны для извлечения сниффингом, в том числе и информация о
группах сети. Все это привело в увеличению самого трафика и усложнению
структуры пакета. Сам по себе, на данный момент, v2 практически нигде
не используется. Машины под управлением Windows NT используют SNMP v1.
Таким образом мы медленно переходим к, пожалуй, самой интересной части
статьи, а именно к проблемам Security. Об этом давайте и поговорим ...
Практика и безопасность
В наше время вопросы сетевой безопасности приобретают особое значение,
особенно когда речь идет о протоколах передачи данных, тем более в
корпоративных сетях. Даже после поверхностного знакомства с SNMP v1/v2
становится понятно, что разработчики протокола думали об этом в
последнюю очередь или же их жестко поджимали сроки сдачи проекта %-).
Создается впечатление что протокол рассчитан на работу в среде так
называемых "доверенных хостов". Представим себе некую виртуальную
личность. Человека, точнее некий IP адрес, обладатель которого имеет
намерение получить выгоду , либо же просто насолить администратору
путем нарушения работы некой сети. Станем на место этой особы.
Рассмотрение этого вопроса сведем к двум пунктам:
a) мы находимся вне "враждебной сети". Каким же образом мы можем
совершить свое черное дело? В первую очередь предполагаем что мы знаем
адрес шлюза сети. Согласно RFC, соединение системы управления с
агентом происходит по 161-ому порту (UDP). Вспомним о том что для
удачной работы необходимо знание группы. Тут злоумышленнику на помощь
приходит то, что зачастую администраторы оставляют значения (имена)
групп, выставленные по умолчанию, а по умолчанию для SNMP существует
две группы - "private" и "public". В случае если администратор не
предусмотрел подобного развития событий, недоброжелатель может
доставить ему массу неприятностей. Как известно, SNMP протокол
является частью FingerPrintering. При желании , благодаря группе
system MIB II, есть возможность узнать довольно большой объем
информации о системе. Чего хотя бы стоит read-only параметр sysDescr.
Ведь зная точно версию программного обеспечения, есть шанс , используя
средства для соответствующей ОС получить полный контроль над системой.
Я не зря упомянул атрибут read-only этого параметра. Ведь не порывшись
в исходниках snmpd (в случае UNIX подобной ОС ), этот параметр
изменить нельзя, то есть агент добросовестно выдаст злоумышленнику все
необходимые для него данные. А ведь не надо забывать о том, что
реализации агентов под Windows поставляются без исходных кодов, а
знание операционной системы - 50% успеха атаки. Кроме того, вспомним
про то, что множество параметров имеют атрибут rw (read-write), и
среди таких параметров - форвардинг ! Представьте себе последствия
установки его в режим "notForwarding(2)". К примеру в Linux реализации
ПО для SNMP под название ucd-snmp есть возможность удаленного запуска
скриптов на сервера, путем посылки соответствующего запроса. Думаю,
всем понятно к чему могут привести "недоработки администратора".
б) злоумышленник находится на локальной машине. В таком случае
вероятность увольнения админа резко возрастает. Ведь нахождение в
одном сегменте сети дает возможность простым сниффингом отловить
названия групп, а с ними и множество системной информации. Этого
случая также касается все сказанное в пункте (а).
Перейдем к "практическим занятиям". Что же может на понадобиться. В
первую очередь программное обеспечение. Его можно достать на
http://net-snmp.sourceforge.net . Примеры я буду приводить для ОС
Линукс, но синтаксис команд аналогичен Windows ПО.
Установка пакета стандартна:
gunzip udc-snmp-3.5.3.tar.gz
tar -xvf udc-snmp-3.5.3.tar
cd udc-snmp-3.5.3
./configure
make
make install
Запуск демона (агента)
snmpd
После инсталяции Вам доступны программы:
snmpget
snmpset
snmpgetnext
snmpwalk
snmpbulkwalk
snmpcheck
snmptest
snmpdelta
snmpnetstat snmpstatus
snmptable
snmptrap
snmptranstat
и демон
snmptrapd
Посмотрим, как выглядят описанные выше операции на практике.
Запрос GetRequest реализует одноименная программа snmpget
Для получения необходимой информации выполним следующую команду:
root@darkstar:~# snmpget 10.0.0.2 public system.sysDescr.0
На что сервер добросовестно сообщит нам:
system.sysDescr.0 = Hardware: x86 Family 6 Model 5 Stepping 0 AT/AT
COMPATIBLE - Software: Windows NT Version 4.0 (Build Number: 1381
Uniprocessor Free )
(не правда ли - довольно содержательно), либо же
system.sysDescr.0 = Linux darkstar 2.4.5 #1 SMP Fri Aug 17 09:42:17
EEST 2001 i586
Прямо-таки - руководство по проникновению.
Допустим, мы хотим что-либо изменить в настройках агента. Проделаем
следующую операцию:
root@darkstar:~# snmpset 10.0.0.2 public system.sysContact.0 s
test@test.com
и получим ответ:
system.sysContact.0 = test@test.com
Список объектов MIB II с атрибутами можно найти пойдя по ссылке,
указанной в "Приложении".
Думаю, настало время рассмотреть SNMP на пакетном уровне.
[snmp_ownpart.jpg] Этот пакет был отловлен сниффером NetXRay на
сетевом интерфейсе агента. Как видим - практика не далека от теории.
Наблюдаем Request ID и параметры запроса. На полном скриншоте
( http://www.titanicum.kiev.ua/snmp/snmp_to_agent.jpg ) можно
увидеть стек протоколов - от кадров Ethernet, через UDP доходим до
самого Simple Network Management Protocol. А этот пакет
( http://www.titanicum.kiev.ua/snmp/snmp_to_manager.jpg ) был получен
с интерфейса менеджера. Как видите, название группы абсолютно никак не
шифруется (о чем в свою очередь говорит Protocol version number : 1).
Хочется отметить, что согласно спецификации протокола, пакеты SNMP не
имеют четко определенной длины. Существует ограничение сверху равное
длине UDP сообщения, равное 65507 байт, в свою очередь сам пртокол
накладывает другое максимальное значение - лишь 484 байта. В свою
очередь не имеет установленного значения и длина заголовка пакета
(headerLength).
Ну вот мы в общих чертах и ознакомились с протоколом SNMP. Что еще
можно добавить к сказанному выше ... Можно лишь дать пару советов
сетевым администраторам, дабы уменьшить риск возникновения пролем с
безопасностью сети... В первую очередь должное внимание следует
уделить настройке файрволинга. Во-вторых - изменить установленные по
умоланию имена групп. Разумным было бы жестко зафиксировать адреса
машин (менеджеров), с которых разрешается опрос агентов. На этом,
считаю, статью можно и закончить. Хочется верить, что она показалась
Вам интересной.
Приложение
Список из 256 объектов MIB II http://www.titanicum.kiev.ua/snmp/snmp_objects.htm
Объекты MIB II c атрибутами http://www.titanicum.kiev.ua/snmp/mib2.htm
Софт под Линукс http://www.titanicum.kiev.ua/snmp/ucd-snmp-3.5.3.tar.gz
RFC 1158 http://www.titanicum.kiev.ua/snmp/rfc1158.htm
Vova
