Протокол snmp методы сетевых атак и защиты. Защита от DDoS атак типа SNMP Amplification. Список использованных источников

Данная статья посвящена протоколу SNMP (Simple Network Management Protocol) - одному из протоколов модели OSI, который практически не был затронут в документации просторов RU-нета. Автор попытался заполнить этот вакуум, предоставив читателю почву для размышлений и самосовершенствования, касательно этого, возможно нового для Вас, вопроса. Этот документ не претендует на звание "документации для разработчика", а просто отражает желание автора, насколько это возможно, осветить аспекты работы с данным протоколом, показать его слабые места, уязвимости в системе "security", цели преследованные создателями и объяснить его предназначение.

Предназначение

Протокол SNMP был разработан с целью проверки функционирования сетевых маршрутизаторов и мостов. Впоследствии сфера действия протокола охватила и другие сетевые устройства, такие как хабы, шлюзы, терминальные сервера, LAN Manager сервера, машины под управлением Windows NT и т.д. Кроме того, протокол допускает возможность внесения изменений в функционирование указанных устройств.

Теория

Основными взаимодействующими лицами протокола являются агенты и системы управления. Если рассматривать эти два понятия на языке "клиент-сервер", то роль сервера выполняют агенты, то есть те самые устройства, для опроса состояния которых и был разработан рассматриваемый нами протокол. Соответственно, роль клиентов отводится системам управления - сетевым приложениям, необходимым для сбора информации о функционировании агентов. Помимо этих двух субъектов в модели протокола можно выделить также еще два: управляющую информацию и сам протокол обмена данными.

"Для чего вообще нужно производить опрос оборудования?" - спросите Вы. Постараюсь пролить свет на этот вопрос. Иногда в процессе функционирования сети возникает необходимость определить определенные параметры некоторого устройства, такие как, например, размер MTU, количество принятых пакетов, открытые порты, установленную на машине операционную систему и ее версию, узнать включена ли опция форвардинга на машине и многое другое. Для осуществления этого как нельзя лучше подходят SNMP клиенты.

Помимо сказанного выше рассматриваемый протокол обладает еще одной весьма важной особенностью, а именно возможностью модифицировать данные на агентах. Безусловно, было бы глупостью разрешить модификацию абсолютно любого параметра, но,не смотря на это, и количество тех параметров, для которых допускается операция записи просто пугает. С первого взгляда это полностью опровергает всю теорию сетевой безопасности, но, если углубиться в вопрос, то становится ясно, что не все так запущено, как кажется с первого взгляда. "Волков бояться - в лес не ходить". Ведь при небольших усилиях администратора сети можно свести риск успешного завершения атаки к минимуму. Но этот аспект мы обсудим позже.

Остановимся на том, какую же все-таки информацию может почерпнуть система управления из недр SNMP. Вся информация об объектах системы-агента подержится в так называемой MIB (management information base) - базе управляющей информации, другими словами MIB представляет собой совокупность объектов, доступных для операций записи-чтения для каждого конкретного клиента, в зависимости от структуры и предназначения самого клиента. Ведь не имеет смысла спрашивать у терминального сервера количество отброшенных пакетов, так как эти данные не имеют никакого отношения к его работе, так как и информация об администраторе для маршрутизатора. Потому управляющая система должна точно представлять себе, что и у кого запрашивать. На данный момент существует четыре базы MIB:

Internet MIB - база данных объектов для обеспечения диагностики ошибок и конфигураций. Включает в себя 171 объект (в том числе и объекты MIB I).
LAN manager MIB - база из 90 объектов - пароли, сессии, пользователи, общие ресурсы.
WINS MIB - база объектов, необходимых для функционирования WINS сервера (WINSMIB.DLL).
DHCP MIB - база объектов, необходимых для функционирования DHCP сервера (DHCPMIB.DLL), служащего для динамического выделения IP адресов в сети.

Все имена MIB имеют иерархическую структуру. Существует десять корневых алиасов:

