Linux Auditd – Beveiligingsgebeurtenissen correct loggen

Linux Auditd registreert beveiligingsrelevante gebeurtenissen rechtstreeks vanuit de kernel en biedt mij een volledig controletraject voor aanmeldingen, bestandswijzigingen, de uitvoering van commando's en systeemaanroepen. Juist Als ik het systeem zo configureer, kan ik aanvallen in een vroeg stadium detecteren, voldoen aan compliance-eisen zoals ISO 27001 of PCI DSS en incidenten op forensisch verantwoorde wijze analyseren.

Centrale punten

Deze Ik vat het overzicht bewust beknopt, praktijkgericht en zonder holle frasen samen, zodat je meteen begrijpt hoe je auditregels definieert, logbestanden beveiligt en conclusies trekt. I Noem de belangrijkste componenten, typische toepassingen, zinvolle regels en bronnen van fouten die in veel omgevingen tot blinde vlekken leiden. Dus zie je in één oogopslag welke instellingen in auditd.conf van belang zijn en welke tools beschikbaar zijn voor de analyse. Vervolgens Ik ga dieper in op elk onderwerp aan de hand van voorbeelden, duidelijke aanbevelingen en een tabel met belangrijke parameters. Dus dat dan lukt het je om de overstap te maken van „Auditd draait“ naar „Auditd levert bruikbare beveiligingssignalen“.

• Controlespoor: volledige traceerbaarheid van veiligheidsrelevante handelingen
• Regels: specifiek kritieke bestanden, execve, rechten en configuraties
• Logboekbeveiliging: Rotatie, opslagtrigger, reactie bij knelpunten
• Op afstand: centrale verzameling via TCP/TLS en SIEM-koppeling
• Analyse: ausearch, aureport, duidelijke sleutels en overzichtelijke documentatie

Linux Auditd in het beveiligingsconcept

Auditd vormt een aanvulling op klassieke systeemlogboeken door zich specifiek te richten op beveiligingsrelevante acties en de gebeurtenissen via de kernel-interface vast te leggen. De Daemon schrijft deze gebeurtenissen standaard naar /var/log/audit/audit.log en registreert welke gebruiker welke actie op welk tijdstip heeft uitgevoerd. Daardoor kan ik verdachte zaken snel controleren, zoals onbedoelde wijzigingen aan /etc/ssh/sshd_config of bij gevoelige bestanden zoals /etc/shadow. Op In gereguleerde omgevingen verzamel ik hiermee bewijsmateriaal van overtredingen van richtlijnen en voldoe ik aan de eisen voor een betrouwbare logboekregistratie. Tegenover In tegenstelling tot klassieke logboek- of syslog-gegevens biedt Auditd het diepgaande, op beveiliging gerichte inzicht dat van cruciaal belang is voor het opsporen van aanvallen.

Architectuur: kernel, daemon, hulpprogramma's

De Het auditing-systeem bestaat uit een kernel-subsysteem voor de registratie en de user-space-dienst auditd voor opslag en tools voor beheer en analyse. Over auditctl stel ik regels in tijdens de uitvoering of laad ik bij het opstarten permanente regels in /etc/audit/rules.d/*.rules. Met ausearch filter ik gebeurtenissen op tijd, gebruiker, sleutel of bestand, terwijl aureport compacte rapporten worden gegenereerd. Dus Ik combineer gedetailleerde registratie met snelle analyse en zorg ervoor dat het audittraject van begin tot eind traceerbaar blijft. Belangrijk is een consistente naamgeving via -k Sleutels, zodat latere zoekopdrachten correct werken.

Installatie en activering

Op Ik installeer RHEL/CentOS audit via dnf install audit of yum install audit, op Debian/Ubuntu gebruik ik apt install auditd audispd-plugins. Volgens Na de installatie start en activeer ik de dienst met systemctl start auditd en systemctl enable auditd, de status controleer ik met systemctl status auditd. Zodra Als het auditsubsysteem en de dienst actief zijn, worden gebeurtenissen volgens de regels opgeslagen in /var/log/audit/audit.log. I Controleer of het werkt door gericht toegang te krijgen tot een bewaakt bestand en zoek vervolgens de gebeurtenis met ausearch -k keyname. Voor Om bij elke opstart een consistente start te garanderen, zorg ik ervoor dat er permanente regels zijn en dat deze correct worden geladen.

Vroegtijdige start, achterstand en bescherming tegen regels

Naar Om de vroege opstartgebeurtenissen niet te missen, activeer ik het auditsubsysteem al bij het opstarten van de kernel. Daarnaast stel ik kernelparameters in en zorg ik voor een voldoende grote backlog, zodat er tijdens de opstartfase geen gebeurtenissen verloren gaan. Daarnaast Na het laden beveilig ik de regelbasis tegen manipulatie.

• Kernelparameters: audit=1 audit_backlog_limit=8192 in /etc/default/grub aanvullen, vervolgens update-grub (Debian/Ubuntu) of grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL/CentOS) uitvoeren.
• Achterstand in regels: In de startregels stel ik in -b 8192, om de kernel-wachtrij op de juiste manier te dimensioneren.
• Regels blokkeren: Nadat de definitieve regelbasis is geladen, activeer ik de Immutable-modus met -e 2. Wijzigingen zijn dan alleen nog mogelijk na een herstart – een effectieve bescherming tegen manipulaties tijdens het gebruik.
• Overloopgedrag: In /etc/audit/auditd.conf ik definieer overflow_action (bijv. SYSLOG of SINGLE), zodat ik bij een volle buffer duidelijk gedefinieerde reacties krijg.

Auditregels correct vaststellen

De De kwaliteit van het audittraject hangt af van duidelijke, gerichte regels die cruciale handelingen omvatten en onnodige ruis voorkomen. Voor Gevoelige bestanden zet ik bijvoorbeeld -w /etc/passwd -p warx -k passwd_changes en voeg passende regels toe voor /etc/shadow, /etc/sudoers of /etc/ssh/. Naar Om de uitvoering van opdrachten vast te leggen, gebruik ik -a always,exit -F arch=b64 -S execve en de 32-bits-variant, zodat elke versie zichtbaar blijft, ook via wortel. Voor Hulpprogramma's zoals Apache filter ik gericht op basis van het pad naar het binaire bestand, bijvoorbeeld -a always,exit -F arch=b64 -S all -F exe=/usr/sbin/apache2 -k apache_activity. I Documenteer elke regel met beknopte opmerkingen en eenduidige sleutels, zodat analyses reproduceerbaar blijven en collega’s de bedoeling ervan kunnen begrijpen.

Geavanceerde regelvoorbeelden en afstemming

Voor Om meer diepgang te bieden, stel ik een gerichte set samen die wijzigingen in privileges, ingrepen in de kernel, tijd- en netwerkwijzigingen en persistente mechanismen zichtbaar maakt – zonder ruis van pakketten of back-ups.

• Alleen interactieve gebruikers: -F auid>=1000 -F auid!=4294967295 aangevuld met execve-Regels om systeemservices uit te sluiten.
• Wijziging van bevoegdheden: -a always,exit -F arch=b64 -S setuid,setreuid,setresuid -k priv_change en de 32-bits-versie. Optioneel: -C uid!=euid, indien veldvergelijkingen worden ondersteund.
• Kernelmodules: -a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k kmod_change; bovendien: -w /sbin/insmod -p x -k kmod_exec, -w /sbin/modprobe -p x -k kmod_exec.
• Tijdswijzigingen: -a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time_change en -w /etc/localtime -p wa -k time_change.
• Mounts en bestandssysteem: -a always,exit -F arch=b64 -S mount,umount2 -k fs_mount; -w /etc/fstab -p wa -k fs_mount.
• netwerkbasis: -a always,exit -F arch=b64 -S sethostname,setdomainname -k net_conf; -w /etc/hosts -p wa -k net_conf, -w /etc/hostname -p wa -k net_conf, -w /etc/resolv.conf -p wa -k net_conf.
• Cron en timer: -w /etc/crontab -p wa -k sched, -w /etc/cron.d/ -p wa -k sched, -w /var/spool/cron/ -p wa -k sched, -w /etc/systemd/system/ -p wa -k sched, -w /usr/lib/systemd/system/ -p wa -k sched.
• Persistentie via SSH: -w /root/.ssh/ -p wa -k ssh_keys, -w /home/ -p wa -k ssh_keys (smal pad op authorized_keys-bestanden per gebruiker, om ruis te voorkomen).
• Misbruik van SUID/SGID tegengaan: Focus op mappen met uitvoerbare bestanden: -w /usr/bin/ -p wa -k bin_change, -w /usr/sbin/ -p wa -k bin_change, -w /bin/ -p wa -k bin_change, -w /sbin/ -p wa -k bin_change.
• Alleen mislukkingen registreren (voor luide syscalls): -a always,exit -F arch=b64 -S open,openat -F success=0 -k file_denied.
• Ruis onderdrukken: Pakketbeheerders/back-ups uitsluiten, bijvoorbeeld. -a never,exit -F exe=/usr/bin/dpkg, -a never,exit -F exe=/usr/bin/apt, -a never,exit -F exe=/usr/bin/yum, -a never,exit -F exe=/usr/bin/rpm, -a never,exit -F exe=/usr/bin/rsync (Controleer het pad per distributie).

Logboekbeheer en bescherming tegen verlies van logboeken

Zonder Zelfs bij een soepele rotatie en duidelijke drempels bestaat het risico dat auditlogs waardevolle gegevens kwijtraken of het bestandssysteem volraken. Op /etc/audit/auditd.conf Ik definieer onder andere max_log_file, max_log_file_action, num_logs, space_left en reacties zoals space_left_action, disk_full_action of disk_error_action. I Ik geef de voorkeur aan acties zoals ROTATE en een tijdige melding via Syslog, zodat ik bij knelpunten tijdig kan reageren. Daarnaast Ik sla auditlogs op een aparte host op om manipulatie op het betreffende systeem te bemoeilijken en bewijsmateriaal te bewaren. De In de volgende tabel worden de belangrijkste parameters weergegeven en worden typische, praktijkgerichte instellingen getoond.

Parameters	Doel	Voorbeeld	Tip
logbestand	Opslaglocatie van de auditlogs	/var/log/audit/audit.log	Standaardpad behouden en rechten duidelijk vastleggen
log_format	Formaat van de evenementen	RAW	RAW vergemakkelijkt forensische analyse zonder informatieverlies
max_log_file	Maximale bestandsgrootte (MB)	100 tot 500	De grootte aanpassen aan het aantal gebeurtenissen en de opslagcapaciteit
max_log_file_action	Actie bij het bereiken van de grootte	ROTATE	Rotatie voorkomt stilstand of overschrijven
num_logs	Aantal opgeslagen bestanden	5 tot 10	Voldoende geschiedenis voor analyses, zonder veel geheugen te verbruiken
space_left	Drempelwaarde voor vrije opslagruimte (MB)	1024 of hoger	Vroegtijdige waarschuwingen zorgen voor reactietijd
space_left_action	Reactie bij onderblijven	SYSLOG	Overweeg daarnaast een e-mail of een SIEM-waarschuwing
disk_full_action	Wat te doen als de gegevensdrager vol is	SUSPEND of STOP	Een duidelijke beslissing hangt af van de risicobereidheid

Logboekregistratie op afstand en centrale analyse

Voor Voor veel hosts maak ik gebruik van centrale registratie via TCP/TLS, aangestuurd door parameters zoals tcp_listen_port en bijbehorende tegenstukken. Over Via audispd-plugins of rsyslog stuur ik gebeurtenissen door naar een SIEM- of beveiligingsplatform, waarbij ik aanmeldingsfouten, configuratiewijzigingen en verdachte processtarts met elkaar in verband breng. Dus zie ik patronen die op een afzonderlijke server onopvallend lijken, maar die in combinatie onmiddellijk alarm slaan. Wie die al dashboards gebruikt, profiteert van Logboekaggregatie in hosting, omdat auditgebeurtenissen daar worden samengevoegd met andere telemetriegegevens. I Zorg bovendien voor een beveiligde transportroute en een duidelijke scheiding tussen de productieve systemen en de verzamelinstantie.

Analyse: doelgericht gebruikmaken van ausearch en aureport

Ruwe gegevens zijn waardeloos als ik ze niet snel kan filteren, dus begin ik met duidelijke zoektermen en gebruik ik ausearch voor gerichte zoekopdrachten. Met ausearch -k passwd_changes -ts today ik beoordeel bijvoorbeeld recente wijzigingen aan /etc/passwd uit; indien nodig pas ik het tijdvenster en de gebruikersfilter aan. Voor Levert overzichtsrapporten aureport --summary compacte tabellen die opvallende aanmeldingen, bestandswijzigingen en de frequentie van systeemoproepen zichtbaar maken. Daarnaast Ik vul het overzicht van processtarts en het gebruik van middelen aan met Procesboekhouding, om patronen in uitvoeringen en piekbelastingen met elkaar in verband te brengen. Op Het gaat er uiteindelijk om dat ik vragen binnen enkele seconden kan beantwoorden: wie, wat, wanneer, waar en op welke manier.

De analyse verdiepen: gebeurtenisvelden correct interpreteren

Dus dat Om ervoor te zorgen dat analyses accuraat zijn, ken ik de belangrijkste velden en gebeurtenistypen. SYSCALL-De vermeldingen omvatten onder andere. auid (registratie-UID), uid/euid/suid (reële/effectieve/opgeslagen UID), ses (sessie-ID) en exe (uitvoerbaar bestand). PATH-Blokken geven de betreffende paden weer, EXECVE somt de argumenten op, CWD geeft de werkdirectory weer. Met ausearch -m SYSCALL -sc execve -ua 1000 -ts recent richt ik me op interactieve uitvoeringen; aureport -x --summary -i geeft me in één oogopslag de frequenties en opvallende punten. Belangrijk: auid blijft over sudo of setuid-sprongen zijn constant en vormen daarom het robuustere filtercriterium voor „Wie heeft het in gang gezet?“.

Typische fouten vermijden

Naar Te ruim geformuleerde regels zorgen ervoor dat de logbestanden te omvangrijk worden en verbergen de echt belangrijke aanwijzingen; daarom concentreer ik me op kritieke bestanden, execve, wijzigingen in bevoegdheden en beveiligingsrelevante configuraties. Ontbreekt Een soepele rotatie; systemen lopen anders risico, daarom stel ik duidelijke grenzen vast voor omvang en aantal, evenals maatregelen bij knelpunten. I controleer ook de auditconfiguratie en de map /var/log/audit/, omdat aanvallers hun sporen willen uitwissen. En Ik leg elke regel vast met een code, een doel en een korte toelichting, zodat de analyses consistent blijven. Wie Wie zich zorgen maakt over de prestaties, moet nauwkeurig filteren, overbodige paden verwijderen en het effect van nieuwe regels eerst in tests controleren.

Prestaties, stabiliteit en kwaliteitscontroles

Controle mag de bedrijfsvoering niet belemmeren. I controleer regelmatig met auditctl -s, of verloren-Er kunnen gebeurtenissen optreden, en houd de backlog-waarden in de gaten na wijzigingen in de regels. Op Bij een hoge werklast vergroot ik de dispatcher-wachtrij (q_diepte) van de audispd-plug-ins en stel in overflow_action bewust. Waar execve-Als regels te veel volume opleveren, beperk ik dat via auid of via exe=-Stel whitelists/blacklists in en registreer bij luide syscalls alleen mislukkingen. Voor Voorafgaand aan de brede uitrol test ik nieuwe regels in de staging-omgeving, meet ik de gebeurtenisfrequentie en de CPU-belasting en vergelijk ik aureport --summary vóór/na de wijziging, om het effect te kwantificeren.

Container- en virtualisatieomgevingen

Op Naast container-hosts registreert de kernel ook containerprocessen – dat is de bedoeling, maar het kan wel wat lawaai maken. I ik baseer me op de bescherming van de host (bijv. dockerd of Podman), veilige binaire paden en configuraties, en filter het gebruikersoverzicht via auid. Voorbeelden: -w /usr/bin/dockerd -p x -k container_runtime, -w /etc/docker/ -p wa -k container_conf, plus algemene hostregels zoals execve met auid-Filter. Op Bij VM's behandel ik auditlogs als vluchtige gegevens: ik schakel doorsturen op afstand in, stel de rotatieperiode kort in en let bij snapshots op tijdconsistentie. Belangrijk Dan blijft er nog een nauwkeurige NTP/Chrony-synchronisatie over, zodat tijdlijnanalyses betrouwbaar zijn.

Naleving en documentatie

Voor Voor ISO 27001 (o.a. A.12.4 Logging/Monitoring, A.16 Incidentbeheer) en PCI DSS (hoofdstuk 10) stel ik controleerbare bewijsstukken op: Wat Wordt er bijgehouden hoe lang, wie heeft toegang en hoe wordt de integriteit gewaarborgd? I Zorg ervoor dat de regelbasis van versies wordt voorzien, documenteer sleutels en doeleinden, onderteken archieflogs met hashes en sla ze op op een manier die manipulatie onmogelijk maakt. Op Bij de verwerking van persoonsgegevens pas ik het beginsel van gegevensminimalisatie toe (gerichte regels, korte bewaartermijnen) en stel ik duidelijke verwijderingsprocedures vast. Dus Zo ontstaan rapporten die auditors overtuigen en bij een incident daadwerkelijk antwoorden bieden.

Beheer, monitoring en playbooks

Op Bij langdurig gebruik heb ik vaste routines nodig: dagelijkse steekproeven met aureport, waarschuwingen bij verloren > 0, Controle van de vrije auditpartitie en de doorsturing op afstand. I Maak playbooks aan: „Opvallende leidinggevenden“ (filter op exe= en auid), „Kritisch bestand gewijzigd“ (correlatie tussen PATH, SYSCALL, EXECVE), „kernel-ingreep“ (regels met betrekking tot init_module en mount). Bekend Soorten evenementen zoals ANOM_PROMISCUOUS (interface in promisc-modus) of MAC_POLICY_LOAD (MAC-beleid geladen) beoordeel ik op basis van prioriteit en zet ik de volgende stappen in gang.

Probleemoplossing en herstart

Wanneer Als er geen evenementen binnenkomen, kijk ik eerst of ausearch -m DAEMON -ts today en auditctl -s (Status/Backlog). Ontbreken Regels, ik laad ze op met augenrules --load nieuw en controleer met auditctl -l. Is de Immutable-modus is ingeschakeld (-e 2), dan helpt alleen een herstart met aangepaste opstartregels. Op Problemen met autorisatie op /var/log/audit/ Ik herstel de eigenaar en de modus; als SELinux actief is, corrigeer ik de contexten. En Ik controleer of log_format = RAW is vastgelegd – leesbare invoer voor forensisch onderzoek en parsers.

Auditd in hostingomgevingen

Rechtstreeks In hostingomgevingen met veel workloads helpt Auditd mij om de scheiding tussen klanten inzichtelijk te maken en misbruik in een vroeg stadium op te sporen. I Houd web-, database- en applicatieservers in de gaten met gelaagde regelsets en integreer de gebeurtenissen in bestaande monitoring- en incidentresponssystemen. Voor Ik zorg voor een duidelijke scheiding door middel van centrale opslag, afzonderlijke rollen en beperkte rechten op logbestanden. Naar Indien nodig voeg ik aanvullende systeemdiagnostiek toe journalctl voor foutopsporing, maar bewaar veiligheidsrelevante analyses in de eerste plaats in het auditkanaal. Dus Zo ontstaat een betrouwbaar controlespoor dat de belangen van de klanten, compliance-eisen en operationele efficiëntie met elkaar in evenwicht brengt.

Kort en bondig: mijn aanpak

I Begin met een duidelijk doel voor ogen, stel gerichte regels op voor kritieke bestanden, `execve` en wijzigingen in bevoegdheden, en zorg ervoor dat de rotatie beschermd is tegen gegevensverlies. Dan Ik schakel doorsturen op afstand met TLS in, documenteer de sleutels en test het effect van elke regel voordat deze op grote schaal wordt geïmplementeerd. Voor Ik richt me bij mijn dagelijkse werk op ausearch en aureport, voer gerichte zoekopdrachten uit en stel overzichtelijke rapporten op voor de bedrijfsvoering en de beveiliging. Op Als ik afwijkingen constateer, koppel ik auditgebeurtenissen aan andere signalen, zoals proces- of netwerkgegevens, om de oorzaak snel te achterhalen. Dus Linux Auditd levert mij geen stortvloed aan logbestanden op, maar wel duidelijke antwoorden op veiligheidsgerelateerde vragen in productieomgevingen.