Kort sagt: Den som vill byta hostingleverantör efter en säkerhetsincident bör först säkra bevis och klarlägga incidenten, sedan bara föra över granskade data till ett nyuppsatt system och först därefter säga upp det gamla avtalet. Den nya leverantören väljer ni efter säkerhetskriterier: styrkta patchrutiner, åtskillnad mellan kunder, tillgång till loggar, säkerhetskopior och tydliga kontaktpersoner. Ett leverantörsbyte är motiverat när förtroende eller prestanda saknas, men det ersätter ingen sanering.
När förtroendet är borta
Efter PHP2Shell upplever många företag sin hoster under press för första gången. Vissa fick snabbt ett tydligt besked om patchnivån. Andra väntade i dagar på svar, fick bara allmänna fraser eller upptäckte att deras webbplats körde på en föråldrad PHP-version. Om en incident dessutom tillkommer är önskan om ett byte begriplig.
Ett leverantörsbyte är dock inget steg i hanteringen av incidenten, utan i nyuppställningen efteråt. Den som lägger det i fel ordning tar i värsta fall med sig angriparen och förlorar samtidigt de spår som visar vad som hänt.
Rätt ordning vid bytet
- Säkra spår så länge de finns. Loggar, filer och databas från det gamla systemet hör hemma i en säkerhetskopia innan något raderas eller sägs upp. Fråga den gamla hostern uttryckligen efter åtkomst- och felloggar från och med den 20 oktober 2026 och efter hur länge de sparas. Hur ni går tillväga beskrivs i inlägget Säkra bevis innan ni sätter upp på nytt.
- Avgränsa incidenten. Vilka system är berörda, vilka åtkomster har utnyttjats, vilka data var nåbara? Av det beror anmälningsskyldigheter och frågan om vad ni får ta med.
- Pröva anmälningsskyldigheter. Kan personuppgifter vara berörda börjar fristen för en möjlig GDPR-anmälan när ni får kännedom om incidenten, inte vid flytten. Bakgrund finns under GDPR-anmälan: 72 timmar.
- Bygg det nya systemet rent. Stödd PHP-version, aktuella paket, härdad konfiguration innan den första filen förs över.
- För bara över det granskade. Kod från en ren källa, databas och mediafiler efter kontroll.
- Byt alla inloggningsuppgifter. Databas, adminkonton, SSH, FTP, API-nycklar, även de som ligger i konfigurationsfiler.
- Växla över och övervaka. DNS-omläggning, därefter en tid med tätare övervakning.
- Avsluta det gamla avtalet. Först när loggar och säkerhetskopior är säkrade och den nya driften är stabil.
Säg inte upp det gamla avtalet innan ni har loggar och säkerhetskopior i er hand. Med avtalets slut kan data hos leverantören raderas som ni behöver för försäkringsbolag, myndigheter eller den egna utredningen.
Vad ni inte bör ta med
Det vore bekvämt att helt enkelt kopiera hela webbkatalogen eller en avbild av servern. Just det är riskabelt efter en incident. Webbshells förklär sig som harmlösa filer, bakdörrar gömmer sig i konfigurationsfiler som .htaccess eller .user.ini, och insmugglad kod kan ligga i databasinnehåll.
För därför över applikationskoden från en ren källa, till exempel tillverkarens paket i rätt version eller ert versionshanteringssystem. Mediafiler tar ni över utan körbara filer, databasen efter en kontroll av avvikande innehåll och nya administratörskonton. Det som hittades på det gamla systemet hjälper vid den kontrollen.
Tänk också på allt som ligger hos den gamla leverantören vid sidan av webbplatsen. E-postlådor, DNS-poster, certifikat och vidarebefordringar glöms lätt bort vid flytten. Sänk giltighetstiden för DNS-posterna några dagar före omläggningen, så att ändringen snabbt når besökarna. Flyttar e-posten också, planera bytet av postlådor separat, för även där kan inloggningsuppgifter vara berörda efter en incident.
Välj den nya hostern efter säkerhet
Pris och lagringsutrymme står i varje offert. De avgörande säkerhetsfrågorna måste ni oftast ställa själva. Listan nedan hjälper vid jämförelsen:
| Kriterium | Fråga till leverantören | Varför det spelar roll |
|---|---|---|
| Patchrutin | Hur och inom vilken ram installeras och startas PHP-säkerhetsuppdateringar om? | PHP2Shell har visat hur viktig en styrkbar rutin är |
| Bevis | Får jag på begäran en skriftlig bekräftelse av patchnivån? | Underlag för er egen dokumentation |
| PHP-versioner | Vilka grenar erbjuds, och hur länge till? | Gamla grenar utan uppdateringar är en permanent risk |
| Åtskillnad | Körs varje webbplats med egen användare och egen PHP-process? | Begränsar skadan om en granne angrips |
| Loggar | Har jag tillgång till åtkomst- och felloggar, och hur länge sparas de? | Utan loggar ingen utredning |
| Säkerhetskopior | Hur ofta, hur länge, åtskilda från webbservern, med återställningstest? | Återställning efter en incident |
| Nödkontakt | Hur når jag en sakkunnig person vid en incident? | Tid är den knappaste faktorn i skarpt läge |
| Personuppgiftsbiträde | Finns det ett avtal enligt GDPR och en lista över underbiträden? | Krav vid personuppgifter |
En mall för frågan om patchnivån finns i guiden Fråga hostern om patchstatus. Den lämpar sig också för att jämföra leverantörer före avtalet.
Är en annan driftmodell det bättre svaret?
Ibland ligger problemet mindre hos hostern än hos driftmodellen. Den som driver en egen server utan regelbunden skötsel har ofta mer nytta av ett välskött managed-erbjudande. Omvänt kan ett företag med egen IT få mer kontroll över patchtidpunkter genom att själv sköta driften. Avvägningen beskrivs i inlägget Managed hosting eller egen server?.
Oavsett modell gäller: dokumentera ansvarsfördelningen skriftligt. Vem installerar PHP-uppdateringarna, vem startar om, vem kontrollerar applikationen, vem kontaktar vem i en nödsituation? Vid PHP2Shell uppstod många förseningar just här, eftersom varje sida trodde att den andra tog hand om det.
Hur hjälper PHP SOS konkret?
- Vi säkrar loggar och data från det gamla systemet och klarlägger vad som hänt vid incidenten.
- Vi bygger det nya systemet härdat och för bara över granskat innehåll från rena källor.
- Vi granskar nya leverantörers erbjudanden utifrån säkerhetskriterierna och ställer rätt frågor.
- Vid en pågående incident arbetar vi inom ramen för vår incidenthantering (Incident Response) tills incidenten är avslutad och dokumenterad.
Vanliga frågor
Bör jag byta hostingleverantör direkt efter ett intrång?
Inte direkt. Först måste spår säkras, incidenten avgränsas och orsaken klarläggas. En förhastad flytt tar kanske med sig skadlig kod och kan förstöra bevis hos den gamla leverantören.
Var hostern skyldig om min webbplats angreps via PHP2Shell?
Det beror på avtalet och tidpunkten. Vid delad hosting ansvarar oftast hostern för PHP-uppdateringarna, vid egna servrar driftansvarig. Patcharna kom den 21 oktober 2026; om och när de installerades går bara att klarlägga med underlag. För ansvarsfrågor bör ni ta juridisk rådgivning.
Vilka data får jag ta med till den nya hostern?
Bara granskat innehåll: databasen efter kontroll av insmugglad kod, mediafiler utan körbara filer och kod från en ren källa, som tillverkarens paket eller ert versionshanteringssystem. Kompletta serveravbilder eller webbkataloger från det komprometterade systemet bör ni inte föra över ogranskade.
Måste jag involvera dataskyddet efter en incident?
Om personuppgifter kan vara berörda kan det finnas en anmälningsskyldighet enligt GDPR, i regel inom 72 timmar. Hos den nya hostern behöver ni dessutom ett personuppgiftsbiträdesavtal. Klargör det med ert dataskyddsombud; detta är ingen juridisk rådgivning.