ИМЯ

audit.rules - набор правил, загруженных в подсистему аудита ядра

ОПИСАНИE

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

Управление

Команды управления обычно включают в себя настройку системы аудита, а не указание того, что нужно отслеживать. Эти команды обычно включают в себя удаление всех правил, установку размера очереди невыполненных заданий ядра, установку режима сбоя, установку предела частоты событий или команду auditctl - игнорировать синтаксические ошибки в правилах и продолжать загрузку. Как правило, эти правила находятся вверху файла правил.

Файловая система

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

-w путь_к_файлу -p права_доступа -k ключевое_слово

гда права_доступа могут принмать следующие значения:

r: - чтение
w: - запись
x: - исполнение
a: - изменение атрибута

Точки доступа также могут быть созданы с использованием формата системного вызова, описанного ниже, который обеспечивает большую гибкость и возможности. Используя правила системных вызовов, можно использовать параметр path и dir соответственно перед конкретным файлом или каталогом. Также следует отметить, что рекурсивное наблюдение за каталогом будет остановлено, если подкаталогом окажется точка монтирования. Используя правило -q можно сделать монтируемое поддерево эквивалентным просматриваемому каталогу.

Системные вызовы

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

В ядре Linux доступно 4 вида списков или фильтров, как их иногда называют. Это: task, exit, user и exclude.

Список task проверяется только в системных вызовах fork() или clone(). Он редко используется на практике.

Список exit применяется когда необходимо создать событие для аудита, привязанное к точкам выхода из системных вызовов.

Список user используется ядром, чтобы отфильтровать события приходящие из пользовательского пространства. По умолчанию любое событие, происходящее в пространстве пользователя, отслеживается. Если есть какие-то события, которые не нужно отслеживать, то это, то место, где они могут быть удалены. Для просмотра допустимых полей см. auditctl(8).

Фильтр exclude используется, чтобы отфильтровывать ненужные события. Msgtype и ряд атрибутов субъекта могут использоваться для сообщения ядру, какие типы сообщений не нужно записывать. Этот фильтр может удалить событие в целом и не избирателен ни к какому другому атрибуту. Фильтры user и exit лучше подходят для выборочного аудита событий. Поле действие игнорируется для этого фильтра, значение по умолчанию "never" ("никогда").

Правила системных вызовов имеют вид:

-a действие,список -S системный_вызов -F поле=значение -k ключевое_слово

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

always: - всегда создавать событие
never: - никогда не создавать событие

Действие и список разделяются запятой, без пробела. Допустимые списки: task, exit, user и exclude. Их значение было объяснено ранее.

Далее в правиле обычно указывается параметр -S. Значение этого параметра может быть именем или номером системного вызова. Для удобства чтения почти всегда используется имя системного вызова. В правиле можно указать более одного системного вызова, указав еще один параметр -S. При отправке в ядро поля системного вызова помещаются в маску, чтобы одно сравнение могло определить, представляет ли системный вызов интерес. Таким образом, использование нескольких системных вызовов в одном правиле очень эффективно. При указании имени системного вызова auditctl будет искать имя в таблице системных вызовов и преобразовывать его в номер. Это приводит к некоторым проблемам в двухархитектурных системах. Номера системных вызовов на 32- и 64-битных системах не всегда совпадают. Таким образом, чтобы решить эту проблему, как правило, нужно разбить правило на 2, одно из которых указывает -F arch=b32, а другое -F arch=b64. Этот параметр должен быть записан перед параметром -S, чтобы auditctl просматривал правильную таблицу системных вызовов.

После указания системного вызова, в правиле обычно указывают один или несколько параметров -F. Для просмотра всех допустимых полей смотри руководство auditctl(8).

