Linux auditd 2026: Käytännön opas auditointisääntöihin, ausearchiin ja LOTL-uhkien havaitsemiseen

auditd, eli Linux Audit Daemon, on Linuxin ytimen tason valvontaketjun käyttäjätilakomponentti. Toisin kuin tavallinen sovelluslokitus, auditd saa tapahtumansa suoraan ytimen audit-alijärjestelmältä — eli se näkee jokaisen järjestelmäkutsun, tiedostotapahtuman ja oikeudenkorotuksen riippumatta siitä, kirjautuuko sovellus tapahtumasta itse vai ei. Juuri tämä tekee siitä korvaamattoman työkalun forensiikkaan, vaatimustenmukaisuuteen (PCI-DSS, HIPAA, CIS, STIG) ja erityisesti vuonna 2026 räjähdysmäisesti yleistyneiden LOTL-hyökkäysten (Living off the Land) tunnistamiseen.

Rehellisesti sanottuna: jos joudut joskus selittämään tietoturvavälikohtausta auditorille, auditd on se järjestelmä, jota toivot tarkistaneesi etukäteen. Tässä oppaassa käydään läpi auditdin kovettaminen tuotantokäyttöön — konfiguraatiotiedostojen viritys, sääntökirjaston rakentaminen kerroksittain, ausearch- ja aureport-komentojen tehokas käyttö, suorituskyvyn säätäminen sekä lokien välittäminen Wazuh-SIEMiin. Esimerkit on testattu Ubuntu 24.04- ja RHEL 9 -järjestelmissä audit-userspace 4.0:lla.

Miksi auditd on välttämätön vuonna 2026

CISAn, FBIn, NSA:n ja NCSC-UK:n yhteinen LOTL-uhkavaroitus vuodelta 2024 muutti pelin perinpohjin: valtiolliset toimijat kuten Volt Typhoon pesivät kriittiseen infrastruktuuriin yli viideksi vuodeksi käyttämättä yhtään uutta haittaohjelmaa — vain Linuxin omia työkaluja. Vuonna 2026 sama tekniikka on rikollisten valtavirtaa.

Perinteinen tiedostoperustainen virustorjunta ei näe niitä, koska levylle ei kirjoiteta uusia binäärejä. Mitä ne kuitenkin synnyttävät on poikkeavia syscall-sekvenssejä — ja juuri ne auditd näkee.

Yhden palvelimen syscall-virrasta saadaan kerralla:

• Kuka (auid, uid, gid) suoritti minkäkin komennon
• Mitä binääriä ajettiin (executable, comm)
• Mitä tiedostoja luettiin tai muutettiin (path, mode, perms)
• Mistä päästä yhteys tuli (hostname, addr)
• Onnistuiko operaatio (success=yes/no, exit-koodi)

Aika harva muu työkalu antaa tämän kaiken yhdellä kertaa, ja vielä ytimen aitona tapahtumana — ei sovelluksen omana tulkintana.

Arkkitehtuuri: ydin, kuljettaja ja työkalut

Audit-järjestelmä koostuu neljästä kerroksesta:

1. Ytimen audit-alijärjestelmä — tuottaa tapahtumat audit-soketin kautta käyttäjätilaan.
2. auditd-demoni — kuuntelee soketin viestejä ja kirjoittaa ne tiedostoon /var/log/audit/audit.log.
3. auditctl — lataa ja kysyy sääntöjä ajossa olevasta ytimestä.
4. ausearch / aureport / aulast — analyysi- ja raportointityökalut.

Säännöt määritellään pysyvästi hakemiston /etc/audit/rules.d/ alle. Tiedostot luetaan numeroidussa järjestyksessä ja yhdistetään tiedostoksi /etc/audit/audit.rules, jonka augenrules-skripti tuottaa käynnistyksessä:

10-base-config.rules     # auditctl-asetukset, puskurit, failure mode
20-dont-audit.rules      # poikkeukset, melun vaimentaminen
30-stig.rules            # pääsääntökirjasto (CIS/STIG/LOTL)
40-local.rules           # paikalliset lisäsäännöt
50-server.rules          # palvelinkohtaiset säännöt
70-rules.rules           # paikallinen viritys
90-finalize.rules        # asettaa säännöt muuttumattomiksi (-e 2)

Kerrostettu rakenne kannattaa ottaa käyttöön heti — se säästää tunteja kun joudut myöhemmin jäljittämään, mistä jokin tietty melusääntö tulee.

auditd.confin viritys tuotantoon

