Protection de la boutique WooCommerce : WAF, 2FA, géoblocage et surveillance

La ​​semaine dernière, j'ai reçu un e-mail d'un client qui possède une boutique en ligne d'huiles industrielles sur WooCommerce. Le sujet était laconique : « Nous avons été piratés ». Après une demi-heure d'appel, j'ai appris que l'histoire était banale au point de grincer des dents. Quelqu'un a deviné le mot de passe du compte du responsable, est entré dans la zone d'administration, a exporté la base de données clients - noms, numéros de téléphone, adresses de livraison, historique des commandes - et a disparu. Personne n'a remarqué l'invasion pendant deux jours. Le gestionnaire a utilisé le mot de passe « company2024 », il n'y avait pas d'authentification à deux facteurs, le standard wp-login.php était visible sur tout Internet et la seule « protection » était Wordfence, qui a cessé de se mettre à jour il y a trois mois en raison d'une licence expirée. Est-ce une image familière ? J'ai vu cela se produire des dizaines de fois au cours des cinq dernières années, et à chaque fois j'éprouve le même sentiment : un mélange de frustration et de conscience que cela aurait pu être évité.

Voici le problème : lorsque nous lançons une boutique WooCommerce, tout le monde pense au design, au catalogue de produits, aux méthodes de paiement, à la configuration de la livraison et au référencement. La sécurité est l’élément même qui se retrouve systématiquement en bas de la liste. "On l'installera plus tard", "ça ne nous regarde pas, nous sommes un petit magasin", "qui a besoin de nous". Et puis il s’avère qu’ils sont nécessaires. Parce que WooCommerce n’est pas qu’un blog WordPress où l’on peut tout au plus gâcher l’article. Il s'agit des données de paiement, des données personnelles des clients, de l'accès au panneau administratif, à partir duquel vous pouvez faire des choses valant des centaines de milliers de roubles. Et ils ne vous attaquent pas spécifiquement : ils attaquent tout le monde à la suite, avec des scripts automatisés qui sont absolument indifférents au fait que vous vendiez des lubrifiants industriels ou des bougies de créateurs.

Je développe et commercialise pour des entreprises B2B et industrielles depuis de nombreuses années, et pendant cette période, j'ai suffisamment vu les conséquences des hacks pour comprendre une chose : la sécurité de la boutique WooCommerce n'est pas une option, c'est une fondation. Sans cela, tout le reste (un beau site Web, un entonnoir de vente rationalisé, un CRM personnalisé) s'effondre instantanément. C'est pourquoi, lorsque nous avons conçu le module de sécurité pour COS WP Woo, nous l'avons abordé non pas comme « une autre fonctionnalité », mais comme un système qui devrait couvrir tous les principaux vecteurs d'attaque de WooCommerce. Et aujourd'hui, je veux vous expliquer comment fonctionne ce système - non pas de manière abstraite, mais avec des exemples spécifiques et une explication de la raison pour laquelle chaque niveau de protection est nécessaire.

Pourquoi une boutique WooCommerce est une cible savoureuse

Voyons d'abord pourquoi les boutiques WooCommerce sont si souvent piratées. Il y a plusieurs raisons, et elles fonctionnent toutes simultanément. WordPress est le CMS le plus populaire au monde, alimentant plus de 40 % de tous les sites Web. WooCommerce est le plugin de commerce électronique le plus populaire qui transforme WordPress en une boutique en ligne à part entière. Cela signifie que toute vulnérabilité trouvée devient instantanément applicable à des millions de sites. Les pirates ne recherchent pas de vulnérabilité dans votre boutique spécifique - ils trouvent une faille dans la version 6.4.2 de WordPress ou dans la version 5.8 du plugin Contact Form 7, puis un script automatisé explore des centaines de milliers de sites et tente d'exploiter cette faille. Vous finissez sous la patinoire. Aucune haine personnelle.

Mais il y a un autre côté. Contrairement à un blog classique, WooCommerce stocke des données qui apportent une réelle valeur ajoutée. La table wp_postmeta d'un magasin moyen contient des centaines de mégaoctets d'informations, notamment des adresses de livraison, des numéros de téléphone, des adresses e-mail et parfois même des données partielles de carte. La table wp_users contient des hachages de mots de passe, et si l'un des administrateurs utilise le même mot de passe sur plusieurs services, considérez que toute la chaîne est compromise. J'ai travaillé avec un magasin où la table wp_postmeta pesait près d'un gigaoctet - près de 17 000 produits, des dizaines de milliers de commandes sur sept ans. La fuite d'une telle base de données n'est pas seulement une nuisance, c'est une amende potentielle en vertu de la loi 152-FZ et un coup porté à la réputation dont les petites entreprises ne se remettront peut-être pas.

Et voici autre chose que j'ai remarqué : il existe une idée fausse courante parmi les propriétaires de boutiques en ligne selon laquelle s'ils ont un certificat SSL configuré et une sorte de plugin de sécurité installé, alors ils sont protégés. SSL est un cryptage de la connexion entre le navigateur et le serveur, une chose merveilleuse, mais il ne protège pas contre les injections SQL, la devinette de mot de passe ou les scripts malveillants dans le plugin de quelqu'un d'autre. Et « une sorte de plugin de sécurité » s'avère souvent être une version gratuite de Wordfence ou d'iThemes Security, installée il y a deux ans et n'a jamais été ouverte depuis. Une véritable protection n’est pas un outil unique, c’est un ensemble de mesures qui fonctionnent à différents niveaux. Et je veux passer par chacun de ces niveaux.