System - данная группа MIB II содержит в себе семь объектов, каждый из которых служит для хранения информации о системе (версия ОС, время работы и т.д.).
Interfaces - содержит 23 объекта, необходимых для ведения статистики сетевых интерфейсов агентов (количество интерфейсов, размер MTU, скорость передачи, физические адреса и т.д.) .
AT (3 объекта) - отвечают за трансляцию адресов. Более не используется. Была включена в MIB I. Примером использования объектов AT может послужить простая ARP таблица (более подробно об ARP протоколе можно почитать в статье "Нестандартное использование протокола ARP", которую можно найти на сайте www.uinc.ru в разделе "Articles") соответствия физических (MAC) адресов сетевых карт IP адресам машин. В SNMP v2 эта информация была перенесена в MIB для соответствующих протоколов.
IP (42 объекта) - данные о проходящих IP пакетах (количество запросов, ответов, отброшенных пакетов).
ICMP (26 объектов) - информация о контрольных сообщениях (входящие/исходящие сообщения, ошибки и т.д.).
TCP (19) - все, что касается одноименного транспортного протокола (алгоритмы, константы, соединения, открытые порты и т.п.).
UDP (6) - аналогично, только для UDP протокола (входящие/исходящие датаграммы, порты, ошибки).
EGP (20) - данные о трафике Exterior Gateway Protocol (используется маршрутизаторами, объекты хранят информацию о принятых/отосланных/отброшенных кардах).
Transmission - зарезервирована для специфических MIB.
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 есть возможность удаленного запуска скриптов на сервера, путем посылки соответствующего запроса. Думаю, всем понятно к чему могут привести "недоработки администратора".
б) злоумышленник находится на локальной машине. В таком случае вероятность увольнения админа резко возрастает. Ведь нахождение в одном сегменте сети дает возможность простым сниффингом отловить названия групп, а с ними и множество системной информации. Этого случая также касается все сказанное в пункте (а).

Перейдем к "практическим занятиям". Что же может на понадобиться. В первую очередь программное обеспечение. Его можно достать на . Примеры я буду приводить для ОС Линукс, но синтаксис команд аналогичен 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

Запуск демона (агента)

После инсталяции Вам доступны программы:

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 [email protected]

и получим ответ:

system.sysContact.0 = [email protected]

Список объектов MIB II с атрибутами можно найти пойдя по ссылке, указанной в "Приложении".

Думаю, настало время рассмотреть SNMP на пакетном уровне. Этот пакет был отловлен сниффером NetXRay на сетевом интерфейсе агента:

Как видим - практика не далека от теории. Наблюдаем Request ID и параметры запроса. На полном скриншоте можно увидеть стек протоколов - от кадров Ethernet, через UDP доходим до самого Simple Network Management Protocol:

А этот пакет был получен с интерфейса менеджера:

Как видите, название группы абсолютно никак не шифруется (о чем в свою очередь говорит Protocol version number: 1). Хочется отметить, что согласно спецификации протокола, пакеты SNMP не имеют четко определенной длины. Существует ограничение сверху равное длине UDP сообщения, равное 65507 байт, в свою очередь сам пртокол накладывает другое максимальное значение - лишь 484 байта. В свою очередь не имеет установленного значения и длина заголовка пакета (headerLength).

Ну вот мы в общих чертах и ознакомились с протоколом SNMP. Что еще можно добавить к сказанному выше... Можно лишь дать пару советов сетевым администраторам, дабы уменьшить риск возникновения пролем с безопасностью сети... В первую очередь должное внимание следует уделить настройке файрволинга. Во-вторых - изменить установленные по умоланию имена групп. Разумным было бы жестко зафиксировать адреса машин (менеджеров), с которых разрешается опрос агентов. На этом, считаю, статью можно и закончить. Хочется верить, что она показалась Вам интересной.

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

Рис. 1. Упрощенная архитектура SNMP

Основной протокол связи в SNMP - это UDP (User Datagram Protocol). Если агенты SNMP анализируют данные с порта UDP 161 при получении запросов от NMS, то NMS анализирует поток, передаваемый через порт UDP 162 для получения асинхронных сообщений. На рис. 1 показана упрощенная архитектура SNMP-управления, где динамический порт назначает операционная система. SNMP поддерживает простейшую аутентификацию с помощью имени сообщества, которое служит в качестве пароля для получения или изменения данных, существенных для задач управления.

Исследователи из финского университета Оулу разработали тесты, которые позволяют обнаружить множество уязвимых мест в реализациях SNMPv1. Тестовые пакеты, как правило, используются для анализа протокола и порождают сообщения, которые проверяют выполнение различных ограничений архитектуры.

Исследователи обнаружили следующие уязвимые места SNMP .

Обработка сообщений trap. Множество недостатков было выявлено в том, как различные станции NMS (network management station) декодируют и обрабатывают trap-сообщения.
Обработка запросов. Тестирование показало наличие некорректностей при декодировании и обработке запросов SNMP различными агентами.

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

