Kort sagt: Att byta CMS efter ett hack hjälper bara om det gamla systemet självt var orsaken, till exempel för att tillverkaren inte längre levererar säkerhetsuppdateringar eller viktiga utökningar inte längre underhålls. Låg orsaken i föråldrade tillägg, svaga åtkomster eller en lucka som PHP2Shell i det underliggande PHP, flyttar ett byte bara arbetet. I varje fall gäller: Granska innehållet först, flytta sedan, annars följer den skadliga koden med.
När förtroendet är borta
Efter ett intrång är stämningen ofta entydig: ”Aldrig mer med det här systemet.” Det är begripligt. Webbplatsen har omdirigerat besökare till främmande sidor, Google har varnat, kunder har frågat. Ett nytt CMS känns som en nystart.
Läget kring PHP2Shell visar dock varför den reflexen kan leda fel. Luckan sitter i PHP-tolken, inte i WordPress, TYPO3, Shopware eller något annat system. WordPress.org planerar enligt drweb.de därför ingen egen uppdatering mot den. Den som nu byter från ett PHP-CMS till ett annat PHP-CMS har till slut samma beroende, bara med en annan logotyp. Vilka system som körs på PHP visar översikten Vilka CMS och webbshopsystem som körs på PHP.
Vad orsaken var avgör
Innan ni funderar på ett byte måste intrångets orsak vara klarlagd. Typiska ingångar är föråldrade utökningar, återanvända eller svaga lösenord, saknad tvåfaktorsinloggning, en opatchad server eller bortglömda testinstallationer. Ingen av dessa orsaker är knuten till ett visst CMS.
Den som inte känner orsaken riskerar att ta med den in i det nya systemet. Ett team som hittills har skjutit upp uppdateringar kommer att göra likadant i det nya CMS:et. En byrå som använde gemensamma administratörskonton upprepar det om ingen ändrar förloppet. Frågan är alltså mindre ”vilket CMS?” och mer ”vilken process?”.
Byta CMS efter hacket: avvägningen
| Kriterium | Stanna kvar vid det befintliga CMS:et och härda | Byta till ett annat CMS |
|---|---|---|
| Intrångets orsak | Känd och åtgärdbar, till exempel ett föråldrat tillägg | Ligger i systemet självt, till exempel saknade tillverkaruppdateringar |
| Tillverkarens underhåll | Säkerhetsuppdateringar levereras | Tillverkaren har upphört med underhållet |
| Beroende av utökningar | Få, underhållna utökningar | Många utökningar utan aktivt underhåll |
| Arbetsinsats | Sanering, härdning, processändring | Nybyggnad, migrering, utbildning, ofta ny design |
| Tid till en säker webbplats | Kortare | Längre, övergångslösning behövs |
| Skydd mot PHP-luckor | Ingen förändring, PHP måste patchas | Ingen förändring, så länge det nya systemet använder PHP |
| Långsiktig nytta | Hög, om processerna förbättras | Hög, om det gamla systemet ändå var förbrukat |
Om de flesta raderna i ert läge hamnar till vänster lönar sig bytet knappast. Att stanna kvar, sanera, härda och förbättra underhållsförloppet ger mer säkerhet för mindre pengar. För WordPress-ansvariga sammanfattar WordPress och PHP2Shell de viktigaste stegen.
En leverantör behöver ni inte alltid för det här beslutet. Var orsaken entydig, till exempel ett känt tillägg med publicerad lucka, och har er byrå eller administratör satt upp webbplatsen på nytt på ett rent sätt kan ni besluta själva. Extern hjälp lönar sig om orsaken förblir oklar eller personuppgifter kan vara berörda.
Om ni byter: ta inte med den skadliga koden
Faller beslutet på ett byte är migreringen själv en säkerhetsrisk. Angripare lämnar spår inte bara i filer utan också i databasen. Dessa steg hjälper till att flytta rent:
- Säkra och isolera det gamla systemet: Fullständig säkerhetskopia som bevis, ta sedan det gamla systemet från nätet eller gör det bara nåbart internt.
- Exportera innehåll riktat: Texter, sidstruktur och media, inte hela databasen. Ta inte över användarkonton utan skapa dem på nytt.
- Granska innehållet: Gå igenom texter efter insmugglade skript, dolda länkar och främmande omdirigeringar. Hur det går till beskriver Granska databasen efter insmugglad kod.
- Filtrera media: Ta bara över förväntade filtyper, sortera bort filer med dubbla ändelser eller skriptinnehåll.
- Sätt upp det nya systemet rent: Från tillverkarens originalkälla, på en server med patchad PHP, med nya inloggningsuppgifter och tvåfaktorsinloggning.
- Planera omdirigeringar: Led gamla adresser till nya så att sökmotorer och besökare kommer fram, utan att gamla sökvägar förblir öppna.
Ett CMS-byte ersätter inte en sanering av den gamla servern. Fortsätter det gamla systemet att köras, till exempel som en bortglömd kopia under en underdomän, förblir bakdörren öppen.
Alternativet som ofta förbises
Vissa företag konstaterar efter ett hack att de inte alls behöver funktionerna i ett stort CMS. En företagswebbplats med några få sidor som sällan ändras klarar sig även utan PHP på servern. En generator för statiska sidor skapar färdiga HTML-filer som inte längre behöver någon serverside-programlogik. Vilka för- och nackdelar det har beskriver Statiska webbplatser: mindre PHP, mindre angreppsyta.
Omvänt är det för webbshoppar, portaler eller webbplatser med många redaktörer oftast inget alternativ. Där förblir ett dynamiskt system rimligt, och säkerheten uppstår genom underhåll, härdning och övervakning.
Den som är osäker på om det i den gamla WordPress-installationen fortfarande lurar dolda åtkomster hittar i Hitta bakdörrar i WordPress de typiska fyndplatserna. Det hjälper också vid beslutet om en sanering är realistisk.
Hur hjälper PHP SOS konkret?
- Vi klargör först intrångets orsak och talar om för er om den ligger i CMS:et eller i process och server.
- Vi saniterar det befintliga systemet inom ramen för skadeprogramsborttagning eller förbereder det som bevis för en ombyggnad.
- Vid ett byte granskar vi innehåll och media som ska tas över med avseende på skadlig kod innan de hamnar i det nya systemet.
- Vi sätter upp den nya servern med patchad PHP och härdad konfiguration.
Slutsats
Ett CMS-byte efter ett hack är sällan lösningen men ibland rätt tillfälle. Om det gamla systemet inte längre underhålls lönar sig nystarten. Om orsaken låg i processer eller i servern ger arbetet med processen mer än en ny logotyp. I båda fallen gäller: Granska först, flytta sedan.
Vanliga frågor
Hjälper ett CMS-byte mot PHP2Shell?
Nej, så länge det nya CMS:et också körs på PHP. PHP2Shell sitter i PHP-tolken, inte i CMS:et. Avgörande är PHP:s patchstatus på servern, inte systemet ovanpå.
Är WordPress osäkrare än andra CMS?
Det går inte att säga generellt. Många intrång uppstår genom föråldrade utökningar, svaga åtkomster eller saknade uppdateringar, och dessa orsaker finns i varje system. Utbredningen gör dock ett CMS till ett vanligare mål för automatiserade skanningar.
Kan jag bara exportera innehåll från det hackade CMS:et?
Bara efter kontroll. Databasen kan innehålla insmugglade skript, dolda länkar eller främmande administratörskonton. Uppladdade filer kan maskera skadlig kod. Exportera innehåll riktat och kontrollera det före importen.
När är ett CMS-byte verkligen rimligt?
När tillverkaren inte längre levererar säkerhetsuppdateringar, när webbplatsen är beroende av utökningar som inte längre underhålls eller när systemet helt enkelt inte längre passar dagens krav. Hacket är då tillfället, inte skälet.