Considérez votre boutique WooCommerce comme un bâtiment. SSL est une clôture autour du territoire. Mais à l’intérieur de la clôture, il faut un système de vidéosurveillance (surveillance), un agent de sécurité à l’entrée qui vérifie les documents (authentification), des serrures sur les portes (restriction d’accès), un détecteur de mouvement (pare-feu), et même un système d’alerte si quelqu’un commence à gratter le mur (surveillance de l’intégrité des fichiers). Supprimez n’importe quel élément et l’ensemble du système devient vulnérable. C'est exactement ainsi que nous avons abordé la conception du module de sécurité : pas un gros commutateur, mais une défense à plusieurs niveaux.

WAF est la première ligne de défense qui fonctionne avant que des problèmes ne surviennent

J'ai longuement réfléchi à par où commencer pour parler d'outils spécifiques et j'ai décidé de commencer par WAF - Web Application Firewall. Parce que c’est le composant même qui coupe 80 % du trafic indésirable avant même que la requête n’atteigne votre code PHP. Essentiellement, un WAF est un filtre qui analyse chaque requête HTTP entrante et la compare à un ensemble de règles. Si la requête ressemble à une tentative d’injection SQL, bloquez-la. Si l'URL contient une construction telle que ../../../etc/passwd, il s'agit d'un parcours de chemin, bloquez-le. S'il y a du code JavaScript dans les paramètres de la requête, il s'agit d'une attaque XSS, bloquez-le.

Cela semble simple, mais la mise en œuvre est le diable dans les détails. Je me souviens comment, sur un projet, nous avons installé ModSecurity sur le serveur, et il a immédiatement commencé à bloquer les demandes légitimes de WooCommerce. Parce que WooCommerce envoie de tels formulaires lors de la passation d'une commande, ModSecurity avec les règles OWASP CRS commence à suspecter une injection SQL dans une requête POST sur deux. Le résultat était que les clients ne pouvaient pas passer de commande, le taux de conversion tombait à zéro et nous avons passé deux jours à peaufiner les règles. C'est pourquoi un WAF qui fonctionne au niveau de l'application et comprend le contexte de WordPress et WooCommerce n'est pas la même chose qu'un WAF au niveau du serveur.

Dans notre module, WAF fonctionne comme un middleware qui intercepte la requête très en amont, avant même que WordPress ne commence à traiter le routage. Il vérifie les paramètres GET, le corps du POST, les cookies, les en-têtes – tout ce qui vient du client. Et il sait ce qu'est WooCommerce. Il comprend qu'une requête POST de paiement avec le champ billing_address_1 est normale, mais qu'une requête GET avec le paramètre ?id=1 UNION SELECT * FROM wp_users n'est pas normale. C'est une différence importante par rapport aux solutions universelles : notre WAF est conçu pour WordPress et WooCommerce, le nombre de faux positifs est donc minime.

Honnêtement, lorsque je regarde les logs WAF après la première semaine de travail sur une boutique WooCommerce plus ou moins visitée, mes yeux s'écarquillent à chaque fois. Des dizaines de milliers de requêtes bloquées. Injections SQL, tentatives de traversée de répertoires, sondes XSS, analyse des vulnérabilités connues dans les plugins populaires - cela se produit 24h/24 et 7j/7, sans pause ni week-end. Sur l'un de nos projets clients, WAF a bloqué 47 000 requêtes malveillantes au cours du premier mois. Quarante sept mille. Et le propriétaire du magasin, avant d'installer notre module, était sûr que personne n'attaquerait son « site dont personne n'a besoin ».

Mais WAF est la première ligne. Il stoppe les attaques automatisées massives. WAF n’aidera pas contre le piratage ciblé utilisant des informations d’identification volées. Cela nécessite d'autres outils.

URL de connexion personnalisée et blocage XML-RPC : suppression des cibles des emplacements visibles

Et si on regardait le problème de l'autre côté ? Au lieu de construire des murs, vous pouvez simplement supprimer ce sur quoi vous tirez. Quiconque a déjà consulté les journaux d’accès d’un site WordPress a vu des requêtes interminables vers /wp-login.php et /xmlrpc.php. Ce sont deux adresses que les robots connaissent par cœur. Ils sont écrits dans chaque script de force brute, dans chaque scanner automatisé. Supprimez ces adresses et 90 % des attaques automatisées se heurteront simplement à une erreur 404 et partiront à la recherche de la prochaine victime.

Une URL personnalisée pour la page de connexion est une idée que je considérais comme une « sécurité par l'obscurité » et que j'étais un peu méprisante. Par exemple, la véritable sécurité devrait reposer sur des mots de passe forts et une authentification appropriée, et non sur le fait de cacher la porte. Mais la pratique a montré que je me trompais. Non, bien sûr, une URL personnalisée ne remplace pas des mots de passe forts et à deux facteurs. Mais c’est un moyen incroyablement efficace de réduire la charge des robots et de supprimer 99 % des déchets automatisés des journaux. Lorsque nous avons remplacé /wp-login.php par une URL personnalisée sur l'un des sites de vente, le nombre de tentatives de connexion par jour est passé de 3 000 à 12. Douze ! Ce sont de vraies personnes qui connaissaient l'adresse : des administrateurs et des gérants de magasins. Les trois mille autres étaient des robots qui tapaient bêtement à l'adresse standard.

