Auditd na Linuxe v roku 2026: Audit pravidlá mapované na MITRE ATT&CK a detekcia hrozieb

Aj v dobe eBPF a runtime senzorov ako Tetragon či Falco zostáva auditd – Linux Audit Framework – základným kameňom detekcie hrozieb na serveroch s Linuxom. Beží priamo v jadre, je dostupný v každej hlavnej distribúcii a regulátori ako PCI DSS 4.0.1, CIS Benchmarks a STIG ho explicitne vyžadujú. Takže áno, aj v roku 2026 sa mu nevyhneme – a popravde, ani by sme nemali. V tomto sprievodcovi sa pozrieme na auditd cez optiku roku 2026: praktické pravidlá mapované na MITRE ATT&CK, výkonové ladenie, ausearch/aureport a integráciu so SIEM.

Ako auditd vlastne funguje

Linuxový audit subsystém má tri vrstvy. V jadre beží kauditd, ktorý zachytáva systémové volania a posiela ich cez netlink socket do userspace. V userspace beží démon auditd, ktorý zápisy ukladá do /var/log/audit/audit.log. Pravidlá načítava nástroj auditctl – buď za behu, alebo pri štarte zo súboru /etc/audit/audit.rules, ktorý sa zvyčajne skladá z fragmentov v /etc/audit/rules.d/.

A ešte dôležitý detail: auditd nie je filter ani prevention systém – iba zaznamenáva. Detekciu robíte buď v reálnom čase cez audisp pluginy (napríklad audisp-syslog alebo audisp-remote), alebo offline pomocou nástrojov ausearch a aureport. Toto rozdelenie zodpovedností je dôležité pochopiť, lebo ovplyvňuje, kde umiestnite logiku detekcie. Mnoho tímov sa s tým zbytočne potráp.

Inštalácia a aktivácia

Na RHEL/Rocky/AlmaLinux 9 a 10 je auditd štandardne nainštalovaný a beží. Na Ubuntu 24.04 a 25.10 ho treba inštalovať explicitne:

# Ubuntu/Debian
sudo apt install -y auditd audispd-plugins

# RHEL/Rocky/Alma
sudo dnf install -y audit audit-libs

# Aktivácia a štart
sudo systemctl enable --now auditd

# Overenie stavu
sudo auditctl -s

Výstup auditctl -s ukáže aktuálny počet stratených udalostí (lost), veľkosť backlog fronty a režim (enabled môže byť 0, 1 alebo 2 – kde 2 znamená immutable do reštartu). Tomu poslednému stavu sa budem venovať nižšie, lebo vie pekne zaskočiť.

Anatómia audit pravidla

Pravidlo má tri základné formy: kontrolu prístupu k súboru, kontrolu systémového volania a kontrolu prihlásení. V praxi sa najčastejšie stretnete s prvými dvoma:

# Watch (sledovanie súboru)
-w /etc/passwd -p wa -k identity

# Syscall rule
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_exec

Kľúčové prepínače:

• -w – sledovaná cesta k súboru alebo adresáru.
• -p – povolenia (read, write, execute, attribute).
• -a always,exit – akcia a moment vyhodnotenia (exit je výhodnejší než entry, lebo má prístup k návratovým hodnotám syscallu).
• -F – filter (architektúra, UID, GID, kľúč, cesta…).
• -S – konkrétny syscall.
• -k – pomenovaný kľúč; toto je úprimne vaša najdôležitejšia zbraň pri vyhľadávaní v logoch.

Konvencia pomenovania kľúčov pre MITRE ATT&CK

Najlepšie pravidlá v praxi sú tie, ktoré majú kľúč mapovaný na konkrétnu techniku MITRE ATT&CK. Vďaka tomu môžete v SIEM rovno hľadať key="T1059.004" a hneď vidíte execution z shellu. Príklad:

## T1059.004 – Unix Shell execution
-a always,exit -F arch=b64 -S execve -F path=/bin/bash -k T1059.004
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/bash -k T1059.004
-a always,exit -F arch=b64 -S execve -F path=/bin/sh -k T1059.004

## T1543.002 – Systemd Service persistence
-w /etc/systemd/system/ -p wa -k T1543.002
-w /etc/systemd/user/   -p wa -k T1543.002
-w /usr/lib/systemd/system/ -p wa -k T1543.002

## T1562.012 – Disable/Modify Linux Audit System
-w /etc/audit/         -p wa -k T1562.012
-w /etc/libaudit.conf  -p wa -k T1562.012
-w /sbin/auditctl      -p x  -k T1562.012
-w /sbin/auditd        -p x  -k T1562.012

Pravidlo T1562.012 je obzvlášť dôležité – útočník, ktorý sa snaží zakryť stopy, často vypína samotný audit ako prvé. Detekciu vypnutia auditu MITRE samostatne dokumentuje v stratégii DET0062. Stojí to za pozretie.

Produkčná sada pravidiel pre rok 2026

Namiesto jedného obrovského audit.rules rozdeľte konfiguráciu do tematických fragmentov v /etc/audit/rules.d/. Auditd ich pri štarte zlúči do jedného súboru cez augenrules --load. Moja odporúčaná štruktúra (vychádza z toho, čo sa mi osvedčilo na desiatkach hostov):

/etc/audit/rules.d/
├── 10-base.rules          # buffer, failure mode, samocheckujúce pravidlo
├── 20-identity.rules      # passwd, shadow, group, sudoers
├── 30-priv-exec.rules     # execve s euid=0, setuid/setgid binárky
├── 40-network.rules       # socket(), bind(), connect() z neštandardných UID
├── 50-modules.rules       # init_module, delete_module, finit_module
├── 60-persistence.rules   # systemd, cron, profile.d, ssh authorized_keys
├── 70-mitre-attack.rules  # mapovania na MITRE techniky
└── 99-finalize.rules      # -e 2 (immutable)

10-base.rules – základ

# Zmaž predošlé pravidlá pri reštarte
-D

# Buffer pre špičkové zaťaženie (default 8192 je často málo)
-b 16384

# Frekvencia spätnej väzby (panika pri 1, syslog pri 2)
-f 1

# Ignoruj chyby pri načítaní jednotlivých pravidiel
--backlog_wait_time 60000

20-identity.rules – účty a oprávnenia

-w /etc/passwd      -p wa -k identity
-w /etc/group       -p wa -k identity
-w /etc/shadow      -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
-w /etc/pam.d/      -p wa -k identity
-w /etc/security/   -p wa -k identity

30-priv-exec.rules – privilegované vykonávanie

# Volania execve ako root
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k T1548.003

# setuid/setgid (privilege escalation)
-a always,exit -F arch=b64 -S setuid  -F a0!=4294967295 -k T1548.001
-a always,exit -F arch=b64 -S setreuid -F a0!=4294967295 -k T1548.001
-a always,exit -F arch=b64 -S setgid  -F a0!=4294967295 -k T1548.001

# Vykonanie zo /tmp, /dev/shm – obľúbený stager
-a always,exit -F arch=b64 -S execve -F dir=/tmp     -k stager_exec
-a always,exit -F arch=b64 -S execve -F dir=/dev/shm -k stager_exec

50-modules.rules – kernel moduly

-a always,exit -F arch=b64 -S init_module   -S finit_module -k T1547.006
-a always,exit -F arch=b64 -S delete_module -k T1547.006
-w /etc/modprobe.conf -p wa -k T1547.006
-w /etc/modprobe.d/   -p wa -k T1547.006

60-persistence.rules – persistencia

# Cron a anacron
-w /etc/crontab       -p wa -k T1053.003
-w /etc/cron.d/       -p wa -k T1053.003
-w /etc/cron.daily/   -p wa -k T1053.003
-w /etc/cron.hourly/  -p wa -k T1053.003
-w /var/spool/cron/   -p wa -k T1053.003

