Forside › macOS- og Linux-forensik · Gennemgået oktober 2026 · Af John Nielsen
På en Linux-server findes svarene typisk i tre slags kilder: systemets journal (journald), de klassiske tekstlogs som auth.log eller secure, og brugernes shellhistorik. Sammen kan de vise, hvem der loggede ind, hvorfra, hvornår, og hvilke kommandoer der blev kørt med forhøjede rettigheder. Kilderne roterer og kan ændres af enhver med root-adgang, så de skal sikres hurtigt, helst sammen med en central kopi, der ligger uden for serverens kontrol. Sikringen af selve serveren og dens diske er beskrevet her: → Virtuelle maskiner og servere: sikring uden nedetid
Haster det? Både journald og tekstlogs roterer, flygtige journaler forsvinder ved genstart, og historikken for aktive sessioner kan kun sikres fra den kørende server. Se akut forensisk sikring, og bemærk, at hastesager koster ekstra.
journald
På distributioner med systemd samler journald logs fra kernen, tjenester og programmer i et binært format med strukturerede felter: tidsstempel i mikrosekunder, værtsnavn, proces-id, bruger-id, tjeneste og meddelelse.
- Vedvarende eller flygtig: Indstillingen Storage i journald.conf afgør det. Med “persistent” gemmes journalen på disken under
/var/log/journal, med “volatile” kun i hukommelsen under /run/log/journal, og med “auto” vedvarende, hvis mappen under/var/logfindes. Flygtige data forsvinder ved genstart. Standardværdien fastlægges, når systemd bygges, og distributionerne har valgt forskelligt, så den effektive indstilling og mappernes indhold aflæses på det konkrete system. Konfigurationen afgør, om der overhovedet er historik. - Størrelse og rotation: journald begrænser journalens samlede størrelse og fjerner ældste filer. Hvor langt tilbage den rækker, skal konstateres i den konkrete sikring.
- Boot-opdeling: Hver opstart får et id, så hændelser kan knyttes til en bestemt kørselsperiode.
- Forsegling: journald kan konfigureres med forward secure sealing, der gør det muligt at kontrollere, om journalfiler er ændret. Det er sjældent slået til, men skal tjekkes, fordi det styrker integriteten markant. → Logintegritet
Sikr journalfilerne som filer, og eksportér desuden i et struktureret format med alle felter. En eksport kun som tekst mister felterne og kan ikke senere kontrolleres mod filerne.
Klassiske tekstlogs
Mange servere kører rsyslog eller en tilsvarende tjeneste ved siden af journald og skriver tekstlogs i /var/log. Navnene varierer mellem distributionsfamilier:
auth.log(Debian, Ubuntu) eller secure (Red Hat-familien) · SSH-logins, mislykkede forsøg, sudo, su, ændringer af konti- syslog eller messages · Generelle system- og tjenestehændelser
- wtmp, btmp og lastlog · Binære registre over logins, mislykkede logins og seneste login pr. bruger
audit.log(auditd) · Detaljerede revisionshændelser efter de regler, der er sat op- Pakkehåndteringens log · Installation og fjernelse af programmer
- Tjenesternes egne logs · Webserver, database, mail, cron
Tekstlogs i klassisk syslog-format mangler ofte år og tidszone i tidsstemplet. Det skal udledes af filens placering i rotationen, filens egne tidsstempler og serverens konfiguration. Roterede filer er ofte komprimerede og skal med.
wtmp og btmp er binære og læses med de tilhørende værktøjer eller forensiske parsere. De viser sessioner med terminal, kildeadresse, start og slut, men de kan manipuleres af en root-bruger og bør bekræftes af journald eller auth-loggen.
auditd
Er auditd konfigureret, kan den registrere kommandokørsel, filadgang og ændringer i systemfiler med bruger-id, også det oprindelige login-id (auid), der bevares, når en bruger skifter til root med sudo. Det er en af de få kilder, der kan knytte en handling som root til den person, der oprindeligt loggede ind. Hvad der findes, afhænger helt af reglerne, der var sat op før hændelsen.
Shellhistorik
Bash og andre skaller gemmer brugerens kommandoer i en historikfil i hjemmemappen. Den er nyttig, men upålidelig som eneste kilde:
- Skrives typisk først ved afslutning af skallen. En session, der stadig kører eller blev afbrudt, er måske ikke med. Historikken for aktive sessioner kan kun sikres fra den kørende maskine.
- Ingen tidsstempler som udgangspunkt, medmindre skallen er konfigureret til det.
- Kan undlade kommandoer efter indstillinger, fx kommandoer med mellemrum foran, og kan slettes eller tømmes af brugeren.
- Flere sessioner kan overskrive hinandens historik.
En tom eller manglende historikfil er derfor ikke i sig selv tegn på sletning. Har sletning fundet sted, kan spor findes i filsystemets tidsstempler, i auditd eller i en central logopsamling. → Anti-forensics: sletning og manipulation
Andre spor på serveren
Logs er ikke de eneste kilder. En række konfigurationsfiler og mapper viser, hvad der er ændret, og kan sammenholdes med logposterne:
- Konti og grupper: filerne med brugere, grupper og sudo-rettigheder. Filernes ændringstid og indhold viser, om konti eller rettigheder er tilføjet.
- SSH-nøgler: autoriserede nøgler i brugernes hjemmemapper viser, hvem der kan logge ind uden adgangskode. En nøgle, der ikke kan forklares, er et vigtigt fund.
- Planlagte job: cron-tabeller og systemd-timere kan afsløre opgaver, der kører automatisk.
- Tjenester: nye eller ændrede systemd-enheder viser programmer, der startes ved opstart.
- Midlertidige mapper: værktøjer og scripts placeres ofte i midlertidige mapper, som ryddes ved genstart.
Gennemgangen sker for at opdage og dokumentere vedvarende adgang, fx efter en administrators fratræden, og aldrig ved at ændre eller fjerne noget på originalen. → Bagdøre efter en administrator
Filsystemets tidsstempler på disse filer bør sammenholdes med logposterne. En ny nøgle tilføjet samme minut som et login fra en ukendt adresse er et stærkere fund end hver kilde for sig.
Sikring af en kørende server
En produktionsserver kan sjældent slukkes. Rækkefølgen bør være:
- Notér systemtid, tidszone og NTP-status, og sammenlign med en pålidelig kilde.
- Sikr flygtige oplysninger: aktive sessioner, kørende processer, netværksforbindelser og eventuelt hukommelse. → Live response
- Kopiér logmapperne og journalen med bevarede tidsstempler til et eksternt mål, og hash hver fil.
- Hent kopier fra central logopsamling, fx SIEM eller syslog-server, for samme periode.
- Lav en kopi af disken, typisk via snapshot på hypervisor- eller cloudniveau.
- Stop eller udskyd logrotation efter aftale med driften, hvis den relevante periode er ved at forsvinde.
Alle kommandoer, der køres på serveren, skal registreres med tidspunkt og output, fordi de selv efterlader spor i de logs, der sikres.
Fejlkilder i fortolkningen
- Root kan ændre alt lokalt. En undersøgelse af en administrator med root-adgang kan ikke hvile på serverens egne logs alene. Uafhængige kilder uden for serveren er nødvendige. → Undersøgelse af en administrator, der kan slette loggen
- Tjenestekonti og nøgler. Mange logins sker med delte konti eller SSH-nøgler. Kontoen er ikke personen. Nøglens fingeraftryk i loggen kan sammenholdes med, hvem der havde nøglen.
- Kildeadresser. Adresser i loggen kan være en jump-server, en VPN-koncentrator eller en NAT-adresse.
- Tidszoner. journald gemmer UTC internt, mens tekstlogs ofte skrives i lokal tid uden zone. Blandes de ukritisk, bliver tidslinjen forskudt.
- Ufuldstændig rotation. Huller kan skyldes rotation, en genstart med flygtig journal eller fyldt disk.
Hvad kilderne kan og ikke kan bevise
Samlet kan logkilderne vise login-sessioner med konto, kildeadresse og tidsrum, brug af sudo, ændringer af konti og tjenester og ofte hvilke kommandoer der blev kørt. De kan ikke alene vise, hvem der fysisk brugte en konto, og de kan være ændret af en root-bruger. Konklusioner bør bygge på flere uafhængige kilder.
Dokumentation
Angiv distribution og version, logkonfiguration (vedvarende journal, rotation, auditd-regler, central opsamling), hvilke filer der er sikret med hash, tidsrum pr. kilde, og alle kommandoer, der er kørt på serveren under sikringen.
Kilder og versioner
Senest gennemgået: oktober 2026.
Næste skridt
Del af: macOS- og Linux-forensik
Læs også: APFS: snapshots, kloner og betydningen for sikringen · ext4, XFS, Btrfs og LVM: sletning og snapshots på Linux
→ Forensisk undersøgelse af en computer · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
