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

Полезные советы

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

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

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

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

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

Файлы: 1 файл

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата сдачи:_______________

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

Оценка:__________________

Челябинск

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

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

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

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

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

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

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

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

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

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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Структура PDU

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

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

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

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

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

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

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

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

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

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

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

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

Протокол SNMP (Simple Network Management Protocol) предназначен для облегчения работы администратора по управлению устройствами сети. Однако огромной проблемой протокола SNMP версии 1 (SNMPv1) всегда была абсолютная незащищенность узла, на котором работали средства поддержки этого протокола. В исходной версии использовался только один механизм обеспечения безопасности, основанный на использовании специальных паролей, называемых строками доступа (community string ).

В ответ на жалобы о наличии слабых мест в системе обеспечения безопасности была быстро разработана значительно улучшенная версия SNMP (SNMFV2). В этой версии для аутентификации сообщений, передаваемых между серверами и клиентами SNMP, используется алгоритм хэширования MD5. Это позволяет обеспечить как целостность пересылаемых данных, так и возможность проверки их подлинности. Кроме того, SNMPv2 допускает шифрование передаваемых данных. Это ограничивает возможности злоумышленников по прослушиванию трафика сети и получению строк доступа. Однако в то же время ничто не мешает администраторам использовать на маршрутизаторах простейшие пароли.

Третья версия протокола SNMP (SNMPv3) является текущим стандартом и позволяет достичь необходимого уровня безопасности устройств, но его принятие, по-видимому, затянется на довольно длительное время. Достаточно изучить типичную сеть, чтобы убедиться в том, что большинство устройств работает под управлением даже не SNMPv2, а SNMPv1! Более подробная информация о протоколе SNMPv3 находится по адресу http://www.ietf.org/html.charters/snmpv3-charter.html . Однако ни одна из версий протокола SNMP не ограничивает возможности использования администраторами строк доступа, предлагаемых разработчиками. Как правило, для них устанавливаются легко угадываемые пароли, которые хорошо известны всем, кто хоть немного интересуется подобными вопросами.

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

Однако перед тем, как перейти к подробному рассмотрению изъянов протокола SNMP, давайте кратко познакомимся с основными понятиями, которые с ним связаны. Строки доступа могут быть одного из двух типов - позволяющие только чтение (тип read) и позволяющие как чтение, так и запись (read/write). При использовании строк доступа SNMP, позволяющих только чтение, можно лишь просматривать сведения о конфигурации устройства, такие как описание системы, TCP - и UDP-соединения, сетевые адаптеры и т.д. Строки доступа, предоставляющие права чтения и записи, обеспечивают администратору (и, конечно, злоумышленнику) возможность записывать информацию в устройство. Например, с использованием всего одной команды SNMP администратор может изменить контактную системную информацию, snmpset 10.12.45.2 private.1.3.6.1.2.1.1 s Smith.

Маршрутизаторы Ascend

По умолчанию маршрутизаторы Ascend обеспечивают доступ по протоколу SNMP с помощью строк доступа public (для чтения - read ) и write для чтения и записи - read/write ). Изъян в системе защиты, связанный с SNMP-доступом для чтения и записи, впервые был обнаружен специалистами из Network Associates. Inc.

Контрмеры: защита маршрутизаторов Ascend

Для того чтобы изменить установленные по умолчанию строки доступа на маршрутизаторе Ascend, просто воспользуйтесь командой меню Ethernet › ModConflg › SNMP Options .

Маршрутизаторы Bay

Маршрутизаторы компании Bay NT по умолчанию предоставляют доступ по протоколу SNMP, контролируемый на уровне пользователей как для чтения, так и для записи. Для того чтобы воспользоваться этой возможностью, достаточно попытаться использовать установленное по умолчанию пользовательское имя User без пароля. В командной строке маршрутизатора введите команду:

Show snmp comm types

Эта команда позволяет просматривать имеющиеся строки доступа. То же самое с помощью диспетчера Site Manager может проделать любой пользователь (команда меню Protocols › IP › SNMP › Communities ).

Контрмеры: защита маршрутизаторов Bay

В диспетчере Site Manager , который входит в состав программного обеспечения маршрутизаторов компании Bay Networks, выберите команду меню Protocols › IlP1 › SNMPoCommunities . После этого выберите команду Community › Edit Community и измените строки доступа.

Контрмеры: защита SNMP

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

Access-list 101 deny udp any any eq 161 log!

ВВЕДЕНИЕ 3

1. ТЕОРЕТИЧЕСКОЕ ОБОСНОВАНИЕ ПРОБЛЕМЫ ИССЛЕДОВАНИЯ МЕТОДОВ АТАК НА ПРОТОКОЛ SNMP

