Домашняя страница проекта STAT в Интернете находится по адресу http://www.cs.ucsb.edu/~kemm/netstat.html/projects.html, здесь найдете документацию и собственно сам софт. Страница для закачки разбита по приложениям, причем если вы хотите установить только LinSTAT (http://www.cs.ucsb.edu/~kemm/netstat.html/software/linstat.html), то на этой странице найдете все необходимые компоненты для удовлетворения зависимостей. Доступны как прекомпилированые rpm-пакеты (для RedHat 7.3), так и исходные тексты. Надо сказать, что в rpm-пакетах можно найти только базовые приложения, да и то, например модули ядра, будут работать только с тем ядром для которого они компилированы, при использовании в другой системе получите примерно такое сообщение.
Starting linuxstat services: insmod: error inserting
‘/usr/local/stat/sensors/linuxstat_sensor_1.0/auditmodule.o’: -1 Invalid module format
Поэтому наиболее общим вариантом будет установка из исходников. Как сказано в
документации, для установки достаточно ввести стандартные ./configure, make, make install и
все. Но при установке MetaSTAT (с остальными приложениями проблем практически не
было) на RedHat 7.3 и 9, SuSE 9.1, Linux XP, Slackware 9.1, проблемы возникали в каждом
случае (в RedHat 7.3 и Slackware меньше) поэтому, скорее всего, придется немного
повозится в каждом конкретном случае. Например, такая ошибка преследовала во всех
системах.
checking for libxml/parser.h… no
The STAT Core needs libxml2 headers installed before it can be compiled (note that a link called
«libxml» and pointing to «libxml2/libxml» is needed)
Но libxml установлен, ищем где.
# find /usr /opt -name parser.h
/usr/include/libxml2/libxml/parser.h
Исправить ситуацию можно так.
# ln -s /usr/include/libxml2/libxml /usr/include/libxml
После этого.
checking for pthread.h… yes
checking libxml/parser.h usability… yes
checking libxml/parser.h presence… yes
checking for libxml/parser.h… yes
Проблема с glib в SuSE решилась так.
MetaSTAT needs glib installed before it can be compiled
configure: error: /bin/sh ‘./configure’ failed for MetaSTAT
# ln -s /usr/lib/libglib-1.2.so.0.0.10 /usr/lib/libglib-1.2.so
А еще.
# ln -s /opt/gnome/lib/libgnome.so.32.4.3 /opt/gnome/lib/libgnome.so.0
# ln -s /usr/lib/libcrypto.so.0.9.7 /usr/lib/libcrypto.so.2
# ln -s /usr/lib/libssl.so.0.9.7 /usr/lib/libssl.so.2
Смысл, думаю ясен. Хотя от MetaSTAT можно по началу отказаться вообще и установить
позднее, все компоненты можно использовать отдельно без централизованного управления.
А так скачиваем необходимые сенсоры и распаковываем командой tar xzvf название_пакета.
После чего в текущем каталоге образуется подкаталог STAT-1.0. При задании команды
./configure без дополнительных параметров будут найдены все распакованные сенсоры, они
находятся в STAT-1.0/Sensors/ и можно установить любой, из них просто зайдя в нужный
каталог и дав необходимые команды. Либо можно отменить автодетектирование добавив
опцию —disable-autodetect и затем указать на нужные сенсоры (например, –enable-netstat, —
enable-linstat) и нелишней будет опция –enable-java для компиляции Java компонентов. После
компиляции и установки появится каталог /usr/local/stat/ в котором собраны все библиотеки
сценариев и основные настройки сенсоров. Большинство файлов не требует вмешательства.
Для более точной подстройки некоторых датчиков загляните в подкаталог providers, где в
подкаталогах соответствующих датчиков найдете файл provider_config. Например в файле
/usr/local/stat/providers/apache_provider_1.0/provider_config по умолчанию такая запись
use_command_line_args, свидетельствующая о том, что параметры берутся с командной
строки. А в linuxstat_provider_1.0/provider_config занесены файлы и каталоги доступ к
которым будет контролироваться сенсором LinSTAT. Теперь конкретней о некоторых
сенсорах и сопутствующих приложениях.
Как уже говорилось выше LinSTAT является версией утилиты аудита системы SNARE (System iNtrusion Analysis and Reporting Environment) с уже настроенными параметрами контроля. После установки в вашем распоряжении будет динамически загружаемый модуль ядра auditmodule.o и три утилиты auditdaemon, linuxstat и praudit. Модуль работая в пространстве ядра отлавливает критические системные вызовы вроде ‘execve‘ (выполнение команды), ‘open‘ (открыть файл), ‘mkdir‘ (создать каталог) и отправляет результат к подпрограмме, которая собирает всю информацию относительно процесса и пользователя его запустившего или просто попытался выполнить рассматриваемый системный вызов. Модуль сохраняет информацию во временном буфере, который может быть прочитан при помощи auditdaemon или linuxstat. Эти две программы по сути являются пользовательским интерфейсом к auditmodule.o, считываются данные через
устройство /proc/audit. При этом auditdaemon собирает все данные и сохраняет их в
бинарном формате в файл (по умолчанию /var/log/snare/audit), для того чтобы просмотреть
события ее можно извлечь при помощи praudit.
#auditdaemon -o /var/log/snare/audit-`date -I`
#praudit -c /var/log/snare/audit-2004-09-02
…
EVENT #26: act: READ, time: Thu Sep 2 17:46:59 2004, retcode: 2, exec_args: gpm, pathname:
/usr/sbin/gpm, uid: 0, gid: 0, euid: 0, egid: 0, pid: 991, ppid: 1, pwd: /, objname: /dev/tty0, owner: 0,
gowner: 0, inode: 36763, dev: 770, perm: rw—w—-
…
End of file /var/log/snare/audit (33 events in 4335 bytes: 131.36 bytes/event)
Утилита linuxstat работает в двух режимах live и offline. В live режиме информация берется
непосредственно с /proc/audit и сразу же анализируется сценариями STAT, в offline
анализируется файл созданный auditdaemon’ом.
В live режиме программу можно запустить так.
#linuxstat -name LinSTAT:1.0 -hostname localhost -live
А в offline так.
#linuxstat -name LinSTAT:1.0 -hostname localhost -offline /var/log/snare/audit-2004-09-02
Для примера пробуем занести новые данные в файл /etc/passwd, в live режиме система сразу
же выдает предупреждающее сообщение.
LinSTAT:1.0@09/02/2004 21:32:36: LOG: linux_restricted_write: 500: /etc/passwd written by
user 500, program /bin/bash
LinSTAT:1.0@09/02/2004 21:32:36: LOG:
2004-09-02T18:32:36Z
restricted_dir_write
http://www.cs.ucsb.edu/~rsg/STAT
LinSTAT:1.0
192.168.1.1sergej
500
500
bash
/bin/bash 22002
/etc/passwd
/etc/
passwd
Для запуска при старте системы используется скрипт /etc/init.d/linstat, который берет
данные из файла /etc/sysconfig/linuxstat. В этих файлах можно изменить параметры запуска и
месторасположение исполняемых и файлов отчетов.
# /etc/init.d/linstat
Usage: /etc/init.d/linstat {start_lin|stop_lin|restart_lin|start_daemon|stop_daemon|restart_daemon}
Как видите можно отдельно запустить только демон auditmodule или всю систему IDS,
например вот так.
# /etc/init.d/linstat start_lin
Starting linuxstat services: The audit module should be active now.
После чего идут сообщения об активированных сценариях.
LinSTAT:1.0@09/02/2004 15:37:54: LOG:
Сенсор webSTAT анализирует логи Web-сервера Apache, после установки будет
доступна только одна утилита — webstat, которая и принимает в качестве аргумента лог-файл.
Работает также в двух режимах offline и live. Первый реализуется опцией [-auditfile | -a].
# webstat -a /var/log/apache2/access_log
Второй при помощи опции [-interface | -i].
#webstat -i /var/log/apache2/access_log
Теперь для контроля работы набираем в строке браузера http://server/cgi-bin/, после
чего система выдает сообщение.
webstat@localhost@08/26/2004 11:36:18: LOG: apache_regex_xml:
26/Aug/2004:11:36:18 +0300 : First Bad Request «GET /cgi-bin/ HTTP/1.1» :From 192.168.0.1
:Attack: cgi_dir
При повторной попытке.
webstat@localhost@08/26/2004 11:37:34: LOG: apache_regex_xml:
26/Aug/2004:11:37:34 +0300 : Subsequent Bad Request «GET /cgi-bin/ HTTP/1.1» :From
192.168.0.1 :Attack: cgi_dir
Обратите внимание, что система различает первую и последующие попытки одной и той же
атаки. Использование сенсора logSTAT аналогично предыдущему.
#logstat -i /var/log/messages -i /var/log/secure
Либо.
#logstat -a /var/log/messages -a /var/log/secure
[Sun Aug 29 10:01:56 2004] : Facility : kernel: First Occurance : eth0: setting promiscuous mode.
logstat@localhost@29/08/2004 12:01:57: LOG: syslog_watch:
[Sun Aug 29 11:01:16 2004]: Facility : sshd[7717]: First Occurance : failed password for root
from 192.168.0.20 port 22 ssh2
[Sun Aug 29 11:01:16 2004]: Facility : server[23101]: Subsequent Occurance : dispatch_input:
bad request line
‘aa~m?~n?~o?~p?%.236u%304$n%.217u%305$n%.6u%306$n%.192u%307$n~p~p~p~p~p~p~
p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p
~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~
p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p
~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~
p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p
~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~
p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p1???^g?_~mo^g~mq^l~iq^d~mq^\~iq^h
~ia^\1?i^q1?a^\^pf?@?@y^l^bu^d<^at^m?@^a}???~@~i??0??@?@^cu?i1??hc^g~i[^ h~mk^h~ic^l^k?@1??~@?t/bin/sh’ logstat@localhost@01/09/2004 22:13:04: LOG: syslog_bufferoverflow: Датчик NetSTAT также может работать в двух режимах. Если запустить с указанием сетевого интерфейса, то будут контролироваться проходящие через него пакеты. #netstat -i eth0 Got UDP port unreachable 192.168.0.1 48361 -> 192.168.0.20 1
Inside tcpprobe, generating Half Open event
attacker: 192.168.0.1, attackerport: 48370, victim: 192.168.0.1, victimport:22
CLASSIFICATION_NAME=»tcpsweep»
CLASSIFICATION_URL=»http://www.cs.ucsb.edu/~rsg»
SOURCE_NODEADDRESS=»192.168.0.1″
SOURCE_PORT=»48361″
TARGET_NODEADDRESS=»192.168.0.20″
ADDITIONAL_DATA=»Alert only contains last attacker»
threshold=»3″
timeout=»3″
victims=»»
victim_address=»335587520″
total_probed=»1488″
addr_probes=»»
t1=»1″
И как входные данные можно использовать информацию собранную внешней
утилитой, например tcpdump.
#netstat -a tcpdump_file
Для удобства параметры можно занести в provider_config.
interface eth0
или
auditfile /audit/file.tcpdump
Принцип работы остальных сенсоров STAT аналогичен и думаю ясен.
К сожалению STAT только только выбрался из концептуального состояния и еще не
успел обзавестись полноценными средствами сбора и вывода данных так, что их придется
создавать самому, а поэтому о массовом использовании разговор пока не идет. Проведенные тестовые испытания подтвердили жизненность методики STAT, были обнаружены не только уже известные атаки, но и тестировались уязвимости обнаруженные, после того как система была установлена, но все равно в отчетах одного из сенсоров появлялось предупреждающее сообщение. В этом проявляется одна из основных достоинств STAT, т.е. работающая IDS фактически не требует никаких обновлений и может эксплуатироваться большой промежуток времени без внимания администратора. Остается надеяться, что наработки не пропадут даром. Успехов.