Gérer WordPress, ce n’est pas seulement installer un thème et régler quelques options. L’essentiel se joue souvent dans les accès techniques: SSH, FTP, comptes applicatifs, permissions système, journaux et durcissement. Et parmi tous les points d’entrée possibles, l’accès FTP reste un classique. Il peut être utile pour une maintenance ponctuelle, mais il devient vite un risque si l’on laisse des configurations “par défaut”, des comptes réutilisés ou des accès trop ouverts.
Quand je fais un audit et sécurisation WordPress sur un site existant, je commence presque toujours par “comment on touche au code”. Les mises à jour automatiques réduisent la dépendance, mais beaucoup d’équipes gardent encore des usages FTP, soit pour déposer des fichiers manuellement, soit pour récupérer des sauvegardes, soit pour intervenir vite en cas de panne. Le but n’est pas d’interdire le besoin. Le but est de rendre chaque accès traçable, limité et difficile à détourner.
Comprendre le risque réel derrière FTP et SFTP
FTP et SFTP ne sont pas interchangeables.
FTP, en mode classique, transporte les identifiants en clair. Sur un réseau local compromis, ou sur un trajet interceptable entre le poste et le serveur, un attaquant peut capturer le nom d’utilisateur et le mot de passe. Même si l’attaque demande une situation précise, FTP “qui fonctionne” reste le scénario le plus fréquent. Beaucoup d’intrusions commencent par une récupération de crédentiels plutôt que par une exploitation exotique.
SFTP, lui, s’appuie sur SSH. Le canal est chiffré, l’authentification suit le modèle SSH, et on peut mettre en place des restrictions solides au niveau serveur. Dans une démarche d’audit et sécurisation WordPress, SFTP est en général le bon choix dès lors que vous devez conserver un accès par fichiers.
Mais il y a un point que je vois trop souvent: “on est en SFTP donc c’est bon”. Non. Si le serveur accepte encore des identifiants trop permissifs, si les comptes ont accès à toute l’arborescence, si les mots de passe sont faibles ou réutilisés, ou si le même compte sert à l’administration web et au transfert de fichiers, l’incident reste probable.
L’enjeu, c’est la combinaison: protocole sécurisé, contrôle d’accès strict, authentification robuste, et supervision.
Identifier les usages FTP côté infrastructure
Avant de corriger, il faut comprendre. Une sécurisation FTP/SFTP réussie est rarement un simple “activer SFTP et basta”. Elle dépend de ce que le site et l’infrastructure font réellement.
Dans un audit, je cherche plusieurs signaux:
- Les outils utilisés par l’équipe (clients FTP historiques, intégrateurs de sauvegarde, scripts maison). La présence d’anciens comptes (souvent créés pour “juste une fois”, puis réutilisés). Les paramètres d’hébergement: options proposées par le panel (accès FTP direct, comptes associés à un domaine, chroot ou non). Les logs disponibles (accès, échecs d’authentification, transferts, erreurs). Les droits système sur le dossier WordPress, et surtout sur les uploads (souvent le plus exposé).
Une anecdote typique: sur un site e-commerce, l’équipe pensait ne plus utiliser FTP depuis des mois. En regardant les journaux, on a vu des tentatives d’authentification nocturnes, provenant d’une machine interne qui n’existait plus dans la documentation. Le protocole n’était pas le seul souci, c’était l’angle mort organisationnel. Une sécurisation technique, sans nettoyage des usages, laisse une porte entrouverte.
Choisir la bonne stratégie: SFTP uniquement, ou migration progressive
Passer d’un modèle FTP vers un modèle SFTP peut se faire sans casser tout de suite les workflows. Mais il faut décider de votre politique.
Deux approches sont réalistes:
- Migration progressive: vous activez SFTP, vous testez les clients, vous mettez à jour les identifiants, puis seulement après vous désactivez FTP. Basculage immédiat: vous coupez FTP dès que les accès SFTP fonctionnent, avec une fenêtre planifiée et un plan de retour.
Dans la pratique, si vous n’avez pas une visibilité claire sur tous les postes qui se connectent, la migration progressive est plus prudente. Elle réduit le risque de bloquer une intervention urgente. En revanche, si votre audit montre que FTP n’a plus d’usage réel et que vous avez une petite équipe, un basculement rapide peut être plus efficace.
Le bon critère, c’est la confiance dans l’inventaire. Un audit et sécurisation WordPress sérieux ne se limite pas à un état “aujourd’hui”. Il doit révéler les points de contact “qui reviennent” au fil du temps.
Durcir l’accès SFTP sur le serveur
Une fois que vous êtes sur SFTP, le durcissement n’est pas optionnel. Il s’agit de limiter la surface d’attaque et de réduire le bénéfice d’une compromission.
Sur les serveurs Linux, SFTP est fourni via SSH. Les paramètres clés se trouvent généralement côté https://gardewp.fr/securite-wordpress/ démon SSH (sshd) et côté gestion des comptes utilisateurs. Les principes à viser, sans entrer dans des recettes qui varient selon votre hébergeur, sont assez constants:
1) Limiter qui peut se connecter
2) Limiter où chaque compte peut écrire 3) Renforcer l’authentification 4) Protéger la configuration et surveillerPour l’écriture dans l’espace WordPress, le détail qui compte est la séparation des rôles. Un compte SFTP dédié ne doit pas avoir les mêmes droits qu’un compte utilisé pour l’administration système. Et idéalement, il doit être “confiné” au périmètre dont il a besoin.
Sur beaucoup d’hébergements, l’option de type chroot pour SFTP est disponible. Le chroot limite la vue du système de fichiers, ce qui empêche un compte de “remonter” trop loin. Même si l’attaquant réussit une authentification, ses actions sont limitées par l’environnement.
Autre point concret: les permissions. Dans WordPress, on voit souvent des cas où tout appartient au même utilisateur, ou au contraire des permissions trop permissives qui facilitent une escalade. Un durcissement efficace consiste à conserver un modèle où le serveur web (souvent via PHP-FPM) a les droits nécessaires, et où le compte SFTP a les droits nécessaires, sans donner plus.
Ce n’est pas forcément “tout 755 et tout 644”. En audit, j’adapte selon le contexte, surtout pour wp-content/uploads, qui a généralement besoin d’écrire pour les médias. Mais je garde une exigence: pas d’écriture globale si ce n’est pas indispensable.
Authentification: mots de passe, clés, et rotation
La plupart des incidents liés à l’accès se résument à une mauvaise authentification. Sur SFTP, la meilleure pratique consiste à utiliser des clés SSH plutôt qu’un mot de passe. Les clés réduisent fortement l’impact d’un mot de passe divulgué. Elles permettent aussi de révoquer rapidement l’accès en changeant les clés autorisées.
En audit, je vérifie:
- si l’hébergement autorise l’authentification par clé, si les comptes acceptent encore les mots de passe, si les clés sont correctement liées aux utilisateurs, et si l’équipe a une hygiène de gestion (pas de clé partagée, pas de clé “générique” installée partout).
Une règle pragmatique que j’applique: une clé par personne ou par machine gérée. Si vous utilisez un poste pour les interventions, la clé de ce poste doit correspondre à ce poste. Si l’on change de machine, on supprime l’ancienne clé.
Pour la rotation, je m’appuie sur des événements, pas seulement sur un calendrier théorique. Si un collaborateur part, si un PC est perdu, si vous constatez des tentatives d’authentification répétées, c’est un signal de rotation. Dans beaucoup de contextes, un suivi mensuel ou trimestriel n’est pas réaliste, mais un suivi événementiel est tenable.
Enfin, je regarde le paramètre de politique de mots de passe si les mots de passe restent autorisés. Un mot de passe “complexe mais réutilisé ailleurs” reste un mauvais plan. Idéalement, les mots de passe sont désactivés côté SSH pour les utilisateurs SFTP, sauf contrainte d’hébergement.
Limiter les droits: principe du moindre privilège pour WordPress
WordPress a une particularité: de nombreux fichiers sont modifiés par le CMS, mais surtout par le navigateur (thèmes, plugins, médias) et par l’outil de mise à jour. Le transfert de fichiers SFTP sert plutôt à l’ajout ou au dépannage. Donc le compte SFTP n’a pas besoin d’avoir une liberté totale.
Concrètement, je vise deux résultats:
- Le compte SFTP ne doit pas pouvoir modifier des zones qui ne servent pas à la maintenance. Le compte SFTP ne doit pas avoir un accès système au-delà de WordPress.
Dans une configuration idéale, vous avez un compte pour intervenir sur wp-content et éventuellement sur des fichiers nécessaires (par exemple une configuration de thème ou un fichier de logs selon votre stratégie). Vous évitez de donner des droits sur tout le disque.
Les edge cases existent. Par exemple, certains plugins nécessitent l’écriture dans des répertoires spécifiques, ou des scripts de maintenance déposent des fichiers temporaires. Si vous appliquez une restriction trop forte sans vérifier, vous cassez le site. C’est pour cela que je fais souvent une étape intermédiaire: je verrouille progressivement, avec un test sur un environnement miroir ou au moins sur une fenêtre de maintenance.
Mettre en place des garde-fous contre l’usage “répété”
Un accès FTP/SFTP exposé n’est pas uniquement une question de “qui a le mot de passe”. Il faut aussi penser aux tentatives répétées, aux comptes obsolètes et aux comportements anormaux.
Sans tomber dans des systèmes compliqués, vous pouvez déjà réduire le bruit et les risques en vous concentrant sur:
- la désactivation de l’accès non utilisé (FTP si possible), la réduction des utilisateurs autorisés, la limitation des tentatives échouées côté SSH, et la surveillance des journaux.
Sur les tentatives d’authentification, le volume compte. Si vous voyez des milliers de tentatives sur un compte, c’est souvent qu’un identifiant a circulé, ou que des bots explorent. Dans ce cas, vous verrouillez plus vite, vous révoquez les accès, et vous vérifiez les logs plus en amont (création de fichiers, modifications suspectes, inconnus dans wp-content).
Je ne recommande pas de “bloquer tout” sans analyse. Une stratégie trop brutale peut bloquer l’équipe le jour où vous en avez besoin. Mais une stratégie mesurée, avec thresholds et procédures de reprise, est saine.
Exemple de procédure d’audit sur un site WordPress existant
Sur un audit réel, je travaille par étapes, sans tout casser d’un coup. Cela évite les régressions et permet de documenter les décisions.
D’abord, je dresse une cartographie: comptes de connexion, protocoles activés, droits de l’utilisateur web, chemins sensibles (wp-config.php, wp-content/uploads, dossiers de plugins et thèmes). Ensuite, je vérifie les logs SSH/FTP disponibles. Puis je compare ce que j’observe avec ce que l’équipe pense utiliser.
Ensuite, je teste SFTP avec le client réel de l’équipe. Pas un client “en théorie”. Un client peut imposer certains réglages, et certains hébergeurs ont des comportements spécifiques sur la navigation des répertoires.
Puis je verrouille les droits de manière progressive. Par exemple, je commence par empêcher les connexions par mot de passe si les clés sont prêtes. Si cela n’est pas possible, j’applique un durcissement autour des comptes, et je planifie l’étape suivante.
Enfin, je documente la procédure. Une configuration sécurisée mais incomprise est fragile. L’équipe doit savoir quel compte utiliser, quel dossier est accessible, et quoi faire si un plugin ou un script a besoin de fichiers.
Ce dernier point paraît trivial, mais il fait toute la différence. J’ai vu des sites “sécurisés” qui ont été re-durcis en urgence après que quelqu’un a recréé un compte par réflexe, faute d’information sur l’accès existant.
Désactiver FTP: quand et comment le faire sans interruption
Désactiver FTP paraît simple, mais le “quand” dépend des dépendances. Avant de couper, vérifiez:
- s’il y a des scripts qui transfèrent via FTP, si un outil de sauvegarde utilise FTP, si une procédure de restauration historique passe par FTP.
Si vous n’avez pas les logs ou s’ils sont incomplets, vous pouvez faire un test contrôlé: désactivation partielle ou restriction par IP si votre hébergeur le propose. Puis vous observez pendant une période courte. L’objectif est d’éviter un blocage de maintenance.
Quand vous coupez FTP, gardez une procédure de remplacement. Pour les interventions, SFTP doit être prêt et validé. Pour les sauvegardes, privilégiez des méthodes d’hébergement ou des dumps gérés.
Pour WordPress, je considère que la désactivation de FTP est un marqueur de maturité sécurité, surtout si votre audit et sécurisation WordPress met en évidence des comptes faibles ou des habitudes héritées.
Contrôle et surveillance: logs, intégrité, et signaux d’alerte
La partie la plus “vivante” de la sécurité, ce sont les signaux. Les logs sont votre meilleur détecteur d’incident, à condition de les comprendre et de les exploiter.
Je vérifie au minimum:
- les échecs d’authentification SSH, les réussites, surtout sur des heures inhabituelles, les changements dans wp-content (thèmes, plugins, uploads), et les traces de modification de fichiers sensibles.
Si vous n’avez pas de solution centralisée, vous pouvez déjà faire simple: consulter les logs SSH régulièrement, et mettre en place une routine d’analyse légère. Par exemple, un regard hebdomadaire sur les échecs récurrents peut suffire à détecter un problème tôt.
Ensuite, je recommande une approche “intégrité” pour les fichiers critiques. Selon votre environnement, cela peut passer par des outils de vérification de checksum, ou par une approche plus manuelle au besoin. Le but n’est pas d’avoir 100 pour cent de couverture, c’est d’avoir un moyen fiable de constater une modification inattendue.
Un détail pratique: les timestamps de fichiers peuvent être trompeurs. Une mise à jour de plugin, une régénération de cache ou un changement normal peut modifier les dates. C’est pour cela que la surveillance doit être corrélée avec les événements (vous avez fait une mise à jour, une restauration, une maintenance). Si la modification arrive sans action humaine associée, vous investiguez.
Points d’attention spécifiques WordPress
Sécuriser l’accès FTP/SFTP touche le CMS indirectement. Quand quelqu’un dépose ou modifie un fichier, WordPress devient un levier. La plupart des incidents tournent autour de wp-content, en particulier uploads et plugins.
Voici quelques sujets concrets à vérifier en même temps que le verrouillage FTP/SFTP:
1) Les comptes SFTP et les plugins qui écrivent des fichiers
Certains plugins d’import, de sauvegarde, ou de construction de pages utilisent des méthodes d’écriture et créent des fichiers temporaires. Si vous confinez trop les droits, ils peuvent échouer, et parfois les équipes “corrigent” en ouvrant trop large. Mieux vaut anticiper.2) Le fichier wp-config.php
Il est souvent la clé de la configuration. Je préfère que le compte SFTP n’y ait pas accès, sauf nécessité explicite.
3) Les répertoires d’uploads
Ils sont le dépôt le plus fréquent. Même si ce n’est pas un “risque FTP” en soi, c’est un point d’attention pour la surveillance. Si un attaquant obtient l’accès SFTP, c’est souvent là qu’il essaye de déposer des scripts ou des fichiers déguisés.4) Les webhooks et les comptes d’automatisation
Si vous utilisez des outils qui déclenchent des actions de maintenance, vérifiez qu’ils n’ont pas d’accès indirect via des identifiants partagés. Une compromission n’a pas besoin d’être “brute”, elle peut être organisationnelle.Comparer FTP et SFTP en termes de décisions d’audit
Pour trancher, je raisonne en décisions, pas en théorie. Voici une comparaison utile pour cadrer les arbitrages lors d’un audit et sécurisation WordPress.
| Élément | FTP | SFTP | |---|---|---| | Chiffrement du canal | généralement non, identifiants exposés | oui, via SSH | | Intégration contrôle d’accès | limité selon hébergeur | solide, via SSH et politiques | | Gestion des droits | souvent via comptes FTP | via comptes SSH, options de confinement | | Risque principal | interception de crédentiels | compromission de compte, erreurs de configuration, absence de supervision | | Recommandation | à éviter | à privilégier |
Si FTP est encore activé, je le traite comme un “défaut de sécurité” à corriger, avec un plan de migration réaliste.
Une mini check-list de verrouillage (sans perdre de temps)
Quand je dois livrer un dossier d’audit et sécurisation WordPress à une équipe, je termine souvent par une séquence courte de décisions à appliquer. Pas une usine à gaz, juste l’essentiel pour fermer les portes les plus évidentes.
- Utiliser SFTP avec authentification par clé SSH plutôt que mots de passe Désactiver FTP dès que les dépendances sont confirmées Confiner le compte SFTP au périmètre nécessaire (chroot si disponible) Donner au compte SFTP uniquement les droits d’écriture requis sur wp-content Mettre en place une revue périodique des logs SSH et des modifications dans wp-content
C’est court, mais c’est le noyau qui revient dans la majorité des audits.
Trade-offs et erreurs fréquentes à éviter
Il y a des pièges qui reviennent. Les connaître évite des cycles de correction.
“On a désactivé FTP, donc c’est terminé”
Non. Si votre SFTP est accessible avec des mots de passe faibles, ou si des comptes anciens sont encore autorisés, l’attaque passe par une autre voie. La réduction de surface doit être complète.
“On ouvre tout pour que ça marche”
Un compte trop permissif finit toujours par devenir un problème. Souvent, c’est le moment où l’équipe commence à “ajouter au lieu de corriger”. Ouvrir sur un dossier sensible, puis oublier, c’est un classique. La bonne pratique consiste à faire du calibrage, avec tests et retours.
Confusion entre accès SFTP et accès web
WordPress peut être compromis par une faille applicative, pas uniquement par un accès fichier. Verrouiller SFTP est indispensable, mais il faut aussi garder une hygiène globale: mises à jour, suppression des plugins inutilisés, configuration des permissions, et surveillance.
Confiance excessive dans un seul outil de sécurité
Un firewall et un scanner peuvent manquer un compte mal configuré ou des droits d’écriture excessifs. Les sécurisations doivent se compléter. L’accès SFTP doit être “propre” même si un autre outil échoue.
Comment rendre la sécurité durable côté équipe
La meilleure configuration échoue si la procédure est floue. Pour rendre la sécurisation FTP/SFTP durable, je recommande de formaliser le fonctionnement au niveau équipe.
Au minimum, il faut que chacun sache:
- quel compte SFTP utiliser (et pourquoi), quelles clés SSH sont associées, quels dossiers sont autorisés, comment réagir en cas d’échec d’accès, et comment on gère un départ de collaborateur.
Dans une petite équipe, cela peut tenir en une page interne. Dans une structure plus large, cela devient une procédure validée. L’objectif n’est pas bureaucratique. L’objectif est d’empêcher la recréation sauvage de comptes et l’injection d’accès temporaires qui deviennent permanents.
Points à valider avant de dire “c’est sécurisé”
Un audit final n’est pas un sentiment, c’est une vérification. Avant de conclure que l’accès FTP/SFTP est correctement sécurisé, je veux des preuves concrètes:
- FTP est réellement désactivé ou restreint, et les tentatives cessent SFTP fonctionne pour les opérations nécessaires Les comptes autorisés sont listés et cohérents avec l’équipe Les clés SSH sont individuelles ou maîtrisées Les droits d’écriture sont minimaux et alignés avec WordPress
Si ces points tiennent, on a une base solide. Si l’un d’eux manque, il reste un risque, même si tout “semble stable”.
Sécuriser l’accès FTP/SFTP dans WordPress, ce n’est pas seulement changer un protocole. C’est articuler technique, processus et visibilité. Un bon audit et sécurisation WordPress traite l’accès aux fichiers comme un levier majeur, avec une approche pragmatique: on corrige ce qui est réel, on évite les décisions trop brutales, et on rend la sécurité facile à maintenir.