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

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

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

Далее мы попытаемся настроить Snort для работы с БД MySQL и поговорим о способах просмотра записанных данных. Занесение данных в БД – лишь малая часть проблемы, можно сказать, надводная часть айсберга, а вот «что делать с уже внесёнными данными дальше?» – это уже вопрос, который может и не иметь однозначно правильного ответа. Попытка дать на него ответ – это довольно непростая задача, особенно если мы хотим сделать какие-то обоснованные выводы на основе данных, собранных с распределённой сети сенсоров. Наибольшую сложность могут представлять попытки обнаружения в данных следов распределённых телекоммуникационных атак, но об этом, скорее всего, я напишу в будущих статьях.

Занесение данных из IDS Snort в БД

Для начала мы возьмём относительно простую и свободно распространяемую БД MySQL. Её выбор обоснован большей распространённостью среди простых БД и наличием достаточного числа литературы к ней на русском языке [5].

Напомню основные моменты по установке Snort (подробнее см. [1]). Как и обычно, скачиваем и ставим последний Snort, если он не стоит:

# wget http://www.snort.org/dl/snort-2.0.2.tar.gz

# wget http://www.snort.org/dl/snort-2.0.2.tar.gz.md5

Сравниваем значения хеша, выданного командами:

# cat snort-2.0.2.tar.gz.md5

# md5sum snort-2.0.2.tar.gz

Аналогично скачиваем и проверяем последние правила:

# wget http://www.snort.org/dl/rules/snortrules-stable.tar.gz

# wget http://www.snort.org/dl/rules/snortrules-stable.tar.gz.md5

# cat snortrules-stable.tar.gz.md5

# md5sum snortrules-stable.tar.gz

Распаковываем скачанное куда-нибудь, например в директорию /progi/snort-2.0.2, и запускаем там конфигурирование с опцией --with-mysql:

#./configure --with-mysql

не забываем про библиотеку libpcap. Если она не стоит и выдаётся ошибка:

копируем со второго диска (RedHat v.7.3) и ставим:

# rpm -ihv libpcap-0.6.2-12.i386.rpm

Если БД MySQL у вас не установлена, то вам выдастся следующее сообщение в процессе конфигурирования:

и вам надо будет поставить БД MySQL. RedHat 7.3 идёт с версией 3.23.49-3 и mysqlclient9-3.23.22-6. Так как более новые версии данных продуктов доступны также в rpm через up2date (или http://redhat.com/apps/support/errata), то мы возьмём их, соответственно версии 3.23.54a-3 и 3.23.22-8.

Обладатели других версий Linux могут установить себе БД самостоятельно, при этом, наверное, будет лучше скачать последнюю версию прямо с сайта MySQL [6].

Решение всех возникших проблем при этом ложится на ваши плечи. Мы же пишем все нужные файлы для MySQL в отдельную директорию и ставим их все вместе, так как это проще, чем соблюдать последовательность установки, дабы избежать ошибок с зависимостями о необходимости установки того rpm перед этим или после этого.

Далее, либо руками прописываем мягкие ссылки на /etc/rc.d/init.d/mysqld в директориях /etc/rc.d/rc?.d на запуск и останов, либо запускаем:

# chkconfig mysqld on

который делает это за нас. (Замечание: в некоторых не-rpm поставках mysqld называется mysql.)

Далее либо перезапускаемся, либо запускаем MySQL руками:

# /etc/rc.d/init.d/mysqld start

Далее повторно (если у вас не был установлен MySQL) запускаем конфигурацию из директории, где у нас установлен дистрибутив Snort.

# ./configure --with-mysql

Запускаем компиляцию:

# make

И устанавливаем Snort:

# make install

Далее из snortrules-stable.tar.gz копируем правила (файлы *.rules) в /etc/snort/rules. Остальные файлы помещаем в /etc/snort. После этого редактируем /etc/snort/snort.conf.

Точная настройка и разбор snort.conf-файла вообще заслуживает отдельной статьи.

Основные моменты, что мы меняли в [1]:

В первом разделе это были переменные:

var HOME_NET 123.45.45.45

или для диапазона адресов:

var HOME_NET [10.1.1.0/24,192.168.1.0/24]

var RULE_PATH rules

Вторая и четвёртые части у нас не изменились, а в третьей, отвечающей за вывод данных, как раз и будут главные изменения. Там мы укажем, что необходимо вести вывод в БД MySQL.

Мы находим закомментированные строчки:

# database: log to a variety of databases

# ---------------------------------------

# See the README.database file for more information about

# configuring and using this plugin.

#

# output database: log, mysql, user=root password=test dbname=db host=localhost

# output database: alert, postgresql, user=snort dbname=snort

# output database: log, unixodbc, user=snort dbname=snort

# output database: log, mssql, dbname=snort user=snort password=test

Раскомментируем первую, нужную нам для MySQL строчку, или сделаем её копию и укажем имя БД, пароль и пользователя для доступа к ней, которые зададим после. Пусть пользователь БД будет называться snort, пароль будет ваш_пароль№1, пользоваться мы будем БД snort. Имя нашего хоста будет localhost.

В итоге получим:

output database: log, mysql, user=snort password=ваш_пароль№1 dbname=snort host=localhost

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

Для того чтобы делать записи в БД, нужно, чтобы в этой самой БД существовала не только необходимая БД с соответствующим именем, но и были созданы таблицы, куда, собственно, и будут добавляться записи. Если мы прочитаем файл README.database, на который есть ссылка в комментариях к строчкам выше, то оттуда мы можем узнать, что можно вести логи не только в MySQL, который мы выбрали вначале, но и в:

n   PostgreSQL;

n   любую UNIX ODBC БД;

n   MS SQL Server;

n   Oracle.

Список вполне неплохой.

Если почитать README.database внимательно, то там будет написано практически всё, чем мы займёмся дальше, правда, на английском языке.

Если БД MySQL у вас установлена впервые или вы её ранее не настраивали, то вам в целях безопасности придётся немного поднастроить её сейчас, в частности, задать пароль на суперпользователя БД – root (root для MySQL и root для системы – это разные пользователи). Для этого подключаемся к БД от имени пользователя root:

# mysql -u root

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

Команды следует набирать после приглашения «mysql>»:

mysql> set password for 'root'@'localhost'=password('ваш_пароль№2');

в ответ должно выдастся что-то вроде:

Query OK, 0 rows affected (0.39 sec)

Затем создаём БД snort (это нужно и тем, у кого MySQL уже давно настроена):

mysql> create database snort;

Иногда слова CREATE DATABASE пишут заглавными буквами, но в данном случае это не важно. Далее следует выйти из БД командой:

mysql> exit

Теперь, после того как мы установили пароль для захода в БД, нам следует набирать пароль при входе в БД и заходить уже другой командой, с лишним ключом «-p», говорящим о необходимости запрашивать пароль:

# mysql -u root -p

 

на запрос пароля при входе следует вводить «ваш_пароль№2», заданный выше. Далее необходимо создать пользователей, от имени которых мы будем работать с БД, задать им права на выполнение тех или иных действий, пароли и структуру таблиц БД snort. Количество таблиц, которые использует Snort, велико для того, чтобы задавать их все вручную:

n  schema

n  event

n  signature

n sig_reference

n  reference

n  reference_system

n  sig_class

n  sensor

n  iphdr

n  tcphdr

n  udphdr

n  icmphdr

n  opt

n  data

n  encoding

n  detail

Это долго и неудобно, велика вероятность ошибки. Поэтому лучше воспользоваться уже готовым cписком команд, благо для популярных БД они поставляются с дистрибутивом Snort в директории contrib.

Нужный нам файл называется create_mysql. Мы ограничимся лишь быстрым просмотром этого файла для ознакомления, а если у вас будет своя, уникальная БД, тогда вам лучше взять подобный файл и разобраться со структурой таблиц досконально, а пока я не вижу смысла придумывать велосипед.

Создать описанную структуру можно командой:

# mysql -D snort -u root -p < /progi/snort-2.0.2/contrib/create_mysql

Однако мы сделаем это немного по-другому, в интерактивном режиме, чтобы было более понятно. Для этого файл create_mysql мы помещаем в директорию, из которой будем запускать MySQL, чтобы он его видел без указания лишних путей.

Запускаем:

# mysql -u root -p

Введя ваш_пароль№2, в приглашении БД указываем, что мы хотим подключиться и работать с БД snort.

mysql> connect snort

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

mysql> source create_mysql

В ответ на это мы должны увидеть множество строчек вида:

Query OK, 0 rows affected (0.00 sec)

Query OK, 1 row affected (0.00 sec)

означающих, что выполнение той или иной SQL-команды прошло успешно. В директории /var/lib/mysql/snort должны появиться файлы, соответствующие созданным таблицам.

Далее нам необходимо создать пользователя snort, от имени которого Snort будет работать с БД, задать ему пароль и вручить ему права на те или иные действия с БД snort. Например, на добавление новых записей в таблицы и пр.

Явной команды вроде adduser для добавления пользователей, как в Linux, здесь нет, объясняется это тем, что сведения о пользователях хранятся также в самой БД в её таблицах, поэтому при задании каких-либо атрибутов пользователю, то есть его прав или пароля, пользователь автоматически вносится в БД. Именно исходя из соображений безопасности по доступу к таблице с данными пользователей мы выше ввели пароль для суперпользователя БД.

Вручаем права пользователю snort:

mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to snort;

для того чтобы можно было работать с БД, локально запускаем всё то же самое, но для snort@localhost:

mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to snort@localhost;

Далее, забегая вперёд, создадим ещё одного пользователя и вручим ему права только на просмотр БД. В принципе, если этим пользователем будет php-скрипт на нашем компьютере, достаточно одной (второй) записи для локального доступа. Пользователя назовём acidviewer, а из прав дадим ему те же, что и выше, кроме права DELETE.

mysql> grant CREATE,INSERT,SELECT,UPDATE on snort.* to acidviewer;

mysql> grant CREATE,INSERT,SELECT,UPDATE on snort.* to acidviewer@localhost;

Теперь зададим пароли для созданных аккаунтов. Так как информация о паролях хранится в БД mysql, а мы сейчас работаем с БД snort, переключимся на первую.

mysql> connect mysql

Поскольку аккаунтов для одного и того же пользователя два, один для доступа извне, а другой с localhost, то пароли будут задаваться также два раза. Можно задать разные пароли, но будет велик риск запутаться. Пароль ваш_пароль№1 используется тот, что мы указали выше при редактировании файла snort.conf в третьей секции. Пароль для acidviewer следует придумать, назовём его ваш_пароль№3.

mysql> set password for 'snort'@'localhost'=password('ваш_пароль№1');

mysql> set password for 'snort'@'%'=password('ваш_пароль№1');

mysql> set password for 'acidviewer'@'localhost'=password('ваш_пароль№3');

mysql> set password for 'acidviewer'@'%'=password('ваш_пароль№3');

Далее сбрасываем привилегии и выходим.

mysql> flush privileges;

mysql> exit

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

Замечание: дотошный читатель скажет, что пользователю snort мы задали несколько больше привилегий, чем ему это необходимо. Сделано это было специально с целью не запутывать читателя лишней информацией и лишними пользователями. Поэтому два пользователя были объединены в одного и от имени snort будет работать не только Snort, но и программа (скрипт), с помощью которой мы будем просматривать БД и, возможно, редактировать её. Как раз для редактирования расширенные права и нужны.

Пробуем запустить Snort вручную.

# /usr/local/bin/snort -o -i eth0 -d -c /etc/snort/snort.conf

Параметр, указывающий на каком интерфейсе будет слушать Snort: «-i eth0», можно опустить.

Замечание: если у вас пароль, указанный в snort.conf (ваш_пароль№1), не соответствует заданному в БД для пользователя snort (тоже ваш_пароль№1) из-за ошибки в написании, то вам может выдасться в процессе запуска Snort сообщение:

ERROR: database: mysql_error: Access denied for user: 'snort@localhost' (Using password: YES)

Если вы следовали изложенному выше, у вас проблем быть не должно.

В случае успешного ручного запуска создаём скрипт для автоматизации этого процесса при загрузке компьютера. Скрипт назовём snortd и поместим его в /etc/rc.d/init.d:

#!/bin/bash

#

# snortd         Start/Stop the snort IDS daemon.

#

# chkconfig: 2345 79 11

# description:  snort is a lightweight network intrusion

# detection tool that currently detects more than 1100 host

# and network vulnerabilities, portscans, backdoors, and more.

#

# June 10, 2000 -- Dave Wreski <dave@linuxsecurity.com>

#   - initial version

#

# July 08, 2000 Dave Wreski <dave@guardiandigital.com>

#   - added snort user/group

#   - support for 1.6.2

 

# Source function library.

. /etc/rc.d/init.d/functions

 

# Specify your network interface here

INTERFACE=eth0

 

# See how we were called.

case "$1" in

   start)

     echo -n "Starting snort: "

     # ifconfig eth0 up

     daemon /usr/local/bin/snort -o -i $INTERFACE -d -D -c /etc/snort/snort.conf

     touch /var/lock/subsys/snort

     sleep 3

     if [ -f /var/log/snort/alert ]

     then

     rm /var/log/snort/alert

     fi

     echo

     ;;

   stop)

     echo -n "Stopping snort: "

     killproc snort

     rm -f /var/lock/subsys/snort

     echo

     ;;

   restart)

     $0 stop

     $0 start

     ;;

   status)

     status snort

     ;;

   *)

     echo "Usage: $0 {start|stop|restart|status}"

     exit 1

