Настройка нескольких сенсоров Snort с помощью SnortCenter

Павел Закляков

Прежде чем перейти к практическим вопросам использования нескольких сенсоров на базе IDS Snort, рассмотрим теоретические аспекты этой задачи. Для этого оценим трудности, возникающие при различных способах реализации, и создадим модель, по большей части лишённую замеченных недостатков.

«Одна голова хорошо, а две лучше», – подумал змей Горыныч, убегая от Ильи Муромца. Так и в вопросах обнаружения атак: информация лишней не бывает, больше сенсоров – меньше вероятность пропуска атаки. Конечно, эффективность подключения новых сенсоров, начиная с некоторого числа, не даст такого прироста эффективности, как вначале, но это уже другой вопрос.

При использовании нескольких сенсоров наиболее удобным способом ведения логов будет использование одной или нескольких БД. Подробнее об этом можно прочитать в [4]. Задача заставить два сенсора вносить свои записи в одну БД не представляет из себя никакой сложности. Об этом не было рассказано ранее, но можно догадаться, что необходимо в третьей секции конфигурационного файла snort.conf, отвечающей за вывод данных, прописать всего лишь в одной строчке другое имя хоста с БД, номер порта, логин и пароль. Далее, если доступ к БД не закрыт каким-нибудь пакетным фильтром или МЭ по пути, то никаких проблем быть не должно. Даже ACID будет исправно показывать статистику от двух и более сенсоров. Работа такой системы только на первый взгляд кажется прозрачной и беспроблемной. По мере увеличения времени эксплуатации системы неизбежно возникнут различные вопросы. Вот некоторые из них, которые видно невооружённым глазом сразу до начала эксплуатации:

n  Обновления сигнатурной БД, в нашем примере это правила, по которым обнаруживаются атаки.

n  Совместный анализ данных. Данные в БД заносятся из разных мест, а при анализе этот факт никак не учитывается.

n  Доверенность сенсоров и устойчивость самой системы обнаружения атак к атакам на неё.

n  Контроль за сенсорами.

Таким образом, казалось бы, простенькая идея замены одного адреса хоста в файле конфигурации оборачивается большим списком вопросов, не на все из которых можно найти однозначный ответ.

Давайте остановимся и частично рассмотрим проблемы и пути решения первого вопроса.

При отсутствии каких-либо целенаправленных решений поставленный вопрос решается неудобно, но просто. Администратор подключается к компьютеру стандартными средствами администрирования, например, с помощью ssh или telnet. Руками вносит изменения в конфигурационный файл и перезапускает snort. Потом подключается к другому хосту, где установлен другой сенсор и повторяет операцию. Согласитесь, что при большом количестве узлов ситуация не очень удобная. Поэтому администратор, чтобы избавить себя от подобной рутинной работы, один раз автоматизирует процесс – пишет скрипт на bash, который периодически запускается через cron, скачивает c помощью wget новые правила с сайта www.snort.org и устанавливает их в систему. Благо правила всё время находятся в одном и том же месте на сайте, а имя файла с последними правилами остаётся неизменным. Либо http://www.snort.org/dl/rules/snortrules-stable.tar.gz (* см.ниже) – стабильная ветка, либо http://www.snort.org/dl/rules/snortrules-current.tar.gz (* см. ниже) – активно развивающаяся. Во время процесса установки в систему правила разархивируются, распаковываются, возможно, как-то проверяются, помещаются на место старых правил, в конфигурационный файл, возможно, вносятся изменения и происходит перезапуск демона snort, чтобы внесённые изменения вступили в силу.