Прелюдия для защиты

СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

Прелюдия для защиты

В предыдущем номере журнала в статье «Централизованное обнаружение вторжения с Samhain» была затронута возможность компилирования датчиков host-based intrusion detection system Samhain как датчиков другой IDS – Prelude. Как мне кажется, в последней сочетается довольно много положительных качеств, чтобы обратить на эту IDS пристальное внимание.

Проект начат в 1998 году (одновременно с началом разработки Snort), основной его целью было создание модульного сетевого IDS, но очень скоро разработчики поняли, что за технологиями все равно не угнаться, и пересмотрели свои подходы и требования к обеспечению безопасности систем. В результате Prelude представляет собой полнофункциональную, т.н. гибридную, IDS. Она разрабатывалась прежде всего для работы на компьютерах под управлением GNU/Linux, но поддерживаются также и *BSD-системы, как и другие POSIX-совместимые системы, распространяется свободно по лицензии GPL. Суть гибридности Prelude заключается в том, что контролируются не только события, происходящие в сети, но и то, что творится на локальных компьютерах, что, с одной стороны, повышает вероятность обнаружения попытки вторжения, а с другой – уменьшает общее количество разнородных приложений, с которыми придется иметь дело системному администратору. Домашняя страница проекта: http://www.prelude-ids.org.

Состоит Prelude из нескольких частей:

