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

Linux > Возможности Snort
15.11.2014 17:17:53



Статья:

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

Snort является сетевой системой обнаружения атак с открытым исходным кодом, способной выполнить в реальном времени анализ IP-пакетов, передаваемых на контролируемых интерфейсах, с целью обнаружения атак или попыток поиска уязвимостей. Snort обнаруживает атаки, комбинируя два метода: сигнатурный и анализ протоколов.
Всю собранную информацию детектор Snort позволяет сохранить в файлах журналов, которые могут иметь различный формат: обычный ASCII текстовый файл или бинарный формат, совместимый с tcpdump. Кроме того, для удобства анализа всю собранную информацию можно занести в базу данных: Postgresql, MySQL, unixODBC и некоторые другие.
Система, построенная на датчиках Snort, способна собирать и обрабатывать информацию с нескольких разнесенных датчиков. Все в дело в производительности компьютеров, используемых в качестве сенсоров. Для того чтобы улучшить производительность, разделяя быструю работу IDS по захвату пакетов и относительно медленную по занесению информации, необходимо использовать Barnyard, который доступен на странице закачки проекта Snort. В этом случае Snort создает специальный двоичный выходной «унифицированный» формат, с которым в дальнейшем и работает Barnyard.


Snort and Wireless

Snort непосредственно не умеет работать с беспроводными 802.11 сетями, но подключенный к такому устройству сможет интерпретировать полученную информацию. Сегодняшний Snort в принципе не делает различия в том, с каким типом сети он имеет дело, никаких специфических опций при установке также задавать не надо. Как обычно указываем интерфейс ?-i?, и Snort начинает анализ пакетов в режиме raw monitoring (RFMON), без привязки к специфической сети, собирая все пакеты, попадающиеся в радиоэфире. Чтобы контролировать только свою сеть? необходимо соответствующим образом настроить Wi-Fi устройство или настроить систему фильтров. Сети IEEE 802.11 используют три вида пакетов: управления, контроля и данных.
Чтобы отслеживать первые два типа, необходимо добавить в строку запуска параметр ?-w?. Для более эффективной защиты можно использовать орудие нападения — Kismet. Он умеет отлично сканировать эфир, а значит, его можно применять для поиска посторонних устройств. Анализируя данные с различных точек доступа и Wi-Fi-карт в связке с Snort, можно дать отпор даже опытному хакеру.
Существует специальное ответвление Snort – Snort-Wireless, как раз предназначенный для обнаружения атак, направленных на сети стандарта 802.11. Snort-Wireless обратно совместим с Snort 2.0, при этом содержит некоторые специфические правила обработки пакетов, настроенных на специфические уязвимости и типичные атаки беспроводных сетей. Последние обновления датированы ноябрем 2005 года, на сайте доступен патч для Snort 2.4.3 (требующий при компиляции опции ?--enable-wireless?), также имеется и уже патченая версия Snort. Функционально Snort-Wireless мало отличается от Snort, дополнительно в его состав включен набор правил wifi.rules, содержащий описание специфических уязвимостей и ряд препроцессоров. В настоящее время реализовано пять препроцессоров:

  1. AntiStumbler (spp_antistumbler) – распознает рассылку большого количества нулевых SSID с одного MAC-адреса, что используют NetStumbler и MacStumbler для обнаружения точек доступа;
  2. DeauthFlood (spp_deauth_flood) – подсчитывет количество кадров деаутентификации и при превышения порога поднимает тревогу;
  3. AuthFlood (spp_auth_flood) – определяет количество попыток аутентификации, что может свидетельствовать о возможной DOS атаке;
  4. MacSpoof (spp_macspoof) – отслеживает попытки подмены МАС адреса;
  5. RogueAP (spp_rogue_ap) – его задача сообщать о присутсвии других точек доступа.

В Snort таких препроцессоров нет, поэтому для защиты беспроводной сети имеет смысл использовать именно Snort-Wireless.


Ставим Snort

