16.4.1. Формат конфигурационного файла

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

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

Следующий список содержит все классы по умолчанию, присутствующие в файле audit_class:

• all - all - Соответствует всем классам событий.

• ad - administrative - Аудит административных действий, произошедших в системе.

• ap - application - Аудит события, вызванного каким-либо приложением.

• cl - file_close - Аудит вызовов системной функции close.

• ex - exec - Аудит запуска приложения. Аудит аргументов командной строки и переменных окружения контролируется через audit_control(5) используя параметры argv и envv в опции policy.

• fa - file_attr_acc - Аудит доступа к атрибутам объектов и их изменению, например через stat(1), pathconf(2), а также подобных этим событий.

• fc - file_creation - Аудит событий, в результате которых создаются файлы.

• fd - file_deletion - Аудит событий, в результате которых удаляются файлы.

• fm - file_attr_mod - Аудит событий, в результате которых изменяются атрибуты файлов, например, chown(8), chflags(1), flock(2).

• fr - file_read - Аудит событий, в результате которых происходит чтение данных, открываются файлы на чтение и т.п.

• fw - file_write - - Аудит событий, в результате которых происходит запись данных, изменение файлов и так далее.

• io - ioctl - Аудит вызовов системной функции ioctl(2).

• ip - ipc - Аудит различных видов взаимодействия процессов, включая создание не-именованных каналов (pipe) и взаимодействие процессов в стиле System V IPC.

• lo - login_logout - Аудит событий login(1) и logout(1).

• na - non_attrib - Аудит не-приписываемых событий.

• no - no_class - Пустой класс, используется для отключения аудита.

• nt - network - Аудит событий, связанных с сетевыми подключениями, например connect(2) и accept(2).

• ot - other - Аудит событий, не вошедших в другие классы.

• pc - process - Аудит действий процессов, таких как exec(3) и exit(3).

Эти классы событий могут быть настроены изменением конфигурационных файлов audit_class и audit_event.

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

• [пустой префикс] - Аудит проводится как для успешного, так и для ошибочного события. Например, просто указание класса без префикса приведет к занесению события в журнал при любом результате операции.

• + - Аудит только успешных событий.

• - - Аудит только ошибочных событий.

• ^ - Отключение аудита как успешных, так и ошибочных событий.

• ^- - Отключение аудита ошибочных событий.

• ^+ - Включение аудита успешных событий.

Следующий пример выбирает успешные и не-успешные события входа в систему и выхода из нее, и только успешные события исполнения файла:

lo,+ex

16.4.2. Конфигурационные файлы

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

dir:/var/audit
flags:lo
minfree:20
naflags:lo
policy:cnt
filesz:0

dir:/var/audit
flags:lo,ad,-all,^-fa,^-fc,^-cl
minfree:20
naflags:lo

root:lo:no
audit:fc:no

16.5.1. Просмотр журнала аудита

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

Например, утилита praudit выведет все содержимое журнала аудита в текстовом формате:

# praudit /var/audit/AUDITFILE

В данном примере AUDITFILE - журнал, который будет выведен в текстовом формате.

Журнал аудита состоит из серии записей, которые, в свою очередь состоят из элементов. Эти элементы команда praudit выводит последовательно - по одному на строку. Каждый элемент имеет специфический тип, например заголовок (header) содержит заголовок pfgbcb, a путь (path) - путь к файлу, к которому относится запись. lookup. Следующий пример показывает запись для события выполнения (execve):

header,133,10,execve(2),0,Mon Sep 25 15:58:03 2006, + 384 msec
exec arg,finger,doug
path,/usr/bin/finger
attribute,555,root,wheel,90,24918,104944
subject,robert,root,wheel,root,wheel,38439,38032,42086,128.232.9.100
return,success,0
trailer,133

Эта запись является результатом успешного выполнения системного вызова execve, который стал результатом выполнения команды finger doug. Элемент exec содержит и команду, которую оболочка передала ядру, и ее аргументы. Элемент путь (path) содержит путь к исполняемому файлу в представлении ядра. Элемент атрибут (attribute) описывает исполняемый файл, и, в частности, права доступа к файлу. Элемент субъект (subject) описывает процесс, вызвавший выполнение и сохраняет его в виде ряда значений, представляющих собой UID аудируемого пользователя, исполняющие (effective) UID и GID, реальные (real) UID и GID, идентификатор процесса, идентификатор сессии, порт и адрес, с которого был осуществлен вход в систему. Обратите внимание - идентификатор аудируемого пользователя и реальный идентификатор пользователя отличаются: это значит, что пользователь robert повысил привилегии до пользователя root перед выполнением команды, но система аудита занесла его действия в журнал используя изначальный идентификатор. Наконец, элемент возврат (return) описывает успешное завершение операции с кодом завершения 0, а элемент trailer завершает запись.

16.5.2. Фильтрация журналов аудита

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

# auditreduce -u trhodes /var/audit/AUDITFILE | praudit

Эта команда выделит все записи, относящиеся к пользователю trhodes, которые хранятся в файле AUDITFILE.

16.5.3. Делегирование прав просмотра журнала

Члены группы audit имеют доступ на чтение к журналу аудита, находящемуся в /var/audit; по умолчанию эта группа пуста, и только root имеет к ним доступ. Для того, что бы передать пользователю права на чтение журнала, его необходимо добавить в группу audit. Право на чтение журнала аудита позволяет получить множество информации о поведении пользователей и процессов, что может привести к раскрытию конфиденциальных данных. Поэтому, рекомендуется делегировать права на чтение журнала аудита с большой осторожностью.

16.5.4. Мониторинг системы в реальном времени

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

# praudit /dev/auditpipe

По умолчанию, потоки доступны только пользователю root. Чтобы сделать их доступными членам группы audit добавьте правило devfs в файл devfs.rules:

add path 'auditpipe*' mode 0440 group audit

Смотрите страницу справочника devfs.rules(5) для более полной информации о настройке файловой системы devfs.

16.5.5. Ротация журнальных файлов аудита

Журнал аудита пишется только ядром и управляется только демоном аудита auditd. Администраторы не должны пытаться использовать newsyslog.conf(5) или другие инструменты для прямой ротации логов. Вместо этого, для прекращения аудита, реконфигурации и ротации журнальных файлов должна использоваться команда audit. Следующая команда приведет к созданию нового журнального файла и даст команду ядру переключиться на запись в этот файл. Протоколирование в старый файл будет прекращено, а сам файл - переименован. Это рекомендованный способ ротации журнальных файлов.

# audit -n

Добавление следующей строки в файл /etc/crontab приведет к принудительной ротации каждые двенадцать часов через cron(8):

0     */12       *       *       *       root    /usr/sbin/audit -n

Изменения вступят в силу после сохранения файла /etc/crontab.

Автоматическая ротация журнальных файлов возможна при использовании опции filesz в файле audit_control(5), и описан в секции "Формат конфигурационного файла".

16.5.6. Сжатие журнальных файлов

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

#
# Compress audit trail files on close.
#
if [ "$1" = closefile ]; then
    gzip -9 $2
fi

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