TYPO3, SPIP ou CMS oublié : le piratage des sites « qui tournaient encore »
TYPO3, SPIP, Drupal 7, Joomla 3, un CMS d'agence de 2012 : pas de mises à jour, prestataire parti, PHP ancien. L'entrée est banale. Le coût, c'est la reconstruction d'un métier non documenté. Copiez avant toute bravoure. Éteindre n'est pas un échec ; tout réécrire le soir de l'alerte, si.
Pas de mises à jour, prestataire parti, PHP ancien. L'entrée est banale. Le coût est la reconstruction du métier non documenté. Copiez avant toute bravoure.
« Ça tournait encore » n'est pas une stratégie
Un site que personne n'ouvre depuis trois ans peut encore répondre 200. Les bots, eux, l'ouvrent. Une faille publique sur une version figée suffit. Le propriétaire découvre l'incident via un mail d'abus ou un client : « votre page renvoie vers un casino ».
La honte de « ne pas avoir mis à jour » n'aide pas. Beaucoup de ces CMS n'ont plus de chemin de maj simple, ou plus de prestataire. L'enjeu n'est pas la culpabilité. C'est : copie, coupure des accès, décision métier (on éteint / on migre / on nettoie pour tenir six mois).
Premiers gestes s'appliquent. Réinstaller « un WordPress à la place » le dimanche sans copie perd formulaires, archives PDF, règles métier. Site piraté et refonte.
SPIP, TYPO3 et les autres : des familles, un même protocole
SPIP : squelettes, plugins, dossier `IMG`, parfois un vieux PHP. TYPO3 : extensions TER abandonnées, `fileadmin`, backend admin. Drupal 7 / Joomla 3 : voir Drupal et Joomla. CMS d'agence fermée : traitez-le comme un site PHP sur mesure.
On ne publie pas d'exploits par version. On dit : inventaire des paquets, comptes admin, dossiers médias, cron, configs. Le nom du CMS change les chemins, pas l'ordre.
Un « plugin de sécurité WordPress » n'a rien à faire ici. Un WAF après nettoyage, si. WAF.
Copier avant de moderniser
Fichiers + base, hors compte. C'est votre seule documentation si le prestataire a disparu. L'archive hébergeur du jour de la suspension est déjà sale : preuve, pas restauration. Archive sale.
Les journaux partent dans le même sac. Une réinstall « pour se rassurer » les détruit — y compris pour une éventuelle fuite (adhérents, usagers, école).
Exportez les contenus visibles (pages, PDF) même imparfaitement. Le jour où vous éteignez le PHP, ces exports sont le site.
- Zip + dump hors serveur.
- Liste des URLs importantes (même à la main).
- Captures de l'admin s'il ouvre encore.
Où l'entrée est généralement banale
Mot de passe admin ou FTP réutilisé, plugin/extension morte, upload dans les médias, voisin de compte, panel forcé. Rarement « une attaque sophistiquée contre TYPO3 ». Souvent le même bot que pour WordPress, un autre chemin.
PHP 5.6 / 7.0 encore proposé par un hébergeur « parce que le site casse sinon » : surface connue. Le correctif n'est pas de publier un PoC. C'est de sortir de cette version après copie, ou d'éteindre.
Minage : CPU, facture, suspension. Fréquent sur les sites oubliés. Cryptominage. Rançon plus rare, même protocole : ne pas payer. Rançongiciel.
Le prestataire a disparu : qui a les accès
Panel, FTP, admin CMS, registrar, Search Console : souvent dans une boîte mail personnelle du développeur. Prestataire disparu. L'hébergeur peut réinitialiser le panel du contrat (pièce d'identité, titulaire). Commencez là.
Ne menacez pas le support. Ticket factuel, titulaire, adresse perso. Guide suspension.
Un freelance qui « a encore les accès » après dix ans : révoquez après copie. Ancien développeur.
PHP ancien, isolation, voisin de compte
Le CMS oublié est souvent le quinzième vhost du cPanel. Il sert de rampe vers les configs des sites vivants. Isolation. La décision utile est parfois : éteindre celui-là pour sauver la boutique d'à côté.
open_basedir, comptes séparés : demandez à l'hébergeur. Si c'est impossible, changer d'hébergement après nettoyage des sites que vous gardez.
Réputation IP si le vieux site a spammé. Réputation IP.
Décider : éteindre, migrer, ou tenir un peu
Éteindre : vhost coupé, dossier hors web, domaine en page statique ou redirection 301 vers un successeur. Honnête quand plus personne ne met à jour le métier.
Tenir un peu : nettoyage, PHP médias interdit, moins d'admins, WAF, surveillance trente jours — en sachant que la dette reste. Utile le temps d'un marché public ou d'une saison.
Migrer : projet. Pas le soir de l'incident. Contenu d'abord (export), puis nouveau socle. Coût réel : la refonte était déjà due ; l'incident en fixe la date.
Constat, hébergeur, données
Adhérents, usagers, école, mairie : le CMS oublié a parfois une table. Le constat décide d'informer. Association, mairie, école, avocat / médecin.
Joindre au ticket : motif, chemins, date, décision (éteint / nettoyé). Pas « on va refaire un WordPress la semaine prochaine » comme seul plan — l'hébergeur veut la cause actuelle traitée. Créer un compte pour un écrit technique.
Choisir qui migre ensuite n'est pas le même devis que le nettoyage. Prestataire de nettoyage. Melanger les deux le soir de l'alerte Chrome perd des règles métier que plus personne ne sait recoder.
Joindre au ticket : motif, chemins, décision (éteint / nettoyé / tenu six mois). Pas « on va refaire un WordPress la semaine prochaine » comme seul plan — l'hébergeur veut la cause actuelle traitée.
Le métier non documenté : le vrai coût
Formulaires d'inscription, exports PDF, unsystème de badges, un calendrier collé à une asso : ça n'est dans aucun README. D'où copier avant d'éteindre ou de « moderniser ». Le coût réel de ces sites, c'est souvent la reconstruction, pas le forfait malware. L'incident fixe une date qui était déjà due.
PHP ancien « parce que ça casse sinon » : testez le saut sur copie, pas en prod le soir J. Si plus personne ne sait corriger, c'est un argument pour éteindre. Site PHP. Maj sans casser.
Voisin de compte : le CMS oublié est souvent le quinzième vhost. Éteignez-le pour sauver la boutique d'à côté. Isolation. Créer un compte. Prestataire parti : panel du titulaire d'abord. Prestataire disparu.