AIDE na Linuxe v roku 2026: File Integrity Monitoring, konfigurácia a detekcia narušenia

Aktualizované: 4. august 2026

AIDE (Advanced Intrusion Detection Environment) je open-source nástroj pre monitoring integrity súborov na Linuxe, ktorý vytvorí kryptografický snapshot súborového systému a upozorní na neautorizované zmeny. V roku 2026 zostáva AIDE zlatým štandardom pre offline file integrity monitoring (FIM) a je vyžadovaný CIS benchmarkami, PCI DSS 4.0 aj HIPAA. Tento sprievodca ukazuje inštaláciu, produkčnú konfiguráciu, automatizáciu cez systemd timery a integráciu s Wazuh SIEM.

• AIDE 0.19 (vydané 2025) prináša natívnu podporu SHA-3, BLAKE2 a fs-verity attribútov pre modernú kryptografiu.
• Referenčná databáza musí byť uložená offline (napr. na read-only médiu alebo vzdialenom serveri), aby ju útočník nemohol prepísať súčasne so škodlivými zmenami.
• Kombinácia AIDE + auditd pokrýva ako periodickú (batch), tak realtime detekciu. Auditd zachytí zmenu v momente vzniku, AIDE ju potvrdí kryptograficky.
• Pre RHEL 10, Debian 13 a Ubuntu 26.04 LTS je AIDE dostupný priamo z oficiálnych repozitárov bez EPEL závislostí.
• Automatizácia cez aide.timer (systemd) je spoľahlivejšia než cron kvôli náhodnému RandomizedDelaySec, ktorý rozkladá zaťaženie na flotile.
• CIS Level 2 benchmarky vyžadujú AIDE beh minimálne raz denne a odosielanie výstupu do centrálneho SIEM systému.

Čo je AIDE a ako funguje file integrity monitoring

AIDE funguje na princípe offline snapshotu. Pri prvom spustení prejde definovanú množinu súborov a adresárov, vypočíta pre každý z nich kryptografické atribúty (SHA-512, SHA-3, BLAKE2, veľkosť, inode, mtime, ACL, xattr, capabilities) a uloží ich do binárnej databázy. Pri každom ďalšom behu tento snapshot porovná s aktuálnym stavom a vypíše rozdiely: pridané, zmenené, odstránené súbory.

Na rozdiel od realtime FIM riešení ako Wazuh syscheck alebo eBPF-based Tetragon monitoring, AIDE nezachytáva zmeny v momente vzniku. Beží periodicky ako batch úloha. Táto architektúra má dve výhody: nulová performance réžia mimo spustenia a odolnosť voči útokom, ktoré vypnú kernel-space senzory. Nevýhodou je detekčný delay medzi zmenou a jej hlásením.

Preto sa AIDE v modernej Linux security architektúre kombinuje s realtime nástrojmi. AIDE poskytuje kryptografický ground truth (dôveryhodný baseline), zatiaľ čo auditd s MITRE ATT&CK pravidlami alebo eBPF-based tools poskytujú okamžité alerty. Táto dvojfázová stratégia je odporúčaná NIST SP 800-53 kontrolou SI-7 (Software, Firmware, and Information Integrity).

Osobne som na jednom projekte hodinu ladil "záhadné" AIDE alerty, kým mi došlo, že sme mali AIDE aj Wazuh syscheck súčasne, a jeden druhému vlastne prepisovali baseline. Keď oba nástroje bežia paralelne, treba jasne rozdeliť zodpovednosti: AIDE robí kryptografický audit raz denne, Wazuh syscheck robí realtime alerting. Nikdy nie oba na tie isté cesty.

Kryptografické algoritmy podporované v AIDE 0.19 zahŕňajú SHA-256, SHA-512, SHA-3 (Keccak), BLAKE2b a RIPEMD-160. Pre 2026 je odporúčaná kombinácia SHA-512 + BLAKE2b. Dva nezávislé hashe zabránia tomu, aby útočník vytvoril kolíziu naraz v oboch algoritmoch.

Inštalácia AIDE na RHEL 10, Debian 13 a Ubuntu 26.04

