Применимо к редакции: МСВСфера 9 (ФСТЭК)

6. РЕГИСТРАЦИЯ СОБЫТИЙ БЕЗОПАСНОСТИ

6.1. Введение

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

Ниже приведены некоторые сценарии использования подсистемы аудита.

  • Регистрация событий входа в систему

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

  • Отслеживание доступа к файлам

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

  • Мониторинг системных вызовов

    С помощью подсистемы аудита можно отслеживать использование отдельных системных вызовов (man 2 syscalls), например, операции монтирования файловых систем, изменение системного времени, открытие сетевого соединения и т.п..

  • Отслеживание событий безопасности средства виртуализации

    Позволяет отслеживать различные действия пользователей с ресурсами, управляемыми гипервизором libvirt.

  • Регистрация событий установки или удаления ПО

    С помощью подсистемы аудита можно отслеживать установку, удаление или обновление пакетов с использованием различных пакетных менеджеров: dnf/yum, pip, npm, cpan, gem и т.д..

Рассмотрим основные компоненты и архитектуру подсистемы аудита подробнее.

Основные компоненты и архитектура подсистемы аудита

Основные компоненты и архитектура подсистемы аудита

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

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

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

  4. После записи события в буфер kauditd осуществляется возврат управления в обработчик системного вызова.

  5. Из обработчика системного вызова осуществляется возврат управления в программу.

  6. Из буфера событие попадает на обработку в компонент kauditd.

  7. Компонент kauditd передаёт информацию о событии из пространства ядра в сервис auditd, работающий в пользовательском пространстве, с помощью стандартного механизма коммуникации netlink (man 7 netlink).

  8. Сервис auditd регистрирует событие безопасности в файле системного журнала (по умолчанию в /var/log/audit/audit.log).

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

  • Сервис auditd может передать информацию о событии безопасности на обработку в другие сервисы/программы с помощью расширений (плагинов). Получателями такой информации могут быть системы централизованного сбора и анализа системных журналов, системы мониторинга, накладные средства защиты информации (СЗИ) и т.п..

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

6.2. Настройка сервиса auditd

6.2.1. Конфигурационный файл /etc/audit/auditd.conf

Настройка сервиса auditd осуществляется через конфигурационный файл /etc/audit/auditd.conf, использующий стандартный для Unix-подобных систем формат КЛЮЧ = ЗНАЧЕНИЕ. Все ключи и значения являются регистронезависимыми.

В таблице ниже приведено описание допустимых параметров и их значения по умолчанию.

Таблица 16 - Параметры сервиса auditd и их значения по умолчанию

Параметр

Значение по умолчанию

Описание

local_events

yes

Включает (yes) или выключает (no) регистрацию событий безопасности локальной системы. Если необходимо только регистрировать события, полученные по сети, установите в значение no. Обычно это используется при развёртывании auditd в контейнере для централизованного сбора информации с нескольких систем.

log_file

/var/log/audit/audit.log

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

write_logs

yes

Включает (yes) или выключает (no) запись журналов безопасности на диск.

log_format

ENRICHED

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

log_group

root

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

priority_boost

4

Неотрицательное число, определяющее приоритет выполнения службы аудита. Чтобы оставить приоритет без изменений, используйте значение 0.

krb5_principal

auditd

Имя Kerberos-принципала сервера auditd. При использовании значения по умолчанию сервер auditd будет искать ключ с именем auditd/HOSTNAME@REALM в файле, заданном директивой krb5_key_file, где HOSTNAME — это каноническое имя сервера, возвращаемое службой DNS по его IP-адресу, а REALM — область (realm) Kerberos.

freq

50

Неотрицательное число, которое определяет сколько событий необходимо записать прежде чем выполнить принудительную синхронизацию данных на диск. Этот параметр применяется только если значение flush установлено в INCREMENTAL или INCREMENTAL_ASYNC.

name_format

NONE

Определяет как имена компьютеров вставляются в поток событий безопасности. Допустимые значения параметра перечислены после таблицы.

name

Не задано

Строка, определяемая системным администратором, для использования в качестве имени системы если параметр name_format установлен в значение USER.

max_log_file

8

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

max_log_file_ac­tion

ROTATE

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

verify_email

yes

Если установлен в yes, то для доменного имени, указанного в почтовом адресе в директиве action_mail_acct, будет выполнена проверка на наличие соответствующей DNS-записи. Этот параметр должен быть расположен перед опцией action_mail_acct в конфигурационном файле, иначе будет использовано значение по умолчанию yes.

flush

INCREMENTAL_ASYNC

Определяет стратегию работы с дисковым буфером. Допустимые значения параметра перечислены после таблицы.

q_depth

2000

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

num_logs

5

Определяет максимальное количество файлов журналов, которые необходимо сохранять, если параметр max_log_file_action установлен в значение ROTATE. Если значение num_logs меньше 2, то ротация файлов журналов не будет производиться. В качестве значения допустимо любое число в диапазоне от 0 до 999. С увеличением количества сохраняемых файлов может потребоваться поднять лимит на максимальное количество ожидающих запросов к сервису auditd — за это отвечает опция -b в конфигурационном файле /etc/audit/audit.rules. Если настроена ротация журналов, то auditd будет следить за количеством файлов журналов и удалять лишние файлы. Проверка избыточных журналов выполняется только при запуске сервиса и при проверке изменения конфигурации сервиса.

space_left_ac­tion

SYSLOG

Определяет какое действие необходимо предпринять если на файловой системе начинает заканчиваться свободное пространство. Допустимые значения параметра перечислены после таблицы.

action_mail_acct

root

Адрес электронной почты или псевдоним (см. /etc/aliases), на который будут отправляться сообщения от auditd. Если адрес не является локальным для данной системы, то необходимо чтобы на ней была настроена почтовая система для отправки, в том числе, требуется наличие программы /usr/lib/sendmail, предоставляемой postfix, exim, sendmail и другими почтовыми системами.

space_left

75

Если объём свободного места в файловой системе, содержащей log_file, становится меньше указанного значения, то сервис auditd выполнит действие, определённое директивой space_left_action. Если значение указано как целое число, то оно интерпретируется как абсолютный размер в мегабайтах. Если значение указано в виде числа от 1 до 99 со знаком процента (например, 5%), то auditd самостоятельно вычислит соответствующее значение как указанный процент от общего размера файловой системы.

use_libwrap

yes

Определяет, следует ли использовать механизм tcp_wrappers для фильтрации подключений от других компьютеров. Допустимые значения: yes или no.

admin_space_left

50

Если объём свободного места в файловой системе, содержащей log_file, становится меньше указанного значения, то сервис auditd выполнит действие, определённое директивой admin_space_left_action. Как и для директивы space_left, значение указывается либо в виде целого числа (абсолютный размер в мегабайтах), либо в процентах от 1% до 99%. В любом случае, значение admin_space_left должно быть меньше space_left — это следует рассматривать как последний шанс что-то предпринять прежде чем дисковое пространство будет полностью заполнено.

admin_space­_left_action

SUSPEND

Определяет какое действие необходимо предпринять если на файловой системе почти закончилось место. Список допустимых значений и их поведение совпадает с директивой space_left_action: IGNORE, SYSLOG, ROTATE, EMAIL, EXEC /путь-к-программе, SUSPEND, SINGLE и HALT.

max_restarts

10

Неотрицательное число, которое определяет сколько раз служба auditd может попытаться перезапустить вышедшее из строя расширение (плагин).

disk_full_action

SUSPEND

Определяет какое действие необходимо предпринять если на файловой системе закончилось место. Допустимые значения: IGNORE, SYSLOG, ROTATE, EXEC /путь-к-программе, SUSPEND, SINGLE, HALT. Поведение для каждого из значений рассмотрено в описании к директиве space_left_action.

disk_error_ac­tion

SUSPEND

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

tcp_listen_port

Не задано

Числовое значение от 1 до 65535, при указании которого сервис auditd будет принимать записи о событиях безопасности от удалённых систем на соответствующем TCP-порту. Для работы с удалённым сервером или клиентами рекомендуется настроить сервис auditd, чтобы он запускался после активации сетевых интерфейсов, соответствующая инструкция приведена в файле /usr/lib/systemd/system/auditd.service.

tcp_listen_queue

5

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

end_of­_event_timeout

2

Неотрицательное количество секунд, после которого событие считается завершённым при анализе потока журнала событий пользовательскими утилитами и библиотечными функциями, такими как aureport (man aureport), ausearch (man ausearch) и т.д. Если в процессе обработки событий время текущего события превышает end_of_event_timeout относительно соседних событий в потоке, то такое событие будет считаться завершённым.

tcp_max_per_addr

1

Числовое значение от 1 до 1024, которое определяет максимально разрешённое количество одновременных подключений с одного IP-адреса. Установка слишком большого значения может привести к DDoS-атаке на сервер auditd. Следует иметь ввиду, что в ядре Linux есть свои собственные лимиты, которые могут ограничить количество подключений даже если настройка сервиса auditd позволяет использовать больше соединений. Значение по умолчанию 1 является достаточным для большинства случаев, если только вы не реализовываете самостоятельно какую-то дополнительную надстройку для пересылки ранее неотправленных сообщений.

tcp_client_ports

Не задано

Определяет с какого исходящего TCP-порта или портов разрешены входящие подключения к сервису auditd. Допустимый диапазон портов: от 1 до 65535. Единичный порт задаётся одним числовым значением, а диапазон — двумя значениями, разделёнными символом «-». Например, чтобы потребовать от клиента использовать привилегированный порт, можно задать значение 1-1023 — это может рассматриваться как дополнительная мера защиты, позволяющая исключить атаки типа «инъекция логов» от имени непривилегированных пользователей. В случае использования этой опции также потребуется установить соответствующее значение директиве local_port в конфигурационном файле /etc/audit/audisp-remote.conf (см. man audisp-remote.conf). В конфигурации по умолчанию никаких ограничений по исходящим портам не применяется.

plugin_dir

/etc/audit/plugins.d

Задаёт каталог, в котором auditd будет осуществлять поиск конфигурационных файлов своих расширений (плагинов).

tcp_client­_max_idle

0

Задаёт время в секундах в течении которого допускается отсутствие каких-либо данных со стороны клиента. Этот параметр используется для закрытия неактивных подключений, если на клиентской системе возникла проблема и она не может самостоятельно завершить подключение. Это глобальная настройка и её значение должно быть выше чем значение heartbeat_timeout (man audisp-remote.conf) на клиентских машинах. Рекомендуется устанавливать значение tcp_client_max_idle в два раза большим чем heartbeat_timeout. Значение по умолчанию 0 отключает эту проверку.

transport

TCP

Если установлено в TCP, то данные между клиентом и сервером auditd будут передаваться в виде открытого текста без шифрования. Если установлено в KRB5, то протокол Kerberos 5 будет использоваться для аутентификации и шифрования.

krb5_key_file

/etc/audit/audit.key

Путь к файлу с ключом для Kerberos-принципала этого клиента. Этот файл должен принадлежать пользователю root и иметь права 0400.

distribute_network

no

Если установлено в yes, то события, поступающие из сети, будут переданы диспетчеру auditd для обработки расширениями (плагинами), что позволит реализовать их дальнейшую пересылку на другой сервер или в систему мониторинга/анализа событий. Если значение no, то события будут только сохраняться в журнал на диске.

overflow_action

SYSLOG

Определяет как служба auditd должна реагировать на переполнение внутренней очереди событий. Когда это происходит, это означает, что в очередь на регистрацию поступает больше событий, чем может быть обработано дочерними процессами auditd. Эта ошибка также означает, что текущее событие, поступившее на обработку, будет потеряно. Допустимые значения: IGNORE, SYSLOG, SUSPEND, SINGLE и HALT. Поведение для каждого из значений рассмотрено в описании к директиве space_left_action.

Допустимые значения параметров

log_format:

  • RAW — записи о событиях безопасности будут храниться в том формате, в котором их отправляет ядро операционной системы.

  • ENRICHED — перед сохранением на диск записи о событиях безопасности будут приведены к более понятному человеку виду путём «разворачивания» информации об идентификаторе пользователя (uid), идентификаторе группы (gid), системном вызове (syscall), архитектуре и адресе сокета. Это упростит анализ событий, созданных на одной системе, в другой системе.

flush:

  • NONE — не выполнять какие-либо дополнительные действия по синхронизации буфера с диском со стороны службы регистрации событий.

  • INCREMENTAL — выполнять принудительную синхронизацию буфера на диск с частотой, определяемой параметром freq.

  • INCREMENTAL_ASYNC — поведение похоже на INCREMENTAL, но синхронизация буфера выполняется в асинхронном режиме для улучшения производительности.

  • DATA — незамедлительно синхронизировать данные файла на диск.

  • SYNC — незамедлительно сохранять данные и метаданные файла на диск.

name_format:

  • NONE — имя компьютера не будет вставляться в записи журнала безопасности.

  • HOSTNAME — в журнал будет добавляться имя компьютера, получаемое из системного вызова gethostname.

  • FQD — система аудита получит имя компьютера и преобразует его в полное имя компьютера (FQDN) с помощью DNS-запроса.

  • NUMERIC — поведение похоже на режим FQD, но по имени компьютера будет определяться IP адрес компьютера. Перед использованием этой опции рекомендуется проверить что команды hostname -i или domainname -i возвращают корректный IP-адрес системы. Использование этой опции не рекомендуется, если для настройки сети используется DHCP так как существует вероятность смены IP-адреса компьютера.

  • USER — будет использоваться имя, заданное системным администратором в параметре name.

max_log_file_action:

  • IGNORE — не контролировать максимальный размер файла.

  • SYSLOG — записать соответствующее предупреждение в системный журнал ОС.

  • SUSPEND — прекратить записывать журнал аудита на диск, сервис auditd при этом продолжит свою работу.

  • ROTATE — выполнить ротацию файла журнала событий безопасности, при необходимости удалить старые файлы журналов. Будет создан новый файл журнала, а текущий будет переименован — к его имени будет добавлен постфикс 1, постфикс более старых файлов журналов будет увеличен на единицу. Такого же поведения придерживается утилита logrotate.

  • KEEP_LOGS — поведение аналогично опции ROTATE, но старые файлы журналов не будут удаляться, что предотвратит потерю данных из журнала событий безопасности. Когда на диске закончится место, будет выполненное действие, определённое директивой space_left_action. Этот вариант рекомендуется использовать совместно с системой резервного копирования.

