auditd отвечает на вопрос «кто и каким процессом изменил объект», а не заменяет журнал приложения или мониторинг нагрузки. Для полезного аудита нужны точные правила, проверка события и контроль потерь. Ниже — процедура для Debian/Ubuntu на 64-битной системе: от лабораторного каталога до постоянных правил для конфигураций.
1. Определите задачу и доступные права
Архитектура: от syscall до расследования
Linux Audit — подсистема ядра и набор userspace-инструментов. Правила ядра выбирают интересующие операции; записи проходят через очередь и netlink в auditd; daemon сохраняет их в audit.log и может передавать плагинам. auditctl управляет runtime, augenrules собирает постоянные правила, ausearch реконструирует события, aureport строит отчёты. journald/syslog и audit.log не взаимозаменяемы: сообщение приложения и событие системного вызова фиксируют разные факты.
Правило файлового аудита сообщает о доступе/изменении объекта, но не хранит дифф его содержимого. FIM, backup, git для конфигураций и аудит дополняют друг друга. SIEM связывает событие с другими источниками, но не восстановит запись, потерянную до попадания в auditd. Поэтому полноценная настройка включает отбор, доставку, хранение, контроль потерь и процедуру поиска.
Модель угроз и стенд
Рецепты ниже рассчитаны на Debian 13 с systemd и x86_64, для b64-процессов. Для Ubuntu пути в целом сходны; RHEL/Alma/Rocky могут отличаться процедурой управления сервисом и расположением плагинов. На ARM не копируют автоматически b32-пары x86. Нужны sudo, консоль и отдельная тестовая VM. В immutable-режиме изменение возможно только через плановую перезагрузку с заранее подготовленной конфигурацией.
Сначала выберите расследуемые вопросы: кто изменил sudoers, какая login identity запустила root-команду, какой процесс поменял systemd unit, почему был отказ доступа. Затем для каждого вопроса определите событие, поля, ключ, допустимую нагрузку и срок хранения. Универсальный аудит каждого read/write всего сервера обычно даёт поток, который невозможно полезно разобрать.
Сохраните состояние без раскрытия содержимого секретов
sudo install -d -o root -g root -m 700 /root/avg-audit-backup
sudo cp -a /etc/audit /root/avg-audit-backup/audit-before
sudo sh -c 'auditctl -s > /root/avg-audit-backup/status-before.txt'
sudo sh -c 'auditctl -l > /root/avg-audit-backup/runtime-before.txt'
findmnt /var/log/audit
uname -rКаталог backup должен быть новым либо содержать отдельно датированную копию; повторный cp поверх истории не заменяет версионирование. Сохраняем настройки и правила, не копируем /etc/shadow в публичный отчёт. Для расследования важны версия ядра, архитектура, boot и локальное время: event serial может повторяться после перезагрузки.
Выберите конкретные объекты: SSH-конфигурация, локальные учётные записи, sudoers или настройки важного сервиса. Правило «логировать все системные вызовы» создаёт огромный поток и затрудняет поиск. Для каждой группы событий задайте ключ, срок хранения и ответственного за разбор.
Аудит ядра хоста не равен запуску auditd внутри обычного контейнера. Контейнер может не иметь CAP_AUDIT_CONTROL и не управляет отдельным независимым ядром. Настройку выполняют на хосте; контейнерный процесс затем связывают с событиями доступными средствами среды.
Перед изменениями сохраните действующие /etc/audit и список runtime-правил в закрытый backup. Команда auditctl требует административных прав. В production сначала определите, кто управляет аудитом: вручную, конфигурационным менеджером, агентом защиты или централизованным профилем. Параллельные источники правил могут перезаписывать друг друга.
2. Установите auditd и проверьте состояние
sudo apt-get update
sudo apt-get install auditd
systemctl status auditd --no-pager
sudo auditctl -s
sudo auditctl -l
uname -mВ auditctl -s важны enabled, pid, lost и backlog. enabled=1 означает включённый изменяемый аудит, enabled=2 — immutable; изменить правила до перезагрузки нельзя. pid=0 означает отсутствие работающего userspace daemon. lost — накопленный счётчик потерянных записей, backlog — текущая очередь.
Документация auditctl объясняет эти поля. Не обнуляйте lost перед фиксацией исходного состояния. Ненулевое историческое значение требует сравнения динамики; рост во время теста показывает актуальную потерю. Если встретилось правило never,task или другие исключения, сначала выясните их владельца и влияние — новое exit-правило может не дать ожидаемых событий.
Прочитайте состояние, прежде чем добавлять правила
enabled 1
failure 1
pid 742
rate_limit 0
backlog_limit 8192
lost 0
backlog 0Это пример формата, не результат измерения вашего сервера. enabled=1 допускает изменение, 2 блокирует его до reboot, 0 означает отключенный аудит. failure задаёт поведение при сбоях подсистемы, pid относится к daemon. rate_limit=0 снимает ограничение скорости ядра, но не даёт бесконечной производительности записи. backlog_limit — предел очереди, backlog — её текущая занятость, lost — счётчик потерянных записей.
Если enabled=2, сначала согласуйте перезагрузку и изменение профиля, а не пробуйте многократную загрузку. Если pid=0, разберите журнал auditd и конфигурацию. Если lost увеличивается, успешный поиск одного события не подтверждает полноту аудита. Не сбрасывайте lost перед замером: значение до/после и время интервала дают диагностический смысл.
Найдите конфликтующие исключения
sudo auditctl -l
sudo grep -R -n -- 'never,task\|never,exit\|-e 2' /etc/audit/rules.d
systemctl cat auditdnever,task может отключать syscall-аудит для новых tasks; более ранние never-правила влияют на результат отбора. Разберитесь, какой профиль создал исключение. Если владелец подтверждает удаление именно default -a never,task в пилоте, точное runtime-действие — sudo auditctl -d never,task; соответствующую постоянную строку меняют отдельной управляемой правкой. Не используйте глобальный -D ради того, чтобы увидеть тестовый event. Существующие процессы и особенности среды требуют повторной проверки после изменения.
3. Создайте минимальное лабораторное правило
Пример ниже предназначен для 64-битных процессов и каталога /srv/audit-lab, который создаётся специально для теста. Сначала убедитесь, что он не используется приложением. Используется syscall-фильтр dir/perm; старый краткий синтаксис -w поддерживается, но для новых конфигураций предпочтителен более явный фильтр.
sudo install -d -m 700 /srv/audit-lab
sudo auditctl -a always,exit -F arch=b64 -F dir=/srv/audit-lab -F perm=wa -F key=avg_lab
sudo auditctl -l -k avg_lab
sudo touch /srv/audit-lab/probe.txt
sudo chmod 600 /srv/audit-lab/probe.txt
sudo ausearch -k avg_lab -ts recent -iperm=w отслеживает записи, perm=a — изменения атрибутов. Ключ объединяет события по назначению. Каталог должен существовать при загрузке правила. Фильтр не следует считать автоматическим охватом любых будущих файловых систем, смонтированных под ним: переходы и bind mounts проверяют отдельно.
Если событий нет, проверьте runtime-правило, исключения, immutable, реальный путь и архитектуру процесса. Для 32-битных программ на поддерживающем их x86_64-хосте потребуется отдельное arch=b32 правило. Не копируйте его без проверки поддержки на любой ARM-сервер.
Разберите правило по полям
-a always,exit добавляет правило в список проверки выхода из syscall. -F arch=b64 выбирает таблицу системных вызовов нужной архитектуры. dir ограничивает дерево каталога, perm=wa — запись и изменение атрибутов, key помечает событие для поиска. В таком файловом фильтре auditctl подбирает нужные syscalls по perm; arch указывают раньше их выбора. Для отдельного syscall -S пишут после arch.
Фильтрация path/dir эффективнее бесконтрольного аудита всего openat. Каталог должен существовать. При bind mount, отдельной смонтированной файловой системе и контейнерном mount namespace фактическое покрытие подтверждают экспериментом. Аудит дерева не означает автоматическое покрытие всего содержимого любого будущего mount под этим путём. Семантика правил — в документации проекта Linux Audit.
Сравните syscall и файловую операцию
Один touch может выполнить несколько системных вызовов; chmod может породить другое событие с тем же key. Количество строк audit.log не равно количеству действий пользователя. Для теста разделите создание и изменение атрибутов, отметьте время и ищите полные события, а не только PATH. Ошибка Operation not permitted при auditctl может быть следствием immutable или отсутствия CAP_AUDIT_CONTROL, а не неверного каталога.
4. Прочитайте событие как связанную группу записей
Одно действие может породить SYSCALL, PATH, CWD и PROCTITLE с общим event id. Отдельная строка PATH без остальных записей не показывает всю операцию. ausearch связывает их по событию; -i преобразует часть числовых значений в удобные имена.
Обращайте внимание на success, exit, syscall, exe, pid, uid/euid и auid. uid/euid показывают текущие права процесса, auid — исходную login identity, если она назначена. После sudo текущий euid может быть root, а auid сохранять личность вошедшего пользователя. Для сервисов auid может быть unset: не приписывайте их запуск конкретному сотруднику автоматически.
sudo ausearch -k avg_lab -ts recent --raw
sudo ausearch -k avg_lab -ts recent -i
sudo aureport -f --summary -iСобытия фиксируют метаданные операции, не обязательно прежнее и новое содержимое файла. Для восстановления текста нужен backup или управление конфигурацией. В PROCTITLE и аргументах процессов могут быть чувствительные данные; пароли не передают в командной строке, а доступ к аудиту ограничивают.
Пример события с разбором каждого поля
type=SYSCALL msg=audit(1791691200.123:812): arch=c000003e syscall=257 success=yes exit=3 ppid=1700 pid=1701 auid=1000 uid=0 gid=0 euid=0 tty=pts0 exe="/usr/bin/touch" key="avg_lab"
type=CWD msg=audit(1791691200.123:812): cwd="/home/admin"
type=PATH msg=audit(1791691200.123:812): item=0 name="/srv/audit-lab/probe.txt" inode=12345 nametype=CREATEВывод иллюстративный, часть полей опущена. Общие timestamp и serial 812 связывают записи. arch=c000003e соответствует x86_64; syscall=257 в этой таблице — openat. При success=yes exit=3 означает возвращённый дескриптор, а не код ошибки 3. При неудаче exit может быть отрицательным errno, например -13/EACCES. ausearch -i интерпретирует значения, но исходные --raw сохраняют для доказательств.
uid/euid=0 означает текущий root-контекст, auid=1000 — исходную login identity, сохранённую после sudo при правильной настройке входа. Поле unset не обозначает «анонимного злоумышленника»: так могут работать штатные daemon. exe — исполняемый файл процесса, comm — короткое имя, PROCTITLE/EXECVE — аргументы. Ни одно отдельное поле не устанавливает личность человека без сопоставления с SSH/PAM, временем и источником подключения.
sudo ausearch -a 812 -ts today --raw
sudo ausearch -k avg_lab -ts today -m SYSCALL -i
sudo aureport --login --summary -i
sudo aureport --executable --summary -i812 заменяют serial конкретного теста. Ищите в ограниченном интервале и с известного хоста/boot: serial не является глобальным UUID. -m фильтрует типы, поэтому для сохранения полного события после нахождения serial повторите поиск без такого ограничения. Отчёт --executable показывает частоту исполняемых файлов, а не автоматически вердикт вредоносности.
Чего не видно в событиях
Audit не гарантирует запись содержимого файла, вывода программы и всех данных сетевой сессии. Аргументы shell-команды могут раскрывать секреты, поэтому даже без TTY-аудита журнал требует ограничений доступа. Не передавайте API-токен через curl -H в общей командной строке, если этот exec собирается централизованно. Для разбора сохраняют оригинал в закрытый архив, наружу предоставляют редактированную копию.
5. Подготовьте постоянные правила для конфигураций
После успешного лабораторного теста создайте отдельный root-owned файл /etc/audit/rules.d/50-avg-config.rules. До записи проверьте наличие всех путей. Для Debian/Ubuntu можно использовать следующий профиль 64-битных процессов:
-a always,exit -F arch=b64 -F path=/etc/passwd -F perm=wa -F key=avg_accounts
-a always,exit -F arch=b64 -F path=/etc/group -F perm=wa -F key=avg_accounts
-a always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -F key=avg_accounts
-a always,exit -F arch=b64 -F path=/etc/gshadow -F perm=wa -F key=avg_accounts
-a always,exit -F arch=b64 -F path=/etc/sudoers -F perm=wa -F key=avg_privileges
-a always,exit -F arch=b64 -F dir=/etc/sudoers.d -F perm=wa -F key=avg_privileges
-a always,exit -F arch=b64 -F dir=/etc/ssh -F perm=wa -F key=avg_sshПрофиль намеренно не исключает uid=0 и auid=unset: изменение конфигураций сервисом или root тоже важно. Это не глобальный аудит исполнения всех команд. Проверка только чтения shadow в данный профиль не входит; добавление perm=r резко меняет объём и требует отдельной оценки.
Изменяемый файл базы учётных записей может быть заменён новым inode при штатной операции. Поэтому после реального изменения и обновления пакетов проверяйте фактическое событие, а не только наличие текстовой строки правила. Ключи avg_* помогают отличить ваш профиль от чужого.
Добавьте контролируемый аудит привилегированных действий
Следующие строки — отдельный расширенный профиль x86_64, дополняющий наблюдение конфигураций. UID_MIN сначала получите через awk '$1=="UID_MIN" {print $2}' /etc/login.defs; в примере он 1000. Для SSSD/AD диапазон и фактический auid проверяют отдельно.
-a always,exit -F arch=b64 -S execve,execveat -F euid=0 -F auid>=1000 -F auid!=unset -F key=avg_root_exec
-a always,exit -F arch=b64 -F dir=/etc/systemd/system -F perm=wa -F key=avg_systemd
-a always,exit -F arch=b64 -F dir=/etc/cron.d -F perm=wa -F key=avg_cron
-a always,exit -F arch=b64 -F path=/etc/crontab -F perm=wa -F key=avg_cronExec-правило ловит root-execution из пользовательской login session. Оно не охватывает прямой вход root с auid=0 и сервисы с unset: это сознательный отбор, который надо отразить в модели угроз. Для прямого root-входа нужен дополнительный профиль, а лучше исключить такой вход организационно. Оно фиксирует аргументы, поэтому перед массовым включением оцените чувствительность и объём событий. Повседневный sudo -l может дать события, но не подтверждает выполнение разрешённого задания.
Для отслеживания cron spool на Debian отдельно проверяют путь /var/spool/cron/crontabs и существование каталога. Unit может быть установлен в /usr/lib/systemd/system, а runtime-создание — в /run/systemd/system: только /etc недостаточно для полного вопроса о persistence. Дополнительные директории выбирают по вашей ОС, не считают приведённые четыре строки исчерпывающими.
Отслеживайте отказ доступа в узкой области
-a always,exit -F arch=b64 -S openat -F dir=/srv/audit-lab -F exit=-EACCES -F key=avg_denied
-a always,exit -F arch=b64 -S openat -F dir=/srv/audit-lab -F exit=-EPERM -F key=avg_deniedЭти правила ограничены тестовым деревом. Они не поймают любой отказ любого syscall: программу, использующую openat2 или другой способ доступа, проверяют отдельно по поддерживаемой таблице syscalls. EACCES и EPERM не взаимозаменяемы. Для глобального расследования можно временно расширить отбор, но сначала замеряют поток; постоянный аудит всех неуспешных openat на нагруженном сервере может оказаться дорогим.
Почему нужны b32-пары и когда они лишние
На x86_64 32-битный процесс использует другую таблицу syscall numbers. Если приложение реально использует compat ABI, добавьте соответствующие b32-строки после проверки поддержки. Пара b64+b32 не нужна только потому, что процесс «старый»: проверьте бинарник через file и реальное событие. На архитектуре без этого ABI неподдерживаемая строка может сорвать загрузку профиля.
6. Загрузите правила и проверьте постоянство
Сохраните копию прежнего файла, если он уже существовал, и установите владельца root:root, режим 600. augenrules собирает несколько .rules в общий набор. Его справка описывает порядок обработки; директивы -D и -e могут влиять на итоговую загрузку.
sudo chown root:root /etc/audit/rules.d/50-avg-config.rules
sudo chmod 600 /etc/audit/rules.d/50-avg-config.rules
sudo augenrules --check
sudo auditctl -s
sudo augenrules --load
sudo auditctl -lПеред --load изучите действующий общий профиль и исключения. Не вставляйте в свой файл -D: это удалит чужие правила. Не добавляйте -e 2 на этапе пилота: immutable потребует перезагрузки для дальнейших изменений. Загрузка при immutable будет отвергнута; обходить это отключением защиты нельзя.
После согласованной перезагрузки стенда повторите auditctl -l и лабораторный тест. Runtime-правило, добавленное вручную, исчезает после перезапуска; постоянный .rules должен восстановиться штатной загрузкой. Для систем, использующих иной загрузчик, следуют именно его процедуре, не создают второй независимый механизм.
Проверьте сборку правил, а не только свой файл
sudo augenrules --check
sudo sed -n '1,220p' /etc/audit/audit.rules
sudo auditctl -s
sudo augenrules --load
sudo auditctl -l -k avg_accounts
sudo auditctl -l -k avg_root_execaugenrules собирает .rules в установленном порядке и специально обрабатывает управляющие директивы. --check показывает различие конфигурации, но не является полноценным dry-run всех syscalls ядра. После --load обязательно смотрят код возврата, журнал и runtime. Ошибка «path does not exist» требует исправить путь или подготовить выбранный объект; нельзя игнорировать последующую неполную загрузку.
Если действующий полный профиль содержит -D, его очередная загрузка может очистить runtime и восстановить только собранные файлы. Это допустимо лишь как процедура владельца всего профиля, не как незаметный побочный эффект добавления одной статьи. Сравните сохранённые runtime-before с новым списком и убедитесь, что чужие правила не исчезли.
Immutable -e 2 включают последним после приёмки и подготовки следующего окна изменения. Он затрудняет изменение правил из работающей системы, но не делает root-компрометацию невозможной и не защищает диск от offline-изменения. Kernel audit=1 помогает охвату ранней загрузки; изменение cmdline, audit_backlog_limit и reboot относится к отдельной подготовке хоста, не к повседневной загрузке .rules.
7. Выполните позитивный и негативный тест
Для лаборатории проверьте запись и chmod внутри наблюдаемого каталога, затем запись в отдельный необслуживаемый каталог. Под ключом avg_lab должно появляться первое действие; второе не должно порождать событие именно этого ключа. Иные действующие правила могут его зарегистрировать — это нормально.
Для production-конфигураций тест проводится штатным согласованным изменением, например через управляемую настройку сервиса. Не меняйте shadow ради «проверки логирования» и не создавайте случайный sudoers-файл. Проверяйте время, exe, результат и идентичность инициатора; события успеха и отказа не смешивайте.
Если аудит не охватывает 32-битный клиент, добавьте необходимую b32-пару только на поддерживаемой архитектуре и повторите тест. Если пользователь приходит через SSSD/LDAP, локальный /etc/passwd не отражает изменения каталога: аудит хоста и аудит AD решают разные задачи.
Воспроизводимый позитивный и негативный сценарий
sudo touch /srv/audit-lab/avg-positive.txt
sudo chmod 640 /srv/audit-lab/avg-positive.txt
sudo install -d -m 700 /srv/audit-outside
sudo touch /srv/audit-outside/avg-negative.txt
sudo ausearch -k avg_lab -ts recent -i
sudo auditctl -sВ avg_lab ожидаются positive и chmod, но не negative. Проверяйте полное имя PATH и exe, а не только количество событий: во время теста могут происходить другие операции. Запись negative может появиться под иным ключом действующего профиля — это не ошибка лабораторного фильтра. Поток должен иметь связные группы записей, success=yes и ожидаемый путь.
Для проверки auid зайдите на VM по SSH личным тестовым пользователем и выполните через sudo безвредный touch в лаборатории. В событии ожидаются euid=0 и auid этого пользователя. Запуск из cron или root-консоли не воспроизводит этот путь. Негативный тест denied требует закрытого каталога и чтения из непривилегированного контекста; делайте его на отдельном каталоге, не лишайте прав приложение.
После теста снимите lost/backlog повторно, сравните с исходным состоянием и убедитесь в доставке на collector. Вывод no matches может означать неверный временной фильтр/ключ, отсутствие события или неработающий аудит; он сам по себе не говорит, какой из вариантов верен.
8. Настройте хранение и контроль заполнения
В /etc/audit/auditd.conf оцените log_file, max_log_file, num_logs, max_log_file_action и действия при нехватке места. Политика ROTATE оставляет ограниченное число файлов, KEEP_LOGS может заполнить раздел, а остановка/перевод системы в аварийный режим влияет на доступность. Справка auditd.conf нужна для осознанного выбора.
Не задавайте универсально disk_full_action=HALT или kernel failure mode=panic для обычного файлового сервера. Это проектное решение по модели угроз и доступности, а не обязательный флаг каждого аудита. Уведомления о заполнении и потерях должны приходить до критической стадии.
df -h /var/log/audit
sudo du -sh /var/log/audit
sudo auditctl -s
sudo journalctl -u auditd --since '-1 hour' --no-pagerКонтролируйте рост lost между измерениями, backlog в нагрузке, свободное место и возраст последнего события. Зелёный service auditd не доказывает отсутствие потерь. Оповещение только о заполнении диска пропускает переполнение очереди ядра.
Рассчитайте хранение и настройте действия при заполнении
Сначала замерьте суточный объём под типичной нагрузкой и при обновлениях. Если поток 50 MiB/час, сутки дадут примерно 1,2 GiB; семь суток — 8,4 GiB без запаса. Число строк в минуту не заменяет байтовый объём: одно exec может иметь длинные аргументы. Выделите отдельную ёмкость, запас для недоступного collector и пороги оповещения.
Пример лабораторного, ограниченного хранением профиля для отдельного раздела не менее нескольких GiB:
log_file = /var/log/audit/audit.log
log_format = RAW
flush = INCREMENTAL_ASYNC
freq = 50
max_log_file = 128
num_logs = 8
max_log_file_action = ROTATE
space_left = 1024
space_left_action = SYSLOG
admin_space_left = 512
admin_space_left_action = SYSLOG
disk_full_action = SUSPEND
disk_error_action = SYSLOGЗначения размеров — MiB по документации выбранной версии. Восемь файлов по 128 MiB дают примерно 1 GiB локального бюджета, не семь суток для приведённого потока. SYSLOG лишь сообщает; если оповещения не собираются, политика фактически молчит. SUSPEND при полном диске останавливает запись аудита, поэтому это явный компромисс лаборатории; production определяет, допустимо ли продолжить обслуживание без аудита или требуется аварийная остановка. Документация параметров — auditd.conf.
После изменения перечитайте настройки поддерживаемым способом вашей версии (sudo auditctl --signal reload, если эта опция присутствует в локальной man-странице), проверьте журнал и состояние. В некоторых дистрибутивах auditd запрещает обычный systemctl restart и требуется штатный service wrapper. Не выключайте защиту сервиса для обхода этой процедуры.
Контролируйте очередь и потери
Снимайте auditctl -s при нормальной и пиковой нагрузке. Рост backlog показывает задержку обработки; рост lost — уже потерянные записи. Увеличение backlog_limit даёт буфер, но не ускоряет диск и collector. Rate limit может ограничить нагрузку ценой потерь. Failure mode panic влияет на доступность всего хоста и выбирается только осознанно, а не как обязательный «hardcore» флаг.
9. Передавайте события и сохраняйте проверяемость
Централизованный сбор уменьшает зависимость расследования от скомпрометированного хоста. Используйте поддерживаемый вашей системой агент или audisp-плагин с проверенным транспортом и аутентификацией. Локальная копия должна сохраняться в соответствии с политикой даже при недоступном collector.
Сквозной тест: создать известное лабораторное событие, найти его локально, затем на collector по хосту, ключу, времени и event id. Проверьте часовой пояс и синхронизацию времени. Склейка отдельных строк без общего event id может исказить контекст.
Шифрование сети не делает архив неизменяемым. Для важных журналов отдельно проектируют права, срок хранения и защиту удаления на сервере сбора. Не включайте запись TTY «для полноты» без оценки: она может захватывать ввод, который не должен попасть в общий журнал.
Пример центрального сбора существующим Wazuh-agent
Если на стенде уже установлен и зарегистрирован Wazuh-agent, проверьте, нет ли такого источника в ossec.conf или центральной конфигурации. Внутри существующего ossec_config добавьте один localfile:
<localfile>
<log_format>audit</log_format>
<location>/var/log/audit/audit.log</location>
</localfile>Формат audit предназначен для этого журнала; описание — справочник Wazuh localfile. После проверки XML и backup конфигурации перезапустите только агент и изучите /var/ossec/logs/ossec.log. Это дополнение к уже действующему сбору, не полный мастер установки SIEM. Доступ агента к журналу должен быть предусмотрен его моделью прав; chmod 777 audit.log не является решением.
sudo systemctl restart wazuh-agent
sudo systemctl status wazuh-agent --no-pager
sudo tail -n 40 /var/ossec/logs/ossec.log
sudo touch /srv/audit-lab/avg-collector-test.txt
sudo ausearch -k avg_lab -ts recent --rawНа collector найдите event по hostname/agent, key, времени и serial, сопоставьте PATH и SYSCALL. Не каждый полученный event становится alert: правила корреляции и хранение всех событий на менеджере настраиваются отдельно. Отсутствие предупреждения в dashboard не доказывает отсутствие доставки. Для проверки разбора используют существующую процедуру logtest менеджера и исходный sample без секретов.
Испытайте недоступность collector
На отдельном стенде временно оборвите только канал агента, создайте несколько маркеров, восстановите канал и проверьте, какие события дошли и как изменились локальные очереди. Не предполагается бесконечная offline-буферизация. Локальная ротация может удалить исходные события раньше восстановления. audisp-remote — альтернативный путь со своей очередью, аутентификацией и транспортом; его параметры не взаимозаменяемы с Wazuh.
Для защищённого архива нужны отдельные права удаления, сроки хранения, резервная копия и проверка целостности. Один SHA256 фиксирует текущее содержимое, но не доказывает, что до его вычисления журнал не меняли. Доверие к доказательству строится на цепочке получения и хранении вне контролируемого подозреваемым хоста.
10. Возврат правил и приёмка
Для удаления лабораторного runtime-правила используйте точное обратное действие, сохранив все параметры:
sudo auditctl -d always,exit -F arch=b64 -F dir=/srv/audit-lab -F perm=wa -F key=avg_lab
sudo auditctl -l -k avg_labДля постоянного профиля восстановите исходный принадлежащий вам файл и согласованно перезагрузите правила. Не используйте auditctl -D без ограничения и анализа полного профиля: это затронет весь аудит. В immutable-режиме планируют допустимую перезагрузку; конфигурацию нельзя изменить незаметным обходом.
Приёмка включает сохранение правил после reboot, правильное тестовое событие, отсутствие роста lost, проверку заполнения и доставку на collector. В результате должен получиться управляемый журнал действий, а не просто установленный пакет auditd.
Приёмка и безопасное сопровождение
Сохраните таблицу покрытия: вопрос → правило → положительный тест → отрицательный тест → ключ → срок хранения. Для root execution отдельно запишите исключения auid=0/unset и compat ABI. Для файлового аудита отметьте отдельные mounts и пути. После обновления auditd/ядра повторите несколько контрольных сценариев: парсер, поддержка syscall и загрузчик правил могут измениться.
Возврат собственного постоянного файла не всегда удаляет его уже загруженные runtime-правила. Поэтому сначала фиксируют текущий профиль, удаляют точные принадлежащие пилоту правила обратными -d-командами либо используют согласованную загрузку владельца полного профиля. В immutable готовят файлы и плановую перезагрузку. Нельзя просто удалить .rules и объявить аудит возвращённым.
Результат качественной настройки — объяснимое событие с корректной login identity и путём, сохранённое локально и централизованно, измеренный поток без роста lost и воспроизводимая процедура изменения. Установленный пакет, зелёный service и большой набор правил отдельно не дают этой гарантии.