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

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

1.1 Внутренняя структура Snort

1.1.2 Препроцессоры

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

1.1.4 Модули вывода

1.2 Обнаружение атаки

1.3 Правила Snort

1.3.1 ACTION

1.3.2 PROTO

1.3.3 IP_ADDR

1.3.4 PORT

1.3.5 DIRECTION

1.3.6 OPTIONS

1.4 Возможности

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

1.6 Iptables

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

1.6.2 Принцип работы

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

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

1.6.5 Таблица mangle

1.6.6 Таблица filter

2. Система предотвращения атак Заключение Список используемых источников

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

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

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

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

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

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

1.1 Внутренняя структура Snort

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

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

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

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

1.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.1.3 Модули обнаружения

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

1.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)

· и т. д.

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

1.2 Обнаружение атаки

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

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

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

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

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

1.3 Правила Snort

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

1.3.1 ACTION

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

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

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

ruletype redalert

{

type alert

output alert_syslog: LOG_AUTH LOG_ALERT

output database: log, mysql, user=snort dbname= snort host= localhost

}

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

1.3.2 PROTO

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

1.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].

1.3.4 PORT

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

1.3.5 DIRECTION

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

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

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

1.3.6 OPTIONS

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

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

Параметры, задающие дополнительные условия на соответствие правилу:

ttl — задает значение поля TTL в заголовке IP-пакета;

tos — задает значение поля TOS в заголовке IP-пакета;

id — задает значение поля номера фрагмента в заголовке IP-пакета;

ipopts — задает значение поля параметров IP-пакета;

fragbits — задает биты фрагментации IP-пакета;

dsize — задает условия на размер IP-пакета;

flags — задает условия на наличие или отсутствие определенных TCP-флагов;

seq — задает номер сегмента TCP-пакета в последовательности;

ack — задает значение поля подтверждения в TCP-пакете;

itype — задает значение поля типа ICMP-пакета;

icode — задает значение поля кода ICMP-пакета;

icmp_id — задает значение поля ICMP ECHO ID в ICMP-пакете;

icmp_seq — задает номер ICMP ECHO пакета в последовательности;

content — задает искомый шаблон в содержимом пакета, а не в заголовке (шаблон можно задавать как в текстовом виде, так и в шестнадцатеричном);

content-list — этот параметр аналогичен параметру content за исключением того, что список искомых шаблонов берется из заданного файла;

offset — работает совместно с опцией content для определения смещения в пакете, с которого будет производиться анализ содержимого;

depth — аналогичен параметру offset и определяет положение в пакете, до которого будет производиться анализ содержимого;

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

rpc — этот параметр позволяет более точно задать характеристики программных или процедурных вызовов RPC-сервисов.

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

Параметры, значения которых имеют смысл при соответствии анализируемого пакета всем условиям:

msg — содержит текст сообщения;

logto — задает альтернативный файл для записи в него содержимого пакета;

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

4resp — если пакет соответствует правилу, то Snort выполнит одно из указанных действий — например, закроет соединение, отправив TCP-RST-пакет одному из хостов.

react — блокирует заданные в правиле web-сайты, закрывая соединение с ними и/или отправляя заданное сообщение браузеру, с которого была предпринята попытка зайти на сайт.

1.4 Возможности

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

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

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

preprocessor flow: stats_interval 0 hash 2

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

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

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

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

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

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

При использовании Snort с snort_inline в вашем распоряжении будут три действия: drop, reject и sdrop.

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

sdrop — Отбросить пакет при помощи программного брандмэуера и не использовать систему журналирования.

reject — Используя брандмэуер, отбросить пакет в том случае, если протокол TCP, или же записать в файл журнала сообщение: ICMP порт недоступен, если пакет приходит по протоколу UDP.

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

1.6 Iptables

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

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

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

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

Действие — описание действия, которое нужно проделать с пакетом и/или соединением в том случае, если они подпадают под действие этого правила. О действиях более подробно будет рассказано ниже.

Счетчик — компонент правила, обеспечивающий учет количества пакетов, которые попали под критерий данного правила. Также счетчик учитывает суммарный объем таких пакетов в байтах.

Цепочка — упорядоченная последовательность правил. Цепочки можно разделить на пользовательские и базовые.

Базовая цепочка — цепочка, создаваемая по умолчанию при инициализации таблицы. Каждый пакет, в зависимости от того, предназначен ли он самому хосту, сгенерирован им или является транзитным, должен пройти положенный ему набор базовых цепочек различных таблиц. Схема следования пакетов приведена на рисунке. Кроме того, базовая цепочка отличается от пользовательской наличием «действия по умолчанию» (default policy). Это действие применяется к тем пакетам, которые не были обработаны другими правилами этой цепочки и вызванных из нее цепочек (см. переходы). Имена базовых цепочек всегда записываются в верхнем регистре (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING).

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

