Forside › Netværk og logs · Gennemgået oktober 2026 · Af John Nielsen
En webservers adgangslog registrerer hver HTTP-forespørgsel, serveren behandlede: hvornår, fra hvilken IP-adresse, hvilken adresse der blev bedt om, med hvilken metode, hvad serveren svarede, og hvor mange bytes der blev sendt. Det gør loggen central i sager om kompromitterede hjemmesider, misbrug af webshops, udtræk af data via en webapplikation og tvister om, hvad der skete på en side. Ved injiceret kode på en betalingsside er loggen et af de vigtigste spor; se Skimming på betalingssiden. Men tre forhold afgør, hvad loggen kan bruges til: hvilket format og hvilke felter serveren var sat op til at skrive, hvilken tidszone tidsstemplet står i, og om der stod en proxy, en load balancer eller et CDN foran serveren, så den IP-adresse, serveren så, i virkeligheden var mellemleddets.
Haster det? Webserverlogs roterer og slettes efter en fast periode, hos hostingleverandører ofte efter få dage eller uger. Ved akut behov: akut forensisk sikring; hastesager koster ekstra.
Hvordan en loglinje læses på et overordnet niveau, er beskrevet for advokater i Sådan læser du en logfil. Her går vi i dybden med de tre udbredte webservere.
Standardformaterne
Apache skriver som udgangspunkt i Common Log Format eller det udvidede Combined Log Format. Combined indeholder klientens adresse, identitet og brugernavn, tidspunkt i firkantede parenteser med tidszoneforskydning, forespørgselslinjen med metode, sti og protokol, statuskode, antal bytes i svaret, henvisende side og brugeragent. Formatet styres af LogFormat– og CustomLog-direktiverne, og mange installationer har tilføjet felter som svartid eller virtuel vært.
Nginx bruger et tilsvarende kombineret format som standard, styret af direktivet log_format. Tidsstemplet er lokal tid med forskydning. Nginx kan også konfigureres til JSON-logning, hvilket gør felterne entydige.
IIS skriver typisk i W3C Extended Log File Format. Filens hoveder med linjer, der starter med havelåge, angiver, hvilke felter der er med, og i hvilken rækkefølge. Typiske felter er dato, tid, serverens IP, metode, sti, forespørgselsstreng, port, brugernavn, klientens IP, brugeragent, statuskode, understatus, Windows-statuskode og tidsforbrug. Felterne kan ændres, og rækkefølgen kan derfor variere mellem filer fra samme server. Læs altid hovedet i hver fil.
Tidszoner og tidspunkter
- Apache · Lokal tid med angivelse af forskydning, fx +0100
- Nginx · Lokal tid med forskydning
- IIS (W3C) · UTC uden angivelse i selve linjen
IIS skriver altid UTC i W3C-formatet, men der findes en indstilling, så filnavne og skift til ny logfil følger lokal tid. En fil med en dato i navnet kan derfor indeholde linjer fra to UTC-døgn.
IIS-tid i UTC er en klassisk fejlkilde: En dansk læser, der ikke ved det, flytter alle hændelser en eller to timer. Apache og Nginx bærer forskydningen i linjen, men sommertid gør, at forskydningen skifter midt i en log. Normalisér alt til én tidszone, og angiv den.
Tidspunktet betyder heller ikke det samme overalt. Apaches standardtidsstempel angiver, hvornår forespørgslen blev modtaget, mens Nginx’ lokale tid angiver, hvornår loglinjen blev skrevet, typisk ved afslutningen. Ved lange forespørgsler, fx store downloads, kan forskellen være betydelig. Begge servere kan logge forespørgslens varighed i et ekstra felt, hvis logformatet er udvidet, og så kan start og slut beregnes.
Proxy, load balancer og CDN
Står der en reverse proxy, en load balancer eller et CDN foran webserveren, er det mellemleddet, der forbinder til serveren. Serverens log viser da mellemleddets adresse som klient for alle forespørgsler, medmindre serveren er sat op til at læse den oprindelige adresse fra en header, typisk X-Forwarded-For eller en udbyderspecifik header.
Det giver tre problemer:
- Uden opsætning viser loggen kun mellemleddets adresser. Den rigtige klientadresse findes kun i mellemleddets egen log.
- Med opsætning er klientadressen hentet fra en header. Den er kun troværdig, hvis serveren kun accepterer headeren fra kendte mellemled. Ellers kan klienten selv skrive en vilkårlig adresse i headeren.
- Cache: Et CDN besvarer mange forespørgsler fra sin cache uden at kontakte serveren. De optræder slet ikke i serverens log, kun i CDN’ets.
Gem derfor konfigurationen for både serveren og mellemleddene, og hent CDN’ets egne logs, hvis de findes. Mange CDN’er gemmer kun logs kortvarigt eller kun på bestemte abonnementer. Hvordan IP-adressen derefter vurderes, er beskrevet i IP-adresser som bevis.
Statuskoder og bytes
Statuskoden viser, hvad serveren svarede: 200 for et normalt svar, 206 for et delvist svar, 301 og 302 for omdirigering, 304 for “ikke ændret”, 401 og 403 for manglende adgang, 404 for ikke fundet og 500 for serverfejl. Bytefeltet viser størrelsen af det, serveren sendte, ikke nødvendigvis det, klienten modtog. En afbrudt download kan stå med fuld størrelse eller færre bytes, afhængigt af server og opsætning.
POST-forespørgsler, fx login, formularer og uploads, logges med adresse og status, men ikke med indholdet. Et login-forsøg i loggen viser altså, at der blev sendt en formular, ikke hvilket brugernavn der blev brugt, medmindre applikationen selv logger det.
Sikring
- Kopiér alle logfiler, også roterede og komprimerede, fra serveren eller via hostingleverandøren. Se Hostingleverandørens logs.
- Gem konfigurationen: logformat, virtuelle værter, tidszone, proxy- og header-opsætning, rotation.
- Hent logs fra mellemled: load balancer, web application firewall og CDN.
- Notér serverens ur og tidssynkronisering.
- Beregn hashværdier for alle filer straks.
Rotation og komprimering er beskrevet i Logfiler og logrotation.
Sammenhold med applikationens egne spor
Webserverloggen ved intet om brugere i applikationen. Den ser adresser og statuskoder. For at koble en forespørgsel til en konto i et CMS, en webshop eller en fagapplikation skal den sammenholdes med applikationens egne logs, databasens tabeller over logins og ordrer, og filsystemets tidsstempler for ændrede filer. En POST til login-adressen efterfulgt af forespørgsler til administrationssider fra samme adresse er et mønster; applikationens log over vellykkede logins for samme tidspunkt er det, der binder mønstret til en konto. Omvendt kan en fil med et nyt ændringstidspunkt dateres og derefter matches med en forespørgsel i loggen, der kaldte en upload- eller redigeringsfunktion.
Fejlkilder i fortolkningen
- Robotter og scannere udgør en stor del af forespørgslerne på mange sider. Brugeragenten er klientens egen påstand og kan efterligne en browser.
- Én side, mange linjer: Billeder, scripts og typografiark giver hver deres linje.
- Delte IP-adresser: Firmanetværk, mobilnet og VPN gør, at mange brugere deler adresse.
- Forespørgselsstrenge kan indeholde personoplysninger eller sessionsnøgler. Behandl loggen fortroligt, og afgræns gennemgangen.
- Flere servere bag en load balancer skriver hver deres log. Én servers log er kun en del af billedet.
Hvad webserverloggen kan og ikke kan bevise
En komplet og korrekt fortolket adgangslog kan vise, at en klientadresse bad om bestemte adresser på bestemte tidspunkter, og hvad serveren svarede. Den kan vise mønstre som scanning, gentagne loginforsøg og hentning af bestemte filer, og den kan datere, hvornår en ondsindet fil første gang blev kaldt. Den kan ikke vise, hvem der stod bag adressen, hvad der blev sendt i en formular, eller forespørgsler, som et CDN besvarede fra cache. Fremgangsmåden ved en kompromitteret WordPress-side er beskrevet i Kompromitteret WordPress, og den grundlæggende sikring af en WordPress-hjemmeside i Bevissikring af en WordPress-hjemmeside.
Dokumentation
Angiv server og version, logformat med felter, tidszone, mellemled og deres opsætning, periode, perioder uden logs, eksportmetode og hashværdier. Beskriv eksplicit, om klientadressen er serverens egen observation eller hentet fra en header, og hvilke forespørgsler der kan være besvaret af et mellemled uden at nå serveren.
Kilder og versioner
- Microsoft Learn: IIS logFile-element (W3C, UTC og localTimeRollover)
- Apache HTTP Server: mod_log_config (%t og %D)
- nginx: ngx_http_log_module ($time_local og $request_time)
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Netværk og logs
Læs også: NetFlow og pakkeopsamling i civile undersøgelser · Logkorrelation: sådan kobles hændelser på tværs af systemer
→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
