Article mis à jour le 24 juillet 2014 pour ajouter la désactivation de XMLRPC lorsque celui-ci n’est pas utilisé.
Une attaque par force brute est lorsqu’une personne essaie de trouver votre mot de passe en essayant toutes les combinaisons possibles.
Pour vous protéger de ces attaques, vous devez installer et activer le plug-in « Limit login attempts » :
Correctif : Nous conseillons désormais BruteProtect à la place de Limit Login Attempts et de laisser XMLRPC actif si vous installez JetPack. Bruteprotect sera bientôt dans JetPack et réduit les ressources utilisées lors d’une attaque rendant inutile la désactivation de XMLRPC.
Puis, si vous ne l’utilisez pas désactivez XMLRPC en installant et en activant le plugin suivant :
https://wordpress.org/plugins/disable-xml-rpc/
En effet beaucoup de plugins qui détectent les attaques force brute ne vérifient pas les tentatives de connexions par XMLRPC.
Pour éviter d’utilser des ressources pour ces accès, vous vous conseillons d’ajouter les lignes suivantes en haut de votre fichier .htaccess :
Avec le plugin Bruteprotect les ressourources utilisées sont réduites et XMLRPC est nécessaire pour utiliser JetPack
Vous devez aussi vous assurer que votre nom d’utilisateur n’est pas « admin » et que votre mot de passe n’est pas trop simple.
- Connectez-vous avec PHPMyAdmin depuis votre interface cPanel
- Cliquez sur le nom de votre base de données puis sur la table wp_users.
- Pour éviter que votre nom d’utilisateur ne soit affiché en public, laissez user_nicename en « admin » mais modifiez user_login pour avoir un nom d’utilisateur que personne ne peut deviner.
Votre site est maintenant protégé contre les attaques par force brute, un attaquant ne pourra donc pas trouver votre mot de passe de cette manière… mais un attaquant ne le saura peut-être pas et en lançant une attaque il ralentra votre site.
Pour y remédier :
Ajoutez les lignes suivantes tout au début de votre fichier .htaccess (avant le code de WordPress mais après le code XMLRPC) :
[pastacode lang= »bash » message= » » highlight= » » provider= »manual »]
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_COOKIE} !^.*cookie\-mona\-securisation=4532698754.*$ [NC]
RewriteRule wp-login.php - [F]
</IfModule>
[/pastacode]
Ensuite créez un nouveau fichier php que vous allez nommer avec un nom que vous allez choisir par exemple :
se-connecter-a-mon-blog.php
Dans ce fichier, collez le code suivant :
[pastacode lang= »php » message= » » highlight= » » provider= »manual »]
[/pastacode]
Pour tester, commencez par essayer de vous connecter à votre login avec wp-login.php, vous devez voir une page erreur 403 :
Ensuite, appelez dans votre navigateur votre nouveau fichier PHP, par exemple :
http://URL-DE-VOTRE-SITE-WORDPRESS/se-connecter-a-mon-blog.php
Vous pourrez alors vous connecter ! Toute personne qui ne passe pas par cette URL aura l’erreur 403 évitant ainsi de charger Wordpress.
C’est un systeme de defence trés inteligent, bravo et concepteur et Merci pour l’article.
Est-ce qu’une application simple comme Lastpass ne fera pas l’affaire contre les phishing et les brutes forces ?
Bonjour,
Un outil comme Lastpass ou 1Password permet d’avoir des mots de passe très longs, de ne jamais les saisir au clavier et donc de réduire la possibilité d’une intrusion de type brute force.
Des mots de passe de 50 caractères aléatoires peuvent donc réduire la nécessité d’utiliser un plugin comme limit login attempts.
Une autre solution efficace est la double authentication :
https://wordpress.org/plugins/wp-google-authenticator/
https://wordpress.org/plugins/yubikey-plugin/
Avec la double authentification le plugin limit login attempts devient inutile. À vérifier si xmlrpc.php est protégé par les plugins de double authentification ou s’il faut le désactiver.
Des mots de passe très longs ou la double authentification n’aideront pas par contre à arrêter une attaque qui ralentit votre site. Pour cela la meilleure protection actuellement est la technique que nous proposons qui consiste à renommer wp-login.php sans altérer de fichiers ou le fonctionnement de WordPress. Cette protection ne sécurise pas, mais est efficace pour éviter de lancer WordPress à chaque tentative d’un robot faisant une attaque brute force.
Bonsoir,
Merci pour c’est conseils précieux !
Cependant, que faire lorsqu’il est trop tard et que son site est infecté ?
La solution la plus radicale est de tout supprimer et réinstaller mais existe-il un moyen de trouver les fichiers infectés et de les supprimer ?
Bonsoir,
Lorsqu’il est trop tard et le site est infecté, il est difficile de savoir s’il y a des fichiers cachés permettant au pirate d’entrer à nouveau. La meilleure solution est donc de télécharger et envoyer sur le FTP une version propre de WordPress, des plug-ins et du thème, de vérifier que le dossier uploads ne contient aucun fichier PHP ou autre script et vérifier le contenu de tous les fichiers .htaccess, et restaurer juste le dossier uploads. Ensuite, il faut vérouiller l’accès au dossier public avec un fichier .htaccess (deny from all et allow from votre.adresse.i.p), se connecter, supprimer tous les utilisateurs ou au moins modifier leurs mots de passe et vérifier leurs adresses e-mails, puis appliquer les mesures de sécurité conseillées ci-dessus. Si le WordPress a été installé proprement et que le thème n’a pas été modifié directement sans créer un thème enfant, cela se passe sans perdre de contenu.
Nous avons par ailleurs remplacé Limit Login Attempts par Brute Protect dernièrement puisque celui-ci appartient maintenant à Automattic (WordPress.com). Je vais mettre à jour notre article !
Merci !!
Merci pour cet article ..
j ai protégé le site d un de mes client avec Worldfence et WPSecureOps BruteForce Protect est ce suffisant ?.
Ce plugin semble protéger par mot de passe .htacces votre dossier wp-admin, il ne parle pas de protection brute force.
La solution que nous conseillons actuellement est de rendre wp-login.php inaccessible par l’URL normale, soit avec les règles .htaccess que nous vous conseillons, soit avec un plugin comme sf-move-login. Cela permet d’éviter 95% des attaques brute force. Ensuite un simple plugin comme login lockdown est suffisant pour se protéger votre les 5% restants. Nous interdisons aussi l’accès au fichier xmlrpc.php puisque nous avons abandonnée Jetpack sur les sites que nous gérons directement.
Hi Rouen,
Our plugin (WPSecureOps BruteForce Protect) will only protect your wp-login.php from getting attacked by bots trying to randomly guess your passwords.
We’d created a separate plugin (WPSecureOps Easy Firewall) that does XMLRPC disabling and most of the officially recommended steps out of WordPress’s guide for securing your blog, but using our plugin all of those steps are just a matter of ticking a checkbox (no coding required!).
So, please free to test it out: https://wordpress.org/plugins/wpsecureops-easy-firewall/
Cheers,
WPSecureOps Team
Merci pour le conseil…. un de mes sites était entrain de subir une attaque force brute avec des centaines de tentatives, j’utilisais le plugin Limits login attemps mais sans arriver à stopper les attaques… là avec ta solutions c’est radical et vraiment simple à mettre en oeuvre.
Aprés j’ hésite de passer à BruteProtect , le plugin n’est pas mis jour depuis 3 mois… et pas tester avec la derniére version de wordpress
En tout cas merci pour le tip… 😀
Bonjour,
Malheureusement BruteProtect est maintenant intégré dans JetPack sous le nom de Protect. Nous ne le conseillons plus puisque nous n’aimons pas avoir les appels extérieurs à JetPack. Limit login attempts n’étant plus maintenu, nous conseillons login lockdown. Nous conseillons aussi la désactivation du XMLRPC dans la mesure du possible (incompatible avec JetPack) et depuis la version 4.2 le plugin disable emojis.
Bonjour,
J’ai voulu tester « Protect » sur les quelques WordPress sur lesquels j’ai installé JetPack et franchement, … je n’ai absolument pas été convaincu car il devient difficile de pouvoir se connecter à son site, même avec les bons codes, alors tout comme vous, je déconseille.
Je vais donc essayer de mettre en place votre préconisation pour stopper les attaques de brute force que je limite jusqu’ici avec Wordfence qui dispose d’une fonctionnalité de blocage d’IP au bout d’un certain nombre de tentatives infructueuses (à paramétrer).
Cordialement,
Bruno
Bonsoir,
Nous allons bientôt réécrire cet article.
Nous préconisons :
1) De rendre inaccessible xmlrpc.php
2) De renommer l’URL de wp-login.php avec notre méthode de cookie et .htaccess si votre version d’Apache est compatible
3) D’installer un plugin de protection contre les attaque brute force comme le plugin Login Lockdown par exemple.
L’avantage de rendre inaccessibles xmlrpc.php et wp-login.php est d’éviter d’appeler PHP lors d’une attaque par force brute sur ces fichiers. Le serveur web que nous proposons avec nos hébergements est capable de résister à des attaques relativement importantes (plusieurs milliers de requêtes simultanées) alors que si PHP était appelé avec en prime tout WordPress cela pourrait ralentir le site, voir même si le serveur n’est pas cloisonné tout le serveur.
Notre expérience avec BruteProtect était bonne, mais vu qu’il est maintenant intégré dans JetPack, que JetPack nécessite d’avoir le fichier xmlrpc.php accessible et que le nombre d’attaques sur ce fichier augmentent régulièrement, nous conseillons maintenant d’utiliser Login Lockdown et notre astuce de Cookie pour renommer le fichier wp-login.php ainsi que les lignes suivantes pour interdire l’accès à xmlrpc.php :
ErrorDocument 403 « Forbidden »
Order Allow,Deny
deny from all
WordPress déconseille de le faire, mais nous estimons que la sécurité de xmlrpc.php est dépassé et qu’il vaut mieux de le désactiver en attendant que WordPress décide d’implémenter une solution sécurisée à base de celfs uniques par application.
Merci pour tout ces très bons conseil
Je vous recommande l extension itheme security ,c est simple et intuitif …
Ce plugin détecte les problèmes il y a juste à cliquer afin de les corriger …si vous n êtes pas sur de ce vous faite ne touchez pas aux option avancés …
je n ai pas trouvé plus complet pour la sécurité à ce jour…
Bonjour,
Nous avions testé ce plugin à l’époque où il était nommé better WP security et nous ne l’avons pas retenu. À l’époque il avait tendance à bloquer tout accès à quelques sites lorsqu’il faisait une erreur de mise à jour de fichier .htaccess. Cela ne se produisait pas régulièrement et pas sur tous les sites mais suffisament pour ne pas le conseiller.
Cordialement,
Richard Hordern
je trouve Itheme security simple d utilisation,complèt, fiable il est également extrêmement bien noté par les utilisateurs….
il détecte ce qui ne va pas ,il y a juste à cliquer afin de corriger les problèmes ..
Cette extension permet également de renommer le compte Admin ,de modifier votre .htacess ….
Depuis wp better security ce plugin a évolué ,j utilise également Wordfence pour sécuriser les sites de mes clients.
Bonjour,
Il est possible qu’il ait été amélioré, mais comme nous avons déjà vu des problèmes causés par ce plugin nous ne le conseillons pas.
Bonjour,
Moi aussi j’avais testé pendant plusieurs mois better WP security, mais j’ai fini par l’abandonner, car c’était une véritable usine à gaz.
En plus, cette extension créait des conflits avec d’autres, alors on n’est pas prêt de m’y reprendre, car j’ai trop été déçue et ennuyée.
Biz 😉
Bonjour
Quel soucis avez vous rencontré avec le plugin de sécurité Itheme sécurity….
je l utilise pour sécuriser tout les sites de mes clients et je n ai jamais rencontré de problème….
Cordialement
Il y a plusieurs années nous le conseillions, mais avons changé d’avis lorsqu’il a corrompu plusieurs fichiers .htaccess de nos clients rendant leur sites inaccessibles.
Beaucoup de ce que fait cette extension est déjà fait par le parfeu mod security que nous utilisons.
Beaucoup de nos clients utilisent WordFense, mais c’est un peu le même problème, c’est aussi une usine à gaz qui peut parfois provoquer des dysfonctionnements.
Nous recommandons maintenant :
Si vous faites les points mentionnés ci-dessus, vous ne prenez pas de risque.
Merci Monarobase
Je ne connaissais pas le parfeu mod security je vais tester ca ..
Lorsque j utilise Itheme security j ai constaté des petit soucis avec les permaliens …
Bonjour,
Mod Security est une sécurité installé au niveau du serveur web cela n’est pas un simple plugin que vous pouvez installer, votre hébergeur doit donc le proposer.
je trouve que Jetpack alourdi et ralenti le temps de chargement …j utilise Wp super cache pour accélérer le temps de chargement ..
Le temps de chargement d un site web est tres important …
Bonjour,
Je suis entièrement d’accord avec vous. Nous déconseillons aussi l’utilisation de Jetpack. Si vous avez un hébergement chez nous, privilègez LiteSpeed Cache à la place de WP Super Cache, en effet il utilise directement le cache de notre serveur web et est beaucoup plus performant que WP Super Cache.
Bonjour,
j’utilise le truc du cookie pour le login et une règle htaccess pour l’accès au xmlrpc.php (allow iprange) mais je ne sais plus utiliser Open Live Writer pour créer un post… qui est une méthode alternative pour moi (j’utilise le mail comme méthode habituelle)…
Est-il possible de concilier les deux de façon un peu safe ?
Merci de votre aide
Eric Collart
Bonjour,
Dans ce cas la seule solution est de laisser xmlrpc.php accessible.
Utilisez un plug-in comme Loginizer pour limiter les tentatives de connexion, et si vous hébergez votre site chez nous, nous détectons la majorité des attaques sur ce fichier et les bloquons.