Глава 19. Аудит событий безопасности

Этот перевод может быть устаревшим. Для того, чтобы помочь с переводом, пожалуйста, обратитесь к Сервер переводов FreeBSD.

Содержание

19.1. Обзор

Операционная система FreeBSD включает поддержку аудита событий безопасности. Аудит событий обеспечивает надежное, детализированное и настраиваемое журналирование различных системных событий, связанных с безопасностью, включая входы в систему, изменения конфигурации, доступ к файлам и сети. Эти записи журнала могут быть неоценимыми для мониторинга системы в реальном времени, обнаружения вторжений и "посмертного" анализа после краха системы. FreeBSD реализует опубликованный Sun™ программный интерфейс Basic Security Module (BSM) и формат файлов, и также совместима с реализациями аудита Solaris™ и Mac OS® X.

Эта глава посвящена установке и настройке аудита событий. В ней объясняются политики аудита и приводится пример конфигурации аудита.

Прочитав эту главу, вы будете знать:

Что такое аудит событий и как он работает.
Как настроить аудит событий в FreeBSD для пользователей и процессов.
Как просмотреть журнал аудита с использованием инструментов сокращения и просмотра аудита.

Прежде чем читать эту главу, вы должны:

Понимать основы UNIX® и FreeBSD (Основы FreeBSD).
Быть знакомым с основами настройки и компиляции ядра (Настройка ядра FreeBSD).
Иметь некоторое представление о безопасности и о том, как она относится к FreeBSD (Безопасность).

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

Система аудита событий безопасности способна создавать очень подробные журналы активности системы. На загруженной системе данные файлов журналов могут быть очень большими при настройке высокой детализации, в некоторых конфигурациях превышая гигабайты в неделю. Администраторы должны учитывать требования к дисковому пространству, связанные с конфигурациями аудита с высоким объемом данных. Например, может быть целесообразно выделить отдельную файловую систему для /var/audit, чтобы другие файловые системы не пострадали, если файловая система аудита переполнится.

19.2. Ключевые термины

Следующие термины связаны с аудитом событий безопасности:

событие (event): аудируемое событие — это любое событие, которое может быть зарегистрировано с помощью подсистемы аудита. Примерами событий, связанных с безопасностью, являются создание файла, установка сетевого соединения или вход пользователя в систему. События могут быть "приписываемые", то есть их можно отследить до аутентифицированного пользователя, или "неприписываемые". Примерами неприписываемых событий являются любые события, происходящие до аутентификации в процессе входа в систему, например, неудачные попытки ввода пароля.
класс (class): именованный набор связанных событий, используемых в выражениях выбора. Распространённые классы событий включают "создание файла" (fc), "выполнение" (ex) и "вход/выход" (lo).
запись (record): запись в журнале аудита, описывающая событие безопасности. Записи содержат тип события, информацию о субъекте (пользователе), выполняющем действие, данные о дате и времени, информацию об объектах или аргументах, а также указание на успешность или неудачу выполнения.
журнал (trail): файл журнала, состоящий из серии записей аудита, описывающих события безопасности. Записи в журнале расположены в приблизительном хронологическом порядке относительно времени завершения событий. Только авторизованные процессы имеют право добавлять записи в журнал аудита.
выражение выбора (selection expression): строка, содержащая список префиксов и имен классов событий аудита, используемых для сопоставления событий.
предварительный выбор (preselection): процесс, в ходе которого система определяет, какие события представляют интерес для администратора. Конфигурация предварительного отбора использует ряд выражений выбора для определения классов событий, подлежащих аудиту для конкретных пользователей, а также глобальные настройки, применяемые как к авторизованным, так и к неавторизованным процессам.
фильтрация (reduction): процесс выбора записей из существующих журналов аудита для сохранения, печати или анализа. Аналогично, процесс удаления нежелательных записей аудита из журнала. Используя сокращение, администраторы могут реализовать политики сохранения данных аудита. Например, детальные журналы аудита могут храниться в течение одного месяца, но после этого они могут быть сокращены, чтобы сохранить только информацию о входах в систему для архивных целей.

19.3. Настройка аудита

Поддержка аудита событий в пользовательском пространстве устанавливается как часть базовой операционной системы FreeBSD. Поддержка на уровне ядра доступна в ядре GENERIC по умолчанию, и auditd(8) может быть включен добавлением следующей строки в /etc/rc.conf:

auditd_enable="YES"