esac

 

exit 0

Замечание: закомментированная строчка «ifconfig eth0 up» имеет следующий смысл: если при каких-то условиях (смена номера запуска или какой-то сбой при запуске network) Snort будет запускаться до запуска сети и поднятия интерфейса, то при её наличии ошибки не будет. Повторное поднятие уже поднятого интерфейса ошибок давать не должно. Строчку «rm /var/log/snort/alert» и несколько соседних можно закомментировать, если вы не хотите, чтобы у вас при запуске этот файл начинался с нуля.

Далее, либо руками прописываем мягкие ссылки на /etc/rc.d/init.d/snortd в директориях /etc/rc.d/rc?.d на запуск и останов, соблюдая последовательность запуска, чтобы Snort запускался после MySQL, например:

# ln -s /etc/rc.d/init.d/snortd /etc/rc.d/rc3.d/S79snortd

# ln -s /etc/rc.d/init.d/snortd /etc/rc.d/rc3.d/K11snortd

либо запускаем:

# chkconfig snortd on

или

# chkconfig --level 3 snortd on

(сделать ссылки только для уровня 3), который делает это за нас.

Автоматизация этого процесса не даёт гарантии того, что запуск Snort окажется после MySQL, а останов наоборот, поэтому этот момент следует проконтролировать вручную, посмотрев, чтобы номер у S??snortd был больше, чем у S??mysqld, а номер у K??snortd был меньше, чем у K??mysqld.

