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

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

По согласованию с редакцией журнала публикую свою статью "Защита от 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.

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

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)

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

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

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

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

ВВЕДЕНИЕ……………………………………………………………………..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 с вышеописанными настройками производится командой.