Inštalačný postup sa líši podľa distribúcie. AIDE je však od roku 2025 dostupný priamo z oficiálnych repozitárov všetkých hlavných Enterprise Linux distribúcií, takže už netreba EPEL alebo tretie strany.

RHEL 10 / Rocky Linux 10 / AlmaLinux 10

# Inštalácia z BaseOS repozitára
sudo dnf install -y aide

# Overenie verzie (mala by byť 0.19 alebo novšia)
aide --version

# Overenie SELinux kontextu binárky
ls -Z /usr/sbin/aide
# system_u:object_r:aide_exec_t:s0

Debian 13 / Ubuntu 26.04 LTS

# AIDE je v main repozitári
sudo apt update
sudo apt install -y aide aide-common

# Debian používa /var/lib/aide/aide.db.new pre novú databázu
# Ubuntu má pre-generovaný /etc/aide/aide.conf.d/ adresár

# Overenie inštalácie
which aide aideinit update-aide.conf

Overenie integrity samotného balíka

Pred inštaláciou má zmysel overiť podpis balíka. Inak by útočník mohol podvrhnúť kompromitovanú verziu AIDE, ktorá by ignorovala jeho backdoor. Použite GPG kľúč distribútora:

# RHEL/Rocky: overenie GPG podpisu
sudo dnf install --downloadonly aide
rpm -Kv /var/cache/dnf/*/packages/aide-*.rpm

# Debian/Ubuntu: overenie SHA256 z Debian Snapshot
apt download aide
sha256sum aide_*.deb
# Porovnaj s https://snapshot.debian.org/

Konfigurácia /etc/aide.conf: pravidlá, skupiny a výnimky

Súbor /etc/aide.conf definuje čo AIDE monitoruje a ktoré atribúty zaznamenáva. Konfigurácia sa skladá z troch častí: makrá (cesty a databázy), definície skupín (rule groups) a selection lines (ktoré adresáre s ktorými pravidlami).

Základná štruktúra konfigurácie

# /etc/aide.conf — produkčný baseline pre RHEL 10

# --- Cesty a databázy ---
database_in=file:/var/lib/aide/aide.db.gz
database_out=file:/var/lib/aide/aide.db.new.gz
database_new=file:/var/lib/aide/aide.db.new.gz
gzip_dbout=yes

# --- Report ---
report_url=file:/var/log/aide/aide.log
report_url=syslog:LOG_AUTH
report_level=changed_attributes

# --- Rule groups ---
# Kombinácia SHA-512 + BLAKE2b + xattr + ACL
FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha512
PARANOID = FIPSR+sha3_512+blake2b+capabilities+ftype

# Pre logy: len rast, žiadne pravidlá pre obsah
LOGS = p+i+n+u+g+S

# --- Selection lines (dôležitá je poradie!) ---
/boot     PARANOID
/bin      FIPSR
/sbin     FIPSR
/usr/bin  FIPSR
/usr/sbin FIPSR
/lib      FIPSR
/lib64    FIPSR
/etc      PARANOID

# Konfiguračné súbory bezpečnostných služieb
/etc/ssh/sshd_config    PARANOID
/etc/sudoers            PARANOID
/etc/sudoers.d          PARANOID
/etc/pam.d              PARANOID
/etc/selinux            PARANOID

# Aplikačné logy: len sledovanie existencie
/var/log LOGS

# Vylúčenia (! na začiatku)
!/var/log/journal
!/var/log/lastlog
!/var/log/wtmp
!/var/log/btmp
!/var/lib/aide/aide.db.new.gz
!/tmp
!/proc
!/sys
!/run

Kľúčové je pochopiť syntax pravidiel. Každý znak reprezentuje jeden atribút. p = permissions, i = inode, n = number of links, u = user, g = group, s = size, m = mtime, c = ctime, S = check for growing size only, sha512 = SHA-512 hash, xattrs = extended attributes, acl = POSIX ACL, selinux = SELinux label. Kompletný zoznam nájdete v oficiálnej AIDE dokumentácii.

Vylúčenie pseudo-filesystémov a runtime dát

Adresáre /proc, /sys, /run a /dev obsahujú kernel-generated data, ktoré sa menia každú sekundu. Ich zahrnutie zaplní databázu odpadom a spomalí AIDE 100×. Vždy ich vylúčte pomocou ! operátora. Podobne /var/cache, /tmp, adresáre package managerov (/var/lib/dnf, /var/lib/apt) a container runtime storage (/var/lib/containers, /var/lib/docker).

Inicializácia databázy a prvý integrity check

Po dokončení konfigurácie treba vytvoriť referenčnú databázu (baseline). Toto je kritický krok. Databáza sa vytvára z aktuálneho stavu systému, takže systém musí byť v čistom, dôveryhodnom stave. Odporúčaný postup: nový server, hneď po inštalácii OS, pred pripojením do siete a pred spustením akýchkoľvek workloadov.

# --- 1. Inicializácia databázy ---
sudo aide --init
# Čas: 2-15 minút podľa veľkosti súborového systému

# --- 2. Aktivácia databázy (RHEL/Fedora) ---
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

# --- 3. Aktivácia databázy (Debian/Ubuntu) ---
sudo aideinit --yes --force
# Alebo manuálne:
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# --- 4. Prvý test: okamžite by mal vrátiť "no differences" ---
sudo aide --check
echo "Exit code: $?"
# 0 = žiadne zmeny
# 1-7 = detekované zmeny (bitmasked: 1=added, 2=removed, 4=changed)

Testovanie funkčnosti detekcie

Pred nasadením do produkcie treba overiť, že AIDE naozaj deteguje zmeny. Poviem otvorene, tento krok som kedysi preskočil, a potom sa zistilo (na audite), že baseline bol vygenerovaný z už kompromitovaného systému. Klasický funkčný test:

# Simulácia útoku — zmena binárky
sudo cp /bin/ls /bin/ls.backup
sudo bash -c 'echo " " >> /bin/ls'

# AIDE musí detegovať zmenu
sudo aide --check
# Očakávaný výstup:
# File: /bin/ls
#  Size    : 138472  , 138473
#  SHA512  : QzYxNjNhZDU2...  , NmFkNzhkMzM4...

# Obnova
sudo mv /bin/ls.backup /bin/ls
sudo aide --update
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

Automatizácia AIDE cez systemd timery a cron

Manuálne spúšťanie AIDE v produkcii nefunguje. Potrebujete pravidelný, deterministický beh, a moderný spôsob na Linuxe je systemd timer. Debian a Ubuntu poskytujú dailyaidecheck.timer out-of-the-box, ale pre RHEL a produkčné nasadenie odporúčam vlastný service + timer pár s email/SIEM notifikáciou.

systemd service a timer

# /etc/systemd/system/aide-check.service
[Unit]
Description=AIDE File Integrity Check
Documentation=man:aide(1)
ConditionPathExists=/var/lib/aide/aide.db.gz

[Service]
Type=oneshot
Nice=19
IOSchedulingClass=idle
ExecStart=/usr/sbin/aide --check --config=/etc/aide.conf
# Výstup ide do syslogu vďaka report_url=syslog v aide.conf
StandardOutput=journal
StandardError=journal
# Sandbox samotnej AIDE služby
ProtectSystem=strict
ReadOnlyPaths=/
ReadWritePaths=/var/lib/aide /var/log/aide
NoNewPrivileges=yes
PrivateTmp=yes

# /etc/systemd/system/aide-check.timer
[Unit]
Description=Denný AIDE integrity check
Requires=aide-check.service

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=1800
Persistent=true
AccuracySec=1min

[Install]
WantedBy=timers.target

# Aktivácia
sudo systemctl daemon-reload
sudo systemctl enable --now aide-check.timer

# Overenie
systemctl list-timers aide-check.timer
journalctl -u aide-check.service --since "24 hours ago"

RandomizedDelaySec=1800 je vo flotile kľúčový. Ak beží AIDE na 500 serveroch naraz o 03:00, monitoring alert sa zaplní súčasne 500 správami a operátor nič nevidí. Náhodné rozptýlenie 30 minút rozloží záťaž rovnomerne. Persistent=true zabezpečí, že check prebehne aj vtedy, ak bol server v čase spustenia offline (napríklad reboot počas patching okna).

AIDE vs Tripwire, Samhain a osquery FIM

AIDE nie je jediný FIM nástroj na Linuxe. Rozhodnutie medzi alternatívami závisí od požiadaviek na realtime detekciu, centralizáciu a licenciu.

Vlastnosť	AIDE 0.19	Tripwire Open Source	Samhain 4.5	osquery FIM
Licencia	GPL v2	GPL v2	GPL v2	Apache 2.0
Realtime detekcia	Nie (batch)	Nie (batch)	Áno (inotify)	Áno (fsevents)
Centralizovaný server	Externe (Wazuh)	Externe	Vstavaný (Yule)	osquery Fleet
Podpora SHA-3/BLAKE2	Áno	Nie	Áno	SHA-256 only
Konfigurácia	Textová	Textová (twpol)	Textová	SQL queries
Aktívny vývoj (2026)	Aktívny	Nízky	Aktívny	Aktívny
Container awareness	Manuálna	Manuálna	Manuálna	Natívna
Náročnosť nasadenia	Nízka	Stredná	Vysoká	Stredná

Kedy vybrať AIDE: jednoduché servery, silné compliance požiadavky (CIS, PCI DSS), nemáte SIEM tím na komplexnú integráciu, chcete offline databázový model. Kedy vybrať Samhain: vyžadujete realtime alerting a máte centrálny Samhain server (Yule). Kedy vybrať osquery: flotila kontajnerov a Kubernetes, chcete SQL-based dotazy naprieč hostmi.

Integrácia s Wazuh SIEM a odosielanie reportov

AIDE výstup uložený len na jednom serveri nie je bezpečnostne relevantný, keďže útočník ho môže prepísať. Reporty preto musia ísť do vzdialeného SIEM. Kompletný sprievodca centrálnym SIEM nasadením nájdete v článku Wazuh ako open-source SIEM a XDR pre Linux.

Konfigurácia AIDE výstupu do syslogu

# V /etc/aide.conf pridajte:
report_url=file:/var/log/aide/aide.log
report_url=syslog:LOG_AUTH
report_url=stdout

# rsyslog forward do Wazuh managera
# /etc/rsyslog.d/60-aide.conf
if $programname == 'aide' then {
    action(type="omfwd"
           target="wazuh-manager.internal"
           port="514"
           protocol="tcp"
           template="RSYSLOG_SyslogProtocol23Format")
    stop
}

Wazuh rule pre AIDE alerty

# /var/ossec/etc/rules/local_rules.xml
<group name="aide,integrity,">
  <rule id="100501" level="10">
    <decoded_as>aide</decoded_as>
    <match>File: /etc/</match>
    <description>AIDE: Modifikácia konfiguračného súboru v /etc</description>
    <mitre>
      <id>T1543</id>
    </mitre>
  </rule>

  <rule id="100502" level="12">
    <decoded_as>aide</decoded_as>
    <match>File: /bin/|/sbin/|/usr/bin/|/usr/sbin/</match>
    <description>AIDE: Kritická modifikácia systémovej binárky</description>
    <mitre>
      <id>T1554</id>
    </mitre>
  </rule>
</group>

MITRE mapovanie T1554 (Compromise Host Software Binary) a T1543 (Create or Modify System Process) umožňuje SOC analytikom kontextovo triedbovať alerty. Zmena v /bin/ls má výrazne inú prioritu než zmena v /etc/hostname.

Ochrana AIDE databázy pred manipuláciou

Najčastejšia chyba pri deploymente AIDE je uloženie databázy na monitorovaný súborový systém. Ak útočník získa root a prepíše aj /var/lib/aide/aide.db.gz súčasne s malicious zmenami, AIDE hlási "no changes". Existujú štyri overené obrany:

1. Offline read-only médium

# Uloženie databázy na read-only mount
# /etc/fstab
/dev/sdb1  /var/lib/aide  ext4  ro,noexec,nosuid,nodev  0 0

# Pri aktualizácii dočasne remount:
sudo mount -o remount,rw /var/lib/aide
sudo aide --update
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
sudo mount -o remount,ro /var/lib/aide

2. Vzdialené úložisko cez SSH/rsync

#!/bin/bash
# /usr/local/sbin/aide-remote-check.sh
set -euo pipefail

# Stiahni databázu z centrálneho servera
scp -o StrictHostKeyChecking=yes \
    [email protected]:/backup/aide/$(hostname).db.gz \
    /tmp/aide.db.gz

# Overenie GPG podpisu databázy
gpg --verify /tmp/aide.db.gz.sig /tmp/aide.db.gz

# Spusti check s ephemerálnou databázou
aide --check --config=/etc/aide.conf \
     -B "database_in=file:/tmp/aide.db.gz"

# Vyčisti
shred -u /tmp/aide.db.gz

3. GPG podpisovanie databázy

Aj keď útočník získa read prístup k databáze, bez privátneho GPG kľúča ju nedokáže prepísať tak, aby prešla verifikáciou. Po každom aide --update podpíšte databázu offline kľúčom:

sudo aide --update
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
gpg --detach-sign --output /var/lib/aide/aide.db.gz.sig \
    /var/lib/aide/aide.db.gz

4. Immutable atribút (chattr +i)

# Nastavenie immutable (ani root nemôže prepísať)
sudo chattr +i /var/lib/aide/aide.db.gz

# Pri legitímnej aktualizácii:
sudo chattr -i /var/lib/aide/aide.db.gz
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
sudo chattr +i /var/lib/aide/aide.db.gz

Kombinácia chattr +i s OpenSCAP CIS benchmarkami tvorí základnú defense-in-depth vrstvu vyžadovanú NIST SP 800-53 SI-7.

CIS benchmarky, PCI DSS a mapovanie na compliance

File integrity monitoring je explicitne vyžadovaný niekoľkými compliance rámcami. AIDE splní tieto požiadavky "out of the box" pri správnej konfigurácii:

• CIS Benchmark for RHEL 10 Level 2 (sekcia 6.1.2): "Configure filesystem integrity checking". Konkrétne požaduje AIDE alebo ekvivalent, so spustením minimálne raz denne.
• PCI DSS 4.0, požiadavka 11.5: "Deploy a change-detection mechanism to alert personnel to unauthorized modification of critical system files, configuration files, or content files." Audítor akceptuje AIDE report ako dôkaz.
• HIPAA Security Rule §164.312(c)(1): Integrity controls. Vyžaduje mechanizmus na detekciu neautorizovaných zmien elektronických zdravotných záznamov.
• NIST SP 800-53 Rev. 5, kontrola SI-7: Software, Firmware, and Information Integrity. AIDE priamo mapuje na (1), (5) a (7) enhancement.
• ISO/IEC 27001:2022, Annex A 8.32: Change management. Kombinácia AIDE + auditd poskytuje audit trail.

Pre detailný Red Hat guide pre AIDE compliance a scap-security-guide profile xccdf_org.ssgproject.content_profile_cis, ktoré automaticky konfigurujú AIDE podľa CIS Level 2 baseline.

Riešenie problémov: false positives a výkon

Produkčné AIDE deploymenty najčastejšie zlyhávajú na dvoch veciach: alert fatigue z false positives a nadmerná spotreba I/O pri denných checkoch.

Časté zdroje false positives

• Package updates: dnf update alebo apt upgrade zmenia stovky binárok naraz. Riešenie: po každom patchi spustite aide --update ako súčasť post-patching pipeline.
• Journal a lastlog: /var/log/journal, /var/log/lastlog, /var/log/wtmp sa menia pri každom prihlásení. Vylúčte cez !.
• SELinux relabeling: restorecon mení xattr, ale nie obsah. Ak monitorujete selinux attribute, po každom relabel je potrebný update.
• Ansible/Puppet drift: Configuration management prepisuje súbory. Buď udržujte konfiguračné súbory idempotentné, alebo integrujte aide --update do CM run hooks.

Optimalizácia výkonu

# --- 1. Použite iba potrebné hashe ---
# BLAKE2b je ~2× rýchlejší ako SHA-512 na moderných CPU
FAST = p+i+n+u+g+s+m+c+blake2b

# --- 2. Paralelizujte cez xargs (pre veľmi veľké systémy) ---
# AIDE 0.19 podporuje --workers=N parameter
sudo aide --check --workers=$(nproc)

# --- 3. Ionice + nice pre nižšiu prioritu ---
sudo ionice -c 3 nice -n 19 aide --check

# --- 4. Vylúčte cache a temporary adresáre ---
!/var/cache
!/var/tmp
!/var/lib/dnf
!/var/lib/apt
!/var/lib/containers
!/var/lib/docker

Na typickom serveri s 500 GB dát a NVMe SSD zaberie AIDE check s BLAKE2b približne 3-5 minút. Na spinning disku počítajte s 20-40 minútami. Pre kontajnerové hosty s tisíckami image layer files môžete použiť --limit parameter na inkrementálny check adresárov po dávkach.

Debug mód pri neočakávanom výstupe

# Verbose režim ukáže, ktoré pravidlá matchujú
sudo aide --check --verbose=20

# Dry-run bez porovnávania (len parse konfigurácie)
sudo aide --config-check

# Použitie AIDE 0.19 s JSON výstupom pre SIEM parsing
sudo aide --check --report=json:/var/log/aide/aide.json

Pre kompletný zoznam možností konfigurácie a advanced use cases pozrite oficiálny AIDE GitHub repozitár, kde nájdete aj CHANGELOG s prehľadom noviniek v 0.19.

Často kladené otázky

Ako často by mal AIDE bežať v produkcii?

CIS Level 2 benchmark vyžaduje minimálne raz za 24 hodín. Pre high-security prostredia (PCI DSS zóna, systémy so zdravotnými dátami) je bežná frekvencia každých 4-6 hodín. Väčšia frekvencia neprináša výraznú detekčnú výhodu. Pre realtime detekciu použite auditd alebo eBPF-based nástroje ako Tetragon.

Čo znamená exit code 1, 2, 4 alebo 7 pri aide --check?

AIDE používa bitmasked exit code: 1 = pridané súbory, 2 = odstránené súbory, 4 = zmenené súbory. Exit code 7 (1+2+4) znamená, že AIDE detegoval všetky tri typy zmien. Exit 0 znamená čistý systém. Kódy 8+ signalizujú chybu (napr. nedostupná databáza, syntax error v aide.conf).

Ako obnoviť AIDE databázu po legitímnej aktualizácii systému?

Spustite sudo aide --update, ktorý porovná stav a zároveň vygeneruje novú databázu v /var/lib/aide/aide.db.new.gz. Po revízii report a potvrdení, že všetky zmeny sú očakávané, presuňte novú databázu do produkčnej cesty: sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz. Nikdy neaktualizujte databázu bez ľudskej kontroly reportu.

Prečo AIDE deteguje zmeny v /var/log aj keď som nič nemenil?

Logy sa menia neustále. Každé prihlásenie, každá spustená služba, každý cron job zapisuje. Pre /var/log použite oddelené pravidlo LOGS = p+i+n+u+g+S, ktoré kontroluje len rastúcu veľkosť súboru (nie mtime, hash ani obsah). A vylúčte /var/log/journal, lastlog, wtmp a btmp úplne.

Je AIDE vhodný na monitoring Docker/Podman kontajnerov?

Pre monitoring hosta áno, chráni container runtime binaries (containerd, runc, podman) a konfiguráciu. Pre monitoring vnútra kontajnerov je AIDE zle vybraný nástroj: kontajnery sú efemérne a ich filesystem je typicky read-only. Použite radšej image scanning (Trivy, Grype) pri buildu a runtime detekciu cez Falco alebo Tetragon.

Ako integrovať AIDE s existujúcim Wazuh SIEM?

Nakonfigurujte v /etc/aide.conf report na syslog (report_url=syslog:LOG_AUTH), presmerujte rsyslog na Wazuh manager na porte 514, a v Wazuh local_rules.xml pridajte pravidlá s <decoded_as>aide</decoded_as>. Wazuh 4.9+ obsahuje built-in AIDE decoder, netreba manuálne parsovanie.