Некоторые из уязвимых мест, обнаруженные Protos, не требуют, чтобы в сообщениях SNMP присутствовало корректное имя сообщества, в силу чего использовать такие уязвимые места очень легко. Кроме того, поскольку UDP - коммуникационный протокол, не требующий установления соединения, агенты SNMP и NMS, поддерживающие trap, принимают входящие запросы и сообщения trap без каких-либо предварительных настроек сеанса. Большинство продуктов, ориентированных на SNMP, выпускаются со строками сообщества по умолчанию public («общедоступный») для доступа только на чтение и private («частный») для доступа с правами чтения и записи. Строка имени сообщества интегрирована в сообщение SNMP и передается по сети в виде обычного текста. Даже если эта строка указана корректно, она уязвима для перехвата пакетов.

Для блокирования атак, использующих эти дефекты защиты, контроля сетевого доступа также недостаточно, поскольку адреса отправителей UDP легко сфальсифицировать spoofing. Хакер может послать пакеты, указав фальшивый адрес отправителя, и вывести из строя устройство-получатель. Более того, некоторые реализации SNMP по умолчанию разрешают пересылать пакеты SNMP широковещательно. Хакеры могут легко распространить широковещательные пакеты, чтобы поразить всю сеть целиком, даже если им не известен адрес конкретного устройства и имя сообщества SNMP .

Оценка угроз

Уязвимые места могут создать условия для DoS-атаки или для прерывания обслуживания, и, в некоторых случаях, могут позволить хакеру получить доступ к устройству. Конкретные проявления меняются от продукта к продукту. Поскольку в большинстве случаев службы SNMP по умолчанию не включены, для домашних пользователей эти дефекты не представляют прямой угрозы. Однако так как SNMPv1 широко применяется в важнейших устройствах сетевой инфраструктуры, использование этих изъянов может привести к нестабильности и прерыванию работы крупномасштабной сети. В частности, если хакеры сочетают эти уязвимые места с дефектами защиты в протоколах маршрутизации Internet, таких как Border Gateway Protocol, проникновение на один магистральный маршрутизатор может привести к нестабильности всей Сети. Если большое число сетевых устройств имеет общий дефект, связанный с переполнением буфера в SNMP, то хакеры могут написать червя наподобие Code Red, который будет использовать этот изъян, что может привести к еще одной волне появления червей.

Решения

Пользуясь данными бюллетеня CERT, перечислим некоторые общие решения, способные защитить сеть .

Сканеры SNMPv1. Некоторые организации выпустили инструментальные средства, которые сканируют сеть в поисках устройств, на которых работает протокол SNMP. SNMPing, разработанный в SANS, представляет собой инструментарий на базе Windows, который ищет демонов SNMP на порту 161 или на другом порту. SNScan, аналогичная утилита, разработанная в Foundstone, быстро и точно выявляет в сети устройства, ориентированные на SNMP.

Заплатки. Обнаружив в сети устройства, ориентированные на SNMP, целесообразно связаться с производителями этих устройств, чтобы выяснить, разработали ли они необходимые заплатки.

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

Фильтрация на входе. Межсетевые экраны и маршрутизаторы можно настроить таким образом, чтобы они выполняли входную фильтрацию портов UDP 161 и 162, что может предотвратить инициируемые из внешней сети атаки на уязвимые устройства в локальной сети. Другие порты, поддерживающие службы, связанные с SNMP, в том числе порты TCP и UDP 161, 162, 199, 391, 750 и 1993, также могут потребовать входной фильтрации.

Выходная фильтрация. Устройства, которые предоставляют общедоступные службы, в обычной ситуации не инициируют исходящий трафик в Internet. Чтобы управлять трафиком, исходящим из сети, реализуйте выходную фильтрацию. Фильтрация исходящего трафика на портах UDP 161 и 162 на границе сети может предотвратить использование вашей системы в качестве плацдарма для атаки.

Изменение строк сообщества по умолчанию. Как уже отмечалось, большинство продуктов, ориентированных на SNMP, имеют по умолчанию строки сообщества public для доступа только на чтение и private для доступа с правом на чтение и запись. Необходимо изменить эти задаваемые по умолчанию значения строк сообществ. Новое имя сообщества, однако по-прежнему будет уязвимо для перехвата пакетов.

