Аудит безопасности в Red OS — конфигурация auditd

Отключи SELinux до отладки – мешает. Проверь, активен ли демон: systemctl status auditd. Если не запущен – запусти. Если не установлен – dnf install audit. Всё просто. Но не на Red OS. Тут нюансы.

Сразу настрой /etc/audit/auditd.conf. Без корректного указания max_log_file и num_logs система забьёт /var и не моргнёт. Укажи: max_log_file = 50, num_logs = 10. Логи пиши только на отдельный том – иначе к чёрту все логи, если диск кончится. Лучше монтируй под /var/log/audit.

Пример: в /etc/fstab добавь строку монтирования для отдельного тома под аудит, если у тебя LVM:
/dev/mapper/vg0-audit /var/log/audit xfs defaults 0 0

Теперь правила. Не лезь сразу в /etc/audit/rules.d/audit.rules. Лучше сначала руками. auditctl работает без перезапуска. Тестируй.

Добавь слежение за попытками доступа к /etc/shadow:
auditctl -w /etc/shadow -p rwxa -k shadow_access

Это ключ. Ключ – фильтрация по тегу -k. Потом не найдёшь логи в кипе мусора. Используй осмысленные метки.

Важно: по умолчанию в Red OS лог пишется через rsyslog, но может не дублироваться в /var/log/messages. Проверяй конфиг /etc/rsyslog.conf.

Доступ root? Отслеживай через uid. Правило на мониторинг всех вызовов с UID 0:

auditctl -a always,exit -F uid=0 -F arch=b64 -S execve -k root_exec

И обязательно настрой ротацию: /etc/audit/auditd.conf → max_log_file_action = ROTATE. Иначе получишь фатальный стоп при переполнении. Да, оно так работает.

Внимание! Red OS не использует systemd-journald по умолчанию для этих логов. Не ищи их там. Только /var/log/audit/audit.log.

Ты либо контролируешь свои правила, либо утопаешь в событиях. Удали дефолтные шаблоны, если не понимаешь их назначения. Файл: /etc/audit/rules.d/. Оставь только своё. Один файл – один объект контроля. Удобнее масштабировать.

Хочешь пересобрать правила после редактирования? augenrules --load. Без этого ничего не применится. Проверка: auditctl -l.

Вот и всё. Работает – не трогай. Но будь готов к неожиданностям – audit не прощает ошибок. Логи врут редко. Люди – часто.

Установка и активация auditd в Red OS

Система без audit пакета – дырявая лодка. Проверь: rpm -q audit. Нет? Установи:

dnf install audit -y

Проверка наличия службы:

systemctl list-unit-files | grep auditd

Неактивна? Стартуем. Постоянно:

systemctl enable --now auditd

Проверь, что демон живой:

systemctl status auditd

Порой auditd не стартует из-за отсутствия /var/log/audit. Ручной костыль:

mkdir -p /var/log/audit && restorecon -R /var/log/audit

Проверка взаимодействия с ядром:

auditctl -s

Там должно быть enabled 1. Если 0, система не мониторит. Причина? Часто – параметр ядра. Добавь в /etc/default/grub:

GRUB_CMDLINE_LINUX="audit=1"

Обнови конфигурацию загрузчика:

grub2-mkconfig -o /boot/grub2/grub.cfg

После этого обязательно перезагрузи.

Важно! Некоторые версии Red OS отключают мониторинг событий на уровне ядра по умолчанию. Без audit=1 – логов не будет вообще. Проверяй всегда.

Проверь, пишет ли система логи туда, куда нужно:

ls -l /var/log/audit/audit.log

Нет файла – нет событий. Права должны быть root:root 0600. Любое отклонение – потенциальная компрометация.

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

ausearch -ts recent

Если пусто – проверяй правила, конфигурацию, SELinux и доступ к каталогу логов.

Помните: при использовании нестандартных ядер или минимальных установок audit может не иметь необходимых hook-ов. Всегда сверяйтесь с компиляцией ядра и параметрами bootloader.

Установлено. Работает. Логирует. Значит можно двигаться дальше.

Конфигурация правил аудита для слежения за изменением системных файлов

Начни с ядра. Оно должно мониторить события. Без него – тишина. Проверка:

auditctl -s

Далее – цель. Что мониторить? /etc/passwd? Да. /etc/shadow? Обязательно. /boot? Тоже. Вот правило:

auditctl -w /etc/passwd -p wa -k passwd_watch

Пояснение: -w – путь. -p – действия: w – запись, a – атрибут. -k – фильтр по ключу. Это не просто тэг. Это спасение при поиске.

Теперь /etc/shadow. Тут полная защита:

auditctl -w /etc/shadow -p rwa -k shadow_mod

Ловим всё. Даже попытку чтения. Потому что если кто-то читает – он уже рядом. Это не предупреждение. Это тревога.

Важно помнить: любые действия над этими файлами должны быть мгновенно зафиксированы. Даже попытка поменять права.

Добавь ядро и загрузчик. Файлы под угрозой – /boot/grub2/grub.cfg и /etc/default/grub:

auditctl -w /boot/grub2/grub.cfg -p wa -k grub_cfg_watch
auditctl -w /etc/default/grub -p wa -k grub_default_watch

Далее – служебные конфиги. /etc/ssh/sshd_config? Да. Один неверный параметр – и у тебя открыт root по паролю. Лови:

auditctl -w /etc/ssh/sshd_config -p wa -k sshd_conf

У тебя systemd? Тогда не забудь:

auditctl -w /etc/systemd/system -p wa -k systemd_units

Внимание! Не используйте абсолютный путь без указания прав -p. Иначе правило будет создано, но не сработает. Пропущенная буква – потерянный инцидент.

После проверки – сохранить. Все правила уносятся в файл:

/etc/audit/rules.d/system_watch.rules

Пример строки в файле:

-w /etc/shadow -p rwa -k shadow_mod

Не забудь перезагрузить правила:

augenrules --load

Проверка результата:

auditctl -l

Если правила не активны – ищи ошибку в синтаксисе. Один лишний пробел ломает всё.

Завёл правила – проверь на практике. Меняешь файл – логи должны появляться в:

/var/log/audit/audit.log

Поиск события по ключу:

ausearch -k shadow_mod

Там будет всё: кто, когда, как. И что именно он сделал. Без лишних слов. Только факты.

Настройка логирования действий пользователей с повышенными привилегиями

Цель ясна: отследить всё, что делает пользователь с UID 0. Команда:

auditctl -a always,exit -F arch=b64 -F euid=0 -S execve -k root_exec

Ты на 32-битной системе? Меняй arch=b64 на arch=b32. Или указывай оба варианта сразу:

auditctl -a always,exit -F arch=b32 -F euid=0 -S execve -k root_exec
auditctl -a always,exit -F arch=b64 -F euid=0 -S execve -k root_exec

execve – запуск любого исполняемого файла. Базовый контроль. Хочешь шире? Добавляй open, chmod, unlink. Но сначала – execve. Остальное потом.

UID – ненадёжно. Применяется SUID? Используй auid. Тогда улавливаются и действия через sudo:

auditctl -a always,exit -F arch=b64 -F auid=0 -S execve -k sudo_exec

Разница? Огромная. UID – это кто сейчас. AUID – кто начал сессию. Именно то, что нужно.

Важно помнить: auid присваивается при логине. Если его нет – правило ничего не поймает. Проверяй whoami и id при тестировании.

Примени фильтрацию по конкретным исполняемым:

auditctl -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=4294967295 -k passwd_exec

perm=x – именно исполнение. auid>=1000 – только реальные пользователи. auid!=4294967295 – фильтр по «unset» значению (anon).

Постоянное сохранение – файл:

/etc/audit/rules.d/root_activity.rules

Пример содержания:

-a always,exit -F arch=b64 -F euid=0 -S execve -k root_exec
-a always,exit -F arch=b64 -F auid=0 -S execve -k sudo_exec

Загрузка в ядро:

augenrules --load

Проверка:

auditctl -l

Проверка результата – вызови любой бинарь под root. Затем:

ausearch -k root_exec

Либо:

ausearch -k sudo_exec

Ты должен видеть: имя команды, полный путь, аргументы, PID, UID, AUID. Всё. Кто, что, когда, зачем. Без догадок.

Внимание! если AUID в логах отсутствует или равен -1, значит у тебя проблемы с PAM или сессия была создана некорректно. Без AUID – поломанная аналитика.

Каждое действие root теперь под прицелом. Ты либо это контролируешь, либо это контролирует тебя.

Автоматическая ротация и хранение логов аудита в соответствии с политиками безопасности

Файл /etc/audit/auditd.conf – центральный узел. Ошибёшься здесь – потеряешь всё. Читай внимательно. Не доверяй дефолтным значениям.

• max_log_file = 100 – размер одного журнала в МБ. Не больше. Не меньше. Зависит от частоты событий и длительности хранения.
• num_logs = 10 – количество архивов. Меньше – потеряешь след. Больше – забьёшь диск.
• max_log_file_action = ROTATE – критично. Иначе при переполнении: стоп. Полный. Без предупреждения.
• space_left = 200 – сработает при 200 МБ свободного пространства. Мало? Поднимай. Система должна жить.
• space_left_action = SYSLOG – лог в системный журнал. Добавь wall, если нужен крик в консоль.
• admin_space_left = 100 – второй порог. Уже серьёзно. Настрой реакцию.
• admin_space_left_action = SUSPEND – можно single, но это радикально. SUSPEND временно приостанавливает журналирование. Спасает от фатала.

Проверка через:

auditctl -s

Там должно быть disk_full_action = ROTATE. Если IGNORE – поздравляю. Ты слеп.

Внимание! Не храни журналы на том же разделе, где крутится ОС. Отдельный LVM или примонтированный каталог под /var/log/audit – твоя броня от обнуления системы.

Папка с архивами: /var/log/audit/. Формат файлов – audit.log, audit.log.1, audit.log.2 и так далее. Старые сжимаются – зависит от logrotate.

Проверь: файл /etc/logrotate.d/audit должен быть. Если нет – создай:

/var/log/audit/audit.log {
rotate 10
daily
missingok
notifempty
compress
delaycompress
postrotate
/sbin/service auditd reload > /dev/null 2>&1 || true
endscript
}

Хочешь ежечасную ротацию? Измени daily на hourly и перемести правило в /etc/logrotate.hourly/.

Помните: любое нарушение политики хранения журналов – автоматическая невалидность всей системы сбора событий. Нет истории – нет доверия.

Проверь права:

ls -l /var/log/audit/

Должно быть: root:root, 0600. Не 0644. Не 0666. Только 0600. Нарушил – открыл доступ.

Логи есть. Ротация работает. Архивы доступны. Значит ты контролируешь не только настоящее, но и прошлое. И это – уже повод спать чуть спокойнее.