1.1 НЕОБХОДИМОСТЬ ИЗУЧЕНИЯ МЕТОДОВ АТАК НА ПРОТОКОЛ SNMP 5

1.2 ПРОТОКОЛ SNMP: ОПИСАНИЕ, ПРЕДНАЗНАЧЕНИЕ 7

2. АНАЛИЗ АТАК НА ПРОТОКОЛ SNMP И СПОСОБОВ ПРОТИВОДЕЙСТВИЯ

2.1 ТЕХНИКИ АТАК НА ПРОТОКОЛ SNMP И СПОСОБЫ ИХ ПРЕДОТВРАЩЕНИЯ 11

2.2 СПОСОБЫ ПРОТИВОДЕЙСТВИЯ АТАКАМ НА ПРОТОКОЛ SNMP 15

ЗАКЛЮЧЕНИЕ 20

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 21

Выдержка из текста

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

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

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

DoS-атака (от англ. Denial of Service, отказ в обслуживании) — атака на вычислительную систему с целью вывести её из строя, то есть создание таких условий, при которых легитимные (правомерные) пользователи системы не могут получить доступ к предоставляемым системой ресурсам, либо этот доступ затруднён. Отказ «вражеской» системы может быть как самоцелью (например, сделать недоступным популярный сайт), так и одним из шагов к овладению системой (если во внештатной ситуации ПО выдаёт какую-либо критическую информацию — например, версию, часть программного кода и т. д.).

января 2007 года вступил в силу Федеральный закон «О персональных данных» № 152-ФЗ, регулирующий отношения, связанные с обработкой персональных данных (далее — ПДн), и устанавливающий требования к защите таких данных .

выпускной квалификационной работе (далее — ВКР) ставится цель — защитить корпоративную сеть на предприятии ООО «СЦСО Надежда» от несанкционированного доступа на базе сертифицированных программно-аппаратных продуктов удовлетворяющих требованием регуляторов ФСТЭК и ФСБ в области защите информации. Так как в настоящее время корпоративная сеть данного предприятия не отвечает требованием ФЗ №

2. января 2007 года руководство рассматриваемой компании приняло решение организовать защиту информационной системы в соответствии с принятыми законодательными требованиями .

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

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

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

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

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

В рамках проводимого исследования использовалась литература в двух основных направлениях. Во-первых, основные принципы и общая методология построения систем информационной безопасности приведены в работах В.В. Гафнера, Т.В. Ершовой, Ю.Е. Хохлова, С.Б. Шапошника, В. П. Мельникова, С. А. Клейменова, А. М. Петракова, С.Т. Папаева, И.В. Бабайцев, а Н.В. Козака и др. Во-вторых, критерии систем защиты информации, в частности персональных данных и пр. обозначены в трудах Н.И. Петрыкиной, В. А. Семененко, А. Ф. Чипиги, В.Ф. Шаньгина и др. При этом обширный потенциал и недостаточность научных разработок в исследуемой сфере подчеркивается в научных трудах И.В. Машкиной, К.А. Шапченко, Ю.М. Шубина, Д.А. Щелкунова и др. Содержание обозначенных и других работ, используемых в проведенном исследовании обозначает многостороннюю, но недостаточно изученную сферу системной защиты информации в ДОУ.

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

Мир переживает период качественного изменения терроризма. Из индивидуального (например, терроризма эсеров в последний период существования Российской Империи) терроризм трансформировался в массовый: главным объектом террора стала не только властная элита, но и все общество; основными средствами устрашения стали убийства не конкретных людей, а неопределенного, как можно более широкого, круга лиц. Именно поэтому сегодня терроризм касается каждого: например, любой человек может оказаться в метро или магазине во время взрыва. Поэтому тема данной работы, бесспорно, актуальна.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Нормативно-правовые акты

1. Федеральный закон Российской Федерации от

Список специализированной и научной литературы

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 — Системы обнаружения и предотвращения вторжений [Электронный ресурс]

14. Анализ Интернет-угроз в 2014 году. DDoS-атаки. Взлом веб-сайтов.[Электронный ресурс].

15. Колищак А. Уязвимость форматной строки [Электронный ресурс].

16. Первая миля, № 04, 2013 [Электронный ресурс].

Введение

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

Угрозы

Проблемы с протоколом SNMP начались с первой версии, когда механизма
защиты не было как такового. Любой желающий мог узнать пароли просто
прослушивая сеть. Но через некоторое время вышла вторая версия, в которой,
в соответствии с требованиями времени, были реализованы более серьезные
функции защиты. В частности, хэширование при помощи MD5, шифрование по
DES и др. (см. первую статью). На сегодняшний момент последней является третья версия SNMP, разработчики
которой основной задачей видят обеспечение безопасности. Однако, не все
так гладко с безопасностью даже и у третьей версии.
Существует 6 видов угроз для SNMP:

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