space_left_action:

  • IGNORE — ничего не предпринимать.

  • SYSLOG — записать соответствующее предупреждение в системный журнал.

  • ROTATE — осуществить ротацию файлов журналов, удалить самые старые из них чтобы освободить место.

  • EMAIL — отправить соответствующее предупреждение на адрес электронной почты, указанный в директиве action_mail_acct и записать предупреждение в системный журнал.

  • EXEC /путь-к-программе — приостановить запись событий в журнал и выполнить указанную программу, передача параметров программе не поддерживается. Вызванная программа должна освободить место и подать сигнал SIGUSR2 сервису auditd чтобы он возобновил запись событий. Самый простой способ это сделать — выполнить команду auditctl --signal USR2.

  • SUSPEND — прекратить запись данных на диск, при этом сам сервис auditd будет активен.

  • SINGLE — перевести компьютер в однопользовательский режим (также известный как режим восстановления), как если бы системный администратор выполнил команду telinit 1 или systemctl isolate runlevel1.target.

  • HALT — выключить компьютер. Все действия кроме ROTATE будут выполняться только один раз.

disk_error_action:

  • IGNORE — ничего не предпринимать.

  • SYSLOG — записать не более пяти последовательных предупреждений в системный журнал.

  • EXEC /путь-к-программе — приостановить запись событий в журнал и выполнить указанную программу, передача параметров программе не поддерживается. Вызванная программа должна освободить место и подать сигнал SIGUSR2 сервису auditd чтобы он возобновил запись событий. Самый простой способ это сделать — выполнить команду auditctl --signal USR2.

  • SUSPEND — прекратить запись данных на диск, при этом сам сервис auditd будет активен.

  • SINGLE — перевести компьютер в однопользовательский режим (также известный как режим восстановления), как если бы системный администратор выполнил команду telinit 1 или systemctl isolate runlevel1.target.

  • HALT — выключить компьютер.

6.2.2. Применение изменений

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

$ sudo auditctl --signal HUP

Служба auditd перечитает конфигурационный файл и, если не обнаружит синтаксических ошибок, попробует применить запрошенные изменения. В случае успешного завершения операции в журнале событий безопасности /var/log/audit/audit.log появится соответствующее сообщение типа DAEMON_CONFIG:

type=DAEMON_CONFIG msg=audit(1731317470.852:545): op=reconfigure state=changed \
auid=1000 pid=15069 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 \
res=success AUID="user"

В случае возникновения ошибки, в зависимости от её типа, будет выполнено одно из действий, определённых директивами space_left_action, admin_space_left_action, disk_full_action или disk_error_action в конфигурационном файле.

6.2.3. Рекомендации по безопасной настройке

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

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

  • На сервере рекомендуется настроить почтовую систему (MTA, Mail Transfer Agent) для отправки уведомлений от службы аудита системному администратору. В репозиториях МСВСфера ОС доступны следующие почтовые сервера: postfix, sendmail и esmtp. Если ваша система мониторинга использует протокол SNMP (Simple Network Management Protocol), то в качестве альтернативного способа доставки уведомлений можно реализовать соответствующие скрипты/утилиты для отправки предупреждений в систему мониторинга, а через неё, в свою очередь, отправлять предупреждения системному администратору. В состав пакета net-snmp-utils входит утилита snmptrap, которую можно использовать для отправки сигналов SNMP-trap. Через разработку собственных утилит можно реализовать отправку уведомлений с использованием других протоколов.

  • Каталог, в котором хранятся журналы безопасности (см. описание параметра log_file), должен находиться на отдельном разделе/точке монтирования. Это позволит избежать ситуации, когда для журналов безопасности не осталось свободного места по причине того, что оно занято файлами других процессов. Также это позволит службе аудита точнее определять и контролировать оставшееся место.

  • Параметрам max_log_file и num_logs должны быть присвоены такие значения, чтобы служба аудита могла использовать всё доступное место на файловой системе. Следует иметь в виду, что чем больше файлов необходимо ротировать, тем больше времени на это потребуется службе аудита прежде чем приступить к записи событий в новый файл журнала. Соответственно, не рекомендуется устанавливать слишком маленький размер файла журнала.

  • Параметру max_log_file_action рекомендуется присвоить значение KEEP_LOGS, чтобы старые файлы журналов безопасности не удалялись.

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

  • Для параметра space_left_action рекомендуется установить значение EMAIL, чтобы отправить соответствующее предупреждение на электронную почту системному администратору. В качестве альтернативы можно использовать значение EXEC и вызывать соответствующую утилиту для отправки уведомления с использованием другого протокола, допустим, SNMP.

  • Параметру admin_space_left рекомендуется установить такое значение, при котором у службы аудита останется достаточно свободного пространства для протоколирования действий системного администратора.

  • Значение параметра admin_space_left_action рекомендуется установить в SINGLE, чтобы перевести систему в однопользовательский режим и позволить администратору освободить место на диске.

  • Параметру disk_full_action рекомендуется установить значение HALT для автоматического выключения системы, если на диске кончилось место — это позволит избежать незапротоколированных действий в системе. Если выключение системы неприемлемо, то установите значение SINGLE, чтобы перевести систему в однопользовательский режим.

  • Параметр disk_error_action должен быть установлен в значение SYSLOG, SINGLE или HALT, в зависимости от политики безопасности вашего предприятия в отношении аппаратных сбоев.

  • Если у вас отсутствует система резервного питания и потенциальная утеря нескольких (см. описание директивы freq в конфигурационном файле) последних записей о событиях безопасности является для вас критичной, то установите значение директивы flush в SYNC, что обеспечит постоянную синхронизацию данных и метаданных на диск. Однако, следует отметить, что это приведёт к снижению производительности дисковой подсистемы.

В случае использования сервиса auditd для агрегации журналов с других машин по сети рекомендуется:

  • Использовать протокол Kerberos для аутентификации и шифрования соединения между компьютерами, за это отвечают директивы transport, krb5_principal и krb5_key_file в конфигурационном файле.

  • Разрешить отправку журналов безопасности только с использованием привилегированных портов — директива tcp_client_ports в конфигурационном файле. Это поможет избежать атак со стороны непривилегированных пользователей на клиентских машинах.

6.3. Управление правилами аудита

Правила фильтрации событий безопасности можно условно разделить по времени их жизни на временные и постоянные. Временные правила в основном используются для отладки, они добавляются в систему вручную, с помощью утилиты auditctl, и действуют до перезагрузки или выключения системы. Постоянные правила хранятся в виде файлов в каталоге /etc/audit/rules.d и автоматически применяются каждый раз при загрузке системы.

6.3.1. Утилита auditctl

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

Как и для большинства команд в среде GNU/Linux, для вызова утилиты auditctl используется стандартный синтаксис:

auditctl [аргументы]

Аргументы, которые принимает команда, разбиты на три группы по их назначению.

  • Конфигурационные опции — отвечают за настройку параметров ядра, связанных с подсистемой аудита.

  • Опции состояния — отображают состояние подсистемы аудита, также существует опция для отправки сообщения в поток событий безопасности.

  • Опции для управления правилами фильтрации событий безопасности.

Конфигурационные опции перечислены в таблице.

Таблица 17 - Конфигурационные опции auditctl

Аргумент

Описание

-b <количество>

Устанавливает лимит на максимальное количество ожидающих обработки событий безопасности для подсистемы аудита в ядре. Если лимит будет превышен, то ядром будет выставлен флаг сбоя для дальнейшей обработки. Следует иметь в виду, что очередь необработанных сообщений хранится в оперативной памяти, соответственно, объём потребляемой памяти будет пропорционален количеству записей в очереди. Одна запись может занимать около 10 килобайт. По умолчанию размер буфера в ядре равен 64 записям, но правила, поставляемые с МСВСфера ОС, устанавливают его размер в 8192 записей.

--backlog_wait­_time <время_ожидания>

Задаёт максимальное время ожидания пока размер полностью заполненной очереди событий, ожидающих обработки, не уменьшится. В случае превышения этого лимита текущее событие, ожидающее обработки, будет утеряно (удалено). При этом в журнал событий будет записана соответствующая ошибка. По умолчанию таймаут в ядре равен 60×HZ.

--reset_backlog­_wait_time_actual

Сбрасывает счётчик фактического времени ожидания уменьшения очереди событий, отображаемый статус-командой auditctl -s.

-c

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

-D

Удалить все правила и точки наблюдения. Может быть скомбинирован с аргументом -k.

-e [0..2]

Управляет состоянием службы аудита. Допустимые значения параметра перечислены после таблицы.

-f [0..2]

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

-h

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

-i

Если используется самостоятельно, то включает режим игнорирования ошибок при чтении правил из файла — в таком случае auditctl всегда будет возвращать успешный код возврата. Если же используется в комбинации с аргументом -s, то, по возможности, переводит числовые идентификаторы в понятные пользователю слова.

--loginuid­immutable

Делает UID учётных записей неизменяемым сразу после его установки, что предотвращает возможность выдавать себя за других пользователей. Для изменения UID требуется полномочие CAP_AUDIT_CONTROL, поэтому непривилегированный пользователь не может его изменить. Использование этого параметра может вызвать проблемы при использовании контейнеризации.

-t

«Обрезать» неиспользуемые ветви поддеревьев каталогов после монтирования.

-q <точка_монти­рования,поддерево>

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

-r <частота>

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

--reset-lost

Сбрасывает счётчик потерянных записей, отображаемых статус-командой auditctl -s.

-R <путь_к_файлу>

Считать и выполнить правила из указанного файла. Правила будут применяться построчно, в том порядке, в котором они определены в файле. Файл должен принадлежать пользователю root и быть недоступным для чтения и записи другими пользователями, в противном случае запрос на его обработку будет отклонён. Строки, имеющие в начале символ # считаются комментариями. Каждая строка будет обрабатываться как набор аргументов для команды auditctl. Поскольку файл обрабатывается именно командой auditctl, а не командной оболочкой bash, не экранируйте специальные символы shell. Примеры файлов с правилами приведены дальше в этом разделе.

--signal <сигнал>

Отправляет сигнал (man 7 signal) службе аудита, для этого потребуются соответствующие привилегии. Поддерживаемые сигналы перечислены после таблицы.

Допустимые значения параметров

-f [0..2]:

  • 0 — «тихий» режим, ничего не предпринимать.

  • 1 — записать сообщение об ошибке в журнал сообщений ядра с помощью функции printk().

  • 2 — отрапортовать о критичной ошибке ядра и перевести его в состояние «kernel panic» заблокировав тем самым дальнейшую работу системы. Значение по умолчанию — 1, но для защищённых окружений рекомендуется использовать 2.

-e [0..2]:

  • 0 — временно отключить службу аудита.

  • 1 — включить службу аудита.

  • 2 — включить службу аудита и заблокировать последующие изменения её конфигурации. Блокировка конфигурации должна быть последней командой в цепочке правил для службы аудита, после её применения любая попытка изменить конфигурацию службы аудита будет запротоколирована и отклонена. Изменение правил вновь станет возможным только после перезагрузки компьютера.

Поддерживаемые сигналы для –signal <сигнал>:

  • TERM (stop) — завершает работу службы аудита.

  • HUP (reload) — при получении данного сигнала служба auditd перечитает конфигурационный файл и, если не обнаружит синтаксических ошибок, попробует применить запрошенные изменения. В случае успешного завершения операции в журнале событий безопасности /var/log/audit/audit.log появится соответствующее сообщение типа DAEMON_CONFIG. В случае возникновения ошибки, в зависимости от её типа, будет выполнено одно из действий, определённых директивами space_left_action, admin_space_left_action, disk_full_action или disk_error_action в конфигурационном файле.

  • USR1 (rotate) — указывает службе аудита на необходимость прекратить запись в текущий файл журнала, создать новый файл и продолжить вести журнал в нём. Этот сигнал может быть полезным для организации процесса резервного копирования.

  • USR2 (resume) — указывает службе аудита на необходимость продолжить ведение журнала событий безопасности. Обычно это требуется после приостановки ведения журнала или переполнения внутренней очереди подсистемы аудита.

Опции состояния перечислены в таблице.

Таблица 18 - Опции состояния auditctl

Аргумент

Описание

-l

Вывести список всех правил по одному на строку.

В связке с этой опцией можно использовать ещё два параметра:

-k <ключ> — вывести только правила, соответствующие заданному ключу.

-i — интерпретировать значения полей от a0 до a3 для корректного определения аргументов системных вызовов.

-m <текст>

Отправить в подсистему аудита сообщение из пользовательского пространства. Это можно сделать только от имени суперпользователя root или если у вашего пользователя есть полномочия CAP_AUDIT_WRITE. Отправленное сообщение будет иметь тип USER.

-s

Показать отчёт о состоянии подсистемы аудита в ядре. В нём будут указаны значения, которые устанавливаются с помощью опций -e, -f, -r и -b команды auditctl. Значение pid — это идентификатор процесса службы аудита, если оно равно 0, то служба аудита не запущена. Значение lost отображает количество записей, которые были удалены из-за переполнения очереди событий, ожидающих обработки. Значение backlog отображает количество записей, которые в данный момент находятся в очереди на обработку. Также к опции -s можно добавить параметр -i чтобы получить интерпретированное значение некоторых числовых полей.

-v

Вывести версию утилиты auditctl.

Опции для управления правилами фильтрации перечислены в таблице.

Таблица 19 - Опции для управления правилами фильтрации auditctl

Аргумент

Описание

-a <список,действие | действие,список>

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

-A <список,действие>

Добавить правило с указанным действием в начало списка. Информацию по доступным действиям и спискам смотрите выше в описании к директиве -a.

-C <поле=поле | поле!=поле>

Создать условие сравнения двух полей для правила. Используется синтаксис первое_поле оператор второе_поле, поддерживаются операторы: = (равно) и != (не равно). В одном правиле может использоваться несколько операций сравнения, каждая должна начинаться с аргумента -C. Чтобы правило сработало для события аудита, все его условия, заданные директивами -C и -F должны быть выполнены.

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

группа uid: auid, uid, euid, suid, fsuid и obj_uid.

группа gid: gid, egid, sgid, fsgid и obj_gid.

