Документация по ОС FreeBSD Четверг, 28.03.2024, 21:27
Приветствую Вас Гость | RSS
Меню сайта

Категории каталога
Мои статьи [0]
Установка и настройка [281]
X Window [25]
Man pages [30]
Ports & Packages [26]
cvs [18]
Multimedia [20]
Нововсти в мире Unix [0]
RFC [4]
RFC (Request for Comments, Запрос на комментарии) - серия документов, публикуемая сообществом исследователей и разработчиков, руководствующихся практическими интересами, в которой описывается набор протоколов и обобщается опыт функционирования Интернет.
Безопасность [52]
Работа с железом [58]
Книги по FreeBSD [17]
Сеть [505]
Программирование [40]
FireWall [58]
Темы экзамена BSDA [14]
Официальные темы экзамена BSDA, включая подробноые описания и советы по обучению.

Главная » Статьи » Безопасность

Доверься ищейке. Прикручиваем к Snort систему блокировки атак SnortSAM и веб-консоль BASE [2009]

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


Наиболее популярной OpenSource системой NIDS (Network Intrusion Detection System) и системой предотвращения вторжений (Intrusion Prevention System) является Snort (www.snort.org). Это мощный инструмент, способный обнаруживать и блокировать атаки (с помощью внешних программ вроде SnortSAM). Принцип работы Snort довольно прост: все пакеты захватываются снифером, затем анализируется их содержимое, и при совпадении с правилами выдается предупреждение. Распознаются некоторые методы сканирования, попытки определить ОС и использовать в ней уязвимости, сетевые атаки, наличие вирусов в файлах и т.д. Вся информация протоколируется и записывается либо в файлах журналов разного формата (обычный текстовый ASCII или бинарный tcpdump формат), либо в СУБД (MySQL, PostgreSQL). Система с установленной Snort обычно ставится «на входе» сети (например, в демилитаризованной зоне). Для обеспечения максимальной эффективности возможно использование дополнительных сенсоров на других системах.

Установка Snort

Итак, после небольшого вступления рассмотрим процесс установки Snort с плагином SnortSAM на FreeBSD 7.x. Для наглядного анализа собранной информации будем использовать веб-консоль BASE. Первым делом обновляем порты:

# portsnap fetch
# portsnap update

Устанавливаем Snort, подключив поддержку MySQL и плагина SnortSAM:

# cd /usr/ports/security/snort
# make -DWITH_MYSQL -DWITH_SNORTSAM
# make install

При сборке без параметров просто отмечаем нужные флажки. Как и большинство портов, все файлы конфигурации Snort располагает в каталоге /usr/local/etc и скрипт запуска – в /usr/local/etc/rc.d. Конфигурационный файл snort.conf находится в подкаталоге /usr/local/etc/snort вместе с некоторыми другими файлами. Чтобы сэкономить журнальное место, остановимся только на основных настройках snort.conf:

# ee /usr/local/etc/snort/snort.conf

; Указываем диапазон адресов внутренней сети (как вариант, можно использовать имя интерфейса)
var HOME_NET 192.168.1.0/24
; Задаем внешние адреса
var EXTERNAL_NET !$HOME_NET
; Для наиболее полной функциональности Snort рекомендуется определить IP-адреса специфических сервисов. В файле найдешь ряд готовых шаблонов, достаточно проставить нужные адреса
var DNS_SERVERS 192.168.1.1
var SMTP_SERVERS 192.168.1.2
; Теперь указываем порты для определенных сервисов (в данном случае HTTP), чтобы Snort подходил к анализу более избирательно
portvar HTTP_PORTS [80,8000:8080]
portvar SHELLCODE_PORTS !80
; Выполняем журналирование событий посредством Syslog
output alert_syslog: LOG_AUTH LOG_ALERT

Далее в файле описываются правила (rules), которые будет использовать Snort при анализе трафика. По умолчанию каталог с правилами находится в /usr/local/etc/snort/rules, но если оставить запись по умолчанию «var RULE_PATH ./rules», то получим ошибку о невозможности открытия файла local.rules. Поэтому исправляем на «var RULE_PATH rules». Кстати, никто не мешает указать и полный путь к каталогу.

Файлы с описаниями правил подключаются в секции «Step #6: Customize your rule set», расположенной в самом конце snort.conf. Например:

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

Названия правил говорят сами за себя. Файл local.rules предназначен для создания рулесетов пользователем, поэтому изначально он пуст. Оставляй то, что действительно нужно, а остальное отключай, установив знак комментария перед именем.

Самих правил в rules пока нет. Начиная с Snort 2.4.0 (2005 год), они распространяются отдельно. Для их получения требуется регистрация на snort.org, после которой ты получишь специальный OinkCode, предназначенный для загрузки правил. Исключение составляют лишь Community rules. Они лежат в свободном доступе.

Правила можно устанавливать вручную, просто скачав и распаковав в каталог rules, и затем самостоятельно следить за их обновлением. Но такой вариант не очень удобен. Так, если ты внесешь в правило изменения, при следующем обновлении оно будет утеряно. Поэтому лучше использовать Perl-скрипт Oinkmaster (oinkmaster.sf.net), который и будет производить все операции по обновлению. Ставим:

# cd /usr/ports/security/oinkmaster
# make install clean

По умолчанию Oinkmaster ищет свой конфиг oinkmaster.conf сначала в каталоге /etc, а затем в /usr/local/etc. В FreeBSD уже есть готовый шаблон, переименовываем его и правим:

# cp -v /usr/local/etc/oinkmaster.conf.sample /usr/local/etc/oinkmaster.conf

# ee /usr/local/etc/oinkmaster.conf

; Снимаем комментарий со строки и заменяем параметр <oinkcode> своим значением, полученным с сайта snort.org
url = http://www.snort.org/pub-bin/oinkmaster.cgi/<oinkcode>/snortrules-snapshot-CURRENT.tar.gz
; Community rules скачиваются без oinkcode
url = http://www.snort.org/pub-bin/downloads.cgi/Download/comm_rules/Community-Rules-CURRENT.tar.gz
; Перечень файлов, которые требуется обновить
path = /bin:/usr/bin:/usr/local/bin
update_files = \.rules$|\.config$|\.conf$|\.txt$|\.map$
; Список файлов, не подлежащих обновлению
skipfile local.rules
skipfile deleted.rules
skipfile snort.conf
skipfile sid-block.map

Кроме того, Oinkmaster позволяет включать, отключать и изменять как отдельные правила, так и правила, записанные в определенных (или всех) файлах. Каждое правило Snort имеет свой уникальный номер SID (Snort ID), который и использует Oinkmaster. К примеру, чтобы после обновления отключить правило с SID 12345, дописываем в oinkmaster.conf строку: «disablesid 12345». Есть и обратная операция: «enablesid». Для автоматической замены строк в правилах используется директива «modifysid», в качестве одного из параметров принимающая SID или имя файла. Например, заменяем в правиле SID 1111 и для всех exploit.rules действие alert на drop:

modifysid exploit.rules, 1111 "^alert" | "drop"

После того, как все настройки выполнены, запускаем команду на установку правил:

# /usr/local/bin/oinkmaster -o /usr/local/etc/snort/rules/

В дальнейшем эту задачу лучше автоматизировать с помощью cron:

# crontab -e
30 2 * * * /usr/local/bin/oinkmaster -o /usr/local/etc/snort/rules/ -b /usr/local/etc/snort/backup 2>&1

Теперь в 2:30 ночи Oinkmaster самостоятельно будет обновлять правила. Архив достаточно большой по размеру (90 Мб), и, если Snort установлен на нескольких системах, можно скачать его на одном компьютере и скопировать в локальный каталог, с которого и произвести обновление:

# oinkmaster -u file:///tmp/rules.tar.gz -o /usr/local/etc/snort/rules/

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

# snort -vd

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

# snort –vd -i le0

Теперь пробуем запустить ищейку в режиме NIDS:

# snort -c /usr/local/etc/snort/snort.conf
Initializing rule chains...
2163 Snort rules read
2163 detection rules
-*> Snort! <*-
Version 2.8.2.2 (Build 18) FreeBSD

Запустив команду «tail -f /var/log/messages» на другом терминале, наблюдаем за процессом его запуска:

snort[23312]: Initializing daemon mode
kernel: le0: promiscuous mode enabled
snort[23313]: Snort initialization completed successfully (pid=23313)

Если вылезли ошибки, следует с ними разобраться. Например, часто встречается такое сообщение:

snort[23313]: Not Using PCAP_FRAMES

Переменная PCAP_FRAMES определяет размер буфера (в пределах 0 - 32768, значение «max» эквивалентно максимальному 32768), используемого для захваченных фрэймов. Чтобы победить проблему, достаточно выполнить команду:

# setenv PCAP_FRAMES max

И прописываем эту строку в /etc/csh.cshrc. Напомню, что для /bin/bash вместо setenv используется export и /etc/profile:

# export PCAP_FRAMES="max"

Прописываем старт Snort в /etc/rc.conf и запускаем:

# echo 'snort_enable="YES"' >> /etc/rc.conf
# /usr/local/etc/rc.d/snort start

Подключаем запись Snort в MySQL

Теперь, когда Snort нормально работает, нужно настроить вывод собранной информации в базу данных. В качестве СУБД задействуем самую популярную платформу с открытым кодом, на которой современные разработчики строят сетевые сервисы. При сборке Snort с параметром «-DWITH_MYSQL» параллельно будет установлен и клиент MySQL. Смотрим его версию:

# mysql
mysql Ver 14.12 Distrib 5.0.75, for portbld-freebsd7.1 (i386) using 5.2

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

# cd /usr/ports/databases/mysql50-server
# make install clean
# /usr/local/bin/mysql_install_db
# cp /usr/local/share/mysql/my-medium.cnf /etc/my.cnf

Запускаем:

# echo 'mysql_enable="YES"' >> /etc/rc.conf
# /usr/local/etc/rc.d/mysql-server start

Проверяем работу:

# sockstat -l
mysql mysqld 42648 10 tcp4 *:3306 *:*
mysql mysqld 42648 12 stream /tmp/mysql.sock

Устанавливаем пароль админа MySQL:

# /usr/local/bin/mysqladmin -u root password newpassword

Создаем новую базу данных snort и даем пользователю с таким же именем все права:

# mysql -u root -p
mysql> CREATE DATABASE snort;
mysql> GRANT ALL PRIVILEGES ON snort.* TO 'snort'@'localhost' IDENTIFIED BY 'snortpassword';
mysql> FLUSH PRIVILEGES;
mysql> quit;

Наполняем базу при помощи предоставленного разработчиками шаблона:

# mysql -u snort -psnortpassword snort < /usr/local/share/examples/snort/create_mysql

Теперь подключаем вывод Snort к MySQL, добавив в snort.conf строку:

# ee /usr/local/etc/snort/snort.conf

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

Перезапускаем Snort:

# /usr/local/etc/rc.d/snort restart

Теперь, когда Snort производит анализ трафика и записывает результат в базу MySQL, самое время установить систему анализа BASE.

Собираем BASE

За все время развития Snort было создано большое количество программ для анализа собранной информации – от консольных, вроде SnortALog, проверяющих записи Syslog, до графических, представляющих информацию в более удобном для восприятия виде. Одним из таких проектов стал BASE (Basic Analysis and Security Engine, base.secureideas.net), основой которого послужил популярный некогда интерфейс ACID (Analysis Console for Intrusion Databases). Сам ACID уже долго не развивался и в настоящее время исключен из дерева портов.

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

# cd /usr/ports/security/base
# make install clean

По окончании все скрипты будут помещены в каталог /usr/local/www/base. Задаем нужные права:

# chown -R www:www /usr/local/www/base

Теперь открываем браузер, переходим на страницу http://ip-snort/base и начинаем процесс настройки. Вначале скрипт проверит возможность записи в каталог /usr/local/www/base, версию PHP и уровень журналирования PHP. Если по всем пунктам получаем положительный результат, идем к первому шагу, где выбираем язык и указываем путь к adoDB (во фре – /usr/local/share/adodb). Следующий этап – указываем параметры доступа к базе snort (Database type = MySQL, Database name = snort, Database Host = localhost, Database username = snort, Database Password = snortpassword). Далее, если требуется аутентификация, указываем логин и пароль, или, отметив «Use Authentication System», используем системные учетные записи. На последнем шаге, нажав «Create BASE AG», создаем базу. Теперь переходим на http://ip-snort/base и, отбирая критерии, просматриваем информацию, полученную из записей Snort - список обнаруженных атак и их источников, системы, на которые они направлены, топ атак и т.д. Вообще говоря, интерфейс BASE очень прост и локализован, поэтому в его освоении не должно возникнуть проблем.

Устанавливаем SnortSAM

Контроль данных, конечно, полезен и позволяет оценить уровень угроз, но без автоматизации блокировки атак схема будет недостаточно полной и эффективной. Для остановки атак предлагаю использовать SnortSAM (www.snortsam.net), который может заблокировать IP-адрес, перенастраивая правила IP Filter (ipf), ipfw2, Packet Filter (pf), Linux IPtables/EBtables, MS ISA Server firewall/proxy, некоторых роутеров Cisco и т.д. Причем один SnortSAM может управлять настройками сразу нескольких файрволов (мощная фича!). Сам SnortSAM состоит из двух компонентов: патч к Snort (мы его уже установили, использовав '-DWITH_SNORTSAM') и собственно управляющей программы. Устанавливаем:

# cd /usr/ports/security/snortsam
# make install clean

Параметр у SnortSAM только один:

OPTIONS= PFW "Enable IPFW table checking if it set deny rules" on

По умолчанию он включен, и в большинстве случаев нет смысла его изменять. Копируем шаблон конфига:

# cp /usr/local/etc/snortsam/snortsam.conf.sample /usr/local/etc/snortsam/snortsam.conf

Опций внутри snortsam.conf немало. Многие из них обеспечивают подключение и настройку файрволов с внешних машин. Конфигурируем:

# ee /usr/local/etc/snortsam/snortsam.conf

