auditd odpowiada na pytania, które pojawiają się dopiero po zdarzeniu: kto zmienił ten plik, kiedy założono tego użytkownika, skąd uruchomiono ten proces. Żadne inne narzędzie na nie nie odpowiada — w dziennikach aplikacji takich danych nie ma, a historię poleceń poprawia ten, kto ją zostawił.

Trudność polega na tym, że sama instalacja pakietu nie daje nic. Reguł domyślnych praktycznie nie ma, dziennik jest zapisywany, ale pusty co do treści, a odkrywa się to w najgorszym momencie: kiedy dane są potrzebne, a ich nie ma.

Instalacja

sudo apt install auditd audispd-plugins
sudo systemctl status auditd

Jedna osobliwość: w niektórych wersjach auditd nie restartuje się przez systemctl restart — usługą steruje własne polecenie. Reguły wczytuje się ponownie tak:

sudo augenrules --load
sudo auditctl -l

Drugie polecenie pokazuje, co jest realnie wczytane. Jemu należy wierzyć, a nie zawartości plików.

Zestaw reguł

Reguły kładzie się w /etc/audit/rules.d/ jako osobny plik. Poniżej minimalny zestaw, który się zwraca: odpowiada na większość pytań przy incydencie i nie zasypuje dysku.

sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## Użytkownicy i uprawnienia
-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

## Dostęp SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

## Zadania zaplanowane
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## Moduły jądra
-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

## Użycie sudo i su
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load

Składnia jest krótka: -w to obserwowana ścieżka, -p wa oznacza reakcję na zapis i zmianę atrybutów, -p x na wykonanie, -k to klucz, po którym będziemy potem szukać. Właśnie klucze są główną wygodą: bez nich szukanie w dzienniku zamienia się w przeglądanie gigabajta tekstu.

Czego w tym zestawie nie ma i dlaczego

Poradniki często proponują zapisywać wszystkie wywołania execve — czyli każde uruchomienie każdego programu. Pokusa jest zrozumiała: pełny obraz działań. W praktyce na serwerze produkcyjnym daje to setki megabajtów na dobę, zjada zauważalną część procesora i prowadzi do tego, że dziennik trzeba przycinać, zanim będzie potrzebny. Jeśli taka szczegółowość jest konieczna, włączajmy ją punktowo — dla jednego użytkownika albo na czas dochodzenia.

To samo dotyczy obserwowania katalogu witryny: zapis idzie tam nieprzerwanie, a reguła zamienia dziennik w strumień pozbawionych znaczenia zdarzeń.

Czytanie

Szukanie po kluczu, z rozwinięciem identyfikatorów liczbowych na nazwy:

sudo ausearch -k identity -i
sudo ausearch -k privileges -i -ts today

Przełącznik -i jest niezbędny do czytelności: bez niego zamiast nazw użytkowników i wywołań systemowych zobaczymy liczby. -ts ogranicza okres (today, recent albo konkretna data).

Zestawienie za okres:

sudo aureport --summary -i
sudo aureport --auth -i --failed

W zapisie zdarzenia interesujące są trzy pola: auid — identyfikator użytkownika, który rozpoczął sesję, uid — tożsamość, pod którą działanie wykonano, oraz exe — program, który je wykonał. Różnica między auid a uid to odpowiedź na pytanie „kto dokładnie został rootem”: uid=0 przy auid konkretnej osoby jednoznacznie wskazuje sprawcę, za kogokolwiek podawałby się w trakcie sesji.

Dysk

Ustawienia objętości są w /etc/audit/auditd.conf:

max_log_file = 50
num_logs = 5
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG

Osobno warto spojrzeć na disk_full_action. W niektórych konfiguracjach domyślnie ustawione jest zatrzymanie systemu przy zapełnieniu dysku — zachowanie uzasadnione na maszynach z wymogami audytu i całkowicie nie na miejscu na serwerze WWW. Tę wartość trzeba sprawdzić, zanim dysk się zapełni.

Tryb reguł niezmiennych

Wiersz -e 2 na końcu pliku reguł zabrania ich zmiany do restartu — także temu, kto zdobył roota. To wyraźnie podnosi wartość dziennika: napastnik nie może wyłączyć obserwacji bez zrestartowania maszyny, a restart sam w sobie jest zauważalny.

Druga strona jest oczywista: własnych reguł też nie zmienimy bez restartu. Włączać to warto, gdy zestaw się ustabilizuje i przeżyjemy z nim miesiąc.

Po co to na zwykłym serwerze

auditd niczemu nie zapobiega. Jego wartość ujawnia się dokładnie raz — kiedy trzeba odtworzyć kolejność zdarzeń, a dane albo są, albo ich nie ma. Zebrać ich wstecz nie sposób, dlatego zestaw reguł zakłada się z wyprzedzeniem i potem zostawia w spokoju.

Praktyczny znak, że konfiguracja jest poprawna: lista reguł nie jest pusta, dziennik nie rośnie w niekontrolowany sposób, a zdarzenia z kluczami identity i privileges pojawiają się rzadko i każde da się wyjaśnić. Jak to wygląda na jednej stronie, pokazuje demonstracja poniżej.