Обновление сигнатур. Еще одним решением может стать поддержка в актуальном состоянии сигнатур IDS. Сигнатуры, которые напрямую касаются дефектов, обнаруженных в рамках проекта Protos, теперь можно получить у многих производителей систем обнаружения вторжений. Например, Snort, сообщество разработчиков свободно распространяемых решений для обнаружения вторжений в сеть, разработало набор правил, ориентированных на обработку искаженных пакетов и созданных с помощью пакета Protos. Компания Cisco Systems обновила сигнатуру для своей системы Secure Intrusion Detection System, которую можно получить анонимно. Internet Security Systems выпустила общую сигнатуру для своих продуктов RealSecure и BlackICE.

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

Джуофей Джианг ([email protected]) - ведущий инженер-исследователь Института исследований в области технологий безопасности колледжа в Дартмуте. К области его научных интересов относятся компьютерные сети и безопасность, распределенные информационные системы, мобильные агенты и машинное обучение.

Литература

"CERT Advisory CA-2002-03: Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)", 12 Feb. 2002, (current 11 2002 March)
"PROTOS: Security Testing of Protocol Implementations", 19 July 2001 (current 11 2002 March)
"PROTOS Test-Suite: c06-snmpv1", 12 Feb. 2002 (current 11 2002 March)
"M-042: Multiple Vulnerabilities in Multiple Implementations of SNMP", 12 Feb. 2002 (current 11 2002 March)

SNMP - это протокол прикладного уровня, разработанный для стека TCP/IP, хотя имеются его реализации и для других стеков, например IPX/SPX. Протокол SNMP используется для получения от сетевых устройств информации об их статусе, производительности и других характеристиках, которые хранятся в базе данных управляющей информации MIB (Management Information Base). Простота SNMP во многом определяется простотой MIB SNMP, особенно их первых версий MIB I и MIB II. Кроме того, сам протокол SNMP также весьма несложен.

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

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

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

Команда Get-request используется менеджером для получения от агента значения какого-либо объекта по его имени.

Команда GetNext-request используется менеджером для извлечения значения следующего объекта (без указания его имени) при последовательном просмотре таблицы объектов.

С помощью команды Get-response агент SNMP передает менеджеру ответ на команды Get-request или GetNext-request.

Команда Set используется менеджером для изменения значения какого-либо объекта. С помощью команды Set происходит собственно управление устройством. Агент должен понимать смысл значений объекта, который используется для управления устройством, и на основании этих значений выполнять реальное управляющее воздействие - отключить порт, приписать порт определенной VLAN и т. п. Команда Set пригодна также для установки условия, при выполнении которого агент SNMP должен послать менеджеру соответствующее сообщение. Может быть определена реакция на такие события, как инициализация агента, рестарт агента, обрыв связи, восстановление связи, неверная аутентификация и потеря ближайшего маршрутизатора. Если происходит любое из этих событий, то агент инициализирует прерывание.

Команда Trap используется агентом для сообщения менеджеру о возникновении особой ситуации.

Версия SNMP v.2 добавляет к этому набору команду GetBulk, которая позволяет менеджеру получить несколько значений переменных за один запрос.

ЗАКЛЮЧЕНИЕ
Исследование посвящено вопросам обеспечения безопасности организации сетевого взаимодействия посредством протокола SNMP. В процессе работы были выявлены особенности названного протокола и возможные проблемы его использования. Для обоснования проблемы приведены статистические данные, подтверждающие высокую вероятность реализации сетевых атак. Кроме того, теоретическая часть содержит сведения о структуре протокола, схему запросов/откликов и этапы получения ответов на запросы.
В рамках курсовой работы проведен анализ возможных атак на протокол SNMP, среди которых можно выделить Dos-атаки, атаки типа «Переполнение буфера» и использующие уязвимости форматной строки. Конечно, потенциально возможных угроз гораздо больше, но их обзор предусматривает более глубокое и всесторонне исследов ание.
Для построения системы защиты сетевого взаимодействия абонентов сети были рассмотрены способы предотвращения атак на протокол SNMPи отмечено, что эффективным будет применение комплекса средств.
На основе анализа выявлено, что протоколSNMP достаточно уязвим и, если все-таки принято решение о его использовании, следует разработать политику безопасности и придерживаться всех ее принципов.
Таким образом, можно сделать вывод о достижении цели и решении задач, определенных во введении

