auditd отговаря на въпроси, които възникват едва след събитието: кой е променил този файл, кога е създаден този потребител, откъде е стартиран този процес. Никой друг инструмент не отговаря на тях — в журналите на приложенията такива данни няма, а историята на командите я редактира този, който я е оставил.
Трудността е, че самото инсталиране на пакета не дава нищо. Правила по подразбиране практически няма, журналът се пише, но по съдържание е празен, и това се открива в най-лошия възможен момент: когато данните са нужни, а ги няма.
Инсталиране
sudo apt install auditd audispd-plugins
sudo systemctl status auditd
Една особеност: в някои версии auditd не се рестартира с systemctl restart — услугата се управлява със собствена команда. Правилата се презареждат така:
sudo augenrules --load
sudo auditctl -l
Втората команда показва какво реално е заредено. На нея вярвайте, а не на съдържанието на файловете.
Наборът правила
Правилата се слагат в /etc/audit/rules.d/ като отделен файл. По-долу е минималният набор, който се изплаща: отговаря на повечето въпроси при инцидент и не запълва диска.
sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## Потребители и права
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k privileges
-w /etc/sudoers.d/ -p wa -k privileges
## Достъп по SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys
## Планирани задачи
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron
## Модули на ядрото
-w /sbin/insmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules
## Използване на sudo и su
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load
Синтаксисът е кратък: -w е наблюдаваният път, -p wa означава реакция при запис и промяна на атрибути, -p x — при изпълнение, а -k е ключът, по който после ще търсите. Точно ключовете са главното удобство: без тях търсенето в журнала се превръща в преглеждане на гигабайт текст.
Какво го няма в този набор и защо
Ръководствата често предлагат да се записват всички извиквания на execve — тоест всяко стартиране на всяка програма. Изкушението е разбираемо: пълна картина на действията. На практика на работещ сървър това дава стотици мегабайти на денонощие, изяжда осезаема част от процесора и води до това журналът да се подрязва още преди да е нужен. Ако такава подробност е необходима, включвайте я точково — за един потребител или за времето на разследване.
Същото важи за наблюдението на директорията на сайта: там се пише непрекъснато, а правилото превръща журнала в поток от безсмислени събития.
Четене
Търсене по ключ, с превръщане на числовите идентификатори в имена:
sudo ausearch -k identity -i
sudo ausearch -k privileges -i -ts today
Ключът -i е задължителен за четимост: без него ще виждате числа вместо имена на потребители и системни извиквания. -ts ограничава периода (today, recent или конкретна дата).
Обобщение за период:
sudo aureport --summary -i
sudo aureport --auth -i --failed
В записа на събитие са интересни три полета: auid — идентификаторът на потребителя, започнал сесията, uid — самоличността, под която е извършено действието, и exe — програмата, която го е извършила. Разликата между auid и uid е отговорът на въпроса „кой точно е станал root“: uid=0 с auid на конкретен човек посочва еднозначно виновника, за когото и да се е представял по време на сесията.
Дискът
Настройките за обема са в /etc/audit/auditd.conf:
max_log_file = 50
num_logs = 5
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG
Отделно погледнете disk_full_action. В някои конфигурации по подразбиране стои спиране на системата при запълване на диска — поведение, оправдано на машини с изисквания за одит и напълно неуместно на уеб сървър. Тази стойност трябва да се провери, преди дискът да се запълни.
Режимът на неизменяеми правила
Редът -e 2 в края на файла с правила забранява промяната им до рестарт — включително на този, който е получил root. Това осезаемо повишава стойността на журнала: нападателят не може да изключи наблюдението, без да рестартира машината, а рестартът сам по себе си е забележим.
Обратната страна е очевидна: и собствените си правила няма да промените без рестарт. Струва си да се включи, когато наборът се стабилизира и изкарате с него един месец.
Защо това на обикновен сървър
auditd не предотвратява нищо. Стойността му се проявява точно веднъж — когато трябва да се възстанови последователността от събития, а данните или ги има, или ги няма. Не могат да се съберат със задна дата, затова наборът правила се създава предварително и после се оставя на мира.
Практически признак, че настройката е правилна: списъкът с правила не е празен, журналът не расте безконтролно, а събитията с ключове identity и privileges се появяват рядко и всяко може да се обясни. Как изглежда това на една страница, показва демонстрацията по-долу.