Pääkonfiguraatiotiedosto on /etc/audit/auditd.conf. Aloita levyn ja muistin budjetoinnista. Tuotannossa puutteellinen levyvaraus johtaa joko menetettyihin tapahtumiin tai (pahimmillaan) järjestelmän pysähtymiseen.

# /etc/audit/auditd.conf — tuotantokovettu pohja

log_file = /var/log/audit/audit.log
log_format = ENRICHED            # liittää uid->nimi, syscall->nimi mukaan
log_group = adm
priority_boost = 4
flush = INCREMENTAL_ASYNC
freq = 50

# Lokirotaatio — ~1 GB budjetti
max_log_file = 128               # MB per tiedosto
num_logs = 8                     # 8 x 128 MB = 1 GB
max_log_file_action = ROTATE

# Levytilan hälytykset
space_left = 1024                # MB
space_left_action = SYSLOG
admin_space_left = 256
admin_space_left_action = SINGLE  # vaihda HALT, jos vaaditaan tiukkaa
disk_full_action = SUSPEND
disk_error_action = SUSPEND

# Verkkolähetys (jos ei käytä auditd-pluginia)
tcp_listen_queue = 5
tcp_max_per_addr = 1
use_libwrap = yes
enable_krb5 = no

ENRICHED-formaatin tärkeys: ilman sitä lokirivit sisältävät vain numeerisia uid-, gid- ja syscall-arvoja, jotka tekevät analyysistä turhauttavan työlästä. ENRICHED lisää nimet rinnalle erikseen, joten lokit ovat luettavia ilman -i-lippua. Pieni asetus, iso ero arjessa.

10-base-config.rules — ytimen perusvirtys

# /etc/audit/rules.d/10-base-config.rules

# Tyhjennä aiemmat säännöt latauksen alussa
-D

# Puskurin koko (tapahtumia jonossa). 8192 sopii kuormitettuun palvelimeen.
-b 8192

# Failure mode: 0 = vain logi, 1 = printk, 2 = kernel panic
# Vaatimustenmukaisuus (STIG) edellyttää usein arvoa 1 tai 2.
-f 1

# Hylkäysjonon koko
--backlog_wait_time 60000

20-dont-audit.rules — melun vaimentaminen

Ilman tätä kerrosta tuotantopalvelin tuottaa miljoonia rivejä päivässä epäolennaista dataa. Sääntö -a never ohittaa tapahtuman jo ytimessä — paljon tehokkaampaa kuin suodattaa myöhemmin (mikä on muuten yllättävän yleinen virhe).

# /etc/audit/rules.d/20-dont-audit.rules
# HUOM: nämä säännöt PITÄÄ ladata ennen suodatussääntöjä.

# Älä auditoi cron-ajureiden taustaa
-a never,user -F subj_type=crond_t
-a never,exit -F subj_type=crond_t

# Älä auditoi VMware-työkalujen lukukyselyitä
-a never,exit -F arch=b64 -F path=/usr/bin/vmware-toolbox-cmd -F perm=x

# Vältä /proc-pollausta
-a never,exit -F dir=/proc

30-stig.rules — pääsääntökirjasto

Tämä on raskaan sarjan kerros. Yhdistä CIS-, STIG- ja LOTL-säännöt yhdeksi tuotettavaksi tiedostoksi. Älä yritä kirjoittaa kaikkea itse — käytä lähtökohtana Neo23x0/auditd-projektia tai virallista linux-audit/audit-userspace-repoa. Pyörän keksiminen uudestaan ei tässä kannata.

Sudo- ja oikeustoimitusten valvonta

# Sudo-konfiguraatiomuutokset
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions

# SUID/SGID-ohjelmien suorittaminen ihmiskäyttäjänä
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F auid>=1000 -F auid!=unset -k privileged_exec
-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -F auid>=1000 -F auid!=unset -k privileged_exec

Huomaa auid>=1000: Debian/Ubuntu sekä RHEL 7+:n UID_MIN on 1000. Jos /etc/login.defs kertoo eri arvon, korvaa se kaikkialla. auditd ei tue muuttujia, joten korvaus on tehtävä käyttöönotossa (Ansible-Jinja, sed tai envsubst — itse käytän mieluiten Ansiblea, koska sääntötiedostoja on harvoin vain yksi).

Tunnistusten ja salasanatiedostojen valvonta

-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/security/opasswd -p wa -k identity
-w /etc/pam.d/ -p wa -k pam_config

SSH- ja avainvaraston valvonta

