Protection Anti-Bot

Protection Anti-Bot : Des Machines, Pas des Humains

Un "bot" est un programme qui accède automatiquement à votre site sans intervention humaine. Certains bots sont bons (Google), d'autres sont malveillants (spam, scraping, attaques).

La Protection Anti-Bot de SeenSecure détecte si ce qui accède réellement est un humain ou une machine. S'il s'agit d'un bot malveillant, il le bloque. S'il s'agit d'un bon bot (Googlebot), il le laisse passer.

Types de Bots

Bots Légitimes (Autorisés)

Bot	Objectif	Avantage
Googlebot	Indexe pour la recherche Google	Votre site apparaît sur Google
Bingbot	Indexe pour la recherche Bing	Votre site apparaît sur Bing
Facebook Crawler	Récupère les métadonnées pour le partage	Les liens sur Facebook affichent un aperçu
Slack Bot	Récupère les métadonnées pour Slack	Les liens dans Slack affichent des infos

Bots Malveillants (Bloqués)

• Scrapers : Copient votre contenu
• Bots de Force Brute : Essaient des mots de passe automatiquement
• Bots de Spam : Publient du spam dans les commentaires
• Bots DDoS : Envoient des milliers de requêtes pour faire tomber le site
• Bots Malveillants : Recherchent des vulnérabilités
• Bots à Rotation de Proxies : Cachent leur identité pour échapper aux blocages

Bots Ambigus (Selon le Contexte)

Certains bots ne sont pas clairement bons ou mauvais. Exemple :

• Pingdom : Surveillance légitime de disponibilité
• Crawlers Génériques : Peuvent être à des fins de recherche ou malveillants
• Outils SEO : Outils d'analyse (légaux mais agressifs)

Couche 1 : Filtrage par Identité

La première couche n'analyse pas le comportement et n'attend pas de voir ce que fait le visiteur — elle juge d'après ce que la requête dit d'elle-même, avant même que WordPress ne se charge. C'est la moins coûteuse à exécuter (aucune requête à la base de données, aucun calcul), c'est pourquoi elle passe en premier : elle écarte le trafic manifestement automatisé en microsecondes, laissant les couches plus coûteuses ne s'occuper que de ce qui a déjà franchi ce premier filtre.

Liste Noire de User-Agent

Chaque visiteur (humain ou machine) envoie un en-tête User-Agent indiquant quel logiciel il utilise. Un vrai navigateur envoie quelque chose comme Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36. De nombreux outils automatisés de scraping et d'attaque, en revanche, utilisent leur vrai nom sans se déguiser — soit parce que leur créateur n'a jamais pensé à le cacher, soit parce que modifier le User-Agent dans certains outils demande une configuration supplémentaire que presque personne ne fait.

Vrai navigateur : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Bot légitime :    Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Outil :           python-requests/2.25.1
Outil :           curl/7.68.0
Outil :           Scrapy/2.5.0 (+https://scrapy.org)
Vide :            (aucun en-tête User-Agent)
                

SeenSecure maintient une liste de 21 signatures connues d'outils de scan et de pentest (sqlmap, Nikto, Nmap, masscan, Metasploit, Hydra, etc.) et bloque la requête dès que le User-Agent correspond — avant de dépenser la moindre autre ressource à l'analyser.

Blocage HTTP/1.0

HTTP possède plusieurs versions de protocole. HTTP/1.0, datant de 1996, est la plus ancienne et pratiquement aucun navigateur moderne ne l'utilise plus — Chrome, Firefox, Safari et Edge négocient automatiquement HTTP/1.1, HTTP/2 ou HTTP/3 avec le serveur. Si une requête réelle arrive en s'annonçant comme HTTP/1.0, elle ne provient presque certainement pas d'un vrai navigateur, mais d'un script simple construit avec une bibliothèque minimale qui n'a jamais mis à jour sa version de protocole par défaut.

En-tête de Langue Absent ou Incohérent

Un vrai navigateur envoie toujours l'en-tête Accept-Language, indiquant dans quelle langue il préfère recevoir le contenu (défini par le système d'exploitation ou le navigateur lui-même). Un script écrit à la main ne prend presque jamais la peine de l'ajouter — personne qui cherche seulement à extraire des données ou tester des vulnérabilités ne se soucie de la langue de réponse du serveur. Son absence totale est donc un signal fort de trafic non humain.

