En bref : changer de CMS après un piratage n'aide que si l'ancien système lui-même était la cause, par exemple parce que l'éditeur ne fournit plus de mises à jour de sécurité ou que des extensions importantes ne sont plus entretenues. Si la cause résidait dans des extensions obsolètes, des accès faibles ou une faille comme PHP2Shell dans le PHP sous-jacent, un changement ne fait que déplacer l'effort. Dans tous les cas : vérifier les contenus d'abord, migrer ensuite, sinon le code malveillant suit.
Quand la confiance a disparu
Après une intrusion, l'humeur est souvent sans équivoque : « Plus jamais avec ce système. » C'est compréhensible. Le site a redirigé des visiteurs vers des sites étrangers, Google a lancé un avertissement, des clients ont posé des questions. Un nouveau CMS a l'air d'un nouveau départ.
La situation autour de PHP2Shell montre toutefois pourquoi ce réflexe peut égarer. La faille se trouve dans l'interpréteur PHP, pas dans WordPress, TYPO3, Shopware ou un autre système. Selon drweb.de, WordPress.org ne prévoit donc pas de mise à jour propre contre elle. Celui qui passe maintenant d'un CMS PHP à un autre CMS PHP a au final la même dépendance, seulement avec un autre logo. Quels systèmes tournent sur PHP, l'aperçu Quels CMS et systèmes de boutique tournent sur PHP le montre.
Ce que décide la cause
Avant de songer à un changement, la cause de l'intrusion doit être clarifiée. Les portes d'entrée typiques sont des extensions obsolètes, des mots de passe réutilisés ou faibles, l'absence d'authentification à deux facteurs, un serveur non corrigé ou des installations de test oubliées. Aucune de ces causes n'est liée à un CMS particulier.
Celui qui ne connaît pas la cause risque de l'emporter dans le nouveau système. Une équipe qui a jusqu'ici repoussé les mises à jour le fera tout autant dans le nouveau CMS. Une agence qui utilisait des comptes administrateur partagés recommencera si personne ne change la procédure. La question est donc moins « quel CMS ? » que « quel processus ? ».
Changer de CMS après le piratage : la pesée
| Critère | Rester sur le CMS existant et le durcir | Passer à un autre CMS |
|---|---|---|
| Cause de l'intrusion | Connue et corrigeable, par exemple extension obsolète | Réside dans le système lui-même, par exemple mises à jour de l'éditeur manquantes |
| Entretien par l'éditeur | Des mises à jour de sécurité sont fournies | L'éditeur a cessé l'entretien |
| Dépendance aux extensions | Peu d'extensions, entretenues | Nombreuses extensions sans entretien actif |
| Effort | Nettoyage, durcissement, changement de processus | Reconstruction, migration, formation, souvent refonte |
| Temps jusqu'à un site sûr | Plus court | Plus long, solution transitoire nécessaire |
| Protection contre les failles PHP | Aucun changement, PHP doit être corrigé | Aucun changement, tant que le nouveau système utilise PHP |
| Bénéfice à long terme | Élevé, si les processus sont améliorés | Élevé, si l'ancien système était de toute façon en fin de vie |
Si, dans votre situation, la plupart des lignes tombent à gauche, le changement ne vaut guère la peine. Rester, nettoyer, durcir et améliorer la procédure de maintenance apporte plus de sécurité pour moins d'argent. Pour les exploitants de WordPress, WordPress et PHP2Shell résume les étapes les plus importantes.
Vous n'avez pas toujours besoin d'un prestataire pour cette décision. Si la cause était claire, par exemple une extension connue avec une faille publiée, et que votre agence ou votre admin a proprement réinstallé le site, vous pouvez décider vous-même. Une aide externe vaut la peine si la cause reste incertaine ou si des données personnelles pourraient être concernées.
Si vous changez : ne pas emporter le code malveillant
Si la décision de changer est prise, la migration elle-même est un risque de sécurité. Les attaquants laissent des traces non seulement dans les fichiers, mais aussi dans la base de données. Ces étapes aident à migrer proprement :
- Sauvegarder et isoler l'ancien système : sauvegarde complète comme preuve, puis retirer l'ancien système du réseau ou ne le rendre accessible qu'en interne.
- Exporter les contenus de façon ciblée : textes, structure des pages et médias, pas la base de données complète. Ne pas reprendre les comptes utilisateurs, mais les recréer.
- Vérifier les contenus : passer en revue les textes pour y repérer des scripts injectés, des liens cachés et des redirections étrangères. La manière de faire est décrite dans Vérifier la base de données à la recherche de code injecté.
- Filtrer les médias : ne reprendre que les types de fichiers attendus, écarter les fichiers à double extension ou au contenu de script.
- Installer proprement le nouveau système : à partir de la source d'origine de l'éditeur, sur un serveur avec PHP corrigé, avec de nouveaux identifiants et l'authentification à deux facteurs.
- Planifier les redirections : rediriger les anciennes adresses vers les nouvelles, pour que moteurs de recherche et visiteurs arrivent à destination, sans que d'anciens chemins restent ouverts.
Un changement de CMS ne remplace pas le nettoyage de l'ancien serveur. Si l'ancien système continue de tourner, par exemple comme copie oubliée sous un sous-domaine, la porte dérobée reste ouverte.
L'alternative souvent négligée
Certaines entreprises constatent après un piratage qu'elles n'ont en réalité pas besoin des fonctions d'un grand CMS. Un site d'entreprise de quelques pages, rarement modifiées, se passe aussi de PHP sur le serveur. Un générateur de pages statiques produit des fichiers HTML finis qui n'ont plus besoin de logique de programme côté serveur. Les avantages et inconvénients sont décrits dans Sites statiques : moins de PHP, moins de surface d'attaque.
À l'inverse, ce n'est le plus souvent pas une option pour les boutiques, les portails ou les sites avec de nombreux rédacteurs. Un système dynamique reste alors judicieux, et la sécurité naît de l'entretien, du durcissement et de la surveillance.
Celui qui hésite à savoir si des accès cachés rôdent encore dans l'ancien WordPress trouvera dans Trouver des portes dérobées dans WordPress les endroits typiques. Cela aide aussi à décider si un nettoyage est réaliste.
Comment PHP SOS aide-t-il concrètement ?
- Nous clarifions d'abord la cause de l'intrusion et vous disons si elle tient au CMS ou au processus et au serveur.
- Nous nettoyons le système existant dans le cadre de la suppression des logiciels malveillants ou le préparons comme preuve pour une reconstruction.
- En cas de changement, nous vérifions les contenus et médias à reprendre pour y détecter du code malveillant avant qu'ils n'arrivent dans le nouveau système.
- Nous installons le nouveau serveur avec PHP corrigé et une configuration durcie.
Conclusion
Un changement de CMS après un piratage est rarement la solution, mais parfois la bonne occasion. Si l'ancien système n'est plus entretenu, le nouveau départ vaut la peine. Si la cause résidait dans les processus ou le serveur, le travail sur le processus apporte plus qu'un nouveau logo. Dans les deux cas : vérifier d'abord, migrer ensuite.
Questions fréquentes
Un changement de CMS aide-t-il contre PHP2Shell ?
Non, tant que le nouveau CMS tourne lui aussi sur PHP. PHP2Shell se trouve dans l'interpréteur PHP, pas dans le CMS. Ce qui est déterminant, c'est l'état des correctifs de PHP sur le serveur, pas le système qui se trouve au-dessus.
WordPress est-il moins sûr que d'autres CMS ?
On ne peut pas le dire de façon générale. De nombreuses intrusions naissent d'extensions obsolètes, d'accès faibles ou de mises à jour manquantes, et ces causes existent dans tous les systèmes. Sa diffusion fait toutefois d'un CMS une cible plus fréquente des scans automatisés.
Puis-je simplement exporter les contenus du CMS piraté ?
Seulement après vérification. La base de données peut contenir des scripts injectés, des liens cachés ou des comptes administrateur étrangers. Les fichiers téléversés peuvent dissimuler du code malveillant. Exportez les contenus de façon ciblée et vérifiez-les avant l'import.
Quand un changement de CMS est-il vraiment judicieux ?
Quand l'éditeur ne fournit plus de mises à jour de sécurité, quand le site dépend d'extensions qui ne sont plus entretenues, ou quand le système ne correspond tout simplement plus aux besoins actuels. Le piratage est alors l'occasion, pas la raison.