Таблица — совокупность базовых и пользовательских цепочек, объединенных общим функциональным назначением. Имена таблиц (как и модулей критериев) записываются в нижнем регистре, так как в принципе не могут конфликтовать с именами пользовательских цепочек. При вызове команды iptables таблица указывается в форматеt имя_таблицы. При отсутствии явного указания, используется таблица filter. Более подробно таблицы будут рассмотрены ниже.

1.6.2 Принцип работы

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

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

Как уже было сказано выше, каждое встроенное действие реализует какую-либо одну операцию, например, ACCEPT пропускает пакет, MARK меняет его маркировку, MASQUERADE обеспечиват маскарадинг соединения. Наиболее общими действиями являются:

ACCEPT, DROP и REJECT — базовые операции фильтрации. Более подробно они рассмотрены ниже, при описании таблицы filter.

RETURN — обеспечивает возврат из текущей цепочки. В частности, если из цепочки A правилом номер 3 пакет был направлен в цепочку B, то применение к нему в цепочке B действия RETURN приведет к его переходу обратно в цепочку A, и он продолжит ее прохождение со следующего правила (номер 4).

LOG — позволяет записывать информацию о пакетах в журнал ядра.

ULOG — позволяет передавать информацию об обработанных пакетах специальным демонам, таким, как ulogd. Такой подход позволяет эффективно управлять информацией о трафике, в частности, заносить ее в базы данных, такие как MySQL, PostgreSQL или SQLite. Впоследствии эти данные могут быть проанализированы и визуализированы с помощью таких средств, как NuLog.

NFLOG — более универсальный вариант ULOG, обеспечивающий передачу информации о пакете не напрямую в netlink-сокет (как это делает ULOG), а специальной подсистеме — logging backend. Например, бэкенд nfnetlink_log обеспечивает передачу данных в netlink-сокет, то есть с ним NFLOG работает аналогично ULOG.

NFQUEUE — во многом похоже на ULOG, но передает специальному демону не информацию о пакете, а сам пакет целиком. Применяется, в частности, для организации работы l7-filter-userspace.

QUEUE — устаревшая версия NFQUEUE. Не имеет параметров, так как работает только с очередью номер 0.

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

Терминальными называются действия, которые прерывают прохождение пакета через текущую базовую цепочку. То есть если к пакету в рамках некоторого правила было применено терминальное действие, он уже не проверяется на соответствие всем следующим правилам в этой цепочке (и в тех цепочках, из которых она была вызвана, если это пользовательская цепочка). Терминальными являются все действия, специфичные для таблиц filter и nat. Из приведенных выше в этом разделе — ACCEPT, DROP, REJECT, NFQUEUE, QUEUE.

Нетерминальными, соответственно, являются действия, не прерывающие процесс прохождения пакета через цепочки. Нетерминальными являются действия, специфичные для таблицы mangle, а из перечисленных выше — LOG, ULOG и NFLOG.

1.6.5 Таблица mangle

Данная таблица предназначена для операций по классификации и маркировке пакетов и соединений, а также модификации заголовков пакетов (поля TTL и TOS).

Таблица mangle содержит следующие цепочки (Рис. 3):

PREROUTING — позволяет модифицировать пакет до принятия решения о маршрутизации.

INPUT — позволяет модифицировать пакет, предназначенный самому хосту.

FORWARD — цепочка, позволяющая модифицировать транзитные пакеты.

OUTPUT — позволяет модифицировать пакеты, исходящие от самого хоста.

POSTROUTING — дает возможность модифицировать все исходящие пакеты, как сгенерированные самим хостом, так и транзитные.

Заметим, что все цепочки таблицы mangle пакеты проходят раньше, чем одноименные цепочки таблиц nat и filter. Это позволяет классифицировать и маркировать пакеты и соединения в цепочках этой таблицы. Впоследствии эти маркировки могут быть использованы в цепочках двух других таблиц при принятии решений о фильтрации и трансляции адресов.

Рис. 3 — Цепочки

1.6.6 Таблица filter

Предназначена для фильтрации трафика, то есть разрешения и запрещения пакетов и соединений.

Таблица filter содержит следующие цепочки:

INPUT — эта цепочка обрабатывает трафик, поступающий непосредственно самому хосту.

FORWARD — позволяет фильтровать транзитный трафик.

OUTPUT — эта цепочка позволяет фильтровать трафик, исходящий от самого хоста.

Допустимыми действиями в таблице filter являются:

ACCEPT — пропуск пакета. Пакет покидает текущую базовую цепочку и следует дальше по потоковой диаграмме (см. рис.).

