Règles de pare-feu Cloudflare pour sécuriser WordPress

Contenus de la page

J’utilise Cloudflare pour tous mes sites Web WordPress – non seulement pour les rendre plus rapides, mais aussi plus sécurisés.

Le pare-feu d’application Web (WAF) de Cloudflare fournit une couche de sécurité supplémentaire pour vos sites Web.

Base de connaissances Cloudflare

Comment utiliser Cloudflare pour sécuriser votre site WordPress

Ce guide est destiné aux webmasters soucieux de la sécurité qui gèrent un site ou un blog WordPress sur un domaine compatible Cloudflare. Sur le plan gratuit, Cloudflare accorde cinq règles de pare-feu qui sont vides par défaut.

En ajoutant des règles spécifiques à WordPress que je décris sur cette page, vous pouvez sécuriser votre site et bloquer les attaques avant même qu’elles n’atteignent le serveur de votre hébergeur.

Avis de non-responsabilité : Je ne suis en aucun cas affilié à Cloudflare, mais je suis un utilisateur satisfait de leurs services depuis plusieurs années.

Ajoutez votre adresse IP à la liste blanche

Avant d’implémenter des règles de pare-feu, vous devez d’abord ajouter votre propre IP à la liste blanche. De cette façon, vous ne serez pas affecté si vous décidez de bloquer votre zone d’administration WordPress aux étrangers (ce que j’expliquerai dans une minute).

Cela peut être fait en accédant à votre tableau de bord Cloudflare et en cliquant sur pare-feualors Outilsen saisissant votre adresse IP* et en choisissant liste blanche dans le menu déroulant.

Liste blanche d’une IP dans CloudFlare Firewall.

*Vous avez ici plusieurs choix dans l’ordre de sécurité décroissante :

Ajoutez votre exactement Adresse IP. Choix optimal si votre FAI vous accorde une adresse IP statique. Notez que si votre adresse IP change, vous devrez la ressaisir pour ne pas être bloqué hors de votre zone d’administration WordPress.
Ajoutez à la liste blanche toute la plage d’adresses IP de votre FAI. Bon choix si vous avez une adresse IP dynamique.
Ajoutez votre pays à la liste blanche. Cela ne vous protégera pas des attaques provenant de votre propre pays, mais cela peut être une option pratique si vous voyagez fréquemment et utilisez le Wi-Fi pour vous connecter à votre site WordPress.

Une adresse IP ou un pays sur liste blanche de cette manière sera exempté de tout règles de pare-feu, vous n’aurez donc pas besoin d’ajouter des exceptions pour chaque règle individuelle.

Si vous jetez un coup d’œil aux journaux de votre serveur, vous trouverez probablement de nombreuses adresses IP du monde entier essayant d’accéder à votre fichier wp-login.php. C’est de loin l’attaque la plus courante sur les installations WordPress. Ce sont généralement des analyses automatisées qui ne représentent pas une grande menace, mais vous pouvez toujours les bloquer pour votre tranquillité d’esprit.

Cela suppose bien sûr que vous (l’administrateur) êtes le seul utilisateur de votre site. Si vous avez plusieurs utilisateurs ou utilisez un plugin d’adhésion, vous voudrez probablement ignorer cette règle.

Dans votre tableau de bord Cloudflare, cliquez sur pare-feu encore une fois, puis appuyez sur le bleu Créer une règle de pare-feu bouton. Nommez-le comme vous voulez et entrez ce qui suit :

Champ : chemin URI
Opérateur : contient
Valeur : /wp-login.php

[Action: Block]

Faites défiler pour continuer

Si vous l’avez bien fait, vous devriez voir ce qui suit dans le Aperçu des expressions section.

(http.request.uri.path contains "/wp-login.php")

Enregistrez la règle et elle devrait être activée automatiquement. Cloudflare bloquera désormais toutes les tentatives de connexion à wp-login.php, sauf à partir de l’adresse IP que vous avez ajoutée à la liste blanche.

Ces tentatives de force brute disparaîtront des journaux de votre serveur, mais vous pourrez les suivre sur Cloudflare. Événements de pare-feu section si vous souhaitez vérifier que la protection fonctionne.

2. Bloquer les attaques xmlrpc.php

