Linux Auditd – Korrekt logning af sikkerhedshændelser

Linux Auditd logger sikkerhedsrelevante hændelser direkte fra kernen og giver mig et fuldstændigt revisionsspor for log-ins, filændringer, kommandoudførelser og systemkald. Korrekt Når systemet er konfigureret, kan jeg opdage angreb tidligt, overholde compliance-krav som ISO 27001 eller PCI DSS og foretage en forensisk holdbar analyse af hændelser.

Centrale punkter

Denne Jeg har bevidst valgt at holde oversigten kortfattet, praktisk orienteret og uden tomme floskler, så du straks kan forstå, hvordan du definerer auditregler, beskytter logfiler og drager konklusioner. I Nævn de vigtigste komponenter, typiske anvendelsessituationer, fornuftige regler og fejlkilder, der i mange miljøer fører til blinde vinkler. Så kan du med et blik se, hvilke indstillinger i auditd.conf der er relevante, og hvilke værktøjer der står til rådighed til analysen. Efterfølgende Jeg går i dybden med hvert emne ved hjælp af eksempler, klare anbefalinger og en tabel over afgørende parametre. Så det lykkes det dig at gå fra „Auditd kører“ til „Auditd leverer brugbare sikkerhedssignaler“.

• Revisionsspor: fuldstændig sporbarhed af sikkerhedsrelevante handlinger
• Regler: specifikke kritiske filer, execve, privilegier og konfigurationer
• Logbeskyttelse: Rotation, lagerudløser, reaktion ved flaskehalse
• Fjernbetjening: central indsamling via TCP/TLS og SIEM-integration
• Analyse: ausearch, aureport, klare nøgler og overskuelig dokumentation

Linux Auditd i sikkerhedskonceptet

Auditd supplerer de klassiske systemlogfiler ved målrettet at fokusere på sikkerhedsrelevante handlinger og registrere hændelserne via kernel-grænsefladen. Der Daemon logger som standard disse begivenheder /var/log/audit/audit.log og registrerer, hvilken bruger der har udført hvilken handling på hvilket tidspunkt. Derfor kan jeg hurtigt undersøge mistænkelige forhold, f.eks. utilsigtede ændringer i /etc/ssh/sshd_config eller følsomme filer som /etc/shadow. På I regulerede miljøer sikrer jeg dermed dokumentation for overtrædelser af retningslinjer og opfylder kravene til en pålidelig logføring. Overfor I modsætning til klassiske log- eller syslog-data giver Auditd det dybtgående, sikkerhedsfokuserede overblik, der er afgørende for at afdække angreb.

Arkitektur: Kernel, daemon, værktøjer