; Пароль для доступа со всех внешних машин должен совпадать с указанным в snort.conf. При помощи другого параметра «accept» можно указывать пароль для каждой системы
defaultkey snortsam_key
; Порт, на котором SnortSAM будет слушать подключения (по умолчанию 898).
port 898
; Внутренние машины нельзя блокировать
dontblock 192.168.1.0/24
; Список корневых DNS-серверов, идет в комплекте
include rootservers.cfg
; Режим демона
daemon
; Файл журнала и уровень протоколирования
logfile snortsam.log
loglevel 3
; Для блокировки используем IP Filter
ipf le0

И в snort.conf добавляем такую строку:

output alert_fwsam: 127.0.0.1/snortsam_key

Где 127.0.0.1 – адрес компьютера, на котором работает SnortSAM, и через дробь – ключ доступа к нему. Помимо этого, в каждое правило Snort, при совпадении с которым необходима блокировка, следует добавить параметр «'fwsam: {кто}, {время};'». Например, чтобы источник блокировался на час, пишем так: «fwsam: src, 1 hour;». Для этих целей как раз и подходит Oinkmaster.

modifysid 12345 "\)$" | "fwsam: src, 10 minutes;)"

Перезапускаем Snort и запускаем SnortSAM:

# /usr/local/etc/rc.d/snort restart
# echo 'snortsam_enable="YES"' >> /etc/rc.conf
# /usr/local/etc/rc.d/snortsam start

Для проверки можно создать в local.rules два правила, где 192.168.1.1 – адрес системы с установленным Snort:

alert tcp any any -> 192.168.1.1 11110 (msg:"TEST log 11110/tcp"; sid:1111110;)
alert tcp any any -> 192.168.1.1 11111 (msg:"TEST block 11111/tcp"; sid:1111111; fwsam:src[in],5min;)

Теперь при подключении телнетом к порту 11110 мы получим предупреждающее сообщение в журнале, а при подключении к порту 11111 чересчур активный узел будет блокирован на 5 минут. В итоге, мы получили полноценную систему защиты, которая будет днем и ночью защищать твои сервера. Эту схему можно развивать, используя несколько сенсоров Snort и агентов SnortSAM. Конечно, потребуется тонкая подгонка правил и настроек под конкретную обстановку, но это приятные хлопоты :).

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

Начнем с того, что IDS/IPS вовсе не одно и то же – хотя их частенько путают, чему весьма способствуют гибридные варианты (они представляют собой IDS, которая реализует некоторое подмножество функционала, формально являющегося прерогативой IPS). «Чистые» IDS в природе практически не встречаются (поскольку атаку необходимо не только распознать, но и блокировать, чем и занимаются IPS).

В некоторых случаях IPS опирается на IDS, например, анализирует сетевой трафик на предмет наличия известных сигнатур, блокируя «нехорошие» TCP-пакеты, а то и вовсе работает на уровне приложений. Однако это не единственный вариант. Ряд атак удается блокировать безо всякой детекции. В частности, «нормализаторы» (от английского normalize) регенерируют трафик, работая по принципу прокси-серверов. Они «выхватывают» из пакетов только те поля, которые понимают, преобразуя их в «канонический» вид. В результате, хакер уже не может послать жертве неожиданный запрос, вызывающий рвотный рефлекс. Естественно, такой подход не защищает от ошибок переполнения, ведь с его точки зрения «взрывпакеты» выглядят вполне легитимно – так что, без детекции не обойтись.

И тут мы приходим к проблеме ложных позитивных срабатываний. IDS обнаруживает атаку там, где она и не ночевала, отклоняя запрос пользователя. Это не есть хорошо! А IPS, установленная на «пароноидальный» уровень, сама по себе является нехилым источником DoS-атак. Пользователи матерятся так, что хвост увядает. Поэтому IPS обычно настраивается на довольно грубый уровень, допускающий блокировку только явных атак. Какое количество атак при этом остается незамеченным – приходится только гадать. В этом смысле IDS намного перспективнее, поскольку даже на самом чувствительном уровне ложные позитивные срабатывания не приносят никакого ущерба, ограничиваясь новой записью в логе. Естественно, когда ложных срабатываний становится ОЧЕНЬ много, админ просто перестает обращать на них внимание, и это проблема не админа, а IDS. Ну, невозможно досконально расследовать каждую тревогу, если они сыплются косяками.

Крис Касперски

WWW

Сайты проектов:



Источник: http://www.xakep.ru/magazine/xa/127/126/1.asp
Категория: Безопасность | Добавил: oleg (22.12.2009) | Автор: _ssh3r1ff-
Просмотров: 1289 | Рейтинг: 0.0/0 |
Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
Форма входа

Beastie

Друзья сайта

Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0
links

Copyright MyCorp © 2024