Обычная история команд в Linux не всегда помогает понять, что произошло на сервере. Файл
history можно очистить, команды могут выполняться через скрипты, а некоторые действия вообще выполняются не через shell.Для контроля изменений файлов и действий пользователей используется
auditd. Он работает на уровне системного аудита и позволяет увидеть, какой процесс выполнил операцию и какой пользователь был связан с этим действием.Проверяем состояние службы аудита:
systemctl status auditd
Добавим правило для отслеживания изменений файла конфигурации SSH:
sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config
Параметр
-w указывает файл или каталог, за которым нужно следить. Опция -p wa означает отслеживание записи в файл (w) и изменения его атрибутов (a). Ключ -k добавляет идентификатор правила, по которому потом удобно искать связанные события.Теперь изменим файл:
vim /etc/ssh/sshd_config
И найдём связанные события аудита:
sudo ausearch -k ssh_config -i
В выводе можно увидеть информацию о процессе и пользователе:
type=SYSCALL
comm="vim"
exe="/usr/bin/vim"
uid=1000
auid=1000
success=yes
Поле
exe показывает, какой процесс выполнял действие. uid показывает пользователя, от имени которого выполнялся процесс, а auid — пользователя, который изначально вошёл в систему. Это важно, потому что при использовании sudo процесс может выполняться от имени root, но исходный пользователь будет сохранён в auid.Например:
ivan -> sudo vim /etc/ssh/sshd_config
uid=0
auid=1000
Теперь видно, что действие выполнялось с правами root, но инициировал его пользователь
ivan.Например, нужно понять, кто изменил или удалил файл приложения:
sudo auditctl -w /opt/app/config.yml -p wa -k app_config
После удаления файла:
rm /opt/app/config.yml
Проверяем событие:
sudo ausearch -k app_config -i
В результате можно увидеть процесс, который выполнил операцию, и пользователя, от которого она была выполнена:
uid=deploy
auid=deploy
exe=/usr/bin/rm
success=yes
Важно понимать, что
auditd записывает не историю введённых команд, а системные действия. Например, файл может удалить не только rm, но и скрипт или приложение. В журнале будет информация о фактическом процессе, который выполнил операцию.Также можно отслеживать изменения целых каталогов. Например, контроль изменений файлов
systemd:sudo auditctl -w /etc/systemd/system -p wa -k systemd_changes
После изменения unit-файлов ищем события:
sudo ausearch -k systemd_changes -i
Для постоянного хранения правил их добавляют в конфигурацию
audit:/etc/audit/rules.d/custom.rules
Например:
-w /etc/nginx/nginx.conf -p wa -k nginx_change
После изменения правил необходимо загрузить новую конфигурацию:
sudo augenrules --load
Правила, созданные через
auditctl, являются временными и исчезнут после перезагрузки. Файлы в /etc/audit/rules.d/ позволяют сохранить настройки постоянно.Для современных систем также стоит учитывать, что правила через
-w являются старым форматом. Более гибкий вариант — использовать syscall-based правила, например:-a always,exit -F path=/etc/nginx/nginx.conf -F perm=wa -k nginx_change
При создании правил для больших каталогов нужно учитывать нагрузку на систему. Например, аудит всего
/ может привести к большому количеству событий и дополнительной нагрузке на сервер.🔥
auditd помогает разобраться, что произошло в Linux: какой пользователь изменил файл, какой процесс выполнил действие и было ли оно успешным.🚪 Linux Ready | #практика