Безопасность сервера / Ступень 9 из 10 · шаг 5 из 6

Конфиг меняется сам

~20 мин

Не запущена Запускается обычно ~20 с

Ситуация

Портал компании читает настройки из /etc/portal/portal.conf. Утром в нём оказались debug = true, открытая регистрация и адрес чужой базы. Ты вернул рабочие настройки — через минуту файл снова стал прежним:

cat /etc/portal/portal.conf
ls -l /etc/portal/portal.conf

Писать в конфиг может группа portal — разработчики и учётная запись выкатки. В твоём crontab -l пусто, в /etc/cron.d — только резервная копия настроек.

Задача

Поставь правило аудита на запись в /etc/portal/portal.conf. Правило действует сейчас и лежит в /etc/audit/rules.d — переживёт перезагрузку.
По событиям аудита найди, кто переписывает конфиг. Запиши в ~/culprit.txt одной строкой имя пользователя и полный путь программы, которая пишет в файл.
Сними это задание с расписания.
Остальное оставь как было: cron работает, другие задания пользователей и резервная копия на месте, у группы portal сохраняется запись в конфиг.

Интернета на машине нет, всё нужное уже установлено. Команды администратора запускай через sudo.

Цели лабы

0 из 4

Правило аудита следит за записью в /etc/portal/portal.conf — действует сейчас и лежит в /etc/audit/rules.d — ещё не проверялась
В ~/culprit.txt — пользователь и полный путь программы, которая пишет в конфиг — ещё не проверялась
Задание, которое меняет конфиг, снято с расписания — ещё не проверялась
Остальное как прежде — cron работает, другие задания и резервная копия на месте, у группы portal есть запись в конфиг — ещё не проверялась

Подсказки

открыто 0 из 3 · открываются по одной

Подсказка 1

Показать решение после 3 неудачных проверок

Для запуска машины нужен вход

Машина запускается на твой аккаунт, там же хранится прогресс. Читать можно без входа.

После входа вернёшься на эту лабу.

Безопасность · подобрано по лабе

auditd — аудит безопасности

Шпаргалка

$_ — вставить в терминал

