Руководство FreeBSD
Пред. | Глава 17. Аудит событий безопасности | След.

# 17.5. Администрирование системы аудита

## 17.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` завершает запись.

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

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

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

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

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

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

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

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

    # praudit /dev/auditpipe

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

    add path 'auditpipe*' mode 0440 group audit

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

> Внимание: При неосторожном использовании возможно возникновение бесконечных циклов событий. Например, если аудиту подвергаются все операции сетевого ввода-вывода, и команда `praudit` запущена во время SSH-сессии, то любое событие породит вывод сообщения, которое в свою очередь тоже будет событием и так до бесконечности. Разумнее будет не запускать `praudit` на потоке событий из сессии, которая детально журналируется.

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

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

    # audit -n

> Внимание: Если демон auditd не запущен, то эта команда окончится неудачей и будет выведено сообщение об ошибке.

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

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

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

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

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

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

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

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

Пред. | Начало | След.
Настройка системы аудита | Уровень выше | Устройства хранения

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.