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

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

Содержание

16.1. Краткий обзор

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

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

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

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

Перед прочтением этой главы вы должны:

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

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

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

16.2. Ключевые понятия

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

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

16.3. Настройка системы аудита

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

auditd_enable="YES"

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

# service auditd start

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

options	AUDIT

16.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(2).
ip	ipc	Аудит различных видов взаимодействия процессов, включая создание неименованных каналов (POSIX pipe) и взаимодействие процессов в стиле System V IPC.
lo	login_logout	Аудит событий login(1) и logout(1).
na	non attributable	Аудит неприписываемых событий.
no	invalid class	Не соответствует никаким событиям аудита.
nt	network	Аудит событий, связанных с сетевыми подключениями, например connect(2) и accept(2).
ot	other	Аудит различных событий.
pc	process	Аудит действий процессов, таких как exec(3) и exit(3).

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

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

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

Если префикс не указан, то аудиту подлежат как успешные, так и неуспешные события.

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

lo,+ex

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

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

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

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

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

16.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 запрещает автоматическую ротацию логов. Если указанный размер ниже минимального значения 512К, то он будет проигнорирован, и будет сгенерировано предупреждающее сообщение в логах.

Поле expire-after определяет момент времени, при достижении которого журнальные файлы считаются неактуальными и удаляются.

16.3.2.2. Файл audit_user

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

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

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

16.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 описывает ID аудируемого пользователя, исполняющие (effective) UID и GID, реальные ID пользователя и группы, идентификатор процесса, идентификатор сессии, порт и адрес, с которого был осуществлен вход в систему. Обратите внимание: идентификатор аудируемого пользователя и реальный идентификатор пользователя отличаются, так как пользователь robert повысил привилегии до пользователя root перед выполнением команды, но система аудита занесла его действия в журнал используя изначальный идентификатор. Элемент return описывает успешное выполнение операции, а элемент trailer завершает запись.

Указав аргумент -x можно получить вывод в формате XML.

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

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

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

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

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

# praudit /dev/auditpipe

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

add path 'auditpipe*' mode 0440 group audit

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

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

16.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

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

Изменено: 9 марта 2024 г. by Danilo G. Baio

Главная