# Systemd
-w /etc/systemd/system/    -p wa -k T1543.002
-w /usr/lib/systemd/system/ -p wa -k T1543.002

# Shell startup files
-w /etc/profile.d/   -p wa -k T1546.004
-w /etc/profile      -p wa -k T1546.004
-w /etc/bashrc       -p wa -k T1546.004

# SSH authorized keys
-a always,exit -F arch=b64 -S openat -F path=/root/.ssh/authorized_keys -F a2&0x1 -k T1098.004

99-finalize.rules – uzamknutie

# Immutable: pravidlá sa nedajú meniť až do reštartu
-e 2

Po prepísaní fragmentov pravidlá nahrajte:

sudo augenrules --load
sudo auditctl -l | head
sudo auditctl -s

Výkonové ladenie auditd

Tu prichádza tá nudnejšia, ale dôležitejšia časť. Komplexná sada pravidiel môže pridať 10–15 % zaťaženia CPU na busy serveri a v extrémnych prípadoch zaplniť disk za hodiny. Raz som videl host, kde to bolo doslova 40 minút – database server s veľmi krátkymi procesmi. Tu sú techniky, ktoré skutočne fungujú v produkcii:

1. Poradie pravidiel je všetko

Auditd vyhodnocuje pravidlá v poradí, v akom sú zaregistrované. Pri každom syscalle prejde cez všetky aplikovateľné pravidlá – najčastejšie udalosti dajte hore, výnimky dole. Zvyčajne to znamená, že tichú prevádzku ako execve z /usr/bin filtrujete prv, než aplikujete špecifické MITRE pravidlá.

2. Filtrujte šum cez -F

Najčastejšia chyba (a videl som ju naozaj často)? Sledovať execve bez filtra. Auditd potom loguje každý spustený proces, vrátane skriptov z cronu. Filtrujte podľa auid (audit UID), aby ste zachytili len akcie skutočných používateľov, nie systémových démonov:

# Zlé – generuje gigabajty
-a always,exit -F arch=b64 -S execve -k all_exec

# Lepšie – iba interaktívni používatelia
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_exec

3. Tuning auditd.conf

Súbor /etc/audit/auditd.conf má pár parametrov s veľkým dopadom:

log_format = ENRICHED
log_group = adm
priority_boost = 4
disp_qos = lossy
max_log_file = 100
num_logs = 10
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG
admin_space_left = 200
admin_space_left_action = HALT

ENRICHED formát pridáva preložené UID, GID, AUID, SAUID a session ID priamo do logu – nemusíte ich potom dohľadávať. priority_boost = 4 mierne zvýši prioritu démona, čo pomáha na zaťažených systémoch, kde auditd zaostáva za jadrom. Malý detail, veľký rozdiel.

4. Sledujte stratu udalostí

sudo auditctl -s | grep lost
# lost 0   ← chcete vidieť toto
# lost 1842  ← problém: zväčšite -b alebo zjednodušte pravidlá

Ak vidíte stratu udalostí, zdvojnásobte backlog buffer (-b 16384 → -b 32768) alebo upracte pravidlá. Strata udalostí znamená, že útočník mohol prejsť bez záznamu – a to je presne to, čomu sa snažíte vyhnúť.

5. Benchmarkujte pred a po

Auditd sa najľahšie ladí, keď máte čísla. Pred zavedením nových pravidiel zmerajte výkon pomocou perf stat alebo aspoň top/pidstat na auditd, a sledujte aj počet lost udalostí v hodinových intervaloch. Bez baseline-u len hádate.

Analýza udalostí: ausearch a aureport

Surový obsah /var/log/audit/audit.log je strojom čitateľný, ale úprimne, pre človeka je to dosť na hlavu. Na pomoc slúžia dva nástroje:

ausearch – cielené dotazy

# Všetky udalosti s konkrétnym kľúčom za posledných 24 h
sudo ausearch -k T1562.012 -ts recent -i

# Neúspešné prihlásenia za dnešok
sudo ausearch -m USER_LOGIN -sv no -ts today -i

# Všetky AVC denials (SELinux) za poslednú hodinu
sudo ausearch -m AVC -ts recent -i

# Časový rozsah
sudo ausearch -ts 05/01/2026 -te 05/01/2026 23:59:59 -k identity -i

# Inkrementálne – iba nové udalosti od posledného behu (vhodné pre cron)
sudo ausearch -k T1059.004 --checkpoint /var/lib/ausearch/exec.ckpt -i

Prepínač -i (interpret) prevedie numerické UID, GID a syscall čísla na čitateľné mená. Prepínač --checkpoint je kľúčový pre periodické dotazy z cronu – ausearch si zapamätá poslednú spracovanú udalosť a pri ďalšom behu pokračuje, kde skončil. Bez neho budete zbytočne spracovávať tie isté riadky znova a znova.

aureport – súhrny

# Celkový prehľad všetkých udalostí
sudo aureport --summary

# Iba dnešok
sudo aureport --summary -ts today

# Top 10 zlyhaných prihlásení podľa používateľa
sudo aureport --auth --failed -i --summary | head

# Najčastejšie spúšťané súbory
sudo aureport --executable -i --summary | head

# Anomálie (anomálne udalosti, ktoré jadro hlási samo)
sudo aureport --anomaly

Moje dobré pravidlo: aureport na rannú prehliadku stavu, ausearch na investigáciu konkrétneho incidentu. Funguje to.

Posielanie auditd udalostí do SIEM

Audit logy izolované na jednom hostu majú obmedzenú hodnotu. Pre detekciu a forenziku ich treba dostať do centrálneho úložiska – inak je to len drahý disk plný textových súborov. V roku 2026 sú najpopulárnejšie cesty:

Cesta 1: audisp-syslog → rsyslog → SIEM

Najjednoduchšia integrácia – auditd posiela udalosti cez audisp plugin do lokálneho syslogu a ten ich preposiela ďalej:

# /etc/audit/plugins.d/syslog.conf
active = yes
direction = out
path = /sbin/audisp-syslog
type = always
args = LOG_LOCAL6
format = string

V rsyslog potom presmerujete local6 na vzdialený TCP/TLS endpoint:

# /etc/rsyslog.d/50-audit-forward.conf
local6.* @@(o)siem.example.com:6514

Cesta 2: Wazuh agent

Wazuh agent natívne číta /var/log/audit/audit.log a parsuje audit udalosti vrátane mapovania na kľúče. V /var/ossec/etc/ossec.conf agenta:

<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>

Cesta 3: Elastic Agent / auditbeat

Pre Elastic stack použite Elastic Agent s integráciou Auditd. Beat sa pripojí priamo na audit netlink a netreba prechádzať cez syslog – výhoda je nižšia latencia a štruktúrované polia v ECS schéme. Pre väčšie nasadenia toto býva jasná voľba.

Časté nástrahy a ako sa im vyhnúť

• Plný disk. Nastavte max_log_file_action = ROTATE a num_logs rozumne. Ak preferujete external storage, použite KEEP_LOGS a rotujte cez logrotate alebo posielajte logy hneď preč.
• Immutable bez plánu. -e 2 je skvelý proti útočníkovi, ale zabudli ste na neho aj vy. Po nahodení potrebujete reštart, aby ste pridali nové pravidlo. Pri testovaní použite -e 1, pri produkcii -e 2 + change management. Učil som sa to po zlom.
• Pravidlá na entry namiesto exit. -a always,entry nevidí návratovú hodnotu syscallu a je deprecated v moderných kerneloch. Vždy exit.
• Sledovanie execve bez auid filtra. Generuje obrovské logy – systémové démony pri každom skripte z cronu. Vždy filtrujte auid>=1000, alebo cieľte na konkrétne binárky.
• Ignorovanie lost počítadla. Pridajte si monitoring (Prometheus node_exporter má textfile collector – stačí cron, ktorý zapisuje auditctl -s do .prom súboru).

