Kort gezegd: Het CMS wisselen na een hack helpt alleen als het oude systeem zelf de oorzaak was, bijvoorbeeld omdat de fabrikant geen beveiligingsupdates meer levert of belangrijke extensies niet meer worden onderhouden. Lag de oorzaak bij verouderde plug-ins, zwakke toegangen of een lek zoals PHP2Shell in de onderliggende PHP, dan verschuift een wissel alleen het werk. In elk geval geldt: inhoud eerst controleren, dan verhuizen, anders verhuist de schadelijke code mee.
Als het vertrouwen weg is
Na een inbraak is de stemming vaak duidelijk: „met dit systeem nooit meer.“ Dat is begrijpelijk. De website heeft bezoekers naar vreemde sites doorverwezen, Google heeft gewaarschuwd, klanten hebben nagevraagd. Een nieuw CMS voelt als een nieuwe start.
De situatie rond PHP2Shell laat echter zien waarom deze reflex op een dwaalspoor kan leiden. Het lek zit in de PHP-interpreter, niet in WordPress, TYPO3, Shopware of een ander systeem. WordPress.org plant volgens drweb.de daarom geen eigen update ertegen. Wie nu van het ene PHP-CMS naar het andere PHP-CMS wisselt, heeft aan het eind dezelfde afhankelijkheid, alleen met een ander logo. Welke systemen op PHP draaien, toont het overzicht Welke CMS- en shopsystemen op PHP draaien.
Wat de oorzaak was, beslist
Voordat u over een wissel nadenkt, moet de oorzaak van de inbraak zijn opgehelderd. Typische toegangspoorten zijn verouderde extensies, meervoudig gebruikte of zwakke wachtwoorden, ontbrekende tweefactorauthenticatie, een niet-gepatchte server of vergeten testinstallaties. Geen van deze oorzaken is aan een bepaald CMS gebonden.
Wie de oorzaak niet kent, riskeert haar mee te nemen naar het nieuwe systeem. Een team dat updates tot nu toe uitstelde, zal dat in het nieuwe CMS evengoed doen. Een bureau dat gemeenschappelijke beheerdersaccounts gebruikte, zal dat herhalen als niemand het proces wijzigt. De vraag is dus minder „welk CMS?“ dan „welk proces?“.
CMS wisselen na de hack: de afweging
| Criterium | Bij het bestaande CMS blijven en verharden | Naar een ander CMS wisselen |
|---|---|---|
| Oorzaak van de inbraak | Bekend en te verhelpen, bijv. verouderde plug-in | Ligt in het systeem zelf, bijv. ontbrekende fabrikantupdates |
| Onderhoud door de fabrikant | Beveiligingsupdates worden geleverd | Fabrikant heeft het onderhoud gestaakt |
| Afhankelijkheid van extensies | Weinig, onderhouden extensies | Veel extensies zonder actief onderhoud |
| Inspanning | Opschoning, verharding, procesverandering | Wederopbouw, migratie, training, vaak herontwerp |
| Tijd tot een veilige website | Korter | Langer, overbruggingsoplossing nodig |
| Bescherming tegen PHP-lekken | Geen verandering, PHP moet worden gepatcht | Geen verandering, zolang het nieuwe systeem PHP gebruikt |
| Langetermijnnut | Hoog, als processen worden verbeterd | Hoog, als het oude systeem toch al aan zijn eind was |
Als in uw situatie de meeste regels links uitkomen, loont de wissel nauwelijks. Blijven, opschonen, verharden en het onderhoudsproces verbeteren levert meer veiligheid op voor minder geld. Voor WordPress-beheerders vat WordPress en PHP2Shell de belangrijkste stappen samen.
Voor deze beslissing hebt u niet altijd een dienstverlener nodig. Was de oorzaak eenduidig, bijvoorbeeld een bekende plug-in met gepubliceerd lek, en heeft uw bureau of beheerder de website netjes opnieuw opgezet, dan kunt u zelf beslissen. Externe hulp loont als de oorzaak onduidelijk blijft of persoonsgegevens getroffen kunnen zijn.
Als u wisselt: de schadelijke code niet meenemen
Valt de beslissing voor een wissel, dan is de migratie zelf een beveiligingsrisico. Aanvallers laten sporen achter niet alleen in bestanden, maar ook in de database. Deze stappen helpen netjes te verhuizen:
- Oud systeem veiligstellen en isoleren: volledige back-up als bewijs, daarna het oude systeem van het netwerk halen of alleen nog intern bereikbaar maken.
- Inhoud gericht exporteren: teksten, paginastructuur en media, niet de complete database. Gebruikersaccounts niet overnemen, maar opnieuw aanmaken.
- Inhoud controleren: teksten doorzoeken op ingebrachte scripts, verborgen links en vreemde doorverwijzingen. Hoe dat gaat, beschrijft De database controleren op ingebrachte code.
- Media filteren: alleen verwachte bestandstypen overnemen, bestanden met dubbele extensies of scriptinhoud uitsluiten.
- Nieuw systeem schoon opzetten: vanuit de oorspronkelijke bron van de fabrikant, op een server met gepatchte PHP, met nieuwe inloggegevens en tweefactorauthenticatie.
- Doorverwijzingen plannen: oude adressen naar nieuwe omleiden, zodat zoekmachines en bezoekers aankomen, zonder dat oude paden open blijven.
Een CMS-wissel vervangt de opschoning van de oude server niet. Draait het oude systeem door, bijvoorbeeld als vergeten kopie onder een subdomein, dan blijft de achterdeur open.
Het alternatief dat vaak wordt gemist
Sommige bedrijven stellen na een hack vast dat ze de functies van een groot CMS helemaal niet nodig hebben. Een bedrijfswebsite met weinig pagina's die zelden verandert, komt ook zonder PHP op de server toe. Een generator voor statische pagina's maakt kant-en-klare HTML-bestanden die geen programmalogica aan serverzijde meer vragen. Welke voor- en nadelen dat heeft, beschrijft Statische websites: minder PHP, minder aanvalsoppervlak.
Omgekeerd is dat voor shops, portalen of websites met veel redacteuren meestal geen optie. Hier blijft een dynamisch systeem zinvol, en de veiligheid ontstaat door onderhoud, verharding en bewaking.
Wie onzeker is of in de oude WordPress nog verborgen toegangen schuilen, vindt in Backdoors in WordPress vinden de typische vindplaatsen. Dat helpt ook bij de beslissing of een opschoning realistisch is.
Hoe helpt PHP SOS concreet?
- Wij stellen eerst de oorzaak van de inbraak vast en zeggen u of ze bij het CMS ligt of bij proces en server.
- Wij schonen het bestaande systeem op in het kader van de malwareverwijdering of bereiden het als bewijs voor een wederopbouw voor.
- Bij een wissel controleren wij de over te nemen inhoud en media op schadelijke code voordat ze in het nieuwe systeem terechtkomen.
- Wij zetten de nieuwe server op met gepatchte PHP en verharde configuratie.
Conclusie
Een CMS-wissel na een hack is zelden de oplossing, maar soms de juiste aanleiding. Als het oude systeem niet meer wordt onderhouden, loont de nieuwe start. Als de oorzaak in processen of op de server lag, levert werken aan het proces meer op dan een nieuw logo. In beide gevallen geldt: eerst controleren, dan verhuizen.
Veelgestelde vragen
Helpt een CMS-wissel tegen PHP2Shell?
Nee, zolang het nieuwe CMS ook op PHP draait. PHP2Shell zit in de PHP-interpreter, niet in het CMS. Beslissend is de patchstatus van PHP op de server, niet het systeem erboven.
Is WordPress onveiliger dan andere CMS?
Dat is niet algemeen te zeggen. Veel inbraken ontstaan door verouderde extensies, zwakke toegangen of ontbrekende updates, en die oorzaken bestaan in elk systeem. De verspreiding maakt een CMS wel tot een vaker voorkomend doelwit van geautomatiseerde scans.
Kan ik inhoud uit het gehackte CMS gewoon exporteren?
Alleen na controle. De database kan ingebrachte scripts, verborgen links of vreemde beheerdersaccounts bevatten. Geüploade bestanden kunnen schadelijke code camoufleren. Exporteer inhoud gericht en controleer haar vóór het importeren.
Wanneer is een CMS-wissel echt zinvol?
Als de fabrikant geen beveiligingsupdates meer levert, als de website afhankelijk is van extensies die niet meer worden onderhouden of als het systeem voor de huidige eisen eenvoudigweg niet meer past. De hack is dan de aanleiding, niet de reden.