Система аудита считает что идентификатор пользователя - это неотрицательные числа. Система аудита использует число -1, чтобы указать, что логин не установлен. При выводе оно будет отображаться как 4294967295. При написании правила, для поиска всех действительных пользователей системы, нужно заглянуть в файл /etc/login.defs, чтобы увидеть, где начинаются учетные записи пользователей. Например, если UID_MIN равен 500, также необходимо принять во внимание то, что представление без знака числа -1, также больше 500. Эту проблему можно решить с помощью следующего фрагмента правила:

-F auid>=500 -F auid!=4294967295

Оба эти условия должны быть истиной.

Последнее, что нужно знать о правилах системных вызовов, то что к правилу можно добавить ключевое поле, которое представляет собой текстовую строку произвольной формы, добавляемую к событию, чтобы помочь определить его значение. Более подробно это обсуждается в разделе ПРИМЕЧАНИЯ.

ПРИМЕЧАНИЯ

Целью аудита является возможность проводить расследование (периодически или всякий раз, когда происходит инцидент). Несколько простых шагов в планировании могут сделать эту работу проще. Хороший совет - использовать ключевые слова в точках наблюдения и правилах системных вызовов, чтобы придать правилу смысл. Если правила связаны или вместе отвечают определенному требованию, присвойте им общее ключевое слово. Ключевое слово можно использовать во время просмотра журналов, чтобы выбрать только результаты с определенным значением.

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

aureport --start this-week

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

aureport --start this-week --key --summary

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

-a always,exit -F arch=b64 -S open -S openat -F exit=-EPERM -k access

Затем можно изолировать эти ошибки с помощью ausearch и направить результаты в aureport для отображения. Предположим, расследование обнаружило множество событий типа "отказано в доступе". Для того чтобы просмотреть файлы, к которым была предпринята попытка несанкционированного доступа, можно выполнить следующую команду:

ausearch --start this-week -k access --raw | aureport --file --summary

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

ausearch --start this-week -k access --raw | aureport --user --summary

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

ausearch --start this-week -k access -f /path-to/file --raw | aureport --user -i

Этот отчет покажет попытки доступа отдельно для каждого пользователя. Если нужно увидеть конкретное событие аудита, о котором сообщается, необходимо просмотреть значения даты, времени и номера события. Предполагая, что номер события 822 и оно произошло 09/01/2009 в 2:30 команда будет выглядеть следующим образом:

ausearch --start 09/01/2009 02:30 -a 822 -i --just-one

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

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

СООБЩЕНИЯ ОБ ОШИБКАХ

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

Если вы получите следующее предупреждение от auditctl: "32/64 bit syscall mismatch in line XX, you should specify an arch", это означает, что вы указали правило системного вызова в системе с двумя архитектурами, где системный вызов имеет разные номера для 32- и 64-битных интерфейсов. Это означает, что на одном из этих интерфейсов вы, вероятно, проверяете неверный системный вызов. Для решения этой проблемы, перепишите правило как два правила, определяя предполагаемую архитектуру для каждого правила. Например, правило:

-always,exit -S openat -k access

может быть переписано как:

-always,exit -F arch=b32 -S openat -k access
-always,exit -F arch=b64 -S openat -k access

Если вы получите предупреждение: "entry rules deprecated, changing to exit rule", это означает, что у вас есть правило, предназначенное для фильтрации записей, но этот фильтр больше не доступен. Auditctl переместил ваше правило в фильтр exit, чтобы оно не потерялось. Для решения этой проблемы, чтобы больше не получать этого предупреждение, вам нужно изменить нарушающее правило с entry на exit.

ПРИМЕРЫ

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

-a always,exit -F arch=b32 -S open -S openat -F exit=-EACCES -k access
-a always,exit -F arch=b32 -S open -S openat -F exit=-EPERM -k access
-a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -k access
-a always,exit -F arch=b64 -S open -S openat -F exit=-EPERM -k access

СМ. ТАКЖЕ

auditctl(8), auditd(8).

АВТОР

Стив Граб (Steve Grubb)

ПЕРЕВОД

Перевод с английского Elena Mishina <lepata@altlinux.org> 2019

audit.rules(7)

ИМЯ