На момент написания статьи актуальной была версия 2.6.1.1. В репозитарии Ubuntu, который использовался при написании статьи, 2.3.3. Хотелось бы отметить, что подкаталог contrib, содержащий различные дополнения к Snort, начиная с версии 2.2.0, пустует. Скрипты для создания баз данных переместились в подкаталог schemas, а для создания rpm-пакетов в одноименный подкаталог. Остальные же расширения можно найти на странице www.snort.org/dl/contrib. Все сказано, можно начинать установку.
Распаковываем архив:

# tar –xzvf snort-2.6.1.1.tar.gz

Конфигурируем. В самом простом случае скрипту не нужно передавать никаких параметров. Если же необходимо использовать базу данных, то например для MySQL добавляем опцию ?--with-mysql?. Начиная с версии 2.3.0 RC1, в Snort включен код проекта Snort-inline, тем самым он получил возможность не только выявлять, но и останавливать начавшуюся атаку, перестраивая правила iptables. И теперь Snort является полноценной системой предотвращения атак, для включения этого режима добавляем ?--enable-inline?.

 
# ./configure --with-mysql
# make
# make install


Настройка Snort

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

# mkdir /etc/snort

А здесь будет вестись журнал работы:

# mkdir /var/log/snort

Теперь в каталог /etc/snort копируем все, что лежит в подкаталоге etc дистрибутива:

 
# cp –R ./etc/* /etc/snort/

Далее распаковываем файл правил и помещаем их в /etc/snort/rules. В принципе, место для правил можно выбрать любое, но так удобнее, да и считается традиционным:

# tar –xzvf snortrules-snapshot-CURRENT.tar.gz
# mv rules /etc/snort

Увеличить

Рис. 1. Мастер настройки пакетов Ubuntu поможет настроить Snort


Играем по правилам

Для описания событий, которые могут считаться злонамеренными или аномальными, используется гибкий язык правил, плюс модульная система анализа. Сегодня существует два типа правил. Официальные сертифицированные и строго протестированные «Sourcefire VRT Certified Rules», распространяющиеся по лицензии VRT Certified Rules License Agreement, ограничивающей их коммерческое использование. Эти правила доступны в двух вариантах: для зарегистрированных и не зарегистрированных пользователей. Регистрация абсолютно бесплатна. Все изменения в первую очередь распространяются подписчикам (subscription release с буквой «s» в названии пакета), затем становятся доступными для зарегистрированных пользователей (без буквы «s»). Те же, кто не зарегистрировался, довольствуются статистическими правилами, обновляемыми лишь к каждому релизу Snort и естественно отстающими от жизни (они имеют префикс «pr» в названии). Второй тип правил называется Community Rules. Эти правила создаются добровольцами, но они еще не прошли проверку, и распространяются под лицензией GPL. Для загрузки Certified Rules необходимо зайти на страницу Download Rules, выбрать нужное правило и изменить ссылку. Например, ссылка на VRT Certified Rules for Snort CURRENT выглядит так: www.snort.org/pub-bin/downloads.cgi/Download/vrt_os/snortrules-snapshot-CURRENT.tar.gz. Но нажав на нее, файл не получишь. Необходимо сначала ее преобразовать к такому виду: www.snort.org/pub-bin/oinkmaster.cgi/код_полученный_при _регистрации/vrt_os/snortrules-snapshot-CURRENT.tar.gz. Учти, что при ошибке ввода повторная закачка будет возможна лишь через 15 минут, также нельзя пользоваться некоторыми менеджерами закачки.
Давай рассмотрим одно правило, для того, чтобы было ясно, как они пишутся. Вдруг тебе понадобится самому писать правило, либо захочешь разобраться в том, что конкретно делает то или иное правило. Возьмем одно правило из файла community-smtp.rule:

alert tcp !$SMTP_SERVERS any -> any 25 (msg:»COMMUNITY SMTP Mytob MAIL
FROM Attempt»; flow:established,to_server; content:»MAIL FROM|3A|»; nocase;
pcre:»/MAILs+FROMs*x3As*x3C?(spm|fcnz|www|secur|abuse)@/i»;
reference:url,www.symantec.com/avcenter/venc/data/w32.mytob@mm.html;
classtype:misc-attack; sid:100000689; rev:1;)

