Configurare auditd pe Linux în 2026: Ghid Complet de Audit al Sistemului
Ghid complet pentru configurarea auditd pe Linux în 2026: instalare pe RHEL, Ubuntu, Debian și openSUSE, scrierea regulilor cu auditctl, aplicarea profilurilor CIS și STIG, analiza logurilor cu ausearch și aureport, plus integrare cu SIEM (Elastic, Splunk, Wazuh).
Configurarea auditd pe Linux presupune instalarea pachetului audit, activarea daemonului prin systemctl enable --now auditd și adăugarea unor reguli în /etc/audit/rules.d/audit.rules care specifică ce apeluri de sistem, fișiere sau procese trebuie monitorizate. Cadrul de audit din nucleul Linux (Linux Audit Framework) generează o pistă de audit inviolabilă, esențială pentru conformitatea cu standardele PCI DSS, HIPAA, STIG și CIS. În 2026, auditd rămâne unealta oficială recomandată de Red Hat, SUSE și Canonical pentru monitorizarea evenimentelor de securitate la nivel kernel.
auditd rulează în user-space și primește evenimente prin socket netlink direct de la subsistemul de audit din kernel, oferind un jurnal separat de syslog și rezistent la manipulare.
Regulile se scriu cu utilitarul auditctl pentru testare temporară și se persistă în fișiere .rules în directorul /etc/audit/rules.d/, compilate apoi de augenrules.
Setul de reguli CIS și DISA STIG pentru RHEL 9 și Ubuntu 24.04 conține peste 70 de reguli care monitorizează modificări pe /etc/passwd, apeluri execve, escaladări de privilegii și încărcări de module kernel.
Analiza logurilor se face cu ausearch pentru interogări interactive și aureport pentru rapoarte agregate; pentru SIEM integrarea se realizează prin audisp-remote sau plugin-uri pentru Splunk, Elastic și Wazuh.
În 2026, versiunea audit 4.0 aduce suport îmbunătățit pentru io_uring, containere Podman și evenimente structurate JSON prin audisp-json.
Pentru sisteme cu mulți utilizatori, activarea --backlog_wait_time și dimensionarea corectă a buffer-ului kernel previn pierderi de evenimente sub sarcină.
Ce este auditd și cum funcționează cadrul de audit Linux?
Pe scurt: auditd este daemonul din spațiul utilizator al Linux Audit Framework, un subsistem al nucleului care înregistrează evenimente relevante pentru securitate. Vorbim despre apeluri de sistem, accese la fișiere, execuții de programe, modificări ale politicii SELinux și schimbări ale identității utilizatorului. Spre deosebire de rsyslog sau systemd-journald, auditd rulează cu integritate ridicată, are propriul canal de comunicare (socket netlink de tip AUDIT_NETLINK) și e proiectat astfel încât evenimentele să nu poată fi pierdute silențios chiar și sub atac.
Cadrul are trei componente principale. Prima este subsistemul kernel, care emite evenimente pe baza unor filtre configurate prin auditctl. A doua este daemonul auditd, care primește aceste evenimente și le scrie într-un fișier de log (implicit /var/log/audit/audit.log). A treia componentă o reprezintă plugin-urile audispd (denumite acum audisp-*), care redistribuie evenimentele către SIEM-uri, sisteme de detecție a intruziunilor sau formate structurate precum JSON.
În 2026, majoritatea distribuțiilor moderne (RHEL 9.4, Ubuntu 24.04 LTS, Debian 13, openSUSE Leap 15.6) livrează auditd 3.1 sau 4.0. Versiunea 4.0, lansată la începutul anului, aduce suport nativ pentru evenimente io_uring, un subsistem I/O asincron folosit intens de bazele de date și de rulările de containere. În plus, îmbunătățește filtrarea pentru namespace-uri de proces, ceea ce e esențial pentru mediile cu Docker și Podman.
Instalare auditd pe Ubuntu, Debian, RHEL și openSUSE
Pe majoritatea distribuțiilor bazate pe RHEL, pachetul audit este instalat implicit ca parte a sistemului de bază. Pe Debian și Ubuntu însă, trebuie instalat explicit. Comenzile de mai jos acoperă cele patru familii principale de distribuții:
După instalare, verificați că subsistemul kernel este activ prin comanda auditctl -s. Rezultatul trebuie să conțină enabled 1 și pid egal cu PID-ul procesului auditd. Dacă vedeți enabled 0, activați auditul persistent adăugând audit=1 la parametrii kernelului (în GRUB, editați /etc/default/grub, apoi rulați sudo update-grub sau grub2-mkconfig).
Arhitectura Linux Audit Framework: kernel, auditd, plugin-uri
Fluxul de evenimente urmează un traseu bine definit. Când un proces execută un apel de sistem monitorizat, să spunem openat() pe /etc/shadow, modulul de audit din kernel construiește un mesaj cu contextul complet (UID real, EUID, PID, PPID, executabil, argumente, calea traducerii inode-ului) și îl trimite pe socket-ul netlink către un singur consumator: procesul auditd. Dacă auditd nu este activ sau este supraîncărcat, kernelul aplică politica configurată prin -f: 0 (silent), 1 (printk în dmesg) sau 2 (kernel panic, folosit doar în medii ultra-secure).
Auditd scrie evenimentele într-un log rotativ (/var/log/audit/audit.log, apoi .1, .2 etc.) și, opțional, le transmite plugin-urilor audisp-* prin pipe-uri anonime. Configurația principală se află în /etc/audit/auditd.conf; parametrii critici de setat sunt:
max_log_file = 50, adică dimensiunea maximă în MB per fișier;
num_logs = 10, numărul de fișiere rotite păstrate;
max_log_file_action = ROTATE, comportamentul la umplere (alternativ KEEP_LOGS pentru retenție strictă);
space_left_action = SYSLOG, acțiune la 75 MB liberi;
admin_space_left_action = SUSPEND, acțiune la 50 MB liberi, potrivit pentru medii cu conformitate strictă.
Plugin-urile din /etc/audit/plugins.d/ permit expedierea evenimentelor. Cele mai folosite sunt audisp-syslog (către rsyslog/journald), audisp-remote (către un colector central prin TCP/TLS) și audisp-json, introdus în audit 3.1 pentru integrare directă cu Elastic și Splunk.
Cum se scriu reguli de audit cu auditctl
Regulile auditd se împart în trei categorii: control (setări globale, marcate cu -D, -b, -f), file system (watch-uri pe căi, marcate cu -w) și system call (filtre pe apeluri kernel, marcate cu -a). Sintaxa este identică între linia de comandă auditctl și fișierele .rules. Practic, ce testați cu auditctl puteți lipi direct într-un fișier de reguli.
Iată un exemplu de fișier /etc/audit/rules.d/10-baza.rules care implementează monitorizarea minimă recomandată pentru servere de producție:
# Șterge toate regulile anterioare la încărcare
-D
# Buffer kernel de 8192 evenimente (implicit 64, prea mic pentru producție)
-b 8192
# Nu bloca sistemul la buffer plin; loghează în dmesg
-f 1
# Monitorizare modificări în fișiere critice de identitate
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k identity
-w /etc/sudoers.d/ -p wa -k identity
# Monitorizare configurație SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config
# Detectare execuții cu privilegii escaladate (setuid/setgid)
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k rootcmd
# Încărcare/descărcare module kernel
-a always,exit -F arch=b64 -S init_module,delete_module,finit_module -k modules
# Fac regulile imuabile până la reboot (rulează întotdeauna ULTIMA)
-e 2
Pentru a le încărca fără reboot, rulați sudo augenrules --load apoi verificați cu sudo auditctl -l. Flag-ul -p wa înseamnă „monitor write and attribute change"; alte permisiuni disponibile sunt r (read) și x (execute). Câmpul -k identity este o cheie textuală pe care o veți folosi ulterior la interogări cu ausearch -k identity.
Modificări asupra timpului sistemului (adjtimex, settimeofday, clock_settime);
Schimbarea numelui de host și a fișierului /etc/hostname;
Evenimente de autentificare eșuată (/var/log/faillog, /var/log/tallylog);
Modificări ale configurației MAC, adică SELinux (/etc/selinux/) sau AppArmor (/etc/apparmor.d/);
Utilizarea privilegiată a comenzilor chown, chmod, setxattr;
Ștergerea fișierelor de către utilizatori (unlink, unlinkat, rename, renameat).
În loc să scrieți manual regulile, folosiți setul oficial livrat cu pachetul audit în directorul /usr/share/audit/sample-rules/. Copiați setul dorit, de exemplu 30-stig.rules pentru conformitate STIG, în /etc/audit/rules.d/ și reîncărcați:
# Aplicare set complet STIG pe RHEL 9
sudo cp /usr/share/audit/sample-rules/30-stig.rules \
/etc/audit/rules.d/30-stig.rules
# Adaugă setul NISPOM (dacă mediul cere conformitate DoD)
sudo cp /usr/share/audit/sample-rules/30-nispom.rules \
/etc/audit/rules.d/30-nispom.rules
# Compilează regulile în /etc/audit/audit.rules
sudo augenrules --load
# Verifică rezultatul; ar trebui să vedeți zeci de reguli active
sudo auditctl -l | wc -l
Pentru audit automat al conformității, combinați auditd cu OpenSCAP, utilitarul oficial care evaluează sistemul față de profilurile SCAP (Security Content Automation Protocol). Rularea oscap xccdf eval --profile stig generează un raport HTML care marchează exact ce reguli auditd lipsesc. E o unealtă pe care aș pune-o în orice pipeline CI/CD pentru infrastructură.
Cum se analizează logurile auditd cu ausearch și aureport
Fișierul /var/log/audit/audit.log nu este proiectat pentru lectură umană. Un singur eveniment poate ocupa 5-10 linii cu câmpuri binare codate. Așa că folosiți întotdeauna ausearch pentru interogări:
# Toate evenimentele cu cheia "identity" din ultimele 24h
sudo ausearch -k identity --start recent
# Eșecuri de autentificare în ultima săptămână
sudo ausearch -m USER_AUTH -sv no --start week-ago
# Toate comenzile executate de un utilizator specific
sudo ausearch -ua alice --start today -i
# Convertire timestamp uman-lizibilă (flag -i)
sudo ausearch -k rootcmd -i --start yesterday | less
# Formatare JSON pentru pipeline-uri
sudo ausearch -k modules --raw | ausearch --format csv
Pentru rapoarte agregate, aureport generează sumare pe categorii:
# Sumar general al activității de audit
sudo aureport --summary
# Top 10 executabile rulate
sudo aureport -x --summary -i | head -20
# Toate autentificările eșuate cu detalii
sudo aureport -au --failed -i
# Accesări de fișiere (necesită reguli cu -w)
sudo aureport -f -i --start week-ago
Câmpul MSG=audit(1722598234.123:4567) conține timestamp-ul UNIX și un ID unic de eveniment. Când debug-uiți o alertă, extrageți ID-ul cu ausearch -a 4567 pentru a vedea toate liniile corelate (un singur syscall poate genera SYSCALL, PATH, CWD, PROCTITLE pe linii separate). Îmi amintesc de un caz în care am urmărit un fals-pozitiv timp de o oră până am realizat că evenimentele „lipsă" erau pe linii adiacente pe care le filtrasem accidental cu grep.
Integrare auditd cu SIEM: Elastic, Splunk și Wazuh
Pentru medii de producție, jurnalizarea locală este doar prima etapă. Trimiterea evenimentelor către un colector central permite corelare, alertare în timp real și retenție dincolo de limita de disc a hostului. Cele trei metode standard sunt:
1. Prin audisp-remote (nativ)
Editați /etc/audit/plugins.d/au-remote.conf pentru a activa plugin-ul, apoi configurați destinația în /etc/audit/audisp-remote.conf:
active = yes
remote_server = siem.internal.example.ro
port = 60
transport = tcp
enable_krb5 = no
network_retry_time = 5
2. Prin Filebeat + Elastic
Elastic oferă modulul auditd pentru Filebeat care parsează nativ formatul auditd și îl trimite către Elasticsearch cu mapare la Elastic Common Schema. Activați cu sudo filebeat modules enable auditd. Detalii în documentația oficială Filebeat.
3. Prin Wazuh agent
Agentul Wazuh citește direct din /var/log/audit/audit.log și aplică peste 200 de reguli predefinite pentru detectarea escaladărilor de privilegii, modificărilor de configurație și execuțiilor suspecte. Este soluția recomandată pentru echipe care nu au deja un SIEM comercial. Vezi ghidul complet de instalare Wazuh pentru detectarea intruziunilor. În combinație cu Fail2ban pentru blocarea atacurilor brute force, obțineți o stivă defensivă solidă.
Tuning de performanță și prevenirea pierderilor de evenimente
Pe servere cu trafic ridicat, cum ar fi proxy-uri, baze de date OLTP sau hipervizori, auditd poate deveni un bottleneck dacă buffer-ul kernelului se umple. Rezultatul apare în dmesg ca audit: backlog limit exceeded și înseamnă evenimente pierdute. Trei parametri controlează comportamentul:
-b 8192: dimensiunea buffer-ului kernel; crește-o la 16384 sau 32768 pe sisteme cu >100 core-uri.
--backlog_wait_time 60000: timp în microsecunde pe care kernelul îl așteaptă înainte de a arunca evenimente; setat la 60ms este un compromis rezonabil.
-f 1: la buffer plin, loghează în dmesg (nu opri sistemul). Folosiți -f 2 doar în medii cu conformitate militară unde pierderea unui singur eveniment înseamnă panică de kernel.
Pe partea de plugin-uri, evitați audisp-syslog pe volume mari fiindcă canalizarea prin journald triplează CPU-ul consumat. Preferați audisp-remote cu TCP direct sau audisp-json care exportă în format nativ pentru Filebeat.
Alt aspect subestimat: excluderea zgomotului. Regulile prea largi generează sute de evenimente pe secundă. Folosiți -a never pentru a filtra procesele legitime înainte de matching-ul real:
# Ignoră scanările de disc ale journalctl
-a never,exit -F arch=b64 -S openat -F path=/var/log/journal
# Ignoră accesele containerelor Docker către overlay
-a never,exit -F arch=b64 -F dir=/var/lib/docker/overlay2
Depanare probleme comune și mesaje de eroare
Iată problemele frecvente și soluțiile lor:
audit: type=1400 audit(...): apparmor="DENIED": nu este o eroare auditd, ci un mesaj AppArmor propagat prin kernel. Analizează cu aa-status. Pentru configurare MAC, vezi ghidul de securizare nftables care menționează pattern-uri similare.
Error - iptables/audit rules not loaded: probabil augenrules a găsit conflicte între fișiere .rules. Rulați sudo augenrules --check pentru a valida sintaxa.
Fișierul de log crește necontrolat: verificați max_log_file și num_logs în auditd.conf. Pentru curățare imediată, sudo service auditd rotate.
Reguli marcate ca imuabile (-e 2) blochează modificările: este comportamentul așteptat. Reboot pentru a aplica reguli noi, sau setați -e 1 în timpul dezvoltării.
Evenimente lipsă pentru containere Docker: auditd nu vede syscall-uri din container prin namespace-uri. Pe kernel 5.15+ folosiți -F subj_type=container_t (necesită SELinux) sau colectați din interior cu Falco.
Syslog (rsyslog, systemd-journald) colectează mesaje de log din aplicații și daemon-uri user-space prin socket-ul /dev/log. Auditd primește evenimente direct de la kernel prin socket netlink dedicat, cu integritate criptografică opțională și fără posibilitatea aplicațiilor de a manipula fluxul. Pentru conformitate PCI DSS și HIPAA, auditul kernel este obligatoriu pentru monitorizarea apelurilor de sistem, în timp ce syslog este suficient pentru evenimente aplicative.
Cum șterg regulile auditd fără a reporni sistemul?
Rulați sudo auditctl -D pentru a șterge toate regulile din memorie. Comanda funcționează doar dacă flag-ul -e nu este setat la valoarea 2 (imuabil). Dacă regulile sunt imuabile, singura opțiune este reboot. Pentru a preveni situația, folosiți -e 1 în timpul dezvoltării și doar la deploy final setați -e 2.
Cât spațiu pe disc consumă auditd pe un server obișnuit?
Cu setul CIS aplicat, un server web tipic generează 100-500 MB de log-uri auditd pe zi. Un server de baze de date sau un hipervizor poate ajunge la 2-5 GB pe zi. Configurați rotația cu max_log_file = 100 (MB) și num_logs = 10 pentru retenție locală de aproximativ o săptămână, apoi trimiteți la un colector central pentru retenție pe termen lung.
Funcționează auditd în containere Docker sau Kubernetes?
Auditd rulează pe host, nu în interiorul containerelor. Vede toate syscall-urile din pod-uri și containere pentru că kernelul este partajat, dar contextul (nume container, pod, namespace) trebuie extras separat. Pentru vizibilitate în containere folosiți Falco, Tetragon sau plugin-ul audisp-container introdus în audit 4.0 care adaugă câmpuri container_id.
Ce sunt regulile STIG pentru auditd și de ce sunt importante?
DISA STIG (Security Technical Implementation Guide) definește configurația minimă acceptată pentru sistemele Linux folosite de departamentele federale ale SUA. Regulile STIG pentru auditd impun monitorizarea a peste 70 de evenimente critice (execuții cu privilegii, modificări MAC, evenimente de autentificare). Chiar dacă nu operați într-un mediu guvernamental, setul STIG oferă o bază solidă, testată extern, pentru orice organizație cu cerințe de conformitate.