Après wp-login.php, xmlrpc.php est la deuxième cible d’attaque la plus courante. XML-RPC a des utilisations légitimes, telles que les blogs à partir d’un smartphone ou la publication de contenu sur plusieurs sites WordPress à la fois. Si vous ne le faites pas, il peut être bloqué en toute sécurité. Suivez la même procédure que précédemment et créez la règle :

Champ : chemin URI
Opérateur : contient
Valeur : /xmlrpc.php

[Action: Block]

Vous devriez voir ce qui suit dans le Aperçu des expressions section.

(http.request.uri.path contains "/xmlrpc.php")

3. Protégez la zone wp-admin

Maintenant, faisons en sorte que vous et vous seul puissiez accéder à votre zone d’administration. Cette règle est légèrement plus complexe car vous devez faire deux exceptions.

Le premier est /wp-admin/admin-ajax.php, qui est utilisé par certains plugins pour afficher du contenu dynamique sur votre site Web. En tant que tel, bien qu’il soit situé dans le dossier /wp-admin/, il doit être accessible de l’extérieur.

Le second est /wp-admin/theme-editor.php, qui exécute une vérification d’erreur chaque fois que vous modifiez votre thème via l’éditeur intégré en créant une demande de bouclage vers votre page d’accueil. Si vous n’ajoutez pas cette exception, la vérification échouera avec un message « Impossible de communiquer avec le site pour vérifier les erreurs fatales » et vos modifications ne seront pas enregistrées.

Allez-y et créez la règle suivante :

Champ : chemin URI
Opérateur : contient
Valeur : /wp-admin/

[AND]

Champ : chemin URI
Opérateur : ne contient pas
Valeur : /wp-admin/admin-ajax.php

[AND]

Champ : chemin URI
Opérateur : ne contient pas
Valeur : /wp-admin/theme-editor.php

[Action: Block]

Ou cliquez simplement Modifier l’expression et coller dans ce qui suit.

(http.request.uri.path contains "/wp-admin/" and not http.request.uri.path contains "/wp-admin/admin-ajax.php" and not http.request.uri.path contains "/wp-admin/theme-editor.php")

4. Bloquer les requêtes sans référent aux plugins

La plupart des sites WordPress sont piratés via des plugins sécurisés. La meilleure approche, bien sûr, n’est pas de les installer en premier lieu, mais vous pouvez également créer une règle de pare-feu bloquant l’accès direct à /wp-content/plugins/.

Les requêtes légitimes qui transitent par votre site Web ont quelque chose comme « http://votresite.com/page » comme référent HTTP et doivent être autorisées. Vous pouvez également autoriser les bons robots connus (tels que le robot d’exploration Google) au cas où ils essaieraient d’indexer quelque chose, comme une image, dans votre dossier de plugins.

Créez la règle suivante :

Champ : chemin URI
Opérateur : contient
Valeur : /wp-content/plugins/

[AND]

Champ : Référent
Opérateur : ne contient pas
Valeur : votresite.com (remplacer par votre vrai domaine)

[AND]

Champ : Robots connus
Opérateur : égal
Valeur : Désactivé

[Action: Block]

Ou, collez simplement cette expression directement (n’oubliez pas de remplacer votresite.com par l’adresse réelle).

(http.request.uri.path contains "/wp-content/plugins/" and not http.referer contains "yoursite.com" and not cf.client.bot)

5. Réduisez le spam en bloquant les demandes directes vers wp-comments-post.php

Je vais être honnête : l’effet de cette règle sera minime, car les spambots sont aujourd’hui suffisamment sophistiqués pour usurper le référent. Cela ne bloquera que les robots martelant directement le fichier wp-comments-post.php. Pourtant, le même conseil est décrit dans WordPress Codex (sauf qu’ils utilisent une règle .htaccess plutôt que Cloudflare), donc si c’est assez bon pour eux, c’est assez bon pour moi.

La règle est la suivante :

Champ : chemin URI
Opérateur : égal
Valeur : /wp-comments-post.php

[AND]

Champ : Méthode de requête
Opérateur : égal
PUBLIER

[AND]

Champ : Référent
Opérateur : ne contient pas
Valeur : votresite.com (remplacer par votre vrai domaine)

[Action: Block]

Et voici l’expression pour vous faire gagner du temps.

(http.request.uri.path eq "/wp-comments-post.php" and http.request.method eq "POST" and not http.referer contains "yoursite.com")

Votre site Web est maintenant légèrement plus sécurisé !

Ces cinq règles devraient couvrir les attaques WordPress les plus courantes, mais n’hésitez pas à les ajuster et à les combiner en fonction de vos besoins.

La plupart des attaques que vous voyez dans vos journaux proviennent de robots automatisés qui analysent simplement les sites Web à la recherche de vulnérabilités, mais si une personne extérieure à vos adresses IP sur liste blanche tente d’accéder à votre zone d’administration, elle sera accueillie par une page « Erreur 1020 » comme celle-ci (vous pouvez confirmez-le en y accédant via un proxy ou un VPN).

Il s’agit de la page qu’un attaquant potentiel verra après avoir déclenché l’une de vos règles de pare-feu.

Lectures complémentaires

Si vous rencontrez des problèmes ou souhaitez en savoir plus, je vous suggère de consulter la base de connaissances de Cloudflare.

Cet article est exact et fidèle au meilleur de la connaissance de l’auteur. Le contenu est uniquement à des fins d’information ou de divertissement et ne remplace pas un conseil personnel ou un conseil professionnel en matière commerciale, financière, juridique ou technique.

questions et réponses

Question: Pouvons-nous combiner toutes les demandes ci-dessus en une seule règle ?

Réponse: Bien sûr. Mettez chaque règle individuelle entre parenthèses et joignez-les avec « ou » (si votre action est de bloquer).

Question: À propos de la règle pour bloquer les demandes sans référent aux plugins. J’ai remarqué que vos instructions pour construire la règle utilisent le chemin URI « /wp-content/plugins/ » mais l’expression que vous fournissez utilise le chemin URI « /plugins/ ». Pouvez-vous s’il vous plaît confirmer quelle valeur de chemin d’URI est correcte ?

Réponse: Belle prise, je vais les modifier pour correspondre. En ce qui concerne votre question, à moins que vous n’ayez renommé votre dossier /wp-content/ ou que vous ayez un autre dossier non-Wordpress nommé /plugins/ pour une raison quelconque, peu importe celui que vous utilisez.

Dario Cedeno V. le 31 août 2020 :

Les règles wp-comments-post.php semblent n’avoir aucun impact sur la génération de spam, nous devrions probablement trouver un meilleur blocage sur les commentaires.

Andrew Po (auteur) le 10 août 2020 :

Vous pouvez simplement rechercher sur Google « quelle est mon IP ».

daniel vilenchik le 05 août 2020 :

Comment suis-je censé connaître mon adresse IP et de quel type s’agit-il ?

Andrew Po (auteur) le 22 février 2020 :

C’est juste une question d’utiliser des parenthèses pour regrouper les expressions. Je n’ai pas testé mais ceci devrait fonctionner :

((http.request.uri.path contient « /wp-admin/ » et non http.request.uri.path contient « /wp-admin/admin-ajax.php » et non http.request.uri.path contient » /wp-admin/theme-editor.php »)) et (ip.geoip.country ne « FR » et ip.geoip.country ne « CA »)

Andrew Po (auteur) le 03 décembre 2019 :

A la fin de wp-login.php ? Lorsque vous utilisez « contient » au lieu de « égal », bien sûr, vous pouvez le supprimer.

Mais accéder à /wp-login sans le .php devrait renvoyer un 404, il ne devrait donc pas y avoir beaucoup de raisons de bloquer cela en premier lieu.

David Elstob le 01 décembre 2019 :

J’ai suivi un didacticiel ailleurs et j’ai immédiatement commencé à obtenir des résultats sur /wp-login.

Cependant, la règle du plugin m’a causé des problèmes… parce qu’ils ont raté les Known Bots contrairement à vous, merci.

La seule chose que je suggère est – avez-vous réellement besoin du .php à la fin parce que tout le monde ne le tapera pas? Alors, pourriez-vous manquer quelques hits?

julien le 30 avril 2019 :

Un grand merci pour ce guide facile à suivre sur la configuration des règles de pare-feu CloudFlare pour renforcer WordPress avec une plus grande sécurité. Ces instructions claires m’ont permis de créer des règles de pare-feu en toute confiance. Merci!