Commando's van gebruikers op Linux server controleren

Wat registreert daadwerkelijk de commando's die gebruikers op uw server hebben uitgevoerd

Om te controleren welke commando's gebruikers op uw server hebben uitgevoerd, heeft u een logbestand nodig dat de gebruiker niet kan aanpassen. De shell-geschiedenis is niet zo'n logbestand. Het is een handig bestand dat eigendom is van het account dat het heeft geschreven, en iedereen die in die shell kan typen, kan het uitschakelen of verwijderen.

Er zijn vier lagen die wel een betrouwbaar logboek bijhouden, waarbij elke laag zijn eigen kosten met zich meebrengt. sudo schrijft per commando een regel naar syslog. sudo I/O-logging legt een volledige sessie voor één account vast. Een shell-hook zoals PROMPT_COMMAND logt wat een interactieve bash-gebruiker heeft getypt. Het audit-subsysteem van de kernel registreert de execve-syscall zelf, en daarom is dit de enige laag die elk proces ziet. Deze handleiding doorloopt deze lagen, geeft aan waar elke laag tekortschiet en eindigt met het onderdeel dat bepaalt of de gegevens enige waarde hebben: het verplaatsen van de logbestanden van de machine af voordat de persoon die u controleert erbij kan.

Eén waarschuwing voordat u begint. Het audit-subsysteem werkt op kernelniveau, dus niets hiervan kan worden getest in een container die de kernel van de host deelt. Voer deze commando's uit op een KVM VPS waar u de controle over de kernel heeft.

Waarom shell history geen audit-log is

~/.bash_history schiet tekort als bewijslast om vier eenvoudige redenen, en voor geen van deze is een slimme aanvaller nodig.

Het is eigendom van de gebruiker. Het bestand heeft modus 600 en is eigendom van dat account, dus rm ~/.bash_history vereist geen enkel privilege. Hetzelfde geldt voor het openen van het bestand in een editor en het verwijderen van de twintig regels die ertoe doen.

Het wordt geschreven bij het afsluiten van de shell. Een sessie die eindigt met kill -9 $$, of door een verbroken verbinding, schrijft niets weg. history -c vóór exit heeft hetzelfde effect en zorgt ervoor dat het lijkt alsof er niets is gebeurd.

Het kan met één woord worden uitgeschakeld. unset HISTFILE zorgt ervoor dat het bestand voor die sessie niet wordt bijgewerkt. set +o history stopt de registratie onmiddellijk. HISTCONTROL=ignorespace verbergt elk commando dat begint met een spatie. Dit alles is ingebouwd in man bash, omdat het bedoeld is om onder controle van de gebruiker te staan.

Het registreert wat er is getypt, niet wat er is uitgevoerd. Door een alias of een shell-functie is de tekst in het bestand niet het programma dat de kernel daadwerkelijk heeft uitgevoerd.

Er zijn ook geen tijdstempels, tenzij HISTTIMEFORMAT was ingesteld op het moment dat de regel werd geschreven, omdat bash zijn #1755043200-markeringsregels alleen schrijft wanneer die variabele is ingesteld.

Bij een gedeelde login kan het bovendien niet vertellen wie de actie heeft uitgevoerd. Drie mensen die één deploy-account gebruiken, produceren één gecombineerd bestand onder één uid. Geen enkele log-laag kan een actie toeschrijven aan een persoon wanneer twee mensen een uid delen; dit is het praktische argument voor één account zonder privileges per persoon in plaats van een gedeelde login.

Shell history is goed in zijn eigenlijke taak: u helpen het commando van gisteren opnieuw te typen. Gebruik het als aanwijzing. Presenteer het nooit als bewijs.

Wat sudo logt en waar het stopt

sudo verstuurt voor elk commando dat het uitvoert een regel naar de authpriv syslog-faciliteit.

sudo grep 'sudo:' /var/log/auth.log | tail -5
journalctl -t sudo -n 5