Сравнивать между собой можно только поля из одной группы. Поля obj_uid и obj_gid заполняются данными из объекта, для которого возникло событие — файла, каталога и т.п..

-d <список,действие>

Удалить правило с указанным действием из списка. Правило будет удалено только если полностью совпали все поля условия и название системного вызова.

-F <поле=значение | поле!=значение | поле<значение | поле>значение | поле<=значение | поле>=значение | поле&значение | поле&=значение>

Создать условие сравнения для правила. Используется синтаксис поле оператор значение, поддерживаются операторы: = (равно), != (не равно), < (меньше), > (больше), <= (меньше или равно), >= (больше или равно), & (битовая маска) и &= (битовая проверка). В одном правиле может быть до 64 условий, каждое должно начинаться с аргумента -F. Чтобы правило сработало для события аудита, все его условия, заданные директивами -F и -C должны быть выполнены. Для полей, содержащих идентификатор пользователя можно также использовать имя пользователя — программа самостоятельно преобразует имя в идентификатор. То же самое выполняется и для полей с идентификатором группы. Допустимые имена полей перечислены после таблицы.

-W <путь>

Удалить точку наблюдения за объектом файловой системы по указанному пути. Требуется полное соответствие правилу, смотрите описание к опции -d.

-k <ключ>

Устанавливает ключ фильтрации для данного правила. Ключом может быть произвольная текстовая строка длиной не больше 31 байта. Ключ позволяет однозначно идентифицировать записи журнала безопасности, созданные с помощью правила. Обычно используется когда у вас есть несколько правил, которые в совокупности удовлетворяют требованию безопасности. По ключу можно отфильтровать все соответствующие записи с помощью утилиты ausearch, не зависимо от того, какое правило сработало. Ключ также можно использовать для удаления определённых правил с помощью аргумента -D или для получения списка соответствующих правил с помощью аргумента -l. К одному правилу может быть привязано несколько ключей если вы хотите выполнять поиск по событиям несколькими способами или если вы используете собственное расширение auditd для анализа записей в журнале.

-p <r|w|x|a>

Устанавливает фильтр прав доступа к объекту файловой системы: r — чтение (read), w — запись (write), x — исполнение (execute), a — изменение атрибутов (attribute change). Не следует путать эти права с обычными правами доступа к файлу, скорее они определяют системные вызовы, которые выполняют данные действия. Обратите внимание, системные вызовы read и write не включены в этот набор, поскольку они перегрузили бы журнал аудита сообщениями.

-S <имя_или_но­мер_системного_вы­зова | all>

Название или номер системного вызова, который необходимо отслеживать. Также можно использовать ключевое слово all, которое включает обработку всех системных вызовов. В случае если установлен фильтр по другим полям, а системный вызов не указан, то правило будет применяться ко всем системным вызовам. Используя несколько опций -S можно указать несколько системных вызовов в одном правиле — это повышает производительность, поскольку потребуется вычислять меньшее количество правил. В качестве альтернативы, вы можете указать несколько системных вызовов через запятую.

Если вы работаете с системой, которая поддерживает несколько архитектур, например x86_64, то вы должны знать, что auditctl просто берёт название системного вызова, находит номер системного вызова в таблице вызовов для «родной архитектуры» (в данном случае, для b64) и отправляет это правило ядру. Соответственно, если в правиле не определено поле arch, то правило будет применено и к 64-битным системным вызовам, и к 32-битным. Это может привести к нежелательным последствиям, поскольку системные вызова для 32-битных и 64-битных систем могут иметь разные номера. Соответственно, в таком случае рекомендуется создавать два отдельных правила для b32 и b64-архитектур.

-w <путь>

Добавить точку наблюдения за объектом файловой системы по указанному пути. Вы не можете создать точку наблюдения за корневым каталогом (/) поскольку это запрещено ядром. Групповые символы (wildcards) запрещены — при попытке их использования будет выдано соответствующее предупреждение. Внутри точки наблюдения реализованы методом слежения за номерами индексных дескрипторов (inodes). Если вы устанавливаете точку наблюдения за файлом, то это равносильно использованию опции -F path=значение в правиле. Если же вы устанавливаете точку наблюдения за каталогом, то это равносильно использованию опции -F dir=значение в правиле. Форма записи правил через опцию -w предназначена для обратной совместимости, запись через -F является более выразительной. В отличии от большинства правил аудита системных вызовов, точки наблюдения за файловой системой не оказывают существенного влияния на производительность в зависимости от количества правил, отправленных ядру. Единственными допустимыми параметрами при использовании опции -w являются -p и -k. Если вам требуется выполнить что-то необычное, например, провести аудит доступа определённого пользователя к файлу, то воспользуйтесь опцией -F с аргументами path или dir.

Допустимые имена списков аргумента -a <список,действие | действие,список>:

  • task — добавить правило к списку, отвечающему за процессы. Этот список правил используется только во время создания процесса — когда родительский процесс вызывает функции fork() или clone(). При использовании этого списка вы должны использовать только те поля, которые известны на момент создания процесса: uid, gid и т.д..

  • exit — добавить правило к списку, отвечающему за точки выхода из системных вызовов. Этот список используется чтобы определить, следует ли создавать событие аудита при завершении системного вызова.

  • user — добавить правило в список, отвечающий за фильтрацию пользовательских сообщений. Этот список используется ядром для фильтрации сообщений, исходящих из пользовательского пространства, перед передачей их службе аудита. При использовании этого списка поддерживаются только следующие поля: uid, auid, gid, pid, subj_user, subj_role, subj_type, subj_sen, subj_clr, msgtype и exe. Все остальные поля будут считаться не соответствующими условию. Следует понимать, что любое событие, исходящее из пространства пользователя, у которого есть полномочие CAP_AUDIT_WRITE, будет записано в журнал событий безопасности. Соответственно, в большинстве случаев этот фильтр будет использоваться с правилами, действие для которых — never, поскольку для записи события ничего не нужно делать.

  • exclude — добавить правило, исключающее определённый тип события. Например, таким образом можно отключить протоколирование событий от SELinux AVC. События можно исключать по следующим полям: pid, uid, gid, auid, msgtype, subj_user, subj_role, subj_type, subj_sen, subj_clr и exe. Значение параметра действие игнорируется и всегда используется значение never.

  • filesystem — добавить правило, которое будет применяться ко всем файловым системам заданного в поле fstype типа. Обычно этот фильтр используется для исключения всех событий, связанных со специальными файловыми системами, например debugfs или tracefs.

  • io_uring — добавить правило к фильтру системных вызовов подсистемы ядра io_uring. Правила для этого фильтра должны указывать системный вызов с помощью аргумента -S <системный_вызов>, описанного ниже. Вы также можете использовать аргумент -k <ключ> для правила чтобы сгруппировать его с другими правилами, отслеживающими тот же самый системный вызов.

Допустимые действия для правил аргумента -a <список,действие | действие,список>:

  • never — не генерировать записи аудита для подходящих под правило событий. В общем случае рекомендуется размещать такие правила в начале списка, так как срабатывает первое подходящее правило.

  • always — создавать запись аудита, всегда наполнять её данными в точке входа в системный вызов и выдавать на обработку в момент выхода из системного вызова.

Допустимые имена полей аргумента -F <поле=значение | поле!=значение | поле<значение | поле>значение | поле<=значение | поле>=значение | поле&значение | поле&=значение>:

  • a0, a1, a2, a3 — первые четыре аргумента, переданные системному вызову. Строковые аргументы не поддерживаются поскольку ядро получает указатель на строку вместо самой строки. Соответственно, при использовании этих полей, вам следует использовать только числовые значения. Обычно это используется на платформах, мультиплексирующих сокеты или операции IPC.

  • arch — архитектура процессора, на котором выполняется системный вызов. Узнать архитектуру системы можно с помощью команды uname -m. Если вы не знаете архитектуру своего компьютера, но хотите использовать 32-разрядные системные вызовы и ваш компьютер поддерживает 32 бита, вы также можете использовать b32 вместо архитектуры. Таким же образом можно использовать b64 для 64-разрядных системных вызовов. Таким образом можно создавать в некотором смысле независимые от архитектуры правила, поскольку тип семейства будет определяться автоматически. Однако, следует помнить, что системные вызовы могут быть специфичными для определённой архитектуры и то, что доступно для x86_64, может быть недоступно на aarch64. Архитектура должна указываться перед аргументом -S чтобы утилита auditctl могла определить в какой внутренней таблице искать номера системных вызовов.

  • auid — исходный идентификатор пользователя, использованный для входа в систему. auid — это сокращение от audit uid, также его иногда называют loginuid. В качестве значения может использовать как идентификатор пользователя, так и его имя.

  • devmajor — старший номер устройства (device major number).

  • devminor — младший номер устройства (device minor number).

  • dir — полный путь к каталогу для наблюдения. Это приведёт к рекурсивному просмотру этого каталога и всего его поддерева. Это поле можно использовать только в списке exit. Также смотрите описание опции -w.

  • egid — действующий идентификатор группы. Может использоваться как числовой идентификатор, так и название.

  • euid — действующий идентификатор пользователя. Может использоваться как числовой идентификатор, так и имя.

  • exe — абсолютный путь к приложению, для которого будет применяться это правило. Поддерживаются только операторы = и !=. Это поле можно проверять только один раз для каждого правила.

  • exit — код возврата из системного вызова. Если в качестве кода используется ошибка errno (man 3 errno), то можно использовать её текстовое представление.

  • fsgid — идентификатор группы, применяемый к файловой системе.

  • fstype — тип файловой системы, используется только в списке правил filesystem. Допустимые значения: debugfs и tracefs.

  • fsuid — идентификатор пользователя, применяемый к файловой системе. Можно использовать как числовой идентификатор, так и имя пользователя.

  • filetype — тип целевого файла. Допустимые значения: file, dir, socket, link, character, block или fifo.

  • gid — идентификатор группы. Можно использовать как числовой идентификатор, так и название группы.

  • inode — номер индексного дескриптора (inode).

  • key — альтернативный способ установки ключа для фильтрации правил. Смотрите описание опции -k ниже.

  • msgtype — тип сообщения, к которому должно применяться правило. Может использоваться только в списках exclude и user.

  • obj_uid — идентификатор пользователя, связанный с объектом (файлом или каталогом).

  • obj_gid — идентификатор группы, связанный с объектом (файлом или каталогом).

  • obj_user — имя SELinux пользователя, владеющего ресурсом.

  • obj_role — SELinux роль ресурса.

  • obj_type — SELinux тип ресурса.

  • obj_lev_low — нижний уровень ресурса в контексте SELinux.

  • obj_lev_high — верхний уровень ресурса в контексте SELinux.

  • path — полный путь к файлу для точки наблюдения, используется только в списке правил exit.

  • perm — фильтр прав доступа для файловых операций. Подробное описание доступно в справке по опции -p. Этот фильтр используется только в списке правил exit. Его также можно использовать без указания системного вызова — ядро само подберёт системные вызовы, которые удовлетворяют запрашиваемым разрешениям.

  • pers — персональный номер операционной системы.

  • pid — идентификатор процесса.

  • ppid — идентификатор родительского процесса.

  • saddr_fam — номер семейства протоколов, который указан в файле /usr/include/bits/socket.h. Например, IPv4 будет иметь номер 2, а IPv6 — 10.

  • sessionid — идентификатор сеанса пользователя.

  • subj_user — имя пользователя-владельца процесса в контексте SELinux.

  • subj_role — SELinux роль процесса.

  • subj_type — SELinux тип процесса.

  • subj_sen — SELinux чувствительность процесса (Linux Sensitivity).

  • subj_clr — SELinux допуск процесса (SELinux Clearance).

  • sgid — установленный идентификатор группы (см. man getresgid).

  • success — если код возврата системного вызова больше либо равен нулю, то данное поле будет иметь значение true/yes, иначе — false/no. При создании правила используйте 1 для true/yes и 0 для false/no.

  • suid — установленный идентификатор пользователя (см. man getresuid).

  • uid — идентификатор пользователя, можно использовать как числовой идентификатор, так и имя пользователя.

6.3.2. Создание правил аудита

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

6.3.2.1. Контроль загрузки и выгрузки модулей ядра

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

# регистрировать любой запуск команды /usr/bin/kmod. В МСВСфера ОС 9 команды
# /usr/sbin/insmod, /usr/sbin/rmmod и /usr/sbin/modprobe являются символическими
# ссылками на /usr/bin/kmod.
$ sudo auditctl -a always,exit -F path=/usr/bin/kmod -F perm=x \
  -F key=kernel_modules

# предыдущее правило так же можно переписать с использованием опции `-w`,
# с точки зрения подсистемы аудита оба правила эквивалентны:
# sudo auditctl -w /usr/bin/kmod -p x -k kernel_modules

# отслеживать системные вызовы, выполняющие загрузку и выгрузку модулей ядра
# на 64-битной архитектуре
$ sudo auditctl -a always,exit -F arch=b64 \
  -S init_module,finit_module,delete_module -F key=kernel_modules

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

$ sudo ausearch -k kernel_modules

6.3.2.2. Отслеживание изменений в конфигурации sudo

Sudo — это утилита, позволяющая пользователю выполнять программы с привилегиями другой учётной записи, в том числе и от имени суперпользователя. Настройка sudo выполняется либо через редактирование основного конфигурационного файла /etc/sudoers, либо через создание дополнительных конфигурационных файлов в каталоге /etc/sudoers.d.

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

# отслеживать любые изменения файла /etc/sudoers
$ sudo auditctl -a always,exit -F path=/etc/sudoers -F perm=wa \
  -F key=sudo_config

# отслеживать любые изменения в каталоге /etc/sudoers.d
$ sudo auditctl -a always,exit -F dir=/etc/sudoers.d -F perm=wa \
  -F key=sudo_config

Эти правила также можно записать с использованием опции -w:

# отслеживать любые изменения файла /etc/sudoers
$ sudo auditctl -w /etc/sudoers -p wa -k sudo_config

# отслеживать любые изменения в каталоге /etc/sudoers.d
$ sudo auditctl -w /etc/sudoers.d -p wa -k sudo_config

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

$ sudo ausearch -k sudo_config

6.3.2.3. Отслеживание установки или обновления RPM-пакетов

