SNORT как сервисная IPS
Введение.
Про SNORT было сказано много, но в большинстве статей речь идёт о SNORT, как о средстве тотального наблюдения за сетью, которое собирает все данные с сетевого интерфейса. В этой статье я расскажу как собрать конструкцию, в которой SNORT будет в режиме IPS следить не за всем трафиком на интерфейсе, а только за трафиком, который можно описать с помощью правил для iptables. Я не буду касаться настройки правил, речь будет исключительно о том, как на голой системе собрать SNORT для работы в режиме IPS и как подойти к защите им абстрактного сервиса. Так же будет описана сборка и запуск SNORT.
Как работает?
Поступив в SNORT, пакет последовательно проходит через декодеры, препроцессоры и только потом уже попадает в детектор, который начинает применять правила. Задача декодеров сводится к тому, чтоб из протоколов канального уровня( Ethernet, 802.11, Token Ring…) «вытащить» данные сетевого и транспортного уровня (IP, TCP, UDP).
Задачей препроцессоров является подготовка данных из протоколов транспортного и сетевого уровней к процессу применения правил. Для нашего случая мы будем использовать препроцессор для работы с 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 ?
В модели 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
Идём на веб-морду, находим и устанавливаем плагин:
Далее добавляем источник данных – файл. Там всё интуитивно понятно и единственный тонкий момент, в том что Source Type нужно задать вручную: snort_alert_full. Когда всё готово, то генерируем алерт ( через netcat посылаем abc123 на защищаемый порт). И видим в splunk:
В столбце слева представлены данные, которые распознал парсер и по которым строятся индексы для входящих данных. По этим данным можно проводить анализ, используя встроенный язык запросов, можно строить графики, можно отображать источники на карте и многое, многое другое.
К тому же, процесс создания собственных плагинов описан на сайте производителя, что позволяет создать свой плагин, который будет заточен под конкретную задачу.
Источник
Система обнаружения вторжения для Чайников. Установка и Конфигурирование SNORT.
Snort – облегченная система обнаружения вторжения . Snort обычно называют “обгегченным” NIDS, — потому что это он разработан прежде всего для маленьких сетей. Программа может исполнять анализ протокола и может использоваться, чтобы обнаружить разнообразные нападения и исследовать проблемы, типа переполнения буфера, скрытых просмотров порта, CGI нападения, попыток определения OS и т.п. Snort использует ‘правила’ (указанные в файлах ‘правила’), чтобы знать какой трафик пропустить а какой задержать. Инструмент гибок, позволяя вам записывать новые правила и соблюдать их . Программа также имеет ‘ механизм обнаружения ‘, который использует модульную сменную архитектуру, посредством чего определенные дополнения к программе могут быть добавлены или удалены из ‘ механизма обнаружения’.
Snort может работать в трех режимах:
1. Как пакетный снифер, подобно tcpdump
2. Как регистратор пакета
3. Как развитая система обнаружения вторжения
В этой статье мы подробно расскажем о инсталляции Snort, его архитектуре, научимся создавать правила и управлять ими.
Платформа:
Linux 2.2.* ,
Snort 1.7(http://www.snort.org/)
Sparc: SunOS 4.1.x, Solaris, Linux, and OpenBSD
x86: Linux, OpenBSD, FreeBSD, NetBSD, and Solaris
M68k/PPC: Linux, OpenBSD, NetBSD, Mac OS X Server
Требования:
Tcpdump (www.tcpdump.org)
Libpcap (Snort основан на библиотеке libpcap, обычно используемой в большинстве TCP/IP сниферов и анализаторов) – скачать можно отсюда: ftp://ftp.ee.lbl.gov/libpcap.tar.Z
Компилирование и Установка SNORT
Основной сайт для Snort — http://www.snort.org. Snort распространяется согласно лицензии GNU GPL автором Мартином Роешом. После загрузки архива, разархивируем его в каталог snort-1.7:
root @lord]# tar -zxvf snort-1.7.tar.gz
После загрузки libpcap, разархивируйте его подобным образом. Войдите в каталог libpacp, и выполните следующие шаги:
root @lord]# ./configure root @lord]# make
Теперь, мы компилируем Snort. Войдите в каталог, в котором находится Snort, и выполните следующие команду:
root @lord]# ./configure —with-libpcap-includes=/path/to/libpcap/ <* in my case it was : root@lord ./configure --with-libpcap-includes=/home/dood/libpcap >
root @lord]# make root @lord]# make install
Snort теперь установлен на вашей машине.
Создайте директорию, в которой Snort будет хранить файлы регистрации:
root @lord]#mkdir /var/log/snort
И как всегда, выполните:
root @lord]# whereis snort
чтобы подтвердить, где установлен Snort.
Основы структуры Snort
Архитектура Snort состоит из трех основных компонентов, которые могут быть описаны как:
1. Дешифратор пакетов : готовит перехваченные пакеты в форму типа данных, которые затем могут быть обработаны механизмом обнаружения. Дешифратор пакетов может регистрировать Ethernet, SLIP и PPP пакеты.
2. Механизм Обнаружения : анализирует и обрабатывает пакеты, поданные к нему “Дешифратором”, основываясь на правилах Snort. Сменные модули могут быть включены в механизм обнаружения, чтобы увеличить функциональные возможности Snort.
3. Logger/Alerter : Регистратор позволяет вам регистрировать информацию, собранную дешифратором пакетов в удобочитаемом формате. По умолчанию файлы регистрации сохранены в каталоге :/var/log/Snort.
Механизм предупреждения посылает предупреждения к syslog, файлу, Unix sockets или базе данных. По умолчанию, все предупреждения сохранены в файле: /var/log/Snort/alerts.
Использование SNORT и его режимы
В этом разделе мы обсудим концепции и команды SNORT в подробностях. Начнем с простой команды, которая отображает все ключи программы:
Команда выдаст следующее:
-*> Snort!
Как уже говорилось, SNORT выполняется в трех различных режимах:
1. Режим пакетного снифера : Когда Snort работает в этом режиме, он читает и дешифрует все сетевые пакеты и формирует дамп к stdout (ваш экран).
Для перевода Snort в режим сниффера используйте ключ –v:
root @lord]# ./snort –v
Примечание : В этом режиме он показывает только заголовки пакетов.
Для просмотра заголовка + содержания пакета выполните:
root @lord]# ./snort -X
2. Режим регистрации пакетов : Этот режим записывает пакеты на диск и декодирует их в ASCII формат.
root @lord]# Snort -l
2. Режим обнаружения вторжения :
Сигнальные данные регистрируются механизмом обнаружения (по умолчанию файл называемый » alert» в каталоге регистрации, но можно через syslog, Winpop сообщения и т.д.) Каталог регистрации по умолчанию -/var/log/snort , может быть изменен, используя ключ «-l».
Теперь рассмотрим типичную команду Snort для анализа пакета:
root @lord]# snort -v -d -e -i eth0 -h 192.168.3.0/24
Здесь, мы рассматриваем подсеть класса C в пределах от 192.168.3.0-192.168.3.255 (маска подсети: 255.255.255.0). Сделаем подробный разбор вышеупомянутой команды, чтобы понять, что она означает:
‘-v ‘ : посылает подробный ответ на вашу консоль.
‘- d ‘: формирует дамп декодированных данных прикладного уровня
‘- e ‘: показывает декодированные Ethernet заголовки.
‘- i ‘: определяет интерфейс, который будет проверен для анализа пакета.
‘- h ‘: определяет сеть, которой нужно управлять
В следующем примере мы заставим Snort генерировать предупреждения:
Режимы предупреждения Snort состоят из трех основных групп (можно задавать свои):
a. Быстрый: записывает предупреждения в файл ‘alert’ в одну строку, так же как и в syslog.
b. Полный: записывает предупреждения в файл ‘alert’ c полным декодированным заголовком.
c. None: — не выдает предупреждения.
Команда тогда изменится на следующую:
root @lord]# snort -v -d -e -i eth0 -h 192.168.3.0/24 -A fast
Чтобы посылать аварийные сообщения syslog, используйте ключ ‘- s’ вместо этого. Предупреждения появятся в /var/log/secure или /var/log/messages :
root @lord]# snort -v -d -e -i eth0 -h 192.168.3.0/24 -s
До сих пор все перехваченные и проанализированные пакеты показывались на вашем экране. Если вы хотите, чтобы Snort записывал их в ваш файл регистрации, вы должны использовать опцию «-l » и указать имя директории для записи логов (например /var/log/snort ):
root @lord]#snort -v -d -e -i eth0 -h 192.168.3.0/24 -A full -l /var/log/snort
Чтобы регистрировать пакеты в формате tcpdump и производить минимальные предупреждения, используйте ключ ‘ -b ‘:
root @lord]#snort -b -i eth0 -A fast -h 192.168.3.0/24 -s -l /var/log/snort
В вышеупомянутых командах, Snort регистрирует все пакеты в вашем сегменте сети. Если вы хотите регистрировать только некоторые типы пакетов в зависимости от правил, используете ключ ‘ -c ‘.
root @lord]# snort -b -i eth0 -A fast -h 192.168.5.0/24 -s -l /var/log/snort -c /snort-rule-file.
Дополнительную информацию можно получить здесь:
Источник
