Auditd mesterfokon: Behatolásészlelés, fenyegetésvadászat és megfelelőség Linux rendszereken

Bevezetés

A Linux operációs rendszer 2026-ban is az informatikai infrastruktúra abszolút gerince: a világ szerverjeinek több mint 90%-a, a felhőalapú munkafolyamatok túlnyomó többsége és a konténerizált alkalmazások szinte kivétel nélkül Linux kernelen futnak. De itt jön a csavar — ezzel párhuzamosan a támadási felület is drámaian megnőtt. A 2025-ös évben több mint 5500 Linux kernel CVE-t regisztráltak, ami történelmi rekord. Ez elég világosan jelzi, hogy a puszta javításkezelés (patch management) önmagában már nem elég.

Szóval, mit tehetünk? Nos, a futásidejű monitorozás (runtime monitoring) az egyik legkritikusabb védelmi réteg, ami rendelkezésünkre áll. A Linux Audit keretrendszer — amelynek szíve az auditd démon — kernel szinten biztosít részletes naplózást a rendszerhívásokról, fájlhozzáférésekről, jogosultságváltozásokról és felhasználói tevékenységekről. Nem egyszerű naplózó eszközről beszélünk: megfelelően konfigurálva az auditd egy teljes értékű behatolásészlelő rendszer (IDS), fenyegetésvadász platform és megfelelőségi motor egyszerre.

Ez a cikk mesterfokon mutatja be az auditd keretrendszert — az architektúrától a telepítésen és konfiguráción át a valós behatolásészlelési szabálykészletekig, a SIEM-integrációig és a teljesítményoptimalizálásig. A célunk egyszerű: hogy képes legyél egy produkciós környezetben is helytálló, átfogó audit-megoldást felépíteni.

Az auditd architektúra megértése

Mielőtt bármit is konfigurálnánk, érdemes megérteni, hogyan működik a háttérben ez az egész. A Linux Audit keretrendszer egy többrétegű architektúrán alapul, amely a kerneltől a felhasználói térig (userspace) terjed.

Kernel szintű audit alrendszer

Az audit alrendszer magja a Linux kernelben lakik. Amikor egy alkalmazás rendszerhívást (syscall) hajt végre, a kernel audit hook-jai leellenőrzik, hogy az adott esemény megfelel-e valamelyik aktív audit szabálynak. Ha igen, az eseményt egy kernel pufferbe írják. Ez a mechanizmus azért hatékony, mert a szűrés már a kernelben megtörténik — minimalizálva a felhasználói térbe jutó adatmennyiséget.

A kauditd kernel szál

A kauditd egy dedikált kernel szál (thread), ami a kernel audit pufferéből olvassa ki az eseményeket és netlink socketen keresztül továbbítja a felhasználói térbe. Ha az auditd démon nem tud lépést tartani az események áradatával, a kauditd a kernel pufferében tárolja az üzeneteket. A puffer mérete konfigurálható, és mint majd látni fogjuk, ez az egyik legkritikusabb beállítás nagy terhelésű rendszereken.

Az auditd felhasználói térbeli démon

Az auditd démon a felhasználói térben fut, és fogadja a kauditd által küldött eseményeket. A fő feladata egyszerű: mindent beleír a naplófájlba (alapértelmezetten /var/log/audit/audit.log). Az auditd maga nem végez szűrést — minden, a kerneltől kapott eseményt naplóz. A konfigurációja az /etc/audit/auditd.conf fájlban található.

Az audit diszpécser (audisp)

Az audispd (Audit Dispatcher) egy közvetítő démon, ami az audit eseményeket további célokhoz — pluginekhez — továbbítja. Modern rendszereken (auditd 3.x) az audisp funkcionalitás közvetlenül az auditd-be integrálódott, és a pluginek konfigurációja az /etc/audit/plugins.d/ könyvtárban található. A leggyakoribb pluginek:

• af_unix — Unix socketen keresztüli továbbítás
• syslog — Syslog-ba történő naplózás
• audisp-remote — Távoli szerverre történő naplóküldés
• sedispatch — SELinux eseménykezelés

Napló-áramlás összefoglalása

Az audit események útja röviden: Rendszerhívás → Kernel audit hook → Kernel puffer → kauditd szál → netlink socket → auditd démon → audit.log / audisp pluginek. Ez a lánc biztosítja, hogy az események az operációs rendszer legmélyebb szintjéről származnak — így rendkívül nehéz manipulálni őket, ellentétben az alkalmazásszintű naplókkal.

Telepítés és alapkonfiguráció

Térjünk a gyakorlatra. A telepítés szerencsére pofonegyszerű, bár van pár apró eltérés a disztribúciók között.

Telepítés Debian/Ubuntu rendszereken

# Audit csomag telepítése Debian/Ubuntu rendszeren
sudo apt update
sudo apt install -y auditd audispd-plugins

# Szolgáltatás engedélyezése és indítása
sudo systemctl enable auditd
sudo systemctl start auditd

# Állapot ellenőrzése
sudo systemctl status auditd

Telepítés RHEL/CentOS/AlmaLinux rendszereken

# Audit csomag telepítése RHEL alapú rendszeren
sudo dnf install -y audit audit-libs

# Szolgáltatás engedélyezése és indítása
sudo systemctl enable auditd
sudo systemctl start auditd

# Fontos: RHEL rendszereken az auditd-t nem a systemctl-lel kell újraindítani
# hanem a dedikált paranccsal:
sudo service auditd restart

Egy apró, de fontos megjegyzés a RHEL-lel kapcsolatban: a systemctl restart auditd parancs nem működik megfelelően ezeken a rendszereken. Használd helyette a service auditd restart parancsot — sok fejfájástól megkíméled magad.

Az auditd.conf kulcsfontosságú beállításai

Az /etc/audit/auditd.conf fájl határozza meg az auditd démon viselkedését. Az alábbi konfiguráció egy produkciós környezethez ajánlott kiindulópont:

# /etc/audit/auditd.conf — Produkciós konfiguráció
#
# Naplófájl elérési útja
log_file = /var/log/audit/audit.log

# Naplóformátum: RAW (nyers) vagy ENRICHED (gazdagított, hostname-mel)
log_format = ENRICHED

# Naplócsoportosítás: NONE, INCREMENTAL, INCREMENTAL_ASYNC
write_logs = yes
log_group = root

# Prioritás növelése a megbízhatóság érdekében
priority_boost = 4

# Napló kiürítési mód: NONE, INCREMENTAL, INCREMENTAL_ASYNC, DATA, SYNC
flush = INCREMENTAL_ASYNC
freq = 50

# Maximális naplófájl méret MB-ban
max_log_file = 50

# Rotált naplófájlok száma
num_logs = 10

# Művelet, ha a napló eléri a maximális méretet: IGNORE, SYSLOG, SUSPEND, ROTATE, KEEP_LOGS
max_log_file_action = ROTATE

# Szabad lemezterület figyelmeztetés (MB-ban)
space_left = 150
space_left_action = SYSLOG
admin_space_left = 75
admin_space_left_action = SUSPEND

# Művelet, ha a lemez megtelik
disk_full_action = SUSPEND
disk_error_action = SUSPEND

# Elosztási mód az audisp pluginek felé
distribute_network = no

A legkritikusabb beállításokról pár szó:

• log_format = ENRICHED — A gazdagított formátum UID-kat felhasználónevekké, rendszerhívás-számokat nevekké oldja fel. Őszintén szólva, elemzéskor ez életet ment.
• flush = INCREMENTAL_ASYNC — Jó kompromisszum a teljesítmény és a megbízhatóság között. Ha kritikus rendszered van, ahol egy naplósor sem veszhet el, használj inkább SYNC-et.
• space_left_action = SYSLOG — Riasztást küld, mielőtt elfogyna a lemezterület. Mert ugye, senki nem akar hajnali 3-kor teli lemez miatt ébredni.
• disk_full_action = SUSPEND — Megakadályozza a rendszer összeomlását teli lemez esetén. Magas biztonsági követelmények mellett használható a HALT opció is, ami egyszerűen leállítja a rendszert (de ez nyilván drasztikus lépés).

Audit szabályok létrehozása

Most jön a lényeg. Az audit szabályok határozzák meg, milyen eseményeket figyeljen a kernel. Három fő típust különböztetünk meg:

Szabálytípusok

• Vezérlő szabályok (Control rules) — Az audit rendszer viselkedését módosítják (pufferméret, hibakezelési mód, engedélyezés/letiltás).
• Fájlrendszer-szabályok (Filesystem rules / -w) — Meghatározott fájlok vagy könyvtárak olvasásának, írásának, végrehajtásának vagy attribútumváltozásának figyelése.
• Rendszerhívás-szabályok (Syscall rules / -a) — Konkrét rendszerhívások monitorozása szűrési feltételekkel (felhasználó, csoport, argumentumok stb.).

A szabályfájlok struktúrája

A tartós audit szabályok az /etc/audit/rules.d/ könyvtárban találhatók. Az augenrules eszköz ezeket a fájlokat ábécésorrendben összefűzi és betölti. A bevált elnevezési konvenció:

/etc/audit/rules.d/
├── 10-base-config.rules      # Alapkonfiguráció (pufferméret, hibakezelés)
├── 20-filters.rules           # Kizáró szabályok (zajszűrés)
├── 30-stig.rules              # Megfelelőségi szabályok (CIS, STIG)
├── 40-local.rules             # Szervezetspecifikus szabályok
├── 50-threatdetect.rules      # Behatolásészlelési szabályok
└── 99-finalize.rules          # Záró szabályok (immutable mód)

Ez a struktúra átláthatóvá teszi a konfigurációt, és megkönnyíti a karbantartást is. Tapasztalatom szerint a számozott elnevezés sokat segít, amikor több csapattag is hozzányúl a szabályokhoz.

Fájlrendszer-figyelés (File monitoring)

# Kritikus identitásfájlok figyelése
-w /etc/passwd -p wa -k identity_mod
-w /etc/shadow -p wa -k identity_mod
-w /etc/group -p wa -k identity_mod
-w /etc/gshadow -p wa -k identity_mod
-w /etc/security/opasswd -p wa -k identity_mod

# Sudo konfiguráció figyelése
-w /etc/sudoers -p wa -k sudoers_mod
-w /etc/sudoers.d/ -p wa -k sudoers_mod

# SSH kulcsok és konfiguráció figyelése
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k root_ssh_keys
-w /home/ -p wa -k user_home_ssh

# PAM konfiguráció figyelése
-w /etc/pam.d/ -p wa -k pam_config
-w /etc/security/limits.conf -p wa -k pam_limits

# Cron job-ok figyelése
-w /etc/crontab -p wa -k cron_mod
-w /etc/cron.d/ -p wa -k cron_mod
-w /etc/cron.daily/ -p wa -k cron_mod
-w /etc/cron.hourly/ -p wa -k cron_mod
-w /etc/cron.weekly/ -p wa -k cron_mod
-w /etc/cron.monthly/ -p wa -k cron_mod
-w /var/spool/cron/ -p wa -k cron_mod

A -p kapcsoló a figyelendő műveleteket határozza meg: r (olvasás), w (írás), x (végrehajtás), a (attribútumváltozás). A -k kulcsszóval pedig gyorsan szűrhetünk az események között keresésnél — ez később aranyat ér.

Rendszerhívás-figyelés (Syscall monitoring)

# Programvégrehajtás figyelése (minden execve hívás)
-a always,exit -F arch=b64 -S execve -k exec_cmd
-a always,exit -F arch=b32 -S execve -k exec_cmd

# Hálózati socket műveletek figyelése
-a always,exit -F arch=b64 -S socket -S connect -S accept -S bind -k net_conn
-a always,exit -F arch=b32 -S socket -S connect -S accept -S bind -k net_conn

# Fájlrendszer csatolás/leválasztás figyelése
-a always,exit -F arch=b64 -S mount -S umount2 -k mount_ops
-a always,exit -F arch=b32 -S mount -S umount -k mount_ops

# Folyamat-nyomkövetés (ptrace) — támadók gyakran használják
-a always,exit -F arch=b64 -S ptrace -F a0=0x4 -k ptrace_attach
-a always,exit -F arch=b64 -S ptrace -F a0=0x10 -k ptrace_seize
-a always,exit -F arch=b32 -S ptrace -k ptrace_access

Jogosultságemelés észlelése

Ez az a terület, ahol az auditd igazán ragyog. A jogosultságemelés (privilege escalation) az egyik leggyakoribb támadási lépés, és az alábbi szabályokkal szinte lehetetlen észrevétlenül megtenni:

# SUID/SGID bit változások figyelése
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -F perm=x -k suid_sgid_change

# setuid/setgid rendszerhívások figyelése
-a always,exit -F arch=b64 -S setuid -S setreuid -S setresuid -S setfsuid -k setuid_call
-a always,exit -F arch=b64 -S setgid -S setregid -S setresgid -S setfsgid -k setgid_call

# Privilegizált parancsok végrehajtásának figyelése
-a always,exit -F path=/usr/bin/sudo -F perm=x -k priv_sudo
-a always,exit -F path=/usr/bin/su -F perm=x -k priv_su
-a always,exit -F path=/usr/bin/chsh -F perm=x -k priv_chsh
-a always,exit -F path=/usr/bin/newgrp -F perm=x -k priv_newgrp
-a always,exit -F path=/usr/sbin/usermod -F perm=x -k priv_usermod
-a always,exit -F path=/usr/sbin/userdel -F perm=x -k priv_userdel
-a always,exit -F path=/usr/sbin/useradd -F perm=x -k priv_useradd
-a always,exit -F path=/usr/sbin/groupmod -F perm=x -k priv_groupmod
-a always,exit -F path=/usr/sbin/groupadd -F perm=x -k priv_groupadd

Ideiglenes szabályok betöltése auditctl-lel

Mielőtt élesben bevezetnél egy szabályt, érdemes ideiglenes szabályként betölteni és tesztelni. Ezek újraindításig érvényesek:

# Aktuális szabályok listázása
sudo auditctl -l

# Ideiglenes szabály hozzáadása (újraindításig érvényes)
sudo auditctl -w /tmp -p x -k tmp_exec

# Összes szabály törlése
sudo auditctl -D

# Tartós szabályok betöltése fájlból
sudo augenrules --load

# Állapot lekérdezése
sudo auditctl -s

Fenyegetésvadászat az ausearch és aureport eszközökkel

A szabályok betöltése csak a fél munka. Az igazi biztonsági érték a naplóelemzésben rejlik. Az ausearch és az aureport a Linux Audit keretrendszer beépített elemző eszközei, és meglehetősen hatékonyak.

Sikertelen bejelentkezések keresése

# Összes sikertelen bejelentkezési kísérlet
sudo ausearch -m USER_LOGIN --success no --interpret

# Sikertelen bejelentkezések az elmúlt 24 órában
sudo ausearch -m USER_LOGIN --success no -ts today --interpret

# Sikertelen SSH bejelentkezések specifikus felhasználóhoz
sudo ausearch -m USER_LOGIN --success no -ua admin --interpret

# Sikertelen bejelentkezések adott időintervallumban
sudo ausearch -m USER_LOGIN --success no -ts 01/15/2026 08:00:00 -te 01/15/2026 18:00:00 --interpret

Gyanús parancsvégrehajtások keresése

# Összes végrehajtott parancs keresése kulcsszó alapján
sudo ausearch -sc execve -k exec_cmd --interpret | head -100

# Konkrét felhasználó tevékenysége (auid alapján)
sudo ausearch --auid 1001 -sc execve --interpret

# Gyanús binárisok keresése a /tmp könyvtárból
sudo ausearch -f /tmp -sc execve --interpret

# Shadow fájl hozzáférések keresése
sudo ausearch -f /etc/shadow --interpret

# Kulcsszó alapú keresés
sudo ausearch -k identity_mod --interpret

Személyes tapasztalatom, hogy az ausearch -k parancs a leggyakrabban használt. Ha konzisztensen osztasz ki kulcsszavakat a szabályaidhoz, pillanatok alatt megtalálsz bármilyen eseményt.

Aureport összefoglaló jelentések

# Általános összefoglaló
sudo aureport --summary

# Hitelesítési jelentés
sudo aureport --auth

# Sikertelen események összefoglalója
sudo aureport --failed

# Végrehajtható fájlok jelentése
sudo aureport -x --summary

# Felhasználói tevékenység jelentése
sudo aureport -u --summary

# Anomáliák jelentése
sudo aureport --anomaly

# Időszakos jelentés (napi)
sudo aureport --start today --end now --summary

# Kulcsszó-alapú jelentés (mely szabályok generálták a legtöbb eseményt)
sudo aureport -k --summary

Az aureport -k --summary különösen hasznos: megmutatja, melyik szabályok generálják a legtöbb eseményt. Ha valamelyik kulcs kiugróan sok találatot produkál, érdemes megvizsgálni — vagy túl tág a szabály, vagy valami gyanús történik.

Audit naplómezők értelmezése

Egy tipikus audit naplóbejegyzés első ránézésre elég ijesztően néz ki. De ha tudod, mit hol keress, meglepően informatív:

type=SYSCALL msg=audit(1706184523.456:28594): arch=c000003e syscall=59 success=yes exit=0 a0=55b3f2a1e0a0 a1=55b3f2a1c850 a2=55b3f2a1e9a0 a3=7ffd4a2b7e90 items=2 ppid=4521 pid=4522 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="passwd" exe="/usr/bin/passwd" subj=unconfined key="priv_cmd"

A legfontosabb mezők:

• type — Az esemény típusa (SYSCALL, PATH, CWD, EXECVE, USER_LOGIN stb.)
• msg=audit(timestamp:serial) — Időbélyeg és egyedi sorszám
• arch — Architektúra (c000003e = x86_64)
• syscall=59 — Rendszerhívás száma (59 = execve x86_64 rendszeren)
• success — A művelet sikeressége (yes/no)
• auid — Az audit UID, vagyis a felhasználó eredeti bejelentkezési azonosítója, amely nem változik su/sudo esetén sem
• uid/euid — Az aktuális és az effektív felhasználói azonosító
• ses — Munkamenet-azonosító (egyedi bejelentkezési munkamenet)
• comm — A végrehajtott parancs neve
• exe — A végrehajtható fájl teljes elérési útja
• key — Az audit szabályhoz rendelt kulcsszó

Az auid (audit UID) különösen fontos a fenyegetésvadászatban. Még ha egy felhasználó su vagy sudo paranccsal más felhasználóvá válik is, az auid megőrzi az eredeti identitást. Ez teszi lehetővé a teljes tevékenységlánc visszakövetését — ami incidenskezelésnél felbecsülhetetlen.

CIS Benchmark és NIST megfelelőség

Az auditd konfigurálása nem csupán biztonsági best practice — számos szabályozási keretrendszer és ipari szabvány meg is követeli. A két leggyakrabban hivatkozott keretrendszer a CIS Benchmarks és a NIST SP 800-53.

CIS Level 2 audit követelmények

A CIS (Center for Internet Security) Linux benchmark Level 2 profilja rengeteg audit szabályt ír elő. Íme a legfontosabbak dióhéjban:

• Az auditd szolgáltatásnak futnia kell és engedélyezettnek kell lennie
• Az audit naplókat automatikusan nem szabad törölni (max_log_file_action = keep_logs)
• Az audit rendszernek figyelmeztetnie kell, ha a naplótárterület fogy
• Naplózni kell: dátum/idő módosítását, felhasználó/csoport módosításokat, hálózati környezet változásait, MAC szabályzat módosításokat, bejelentkezési/kijelentkezési eseményeket, munkamenet-kezdeményezéseket, DAC jogosultságmódosításokat, sikertelen fájlhozzáférési kísérleteket, privilegizált parancsok használatát, fájlrendszer-csatolásokat, fájltörléseket, sudoers módosításokat és kernel modul betöltést

NIST 800-53 kontrollok leképezése

Az auditd közvetlenül támogatja a következő NIST 800-53 (Rev. 5) kontrollokat:

• AU-2 (Audit Events) — Az audit rendszernek képesnek kell lennie meghatározott eseménytípusok naplózására. Az auditd rendszerhívás-szintű granularitást biztosít, ami messze túlmutat a legtöbb naplózó megoldáson.
• AU-3 (Content of Audit Records) — Az audit rekordoknak tartalmazniuk kell az esemény típusát, időpontját, eredményét, forrását és az érintett objektumokat. Az ENRICHED formátum ezt maradéktalanul teljesíti.
• AU-8 (Time Stamps) — Pontos időbélyegek. Az auditd a kernel időbélyegeit használja, ami a lehető legmegbízhatóbb forrás.
• AU-12 (Audit Generation) — Audit generálás az AU-2-ben meghatározott eseményekre. A szabályalapú rendszer ezt teljes mértékben biztosítja.
• AC-6 (Least Privilege) — A jogosultságemelés figyelésével az auditd segíti ennek a kontrollnak az ellenőrzését és érvényesítését.

Megfelelőségi szabálykészlet

Az alábbi szabálykészlet lefedi a CIS és NIST által elvárt főbb naplózási követelményeket:

# CIS/NIST megfelelőségi alapszabályok

# 4.1.3 — Dátum és idő módosítások naplózása
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
-a always,exit -F arch=b32 -S adjtimex -S settimeofday -S stime -k time_change
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -k time_change
-w /etc/localtime -p wa -k time_change

# 4.1.4 — Felhasználó/csoport módosítások naplózása
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity

# 4.1.5 — Hálózati környezet módosítások naplózása
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k network_mod
-a always,exit -F arch=b32 -S sethostname -S setdomainname -k network_mod
-w /etc/issue -p wa -k network_mod
-w /etc/issue.net -p wa -k network_mod
-w /etc/hosts -p wa -k network_mod
-w /etc/network/ -p wa -k network_mod
-w /etc/networks -p wa -k network_mod
-w /etc/netplan/ -p wa -k network_mod

# 4.1.6 — MAC (Mandatory Access Control) módosítások
-w /etc/apparmor/ -p wa -k mac_policy
-w /etc/apparmor.d/ -p wa -k mac_policy
-w /etc/selinux/ -p wa -k mac_policy

# 4.1.7 — Bejelentkezési/kijelentkezési események
-w /var/log/faillog -p wa -k login_events
-w /var/log/lastlog -p wa -k login_events
-w /var/log/tallylog -p wa -k login_events
-w /var/run/faillock/ -p wa -k login_events

# 4.1.8 — Munkamenet-kezdeményezés
-w /var/run/utmp -p wa -k session
-w /var/log/wtmp -p wa -k session
-w /var/log/btmp -p wa -k session

# 4.1.9 — DAC jogosultságmódosítások
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

# 4.1.10 — Sikertelen fájlhozzáférési kísérletek
-a always,exit -F arch=b64 -S open -S truncate -S ftruncate -S creat -S openat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access_denied
-a always,exit -F arch=b64 -S open -S truncate -S ftruncate -S creat -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access_denied

Gyakorlati példa: Élő behatolásészlelési szabálykészlet

Most pedig nézzünk egy olyan szabálykészletet, amelyet ténylegesen produkciós környezetben lehet használni. Ez a készlet kifejezetten behatolásészlelésre és fenyegetésvadászatra lett optimalizálva, és egyetlen fájlba szervezve tartalmazza a legfontosabb detektálási logikákat.

# /etc/audit/rules.d/50-threatdetect.rules
# Behatolásészlelési és fenyegetésvadász szabálykészlet
# Verzió: 2026.01 | Szerző: SecOps Team
# ============================================================

# --- VEZÉRLŐ SZABÁLYOK ---
# Puffer mérete (nagyobb = kevesebb eseményvesztés, több memória)
-b 16384

# Hibaüzenet naplózása, ha a puffer megtelik (0=silent, 1=printk, 2=panic)
-f 1

# Háttérszabályok eltávolítása az induláskor
-D

# --- KERNEL MODUL BETÖLTÉS/ELTÁVOLÍTÁS ---
# Támadók gyakran töltenek be rootkit modulokat
-w /sbin/insmod -p x -k kernel_module
-w /sbin/rmmod -p x -k kernel_module
-w /sbin/modprobe -p x -k kernel_module
-a always,exit -F arch=b64 -S init_module -S finit_module -k kernel_module_load
-a always,exit -F arch=b64 -S delete_module -k kernel_module_remove

# --- IDŐ MÓDOSÍTÁSOK ---
# Az időmanipuláció a támadók nyomkövetés-elhárítási technikája
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time_tampering
-a always,exit -F arch=b32 -S adjtimex -S settimeofday -S stime -S clock_settime -k time_tampering
-w /etc/localtime -p wa -k time_tampering

# --- FELHASZNÁLÓ ÉS CSOPORT MÓDOSÍTÁSOK ---
-w /etc/passwd -p wa -k user_group_mod
-w /etc/shadow -p wa -k user_group_mod
-w /etc/group -p wa -k user_group_mod
-w /etc/gshadow -p wa -k user_group_mod
-a always,exit -F path=/usr/sbin/useradd -F perm=x -k user_creation
-a always,exit -F path=/usr/sbin/userdel -F perm=x -k user_deletion
-a always,exit -F path=/usr/sbin/usermod -F perm=x -k user_modification
-a always,exit -F path=/usr/sbin/groupadd -F perm=x -k group_creation

# --- HÁLÓZATI KONFIGURÁCIÓ VÁLTOZÁSOK ---
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k network_config
-w /etc/hosts -p wa -k network_config
-w /etc/hostname -p wa -k network_config
-w /etc/resolv.conf -p wa -k network_config
-w /etc/network/ -p wa -k network_config
-w /etc/netplan/ -p wa -k network_config
-w /etc/NetworkManager/ -p wa -k network_config
-w /etc/sysconfig/network-scripts/ -p wa -k network_config

# --- MUNKAMENET FIGYELÉS ---
-w /var/run/utmp -p wa -k session_tracking
-w /var/log/wtmp -p wa -k session_tracking
-w /var/log/btmp -p wa -k session_tracking
-w /var/run/faillock/ -p wa -k session_tracking

# --- PRIVILEGIZÁLT PARANCSOK VÉGREHAJTÁSA ---
-a always,exit -F path=/usr/bin/sudo -F perm=x -k priv_escalation
-a always,exit -F path=/usr/bin/su -F perm=x -k priv_escalation
-a always,exit -F path=/usr/bin/pkexec -F perm=x -k priv_escalation
-a always,exit -F path=/usr/bin/chage -F perm=x -k priv_escalation
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -k priv_escalation
-a always,exit -F path=/usr/bin/passwd -F perm=x -k priv_escalation
-a always,exit -F path=/usr/bin/crontab -F perm=x -k priv_escalation
-a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -k priv_escalation
-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -k priv_escalation

# --- GYANÚS BINÁRIS VÉGREHAJTÁS ---
# Végrehajtás ideiglenes könyvtárakból (gyakori támadási vektor)
-a always,exit -F dir=/tmp -F perm=x -F auid>=1000 -F auid!=4294967295 -k suspicious_exec_tmp
-a always,exit -F dir=/var/tmp -F perm=x -F auid>=1000 -F auid!=4294967295 -k suspicious_exec_vartmp
-a always,exit -F dir=/dev/shm -F perm=x -F auid>=1000 -F auid!=4294967295 -k suspicious_exec_shm

# --- LOTL (Living off the Land) TECHNIKÁK ÉSZLELÉSE ---

# Hálózati felderítés eszközök
-a always,exit -F path=/usr/bin/nmap -F perm=x -k lotl_recon
-a always,exit -F path=/usr/bin/tcpdump -F perm=x -k lotl_recon
-a always,exit -F path=/usr/bin/ncat -F perm=x -k lotl_recon
-a always,exit -F path=/usr/bin/nc -F perm=x -k lotl_recon
-a always,exit -F path=/usr/bin/netcat -F perm=x -k lotl_recon
-a always,exit -F path=/usr/bin/ss -F perm=x -k lotl_recon
-a always,exit -F path=/usr/bin/ip -F perm=x -k lotl_recon

# Adatkiszűrés (data exfiltration) eszközök
-a always,exit -F path=/usr/bin/curl -F perm=x -F auid>=1000 -F auid!=4294967295 -k lotl_exfil
-a always,exit -F path=/usr/bin/wget -F perm=x -F auid>=1000 -F auid!=4294967295 -k lotl_exfil
-a always,exit -F path=/usr/bin/scp -F perm=x -F auid>=1000 -F auid!=4294967295 -k lotl_exfil
-a always,exit -F path=/usr/bin/sftp -F perm=x -F auid>=1000 -F auid!=4294967295 -k lotl_exfil
-a always,exit -F path=/usr/bin/rsync -F perm=x -F auid>=1000 -F auid!=4294967295 -k lotl_exfil
-a always,exit -F path=/usr/bin/base64 -F perm=x -k lotl_exfil
-a always,exit -F path=/usr/bin/openssl -F perm=x -k lotl_exfil

# Kódvégrehajtás és fordítás
-a always,exit -F path=/usr/bin/python3 -F perm=x -F auid>=1000 -F auid!=4294967295 -k lotl_code_exec
-a always,exit -F path=/usr/bin/perl -F perm=x -F auid>=1000 -F auid!=4294967295 -k lotl_code_exec
-a always,exit -F path=/usr/bin/ruby -F perm=x -F auid>=1000 -F auid!=4294967295 -k lotl_code_exec
-a always,exit -F path=/usr/bin/gcc -F perm=x -k lotl_code_exec
-a always,exit -F path=/usr/bin/cc -F perm=x -k lotl_code_exec
-a always,exit -F path=/usr/bin/as -F perm=x -k lotl_code_exec

# Nyomkövetés-elhárítás (anti-forensics)
-a always,exit -F path=/usr/bin/shred -F perm=x -k antiforensics
-a always,exit -F path=/usr/bin/wipe -F perm=x -k antiforensics
-w /var/log/ -p wa -k log_tampering

# --- RENDSZERHÍVÁS SZINTŰ DETEKTÁLÁS ---
# Ptrace — folyamat-injektálás és debugger csatolás
-a always,exit -F arch=b64 -S ptrace -k process_injection

# Memória-végrehajtás (fileless malware)
-a always,exit -F arch=b64 -S memfd_create -k fileless_execution
-a always,exit -F arch=b64 -S execveat -k fileless_execution

# Névtér-manipuláció (container escape kísérletek)
-a always,exit -F arch=b64 -S unshare -k namespace_manipulation
-a always,exit -F arch=b64 -S setns -k namespace_manipulation

# --- SSH ÉS TÁVOLI HOZZÁFÉRÉS ---
-w /etc/ssh/sshd_config -p wa -k sshd_config_change
-w /etc/ssh/sshd_config.d/ -p wa -k sshd_config_change
-w /root/.ssh/authorized_keys -p wa -k ssh_key_injection
-w /etc/ssh/ssh_host_rsa_key -p r -k ssh_host_key_access
-w /etc/ssh/ssh_host_ecdsa_key -p r -k ssh_host_key_access
-w /etc/ssh/ssh_host_ed25519_key -p r -k ssh_host_key_access

# --- SUDOERS MÓDOSÍTÁS ---
-w /etc/sudoers -p wa -k sudoers_tampering
-w /etc/sudoers.d/ -p wa -k sudoers_tampering

# --- SYSTEMD ÉS SZOLGÁLTATÁSOK ---
-w /etc/systemd/ -p wa -k systemd_mod
-w /usr/lib/systemd/ -p wa -k systemd_mod
-w /run/systemd/system/ -p wa -k systemd_mod

# --- LD_PRELOAD ÉS DINAMIKUS BETÖLTŐ MANIPULÁCIÓ ---
-w /etc/ld.so.conf -p wa -k ld_preload
-w /etc/ld.so.conf.d/ -p wa -k ld_preload
-w /etc/ld.so.preload -p wa -k ld_preload

Ez a szabálykészlet lefedi a legtöbb ismert támadási technikát, a rootkit moduloktól a fileless malware-ig, a LOTL technikáktól a container escape kísérletekig. Természetesen nem minden környezetben kell az összes szabályt alkalmazni — mérlegeld a saját fenyegetési modelled alapján.

Integráció SIEM rendszerekkel

Az auditd igazi ereje akkor bontakozik ki, amikor a naplókat egy központi SIEM (Security Information and Event Management) rendszerbe továbbítjuk. Ott korreláció, riasztások és vizualizáció áll rendelkezésre — ami nagyságrendekkel több, mint amit egy egyedülálló audit.log fájl nyújthat.

Wazuh integráció

A Wazuh egy nyílt forráskódú biztonsági platform, amely natívan támogatja az audit naplók feldolgozását. A Wazuh ügynök konfigurációjába mindössze ennyit kell felvenni:

<!-- /var/ossec/etc/ossec.conf — Audit napló beolvasás -->
<ossec_config>
  <localfile>
    <log_format>audit</log_format>
    <location>/var/log/audit/audit.log</location>
  </localfile>
</ossec_config>

A Wazuh beépített dekóderekkel és szabályokkal rendelkezik az audit események feldolgozásához. Ha egyéni riasztásokat szeretnél, a /var/ossec/etc/rules/local_rules.xml fájlban definiálhatod őket:

<!-- Wazuh egyéni szabály: kernel modul betöltés figyelmeztetés -->
<group name="linux,audit,kernel_module">
  <rule id="100210" level="12">
    <if_sid>80700</if_sid>
    <field name="audit.key">kernel_module_load</field>
    <description>Kernel modul betöltés észlelve — lehetséges rootkit tevékenység</description>
    <group>audit_command,kernel,rootkit,</group>
    <mitre>
      <id>T1547.006</id>
    </mitre>
  </rule>
</group>

Elastic Stack / Auditbeat integráció

Az Elastic Auditbeat egy alternatív megközelítés: közvetlenül az audit alrendszerből olvas, megkerülve az auditd démont. Ez akkor előnyös, ha az Elastic Stack a fő SIEM megoldásod. Az auditbeat.yml konfigurációja:

# /etc/auditbeat/auditbeat.yml — Audit modul konfiguráció
auditbeat.modules:
- module: auditd
  audit_rules: |
    -w /etc/passwd -p wa -k identity
    -w /etc/shadow -p wa -k identity
    -a always,exit -F arch=b64 -S execve -k exec
    -a always,exit -F arch=b64 -S connect -k network
    -w /etc/sudoers -p wa -k sudoers

- module: file_integrity
  paths:
    - /etc/
    - /usr/bin/
    - /usr/sbin/
    - /boot/

output.elasticsearch:
  hosts: ["https://elasticsearch.example.com:9200"]
  username: "auditbeat_writer"
  password: "${BEAT_ES_PASSWORD}"
  ssl.certificate_authorities: ["/etc/auditbeat/ca.pem"]
  index: "auditbeat-%{+yyyy.MM.dd}"

setup.kibana:
  host: "https://kibana.example.com:5601"
  ssl.certificate_authorities: ["/etc/auditbeat/ca.pem"]

Fontos megjegyzés: ha Auditbeat-et használsz, ne futtasd mellette az auditd-t is ugyanazokkal a szabályokkal, mert konfliktusba kerülhetnek. Válaszd az egyiket, és ragaszkodj hozzá.

Audisp-remote — központosított naplógyűjtés

Az audisp-remote plugin lehetővé teszi az audit naplók valós idejű továbbítását egy központi naplógyűjtő szerverre. Ez a megoldás egyszerűbb, mint egy teljes SIEM bevezetése, de a központosított naplózás alapelvét már biztosítja:

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

# /etc/audit/audisp-remote.conf
remote_server = siem.example.com
port = 60
transport = tcp
queue_file = /var/spool/audit/remote.log
mode = immediate
queue_depth = 10240
fail_action = syslog
network_retry_time = 1
max_tries_per_record = 3
network_failure_action = stop

Rsyslog továbbítás

Ha rsyslog-on keresztül szeretnéd továbbítani az audit naplókat (ami sok környezetben a legegyszerűbb megoldás):

# /etc/rsyslog.d/60-audit-forward.conf
module(load="imfile")

input(type="imfile"
      File="/var/log/audit/audit.log"
      Tag="linux-audit:"
      Severity="info"
      Facility="local6"
      PersistStateInterval="100"
      reopenOnTruncate="on")

# Továbbítás távoli szerverre TLS-sel
local6.* action(
    type="omfwd"
    target="siem.example.com"
    port="514"
    protocol="tcp"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="siem.example.com"
)

JSON kimenet formázása

Az audit naplók JSON formátumú kimenete jelentősen megkönnyíti a SIEM-integrációt. Jó hír, hogy az auditd 3.1+ verziója natívan támogatja:

# ausearch JSON kimenet (auditd 3.1+)
sudo ausearch --format json -k exec_cmd | python3 -m json.tool

# Példa JSON kimenet egy feldolgozott eseményre:
{
  "timestamp": "2026-01-15T14:23:45.123+0100",
  "sequence": 28594,
  "category": "SYSCALL",
  "record_type": "execve",
  "result": "success",
  "session": "3",
  "auid": {
    "id": 1000,
    "name": "admin"
  },
  "uid": {
    "id": 0,
    "name": "root"
  },
  "process": {
    "pid": 4522,
    "ppid": 4521,
    "exe": "/usr/bin/passwd",
    "comm": "passwd"
  },
  "key": "priv_escalation",
  "arch": "x86_64"
}

Teljesítményoptimalizálás és bevált gyakorlatok

Az audit keretrendszer rendkívül értékes biztonsági adatokat szolgáltat, de — és ezt fontos hangsúlyozni — helytelen konfiguráció esetén komoly teljesítményproblémákat okozhat. Lássuk, hogyan kerülhetjük el a buktatókat.

Puffer hangolás (Buffer tuning)

A kernel audit puffer mérete határozza meg, hány eseményt képes a rendszer ideiglenesen tárolni a felhasználói térbe történő továbbítás előtt. Ha a puffer megtelik, események veszhetnek el. Ez az a helyzet, amit mindenképpen el akarunk kerülni.

# Puffer méret beállítása a szabályfájl elején
# Alacsony terhelés (fejlesztői gépek): 4096-8192
# Közepes terhelés (webszerverek): 8192-16384
# Magas terhelés (adatbázis szerverek, CI/CD): 16384-65536
-b 16384

# Aktuális puffer állapot ellenőrzése
sudo auditctl -s
# Keressük a "backlog" és "backlog_limit" értékeket

# Elvesztett események száma
sudo auditctl -s | grep lost

Ráta-korlátozás (Rate limiting)

A ráta-korlátozás megakadályozza, hogy egy rosszindulatú (vagy egyszerűen rosszul megírt) folyamat szándékosan elárasztja az audit alrendszert:

# Maximális eseményráta beállítása (esemény/másodperc)
# 0 = nincs korlátozás (nem ajánlott produkciós környezetben)
-r 5000

Zajos szabályok kizárása

Egyes alkalmazások és rendszerfolyamatok iszonyatosan sok audit eseményt generálnak anélkül, hogy bármilyen biztonsági értékük lenne. Ezeket szűrő szabályokkal ki lehet zárni:

# /etc/audit/rules.d/20-filters.rules