Elke regel vermeldt de gebruiker, de terminal, de werkmap, de doelgebruiker en het commando:

sudo:    alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/apt update

Als /var/log/auth.log niet bestaat, is rsyslog niet geïnstalleerd op die image en staan dezelfde gegevens alleen in de journal. Controleer of de journal niet vluchtig is voordat u erop vertrouwt:

journalctl --list-boots

Als alleen de huidige boot wordt vermeld, betekent dit dat /var/log/journal niet bestaat, waardoor de journal in /run leeft en elke regel verloren gaat bij de volgende reboot. Maak deze persistent:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Nu de beperking. sudo logt het commando dat het moest uitvoeren. Het logt niet wat dat commando vervolgens doet. Eén regel beëindigt dus het spoor:

sudo -i

Het logboek krijgt één record voor de shell. Elk commando dat binnen die root-shell wordt getypt, is onzichtbaar voor sudo, omdat sudo zich niet langer in het pad bevindt. sudo su -, sudo bash en sudo vim /etc/shadow gevolgd door :!bash hebben allemaal dezelfde vorm. Een sudoers-regel die elk programma met een shell-escape toestaat, zoals vim of find, is een regel die ongecontroleerde root-toegang verleent. Lees wat een account daadwerkelijk kan bereiken voordat u de logregels vertrouwt:

sudo -l -U alice

Een volledige sessie opnemen voor één account

Controleer eerst welke versie van sudo u gebruikt, aangezien deze functionaliteit niet aanwezig is in de Rust-herschrijving:

sudo --version | head -1

Als de uitvoer sudo-rs vermeldt, sla dit gedeelte dan over en gebruik het audit-subsysteem. De documentatie van Ubuntu voor de releases 25.10 en 26.04 geeft aan dat I/O-logging en sudoreplay niet worden ondersteund; dit was in augustus 2026 nog steeds het geval. Dit is van belang omdat sudo-rs de standaard sudo is in die releases; een upgrade kan er dus voor zorgen dat een controlemechanisme waar u op vertrouwde, verdwijnt. De volledige lijst met gedragswijzigingen in sudo-rs is het lezen waard voordat u logging op basis van sudo plant.

Bij de originele sudo, die nog steeds wordt meegeleverd met Ubuntu 24.04 LTS, schakelt u I/O-logging voor één account als volgt in:

sudo visudo -f /etc/sudoers.d/iolog

Defaults:deploy log_output
Defaults!/usr/bin/sudoreplay !log_output

Gebruik visudo in plaats van een teksteditor, omdat dit commando weigert een bestand op te slaan dat niet correct geparseerd kan worden. Een defect sudoers-bestand sluit iedereen uit van sudo-toegang. Speel vervolgens een sessie af:

sudo sudoreplay -l user=deploy
sudo sudoreplay 000001

sudoreplay -l toont de sessies met hun ID's en geeft niets weer als log_output nooit op die gebruiker is toegepast. De kosten: elke byte die via de terminal verloopt, wordt opgeslagen onder /var/log/sudo-io, waardoor een uitgebreide sessie veel schijfruimte in beslag neemt. De tweede regel in sudoers voorkomt dat een replay zichzelf opneemt. Het werkelijke risico betreft geheimen, aangezien een I/O-logboek alles bevat wat is getypt en weergegeven, inclusief wachtwoorden die in een prompt binnen de sessie zijn ingevoerd. Het logboek vereist daarom dezelfde beveiliging als een wachtwoordkluis. De dekking is bovendien beperkt. Het registreert alleen commando's die via sudo worden uitgevoerd. Iemand die inlogt en volledig als zichzelf werkt, wordt helemaal niet opgenomen.

Shell-hooks en hoe deze precies worden omzeild

Het recept dat de ronde doet voor "log elk commando" is een PROMPT_COMMAND-hook die in /etc/profile.d/ wordt geplaatst:

# /etc/profile.d/00-cmdlog.sh
PROMPT_COMMAND='logger -p local6.info -t cmdlog "$(whoami) $$ $(history 1 | sed "s/^ *[0-9]* *//")"'

bash voert PROMPT_COMMAND uit voordat elke prompt wordt getoond, waardoor een regel naar syslog gaat zodra deze wordt getypt in plaats van bij het afsluiten, en logger schrijft via de systeemlog-daemon, waardoor de eigen bestandsrechten van de gebruiker geen rol spelen. Open een nieuwe login-shell en controleer dit met sudo tail -f /var/log/syslog, of journalctl -t cmdlog -f op een image zonder rsyslog.

Vervolgens stopt het met werken, op vijf manieren die u elk binnen een minuut kunt reproduceren.

• Niet-interactieve shells tonen nooit een prompt. ssh you@server 'id' voert het commando uit en keert terug, en er wordt niets gelogd, omdat PROMPT_COMMAND nooit werd geëvalueerd.
• Het is een variabele. unset PROMPT_COMMAND schakelt deze uit voor de rest van de sessie en vereist geen privileges.
• Het bestand wordt gelezen door login-shells. bash --noprofile --norc voert /etc/profile.d/ helemaal niet uit.
• Het is specifiek voor bash. zsh, sh, python3 -c 'import os; os.system("id")' en :!id binnen vim voeren allemaal programma's uit die geen enkele bash-prompt-hook ooit zal zien.
• Het logt de regel zoals getypt, dus een alias of een functie verbergt nog steeds het commando dat daadwerkelijk werd uitgevoerd.

Gebruik een shell-hook als gemak. Het beantwoordt de vraag "wat heb ik afgelopen dinsdag uitgevoerd" voor coöperatieve gebruikers. Laat een checklist dit niet als een controlemechanisme bestempelen.

Het kernel audit-subsysteem ziet elke execve

Het Linux audit-subsysteem, aangestuurd door de auditd-daemon, is de enige laag in dit proces waar een gebruiker niet omheen kan. De registratie vindt namelijk plaats in de kernel op het moment dat de syscall wordt uitgevoerd. Als een proces een programma uitvoert, wordt er een event gegenereerd. De shell, de programmeertaal en de aanwezigheid van een terminal maken hierbij geen verschil.

sudo apt update && sudo apt install -y auditd audispd-plugins
sudo systemctl enable --now auditd
sudo auditctl -s

auditctl -s toont de status van de daemon. enabled 1 met een pid die niet nul is, betekent dat de daemon actief is, en lost 0 geeft aan dat er nog geen records verloren zijn gegaan. Onthoud die lost-teller; deze komt later terug.

auid is het veld dat audit de moeite waard maakt. PAM stelt een login-uid in wanneer een sessie start, en de kernel draagt dit vanaf dat moment over op elk onderliggend proces. Controleer uw eigen waarde:

cat /proc/self/loginuid

Een interactieve SSH-sessie toont uw uid, omdat /etc/pam.d/sshd de waarde pam_loginuid.so bevat. Een waarde van 4294967295 betekent dat de loginuid nooit is ingesteld; dit is normaal voor processen die bij het opstarten door een systeem-daemon worden gestart. Het belangrijke punt is dat sudo -i dit niet wijzigt: een root-shell die door alice is geopend, behoudt nog steeds auid 1000. Elk commando dat daarbinnen wordt uitgevoerd, is dus herleidbaar naar alice. Dat is precies het gat dat sudo openlaat. Het wijzigen van een loginuid nadat deze is ingesteld, vereist CAP_AUDIT_CONTROL, waar gewone gebruikers niet over beschikken, en sudo auditctl --loginuid-immutable sluit deze mogelijkheid ook voor root af tot de volgende reboot.

Controleer of /etc/pam.d/sshd, /etc/pam.d/login en /etc/pam.d/cron elk pam_loginuid.so bevatten, anders komen events binnen zonder dat er een gebruiker aan gekoppeld is. Dit is dezelfde lijst met bestanden die u aanpast bij het beveiligen van SSH-toegang op een VPS, dus voer deze twee taken tegelijkertijd uit.

Een basisset regels voor auditd

Regels staan in /etc/audit/rules.d/*.rules. augenrules voegt deze in alfabetische volgorde van bestandsnaam samen tot één lijst. De volgorde bepaalt het gedrag, omdat de kernel stopt bij de eerste regel die overeenkomt. Bekijk wat er al aanwezig is voordat u iets toevoegt, aangezien een -D in een later bestand alles wist wat daarvoor is geladen.

ls /etc/audit/rules.d/
cat /etc/audit/rules.d/audit.rules

Schrijf vervolgens /etc/audit/rules.d/50-exec.rules:

## Suppressions first: the kernel takes the first matching rule.
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-deb
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-query
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-split
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-trigger

## Every program started by a logged-in human.
-a always,exit -F arch=b64 -S execve,execveat -F auid>=1000 -F auid!=unset -k exec
-a always,exit -F arch=b32 -S execve,execveat -F auid>=1000 -F auid!=unset -k exec

## Changes to who may become root.
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity

## Changes to the audit configuration itself.
-w /etc/audit/ -p wa -k auditconfig

Laad de regels en controleer de status:

sudo augenrules --load
sudo auditctl -l

auditctl -l die uw regels teruggeeft, betekent dat ze actief zijn. No rules betekent dat het laden is mislukt, en journalctl -u auditd -n 20 geeft het bestand en de regel aan die de parser heeft geweigerd. Oudere audit-userspace-versies begrijpen het trefwoord unset niet. Als de loader klaagt over dat veld, schrijf dan -F auid!=4294967295 in plaats daarvan; dit is dezelfde waarde voluit geschreven.

Lees nu de gebeurtenissen uit:

sudo ausearch -k exec -ts recent -i | tail -40
sudo ausearch -ul 1000 -ts today -i
sudo aureport -k --summary -i

-i zet uid's en syscall-nummers om naar namen; dit is in de praktijk niet optioneel. -ts recent bestrijkt de laatste tien minuten. Elke uitvoering komt binnen als een groep records: een SYSCALL-record met uid, auid, exit-status en key, een EXECVE-record met de volledige argumentenlijst, plus CWD- en PATH-records voor de context.

Eén belangrijke beperking, omdat dit vaak voor verwarring zorgt: audit registreert syscalls, en een shell-builtin maakt geen eigen syscall. cd /root voert geen programma uit. echo evil >> /etc/passwd getypt bij een bash-prompt voert eveneens geen programma uit, omdat zowel de echo als de redirect plaatsvinden binnen het shell-proces dat al draait. De execve-regels zien dus programma's en de -w-regels zien de schrijfacties. Geen van beide is op zichzelf voldoende.

Vergrendel tot slot de configuratie:

## /etc/audit/rules.d/99-finalize.rules
-e 2

-e 2 maakt de regelset onveranderlijk tot de volgende reboot. Nadat deze is geladen, rapporteert auditctl -s de waarde enabled 2, en elke poging om een regel toe te voegen of te verwijderen mislukt met Operation not permitted, ook voor root. Voeg dit bestand als laatste toe en houd er rekening mee dat u moet herstarten telkens wanneer u een regel wilt wijzigen. Die afweging is het doel: een regelset die iedereen stilletjes kan uitschakelen, is geen bewijslast.

Een auditlog die niemand leest is slechts een compliance-artefact

Het faalmechanisme van auditd is niet dat het gebeurtenissen mist. Het probleem is dat het zoveel registreert dat niemand er ooit naar kijkt, waardoor het logbestand enkel bestaat om aan een checklist te voldoen in plaats van om vragen te beantwoorden.

Voer de berekening uit op uw eigen systeem voordat u configuraties aanpast:

sudo aureport -k --summary -i
sudo du -sh /var/log/audit

Een enkele sudo apt upgrade voert duizenden kortstondige processen uit, en elk daarvan draagt uw auid, waardoor één pakketupdate meer data kan genereren dan een week aan menselijke invoer. Daarom noemen de bovenstaande onderdrukkingen dpkg en zijn helpers. Pas onderdrukking toe op basis van het uitvoerbaar bestand, nooit op basis van de gebruiker: een uitsluiting voor /usr/bin/dpkg is een gat in de beveiliging dat u in één zin kunt beschrijven, terwijl een uitsluiting voor een account een gat is dat precies de vorm heeft van hetgeen u probeerde te detecteren.

De -k-sleutel op elke regel is wat het logbestand een maand later doorzoekbaar maakt. ausearch -k sudoers is een vraag met een antwoord. ausearch zonder filter is een muur van tekst die u traint om te stoppen met lezen. Als uw collector JSON vereist in plaats van het standaardformaat, is laurel een auditd-plugin die elke gebeurtenis herschrijft als één JSON-object met gedecodeerde argumenten. Deze registreert zich in /etc/audit/plugins.d/ zoals elke andere plugin, en auditd verwerkt wijzigingen in plugins bij sudo pkill -HUP auditd.

Wat auditd werkelijk kost

Elke overeenkomstige syscall wordt een record dat de kernel formatteert en doorgeeft aan de userspace. De kosten manifesteren zich op twee plaatsen en zijn beide meetbaar op uw eigen workload, in plaats van dat ze in te schatten zijn op basis van gepubliceerde cijfers van anderen.

• CPU en latentie. Een machine die constant forks uitvoert, zoals een build-host of een CI-runner, produceert een record per exec. Wanneer de kernel-backlog vol raakt, zorgt --backlog_wait_time ervoor dat de kernel het proces dat de gebeurtenis genereerde pauzeert totdat er ruimte is. Hierdoor uit audit zich als trage builds in plaats van als een CPU-percentage. Monitor backlog en lost in sudo auditctl -s onder reële belasting. Een stijgende lost betekent dat records verloren zijn gegaan; een logbestand met stille gaten is slechter dan geen logbestand, omdat u er nog steeds op zult vertrouwen.
• Schijfgebruik. Lees /etc/audit/auditd.conf en bepaal bewust wat er gebeurt wanneer de schijf vol raakt, aangezien de standaardwaarden slechts meningen zijn. max_log_file, num_logs en max_log_file_action regelen de rotatie. space_left_action, admin_space_left_action en disk_full_action regelen de noodsituatie, en sommige van de beschikbare acties, waaronder halt en single, leggen de machine plat in plaats van een record te verliezen.

De -f-regel in /etc/audit/rules.d/audit.rules is diezelfde beslissing op kernelniveau: -f 1 rapporteert een audit-fout aan syslog, en -f 2 veroorzaakt een kernel panic. Kies alleen voor 2 als u er werkelijk de voorkeur aan geeft de server te verliezen in plaats van een record. Op een VPS waarop kritieke diensten draaien, kunt u beter roteren en het opslagprobleem verplaatsen naar een externe locatie.

Verplaats logs van de server, nagenoeg in real-time

Dit is het punt dat incidentrapporten keer op keer bevestigen. Logs die op een gecompromitteerde server blijven staan, kunnen worden aangepast door degene die de server heeft binnengedrongen. root kan /var/log/auth.log herschrijven, /var/log/audit/audit.log verwijderen en de daemon stoppen. -e 2 voorkomt dat de regels worden verwijderd. Het doet echter niets tegen rm. Elke bovenliggende laag levert alleen bewijslast als er eerst een kopie van de machine wordt verplaatst.

Het transport van audit zelf verloopt via de audisp-remote-plugin van audispd-plugins. Schakel deze in via /etc/audit/plugins.d/au-remote.conf:

active = yes
direction = out
path = /usr/sbin/audisp-remote
type = always
format = string

Controleer path tegen command -v audisp-remote voordat u de configuratie opnieuw laadt; een onjuist pad levert niets op behalve één regel in de journal. Stel remote_server en port in binnen /etc/audit/audisp-remote.conf, en stel op de collector tcp_listen_port = 60 in binnen de eigen auditd.conf. Herlaad met sudo pkill -HUP auditd. Op veel images wordt systemctl restart auditd geweigerd omdat het unit-bestand RefuseManualStop=yes instelt; het sturen van een signaal is daarom de betrouwbare methode.

De andere optie is om audit op te nemen in de syslog-stroom die u al doorstuurt. /etc/audit/plugins.d/syslog.conf wordt geleverd met active = no. Stel dit in op yes, herlaad, en audit-events worden toegevoegd aan de regels van sudo en alle overige logs. Stuur vervolgens alles door met rsyslog via TLS (transport layer security), waarvoor het rsyslog-gnutls-pakket vereist is:

# /etc/rsyslog.d/60-forward.conf
*.* action(type="omfwd"
    target="logs.example.net" port="6514" protocol="tcp"
    StreamDriver="gtls" StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.net"
    action.resumeRetryCount="-1"
    queue.type="linkedList" queue.filename="fwd" queue.saveOnShutdown="on")

De wachtrij-instellingen zijn hierbij het meest relevant. action.resumeRetryCount="-1" probeert het oneindig opnieuw, en de schijfondersteunde wachtrij met queue.saveOnShutdown="on" houdt records vast terwijl de collector onbereikbaar is, om ze vervolgens te verzenden zodra de verbinding is hersteld. Zonder deze twee instellingen laat een herstart van de collector een gat achter in uw bewijslast, zonder enige melding dat er data ontbreekt. Pas de instellingen toe met sudo systemctl restart rsyslog en bevestig vervolgens dat de records daadwerkelijk aankomen op de collector voordat u op de data vertrouwt.

Er rest nog één punt: de collector moet een machine zijn waar de gecontroleerde personen niet op kunnen inloggen. Als dezelfde beheerdersgroep root-toegang heeft op de logserver, heeft u het bestand enkel gekopieerd en niet beveiligd. Gebruik gescheiden inloggegevens, gescheiden sleutels en idealiter een gescheiden provideraccount. Dit is dezelfde redenering die een centrale manier om veel Linux-servers te beheren de moeite waard maakt om op te zetten voordat u het nodig heeft; het is het verschil tussen een nuttig en een nutteloos eerste uur wanneer u werkt aan het herstel van een gecompromitteerde VPS.

Controleer of een normale gebruiker het record niet kan overschrijven

Test de bewering in plaats van deze aan te nemen. Doe dit vanuit een gewoon account, zonder sudo:

echo test >> /var/log/auth.log
cat /var/log/audit/audit.log
auditctl -D
id -nG

Verwacht, in deze volgorde: Permission denied, omdat auth.log eigendom is van syslog met groep adm en modus 640; opnieuw Permission denied, omdat het audit log modus 600 heeft en eigendom is van root; een foutmelding die uitvoering weigert, omdat het wijzigen van audit-regels CAP_AUDIT_CONTROL vereist; en een groepenlijst die noch adm, noch systemd-journal bevat.

Die laatste controle is waar mensen de fout in gaan. Lidmaatschap van adm verleent leestoegang tot /var/log/auth.log, en lidmaatschap van systemd-journal verleent leestoegang tot het volledige journal. Geen van beide verleent schrijftoegang, dus geen van beide staat manipulatie toe. Beide stellen een persoon in staat om elke authenticatieregel op de server te lezen; dit is een bewuste keuze die u moet maken in plaats van simpelweg een usermod -aG-regel uit een forumpost te kopiëren.

Bevestig tot slot de twee zaken die een herstart moeten overleven:

sudo auditctl -s
systemctl is-enabled auditd

enabled 2 betekent dat de regelset is vergrendeld tot de volgende opstart. enabled uit het tweede commando betekent dat auditd na die opstart opnieuw start. Een regelset die slechts tot de volgende kernel-update standhoudt, is evenmin een audit trail.

FAQ

Hoe zie ik alle commando's die een specifieke gebruiker heeft uitgevoerd?

Zoek het uid op met id -u alice en doorzoek vervolgens het audit-logboek op basis van het login-uid: sudo ausearch -ul 1000 -ts today -i. Voeg -k exec toe om de resultaten te beperken tot de execve-regel. Het login-uid wordt bij het inloggen vastgelegd en blijft behouden bij su en sudo -i; hiermee worden dus ook commando's geregistreerd die zijn uitgevoerd binnen een root-shell die door dat account is geopend. Dit werkt alleen voor commando's die zijn uitgevoerd nadat de regels zijn geladen, aangezien audit geen geschiedenis bijhoudt van gebeurtenissen die niet geconfigureerd waren om te worden vastgelegd. sudo aureport -k --summary -i toont de aantallen per regel als u eerst een overzicht van de datastructuur wilt zien.

Kan een gebruiker zijn bash-geschiedenis verwijderen om zijn acties te verbergen?

Ja, en hiervoor zijn geen speciale rechten vereist. ~/.bash_history is eigendom van de gebruiker met modus 600, dus deze kan het bestand bewerken, inkorten of verwijderen. De gebruiker kan het schrijven naar het bestand ook stoppen met unset HISTFILE, de registratie halverwege een sessie beëindigen met set +o history, of individuele commando's verbergen door ze met een spatie te laten beginnen wanneer HISTCONTROL=ignorespace is ingesteld. Bash schrijft het bestand pas bij het afsluiten van de shell; een sessie die wordt beëindigd met kill -9 $$ legt daarom niets vast. Beschouw shell-geschiedenis als een aanwijzing, nooit als bewijslast.

Logt sudo wat er gebeurt binnen sudo -i?

Nee. sudo logt alleen het commando dat het moest uitvoeren, dus sudo -i genereert één regel voor de shell en daarna niets meer. Elk commando dat in die root-shell wordt getypt, is onzichtbaar voor sudo, omdat sudo niet langer betrokken is bij het proces. sudo su -, sudo bash en elk toegestaan programma met een shell-escape gedragen zich op dezelfde manier. Twee methoden dichten dit gat: audit-regels op execve, die elk programma registreren met het oorspronkelijke login-uid gekoppeld, en sudoers-regels die in de eerste plaats geen shell verstrekken.

Vertraagt auditd mijn server?

Dit hangt volledig af van het aantal processen dat uw workload start; meet dit in plaats van uit te gaan van een schatting. Een server die voornamelijk verzoeken beantwoordt, voert weinig exec-acties uit en zal geen vertraging merken. Een build-host of CI-runner voert constant exec-acties uit en kan wel vertraging ondervinden, omdat het proces dat de gebeurtenis genereerde wordt gepauzeerd wanneer de audit-backlog van de kernel vol is, totdat er weer ruimte is. Voer sudo auditctl -s uit onder werkelijke belasting en houd backlog en lost in de gaten. Elke lost boven nul betekent dat er records verloren zijn gegaan; dit is het slechtst mogelijke resultaat, aangezien het logboek nu onzichtbare gaten bevat.

Waar moeten de audit-logboeken worden opgeslagen?

Op een andere machine, met een vertraging van enkele seconden. Iedereen die root-toegang verkrijgt op de gecontroleerde host kan /var/log/audit/audit.log verwijderen en /var/log/auth.log herschrijven. Lokale kopieën beantwoorden daarom alleen vragen over incidenten die niemand probeerde te verbergen. Stuur de logs door met de audisp-remote-plugin naar een centrale auditd, of schakel de audit-syslog-plugin in en stuur de volledige syslog-stroom door met rsyslog via TLS. Geef de collector eigen inloggegevens en zorg ervoor dat de accounts die worden gecontroleerd geen toegang hebben tot de collector.