Hostingleverandørens logs: hvad kan leveres, og hvor hurtigt forsvinder det

Forside › Cloud- og SaaS-forensik · Gennemgået oktober 2026 · Af John Nielsen

Når en hjemmeside, en webshop eller en mailkonto på et webhotel er kompromitteret eller indgår i en tvist, ligger mange af de vigtigste logs hos hostingleverandøren og ikke hos kunden. Bruger webshoppen en hostet platform, se også Webshopplatforme: ordre-, admin- og ændringslogs. Nogle kan kunden selv hente i kontrolpanelet, andre kan kun leverandøren trække ud, og mange slettes efter få dage eller uger. Den praktiske regel er derfor: Hent det, du selv kan, med det samme, og bed samtidig skriftligt leverandøren om at bevare resten, før du begynder at analysere.

Haster det? Mange hostingleverandører sletter logs efter få dage eller uger, og nogle logs kan kun leverandøren trække ud. Se akut forensisk sikring, og bemærk, at hastesager koster ekstra.

Den generelle mekanik bag logrotation er beskrevet i Logfiler og logrotation. Her handler det om det særlige ved delt hosting, VPS og administreret hosting.

Typer af hosting og hvem der har hvad

Delt webhotel · Ofte kun adgangs- og fejllog for egne domæner via kontrolpanel, med kort opbevaring
Administreret WordPress eller webshop-hosting · Varierer; ofte kun via support
VPS eller dedikeret server · Fuld adgang til systemets logs, men ikke til leverandørens netværks- og panellogs
Platform som tjeneste (fx hostet webshopsystem) · Kun det, platformen viser i administrationen

På et delt webhotel deler mange kunder samme server og ofte samme IP-adresse. Systemlogs, logs fra fælles tjenester og netværksudstyr indeholder data om andre kunder og udleveres derfor sjældent i rå form. Leverandøren kan i stedet udtrække de linjer, der vedrører kundens konto, og det udtræk skal dokumenteres.

Typiske logtyper hos en hostingleverandør

Adgangslog for webserveren: hver forespørgsel med IP-adresse, tidspunkt, adresse, statuskode, størrelse og brugeragent. Felterne er gennemgået i Webserverlogs: IIS, Apache og Nginx.
Fejllog: PHP-fejl, adgangsfejl og fejl i scripts. Viser ofte forsøg på at udnytte sårbarheder.
FTP- og SFTP-log: logins og overførte filer. Afgørende, hvis filer er lagt op eller ændret uden om CMS’et.
Kontrolpanelets log: logins i kontrolpanelet, ændringer af adgangskoder, oprettelse af FTP-konti, databaser og mailkonti.
Maillogs: afsendte og modtagne mails på serverniveau, login til postkasser via IMAP, POP og webmail. Sikringen af selve postkassen er beskrevet i IMAP-postkasser hos webhoteller.
Databaselog: sjældent slået til på delte servere.
Backup: daglige eller ugentlige kopier af filer og databaser, ofte med en kort rullende historik.
Sikkerhedslogs: web application firewall, malwarescanning og blokeringer.

Hvilke af dem der findes, og hvor længe de gemmes, varierer meget. Hver udbyder fastsætter selv perioden, og den kan være kort. Nogle sletter de rå adgangslogs, så snart der er lavet statistik ud fra dem. Spørg derfor udbyderen om den konkrete opbevaring, og få svaret skriftligt. Backup kan række længere tilbage, men indeholder normalt ikke logs.

Hvad kunden selv kan hente

Adgangs- og fejllogs fra kontrolpanelet eller via SFTP, inklusive roterede og komprimerede filer.
Hele webroden og databasen som de ser ud nu, via SFTP og databaseeksport. Det giver filernes tidsstempler og indhold.
Kontrolpanelets egne oversigter over logins og ændringer, hvis de findes. Eksportér dem, eller dokumentér dem med skærmoptagelse, hvis eksport ikke er mulig.
Liste over FTP-konti, databasebrugere og mailkonti med oprettelsesdatoer, hvis panelet viser dem.
Tilgængelige backups, som de ligger hos leverandøren. Download dem, før de roteres væk.

Beregn hashværdier for alt, der hentes, og notér, hvilken konto og hvilken vej det er hentet med. Ændr ikke noget på serveren, før det er hentet. Den praktiske rækkefølge for en virksomhed med en hacket hjemmeside er beskrevet i Hjemmesiden eller webshoppen er hacket.