Рассмотрим, как кажется, наиболее защищенную третью версию SNMP в свете
противодействиям этим типам атак.

Атака на SNMPv3

Маскарадинг - ошибка устранена, система
проверяет происхождение пакетов
Модификация - протокол проверяет целостность при помощи MD5
Угроза раскрытия - криптование при помощи DES
Анализ трафика - протокол по прежнему
УЯЗВИМ
Отказ в обслуживании - УЯЗВИМА

Итак, как оказалось, даже 3 версия уязвима для некоторых типов атак. В
частности, набор утилит ucd-snmp версий 5.0.1, 5.0.3, 5.0.4.pre2, который
включает в себя SNMP демон, утилиты для опроса и установления значений
MIB, а также другие полезные особенности уязвимы для атаки отказа в
обслуживании. Уязвимость была найдена Andrew Griffiths и анонсирована
компанией iDEFENSE 2 октября 2002.
Решением проблем такого плана может быть только регулярное обновление
программного обеспечения.

Одной из самых распространенных проблем даже по сей день являются пароли
(community strings) по умолчанию. В который раз хочется отметить, что
установки по умолчанию НЕОБХОДИМО менять. Решением послужит тщательное изучение страниц man по следующим файлам:
snmp.conf, snmp_config, snmpcmd, в которых содержится информация по
конфигурации SNMP и работе файлов. Даже при простом изменении значения по
умолчанию "public" на более сложный пароль, злоумышленник уже не сможет
получить информацию о Вашей системе при помощи тривиальной утилиты
snmpwalk. Множество сетевых устройств (switches, WAN/LAN роутеры, модемы, а также
некоторые операционные системы) по умолчанию сконфигурированы с
активированым SNMP и даже с rw доступом(!). Последствия такой небрежности
предсказать несложно. Вот небольшой список, для примера, устройств с
паролями по умолчанию:

3com Switch 3300 (3Com SuperStack II) - private
- Cray MatchBox router (MR-1110 MatchBox Router/FR 2.01) - private
- 3com RAS (HiPer Access Router Card) - public
- Prestige 128 / 128 Plus - public
- COLTSOHO 2.00.21 - private
- PRT BRI ISDN router - public
- CrossCom XL 2 - private
- WaiLAN Agate 700/800 - public
- HPJ3245A HP Switch 800T - public
- ES-2810 FORE ES-2810, Version 2.20 - public
- Windows NT Version 4.0 - public
- Windows 98 (не 95) - public
- Sun/SPARC Ultra 10 (Ultra-5_10) - private

Кстати, 16 октября в списке рассылки bugtraq была опубликована новая
информация о несанкционированном доступе к AVAYA Cajun. SNMP-community
NoGaH$@! позволяет полный доступ. Также были приведены недокументированные
учетные записи diag/danger и manuf/xxyyzz. Решением таких проблем послужит ограничение rw доступа, запрещение доступа
к устройствам с активированным SNMP извне. Необходимо запретить доступ на
SNMP-порты для всех посторонних компьютеров. Осуществить это довольно просто,
достаточно использовать набор правил ipchains/iptables. Дать совет по настройке
ipchains довольно сложно, т.к. необходимо знать топологию локальной сети, а
для домашних рабочих станций SNMP не нужен.

Для любого системного администратора, который имеет дело с данным
протоколом, необходимы программы, которые бы упрощали работу с SNMP. В
связи с этим можно упомянуть MRTG и SNMP::Monitor. На взгляд автора пакета
SNMP::Monitor, его программа имеет преимущества по сравнению с MRTG (какие
именно, Вы можете прочитать в readme). Скачать SNMP::Monitor можно с
архивов packetstormsecurity.org . Вот лишь некоторые из ее функций:

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

Определенно необходимо логгирование отказов в предоставлении SNMP сервиса
неавторизованным хостам и последующий анализ журналов. Если Вы хотите
проверить уязвимость Вашей сети, то неплохой программой будет snmpsniff,
перехватчик трафика. Загрузить ее можно с www.packetstormsecurity.org/sniffers/snmpsniff-1.0.tar.gz .
Для проверки надежности паролей можно использовать snmpbrute.c, который
является довольно быстрым переборщиком паролей.

Итак, в данной работе я попытался насколько это возможно осветить вопросы
безопасной работы SNMP. Если что-то пропустил, то буду благодарен за
подсказку. Спасибо за комментарии, которые натолкнули написать
продолжение.