Для отслеживания установки или обновления RPM-пакетов подсистемой аудита установите из репозиториев МСВСфера ОС пакет rpm-plugin-audit, который содержит необходимое расширение для пакетного менеджера RPM:

$ sudo dnf install -y rpm-plugin-audit

Больше никаких действий по настройке не требуется — при каждой установке или обновлении RPM-пакета в журнал событий безопасности будет добавляться соответствующая запись с типом SOFTWARE_UPDATE.

Пример сообщения об обновлении пакета osinfo-db:

type=SOFTWARE_UPDATE msg=audit(1731661320.537:3549): \
pid=22903 uid=0 auid=1000 ses=4 subj=unconfined_u:unconfined_r: \
unconfined_t:s0-s0:c0.c1023 msg='op=update sw="osinfo-db-20231215-1.el9.inferit.noarch" \
sw_type=rpm key_enforce=0 gpg_res=1 root_dir="/" comm="dnf" exe="/usr/bin/python3.9" \
hostname=msvsphere-94-arm.msvsphere.test addr=? terminal=pts/2 res=success'

6.3.2.4. Отслеживание установки модулей для Lua, NodeJS, Perl, Python, Ruby

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

  • /usr/bin/pip — установщик Python-модулей

  • /usr/bin/npm — установщик NodeJS-модулей

  • /usr/bin/cpan — установщик Perl-модулей

  • /usr/bin/gem — установщик Ruby-модулей

  • /usr/bin/luarocks — установщик Lua-модулей

  • /usr/bin/dnf-3 — пакетный менеджер DNF

  • /usr/bin/yum — пакетный менеджер Yum (в настоящее время является ссылкой на DNF чтобы обеспечить совместимость)

Данные правила находятся в файле /usr/share/audit/sample-rules/44-installers.rules и не включены по умолчанию. Для их активации выполните следующие действия.

  1. Скопируйте файл с правилами в каталог постоянных правил подсистемы аудита /etc/audit/rules.d:

    $ sudo cp /usr/share/audit/sample-rules/44-installers.rules /etc/audit/rules.d/
    
  2. Загрузите обновлённый набор правил в подсистему аудита:

    $ sudo augenrules --load
    
  3. Убедитесь, что правила были загружены, с помощью команды:

    $ sudo auditctl -l | grep software-installer
    -p x-w /usr/bin/dnf-3 -k software-installer
    -p x-w /usr/bin/yum -k software-installer
    -p x-w /usr/bin/pip -k software-installer
    -p x-w /usr/bin/npm -k software-installer
    -p x-w /usr/bin/cpan -k software-installer
    -p x-w /usr/bin/gem -k software-installer
    -p x-w /usr/bin/luarocks -k software-installer
    

Теперь при запуске любого из отслеживаемых пакетных менеджеров в журнал подсистемы аудита будет добавлена соответствующая запись. Отфильтровать такие события можно по ключу software-installer. Ниже приведён пример события, которое было запротоколировано при выполнении команды pip install markdown2:

$ ausearch -k software-installer
----
time->Fri Nov 15 13:40:38 2024
type=PROCTITLE msg=audit(1731667238.489:3725): proctitle=2F7573722F62696E2F707974686F6E33002F62696E2F70\
697000696E7374616C6C006D61726B646F776E32
type=PATH msg=audit(1731667238.489:3725): item=2 name="/lib64/ld-linux-x86-64.so.2" \
inode=1980964 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 \
nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1731667238.489:3725): item=1 name="/usr/bin/python3" inode=1993087 \
dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 \
nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1731667238.489:3725): item=0 name="/bin/pip" inode=1966587 \
dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 \
nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1731667238.489:3725): cwd="/home/user"
type=EXECVE msg=audit(1731667238.489:3725): argc=4 a0="/usr/bin/python3" \
a1="/bin/pip" a2="install" a3="markdown2"
type=SYSCALL msg=audit(1731667238.489:3725): arch=c000003e syscall=59 \
success=yes exit=0 a0=560b1acfe030 a1=560b1aceae30 a2=560b1abd46e0 a3=8 \
items=3 ppid=14961 pid=23067 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 \
sgid=0 fsgid=0 tty=pts2 ses=4 comm="pip" exe="/usr/bin/python3.9" \
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="software-installer"

Более подробно работа с постоянными правилами подсистемы аудита и утилитой ausearch описана в следующих разделах.

6.3.2.5. Рекомендации по оптимизации правил

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

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

$ sudo auditctl -a always,exit -F arch=b64 -S init_module -F key=kernel_modules
$ sudo auditctl -a always,exit -F arch=b64 -S finit_module -F key=kernel_modules
$ sudo auditctl -a always,exit -F arch=b64 -S delete_module -F key=kernel_modules

Поскольку все остальные поля правила совпадают, их легко можно объединить в одно правило, которое уже приводилось в примере ранее:

$ sudo auditctl -a always,exit -F arch=b64 \
  -S init_module,finit_module,delete_module -F key=kernel_modules

Также можно указывать каждый системный вызов с помощью отдельного аргумента -S — с точки зрения подсистемы аудита оба варианта эквивалентны:

$ sudo auditctl -a always,exit -F arch=b64 \
  -S init_module -S finit_module -S delete_module -F key=kernel_modules

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

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

$ auditctl -a always,exit -F arch=b64 -S openat -S truncate -F success=0

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

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

$ auditctl -a always,exit -F dir=/etc -F arch=b64 -S openat,truncate -F success=0

И будет применяться только к файлам внутри каталога /etc или в его подкаталогах, что значительно сократит количество проверяемых системных вызовов.

6.3.3. Создание постоянных правил

Постоянные правила подсистемы аудита хранятся в виде файлов в каталоге /etc/audit/rules.d/ и автоматически применяются во время запуска службы auditd.

Каждый файл с правилами должен иметь расширение .rules, например, 50-mail-server.rules. Файлы с правилами обрабатываются и загружаются последовательно, в порядке естественной сортировки («natural sort order»). Общепринятой, хотя и не обязательной, является следующая схема именования файлов: приоритет-описание.rules где приоритет — целое число, задающее порядок загрузки файла, а описание — краткое описание назначения загружаемых правил.

При разработке правил для МСВСфера ОС предлагается придерживаться следующей схемы:

  • 10 — правила для настройки ядра и подсистемы аудита;

  • 20 — правила, переопределяющие настройки ядра и подсистемы аудита, поставляемые с операционной системой;

  • 30 — основные правила;

  • 40 — дополнительные/опциональные правила;

  • 50 — правила, специфичные для группы серверов;

  • 70 — правила, специфичные для локальной системы;

  • 90 — правило, блокирующее дальнейшее изменение списка правил.

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

  • пустые строки и весь текст после символа # игнорируются;

  • каждая непустая строка считается правилом и оформляется в виде списка аргументов для команды auditctl (см. раздел 6.3.2. Создание правил аудита), при этом сама команда auditctl не указывается — она будет автоматически вызвана системой с заданными аргументами при обработке файла с правилами. На одной строке должно объявляться только одно правило;

  • файл должен оканчиваться пустой строкой.

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

-w /etc/libvirt/libvirt-admin.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/libvirt.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/libvirtd.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/qemu.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/qemu-lockd.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/virtinterfaced.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/virtlockd.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/virtlogd.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/virtnetworkd.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/virtnodedevd.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/virtnwfilterd.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/virtproxyd.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/virtqemud.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/virtsecretd.conf -p wa -k libvirt-config-changes
-w /etc/libvirt/virtstoraged.conf -p wa -k libvirt-config-changes
-w /usr/share/polkit-1/actions/org.libvirt.api.policy -p wa -k libvirt-polkit-changes
-w /usr/share/polkit-1/actions/org.libvirt.unix.policy -p wa -k libvirt-polkit-changes
-w /usr/share/polkit-1/rules.d/50-libvirt.rules -p wa -k libvirt-polkit-changes

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

$ sudo chown root:root /etc/audit/rules.d/50-mail-server.rules
$ sudo chmod 600 /etc/audit/rules.d/50-mail-server.rules

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

$ sudo augenrules --load

6.4. Работа с журналом событий безопасности

6.4.1. Формат файла журнала событий безопасности

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

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

$ sudo auditctl -a always,exit -F path=/etc/fstab -F perm=r -F key=fstab_read

Теперь прочитаем файл какой-нибудь командой, допустим cat:

$ cat /etc/fstab

В журнале /var/log/audit/audit.log появятся следующие записи о событии:

type=SYSCALL msg=audit(1731576783.677:1528): arch=c000003e syscall=257 \
success=yes exit=3 a0=ffffff9c a1=7ffd91e5b610 a2=0 a3=0 items=1 ppid=19085 \
pid=20721 auid=1667 uid=1667 gid=1667 euid=1667 suid=1667 fsuid=1667 \
egid=1667 sgid=1667 fsgid=1667 tty=pts6 ses=7 comm="cat" exe="/usr/bin/cat" \
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="fstab_read"

type=CWD msg=audit(1731576783.677:1528): cwd="/home/user"

type=PATH msg=audit(1731576783.677:1528): item=0 name="/etc/fstab" \
inode=262528 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 \
obj=unconfined_u:object_r:etc_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 \
cap_fe=0 cap_fver=0 cap_frootid=0 OUID="root" OGID="root"

type=PROCTITLE msg=audit(1731576783.677:1528): proctitle=636174002F6574632F6673746162

Все четыре записи имеют одинаковое значение поля msg, что определяет их принадлежность к одному событию. Записи журнала аудита всегда начинаются с поля type, каждая запись состоит из нескольких пар поле=значение, разделённых пробелом, в некоторых случаях может использоваться запятая.

Теперь рассмотрим каждую из записей подробнее.

Для первой записи установлены следующие поля.

  • type=SYSCALL — поле type указывает на тип записи, в данном случае значение SYSCALL означает, что эта запись вызвана системным вызовом ядра.

  • msg=audit(1731576783.677:1528) — поле msg содержит следующие данные.

    • Временную отметку и уникальный идентификатор события в формате audit(временная_отметка:ID). Несколько записей в журнале аудита могут иметь одинаковую отметку и идентификатор если они были сгенерированы в рамках обработки одного события безопасности. Для временной отметки используется стандартный для Unix-подобных систем формат — количество секунд, прошедших с 00:00:00 по UTC 1 января 1970 года. Существует множество способов преобразования такой временной отметки в понятный человеку формат, самый простой из них — утилита date:

      $ date -d @1731576783.677
      Чт 14 ноя 2024 12:33:03 MSK
      
    • Различные специфичные для события пары поле=значение, полученные из ядра или из пользовательского пространства. Формально, все данные, которые находятся после msg=audit(временная_отметка:ID): ... являются значением поля msg, так что не удивляйтесь если в некоторых случаях вы даже увидите два поля msg в одной записи — такие записи встречаются, например, в событиях от гипервизора libvirt.

  • arch=c000003e — информация об архитектуре системы, закодированная в шестнадцатеричной системе. При поиске записей с помощью утилиты ausearch используйте аргумент -i / --interpret чтобы автоматически преобразовывать закодированные значения в понятный человеку формат. Значение c000003e будет преобразовано в x86_64.

  • syscall=257 — тип (номер) системного вызова, который был отправлен ядру. Для 64-битной архитектуры понятное пользователю значение можно получить из файла /usr/include/asm/unistd_64.h. В данном случае, 257 — это системный вызов openat. Для преобразования номера системного вызова в его название можно использовать утилиту ausyscall:

    $ ausyscall 257
    openat
    

    С помощью команды ausyscall --dump можно получить список номеров всех системных вызовов с их именами.

  • success=yes — указывает на то, был ли системный вызов завершён успешно или возникла какая-то ошибка. В этом примере вызов был успешным.

  • exit=3 — код возврата, который вернул системный вызов. Это значение может отличаться для разных системных вызовов.

  • a0=ffffff9c a1=7ffd91e5b610 a2=0 a3=0 — в полях от a0 до a3 содержатся первые четыре аргумента системного вызова, закодированные в шестнадцатеричной системе счисления. Значения этих аргументов зависят от системного вызова и могут быть декодированы с помощью утилиты ausearch.

  • items=1 — количество вспомогательных записей типа PATH, которые следуют в журнале за данной записью системного вызова.

  • ppid=19085 — идентификатор родительского процесса (parent PID).

  • pid=20721 — идентификатор анализируемого процесса (PID).

  • auid=1667 — исходный идентификатор пользователя, использованный для входа в систему (audit id). Этот идентификатор наследуется каждым процессом, даже если идентификатор пользователя был изменён, например, при переключении учётных записей с помощью команды su -.

  • uid=1667 — идентификатор пользователя, запустившего анализируемый процесс.

  • gid=1667 — идентификатор группы пользователя, запустившего анализируемый процесс.

  • euid=1667 — действующий идентификатор пользователя, запустившего процесс. Определяет текущие полномочия процесса.

  • suid=1667 — установленный идентификатор пользователя, запустившего процесс. Используется для хранения начального значения EUID, задаваемого при запуске файла с установленным битом set-user-ID.

  • fsuid=1667 — идентификатор пользователя файловой системы, запустившего процесс.

  • egid=1667 — действующий идентификатор группы пользователя, запустившего процесс. Определяет текущие полномочия процесса.

  • sgid=1667 — установленный идентификатор группы пользователя, запустившего процесс. Используется для хранения начального значения EGID, задаваемого при запуске файла с установленным битом set-group-ID.

  • fsgid=1667 — идентификатор группы пользователя файловой системы, запустившего процесс.

  • tty=pts6 — терминал, с которого был запущен процесс. Типовые форматы значений для этого поля:

    • ttyN — физический терминал.

    • pts/N — терминал, который эмулируется какой-то программой, допустим, сервером SSH. Командные оболочки, запущенные в графической среде, будут являться pts-терминалами.

    • (none) — терминал отсутствует, обычно такое значение устанавливается для системных вызовов, выполняемых системными процессами.

  • ses=7 — идентификатор сессии, из которой был запущен процесс.

  • comm="cat" — название команды, которая использовалась для запуска процесса.

  • exe="/usr/bin/cat" — путь к исполняемому файлу, который использовался для запуска процесса.

  • subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 — SELinux контекст анализируемого процесса.

  • key="fstab_read" — определённый администратором ключ фильтрации, связанный с правилом, которое сгенерировало событие безопасности.

Для второй записи установлены следующие поля (описание поля msg пропущено, так как полностью совпадает с первой записью):

  • type=CWD — тип CWD используется для записи о текущем рабочем каталоге, из которого был запущен анализируемый процесс, вызвавший системный вызов из первой записи. Цель этой записи состоит в том, чтобы зафиксировать местоположение текущего процесса на случай, если в запись с типом PATH будет записан относительный путь. Таким образом, можно будет восстановить абсолютный путь к выполненной команде.

  • cwd="/home/user" — путь к каталогу, из которого был сделан системный вызов.

Для третьей записи установлены следующие поля (описание поля msg пропущено, так как полностью совпадает с первой записью):

  • type=PATH — тип PATH используется для записей о каждом пути, который был передан системному вызову в качестве аргумента. В нашем случае, в системный вызов openat передавался только один путь — /etc/fstab. Для системных вызовов, принимающих несколько путей в качестве аргументов, подсистема аудита создала бы соответствующее количество записей данного типа.

  • item=0 — порядковый номер этой записи среди общего числа записей типа PATH для данного события безопасности. Нумерация начинается с нуля, соответственно, в этом примере рассматривается первая запись.

  • name="/etc/fstab" — путь к файлу или каталогу, который был передан системному вызову в качестве аргумента.

  • inode=262528 — номер индексного дескриптора (inode), связанного с этим файлом или каталогом. Зная этот номер, можно определить путь к файлу или каталогу с помощью следующей команды:

    $ find / -inum  262528 -print
    /etc/fstab
    
  • dev=fd:00 — младший (minor) и старший (major) номера устройства, которое содержит файл или каталог, записанный в этом событии.

  • mode=0100644 — права доступа к файлу или каталогу, записанные в числовой форме, которые возвращаются функцией stat (man 2 stat) в поле st_mode. В данном случае 0100644 можно интерпретировать как -rw-r--r--, что означает, что пользователь root имеет право на чтение и запись, а остальные пользователи только на чтение.

  • ouid=0 — идентификатор пользователя, который владеет заданным файлом или каталогом.

  • ogid=0 — идентификатор группы, которая владеет заданным файлом или каталогом.

  • rdev=00:00 — младший (minor) и старший (major) номера устройства для специальных файлов. В данном случае он не используется, потому что /etc/fstab является обычным файлом.

  • obj=unconfined_u:object_r:etc_t:s0 — SELinux контекст файла или каталога на момент выполнения системного вызова.

  • nametype=NORMAL — обозначает тип файлового объекта внутри контекста события. Подсистемой аудита используются следующие типы:

    • UNKNOWN — файловый объект не известен системе, например, его не существует.

    • NORMAL — обычный файловый объект. Как правило, это исполняемый файл или файл, у которого меняются атрибуты.

    • PARENT — файловый объект является родительским для одного из объектов, представленного в событии безопасности.

    • DELETE — файловый объект, удаляемый во время выполнения системного вызова.

    • CREATE — файловый объект, создаваемый во время выполнения системного вызова.

  • cap_fp=0 — данные, относящиеся к настройке разрешённых возможностей файловой системы для файлового объекта.

  • cap_fi=0 — данные, относящиеся к настройке унаследованных возможностей файловой системы для файлового объекта.

  • cap_fe=0 — установка эффективного бита возможностей файловой системы для файлового объекта.

  • cap_fver=0 — версия возможностей файловой системы для файлового объекта.

Для четвёртой записи установлены следующие поля (описание поля msg пропущено, так как полностью совпадает с первой записью):

  • type=PROCTITLE — тип PROCTITLE указывает на то, что данная запись содержит полную команду запуска процесса, вызвавшего данное событие безопасности.

  • proctitle=636174002F6574632F6673746162 — закодированная в шестнадцатеричной системе счисления полная команда запуска процесса. Утилита ausearch, запущенная с аргументом -i / --interpret автоматически преобразует закодированный текст в понятную пользователю строку, в нашем примере — в cat /etc/fstab.

Записи подсистемы аудита не ограничиваются перечисленными выше четырьмя типами, полный список типов доступен в конце этой главы.

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

6.4.2. Утилита aureport

Команда aureport генерирует итоговые отчёты на основе зарегистрированных в журнале безопасности событий. Также aureport может принимать данные, поступающие на стандартный ввод (stdin), до тех пор пока на входе будут необработанные события аудита. За исключением основного сводного отчёта, все остальные отчёты содержат номер события в журнале аудита. Зная этот номер, вы можете посмотреть все данные по этому событию, используя команду ausearch -a <НОМЕР_СОБЫТИЯ>. Также существует возможность задать временной интервал, за который необходимо сгенерировать отчёт.

Опции командной строки утилиты aureport перечислены в таблице.

Таблица 20 - Опции командной строки утилиты aureport

Аргумент

Описание

-au, --auth

Сгенерировать отчёт о попытках аутентификации.

-a, --avc

Сгенерировать отчёт о предоставлении разрешений SELinux AVC (Access Vector Cache).

--comm

Сгенерировать отчёт о выполнении команд.

-c, --config

Сгенерировать отчёт об изменениях конфигурации.

-cr, --crypto

Сгенерировать отчёт о событиях, связанных с криптографией.

--debug

Выводить искажённые события, которые были пропущены, в стандартный поток ошибок (stderr).

--eoe-timeout <секунды>

Устанавливает время ожидания разбора событий. Подробности доступны в описании директивы end_of_event_timeout конфигурационного файла auditd.conf. Значение, переданное в этом аргументе, имеет больший приоритет, чем значение, указанное в auditd.conf.

-e, --event

Сгенерировать отчёт о событиях.

--escape <режим>

Эта опция определяет, требуется ли экранирование вывода чтобы сделать его более безопасным для некоторых сценариев. Доступны следующие режимы экранирования: raw, tty, shell и shell_quote. Каждый режим включает правила экранирования из предыдущего режима и экранирует всё больше символов. Например, shell экранирует всё то, что экранируется в tty и добавляет экранирование дополнительных символов. Режим по умолчанию — tty.

-f, --file

Сгенерировать отчёт об операциях с файлами и Unix-сокетами.

--failed

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

-h, --host

Сгенерировать отчёт о системе, который, среди прочего, включает события обновления ПО, аутентификации и т.п.

--help

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

-i, --interpret

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

-if, --input < файл | каталог >

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

--input-logs

Получить путь к журналу аудита для анализа из конфигурационного файла audit.conf. Применяется при автоматическом формировании отчётов через cron.

--integrity

Сгенерировать отчёт о событиях целостности.

-k, --key

Сгенерировать отчёт по ключевым словам в правилах аудита.

-l, --login

Сгенерировать отчёт о попытках входа в систему.

-m, --mods

Сгенерировать отчёт об изменениях учётных записей.

-ma, --mac

Сгенерировать отчёт об изменениях в системе мандатного доступа SELinux.

-n, --anomaly

Сгенерировать отчёт об аномальных событиях, сюда, в том числе, входят события о переходе сетевой карты в «неразборчивый» режим (promiscuous mode) и ошибки сегментирования (segmentation fault).

--node <имя-узла>

Использовать для выборки только события, поступившие с определённого узла. По умолчанию отчёт генерируется по всем узлам. Допускается указание имён нескольких узлов.

-nc, --no-config

Не включать в отчёт события с типом CONFIG_CHANGE. Это может быть полезным для отчёта по ключевым словам, поскольку многие правила аудита их используют — указание этой опции поможет избежать ложных срабатываний.

-p, --pid

Сгенерировать отчёт о процессах.

-r, --response

Сгенерировать отчёт о реагировании на аномальные события.

-s, --syscall

Сгенерировать отчёт о системных вызовах.

--success

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

-t, --log

Сгенерировать отчёт о временных периодах каждого файла журнала подсистемы аудита.

--tty

Сгенерировать отчёт о нажатиях клавиш в терминале.

-te, --end [дата] [время]

Учитывать только события, которые произошли раньше или во время указанной временной отметки. Формат даты зависит от ваших региональных настроек (см. описание переменной окружения LC_TIME). Если дата не указана, то используется значение today. Если время не указано, то используется значение now. Для указания времени используется 24-часовой формат. Ключевые слова перечислены после таблицы.

-u, --user

Сгенерировать отчёт о пользователях.

-v, --version

Вывести версию программы aureport и завершить работу.

--virt

Сгенерировать отчёт о событиях системы виртуализации.

-x, --executable

Сгенерировать отчёт об исполняемых файлах.

Ключевые слова агумента -te, –end [дата] [время]:

  • now — сейчас.

  • recent — 10 минут назад.

  • boot — время за секунду до последней загрузки системы.

  • today — сегодня.

  • yesterday — 1 секунда после полуночи вчерашнего дня.

  • this-week — 1 секунда после полуночи 0 (первого) дня текущей недели (определяется вашими региональными настройками).

  • week-ago — 1 секунда после полуночи ровно 7 дней назад.

  • this-month — 1 секунда после полуночи первого дня текущего месяца.

  • this-year — 1 секунда после полуночи первого января текущего года.

6.4.2.1. Примеры использования утилиты aureport

Отчёт об изменениях учётных записей

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

$ sudo aureport --mods --start yesterday

Account Modifications Report
=================================================
# date time auid addr term exe acct success event
=================================================
1. 12/09/2024 18:11:56 1000 libvirt.msvsphere.test pts/11 /usr/sbin/useradd devuser yes 2199
2. 12/09/2024 18:11:56 1000 libvirt.msvsphere.test pts/11 /usr/sbin/useradd devuser yes 2200
3. 12/09/2024 18:11:56 1000 libvirt.msvsphere.test pts/11 /usr/sbin/useradd devuser yes 2201
4. 12/09/2024 18:11:56 1000 libvirt.msvsphere.test pts/11 /usr/sbin/useradd devuser yes 2202
5. 12/09/2024 18:11:56 1000 libvirt.msvsphere.test pts/11 /usr/sbin/useradd ? yes 2203
6. 12/09/2024 18:12:04 1000 libvirt.msvsphere.test pts/11 /usr/bin/passwd devuser yes 2204
7. 12/09/2024 18:12:53 1000 libvirt.msvsphere.test pts/11 /usr/sbin/groupadd ? yes 2205
8. 12/09/2024 18:12:53 1000 libvirt.msvsphere.test pts/11 /usr/sbin/groupadd ? yes 2206
9. 12/09/2024 18:13:48 1000 libvirt.msvsphere.test pts/11 /usr/sbin/useradd qauser yes 2207
10. 12/09/2024 18:13:48 1000 libvirt.msvsphere.test pts/11 /usr/sbin/useradd qauser yes 2208
11. 12/09/2024 18:13:48 1000 libvirt.msvsphere.test pts/11 /usr/sbin/useradd qauser yes 2209
12. 12/09/2024 18:13:48 1000 libvirt.msvsphere.test pts/11 /usr/sbin/useradd qauser yes 2210
13. 12/09/2024 18:13:48 1000 libvirt.msvsphere.test pts/11 /usr/sbin/useradd ? yes 2211
14. 12/09/2024 18:13:59 1000 libvirt.msvsphere.test pts/11 /usr/bin/passwd qauser yes 2212
15. 12/09/2024 18:14:14 1000 libvirt.msvsphere.test pts/11 /usr/sbin/groupadd ? yes 2213
16. 12/09/2024 18:14:14 1000 libvirt.msvsphere.test pts/11 /usr/sbin/groupadd ? yes 2214

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

  • # — порядковый номер строки в таблице;

  • date — дата события;

  • time — время события;

  • auid — исходный идентификатор пользователя, инициировавшего событие. Вы также можете использовать аргумент -i для автоматического преобразования идентификатора в имя пользователя;

  • addr — имя узла или его IP адрес;

  • term — терминал, с которого была запущена команда, вызвавшая событие;

  • exe — запущенная команда;

  • acct — название учётной записи, для которой проводилось изменение;

  • success — статус операции;

  • event — идентификатор события.

Зная идентификатор события, можно посмотреть всю доступную информацию о нём с помощью команды ausearch.

$ sudo ausearch -a 2212
----
time->Mon Dec  9 18:13:59 2024
type=USER_CHAUTHTOK msg=audit(1733757239.466:2212): pid=589141 \
uid=0 auid=1000 ses=4 subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 \
msg='op=PAM:chauthtok grantors=pam_pwquality,pam_unix acct="qauser" \
exe="/usr/bin/passwd" hostname=libvirt.msvsphere.test addr=? terminal=pts/11 res=success'

В данном примере пользователь с идентификатором 1000 успешно изменил пароль пользователю qauser с помощью команды passwd.

Итоговый отчёт о входе пользователей в систему

Для некоторых данных поддерживается формирование итоговых отчётов с помощью аргумента --summary. Например, следующая команда генерирует итоговый отчёт о входе пользователей в систему за последние 7 дней.

$ sudo aureport -u -i --summary --start yesterday

User Summary Report
===========================
total  auid
===========================
1185  unset
36  virtadmin
27  gdm
24  vmuser
21  devuser
9  vmdev
7  qauser
1  root

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

6.4.3. Утилита ausearch

Утилита ausearch — это инструмент для поиска событий в журнале службы аудита на основе различных критерий. Опции командной строки утилиты ausearch перечислены в таблице.

Таблица 21 - Опции командной строки утилиты ausearch

Аргумент

Описание

-c, --comm <название_команды>

Искать события, связанные с указанным именем команды.

--arch <архитектура>

Выполнить поиск событий для указанной архитектуры процессора. Вместо явного указания архитектуры вы также можете использовать константы b32 для 32-битных архитектур и b64 для 64-битных. Узнать архитектуру вашей системы можно с помощью команды uname -m.

-a, --event <идентифика­тор_события>

Выполнить поиск события с заданным идентификатором. Все сообщения от подсистемы аудита имеют поле вида msg=audit(1731576783.677:1528): ..., идентификатор события — это число после символа :, в данном примере — 1528. Все записи, связанные с одним системным вызовом приложения, имеют одинаковый идентификатор. Следующий системный вызов, выполненный тем же приложением, уже будет иметь другой идентификатор, таким образом обеспечивается уникальность.

--debug

Выводить искажённые события, которые были пропущены, в стандартный поток ошибок (stderr).

-w, --word <слово>

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

-x, --executable <программа>

Выполнить поиск событий с заданным именем исполняемой программы.

-vm, --vm-name <название_госте­вой_системы>

Выполнить поиск событий, связанных с заданным названием гостевой системы (виртуальной машины).

--checkpoint <файл_контроль­ной_точки>

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

События подсистемы аудита могут состоять из одной или нескольких записей. При их обработке ausearch определяет событие как завершённое или незавершённое. Завершённое — это либо событие с одной записью, либо событие, которое произошло на две секунды (см. описание опции --eoe-timeout) раньше по сравнению с текущим обрабатываемым событием (см. описание директивы end_of_event_timeout в конфигурационном файле auditd.conf).

При использовании опции --checkpoint в файл_контрольной_точки записывается последнее завершённое событие, а также номер устройства и номер индексного дескриптора (inode) файла журнала, из которого было получено это событие. При следующем вызове ausearch загрузит эти данные из файла контрольной точки и будет игнорировать все события из журналов до тех пор, пока не будет обнаружено совпадение с контрольной точкой. После этого утилита начнёт выводить завершённые события.

Если указанный в контрольной точке файл или последнее событие не будут найдены, то ausearch завершит свою работу с ошибкой (см. таблицу кодов возврата ниже).

--eoe-timeout <секунды>

Устанавливает количество секунд, после которого событие считается завершённым при анализе потока журнала событий. Подробности смотрите в описании директивы end_of_event_timeout конфигурационного файла auditd.conf. Установка этой опции переопределит значение, указанное в файле auditd.conf.

-e, --exit <код>

Выполнить поиск событий на основе указанного кода возврата из системного вызова или кода ошибки errno (man errno).

--escape <режим>

Эта опция определяет, требуется ли экранирование вывода чтобы сделать его более безопасным для некоторых сценариев. Доступны следующие режимы экранирования: raw, tty, shell и shell_quote. Каждый режим включает правила экранирования из предыдущего режима и экранирует всё больше символов. Например, shell экранирует всё то, что экранируется в tty и добавляет экранирование дополнительных символов. Режим по умолчанию — tty.

--extra-keys

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

--extra-labels

Если format установлен в csv, эта опция добавит столбцы с SELinux метками субъекта и объекта если они определены.

--extra-obj2

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

--extra-time

Если format установлен в csv, эта опция добавит дополнительные столбцы с разобранным по полям временем и датой: YEAR, MONTH, DAY, WEEKDAY, HOUR, MILLI и GMT_OFFSET.

-f, --file <имя_файла>

Выполнить поиск событий, связанных с указанным именем файла. Эта опция будет применима как к обычным файлам, так и к Unix-сокетами (AF_UNIX/AF_LOCAL).

--format <формат>

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

-ga, --gid-all <идентифика­тор_группы>

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

-ge, --gid-effective <идентифика­тор_группы>

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

-gi, --gid <идентифика­тор_группы>

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

--help

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

-hn, --host <имя_узла>

Выполнить поиск событий, связанных с заданным именем узла. Имя узла может быть именем компьютера, полным именем компьютера (FQDN) или IP-адресом. Преобразование IP-адресов в доменные имена не выполняется. Обычно этот критерий поиска коррелирует с полями записей addr или host. Также смотрите описание опции --node, которая выполняет поиск по полю node.

-i, --interpret

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

-if, --input <файл | каталог>

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

--input-logs

Получить путь к журналу аудита для анализа из конфигурационного файла audit.conf. Применяется при автоматическом формировании отчётов через cron.

--just-one

Остановить поиск после выдачи первого события, соответствующего критериям поиска.

-k, --key <ключ>

Выполнить поиск событий, связанных с указанным ключом. Подробности доступны в описании опции -k команды auditctl.

-l, --line-buffered

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

-m, --message <тип | список_типов>

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

Вы можете посмотреть список всех поддерживаемых типов, если запустите команду ausearch -m без указания типа.

-n, --node <имя_узла | список_имён_узлов>

Выполнить поиск событий, исходящих от определённого компьютера (узла). Допускается перечисление нескольких узлов через запятую, для вывода события достаточно совпадения с одним из перечисленных имён. Поиск выполняется по полю записи node. Также смотрите описание директивы --host, которая выполняет поиск событий, связанных с именем или IP-адресом узла.

-o, --object <контекст_SELinux>

Выполнить поиск событий, связанных с объектами, которым присвоен указанный контекст SELinux. Поиск выполняется по полю obj.

-p, --pid <pid>

Выполнить поиск событий, связанных с заданным идентификатором процесса (pid).

-pp, --ppid <pid_родитель­ского_процесса>

Выполнить поиск событий, связанных с заданным идентификатором родительского процесса (parent pid).

-r, --raw

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

-sc, --syscall <системный_вызов>

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

-se, --context <контекст_SELinux>

Выполнить поиск событий, связанных с объектами или субъектами, которым присвоен указанный контекст SELinux. Поиск выполняется по полям obj и subj.

--session <сессия>

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

-su, --subject <контекст_SELinux>

Выполнить поиск событий, связанных с субъектами, которым присвоен указанный контекст SELinux. Поиск выполняется по полю subj.

-sv, --success <статус>

Выполнить поиск событий, завершившихся с заданным статусом. Допустимые значения: yes (успешно) и no (неудачно).

-ul, --loginuid <идентифика­тор_пользователя>

Выполнить поиск событий, у которых исходный идентификатор пользователя (auid) соответствует указанному идентификатору пользователя.

-te, --end [дата] [время]

Учитывать только события, которые произошли раньше или во время указанной временной отметки. Формат даты зависит от ваших региональных настроек (см. описание переменной окружения LC_TIME). Если дата не указана, то используется значение today. Если время не указано, то используется значение now. Для указания времени используется 24-часовой формат. Ключевые слова для параметра перечислены после таблицы.

-ts, --start [дата] [время]

Учитывать только события, которые произошли позже или во время указанной временной отметки. Формат даты зависит от ваших региональных настроек (см. описание переменной окружения LC_TIME). Если дата не указана, то используется значение today. Если время не указано, то используется значение now. Для указания времени используется 24-часовой формат. Ключевые слова для параметра перечислены после таблицы.

-tm, --terminal <терминал>

Выполнить поиск событий, связанных с заданным терминалом. Некоторые службы, такие как cron и atd, используют имя службы как имя терминала.

-ua, --uid-all <идентифика­тор_пользователя>

Выполнить поиск событий, у которых либо идентификатор пользователя (uid), либо действующий идентификатор пользователя (euid), либо исходный идентификатор пользователя (auid) соответствуют указанному идентификатору пользователя.

-ue, --uid-effective <идентифика­тор_пользователя>

Выполнить поиск событий, у которых действующий идентификатор пользователя (euid) соответствует указанному идентификатору пользователя.

-ui, --uid <идентифика­тор_пользователя>

Выполнить поиск событий, у которых идентификатор пользователя (uid) соответствует указанному идентификатору пользователя.

-uu, --uuid <идентифика­тор_госте­вой_системы>

Выполнить поиск событий, связанных с заданным идентификатором гостевой системы (UUID).

-v, --version

Вывести версию утилиты ausearch и завершить работу.

Допустимые значения параметра –format <формат>:

  • raw — смотрите описание к опции --raw.

  • default — формат, в котором вы получаете вывод если опция --format не задана: сначала идёт строка-разделитель, затем — временная отметка события, после — все записи, связанные с этим событием.

  • interpret — смотрите описание к опции --interpret.

  • csv — выводит результаты поиска в виде нормализованных событий в формате значений, разделённых запятой (CSV) — этот формат подходит для импорта в аналитические программы.

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

Ключевые слова для параметра -te, –end [дата] [время]:

  • now — сейчас.

  • recent — 10 минут назад.

  • boot — время за секунду до последней загрузки системы.

  • today — сегодня.

  • yesterday — 1 секунда после полуночи вчерашнего дня.

  • this-week — 1 секунда после полуночи 0 (первого) дня текущей недели (определяется вашими региональными настройками).

  • week-ago — 1 секунда после полуночи ровно 7 дней назад.

  • this-month — 1 секунда после полуночи первого дня текущего месяца.

  • this-year — секунда после полуночи первого января текущего года.

Ключевые слова для параметра -ts, –start [дата] [время]:

  • now — сейчас.

  • recent — 10 минут назад.

  • boot — время за секунду до последней загрузки системы.

  • today — сегодня.

  • yesterday — 1 секунда после полуночи вчерашнего дня.

  • this-week — 1 секунда после полуночи 0 (первого) дня текущей недели (определяется вашими региональными настройками).

  • week-ago — 1 секунда после полуночи ровно 7 дней назад.

  • this-month — 1 секунда после полуночи первого дня текущего месяца.

  • this-year — 1 секунда после полуночи первого января текущего года.

  • checkpointausearch будет использовать временную отметку из файла контрольной точки игнорируя при этом идентификатор последнего завершённого события, номер устройства и номер индексного дескриптора (inode) файла журнала (см. описание опции --checkpoint). По сути это действие для восстановления, если вызов ausearch --checkpoint завершился с кодом возврата 10, 11 или 12 (см. таблицу кодов возврата ниже).

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

    ausearch --checkpoint /etc/audit/auditd_checkpoint.txt -i
    _au_status=$?
    if test ${_au_status} eq 10 -o ${_au_status} eq 11 -o ${_au_status} eq 12
    then
      ausearch --checkpoint /etc/audit/auditd_checkpoint.txt --start checkpoint -i
    fi
    

Коды возврата утилиты ausearch перечислены в таблице.

Таблица 22 - Коды возврата утилиты ausearch

Код возврата

Описание

0

Операция выполнена успешно.

1

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

10

В файле контрольной точки обнаружены неверные данные.

11

Ошибка обработки контрольной точки.

12

Событие из контрольной точки не найдено в соответствующем файле журнала.

6.4.3.1. Примеры использования утилиты ausearch

Поиск по типу события

Отобразить события безопасности за последние сутки, связанные с входом пользователя в систему:

$ sudo ausearch -m USER_LOGIN,LOGIN --start yesterday
----
time->Tue Dec 17 14:38:08 2024
type=LOGIN msg=audit(1734435488.883:195): pid=2132 uid=0 \
subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 old-auid=4294967295 \
auid=1004 tty=(none) old-ses=4294967295 ses=4 res=1
----
time->Tue Dec 17 14:38:08 2024
type=LOGIN msg=audit(1734435488.907:201): pid=2146 uid=0 \
subj=system_u:system_r:init_t:s0 old-auid=4294967295 auid=1004 \
tty=(none) old-ses=4294967295 ses=5 res=1
----
time->Wed Dec 18 15:49:57 2024
type=LOGIN msg=audit(1734526197.764:621): pid=256120 uid=0 \
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 old-auid=4294967295 \
auid=1000 tty=(none) old-ses=4294967295 ses=6 res=1
----
time->Wed Dec 18 15:49:57 2024
type=USER_LOGIN msg=audit(1734526197.821:626): pid=256120 uid=0 \
auid=1000 ses=6 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 \
msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=? addr=192.168.1.4 terminal=/dev/pts/3 res=success'

С помощью аргумента -i / --interpret можно преобразовать числовые идентификаторы пользователей в имена:

$ sudo ausearch -m USER_LOGIN,LOGIN --start yesterday -i
----
type=LOGIN msg=audit(12/17/2024 14:38:08.883:195) : \
pid=2132 uid=root subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 \
old-auid=unset auid=virtadmin tty=(none) old-ses=4294967295 ses=4 res=yes
----
type=LOGIN msg=audit(12/17/2024 14:38:08.907:201) : \
pid=2146 uid=root subj=system_u:system_r:init_t:s0 old-auid=unset \
auid=virtadmin tty=(none) old-ses=4294967295 ses=5 res=yes
----
type=LOGIN msg=audit(12/18/2024 15:49:57.764:621) : \
pid=256120 uid=root subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 \
old-auid=unset auid=virtuser tty=(none) old-ses=4294967295 ses=6 res=yes
----
type=USER_LOGIN msg=audit(12/18/2024 15:49:57.821:626) : \
pid=256120 uid=root auid=virtuser ses=6 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 \
msg='op=login id=virtuser exe=/usr/sbin/sshd hostname=? addr=192.168.1.4 terminal=/dev/pts/3 res=success'
----
type=LOGIN msg=audit(12/18/2024 15:50:36.490:657) : pid=256436 \
uid=root subj=system_u:system_r:init_t:s0 old-auid=unset auid=gdm \
tty=(none) old-ses=4294967295 ses=7 res=yes
Поиск по идентификатору пользователя

Отобразить события безопасности за сегодняшний день, связанные с определённым идентификатором или именем пользователя:

$ sudo ausearch --uid-all virtadmin --start today
----
time->Wed Dec 18 15:50:16 2024
type=USER_AUTH msg=audit(1734526216.077:641): pid=256200 uid=0 \
auid=1004 ses=4 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 \
msg='op=PAM:authentication grantors=pam_usertype,pam_localuser, \
pam_unix,pam_gnome_keyring acct="virtadmin" exe="/usr/libexec/gdm-session-worker" \
hostname=libvirt.msvsphere.test addr=? terminal=/dev/tty1 res=success'
----
time->Wed Dec 18 15:50:16 2024
type=USER_ACCT msg=audit(1734526216.079:642): pid=256200 \
uid=0 auid=1004 ses=4 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 \
msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="virtadmin" \
exe="/usr/libexec/gdm-session-worker" hostname=libvirt.msvsphere.test \
addr=? terminal=/dev/tty1 res=success'
----
time->Wed Dec 18 15:50:16 2024
type=CRED_REFR msg=audit(1734526216.080:643): pid=256200 \
uid=0 auid=1004 ses=4 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 \
msg='op=PAM:setcred grantors=pam_localuser,pam_unix,pam_gnome_keyring \
acct="virtadmin" exe="/usr/libexec/gdm-session-worker" hostname=libvirt.msvsphere.test addr=? terminal=/dev/tty1 res=success'
----
time->Wed Dec 18 15:50:36 2024
type=USER_END msg=audit(1734526236.347:648): pid=2132 \
uid=0 auid=1004 ses=4 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 \
msg='op=PAM:session_close grantors=pam_selinux,pam_loginuid,pam_selinux,pam_keyinit,\
pam_namespace,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_gnome_keyring,pam_umask \
acct="virtadmin" exe="/usr/libexec/gdm-session-worker" hostname=libvirt.msvsphere.test \
addr=? terminal=/dev/tty2 res=success'
----
time->Wed Dec 18 15:50:36 2024
type=CRED_DISP msg=audit(1734526236.347:649): pid=2132 uid=0 auid=1004 \
ses=4 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred \
grantors=pam_localuser,pam_unix,pam_gnome_keyring acct="virtadmin" \
exe="/usr/libexec/gdm-session-worker" hostname=libvirt.msvsphere.test \
addr=? terminal=/dev/tty2 res=success'
----
time->Wed Dec 18 15:50:46 2024
type=LOGIN msg=audit(1734526246.330:677): pid=256830 uid=0 \
subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 old-auid=4294967295 \
auid=1004 tty=(none) old-ses=4294967295 ses=8 res=1
----
time->Wed Dec 18 15:50:46 2024
type=PROCTITLE msg=audit(1734526246.330:677): proctitle=67646D2D73657373696F6E2D776F726B6572205B70616\
D2F67646D2D70617373776F72645D
type=SYSCALL msg=audit(1734526246.330:677): arch=c000003e \
syscall=1 success=yes exit=4 a0=9 a1=7ffd6aa865a0 a2=4 a3=3ec \
items=0 ppid=1020 pid=256830 auid=1004 uid=0 gid=1004 euid=0 suid=0 \
fsuid=0 egid=1004 sgid=1004 fsgid=1004 tty=(none) ses=8 comm="gdm-session-wor" \
exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
----
time->Wed Dec 18 15:50:46 2024
type=USER_ROLE_CHANGE msg=audit(1734526246.330:678): pid=256830 \
uid=0 auid=1004 ses=8 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 \
msg='op=pam_selinux default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 \
selected-context=unconfined_u:unconfined_r: \
unconfined_t:s0-s0:c0.c1023 exe="/usr/libexec/gdm-session-worker" \
hostname=libvirt.msvsphere.test addr=? terminal=/dev/tty2 res=success'
----
time->Wed Dec 18 15:50:46 2024
type=USER_START msg=audit(1734526246.352:679): pid=256830 \
uid=0 auid=1004 ses=8 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 \
msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_selinux,pam_keyinit, \
pam_namespace,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_gnome_keyring, \
pam_umask acct="virtadmin" exe="/usr/libexec/gdm-session-worker" \
hostname=libvirt.msvsphere.test addr=? terminal=/dev/tty2 res=success'
Выгрузка данных из журнала

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

Например, можно экспортировать результаты в формате CSV:

$ sudo ausearch --uid-all virtadmin --start today --format csv
NODE,EVENT,DATE,TIME,SERIAL_NUM,EVENT_KIND,SESSION,SUBJ_PRIME,SUBJ_SEC, \
SUBJ_KIND,ACTION,RESULT,OBJ_PRIME,OBJ_SEC,OBJ_KIND,HOW
,USER_AUTH,12/18/2024,15:50:16,641,user-login,4,virtadmin,root, \
privileged-acct,authenticated,success,virtadmin,,user-session,/usr/libexec/gdm-session-worker
,USER_ACCT,12/18/2024,15:50:16,642,user-login,4,virtadmin,root, \
privileged-acct,was-authorized,success,virtadmin,,user-session,/usr/libexec/gdm-session-worker
,CRED_REFR,12/18/2024,15:50:16,643,user-login,4,virtadmin,root, \
privileged-acct,refreshed-credentials,success,virtadmin,,user-session,/usr/libexec/gdm-session-worker
,USER_END,12/18/2024,15:50:36,648,user-login,4,virtadmin,root, \
privileged-acct,ended-session,success,/dev/tty2,,user-session,/usr/libexec/gdm-session-worker
,CRED_DISP,12/18/2024,15:50:36,649,user-login,4,virtadmin,root, \
privileged-acct,disposed-credentials,success,virtadmin,,user-session,/usr/libexec/gdm-session-worker
,LOGIN,12/18/2024,15:50:46,677,user-login,8,system,root, \
privileged-acct,changed-login-id-to,success,virtadmin,,user-session,
,SYSCALL,12/18/2024,15:50:46,677,audit-rule,8,virtadmin,root, \
privileged-acct,triggered-unknown-audit-rule,success,,,admin-defined-rule,/usr/libexec/gdm-session-worker
,USER_ROLE_CHANGE,12/18/2024,15:50:46,678,mac,8,virtadmin,root, \
privileged-acct,changed-role-to,success,unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023,\
,user-session,/usr/libexec/gdm-session-worker
,USER_START,12/18/2024,15:50:46,679,user-login,8,virtadmin,root, \
privileged-acct,started-session,success,/dev/tty2,,user-session,/usr/libexec/gdm-session-worker

Также можно экспортировать фрагменты журнала в «сыром» (raw) формате для их последующей обработки с помощью ausearch или других утилит для работы с журналами событий безопасности.

Например, следующая команда экспортирует все события входа пользователей в систему за последнюю неделю в файл weekly-logins.log:

$ sudo ausearch -m LOGIN,USER_LOGIN --start week-ago --raw > weekly-logins.log

С полученным файлом можно работать как с обычным журналом службы аудита, например выполнить фильтрацию по определённому пользователю и преобразовать вывод в CSV формат:

$ ausearch --uid-all 1004 --format csv --input weekly-logins.log
NODE,EVENT,DATE,TIME,SERIAL_NUM,EVENT_KIND,SESSION,SUBJ_PRIME,SUBJ_SEC,SUBJ_KIND,
ACTION,RESULT,OBJ_PRIME,OBJ_SEC,OBJ_KIND,HOW
,LOGIN,12/16/2024,12:03:51,1269,user-login,10,system,root,privileged-acct,
changed-login-id-to,success,virtadmin,,user-session,
,LOGIN,12/16/2024,12:03:51,1275,user-login,11,system,root,privileged-acct,
changed-login-id-to,success,virtadmin,,user-session,
,LOGIN,12/16/2024,21:11:17,173,user-login,2,system,root,privileged-acct,
changed-login-id-to,success,virtadmin,,user-session,
,LOGIN,12/16/2024,21:11:17,179,user-login,3,system,root,privileged-acct,
changed-login-id-to,success,virtadmin,,user-session,
,LOGIN,12/17/2024,14:38:08,195,user-login,4,system,root,privileged-acct,
changed-login-id-to,success,virtadmin,,user-session,
,LOGIN,12/17/2024,14:38:08,201,user-login,5,system,root,privileged-acct,
changed-login-id-to,success,virtadmin,,user-session,
,LOGIN,12/18/2024,15:50:46,677,user-login,8,system,root,privileged-acct,
changed-login-id-to,success,virtadmin,,user-session,

6.4.4. Резервное копирование журналов событий безопасности

Поскольку журналы событий безопасности хранятся в виде файлов в каталоге /var/log/audit, для создания их резервной копии может применяться любой инструмент резервного копирования, поддерживающий работу с файлами. В состав операционной системы включены утилиты tar, rsync и система резервного копирования bacula.

Простой пример создания локальной резервной копии с помощью команды tar:

$ tar -cjpvf "auditd-logs.$(date --iso-8601).tar.bz2" /var/log/audit/audit.log*

В результате выполнения команды в текущем каталоге будет создан файл auditd-logs.YYYY-MM-DD.tar.bz2 где YYYY — год, MM — месяц и DD — сегодняшнее число. В архив будут помещены все файлы из каталога /var/log/audit, соответствующие шаблону audit.log*.

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

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

  • переименует все имеющиеся копии журнала увеличив число в расширении файла на единицу: audit.log.1 будет переименован в audit.log.2, audit.log.2 — в audit.log.3 и т.д.;

  • остановит запись в текущий файл журнала audit.log;

  • переименует текущий файл журнала в audit.log.1;

  • создаст новый файл журнала audit.log и продолжит запись событий уже в него.

Таким образом будет обеспечена консистентность текущего файла журнала при его резервном копировании.

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

#!/bin/bash

# завершить работу программы в случае возникновения ошибки
set -e

# сменить текущий каталог на /srv/backup
cd /srv/backup

# выполнить принудительную ротацию журналов службы auditd
auditctl --signal rotate

# создать архив со всеми файлами, соответствующими шаблону
tar -cjpvf "auditd-logs.$(date --iso-8601).tar.bz2" /var/log/audit/audit.log.*

Автоматизировать создание резервных копий можно с помощью службы периодического выполнения заданий cron или таймеров systemd. Например, для создания ежедневных архивов вы можете сохранить указанный выше сценарий в файл в каталоге /etc/cron.daily (например, audit-logs-backup.sh) и сделать его исполняемым:

$ sudo chmod +x /etc/cron.daily/audit-logs-backup.sh

После этого служба cron будет автоматически выполнять сценарий ежедневно.

Для восстановления можно использовать следующую команду (замените auditd-logs.2024-12-28.tar.bz2 на реальное имя файла):

$ tar -C / -xjpvf auditd-logs.2024-12-28.tar.bz2

6.4.5. Контроль целостности сведений о событиях безопасности

Целостность сведений о событиях безопасности обеспечивается на уровне ограничения прав доступа в операционной системе: каталог с журналами безопасности /var/log/audit и текущий файл журнала /var/log/audit/audit.log доступны для чтения и записи только привилегированному пользователю root и службе auditd. В свою очередь, предыдущие файлы журналов доступны только для чтения привилегированному пользователю root.

Для повышения защищённости системы рекомендуется использовать дополнительные средства контроля целостности, например, утилиту aide, которая входит в состав дистрибутива МСВСфера ОС. Документация по установке и настройке aide доступна в главе «9. КОНТРОЛЬ ЦЕЛОСТНОСТИ».

При изменении прав доступа, владельца и других атрибутов каталога /var/log/audit или файла журнала событий безопасности /var/log/audit/audit.log команда aide выдаст соответствующее предупреждение о нарушении целостности в отчёте:

aide --check
Start timestamp: 2025-01-20 06:48:56 +0000 (AIDE 0.16)
AIDE found differences between database and filesystem!!

Summary:
  Total number of entries:      37822
  Added entries:                0
  Removed entries:              0
  Changed entries:              2

---------------------------------------------------
Changed entries:
---------------------------------------------------

d   p..      A.. : /var/log/audit
f   ..g      ... : /var/log/audit/audit.log

---------------------------------------------------
Detailed information about changes:
---------------------------------------------------

Directory: /var/log/audit
  Perm     : drwx------                       | drwxr-xr-x
  ACL      : A: user::rwx                     | A: user::rwx
           A: group::---                    | A: group::r-x
           A: other::---                    | A: other::r-x

File: /var/log/audit/audit.log
  Gid      : 0                                | 1000


---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------

/var/lib/aide/aide.db.gz
  MD5      : AABMsEbRMfWShAvA8Yl8kg==
  SHA1     : FssoJmeKJvo7VMc79ZuV1bGgNwI=
  RMD160   : OXPu+xyPaeV6I2c8AOrxwZx8EKA=
  TIGER    : Cez1vaIx/3koN5MbQOwktp/D247COpTa
  SHA256   : B8eWuoZeZ/9PsRrFJIV7lmrXBHo5DPbD
             qaBEO4iea1E=
  SHA512   : xmC1vT9hx9jXmX8NZDbzwUpsaldBbUPj
             F95IEPWxaJn8I3PQnR4G2fZZHnz6mG9G
             OW222CS6V3s2u25O5SqiTQ==


End timestamp: 2025-01-20 06:48:58 +0000 (run time: 0m 2s)

6.4.6. Оповещение о событиях безопасности

Основной задачей подсистемы аудита является регистрация событий безопасности — автоматическое отслеживаниие таких событий и занесение их в системный журнал.

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

6.4.6.1. Разработка расширений для службы аудита

Служба auditd имеет встроенный механизм расширений (плагинов), за счёт которого можно значительно расширить функциональность системы.

Механизм расширений (плагинов) службы ``auditd``

Механизм расширений (плагинов) службы auditd

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

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

  • непрерывно получает поток событий на стандартный поток ввода (stdin), формат получаемых данных идентичен тому, в котором события записываются в системный журнал событий безопасности;

  • обрабатывает системные сигналы HUP (обновить настройки из конфигурационного файла) и TERM (завершить работу);

  • обрабатывает события максимально быстро, не допуская блокировок и переполнения очереди событий, ожидающих отправки со стороны службы auditd;

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

В состав операционной системы МСВСфера 9 сертифицированная редакция входят библиотеки для языков программирования Cи (пакет audit-libs-devel) и Python (пакет python3-audit), которые предоставляют набор готовых функций для разбора поступающих данных. В случае с остальными языками программирования вам потребуется разработать соответствующий парсер самостоятельно.

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

Исходный код расширения с пояснениями:

#!/usr/bin/python3 -I
# аргумент -I указывает на необходимость запуска в изолированном режиме: не
# выполняется поиск модулей в каталоге с программой и в пользовательском
# домашнем каталоге, так же игнорируются все переменные окружения PYTHON*.

# импорт необходимых модулей из стандартной библиотеки Python
import datetime
import email.message
import pprint
import signal
import smtplib
import sys

# модуль auparse поставляется в RPM пакете python3-audit и предоставляет функции
# для разбора событий, поступающих от службы аудита
import auparse

# исходящий почтовый адрес для отправляемых уведомлений
FROM_EMAIL = 'audit-plugin-notify@localhost'
# список почтовых адресов, на которые необходимо отправлять уведомления
ADMIN_EMAILS = ['secadmin@localhost']


def reload_config():
    """
    Функция-заглушка, внутри которой может быть реализована логика обработки
    сигнала HUP - обновление настроек из конфигурационного файла.
    """
    pass


