Bloquer le trafic de botnet avant qu’il n’atteigne votre base de données

La plupart des stacks applicatives sont conçues pour être accueillantes. Une requête arrive, le routeur la transmet à un contrôleur, le contrôleur ouvre une connexion à la base de données, exécute une requête, puis renvoie une réponse. Pour un utilisateur humain, ce chemin est parfaitement normal. Pour un botnet, c’est une autoroute.

Un botnet distribué n’a pas besoin d’exploiter une faille pour vous faire mal. Il lui suffit que votre application continue à dire oui : oui au formulaire de connexion, oui à l’endpoint de recherche, oui à l’e-mail de réinitialisation de mot de passe, oui à une nouvelle connexion puisée dans le pool. Quand le trafic atteint votre ORM, vous avez déjà payé le coût du TLS, de la recherche de session et d’un aller-retour en base — multiplié par des milliers de nœuds par minute.

La requête la moins chère est celle que vous ne traitez jamais. C’est tout l’intérêt du filtrage IP en périphérie.

À quoi ressemble vraiment un botnet au niveau IP

Le trafic d’un botnet arrive rarement depuis une seule adresse. Il vient de partout, avec un mélange qui tombe souvent dans quelques catégories reconnaissables :

• Machines résidentielles compromises. Routeurs domestiques, objets connectés et postes infectés. Peu de volume individuellement, énorme puissance collective.
• Capacité datacenter louée. Instances VPS bon marché lancées en masse. Un client humain navigue très rarement sur votre tunnel d’achat depuis une plage AWS, OVH ou Hetzner.
• Réseaux de proxy commerciaux. Pools de proxy résidentiels et mobiles revendus au gigaoctet, précisément présentés comme un moyen de contourner les blocages IP.
• Sorties VPN publiques et TOR. Légitimes pour les utilisateurs soucieux de leur confidentialité, mais surreprésentées dans les abus.

Aucune de ces catégories n’est malveillante par nature. Une IP de datacenter peut être une sonde de monitoring que vous avez vous-même configurée. Une sortie VPN peut correspondre à un client connecté au Wi-Fi d’un hôtel. C’est justement pour cela que la décision doit vous appartenir, plutôt que de dépendre d’une liste de blocage aveugle : il vous faut la classification, puis vous appliquez votre politique.

Bloquer avant la base de données, pas après

L’ordre des opérations compte davantage que la précision d’un signal isolé. Prenons deux versions du même endpoint de connexion.

| Stage | Without IP filtering | With IP filtering first | | --- | --- | --- | | Parse request | Yes | Yes | | IP classification | — | ~1 lookup, cached | | Session / user lookup | Yes | Only if allowed | | Password hash verify | Yes (expensive by design) | Only if allowed | | Rate-limit write | Yes | Only if allowed |

Le hachage des mots de passe est volontairement lent : c’est précisément son rôle. Une campagne de credential stuffing contre une page de connexion non protégée transforme votre propre mécanisme de sécurité en vecteur de déni de service. En plaçant la décision IP avant cette étape, un nœud attaquant reçoit un 403 pour le coût d’un accès en table de hachage, tandis que votre pool de connexions à la base reste disponible pour les vrais clients.

Le même raisonnement vaut pour les endpoints de recherche qui sollicitent des index full-text, les formulaires d’inscription qui déclenchent des e-mails transactionnels, ou toute route qui écrit une ligne d’audit à chaque tentative.

Une politique pragmatique, pas un mur

Tout bloquer dès que quelque chose paraît suspect, c’est le meilleur moyen de remplir le support de tickets mécontents. Une réponse graduée fonctionne beaucoup mieux, et elle devient simple à formaliser dès que vous disposez d’un score de risque et d’un type pour chaque adresse :

• Autoriser sans bruit. Adresses d’opérateurs résidentiels et professionnels avec un score de risque faible. C’est l’immense majorité du trafic réel.
• Ajouter de la friction. Sorties VPN ou TOR uniquement sur les actions sensibles : inscription, réinitialisation de mot de passe, modification des coordonnées de paiement. Affichez un challenge, exigez une confirmation par e-mail, désactivez l’octroi automatique d’un essai gratuit.
• Limiter fortement. Plages datacenter et hébergement qui frappent des endpoints destinés aux humains. Les intégrations légitimes doivent passer par votre API avec une clé, pas par votre formulaire de connexion.
• Rejeter en périphérie. Infrastructure de proxy connue pour ses abus sur l’authentification, ou toute source qui dépasse déjà votre budget par IP.

