Logfiler og logrotation: sikring før data forsvinder

Forside › Netværk og logs · Gennemgået oktober 2026 · Af John Nielsen

Logs er blandt de mest flygtige beviser på en disk, fordi de er designet til at blive slettet. Når en logfil når en vis størrelse eller alder, roteres den, komprimeres og slettes til sidst, og i mange systemer er perioden kort. Den første opgave, når en sag opstår, er derfor at finde ud af, hvor de relevante logs ligger, hvornår de forsvinder, og hvilke der skal sikres først. Den generelle problemstilling er beskrevet i Data, der forsvinder. Her gennemgås teknikken.

Haster det? Mange logs roterer efter få dage eller ved en fast størrelse, og netværksudstyrets interne buffer kan være overskrevet inden for timer. Se akut forensisk sikring, og bemærk, at hastesager koster ekstra.

Hvordan rotation virker

• Linux, klassisk · logrotate, styret af logrotate.conf og filerne i logrotate.d: interval, antal gamle filer og komprimering
• Linux, systemd · journald, styret af journald.conf: maksimal størrelse og alder, vedvarende lagring eller kun i hukommelsen
• Windows · Hændelseslogs med maksimal størrelse pr. log og en handling ved fuld log, ofte overskrivning efter behov
• Netværksudstyr · Intern buffer, ofte lille, hvor de ældste poster overskrives først
• SaaS · Leverandørens opbevaringsperiode, ofte afhængig af licens

To forhold overses ofte. Er journald sat op uden vedvarende lagring, ligger loggen kun i hukommelsen og forsvinder ved genstart. Og på Windows er sikkerhedsloggen på mange systemer så lille, at den ved normal aktivitet kun dækker kort tid, på en travl domænecontroller måske kun timer eller dage. Den faktiske konfiguration skal derfor aflæses på det konkrete system, ikke antages ud fra standardværdier. På Windows viser kommandoen wevtutil gl med lognavnet den aktuelle maksimale størrelse og handlingen ved fuld log, og resultatet kan gemmes som dokumentation.

Rotation er heller ikke det eneste, der fjerner logs. Diskpladsovervågning, oprydningsscripts og migrering til nye servere kan slette ældre filer, og en geninstallation fjerner alt lokalt.

Hvor ligger logs?

Servere

• Linux: mappen /var/log med blandt andet auth.log eller secure, syslog eller messages, journald-filerne og applikationernes egne logs.
• Windows: hændelseslogs som evtx-filer under System32\winevt\Logs og applikationernes egne mapper.
• Webservere: adgangs- og fejllogs, fx under nginx- eller Apache-mappen i /var/log, eller IIS-logs under inetpub.
• Databaser: transaktions-, fejl- og auditlogs, hvis revision er slået til.

Firewalls og VPN

• Lokal log på enheden, ofte kun for kort tid.
• Videresendelse til en syslog-server eller et SIEM-system.
• Producentens cloudportal med opbevaring efter licens.

Hvad disse logs kan vise om forbindelser og logins, er beskrevet i Firewall-, VPN- og loginlogs.

SaaS

• Microsoft 365: auditlog og loginlogs i Entra ID, se Unified Audit Log.
• Google Workspace: auditlogs i administrationskonsollen, se Google Vault og auditlogs.
• Andre tjenester: Opbevaring og eksportmuligheder varierer meget. Nogle tjenester viser kun logs i brugerfladen uden mulighed for eksport, og så må sikringen ske ved dokumenteret skærmoptagelse eller ved en anmodning til leverandøren.

Første skridt: stop tabet

1. Kortlæg kilderne. Hvilke systemer kan vise det, sagen handler om? Tænk både på den enhed, hvor handlingen skete, og på de systemer, handlingen passerede igennem.
2. Find opbevaringsperioden for hver kilde ud fra den faktiske konfiguration.
3. Sikr de kilder, der udløber først. En firewallbuffer på få dage går forud for en serverlog, der gemmes et år.
4. Overvej at forlænge opbevaringen midlertidigt, fx ved at øge logstørrelsen eller slå videresendelse til. Ændringen skal dokumenteres med tidspunkt og person, fordi den ændrer systemet.
5. Undgå genstart af systemer, der kun gemmer logs i hukommelsen, før de er sikret.

Sikring i praksis

