Comment arrêter la force brute et les robots sur WooCommerce sans Wordfence

La semaine dernière, une connaissance m'a écrit - le propriétaire d'un magasin de pièces automobiles en ligne sur WooCommerce. Il écrit : "Oleg, mon site est lent, l'hébergement se plaint de la charge, mais je n'ai rien changé." J'entre pour voir un tableau classique. Au cours des dernières 24 heures, soixante mille requêtes adressées à wp-login.php ont été entassées dans le fichier access.log. Soixante mille. À partir de deux cents adresses IP différentes. Quelqu'un essaie méthodiquement les mots de passe - admin, administrateur, boutique, manager, test, 123456 - en cercle, sans s'arrêter. Les robots fonctionnent comme une montre suisse : trois à quatre requêtes par seconde, juste assez pour ne pas tomber sous la protection primitive de limite de débit de l'hébergement, mais suffisamment pour que le serveur s'étouffe en traitant les requêtes PHP.

Mon premier conseil instinctif a été « installez Wordfence ». C'est un réflexe, non ? La sécurité WordPress signifie Wordfence. Je l’ai pensé moi-même pendant des années. Mais ensuite je me suis arrêté et je me suis posé une question qui aurait dû être posée il y a longtemps : Wordfence est-il vraiment le seul moyen de se protéger contre la force brute ? Et est-ce vraiment la meilleure solution pour une boutique WooCommerce avec ses charges de travail et ses exigences spécifiques ? Honnêtement, plus je creusais, plus je devenais convaincu que pour les sites commerciaux sur WooCommerce, Wordfence, c'est comme tirer des moineaux avec un canon. Oui, vous le ferez. Mais en même temps, vous détruirez la moitié du mur.

Laissez-moi vous dire ce à quoi je suis arrivé après plusieurs années de lutte avec les robots et la force brute sur de vrais projets WooCommerce - et pourquoi, à un moment donné, j'ai abandonné les lourds plugins de sécurité universels au profit de solutions intégrées basées sur des points. Il ne s'agit pas d'une comparaison théorique des « dix meilleurs plugins de sécurité » : il s'agit d'une expérience avec des magasins industriels qui proposent seize mille produits, deux mille visiteurs par jour et une tolérance zéro pour les temps d'arrêt.

Pourquoi Wordfence n'est plus mon choix par défaut

Je ne vais pas dire que Wordfence est un mauvais produit. Ce ne serait pas juste. Wordfence est un outil puissant, mature et bien pris en charge, doté d'une énorme base de données de signatures. Le problème est différent : il a été conçu comme une solution universelle pour tout site WordPress, du blog d'une femme au foyer au portail d'entreprise. Et WooCommerce n'est pas « n'importe quel site ». Il s'agit d'une boutique avec des pages dynamiques, un panier AJAX, une caisse, des requêtes API des systèmes de paiement, des webhooks des services de livraison et une synchronisation avec 1C. Et quand au milieu de tout cela se trouve un plugin de plus d'une centaine de mégaoctets, qui, à chaque requête, le vérifie par rapport à une base de données de plusieurs millions de signatures, le plaisir commence.

J'ai rencontré ce problème pour la première fois lors d'un projet pour un client qui vend des lubrifiants industriels. Il dispose d'une boutique sur WooCommerce, seize mille positions, synchronisation avec 1C : Trade Management via OData, recherche sur Typesense, méga-menu avec navigation à trois niveaux, tarification B2B avec groupes de clients. Magasin fonctionnant normalement. Wordfence Premium coûtait cent dix-neuf dollars par an, tout était comme il se doit. Et puis un jour, nous avons remarqué que les pages du catalogue commençaient à se charger une seconde et demie de plus après la mise à jour de Wordfence. Une seconde et demie, c'est une éternité pour une boutique en ligne. Nous avons commencé à creuser et découvert que Wordfence était en conflit avec LiteSpeed ​​​​Cache. Les deux plugins tentent de contrôler les en-têtes HTTP, tous deux sont impliqués dans le traitement des requêtes à un stade précoce et, par conséquent, la mise en cache fonctionne parfois. Certaines pages sont servies à partir du cache, d'autres non, et l'utilisateur voit un site rapide ou lent. L’incohérence est la pire chose qui puisse arriver dans le commerce électronique.

Nous avons passé deux jours à configurer des exceptions. Ajout de modèles d'URL pour le paiement, le panier, les points de terminaison de l'API et les gestionnaires AJAX pour WooCommerce. Cela semble avoir fonctionné. Un mois plus tard, Wordfence a été mis à jour – et certaines exceptions ont cessé de fonctionner car le format de configuration avait un peu changé. Nous perdons encore du temps. Et à un moment donné, j'ai pensé : attendez, qu'est-ce que Wordfence fait exactement pour nous que nous ne pouvons pas réaliser plus facilement ?

Il s'est avéré que parmi l'énorme arsenal de Wordfence, nous avons en fait utilisé quatre fonctions : la protection par force brute, le blocage des adresses IP suspectes, le CAPTCHA sur les formulaires et la surveillance des fichiers. Un pare-feu avec ses règles WAF est utile. Mais notre hébergement dispose déjà de ModSecurity avec le jeu de règles OWASP. Scanner de logiciels malveillants - exécuté une fois par mois, n'a jamais rien trouvé (car nous n'installons pas de mauvais plugins et thèmes). Authentification à deux facteurs - configurée uniquement pour l'administrateur. Il s'avère que nous payons cent dix-neuf dollars par an et souffrons de conflits de mise en cache au profit de fonctionnalités qui peuvent être mises en œuvre beaucoup plus facilement.

Savez-vous ce qui a fini par me convaincre ? J'ai regardé la taille du plugin. Wordfence avec sa base de données de signatures, son pare-feu, son scanner et son panneau d'administration fait plus d'une centaine de mégaoctets. Cent mégaoctets de code PHP, qui sont chargés d'une manière ou d'une autre à chaque requête adressée au site. À titre de comparaison, l'ensemble de WooCommerce fait environ quarante mégaoctets. Autrement dit, un plugin de sécurité est plus grand que la plateforme qu’il protège. C'est tolérable pour un blog. Pour un magasin avec des milliers de sessions simultanées, non.

Et encore un point rarement abordé. Wordfence stocke les journaux, les statistiques, les données d'analyse et les tableaux de pare-feu dans la base de données WordPress. Dans la base de données même avec laquelle la boutique WooCommerce est déjà surchargée, wp_postmeta sur notre projet pèse 937 mégaoctets. Ajouter plusieurs tables supplémentaires avec des millions de lignes de Wordfence à cela signifie aggraver la situation déjà non triviale des performances de MySQL.

Je ne dis pas que tout le monde devrait immédiatement désinstaller Wordfence. C'est un excellent choix pour de nombreux sites. Mais si vous disposez d’une boutique WooCommerce avec une charge importante, une mise en cache au niveau du serveur et des intégrations spécifiques, cela vaut la peine de se demander s’il existe un moyen d’obtenir la protection nécessaire sans ce poids lourd. Spoiler : oui. Et maintenant, je vais vous dire comment nous avons fait.

Anatomie d'une attaque : que font exactement les robots et ce qu'ils veulent

Avant de nous défendre, il convient de comprendre exactement contre quoi nous nous défendons. J'ai remarqué que de nombreux propriétaires de magasins perçoivent une « attaque de site » comme quelque chose qui sort d'un film hollywoodien : un hacker encapuchonné tapant furieusement sur le clavier, des personnages verts courant sur l'écran. En réalité, quatre-vingt-dix pour cent des attaques sur les sites WordPress/WooCommerce sont des processus entièrement automatisés. Des robots. Scripts. Il n’y a personne derrière l’écran. Il existe un botnet de plusieurs milliers de serveurs et d’appareils IoT compromis qui explore méthodiquement des millions de sites WordPress et essaie des connexions standard avec des mots de passe provenant de bases de données divulguées.

L'objectif principal est d'accéder à la zone d'administration. Ne pas voler vos produits ou votre clientèle (même si cela arrive). Le plus souvent, WordPress piraté est utilisé comme lien intermédiaire : ils hébergent des pages de phishing, envoient du spam via votre messagerie, installent des mineurs de cryptomonnaie et redirigent vos visiteurs vers des sites tiers. Pour une boutique WooCommerce, les conséquences sont catastrophiques : Google marque le site comme dangereux en quelques heures, les clients voient un écran d'avertissement rouge dans le navigateur, les ventes tombent à zéro. Restaurer votre réputation dans les moteurs de recherche peut prendre des semaines.

Le vecteur d'attaque numéro un est la force brute via wp-login.php. La page de connexion WordPress standard, accessible au monde entier par défaut. Le bot envoie une requête POST avec une paire login-mot de passe, reçoit une réponse et envoie la requête suivante. À une vitesse de trois à cinq requêtes par seconde, le robot peut trier des dizaines de milliers de combinaisons par jour. Si votre mot de passe est « shop2024 », la question n’est pas de savoir si vous serez piraté, mais quand. De plus, même si le bot ne devine pas le mot de passe, cela cause quand même des dommages : chaque requête adressée à wp-login.php est une session PHP à part entière avec connexion à la base de données, vérification des informations d'identification et enregistrement dans le journal. Soixante mille requêtes de ce type par jour représentent une charge importante, même pour un bon serveur.

Le vecteur numéro deux est XML-RPC. Il s’agit d’un protocole WordPress à distance qui a été inventé à l’époque où les gens publiaient des articles de blog via des applications de bureau. En 2026, environ zéro pour cent des propriétaires de magasins WooCommerce utilisent XML-RPC. Mais il est activement utilisé par les robots, car via XML-RPC, vous pouvez envoyer la méthode system.multicall avec des centaines de paires login-mot de passe en une seule requête. Autrement dit, au lieu de frapper cent fois à la porte, le robot frappe une fois et remet cent clés en même temps. De nombreux plugins de sécurité limitent les tentatives de connexion via wp-login.php, mais oublient XML-RPC - et les robots basculent simplement sur ce canal.

Vecteur numéro trois - formulaires d'inscription et de paiement. Sur une boutique WooCommerce, contrairement à un blog classique, il existe des formulaires ouverts qui sont accessibles aux utilisateurs non autorisés : création d'un compte, passation de commande, formulaire de feedback et parfois demande d'offre commerciale. Les robots utilisent ces formulaires à deux fins : l'enregistrement du spam (créant des milliers de faux comptes) et la vérification de la validité des adresses e-mail provenant de bases de données divulguées. Le formulaire de paiement est particulièrement vulnérable car il vous permet de vérifier les cartes bancaires volées lors de petites transactions - ce qu'on appelle le test de carte. PayPal, Stripe, YooKassa combattent tous cela, mais si vous n'avez pas de CAPTCHA lors du paiement, vous offrez essentiellement aux robots un outil gratuit de vérification de carte.