# Nagyszámú fájlolvasást végző felügyeleti eszközök kizárása
-a never,exit -F exe=/usr/sbin/zabbix_agentd -k exclude_monitoring
-a never,exit -F exe=/usr/bin/prometheus-node-exporter -k exclude_monitoring

# Cron démon rutinjellegű tevékenysége
-a never,exit -F exe=/usr/sbin/cron -F syscall!=execve -k exclude_cron

# Auditd saját folyamatainak kizárása
-a never,exit -F exe=/usr/sbin/auditd -k exclude_auditd
-a never,exit -F exe=/usr/sbin/auditctl -k exclude_auditd

Fontos figyelmeztetés: A kizáró szabályokkal nagyon óvatosan kell bánni. Egy rosszul konfigurált kizárás biztonsági vakfoltot hozhat létre — és éppen ott fog bejönni a támadó, ahol nem figyelsz. Minden kizárási szabályt dokumentálj, és rendszeresen vizsgáld felül.

Immutable szabályok (-e 2)

Az immutable (változtathatatlan) mód az egyik legfontosabb biztonsági funkció: megakadályozza, hogy bárki — beleértve a root felhasználót is — módosítsa az audit szabályokat a rendszer újraindítása nélkül:

# /etc/audit/rules.d/99-finalize.rules
# Az audit konfiguráció zárolása — módosítás csak újraindítás után lehetséges
-e 2

Ha egy támadó root hozzáférést szerez, az első dolga általában az audit szabályok letiltása. Az immutable móddal ez nem lehetséges újraindítás nélkül — ami viszont már maga is egy észlelhető esemény.

További bevált gyakorlatok

• Mindig használj kulcsokat (-k) — Minden szabályhoz rendelj egyedi kulcsot. Ez drámaian meggyorsítja a keresést és lehetővé teszi a hatáselemzést.
• Tesztelj staging környezetben — Új szabályokat soha ne közvetlenül éles rendszeren vezess be. Először staging környezetben mérd fel a teljesítményhatást.
• Monitorozd az audit alrendszert — Rendszeresen ellenőrizd az auditctl -s kimenetét. Figyeld a lost és backlog értékeket — ha a lost szám nő, baj van.
• Dokumentáld a szabályokat — Minden szabályhoz írj megjegyzést, hogy miért került bevezetésre. Három hónap múlva hálás leszel magadnak.
• Rendszeres felülvizsgálat — Negyedévente vizsgáld felül a szabálykészletet. Távolítsd el a már nem releváns szabályokat, és adj hozzá újakat az aktuális fenyegetések alapján.
• Korrelálj más naplóforrásokkal — Az audit naplókat a SIEM-ben más forrásokkal kombinálva exponenciálisan nő az észlelési képesség.
• Arch szabályok duplikálása — 64 bites rendszeren mindig hozz létre szabályt mind a b64, mind a b32 architektúrára. A 32 bites alkalmazások a 32 bites rendszerhívásokat használják, és meglepő módon még 2026-ban is akadnak ilyenek.
• Az auid!=4294967295 szűrő — Ez kiszűri a démonok és rendszerfolyamatok által generált eseményeket, amelyeknek nincs bejelentkezési munkamenetük. Legyél tudatos a használatával: bizonyos támadási vektorok éppen ezeket a folyamatokat célozzák.

Összefoglalás

A Linux Audit keretrendszer (auditd) 2026-ban is az egyik leghatékonyabb és legmélyebbre ható biztonsági monitorozó eszköz, amellyel egy Linux rendszergazda vagy biztonsági elemző dolgozhat. A kernel szintű működés, a rendszerhívás-szintű granularitás és a széleskörű konfigurálhatóság olyan védelmi réteget biztosít, amelyet sem az alkalmazásszintű naplózás, sem a hálózati monitorozás nem tud pótolni.

Foglaljuk össze, mit tanultunk:

1. Architektúra — A kernel audit alrendszer, a kauditd szál, az auditd démon és az audisp pluginek alkotják a teljes láncot a rendszerhívástól a naplófájlig.
2. Szabálytípusok — A fájlrendszer-figyelés (-w), a rendszerhívás-figyelés (-a) és a vezérlő szabályok (-b, -f, -e) kombinációja biztosítja az átfogó lefedettséget.
3. Fenyegetésvadászat — Az ausearch és aureport eszközökkel hatékonyan kutathatók a sikertelen bejelentkezések, gyanús parancsvégrehajtások, jogosultságemelési kísérletek és LOTL technikák.
4. Megfelelőség — Az auditd közvetlenül támogatja a CIS Benchmark Level 2 és a NIST 800-53 (AU-2, AU-3, AU-12) kontrollokat.
5. SIEM-integráció — A Wazuh, az Elastic Auditbeat, az audisp-remote és az rsyslog révén az audit naplók beilleszthetők a szervezet központi biztonsági monitorozó rendszerébe.
6. Teljesítmény — A puffer hangolás, a kizáró szabályok, az immutable mód és a rendszeres felülvizsgálat biztosítja, hogy a monitorozás ne váljon a rendszer szűk keresztmetszetévé.

A védelmi mélység (defense-in-depth) stratégiájában az auditd a detektálási réteg egyik pillére. Kiegészíti a megelőző kontrollokat — tűzfalat, hozzáférés-vezérlést, javításkezelést — és olyan rálátást biztosít a rendszer működésére, amelyet semmilyen más eszközzel nem lehet elérni.

Az 5500+ Linux kernel CVE egyértelmű üzenet: a proaktív monitorozás nem luxus, hanem szükségszerűség. Az auditd ennek a proaktivitásnak a magja — és 2026-ban, a folyamatosan növekvő fenyegetettség közepette, fontosabb, mint valaha. Fogj hozzá, építsd fel a saját szabálykészletedet, és ne feledd: a legjobb audit konfiguráció az, amelyik a te környezetedre van szabva.