Dans notre module, cela est implémenté via le composant LoginUrl. Vous spécifiez une adresse arbitraire - au moins /my-secret-door, au moins /academic, au moins /login-1234. Les standards /wp-login.php et /wp-admin (pour ceux qui ne sont pas connectés) cessent de fonctionner et renvoient 404. Le bot arrive à /wp-login.php, reçoit « page introuvable », note « il n'y a pas de WordPress ici » et s'en va. Élégant et efficace.

Parlons maintenant de XML-RPC. Il s’agit d’un ancien protocole que WordPress a hérité de son moteur précédent – ​​b2/cafelog. Il vous permet de gérer votre site à distance via des requêtes XML. C'était autrefois utile pour les applications mobiles et les éditeurs frontaux, mais avec l'avènement de l'API REST, le besoin de XML-RPC a pratiquement disparu. Mais les attaquants adorent XML-RPC. Pourquoi? Parce que la méthode system.multicall vous permet d'envoyer des centaines de tentatives d'authentification en une seule requête HTTP. Autrement dit, au lieu de faire 500 requêtes à wp-login.php (ce qui est facile à remarquer et à bloquer), l'attaquant envoie une requête à xmlrpc.php contenant 500 combinaisons login-mot de passe. Certains plugins de protection contre la force brute ne remarquent même pas ce vecteur, car ils ne comptent que les tentatives de connexion via un formulaire standard.

Nous fermons simplement complètement xmlrpc.php. Un interrupteur dans les paramètres et le protocole est bloqué. Pas de XML-RPC, pas de multiappel. Si vous avez besoin d'accéder à partir d'applications externes, il existe une API REST pour cela avec une authentification normale et une limitation de débit. Je n’ai vu aucun scénario commercial réel en 2025-2026 où XML-RPC serait nécessaire. Mais j’ai rencontré suffisamment de scénarios dans lesquels des sites Web ont été détruits.

Une précision importante mérite d’être apportée ici. Certains diront : « Eh bien, Jetpack utilise XML-RPC pour communiquer avec WordPress.com. » Oui, il le fait. Mais si vous êtes passé à notre module de sécurité, vous n'avez plus besoin de Jetpack à ces fins. De plus, Jetpack a commencé à migrer vers l'API REST il y a longtemps. Bref, fermez XML-RPC et ne regardez pas en arrière.

Authentification à deux facteurs et protection contre la force brute : deux verrous valent mieux qu'un

Parlons de l'authentification - le point apparemment le plus simple et en même temps le plus vulnérable de toute boutique WooCommerce. Je peux installer le WAF le plus puissant, fermer XML-RPC, masquer l'URL de connexion, mais si l'administrateur du site utilise le mot de passe « admin123 », toutes mes défenses s'effondrent comme un château de cartes. Et ne pensez pas que j’exagère. Selon les statistiques que j'ai vues dans des projets réels, environ une boutique WooCommerce sur quatre compte au moins un utilisateur disposant de droits d'administration et d'un mot de passe de dix caractères sans caractères spéciaux. Il ne s'agit pas de négligence, c'est la réalité dans laquelle un directeur commercial doit mémoriser les mots de passe de vingt systèmes et choisir ce qui est le plus facile à retenir.

L'authentification à deux facteurs résout radicalement ce problème. Même si un attaquant découvre le mot de passe - le vole, le récupère, l'intercepte, le trouve dans une base de données divulguée - il ne pourra pas se connecter sans un deuxième facteur. Dans notre module, nous avons implémenté TOTP - Time-based One-Time Password, la même norme utilisée par Google Authenticator, Microsoft Authenticator et des dizaines d'autres applications. L'administrateur scanne le code QR, l'application commence à générer des codes à six chiffres qui changent toutes les 30 secondes. Lors de votre connexion, vous devez saisir votre identifiant, votre mot de passe et votre code actuel depuis l'application. Trois facteurs ? Non, deux - le mot de passe est « que savez-vous », le code de l'application est « qu'est-ce que vous avez » (téléphone avec l'application). Classique à deux facteurs.

J'insiste pour que le 2FA soit obligatoire pour tous les administrateurs et gérants de magasins au minimum. Facultatif - pour tous les utilisateurs. Savez-vous quel argument j’entends le plus souvent ? "C'est gênant pour les salariés, ils vont se plaindre." Je réponds toujours la même chose : tu sais ce qui ne convient pas ? Appelez les clients et expliquez-leur que leurs données personnelles ont été divulguées parce que Masha du service commercial a décidé que « qwerty » était un mot de passe assez fort. Le code à usage unique ajoute trois secondes au processus de connexion. Trois secondes contre les fuites potentielles de données de milliers de clients. Il me semble que le choix est évident.

Mais 2FA est un deuxième verrou. Et le premier ? C’est là qu’intervient la protection contre la force brute. Notre module LoginProtection fonctionne sur le principe du blocage progressif. Les trois premières tentatives de connexion infructueuses constituent un avertissement. Après le cinquième, l'IP est bloquée pendant 15 minutes. Après la dixième heure - pendant une heure. Après le vingtième - pendant une journée. De plus, le blocage fonctionne non seulement par IP, mais aussi par nom d'utilisateur. Ceci est important car les attaquants utilisent parfois des botnets distribués avec des milliers d'adresses IP, mais ciblent un seul compte – « administrateur » ou « gestionnaire ». Si le nom d'utilisateur « admin » a eu 20 tentatives infructueuses depuis différentes IP, nous bloquons la connexion pour ce nom d'utilisateur pendant un certain temps, quelle que soit l'IP.

Et ici, je veux raconter une histoire qui illustre parfaitement pourquoi tous ces mécanismes sont nécessaires ensemble. L'un de nos clients est un fabricant d'équipements hydrauliques possédant une boutique WooCommerce. Il avait trois managers qui travaillaient pour lui, chacun avec son propre compte. L'un des gérants a démissionné, mais personne n'a bloqué son compte. Deux mois plus tard, le mot de passe de ce compte a fait surface dans une fuite de données publiques d'un autre service (où le gestionnaire utilisait le même mot de passe). Le bot a trouvé ce mot de passe, l'a essayé sur wp-login.php - et l'a entré. Si notre module avait été installé, une URL de connexion personnalisée aurait signifié que le bot n'aurait tout simplement pas trouvé la page de connexion. Si par miracle je le trouvais, 2FA nécessiterait un code provenant d’une application que le bot ne possède pas. Et s’il n’y avait pas de 2FA, la surveillance des activités afficherait une entrée provenant d’une adresse IP inconnue à 3 heures du matin et l’administrateur recevrait une notification. Trois lignes de défense, dont chacune aurait pu, à elle seule, empêcher l'incident. Et ces trois éléments réunis rendent le piratage presque impossible.

Je voudrais également dire quelque chose à propos du CAPTCHA. Nous prenons en charge Google reCAPTCHA v2, reCAPTCHA v3 et hCaptcha - votre choix. CAPTCHA peut être activé sur le formulaire de connexion, sur le formulaire d'inscription, sur la page de paiement, sur le formulaire de récupération de mot de passe. reCAPTCHA v3 fonctionne de manière invisible : l'utilisateur ne remarque rien et Google, sur la base d'une analyse comportementale, décide s'il s'agit d'un robot ou d'une personne. Pour la plupart des magasins, je recommande la v3 - elle n'irrite pas les clients et en même temps coupe efficacement les robots. Sur les formulaires de connexion administrateur, vous pouvez cocher la v2 avec la classique case à cocher « Je ne suis pas un robot », ici l'UX est moins critique, mais la protection est plus stricte.

Géoblocage : une approche chirurgicale du filtrage du trafic

Vous savez, cela fait longtemps que je suis sceptique quant au géoblocage. Il semblait que bloquer des pays entiers était un outil trop rudimentaire, un peu comme « frapper les moustiques avec un marteau ». Mais j’ai ensuite commencé à analyser les journaux d’attaques sur les sites clients et j’ai changé d’avis. Pas 180 degrés, mais plutôt 120. Le blocage géographique n’est pas une panacée, mais c’est un outil étonnamment efficace dans certains scénarios.

Voici les numéros précis d'un des projets. En un mois, WAF a bloqué environ 50 000 requêtes malveillantes. Je les ai divisés par géolocalisation. 38 % provenaient de pays d'Asie du Sud-Est qui ne faisaient pas partie du marché cible du magasin. 22% sont originaires d'Amérique du Sud, également de passage. 15% viennent d'Afrique. 12 % viennent d’Europe de l’Est (mais pas de Russie ni de la CEI). Total : 87 % du trafic malveillant provenait de régions où le magasin ne comptait aucun client réel. Zéro commande, zéro inscription, zéro demande. Trafic d’attaque pur.

Le blocage géographique vous permet de bloquer l'accès au site (ou à certaines parties de celui-ci - par exemple, uniquement wp-admin et REST API) pour les adresses IP des pays sélectionnés. Ce n'est pas un remplacement du WAF, c'est un ajout. WAF analyse le contenu de la demande, géobloquant les filtres par source. Ensemble, ils créent un double filtre : premièrement, le trafic en provenance de régions non ciblées est coupé et ce qui reste est vérifié par le WAF pour déceler tout caractère malveillant.

Mais je veux être honnête : le géoblocage n'est pas pour tout le monde. Si votre boutique vend dans le monde entier, bloquer des pays est une mauvaise idée. Si vous avez des clients au Brésil ou en Inde, vous ne pouvez pas bloquer ces régions. Le géoblocage est idéal pour les magasins dont le marché géographique est clairement défini. Un magasin B2B russe qui vend uniquement en Russie et dans la CEI ? Vous pouvez bloquer en toute sécurité l'accès depuis des pays d'où les commandes ne viendront certainement pas, mais d'où viendront certainement les attaques. Un magasin qui travaille pour la Russie et l’UE ? Fermez les régions avec lesquelles vous ne travaillez pas. Chaque région bloquée signifie des milliers de requêtes malveillantes qui n'atteindront tout simplement pas votre serveur. Il s'agit à la fois de sécurité et d'économie des ressources du serveur.

Dans notre module, le blocage géographique est configuré via une interface pratique - sélectionnez les pays, indiquez ce qu'il faut bloquer (l'ensemble du site ou uniquement la zone d'administration) et activez-le. Les bases de données GeoIP sont mises à jour automatiquement. Vous pouvez définir une liste blanche pour des adresses IP spécifiques qui ne doivent pas être bloquées quel que soit le pays. Ceci est utile si vous avez un développeur distant d'une région bloquée.

Et encore un point qui mérite d'être souligné. Le géoblocage au niveau de l'application (notre plugin) fonctionne légèrement différemment du géoblocage au niveau du CDN (Cloudflare) ou du serveur (CSF/iptables). Au niveau applicatif, la requête est déjà parvenue à PHP, et nous la traitons. Cela signifie une charge minimale sur le serveur, mais la demande est toujours traitée. Si vous disposez de Cloudflare, l’idéal est d’activer le blocage géographique ici et là. Cloudflare coupera le trafic avant qu'il n'atteigne le serveur, et notre module récupérera ce qui s'est glissé via Cloudflare (par exemple, les requêtes directement adressées à l'adresse IP du serveur, en contournant le CDN). Défense en profondeur – vous vous souvenez ?

Gestion IP : listes noire et blanche, blocage automatique par motifs

La gestion IP est un outil qui semble à première vue primitif. Liste noire, liste blanche : qu'y a-t-il de si compliqué ? Mais lorsqu’il est utilisé correctement, il devient un outil tactique puissant. Je vais vous expliquer comment nous l'utilisons et pourquoi il est important en combinaison avec d'autres mesures.

La liste blanche est un territoire sacré. Des adresses IP qui ne sont jamais bloquées, en aucun cas. Cela inclut les adresses de votre bureau, les administrateurs IP de votre domicile, les adresses IP des services de confiance - systèmes de paiement, 1C, partenaires API. J'ai vu une situation dans laquelle le service de surveillance a commencé à envoyer des requêtes que le WAF a interprétées comme une analyse de vulnérabilité et les a bloquées. Le résultat a été que la surveillance a montré que le site était en panne, même s'il fonctionnait parfaitement. Une liste blanche résout ces problèmes.

La liste noire est un blocage dur. Une adresse sur liste noire est rejetée immédiatement, sans aucun traitement. La liste noire est pratique pour bloquer manuellement des sources d'attaques spécifiques que vous avez détectées dans les journaux. Si nous constatons qu’il y a une activité suspecte provenant d’une adresse IP spécifique, nous l’ajouterons à la liste noire, nous le découvrirons plus tard.

Mais le plus intéressant est le blocage automatique basé sur des modèles. Notre module peut envoyer automatiquement une IP à la liste noire si un certain comportement est détecté à partir de cette adresse : trop d'erreurs 404 en peu de temps (signe de scan), trop de tentatives de connexion, tentatives d'accès à des fichiers PHP inexistants, accès à des portes dérobées typiques (wp-config.php.bak, .env, debug.log). Cela fonctionne en conjonction avec WAF et LoginProtection, créant un système de réponse automatique : activité suspecte détectée - bloquée, enregistrée, notifiée à l'administrateur.

Vous savez ce que j'aime dans cette approche ? Il s'auto-apprend. Pas dans le sens de l’apprentissage automatique, mais dans le sens où chaque attaque rend le système plus fort. Chaque IP bloquée s'ajoute à la base de données, chaque modèle d'attaque affine les règles. Après un mois de fonctionnement, votre module de sécurité connaît les plages d'adresses IP spécifiques à partir desquelles votre site est le plus souvent attaqué et les bloque de manière proactive.

Surveillance de l'intégrité des fichiers : votre gardien silencieux

Parlons maintenant de ce qui se passe lorsque toutes les lignes de défense précédentes ont échoué. Disons que l'attaquant a quand même obtenu l'accès. Peut-être via une vulnérabilité dans un plugin tiers, via un compte d'hébergement FTP compromis, via une injection SQL que WAF n'a pas reconnu. Quelle est la première chose qu'il fait ? Il modifie les fichiers. Ajoute une porte dérobée au fichierfunctions.php du thème, place un shell PHP dans le répertoire de téléchargement, modifie les fichiers principaux de WordPress pour intercepter les informations d'identification.

File Integrity Monitoring (FIM) est un système qui surveille les modifications apportées aux fichiers principaux, plugins et thèmes de WordPress. Il prend un « instantané » du système de fichiers (un hachage de chaque fichier) et compare régulièrement l'état actuel à cet instantané. Si un fichier a changé, qu'un nouveau fichier est apparu là où il ne devrait pas être ou qu'un fichier qui devrait s'y trouver a disparu, l'administrateur reçoit une notification.

Je vais vous raconter la vraie histoire. Sur l'un des projets, nous avons découvert que quelqu'un avait modifié le fichier wp-includes/version.php. Ce fichier contient le numéro de version de WordPress et ne change généralement pas entre les mises à jour. Le changement était subtil : une ligne de code a été ajoutée à la fin du fichier, qui, sous certaines conditions, téléchargeait et exécutait un script depuis un serveur externe. Sans surveillance de l’intégrité, ce changement pourrait ne pas être remarqué avant des mois. Avec la surveillance, nous avons reçu une notification dans l'heure.

Dans notre module, la surveillance de l'intégrité fonctionne selon un calendrier - vous pouvez configurer un contrôle toutes les heures, toutes les six heures ou une fois par jour. Lorsque des modifications sont détectées, une notification par e-mail est envoyée avec une liste des fichiers modifiés. L'administrateur peut voir exactement ce qui a changé et décider s'il s'agit d'une mise à jour légitime du plugin ou d'une tentative d'introduction de code malveillant.

Remarque importante : lorsque vous mettez à jour WordPress, des plugins ou des thèmes, les fichiers changent naturellement. Un bon FIM doit être capable de distinguer les changements légitimes des changements suspects. Notre module sait quels fichiers sont inclus dans la distribution WordPress standard d'une certaine version et peut comparer vos fichiers avec ceux de référence. Si le fichier wp-login.php sur votre serveur diffère de celui fourni dans la version officielle de WordPress, cela est préoccupant.

Et ici je veux faire une digression philosophique. La surveillance de l'intégrité des fichiers n'est pas un outil de prévention. Il s'agit d'un outil de découverte. Cela n'arrêtera pas le piratage, mais il vous en informera rapidement. Et en cybersécurité, la vitesse de détection est primordiale. Selon les statistiques, le délai moyen entre un piratage et sa détection est de 197 jours pour les petites entreprises. Pendant près de sept mois, un attaquant peut s'emparer de votre site Web, voler des données, utiliser le serveur pour envoyer du spam, créer des liens malveillants - et vous n'en aurez même pas connaissance. La surveillance de l'intégrité réduit cette fenêtre à quelques heures.

Journal d'activité : une image complète de ce qui se passe

Le journal d'activité est une fonctionnalité dont les gens ne commencent à comprendre la valeur qu'après qu'un incident se produit. Lorsque tout va bien, le journal semble être un bruit inutile : « L'administrateur de l'utilisateur est connecté », « Le gestionnaire des utilisateurs a modifié le produit n° 15748 », « L'administrateur de l'utilisateur a mis à jour les paramètres du plugin ». C’est ennuyeux, sans intérêt, pourquoi le garder ? Et puis un incident survient, et la première question est : "Qui a fait ça ? Quand ? Qu'as-tu changé exactement ?" Et sans journal d’activité, il est impossible de répondre à ces questions.

Notre module ActivityLog enregistre toutes les activités importantes dans le panneau d'administration WordPress et WooCommerce. Connexions et déconnexions des utilisateurs (avec adresses IP et agent utilisateur). Création, modification et suppression de contenu - publications, pages, produits, commandes. Modification des paramètres - tous les paramètres, y compris les paramètres du plugin. Installation, activation et désactivation de plugins et thèmes. Actions avec les utilisateurs - création, suppression, modification de rôles. Travailler avec des fichiers multimédias. Et des dizaines d’autres types d’événements.

J'utilise les journaux d'activité non seulement pour les enquêtes sur les incidents, mais aussi pour la gestion quotidienne. Lorsqu'une équipe compte trois ou quatre personnes ayant accès à l'administrateur du magasin, le journal est votre outil de contrôle. Qui a changé le prix de ce produit ? Qui a supprimé cette catégorie ? Qui a installé cet étrange plugin ? Sans journal - accusations, malentendus, conflits. Avec un journal - faits, dates, heures. Rien de personnel, juste des données.

Et le journal d'activité est aussi un filet de sécurité juridique. En cas de litige avec un client qui prétend que sa commande a été modifiée à son insu, vous pouvez démontrer que la commande a été modifiée par un responsable précis à un moment précis. Ou vice versa, prouvez qu'aucun de vos employés n'a touché à la commande. Dans un monde où les litiges autour des données personnelles deviennent de plus en plus graves, ce niveau de documentation n’est pas un luxe, mais une nécessité.

Les journaux sont stockés dans une table de base de données distincte avec des contextes, ce qui permet de filtrer par utilisateur, par type d'action, par date. Vous pouvez configurer le nettoyage automatique des anciens enregistrements - par exemple, stocker les journaux des 90 derniers jours. C'est suffisant pour la plupart des magasins. Si vous avez besoin d'un archivage à long terme, vous pouvez exporter au format CSV.

Je trouve particulièrement utile la liaison du journal d'activité avec d'autres modules de sécurité. Lorsque WAF bloque une requête, celle-ci est enregistrée dans le journal. Lorsque LoginProtection bloque une adresse IP, elle entre dans le journal. Lorsque FIM détecte une modification de fichier, elle est consignée dans le journal. Vous disposez ainsi d’une chronologie unique de tous les événements de sécurité, consultables dans une seule interface. Pas besoin de basculer entre dix écrans de plugins différents – tout est au même endroit.

Pourquoi nous n'utilisons pas Wordfence et pourquoi vous ne devriez probablement pas non plus

Et c'est là que commence la partie amusante : la comparaison avec ce qui existe déjà sur le marché. Wordfence est le plugin de sécurité le plus populaire pour WordPress, avec plus de 4 millions d'installations actives. Il est bon, sérieux, mérité. Je l'utilise moi-même depuis plusieurs années sur divers projets. Et j'ai accumulé une liste de plaintes, qui ont finalement conduit à la décision de développer mon propre module.

Le premier problème est la taille et les performances. Wordfence est un monstre. La version gratuite occupe environ 30 Mo d'espace disque, la version Premium en prend encore plus. Mais la taille du disque n'est pas si mauvaise. Wordfence exécute son propre pare-feu à chaque requête adressée au site, analyse la base de données, vérifie les fichiers et appelle une API externe pour mettre à jour les signatures. Sur l'hébergement partagé, cela peut augmenter le temps de chargement des pages de 200 à 300 millisecondes. Sur une boutique WooCommerce très fréquentée avec des milliers de produits et un trafic actif, cela est perceptible.

Notre module de sécurité fait partie du COS de WP Woo qui pèse... eh bien, il fait partie d'un plugin, pas d'une entité distincte. Il ne possède pas son propre pare-feu de niveau PHP qui intercepte chaque requête via auto_prepend_file. Il fonctionne via des hooks WordPress standard, ce qui signifie une meilleure compatibilité et prévisibilité.

Le deuxième problème concerne les conflits de mise en cache. J'ai rencontré cela sur tous les autres projets Wordfence. LiteSpeed ​​​​Cache, WP Super Cache, W3 Total Cache - Wordfence entre en conflit avec eux avec une régularité enviable. Ensuite, il ne peut pas analyser les fichiers car le cache renvoie la page avant que Wordfence n'ait le temps de la vérifier. Ensuite son pare-feu bloque les requêtes du plugin de cache. Ensuite, la surveillance du trafic en direct commence à afficher les requêtes mises en cache comme « suspectes ». Sur un projet avec LiteSpeed, nous avons passé deux jours de travail à faire fonctionner Wordfence et LiteSpeed ​​​​Cache sans conflits. Deux jours de travail de développeur, c'est de l'argent réel.

Le troisième problème est le prix. Wordfence Premium coûte 119 $ par an pour un site. Si vous avez cinq magasins – 595 $ par an. Sur dix ans, six mille dollars rien que pour la sécurité. Et ceci malgré le fait que la version gratuite présente des limitations importantes : les signatures du pare-feu sont mises à jour avec un délai de 30 jours (trente jours, Karl ! - pendant ce temps la vulnérabilité aura le temps de devenir la propriété de chaque script kiddie), il n'y a pas de liste noire IP en temps réel, analyse limitée. Autrement dit, la version gratuite est en fait un outil marketing pour vendre Premium.

Notre module de sécurité n'a pas de version gratuite et payante. Toutes les fonctions - WAF, 2FA, géoblocage, FIM, journal d'activité, CAPTCHA, gestion IP, URL personnalisée, blocage XML-RPC, protection contre la force brute - sont disponibles dans le cadre de COS WP Woo. Un plugin, une licence, un ensemble complet d'outils. Vous ne payez pas séparément pour la sécurité, séparément pour le B2B, séparément pour la recherche, séparément pour l'intégration avec 1C. Tous ensemble.

Le quatrième défi est l'intégration. Wordfence est un plugin autonome. Il ne connaît rien de votre module B2B, de votre recherche, de votre CRM. Notre module de sécurité fait partie d’un écosystème unique. Il connaît les utilisateurs B2B et peut appliquer différentes politiques de sécurité pour différents groupes de clients. Il est intégré au module de notifications par e-mail. Il utilise un système de paramètres commun et une interface d'administration commune. Il ne s'agit pas d'un patchwork de dix plugins différents provenant de dix développeurs différents - c'est un système unique où tous les composants sont conçus pour fonctionner ensemble.

Je ne veux pas dire que Wordfence est un mauvais produit. Pour un blog WordPress classique où il n’y a pas de WooCommerce et où les performances ne sont pas critiques, Wordfence Premium est un excellent choix. Mais pour une boutique WooCommerce avec des milliers de produits, des fonctionnalités B2B, une intégration avec 1C et des exigences de performances, le module de sécurité intégré fonctionne mieux car il est conçu pour ce contexte.

Approche intégrée : comment tous les éléments fonctionnent ensemble

Je n'ai pas spécifiquement décrit chaque composant du module de sécurité comme une fonction isolée - car ils ne fonctionnent pas de manière isolée. L’idée est que chaque composant améliore les autres. Passons en revue un scénario d'attaque typique et voyons comment le système réagit à chaque étape.

Un robot du Vietnam tente d'accéder au site. Le géoblocage vérifie l'IP - Le Vietnam ne figure pas sur la liste des pays autorisés. La demande est bloquée. L'incident est enregistré dans le journal d'activité. C'est fait, l'histoire est terminée, elle n'est même pas arrivée au WAF.

Un autre robot, provenant d'un pays autorisé, tente d'accéder à /wp-login.php. Le module LoginUrl intercepte la demande - l'URL ne correspond pas à celle personnalisée. 404 est renvoyé. Le bot pense que le site n'a pas WordPress. Passons à autre chose.

Le troisième robot, plus avancé, a appris d'une manière ou d'une autre la véritable URL de connexion. J'essaie de deviner le mot de passe. Après la cinquième tentative, LoginProtection bloque l'adresse IP. Journalisation, notification à l'administrateur. L'adresse IP est automatiquement mise sur liste noire via IpManagement.

Le quatrième scénario est que l'attaquant ne tente pas de se connecter, mais tente une injection SQL via le paramètre de recherche. WAF reconnaît le modèle, bloque la demande et l'écrit dans le journal. L'adresse IP est envoyée en quarantaine.

Le cinquième scénario est qu'un attaquant ait trouvé une vulnérabilité dans un plugin tiers (pas le nôtre) et ait réussi à télécharger un shell PHP dans le répertoire de téléchargement. FIM détecte un nouveau fichier PHP où il ne devrait y avoir que des images. L'administrateur reçoit une notification, supprime le fichier et met à jour le plugin vulnérable.

Le sixième scénario est un robot essayant d'attaquer via xmlrpc.php. La requête est bloquée au niveau du module XmlRpc. Ce n'est même pas traité.

Vous voyez le modèle ? Chaque niveau a son propre filtre. Pour accéder à vos données, un attaquant doit passer par tous les niveaux. Chaque niveau est indépendant et autonome, mais ensemble, ils créent un système extrêmement difficile à contourner. Ce n'est pas seulement une serrure qui peut être crochetée, mais dix serrures, et chacune est plus difficile que la précédente.

J'entends souvent la question : « Est-ce que tout cela va ralentir mon site ? Bonne question. Réponse : non, si elle est correctement mise en œuvre. Le géoblocage est une vérification IP par rapport à une base de données en mémoire, en microsecondes. Vérification de l'URL de connexion - comparaison de chaînes, nanosecondes. WAF - un ensemble de vérifications d'expression régulière pour une demande entrante, quelques millisecondes. CAPTCHA est une vérification côté client et ne charge pas du tout le serveur. FIM fonctionne comme prévu, en arrière-plan. Journal d'activité - une insertion dans la base de données lors d'un événement. La charge totale de traitement d'une requête est d'environ 5 à 10 millisecondes. C'est plusieurs fois moins que Wordfence avec son analyse complète de chaque demande.

Il y a encore un point que je souhaite mentionner séparément, car il est souvent négligé. La sécurité n’est pas une configuration ponctuelle, c’est un processus. Vous pouvez parfaitement configurer tous les modules aujourd'hui, mais dans trois mois il y aura un nouveau vecteur d'attaque, une nouvelle vulnérabilité dans WordPress ou dans un de vos plugins, une nouvelle technique de contournement CAPTCHA. C'est pourquoi notre module est mis à jour avec le plugin - les règles WAF sont reconstituées, les bases de données GeoIP sont mises à jour, les algorithmes de détection sont améliorés. Vous n'avez pas besoin de le surveiller : les mises à jour arrivent automatiquement. Il s'agit d'une différence fondamentale avec l'approche « définissez-le et oubliez-le », qui se termine par le fait que six mois plus tard, votre « protection » fonctionne selon les règles d'il y a six mois et que les attaquants utilisent déjà des méthodes que votre plugin ne connaît pas encore.

Soyons clairs : la sécurité de la boutique WooCommerce n'est pas un domaine dans lequel vous devez lésiner ou tergiverser. Chaque jour sans protection est un jour où vos données, celles de vos clients et votre réputation sont en danger. J'ai vu des magasins fermer après une violation de données – non pas parce que la violation était catastrophique, mais parce que la confiance des clients ne pouvait pas être rétablie. J'ai vu des entreprises qui ont payé des centaines de milliers de roubles pour récupérer après un piratage - transfert vers un serveur propre, audit de code, notification aux clients, conseils juridiques. Et tout cela aurait pu être évité grâce à un module paramétrable en une demi-heure.

Notre approche n'est pas de vendre la sécurité comme un produit coûteux et distinct, mais d'en faire une partie intégrante de l'outil que vous utilisez déjà pour gérer votre boutique. Pas besoin d'installer un plugin séparé, pas besoin d'acheter une licence distincte, pas besoin de comprendre l'interface d'un autre produit. Ouvrez les paramètres de COS WP Woo, accédez à la section Sécurité, activez les modules nécessaires - et votre boutique est protégée. WAF fonctionne, 2FA est configuré, le géoblocage filtre le trafic indésirable, la surveillance surveille les fichiers, un journal enregistre chaque action. Pas un outil, mais dix - et ils fonctionnent tous harmonieusement, comme les éléments d'un même mécanisme.

Et si vous le regardiez d'un point de vue business ? Le coût d'un incident de sécurité pour une boutique en ligne moyenne est de 200 000 à 2 000 000 de roubles, si l'on compte les pertes directes (recouvrement, audit, avocats) et indirectes (perte de clients, atteinte à la réputation, interruption de l'activité). Le coût de la prévention est de zéro rouble supplémentaire si vous disposez déjà de COS WP Woo. Je ne connais pas de meilleur investissement commercial. Le calcul est simple : passez une demi-heure à la configuration maintenant ou passez des semaines à la restaurer plus tard. Il me semble que le choix est évident. Et le client qui m'a appelé avec la phrase « nous avons été piratés » serait désormais d'accord avec cela.

Essayez COS WP Woo gratuitement- installez le plugin et bénéficiez de 14 jours d'accès complet à tous les modules, y compris la sécurité. WAF, authentification à deux facteurs, géoblocage, surveillance des fichiers, journal d'activité - tout cela commencera à protéger votre boutique dès la première minute. Aucune restriction, pas de frais cachés, pas besoin d'acheter cinq plugins différents. Un outil - une protection complète.