La compréhension de ces trois vecteurs détermine la stratégie de défense. Nous n’avons pas besoin d’un pare-feu universel avec des millions de règles. Nous devons fermer trois portes spécifiques – et les fermer en toute sécurité.

Protection contre la force brute : blocage intelligent au lieu de la force brute

Lorsque j'ai commencé à concevoir un module de protection contre la force brute, la première chose que j'ai faite a été de regarder comment Wordfence le fait. Et tu sais ce que j'ai compris ? L’approche est en réalité simple. Vous comptez le nombre de tentatives de connexion infructueuses à partir d'une adresse IP sur une certaine période. Si vous dépassez la limite, vous bloquez l'IP pendant un certain temps. Ce n’est pas sorcier. Mais comme toujours, le diable se cache dans les détails, et ce sont les détails qui distinguent une bonne mise en œuvre d’une mauvaise.

Le premier détail est le verrouillage progressif. La mise en œuvre naïve de « cinq tentatives - blocage pendant quinze minutes » ne fonctionne pas contre les botnets sérieux. Le bot attend simplement quinze minutes et recommence. Ou passe à une autre IP. Nous avons mis en place un blocage exponentiel : la première série de tentatives infructueuses - blocage pendant quinze minutes, la deuxième - pendant une heure, la troisième - pendant quatre heures, la quatrième - pendant une journée. Une IP qui tente systématiquement de deviner un mot de passe après plusieurs cycles finit par être bloquée pendant vingt-quatre heures. Pendant ce temps, le botnet se tourne généralement vers d’autres cibles.

Le deuxième détail est de compter les tentatives non seulement par IP, mais aussi par nom d'utilisateur. Si quelqu'un essaie les mots de passe du compte administrateur à partir de mille adresses IP différentes, il s'agit toujours d'une attaque, même s'il n'y a eu qu'une seule demande pour chaque IP. Nous comptons séparément : les tentatives depuis la même IP et les tentatives de même connexion. Le dépassement de l’une des limites activera le blocage. Pour IP, l'adresse est bloquée. Pour une connexion, la possibilité de se connecter sous ce nom est bloquée pendant une certaine période, quelle que soit l'IP.

Le troisième détail concerne les notifications instantanées. Lorsque le blocage est déclenché, l'administrateur reçoit un email. Pas en une heure, pas dans le résumé quotidien – tout de suite. La lettre indique l'adresse IP bloquée, le pays, le nombre de tentatives et le login qu'ils ont essayé de trouver. Ceci est important non seulement pour réagir, mais aussi pour comprendre les modèles. Lorsque vous voyez que depuis une semaine, il y a eu des tentatives de connexion sous le login « gestionnaire » à partir d'adresses IP d'un bloc, vous comprenez que quelqu'un attaque délibérément votre site et n'effectue pas d'analyse de masse. Et puis vous prenez d'autres mesures.

Le quatrième détail est la liste blanche. Si vous disposez d'une adresse IP fixe au bureau, vous devez l'ajouter à la liste blanche afin de ne pas vous bloquer accidentellement. Cela semble évident, mais je connais deux cas où un administrateur de magasin a bloqué sa propre adresse IP avec des tentatives de connexion infructueuses (il a oublié le mot de passe, a essayé cinq fois) et n'a ensuite pas pu se connecter à la zone d'administration. Cela n'arrivera pas avec une liste blanche. Nous avons également ajouté une détection automatique de l'adresse IP de l'administrateur lors de la première configuration - afin qu'il n'oublie pas de s'ajouter manuellement.

Tout cela fonctionne au niveau PHP, sans dépendances externes, sans appels aux API cloud, sans bases de signatures de gigaoctets. Les données sur les tentatives de connexion sont stockées dans le tableau du journal d'activité, qui est déjà nécessaire pour l'audit. Aucune charge de base de données supplémentaire : une ligne écrite pour chaque tentative de connexion. Par rapport à Wordfence, qui vérifie l'adresse IP par rapport à la base de réputation du cloud à chaque requête (qui est une requête DNS ou une requête HTTP vers leur API), la différence de performances est significative.

Je réfléchis depuis longtemps à l'intégration de bases de données de réputation IP externes, comme le fait Wordfence avec son flux Threat Intelligence. J'ai décidé que non. En pratique, quatre-vingt-quinze pour cent des attaques sont stoppées dès la phase de limitation des tentatives de connexion. Les cinq pour cent restants sont des attaques ciblées, dont la base de données de réputation IP ne vous sauvera toujours pas, car l'attaquant utilise des proxys purs qui ne figurent dans aucune base de données. Et le coût de l'intégration avec un service externe est la dépendance à l'égard d'une API tierce, une latence supplémentaire à chaque requête et des problèmes potentiels si l'API n'est pas disponible.

URL cachée et CAPTCHA : deux astuces simples qui résolvent quatre-vingts pour cent des problèmes

Connaissez-vous le moyen le plus simple d'arrêter les attaques automatisées sur wp-login.php ? Supprimez wp-login.php. Plus précisément, ne le supprimez pas, mais cachez-le derrière une autre URL. Au lieu du standard example.com/wp-login.php, votre page de connexion sera accessible, par exemple, sur example.com/my-secret-door. Et lors de l’accès à wp-login.php, le bot recevra un 404. C’est une technique si simple que beaucoup de gens la sous-estiment. Mais en vain.

Le fait est que la grande majorité des robots qui attaquent WordPress sont des scripts stupides codés en dur pour accéder à wp-login.php et xmlrpc.php. Ils n'analysent pas votre page à la recherche d'un formulaire de connexion, n'analysent pas JavaScript et ne recherchent pas le lien « Connexion » dans le menu. Ils envoient simplement une requête POST à ​​wp-login.php et c'est tout. Si un 404 est renvoyé à cette adresse, le bot passe au site suivant de la liste. Ça y est, l'attaque s'est terminée avant même d'avoir commencé.

Nous avons implémenté l'URL de connexion personnalisée de manière assez élégante. Lorsque la fonction est activée, l'administrateur définit son propre slug - par exemple, académique, entrée, my-login, peu importe. Le plugin intercepte toutes les requêtes adressées à wp-login.php et wp-admin (pour les utilisateurs non autorisés) et renvoie 404. Dans le même temps, tous les liens internes de WordPress - le bouton « Se déconnecter », les liens en lettres sur la modification du mot de passe, la redirection après l'expiration de la session - sont automatiquement réécrits vers la nouvelle URL. L'utilisateur ne remarque rien, pour lui tout fonctionne comme avant, seule l'adresse de connexion est différente.

Sur notre projet de combat - un magasin d'huiles industrielles - nous avons activé une URL de connexion personnalisée et en 24 heures, nous avons constaté que le nombre de requêtes adressées à wp-login.php est passé de soixante mille à zéro. Littéralement à zéro. Les robots ont continué à frapper sur wp-login.php, ont reçu un 404 et sont partis. La charge sur le serveur a sensiblement diminué - le même délai d'une seconde et demie que nous avons observé plus tôt a disparu. Et cela sans une seule règle de pare-feu, sans base de données de signatures, sans service cloud.

Mais une URL masquée constitue une défense contre les robots automatisés. Qu’en est-il des attaques semi-automatiques dans lesquelles une personne trouve votre page de connexion et lance une attaque ciblée par force brute ? Ou avec des inscriptions de spam via le formulaire WooCommerce ? Ou avec un test de carte lors du paiement ? C'est là que CAPTCHA entre en jeu.

