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

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

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

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

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

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

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

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

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

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

Как уже было сказано выше, каждое встроенное действие реализует какую-либо одну операцию, например, ACCEPT пропускает пакет, MARK меняет его маркировку, MASQUERADE обеспечиват маскарадинг соединения. Наиболее общими действиями являются:, DROP и REJECT - базовые операции фильтрации. Более подробно они рассмотрены ниже, при описании таблицы filter.- обеспечивает возврат из текущей цепочки. В частности, если из цепочки A правилом номер 3 пакет был направлен в цепочку B, то применение к нему в цепочке B действия RETURN приведет к его переходу обратно в цепочку A, и он продолжит ее прохождение со следующего правила (номер 4).- позволяет записывать информацию о пакетах в журнал ядра.- позволяет передавать информацию об обработанных пакетах специальным демонам, таким, как ulogd. Такой подход позволяет эффективно управлять информацией о трафике, в частности, заносить ее в базы данных, такие как MySQL, PostgreSQL или SQLite. Впоследствии эти данные могут быть проанализированы и визуализированы с помощью таких средств, как NuLog.- более универсальный вариант ULOG, обеспечивающий передачу информации о пакете не напрямую в netlink-сокет (как это делает ULOG), а специальной подсистеме - logging backend. Например, бэкенд nfnetlink_log обеспечивает передачу данных в netlink-сокет, то есть с ним NFLOG работает аналогично ULOG.- во многом похоже на ULOG, но передает специальному демону не информацию о пакете, а сам пакет целиком. Применяется, в частности, для организации работы l7-filter-userspace.- устаревшая версия NFQUEUE. Не имеет параметров, так как работает только с очередью номер 0.

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

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

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

.6.5 Таблица mangle

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

Таблица mangle содержит следующие цепочки (Рис. 3):- позволяет модифицировать пакет до принятия решения о маршрутизации.- позволяет модифицировать пакет, предназначенный самому хосту.- цепочка, позволяющая модифицировать транзитные пакеты.- позволяет модифицировать пакеты, исходящие от самого хоста.- дает возможность модифицировать все исходящие пакеты, как сгенерированные самим хостом, так и транзитные.

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

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

.6.6 Таблица filter

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

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

Допустимыми действиями в таблице filter являются:- пропуск пакета. Пакет покидает текущую базовую цепочку и следует дальше по потоковой диаграмме (см. рис.).- заблокировать пакет и сообщить его источнику об отказе. По умолчанию об отказе сообщается отправкой ответного 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).- заблокировать пакет, не сообщая источнику об отказе. Более предпочтительна при фильтрации трафика на интерфейсах, подключенных к интернету, так как понижает информативность сканирования портов хоста злоумышленниками.

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

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

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

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

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

libpcap-1.1.1.tar.gz

libdnet-1.11.tar.gz.0.0.tar_queue-1.0.0.tar-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 .HOME_NET 1.2.3.4 # ip-адрес нашего сервераEXTERNAL_NET anyHTTP_SERVERS $HOME_NET HTTP_PORTS [80,8080]

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

var RULE_PATH /etc/snort/rulesPREPROC_RULE_PATH /etc/snort/preproc_rules

# настраиваем режим inlinedaq: iptablesdaq_mode: inlinepolicy_mode: inline

# папки с процессорамиdirectory /usr/local/lib/snort_dynamicpreprocessor//usr/local/lib/snort_dynamicengine/libsf_engine.so

# фрагментация пакетовfrag3_global: max_frags 65536frag3_engine: policy linux

# tcp и udp процессорstream5_global: max_tcp 8192, track_tcp yes, track_udp nostream5_tcp: policy linux

#preprocessor stream5_udp: ignore_any_ruleshttp_inspect: global iis_unicode_map unicode.map 1251http_inspect_server: server default profile apache no_alerts ports { 80 8080 8180 } oversize_dir_length 500alert_syslog: LOG_ALERT

# инклудим классификаторы траффикаclassification.configreference.config

# подключение правил$RULE_PATH/local.rules

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

# убиваем UNION SQL injectiontcp any any -> $HOME_NET $HTTP_PORTS (msg:"UNION SQL Injection";uricontent:"union";nocase;uricontent:"select";nocase;sid:1;gid:666;)

# убиваем blind SQL injectiontcp any any -> $HOME_NET $HTTP_PORTS (msg:"Blind SQL Injection";uricontent:"ascii";nocase;uricontent:"substr";nocase;uricontent:"select";nocase;sid:2;gid:666;)

# убиваем XSS/CSStcp any any -> $HOME_NET $HTTP_PORTS (msg:"XSS/CSS attack";uricontent:"";nocase;sid:4;gid:666;)

# убиваем хитрый XSS/CSStcp any any -> $HOME_NET $HTTP_PORTS (msg:"XSS/CSS attack";pcre:"/GET \/.*\?.*=(javascript:|onclick=|onmouseover=|onmouseout=|onload=).*\n/i";sid:5;gid:666;)

# убиваем ../../../etc/passwdtcp any any -> $HOME_NET $HTTP_PORTS (msg:"PHP include attack";uricontent:"=../..";sid:6;gid:666;)

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

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

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

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

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

с - путь к конфигу

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

iptables -t nat -A PREROUTING -j NFQUEUE --queue-num 2

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

Заключение

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

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

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

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

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

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

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

.        Викиучебник. 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/123474/

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