Notez que l’étape 4 est le plus petit compartiment, pas le réglage par défaut. L’objectif est de rendre l’abus coûteux, pas de rendre votre produit inaccessible.

Où placer le contrôle dans votre stack

Trois emplacements sont possibles, par ordre approximatif d’efficacité :

• CDN ou reverse proxy. Le point le plus en amont possible. La requête ne touche même pas un serveur applicatif. Idéal pour les règles globales sur des plages manifestement hostiles.
• Middleware dans votre application. Exécuté avant le routage et avant tout appel à la base. C’est là que vivent les politiques plus fines, par endpoint : strictes sur /login, plus souples sur /pricing.
• Dans la logique métier. Pour les décisions qui nécessitent le contexte du compte, par exemple signaler une connexion depuis une IP de datacenter sur un compte qui n’a jusque-là utilisé qu’un seul opérateur mobile.

La plupart des équipes ont d’abord besoin de la solution du milieu. Quelques lignes devant votre routeur suffisent à protéger tout ce qui se trouve derrière.

Mettre en cache agressivement, échouer en mode ouvert

Deux règles d’exploitation évitent qu’un contrôle de réputation IP ne devienne lui-même une source d’incident :

Mettre en cache par adresse. Les botnets réutilisent leurs nœuds. Un TTL court en mémoire — des minutes, pas des jours — transforme des milliers de requêtes en une seule recherche et maintient la latence ajoutée dans l’ordre de la microseconde pour les récidivistes. Guarda met les recherches en cache côté serveur précisément pour cette raison, avec une fenêtre configurable.

Échouer en mode ouvert, journaliser fortement. Si le service de réputation est indisponible, laissez passer la requête et enregistrez l’événement. Un contrôle anti-abus qui fait tomber votre checkout parce qu’un tiers passe une mauvaise journée vous coûtera plus cher que l’abus lui-même. Réservez le fail-closed aux actions réellement critiques, comme les retraits.

Ce qu’il faut mesurer ensuite

Activez d’abord le filtre en mode journalisation seule, puis comparez une semaine de trafic avec une semaine de blocage :

• Requêtes rejetées avant d’atteindre la base de données, en proportion du total.
• Saturation du pool de connexions à la base pendant les pics d’abus.
• Tentatives de connexion échouées par heure.
• Tickets support mentionnant « impossible de me connecter » — le canari des faux positifs.
• Ratio entre inscriptions et comptes vérifiés, qui s’améliore souvent nettement lorsque les inscriptions jetables depuis des datacenters disparaissent.

Si les deux derniers indicateurs partent dans la mauvaise direction, assouplissez le niveau concerné plutôt que de désactiver tout le dispositif.

Les limites, franchement

La réputation IP est une couche de défense, pas une muraille. Les pools de proxy résidentiels tournent sur de vraies adresses grand public qui peuvent être impossibles à distinguer de celles de vos clients. Le carrier-grade NAT signifie qu’une seule IP mobile peut représenter des milliers de personnes. Les attaquants qui ont du budget trouveront toujours une infrastructure plus propre que ceux qui n’en ont pas.

Ce que le filtrage IP fait de manière fiable, c’est éliminer la majorité bon marché et à fort volume : les floods scriptés lancés depuis des serveurs loués et des listes de proxy brûlées. Ainsi, vos défenses plus lentes et plus intelligentes — fingerprinting d’appareil, analyse comportementale, MFA, rate limits appliqués aux comptes — n’ont plus à raisonner que sur une population beaucoup plus réduite et plus intéressante.

C’est le vrai gain : non pas un périmètre impénétrable, mais une base de données qui continue à répondre aux requêtes pendant que vous êtes sous attaque.

Vous pouvez classifier n’importe quelle adresse avec les signaux proxy, VPN, TOR, hosting et score de risque de Guarda via le test gratuit disponible sur la page d’accueil, puis intégrer le même appel dans le middleware placé devant vos routes.