Pull to refresh

SNORT как сервисная IPS

Reading time 6 min
Views 92K
Введение.

Про SNORT было сказано много, но в большинстве статей речь идёт о SNORT, как о средстве тотального наблюдения за сетью, которое собирает все данные с сетевого интерфейса. В этой статье я расскажу как собрать конструкцию, в которой SNORT будет в режиме IPS следить не за всем трафиком на интерфейсе, а только за трафиком, который можно описать с помощью правил для iptables. Я не буду касаться настройки правил, речь будет исключительно о том, как на голой системе собрать SNORT для работы в режиме IPS и как подойти к защите им абстрактного сервиса. Так же будет описана сборка и запуск SNORT.

Как работает?


Поступив в SNORT, пакет последовательно проходит через декодеры, препроцессоры и только потом уже попадает в детектор, который начинает применять правила. Задача декодеров сводится к тому, чтоб из протоколов канального уровня( Ethernet, 802.11, Token Ring…) «вытащить» данные сетевого и транспортного уровня (IP, TCP, UDP).

image

Задачей препроцессоров является подготовка данных из протоколов транспортного и сетевого уровней к процессу применения правил. Для нашего случая мы будем использовать препроцессор для работы с TCP, список решаемых им задач в общем виде такой:
  • Контроль состояния (контроль соблюдения протокола)
  • Сборка сеанса (объединение данных из нескольких пакетов сеанса)
  • Нормализация протокола (довольно скользкая фича с правкой заголовка пакета на лету)

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

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

Компиляция SNORT.


Качаем последнюю Ubuntu 11.04. Установка описана для 32х разрядной системы. Скачиваем всё необходимое:

daq-0.5.tar.gz
libdnet-1.11.tar.gz
libnetfilter_queue-1.0.0.tar
libnfnetlink-1.0.0.tar
libpcap-1.1.1.tar.gz
pcre-8.12.zip
snort-2.9.0.5.tar.gz
snortrules-snapshot-2903.tar.gz


Устанавливаем необходимые пакетики:

apt-get install bison flex gcc g++ zlib1g-dev

Конфигурируем и устанавливаем из исходников скачанный софт в следующем порядке:

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

Если при конфигурации daq мы видим строчку «Build NFQ DAQ module… :yes» и всё скомпилировалось без проблем, то мы на верном пути. Теперь ключевой момент всей затеи – сборка 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-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– поддержка обработки сжатого трафика.

Далее make; make install. SNORT установлен.

Настройка боевого пуска.


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

# Пункт 1: Глобальные переменные для конфига
#Используются в кофиге и правилах
var HOME_NET any
var RULE_PATH ../rules
# Пункт 2: настройка декодеров
config disable_decode_alerts
……
# Пункт 3: настройка детектора
# Разные тонкости применения правил
config pcre_match_limit: 3500
……
# Пункт 5: Настройка препроцессоров
# Препроцессоры нормализации пакетов
# нормализуют протоколы на лету, от чего,иногда, случаются неожиданности
preprocessor normalize_ip4
….
# Препроцессор обработки дефрагментированых пакетов
preprocessor frag3_global: max_frags 65536

# Препроцессоры контроля состояний и построения сеансов
preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp ….

# Пункт 6: подключение библиотек детализации вывода
include classification.config
…..
# Пункт 7: подключение правил
include $RULE_PATH/test.rules

Для простоты в файле test.rules у нас будет только одно правило:
reject tcp any any -> any any (msg:"Test pattern for snort abc123"; content:"abc123"; classtype:shellcode-detect; sid:310; rev:1;)
Это правило говорит, что в случае обнаружения во входящих tcp пакетах подстроки abc123, то источнику немедленно будет послан RST, и сеанс будет прерван. Опасный пакет дальше IPS в систему не попадёт. Запускаем SNORT:

snort -Q --daq nfq --daq-var queue=2 -c /home/ubuntu/Downloads/snort/etc/snort.conf -l /var/log/snort -A full

-Q – работа в режиме IPS
--daq – источника пакетов
--daq-var – параметры источника пакетов
– путь к конфигу
-l – путь к логам
-A full – подробные логи (описание атак и дампы трафика)
-D – работа в режиме демона ( использовать, когда всё отлажено)