Затем запустите демон аудита:

# service auditd start

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

options	AUDIT

19.3.1. Выражения выбора событий

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

Классы событий аудита по умолчанию содержит сводку классов событий аудита по умолчанию:

Таблица 1. Классы событий аудита по умолчанию
Имя класса	Описание	Действие
all	all	Совпадает со всеми классами событий.
aa	authentication and authorization
ad	administrative	Административные действия, выполняемые с системой в целом.
ap	application	Определенное приложением действие.
cl	file close	Аудит вызовов системного вызова `close`.
ex	exec	Аудит выполнения программ. Аудит аргументов командной строки и переменных окружения контролируется через audit_control(5) с использованием параметров `argv` и `envv` в настройке `policy`.
fa	file attribute access	Аудит доступа к атрибутам объектов, таким как stat(1) и pathconf(2).
fc	file create	События аудита, в результате которых создается файл.
fd	file delete	Аудит событий, в которых происходит удаление файлов.
fm	file attribute modify	События аудита, связанные с изменением атрибутов файлов, например, с помощью chown(8), chflags(1) и flock(2).
fr	file read	События аудита, в которых данные читаются или файлы открываются для чтения.
fw	file write	События аудита, в которых данные записываются или файлы создаются либо изменяются.
io	ioctl	Контроль использования системного вызова `ioctl`.
ip	ipc	Аудит различных форм межпроцессного взаимодействия, включая POSIX-каналы и операции System V IPC.
lo	login_logout	Audit login(1) и logout(1) события.
na	non attributable	Аудит неприписываемых событий.
no	ошибочный класс	Не соответствует ни одному событию аудита.
nt	network	События аудита, связанные с сетевыми действиями, такими как connect(2) и accept(2).
ot	other	Аудит различных событий.
pc	process	Аудит операций процессов, таких как exec(3) и exit(3).

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

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

Таблица 2. Префиксы для классов событий аудита
Префикс	Действие
+	Аудит успешных событий в этом классе.
-	Аудит неудачных событий в этом классе.
^	Не аудировать ни успешные, ни неудачные события в этом классе.
^+	Не аудировать успешные события в данном классе.
^-	Не аудировать неудачные события в этом классе.

Если префикс отсутствует, будут аудироваться как успешные, так и неудачные экземпляры события.

Следующая строка выбора выбирает как успешные, так и неудачные события входа/выхода, но только успешные события выполнения:

lo,+ex

19.3.2. Файлы конфигурации

В каталоге /etc/security находятся следующие файлы конфигурации для аудита событий безопасности:

audit_class: содержит определения классов аудита.
audit_control: управляет аспектами подсистемы аудита, такими как классы аудита по умолчанию, минимальное свободное место на томе с журналом аудита и максимальный размер журнала аудита.
audit_event: текстовые названия и описания системных событий аудита, а также список классов, к которым относится каждое событие.
audit_user: пользовательские требования аудита, которые объединяются с глобальными настройками по умолчанию при входе в систему.
audit_warn: настраиваемый сценарий оболочки, используемый auditd(8) для генерации предупреждающих сообщений в исключительных ситуациях, например, когда заканчивается место для записей аудита или когда файл журнала аудита был перезаписан.

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

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

19.3.2.1. Файл audit_control

Некоторые параметры подсистемы аудита по умолчанию указаны в файле audit_control:

dir:/var/audit
dist:off
flags:lo,aa
minfree:5
naflags:lo,aa
policy:cnt,argv
filesz:2M
expire-after:10M

Запись dir используется для указания одного или нескольких каталогов, в которых будут храниться журналы аудита. Если указано несколько каталогов, они будут использоваться по очереди по мере заполнения. Обычно настраивают аудит так, чтобы журналы хранились на выделенной файловой системе — это предотвращает конфликты между подсистемой аудита и другими подсистемами при заполнении файловой системы.

Если поле dist установлено в on или yes, жесткие ссылки будут созданы для всех файлов журнала в /var/audit/dist.

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

Запись minfree определяет минимальный процент свободного места в файловой системе, где хранится журнал аудита.

Запись naflags определяет классы аудита для событий без атрибутов, таких как процесс входа/выхода, аутентификация и авторизация.

Запись policy определяет список флагов политики, разделённых запятыми, которые контролируют различные аспекты поведения аудита. Флаг cnt указывает, что система должна продолжать работу, несмотря на сбой аудита (этот флаг настоятельно рекомендуется). Другой флаг, argv, приводит к аудиту аргументов командной строки системного вызова execve(2) как части выполнения команды.

