Централизованное обнаружение вторжения с Samhain

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

Централизованное обнаружение вторжения с Samhain

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

Поэтому добавляют следующий уровень защиты, сетевые системы обнаружения атак – Network Intrusion Detection System (NIDS), которые по известным сигнатурам обнаруживают злонамеренный трафик, но подчас бесполезны против новых неизвестных методов атак. И опять же не защищают от перебора пароля.

Поэтому на следующем шаге применяют уже «индивидуальные» host-based системы, позволяющие обнаружить вторжение, например, производя контроль целостности файловой системы, некоторые реализации вроде Logcentry или Hostcentry позволяют обнаружить вторжение (и даже попытку) методом анализа лог-файлов или, используя технологию Login Anomaly Detection, исследовать подозрительные действия на входе в систему. Плюс для повышения защиты стоит добавить систему защиты от LKM rootkits вроде rkdet (http://vancouver-webpages.com/rkdet).

Используя все эти технологии вместе, дополнительно наложив на ядро патч вроде LIDS (http://www.lids.org), позволяющий контролировать доступ к важным данным, можно надежно запереть как сеть, так и отдельные компьютеры. Но есть одно неудобство. Принцип KISS (Keep It Simple Stupid) хорошо любимый программистами UNIX-систем, когда программа выполняет только одну маленькую функцию, но хорошо, а при необходимости более широких возможностей все необходимое просто склеивается при помощи скриптов, в этом случае только может помешать. Так начинающему админу приходится кроме настройки нескольких необходимых для работы сервисов, ставить и разбираться еще во всех приложениях защиты. Но это хозяйство не только необходимо настроить и запустить, что подчас не так просто, так как большая часть опций настраивается при помощи конфигурационных файлов, без удобного интерфейса, но нужно и поддерживать всегда в самом свежем состоянии, и притом не на одном, а сразу на всех компьютерах в сети. Это только одна из проблем.

Другая состоит в том, что все эти приложения подчас никак не связаны между собой, поэтому выдаваемая ими информация никак не централизована, поступает со всех компьютеров и в большом количестве, обычно в виде e-mail. Я думаю, что это основная причина, мешающая, несмотря на низкую стоимость, активному продвижению UNIX-подобных систем. Не каждый сможет все сразу осилить, и опыт приходит со временем и только с собственными ошибками. Наверное, поэтому в настоящее время становятся все более популярными комплексные решения защиты системы, объединяющие в себе несколько задач, как правило, с возможностью централизованного управления, обновления или хотя бы сбора данных, иногда с графическим интерфейсом или возможностью настройки через веб-интерфейс. Об одном из таких решений и пойдет речь в статье.

Samhain на сайте http://www.la-samhna.de/samhain/index.html назван «open source file integrity and host-based intrusion detection system», т.е. относится к системам, защищающим отдельный хост. Но возможности даже по скромному перечислению просто впечатляют. Главное – это интеграция нескольких составляющих, позволяющая полностью охватить практически все вопросы по защите системы, не распыляя внимание. Для работы достаточно настроить одно-единственное приложение под свои нужды и в дальнейшем при необходимости обновлять только его. Следующая немаловажная деталь, Samhain возможно настроить не только для защиты отдельного хоста, но и заставить работать в клиент-серверной реализации, когда датчики, установленные на удаленных узлах, отсылают всю собранную информацию по зашифрованному каналу на отдельный сервер. При этом все обновления и конфигурационные файлы также могут быть централизованно размещены на сервере и при загрузке забираться оттуда клиентами, что позволяет оперативно вносить изменения в настройки и легко производить обновление. Плюс несомненным преимуществом является возможность добавления своего модуля, о том, как это можно сделать, описано в документации, в частности в HOWTO-write-modules. Состоит система Samhain из трех компонентов:

• клиента или реализации системы на отдельно стоящем компьютере – samhain;
• сервера, предназначенного для централизованного сбора логов и управления клиентами – yule;
• веб-консоли для удаленного управления – beltane.

Поддерживаются несколько вариантов оповещения или отсылки собранной информации, e-mail, в котором используется свой собственный код, реализующий отсылку по протоколу SMTP, почта при этом подписывается во избежание подделки, естественно syslog, при запуске в виде daemon для вывода ошибок используется устройство /dev/console, которое может быть заменено, используя FIFO. Далее для хранения используется отдельный лог-файл, который также подписывается во избежание подделки. Для централизованного сбора информации от нескольких клиентов возможно использование отдельного лог-сервера, который использует протокол TCP и шифрование сообщений, также для хранения информации, собранной от клиентов, возможно использование RDBMS базы данных. На эту роль подходят PostgreSQL, MySQL, имеется поддержка Oracle и unixODBC, но пока полностью на них не протестирована. Дополнительно возможно использование и других внешних программ или выполнение определенных команд.

Samhain был протестирован на Linux, FreeBSD, AIX 4.x, HP-UX 10.20, Unixware 7.1.0, Solaris 2.6, 2.8 и Alpha/True64. Имеются данные об успешной работе на системах под управлением OpenBSD и HP-UX 11 и, возможно, будет работать и под Mac OS X. Также возможен запуск на Windows 2000 в среде Cygwin, который эмулирует POSIX, но Cygwin использует общедоступные области памяти для хранения информации процессов, что не очень хорошо с точки зрения безопасности. Samhain придерживается стандарта Filesystem Hierarchy Standard (FHS), предписывающего рекомендуемое расположение каталогов в UNIX-системах. Для своей работы Samhain использует базу данных сигнатур, которая создается при первом запуске и в дальнейшем сравнивается с живой системой. В такой базе содержится информация о 192-битной контрольной сумме по алгоритму TIGER (возможно использование SHA-1 или MD5), inode, типе файла, владельце и группе, правах доступа, флаги ext2 файловой системы, временных метках, размере, количестве жестких ссылок, minor и major номеров для файлов устройств и для символических ссылок имя файла, на которое она ссылается.

Установка и конфигурация

Рисунок 1

Рисунок 2

Так как Samhain представляет собой довольно продвинутое приложение со множеством возможностей, о которых просто необходимо рассказать, чтобы сложилось наиболее полное представление о продукте, а документация, как мне кажется, не совсем понятна и логична, то построим далее статью так. Вместе с некоторыми опциями конфигурирования будут указаны параметры конфигурационного файла, которые потребуются, чтобы реализовать эти возможности, а ниже будет описан общий конфигурационный файл для клиента и отличающиеся опции для сервера. Samhain распространяется исключительно в виде исходного текста по причинам, которые поймете по ходу изложения материала. Но в документации, поставляемой вместе с архивом, имеются разделы, объясняющие, как создать прекомпилированный пакет для некоторых поддерживаемых систем (в последней версии появился и samhain.ebuild файл для Gentoo). Итак, скачиваем архив samhain-current.tar.gz, распаковываем:

#tar xvzf samhain-current.tar.gz

В текущем подкаталоге образуются два файла samhain-1.8.3.tar.gz.asc и samhain-1.8.3.tar.gz, рекомендуется первоначально проверить подлинность и целостность исходного текста при помощи gpg:

#/usr/bin/gpg --keyserver pgp.mit.edu --recv-key 0F571F6C

#/usr/bin/gpg --verify samhain-1.8.3.tar.gz.asc samhain-1.8.3.tar.gz

Второй вариант состоит в проверке контрольной MD5-суммы, и сравнении ее с той, которая имеется на сайте.

# md5sum samhain-1.8.3.tar.gz

Теперь распаковываем архив, заходим внутрь, и теперь у нас два возможных варианта установки. Первый, более простой, происходит в графическом режиме, для этого вводим ./Install.sh (должны быть установлены пакеты dialog или xdialog), в результате чего появляется окно, изображенное на рис. 1 и 2, и далее будут задаваться вопросы о будущей конфигурации системы samhain, но в моем случае было получено такое сообщение:

# whereis dialog

# mv /usr/bin/dialog /usr/bin/dialog_bak

После чего удалось настроить систему в графическом режиме. Если что-то не получается, то в таком случае установку можно произвести стандартными:

#./configure [options]

#make

#su

#make install

Если выполнить команду ./configure без дополнительных параметров, получим samhain, который контролирует только локальную систему, без серверно/клиентской архитектуры и прочих, не всегда нужных наворотов, в таком случае это будет напоминать что-то вроде Tripwire. Иначе обратим внимание на дополнительные опции, существенно расширяющие возможности. Для этого вначале даем команду ./configure с ключом help.

• --enable-login-watch – (по умолчанию – нет) компиляция с режимом контроля входа в систему и выхода из системы системных пользователей, используя файлы utmp и wtmp. Для настройки необходимо создать секцию SuidCheck:

[Utmp]

# включение/выключение проверок (0 – off, 1 – on)

LoginCheckActive=1

# интервал времени между проверками в секундах

LoginCheckInterval=600

# серьезность события, достаточно информационного

SeverityLogin=info

SeverityLogout=info

# а вот если один и тот же пользователь зарегистрировался многократно, то это событие скорее критическое

SeverityLoginMulti=crit

• --with-suidcheck – (по умолчанию – нет) заставит samhain проверять все SUID/SGID-программы в определяемых пользователем интервалах и сообщать при появлении новых, не внесенных в базу данных. После инициализации базы данных, все SUID/SGID-файлы будут автоматически включены в базу данных. Естественно не работает на nfs, proc, msdos, vfat и iso9660 и других файловых системах с опцией монтирования nosuid, поэтому не стоит включать их в базу данных. Для настройки необходимо создать секцию SuidCheck примерно такого содержания:

[SuidCheck] 

# включение/выключение проверок (0 – off, 1 – on)

SuidCheckActive=1

# интервал между проверками в секундах (по умолчанию – 7200 сек., т.е. 2 часа)

# SuidCheckInterval=86400

# или можно задать время проверки в стиле crontab, например, в 05:30 каждый день, чтобы, придя на работу, получить информацию.

SuidCheckSchedule=30 5 * * *

# серьезность события, естественно, критическая

SeveritySuidCheck=crit

# так можно исключить один каталог из списка проверяемых (например, строка для Solaris)

#SuidCheckExclude=/net/localhost

# так как проверка SUID/SGID – дело накладное, то можно ограничить количество проверяемых файлов в секунду (files per seconds)

SuidCheckFps=250

На все первоначально найденные SUID/SGID-файлы будут выведены примерно такие сообщения:

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

• --with-kcheck – (по умолчанию – нет) проверка системы на наличие kernel rootkit загружаемых при помощи LKM (loadable kernel module). Хочется напомнить, что отказ от поддержки модулей в ядре, не устраняет их модификацию через /dev/kmem. Для GNU/Linux требуется указать место расположение файла System.map (обычно строка выглядит так: --with-check=/boot/System.map), для FreeBSD этого не требуется. Для конфигурирования добавляем секцию Kernel:

[Kernel] 

# включение/выключение проверок (0 – off, 1 – on)

KernelCheckActive=1

# интервал между проверками в секундах (по умолчанию 300)

KernelCheckInterval=20

KernelCheckIDT=TRUE

# серьезность события

SeverityKernel=crit

• --enable-install-name=samhain|yule – очень интересная опция, позволяющая дать другое произвольное, не вызывающее подозрений имя, с которым и скомпилировать программу, при этом оно будет автоматически заменено во всех скриптах. Это позволит скрыть наличие в системе этой утилиты. При компиляции samhain в среде клиент|сервер без использования этой опции имя samhain|yule будет дано автоматически.
• --enable-khide=System.map (только для Linux) компилирует и устанавливает два модуля ядра: samhain_hide.o и samhain_erase.o. Модуль samhain_hide.o спрячет файлы, каталоги и процессы с именем, указанным в опции --enable-install-name=NAME или если такая опция не используется, то по умолчанию принимается samhain. Второй, samhain_erase.o, предназначен для скрытия самих модулей.
• --enable-mounts-check – модуль, написанный Computer Incident Response Team, позволяет контролировать правильность опций монтирования файловых систем. Этот модуль в настоящее время поддерживает Linux, Solaris и FreeBSD. Требует секции Mounts для настройки:

[Mounts]

# включение/выключение проверок (0 – off, 1 – on)

MountCheckActive=1

# интервал между проверками в секундах

MountCheckInterval=7200

# серьезность события, отслеживается правильность монтирования и корректность опции монтирования

SeverityMountMissing=warn

SeverityOptionMissing=warn

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

checkmount=/

checkmount=/var

checkmount=/usr

checkmount=/tmp noexec,nosuid,nodev

checkmount=/home noexec,nosuid,nodev

• --enable-userfiles – еще один модуль от Computer Incident Response Team, позволяющий отслеживать изменения конфигурационных файлов пользователей вроде .profile. За настройку отвечает секция UserFiles:

[UserFiles]

#

UserfilesActive=1

# включение/выключение проверок (0 – off, 1 – on) файлы, проверяемые в каждом $HOME возможно задание следующих уровней,

# отслеживающих определенные изменения, по умолчанию используется

# noignore

# allignore

# attributes

# logfiles

# loggrow

# noignore

# readonly

# user0

# user1

#

UserfilesName=.login noignore

UserfilesName=.profile readonly

UserfilesName=.ssh/authorized_keys

#

# возможно задание списка проверяемых UID, по умолчанию проверяются все пользователи

UserfilesCheckUids=0,100-500,1000-

• --with-trusted=0, UID1, UID2 – список доверенных пользователей, которым разрешен доступ к файлам, в том числе запись. По умолчанию UID равен 0, но можно через запятую добавить еще значения (не забыв про 0). С одной стороны это облегчает работу и повышает защищенность, т.к. нет необходимости лишний раз прибегать к учетной записи администратора, но с другой стороны нужно быть осторожным и внимательным, т.к. если дополнительный доверенный пользователь является членом группы, то к файлам могут получить доступ и члены группы. Также при использовании этой опции могут возникнуть приблизительно такие проблемы:

# /etc/rc.d/samhain start

Некоторые проблемы решаются просто, вроде этого:

 # chown root:root /etc/samhainrc

Но с другой стороны, при попытке изменить посторонним одного из этих параметров, вы будете предупреждены. Дополнительно имеется опция --with-identity=USER, которая указывает на имя пользователя, которое будет использоваться для понижения привилегий программы после запуска (по умолчанию nobody).

• --with-prelude – опция, благодаря которой я в принципе и обратил серьезное внимание на samhain. При ее включении возможно использование samhain как датчика Open Source Hybrid Intrusion Detection System Prelude и контролировать еще ряд дополнительных параметров, в том числе и сеть. Настройка самого Prelude – тема отдельной статьи. Пока достаточно взять с http://www.prelude-ids.org/rubrique.php3?id_rubrique=6 файл библиотек libprelude и установить его обычным образом.
• --enable-xml-log – журнал событий, по умолчанию находящийся в /var/log/samhain_log, будет вестись в формате XML, эта опция будет обязательной при включении некоторых других опций (базы данных, например).
• --with-database=[mysql|postgresql|oracle|odbc] – включение поддержки выбранной базы данных, в которую затем будут заноситься данные (требует --with-xml-log, PostgreSQL не любит опцию --enable-static). По умолчанию сервер базы данных размещается на localhost, база данных называется samhain, содержит таблицу «log», доступ к которой осуществляется без пароля. Для автоматического создания соответствующей базы данных и таблицы в комплекте имеются скрипты «samhain.mysql.init», «samhain.postgres.init» и «samhain.oracle.init».

Для PostgreSQL установка будет выглядеть так:

# su postgres

$ createdb samhain

$ createuser samhain

$ psql -d samhain < samhain.postgres.init

$ exit

Для MySQL тоже не сложно:

#mysql -p -u root < samhain.mysql.init

#mysql -p -u root

#mysqladmin -p -u root reload

При использовании базы данных необходимо добавить в секцию Log:

[Log]

DatabaseSeverity=warn

И создать секцию Database, изменив поля, значение которых очевидно:

[Database]

SetDBName=db_name

SetDBTable=db_table

SetDBHost=db_host

SetDBUser=db_user

SetDBPassword=db_password

SetDBServerTstamp=true/false – timestamp для сообщений клиентов

• --with-gpg=/full/path/to/gpg – samhain использует GnuGP для подписи файла конфигурации и базы данных сигнатур, выдавая контрольную сумму. При этом ее всегда можно сверить, запустив:

gpg -a --clearsign --not-dash-escaped FILE

Но использовав опцию --with-gpg, можно возложить часть работы на samhain. При этом программа конфигурации проверит, чтобы доверенные пользователи имели доступ к gpg, а gpg будет вызываться без использования переменных оболочки по полному пути, указанному при компиляции, со средой ограниченной переменной $HOME, используя файл $HOME/.gnupg. Для облегчения работы с подписью и проверкой файлов имеется Perl-скрипт samhainadmin.pl, который первоначально придется заточить под свою систему.

При помощи опции --with-checksum=CHECKSUM можно вбить в программу контрольную сумму бинарника gpg, которая будет проверяться каждый раз при обращении к нему, что позволит контролировать оригинальность gpg (можно и отказаться, использовав --with-checksum=no).

Контрольную сумму можно узнать, использовав такую команду:

#/usr/bin/gpg --load-extension tiger --print-md TIGER192 /usr/bin/gpg

И теперь в строке конфигурирования:

--with-checksum="/usr/bin/gpg: 1C739B6A F768C949 FABEF313 5F0B37F5 22ED4A27 60D59664"

Но это еще не все, простой факт, что сигнатура является правильной, не доказывает, что это было подписано именно вами и вашим ключом – только доказывает, что это было подписано кем-то. Для того чтобы Samhain мог проверить, что именно ваш ключ использовался, необходимо добавить опцию --with-fingerprint=FINGERPRINT.

И наконец, сетевые опции:

• --enable-network=[client|server] – эта опция включает поддержку сети и в соответствии с выбранной установкой будет скомпилирован клиент или сервер, при этом их необходимо конфигурировать и компилировать отдельно.
• --with-timeserver=HOST и --with-alttimeserver=HOST – установка адреса для time-сервера основного и альтернативного.
• --with-logserver=HOST     и --with-altlogserver=HOST – указание адреса log-сервера основного и альтернативного.
• --with-libwrap=PATH – компилирование с поддержкой TCP Wrappers, и контроль доступа к log-серверу при помощи файлов /etc/hosts.allow и /etc/hosts.deny.
• --enable-udp – включение прослушивания сервером порта 514 для работы по протоколу UDP для получения информации от syslog-клиентов.
• --with-port=PORT – изменение номера порта для протокола TCP/IP (по умолчанию 49777).

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

# /usr/bin/gpg --gen-key

Обратите внимание на строку Key fingerprint, которая может понадобиться при включении возможности подписи своим ключом файлов, используемых samhain. Если используются ключи, сгенерированные ранее, то узнать Key fingerprint можно, введя:

# gpg --fingerprint Jaremchuk

И конфигурируем клиента:

samhain-1.8.3 # ./configure --with-gpg=/usr/bin/gpg

--with-fp=EA9E228F669770837DD41540FB4AD9A83D8B7333

--enable-login-watch --enable-mounts-check --enable-userfiles --enable-static --enable-network=client --enable-suidcheck

--with-trusted=0,500 --with-recipient=sergej@ logserver.com --enable-xml-log  --with-logserver=logserver.com 

    --with-config-file=REQ_FROM_SERVER/etc/samhainrc --with-kcheck=/boot/ System.map

Во время конфигурирования сервера и клиента нарвался на такие ошибки:

Сообщает, что для опции --with-database требуется опция --enable-xml-log, что и добавляем в строку.

Программа не может найти файл libprelude-config, входящий в библиотеку Prelude IDS. У меня он находился в каталоге /usr/local/bin, который не был виден в переменной РАТН, лечится выполнением следующей команды (в bash):

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

Встретились незнакомые опции: --enable-static – для статической компиляции, является рекомендуемой с точки зрения безопасности. Строка --with-config-file= REQ_ FROM_SERVER/etc/samhainrc указывает, что конфигурационный файл следует брать с сервера, где он называется /etc/samhainrc, опция --with-recipient позволяет железно вшить в бинарник e-mail получателя отчетов, хотя при желании можно его задать и в конфигурационном файле.

В конце конфигурирования программа выводит приблизительно такой отчет:

Обратите внимание на строку с Base key. Это еще один механизм защиты, при котором во всех e-mail сообщениях и логах будут использованы эти два числа, и если на приеме программа обнаружит несоответствие Base key, то такое сообщение будет признано ложным. При каждом конфигурировании она будет разной, можно задать ее самому при помощи опции --enable-base=B1,B2, где B1,B2 целые числа в диапазоне 0...2147483647. Естественно, если используются прекомпилированные пакеты, то эти числа будут для всех одинаковы и, вычислив путем декомпиляции программы их значение, злоумышленник может подделывать сообщения (хотя согласитесь, что для этого нужна и соответствующая подготовка, что не каждый может себе позволить). Во избежание проблем в этом случае разработчики настоятельно рекомендуют добавить ключ к каждому установленному файлу, выполнив:

samhain --add-key=key@/usr/local/sbin/samhain

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

samhain-1.8.3 # make

samhain-1.8.3 # make install

При компиляции с опцией --enable-khide обратите внимание на наличие подобных строк, указывающих на месторасположение и наличие соответствующих модулей:

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

После чего для возможности автоматического запуска утилиты выполняем:

Этот шаг нормально отрабатывался на всех системах (проверял на Linux – Redhat, Gentoo и SuSE, а также во FreeBSD), и проблемы с автозагрузкой возникали только из-за неправильной настройки или недоступности тех или иных файлов. А если у вас не получилось, то возьмите за шаблон один из предлагаемых вариантов, которые можно найти в подкаталогах init и profiles и заточите под свою систему.

И теперь, наконец, сам конфигурационный файл. Называется он /etc/samhainrc (если только не использовалась опция --enable-install-name или --enable-stealth). Внутри имеется готовый шаблон, в котором для большинства случаев достаточно раскомментировать нужные параметры, при этом опции, заданные в строке конфигурации, можно пропускать, а можно дополнить дополнительными значениями. В секциях [Attributes], [LogFiles], [GrowingLogFiles], [IgnoreAll], [IgnoreNone], [ReadOnly], [User0] и [User1] задаются соответствующие политики для указанных внутри файлов и каталогов. При этом возможно два варианта задания путей:

• file= /full/path/to/the/file – для указания непосредственно на файл;
• dir= [recursion depth]/full/path/to/the/dir – для указания на обход каталога, при этом перед путем может ставиться цифра максимальной глубины рекурсии.

Далее следует секция [EventSeverity], в которой определена степень серьезности при нарушении описанных выше событий (в отличие от опциональных пунктов, у которых серьезность внесена в саму секцию, здесь они собраны отдельным пунктом). Имеется десять уровней серьезности события:

• none – не обращать внимания, т.е. не регистрировать;
• debug – отладочное сообщение;
• info – информационное сообщение;
• notice – ничего страшного (нормальное состояние);
• warn – предупреждение;
• mark – временная метка;
• err – ошибка;
• crit – критическое событие;
• alert – завершение программы, например по причине фатальной ошибки;
• inet – входящий от клиента.

Однако, поскольку важность события – вопрос вкуса, некоторые имеют строгое обращение. При этом mark, alert, inet относятся к предустановленным событиям, остальные уровни можно определять самим для конкретного случая. Итак, пример.

 [Attributes]

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

file=/etc/mtab

file=/etc/ssh_random_seed

file=/etc/asound.conf

file=/etc/resolv.conf

file=/etc/localtime

file=/etc/ioctl.save

file=/etc

[LogFiles]

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

file=/var/run/utmp

file=/etc/motd

[GrowingLogFiles]

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

file=/var/log/warn

file=/var/log/messages

file=/var/log/wtmp

file=/var/log/faillog

[IgnoreAll]

# все изменения в этих файлах не попадут в отчет, но они все  же проверяться будут, сюда можно поместить не нуждающиеся

# в проверке файлы при рекурсивном обходе каталога

file=/etc/resolv.conf.pcmcia.save

[IgnoreNone]

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

# вроде /etc/passwd.bak и отслеживать попытку обращения к нему

[ReadOnly]

# для этих файлов игнорируется время доступа

dir=/usr/bin

dir=/bin

dir=3/sbin

dir=/usr/sbin

dir=/lib

dir=3/etc

dir=/boot

И две секции [User0] и [User1], в которых по умолчанию отслеживаются и попадают в отчет все модификации. Но для каждой секции возможно переопределение по умолчанию выставленных параметров. Это особенно удобно при использовании секций [User0] и [User1], что позволяет создать конфигурацию действительно на все случаи жизни. Для этого в секции [Misc] создаются параметры, соответствующие имени изменяемого поля с префиксом Redef, вроде RedefReadOnly, RedefAttributes, RedefUser0 и указанием параметра со знаком плюс (для добавления), минус (для отмены контроля) и без знака для установки. Параметры могут быть такие: CHK (checksum), LNK (link), HLN (hardlink), INO (inode), USR (user), GRP (group), MTM (mtime), ATM (atime), CTM (ctime), SIZ (size), RDEV (device numbers) и MOD (file mode).

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

@HOSTNAME

file=/path/to/file

@end

Или обратной конструкции, т.е. для всех, кроме:

!@ HOSTNAME

file=/path/to/file

@end

Или для некоторых систем (uname -srm):

$sysname:release:machine                                  

# чтение, только если sysname:release:machine соответствует локальному компьютеру   

$end

!$sysname:release:machine                                 

# наоборот   

$end

При этом HOSTNAME должно быть полное доменное имя вроде server.com без всяких псевдонимов и IP-адресов. Теперь такая ситуация: некоторые файлы вы хотите проверять, допустим, раз в час, а всю систему только раз в день. Такая ситуация также предусмотрена. Для этого используется конструкция:

%SCHEDULE_TWO

  dir=/check/only/once/per/day

!%SCHEDULE_TWO

и в разделе Misc прописываем crontab-подобное задание вроде:

FileCheckScheduleTwo=00 * * * *

Теперь пример секции EventSeverity.

[EventSeverity]

# ниже указаны уровни нарушения соответствующих политик

SeverityReadOnly=crit

SeverityLogFiles=crit

SeverityGrowingLogs=crit

SeverityIgnoreNone=crit

SeverityAttributes=crit

#

SeverityIgnoreAll=info

# ошибки доступа к файлам и каталогам

SeverityFiles=err   

SeverityDirs=err 

# непонятные имена файлов или недопустимый UIDS/GIDS, который не принадлежит ни одному пользователю или группе

SeverityNames=info 

И наконец, еще два обязательных раздела: Log – описывающий систему регистрации событий и Misc – общие установки. По умолчанию большая часть регистраторов событий отключена, и поэтому нужно внимательно просмотреть эту секцию и выбрать необходимое. Здесь еще важно пару слов добавить о классах сообщений. Серьезность события ранжирует сообщения по их важности, классы относятся к категориям сообщений, призванным уменьшить вывод, например, рассматривая сообщения в некотором контексте (запуск от cron при котором сообщения запуска и остановки могут быть лишними). Сообщения будут регистрироваться, только если их серьезность соответствует заявленной, и класс сообщения имеется в списке. При этом по умолчанию регистрируются все классы, и параметр none отключает регистрацию.

С версии 1.8.2 регистрируются следующие классы.

 Пока еще поддерживаются старые классы сообщений, но скорее всего от них нужно потихоньку отвыкать, поэтому и не будем о них говорить. Также по умолчанию в лог-сервере отключена регистрация клиентских событий на syslog и e-mail, которая, впрочем, там совсем и не к чему. Но если это все-таки необходимо, то для возможности включения в секции [Misc] пропишите параметр UseClient Severity=yes. Возможно использование спецификаторов «*», «!» и «=», которые означают соответственно «все», «все кроме» и «только», а также инструкции LogCalls с указанием системных выводов, которые необходимо регистрировать (только для консоли и syslog): execve, utime, unlink, dup (+ dup2), chdir, open, kill, exit (+ _exit), fork, setuid, setgid, pipe.

[Log]

# пример использования спецификаторов

# MailSeverity=*

# MailSeverity=!warn

# MailSeverity==crit

# пороги для каждого регистрирующего устройства

MailSeverity=none

PrintSeverity= info

LogSeverity= err

LogClass=RUN FIL STAMP

SyslogSeverity=none

ExportSeverity=warn

PreludeSeverity=none

DatabaseSeverity=err

# системные вызовы

LogCalls=open, kill, setuid, setgid

[Misc]

# старт в виде процесса-daemonа

Daemon=yes

# максимальное время между сообщениями клиентов в секундах  (только для log-server; по умолчанию 86400 сек. = 1 день)

# SetClientTimeLimit=1800

# время между проверками файлов в секундах (600)

#SetFilecheckTime=1000

#или проверка в стиле  crontab

#FileCheckScheduleOne=00 * * * *

# для файлов раздела SCHEDULE_TWO

#FileCheckScheduleTwo=00 * * * * 

# максимальное время между отправками почты, все сообщения кроме аварийных при этом будут накапливаться (86 400 сек.)

#SetMailTime=43200

# максимальная задержка во внутренней очереди от 0 до 127 (по умолчанию 10)

#SetMailNum=10

# установка адреса получателя, позволяется до 8 адресов  до 63 символов. 

SetMailAddress=root@localhost

# host для отправки почты по умолчанию локальный – none

# SetMailRelay=relay.yourdomain.com или IP-адрес

# Для проверки модификаций между запуском программы и выходом.

# SamhainPath=/usr/local/bin/samhain

# time-сервер (порт 37/tcp)

# SetTimeServer=localhost

# log-сервер

# SetLogServer=localhost

# в местном времени или GMT

UseLocalTime=yes

# интервал между сообщениями timestamps, которые будут вставлены в сообщения в таком виде

# MARK : [2004-03-21T19:49:45+0200] msg=<-- TIMESTAMP -->

# 77B71CEA79D01107AE9FAA66233A059D0FDC3B33FBA74700

# SetLoopTime=60

# сюда можно добавить доверенных пользователей, не включенных при компиляции (root и пользователь, от имени которого

# выполняется программа, всегда доверенные)

# TrustedUser=bin

# чем занимаемся: инициализацией базы данных, обновлением или проверкой файлов, если none (режим по умолчанию),

# то команда задается в строке запуска. init|update|check|none

ChecksumTest=check

# установка глобального значения рекурсии (максимум 99, по умолчанию - 0)

SetRecursionLevel=20

# приоритет процесса проверки файлов

#SetNiceLevel=-19..19

# все клиентские сообщения по умолчанию записываются в один log. Опция позволяет использовать индивидуальные журналы

#UseSeparateLogs=yes/no

# возможно переопределение консоли, в том числе и использование pipe-каналов.

#SetConsole=device

# использование соответствующих алгоритмов для вычисления значения контрольных сумм файлов, вместо TIGER

# (используйте один и тот же тип сигнатуры на сервере и клиентах)

#DigestAlgo=MD5

#DigestAlgo=SHA1

# упрощенная сигнатура, может понадобиться для повышения быстродействия, подробнее в разделе "Performance tuning"

#MACType=HASH-TIGER

# начиная с версии 1.7.0, yule может после запуска переходить в chroot (подробнее в документации)

#SetChrootDir=path

# опция, необходимая для включения прослушивания UDP-порта log-сервером (при компилировании с опцией --enable-udp)

SetUDPActive=yes

# если в вашем выводе много сообщений об изменении CTIME, что может происходить при использовании некоторых систем

# резервирования, то может помочь нижняя опция, отключающая эту проверку

#RedefReadOnly=-CTM

# формат заголовка сообщения

# %S серьезность

# %T timestamp

# %C class

# %F исходный файл

# %L исходная строка

# MessageHeader="%S %T "

 [EOF]

#  gpg -a --clearsign --not-dash-escaped /etc/samhainrc

После чего в текущем каталоге появится файл с префиксом .asc, т.е. samhainrc.asc. Для работы переименовываем его:

# mv -f /etc/samhainrc.asc  /etc/samhainrc

Проверить подпись можно в любое время командой:

# cat /etc/samhainrc | gpg --status-fd 1 --verify --homedir /root/.gnupg --no-tty

Теперь, когда все готово, можно приступать к созданию базы данных:

# /usr/local/sbin/samhain -t init

В результате в каталоге /usr/local/var/lib/samhain/ появится файл samhain_file, который содержит все сигнатуры на момент инициализации, с которыми и будут сравниваться в дальнейшем параметры. Во избежание модификации ее также рекомендуется подписать, схема аналогична предыдущей:

# gpg -a --clearsign --not-dash-escaped /var/lib/samhain/samhain_file

# mv /var/lib/samhain/samhain_file.asc /var/lib/samhain/samhain_file

Проверить соответствие можно командой:

samhain -t check

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

samhain -t update

Но наибольшее преимущество достигается при запуске этой утилиты в качестве демона, тогда программа запоминает все изменения и не будет раздражать повторяющимися сообщениями. К тому же только тогда будут в полной мере задействованы все дополнительные возможности в виде проверок на kernel rootkits и пр. Запустить можно тремя способами: при установке Daemon=yes секции Misc и запуска без параметров, программа все остальное, необходимое для работы, возьмет из конфигурационного файла; аналогично программа себя поведет при запуске при помощи стартовых скриптов, расположенных в /etc, например /etc/rc.d/samhain start, и наконец указав, чем ей заниматься в строке запуска:

samhain -D -t check

где -D указывает на запуск в виде процесса-демона.

Но для нормальной работы в среде клиент-сервер для начала придется установить и настроить сервер yule, иначе клиенты будут ругаться при запуске о том, что не могут найти конфигурационный файл и будут пользоваться локальным.

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

samhain-1.8.3 # ./configure --with-gpg=/usr/bin/gpg

--with-fp=EA9E228F669770837DD41540FB4AD9A83D8B7333

--enable-static  --enable-network=server  --with-database=mysql --with-trusted=0,500

--with-libwrap=/usr/lib/libwrap.a

Чтобы узнать местонахождение библиотеки libwrap, используем следующую команду:

# whereis libwrap

И еще небольшое примечание, возможно использование единой базы для всех клиентов. Для ее активации требуется использование примерно такой опции:

--with-data-file=REQ_FROM_SERVER/var/lib/samhain/data.samhain

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

После конфигурирования получаем отчет об установках.

Компилируем и устанавливаем:

samhain-1.8.3 # make

samhain-1.8.3 # make install

samhain-1.8.3 # make install-boot

Конфигурационный файл сервера yule называется /etc/yulerc, его структура похожа на samhainrc, за исключением отсутствия секций проверок (остались Misc, Database, Log и External) и добавления секции Clients. Первые секции полностью рассмотрены раннее и хотя есть незначительные отличия (например, TrustedUser не имеет пользователя по умолчанию), но останавливаться на них не будем. Разберем раздел Clients. Вы не ошибетесь, если подумаете, что в ней описана регистрация клиентов. Каждый клиент в файле описан строкой: Client=HOSTNAME_ CLIENT1@salt@verifier.

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

• выбрать пароль в 16 символов (только знаки 0-9, a-f, A-F). Для автоматического генерирования случайных паролей используйте опцию --gen-password (или -G).

# /usr/local/sbin/yule –G 

• на клиенте при помощи samhain_setpwd установите новый пароль (без параметров утилиты выдаст используемые опции).

# ./samhain_setpwd samhain new  477631269C2CC74B

Получившийся файл samhain.new переименовываем в samhain:

 # cp /usr/local/sbin/samhain.new /usr/local/sbin/samhain

Впрочем, эту операцию можно проделывать и на сервере, копируя затем файлы samhain.new на клиентские компьютеры при помощи, например, ssh.

• на сервере создаем комбинацию для регистрации клиента:

#  /usr/local/sbin/yule -P 477631269C2CC74B 

Заменяем HOSTNAME на полное доменное имя клиента вида client.mydomain.com и заносим эту строку в секцию Clients.

• Повторяем эту процедуру для каждого клиента.

После запуска сервера и клиентов последние начинают устанавливать соединение с сервером. Проблемы при работе возникали в основном из-за неправильной настройки сети, служба DNS не могла определить имя (лучше прописать в /etc/hosts, в документации показано, как правильно это сделать), при компиляции с поддержкой libwrap не прописал клиентов в файле /etc/hosts.allow. В последней версии появился документ, описывающий основные проблемы, возникающие при взаимодействии клиентов и сервера и пути их решения – HOWTO-client+server-troubleshooting.html. Советую ознакомиться.

И в завершение приведу примеры сообщений, выдаваемых Samhain, которые в особенном комментарии не нуждаются.

Пояснения, наверное, требуют разве что конструкции вида <POLICY [ReadOnly] C--I----TS>. Все просто, здесь указана действующая политика и параметры, которые изменились со времени последней проверки. Их расшифровка такая:

• «C» – контрольная сумма,
• «L» – мягкие ссылки,
• «D» – номер устройства (device number),
• «I» – inode,
• «H» – количество жестких ссылок «hardlinks»,
• «M» – режим «mode»,
• «U» – владелец «user»,
• «G» – группа «group»,
• «T» – время «time» (любое),
• «S» – указывает на изменившийся размер «size» файла.

Распаковываем, конфигурируем и в конце проверяем правильность установок.

После чего, используя опции команды configure, поправляем. В зависимости от того как используется PHP, как программа CGI или модуль apache, Beltane должен быть сконфигурирован с различными параметрами для сценария ./configure.

Основными опциями являются:

• --with-php-dir=DIR,
• --with-php-extension=EXT,
• --enable-mod-php,
• --with-user=USERNAME.

В результате в корневом каталоге веб-сервера должен появиться подкаталог (по умолчанию php), содержащий рабочие файлы. И теперь, введя в строке браузера путь к этим данным, можно управлять информацией и настройками. По умолчанию используется логин/пароль rainer/wichmann (рис. 3), его необходимо обязательно изменить через веб-интерфейс или воспользовавшись утилитой makepasswd.pl.

Рисунок 3

Мы не рассмотрели еще много вопросов, например, развертывание удаленных конфигураций, позволяющих в полуавтоматическом режиме развернуть систему для большого числа компьютеров, включая сервер. Подробно этот процесс описан в разделе «Deployment to remote hosts». Не сказано совсем ничего про установку и настройку под Windows NT/2000/XP, применение стеганографии. Но описанного в статье достаточно для базовой установки и настройки, а главное для понимания возможностей. При необходимости оставшиеся вопросы будут освещены в следующий раз.

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