Доверься ищейке. Прикручиваем к Snort систему блокировки атак SnortSAM и веб-консоль BASE_ssh3r1ff- (ssh3r1ff@gmail.com) Ежесекундно по интернет-каналу корпоративной сети проходят тысячи пакетов. Часть из них нацелена на то, чтобы обойти все заслоны и нарушить работу сетевых сервисов или предоставить их автору базу для рассылки спама. И здесь на помощь администратору приходят системы обнаружения атак, позволяющие вовремя среагировать на угрозу.
Наиболее популярной 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. Первым делом обновляем порты:
Устанавливаем Snort, подключив поддержку MySQL и плагина SnortSAM:
При сборке без параметров просто отмечаем нужные флажки. Как и большинство портов, все файлы конфигурации Snort располагает в каталоге /usr/local/etc и скрипт запуска – в /usr/local/etc/rc.d. Конфигурационный файл snort.conf находится в подкаталоге /usr/local/etc/snort вместе с некоторыми другими файлами. Чтобы сэкономить журнальное место, остановимся только на основных настройках snort.conf:
Далее в файле описываются правила (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. Например:
Названия правил говорят сами за себя. Файл local.rules предназначен для создания рулесетов пользователем, поэтому изначально он пуст. Оставляй то, что действительно нужно, а остальное отключай, установив знак комментария перед именем. Самих правил в rules пока нет. Начиная с Snort 2.4.0 (2005 год), они распространяются отдельно. Для их получения требуется регистрация на snort.org, после которой ты получишь специальный OinkCode, предназначенный для загрузки правил. Исключение составляют лишь Community rules. Они лежат в свободном доступе. Правила можно устанавливать вручную, просто скачав и распаковав в каталог rules, и затем самостоятельно следить за их обновлением. Но такой вариант не очень удобен. Так, если ты внесешь в правило изменения, при следующем обновлении оно будет утеряно. Поэтому лучше использовать Perl-скрипт Oinkmaster (oinkmaster.sf.net), который и будет производить все операции по обновлению. Ставим:
По умолчанию Oinkmaster ищет свой конфиг oinkmaster.conf сначала в каталоге /etc, а затем в /usr/local/etc. В FreeBSD уже есть готовый шаблон, переименовываем его и правим:
Кроме того, Oinkmaster позволяет включать, отключать и изменять как отдельные правила, так и правила, записанные в определенных (или всех) файлах. Каждое правило Snort имеет свой уникальный номер SID (Snort ID), который и использует Oinkmaster. К примеру, чтобы после обновления отключить правило с SID 12345, дописываем в oinkmaster.conf строку: «disablesid 12345». Есть и обратная операция: «enablesid». Для автоматической замены строк в правилах используется директива «modifysid», в качестве одного из параметров принимающая SID или имя файла. Например, заменяем в правиле SID 1111 и для всех exploit.rules действие alert на drop:
После того, как все настройки выполнены, запускаем команду на установку правил:
В дальнейшем эту задачу лучше автоматизировать с помощью cron:
Теперь в 2:30 ночи Oinkmaster самостоятельно будет обновлять правила. Архив достаточно большой по размеру (90 Мб), и, если Snort установлен на нескольких системах, можно скачать его на одном компьютере и скопировать в локальный каталог, с которого и произвести обновление:
Когда все готово, запусти Snort. Для работы в режиме снифера главный бинарик следует стартовать с флагом '–v'. При этом на экран выводятся заголовки пакетов:
Если в системе один интерфейс, то программа сама разберется, с чем ей работать. В противном случае его требуется указать через ключ '–i':
Теперь пробуем запустить ищейку в режиме NIDS:
Запустив команду «tail -f /var/log/messages» на другом терминале, наблюдаем за процессом его запуска:
Если вылезли ошибки, следует с ними разобраться. Например, часто встречается такое сообщение:
Переменная PCAP_FRAMES определяет размер буфера (в пределах 0 - 32768, значение «max» эквивалентно максимальному 32768), используемого для захваченных фрэймов. Чтобы победить проблему, достаточно выполнить команду:
И прописываем эту строку в /etc/csh.cshrc. Напомню, что для /bin/bash вместо setenv используется export и /etc/profile:
Прописываем старт Snort в /etc/rc.conf и запускаем:
Подключаем запись Snort в MySQLТеперь, когда Snort нормально работает, нужно настроить вывод собранной информации в базу данных. В качестве СУБД задействуем самую популярную платформу с открытым кодом, на которой современные разработчики строят сетевые сервисы. При сборке Snort с параметром «-DWITH_MYSQL» параллельно будет установлен и клиент MySQL. Смотрим его версию:
Из вывода следует, что используется версия 5.0, поэтому из нескольких вариантов сервера надо выбрать сервер MySQL с таким же номером. Иначе сборка закончится неудачей.
Запускаем:
Проверяем работу:
Устанавливаем пароль админа MySQL:
Создаем новую базу данных snort и даем пользователю с таким же именем все права:
Наполняем базу при помощи предоставленного разработчиками шаблона:
Теперь подключаем вывод Snort к MySQL, добавив в snort.conf строку:
Перезапускаем Snort:
Теперь, когда 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. Все это нужно будет отметить по ходу установки:
По окончании все скрипты будут помещены в каталог /usr/local/www/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') и собственно управляющей программы. Устанавливаем:
Параметр у SnortSAM только один:
По умолчанию он включен, и в большинстве случаев нет смысла его изменять. Копируем шаблон конфига:
Опций внутри snortsam.conf немало. Многие из них обеспечивают подключение и настройку файрволов с внешних машин. Конфигурируем:
И в snort.conf добавляем такую строку:
Где 127.0.0.1 – адрес компьютера, на котором работает SnortSAM, и через дробь – ключ доступа к нему. Помимо этого, в каждое правило Snort, при совпадении с которым необходима блокировка, следует добавить параметр «'fwsam: {кто}, {время};'». Например, чтобы источник блокировался на час, пишем так: «fwsam: src, 1 hour;». Для этих целей как раз и подходит Oinkmaster.
Перезапускаем Snort и запускаем SnortSAM:
Для проверки можно создать в local.rules два правила, где 192.168.1.1 – адрес системы с установленным Snort:
Теперь при подключении телнетом к порту 11110 мы получим предупреждающее сообщение в журнале, а при подключении к порту 11111 чересчур активный узел будет блокирован на 5 минут. В итоге, мы получили полноценную систему защиты, которая будет днем и ночью защищать твои сервера. Эту схему можно развивать, используя несколько сенсоров Snort и агентов SnortSAM. Конечно, потребуется тонкая подгонка правил и настроек под конкретную обстановку, но это приятные хлопоты :). Воздвигнуть IDS/IPS на бюджетном железе, используя только свободно доступные компоненты, вполне возможно. И работать такая защита будет ничуть не хуже, чем программные комплексы, за которые невменяемые разработчики просят десятки тысяч долларов и которые работают под вредоносными операционными системами, требующими кучу памяти и отжирающими уйму процессорных тактов. Начнем с того, что IDS/IPS вовсе не одно и то же – хотя их частенько путают, чему весьма способствуют гибридные варианты (они представляют собой IDS, которая реализует некоторое подмножество функционала, формально являющегося прерогативой IPS). «Чистые» IDS в природе практически не встречаются (поскольку атаку необходимо не только распознать, но и блокировать, чем и занимаются IPS). В некоторых случаях IPS опирается на IDS, например, анализирует сетевой трафик на предмет наличия известных сигнатур, блокируя «нехорошие» TCP-пакеты, а то и вовсе работает на уровне приложений. Однако это не единственный вариант. Ряд атак удается блокировать безо всякой детекции. В частности, «нормализаторы» (от английского normalize) регенерируют трафик, работая по принципу прокси-серверов. Они «выхватывают» из пакетов только те поля, которые понимают, преобразуя их в «канонический» вид. В результате, хакер уже не может послать жертве неожиданный запрос, вызывающий рвотный рефлекс. Естественно, такой подход не защищает от ошибок переполнения, ведь с его точки зрения «взрывпакеты» выглядят вполне легитимно – так что, без детекции не обойтись. И тут мы приходим к проблеме ложных позитивных срабатываний. IDS обнаруживает атаку там, где она и не ночевала, отклоняя запрос пользователя. Это не есть хорошо! А IPS, установленная на «пароноидальный» уровень, сама по себе является нехилым источником DoS-атак. Пользователи матерятся так, что хвост увядает. Поэтому IPS обычно настраивается на довольно грубый уровень, допускающий блокировку только явных атак. Какое количество атак при этом остается незамеченным – приходится только гадать. В этом смысле IDS намного перспективнее, поскольку даже на самом чувствительном уровне ложные позитивные срабатывания не приносят никакого ущерба, ограничиваясь новой записью в логе. Естественно, когда ложных срабатываний становится ОЧЕНЬ много, админ просто перестает обращать на них внимание, и это проблема не админа, а IDS. Ну, невозможно досконально расследовать каждую тревогу, если они сыплются косяками. Крис Касперски VIDEOНа диске ты найдешь видеоролик, в котором показано, как установить систему обнаружения атак Snort на FreeBSD 7, перенаправить вывод данных в базу MySQL и добавить веб-интерфейс BASE. WWWСайты проектов:
|