Hvad der skal bestilles hos leverandøren

Bed skriftligt om bevarelse og udlevering af:

adgangslogs for perioden, også de dele, kunden ikke kan se,
FTP-, SSH- og kontrolpanellogs med IP-adresser,
maillogs for de relevante konti,
backups fra før den formodede hændelse,
oplysninger om ændringer, leverandøren selv har foretaget, fx opdateringer, flytning til ny server eller oprydning efter en malwarefund.

Angiv domæne, kontonummer, periode i UTC eller med tidszone, og bed om rå filer i det oprindelige format frem for regneark. Spørg, hvilken tidszone serveren logger i, og om der er proxy eller CDN foran, som har sine egne logs. Er leverandøren ikke villig til at udlevere, eller er der tale om en tredjemand i en tvist, bliver det et juridisk spørgsmål; se Edition fra tredjemand.

Når kunden har en VPS eller en dedikeret server

På en VPS har kunden selv rodadgang og dermed adgang til systemets logs, webserverens logs og databasen. Sikringen kan derfor følge fremgangsmåden for andre servere: et snapshot via leverandørens panel, hvis det findes, eller en forensisk kopi af disken, suppleret med en kopi af logmapperne. Men tre ting ligger stadig kun hos leverandøren: loggen over logins i leverandørens kundepanel, hvor serveren kan genstartes, geninstalleres eller få nulstillet sin rodadgangskode; konsoladgang via leverandørens webkonsol; og netværksdata fra leverandørens udstyr. Bed om dem særskilt.

Vær opmærksom på, at et snapshot i leverandørens panel ikke nødvendigvis kan hentes ud som en fil. Kan det ikke, bevarer det data hos leverandøren, men giver ingen beviskopi, du selv kan hashe.

Mailkonti på webhotellet

Mange mindre virksomheder har mail på samme webhotel som hjemmesiden. Maillogs på serveren kan vise logins til postkasserne med IP-adresse og protokol, afsendte mails med modtager og tidspunkt, og videresendelser. De er ofte kortlivede og kun tilgængelige via support. I sager om overtagne mailkonti og fakturasvindel er de en vigtig kilde, fordi postkassens indhold ikke viser, hvem der loggede ind.

Faldgruber hos hostingleverandører

Leverandøren rydder op. Ved malwarefund kan leverandøren selv rense eller suspendere kontoen. Det fjerner spor. Spørg, om det er sket, og bed om deres log over indgrebet.
Flytning mellem servere. Ved migrering følger logs ofte ikke med.
Delte IP-adresser. En IP-adresse i en ekstern log kan dække mange kunders sider. Se IP-adresser som bevis.
Tidszoner. Adgangslogs på Linux-servere har typisk lokal tid med angivelse af forskydning; panel- og maillogs kan bruge andre formater.
Statistik i stedet for logs. Webstatistik i kontrolpanelet er afledt af logs og kan ikke erstatte dem.
Bureauet har adgangen. Er hjemmesiden drevet af et webbureau, kan det være bureauet, der har kontoen hos hostingleverandøren. Afklar ejerskab af kontoen tidligt; se Skift af webbureau.

Hvad logs fra hostingleverandøren kan og ikke kan bevise

Sammen kan adgangslog, FTP-log og panellog ofte vise, hvordan en ændring kom ind: via CMS’ets administration, via en sårbarhed i et plugin, via FTP med gyldige oplysninger eller via kontrolpanelet. De kan vise, fra hvilke IP-adresser og hvornår. De kan ikke vise, hvem der stod bag en IP-adresse, og hvis loggen for den relevante periode er roteret væk, kan indgangsvejen ofte kun sandsynliggøres ud fra filernes tidsstempler og indhold. Fremgangsmåden ved en kompromitteret WordPress-side er beskrevet i Kompromitteret WordPress.

Dokumentation

Notér for hver kilde, om den er hentet af kunden eller leveret af leverandøren, hvornår, i hvilket format, hvilken tidszone den bruger, og om den er komplet eller et udtræk. Gem leverandørens skriftlige svar om opbevaring og indgreb. Beregn hashværdier ved modtagelsen, og beskriv perioder, hvor logs ikke længere fandtes.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Cloud- og SaaS-forensik

Læs også: Containere og Kubernetes: flygtige spor, der skal sikres hurtigt · Danske cloudregnskabsprogrammer: ændringslog og eksport

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

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik