D’accord, les amis, Pat Reeves ici, apparaissant dans vos fils depuis botsec.net. Nous sommes le 23 mars 2026, et j’ai récemment eu un mal de tête lié aux bots d’un genre particulier. Pas le genre sophistiqué, sponsorisé par des États-nations – même si c’est toujours intéressant à analyser – mais la nuisance automatisée, un peu trop astucieuse, qui cible l’un de mes projets secondaires.
Mon projet secondaire, pour remettre dans le contexte, est un petit forum de niche pour les passionnés d’informatique rétro. Rien de notable, juste un endroit pour nous, les anciens, pour nous plaindre des processeurs modernes et débattre sur la meilleure façon d’émuler un Amiga. Le trafic n’est pas énorme, mais la passion est là, et pendant des mois, le forum a été joyeusement exempt de bots. Jusqu’au mois dernier.
Subitement, des bots d’enregistrement. Pas juste un filet, mais des vagues. Des centaines de faux comptes, tous avec des noms d’utilisateur légèrement randomisés, des adresses email génériques (souvent provenant de domaines nouvellement enregistrés), et absolument aucun historique de publication. Ils ne faisaient pas de spam immédiatement, ce qui était étrange. Ils étaient juste… en train de s’enregistrer. Et de remplir ma base de données d’utilisateurs, rendant sa gestion pénible, et honnêtement, me donnant l’impression que mon petit havre numérique était envahi.
Alors, ce mois-ci, nous parlons de Vulnérabilité : L’onde silencieuse – Pourquoi les enregistrements de bots à faible effort sont une menace plus grande que vous ne le pensez (et comment les arrêter).
L’ennui qui devient une menace
Vous pourriez penser : « Pat, ce ne sont que des enregistrements. Pas de quoi en faire un plat, n’est-ce pas ? Supprime-les et passe à autre chose. » Et pendant un moment, c’était exactement mon raisonnement. J’ai mis en place un travail cron pour purger les comptes sans publications après 24 heures. Problème résolu, non ? Faux.
Les bots se sont adaptés. Ils ont commencé à faire une seule publication innocente. « Bonjour ! » ou « Content d’être ici. » Rien qui déclencherait mes filtres anti-spam. Juste assez pour éviter la purge des comptes sans publications. Maintenant, j’avais des centaines de comptes avec une publication inutile, continuant à encombrer ma base de données, toujours nécessitant une revue manuelle.
Ce n’est pas juste un ennui. C’est une attaque subtile et insidieuse. Voici pourquoi :
- Drain de ressources : Chaque enregistrement, chaque entrée de base de données, chaque petite publication consomme des ressources serveur. Pour un petit site comme le mien, ce n’est pas négligeable. Si le volume augmente, cela peut entraîner une dégradation des performances ou même un déni de service pour les utilisateurs légitimes.
- Pollution des données : Mes tables d’utilisateurs étaient en désordre. Trouver de vrais utilisateurs, analyser l’activité, ou même simplement sauvegarder la base de données est devenu plus compliqué.
- Risque de réputation : Si ces comptes commençaient soudainement à faire du spam ou du phishing, la réputation de mon forum pourrait en pâtir. Les moteurs de recherche n’apprécient pas les sites associés à des activités malveillantes.
- Précurseur à de plus grandes attaques : Souvent, les bots d’enregistrement à faible effort sont une étape de reconnaissance. Ils testent les eaux, identifient les faiblesses, et établissent une base pour des attaques plus sophistiquées plus tard, comme le credential stuffing ou même le spear-phishing d’utilisateurs authentiques.
- Risques de credential stuffing et de prise de contrôle de compte (ATO) : C’est le gros point. Si un bot enregistre un compte et qu’un utilisateur légitime essaie plus tard de s’enregistrer avec le même nom d’utilisateur/email (ou un commun), l’opérateur du bot a maintenant une cible potentielle pour le credential stuffing s’ils ont acquis des identifiants d’une autre violation. Ils peuvent essayer ces identifiants sur mon site.
Donc, ce qui a commencé comme un problème de « meh, je le nettoierai plus tard » s’est rapidement transformé en une situation de « cela doit cesser maintenant ».
Mes premières tentatives (échouées) : Le piège CAPTCHA
Ma réaction initiale, comme beaucoup, était de lancer un CAPTCHA. Plus précisément, reCAPTCHA v2. Tout le monde connaît reCAPTCHA, n’est-ce pas ? La case à cocher « Je ne suis pas un robot », peut-être quelques panneaux de signalisation flous.
Je l’ai mis en place. Pendant environ trois jours, les enregistrements ont chuté presque à zéro. Je me suis félicité. « Aha ! Résolu ! »
Puis, ils sont revenus. Pas autant, mais suffisamment. Comment ? Eh bien, pour reCAPTCHA v2, il existe des services qui paient des humains en centimes pour résoudre des CAPTCHAs. Ou, de plus en plus, des modèles d’IA deviennent suffisamment performants pour les déchiffrer, surtout les plus simples. C’est un jeu du chat et de la souris, et sur un site à faible trafic, cela ne valait pas le surcoût de reCAPTCHA v3 (qui peut être un cauchemar à régler sans que des utilisateurs légitimes soient signalés).
De plus, les utilisateurs légitimes DÉTESTENT les CAPTCHAs. J’ai reçu quelques plaintes. Mon public sur l’informatique rétro, que Dieu les bénisse, n’est pas toujours le plus patient face aux irritations modernes du web. J’avais besoin de quelque chose de moins intrusif, plus efficace contre les bots, et moins agaçant pour les humains.
Au-delà de la case à cocher : Défenses pratiques
Après avoir abandonné le CAPTCHA visible, j’ai commencé à réfléchir à ce qui distingue un humain d’un bot, au-delà du simple fait de cocher une case. Voici ce qui a réellement fonctionné pour moi :
1. Le champ piège à miel
C’est un classique pour une raison. C’est simple, efficace, et complètement invisible pour les utilisateurs humains. L’idée est d’ajouter un champ supplémentaire, caché, à votre formulaire d’enregistrement. Les bots, étant moins sophistiqués que les humains, essaieront souvent de remplir tous les champs qu’ils trouvent. Les humains ne le verront pas, donc ils ne le rempliront pas.
Voici un exemple simplifié de ce que j’ai ajouté à mon formulaire d’enregistrement HTML :
<form action="/register" method="POST">
<label for="username">Nom d'utilisateur :</label>
<input type="text" id="username" name="username" required>
<label for="email">Email :</label>
<input type="email" id="email" name="email" required>
<!-- Champ piège à miel -->
<div style="display:none;">
<label for="fax_number">Numéro de fax (laisser vide) :</label>
<input type="text" id="fax_number" name="fax_number" tabindex="-1" autocomplete="off">
</div>
<label for="password">Mot de passe :</label>
<input type="password" id="password" name="password" required>
<button type="submit">S'inscrire</button>
</form>
Et côté serveur (en utilisant un exemple Python/Flask, mais la logique s’applique universellement) :
@app.route('/register', methods=['POST'])
def register():
# Vérifiez le champ piège à miel
if request.form.get('fax_number'):
# Bot détecté ! Enregistrez-le, peut-être bloquez l'IP, et retournez une erreur
print(f"Piège à miel déclenché par l'IP : {request.remote_addr}")
return "Échec de l'enregistrement. Veuillez réessayer.", 400 # Ou un message de succès générique pour embrouiller les bots
username = request.form.get('username')
email = request.form.get('email')
password = request.form.get('password')
# ... reste de votre logique d'enregistrement ...
return "Enregistrement réussi !"
Le display:none; le rend invisible. tabindex="-1" empêche la navigation au clavier vers celui-ci. autocomplete="off" aide à empêcher les navigateurs de le remplir automatiquement. J’ai choisi « fax_number » parce que c’est un champ old-school qui n’a pas sa place sur un formulaire d’enregistrement moderne, en faisant un bon « appât. »
2. Analyse basée sur le temps (vérification du timestamp)
Les bots soumettent souvent des formulaires incroyablement vite. Les humains prennent au moins quelques secondes pour remplir même un formulaire simple. J’enregistre le temps où le formulaire est chargé et le temps de soumission.
Quand le formulaire d’enregistrement est servi :
<form action="/register" method="POST">
<!-- Autres champs du formulaire -->
<input type="hidden" name="form_load_time" value="{{ current_timestamp_in_seconds }}">
<button type="submit">S'inscrire</button>
</form>
Côté serveur :
import time
@app.route('/register', methods=['POST'])
def register():
form_load_time = int(request.form.get('form_load_time', 0))
submission_time = int(time.time())
time_taken = submission_time - form_load_time
# Si le formulaire a été soumis trop rapidement (par exemple, moins de 5 secondes)
if time_taken < 5:
print(f"Soumission trop rapide par l'IP : {request.remote_addr}, a pris {time_taken}s")
return "Échec de l'enregistrement. Veuillez réessayer.", 400
# ... reste de votre logique d'enregistrement ...
return "Enregistrement réussi !"
Je me suis fixé une minimum de 5 secondes. Cela a immédiatement attrapé une bonne partie des bots restants. Faites attention à ne pas rendre ce seuil trop élevé, car des utilisateurs légitimes pourraient taper rapidement ou avoir des formulaires pré-remplis.
3. Limitation de débit par IP (avec une tournure)
La limitation de débit par IP standard est bonne : « Pas plus de 5 enregistrements de cette IP par heure. » Mais les bots utilisent souvent des proxies ou changent d’IP. Donc, j’ai ajouté une tournure : l’empreinte IP et User-Agent.
J’ai commencé à enregistrer la chaîne User-Agent avec l’adresse IP. Si je voyais une soudain hausse des enregistrements provenant de différentes IP mais avec la même chaîne User-Agent, légèrement inhabituelle, c’était un fort indicateur d’un botnet ou d’un seul bot changeant d’IP. Cela m’a permis de bloquer ou de signaler temporairement non seulement l’IP, mais également le User-Agent s’il était clairement non naviguateur ou répété de manière suspecte.
Ce n’est pas un extrait de code que vous pouvez juste insérer, car cela nécessite un certain logging et une analyse en backend. Mais conceptuellement, il s’agit d’examiner des motifs au-delà de la simple IP source. Beaucoup de pare-feu d’application web (WAFs) offrent ce type de limitation avancée de débit et de détection d’anomalies.
4. Vérification du domaine de l’email (en utilisant des données publiques)
De nombreux enregistrements de bots proviennent de domaines email nouvellement enregistrés, souvent jetables. J’ai mis en place une vérification contre une petite liste soignée de fournisseurs d’email jetables connus, mais plus efficacement, j’ai commencé à regarder l’âge du domaine email lui-même.
Il existe des API (certaines payantes, d’autres gratuites avec des limitations) qui peuvent vous indiquer quand un domaine a été enregistré. Si une adresse e-mail provient d’un domaine enregistré dans les 30 derniers jours, c’est un énorme signal d’alerte. Ce n’est pas infaillible – de nouveaux sites légitimes sont lancés tout le temps – mais combiné avec d’autres signaux, c’est puissant.
Pour mon forum, j’ai pris une décision pragmatique : si le domaine avait moins de 60 jours ET que d’autres signaux de bot étaient présents (honeypot déclenché, soumission trop rapide), je bloquerais tout simplement l’enregistrement. Pour les domaines de moins de 30 jours, je les signalerais pour un examen manuel et demanderais potentiellement une confirmation par e-mail avant activation.
Les Résultats : La Paix (Presque) Rétablie
Mettre en œuvre ces étapes n’a pas été une solution rapide, mais c’était incroyablement efficace. Le honeypot et les vérifications basées sur le temps ont immédiatement réduit la majorité des enregistrements automatisés. L’analyse des motifs d’IP/User-Agent m’a aidé à identifier et bloquer les opérateurs de bots les plus persistants.
Ma base de données d’utilisateurs est à nouveau propre. Mes journaux de serveur sont moins bruyants. Et je peux me concentrer sur la modération des discussions sur la supériorité du chip SID du Commodore 64, au lieu de supprimer des centaines de faux comptes.
Il est important de comprendre que ce n’est pas une solution « à installer et à oublier ». Les bots évoluent. Les attaquants trouvent de nouvelles méthodes. Je vais devoir surveiller et m’adapter. Mais pour le moment, ces méthodes pratiques et peu coûteuses m’ont redonné le contrôle de mon petit coin d’internet.
Points à Retenir
Si vous êtes confronté à des enregistrements de bots peu effort ou à des nuisances automatisées similaires, voici ce que vous devriez faire dès maintenant :
- Implémentez un Honeypot : C’est incroyablement simple, efficace et invisible pour les utilisateurs. Faites-le.
- Ajoutez une Vérification Basée sur le Temps : Mesurez le temps entre le chargement du formulaire et la soumission. Bloquez les soumissions qui sont anormalement rapides.
- Allez au-delà du Blocage Simple d’IP : Recherchez des motifs dans les chaînes User-Agent, les référants, et d’autres en-têtes de requête pour identifier les bots sophistiqués qui tournent les IP. Considérez un WAF si votre trafic le justifie.
- Validez les Domaines d’E-Mail : Vérifiez les fournisseurs d’e-mail jetables connus et considérez l’âge du domaine pour les nouveaux enregistrements.
- Surveillez et Adaptez : Les bots évoluent toujours. Gardez un œil sur vos journaux, analysez l’activité suspecte et soyez prêt à ajuster vos défenses.
- Ne Dérangez Pas les Vrais Utilisateurs : Priorisez l’expérience utilisateur. Évitez les CAPTCHA trop stricts ou des règles trop rigoureuses qui pourraient bloquer des enregistrements légitimes. La meilleure défense contre les bots est celle que les humains ne remarquent même pas.
Restez prudents et gardez ces bots à distance !
Articles Connexes
- Exercices de l’équipe rouge sur les bots IA
- Architecture de zéro confiance pour les bots IA
- Protection contre l’injection de prompt : Erreurs courantes et solutions pratiques
🕒 Published: