Comment prévenir les attaques par force brute dans WordPress (9 couches de protection)

Si votre site WordPress est en ligne, il est probablement attaqué en ce moment même.

Les robots automatisés scannent continuellement Internet, testant /wp-login.php sur chaque site WordPress qu'ils trouvent. Ils essaient d'abord les identifiants « admin », puis une liste des mots de passe les plus courants.

Un site sans protection subit des centaines de ces tentatives chaque jour, silencieusement, sans aucun signe visible.

Pire encore : les attaques échouées ne sont pas gratuites. Chaque tentative de connexion lance un processus PHP sur votre serveur.

Suffisamment de tentatives simultanées et votre plan d'hébergement atteint ses limites.

Les visiteurs réels commencent à voir des temps de chargement lents ou des pages d'erreur. Certains hébergeurs limitent automatiquement votre compte. Cela se produit même lorsqu'aucun attaquant n'a réussi à entrer.

Une attaque réussie est un problème différent. Un accès administrateur complet signifie des modifications de contenu, des logiciels malveillants injectés dans vos fichiers de thème, des comptes de secours créés, du spam SEO intégré dans vos publications ou des données clients exposées.

La récupération après une violation réussie prend au mieux quelques heures ; plusieurs jours si vous n'avez pas de sauvegarde propre.

Dans cet article, je vous donnerai les meilleures façons de défendre votre site contre les attaques par force brute.

Voici les points clés à retenir :

• Même les attaques par force brute échouées nuisent à votre site. Elles épuisent les ressources PHP, ralentissent les temps de chargement et peuvent déclencher la limitation de l'hébergement avant même qu'un seul mot de passe ne soit deviné correctement.
• Le bourrage d'identifiants n'est pas la même chose que la force brute. Les attaquants utilisent de vrais mots de passe divulgués lors d'autres violations, ce qui signifie qu'un mot de passe fort seul ne suffit pas si vos utilisateurs réutilisent leurs identifiants.
• WordPress n'a pas de protection intégrée contre la force brute. La limitation des tentatives de connexion, l'authentification à deux facteurs et la fonctionnalité WAF nécessitent tous un plugin ou une configuration serveur.
• L'authentification à deux facteurs est l'étape la plus rentable de cette liste. Elle arrête à la fois la force brute et le bourrage d'identifiants, même lorsque le mot de passe est correct.
• La méthode system.multicall de XML-RPC contourne la plupart des défenses de la page de connexion. La désactiver ferme une surface d'attaque distincte que les plugins de limitation de débit ne couvrent pas.
• Changer votre URL de connexion réduit le volume d'attaques mais n'est pas une défense principale. Considérez-le comme une friction, pas une protection.
• Une sauvegarde que vous n'avez jamais restaurée est une sauvegarde que vous n'avez pas réellement. Testez votre processus de restauration trimestriellement avant d'en avoir besoin sous pression.
• Plus de plugins de sécurité ne signifient pas plus de sécurité. Un plugin bien configuré bat quatre plugins partiellement configurés, qui peuvent créer des conflits et des surcoûts.

Table des matières

Qu'est-ce qu'une attaque par force brute ?

La plupart des gens imaginent qu'une attaque par force brute consiste en un bot qui essaie des combinaisons de mots de passe aléatoires jusqu'à ce qu'une fonctionne. Cela arrive, mais ce n'est pas la seule version de cette attaque, et ce n'est même plus la plus courante.

Force brute classique contre bourrage d'identifiants

La force brute classique consiste en un logiciel automatisé qui essaie toutes les combinaisons de caractères possibles jusqu'à trouver un mot de passe qui fonctionne.

Face à un mot de passe long et aléatoire, c'est irréalisable. Il faudrait plus de temps pour trouver par force brute un mot de passe aléatoire de 16 caractères qu'il ne reste de temps avant que le soleil ne s'éteigne.

Le bourrage d'identifiants est différent, et plus dangereux.

Les attaquants achètent ou téléchargent des bases de données divulguées lors d'autres violations de données : adresses e-mail associées à des mots de passe provenant de services compromis. Ils testent ensuite ces paires sur des sites WordPress.

Si l'un de vos utilisateurs s'est inscrit avec le même e-mail et le même mot de passe qu'il utilise partout ailleurs, le bourrage d'identifiants pourrait lui permettre d'accéder à son compte et de se connecter dès la première tentative.

C'est pourquoi « J'ai un mot de passe fort » ne protège pas entièrement vos utilisateurs. Votre mot de passe est peut-être fort. Le leur ne l'est peut-être pas.

Les attaques par dictionnaire se situent entre les deux. Au lieu de toutes les combinaisons possibles, elles testent une liste organisée de mots de passe courants, de motifs connus et de variations de mots réels. Plus rapides que la vraie force brute, plus ciblées que la devinette aléatoire.

Le multiplicateur XML-RPC

WordPress inclut un fichier appelé xmlrpc.php, initialement conçu pour la publication à distance et les intégrations d'API. Il accepte une méthode appelée system.multicall qui permet à une seule requête HTTP de tester des milliers de combinaisons nom d'utilisateur/mot de passe en un seul appel.

C'est important car la plupart des plugins de limitation de connexion surveillent /wp-login.php. Un bot utilisant xmlrpc.php contourne entièrement cette protection. Limiter le débit de votre page de connexion tout en laissant XML-RPC ouvert, c'est comme verrouiller votre porte d'entrée et laisser la fenêtre déverrouillée.

Si vous n'utilisez pas XML-RPC, le désactiver est l'une des mesures les plus rentables de cette liste. La couche 5 explique exactement comment.

Ce que même une attaque échouée vous coûte

Une attaque par force brute qui ne devine jamais un seul mot de passe correct vous coûte quand même quelque chose de réel.

Chaque tentative de connexion est une requête HTTP. Chaque requête lance un processus PHP. Sur un hébergement mutualisé, votre plan inclut un nombre limité de processus PHP simultanés.

Une attaque à haut volume remplit ces processus avec des tentatives de connexion au lieu de servir vos visiteurs réels. Le résultat est des temps de chargement lents, des timeouts et, dans les cas graves, une suspension temporaire de l'hébergement que vous n'aviez pas vue venir.

Cela enfouit également les événements de sécurité légitimes dans le bruit des journaux. Si un attaquant parvient finalement à entrer, les journaux des tentatives échouées qui auraient signalé une activité inhabituelle sont déjà remplis de milliers d'entrées. Vous cherchez une aiguille dans une botte de foin.

Les protections au niveau du plugin réduisent les dégâts. Les protections au niveau du serveur et de la périphérie les éliminent. C'est la raison principale pour laquelle ce guide est structuré en couches plutôt qu'en liste.

Comment prévenir les attaques par force brute dans WordPress

Il n’existe aucun réglage unique qui rende votre site immunisé. Ce qui fonctionne, ce sont les couches : chacune rattrape ce que la précédente a manqué.

Vos identifiants arrêtent la plupart des robots automatisés. La limitation de débit arrête ceux qui passent. Un WAF arrête le volume avant qu’il n’atteigne votre serveur. Les sauvegardes couvrent le scénario où tout le reste échoue.

Les couches ci-dessous sont classées par impact et facilité de mise en œuvre. Commencez par le haut. Allez aussi loin que votre configuration d’hébergement le permet. Même les trois premières couches réduisent considérablement votre exposition.

Voici ce qu’il faut faire :

• Couche 1 : Identifiants : changez le nom d’utilisateur administrateur par défaut, utilisez des mots de passe uniques pour chaque compte et activez l’authentification à deux facteurs pour tous les administrateurs.
• Couche 2 : Limiter les tentatives de connexion : limitez les tentatives de connexion échouées via un plugin ou, pour une protection plus forte, via Cloudflare ou une limitation de débit au niveau du serveur.
• Couche 3 : Changer l’URL de connexion par défaut : déplace l’adresse que la plupart des robots ciblent, réduisant le volume d’attaques automatisées sur votre formulaire de connexion.
• Couche 4 : Ajouter un CAPTCHA : filtre les soumissions de robots automatisés sur le formulaire de connexion ; plus efficace lorsqu’il est combiné avec la limitation de débit plutôt que utilisé seul.
• Couche 5 : Désactiver ou restreindre XML-RPC : ferme une surface d’attaque distincte qui permet aux attaquants de tester des milliers de mots de passe en une seule requête HTTP, contournant les défenses de la page de connexion.
• Couche 6 : Pare-feu d’application Web : bloque le trafic malveillant et les adresses IP connues comme étant dangereuses avant qu’elles n’atteignent votre page de connexion ; les WAF au niveau du périmètre comme Cloudflare empêchent l’épuisement des ressources lors d’attaques à haut volume.
• Couche 7 : Renforcement au niveau du serveur : restreignez wp-login.php par IP, implémentez Fail2ban et utilisez SFTP avec authentification par clé SSH ; pour les propriétaires de VPS et de serveurs dédiés.
• Couche 8 : Gardez tout à jour : corrige les vulnérabilités que les attaquants exploitent pour établir un point d’ancrage avant de forcer leur chemin plus profondément.
• Couche 9 : Sauvegardez votre site : la dernière couche de défense ; une sauvegarde hors site testée avec un chemin de restauration fonctionnel est la seule garantie qu’une attaque réussie ne mettra pas fin à votre site.

Couche 1 : Commencez par vos identifiants

Chaque outil de force brute automatisé commence par le nom d’utilisateur « admin » et les mots de passe les plus courants. Supprimer les deux de votre site prend peut-être cinq minutes et élimine immédiatement la majorité des tentatives d’attaques automatisées.

Ce n’est pas une défense complète, mais c’est le retour sur investissement temporel le plus rapide que vous trouverez dans ce guide.

Utiliser un nom d’utilisateur administrateur non par défaut