Не смотря на довольно внушительный вид, правило довольно простое, и если разобрать его по частям, то все становится на свои места. Первая строка говорит о том, что все сообщения по протоколу TCP, направленные с любого порта на порт 25 (что говорит о почтовых сообщениях), с определенным адресом в поле отправителя принадлежат вирусу-червю W32.Mytob@mm, ниже дан комментарий (reference), позволяющий найти более подробную информацию об уязвимости на сайте Symantec. Некоторые правила, занимают несколько экранов монитора.
Директива alert указывает на действия, которые должен производить Snort при обнаружении пакета, попадающего под это правило. По умолчанию имеется 5 действий: alert, log, pass, activate и dynamic. Кроме того, в режиме inline доступны еще три: drop, reject и sdrop. Правило может быть односторонним (->) и двусторонним (< >), когда направление движения пакета роли не играет.


Файл конфигурации snort.conf

И последний шаг, который осталось сделать — это отредактировать конфигурационный файл/etc/snort/snort.conf. В дистрибутиве уже имеется готовый шаблон, поэтому с нуля его писать не придется. В файле используются переменные, в том числе встречающиеся и в правилах. Это довольно удобно, при смене какого либо параметра затем не придется его переписывать несколько раз. Кроме того, некоторые опции вынесены во внешние файлы, которые подключаются директивой include с именем файла. Все параметры щедро снабжены комментариями, начинающимися традиционно со знака решетки. Для удобства восприятия файл разбит на пять частей:

  1. Установка переменных сети
  2. Настройка препроцессоров
  3. Настройка вывода информации
  4. Установка дополнительных директив
  5. Модификация правил

Для нормальной работы достаточно настроить первые три пункта, остальные можно пока не трогать.
Переменная HOME_NET определяет IP адреса, которые Snort будет считать домашними. Возможно задание отдельного адреса или диапазона. Если требуется указать несколько адресов, они перечисляются через запятую. Ключевое слово «any» означает любой адрес. Например:

var HOME_NET 192.168.1.0/24
var HOME_NET [10.1.1.0/24,192.168.1.0/24]

Переменная EXTERNAL_NET указывает на внешние узлы. По умолчанию значение стоит как any, можно оставить, как есть. А можно указать более логично, что все, не являющееся домом, будет внешним:

var EXTERNAL_NET !$HOME_NET

Ниже в файле идет список серверов (DNS, SMTP, web, sql, telnet и snmp), используемых в сети. Можно оставить, как есть, т.е. $HOME_NET или указать конкретный IP-адрес, но с другой стороны, если у нас нет web-сервера, то зачем отслеживать специфические для него атаки? Поэтому лишнее можно смело отключить. Далее задаются номера портов, используемых серверами. Это позволяет Snort не распылять ресурсы, а искать атаку более конкретно. Принцип тот же: если нет Oracle, то соответствующую строку лучше закомментировать. Обратите внимание, что номер порта может быть задан как единичный [80] и как непрерывный [80:8080]. Перечисление портов через запятую работать не будет (уже несколько лет обещают исправить этот момент). Поэтому если web-сервер использует два порта, то писать необходимо так:

var HTTP_PORTS 80
var HTTP_PORTS 8080

Препроцессоры, подключаемые во второй секции «Configure preprocessors», штука довольно серьезная и в хозяйстве, как говорится, полезная, но требующая некоторого времени для того, чтобы разобраться с назначением и особенностями работы. Обрати внимание, что некоторые препроцессоры дублируют друг друга, поэтому включать все сразу также не имеет смысла. Так вместо Portscan и Flow-Portscan разработчики рекомендуют использовать sfPortscan, разработанный в Sourcefire и предназначенный для тех же целей, т.е. определение сканирования портов. Более быстрый в работе модуль Frag3, предназначенный для дефрагментации IP-пакетов, пришел на замену более старому Frag2. Кроме того, некоторые препроцессоры направлены на определение аномалий в работе определенных сервисов. Так X-Link2State предназначен для определения уязвимости в Exchange Server, а HTTPInspect изучает аномалии в http трафике.


Настройка вывода данных

В третьей секции «Configure output plugins», как уже говорилось, настраиваются выходные параметры. В общем случае строка параметров имеет такой вид:

output <name_of_plugin>: <configuration_options>