Напомню, что в дистрибутиве Snort, в директории contrib имеется файл S99snort, аналогичный snortd.

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

В любом случае в ответ на ваши действия вы должны увидеть зелёное ok, а на команду status вам должно выдаваться, что Snort выполняется.

Если это так, то половина нужного нам результата получена, и мы смело можем переходить ко второй части, а именно к настройке и изучению средств просмотра БД snort, куда запущенный нами Snort исправно записывает свои замечания о проходящем через него трафике.

Просмотр содержимого БД snort

Если компьютер с установленным и правильно запущенным Snort подключить к сети Интернет напрямую, то есть с использованием реального IP-адреса, то менее чем через несколько минут в БД snort появятся новые записи. (В последнее время львиную долю этих записей составляют ICMP-сканирования.) Появление новых записей в БД не так наглядно для конечного пользователя, как если бы логи велись в файл, а мы бы запустили:

# tail -f имя_этого_файла

для просмотра вновь появляющихся записей или:

# cat имя_log_файла

для просмотра содержимого всего файла. Для работы с БД нам необходимо наличие большего объёма знаний. Счастлив тот, кто знает СУБД как свои пять пальцев, – он может смело пропустить несколько абзацев ниже. Со всеми остальными мы попытаемся просмотреть таблицы БД snort с помощью SQL-запросов.

Для начала нам необходимо подключиться к СУБД MySQL. Сделать это можно как от имени суперпользователя root, так и от имени заведённых пользователей snort и acidviewer. Выберем пользователя snort и выполним команду:

# mysql -u snort -p

В качестве пароля необходимо ввести ваш_пароль№1.

Вся последующая работа с БД ведётся с помощью SQL-запросов. Для получения более-менее наглядного представления о таблицах с данными мы выполним несколько простых SQL-запросов. Более глубокое изучение языка запросов читатели могут выполнить самостоятельно. После того как мы убедимся, что данные в таблицах есть, мы перейдём к настройке средств более удобного просмотра БД, а именно ACID. Первая команда, которую мы выполним, покажет нам, какие БД имеются в нашей СУБД.

mysql> SHOW DATABASES;

Замечание: регистр команд не имеет значения, MySQL обработает запрос, даже если вы смешаете регистры, однако мы будем писать команды в верхнем регистре, как стандарт де-факто при использовании языка SQL. Команды можно вводить в несколько строчек, концом команды считается знак «;», а не символ перевода строки. Это очень удобно при написании длинных команд, так как не теряется наглядность.

В ответ на запрос мы должны увидеть табличку с тремя БД: mysql, snort и test.

Выберем БД snort:

mysql> CONNECT snort;

и посмотрим, какие таблицы у нас имеются:

mysql> SHOW TABLES;

Как раз все те, которые мы создавали ранее.

Чтобы посмотреть заголовки столбцов выбранной нами таблицы event, дадим команду:

mysql> SHOW COLUMNS FROM event;

либо

mysql> DESCRIBE event;

По интуитивным соображениям можно понять, что cid отвечает за нумерацию событий. С помощью команды:

mysql> SELECT * FROM event WHERE cid<10;

мы можем получить список нескольких первых событий.

Полученная таблица содержит 4 столбца с заголовками, которые мы видели ранее:

n  sid или sensor ID – тот сенсор, с которого была получена информация;

n  cid или ID counter – грубо говоря, номер события;

n  signature – номер сигнатуры, которая была обнаружена;

n  timestamp – временная метка, чтобы знать, когда произошло событие.

Замечание 1: нумерация событий для разных сенсоров не сквозная, поэтому первичным ключом в данной таблице являются два поля sid и cid. Это можно заметить, если внимательно посмотреть содержимое файла create_mysql.

Замечание 2: как легко догадаться, сенсоров может быть несколько, если получится, то этот случай мы обсудим в следующих статьях.

Замечание 3: давать команду для показа всех строк данной таблицы:

mysql> SELECT * FROM event;

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

Чтобы понять, что такое сигнатура номер 2 или тот номер, что будет у вас в таблице, обратимся к таблице singature и посмотрим содержимое строки с sig_id=2;

mysql> SELECT * FROM signature WHERE sig_id=2;

Если нам не нужна лишняя информация, то мы можем её не выводить, например, выполнив запрос только на вывод содержимого полей sig_id и sig_name следующим образом:

mysql> SELECT sig_id,sig_name FROM signature WHERE sig_id=2;

Как мы видим для моего случая, это «STEALTH ACTIVITY (SYN FIN scan) detection».

Подобным образом можно просматривать все нужные нам таблицы и получать информацию не хуже, чем если бы мы читали текстовый файл. Используя более хитрые запросы, можно выводить информацию из нескольких таблиц в виде одной. Например, если мы хотим посмотреть несколько первых событий, как и ранее, только без столбца sid и чтобы вместо signature выводился не номер, а сразу словами разъяснение, то есть sig_name из таблицы signature, то команда, выполняющая это, будет выглядеть так:

mysql> SELECT event.cid,signature.sig_name,event.timestamp FROM event,signature WHERE event.signature=signature.sig_id AND cid<10;

Вот результат её выполнения.

Обратившись к [5], можно научиться выполнять и более виртуозные запросы. В таблице iphdr для каждого события по его cid точно так же можно узнать IP-адрес источника атаки и на какой адрес она была нацелена.

Моё мнение таково, что хороший системный администратор или специалист по информационной безопасности должны уметь выполнять простые SQL-запросы в командной строке, как это было описано выше. Конечно, никто этого делать не заставляет, и большинство из нас далеки от совершенства, выше было рассказано про то, без чего по-хорошему никак не обойтись. Любая, будь то самая удобная графическая оболочка при попытке задания более сложных запросов неминуемо приведёт вас к написанию SQL-запросов вручную. Несмотря на то что язык SQL лучше знать, чем не знать, не хотелось бы упускать из вида те инструменты, которые значительно упрощают нашу жизнь, в частности, программу phpMyAdmin.

phpMyAdmin

Для работы phpMyAdmin [8] и ACID необходимо, чтобы были установлены пакеты php и php-mysql, у меня это были php-4.1.2-7.3.6 php-mysql-4.1.2-7.3.6, на 2-м и 3-м дисках RedHat v.7.3, соответственно, имеются более ранние версии.

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

Для начала следует сходить на сайт этой программы [8] и скачать последнюю версию с какого-нибудь зеркала. На момент написания статьи последней версией была 2.5.4.

После скачивания, например [9], и проверки хеш-функции:

# md5sum phpMyAdmin-2.5.4-php.tar.gz

(MD5: 76fc7216aa2f132888c7173a6668af46)

содержимое архива следует поместить в папку для php-скриптов. Если не следовать досконально файлу Documentation.txt и закрыть глаза на некоторые вопросы безопасности, то удобнее будет создать директорию phpmyadmin, например, в /var/www/html и содержимое phpMyAdmin-2.5.4, то есть всё то, что находится в архиве, поместить туда (в /var/www/html/phpmyadmin). Далее следует внести небольшое исправление в /var/www/html/phpmyadmin/config.inc.php в строку:

$cfg['Servers'][$i]['password'] = '';

указав там свой пароль от БД:

$cfg['Servers'][$i]['password'] = 'ваш_пароль№2';

Остальные настройки, как host, port, user и пр., менять не стоит, так как по умолчанию всё должно работать.

Если вы установили правильный пароль, то при попытке обращения к директории phpmyadmin веб-сервера, поддерживающего php, должно выдасться следующее:

Многих должен порадовать тот факт, что поддерживается русский язык и есть выбор различных кодировок. Далее, если щёлкнуть на «Базы данных», должны высветиться те БД, которые имеются в MySQL.

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

Щёлкая на название таблицы event слева, получаем информацию об этой таблице:

Далее, внизу, SQL-запрос в окошке оставляем без изменения и жмём кнопку «Пошёл». После чего у нас на экран выводится содержимое нашей таблицы.

Задав себе повторно тот же, что и ранее, вопрос, а именно: «Что за событие означает сигнатура номер 2?», мы можем также просто щёлкнуть на имя таблицы signature слева и увидеть параметры этой таблицы, затем внизу, не меняя SQL-запроса в окошке, нажав на кнопку «Пошёл», получаем содержимое первых 30 строк, среди которых находим нужную.

Соответственно, если изменить запрос, например, на:

mysql> SELECT event.cid,signature.sig_name,event.timestamp FROM event,signature WHERE event.signature=signature.sig_id AND cid<10;

мы получим тот же результат, что и ранее мы получали через консольного клиента. Именно поэтому, какой бы оболочка удобной ни была, следует знать SQL, так как это основа работы с БД.

Надеюсь, что просмотр содержимого БД двумя вышеописанными способами не показался вам чудовищно сложным. Наоборот, я старался сделать это как можно проще, чтобы от слов «БД» у вас не возникали мысли о «чёрном ящике» за семью печатями и не шли мурашки по коже. Надеюсь, что мне удалось убедить тех, кто ранее не был знаком с БД, что это не есть плохо, когда логи хранятся в БД. Их можно также легко просматривать, если не сказать, что даже с большим числом удобств, чем если бы они были в обычном текстовом файле.

После того как мы убедились, что наша БД содержит информацию, попытаемся настроить специализированные и более удобные средства просмотра БД, а именно ACID. Продвинутые читатели, если их не устроит ACID, могут также пропустить всё, что говорится ниже, и самостоятельно «изобрести велосипед» не хуже. Со всеми же остальными начнём настраивать уже готовый пакет – ACID, поставляемый вместе с дистрибутивом Snort (в директории contrib).

ACID

ACID [10] расшифровывается как Analysis Console for Incident/Intrusion Databases и дословно переводится как консоль для анализа баз данных с инцидентами/атаками/вторжениями. В общем, для нашего случая это то, что доктор прописал, тем более что данная программа была разработана координационным центром CERT [11] как часть проекта AIRCERT [12].

ACID из себя представляет набор php-cкриптов, способных выполнять различные функции, в том числе начиная с формирования запросов на получение данных из БД аналогично тому, как это мы делали ранее, и заканчивая декодированием пакетов с целью их более удобного визуального восприятия и подсчётом статистических данных.

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

Для того чтобы наглядно оценить удобство использования данного средства, необходимо также иметь какой-либо из установленных веб-серверов с поддержкой php, например, всё тот же apache. Плюс необходимо иметь несколько дополнительных средств, нужных для работы ACID:

n  ADODB [13];

n  JpGraph [15];

n  PHPlot [16];

n  GD [17].

«ADODB – это абстрактный класс доступа к базам данных, написанный на PHP» [14].

«Для тех, кто в танке, поясню на примере. Предположим, вы написали скрипт под MySQL, и тут заказчик говорит вам, что хостинг меняется, и там есть только PostgreSQL.

Если вы не использовали класс абстрактного доступа к базам данных, то вам пришлось бы:

n  заменить весь код работы с MySQL на postgreSQL;

n  переписать SQL-запросы (так как есть отличия).

Если бы вы использовали абстрактный слой доступа к БД, то вам скорее всего не пришлось бы менять php-код (только в одном месте указали бы, что используете PostgreSQL) и изменить SQL-запросы (хотя иногда и это не понадобилось бы). Я намеренно в этом описании использовал фразу «абстрактный класс доступа к БД», поскольку ADODB – не единственный подобный класс. Наиболее известные конкуренты: Pear::DB и Pear::MDB» [14].

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

PHPLOT – фактически то же самое, что и JpGraph, позволяет рисовать графики. Требует наличия библиотеки GD.

GD – это библиотека ANSI C, необходимая для динамического создания картинок. GD может создавать картинки в различных форматах, в том числе в PNG и JPEG. (GD не поддерживает формат GIF.)

Пробежав по разделам download вышеописанных продуктов, скачиваем последние стабильные версии и проверяем их хеши:

n  ACID 0.9.6b23 [18]

n  ADODB 3.94 [19]

n  JpGraph 1.13 [20]