REJECT — заблокировать пакет и сообщить его источнику об отказе. По умолчанию об отказе сообщается отправкой ответного ICMP-пакета «icmp-port-unreachable». Однако, это действие поддерживает опцию —reject-with, позволяющую указать формулировку сообщения об отказе (возможные значения: icmp-net-unreachable, icmp-host-unreachable, icmp-proto-unreachable, icmp-net-prohibited, icmp-host-prohibited). Для протокола TCP поддерживается отказ в форме отправки RST-пакета (—reject-with tcp-reset).

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

Также определенный интерес представляют действия, предоставляемые модулями xtables-addons (в настоящее время этот проект уже включен в Debian testing). Некоторые из них:

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

TARPIT — «подвесить» TCP-соединение. Используется лишь в самых крайних случаях, например, при борьбе с DoS-атаками. Отвечает на входящее соединение, после чего уменьшает размер фрейма до нуля, блокируя возможность передачи данных. Соединение будет «висеть» в таком состоянии пока не истечет тайм-аут на атакующей стороне (обычно 20—30 минут). При этом на такое соединение расходуются системные ресурсы атакующей стороны (процессорное время и оперативная память), что может быть весьма ощутимо при значительном количестве соединений. В случае правильного использования действия TARPIT ресурсы атакуемой стороны практически не расходуются.

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

DELUDE — создать видимость открытого TCP-порта. На SYN-пакеты отвечает пакетами SYN/ACK, на все прочие пакеты отвечает RST. Очень полезно для введения в заблуждение злоумышленника, сканирующего порты вашего хоста.

CHAOS — для каждого нового TCP-соединения случайно выбрать одно из двух действий. Первое из них — REJECT, второе, в зависимости от выбранной опции, либо TARPIT (—tarpit), либо DELUDE (—delude). В частности, при использовании действия CHAOS —delude для всех неиспользуемых портов, сканирующий ваши порты злоумышленник получит совершенно неверную информацию о состоянии ваших портов. В случае с CHAOS —tarpit ситуация усугубится еще и «подвисающими» соединениями.

Особо заметим, что все действия, перечисленные в качестве допустимых в таблице filter, можно применять в любой из цепочек любой из таблиц (конечно, с разумными ограничениями — например, не стоит ставить действия TARPIT, CHAOS и DELUDE для собственных исходящих пакетов). Однако эти действия предназначены именно для фильтрации, и применение их за пределами таблицы filter является дурным тоном. Как и, например, применение действий, специфичных для таблицы mangle, в таблицах filter и nat.

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

Snort с расширением Snort_inline будет работать на операционной системе Kali-linux-1.0.9. Для адекватной работы snort необходимо установить следующие файлы:

pcre-8.12.zip

libpcap-1.1.1.tar.gz

libdnet-1.11.tar.gz

libnfnetlink-1.0.0.tar

libnetfilter_queue-1.0.0.tar

daq-0.5.tar.gz

Для configure скриптов принудительно задаем директории для установки:

./configure —libdir=/usr/lib —includedir=/usr/include && make && make install

Следующим этапом является сборка snort:

./configure —libdir=/usr/lib —includedir=/usr/include —enable-ipv6 —enable-gre —enable-targetbased —enable-decoder-preprocessor-rules —enable-active-response —enable-normalizer —enable-reload —enable-react —enable-zlib —enable-inline && make && make install

где:

—enable-ipv6 — поддержка IP v6 (внезапно капитан!).

—enable-gre — поддержка GRE инкапсуляции.

—enable-targetbased — поддержка сбора фрагментированных пакетов.

—enable-decoder-preprocessor-rules — поддержка правил для реакции на аномалии выявленные в трафике при работе препроцессоров и декодеров.

—enable-active-response — поддержка внедрения в сеанс пакета при срабатывании правила.

—enable-normalizer — поддержка нормализатора протоколов.

—enable-reload — возможность загрузки/выгрузки правил без перезагрузки SNORT.

—enable-react — поддержка немедленного обрыва сеанса (RST) при срабатывании правила.

—enable-zlibподдержка обработки сжатого трафика;

—enable-inline — использовать интерфейс libipq для snort inline.

После чего настраиваем конфигурацию snort, путь к конфигурации:

/etc/snort/snort.conf .

var HOME_NET 1.2.3.4 # ip-адрес нашего сервера

var EXTERNAL_NET any

var HTTP_SERVERS $HOME_NET

portvar HTTP_PORTS [80,8080]

# путь к папкам с правилами

var RULE_PATH /etc/snort/rules

var PREPROC_RULE_PATH /etc/snort/preproc_rules

# запрещаем ошибки обработки пакетов

config disable_decode_alerts