ВВЕДЕНИЕ
Современное стремительное развитие информационных технологий предъявляет новые требования к хранению, обработке и распространению данных. От традиционных носителей информации и от выделенных серверов компании и частные лица постепенно переходят к дистанционным технологиям, реализованным через глобальную сеть Интернет. Сервисы в Интернет способны стать незаменимыми инструментами функционирования современной, динамично развивающейся компании, к числу которых можно отнести электронную почту; обмен файлами, голосовыми сообщениямии данных с использованием видео-приложений; разработка собственных Web-ресурсов.
По мнению многих специалистовширокое применение технологий Интернет требует построения системы эффективного управления сетевыми устройствами, одним из инструментов которой может стать протокол SNMP. Однако, организация управления и мониторинга сетевых устройств через данный протокол делает уязвимыми для атак элементы сети. Таким образом, вопросы технологии предотвращения сетевых атак в свете развития сервисов Интернет выходят на первый план и требуют всестороннего анализа. Именно поэтому тема исследования актуальна.
Вопросам построения системы защиты от атак на протокол SNMPпосвящены вопросы многих авторов, но единого мнения по поводу целесообразности использования SNMP в виду сложности обеспечения безопасности нет. Так, Фленов М. в свое книге «Linux глазами Хакера» выделил недостатки данного протокола и не рекомендует его применение. СмирноваЕ. В. В учебном пособии «Технологии коммутации и маршрутизации в локальных компьютерных сетях» излагает сведения по многоадресным схемам передачи данных и эффективному управлению сетевым оборудованием с помощью протокола SNMP, а так же отдельно выделяет вопросы безопасности его применения. Дальнейший обзор специальной литературы и Интернет источников подтвердил необходимость исследования вопросов безопасного применения протокола SNMP для принятия решения о целесообразности его использования.основой для данного решения станет анализ возможных атак и эффективности методов их предотвращения.
Цель исследования - провести всесторонний анализ возможных атак на протокол SNMP и способов противодействия.
Для достижения цели необходимо решение ряда задач:
1. Провести обзор литературы и Интернет-источников по вопросам организации безопасного сетевого взаимодействия на основе применения протокола SNMP.
2. Обосновать необходимость изучения методов атак на протокол SNMP и способов их предотвращения.
3. Выделить особенности управления на базе протокола SNMP.
4. Провести анализ техник на протокол SNMP.
5. Описать методы предотвращения атак на протокол SNMP.
Объект исследования - протокол SNMP.
Предмет исследования - методы сетевых атак на протокол SNMP и способы их предотвращения.
Методы исследования: анализ, синтез, изучение источников информации.
Курсовая работа состоит из введения, двух глав и заключения. Первая глава посвящена теоретическому обоснованию проблемы. Вторая глава содержит анализ возможных атак и способов их предотвращения