def notify_user_login(event: dict):
    """
    Функция, которая отправляет электронное письмо с уведомлением о входе
    пользователя в систему.
    """
    # поле "subj" содержит информацию от подсистемы SELinux, благодаря типу
    # можно определить каким образом пользователь вошёл в систему
    se_subj = event['fields'].get('subj', '').split(':')
    if len(se_subj) < 3:
        return
    se_type = se_subj[2]
    if se_type == 'sshd_t':
        # удалённый вход в систему по протоколу SSH
        login_type = 'SSH'
    elif se_type == 'local_login_t':
        # локальный вход в систему через текстовый терминал
        login_type = 'terminal'
    elif se_type == 'xdm_t':
        # вход в систему в графическом режиме
        login_type = 'graphical console'
    else:
        # игнорировать события остального типа, как правило это системные
        # события типа "init_t", которые отображают активность внутренних
        # компонентов системы.
        return
    # сформировать почтовое сообщение и отправить его через локальный сервер
    # электронной почты. В данном случае локальный сервис принимает почту от
    # локальных пользователей без дополнительной аутентификации. Библиотека
    # smptlib также поддерживает аутентификацию и подключение по защищённому
    # протоколу SMTPs, так что при необходимости код можно модифицировать для
    # использования любого другого SMTP сервиса для отправки.
    msg_subj = f'User {event["fields"]["auid"]} logged in via {login_type}'
    with smtplib.SMTP('localhost') as smtp:
        msg = email.message.EmailMessage()
        msg['Subject'] = msg_subj
        msg['To'] = ', '.join(ADMIN_EMAILS)
        msg['From'] = FROM_EMAIL
        msg.set_content(pprint.pformat(event))
        smtp.send_message(msg)


def parse_record(parser: auparse.AuParser):
    """
    Функция, которая разбирает отдельную запись события безопасности.
    """
    # метод parser.get_timestamp возвращает объект, который содержит временную
    # метку записи, имя узла и идентификатор события
    event = parser.get_timestamp()
    # преобразовать данные из записи в словарь (хеш-таблицу) чтобы облегчить
    # их последующую обработку
    data = {
        'type': parser.get_type_name(),
        'event': {
            'host': event.host,
            'ts': datetime.datetime.fromtimestamp(event.sec),
            'serial': event.serial
        },
        'fields': {}
    }
    # выполнить обход всех полей записи и записать информацию в словарь
    # data["fields"]. Метод parser.first_field "передвигает курсор" на первое
    # поле записи
    parser.first_field()
    while True:
        data['fields'][parser.get_field_name()] = parser.interpret_field()
        # метод parser.next_field "передвигает курсор" на следующее поле записи,
        # если полей больше нет, будет возвращено значение False
        if not parser.next_field():
            break
    # вызвать функцию notify_user_login если тип записи - LOGIN (вход
    # пользователя в систему)
    if data['type'] == 'LOGIN':
        notify_user_login(data)


def parse_input_line(parser: auparse.AuParser):
    """
    Функция, которая разбирает загруженную в парсер строку на отдельные события
    и записи, а затем вызывает обработчик для каждой записи
    """
    if not parser.first_record():
        # на вход была получена пустая строка или строка, не содержащая
        # информацию о событиях безопасности - выйти из функции
        return
    while True:
        while True:
            # вызывать функцию parse_record для каждой отдельной записи
            parse_record(parser)
            # метод parser.next_record "передвигает курсор" на следующую запись
            # события, если записей нет, будет возвращено значение False - в
            # таком случае необходимо переходить к обработке следующего события
            if not parser.next_record():
                break
        # метод parser.parse_next_event "передвигает курсор" на следующее
        # событие, если событий нет, будет возвращено значение False - в таком
        # случае необходимо завершить обработку текущей строки
        if not parser.parse_next_event():
            break


def main():
    """
    Функция, которая является точкой входа в программу.
    """
    # настройка обработчиков сигналов HUP (перечитать конфигурационный файл) и
    # TERM (завершить работу программы)
    hup_flag = False
    term_flag = False

    def sighup_handler(signal, frame):
        nonlocal hup_flag
        hup_flag = True

    def sigterm_handler(signal, frame):
        nonlocal term_flag
        term_flag = True

    signal.signal(signal.SIGHUP, sighup_handler)
    signal.signal(signal.SIGTERM, sigterm_handler)

    # войти в бесконечный цикл обработки событий
    while True:
        if hup_flag:
            # вызвать функцию для обновления настроек программы если получен
            # сигнал HUP
            reload_config()
            hup_flag = False
        elif term_flag:
            # завершить работу программы если получен сигнал TERM
            sys.exit(0)
        else:
            # считать строку, содержащую информацию об одном или нескольких
            # событиях аудита, из потока стандартного ввода stdin
            for line in sys.stdin:
                # инициализировать парсер записей журнала аудита AuParser,
                # поставляемый с библиотекой auparse.
                parser = auparse.AuParser(auparse.AUSOURCE_BUFFER, line)
                # вызвать функцию для разбора строки с информацией о событии
                parse_input_line(parser)


if __name__ == '__main__':
    sys.exit(main())

Чтобы служба аудита могла запустить расширение, файл с исполняемым кодом необходимо разместить в каталоге, доступном для чтения службой и сделать этот файл исполняемым. Обычно для этих целей используется каталог /usr/local/bin.

В нашем примере код на языке программирования Python не требует компиляции, так что достаточно будет просто сохранить его в файл /usr/local/bin/audit-plugin-notify, сделать его исполняемым и установить безопасные права:

$ sudo chown root:root /usr/local/bin/audit-plugin-notify
$ sudo chmod 755 /usr/local/bin/audit-plugin-notify

Для тестирования и/или отладки расширения нет необходимости сразу подключать его к службе аудита. Поскольку расширение работает с данными в том же формате, в котором они записываются в системный журнал событий безопасности, вы можете использовать для отладки вывод команды ausearch --raw:

$ sudo ausearch -m LOGIN --raw  | /usr/local/bin/audit-plugin-notify

Либо перенаправлять последние записи из журнала непосредственно на ввод расширения с помощью команды tail -F:

$ sudo tail -F /var/log/audit/audit.log | /usr/local/bin/audit-plugin-notify

Для отправки электронных писем из плагина вам понадобится локальная почтовая служба, например, postfix:

$ sudo dnf install -y postfix
$ sudo systemctl enable --now postfix

Для целей тестирования дополнительная конфигурация почтового сервиса не требуется — достаточно чтобы он был запущен и пользователь, на имя которого будет отправляться электронная почта, существовал (не забудьте внести соответствующие изменения в значение переменной ADMIN_EMAILS в исходном коде расширения). Полученная почта будет сохраняться в текстовый файл очереди /var/spool/mail/ИМЯ_ПОЛЬЗОВАТЕЛЯ, с которым может работать как почтовый клиент Evolution (тип сервера «Стандартная для Unix очередь типа mbox»), так и любая программа для просмотра текстовых файлов (less, cat и т.п.). Для получения информации о безопасной настройке почтовой службы для реальных условий вам необходимо обратиться к специализированному руководству.

После того как разработка расширения завершена, его можно подключать к службе аудита. Для этого необходимо создать соответствующий конфигурационный файл плагина в каталоге /etc/audit/plugins.d, имя файла может быть любым, но файл должен иметь расширение .conf. В нашем примере создадим файл /etc/audit/plugins.d/audit-plugin-notify.conf следующего содержания:

# включает (yes) или выключает расширение (no)
active = yes

# направление, в котором работает расширение. В настоящий момент значение всегда
# должно быть out.
direction = out

# путь к исполняемому файлу расширения.
path = /usr/local/bin/audit-plugin-notify

# для пользовательских расширений, не входящих в поставку службы аудита,
# значение type всегда должно быть always.
type = always

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

# служба аудита может подавать данные на ввод расширения в двух форматах:
# в своём внутреннем бинарном (binary) и в текстовом (string). Используемый
# нами модуль auparse поддерживает только текстовый формат.
format = string

Полная информация по всем опциям конфигурационного файла расширения доступна на странице руководства man auditd-plugins.

После создания файла установите для него корректные права:

$ sudo chown root:root /etc/audit/plugins.d/audit-plugin-notify.conf
$ sudo chmod 644 /etc/audit/plugins.d/audit-plugin-notify.conf

Для того чтобы расширение, запущенное службой аудита, могло отправлять почту, потребуется добавить соответствующее разрешение в политики SELinux. Создайте файл audit-plugin-notify.te следующего содержания:

module audit-plugin-notify 1.0;

require {
        type smtp_port_t;
        type sysctl_net_t;
        type auditd_t;
        class tcp_socket name_connect;
        class dir search;
        class file getattr;
        class file read;
        class file open;
}

#============= auditd_t ==============
allow auditd_t smtp_port_t:tcp_socket name_connect;
allow auditd_t sysctl_net_t:dir search;
allow auditd_t sysctl_net_t:file { getattr open read };

Затем скомпилируйте его и создайте SELinux модуль с политикой:

$ checkmodule -M -m -o audit-plugin-notify.mod audit-plugin-notify.te
$ semodule_package -o audit-plugin-notify.pp -m audit-plugin-notify.mod

После этого, используйте следующую команду для загрузки SELinux модуля:

$ sudo semodule -i audit-plugin-notify.pp

Подготовка к запуску расширения службы аудита завершена. Теперь достаточно подать службе сигнал HUP чтобы она перечитала свои конфигурационные файлы:

$ sudo auditctl --signal reload

В случае успешного запуска вы увидите, что служба аудита запустила плагин в дереве процессов:

$ ps axf | grep audit
     45 ?        S      0:00  \_ [kauditd]
    826 ?        S<sl   0:00 /sbin/auditd
  10342 ?        S<     0:00  \_ /usr/bin/python3 -I /usr/local/bin/audit-plugin-notify

Если процесс не запустился, то для диагностики вам необходимо будет просмотреть последние записи в журнале сервиса auditd:

$ sudo journalctl -u auditd

Теперь, когда расширение запущено, вы можете войти в систему от имени какого-либо пользователя и убедиться, что вы получили уведомление на почтовый адрес, указанный в переменной ADMIN_EMAILS.

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

6.4.6.2. SIEM-системы

SIEM (Security information and event management) система — это комплексная система управления информационной безопасностью. Как правило, такое программное обеспечение имеет клиент-серверную архитектуру и предназначено для централизованного решения широкого круза задач:

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

  • организация эффективного хранения полученных данных для последующей обработки;

  • анализ событий безопасности, выявление потенциальных угроз и связей между различными событиями;

  • автоматическая либо автоматизированная реакция на инциденты, связанные с безопасностью: отправка уведомлений, блокировка доступа и т.п.;

  • аудит и отчётность на основе собранных данных.

С точки зрения службы auditd интеграция с SIEM-системами обычно реализуется одним из следующих способов:

  • настройка подсистемы auditd на отправку журналов безопасности в SIEM-систему;

  • SIEM-система предоставляет расширение для службы auditd, реализующее передачу данных;

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

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

6.4.7. Типы записей подсистемы аудита

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

Таблица 23 - Типы записей, генерируемые подсистемой аудита в МСВСфера ОС

Тип записи

Источник

Описание

ACCT_LOCK

user

Пользовательская учётная запись была заблокирована администратором.

ADD_GROUP

user

Добавлена новая пользовательская группа.

ADD_USER

user

Добавлена новая пользовательская учётная запись.

ANOM_ABEND

kernel

Процесс завершился аварийно (segmentation fault и т.п.).

AVC

kernel

Отказ или предоставление разрешений SELinux AVC (Access Vector Cache).

BPF

kernel

Загрузка или выгрузка BPF (Berkeley Packet Filter).

CONFIG_CHANGE

user

Конфигурация подсистемы аудита была изменена.

CRED_ACQ

user

Пользовательские учётные данные загружены в пользовательское пространство. См. описание функции pam_setcred модуля PAM.

CRED_DISP

user

Пользовательские учётные данные выгружены из пользовательского пространства. См. описание функции pam_setcred модуля PAM.

CRED_REFR

user

Пользовательские учётные данные были обновлены в пользовательском пространстве. См. описание функции pam_setcred модуля PAM.

CRYPTO_KEY_USER

user

Криптографический ключ был использован в криптографических целях.

CRYPTO_SESSION

user

Содержит параметры, использованные во время установления TLS-сессии.

CWD

kernel

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

DAEMON_CONFIG

user

Конфигурация службы (сервиса) аудита была изменена.

DAEMON_START

user

Служба (сервис) аудита была запущена.

DEL_GROUP

user

Пользовательская группа была удалена.

DEL_USER

user

Пользовательская учётная запись удалена.

EXECVE

kernel

Содержит команду запуска процесса, присутствует только в событиях, связанных с системным вызовом execve(2).

GRP_MGMT

user

Изменены атрибуты пользовательской группы.

KERN_MODULE

kernel

Модуль ядра был загружен или выгружен.

LOGIN

user

Содержит информацию о входе пользователя в систему.

MAC_CONFIG_CHANGE

user

Был изменён логический переключатель SELinux (SELinux boolean).

PATH

kernel

Информация о пути, который был передан системному вызову в качестве аргумента.

PROCTITLE

kernel

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

SERVICE_START

user

Запущена служба (сервис).

SERVICE_STOP

user

Остановлена служба (сервис).

SOCKADDR

kernel

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

SOFTWARE_UPDATE

user

Информация об обновлении программного обеспечения.

SYSCALL

kernel

Информация о выполненном системном вызове.

SYSTEM_BOOT

user

Система была загружена.

SYSTEM_RUNLEVEL

user

Изменение уровня выполнения системы (например, через telinit).

SYSTEM_SHUTDOWN

user

Система была остановлена.

USER_ACCT

user

Обнаружена попытка авторизации пользователя.

USER_AUTH

user

Обнаружена попытка аутентификации пользователя.

USER_CHAUTHTOK

user

Пароль пользователя был изменён.

USER_CMD

user

Команда была запущена из пользовательского пространства. В конфигурации по умолчанию протоколирует только запуск sudo.

USER_END

user

Пользовательская сессия была завершена.

USER_ERR

user

Ошибка состояния учётной записи пользователя.

USER_LOGIN

user

Пользователь вошёл в систему.

USER_LOGOUT

user

Пользователь вышел из системы.

USER_MGMT

user

Изменение атрибутов пользовательской учётной записи.

USER_ROLE_CHANGE

user

SELinux-роль пользователя изменилась.

USER_START

user

Запущена пользовательская сессия.

VIRT_CONTROL

user

Изменено состояние виртуальной машины (запущена, остановлена и т.д.).

VIRT_MACHINE_ID

user

Виртуальной машине назначен контекст безопасности SELinux.

VIRT_RESOURCE

user

Виртуальной машине был назначен (выделен) какой-либо ресурс.

В столбце «Источник» применяются следующие сокращения:

  • user — источником события является пользовательское пространство;

  • kernel — источником события является пространство ядра.