-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/ssh/sshd_config.d/ -p wa -k sshd_config
-w /root/.ssh/ -p wa -k root_ssh_keys
-a always,exit -F dir=/home -F perm=wa -F path=.ssh/authorized_keys -k user_ssh_keys

LOTL-tekniikoiden tunnistus: shell-spawn ja tulkit

LOTL-hyökkääjä käyttää bash:ia, python3:a, perl:iä ja nc:tä luodakseen takaoven käyttämättä uusia binäärejä. Säännöt, jotka kohdistuvat näiden ajoon kohonneilla oikeuksilla, ovat erittäin matalan kohinan ja korkean signaalin yhdistelmä — siis juuri sitä, mitä SOC-tiimi haluaa.

# Tulkkien suoritus normaalin käyttäjän auid:lla — yhdistettynä oikeudenkorotukseen
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/python3 -F auid>=1000 -F auid!=unset -k lotl_interpreter
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/perl -F auid>=1000 -F auid!=unset -k lotl_interpreter
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/ncat -F auid>=1000 -F auid!=unset -k lotl_netcat
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/socat -F auid>=1000 -F auid!=unset -k lotl_netcat

# Crontab- ja systemd-yksiköiden muutokset (yleinen pysyvyysmekanismi)
-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /etc/anacrontab -p wa -k cron
-w /var/spool/cron/ -p wa -k cron
-w /etc/systemd/system/ -p wa -k systemd_units
-w /usr/lib/systemd/system/ -p wa -k systemd_units

Ytimen modulilataus

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

Tiedostonpoistot ja nimeämiset

Yhdistä syscall-säännöt suorituskyvyn vuoksi. Jokainen sääntö arvioidaan jokaisesta syscallista — turhat säännöt nostavat CPU-kuormaa nopeasti. Tämä on yksi niistä asioista, joita ei huomaa testiympäristössä mutta jotka iskevät tuotannossa.

-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=unset -k delete
-a always,exit -F arch=b32 -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=unset -k delete

90-finalize.rules — sääntöjen lukitseminen

# /etc/audit/rules.d/90-finalize.rules
# -e 2 lukitsee säännöt: niitä ei voi enää muuttaa ennen järjestelmän
# uudelleenkäynnistystä. STIG:n vaatimus.
-e 2

Lataus ja varmistus:

# Yhdistä rules.d-tiedostot ja lataa
sudo augenrules --load

# Tarkista ladatut säännöt
sudo auditctl -l | head -20

# Tarkista immutable-tila (peli on '2', kun '90-finalize.rules' luettu)
sudo auditctl -s | grep enabled

# Käynnistä auditd uudelleen jos teit muutoksia auditd.confiin
sudo systemctl restart auditd

ausearch — kohdennettu hakeminen

ausearch käy audit.log-tiedostoa läpi ja palauttaa tapahtumat avaimen, käyttäjän, järjestelmäkutsun, ajan tai tapahtumatyypin perusteella. Lippu -i kääntää numerot luettaviksi nimiksi (jos et käytä ENRICHED-formaattia, mitä siis suosittelin yllä).

# Kaikki kirjautumiset tänään
sudo ausearch -m USER_LOGIN -ts today -i

# Epäonnistuneet kirjautumiset
sudo ausearch -m USER_LOGIN -sv no -ts today -i

# Kaikki tapahtumat avaimella 'identity' (passwd/shadow-muutokset)
sudo ausearch -k identity -ts today -i

# LOTL-hälytykset 24 tunnin ajalta
sudo ausearch -k lotl_interpreter -ts recent -i
sudo ausearch -k lotl_netcat -ts recent -i

# Tietyltä käyttäjältä
sudo ausearch -ua alice -ts today -i

# Tietyssä aikaikkunassa
sudo ausearch -ts 03/01/2026 08:00:00 -te 03/01/2026 17:00:00 -k actions

# SELinux AVC-hylkäykset
sudo ausearch -m AVC -ts today -i

# Tilien luonti / poisto
sudo ausearch -m ADD_USER -m DEL_USER -m ADD_GROUP -m DEL_GROUP -i

Voit myös ohjata raakatapahtuman aureport:lle tarkempaa raporttia varten:

sudo ausearch -k privileged_exec -ts recent --raw | aureport --executable --interpret

aureport — yhteenvedot ja säännölliset auditit

# Yleisyhteenveto
sudo aureport --summary

# Kaikki todennusyritykset
sudo aureport --auth -i

# Vain epäonnistuneet kirjautumiset
sudo aureport --login --failed -i