Если запуск обломился с ошибками, то не стоит печалиться – скорей всего нужно подправить пути к файлам в конфиге.

Создание очереди.


Пакетный фильтр системы можно настроить так, чтоб он передавал полученный пакет с уровня ядра на уровень пользователя, где пользовательская программа будет обрабатывать его и передавать обратно на уровень ядра, в нашем случае эта программа — SNORT. Так как SNORT у нас запущен для работы с нумерованнной очередью (NFQUEUE), то нам необходимо фильтруемый трафик в эту очередь поставить:
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j NFQUEUE --queue-num 2

Зачем была выбрана цепочка PREROUTING ?


image

В модели Iptables пакет попадает в базовую очередь PREROUTING до того, как к нему будут применены какие-либо правила маршрутизации. Отправка пакета в SNORT на этом этапе удобна тем, что далее мы можем его либо обрабатывать локально, либо переслать его дальше, например, используя NAT. Плюсом использования нумерованных очередей является то, что очередей можно создать несколько и трафик каждой очереди пропустить через снорт, запущенный с набором правил, заточенным под фильтруемый трафик. Серьёзным минусом такого подхода является то, что в случае падения SNORT, защищаемый сервис становится недоступен, так как передавать данные из режима пользователя назад в ядро становится некому. После запуска SNORT и создания очереди следует сразу же проверить работу, послав, например через netcat, в очередь сигнатуру из правила – abc123. Если всё было сделано правильно, то соединение будет немедленно разорвано.

Мониторинг.


Запущенный с описанными параметрами SNORT будет для каждой выявленной угрозы писать в alert файл (так же он может писать в базу или отправлять syslog):

[**] [1:310:1] Test pattern for snort abc123 [**]
[Classification: Executable Code was Detected] [Priority: 1]
01/19-12:03:12.155213136 172.16.249.1:56473 -> 172.16.249.130:8080
TCP TTL:64 TOS:0x0 ID:1241 IpLen:20 DgmLen:59 DF
***AP*** Seq: 0x9510F391 Ack: 0xC40C0E14 Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 125531844 9470333


И писать в log файл кусок сеанса в котором была обнаружена сигнатура, это может пригодиться для выявления ошибок детектирования. На этом работа SNORT заканчивается и в дело вступают «системы анализа логов SNORT». Де факто, это наборы скриптов разной степени убогости, к которым, в некоторых случаях, прилагается душераздирающий «веб интерфейс» (BASE, ACID…). Основные их недостатки – неспособность проводить гибкий анализ данных и неэффективная работа с СУБД, которая выливается в неспособность работать с большими объёмами данных. По моему опыту, единственным решением, которое делает работу с логами снорта сносной, является Splunk. В общем виде, Splunk – система управлениями логами, которая сохраняет их, индексирует и обсепечивает удобный интерфейс для работы с получившейся базой. Это проприетарное ПО, которое является условно бесплатным (объём индексируемых данных в сутки не более 500Мb, что для snort более чем достаточно). Система сочетает в себе удобство управления и способность работать с большими объёмами данных, и самое главное: для этой система существует плагин, специально заточенный для работы с логами SNORT. Скачать Splunk можно здесь

Устанавливаем splunk:
dpkg -i splunk-4.2.1-98164-linux-2.6-intel.deb
Запускаем:
/opt/splunk/bin/splunk start

Идём на веб-морду, находим и устанавливаем плагин:

image
Далее добавляем источник данных – файл. Там всё интуитивно понятно и единственный тонкий момент, в том что Source Type нужно задать вручную: snort_alert_full. Когда всё готово, то генерируем алерт ( через netcat посылаем abc123 на защищаемый порт). И видим в splunk:

image

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

image

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

Заключение.

Перед запуском снорта в продуктив, чтоб не было потом мучительно больно, следует:
  • Выстроить систему управление версиями правил и хранить правила на стороннем хосте (SVN вполне годится).
  • Разработать план аварийного режима работы (если снорт упал, и трафик не ходит).
  • Recovery plan на случай, если железка со снортом сломается с потерей данных.
  • Создать тестовое правило типа описанного выше abc123, которым следует проверять работу снорта каждый раз после внесения каких-либо изменений.

С удовольствием отвечу на вопросы.
Tags:
Hubs:
+21
Comments 23
Comments Comments 23

Articles