• Сенсоры – основная часть всей системы обнаружения, развертываются на нескольких системах, чья безопасность контролируется. Они собирают всю информацию и сообщают администратору в случае обнаружения аномалий.
• LibPrelude – клей, связывающий все части вместе, предоставляет единый интерфейс стандартных вызовов IDMEF, основанный на XML, позволяет легко создавать сторонним разработчикам продукты «Prelude Aware». Используется всеми модулями Prelude.
• Prelude-nids – датчик сетевой системы обнаружения атак, который ищет знакомые сигнатуры в проходящих по сети пакетах. В одной сети достаточно иметь один такой сенсор, поэтому его можно установить, например, на сервер. По своей функциональности эквивалентен Snort.
• Prelude-lml – Prelude Log Monitoring Lackey – еще один датчик, на этот раз контролирующий логи. В случае появления подозрительных записей отправляет уведомление, является обязательным при использовании host-based IDS-части. Может быть сконфигурирован как для просмотра локальных лог-файлов, так и работать в сетевом режиме, контролируя поступающие по сети данные. В последнем случае он может работать со всеми syslog-совместимыми данными, поступающими от firewall, маршрутизаторов, принтеров, других UNIX-систем и систем, которые могут преобразовать свои данные к требуемому формату (например, Windows NT/2K/XP – Ntsyslog – http://ntsyslog.sourceforge.net). Построенный на PCRE (Perl Compatible Regular Expressions), состоит из плагинов, каждый из которых отвечает за анализ данных, поступающих от определенной программы, или утилиты: IpFw, IpChains, NtSyslog, GRSecurity, Exim, Portsentry, SSH, Squid и других.
• Libsafe – датчик, работающий только на Linux-системах, автоматически подхватывается Prelude при установленной в системе библиотеке libsafe (http://www.research. avayalabs.com/project/libsafe). Эта библиотека позволяет защититься от атак типа format string и buffer overflow, проверяя запросы к потенциально опасным вызовам вроде sprintf, strcpy, wcscpy и пытается обнаружить попытку переполнения буфера; если таковое обнаруживается, то выполнение опасной программы прерывается. Учитывая, что библиотека, в общем, справляется со своим назначением, а системные расходы незначительны, то ее можно рекомендовать к применению.
• Prelude-manager – предназначен для централизованного сбора данных, поступающих от всех датчиков, выдачи данных подсистеме, реагирующей на событие, и сохранение данных ( MySQL, PostgreSQL, Oracle, XML, plain-текст). В сети может быть несколько manager.
• Counter Measure Agents – исполнительня часть, получает данные относительно выявленной аномалии от manager и принимает меры по остановке нежелательных действий.
• frontends – для централизованного удобного просмотра собранных данных, выявления неисправностей, позволяет просто администрировать и способствует пониманию текущего состояния дел защиты. В этом качестве выступают P(erl|relude) IDS Web Interface и Prelude-php-frontend. Внешний интерфейс, написанный на Perl и РНР соответственно, предназначен для просмотра данных, собранных Prelude и занесенных в базу данных.

Но это еще не все. Кроме упомянутых возможностей в качестве сенсоров после наложения соответствующих патчей могут выступать Snort, Nessus, Nagios, Argus, Honeyd, SysTrace, Bro IDS, Hogwash и планируется AIDE. Также напомню, что датчики Samhain, которые позволяют контролировать довольно большое количество аномалий на хостах, могут быть скомпилированы с библиотекой LibPrelude, выступая тем самым и сенсором Prelude IDS. Все остальные возможности (в том числе и планируемые) Prelude IDS в виде удобных для восприятия таблиц представлены в документе «Prelude Feature Matrix» (http://www.prelude-ids.org/rubrique.php3?id_rubrique=24). Мы же пойдем далее.

Установка Prelude IDS

Все основные компоненты для установки можно найти на странице http://www.prelude-ids.org/rubrique.php3?id_rub-rique=6 в разделе Download Latest Version или Download Latest Snapshots. Как минимум потребуются пакеты libprelude, prelude-manager, prelude-nids, prelude-lml и Piwi. Дополнительно можно здесь же по ссылкам скачать и Libsafe, для работы с OpenBSD pf понадобится prelude-pflogger, а также патчи к соответствующим программам для реализации «Prelude aware»:

• Snort  – Prelude reporting patch;
• Honeyd – Prelude reporting patch;
• Systrace – Prelude reporting patch;
• Nessus – Prelude reporting patch.

Но это то, что сразу в глаза бросается; если посмотреть на столбик слева, то там найдете еще интересную колонку «Contributed Software», в которой найдете еще несколько патчей и расширений к Prelude (отправка алертов по e-mail, сбор статистики, патчи к Nessus, Nagios, Honeyd, Bro IDS, convert_ruleset – скрипт, конвертирующий правила Snort (http://www.snort.org/downloads/snortrules.tar.gz), в правила, понятные Prelude NIDS, и другие полезности).

Проверить скачанные пакеты можно, взяв ключ с:

#gpg --keyserver wwwkeys.pgp.net --recv-keys 0x23D2FAC3

Если все нормально, то можно начинать. По ссылкам можно скачать и прекомпилированные rpm-пакеты, собранные под RedHat 7.3 – 9.0, в которых найдете даже nessus, заточенный под Prelude. Установка их заключается в основном в стандартном rpm -i *.rpm, но в дальнейшем у меня возни с ними было больше, поэтому будем затачивать все под свою систему, самостоятельно собирая из исходников (тем более это не так уж и трудно). Для поклонников Gentoo необходимые для сборки ebuild-файлы найдете в архиве piwi.

Для начала скачиваем и ставим libsafe, которая, начиная с версии 2.11, может быть скомпилирована как датчик Prelude. Здесь все просто.

#make

После окончания компиляции вводим:

#make install

Теперь связываем переменную LD_PRELOAD с библиотекой:

LD_PRELOAD=/lib/libsafe.so.2

export LD_PRELOAD

И заносим эти строки в файл /etc/profile.

В файле /etc/ld.so.preload также желательна такая строка:

/lib/libsafe.so.2

Теперь устанавливаем libprelude:

#tar xvzf libprelude-0-8-latest.tar.gz

#cd libprelude

#./configure

Библиотека автоматически компилируется с поддержкой OpenSSL и требует наличия библиотек и заголовочных файлов. Из дополнительных опций стоит отметить enable-gtk-doc для формирования документации.

#make

#make install

После чего аналогично устанавливаем prelude-manager. После конфигурирования возможно появление такой ошибки.

Совет установить переменную LIBPRELUDE_CONFIG не помог. Необходимо, чтобы место расположения файла libprelude-config было видно из переменной PATH.

#PATH=$PATH:/usr/local/bin/

#export PATH

В конце отчет.

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

И переходим к построению датчиков. Датчики могут быть установлены как на той же машине, что и prelude-manager, так и разбросаны по всем машинам в сети. При этом во избежание дублирования в одной сети необходимо установить один датчик prelude-nids, а во избежание засорения лишними пакетами лучше его приткнуть на тот же компьютер, что и prelude-manager. Хотя, по большому счету, поступайте как вам удобнее, только помните, что сетевые датчики должны контролировать не только пакеты, поступающие из внешней сети, но и, чтобы пресечь действия некоторых «умников», стоять и во всех внутренних сетях.

Действия и проблемы при установке prelude-nids и prelude-lml аналогичны предыдущим.

После установки приступаем к конфигурированию. Все конфигурационные файлы после установки помещаются каждый в свой подкаталог в /usr/local/etc.

Но для начала создадим базу данных:

#/usr/local/bin/prelude-manager-db-create.sh

Команда задаст семь вопросов о паролях, пользователях и других параметрах, необходимых при создании новой базы данных, после чего выдает общий результат и после получения согласия попробует соединиться с выбранной СУБД и создает новую базу данных.

Если все прошло удачно, можно запускать менеджер:

#prelude-manager --mysql --dbhost localhost --dbname prelude --dbuser prelude --dbpass xxxxxx

Или лучше изменить секцию MySQL в конфигурационном файле /usr/local/etc/prelude-manager/prelude-manager.conf, воспользовавшись выводом утилиты:

[MySQL]

# Host the database is listening on.

dbhost = localhost;

# Port the database is listening on.

dbport = 3306;

# Name of the database.

dbname = prelude;

# Username to be used to connect the database.

dbuser = prelude;

# Password used to connect the database.

dbpass = xxxxxx;

Не забудьте только вставить пароль вместо хххххх.

Для того чтобы указать на интерфейс, где менеджер будет ожидать подключения сенсоров в файле prelude-manager.conf, изменяем параметр sensors-srvr, в котором указываем нужный IP-адрес. Теперь можно приступать к регистрации сенсоров. Этот процесс в Prelude хоть и может забрать изрядное количество времени при большом их количестве, но все таки удобен и понятен и не требует особых и лишних телодвижений. Да, и не забудьте разрешить iptables пропускать эти пакеты.

Для регистрации сенсора на сервере запускаем утилиту manager-adduser, которая будет ждать подключения нового клиента, для допуска которого будет выдан на консоль одноразовый пароль. А на клиентском компьютере параллельно запускается sensor-adduser с указанием названия регистрируемого сенсора и узла, где находится менеджер.

# manager-adduser

Примечание: все, что программа вывела выше, появится только при первом запуске и требуется для генерации ключей. Как видите, можете указать требуемую длину ключа и время устаревания ключа (0 – без устаревания).

Ниже – сообщения, относящиеся непосредственно к регистрации сенсора.

Вот и наш пароль.

Все, программа ждет подключения сенсора. Порядок регистрации сенсоров значения не имеет, начнем, наверное, с libsafe.

На компьютере, сенсор которого вы регистрируете, вводим такую команду:

# sensor-adduser -s <тип_сенсора> -m -u

В случае с локальным сенсором эта строка будет выглядеть так:

# sensor-adduser -s libsafe -m 127.0.0.1 -u 0

Если manager-adduser уже запущен, то смело жмем на и два раза вводим выданные им одноразовые пароли.

В окне manager-adduser увидим для локального сенсора такое сообщение.

После чего он заканчивает свою работу.

Единcтвенное, что может сбить с толку, – это запрашиваемое имя пользователя. В документации сказано, что это имя предназначено для внутреннего употребления и не должно совпадать с учетной записью в определенной системе. Других ограничений я не нашел. На этом регистрация сенсора и заканчивается. Это все действия, которые вам нужно будет проделать, для того чтобы libsafe сообщал Prelude IDS о проблемах. Все конфигурации сенсоров сохраняются в /usr/local/etc/prelude-sensors/. Для удаленного сенсора меняем только IP-адрес. Например, сенсор host-based IDS Samhain, об установке которого я писал в предыдущем номере журнала и имеющий довольно продвинутые возможности по детектированию локальных аномалий.

#sensor-adduser --sensorname samhain --uid 0 --manager-addr 192.168.1.20

Обратите внимание: здесь не требуется вручную заводить пользователя и давать пароль, система генерирует ключ.

А в окне manager-adduser увидим такое сообщение.

Для остальных сенсоров действия аналогичны:

Запускаем опять на сервере manager-adduser и получаем новый одноразовый пароль.

При помощи sensor-adduser регистрируем новый сенсор. Для остальных входящих в комплект сенсоров строка запуска будет иметь такой вид (для локальных сенсоров).

# sensor-adduser -s prelude-nids -m 127.0.0.1 -u 0

Если локальные сенсоры (т.е. по IP – 127.0.0.1) можно удаленно регистрировать, зайдя на компьютер при помощи SSH, то регистрация удаленных сенсоров таким образом сильно затягивается, да и с безопасностью могут возникнуть проблемы.

Теперь можно запускать, а заодно и проверить подключения. На сервере запускаем.

# prelude-manager

Теперь очередь сенсоров. Libsafe подхватывается автоматически, а поэтому после регистрации можно о нем забыть. Остались два prelude-lml и prelude-nids. Указать параметры их запуска можно двумя способами: в строке запуска и в конфигурационных файлах (usr/local/etc/prelude-lml/prelude-lml.conf и /usr/local/etc/prelude-nids/prelude-nids.conf). Синтаксис их понятен и хорошо комментирован, для начала достаточно в обеих указать в строке manager-addr IP-адрес менеджера. При этом возможна запись такого вида:

manager-addr = x.x.x.x:port || y.y.y.y && z.z.z.z

При этом сенсор попытается соединиться сначала с менеджером x.x.x.x:port, если это не получится, то с y.y.y.y и z.z.z.z, а если и эта попытка не увенчается успехом, то данные будут сохранены локально. Для lml-сенсора вce правила находятся /usr/local/etc/prelude-lml/ruleset/, узнать, какие из них задействованы, можно в файле simple.rules в строках include. Для ускорения работы можно закомментировать лишние, а новые, скачанные по ссылкам, здесь же подключить (например, от Exaprobe http://www.exaprobe.com/labs/downloads), второй вариант создать свой файл с правилами и прописать его в prelude-lml.conf в блоке [SimpleMod] в строке ruleset, указав на новый файл с правилами. Аналогично все правила для nids-сенсора прописаны в /usr/local/etc/prelude-nids/ruleset/simple.rules. Запускаем сенсоры.

# prelude-nids -i eth0

Ага, забыли завести пользователя prelude. Можно по первой, при тестировании запустить от имени root (опция -u root), но в остальных случаях делаем как положено. Поэтому командой заводим пользователя prelude и при регистрации сенсоров не забываем указывать его uid.

#groupadd prelude

#adduser --no-create-home --disabled-password --quiet --ingroup prelude prelude

Пробуем еще раз.

# prelude-nids -i eth0

В это время в окне терминала, в котором запущен prelude-manager, должно появиться такое сообщение.

Обратите внимание на последние цифры: они соответствуют выданным программой при регистрации этого сенсора.

С lml поступаем аналогично.

# prelude-lml -u root

После тестирования запускаем все приложения в качестве демонов.

# prelude-manager –d

# prelude-lml –d

И так далее. Для автоматического запуска при старте системы создайте отдельный файл (например, rc.prelude) и пропишите строки для его запуска в /etc/rc.d/rc.local или /etc/rc.d/boot.local для SUSE. Теперь для тестирования можно посканировать сеть при помощи nmap или воспользоваться утилитами IDSwakeup (http://www.hsc.fr/res-sources/outils/idswakeup/download) или nidsbench (http://www.anzen.com/research/nidsbench), специально предназначенными для испытания NIDS.

Теперь смотрим, что творится в лог-файлах. Кроме записи в базу данных текстовые логи ведутся в файле /var/log/prelude.log и в формате XML в /var/log/prelude-xml.log. Там находим следующее.

Это забилось сердце сенсора NIDS. А ниже то, что он выловил в результате нашего испытания. При этом система пытается собрать максимальную информацию об объекте возмущения, в том числе и пытается определить удаленную операционную систему.

Для немедленных уведомлений по почте используйте Perl-скрипт alert2mail (http://www.prelude-ids.org/download/contribs/alert2mail). Использовать его просто, но потребуется модуль MIME::Lite.

Первой строкой добавляем:

#! /usr/bin/perl

в строке From =>’root at localhost’ ставим необходимый e-mail, и при желании можно русифицировать сообщения.

Теперь запускаем, скрипт будет считывать новые данные, поступающие в лог-файл (tail -f /var/log/prelude.log), и анализировать их, при появлении опасных строк администратору будет выслан e-mail.

Другой скрипт http://www.prelude-ids.org/download/contribs/prelude-stats-pl.txt позволяет собирать статистику на основании данных, найденных в /var/log/prelude.log. Чтобы не перегружать слишком сеть сообщения от одиночных сенсоров или удаленных групп сенсоров, возможно использование т.н. Relay Manager, которые собирают информацию от своей группы, а затем переправляют по цепочке центральному менеджеру.

В файле prelude-manager.conf за их активацию отвечают два параметра, в которых требуется указать соответствующий IP-адрес(a): admin-srvr и relay-manager (в данном случае это следующий в цепочке Relay Manager, которому переправлять информацию).

Ставим интерфейс

Все это хорошо, но при большом количестве данных лучше анализировать их при помощи выборок из базы данных. Хотя, кстати, имеется документ, рассказывающий, как сделать просмотр без фронтенда при помощи Internet Explorer: http://orbital.wiretapped.net/~technion.

Совсем недавно на сайте появился GUI-инструмент Prelude GTK2 Frontend, который не хочет компилироваться нормально. В документации имеется упоминание на PHP, ncurses и java-фронтендах, но ссылок на сайте не нашел. Поэтому основным и довольно удобным средством просмотра и анализа результатов выступает Piwi – P(erl|relude) IDS Web Interface, позволяющий просматривать листинги предупреждений, в том числе и детально их сортировать, выводить информацию о IP- и MAC-адресах, операционной системе, проводить статистику атак по дням, часам, top 10 атак и атакующих и прочее, плюс возможность самостоятельного поиска при помощи регулярных выражений. Установка piwi сложностей не представляет.

http://perl.httpd.org) и Apache::DBI (http://search.cpan.org/author/ABH).

Также рекомендуется Prelude компилировать с недавно появившейся библиотекой LibPreludeDB (http://www.prelude-ids.org/download/snapshots/trunk/libpreludedb-trunk-latest.tar.gz), но это необязательно, да и ее компиляция вызывает пока только муки.

Теперь, если все необходимое скачано и установлено, просто распаковываем архив в корневой каталог веб-сервера.

Например для Slackware (в SUSE все серверные каталоги найдете в /srv).

# cd /var/www/htdocs/

# tar -xzvf /path/to/piwi-0-8-latest.tar.gz

Теперь пользователя, от имени которого работает Apache, делаем хозяином подпапки generated.

#chown -R nobody.nobody generated/

Здесь обратите внимание, что в разных дистрибутивах Apache выполняется от пользователей с разными именами.

Так в том же SUSE строка будет выглядеть так.

#chown -R  wwwrun.nogroup generated/

А Mandrake, ALTLinux и Gentoo это будет другая строка.

#chown -R  apache.apache generated/

В общем, при наличии проблем с доступом проверьте все еще раз. Далее в подкаталоге Functions в файле config.pl исправьте параметры доступа к базе данных (в самом верху файла), вставьте туда значения, введенные при работе скрипта prelude-manager-db-create.sh.

Примерно так.

 # Database :

    # здесь выбираем используемую базу данных mysql или Pg

    $conf{"dbtype"} = "mysql";

    # имя раннее созданной базы данных

    $conf{"dbname"} = "prelude";

    # узел, где искать базу данных

    $conf{"dbhost"} = "localhost";

    # это для mysql, для PostgreSQL используйте 5432

    $conf{"dbport"} = 3306;

    # (только для mysql)

    $conf{"dboptions"} = "mysql_compression=1";

    $conf{"dblogin"} = "prelude";

    $conf{"dbpasswd"} = "хххххх";

Теперь даем указание Apache на местонахождение исполняемого файла. Например:

<Directory "/var/www/htdocs/piwi/">

    Options +ExecCGI

    AddHandler cgi-script .pl

</Directory>

Это в общем случае, но если не поленились установить Perl-модуль Apache::DBI и mod_perl для Apache, то пишем так.

PerlModule Apache::DBI

    <Files *.pl>

SetHandler perl-script

PerlHandler Apache::PerlRun

PerlSendHeader On

    </Files>

И добавляем к директиве DirectoryIndex через пробел файл index.pl.

DirectoryIndex index.html index.htm index.pl

Все, теперь перезапускаем Apache.

# /etc/rc.d/apache2 restart

И пытаемся попасть на требуемую страницу. Если что-то не выходит, проблемы как всегда найдете в /var/log/apache2/error_log. Например, такая запись свидетельствует о том, что скрипт не может присоединиться к MySQL.

Поэтому проверяем, не забыли ли вообще запустить MySQL (# ps aux | grep mysql). И проверяем еще раз все записи, сделанные в конфигурационных файлах.

Для тестирования установок предназначена страница $piwi_directory/test/index.pl, сюда же попадете и в том случае, если не будут найдены обязательные компоненты, здесь получите всю информацию о текущих проблемах. Для ограничения доступа (необходимую информацию найдете в piwi/Docs/user_file_format.txt) к данным используются файлы, находящиеся в поддиректории Profiles/ с названием вида: имя_пользователя.user, т.е. на каждого пользователя один файл. По умолчанию там находятся два таких файла: admin.user и guest.user, чего достаточно в большинстве случаев. Параметров немного, сейчас достаточно изменить лишь один – IPAccess, который отвечает за допуск этого пользователя с определенного адреса или адресов.

В качестве значения может быть точный адрес вида 192.168.1.200 или групповой для доступа из всей сети, например 192.168.255.255 (строка IPAccess=255.255.255.255 означает доступ с любого адреса). И не будет лишним, если будете использовать файлы .htaccess, .htpasswd или .htdigest и работать по защищенному каналу SSL, но на этом я останавливаться не буду. По адресу http://www.giggled.org.uk/piwi_custom.html найдете документ, в котором описано, как расширить возможности piwi по сортировке IP-адресов.

Расширеное использование Prelude

Хотел было уже заканчивать статью, но, перечитав все сначала, понял, что некоторые вопросы остались за кадром и требуют, чтобы за них замолвили хотя бы пару слов. А сериалов с вечным продолжением я не люблю, поэтому уж потерпите.

Итак, как видите, Prelude довольно продвинутая IDS, к тому же обладающая возможностью наращивания как количественного, так и качественного, некоторые готовые решения уже имеются на сайте, а тем, кто может, позволено заточить любой необходимый сенсор, для того чтобы Prelude узнавала в нем своего. Сенсоров на отдельный хост можно понаставлять сколько душа пожелает, только вот вопрос – не потребуется ли для его нормальной работы второй процессор, а сеть переводить на гигабит. Поэтому увлекаться, наверное, не стоит, затраты по защите возрастут в несколько раз, а эффективность – на десятую процента. Наверное, стоит из всего предлагаемого комплекта выбрать то, что действительно необходимо для нормальной работы.

Итак, для host-based-части, кроме штатного prelude-lml, умеющего работать только с логами и понимающего логи и других устройств, в том числе windows-систем, можно использовать сенсор samhain, в который вместить все, чего душа пожелает, и для очистки совести можно на критические системы вроде сервера или firewall установить на выбор libsafe или для более полного контроля над системнымы вызовами systrace (http://www.citi.umich.edu/u/provos/systrace), патч для Prelude найдете: http://www.rstack.org/oudot/prelude/systrace/files. Сразу оба использовать в большинстве случаев, я думаю, будет излишним.

Если вы поддались статьям Павла Заклякова и настроили Snort, то ничего страшного, наложив патч http://www.prelude-ids.org/download/releases/snort-prelude-reporting-patch-latest.tar.gz и пересобрав его, можно затем использовать его как сенсор NIDS и отказаться совсем от установки prelude-nids (зачем два аналогичных по функциональности сенсора). Если же со Snort еще не сложилось, то, наверное, самым удобным вариантом будет конвертация правил Snort в правила Prеlude NIDS, подключение их к системе и можно использовать таким образом все наработки обеих команд.

Патч к honeypot-системе honeyd (http://www.citi.umich.edu/u/provos/honeyd, и патч http://www.rstack.org/oudot/prelude/honeypots/files) позволяет собирать и в удобной форме анализировать информацию о действиях нападающей стороны, а сама honeypot-система при правильной и осторожной организации является неплохой приманкой для потенциальных взломщиков и к тому же практически не генерирует ошибки, поэтому в некоторых случаях является весьма полезной добавкой.

И еще один интересный сенсор raprelude (http://www.intrusion-lab.net/tools/raprelude), позволяющий фиксировать все виды сетевых событий, зарегистрированных демоном argus (http://qosient.com/argus). При помощи его можно отобрать весь трафик, идущий к определенному сервису на определенном компьютере или, например, нарушающий правила firewall.

Для обнаружения аномалий в Wi-Fi 802.11 сетях предназначен появившийся совсем недавно сенсор WlanDetect (http://www.security-labs.org/wlandetect), определяющий на момент написания статьи 10 возможных нарушений.

Патч к Nagios (http://www.nagios.org, сам патч http://www.exaprobe.com/labs/downloads/Nagios_Plugin/prelude-nagios-0.0.2.tar.gz) позволяет централизованно контролировать состояние сетей и компьютеров.

И последняя связка, без которой статья бы не была полной. Речь идет о сканере безопасности Nessus (http://www.nessus.org), который также может работать в связке с Prelude после наложения патча http://www.prelude-ids.org/download/releases/nessus-2.0.7-reporting-patch-v7.diff, плюс дополнительно используя инструменты http://www.rstack.org/oudot/prelude/correlation, позволяет уменьшить количество предупреждений и в итоге сконцентироваться на действительно серьезных проблемах, помогут выявить соответствия между предупреждениями и, наконец, позволяют связать предупреждения и системные уязвимости и помочь в реальной оценке серьезности угрозы.

Как видите, гибридная Prelude IDS обладает большой функциональностью, а гибкость при выборе различного вида сенсоров позволяет создать требуемую конфигурацию защитной системы. Но на этом проект не остановил свое развитие, и у разработчиков большие планы по интеграции, анализу и корреляции данных. Также планируется большая поддержка различных приложений, и не в последнюю очередь в списке стоят различные виды firewall (в том числе и аппаратные модели), позволяющие вовремя среагировать и остановить атаку. Несмотря на то что я пытался многое расказать в статье, думаю, что постепенно все же придется еще вернуться к Prelude, чтобы рассказать о нововведениях. Удачи.

Комментарии могут оставлять только зарегистрированные пользователи