filesz указывает максимальный размер файла аудита перед автоматическим завершением и ротацией файла. Значение 0 отключает автоматическую ротацию логов. Если запрашиваемый размер файла меньше минимального значения в 512k, он будет проигнорирован, и будет сгенерировано сообщение в логе.

Поле expire-after указывает, когда файлы журналов аудита устареют и будут удалены.

19.3.2.2. Файл audit_user

Администратор может указать дополнительные требования аудита для конкретных пользователей в файле audit_user. Каждая строка настраивает аудит для пользователя с помощью двух полей: поле alwaysaudit определяет набор событий, которые всегда должны аудироваться для пользователя, а поле neveraudit определяет набор событий, которые никогда не должны аудироваться для пользователя.

Следующие примеры записей аудита фиксируют события входа/выхода и успешного выполнения команд для пользователя root, а также создание файлов и успешное выполнение команд для пользователя www. Если используется файл audit_control по умолчанию, запись lo для root избыточна, и события входа/выхода также будут фиксироваться для www.

root:lo,+ex:no
www:fc,+ex:no

19.4. Работа с журналами аудита

Поскольку записи аудита хранятся в двоичном формате BSM, для их изменения или преобразования в текстовый формат доступны встроенные инструменты. Для преобразования файлов записей в простой текстовый формат используйте praudit. Для сокращения файла записей аудита с целью анализа, архивирования или печати используйте auditreduce. Эта утилита поддерживает различные параметры выбора, включая тип события, класс события, пользователя, дату или время события, а также путь к файлу или объект, над которым выполнялось действие.

Например, чтобы вывести всё содержимое указанного журнала аудита в виде обычного текста:

# praudit /var/audit/AUDITFILE

Где AUDITFILE — файл журнала аудита для дампа.

Журналы аудита состоят из последовательности записей аудита, сформированных из токенов, которые praudit выводит последовательно, по одному на строку. Каждый токен имеет определённый тип, например, header (заголовок записи аудита) или path (путь к файлу из поиска по имени). Ниже приведён пример события 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 arg содержит обработанную командную строку, переданную оболочкой ядру. Токен path содержит путь к исполняемому файлу, найденный ядром. Токен attribute описывает бинарный файл и включает режим файла. Токен subject хранит аудитный идентификатор пользователя, эффективные идентификаторы пользователя и группы, реальные идентификаторы пользователя и группы, идентификатор процесса, идентификатор сессии, идентификатор порта и адрес входа. Обратите внимание, что аудитный идентификатор пользователя и реальный идентификатор пользователя различаются, так как пользователь robert переключился на учетную запись root перед выполнением этой команды, но аудит ведется с использованием исходного аутентифицированного пользователя. Токен return указывает на успешное выполнение, а trailer завершает запись.

Также поддерживается формат вывода XML, и он может быть выбран добавлением опции -x.

Поскольку журналы аудита могут быть очень большими, можно выбрать подмножество записей с помощью auditreduce. В этом примере выбираются все записи аудита, созданные для пользователя trhodes, хранящиеся в AUDITFILE:

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

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

19.4.1. Мониторинг в реальном времени с использованием потоков аудита

Потоки аудитные (audit pipes) являются клонируемыми псевдоустройствами, которые позволяют приложениям получать доступ к потоку записей аудита в реальном времени. В первую очередь это интересно разработчикам систем обнаружения вторжений и мониторинга. Однако аудитное канальное устройство — это удобный способ для администратора организовать мониторинг в реальном времени без проблем с правами владения файлами аудита или прерывания потока событий из-за ротации логов. Для отслеживания живого потока событий аудита:

# praudit /dev/auditpipe

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

add path 'auditpipe*' mode 0440 group audit

За дополнительной информацией о настройке файловой системы devfs см. devfs.rules(5).

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

19.4.2. Ротация и сжатие файлов журнала аудита

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

# audit -n

Если auditd(8) в данный момент не запущен, эта команда завершится ошибкой и будет выведено сообщение об ошибке.

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

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

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

Автоматическая ротация файла журнала аудита на основе размера файла возможна с использованием filesz в audit_control, как описано в Файл audit_control.

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

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

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

Изменено: 20 октября 2025 г. by Vladlen Popolitov

Главная