Kort sagt: Den, der efter en sikkerhedshændelse vil skifte hostingudbyder, bør først sikre beviser og afklare hændelsen, derefter kun overføre kontrollerede data til et nyopsat system og først bagefter opsige den gamle aftale. Den nye udbyder vælger I efter sikkerhedskriterier: dokumenterbare patch-forløb, adskillelse af kunder, adgang til logs, backups og klare kontaktpersoner. Et skift af hostingudbyder giver mening, når tilliden eller ydelsen mangler, men det erstatter ikke en oprydning.
Når tilliden er væk
Efter PHP2Shell oplever mange virksomheder for første gang deres hostingudbyder under pres. Nogle fik hurtigt et klart svar om patchstatus. Andre ventede dage på et svar, fik kun generelle vendinger eller opdagede, at deres website kørte på en forældet PHP-version. Kommer der så også en hændelse til, er ønsket om et skift forståeligt.
Et skift af hostingudbyder er dog ikke et skridt i håndteringen af hændelsen, men i nyopstillingen bagefter. Den, der sætter det i den forkerte rækkefølge, tager i værste fald angriberen med og mister samtidig de spor, der viser, hvad der skete.
Den rette rækkefølge ved skiftet
- Sikr spor, så længe de findes. Logs, filer og database på det gamle system hører ind i en sikkerhedskopi, før noget slettes eller opsiges. Spørg udtrykkeligt den gamle hostingudbyder om adgangs- og fejllogs fra og med den 20. oktober 2026 og om deres opbevaringstid. Hvordan I går frem, beskriver indlægget Sikr beviser, før I sætter op på ny.
- Afgræns hændelsen. Hvilke systemer er berørt, hvilke adgange er brugt, hvilke data kunne nås? Heraf afhænger anmeldelsespligter og spørgsmålet om, hvad I må tage med.
- Kontrollér anmeldelsespligter. Kan personoplysninger være berørt, begynder fristen for en mulig GDPR-anmeldelse med kendskabet til hændelsen, ikke med flytningen. Baggrunden står under GDPR-anmeldelsespligt: 72 timer.
- Byg det nye system rent op. Understøttet PHP-version, aktuelle pakker, hærdet konfiguration, før den første fil overføres.
- Overfør kun det kontrollerede. Kode fra en ren kilde, database og medier efter kontrol.
- Skift alle adgangsdata. Database, admin-konti, SSH, FTP, API-nøgler, også dem i konfigurationsfiler.
- Skift over og overvåg. DNS-omlægning, derefter en periode med tættere overvågning.
- Afslut den gamle aftale. Først når logs og sikkerhedskopier er sikret, og den nye drift kører stabilt.
Opsig ikke den gamle aftale, før I har logs og sikkerhedskopier i hånden. Med aftalens udløb kan data hos udbyderen blive slettet, som I har brug for over for forsikringsselskaber, myndigheder eller til jeres egen opklaring.
Hvad I ikke bør tage med
Det ville være bekvemt bare at kopiere hele webmappen eller et aftryk af serveren. Netop det er risikabelt efter en hændelse. Webshells camouflerer sig som harmløse filer, bagdøre sidder i konfigurationsfiler som .htaccess eller .user.ini, og indsmuglet kode kan ligge i databaseindhold.
Overfør derfor applikationskoden fra en ren kilde, f.eks. producentens pakke i den rette version eller jeres versionsstyringssystem. Medier overtager I uden eksekverbare filer, databasen efter en kontrol for påfaldende indhold og nye administratorkonti. Det, der blev fundet på det gamle system, hjælper ved denne kontrol.
Tænk også på alt, hvad der ligger ved siden af websitet hos den gamle udbyder. Mailbokse, DNS-poster, certifikater og videresendelser glemmes let ved flytningen. Sænk gyldighedstiden for DNS-posterne nogle dage før omskiftningen, så omlægningen hurtigt når frem til de besøgende. Flytter mails med, så planlæg skiftet af mailbokse for sig, for også dér kan adgangsdata være berørt efter en hændelse.
Vælg den nye hostingudbyder efter sikkerhed
Pris og lagerplads står i ethvert tilbud. De afgørende sikkerhedsspørgsmål må I som regel selv stille. Følgende liste hjælper ved sammenligningen:
| Kriterium | Spørgsmål til udbyderen | Hvorfor det betyder noget |
|---|---|---|
| Patch-forløb | Hvordan og inden for hvilken ramme indspilles og genstartes PHP-sikkerhedsopdateringer? | PHP2Shell har vist, hvor vigtigt et dokumenterbart forløb er |
| Dokumentation | Får jeg på forespørgsel en skriftlig bekræftelse af patchstatus? | Grundlag for jeres egen dokumentation |
| PHP-versioner | Hvilke grene tilbydes, og hvor længe endnu? | Gamle grene uden opdateringer er en vedvarende risiko |
| Adskillelse | Kører hvert website med egen bruger og egen PHP-proces? | Begrænser skader, hvis en nabo angribes |
| Logs | Har jeg adgang til adgangs- og fejllogs, og hvor længe opbevares de? | Uden logs ingen opklaring |
| Backups | Hvor ofte, hvor længe, adskilt fra webserveren, med gendannelsestest? | Gendannelse efter en hændelse |
| Nødkontakt | Hvordan når jeg ved en hændelse en kyndig person? | Tid er den knappeste faktor i en alvorlig situation |
| Databehandling | Findes der en aftale efter GDPR og en liste over underdatabehandlere? | Pligt ved personoplysninger |
En skabelon til spørgsmålet om patchstatus tilbyder vejledningen Spørg hosteren om patch-status. Den egner sig også til at sammenligne udbydere, før aftalen indgås.
Er en anden driftsmodel det bedre svar?
Nogle gange ligger problemet mindre hos hostingudbyderen end hos driftsmodellen. Den, der driver en egen server uden regelmæssig pleje, er ofte bedre tjent med et velpasset managed-tilbud. Omvendt kan en virksomhed med egen it vinde mere kontrol over patch-tidspunkter, når den selv administrerer. Afvejningen beskriver indlægget Managed hosting eller egen server?.
Uafhængigt af modellen gælder: Fastlæg opgavefordelingen skriftligt. Hvem indspiller PHP-opdateringer, hvem genstarter, hvem kontrollerer applikationen, hvem melder sig hos hvem i en nødsituation? Ved PHP2Shell er mange forsinkelser opstået netop her, fordi hver side troede, at den anden tog sig af det.
Hvordan hjælper PHP SOS konkret?
- Vi sikrer logs og data på det gamle system og afklarer, hvad der skete ved hændelsen.
- Vi bygger det nye system hærdet op og overfører kun kontrolleret indhold fra rene kilder.
- Vi gennemgår nye udbyderes tilbud ud fra sikkerhedskriterierne og stiller de rette spørgsmål.
- Ved en igangværende hændelse arbejder vi inden for rammerne af vores incident response, til hændelsen er afsluttet og dokumenteret.
Ofte stillede spørgsmål
Bør jeg skifte hostingudbyder med det samme efter et hackerangreb?
Ikke med det samme. Først skal spor sikres, hændelsen afgrænses og årsagen afklares. En overilet flytning tager muligvis skadelig kode med og kan ødelægge beviser hos den gamle udbyder.
Var hostingudbyderen skyld i det, hvis mit website blev angrebet via PHP2Shell?
Det afhænger af aftalen og af tidspunktet. Ved shared hosting er det som regel hostingudbyderen, der er ansvarlig for PHP-opdateringer, ved egne servere driftsansvarlige. Patcherne udkom den 21. oktober 2026; om og hvornår de blev indspillet, kan kun afklares med dokumentation. I ansvarsspørgsmål bør I søge juridisk rådgivning.
Hvilke data må jeg tage med til den nye hostingudbyder?
Kun kontrollerede indhold: Databasen efter kontrol for indsmuglet kode, medier uden eksekverbare filer og kode fra en ren kilde som producentens pakke eller jeres versionsstyringssystem. Hele serverbilleder eller webmapper fra det kompromitterede system bør I ikke overføre ukontrolleret.
Skal jeg inddrage databeskyttelse efter en hændelse?
Hvis personoplysninger kan være berørt, kan der bestå en anmeldelsespligt efter GDPR, som regel inden for 72 timer. Hos den nye hostingudbyder har I desuden brug for en databehandleraftale. Afklar det med jeres databeskyttelsesrådgiver; dette er ikke juridisk rådgivning.