Контрольная работа: Разработка системы предотвращения атак на основе plug-in для COA Snort с использованием snort-inline для блокировки выявленных атак

Разработка системы предотвращения атак на основе plug-in для COA Snort с использованием snort-inline для блокировки выявленных атак

Оглавление

Введение

. Теоретическая часть

.1 Внутренняя структура Snort

.1.2 Препроцессоры

.1.3 Модули обнаружения

.1.4 Модули вывода

.2 Обнаружение атаки

1.3 Правила Snort

.3.1 ACTION

.3.2 PROTO

.3.3 IP_ADDR

.3.4 PORT

.3.5 DIRECTION

.3.6 OPTIONS

.4 Возможности

.5 Snort_inline - система предотвращения атак (IPS) на базе Snort

1.6 Iptables

.6.1 Ключевыми понятиями iptables

.6.2 Принцип работы

.6.3 Встроенные действия

.6.4 Терминальные и нетерминальные действия

.6.5 Таблица mangle

.6.6 Таблица filter

. Система предотвращения атак

Заключение

Список используемых источников

Введение

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

1.      Теоретическая часть

Система Snort является классическим продуктом с открытыми исходными текстами. Разработку данной системы начал один автор, Martin Roesch, но благодаря открытой архитектуре и открытым исходным текстам, система стала быстро развиваться за счет других разработчиков, и, кроме того, интегрироваться с прочими программными продуктами, такими как базы данных для ведения журналов обнаружения, анализаторы журналов регистрации. Гибкость и удобство Snort основываются на трех столпах:

·        языке правил, используемый для описания свойств подозрительного ипотенциально опасного трафика;

·        механизме оповещения об обнаружении атаки;

·        модульной архитектуре кода, анализирующего трафик, основанной на концепции подключаемых модулей.

.1 Внутренняя структура Snort

Система Snort имеет гибкую архитектуру, представленную в виде множества подключаемых модулей. Подключаемые модули бывают трех типов:

препроцессоры

модули обнаружения

модули вывода

.1.2 Препроцессоры

Препроцессоры Snort бывают двух типов. Первый тип предназначен для обнаружения подозрительной активности, а второй тип предназначен для модификации пакетов протоколов высоких уровней (чем канальный) для последующей их обработки процессором обнаружения. Этот процесс называется нормализацией трафика. Он позволяет обнаруживать атаки, которые манипулируют внешним видом трафика для большей скрытности. Существует много препроцессоров snort, которые можно подключить или отключить, внеся соответствующие изменения в файл конфигурации. Исходные коды препроцессоров находятся в директории ./src/preprocessors. Здесь приведены только некоторые из них:

· portscan (2) - предназначен для обнаружения сканирования портов

· http_inspect - предназначен для контроля http трафика

· stream4 - предназначен для контроля за TCP сессиями

· arpspoof - предназначен для обнаружения атак arp-spoofing

· bo - предназначен для обнаружения активности BackOrifice

· frag2 - предназначен для сборки фрагментированных пакетов

· RPC-decode - декодирование RPC-трафика;

· Telnet_decode - декодирование трафика telnet-сессий;

· ASN1_decode - выявление аномалий в строках формата ASN1;

· и т.д.

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

Следует отметить, что процедуры, декодирующие сетевой трафик, работают начиная с канального и заканчивая прикладным уровнем. В настоящее время Snort поддерживает декодирование для интерфейсов Ethernet, SLIP и PPP.

.1.3 Модули обнаружения

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

.1.4 Модули вывода

Модули вывода используются Snort для записи событий безопасности, ведения логов и т.д. в различные устройства и хранилища данных. Возможно настроить систему на ведение логов в отдельную базу данных, двоичные и текстовые файлы различных форматов. Возможны даже такие экзотические варианты, как уведомления администратора по e-mail или SMS. Исходные коды этих модулей находятся в директории ./src/output-plugins Вот некоторые модули вывода:

· alert_syslog - вывод в формате syslog

· log_tcpdump - вывод в формате tcpdump

· output_database - выводвБД. Возможны mysql, postgresql, oracle, odbc, mssql(толькодля Snort под Windows)

· csv - выводвформате CSV ( coma separated values)

· и т.д.

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

.2 Обнаружение атаки

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

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

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

Архитектура системы Snort целиком разрабатывалась из соображений эффективности и скорости работы. Поэтому она предельно проста и состоит из следующих подсистем: декодер пакетов, ядро обнаружения и подсистемы оповещения и реагирования. Декодер пакетов реализует набор процедур для последовательной декомпозиции пакетов в соответствии с уровнями сетевого стека, то есть принятый кадр последовательно преобразуется в пакет, сегмент и блок данных с применением специфичных для данного уровня сигнатур атак. Ядро выстраивает имеющиеся правила в т.н. цепи правил - двумерные последовательности правил, где правила с общей частью условий применения объединяются в одно звено цепи, а несовпадающие компоненты правил строятся цепью во втором измерении от полученного звена. Это сделано для ускорения анализа сетевого трафика. Каждый пакет проходит по цепочке от корня, первое подходящее правило выполняет свой блок действий и проход завершается. На рис. 1 представлен небольшой пример такой цепи правил.

Рис. 1 - Цепи правил системы Snort

1.3 Правила Snort

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

.3.1 ACTION

Имеются три основных директивы, определяющие дальнейшие действия при обнаружении сетевого пакета, соответствующего некоторому правилу: pass, log и alert.

Директива pass указывает просто игнорировать пакет. Директива log определяет, что пакет должен быть передан процедуре журналирования, выбранной пользователем, для последующей записи в файл журнала. Наконец, директива alert генерирует уведомление об обнаружении пакета, удовлетворяющего правилу - опять же определенным пользователем способом - и потом уже передает пакет процедуре журналирования для последующего анализа.

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

redalert

{alertalert_syslog: LOG_AUTH LOG_ALERTdatabase: log, mysql, user=snort dbname= snort host= localhost

}

.3.2 PROTO

В настоящее время для анализа доступны три протокола, и, соответственно, допустимы три значения этого параметра - tcp,udp,icmp. В будущем, возможно, появится поддержка ARP, IPX, IGRP, GRE, RIP, OSPF и других.

.3.3 IP_ADDR

Snort не имеет механизма для разрешения имен (и вряд ли он появится в дальнейшем - по соображениям производительности), поэтому для задания хостов необходимо использовать их IP-адреса. Ключевое слово any позволяет задать все возможные адреса, для подсетей указываются CIDR-блоки.

Символ ! инвертирует условие, т.е. !192.168.3.0/24 означает любой не принадлежащий подсети 192.168.3.0/24 IP-адрес. Кроме того, можно задавать списки адресов, перечисляя их через запятую и заключая в квадратные скобки: [192.168.2.0/24,192.169.3.54/32].

.3.4 PORT

Задание номеров портов осуществляется точно также, как и в Linux-утилите ipchains. То есть кроме единственного номера порта можно задать диапазон портов через двоеточие, например, 6000:6010 - порты с 6000 по 6010 включительно, :1024 - порты с 1 по 1024, 1024: - порты с 1024 по 65536. Как и в случае IP-адресов, символ ! инвертирует условие, а ключевое слово any обозначает все порты.

.3.5 DIRECTION

Этот оператор позволяет определить направление движения пакета:

> (одностороннее) - правило будет применяться только к пакетам, идущим с IP_ADDR1 на IP_ADDR2;

<> (двустороннее) - направление движения пакета роли не играет.

.3.6 OPTIONS

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

Параметры отделяются друг от друга точкой с запятой, а ключевое слово параметра отделяется от его аргумента двоеточием. В настоящее время существует 24 параметра, но их количество постоянно увеличивается от версии к версии.