Et ce n'est pas seulement l'absence qui compte : la langue déclarée est aussi comparée au pays d'origine de l'IP (via géolocalisation). Un visiteur affirmant préférer le "zh-CN" (chinois) mais se connectant depuis une IP résidentielle d'un pays où cette langue est rare correspond à un schéma typique de trafic acheminé via un proxy ou VPN mal configuré — cela ne prouve rien à soi seul, mais ajoute des points de suspicion avec les autres signaux de cette couche.

Exclusions d'URL de l'Anti-Bot (Crontab et Scripts Externes)

Comment Identifier Exactement Quel Chemin Exclure

1. Ouvrez Pare-feu › Journaux › Traffic Log et trouvez la ligne bloquée.
2. Copiez la partie chemin de la colonne Request, ex. /planification/script_general_diario.php.
3. Collez-la dans le champ « Exclusions d'URL de l'Anti-Bot », un chemin par ligne, et enregistrez la Couche 1.

Le joker * est pris en charge (ex. /cron/* exclut tout sous /cron/) ainsi que la correspondance par préfixe. /wp-cron.php est déjà exclu par défaut.

Couche 2 : Empreinte du Navigateur

Un attaquant plus sophistiqué n'utilise pas un simple script curl — il utilise un navigateur headless (vrai Chrome ou Firefox, mais contrôlé par du code plutôt que par un humain, sans interface visuelle) précisément pour franchir la Couche 1 sans problème : le User-Agent est identique à celui d'un Chrome normal, la version HTTP est correcte, et il peut même envoyer Accept-Language. La Couche 2 existe pour détecter exactement ce cas, en examinant des propriétés du navigateur que les logiciels d'automatisation laissent exposées même en essayant de se faire passer pour un navigateur normal.

Comment ça marche : quand un visiteur charge une page protégée, un petit script dans le navigateur recueille une poignée de caractéristiques techniques — s'il répond aux requêtes Canvas et WebGL (graphiques), quels plugins sont installés, la résolution d'écran réelle, l'ordre d'arrivée des en-têtes HTTP, et sa rapidité de réaction. Chacune ajoute ou retranche à un score sur 100 : un humain normal avec un vrai navigateur obtient un score élevé ; un navigateur headless sans interface graphique échoue à plusieurs de ces vérifications à la fois et obtient un score bas.

Comment l'Activer et la Configurer

SeenSecure > Firewall > Anti-Bot > Couche 2 : Bot Fingerprint Analyzer > Activé

Champ	Ce qu'il fait
Action à la détection d'un bot	Journaliser seulement, forcer un CAPTCHA, ou bloquer l'accès directement
Score minimum	Curseur de 0 à 100 : les visiteurs en dessous de ce seuil sont traités comme suspects
Vérifier sur	Page de connexion et/ou frontend (commentaires, formulaires publics)
Modules de détection	5 interrupteurs indépendants : détection headless, empreinte Canvas, rendu WebGL, analyse de timing, détection de fonctionnalités

Couche 2+ : Détection Avancée du Comportement Humain (PRO)

Comment ça marche : la souris d'une personne réelle se déplace de façon irrégulière, avec de petites corrections et des pauses — jamais en ligne parfaitement droite. En tapant, il existe des rythmes naturels entre les touches qui ne sont jamais parfaitement réguliers. Un script automatisé, en revanche, déplace généralement la souris en ligne droite jusqu'au champ (ou ne la déplace pas du tout) et tape avec un intervalle presque toujours identique entre les frappes. Ces signaux s'ajoutent au même score déjà calculé par la Couche 2 — ce n'est ni un score ni une action indépendante.

Comment l'Activer

SeenSecure > Firewall > Anti-Bot > Couche 2+ : Détection Avancée du Comportement Humain > Activé

Une fois activée, elle s'ajoute au score de la Couche 2 : si le comportement semble suspect, le score baisse et la même action (journalisation, CAPTCHA ou blocage) déjà configurée sur la Couche 2 s'applique — il n'y a pas de réglage indépendant à configurer.

Couche 3 : Vérification des Crawlers

N'importe qui peut mettre "Googlebot" dans son User-Agent — ce n'est que du texte, aucune vérification automatique ne l'empêche au niveau du protocole. De nombreux bots malveillants font exactement cela, se faisant passer pour Googlebot ou Bingbot pour tenter de faire en sorte que le pare-feu les laisse passer sans autre question, en misant sur le fait que de nombreux sites font aveuglément confiance à ce nom.

SeenSecure vérifie la véritable identité avec une technique standard de l'industrie : le DNS inversé. Lorsqu'une requête prétend être Googlebot, le système résout le nom de domaine réel associé à cette adresse IP (Google, par exemple, résout toujours vers un domaine se terminant par .googlebot.com ou .google.com) et, en cas de correspondance, effectue une seconde vérification dans le sens inverse (DNS direct de ce domaine vers l'IP) pour confirmer qu'elle n'a pas été falsifiée. Ce n'est que si les deux vérifications correspondent que la requête est considérée comme provenant réellement de Google.

Comment Configurer la Protection Anti-Bot

Étape 1 : Activer la Protection

SeenSecure > Firewall > Bot Protection > Activer

Étape 2 : Choisir le Niveau de Protection

• Permissif : Bloque uniquement les bots manifestement malveillants. Googlebot passe sans CAPTCHA
• Modéré (Recommandé) : Détecte les bots suspects, peut demander un CAPTCHA à certains
• Agressif : Tout bot non reconnu = CAPTCHA. Google doit aussi faire ses preuves

Étape 3 : Définir le Comportement à la Détection

• Bloquer : Rejette immédiatement (erreur 403)
• Défi : Demande de résoudre un CAPTCHA
• Enregistrer : Enregistre seulement dans le journal, autorise l'accès (débogage)

Étape 4 : Autoriser des Bots Spécifiques (Liste Blanche)

S'il y a des crawlers légitimes que vous souhaitez autoriser sans CAPTCHA :

Liste blanche :
- Googlebot
- Bingbot
- facebookexternalhit
- Slurp (Yahoo)
                

Étape 5 : Bloquer des Bots Spécifiques (Liste Noire)

Si vous connaissez des bots spécifiquement malveillants :

Liste noire :
- MJ12Bot (SEO malveillant)
- DotBot (scraper)
- AhrefsBot (agressif)
                

Couche 4 : Contrôle de robots.txt et Sitemap XML

Cette couche ne bloque rien par elle-même — c'est une consigne qui indique aux moteurs de recherche (Google, Bing) quelles parties de votre site ils peuvent explorer. Elle complète les autres couches : alors que les couches 1-3 détectent les bots malveillants qui ignorent les règles, la couche 4 organise le comportement des bots légitimes qui les respectent.

Éditeur de robots.txt

Dans Pare-feu > Anti-Bot > Couche 4, activez « Personnaliser robots.txt » et choisissez entre :

• Modèles prédéfinis : configurations toutes faites pour les cas courants (bloquer /wp-admin/, tout autoriser, tout bloquer, etc.), utilisables sans écrire une seule ligne
• Directives personnalisées : vous choisissez vous-même, case par case, quelles parties de WordPress bloquer aux moteurs de recherche (zone d'administration /wp-admin/, fichiers internes /wp-includes/, API REST /wp-json/ et /?rest_route=, ou /xmlrpc.php)

Générateur de Sitemap XML

Sur le même écran, activez « Servir le sitemap.xml généré par SeenSecure » pour publier une carte complète de votre site sur votresite.com/sitemap.xml — le fichier que les moteurs de recherche utilisent pour découvrir toutes vos pages d'un coup, au lieu de devoir les trouver lien par lien.

Option	Ce que ça fait
Exclure les routes bloquées	Le sitemap n'inclut pas les pages déjà marquées comme bloquées dans les directives robots.txt ci-dessus
Cache (secondes)	Durée de conservation du sitemap généré avant recalcul. Pas besoin d'attendre : il se régénère automatiquement à chaque publication ou mise à jour de contenu
Chemins supplémentaires	URLs qui ne sont pas des pages/articles WordPress mais que vous voulez quand même inclure (une par ligne ; les URLs externes complètes sont aussi acceptées)

Couche 5 : Validation Stricte des IP (Anti-Spoofing)

Cette couche n'est pas une nouvelle limite — elle protège toutes les autres. Limitation de débit, blocages de connexion, géoblocage, listes d'IP... toutes ces protections décident quoi faire selon l'adresse IP du visiteur. Le problème : certains en-têtes HTTP (X-Forwarded-For, X-Real-IP, CF-Connecting-IP) peuvent être falsifiés à la main par un visiteur pour se faire passer pour une IP différente de celle réelle de sa connexion — et si le pare-feu fait aveuglément confiance à ces en-têtes, tous vos compteurs et blocages par IP peuvent être contournés simplement en mentant sur sa propre IP.

Couche 6 : Protection Contre Scan Masse 404

À quoi ça sert : quand le même visiteur demande, l'une après l'autre en quelques minutes, de nombreuses pages qui n'existent pas sur votre site, c'est un signe très fiable qu'il scanne à la recherche de failles — aucun humain ne navigue ainsi, et aucun bot de moteur de recherche légitime (Google, Bing) ne génère ce motif. Cette couche compte ces erreurs 404 par IP et interrompt le scan avant qu'il ne se termine.

Pourquoi un attaquant la tente : les outils de scan automatisés (comme Nuclei ou Nikto) essaient des dizaines ou des centaines de chemins connus en quelques secondes — /wp-config.php.bak, /.env, /database.sql, /admin.php — à la recherche d'un fichier sensible resté accessible par erreur. C'est une étape de reconnaissance avant une attaque réelle : plus il essaie de chemins, plus il a de chances de trouver quelque chose d'exploitable.

Comment ça marche : pour chaque IP, le plugin compte combien de pages 404 elle demande dans la fenêtre de temps configurée. Si le seuil est dépassé, cette IP est bloquée pour la durée configurée (ou simplement journalisée, selon l'action choisie). Comme le reste du pare-feu, cette couche respecte le mode global : en mode Surveillance, elle journalise seulement, sans jamais bloquer ; en mode Protection/Strict, elle applique l'action configurée. Vous pouvez exclure les chemins qui génèrent des 404 légitimes (favicon.ico, robots.txt, etc.) pour qu'ils ne comptent pas dans le seuil.

Configuration

Champ	Ce qu'il fait	Défaut
Seuil de 404	Nombre de pages non trouvées qui déclenchent le blocage	12
Fenêtre de temps	Période pendant laquelle les 404 sont comptés	5 min
Durée du blocage	Temps pendant lequel l'IP reste bloquée	10 min
Action	Bloquer l'IP (403) ou journaliser seulement	Bloquer

Mode Privé

Un interrupteur conçu pour les sites qui ne doivent apparaître dans aucun moteur de recherche : intranets, environnements de préproduction, sites en construction ou projets privés. L'activer depuis Pare-feu > Anti-Bot fait trois choses à la fois :

• robots.txt se met à tout bloquer (Disallow: /), quelle que soit la configuration de la Couche 4
• Chaque page envoie l'en-tête X-Robots-Tag: noindex, nofollow, le signal direct qui indique à un moteur de recherche « ne me garde pas dans ton index et ne suis pas mes liens »
• Le pare-feu bloque tout bot détecté, y compris les moteurs de recherche légitimes comme Google ou Bing — sans exception

Meilleures Pratiques

Pour les Sites Publics (Blog, Boutique)

• Utilisez le niveau "Permissif"
• Laissez Googlebot et Bingbot sans CAPTCHA (vous avez besoin de l'indexation)
• Bloquez les bots scrapers connus

Pour les Sites Privés (Admin, Communauté)

• Utilisez le niveau "Agressif"
• Exigez un CAPTCHA pour tout accès initial
• Mettez sur liste blanche uniquement les IPs des employés (pas de bots)

Pour l'E-commerce (Boutique en Ligne)

• Niveau "Modéré"
• Protégez agressivement le checkout (Agressif sur /checkout)
• Le public peut naviguer sans CAPTCHA

Interprétation des Journaux

• Bot = Googlebot, demande un CAPTCHA : Ce n'est pas le vrai Googlebot, c'est un faux. Bloquez-le.
• User-Agent vide + en-têtes suspects : Clairement malveillant.
• Bot légitime bloqué : Vérifiez s'il s'agit d'un faux positif, mettez-le sur liste blanche si légitime.

🔧 Résolution de Problèmes

Un visiteur légitime a été bloqué ou reçoit sans cesse un CAPTCHA

C'est le symptôme le plus courant d'un faux positif. Avant de toucher à quoi que ce soit, confirmez la cause réelle dans Firewall → Traffic Log : recherchez l'IP ou l'heure approximative et regardez la colonne "PROTECTION" — elle indique exactement quelle couche a agi, ne supposez pas que c'était la Protection Anti-Bot sans vérifier.

• Si c'était la Couche 2 (Fingerprint) ou la Couche 3 (Vérification des crawlers) : chacune a, sur sa propre carte dans Firewall → Anti-Bot, un menu d'action avec l'option 📝 "Enregistrer uniquement" — basculez-la temporairement là plutôt que de désactiver toute la couche : vous continuez à voir dans le Traffic Log ce qui aurait été bloqué, sans exclure personne pendant l'ajustement.
• Si c'était la Couche 5 (Validation Stricte des IP) : la carte de cette couche prévient déjà de la cause la plus fréquente : certains proxys d'entreprise ou d'opérateurs mobiles réécrivent l'en-tête X-Forwarded-For sur des connexions légitimes. Si vous avez activé l'interrupteur supplémentaire "🚫 Bloquer l'IP en cas de spoofing", désactivez-le d'abord — vous pouvez garder la validation active (elle continue à corriger l'IP utilisée par vos compteurs) sans le blocage strict.

Je dois débloquer quelqu'un immédiatement

Ajoutez-le directement dans Firewall → Listes d'IP (liste blanche) : cela a priorité absolue sur toute couche Anti-Bot, y compris la Couche 2+. Pas besoin d'attendre l'expiration du blocage ni de toucher la configuration de cette couche.

Questions Fréquentes

Est-ce que cela ralentit mon site avec le CAPTCHA ? Seulement si un visiteur est détecté comme un bot. Les humains passent normalement sans CAPTCHA.

Puis-je autoriser Googlebot mais bloquer les autres bots ? Oui, c'est l'idéal. Liste blanche pour Googlebot/Bing, liste noire pour le reste.

Que se passe-t-il si des utilisateurs légitimes sont signalés comme des bots ? On leur demande de résoudre un CAPTCHA. Si cela arrive fréquemment, réduisez l'agressivité.

Les flux RSS sont-ils affectés ? Non, RSS est différent. Mais certains lecteurs peuvent être détectés comme des bots (normal).

Qu'est-ce que la "Première Ligne" mentionnée dans le panneau Rate Limiting ? C'est une couche de protection distincte, qui n'est pas spécifique aux bots : elle agit avant même le chargement de WordPress, pour arrêter les pics de trafic ou les attaques trop importantes ou trop rapides pour que le reste du plugin puisse réagir. Elle s'active et se configure dans Firewall → Rate Limiting → "🚀 Première Ligne". Dans le cadre de cette protection, et pour ne pas nuire à votre référencement, elle vérifie aussi qu'une visite prétendant être un moteur de recherche ou un assistant IA légitime l'est vraiment avant d'appliquer une limite — il ne suffit pas que la requête l'affirme : elle est recoupée avec les données officielles de l'entreprise concernée, donc personne ne passe en changeant simplement un en-tête.

La Couche 2+ (Comportement Humain) ne fonctionne-t-elle que sur la connexion et l'inscription ? Par défaut oui, car c'est là qu'elle compte le plus (un vrai bot de recherche navigue et lit, il n'essaie jamais de se connecter). Vous pouvez l'étendre à "n'importe quel formulaire du site" depuis sa propre carte dans Firewall → Anti-Bot si vous voulez aussi protéger un formulaire de contact ou similaire.

Quelle est la différence entre bloquer et "enregistrer uniquement" sur chaque couche ? "Enregistrer uniquement" vous permet de voir dans le Traffic Log ce que cette couche aurait bloqué, sans affecter aucun visiteur réel — utile pour tester une nouvelle couche avant de l'activer pour de bon.

Puis-je désactiver une seule couche et laisser les autres actives ? Oui, chacune des 6 couches (et la Couche 2+) s'active/se désactive indépendamment ; aucune ne dépend des autres pour fonctionner.

Augmenter l'agressivité nuit-il à mon classement Google ? Ça ne devrait pas : Googlebot et les autres moteurs de recherche/assistants IA légitimes sont vérifiés par DNS inverse (Couche 3) et par des listes officielles, pas par ce que prétendent leurs en-têtes — ils continuent de passer même quand le reste du trafic est traité plus strictement.