# Tiedostokäyttöyhteenveto
sudo aureport --file --summary

# Käyttäjät, jotka ajoivat suorituksia tänään
sudo aureport --executable -ts today -i | sort -k2 | uniq -c | sort -rn | head -20

# Tilimuutosraportti viimeisen viikon ajalta
sudo aureport --mods -ts week-ago -te now

Päivittäinen automatisoitu yhteenveto

Kirjoita yksinkertainen skripti tiedostoon /usr/local/bin/audit-daily.sh ja ajasta se cronilla. Tämä on yksi niitä matalan vaivan, korkean tuoton tehtäviä, joita lykkää aina seuraavaan sprinttiin — älä lykkää.

#!/usr/bin/env bash
set -euo pipefail
TS="$(date +%Y-%m-%d)"
OUT="/var/log/audit-reports/${TS}.txt"
mkdir -p "$(dirname "$OUT")"
{
  echo "=== Audit Daily Report ${TS} ==="
  echo "--- Yhteenveto ---"
  aureport --summary -ts yesterday -te today
  echo "--- Epäonnistuneet kirjautumiset ---"
  aureport --login --failed -ts yesterday -te today -i
  echo "--- LOTL-tulkit ---"
  ausearch -k lotl_interpreter -ts yesterday -te today -i 2>/dev/null || true
  echo "--- Privileged exec ---"
  ausearch -k privileged_exec -ts yesterday -te today -i 2>/dev/null || true
} > "$OUT"

Suorituskyvyn säätäminen

Kuormitetussa palvelimessa puskurin koko on yleisin pullonkaula. Jos näet rivin "audit: backlog limit exceeded", korota arvoa 10-base-config.rules:ssa:

# Tarkista nykyinen jonon tila
sudo auditctl -s | grep -E 'backlog|lost'

# Kasvata vaiheittain: 8192 → 16384 → 32768
-b 16384

Toinen yleinen ongelma on liian runsas sääntövalikoima ilman -a never -suodatusta. Käytä auditctl -s:n raportoimaa lost-arvoa pohjana — jos se on yli nolla, jotain on pielessä.

Wazuh-integraatio: keskitetty SIEM-analyysi

Yksin auditd ei tarjoa hälytyksiä — se vain tallentaa tapahtumia. Lähetä lokit Wazuhiin reaaliaikaista korrelaatiota varten.

Wazuh-agentti lukee /var/log/audit/audit.log-tiedostoa, mutta varmista että ossec.conf sisältää:

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

Wazuhin oletussäännöt nostavat privileged_exec- ja identity-avainten tapahtumat hälytyksiksi. Räätälöi sääntö local_rules.xml:ään LOTL-tunnistukselle:

<group name="audit,lotl,">
  <rule id="100501" level="10">
    <if_sid>80700</if_sid>
    <match>key=lotl_interpreter</match>
    <description>LOTL: tulkin suoritus loppukäyttäjäkontekstissa</description>
    <mitre>
      <id>T1059</id>
    </mitre>
  </rule>

  <rule id="100502" level="12">
    <if_sid>80700</if_sid>
    <match>key=lotl_netcat</match>
    <description>LOTL: ncat/socat reverse-shell -indikaattori</description>
    <mitre>
      <id>T1071</id>
      <id>T1059</id>
    </mitre>
  </rule>
</group>

Vianmääritys: yleisimmät ongelmat

"Cannot open file" augenrules-ajossa

Yleensä syynä on -i-lipun puute säännössä, joka viittaa puuttuvaan polkuun. Lisää -i tai poista sääntö, joka koskee asentamatonta pakettia. Yksinkertainen korjaus, mutta hämmentää ensikertalaista.

Säännöt eivät pysy uudelleenkäynnistyksen yli