Nous prenons en charge trois options : Google reCAPTCHA v2 (classique « Je ne suis pas un robot » avec images), Google reCAPTCHA v3 (invisible, évalue le comportement de l'utilisateur) et hCaptcha (alternative de Cloudflare, sans dépendance de Google). Chaque option a ses propres forces et faiblesses, et le choix dépend des spécificités du magasin.

reCAPTCHA v2 est le plus fiable en termes de blocage des robots. Si le bot ne peut pas cliquer sur les images avec des bus, il ne réussira pas. L’inconvénient est que cela agace les utilisateurs en direct. Lors d’un paiement dans une boutique WooCommerce, cela pourrait vous coûter une conversion. L'acheteur a déjà saisi l'adresse de livraison, choisi le mode de paiement, puis on lui montre dix photographies floues avec la question « sélectionner toutes les photos avec des bouches d'incendie ». Certains décideront que le site est en panne, d'autres s'adresseront simplement à des concurrents.

reCAPTCHA v3 résout ce problème : il est invisible. L'utilisateur ne clique sur rien, ne résout aucune image. Google analyse le comportement des utilisateurs sur la page – mouvements de la souris, vitesse de remplissage des formulaires, historique du navigateur – et attribue un score de zéro à un. Au-dessus de 0,5 - très probablement une personne. Ci-dessous se trouve probablement un bot. Nous vous permettons de personnaliser le seuil de score dans le panneau d'administration car différents formulaires nécessitent différents niveaux de gravité. Pour accéder au panneau d'administration, vous pouvez définir le seuil sur 0,7 - il vaut mieux être prudent. Pour le paiement - 0,3, afin de ne pas perdre d'acheteurs légitimes ayant un comportement non standard (par exemple, ceux qui remplissent un formulaire à l'aide d'un clavier sans souris).

hCaptcha est une alternative intéressante pour ceux qui ne souhaitent fondamentalement pas communiquer les données des utilisateurs à Google. Fonctionne de la même manière, mais les données sont traitées par Cloudflare. Pour les clients européens soumis aux exigences du RGPD, cela peut être d’une importance cruciale.

Le point clé est de savoir où placer exactement le CAPTCHA. De nombreux plugins de sécurité l'installent uniquement sur wp-login.php et considèrent la tâche terminée. Mais il existe trois autres formes critiques dans une boutique WooCommerce qui sont souvent oubliées. Formulaire d'inscription - grâce à lui, les robots créent des milliers de faux comptes. Formulaire de récupération de mot de passe - grâce à lui, vous pouvez vérifier si un e-mail spécifique existe dans la base de données (le formulaire répond différemment pour les adresses existantes et inexistantes). Et la forme de paiement est le test de carte, dont j'ai déjà parlé. Nous mettons CAPTCHA aux quatre points : connexion, inscription, récupération du mot de passe, paiement. Il est configuré séparément pour chaque formulaire - vous pouvez activer la v3 à la caisse (invisible) et la v2 à la saisie (explicite).

C'est là que je souhaite souligner un point important. CAPTCHA n’est pas une solution miracle. Les botnets avancés peuvent contourner reCAPTCHA v2 en utilisant des services comme 2Captcha ou Anti-Captcha, où de vraies personnes cliquent sur des images pour quelques centimes. reCAPTCHA v3 peut être trompé en émulant le comportement humain dans un navigateur sans tête. Mais tout cela nécessite des efforts et des ressources importants de la part de l’attaquant. Un robot massif qui explore des millions de sites ne dépensera pas un centime pour votre CAPTCHA : il passera simplement au site suivant sans protection. Mais une attaque ciblée représente un niveau de menace complètement différent, et vous devez vous en protéger par d'autres moyens. CAPTCHA dans ce cas est la première ligne qui élimine quatre-vingt-dix-neuf pour cent des déchets automatisés.

Ces deux techniques réunies - URL de connexion cachée et CAPTCHA sur les formulaires - résolvent la grande majorité des problèmes liés aux robots sur une boutique WooCommerce. Sans une seule ligne de configuration de pare-feu, sans abonnement cloud, sans plugin de cent mégaoctets. Juste une protection pure et ciblée sur des points vulnérables précis.

XML-RPC : le trou le plus sous-estimé de WordPress

Je me souviens du moment où j'ai entendu parler de l'attaque par amplification XML-RPC. C'était il y a environ cinq ans et j'ai été sincèrement surpris : comment cela est-il possible dans le monde moderne ? XML-RPC est un ancien protocole WordPress qui vous permet de gérer votre site à distance via des requêtes XML. Publier des articles, gérer des commentaires, télécharger des fichiers - tout cela peut être fait via xmlrpc.php. Le problème est que ce fichier prend en charge la méthode system.multicall, qui vous permet de combiner plusieurs appels en une seule requête. Et les attaquants ont rapidement compris comment l’utiliser.

Au lieu d'envoyer mille requêtes distinctes avec des mots de passe différents (ce qui est facile à suivre et à bloquer), le bot envoie une requête avec la méthode system.multicall, à l'intérieur de laquelle se trouvent mille appels à wp.getUsersBlogs, chacun avec une paire login-mot de passe unique. WordPress traite honnêtement les milliers d'appels et renvoie le résultat. Une requête HTTP signifie mille vérifications de mot de passe. Pas un seul compteur de tentatives de connexion sur wp-login.php ne le verra, car l'attaque passe par un canal complètement différent.

Mais la force brute n'est pas si mauvaise. XML-RPC est également utilisé pour un autre type d'attaque : l'amplification DDoS. Le robot envoie une demande de pingback XML-RPC à votre site avec la fausse adresse de retour d'une victime. Votre WordPress envoie honnêtement une demande de pingback à l’adresse de la victime. Si un bot fait cela simultanément à partir de milliers de sites WordPress compromis, la victime reçoit une attaque DDoS et votre site devient involontairement membre du botnet. Belle perspective, non ? Votre domaine est mis sur liste noire, votre hébergement reçoit des plaintes pour abus et vous ne savez même pas ce qui se passe jusqu'à ce qu'un hébergeur en colère vous écrive.

Solution ? Désactivez complètement XML-RPC. En 2026, aucune boutique WooCommerce n’a besoin de ce protocole. L'API REST de WordPress a depuis longtemps remplacé toutes les fonctions XML-RPC - et le fait de manière plus sécurisée, plus rapide et avec une authentification normale. Application mobile WordPress ? Fonctionne via l'API REST depuis la version 5.0. Jetpack ? Je suis passé à REST il y a longtemps. Publier via des applications tierces ? API REST. Il n’y a aucune raison légitime de garder xmlrpc.php ouvert.

Nous désactivons XML-RPC à deux niveaux. Au niveau WordPress - via le filtre xmlrpc_enabled, qui renvoie false. Cela désactive le traitement des requêtes XML-RPC dans WordPress. Et au niveau HTTP, nous interceptons les requêtes adressées à xmlrpc.php et renvoyons 403 avant même que WordPress ne commence à les traiter. Le deuxième niveau est important car même après avoir été désactivé par le filtre, le fichier xmlrpc.php lui-même reste accessible et peut gérer certaines requêtes avant le déclenchement du filtre. La double protection est plus fiable.

Après avoir désactivé XML-RPC sur un projet de production, j'ai regardé les journaux et j'ai vu que le nombre de requêtes bloquées vers xmlrpc.php était en moyenne de trois à cinq mille par jour. Trois à cinq mille requêtes qui étaient auparavant entièrement traitées par WordPress - analyse XML, connexion à la base de données, vérification des informations d'identification - sont désormais interrompues très tôt avec une consommation de ressources minimale. Il ne s'agit pas seulement de sécurité, mais d'optimisation des performances.

Gestion IP : quand on a besoin d'artillerie lourde

L'URL masquée, le CAPTCHA et la désactivation de XML-RPC sont trois étapes de base qui résolvent quatre-vingt-dix pour cent des problèmes de robots. Mais parfois, il faut agir avec plus de fermeté. Parfois, vous voyez dans les journaux qu'à partir d'une certaine plage d'adresses IP, il n'y a pas seulement des tentatives de connexion, mais une analyse systématique des vulnérabilités - requêtes vers wp-config.php.bak, .env, .git/HEAD, debug.log. Ou vous voyez qu'un sous-réseau particulier génère un trafic anormal vers les pages du catalogue - pas des robots essayant de se connecter, mais des scrapers copiant votre catalogue de produits avec les prix. Dans de tels cas, la gestion IP est nécessaire.

Nous l'avons implémenté sous la forme de deux listes - noire et blanche. La liste noire bloque complètement les adresses IP ou des sous-réseaux entiers (au format CIDR) - le serveur renvoie 403 à toute demande. La liste blanche, au contraire, exempte les adresses indiquées de tout contrôle - aucune restriction sur les tentatives de connexion, pas de CAPTCHA, pas de retards. La liste blanche contient généralement les adresses IP du bureau, les connexions domestiques des administrateurs et les adresses des services de confiance (serveurs 1C, systèmes de paiement, services de livraison).

Mais maintenir manuellement une liste noire est une tâche de Sisyphe. Aujourd’hui, vous bloquerez dix adresses, demain l’attaque viendra d’un autre botnet et vous devrez en bloquer vingt autres. C'est pourquoi nous avons ajouté un blocage automatique basé sur des modèles de comportement. Si une adresse IP génère plus d’un certain nombre de requêtes 404 en une heure (ce qui indique une analyse de vulnérabilité), elle est automatiquement mise sur liste noire. Si l'adresse IP dépasse trois fois la limite de tentatives de connexion, un blocage automatique se produit. Si les requêtes proviennent de l'IP contenant des lignes de charge utile typiques d'injections SQL ou XSS - blocage immédiat. Tout cela peut être configuré, les seuils peuvent être modifiés, car le comportement normal semble différent selon les magasins.

Je tiens ici à vous mettre en garde contre un écueil sur lequel j'ai moi-même marché. Le blocage automatique de l'adresse IP peut bloquer les utilisateurs légitimes qui se trouvent derrière un NAT ou un proxy d'entreprise. Dans une grande entreprise, des centaines d’employés peuvent accéder à Internet via une seule adresse IP. Si l’un d’eux tente plusieurs fois sans succès d’entrer dans votre magasin, l’ensemble du bureau sera bloqué. Le blocage automatique doit donc être configuré avec soin : seuils élevés, temps de blocage court à la première opération, notifications obligatoires à l'administrateur. Et une liste blanche des adresses IP des gros clients, si vous les connaissez.

Un sujet distinct est le blocage géographique. Si votre magasin opère uniquement en Russie et dans la CEI, est-il judicieux d'accepter le trafic en provenance d'Indonésie, du Nigeria ou du Brésil ? Les statistiques montrent qu’une partie importante des botnets sont basés dans des pays d’Asie du Sud-Est, d’Afrique et d’Amérique du Sud. Bloquer des pays entiers est un outil rudimentaire mais efficace. Nous prenons en charge le blocage par pays sur la base de la base de données MaxMind GeoIP. Vous pouvez bloquer des pays spécifiques, ou vous pouvez l'inverser : autoriser uniquement certains pays et bloquer tous les autres. Pour un magasin B2B qui travaille exclusivement avec des entités juridiques russes, l'option « Autoriser uniquement la Russie et la Biélorussie » élimine une énorme quantité de trafic indésirable.

Mais je dois être honnête : le blocage géographique n'est pas une question de sécurité dans sa forme la plus pure. C'est plus une question d'hygiène. Un attaquant sérieux louera un VPS dans le pays souhaité pour cinq dollars et contournera votre géoblocage en une minute. Le blocage géographique est efficace contre les botnets massifs qui ne s'adaptent pas à un site spécifique. Et ce sont la majorité.

Journal d'activité : savoir tout ce qui se passe sur le site

Il y a une chose que je considère encore plus importante que tous les mécanismes de protection énumérés ci-dessus. Il s'agit du journal d'activité. Une piste d'audit complète de tout ce qui se passe sur le site. Qui s'est connecté, quand, à partir de quelle IP. Qui a changé les paramètres. Qui a mis à jour le plugin ? Qui a édité le produit. Qui a changé le prix ? Qui a supprimé l'utilisateur.

Pourquoi est-ce si important ? Parce que la sécurité ne consiste pas seulement à prévenir les attaques. C'est aussi une découverte. Et une enquête. Si vous êtes néanmoins piraté (et qu'il n'y a pas de protection à 100 %), le journal d'activité permet de comprendre : exactement quand la pénétration a eu lieu, par quel vecteur, ce que l'attaquant a réussi à faire, quelles données ont été compromises. Sans journal, vous agirez aveuglément - changez tous les mots de passe, réinstallez tous les plugins, vérifiez tous les fichiers. Avec un journal, vous corrigez spécifiquement ce qui a été affecté.

Je vais vous donner un exemple concret tiré de la pratique. Sur un projet, nous avons découvert que quelqu'un avait modifié l'e-mail du destinataire de la commande dans les paramètres WooCommerce. Les commandes ont continué à arriver sur le site, mais des notifications ont été envoyées à un e-mail tiers - quelqu'un a littéralement intercepté les commandes avec les coordonnées des clients. Sans le journal d’activité, nous n’aurions peut-être pas remarqué le problème pendant des mois. Avec un journal - nous avons vu un enregistrement du changement de paramètre, de l'heure, de l'adresse IP et même de l'agent utilisateur du navigateur à partir duquel il a été effectué. Il s'est avéré que l'un des employés avait utilisé un mot de passe faible, que son compte avait été compromis et que les paramètres avaient été modifiés par son intermédiaire. Nous avons réinitialisé le mot de passe, activé l'authentification à deux facteurs, renvoyé le bon e-mail - et tout cela a pris une heure, pas une semaine.

Notre module de journal d'activité enregistre les événements dans des tables personnalisées distinctes - wpaic_activity_log et wpaic_activity_log_contexts. Tables séparées, pas wp_options ou wp_postmeta, qui sont déjà surchargées. Chaque entrée contient un type d'action, un objet d'action (publication, produit, utilisateur, paramètre), une ancienne et une nouvelle valeur, une adresse IP, un agent utilisateur et un horodatage. Toutes les actions critiques sont enregistrées : connexions et déconnexions, modifications d'utilisateur et de rôle, mises à jour de plugins et de thèmes, modifications des paramètres de WooCommerce, modifications de produits et de prix, actions de commande, modifications de fichiers.

Un détail important est le stockage des journaux. Si vous enregistrez tout pour toujours, le tableau atteindra des tailles obscènes. Nous stockons les journaux pendant une période configurable : quatre-vingt-dix jours par défaut. Les entrées antérieures à cette période sont automatiquement supprimées via Action Scheduler. Elle peut être portée à un an ou réduite à trente jours – cela dépend de vos exigences en matière d'audit. Pour les entreprises qui travaillent avec des données personnelles (et il s'agit de n'importe quelle boutique en ligne), quatre-vingt-dix jours constituent un équilibre raisonnable entre les exigences de sécurité et les économies de ressources.

Et encore un point que je souhaite souligner. Le journal d'activité ne concerne pas seulement la sécurité. C'est aussi une question de gestion. Lorsque plusieurs gérants travaillent dans un magasin, vous voulez savoir qui a changé quoi. Le responsable a-t-il accidentellement réinitialisé le prix d'un produit populaire ? Visible dans le journal. Votre stagiaire a supprimé une page importante ? Visible dans le journal. L'entrepreneur a-t-il mis à jour le plugin qui a interrompu le paiement ? Visible dans le journal. Ce n'est pas un outil pour la paranoïa, mais pour la gestion normale des processus métier.

Lorsque je montre aux commerçants le journal d'activité du premier jour après l'allumage, la réaction est généralement la même : « Je ne savais pas qu'il se passait autant de choses sur le site ». Et c'est vrai : la plupart des gens ne réalisent même pas combien de processus automatisés WordPress et WooCommerce s'exécutent en arrière-plan. Mises à jour transitoires, tâches cron, Planificateur d'actions, webhooks - tout cela génère des événements qui restent invisibles sans journal.

Tout sans plugin séparé : pourquoi la protection intégrée est meilleure

Parlons maintenant de ce que tous ces mécanismes ont en commun et de ce qui rend cette approche fondamentalement différente de l'installation de Wordfence. Toutes ces fonctions - protection contre la force brute, URL cachée, CAPTCHA, désactivation de XML-RPC, gestion IP, géoblocage, journal d'activité - sont implémentées sous forme de modules d'un seul plugin, qui gère simultanément votre catalogue, la tarification B2B, la recherche, la livraison et la synchronisation avec 1C. Il ne s’agit pas d’un « autre plugin de sécurité parmi dix autres ». Il s’agit d’une protection intégrée qui sait tout sur votre boutique.

Pourquoi est-ce important ? Parce que les modules d’un même plugin n’entrent pas en conflit les uns avec les autres. Le module de sécurité connaît le module de mise en cache CSS et n'interfère pas avec son travail. Le module CAPTCHA connaît les formulaires de demande de devis et ajoute automatiquement une vérification. Le module de journal d'activité connaît les actions du module B2B et enregistre les modifications dans les groupes de clients, les niveaux de prix et les sous-comptes. Il s’agit d’un écosystème unique, et non d’un ensemble d’outils disparates qui doivent être configurés séparément et espérer qu’ils ne se battent pas.

Le deuxième avantage est la taille et les performances. Le module de sécurité est constitué de plusieurs classes PHP d'un volume total d'une centaine de kilo-octets. Pas un mégaoctet - un kilooctet. Il ne contient pas de base de données de signatures de la taille d’une encyclopédie, n’analyse pas le système de fichiers à chaque requête et n’envoie pas de données vers le cloud. Il fait exactement ce qu'il doit faire et pas une once de plus. Sur une boutique WooCommerce avec LiteSpeed ​​​​Cache, Redis et Typesense, chaque mégaoctet et chaque milliseconde compte. Un module de sécurité qui ajoute une ou deux millisecondes au traitement des requêtes est une tout autre histoire que Wordfence avec ses vingt à trente millisecondes.

Le troisième avantage est le coût. Wordfence Premium coûte cent dix-neuf dollars par an pour un site. Sucuri Firewall - deux cents dollars. iThemes Security Pro – environ une centaine de dollars. Si vous possédez plusieurs magasins, multipliez-les. La protection intégrée est déjà incluse dans le prix du plugin que vous utilisez déjà pour gérer votre boutique. Pas d'abonnement supplémentaire, pas de licence distincte.

Le quatrième plus est un point de configuration unique. Au lieu de passer de l'administrateur Wordfence au panneau Cloudflare, aux paramètres .htaccess et à la configuration du serveur, vous configurez tout au même endroit. L'onglet « Sécurité » dans le panneau d'administration du plugin déjà familier. Protection contre la force brute, CAPTCHA, URL personnalisée, XML-RPC, listes IP, journal d'activité - le tout sous un même toit, avec un style d'interface unique et une documentation uniforme.

J'entends l'objection : « Mais Wordfence dispose d'un WAF avec des milliers de règles pour se protéger contre l'injection SQL, XSS et autres attaques au niveau des applications ! Droite. Et nous avons également WAF - un module de pare-feu d'application Web avec des règles pour détecter les injections SQL, XSS, la traversée de chemin et d'autres attaques courantes. Mais nous n'essayons pas de remplacer ModSecurity ou de concurrencer Cloudflare WAF. Nous fermons la couche application – celle qui détecte les attaques spécifiques à WordPress que le WAF côté serveur pourrait manquer. Il s'agit d'une protection complémentaire et non d'un remplacement d'un pare-feu de serveur.

Je veux aussi parler d'un aspect dont presque personne ne parle. Lorsque vous avez Wordfence sur votre site Web, vous confiez essentiellement la sécurité de votre boutique à une société tierce, Defiant Inc. Si demain ils décident d'augmenter le prix à trois cents dollars par an, vous paierez car toute votre configuration de sécurité est liée à leur plugin. S'ils ferment la version gratuite, vous paierez. S'ils autorisent une vulnérabilité dans leur plugin (et cela s'est produit), votre boutique en souffrira. La sécurité intégrée dans le cadre du plugin de gestion de votre magasin principal est le contrôle. Vous savez ce que cela coûte, comment cela fonctionne et vous ne dépendez pas de la politique tarifaire d'un fournisseur individuel.

J'aime l'analogie avec la voiture. Wordfence, c'est comme installer un système de sécurité séparé et articulé sur votre voiture : un système d'alarme tiers, un dispositif d'immobilisation séparé, un traceur GPS externe, des serrures supplémentaires sur la porte. Chaque composant est bon en soi, mais ensemble, ils entrent parfois en conflit - l'alarme est déclenchée par l'antidémarrage, le traceur GPS vide la batterie, un verrou supplémentaire bloque le verrou standard. La sécurité intégrée est comme un système d'usine : ABS, ESP, airbags, antidémarrage - tout est conçu ensemble, tout fonctionne dans son ensemble, rien n'entre en conflit. Pas si chic ? Peut être. Mais dans 95 % des situations sur la route, c’est largement suffisant. Et pour les cinq pour cent restants, il existe des solutions spécialisées au niveau Cloudflare Enterprise, qui fonctionnent à un niveau différent et n'entrent en conflit avec rien.

Je ne veux pas que vous preniez cet article comme « Wordfence est mauvais, supprimez-le immédiatement ». Non. Wordfence est un bon outil pour certains scénarios. Mais si vous disposez d'une boutique WooCommerce sérieuse avec une charge élevée, une mise en cache au niveau du serveur et la nécessité d'économiser chaque milliseconde, demandez-vous si vous payez un prix trop élevé (à la fois en argent et en performances) pour des fonctionnalités qui peuvent être obtenues beaucoup moins cher et plus facile. Une protection pointue au niveau de vecteurs d'attaque spécifiques - force brute, XML-RPC, enregistrements de spam, tests de cartes - combinée à un audit complet des actions offre une réelle sécurité sans effets secondaires.

Essayez d'activer le module de sécurité, de configurer une URL de connexion personnalisée, d'ajouter du CAPTCHA aux formulaires, de désactiver XML-RPC - et consultez les journaux en une journée. Je parie que vous verrez des dizaines de milliers de robots bloqués et une réduction notable de la charge du serveur. Et puis ouvrez le journal d’activité et voyez ce qui se passe réellement sur votre site. Ce sera à la fois effrayant et enrichissant. Effrayant - parce que vous verrez à quel point vous n'aviez pas remarqué auparavant. Utile – parce que maintenant vous avez le contrôle.

Et enfin, un conseil qui n'a rien à voir avec les plugins. La protection la plus fiable contre la force brute est un mot de passe fort. Vingt caractères, des lettres dans les deux cas, des chiffres, des caractères spéciaux, pas de mots du dictionnaire. Cela semble anodin, mais je vois régulièrement des magasins avec un chiffre d'affaires de plusieurs dizaines de millions de roubles, où le mot de passe administrateur est le nom de l'entreprise avec l'année de sa création. Toutes les mesures techniques de protection que j'ai décrites sont des barrières qui ralentissent l'attaquant et éliminent les robots. Mais si votre mot de passe est « admin2024 », aucune URL cachée ni aucun CAPTCHA ne vous sauveront, car il sera deviné lors des cent premières tentatives. Un mot de passe fort, une authentification à deux facteurs, une URL de connexion personnalisée et des tentatives de connexion limitées constituent quatre niveaux de protection, dont chacun rend la tâche de l'attaquant beaucoup plus difficile. Frapper les quatre en même temps est une tâche pour laquelle aucun botnet massif ne gaspillerait de ressources. Il ira simplement sur le site suivant où le mot de passe est « 123456 » et xmlrpc.php est ouvert. Ne soyez pas ce site.