Das Auditeringssystemet er opdelt i et kernel-undersystem til registrering og en user-space-tjeneste auditd til lagring samt værktøjer til administration og analyse. Omkring auditctl Jeg opretter regler under kørsel eller indlæser permanente regler ved opstart /etc/audit/rules.d/*.rules. Med ausearch filtrerer jeg begivenheder efter tid, bruger, nøgle eller fil, mens aureport genererer kortfattede rapporter. Så Jeg kombinerer detaljeret registrering med hurtig analyse og sikrer, at revisionssporet er fuldt sporbar hele vejen igennem. Vigtigt er en konsekvent benævnelse af -k Nøgler, så senere søgninger fungerer korrekt.

Installation og aktivering

På Jeg installerer RHEL/CentOS revision via dnf install audit eller yum install audit, på Debian/Ubuntu bruger jeg apt install auditd audispd-plugins. I henhold til Efter installationen starter og aktiverer jeg tjenesten med systemctl start auditd og systemctl enable auditd, jeg tjekker status med systemctl status auditd. Så snart Når auditsubsystemet og tjenesten kører, havner hændelserne i henhold til reglerne i /var/log/audit/audit.log. I Kontroller, at funktionen virker, ved at foretage en målrettet adgang til en overvåget fil, og søg derefter efter hændelsen med ausearch -k keyname. For For at sikre en ensartet opstart ved hver opstart sørger jeg for, at der findes permanente regler, og at de indlæses korrekt.

Tidlig start, oparbejdet efterslæb og beskyttelse mod regler

På For ikke at gå glip af tidlige boot-hændelser aktiverer jeg audit-undersystemet allerede ved kerneopstarten. I den forbindelse indstiller jeg kerneparametre og en tilstrækkelig stor backlog-størrelse, så begivenheder ikke går tabt i opstartsfasen. Derudover Efter indlæsningen låser jeg regelbasen for at forhindre manipulation.

• Kernel-parametre: audit=1 audit_backlog_limit=8192 på /etc/default/grub tilføje, derefter opdater-grub (Debian/Ubuntu) eller grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL/CentOS).
• Efterslæb i reglerne: I startreglerne indstiller jeg -b 8192, for at dimensionere kernel-køen korrekt.
• Blokér regler: Når den endelige regelbase er indlæst, aktiverer jeg Immutable-tilstanden med -e 2. Ændringer kan derefter kun foretages efter en genstart – en effektiv beskyttelse mod manipulationer under drift.
• Overløbsadfærd: I /etc/audit/auditd.conf Jeg definerer overflow_action (f.eks. SYSLOG eller SINGLE), så jeg får klart definerede reaktioner, når bufferen er fuld.

Sådan defineres revisionsregler korrekt

Die Kvaliteten af revisionssporet afhænger af klare, målrettede regler, der dækker kritiske handlinger og undgår unødvendig støj. For Følsomme filer placerer jeg for eksempel -w /etc/passwd -p warx -k passwd_changes og tilføj passende regler for /etc/shadow, /etc/sudoers eller /etc/ssh/. På For at registrere udførelsen af kommandoer bruger jeg -a always,exit -F arch=b64 -S execve samt 32-bit-versionen, så hver udgave forbliver synlig, også gennem rod. For Jeg filtrerer hjælpeprogrammer som Apache målrettet via binærfilens sti, for eksempel -a always,exit -F arch=b64 -S all -F exe=/usr/sbin/apache2 -k apache_activity. I Dokumentér hver regel med korte kommentarer og entydige nøgler, så analyserne forbliver reproducerbare, og kollegerne kan forstå hensigten.

Avancerede regeleksempler og finjustering

For For at gå mere i dybden sammensætter jeg et målrettet sæt, der synliggør privilegieskift, indgreb i kernen, ændringer i tid og netværk samt vedvarende mekanismer – uden støj fra pakker eller sikkerhedskopier.

• Kun interaktive brugere: -F auid>=1000 -F auid!=4294967295 suppleret til execve-Regler til at udelukke systemtjenester.
• Skift af privilegier: -a always,exit -F arch=b64 -S setuid,setreuid,setresuid -k priv_change og 32-bit-versionen. Valgfrit: -C uid!=euid, hvis felt sammenligninger understøttes.
• Kernelmoduler: -a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k kmod_change; desuden: -w /sbin/insmod -p x -k kmod_exec, -w /sbin/modprobe -p x -k kmod_exec.
• Tidsændringer: -a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time_change og -w /etc/localtime -p wa -k time_change.
• Monteringer og filsystem: -a always,exit -F arch=b64 -S mount,umount2 -k fs_mount; -w /etc/fstab -p wa -k fs_mount.
• Netværksgrundlag: -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 og 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.
• Persistens via SSH: -w /root/.ssh/ -p wa -k ssh_keys, -w /home/ -p wa -k ssh_keys (smal sti på authorized_keys-filer pr. bruger for at undgå støj).
• Begrænse misbrug af SUID/SGID: Fokus på mapper med eksekverbare filer: -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.
• Log kun fejl (for støjende systemkald): -a always,exit -F arch=b64 -S open,openat -F success=0 -k file_denied.
• Dæmpe støj: Undtag pakkehåndteringsprogrammer/sikkerhedskopier, f.eks. -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 (Kontroller stien for hver distribution).

Loghåndtering og beskyttelse mod tab af logfiler

Uden at Selv ved korrekt rotation og tydelige skillemærker risikerer audit-logfiler at miste værdifulde data eller fylde filsystemet op. På /etc/audit/auditd.conf definerer jeg blandt andet max_log_file, max_log_file_action, num_logs, space_left og reaktioner som space_left_action, disk_full_action eller disk_error_action. I foretrækker tiltag som ROTATE og en rettidig meddelelse til Syslog, så jeg kan reagere i tide i tilfælde af flaskehalse. Derudover Jeg gemmer audit-logfiler på en separat server for at gøre det sværere at manipulere det berørte system og for at bevare bevismateriale. Die Følgende tabel overskueligt præsenterer de vigtigste parametre og viser typiske, praktisk anvendelige indstillinger.

Parametre	Formål	Eksempel	Hint
logfil	Opbevaringssted for auditlogfilerne	/var/log/audit/audit.log	Bevar standardstien og sikr den klart og tydeligt
log_format	Begivenhedernes format	RAW	RAW letter den kriminaltekniske analyse uden tab af information
max_log_file	Maksimal filstørrelse (MB)	100 indtil 500	Tilpas størrelsen efter antallet af hændelser og lagerplads
max_log_file_action	Kampagne, når den ønskede størrelse er nået	ROTATE	Rotation forhindrer, at data står stille eller overskrives
num_logs	Antal gemte filer	5 indtil 10	Nok historik til analyser, uden at optage for meget lagerplads
space_left	Tærskel for ledig hukommelse (MB)	1024 eller højere	Tidlige advarsler giver reaktionstid
space_left_action	Reaktion ved underskridelse	SYSLOG	Overvej desuden e-mail eller SIEM-alarm
disk_full_action	Hvad skal man gøre, når datamediet er fuldt?	SUSPEND eller STOP	En klar beslutning afhænger af risikovillighed

Fjernlogning og central analyse

For For mange servere anvender jeg central registrering via TCP/TLS, styret af parametre som tcp_listen_port og tilhørende modstykker. Omkring Ved hjælp af audispd-plugins eller rsyslog videresender jeg hændelser til en SIEM- eller sikkerhedsplatform, hvor jeg korrelerer logonfejl, konfigurationsændringer og mistænkelige processtarter. Så kan jeg genkende mønstre, der på en enkelt server virker ubetydelige, men som i sammenhæng straks udløser en alarm. Hvem der allerede anvender dashboards, drager fordel af Log-aggregering i hosting, fordi audit-hændelser der samles med andre telemetridata. I Sørg desuden for en sikker transportvej og en klar adskillelse mellem produktive systemer og samlingsinstansen.

Analyse: Målrettet brug af ausearch og aureport

Rå data er værdiløse, hvis jeg ikke hurtigt kan filtrere dem, derfor starter jeg med klare nøgler og bruger ausearch til målrettede søgninger. Med ausearch -k passwd_changes -ts today vurderer jeg for eksempel de seneste ændringer i /etc/passwd fra; jeg finjusterer tidsvinduet og brugerfilteret efter behov. For Leverer oversigtsrapporter aureport --summary kompakte tabeller, der viser markante logins, filændringer og hyppigheden af systemkald. Derudover Jeg supplerer oversigten over processtarter og ressourceforbrug med Procesregnskab, for at sammenholde forløb og belastningsspidser. På Det vigtigste er, at jeg kan besvare spørgsmål på få sekunder: Hvem, hvad, hvornår, hvor og hvordan.

Uddyb analysen: Sådan fortolkes begivenhedsfelterne korrekt

Så det For at sikre, at udvurderingerne er præcise, kender jeg de vigtigste felter og begivenhedstyper. SYSCALL-Indlæggene omfatter bl.a. auid (Registrerings-UID), uid/euid/suid (reel/effektiv/gemt UID), ses (session-ID) og exe (kørbar fil). PATH-Blokke viser de berørte stier, EXECVE opregner argumenterne, CWD angiver arbejdsmappen. Med ausearch -m SYSCALL -sc execve -ua 1000 -ts recent fokuserer jeg på interaktive fremstillinger; aureport -x --summary -i giver mig et overblik over hyppigheder og afvigelser. Vigtigt: auid er tilbage sudo eller setuid-hop er konstant og er derfor det mere robuste filterkriterium for „Hvem har sat det i gang?“.

Undgå typiske fejl

Til Alt for brede regler fylder logfilerne op og skjuler de virkelig vigtige oplysninger, derfor koncentrerer jeg mig om kritiske filer, execve, ændringer af privilegier og sikkerhedsrelevante konfigurationer. Mangler En velfungerende rotation – ellers kommer systemerne i fare, og derfor sætter jeg klare grænser for størrelse og antal samt foranstaltninger i tilfælde af flaskehalse. I Overvåg også audit-konfigurationen og mappen /var/log/audit/, fordi angribere ønsker at slette sporene. Og Jeg dokumenterer hver regel med nøgle, mål og en kort begrundelse, så analyserne forbliver konsistente. Hvem Hvis man er bekymret for ydeevnen, bør man filtrere meget præcist, fjerne unødvendige stier og først verificere virkningen af nye regler gennem test.

Ydeevne, stabilitet og kvalitetskontrol

Revision må ikke hæmme driften. I tjek regelmæssigt med auditctl -s, om forsvundet-hændelser opstår, og overvåg backlog-værdierne efter regelændringer. Med Ved stor begivenhedsbelastning øger jeg dispatcher-køen (q_depth) af audispd-plugins og indstil overflow_action bevidst. Hvor execve-Hvis reglerne skaber for meget volumen, begrænser jeg det via auid eller via exe=-Indsæt hvidlister/sortlister, og log kun fejl ved støjende systemkald. Før Inden den brede udrulning validerer jeg de nye regler i Staging, måler hændelsesfrekvensen og CPU-belastningen og sammenligner aureport --summary før/efter ændringen for at kvantificere effekten.

Container- og virtualiseringsmiljøer

På Ud over container-værter logger kernen også container-processer – det er tilsigtet, men kan medføre støj. I tager udgangspunkt i værtsbeskyttelsen (f.eks. dockerd eller Podman), sikre binære stier og konfigurationer samt filtrering af brugergrænsefladen via auid. Eksempler: -w /usr/bin/dockerd -p x -k container_runtime, -w /etc/docker/ -p wa -k container_conf, plus generiske værtsregler som f.eks. execve med auid-Filter. På Når det gælder VM'er, behandler jeg audit-logfiler som flygtige data: Jeg aktiverer fjernvideresendelse, indstiller en kort rotationsperiode og sørger for tidskonsistens ved snapshots. Vigtigt Så er der kun den præcise NTP/Chrony-synkronisering tilbage, så tidslinjeanalyserne bliver pålidelige.

Overholdelse af regler og dokumentation

For I henhold til ISO 27001 (bl.a. A.12.4 Logning/overvågning, A.16 Hændelsesstyring) og PCI DSS (kap. 10) udarbejder jeg dokumentation, der kan underkastes revision: Hvad Logges det, hvor længe, hvem har adgang, og hvordan sikres integriteten? I Sørg for, at regelbasen er versioneret, dokumenter nøgler og formål, signer arkivlogfiler med hashværdier, og opbevar dem på en måde, der forhindrer manipulation. Med Når det gælder personoplysninger, anvender jeg princippet om dataminimering (målrettede regler, korte opbevaringsfrister) og fastlægger klare procedurer for sletning. Så Der udarbejdes rapporter, der overbeviser revisorerne og rent faktisk giver svar i forbindelse med hændelsen.

Drift, overvågning og playbooks

På Når jeg arbejder døgnet rundt, har jeg brug for faste rutiner: Daglige stikprøver med aureport, alarmer ved lost > 0, Kontrol af den ledige audit-partition og fjernvideresendelse. I Opret playbooks: „Iøjnefaldende ledere“ (filter efter exe= og auid), „Kritisk fil ændret“ (sammenhæng med PATH, SYSCALL, EXECVE), „Kernel-indgreb“ (regler vedrørende init_module og mount). Kendt Begivenhedstyper som ANOM_PROMISCUOUS (Grænseflade i promisc-tilstand) eller MAC_POLICY_LOAD (MAC-politik indlæst) vurderer jeg efter prioritet og iværksætter de relevante responstrin.

Fejlfinding og genstart

Når Hvis der ikke kommer nogen begivenheder, tjekker jeg først ausearch -m DAEMON -ts today og auditctl -s (Status/Backlog). Mangler Regler – jeg tager dem med augenrules --load nyt og kontroller med auditctl -l. Er Immutable-tilstanden er aktiveret (-e 2), er det eneste, der hjælper, at genstarte computeren med tilpassede opstartsindstillinger. Med Problemer med adgangsrettigheder på /var/log/audit/ Jeg gendanner ejerskab og tilstand; hvis SELinux er aktiveret, korrigerer jeg kontekster. Og Jeg bekræfter, at log_format = RAW er fastlagt – læsbar inddata til forensisk analyse og parsere.

Audit i hostingmiljøer

Lige ud I hosting-opsætninger med mange arbejdsbelastninger hjælper Auditd mig med at gøre adskillelsen af klienter overskuelig og opdage misbrug på et tidligt tidspunkt. I Overvåg web-, database- og applikationsservere ved hjælp af differentierede regelsæt, og integrer hændelserne i eksisterende overvågnings- og hændelseshåndteringssystemer. For Jeg sikrer en klar adskillelse ved hjælp af central lagring, separate roller og restriktive rettigheder til logmapperne. Til den Hvis det er nødvendigt, aktiverer jeg udvidet systemdiagnose journalctl til fejlfinding, men jeg foretager sikkerhedskritiske analyser primært i audit-kanalen. Så Der skabes et pålideligt revisionsspor, der forener kundernes interesser, compliance-krav og operationel effektivitet.

Kort og præcist: Min fremgangsmåde

I Start med et klart mål for øje, formuler målrettede regler for kritiske filer, execve og ændring af privilegier, og sørg for, at rotationen beskyttes mod datatab. Så Jeg aktiverer fjernvideresendelse med TLS, dokumenterer nøglerne og tester virkningen af hver regel, inden den implementeres på bred skala. For Jeg lægger vægt på det daglige arbejde ausearch og aureport, udfør målrettede søgninger og udarbejd overskuelige rapporter til driften og sikkerheden. Med Når jeg opdager afvigelser, sammenholder jeg audit-hændelser med andre signaler, såsom proces- eller netværksdata, for hurtigt at kunne isolere årsagen. Så Med Linux Auditd får jeg ikke en strøm af logfiler, men klare svar på sikkerhedsrelevante spørgsmål i produktive miljøer.