В настоящее Snort может использовать 10 плагинов для вывода информации (каждый из которых имеет дополнительные опции):

  • alert_syslog – для вывода информации используется демон syslog. Модуль позволяет настроить приоритеты сообщений и уровень;
  • alert_fast – информация о возможной атаке выводится в указанный в качестве дополнительного параметра файл в сокращенном формате без подробностей;
  • alert_full – модуль, подходящий для небольших сетей, т.к. сильно тормозит работу Snort. Заголовок пакета выводится полностью, в лог-каталоге будет создан подкаталог, по каждому IP в который будут записываться пакеты, вызвавшие предупреждение;
  • alert_unixsock – похож на предыдущий, но только информация в реальном времени передается в Unix-сокет, откуда может быть считана любой другой программой;
  • log_tcpdump — записывает в указанный файл (к его имени будет добавляться метка времени, поэтому затереть его при перезапуске не получится) перехваченные пакеты в формате утилиты tcpdump;
  • database – модуль, позволяющий заносить информацию в базу данных;
  • csv – вывод в файл формата csv, который может быть использован для занесения информации в базу данных. Кроме имени файла необходимо перечислить параметры, которые заносятся в файл;
  • unified – выводит данные в специальном формате, оптимизированном для обработки внешними утилитами, которые затем будут заниматься регистрацией события;
  • alert_prelude – доступен при конфигурировании с опцией ?--enable-prelude?, в этом случае Snort используется как датчик гибридной IDS Prelude;
  • log_null – в этом случае Snort способен реагировать на указанные предупреждения без регистрации пакетов.

И, наконец, в конце файла найдешь секцию 5 «Customize your rule set», в которой необходимо убрать комментарии, указывающие на файлы с правилами:

include $RULE_PATH/local.rules
include $RULE_PATH/bad-traffic.rules

# include $RULE_PATH/multimedia.rules
# include $RULE_PATH/p2p.rules
include $RULE_PATH/experimental.rules

Названия правил говорят сами за себя. Оставь то, что действительно нужно (хотя если сомневаешься, лучше включить все). По умолчанию файл local.rules пуст, в него заносит свои правила сам пользователь.

Увеличить

Рис. 2. Snort в режиме захвата пакетов


Запуск Snort

После того, как все готово, можно запускать Snort. Для работы в режиме сниффера Snort запускается с флагом ?–v?. При этом на экран будут выводиться заголовки пакетов. Если же есть желание просмотреть и передаваемую информацию, используй следующую команду:

# snort -vd

Если в системе один интерфейс, то программа сама разберется, с чем ей работать. Иначе его требуется указать c помощью ?–i?:

# snort –vd -i eth0

Можно указать на конкретную информацию, которую требуется захватить. Например, устанавливаем в качестве домашней сети 192.168.1.0 и захватываем пакеты с узла 192.168.1.1:

# snort -h 192.168.1.0/24 -d -v host 192.168.1.1

Для регистрации пакетов в общем случае указываем каталог, куда следует записывать информацию:

# snort -l ./log

Если на выходе требуется файл в формате tcpdump, то добавляем параметр ?–b?.
И, наконец, работа в режиме системы обнаружения атак. Так как файл snort.conf уже создан, то поступаем просто:

# snort -c /etc/snort/snort.conf

Для тестирования набираем «ping –s 65507 ip_адрес«. После чего, если выбран соответствующий режим ведения журнала, в каталоге /var/log/snort появится файл с предупреждением о потенциально опасном пакете:

[**] [1:499:3] ICMP Large ICMP Packet [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
15/11-18:21:2.1131991802 192.168.0.1 -> 192.168.0.20
ICMP TTL:255 TOS:0?0 ID:18479 IpLen:20 DgmLen:63028
Type:0 Code:0 ID:512 Seq:19456 ECHO REPLY
[Xref => arachnids 246]

При всестороннем тестировании работы Snort следует использовать специальные утилиты вроде IDSwakeup.
Для автоматического запуска Snort при загрузке системы необходимо использовать скрипт snortd, который лежит в подкаталоге rpm дистрибутива. Копируем его в /etc/rc.d/init.d и даем команду:

# chkconfig snortd on