RFC (Request for Comments, Запрос на комментарии) - серия документов, публикуемая сообществом исследователей и разработчиков, руководствующихся практическими интересами, в которой описывается набор протоколов и обобщается опыт функционирования Интернет.
Доверься ищейке. Прикручиваем к 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 уже есть готовый шаблон,
переименовываем его и правим:
; Снимаем комментарий со строки и заменяем параметр
<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"
После того, как все настройки выполнены, запускаем команду на установку
правил:
Теперь в 2:30 ночи Oinkmaster самостоятельно будет обновлять правила. Архив
достаточно большой по размеру (90 Мб), и, если Snort установлен на нескольких
системах, можно скачать его на одном компьютере и скопировать в локальный
каталог, с которого и произвести обновление:
Когда все готово, запусти Snort. Для работы в режиме снифера главный бинарик
следует стартовать с флагом '–v'. При этом на экран выводятся заголовки
пакетов:
# snort -vd
Если в системе один интерфейс, то программа сама разберется, с чем ей
работать. В противном случае его требуется указать через ключ '–i':
Если вылезли ошибки, следует с ними разобраться. Например, часто встречается
такое сообщение:
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 и запускаем:
Теперь, когда 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
Создаем новую базу данных 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 строку:
Теперь, когда 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
По умолчанию он включен, и в большинстве случаев нет смысла его изменять.
Копируем шаблон конфига:
Опций внутри 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.
Для проверки можно создать в 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. Ну,
невозможно досконально расследовать каждую тревогу, если они сыплются
косяками.