sudo auditctl -w /etc/passwd -p wa -k passwd_changes watch файла
sudo auditctl -a always,exit -F arch=b64 -S execve -F euid=0 -k root_cmd
sudo auditctl -l текущие правила
sudo auditctl -s статус подсистемы
sudo ausearch -k passwd_changes -i по ключу, читаемо
sudo aureport --summary
постоянно: /etc/audit/rules.d/*.rules → augenrules --load

Демон настраивается /etc/audit/auditd.conf — это не то же самое, что правила аудита (они в rules.d, см. «Рецепты»).

log_file = /var/log/audit/audit.log
max_log_file = 8                  # МБ, порог ротации
max_log_file_action = ROTATE     # ROTATE · KEEP_LOGS · SUSPEND · SYSLOG
num_logs = 5
space_left_action = SYSLOG        # реакция на нехватку места на диске
admin_space_left_action = SUSPEND

Применить изменения:

bash

sudo systemctl restart auditd     # перечитать auditd.conf
sudo auditctl -s                  # потерь нет

Важно. max_log_file_action = SUSPEND и admin_space_left_action = SUSPEND останавливают запись событий при переполнении диска — так compliance-система скорее замолчит, чем потеряет события молча. Для менее строгих требований бери ROTATE/SYSLOG; выбор — компромисс между надёжностью аудита и доступностью.

Правила: watch и syscall

bash

# watch файла/каталога: -p = права (r=read w=write x=exec a=attr)
sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo auditctl -w /etc/sudoers -p wa -k sudoers
sudo auditctl -w /etc/ssh/sshd_config -p wa -k sshd_conf

# syscall-правила (-a always,exit): ловить действия
sudo auditctl -a always,exit -F arch=b64 -S execve -F euid=0 \
  -k root_cmd                     # команды root
sudo auditctl -a always,exit -F arch=b64 -S unlink,unlinkat \
  -F dir=/etc -k etc_delete

sudo auditctl -l                  # текущие правила
sudo auditctl -D                  # удалить все (временно)
# постоянно — /etc/audit/rules.d/*.rules + sudo augenrules --load
# запрет правок правил до ребута: последнее правило -e 2

Поиск событий

bash

sudo ausearch -k passwd_changes           # по ключу (-k)
sudo ausearch -k passwd_changes -i        # -i: имена вместо чисел
sudo ausearch -f /etc/passwd -ts today    # по файлу за сегодня
sudo ausearch -ui 1000 -ts recent         # по UID за последние 10 мин
sudo ausearch -m USER_LOGIN --start today # по типу события (логины)
sudo aureport --summary                   # сводный отчёт
sudo aureport -au                         # отчёт по аутентификациям
sudo aureport -f -i                       # отчёт по файловым событиям

Разбор события

На учебной машине служба auditd выключена: sudo systemctl enable --now auditd. Правило -w /etc/demo.conf -p wa -k democonf поймало запись в файл из задания cron пользователя deploy. Одно событие — несколько записей с общим номером; главные — PROCTITLE и SYSCALL:

text

student@ubuntu:~$ sudo ausearch -k democonf -i \
> | grep -E '^type=(SYSCALL|PROCTITLE)'
type=PROCTITLE msg=audit(10/21/26 05:49:01.453:288) :
  proctitle=/bin/sh /usr/local/bin/tweak.sh
type=SYSCALL msg=audit(10/21/26 05:49:01.453:288) : arch=x86_64
  syscall=openat success=yes exit=3 … auid=deploy uid=deploy gid=deploy
  euid=deploy … tty=(none) ses=4 comm=tweak.sh exe=/usr/bin/dash
  subj=unconfined key=democonf

Поле	Что значит
`auid`	кто вошёл в систему — не меняется ни после `sudo`, ни после `su`
`uid`, `euid`	от чьего имени работал процесс в этот момент
`comm`	имя процесса (15 символов)
`exe`	исполняемый файл; у скрипта — интерпретатор, здесь `dash`
`proctitle`	командная строка целиком — у скрипта в ней его путь
`tty`, `ses`	терминал и номер сеанса входа; у cron терминала нет
`key`	ключ правила из `-k`

auid у задания cron — владелец crontab: cron открывает ему сеанс через PAM (pam_loginuid). Запись через sudo sh -c 'echo … >> /etc/demo.conf' даёт uid=root, а auid — того, кто вошёл; у процессов без входа в систему (службы, команды через гостевой агент) auid=unset. Сводка по файлам — aureport -f -i:

text

# date time file syscall success exe auid event
1. 10/21/26 05:48:29 /etc/ openat yes /usr/bin/dash unset 279
2. 10/21/26 05:49:01 /etc/ openat yes /usr/bin/dash deploy 288

Постоянные правила: rules.d

bash

echo '-w /etc/demo.conf -p wa -k democonf' \
  | sudo tee /etc/audit/rules.d/demo.rules
sudo augenrules --load
sudo auditctl -l

augenrules собирает /etc/audit/audit.rules из всех файлов rules.d/*.rules и загружает в ядро; при старте auditd делает то же. Правило, вписанное прямо в audit.rules, при следующем augenrules --load пропадает: файл пересобран, в auditctl -l правила нет. Читает audit.rules только root. augenrules --load печатает состояние подсистемы (enabled 1, backlog …) — это не ошибка.

Кто изменил важный файл?

Поставь watch (auditctl -w файл -p wa -k метка), затем ausearch -k метка -i → uid/команда/время. Для уже случившегося (watch не стоял) — событий нет, аудит не ретроактивен. Поэтому ключевые watch ставят заранее (в rules.d).

Слишком много событий / шум / потери (lost)

auditctl -s покажет lost/backlog. Делай узкие правила (конкретные файлы/syscall/ ключи), подними -b (backlog), следи за размером /var/log/audit/ (своя ротация в auditd.conf: max_log_file, num_logs).

Правила пропали после ребута

auditctl -w/-a временно. Постоянные — /etc/audit/rules.d/*.rules, применяются augenrules --load (или при старте auditd).

Не могу изменить/удалить правила

Включён immutable-режим (-e 2) — правила залочены до перезагрузки (это by design для защиты от подмены).

auditd vs journald

journald — операционные логи служб (journalctl); auditd — кто-что-сделал для безопасности (неизменяемый след). Разные подсистемы.

Отказы AppArmor пропали из journalctl -k

Пока auditd работает, сообщения аудита ядра, в том числе apparmor="DENIED", уходят ему и пишутся в /var/log/audit/audit.log (type=AVC), а в journalctl -k новых строк нет. Ищи их sudo ausearch -m AVC -i (см. apparmor).