СОДЕРЖАНИЕ
ВВЕДЕНИЕ 3
1. ТЕОРЕТИЧЕСКОЕ ОБОСНОВАНИЕ ПРОБЛЕМЫ ИССЛЕДОВАНИЯ МЕТОДОВ АТАК НА ПРОТОКОЛ SNMP
1.1 НЕОБХОДИМОСТЬ ИЗУЧЕНИЯ МЕТОДОВ АТАК НА ПРОТОКОЛ SNMP 5
1.2 ПРОТОКОЛ SNMP: ОПИСАНИЕ, ПРЕДНАЗНАЧЕНИЕ 7
2. АНАЛИЗ АТАК НА ПРОТОКОЛ SNMP И СПОСОБОВ ПРОТИВОДЕЙСТВИЯ
2.1 ТЕХНИКИ АТАК НА ПРОТОКОЛ SNMP И СПОСОБЫ ИХ ПРЕДОТВРАЩЕНИЯ 11
2.2 СПОСОБЫ ПРОТИВОДЕЙСТВИЯ АТАКАМ НА ПРОТОКОЛ SNMP 15
ЗАКЛЮЧЕНИЕ 20
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 21

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
Нормативно-правовые акты
1. Федеральный закон Российской Федерации от 27 июля 2006 г. N 149-ФЗ Об информации, информационных технологиях и о защите информации
Список специализированной и научной литературы
2. Бланк-Эдельман Д. Perl для системного администрирования, М.: символ-Плюс, 2009.- 478с.
3. Бородакий В.Ю. Практика и перспективы создания защищенного информационно-вычислительного облака на основе МСС ОГВ / В.Ю. Бородакий, А.Ю. Добродеев, П.А. Нащекин // Актуальные проблемы развития технологических систем государственной охраны, специальной связи и специального информационного обеспечения: VIII Всероссийская межведомственная научная конференция: материалы и доклады (Орел, 13-14 февраля 2013 г.). - В 10 ч. Ч.4 / Под общ.ред. В.В. Мизерова. - Орел: Акаде мия ФСО России, 2013.
4. Гришина Н. В. Организация комплексной системы защиты информации. -- М.: Гелиос АРВ, 2009. -- 256 с,
5. Дуглас Р. Мауро Основы SNMP, 2-е издание/Дуглас Р. Мауро, Кевин Дж. Шмидт - М.:Символ-Плюс, 2012.-725с.
6. Кульгин М.В. Компьютерные сети. Практика построения. Для профессионалов, СПб.: Питер, 2003.-462с.
7. Мулюха В.А. Методы и средства защиты компьютерной информации. Межсетевое экранирование: Учебное пособие/ Мулюха В.А., Новопашенный А.Г., Подгурский Ю.Е.- СПб.: Издательство СПбГПУ, 2010. - 91 c.
8. Олифер В. Г.,Олифер Н. П. Компьютерные сети. Принципы, технологии, протоколы. - 4-е. - СПб: Питер, 2010. -902с.
9. Технологии коммутации и маршрутизации в локальных компьютерных сетях: учебное пособие / СмирноваЕ. В. и др.; ред. А.В. Пролетарского. - М. : Изд-во МГТУ им. Н.Э. Баумана, 2013. - 389с.
10. Фленов М. Linux глазами Хакера, СПб:BHV-Санкт-Петербург, 2005. - 544 с.
11. Хореев П.В. Методы и средства защиты информации в компьютерных системах. - М.: издательский центр "Академия", 2005. -205 с.
12. Хорошко В. А., Чекатков А. А. Методы и средства защиты информации, К.: Юниор, 2003. - 504с.
Интернет-источники
13. IDS/IPS - Системы обнаружения и предотвращения вторжений [Электронный ресурс] URL: http://netconfig.ru/server/ids-ips/.
14. Анализ Интернет-угроз в 2014 году. DDoS-атаки. Взлом веб-сайтов.[Электронный ресурс]. URL: http://onsec.ru/resources/Internet%20threats%20in%202014.%20Overview%20by%20Qrator-Wallarm.pdf
15. Колищак А. Уязвимость форматной строки [Электронный ресурс]. URL: https://securityvulns.ru/articles/fsbug.asp
16. Первая миля, № 04, 2013 [Электронный ресурс]. URL: http://www.lastmile.su/journal/article/3823
17. Семейство стандартов SNMP [Электронный ресурс]. URL: https://ru.wikibooks.org/wiki /Семейство_стандартов_SNMP
Иностраннаялитература
18. "CERT Advisory CA-2002-03: Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)", 12 Feb. 2002, (current 11 2002 March

Описание работы

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

ВВЕДЕНИЕ……………………………………………………………………..3

1.2 Логика работы протокола SNMP……………………………………..….12

2.1 Безопасность протокола SNMP (или версии протокола SNMP)……….21
2.2 Принципы настройки протокола SNMP…………………………………23
ЗАКЛЮЧЕНИЕ…………………………………………………………….....26
СПИСОК ЛИТЕРАТУРЫ……………………..…………………………...…27

Файлы: 1 файл

Министерство образования и науки РФ

ФГБОУ ВПО «Челябинский государственный университет»

Институт информационных технологий

Кафедра информационных технологий

КУРСОВАЯ РАБОТА

Протокол SNMP. Методы сетевых атак и защиты

Выполнила студентка

Галиуллина Оксана Кунтуаровна

Факультет ИИТ, группа БИС-201

Научный руководитель:

Косенко Максим Юрьевич

Преподаватель кафедры

информационных технологий

Дата сдачи:_______________

Дата защиты:_____________

Оценка:__________________

Челябинск

ВВЕДЕНИЕ………………………………………………………… …………..3

ГЛАВА I. ОПРЕДЕЛЕНИЕ SNMP…………...………………………………5

1.1 Архитектура протокола SNMP…………………………………………….6

1.2 Логика работы протокола SNMP……………………………………..….12

ГЛАВА II. MIB……………………………………………………………….16

ГЛАВА III. БЕЗОПАСНОСТЬ И НАСТРОЙКА SNMP……………..…….21

2.1 Безопасность протокола SNMP (или версии протокола SNMP)……….21

2.2 Принципы настройки протокола SNMP…………………………………23

ЗАКЛЮЧЕНИЕ…………………………………………………… ……….....26

СПИСОК ЛИТЕРАТУРЫ……………………..………………………… ...…27

ВВЕДЕНИЕ

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

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

В настоящее время для управления сетями используются приложения, работающие на базе платформ сетевого управления, таких как системы HP OpenView фирмы Hewlett-Packard, NetView for AIX (IBM), SunNet Manager (Sun), Spectrum (Cabletron Systems), NetWare Management Systems (Novell) и другие разнообразные кросс-платформные средства управления.

В основе этих средств лежит использование протокола SNMP (Simple Network Management Protocol). Протокол SNMP предназначен для сбора и передачи служебной информации (status information) между различными компьютерами.

ГЛАВА I. ОПРЕДЕЛЕНИЕ SNMP

SNMP - это протокол из семейства TCP/IP (Протокол SNMP описан в RFC 1157). Первоначально он был разработан Сообществом Интернета (Internet community) для наблюдения и устранения неполадок в маршрутизаторах и мостах (bridges). SNMP позволяет наблюдать и передавать информацию о состоянии:

компьютеров, работающих под управлением Windows NT;
серверов LAN Manager;
маршрутизаторов и шлюзов;
мини-компьютеров или мэйнфреймов;
терминальных серверов;
концентраторов.

SNMP использует распределенную архитектуру, состоящую из систем управления (management systems) и агентов (agents). С помощью сервиса Microsoft SNMP компьютер, работающий под управлением Windows NT, может выдавать отчет о своем состоянии системе управления SNMP в сети, использующей протокол TCP/IP.

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

1.1 Архитектура протокола SNMP

Сеть, использующая SNMP, для управления содержит три основных компонента:

SNMP менеджер - ПО, устанавливаемое на ПК администратора (системы мониторинга)
SNMP агент - ПО, запущенное на сетевом узле, за которым осуществляется мониторинг.
SNMP MIB - MIB это Management information base. Этот компонент системы обеспечивает структурированность данных, которыми обмениваются агенты и менеджеры. По сути - это некая база данных в виде текстовых фалов.

SNMP менеджер и SNMP агент

Для понимания назначения компонентов, можно сказать, что SNMP менеджер является прослойкой (интерфейсом) между оператором - администратором и сетевым узлом с запущенным SNMP агентом. Так же, можно сказать, что SNMP агент - это интерфейс между SNMP менеджером и железным оборудованием на сетевом узле. Если провести аналогию протокола SNMP с клиент-серверной архитектурой (например, веб-сервера) то веб-сервер работает как служба на некотором порту, а пользователь силами браузера обращается к веб-серверу как клиент. Это четко обозначенная архитектура с выраженным клиентом и сервером. В случае SNMP роли клиента и сервера несколько размыты. Например, SNMP агент является своего рода службой, работающей на устройстве (за которым производится мониторинг) и обрабатывает запросы на определенном порту udp/161, то есть фактически является сервером. А SNMP менеджер является своего рода клиентом, который обращается к серверу SNMP агенту. В SNMP существует т.н. Trap. Это запрос от агента к менеджеру. Точнее даже не запрос, а уведомление. При отправке данного уведомления, агент и менеджер "меняются ролями". То есть, менеджер в таком случае должен являться сервером, работающем на порту udp/162, а агент является клиентом. В последних версиях SNMP trap может именоваться как извещение (notification).

SNMP работает на 7 уровне модели OSI, то есть является службой прикладного уровня. Взаимодействие агента и менеджера на уровне протокола SNMP организуется посредством т.н. пакетов объектов PDU (Protocol Data Unit), которые инкапсулируются в транспортный протокол. Хотя, SNMP поддерживает различные виды транспорта, в 99% случаев используется - UDP. При этом, каждое сообщение PDU содержит определенную команду (на чтение переменной, запись значения переменной, или ответ trap агента). В целом, взаимодействие узлов по SNMP можно представить следующей последовательностью: менеджер->SNMP(PDU)-UDP-IP- Ethernet-IP-UDP-SNMP(PDU)-> агент.

При использовании шифрования в SNMP, по умолчанию используются порт для запросов\ответов udp/10161, а Trap отправляются на udp/10162.

Агенты, работающие на хостах, собирают информацию об устройствах и записывают собранные счетчики в значения переменных в базу данных MIB. Тем самым делая ее доступной для менеджеров.

Рис. 1. Схема взаимодействия SNMP-агент - SNMP-менеджер

SNMP менеджер отправляет запросы агенту на порт udp/161 (если конфигурационно в агенте не задан другой порт) с произвольного порта из эфемерного диапазона. В запросе SNMP менеджера указывается порт и адрес источника. Далее агент принимает пакет и обрабатывает (если выполняются нижеописанные условия). В процессе обработки, формируется ответ, который отправляется на порт, взятый из исходного запроса. Ответ отправляется с udp/161 порта. Можно сказать, что SNMP агент, таким образом, предоставляет доступ SNMP менеджеру к данным, хранящимся в базе MIB. При этом, в момент отправки, SNMP менеджер вставляет в PDU некий ID (RequestID), а агент в ответном PDU вставляет данный ID без изменения, для того чтобы менеджер не путал пакеты от разных агентов. SNMP агент может быть настроен на посылку Trap уведомлений, которую он выполняет с эфемерного порта на udp/162 порт SNMP менеджера.

SNMP PDU (или сообщения SNMP протокола)

Выше я упомянула о единице обмена между узлами SNMP - PDU (Protocol Data Unit), давайте разберем данное понятие. Для обмена между агентом и менеджером используется определенный набор сообщений PDU команд:

Trap - одностороннее уведомление от SNMP агента –> менеджеру о каком-либо событии.
GetReponse - ответ от агента к менеджеру, возвращающий запрошенные значения переменных.
GetRequest - запрос к агенту от менеджера, используемый для получения значения одной или нескольких переменных.
GetNextRequest - запрос к агенту от менеджера, используемый для получения следующего в иерархии значения переменной.
SetRequest - запрос к агенту на установку значения одной или нескольких переменных.
GetBulkRequest – запрос к агенту на получение массива данных (тюнингованная GetNextRequest) . (Этот PDU был введен в SNMPv2.)
InformRequest – одностороннее уведомление между менеджерами. Может использоваться, например для обмена информацией о MIB (соответствие символьных OID - цифровым). В ответ менеджер формирует аналогичный пакет в подтверждение того, что исходные данные получены. (Этот PDU был введен в SNMPv2.)

Как видно, в зависимости от версии протокола, набор команд разный (например InformRequest и GetB ulkRequestполноценно появился только во второй версии SNMP).

Структура PDU

Рассмотрение структуры PDU не обязательно, но это поможет более глубоко понять логику работы SNMP. Все PDU (кроме Trap) состоят из определенного набора полей, в которые записывается необходимая информация:

Рис. 2. Формат пяти SNMP сообщений, инкапсулированных в UDP датаграмму

Что данные поля обозначают:

Версия - содержит версию SNMP;
Пароль (community) - содержит последовательность символов, описывающую принадлежность к группе;
Тип PDU имеет цифровой идентификатор запроса (Get, GetNext, Set, Responde, Trap…);
Идентификатор запроса – это тот самый набор символов, который связывает в единое целое запрос/ответ;
Статус ошибки – это число, характеризующее характер ошибки:

Для запросов (Get, Set, GetNExt и др.) - 0
Для ответов:

0 (NoError) – Нет ошибок;
1 (TooBig) - Объект не вмещается в одно Response сообщение;
2 (NoSuchName) – не существующая переменная;
3 (BadValue) – при попытке установить значение задано недопустимое значение или совершена синтаксическая ошибка;
4 (ReadOnly) – при Set запросе была попытка изменить read-only переменную;
5 (GenErr) – другие ошибки.

Индекс ошибки – содержит некий индекс переменной, к которой относится ошибка;
Поле связанные переменные может содержать одну или более переменную (для запросов Get – это только имя переменных, для Set – имя и устанавливаемое значение, для Response – имя и запрошенное значение).

При этом, содержимое Trap PDU содержит некоторые дополнительные поля (вместо заголовка запроса):

Фирма – характеризующее производителя хоста;
Тип trap уведомления, может быть следующим:

0 (Coldstart) и 1 (Warmstart) – объект возвращен в начальное состояние (между ними имеется некая разница, но какая?..);
2 (Linkdown) – интерфейс опущен, при этом, поле переменной содержит интерфейс, о котором идет речь;
3 (Linkup) – интерфейс поднялся, при этом, поле переменной содержит интерфейс о котором идет речь;
4 (Authenticationfailure) – менеджер прислал мессадж с неверной строкой community;
5 (EGPneighborloss) – затрудняюсь что либо сказать);
6 (Entrprisespecific) – данный тип Trap сообщает о том, что в следующем поле содержится специализированный для данного вендора тип трапа.

Специализированный тип Trap;
Метка времени – содержит метку времени с момента события (непонятно, относительно чего эта метка…).