Quand un WordPress vient d’être piraté, on pense spontanément au thème, aux plugins, à la base de données. C’est logique, mais souvent incomplet. Une partie des attaques les plus tenaces s’entretient grâce à l’accès direct au serveur, via FTP ou SSH. Tant que ces portes restent compromises, vous pouvez restaurer autant de sauvegardes que vous voulez, l’attaquant finira par revenir.
Ce texte se concentre sur ce point précis : comment réagir en urgence face à un WordPress piraté en vérifiant et en nettoyant toutes les entrées FTP et SSH. L’objectif n’est pas seulement de « réparer » le site, mais de reprendre le contrôle de l’environnement serveur autour.
Pourquoi les comptes FTP et SSH sont une cible privilégiée
Un pirate qui obtient un accès FTP ou SSH sur votre hébergement vient, très concrètement, de devenir « vous » aux yeux du serveur. Il peut déposer du code, modifier des permissions, installer une porte dérobée, récupérer des sauvegardes complètes, voire utiliser votre hébergement pour attaquer d’autres serveurs.
Avec un simple accès FTP, un attaquant peut :
- Injecter des fichiers PHP malveillants n’importe où dans l’arborescence. Modifier un wp-config.php pour voler des identifiants de base de données. Déposer des scripts d’envoi de spam ou de phishing, souvent dans des sous-répertoires oubliés.
Avec un accès SSH, la marge d’action est encore plus large. Selon la configuration, il peut :
- Installer des outils persistants (backdoors, rootkits, miners). Modifier des tâches cron pour réinjecter du code malveillant régulièrement. Scanner l’ensemble du serveur et parfois d’autres comptes sur le même serveur, surtout sur des VPS mal configurés.
Dans beaucoup d’urgences « WordPress piraté », la faille initiale se situe au niveau applicatif (plugin vulnérable, thème non mis à jour) mais le maintien de l’accès se fait ensuite au niveau FTP ou SSH. C’est pour cela qu’un nettoyage WordPress qui ne passe pas par cet audit reste fragile.
Premier réflexe en cas d’urgence WordPress piraté
Sur les interventions que je vois passer, la chronologie fait la différence entre un incident grave mais maîtrisé et un cauchemar de plusieurs jours. La première heure est critique.
Voici une courte checklist immédiate, à exécuter dès les premiers signes de piratage, avant de se plonger dans le code :
Mettre le site en maintenance ou le couper temporairement pour limiter les dégâts visibles et l’impact SEO. Télécharger une copie des fichiers et de la base, même infectés, pour analyse ultérieure. Changer immédiatement les mots de passe d’accès au panel d’hébergement (cPanel, Plesk, interface maison). Désactiver ou limiter temporairement les connexions FTP classiques si l’hébergeur le permet. Noter l’heure exacte où vous avez détecté l’incident pour pouvoir recouper avec les logs plus tard.Cette séquence sert à deux choses : geler la situation et éviter que quelqu’un efface ses traces pendant que vous cherchez à comprendre.
Une fois ce premier filet de sécurité posé, vous pouvez attaquer le cœur du sujet : le tour complet des accès FTP et SSH.
Cartographier les accès avant de les modifier
Avant de commencer à supprimer ou modifier des comptes, il est utile de dresser une cartographie des accès qui existent réellement. Sur un environnement qui a vécu, il n’est pas rare de retrouver :
- Des comptes FTP laissés à une agence ou un freelance qui n’intervient plus. Des comptes créés pour un outil de déploiement, mais jamais documentés. Des comptes SSH personnels qui ne sont plus utilisés.
Pour éviter de casser un processus critique en supprimant aveuglément un compte, il est préférable de commencer par lister.
Selon l’hébergeur et le type d’offre, cette étape se fait dans l’interface d’administration (cPanel, Plesk, interface propriétaire) ou directement en SSH si vous avez un serveur dédié ou un VPS. Dans la plupart des panneaux mutualisés, vous trouverez une section « Comptes FTP » et une section « Accès SSH » ou « Shell ».
Notez, pour chaque compte :
- L’identifiant. Le répertoire de base (home directory). La date de dernière connexion si elle est indiquée. Le rôle supposé (accès principal, développeur, agence, automatisation).
Ne perdez pas de temps à être parfait à ce stade. Le but est d’avoir une vision claire des identifiants existants avant de commencer la purge.
Audit détaillé des comptes FTP
Sur des hébergements partagés, FTP reste souvent le principal vecteur d’accès. C’est aussi celui qui concentre les mauvaises pratiques : mots de passe très simples, comptes partagés par plusieurs personnes, aucun suivi.
Un audit FTP complet comprend plusieurs volets.
1. Identifier le ou les comptes FTP « maîtres »
Beaucoup d’hébergeurs créent un compte FTP principal lié au compte d’hébergement. C’est souvent celui qui a accès à toute l’arborescence, y compris d’autres sites si le même hébergement héberge plusieurs WordPress.
Ce compte doit être traité comme une clé maîtresse. Si ce compte est compromis, tous les sites sous ce même hébergement le sont potentiellement. Il est impératif de :
- Changer immédiatement son mot de passe, avec une vraie politique de complexité. Noter à qui ce mot de passe est communiqué. Si vous avez l’habitude de l’envoyer par mail à tout le monde, ce Piratage est l’occasion de revoir ces habitudes.
Si vous découvrez plusieurs comptes FTP ayant un accès à la racine, posez-vous la question de leur justification. Souvent, un seul compte maître bien sécurisé suffit.
2. Supprimer les comptes FTP inutiles ou douteux
En cas d’urgence WordPress piraté, la règle de base est simple : tout compte FTP non identifié est suspect.
Sur de nombreux cas, on retrouve des comptes au nom absurde créés par le pirate pour se ménager un accès persistant. Exemple typique : un compte backup_wp, testuser ou ftp01 rattaché à un sous-dossier qui semble anodin, mais qui contient une backdoor.
Rapprochez chaque compte FTP d’un usage réel. Si vous ne pouvez pas associer un compte à une personne, une fonction claire ou un contrat en cours, il vaut mieux le désactiver au moins temporairement. Sur certains panneaux, vous pouvez suspendre un compte sans le supprimer, ce qui permet de le réactiver si vous découvrez plus tard qu’il était légitime.
3. Restructurer les accès par projet
Une habitude qui réduit énormément l’impact d’un futur incident consiste à cloisonner les comptes FTP par site ou par répertoire.
Si votre hébergement contient plusieurs WordPress, créez un compte FTP distinct pour chaque projet, dont le répertoire de base se limite à ce site. Ainsi, si un identifiant est compromis, le pirate ne pourra pas basculer facilement d’un site à l’autre.
C’est aussi le moment de rompre avec les comptes partagés par toute une équipe. Mieux vaut un compte par personne, même si cela semble plus lourd à gérer. À partir du moment où vous avez déjà vécu un piratage, le gain en traçabilité compense largement cette légère complexité.
Audit des accès SSH : niveau supérieur de risque
L’accès SSH donne souvent davantage de pouvoir qu’un simple accès FTP, surtout sur des VPS ou des serveurs dédiés mal compartimentés. Sur des hébergements mutualisés, l’activation du SSH est parfois plus limitée, mais elle reste à vérifier.
1. Lister les utilisateurs ayant un accès shell
Sur un serveur que vous administrez vous-même, la commande getent passwd permet de lister les utilisateurs du système. Il faut ensuite identifier ceux qui ont un shell valide (/bin/bash, /bin/sh, /bin/zsh, etc.) Et non un shell restreint ou une valeur comme /usr/sbin/nologin.
Sur un panel type Plesk ou cPanel, vous aurez directement une section indiquant quels comptes disposent d’un accès SSH. Là encore, l’objectif est de rapprocher chaque compte d’une personne ou d’un usage.
Dans la pratique, on rencontre souvent :
- Un compte root ou équivalent. Un compte utilisateur principal, utilisé pour les déploiements. Des comptes créés pour des prestataires ponctuels, parfois oubliés depuis des années.
Les comptes historiques sont à traiter en priorité. Un ancien prestataire qui a gardé un accès SSH actif est un scénario que l’on retrouve encore trop souvent.
2. Passer en revue les clés SSH
Si des clés SSH sont utilisées pour l’authentification, il ne suffit pas de changer les mots de passe. Il faut examiner les fichiers authorized_keys des utilisateurs ayant un shell actif.
Sur un système Linux classique, chaque utilisateur dispose potentiellement d’un dossier .ssh dans son home. Le fichier authorized_keys liste les clés publiques autorisées. Recherchez :
- Les clés dont vous ne connaissez pas la provenance. Les commentaires douteux ou vides. Les clés présentant des options particulières, par exemple des commandes forcées.
Toute clé non identifiée doit être suspecte. Dans un contexte d’urgence, il est souvent plus simple de :
- Sauvegarder le fichier authorized_keys. Le vider. Réintroduire manuellement uniquement les clés que vous reconnaissez, au besoin en redemandant les clés à vos collaborateurs.
3. Vérifier les permissions et les groupes
Sur des environnements plus avancés, il arrive que des comptes SSH appartiennent à des groupes qui leur donnent des accès inattendus. Par exemple, un utilisateur censé ne gérer qu’un seul site a en réalité la capacité de lire les dossiers d’autres projets, voire d’exécuter sudo Visitez ce site sur certaines commandes.
Passez en revue les groupes d’appartenance des comptes les plus sensibles. Si vous trouvez des affiliations à des groupes système que vous ne comprenez pas, il vaut mieux investiguer avant de laisser passer.
Sur des hébergements mutualisés, cette partie est souvent verrouillée par l’hébergeur. Le minimum reste alors de vérifier que vous n’avez pas activé un accès SSH sur un compte qui n’en avait pas besoin.
Rotation massive des mots de passe : méthode efficace et réaliste
Lors d’une urgence WordPress piraté, l’envie de tout changer immédiatement est forte. Pourtant, une rotation massive et improvisée peut créer un chaos qui rend le travail plus difficile, surtout si plusieurs personnes interviennent.
Une méthode pragmatique consiste à procéder par cercles de confiance et par niveaux d’accès.
D’abord, changez les mots de passe des accès centraux : panel d’hébergement, compte FTP maître, accès SSH principaux. Utilisez des générateurs de mots de passe sérieux, avec une longueur d’au moins 16 caractères combinant lettres, chiffres et symboles si les systèmes le supportent. Documentez ces nouveaux mots de passe dans un gestionnaire chiffré partagé, plutôt qu’en clair dans un fichier ou un email.
Ensuite, faites le tour des comptes secondaires : comptes FTP limités à des sous-dossiers, utilisateurs SSH moins puissants, comptes SFTP spécifiques à des scripts d’automatisation. Pour ces comptes, posez-vous à chaque fois la question de leur utilité. Pour un grand nombre d’entre eux, la meilleure rotation de mot de passe reste la suppression pure et simple.
Enfin, une fois le site stabilisé et nettoyé, pensez à harmoniser la politique de mots de passe sur l’ensemble de l’organisation. Si un WordPress a été piraté parce que les identifiants FTP traînaient dans un fichier texte partagé sur un drive public, le problème dépasse largement la technique.
Exploiter les logs FTP et SSH pour comprendre et confirmer
Changer les accès est indispensable, mais comprendre ce qui s’est passé l’est tout autant. Sans cette compréhension, vous ne pouvez pas affirmer que l’incident est clos.
Les logs FTP et SSH donnent souvent des indications précieuses sur :
- Les plages d’adresses IP utilisées par l’attaquant. Les dates et heures précises des connexions suspectes. Les comptes utilisés lors des connexions.
Selon l’hébergeur, ces logs sont plus ou moins faciles à récupérer. Sur un VPS, vous aurez généralement accès à des fichiers comme /var/log/auth.log pour SSH, et des fichiers de logs spécifiques au serveur FTP (vsftpd, proftpd ou pure-ftpd).
Sur des hébergements mutualisés, l’interface d’administration propose parfois une section « Logs » où l’on peut télécharger les journaux FTP des derniers jours. Il faut faire vite : certains hébergeurs ne conservent que quelques jours de logs en cas de forte rotation.
En analysant ces journaux, cherchez par exemple :
- Des connexions FTP depuis des pays où personne dans votre équipe ne travaille. Des rafales de tentatives de connexion avortées juste avant un succès. Des connexions SSH en pleine nuit alors que vos équipes sont en Europe et travaillent aux heures de bureau.
Même si vous n’avez pas le temps de faire une analyse exhaustive durant la phase d’urgence, sauvegardez ces logs. Ils pourront servir plus tard à affiner votre compréhension de l’attaque et à adapter votre stratégie de défense.
Nettoyer les fichiers après avoir sécurisé les accès
Le réflexe courant consiste à commencer par supprimer les fichiers suspects dans wp-content ou à restaurer une sauvegarde. Si ce travail se fait alors que les accès FTP et SSH sont encore compromis, le nettoyage risque d’être contourné en quelques minutes.
La bonne séquence ressemble davantage à ceci : d’abord sécuriser les portes (FTP, SSH, panel d’hébergement), ensuite seulement lancer le nettoyage de WordPress.
Ce nettoyage peut prendre plusieurs formes :
- Comparer les fichiers du cœur de WordPress avec une version officielle. Re-télécharger les fichiers de WordPress et des plugins depuis des sources fiables. Examiner manuellement les répertoires wp-content/uploads, wp-content/mu-plugins, wp-includes pour y chercher des fichiers PHP inattendus.
L’important, du point de vue FTP/SSH, est de vérifier qu’après le nettoyage, aucune nouvelle injection n’apparaît dans les minutes ou heures qui suivent. Si des fichiers malveillants réapparaissent très vite, c’est souvent le signe qu’un accès serveur reste compromis, ou qu’une tâche cron malveillante s’exécute toujours.
Mettre en place des protections durables autour des accès serveur
Une crise de type « urgence WordPress piraté » peut servir de déclencheur pour renforcer durablement la sécurité des accès FTP et SSH.
Par expérience, quelques mesures structurantes réduisent énormément le risque de récidive.
Premièrement, abandonner progressivement le FTP non chiffré au profit du SFTP ou de FTPS, selon ce que propose l’hébergeur. Beaucoup d’équipes continuent d’utiliser FTP simple parce que « ça marche partout », mais ce protocole expose les identifiants en clair sur le réseau.
Deuxièmement, restreindre autant que possible l’accès SSH. Si vous n’en avez pas un besoin opérationnel régulier, il peut rester désactivé. Si vous l’utilisez pour le déploiement, privilégiez l’authentification par clé plutôt que par mot de passe, complétée par une ACL IP si votre contexte le permet.
Troisièmement, mettre en place une revue périodique des comptes. Tous les trimestres par exemple, consacrez une demi-heure à parcourir la liste des comptes FTP et SSH, à vérifier leur utilité et à désactiver les comptes dormants. C’est peu de temps par rapport aux heures perdues sur un incident de piratage.
Quatrièmement, tracer qui a accès à quoi. Une simple feuille de calcul ou un outil de gestion d’accès centralisé suffit souvent. L’idée est que, lors de la prochaine alerte, vous sachiez immédiatement qui contacter pour vérifier si une activité suspecte provient réellement d’un membre de l’équipe.
Pièges fréquents à éviter lors du nettoyage
Sous la pression d’un piratage en cours, certaines erreurs reviennent souvent. Elles compliquent la résolution plus qu’elles ne l’accélèrent. Voici quelques pièges à garder à l’esprit :
Changer uniquement le mot de passe WordPress sans toucher aux accès FTP et SSH, ce qui laisse la principale porte ouverte. Supprimer des comptes FTP ou SSH à l’aveugle, puis découvrir après coup qu’ils étaient utilisés par un système de sauvegarde ou de déploiement automatisé. Envoyer les nouveaux mots de passe par email en clair à toute une liste de destinataires, recréant une vulnérabilité humaine immédiate. Négliger les comptes liés à d’autres sites sur le même hébergement, alors qu’un seul compte compromis à la racine peut contaminer plusieurs WordPress. Considérer le site comme « propre » après une simple restauration, sans surveillance active des fichiers et des connexions dans les jours qui suivent.Garder ces points en tête aide à ne pas aggraver une situation déjà tendue.
Cas particuliers : mutualisés, VPS, agences et freelances
La stratégie de sécurisation des comptes FTP et SSH varie selon le contexte d’hébergement.
Sur un mutualisé classique, souvent choisi pour un seul site vitrine, les marges de manœuvre sont plus limitées, mais le périmètre est réduit. L’enjeu principal consiste à :
- Ne garder qu’un nombre minimal de comptes FTP. Désactiver SSH si vous ne l’utilisez jamais. Surveiller régulièrement les fichiers via un plugin de sécurité ou un outil externe.
Sur un VPS ou un dédié, la responsabilité est plus lourde. Un piratage WordPress ne concerne pas seulement l’application, mais potentiellement tout le serveur. La revue des utilisateurs système, des groupes, des clés SSH et des services exposés devient incontournable. Dans ce type d’environnement, segmenter les sites sur plusieurs utilisateurs système peut éviter qu’un seul accès compromis ne met tout à terre.
Quand plusieurs acteurs interviennent sur le même WordPress (agence web, freelance, intégrateur, équipe interne), la question des accès se double d’une problématique contractuelle. Qui a le droit d’avoir un accès FTP ou SSH, pour combien de temps, avec quel type de permissions ? À chaque fin de collaboration, les accès doivent être révoqués de manière systématique. Dans la pratique, c’est rarement fait, jusqu’au jour où le site est piraté et où l’on réalise que des dizaines de personnes peuvent toujours se connecter.
Après la crise : bâtir une culture de l’accès maîtrisé
Un incident d’« urgence WordPress piraté » laisse souvent un goût amer. Pourtant, il peut aussi servir de point de départ pour une meilleure hygiène de sécurité.
Sur les projets qui s’en sortent bien, on observe quelques changements durables :
- Les identifiants FTP et SSH ne circulent plus en clair sur des canaux non sécurisés. Chaque acteur possède son propre accès, avec des droits limités à son périmètre. Les accès temporaires sont créés avec une date butoir, puis revus ou supprimés. Les logs ne sont plus perçus comme un truc purement technique, mais comme une mémoire collective des actions sur le serveur.
Maîtriser les comptes FTP et SSH, ce n’est pas seulement une question de technique. C’est un travail d’organisation, de discipline, de communication entre les personnes impliquées autour du site.
Lorsqu’un WordPress vient d’être piraté, la tentation est forte de se concentrer uniquement sur le code infecté. Pourtant, si l’on veut vraiment tourner la page et éviter la récidive, le vrai chantier se situe souvent autour des accès. Reprendre la main sur tous les comptes FTP et SSH, les nettoyer, les structurer et les surveiller, c’est refixer les fondations. Sans cela, vous ne faites que repeindre un mur fissuré.