Сергей Яремчук
На сегодняшний день существует достаточное количество технологий,
позволяющих защитить систему от вторжения извне. На первом рубеже нападающего
встретит 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 из трех компонентов:
n клиента или реализации системы на отдельно
стоящем компьютере – samhain;
n сервера, предназначенного для централизованного
сбора логов и управления клиентами – yule;
n веб-консоли для удаленного управления – 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
e959ccc997e74e13a037c3281c41a581
samhain-1.8.3.tar.gz
Теперь распаковываем архив, заходим внутрь, и
теперь у нас два возможных варианта установки. Первый, более простой,
происходит в графическом режиме, для этого вводим ./Install.sh (должны быть
установлены пакеты dialog или xdialog), в результате чего появляется окно,
изображенное на рис. 1 и 2, и далее будут задаваться вопросы о будущей
конфигурации системы samhain, но в моем случае было получено такое сообщение:
Your
"dialog" does not support --radiolist, GUI installation impossible
Не хотелось ради какого-то ненужного в системе
диалога лезть в Интернет, поэтому воспользовался еще одним подобным
инструментом lxdialog, который идет вместе с исходными текстами ядра и лежит в
/usr/src/linux/scripts/lxdialog. Так как программа конфигурирования, найдя
программу dialog, далее отказывалась работать, пришлось ее временно убрать:
# whereis dialog
dialog:
/usr/bin/dialog /usr/share/man/man1/dialog.1.gz
# mv
/usr/bin/dialog /usr/bin/dialog_bak
После чего удалось настроить систему в
графическом режиме. Если что-то не получается, то в таком случае установку
можно произвести стандартными:
#./configure [options]
#make
#su
#make install
Если выполнить команду
./configure без дополнительных параметров, получим samhain, который
контролирует только локальную систему, без серверно/клиентской архитектуры и
прочих, не всегда нужных наворотов, в таком случае это будет напоминать что-то
вроде Tripwire. Иначе обратим внимание на дополнительные опции, существенно
расширяющие возможности. Для этого вначале даем команду ./configure с ключом
help.
n --enable-login-watch – (по умолчанию – нет)
компиляция с режимом контроля входа в систему и выхода из системы системных
пользователей, используя файлы utmp и wtmp. Для настройки необходимо создать
секцию SuidCheck:
[Utmp]
# включение/выключение проверок
(0 – off, 1 – on)
LoginCheckActive=1
# интервал времени между
проверками в секундах
LoginCheckInterval=600
# серьезность события,
достаточно информационного
SeverityLogin=info
SeverityLogout=info
# а вот если один и тот же
пользователь зарегистрировался многократно, то это событие скорее критическое
SeverityLoginMulti=crit
n --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-файлы
будут выведены примерно такие сообщения:
DEBUG
: [2004-03-21T19:49:44+0200] msg=<Found suid/sgid file>
path=</sbin/unix2_chkpwd>
AA40D4C2B0315251851C50CC3843965A596A64F5E8E2BB48
А если найдутся новые, то
программа начнет нервничать и сообщит администратору о находке.
n --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
# проверка interrupt
descriptor table (по умолчанию TRUE)
KernelCheckIDT=TRUE
# серьезность события
SeverityKernel=crit
n --enable-install-name=samhain|yule – очень
интересная опция, позволяющая дать другое произвольное, не вызывающее
подозрений имя, с которым и скомпилировать программу, при этом оно будет
автоматически заменено во всех скриптах. Это позволит скрыть наличие в системе
этой утилиты. При компиляции samhain в среде клиент|сервер без использования
этой опции имя samhain|yule будет дано автоматически.
n --enable-khide=System.map (только для Linux)
компилирует и устанавливает два модуля ядра: samhain_hide.o и samhain_erase.o.
Модуль samhain_hide.o спрячет файлы, каталоги и процессы с именем, указанным в
опции --enable-install-name=NAME или если такая опция не используется, то по
умолчанию принимается samhain. Второй, samhain_erase.o, предназначен для
скрытия самих модулей.
n --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
n --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-
n --with-trusted=0, UID1, UID2 – список
доверенных пользователей, которым разрешен доступ к файлам, в том числе запись.
По умолчанию UID равен 0, но можно через запятую добавить еще значения (не
забыв про 0). С одной стороны это облегчает работу и повышает защищенность,
т.к. нет необходимости лишний раз прибегать к учетной записи администратора, но
с другой стороны нужно быть осторожным и внимательным, т.к. если дополнительный
доверенный пользователь является членом группы, то к файлам могут получить
доступ и члены группы. Также при использовании этой опции могут возникнуть
приблизительно такие проблемы:
#
/etc/rc.d/samhain start
ERROR
: [2004-03-11T16:50:53+0200] msg=<Owner not trustworthy.>,
subroutine=<trustfile>, path=</etc/samhainrc>, obj=</etc/samhainrc>
---------
sh_unix.c --- 1293 ---------
The
owner (UID = 500) of the path element: /etc/samhainrc
in
the filename: /etc/samhainrc
is
not in the list of trusted users.
To
fix the problem, you can:
-
run ./configure again with the option --with-trusted=0,...,UID
where UID is the UID of the untrusted user, or
-
use the option TrustedUser=UID in the configuration file.
---------
sh_readconf.c --- 213 ---------
The
configuration file: /etc/samhainrc is untrusted, i.e. an
untrusted
user owns or can write to some directory in the path.
Некоторые проблемы решаются просто, вроде этого:
# chown root:root
/etc/samhainrc
Но с другой стороны, при попытке
изменить посторонним одного из этих параметров, вы будете предупреждены.
Дополнительно имеется опция --with-identity=USER, которая указывает на имя
пользователя, которое будет использоваться для понижения привилегий программы
после запуска (по умолчанию nobody).
n --with-prelude – опция, благодаря которой я в
принципе и обратил серьезное внимание на samhain. При ее включении возможно
использование samhain как датчика Open Source Hybrid Intrusion Detection System
Prelude и контролировать еще ряд дополнительных параметров, в том числе и сеть.
Настройка самого Prelude – тема отдельной статьи. Пока достаточно взять с
http://www.prelude-ids.org/rubrique.php3?id_rubrique=6 файл библиотек
libprelude и установить его обычным образом.
n --enable-xml-log – журнал событий, по умолчанию
находящийся в /var/log/samhain_log, будет вестись в формате XML, эта опция
будет обязательной при включении некоторых других опций (базы данных,
например).
n --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 для сообщений клиентов
n --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.
n --enable-stealth=xor_val, где xor_val может
принимать значение от 128 до 255. Еще одна довольно интересная опция,
позволяющая скрыть присутствие samhain в системе. При этом все сообщения в
журнале складываются со значением xor_val, не зная которое, будет труднее
прочитать записанное. Также журнал можно будет подцепить в конец любого
исполняемого файла или рисунка, а конфигурационный файл в режиме стеганографии
в файл Postscript. Правда, в последнем случае можно использовать вариант
--enable-micro-stealth=xor_val, когда конфигурационный файл прятать не надо. Плюс
дополнительно можно использовать опцию --enable-nocl[=ARG], где ARG –
магическое слово, без которого не будет приводиться анализ аргументов командной
строки.
И наконец, сетевые опции:
n --enable-network=[client|server] – эта опция
включает поддержку сети и в соответствии с выбранной установкой будет
скомпилирован клиент или сервер, при этом их необходимо конфигурировать и
компилировать отдельно.
n --with-timeserver=HOST и
--with-alttimeserver=HOST – установка адреса для time-сервера основного и
альтернативного.
n --with-logserver=HOST и
--with-altlogserver=HOST – указание адреса log-сервера основного и
альтернативного.
n --with-libwrap=PATH – компилирование с
поддержкой TCP Wrappers, и контроль доступа к log-серверу при помощи файлов
/etc/hosts.allow и /etc/hosts.deny.
n --enable-udp – включение прослушивания сервером
порта 514 для работы по протоколу UDP для получения информации от
syslog-клиентов.
n --with-port=PORT – изменение номера порта для
протокола TCP/IP (по умолчанию 49777).
На этом обзор основных опций предлагаю закончить
и перейти к практической части, в ходе которой и будут рассмотрены оставшиеся
вопросы. Итак, конфигурируем клиента и сервер, вариант использования samhain на
одной локальной машине будем считать частным упрощенным случаем настройки
клиента. Для начала заводим набор ключей локальных gpg, можно использовать и
имеющиеся, но я решил для работы с samhain создать отдельный комплект.
# /usr/bin/gpg
--gen-key
gpg (GnuPG)
1.2.2; Copyright (C) 2003 Free Software Foundation, Inc.
This program
comes with ABSOLUTELY NO WARRANTY.
This is free
software, and you are welcome to redistribute it
under certain
conditions. See the file COPYING for details.
...
public and secret
key created and signed.
key marked as
ultimately trusted.
pub 1024D/3D8B7333
2004-03-14 Sergej Jaremchuk (samhain key) <grinder@ua.fm>
Key
fingerprint = EA9E 228F 6697 7083 7DD4 1540 FB4A D9A8 3D8B 7333
sub
1024g/A7C5C8BD 2004-03-14
Обратите внимание на строку Key fingerprint,
которая может понадобиться при включении возможности подписи своим ключом
файлов, используемых samhain. Если используются ключи, сгенерированные ранее,
то узнать Key fingerprint можно, введя:
# gpg
--fingerprint Jaremchuk
pub
1024D/3D8B7333 2004-03-14 Sergej Jaremchuk (samhain key) <grinder@ua.fm>
Key
fingerprint = EA9E 228F 6697 7083 7DD4 1540 FB4A D9A8 3D8B 7333
sub
1024g/A7C5C8BD 2004-03-14
И конфигурируем клиента:
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
Во время конфигурирования сервера и клиента
нарвался на такие ошибки:
configure: error:
--with-database: --enable-xml-log required
Сообщает, что для опции --with-database требуется
опция --enable-xml-log, что и добавляем в строку.
checking whether
to use libwrap... checking for libprelude-config... no
configure: error:
Could not find libprelude-config. Did you specify a valid path?
Программа не может найти файл 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 получателя отчетов, хотя при желании можно его задать и в
конфигурационном файле.
В конце конфигурирования программа выводит
приблизительно такой отчет:
samhain has been
configured as follows:
System
binaries: /usr/local/sbin
Configuration
file: REQ_FROM_SERVER/etc/samhainrc
Manual
pages: /usr/local/man
Data: /var/lib/samhain
PID
file: /var/run/samhain.pid
Log
file: /var/log/samhain_log
Base
key: 1352007530,546562103
You need to sign
the config file now
Обратите внимание на строку с 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 обратите
внимание на наличие подобных строк, указывающих на месторасположение и наличие
соответствующих модулей:
cp samhain_hide.o
/lib/modules/2.4.21-99-default/samhain_hide.o
cp
samhain_erase.o /lib/modules/2.4.21-99-default/samhain_erase.o
Программа настоятельно предлагает подписать
конфигурационный файл. Мы с его настройкой разберемся чуть позже, тогда же и
подпишем вручную.
После чего для возможности автоматического
запуска утилиты выполняем:
samhain-1.8.3 #
make install-boot
./samhain-install.sh
--destdir= --express --verbose install-boot
Linux Standard
Base system detected
/usr/bin/ginstall -c -m 700 init/samhain.startLSB /etc/init.d/samhain
/usr/lib/lsb/install_initd /etc/init.d/samhain
installing init
scripts completed
Этот шаг нормально отрабатывался на всех системах
(проверял на Linux – Redhat, Gentoo и SuSE, а также во FreeBSD), и проблемы с
автозагрузкой возникали только из-за неправильной настройки или недоступности
тех или иных файлов. А если у вас не получилось, то возьмите за шаблон один из
предлагаемых вариантов, которые можно найти в подкаталогах init и profiles и
заточите под свою систему.
И теперь, наконец, сам
конфигурационный файл. Называется он /etc/samhainrc (если только не
использовалась опция --enable-install-name или --enable-stealth). Внутри
имеется готовый шаблон, в котором для большинства случаев достаточно
раскомментировать нужные параметры, при этом опции, заданные в строке
конфигурации, можно пропускать, а можно дополнить дополнительными значениями. В
секциях [Attributes], [LogFiles], [GrowingLogFiles], [IgnoreAll], [IgnoreNone],
[ReadOnly], [User0] и [User1] задаются соответствующие политики для указанных
внутри файлов и каталогов. При этом возможно два варианта задания путей:
n file= /full/path/to/the/file – для указания
непосредственно на файл;
n dir= [recursion depth]/full/path/to/the/dir –
для указания на обход каталога, при этом перед путем может ставиться цифра
максимальной глубины рекурсии.
Далее следует секция
[EventSeverity], в которой определена степень серьезности при нарушении
описанных выше событий (в отличие от опциональных пунктов, у которых
серьезность внесена в саму секцию, здесь они собраны отдельным пунктом).
Имеется десять уровней серьезности события:
n none – не обращать внимания, т.е. не
регистрировать;
n debug – отладочное сообщение;
n info – информационное сообщение;
n notice – ничего страшного (нормальное состояние);
n warn – предупреждение;
n mark – временная метка;
n err – ошибка;
n crit – критическое событие;
n alert – завершение программы, например по
причине фатальной ошибки;
n 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 регистрируются следующие классы.
|
Класс
|
Значение
|
|
AUD
|
Системные вызовы
|
|
RUN
|
Нормальное выполнение программы (запуск, остановка)
|
|
STAMP
|
Временная метка
|
|
FIL
|
Сообщения с проверкой целостности файлов
|
|
TCP
|
Сообщения от клиент/серверной подсистемы
|
|
PANIC
|
Фатальные ошибки, приведшие к завершению программы
|
|
ERR
|
Сообщения об ошибках (general)
|
|
ENET
|
Сообщения об ошибках (network)
|
|
EINPUT
|
Сообщения об ошибках ввода (например, конфигурационный
файл)
|
Пока еще поддерживаются старые классы сообщений,
но скорее всего от них нужно потихоньку отвыкать, поэтому и не будем о них
говорить. Также по умолчанию в лог-сервере отключена регистрация клиентских
событий на 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
# timestamp в местном времени или 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]
Хочется отметить, что это далеко не все опции,
только основные, остальное в документации. Также samhain может выполнять
внешние команды, например для дополнительного форматирования сообщения,
от
Eng
Rus