Lorsque WordPress a été installé pour la première fois sur votre site, il a suggéré « admin » comme nom d’utilisateur par défaut. Beaucoup de sites ne le changent jamais. Les attaquants le savent, et chaque outil de force brute commence par là.

Utiliser un nom d’utilisateur différent oblige un attaquant à deviner deux inconnues au lieu d’une. Ce n’est pas une amélioration spectaculaire contre une attaque ciblée sophistiquée, mais cela élimine la grande majorité des robots automatisés qui ne dépassent jamais l’hypothèse « admin ».

Pour vérifier votre nom d’utilisateur actuel, allez dans Utilisateurs » Profil dans wp-admin. Le champ nom d’utilisateur se trouve dans les paramètres Nom.

WordPress ne vous permet pas de changer votre nom d'utilisateur directement, mais vous pouvez créer un nouveau compte administrateur avec un nom d'utilisateur différent, transférer la propriété de votre contenu et supprimer l'ancien compte « admin ».

Les utilisateurs de WP-CLI peuvent le faire en une seule commande :

wp user update 1 --user_login=yourname

Utilisez des mots de passe forts et uniques pour chaque compte

Chaque compte administrateur de votre site a besoin de son propre mot de passe unique.

Le bourrage d'identifiants fonctionne en testant des paires nom d'utilisateur/mot de passe connues provenant d'autres violations. Si un utilisateur a réutilisé son mot de passe e-mail sur plusieurs sites et que ce mot de passe a fuité ailleurs, le bourrage d'identifiants pourrait se connecter du premier coup.

WordPress inclut un indicateur de force du mot de passe intégré qui signale les mots de passe faibles sur l'écran de profil. Cela arrête les pires choix, mais n'impose pas de longueur minimale ni n'empêche la réutilisation.

Pour plus de contrôle, Password Policy Manager vous permet de définir des exigences de mot de passe pour l'ensemble du site et de forcer la réinitialisation des comptes qui ne les respectent pas.

Activez l'authentification à deux facteurs

Avec la 2FA activée, un mot de passe correct ne suffit pas pour se connecter. L'attaquant a également besoin d'un code sensible au temps provenant d'un appareil physique qu'il ne possède pas.

Cela arrête les attaques par force brute classiques, le bourrage d'identifiants et les attaques par dictionnaire. Même si un attaquant possède votre mot de passe exact provenant d'une violation de données, il ne peut pas se connecter sans le second facteur.

Le cœur de WordPress n'inclut pas la 2FA. Vous avez besoin d'un plugin.

WP 2FA est gratuit, activement maintenu et simple à configurer. Il prend en charge les applications d'authentification comme Google Authenticator, Authy et 1Password.

miniOrange 2FA et le plugin Two Factor sont d'autres options largement utilisées avec une flexibilité de configuration supplémentaire.

Les passkeys sont l'alternative plus récente. Elles utilisent la norme WebAuthn et sont conçues pour résister au phishing : il n'y a pas de code à intercepter, de SMS à intercepter par sim-swap, ni d'application d'authentification à compromettre. Le support des plugins est encore en cours de maturation, mais si votre configuration le prend en charge, les passkeys méritent d'être considérées.

Appliquez la 2FA à chaque compte administrateur du site. Pas seulement le vôtre. Un seul compte administrateur non protégé suffit à un attaquant.

Couche 2 : Limitez les tentatives de connexion

Par défaut, WordPress autorise un nombre illimité de tentatives de connexion. Un bot peut essayer dix mille mots de passe pendant que vous vous préparez un café.

La limitation du débit coupe cela après quelques tentatives, bloquant l'IP fautive avant qu'elle n'approche d'un identifiant correct.

Limitation des tentatives de connexion basée sur un plugin

Les plugins de limitation des connexions fonctionnent en suivant les tentatives échouées par adresse IP. Après un certain nombre d'échecs, le plugin bloque cette IP pendant une période définie. Le bot de l'attaquant passe à autre chose.

Limit Login Attempts Reloaded est l'option gratuite la plus utilisée, avec un écran de configuration simple et sans superflu.

Wordfence inclut la limitation dans son ensemble de fonctionnalités plus large, ce qui le rend intéressant si vous souhaitez un seul plugin couvrant plusieurs couches de sécurité.

Pour la plupart des sites, 5 à 10 tentatives échouées avant un blocage temporaire constituent un bon point de départ.

Des seuils plus bas augmentent la sécurité mais peuvent créer des maux de tête pour le support. Les bureaux d'entreprise, les universités et les réseaux mobiles partagent souvent une seule adresse IP entre des centaines d'utilisateurs. Une personne qui tape mal son mot de passe trois fois bloque tout le monde.

Testez votre seuil par rapport à la manière dont vos utilisateurs se connectent réellement.

Une limitation à connaître : les plugins au niveau applicatif invoquent toujours PHP à chaque requête qu'ils traitent. En cas d'attaque à très haut volume, votre serveur reçoit toujours tout ce trafic.

Le plugin empêche l'attaquant de réussir, mais il n'arrête pas la consommation de ressources. C'est ce qu'aborde la section suivante.

Quand déplacer la protection plus haut dans la pile

Le niveau gratuit de Cloudflare vous permet de créer des règles de limitation de débit personnalisées ciblant spécifiquement /wp-login.php et /xmlrpc.php.

Le trafic est filtré au niveau du bord de Cloudflare avant même d'atteindre votre serveur. Vos workers PHP restent libres pour les visiteurs réels.

C'est la mise à niveau la plus accessible par rapport à la protection au niveau du plugin, et elle ne coûte rien.

Couche 3 : Changez l'URL de connexion par défaut

La plupart des bots automatisés ciblent /wp-login.php car c'est là que WordPress place le formulaire de connexion par défaut. Le déplacer vers une URL personnalisée signifie que la majorité des bots ne le trouvent jamais. Ils rencontrent une 404, enregistrent votre site comme une impasse, et passent à autre chose.

C'est une couche de friction, pas une défense primaire. Un attaquant déterminé ciblant spécifiquement votre site peut trouver une URL de connexion personnalisée par d'autres moyens.

Mais réduire le volume des attaques automatisées a une valeur réelle :

• Moins de tentatives de connexion échouées
• Moins de bruit dans le journal d'activité
• Moins de surcharge de processus PHP par les plugins de limitation traitant des requêtes mortes

Le principal risque est de perdre l'URL. Si vous oubliez votre chemin de connexion personnalisé et que votre hébergeur n'offre pas d'accès d'urgence à wp-admin, vous êtes bloqué hors de votre propre site.

Avant d'effectuer ce changement, stockez l'URL personnalisée dans votre gestionnaire de mots de passe et confirmez la méthode d'accès d'urgence de votre hébergeur. Certains hébergeurs offrent un accès phpMyAdmin ou une réinitialisation de connexion assistée par le support.

WPS Hide Login gère cela avec une configuration minimale : installez-le, définissez votre chemin personnalisé et enregistrez.

Un ajout qui rend cette étape plus efficace : créez une règle Cloudflare qui renvoie un 403 sur le chemin /wp-login.php d'origine après l'avoir déplacé.

Sans cette règle, l'ancienne URL existe toujours et répond, ce qui signifie qu'un scanner persistant peut toujours la trouver en sondant les chemins courants. Bloquer l'ancienne URL au bord ferme cette faille.

Couche 4 : Ajoutez un CAPTCHA au formulaire de connexion

CAPTCHA arrête les bots automatisés de soumettre des formulaires de connexion en exigeant une preuve d'interaction humaine. Un script frappant votre page de connexion des milliers de fois par heure ne peut pas résoudre un défi visuel ou comportemental comme le peut une personne.

Pour la plupart des sites, l'ajout de CAPTCHA au formulaire de connexion réduit considérablement le volume de soumissions automatisées.

Gardez à l'esprit que ce n'est pas infaillible. Des services de résolution de CAPTCHA existent : de vrais humains payés une fraction de centime pour résoudre des défis à grande échelle ou des modèles d'apprentissage automatique entraînés à décrypter d'anciens formats de CAPTCHA.

Face à un attaquant ciblé et bien financé, un CAPTCHA n'est qu'un ralentisseur. Face aux bots automatisés responsables de la grande majorité du trafic de force brute, il est efficace.

Les trois options à considérer adoptent chacune une approche différente.

1. Google reCAPTCHA v3 s'exécute de manière invisible en arrière-plan, évalue le comportement de l'utilisateur et signale les requêtes suspectes sans demander aux utilisateurs de faire quoi que ce soit.
2. hCaptcha adopte une position axée sur la confidentialité et constitue une alternative directe remplaçable.
3. Cloudflare Turnstile est gratuit, sans friction pour la plupart des utilisateurs et n'envoie pas de données comportementales à Google.

Parmi les trois, Turnstile est ma recommandation actuelle pour les nouvelles installations. Les compromis en matière de confidentialité sont meilleurs et l'expérience utilisateur est plus épurée.

Wordfence inclut des options CAPTCHA. Si vous l'utilisez déjà, vérifiez si son CAPTCHA intégré couvre votre formulaire de connexion avant d'ajouter un plugin séparé.

Couche 5 : Désactivez ou restreignez XML-RPC

XML-RPC était l'API de publication à distance d'origine de WordPress, conçue à une époque où l'API REST n'existait pas. La plupart des sites ne l'utilisent plus. La laisser activée donne aux attaquants une surface d'attaque distincte qui contourne la plupart des défenses de la page de connexion que vous avez configurées jusqu'à présent.

Xmlrpc.php accepte une méthode appelée system.multicall qui regroupe des milliers de tentatives de connexion en une seule requête HTTP.

Un plugin de limitation de débit surveillant /wp-login.php ne le verra pas. Votre CAPTCHA ne se déclenchera pas. L'attaque atterrit sous vos défenses car elle vise une porte différente.

Avant de le désactiver, vérifiez si vous l'utilisez réellement. Jetpack se connecte à WordPress.com via XML-RPC. Certains anciens flux de publication mobile en dépendent.

Si vous n'utilisez pas Jetpack ou ne publiez pas depuis une application mobile, vous n'en avez probablement pas besoin.

Les plugins de sécurité comme Wordfence ont un interrupteur en un clic dans la section des paramètres de connexion.

Le plugin Disable XML-RPC-API est une alternative légère si vous préférez ne pas installer une suite de sécurité complète.

Sur Nginx ou Apache, vous pouvez bloquer xmlrpc.php au niveau du serveur afin que la requête n'atteigne jamais PHP.

Si vous avez besoin de XML-RPC pour Jetpack ou une autre intégration, la solution ciblée consiste à bloquer spécifiquement system.multicall plutôt que l'intégralité du point d'accès. Une règle WAF Cloudflare peut le faire sans casser la fonctionnalité XML-RPC légitime.

Restreindre l'accès à xmlrpc.php à des adresses IP spécifiques est une autre option pour les intégrations avec des sources connues et stables.

L'API REST est le remplacement moderne pour les nouvelles intégrations. Si vous créez quelque chose qui aurait utilisé XML-RPC, créez-le plutôt contre l'API REST.

Couche 6 : Utilisez un pare-feu d'application Web

Un pare-feu d'applications Web (WAF) se situe entre le trafic entrant et votre site WordPress, inspectant les requêtes et bloquant les requêtes malveillantes avant qu'elles n'atteignent votre page de connexion.

Plus il opère près du bord du réseau, moins votre serveur travaille sous attaque. Un WAF basé sur un plugin arrête les attaques après qu'elles sont arrivées sur votre serveur. Un WAF au niveau du bord les arrête avant même qu'elles n'atteignent le serveur.

WAF basés sur des plugins

Les WAF de plugins comme Wordfence et MalCare filtrent les requêtes au niveau de la couche applicative. Ils maintiennent des bases de données d'adresses IP malveillantes connues, de signatures de bots et de modèles d'attaques, et ils bloquent les requêtes correspondantes avant que WordPress ne les traite.

Pour les sites sur un hébergement mutualisé où la configuration du serveur n'est pas accessible, un WAF de plugin est le bon point de départ.

La limite est que votre serveur reçoit toujours chaque requête que le WAF évalue. Sous une attaque à grande échelle, PHP démarre toujours, le plugin s'exécute toujours, et vos ressources d'hébergement en subissent toujours les conséquences. L'attaquant n'entre pas, mais le coût en ressources est réel.

WAF au niveau du Edge

Le niveau gratuit de Cloudflare filtre le trafic sur son réseau mondial avant qu'il n'atteigne votre serveur. La gestion des bots, la limitation du débit et les défis CAPTCHA Turnstile fonctionnent tous au niveau du Edge.

Votre serveur ne voit que le trafic que Cloudflare a déjà filtré. Pendant une attaque par force brute à haut volume, votre site reste rapide pour les visiteurs réels car le trafic d'attaque n'arrive jamais.

Sucuri propose un WAF géré avec des ensembles de règles spécifiques à WordPress et une couche CDN incluse. C'est un service payant, mais la maintenance des règles gérées mérite d'être considérée pour les sites qui n'ont pas de développeur surveillant activement les configurations de sécurité.

Les hébergeurs WordPress gérés, y compris WP Engine et Kinsta, incluent des WAF au niveau de l'infrastructure dans leur pile d'hébergement. Si vous êtes sur l'une de ces plateformes, vous bénéficiez probablement déjà d'une protection au niveau du Edge. Confirmez avec votre hébergeur ce que leur WAF couvre spécifiquement et si des règles personnalisées sont disponibles.

Une configuration Cloudflare qui vaut la peine d'être mise en œuvre : une règle de pare-feu personnalisée bloquant tout trafic vers /wp-admin sauf depuis votre adresse IP ou la plage d'adresses IP de votre équipe.

Pour les sites gérés par une petite équipe se connectant depuis des IP prévisibles ou un VPN partagé, c'est l'une des mesures uniques les plus efficaces disponibles. Les bots automatisés ne peuvent pas du tout accéder à la zone d'administration.

Vérifiez simplement que votre site n'utilise pas les URL /wp-admin pour les fonctionnalités destinées aux clients (comme les pages Mon compte WooCommerce ou les connexions au portail d'adhésion) avant d'activer cette règle.

Couche 7 : Durcissement au niveau du serveur

Si vous gérez votre propre serveur ou VPS, vous pouvez pousser la protection en amont de WordPress, bloquant les attaques avant qu'elles n'atteignent PHP ou tout code WordPress.

Cette section s'adresse aux développeurs et aux propriétaires de serveurs VPS ou dédiés. Si vous êtes sur un hébergement mutualisé sans accès à la configuration du serveur, passez à la couche 8.

Restreindre wp-login.php par IP

Si vous et votre équipe vous connectez toujours depuis des adresses IP prévisibles, telles qu'un réseau de bureau ou un VPN partagé, vous pouvez restreindre /wp-login.php à ces IP au niveau du serveur. Chaque requête provenant d'une autre adresse IP reçoit un 403 avant le chargement de WordPress.

Sur Nginx, cela ressemble à ceci à l'intérieur de votre bloc serveur :

location = /wp-login.php {

allow 203.0.113.10;

deny all;

}

Remplacez l'IP par la vôtre. Ajoutez plusieurs lignes 'allow' pour plusieurs IP. La requête de toute adresse non répertoriée n'atteint jamais PHP.

Cela ne fonctionne pas pour les sites WooCommerce, les plateformes d'adhésion ou toute configuration où les clients se connectent via WordPress. Il est mieux adapté aux sites d'entreprise ou de portfolio avec une petite équipe d'administrateurs stable.

Implémenter Fail2ban

Fail2ban lit les journaux de votre serveur et bannit automatiquement les adresses IP qui correspondent aux modèles que vous définissez. Pour WordPress, cela signifie qu'une IP générant des entrées de connexion échouées répétées dans le journal est ajoutée à la liste de blocage de votre pare-feu, généralement via iptables ou nftables, avant qu'elle n'accumule suffisamment de tentatives pour avoir de l'importance.

Il nécessite un plugin d'intégration WordPress pour fonctionner : Fail2ban doit lire les tentatives de connexion échouées dans un format analysable, et WordPress ne les écrit pas dans les journaux du serveur par défaut.

WP fail2ban gère cela, en écrivant les événements d'authentification dans un format que Fail2ban peut analyser directement.

Le résultat est une protection qui fonctionne au niveau du réseau : les IP bloquées n'atteignent jamais votre serveur web, encore moins WordPress. Combiné à la limitation de débit de Nginx sur le point d'accès de connexion, c'est la configuration non-entreprise la plus stricte disponible.

Utilisez SFTP et les clés SSH, pas FTP

Les attaques par force brute ne ciblent pas seulement votre page de connexion. FTP fonctionne sur le port 21 et transmet les identifiants en texte brut. Les attaquants scannent les ports FTP ouverts et appliquent la même approche de devinette d'identifiants qu'ils utilisent sur wp-login.php.

SFTP chiffre la connexion. Si votre hébergeur le prend en charge, passez à SFTP et désactivez complètement FTP. La plupart des hébergeurs modernes le prennent en charge ; certains désactivent FTP par défaut.

Pour l'accès SSH à votre serveur, utilisez l'authentification par clé plutôt que l'authentification par mot de passe. Une paire de clés SSH élimine le vecteur de devinette de mot de passe au niveau du serveur : il n'y a pas de mot de passe à forcer.

Générez une paire de clés localement, ajoutez la clé publique au fichier ~/.ssh/authorized_keys de votre serveur, et désactivez la connexion SSH basée sur mot de passe dans votre sshd_config.

Si vous gérez un VPS et que vous ne l'avez pas encore fait, c'est la première chose qui vaut la peine d'être configurée.

Couche 8 : Gardez WordPress, les plugins et les thèmes à jour

La force brute est souvent la deuxième attaque, pas la première. Les attaquants exploitent fréquemment une vulnérabilité dans un plugin obsolète pour établir un point d'ancrage, créer un compte backdoor, ou élever leurs privilèges.

La force brute vient après, visant les comptes qui existent déjà. Rester à jour ferme les points d'entrée qui rendent la force brute rentable en premier lieu.

Le cœur de WordPress gère les mises à jour de version mineure automatiquement par défaut. Les versions majeures nécessitent une action manuelle ou un paramètre de mise à jour automatique explicite dans votre tableau de bord d'hébergement.

Les mises à jour automatiques par plugin sont disponibles directement dans wp-admin. Allez dans Plugins » Plugins installés, et vous verrez un commutateur Activer les mises à jour automatiques dans la colonne de droite pour chaque plugin.

Pour la plupart des sites, activer les mises à jour automatiques sur tous les plugins actifs est la bonne décision. Le risque d'une mise à jour problématique est réel mais bien moindre que le risque d'exécuter un plugin avec une vulnérabilité connue pendant des semaines après la publication d'un correctif.

Les thèmes suivent la même logique. Un thème inactif sur votre serveur avec une vulnérabilité non corrigée est toujours exploitable, même s'il n'est pas le thème actif.

Supprimez tout ce que vous n'utilisez pas. Désactivé ne signifie pas sécurisé.

Il en va de même pour les extensions. Les fichiers d’une extension désactivée sont toujours sur le serveur et toujours accessibles. S’il existe une vulnérabilité dans ces fichiers, elle peut être exploitée, que l’extension soit active ou non dans WordPress.

Si vous n’utilisez pas une extension, supprimez-la complètement plutôt que de la laisser désactivée.

Pour les équipes gérant plusieurs sites, des outils comme ManageWP, MainWP et Jetpack Manage vous permettent de surveiller et d’appliquer les mises à jour sur tous les sites à partir d’un tableau de bord unique. Effectuer les mises à jour un site à la fois sur dix ou vingt installations est le genre de friction qui entraîne des correctifs manqués.

Couche 9 : Sauvegardez votre site et sachez comment le restaurer

Le guide de renforcement contre les attaques par force brute de WordPress.org le dit clairement : conservez des sauvegardes testées et capables de fonctionner hors ligne, et répétez vos procédures de restauration.

Chaque couche avant celle-ci réduit le risque. Celle-ci élimine le pire scénario.

Si un attaquant parvient à franchir toutes les autres couches, une sauvegarde récente fait la différence entre une récupération d’une heure et une reconstruction totale. La sauvegarde n’empêche pas la violation. Elle détermine la gravité réelle de la violation.

« Testées » est le mot le plus important dans cette phrase. Tester signifie effectuer une restauration sur un environnement de staging, confirmer que le site fonctionne correctement et connaître exactement les étapes du processus avant de devoir le faire sous pression.

Planifiez un test de restauration trimestriellement. Cela prend moins d’une heure et élimine toute incertitude au pire moment.

Automatisez les sauvegardes et les restaurations avec Duplicator

Ce qui rend une sauvegarde utile spécifiquement dans un scénario de violation par force brute : elle doit être hors site, indépendante du serveur compromis, avec un chemin de restauration qui fonctionne même lorsque WordPress est complètement verrouillé.

Duplicator Pro répond à chacune de ces exigences.

Les sauvegardes automatiques planifiées s’exécutent à intervalles horaires, quotidiens, hebdomadaires ou mensuels sans intervention manuelle. Vous définissez la planification une fois et disposez toujours d’un point de restauration récent.

Pour le stockage, Duplicator Pro se connecte à Amazon S3, Google Drive, Dropbox, OneDrive et d’autres services cloud tiers.

Duplicator Cloud est le propre stockage de Duplicator : aucun compte séparé requis, aucun service tiers à configurer. Contrairement à d’autres options, il a été spécialement conçu pour le stockage des sauvegardes WordPress.

Si quelque chose de grave se produit, vous pouvez restaurer directement depuis le stockage cloud sans avoir à re-télécharger les fichiers sur le serveur au préalable. Lorsque votre serveur est compromis et que vous ne faites pas confiance à ce qu’il contient, vous récupérez la restauration directement à partir de la copie cloud.

Les URL de récupération d’urgence sont la partie que la plupart des gens ignorent jusqu’à ce qu’ils en aient besoin. Après une attaque par force brute réussie, l’une des premières choses qu’un attaquant fait est de changer le mot de passe administrateur ou de créer de nouveaux comptes et de verrouiller le propriétaire d’origine.

Une URL de récupération d’urgence contourne complètement wp-admin, vous permettant d’initier une restauration même lorsque vous ne pouvez pas vous connecter. Je l’ai utilisée une fois lors d’un incident réel. C’est la fonctionnalité qui fait la différence entre une récupération en une heure et une journée passée au téléphone avec le support d’hébergement.

La restauration en un clic gère les récupérations standard sans transferts de fichiers manuels ni accès FTP. Sélectionnez la sauvegarde, cliquez sur restaurer, et confirmez. C'est le processus.

Comment surveiller l'activité de force brute

La plupart des propriétaires de sites WordPress découvrent qu'ils sont attaqués par un avis de limitation de leur fournisseur d'hébergement, et non par leur propre surveillance. À ce moment-là, l'attaque a déjà consommé les ressources du serveur, rempli vos journaux de bruit et, dans certains cas, réussi.

La mise en place d'une visibilité proactive prend moins d'une heure et vous permet de savoir ce qui se passe sur votre site avant votre hébergeur.

Surveillance proactive

Le Journal d'activité vous fournit une piste d'audit complète de chaque action effectuée sur votre site, telles que les tentatives de connexion échouées, les connexions réussies, les changements de rôles d'utilisateur, les activations et désactivations de plugins, les modifications de paramètres et les modifications de fichiers.

Cette portée est importante après une violation par force brute. Un attaquant qui pénètre dans le système ne se contente pas de se connecter ; il apporte des modifications.

Le Journal d'activité affiche ces modifications dans une chronologie lisible afin que vous puissiez voir exactement ce qui s'est passé et dans quel ordre. C'est l'information dont vous avez besoin pour évaluer les dégâts et savoir quoi nettoyer.

Demandez au Journal d'activité de vous envoyer des alertes par e-mail pour toute activité de connexion inhabituelle. Cela vous aidera à identifier et à arrêter immédiatement une attaque par force brute au lieu de nettoyer après coup.

Votre panneau de contrôle d'hébergement est une autre couche de surveillance. Des pics inexpliqués de processus PHP ou d'utilisation du processeur en dehors des heures normales sont souvent le premier signe visible d'une attaque à haut volume, apparaissant avant que votre plugin de sécurité n'ait enregistré suffisamment d'événements pour déclencher une alerte.

Signes que vous êtes déjà attaqué

Certaines attaques s'annoncent. D'autres sont plus discrètes.

Une augmentation soudaine des notifications de tentatives de connexion échouées dans votre journal d'activité est le signal le plus clair. Si vous voyez normalement deux ou trois tentatives échouées par jour et que vous en voyez soudainement des centaines, quelque chose a changé.

Les avis de verrouillage de la part d'utilisateurs qui n'ont pas réellement essayé de se connecter sont un signe plus subtil. Les verrouillages basés sur IP affectent tous les utilisateurs partageant cette IP : un bureau d'entreprise ou un réseau universitaire où une personne déclenche un verrouillage peut bloquer tous les autres sur la même connexion.

Si votre boîte de réception de support commence à se remplir de messages « Je ne peux pas me connecter » de personnes qui n'essayaient pas de réinitialiser leur mot de passe, vérifiez votre journal de verrouillage.

Une réponse lente de wp-admin ou des erreurs d'épuisement des processus PHP dans le journal d'erreurs de votre hébergement indiquent une consommation de ressources due à une attaque à haut volume. Le site fonctionne toujours, mais il est plus lent que prévu, et les journaux expliquent pourquoi.

Après tout incident de sécurité, allez dans Utilisateurs » Tous les utilisateurs dans wp-admin et filtrez par le rôle Administrateur.

Un compte administrateur non autorisé créé pendant une fenêtre d'attaque est un signe que l'attaquant a réussi et s'est laissé une porte dérobée. Vérifiez cela avant de considérer un incident comme clos.

Ce qui ne fonctionne pas (et pourquoi les gens le recommandent toujours)

Certains des conseils de sécurité WordPress les plus couramment répétés semblent raisonnables mais offrent peu de protection réelle. Connaître la différence vous évite l'effort de mettre en œuvre des choses qui donnent un faux sentiment de sécurité.

Géo-blocage par pays

L'attrait est évident : si la plupart de vos attaques proviennent d'un pays spécifique, bloquez ce pays. Le problème est que les botnets ne fonctionnent pas de cette façon.

Un botnet est un réseau de machines compromises : routeurs domestiques, serveurs, appareils IoT, ordinateurs ordinaires infectés par des logiciels malveillants. Ces machines sont partout, y compris dans votre propre pays.

Bloquer le trafic de la Russie ou de la Chine n'arrête pas un botnet ayant des nœuds aux États-Unis, au Royaume-Uni et en Australie. Cela bloque les visiteurs légitimes de ces pays. Pour la plupart des sites, le compromis n'en vaut pas la peine.

Protéger wp-admin par mot de passe avec authentification HTTP

Ajouter une deuxième invite de mot de passe avant le répertoire wp-admin semble être une couche supplémentaire utile. En pratique, cela peut casser l'AJAX de WordPress, dont wp-admin dépend pour les fonctionnalités de base, y compris la sauvegarde des articles, l'exécution des paramètres des plugins et la gestion des téléchargements de médias.

Les sites qui implémentent cela correctement avec des exclusions AJAX prudentes peuvent le faire fonctionner, mais pour la plupart des propriétaires de sites, la complexité de la configuration l'emporte sur l'avantage.

Questions fréquemment posées (FAQ)

Avant la prochaine attaque, assurez-vous de pouvoir vous en remettre

Les attaques par force brute coûtent de moins en moins cher à exécuter. Les botnets basés sur le cloud, les bases de données d'identifiants issues d'années de violations accumulées et les services de résolution de CAPTCHA ont tous réduit le coût d'exécution d'une attaque soutenue contre un site WordPress à presque zéro.

Chaque couche de protection de cet article réduit votre risque. Aucune d'entre elles ne le réduit à zéro. La seule garantie qu'une attaque réussie ne mette pas fin à votre site est une sauvegarde testée que vous pouvez restaurer, même lorsque wp-admin est complètement verrouillé.

Plus de 1,5 million de professionnels WordPress utilisent Duplicator Pro pour exactement cela : des sauvegardes automatiques planifiées vers Duplicator Cloud ou tout fournisseur de stockage cloud majeur, une récupération à distance sans re-télécharger les fichiers sur un serveur compromis, et des URL de reprise après sinistre qui restaurent votre site même lorsque vous ne pouvez pas vous connecter.

Si cet article vous a fait réfléchir à la sécurité et à la récupération de WordPress, ces guides méritent d'être lus ensuite.

• Comment protéger votre site Web contre les pirates informatiques (Guide ultime de sécurité)
• WordPress est-il sécurisé ? La vérité révélée
• Checklist de sécurité WordPress : Guide étape par étape pour protéger votre site
• Comment récupérer un site WordPress piraté (9 conseils d’experts)
• Comment nettoyer un site WordPress
• Maîtriser le débogage WordPress : des bases aux techniques avancées
• 9 meilleurs plugins de sauvegarde de base de données WordPress (pour sécuriser vos données)