Auditd vs eBPF (Tetragon, Falco) – kedy ktorý

V roku 2026 sa skôr či neskôr stretnete s otázkou, či ešte vôbec auditd nasadzovať, keď máte eBPF senzory. Realita je, že obe technológie sa dopĺňajú:

• Auditd je vyžadovaný compliance frameworkmi (CIS, STIG, PCI DSS), je v jadre desaťročia, beží na akejkoľvek verzii Linuxu vrátane starších a má bohatú knižnicu hotových pravidiel. Slabina: vyšší overhead pri masívnom logovaní syscallov a statická logika.
• eBPF (Tetragon, Falco) má nižší overhead pri filtrácii v jadre, podporuje korelácie naprieč udalosťami a má bohatší kontext o procesoch (cgroup, kubernetes namespace). Slabina: vyžaduje moderný kernel (5.10+), je novší a auditori ho stále nepoznajú do hĺbky.

Moja praktická rada: nechajte auditd zapnutý s minimálnou compliance sadou (CIS/STIG) pre regulátorov a auditovacie stopy, a eBPF nasaďte pre runtime detekciu a kontajnerové prostredia. Tieto dve vrstvy spolu pokrývajú aj situácie, keď útočník vypne jednu z nich. Belt-and-suspenders, jednoducho povedané.

FAQ

Spomalí auditd môj server?

Áno – v závislosti od pravidiel typicky o 5–15 % CPU pri bezpečnostnej konfigurácii. Najväčší dopad má sledovanie všetkých execve bez filtra. S rozumnými filtrami (auid>=1000, cielené cesty) a buffer veľkosťou 16 384+ je dopad na väčšine workloadov pod 5 %.

Aký je rozdiel medzi auditd a journald?

Journald je všeobecný log subsystém pre systemd a zhromažďuje výstupy služieb a stderr/stdout. Auditd je bezpečnostne orientovaný subsystém s priamou väzbou na jadro a syscalls – zachytáva to, čo procesy robia (volania, prístupy k súborom), nielen to, čo vypíšu. Pre detekciu hrozieb potrebujete auditd; journald je doplnok.

Ako zistím, ktoré pravidlo generuje najviac udalostí?

Spustite sudo aureport --key --summary. Tento príkaz zoradí kľúče podľa počtu udalostí. Najhlučnejšie pravidlá sú kandidáti na pridanie ďalšieho filtra alebo presunutie nižšie v poradí.

Môžem auditd použiť v kontajneroch?

Auditd v kontajneri samotnom vám zvyčajne nepomôže, lebo netlink audit socket je jeden na celý hostiteľ. Riešenie je nechať auditd bežať na hostiteľovi a obohatiť udalosti o kontajnerový kontext cez audisp plugin, alebo paralelne nasadiť Falco/Tetragon, ktoré rozumejú kontajnerom natívne.

Ako splním požiadavky CIS Benchmark pre auditd automaticky?

Použite OpenSCAP s profilom xccdf_org.ssgproject.content_profile_cis. Vygeneruje vám remediation skripty a Ansible playbook, ktoré nasadia kompletnú sadu CIS-compliant audit pravidiel. Profil sa vo všeobecnosti aktualizuje s každým release SCAP Security Guide a v roku 2026 pokrýva CIS Linux Benchmarks v2/v3.

Záver

Auditd nie je sexi, ale je nenahraditeľný. Dobre navrhnutá sada pravidiel mapovaná na MITRE ATT&CK, s rozumným výkonovým ladením a integrovaná do centrálneho SIEM, dáva tímu schopnosť spätne rekonštruovať čokoľvek, čo sa stalo na hostiteľoch – a to je jadro každej forenziky. Začnite s minimálnou compliance sadou, pridávajte MITRE-mapped pravidlá postupne podľa hrozbového modelu a vždy sledujte, či audit subsystém nestráca udalosti. Vaše budúce ja vám poďakuje, keď príde prvý incident.