• Kopiér de oprindelige filer, også roterede og komprimerede versioner. De ældste perioder ligger ofte netop i de komprimerede filer.
• Windows: Eksportér hændelseslogs med systemets eget eksportværktøj i evtx-format, eller kopiér evtx-filerne fra en forensisk kopi. Gem i det oprindelige format, ikke kun som CSV, så alle felter og beskrivelser bevares.
• journald: Kopiér journalfilerne, eller brug journalctl med et eksportformat, der bevarer alle felter, for hele den relevante periode.
• Netværksudstyr: Eksportér via enhedens egne funktioner, og gem også konfigurationen, der viser logniveau, tidszone og videresendelse.
• SaaS: Eksportér i det mest komplette format, tjenesten tilbyder, og del store perioder op, hvis der er grænser for antal resultater pr. eksport. Kontrollér, at antallet af poster stemmer med det, tjenesten viser.
• Beregn hashværdier straks efter eksport, se Hashalgoritmer i forensic.

Tid og ure

Logs er kun så præcise som det ur, der skrev dem:

• Notér hver kildes tidszone og tidsformat. Mange enheder logger i UTC, andre i lokal tid, og nogle uden angivelse af tidszone.
• Kontrollér, om systemet synkroniserer med NTP, og om uret har afveget i perioden.
• Sammenlign med en kendt hændelse, der findes i flere kilder, og beregn den eventuelle forskydning.

Først når tidsforskydningerne er kendt, kan logs fra forskellige systemer sættes sammen. Fremgangsmåden er beskrevet i Tidslinjeanalyse.

Logs kan ændres

En administrator med rettigheder til systemet kan ofte også ændre eller slette logs. Derfor vejer det tungere, når samme hændelse findes i flere uafhængige kilder:

• Lokal log på serveren · Lav, hvis den undersøgte person har administratoradgang
• Central syslog eller SIEM · Højere, især med begrænset adgang
• Leverandørens cloudlog · Høj, kan ikke ændres af kunden

Huller i fortløbende numre, pludselige spring i tid eller en log, der begynder midt i en periode, kan tyde på sletning. De kan også skyldes rotation, fejl eller genstart, så fundet skal sammenholdes med konfigurationen. Se Anti-forensics.

Logs hos tredjepart

Mange relevante logs ligger slet ikke hos den part, der har sagen. Internetudbydere, hostingleverandører, MSP’er og SaaS-leverandører har deres egne logs med egne opbevaringsperioder, og de udleveres normalt kun efter aftale, samtykke eller en afgørelse. Det har to konsekvenser for den tekniske planlægning:

• Kortlægningen bør tidligt identificere de logs, der kun findes hos tredjepart, så advokaten kan tage stilling til, om der skal anmodes om bevarelse eller udlevering, før perioden udløber.
• Når logs modtages fra en leverandør, skal det dokumenteres, hvordan de er trukket ud, hvilket format og hvilken tidszone de har, og om de er komplette. Et regneark med udvalgte linjer er svagere end en rå eksport.

Leverandørens eget driftspersonale kan også have adgang til at ændre eller slette logs. Spørg derfor ind til, hvordan loggene opbevares og beskyttes, og notér svaret.

Typiske fejl i fortolkningen

• En logpost viser, at en konto har gjort noget, ikke hvilken person der brugte kontoen.
• Fravær af en logpost betyder ikke, at handlingen ikke fandt sted, hvis logningen for den type hændelse ikke var slået til.
• IP-adresser i logs kan være oversat af NAT, proxy eller VPN og peger ikke nødvendigvis på den enkelte enhed.
• Felter kan skifte betydning mellem versioner af samme system.

Dokumentation

For hver sikret kilde dokumenteres:

• kilde, system og version,
• opbevaringsindstillinger og logniveau på sikringstidspunktet,
• hvilken periode sikringen dækker, og om den er komplet,
• eksportmetode, værktøj og eventuelle begrænsninger,
• hashværdier og tidszone.

Uden konfigurationen kan en modpart med rette spørge, om loggen overhovedet kunne have registreret det, der påstås at mangle. Gem derfor altid konfigurationen sammen med selve loggen, og beskriv i rapporten, hvordan de to hænger sammen.

Kilder og versioner

• Microsoft Learn: wevtutil, visning af logkonfiguration
• systemd: journald.conf og indstillingen Storage
• Linux man-pages: logrotate

Senest gennemgået: oktober 2026.

Næste skridt

• IP-adresser som bevis: NAT, CGNAT, VPN og geolokationens fejl
• DHCP, Wi-Fi og NAC: hvilken enhed havde IP-adressen?
• Webserverlogs (IIS, Apache, Nginx): felter, tidszoner, proxy og CDN
• Logkorrelation: sådan kobles hændelser på tværs af systemer

Del af: Netværk og logs

Læs også: .dk-domæner: registreringshistorik og DNS-ændringer · IP-adresser som bevis: NAT, CGNAT, VPN og geolokationens fejl

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT