Русская группа пользователей Snort

Дмитрий Рожков

UNIX-администратор ИД «Питер»

Как бы хорошо ни был защищен web-сервер или шлюз в интернет, всегда существует возможность его взлома. И для системного администратора было бы лучше узнавать о попытках взлома еще до того, как взлом произошел. Поэтому особенно важны средства, позволяющие не только обнаружить факт проникновения в систему, но и предупредить о предстоящем вторжении.

Существует два вида систем обнаружения вторжения (IDS, Intrusion Detection Systems): к первым относятся программы, выявляющие аномалии в функционировании системы, например, необычно большое количество одновременно работающих процессов, повышенный трафик, передаваемый интерфейсами системы, и т. п.; ко вторым относят IDS, работа которых заключается в поиске заранее известных признаков атаки. Что же касается великолепной программы Snort, то её можно смело отнести к обоим видам IDS. Благодаря своей открытой архитектуре, Snort легко может быть расширена для решения различных задач.

Эта статья не претендует на всеобъемлющее руководство по Snort, а лишь является моим очень вольным переводом руководства, написанного Martin Roesch (автором программы), вперемешку с моими собственными мыслями.

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

"Системный администратор" №11(12), ноябрь 2003

Описанный в статье [1] способ настройки IDS Snort, при котором логи ведутся в текстовый файл, имеет как положительные моменты, так и отрицательные. Среди положительных моментов можно назвать простоту. С текстовыми файлами человек может работать «напрямую», просматривая их в текстовом редакторе, используя различные возможности их обработки с помощью средств shell и perl. Удобства очевидны: не требуются дополнительные программы и прочие утилиты. Однако если смотреть шире, то по мере увеличения возможностей СОА эти преимущества обращаются в недостатки. Приведём один такой существенный недостаток: при очень больших объёмах логов место на диске при использовании текстовых файлов тратится не оптимально. Многие программы пытаются вести логи в своём, более компактном формате, либо имеют такую опциональную возможность. На первый взгляд это решает проблему размера лог-файлов, заметно их сокращая, но вместе с этим привносится и ряд новых потенциально возможных неудобств. Вот и получается, что двоичные файлы оказываются меньше по размеру, но не могут быть централизованно для всех программ стандартизированы, а текстовые файлы не предоставляют широких возможностей для их быстрого просмотра и более глубокого анализа с целью обнаружения каких-то внутренних зависимостей. Вот и подумаешь исходя из этого: «А зачем изобретать велосипед, не проще ли воспользоваться уже какой-нибудь готовой СУБД для ведения логов в неё?».

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

"Системный администратор" №10(11), октябрь 2003
По данным CERT[1], число инцидентов в сети растёт не по дням, а по часам - если грубо поделить 100 тысяч на 365 дней и на 24 часа, то получится примерно около 11 регистрируемых инцидентов в час. Ситуацию, сложившуюся в последнее время с червём Blaster, следует убрать из рассмотрения как исключение.

Мы видим, что число инцидентов растёт, а в то же время последние номера журнала не изобилуют статьями по вопросам сетевой безопасности, а тем более обнаружению телекоммуникационных атак. На мой взгляд, есть ряд удачных публикаций [2-4]; менее удачных в силу сложности непосредственной применимости [5-8] и неудачных, но все они далеки от обнаружения атак. Даже широко продаваемая литература [9-14] далека от жизни, и за красивыми названиями порой ничего не стоит, кроме полного отставания в вопросах практической реализации. Хотелось бы несколько заполнить этот вакуум полезной информацией, в частности информацией про систему обнаружения атак IDS Snort [15].

Так как теория не стоит на месте и все появляющиеся упоминания скорее неполные, чем неправильные, то хотелось бы закрыть этот вакуум, подведя читателя непосредственно подкованным к вопросу использования IDS Snort.

Замечания, обсуждение и критика вопросов обнаружения телекоммуникационных атак приветствуются.

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

"Системный администратор" №5(18), май 2004

«Лучше один раз увидеть, чем сто раз услышать» гласит пословица. Многие вещи мы лучше понимаем, представляем и запоминаем, если видели их собственными глазами. При этом не всякое нами увиденное воспринимается одинаково хорошо. Очень сильно на процесс восприятия влияет наглядность. В этой статье будет рассмотрен именно такой вариант отображения данных об интенсивности атак, регистрируемых с помощью Snort. В качестве средства отображения используется MRTG.

Предполагается, что имеется СОА Snort, данные с одного или нескольких сенсоров которой заносятся в БД инцидентов. Необходимо организовать визуальное отображение среднего уровня атак в зависимости от времени. Для отображения удобнее всего использовать штатное средство большинства Linux-систем - MRTG (The Multi Router Traffic Grapher) [1,2 стр. 52-53, 3 стр. 316, 4 стр. 208-216]. Предполагается, что MRTG у вас уже установлен. Рассмотрим его настройку. Конфигурационный файл MRTG обычно называется mrtg.cfg и находится в директории /etc/mrtg.

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

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

"Системный администратор" №3(16), март 2004

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

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

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