Tarkista, että muokkaat /etc/audit/rules.d/*.rules-tiedostoja, et auditctl:lla ajossa olevia sääntöjä. Ajossa olevat säännöt katoavat boottauksessa — tämän olen itse oppinut kantapään kautta enemmän kuin kerran.

auid on -1 (4294967295) jossain tapahtumissa

Tämä tarkoittaa, että auid:tä ei ole asetettu — yleensä järjestelmäpalveluja, jotka käynnistyivät ennen kirjautumista. Käytä -F auid!=unset sulkemaan ne pois ihmis-aktiviteettisääntöistä.

32- vs 64-bittinen arkkitehtuuri

32- ja 64-bittisten syscallien numerot eivät aina vastaa toisiaan. Säännöksi tulee yleensä kahdella rivillä — yksi -F arch=b64, toinen -F arch=b32 — ja arch-suodatin on aina -S:ää ennen, jotta auditctl käyttää oikeaa hakutaulukkoa.

Vaatimustenmukaisuusprofiilit valmiina

Kolme suosittua sääntökirjastoa, jotka voit klonata sellaisinaan ja räätälöidä:

• linux-audit/audit-userspace — viralliset PCI-DSS-, NISPOM- ja STIG-sääntötiedostot.
• Neo23x0/auditd — Florian Rothin kuratoima "best practice" -ruleset SIGMA-yhteensopivilla avainnimillä.
• steveandreassend/linux_auditd — CIS- ja STIG-yhdistelmä laajennettuna LOTL-säännöillä CISAn ohjeen mukaisesti.

Usein kysytyt kysymykset

Mitä eroa on auditctl:lla ja augenrules:lla?

auditctl lataa sääntöjä ajossa olevaan ytimeen, mutta muutokset eivät säily uudelleenkäynnistyksen yli. augenrules taas yhdistää /etc/audit/rules.d/-hakemiston tiedostot, kirjoittaa /etc/audit/audit.rules-tiedoston ja lataa ne auditctl:lla. Tuotannossa muokkaa aina rules.d-tiedostoja ja lataa augenrules --load:lla.

Kuinka paljon levytilaa auditd kuluttaa tyypillisessä palvelimessa?

Hyvä lähtökohta on 1 GB lokille per palvelin (max_log_file=128, num_logs=8). Vilkas web-palvelin kattavalla sääntökirjastolla voi kuitenkin tuottaa 200–500 MB päivässä, jolloin tarvitset joko isomman budjetin tai lokien välittömän lähetyksen SIEMiin (Wazuh, Splunk, Elastic).

Voiko auditd havaita rootkitin?

Osittain. Käyttäjätilan rootkit, joka muokkaa /etc/passwd:ia, asentaa pysyvyyden cron-/systemd-yksiköihin tai lataa ytimen moduuleja, jää sääntöihin identity, cron, systemd_units ja modules. Ydintason rootkit, joka kaappaa itse audit-soketin, voi piilottaa itsensä — täydennä siksi auditd:tä eBPF-pohjaisilla työkaluilla kuten Falco ja AIDE-tiedostoeheystarkistuksella.

Hidastaako auditd järjestelmää?

Hyvin viritetty sääntöjoukko (alle 100 sääntöä, syscallit yhdistettyinä) lisää <1 % CPU-kuormaa tyypillisessä palvelimessa. Liian laaja syscall-valvonta ilman -a never -suodatusta voi nostaa kuorman 10–30 %:iin. Mittaa auditctl -s:n lost-arvolla — yli nolla tarkoittaa, että puskuri tai säännöt eivät kestä kuormaa.

Korvaako Wazuh tai Falco auditd:n?

Ei, vaan ne täydentävät sitä. Wazuh on SIEM/XDR-alusta, joka korreloi auditd:n tapahtumat muiden lokien (SSH, sudo, syslog, OSSEC FIM) kanssa ja tuottaa hälytyksiä. Falco käyttää eBPF:ää ja on parempi konteksti-tietoisessa runtime-uhkien havaitsemisessa erityisesti konteissa. auditd on kuitenkin edelleen luotetuin lähde forensiikalle ja vaatimustenmukaisuusauditeille (PCI, HIPAA, STIG), koska sen tapahtumat ovat ytimen aitoja, ei agentin synteesiä.

Yhteenveto

auditd on Linuxin oma uhkien havaitsemisalusta — se ei kilpaile kaupallisten EDR-tuotteiden kanssa, vaan tarjoaa korkealaatuista raakadataa, jota ne kaikki tarvitsevat. Vuonna 2026 LOTL-hyökkäysten valtavirtaistuessa hyvin viritetty auditd on edullisin yksittäinen investointi tunkeutumisen havaitsemiseen.

Aloita tämän oppaan kerroksitellulla sääntöstruktuurilla, lisää privileged_exec-, identity- ja lotl_*-avaimet, kytke lähetys Wazuhiin ja jätä cron ajamaan päivittäinen aureport-yhteenveto. Sen jälkeen voit kerrostaa päälle Falcon konttitarkkailua ja AIDE:n tiedostoeheyden — mutta perustaksi auditd ja sen ylläpidettävät säännöt riittävät kaikille vaatimustenmukaisuusprofiileille PCI-DSS:stä CIS Level 2:een. Hyvää virittämistä.