Параметры, задающие дополнительные условия на соответствие правилу:- задает значение поля TTL в заголовке IP-пакета;- задает значение поля TOS в заголовке IP-пакета;- задает значение поля номера фрагмента в заголовке IP-пакета;- задает значение поля параметров IP-пакета;- задает биты фрагментации IP-пакета;- задает условия на размер IP-пакета;- задает условия на наличие или отсутствие определенных TCP-флагов;- задает номер сегмента TCP-пакета в последовательности;- задает значение поля подтверждения в TCP-пакете;- задает значение поля типа ICMP-пакета;- задает значение поля кода ICMP-пакета;_id - задает значение поля ICMP ECHO ID в ICMP-пакете;_seq - задает номер ICMP ECHO пакета в последовательности;- задает искомый шаблон в содержимом пакета, а не в заголовке (шаблон можно задавать как в текстовом виде, так и в шестнадцатеричном);list - этот параметр аналогичен параметру content за исключением того, что список искомых шаблонов берется из заданного файла;- работает совместно с опцией content для определения смещения в пакете, с которого будет производиться анализ содержимого;- аналогичен параметру offset и определяет положение в пакете, до которого будет производиться анализ содержимого;- отключает чувствительность к регистру при анализе содержимого пакета;- этот параметр позволяет более точно задать характеристики программных или процедурных вызовов RPC-сервисов.

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

Параметры, значения которых имеют смысл при соответствии анализируемого пакета всем условиям:- содержит текст сообщения;- задает альтернативный файл для записи в него содержимого пакета;- этот параметр позволяет включить очень интересную возможность Snort - извлечение пользовательских данных из TCP-сессии, например, для последующего анализа того, какие команды вводил пользователь во время telnet-сессии;

resp - если пакет соответствует правилу, то Snort выполнит одно из указанных действий - например, закроет соединение, отправив TCP-RST-пакет одному из хостов.- блокирует заданные в правиле web-сайты, закрывая соединение с ними и/или отправляя заданное сообщение браузеру, с которого была предпринята попытка зайти на сайт.

.4 Возможности

атака предотвращение snort модуль

СОА Snort можно использовать как анализатор трафика, обладающий значительными возможностями по фильтрации пакетов. Например, можно создать файл с правилами, использующими исключительно действия типа log. В результате из входящего потока данных будут отобраны и сохранены пакеты, удовлетворяющие указанным правилам. Так как по умолчанию журнал ведется в двоичном формате tcpdump, он может быть импортирован почти всеми специализированными программами анализа трафика. Обычно эти программы позволяют наглядно отображать содержимое пакетов, но не обладают такими возможностями по их фильтрации, как Snort.

В СОА Snort встроен программный модуль, позволяющий выявлять сканирование портов защищаемой системы:

preprocessor flow: stats_interval 0 hash 2sfportscan: proto { <протокол> } scan_type { <тип_сканирования> } sense_level { <чувствительность> } logfile { <файл_с_отчетом> }

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

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

В последних версиях Snort появился функционал, делающий её системой предотвращения атак (СПА).

1.5    Snort_inline - система предотвращения атак (IPS) на базе Snort

_inline это встроенный механизм модификации пакетов, позволяющий перезапись опасного содержимого безвредными данными; разновидность системы предотвращения вторжений (IPS). Эта утилита основана на модифицированной версии популярного средства обнаружения вторжений (IDS) Snort, с добавленными несколькими новыми типами правил (drop, sdrop и reject), которые взаимодействуют с iptables (linux) или IPFW (freebsd), указывая какие пакеты нужно блокировать, отклонять, изменять, а какие пропускать на основании правила Snort.

При использовании Snort с snort_inline в вашем распоряжении будут три действия: drop, reject и sdrop.- Отбросить пакет, используя программный брандмэуер, и передать информацию системе журналирования.- Отбросить пакет при помощи программного брандмэуера и не использовать систему журналирования.- Используя брандмэуер, отбросить пакет в том случае, если протокол TCP, или же записать в файл журнала сообщение: ICMP порт недоступен, если пакет приходит по протоколу UDP..

Рис. 2 - работа Snort_inline

.6 Iptables

Iptables - утилита командной строки, является стандартным интерфейсом управления работой межсетевого экрана (брандмауэра) netfilter для ядер Linux версий 2.4 и 2.6. Для использования утилиты iptables требуются привилегии суперпользователя (root).

.6.1 Ключевые понятия iptables

Правило - состоит из критерия, действия и счетчика. Если пакет соответствует критерию, к нему применяется действие, и он учитывается счетчиком. Критерия может и не быть - тогда неявно предполагается критерий «все пакеты». Указывать действие тоже не обязательно - в отсутствие действия правило будет работать только как счетчик.

Критерий - логическое выражение, анализирующее свойства пакета и/или соединения и определяющее, подпадает ли данный конкретный пакет под действие текущего правила.