config disable_tcpopt_experimental_alerts

config disable_tcpopt_obsolete_alerts

config disable_tcpopt_ttcp_alerts

config disable_tcpopt_alerts

config disable_ipopt_alerts

# настраиваем режим inline

config daq: iptables

config daq_mode: inline

config policy_mode: inline

# папки с процессорами

dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/

dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so

# фрагментация пакетов

preprocessor frag3_global: max_frags 65 536

preprocessor frag3_engine: policy linux

# tcp и udp процессор

preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no

preprocessor stream5_tcp: policy linux

#preprocessor stream5_udp: ignore_any_rules

preprocessor http_inspect: global iis_unicode_map unicode. map 1251

preprocessor http_inspect_server: server default profile apache no_alerts ports { 80 8080 8180 } oversize_dir_length 500

output alert_syslog: LOG_ALERT

# инклудим классификаторы траффика

include classification. config

include reference. config

# подключение правил

include $RULE_PATH/local.rules

И создаем правила для snort, путь к правилам — /etc/snort/rules:

# убиваем UNION SQL injection

drop tcp any any -> $HOME_NET $HTTP_PORTS (msg:" UNION SQL Injection" ;uricontent:" union" ;nocase;uricontent:" select" ;nocase;sid:1;gid:666;)

# убиваем blind SQL injection

drop tcp any any -> $HOME_NET $HTTP_PORTS (msg:" Blind SQL Injection" ;uricontent:" ascii" ;nocase;uricontent:" substr" ;nocase;uricontent:" select" ;nocase;sid:2;gid:666;)

# убиваем XSS/CSS

drop tcp any any -> $HOME_NET $HTTP_PORTS (msg:" XSS/CSS attack" ;uricontent:" «;nocase;sid:4;gid:666;)

# убиваем хитрый XSS/CSS

drop tcp any any -> $HOME_NET $HTTP_PORTS (msg:" XSS/CSS attack" ;pcre:" /GET /.*?.*=(javascript:|onclick=|onmouseover=|onmouseout=|onload=).*n/i" ;sid:5;gid:666;)

# убиваем ./././etc/passwd

drop tcp any any -> $HOME_NET $HTTP_PORTS (msg:" PHP include attack" ;uricontent:" =./." ;sid:6;gid:666;)

Как только все настройки введены приступаем к запуску snort.

snortQ —daq nfq —daq-var queue=2 -c /etc/snort/snort.conf

— Q — работа в режиме IPS

—daq — источник пакетов

—daq-var — параметры источника пакетов

— с — путь к конфигу После запуска snort настраиваем iptables:

iptablest natA PREROUTINGj NFQUEUE —queue-num 2

После чего настройка и запуск snort является завершенным.

Заключение

В результате проделанной работы была изучена бесплатная система предотвращения атак Snort_inline на базе Snort. Были получены знания о структуре данной системы и принципах её работы. Научился использовать правила для предотвращения атак на сервер.

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

1. Хабрахабр. Использование snort для блокирования атак скрипт-киддисов — [Электронный ресурс] - Режим доступа: http://habrahabr.ru/post/69 854/

2. Русская группа пользователей Snort. Snort_inline — система предотвращения атак (IPS) на базе Snort — [Электронный ресурс] - Режим доступа: http://www.snortgroup.ru/node/137

3. Дмитрий Рожков. Snort — [Электронный ресурс] - Режим доступа: http://snortgroup.ru/sites/default/files/Snort_linuxcenter.pdf

4. Prezi. Система обнаружения атак Snort — [Электронный ресурс] - Режим доступа: https://prezi.com/ihemgx4iejeu/snort/

5. Unixzen. FreeBSD IPS со встроенным Snort — [Электронный ресурс] - Режим доступа: http://unixzen.ru/freebsd-ips-%D1%81%D0%BE-%D0%B2%D1%81%D1%82%D1%80%D0%BE%D0%B5%D0%BD%D0%BD%D1%8B%D0%BC-snort/

6. Викиучебник. Iptables — [Электронный ресурс] - Режим доступа: http://ru.wikibooks.org/wiki/Iptables#.D0.A2.D0.B0.D0.B1.D0.BB.D0.B8.D1.86.D0.B0_filter

7. OpenNET. Система обнаружения вторжений на базе IDS Snort (snort ids) — [Электронный ресурс] - http://www.opennet.ru/base/sec/snort_ids.txt.html

8. Habrahabr. SNORT как сервисная IPS — [Электронный ресурс] - http://habrahabr.ru/post/123 474/

9. Hacktracking. Snort IPS: afpacket and nfq — [Электронный ресурс] - http://hacktracking.blogspot.ru/2013/10/snort-ips-inline-mode-installation.html