n  PHPlot 4.4.6 [21]

n  GD 2.0.15 [22]

 

d8c49614393fa05ac140de349f57e438  acid-0.9.6b23.tar.gz

78aac17c7fd1d0e0f6685153facb8c36  adodb394.tgz

6ededf633b4fd054662ec123c7825fbb  gd-2.0.15.tar.gz

ad78bd1658e3983bb6afbc074f029698  jpgraph-1.13.tar.gz

8a5b34e09fa29f20e31814cbd8c0d0b5  phplot-4.4.6.tar.gz

Содержимое архивов помещаем в /var/www/html:

# tar -zxvf acid-0.9.6b23.tar.gz -C /var/www/html

# tar -zxvf adodb394.tgz -C /var/www/html

# tar -zxvf gd-2.0.15.tar.gz -C /var/www/html

# tar -zxvf phplot-4.4.6.tar.gz -C /var/www/html

Для JpGraph создаём директорию /var/www/html/jpgraph и содержимое архивной поддиректории src из архива помещаем туда.

# tar -zxvf jpgraph-1.13.tar.gz -C /var/www/html

# mkdir /var/www/html/jpgraph

# mv /var/www/html/jpgraph-1.13/src/* /var/www/html/jpgraph

# rm -rf /var/www/html/jpgraph-1.13

В именах директорий gd-2.0.15, phplot-4.4.6 убираем номера версий либо делаем мягкие ссылки на эти директории:

# cd /var/www/html

# mv gd-2.0.15 gd

# mv phplot-4.4.6 phplot

или

# cd /var/www/html

# ln -s gd-2.0.15 gd

# ln -s phplot-4.4.6 phplot

Напоминание: для работы ACID необходимо наличие установленных пакетов php и php-mysql (подробнее см. выше).

Далее следует настроить ACID на работу с нашей БД и показать ему, куда мы скопировали дополнительные пакеты, для этого в файле /var/www/html/acid_conf.php необходимо изменить переменные:

$DBlib_path = "../adodb";

$alert_dbname = "snort";

$alert_user   = "snort";

$alert_password = "ваш_пароль№1";

$ChartLib_path = "../jpgraph";

Остальные переменные проще настроить по мере необходимости, у большинства читателей это не должно вызвать проблем, так как ACID очень дружелюбен и почти всегда указывает, что и где надо править в случае, если ему что-то не нравится.

Далее обратимся по адресу: http://localhost/acid. При первом запуске ACID нам сообщит, что дополнительные таблицы, необходимые для его работы, не созданы:

Для их создания нам необходимо нажать на «Setup page». После чего у нас отобразится следующее окно:

В котором следует нажать на кнопку «Create ACID AG». После её нажатия у нас отобразится окно:

В первых строчках мы можем прочитать, что в нашей БД (snort) дополнительно были созданы четыре таблицы:

n  acid_ag;

n  acid_ag_alert;

n  acid_ip_cache;

n  acid_event.

После этого Snort готов к работе. Либо нажимаем в конце этой страницы на «Main page», либо опять набираем адрес: http://localhost/acid.

Если у вас БД маленькая, то страница должна отобразиться сразу, если же БД у вас большая, например, более полугода, то тогда придётся подождать вплоть до нескольких минут. В конце у вас должна выводиться картинка, похожая на следующую:

Если это так, то вы правильно всё сделали.

Далее советую вам сделать два необязательных, но полезных действия, а именно: создать ещё один адрес с правами только для просмотра и задать пароли на доступ для обоих.

Во время работы с БД мы уже создали необходимого нам пользователя acidviewer с меньшими правами. Сейчас мы доведём начатое до конца.

Для начала скопируем acid:

# cp -R /var/www/html/acid /var/www/html/acidviewer

Далее отредактируем файл /var/www/html/acidviewer/acid_conf.php, заменив в нём:

$alert_user   = "snort";

$alert_password = "ваш_пароль№1";

на

$alert_user   = "acidviewer";

$alert_password = "ваш_пароль№3";

Интерфейс и кнопки по удалению записей останутся, но при их активации будет выводиться сообщение с ошибкой о том, что у пользователя недостаточно прав для удаления. Создание данного аккаунта удобно тем, что вы можете его давать вашим знакомым администраторам или другим людям для просмотра с меньшей опасностью потерять записи в вашей БД. Обращаться к нему следует http://localhost/acidviewer, естественно, вместо localhost следует писать ваш адрес. И второе, чтобы кто попало через веб-интерфейс не заходил к вам на сервер и не смотрел ваши данные в ACID, создадим пользователей с паролями на доступ к acid и acidviewer. Для этого создадим директорию, где будет храниться файл с паролями, например /usr/lib/apache/passwords.

# mkdir /usr/lib/apache/passwords

Далее, если в этой директории у вас нет файла с паролями и таких пользователей, создадим файл и пользователей. Вначале это будет пользователь admin с паролем ваш_пароль№4. Пароль следует ввести после соответствующего приглашения.

# htpasswd -c /usr/lib/apache/passwords/passwords admin

Опция «-c» означает create (создать файл), указывайте её, если у вас нет файла /usr/lib/apache/passwords/passwords.

Далее добавим второго пользователя view с паролем ваш_пароль№5:

# htpasswd /usr/lib/apache/passwords/passwords view

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

Затем необходимо внести правку в /etc/httpd/conf/httpd.conf, дописав туда следующее:

<Directory "/var/www/html/acid">

    AuthType Basic

    AuthName "commentline1"

    AuthUserFile /usr/lib/apache/passwords/passwords

    Require user admin

    AllowOverride None

</Directory>

<Directory "/var/www/html/acidviewer">

    AuthType Basic

    AuthName "commentline2"

    AuthUserFile /usr/lib/apache/passwords/passwords

    Require user view

    AllowOverride None

</Directory>

Замечание: следует внимательно посмотреть, в какую секцию вы дописываете эти строчки, и проследить за другими секциями, может случиться так, что дописывать их придётся несколько раз, каждый раз для своей секции. Иначе может возникнуть ситуация, когда, например, для http-доступа у вас пароль спрашиваться будет, а для https – нет, или наоборот.

В переменной AuthName можно записать любую информацию, которая будет выдаваться пользователю при запросе пароля.

После внесения изменений в конфигурационный файл необходимо уведомить apache об этих изменениях, просто перезапустив его командой:

# /etc/rc.d/init.d/httpd restart

Если после этого у вас при заходе запрашивается пароль (не забудьте сбросить кеш) и всё работает, то статья удалась и можно сказать, что дальнейшее изучение ACID лучше выполнить самостоятельно с помощью «метода научного тыка», щёлкая мышкой. Графический интуитивно понятный интерфейс не должен вызвать у вас затруднений.

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

Литература, ссылки:

1. Закляков П. Обнаружение атак: теория и практика, Snort. – Журнал «Системный администратор», №10(11), октябрь 2003 г. – 48-67 с.

2. Раздел документации к Snort: http://www.Snort.org/docs

3. Snort Installation Manual on RedHat 7.3: http://www.Snort.org/docs/Snort-rh7-mysql-ACID-1-5.pdf

4. Snort Installation Manual on RedHat 9.0: http://www.Snort.org/docs/Snort_acid_rh9.pdf

5. Аткинсон Л. MySQL. Библиотека профессионала: Пер. с англ. – М.: Издательский дом «Вильямс», 2002 г.

6. MySQL The World’s Most Popular Open Source Database: http://www.mysql.com, раздел download: http://www.mysql.com/downloads/index.html

7. Дюбуа П. Применение MySQL и Perl в Web-приложениях: Пер. с англ. – М.: Издательский дом «Вильямс», 2002 г.

8. phpMyAdmin – MySQL DB administration tool: http://www.phpmyadmin.net

9. Ссылка на одно из зеркал, откуда можно скачать phpMyAdmin: http://unc.dl.sourceforge.net/sourceforge/phpmyadmin/phpMyAdmin-2.5.4-php.tar.gz

10. Сайт ACID (Analysis Console for Intrusion Databases): http://acidlab.sourceforge.net

11. Сайт координационного центра CERT: http://www.cert.org

12. ACID (часть проекта AIR-CERT): http://www.cert.org/kb/acid

13. ADOdb Database Library for PHP: http://php.weblogs.com/adodb

14. Матюхин М.Абстрактный доступ к БД с помощью ADODB: http://detail.phpclub.net/2003-08-19.htm

15. JpGraph – OO Graph Library for PHP: http://www.aditus.nu/jpgraph

16. PHPLOT: http://www.phplot.com

17. GD Graphics Library: http://www.boutell.com/gd

18. http://acidlab.sourceforge.net/acid-0.9.6b23.tar.gz

19. http://phplens.com/lens/dl/adodb394.tgz

20. http://members.chello.se/jpgraph/jpgdownloads/jpgraph-1.13.tar.gz

21. http://ftp1.sourceforge.net/phplot/phplot-4.4.6.tar.gz

22. http://www.boutell.com/gd/http/gd-2.0.15.tar.gz