Linux Auditd – Logga säkerhetshändelser på rätt sätt

Linux Auditd loggar säkerhetsrelaterade händelser direkt från kärnan och ger mig en fullständig granskningsspår för inloggningar, filändringar, kommandokörningar och systemanrop. Rätt När jag har konfigurerat systemet kan jag upptäcka attacker i ett tidigt skede, uppfylla efterlevnadskrav som ISO 27001 eller PCI DSS och analysera incidenter på ett forensiskt tillförlitligt sätt.

Centrala punkter

Denna Jag sammanfattar översikten medvetet kortfattat, praktiskt och utan klichéer, så att du omedelbart förstår hur du definierar revisionsregler, skyddar loggar och drar slutsatser. I Nämn de viktigaste komponenterna, typiska användningsfall, användbara regler och felkällor som i många miljöer leder till blinda fläckar. Så ser du direkt vilka inställningar i auditd.conf som är giltiga och vilka verktyg som finns tillgängliga för utvärderingen. Därefter Jag fördjupar varje ämne med exempel, tydliga rekommendationer och en tabell över viktiga parametrar. Så att lyckas du ta steget från „Auditd körs“ till „Auditd levererar användbara säkerhetssignaler“.

• Revisionsspår: fullständig spårbarhet av säkerhetsrelaterade åtgärder
• Regler: specifika kritiska filer, execve, behörigheter och konfigurationer
• Loggskydd: Rotation, minnesutlösare, hantering av flaskhalsar
• Fjärrkontroll: central insamling via TCP/TLS och SIEM-integration
• Analys: ausearch, aureport, tydliga nycklar och välskriven dokumentation

Linux Auditd i säkerhetskonceptet

Revisiond kompletterar klassiska systemloggar genom att specifikt fokusera på säkerhetsrelevanta åtgärder och registrera händelserna via kärngränssnittet. Der Daemon loggar dessa händelser som standard till /var/log/audit/audit.log och registrerar vilken användare som utförde vilken åtgärd och vid vilken tidpunkt. Därför kan jag snabbt undersöka misstänkta fall, till exempel oavsiktliga ändringar av /etc/ssh/sshd_config eller känsliga filer som /etc/shadow. På I reglerade miljöer säkerställer jag därmed bevis på överträdelser av riktlinjer och uppfyller kraven på en tillförlitlig loggning. Mittemot Jämfört med klassiska logg- eller syslog-data ger Auditd den djupgående, säkerhetsinriktade överblicken som är avgörande för utredningen av attacker.

Arkitektur: Kärna, daemon, verktyg

Das Auditeringssystemet är uppdelat i ett kärnsubsystem för datainsamling och en tjänst i användarutrymmet auditd för lagring samt verktyg för hantering och utvärdering. Om auditctl ställer jag in regler under körning eller laddar jag in permanenta regler vid start /etc/audit/rules.d/*.rules. Med ausearch filtrerar jag händelser efter tid, användare, nyckel eller fil, medan aureport skapar kortfattade rapporter. Så Jag kombinerar detaljerad datainsamling med snabb analys och ser till att revisionsspåret är spårbart hela vägen. Viktigt är en konsekvent benämning av -k Nycklar, så att senare sökningar fungerar som de ska.

Installation och aktivering

På Jag installerar RHEL/CentOS revision via dnf install audit eller . yum install audit, på Debian/Ubuntu använder jag apt install auditd audispd-plugins. Enligt Efter installationen startar och aktiverar jag tjänsten med systemctl start auditd och systemctl enable auditd, jag kontrollerar statusen med systemctl status auditd. Så snart som möjligt När revisionsundersystemet och tjänsten är igång hamnar händelserna i enlighet med reglerna i /var/log/audit/audit.log. I Kontrollera att funktionen fungerar genom att specifikt öppna en övervakad fil och sök sedan efter händelsen med ausearch -k keyname. För För att säkerställa en konsekvent start vid varje uppstart ser jag till att permanenta regler finns på plats och laddas korrekt.

Tidig start, orderstock och skydd enligt reglerna

På För att inte missa händelser i början av uppstarten aktiverar jag granskningssubsystemet redan när kärnan startar. Dessutom Jag ställer in kärnparametrar och en tillräckligt stor backlog-storlek så att händelser inte går förlorade under uppstartsfasen. Dessutom Efter inläsningen låser jag regelbasen för att förhindra manipulation.

• Kärnparametrar: audit=1 audit_backlog_limit=8192 på /etc/default/grub lägga till, därefter uppdatera-grub (Debian/Ubuntu) eller grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL/CentOS) köra.
• Eftersläpning i regler: I startreglerna anger jag -b 8192, för att dimensionera kärnköen på lämpligt sätt.
• Spärra regler: När den slutgiltiga regelbasen har laddats aktiverar jag Immutable-läget med -e 2. Ändringar kan då endast göras efter omstart – ett effektivt skydd mot manipulationer under drift.
• Överflödesbeteende: I /etc/audit/auditd.conf jag definierar overflow_action (t.ex. SYSLOG eller . SINGEL), så att jag får tydligt definierade reaktioner när buffertbehållaren är full.

Att definiera revisionsregler på rätt sätt

Die Kvaliteten på revisionsspåret beror på tydliga, målinriktade regler som täcker kritiska åtgärder och undviker onödiga störningar. För Känsliga filer placerar jag till exempel -w /etc/passwd -p warx -k passwd_changes och lägg till lämpliga regler för /etc/shadow, /etc/sudoers eller . /etc/ssh/. På För att registrera kommandoutföranden använder jag -a always,exit -F arch=b64 -S execve samt 32-bitarsversionen, så att varje version förblir synlig, även genom rot. För Verktyg som Apache filtrerar jag specifikt via binärfilens sökväg, till exempel -a always,exit -F arch=b64 -S all -F exe=/usr/sbin/apache2 -k apache_activity. I Dokumentera varje regel med kortfattade kommentarer och entydiga nycklar, så att utvärderingarna förblir reproducerbara och kollegorna kan förstå avsikten.

Avancerade regelexempel och finjustering

För För att gå mer på djupet sätter jag ihop en fokuserad uppsättning som synliggör privilegiebyten, ingrepp i kärnan, tids- och nätverksändringar samt persistenta mekanismer – utan störningar från paket eller säkerhetskopior.

• Endast interaktiva användare: -F auid>=1000 -F auid!=4294967295 kompletteras med execve-Regler för att undanta systemtjänster.
• Byte av privilegier: -a always,exit -F arch=b64 -S setuid,setreuid,setresuid -k priv_change och 32-bitarsversionen. Valfritt: -C uid!=euid, om fältjämförelser stöds.
• Kärnmoduler: -a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k kmod_change; dessutom: -w /sbin/insmod -p x -k kmod_exec, -w /sbin/modprobe -p x -k kmod_exec.
• Tidsändringar: -a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time_change och -w /etc/localtime -p wa -k time_change.
• Monteringar och filsystem: -a always,exit -F arch=b64 -S mount,umount2 -k fs_mount; -w /etc/fstab -p wa -k fs_mount.
• Nätverksgrund: -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 och 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 stig på authorized_keys-filer per användare för att undvika brus).
• Begränsa missbruk av SUID/SGID: Fokusera på kataloger med körbara 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.
• Logga endast misslyckanden (för högljudda systemanrop): -a always,exit -F arch=b64 -S open,openat -F success=0 -k file_denied.
• Dämpa bruset: Uteslut pakethanterare/säkerhetskopior, t.ex. -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 (Kontrollera sökvägen för varje distribution).

Logghantering och skydd mot loggförlust

Utan Om rotation och tröskelvärden inte hanteras korrekt riskerar auditloggar att förlora värdefull data eller fylla upp filsystemet. På /etc/audit/auditd.conf Jag definierar bland annat max_log_file, max_log_file_action, num_logs, space_left och reaktioner som space_left_action, disk_full_action eller . disk_error_action. I Jag föredrar aktiviteter som ROTATE och en tidig avisering till Syslog, så att jag kan reagera i tid vid flaskhalsar. Dessutom Jag sparar revisionsloggarna på en separat värd för att försvåra manipulationer på det berörda systemet och bevara bevis. Die I följande tabell redovisas viktiga parametrar och typiska, praktiskt användbara inställningar.

Parametrar	Syfte	Exempel	Ledtråd
loggfil	Lagringsplats för revisionsloggarna	/var/log/audit/audit.log	Behåll standardvägen och säkerställ rättigheterna tydligt
log_format	Evenemangens format	RAW	RAW underlättar den kriminaltekniska analysen utan informationsförlust
max_log_file	Maximal filstorlek (MB)	100 tills 500	Anpassa storleken efter händelsevolym och lagringsutrymme
max_log_file_action	Erbjudande när storleken uppnås	ROTATE	Rotationen förhindrar att data står stilla eller skrivs över
num_logs	Antal lagrade filer	5 tills 10	Tillräckligt med historik för analyser, utan att ta upp för mycket lagringsutrymme
space_left	Tröskelvärde för ledigt minne (MB)	1024 eller högre	Tidiga varningar ger reaktionstid
space_left_action	Reaktion vid underskridande	SYSLOG	Överväg även e-post eller SIEM-larm
disk_full_action	Vad man ska göra när lagringsmediet är fullt	SUSPEND eller . STOPP	Ett tydligt beslut som beror på riskacceptans

Fjärrloggning och central utvärdering

För För många värddatorer använder jag central registrering via TCP/TLS, som styrs av parametrar som tcp_listen_port och motsvarande enheter. Om Med hjälp av audispd-plugins eller rsyslog vidarebefordrar jag händelser till en SIEM- eller säkerhetsplattform och korrelerar inloggningsfel, konfigurationsändringar och misstänkta processstarter. Så ser jag mönster som på en enskild server verkar oskyldiga, men som i sammanhanget omedelbart utlöser en larmsignal. Vem som redan använder dashboards drar nytta av Aggregering av loggar i hosting, eftersom händelser från revisionen där sammanförs med andra telemetridata. I Se dessutom till att transportvägen är säker och att det finns en tydlig åtskillnad mellan produktionssystemen och samlingsinstansen.

Analys: Att använda ausearch och aureport på ett målinriktat sätt

Rådata är värdelösa om jag inte kan filtrera dem snabbt, därför börjar jag med tydliga nycklar och använder ausearch för riktade sökningar. Med ausearch -k passwd_changes -ts today betraktar jag till exempel aktuella ändringar av /etc/passwd ; Jag justerar tidsintervallet och användarfiltren vid behov. För Tillhandahåller översiktsrapporter aureport --summary kompakta tabeller som visar anmärkningsvärda inloggningar, filändringar och frekvensen av systemanrop. Dessutom Jag kompletterar översikten över processstarter och resursanvändning med Processredovisning, för att korrelera sekvenser av utföranden och belastningstoppar. På Det viktigaste är att jag kan svara på frågorna på några sekunder: vem, vad, när, var och på vilket sätt.

Fördjupa analysen: Tolka händelsefält på rätt sätt

Så att För att analyserna ska bli träffsäkra måste jag känna till de viktigaste fälten och händelsetyperna. SYSCALL- Posterna omfattar bland annat. auid (registrerings-UID), uid/euid/suid (verklig/effektiv/sparad UID), ses (session-ID) och exe (körbar fil). PATH-blocken visar berörda sökvägar, EXECVE redogör för argumenten, CWD anger arbetskatalogen. Med ausearch -m SYSCALL -sc execve -ua 1000 -ts recent Jag fokuserar på interaktiva presentationer; aureport -x --summary -i ger mig en översikt över frekvenser och avvikelser. Viktigt: auid kvar över sudo eller setuid-hopp är konstanta och utgör därför det mer robusta filterkriteriet för frågan „Vem satte igång det?“.

Undvik typiska misstag

Till Allmänt formulerade regler gör loggarna onödigt omfattande och döljer de verkligen viktiga uppgifterna, därför fokuserar jag på kritiska filer, execve, behörighetsändringar och säkerhetsrelevanta konfigurationer. Saknas En välfungerande rotation – annars utsätts systemen för risker, därför sätter jag tydliga gränser för storlek och antal samt åtgärder vid flaskhalsar. I övervaka även revisionskonfigurationen och katalogen /var/log/audit/, eftersom angripare vill dölja sina spår. Och Jag dokumenterar varje regel med nyckel, mål och en kort motivering, så att utvärderingarna förblir konsekventa. Vem Den som är orolig för prestandan bör filtrera noggrant, ta bort onödiga sökvägar och först testa effekten av nya regler.

Prestanda, stabilitet och kvalitetskontroller

Revision får inte bromsa verksamheten. I kontrollera regelbundet med auditctl -s, om förlorad-Händelser inträffar, och övervaka backlog-värdena efter regeländringar. Med Vid hög händelsebelastning ökar jag dispatcher-kön (q_depth) i audispd-pluginerna och ställ in overflow_action medvetet. Var execve-Om reglerna ger för mycket volym, begränsar jag det genom att auid eller via exe=-Ställ in vitlistor/svartlistor och logga endast misslyckanden vid högljudda systemanrop. Före Inför den omfattande lanseringen validerar jag nya regler i staging-miljön, mäter händelsefrekvensen och CPU-belastningen och jämför aureport --summary före/efter ändringen, för att kvantifiera effekten.

Container- och virtualiseringsmiljöer

På Förutom container-värdar loggar kärnan även containerprocesser – detta är avsiktligt, men kan orsaka hög ljudnivå. I utgår från värdskyddet (t.ex. dockerd eller Podman), säkra binärvägar och konfigurationer samt filtrera användarvyn via auid. Exempel: -w /usr/bin/dockerd -p x -k container_runtime, -w /etc/docker/ -p wa -k container_conf, plus generiska värdregler som execve med auid-Filter. På När det gäller virtuella maskiner behandlar jag revisionsloggar som flyktiga data: aktivera fjärrvidarebefordran, ställ in en kort rotationsperiod och se till att ögonblicksbilderna är tidsmässigt konsistenta. Viktigt Då återstår en korrekt NTP/Chrony-synkronisering för att tidslinjeanalyserna ska vara tillförlitliga.

Efterlevnad och dokumentation

För Enligt ISO 27001 (bl.a. A.12.4 Loggning/övervakning, A.16 Incidenthantering) och PCI DSS (kap. 10) utarbetar jag verifierbara underlag: Vad Loggas det hur länge, vem har åtkomst och hur säkerställs integriteten? I Håll regelbasen versionerad, dokumentera nycklar och syften, signera arkivloggar med hashvärden och lagra dem på ett sätt som förhindrar manipulation. Med När det gäller personuppgifter tillämpar jag principen om dataminimering (riktade regler, korta lagringstider) och fastställer tydliga rutiner för radering. Så Det resulterar i rapporter som övertygar revisorerna och som faktiskt ger svar vid en incident.

Drift, övervakning och handböcker

På Vid kontinuerligt arbete behöver jag fasta rutiner: Dagliga stickprov med aureport, larm vid förlorat > 0, Kontrollera den fria revisionspartitionen och fjärrvidarebefordran. I Skapa playbooks: „Iögonfallande chefer“ (filter enligt exe= och auid), „Kritisk fil ändrad“ (korrelera med PATH, SYSCALL, EXECVE), „Kärngrepp“ (regler för init_module och montera). Känd Evenemangstyper som ANOM_PROMISCUOUS (Gränssnitt i promisc-läge) eller MAC_POLICY_LOAD (MAC-policy laddad) utvärderar jag prioriterat och sätter igång åtgärder.

Felsökning och omstart

När Om inga evenemang dyker upp, kollar jag först ausearch -m DAEMON -ts today och auditctl -s (Status/Arbetslista). Saknas Regler – jag laddar ner dem med augenrules --load ny och kontrollera med auditctl -l. Är Immutable-läget är aktiverat (-e 2), då hjälper endast en omstart med anpassade startregler. Med Behörighetsproblem på /var/log/audit/ återställer jag ägare och läge; om SELinux är aktiverat korrigerar jag kontexterna. Och Jag bekräftar att log_format = RAW är givet – läsbar indata för forensisk analys och parsare.

Auditd i webbhotellsmiljöer

Rak I hostingmiljöer med många arbetsbelastningar hjälper Auditd mig att göra klientseparationen överskådlig och att upptäcka missbruk i ett tidigt skede. I Övervaka webb-, databas- och applikationsservrar med differentierade regeluppsättningar och integrera händelserna i befintliga system för övervakning och incidenthantering. För Jag säkerställer en tydlig åtskillnad genom central lagring, separata roller och begränsade behörigheter till loggkatalogerna. Till Vid behov kompletterar jag systemdiagnosen med journalctl för felsökning, men jag förvarar säkerhetskritiska utvärderingar främst i revisionskanalen. Så Det skapas en tillförlitlig revisionsspår som förenar kundernas intressen, efterlevnadskrav och operativ effektivitet.

Kort och koncist: Min metod

I Börja med en tydlig målsättning, formulera tydliga regler för kritiska filer, execve och behörighetsbyten samt säkerställ att rotationen skyddar mot dataförlust. Sedan Jag aktiverar fjärrvidarebefordran med TLS, dokumenterar nycklarna och testar effekten av varje regel innan den rullas ut i stor skala. För Mitt dagliga arbete bygger på ausearch och aureport, skapa riktade sökningar och ta fram överskådliga rapporter för drift och säkerhet. Med När jag upptäcker avvikelser korrelerar jag händelser från auditeringen med andra signaler, såsom process- eller nätverksdata, för att snabbt kunna isolera orsaken. Så Med Linux Auditd får jag inte en flod av loggdata, utan tydliga svar på säkerhetsrelaterade frågor i produktionsmiljöer.