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

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

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

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

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

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

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

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

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