Le trafic de bots et d'abus se présente souvent non pas comme une rafale, mais comme un comportement lent et continu. Une IP peut effectuer 30 à 50 requêtes par minute ; en soi ce n'est pas catastrophique, mais lorsque cela se poursuit pendant 10 minutes, cela peut se transformer en comportement de scraping, d'automatisation ou de tentative de mot de passe. Le rate limiting instantané ne capture pas toujours correctement le caractère étalé dans le temps de ce comportement.
Les signatures WAAP résolvent une autre question : cette requête correspond-elle à un pattern d'attaque connu ? Les patterns de contenu malveillant tels que SQL injection, XSS ou command injection peuvent être détectés. Mais le scraping, le suivi de prix, les tentatives de compte ou l'usage agressif d'API — qui paraissent légitimes tout en générant un trafic intense — peuvent échapper à la protection basée sur les signatures.
Entre ces deux approches, il faut un modèle d'isolation temporaire. Si une source donnée a montré un comportement dépassant le seuil au cours des N dernières minutes, elle doit être mise en quarantaine pendant M minutes sans être bannie définitivement. Pendant cette durée, son trafic peut être bloqué, dirigé vers une page d'explication ou redirigé vers un autre flux. Une fois la durée écoulée, la source est automatiquement relâchée.
Ce modèle requiert deux mécanismes distincts : une fenêtre d'observation qui mesure le comportement et une fenêtre de quarantaine qui applique l'isolation. L'observation peut être courte et la quarantaine plus longue ; ou l'inverse selon la sensibilité de l'application. L'action ne doit pas non plus être uniforme : pour certaines sources, un blocage silencieux ; pour d'autres, une page d'explication ; pour d'autres encore, une redirection peut être plus appropriée.
La mise en quarantaine du trafic TR7 fournit ce modèle : deux fenêtres temporelles distinctes pour l'observation et la quarantaine, quatre types de clé, trois types d'action, la possibilité d'utiliser l'état de quarantaine comme condition dans d'autres règles, ainsi qu'une visibilité en direct et une intervention manuelle depuis l'écran du vService.
La mise en quarantaine du trafic TR7 réunit l'observation du comportement et l'isolation temporaire dans le même moteur de politique.
Dans chaque règle de quarantaine, la fenêtre d'observation et la fenêtre de quarantaine sont définies séparément. La fenêtre d'observation mesure le comportement de la source ; la fenêtre de quarantaine détermine la durée de l'action une fois le seuil dépassé.
La source ne doit pas obligatoirement être identifiée par sa seule IP. Avec les options IP, IP+user agent, Host+IP et Host+IP+user agent, une distinction plus précise est possible dans les scénarios multi-domaines, NAT et multi-locataires.
Pendant la quarantaine, le trafic peut être bloqué, redirigé vers une autre URL ou recevoir une page de contenu personnalisée. Ainsi, un blocage silencieux peut être appliqué au trafic de l'attaquant, un message explicatif à un utilisateur réel, ou une redirection adaptée au flux métier.
Une source mise en quarantaine se transforme en un signal d'état utilisable à l'échelle du système. D'autres règles de trafic, de redirection et de contenu peuvent utiliser ce signal comme condition pour construire une politique composite.
La mise en quarantaine du trafic réunit l'observation du comportement, l'isolation temporaire et le contrôle opérateur dans un seul modèle de fonctionnement.
Dans chaque règle, la durée d'observation et la durée de quarantaine se règlent indépendamment. Pendant la fenêtre d'observation, le comportement de la source est compté ; lorsque le seuil est dépassé, la source est maintenue dans une liste distincte pendant toute la fenêtre de quarantaine. À l'expiration de la durée, l'enregistrement disparaît automatiquement. Cette structure assure une isolation contrôlée et limitée dans le temps plutôt qu'un bannissement permanent.
L'option `ip` fournit une observation classique basée sur l'IP source. `ipUa` distingue les différents user agents derrière une même IP. `hostIp` compte séparément, dans les environnements multi-domaines, le comportement d'une même IP vers différents hosts. `hostIpUa` offre la distinction la plus granulaire dans les environnements multi-locataires et multi-clients.
L'opérateur peut définir un seuil sur le nombre de requêtes dans une fenêtre temporelle donnée. Des règles telles que « plus de 100 requêtes au cours des 10 dernières minutes » déclenchent une quarantaine basée sur le comportement. La décision repose non pas sur une seule requête, mais sur le comportement cumulé dans la fenêtre. Contrairement au rate limiting, cette approche repose sur l'observation.
L'action `block` sert à rejeter silencieusement le trafic de la source en quarantaine. Pour le trafic de bots et d'automatisation, ce comportement est souvent plus efficace ; l'attaquant n'obtient aucune réponse applicative nette. Cette action convient aux scénarios d'abus à haut risque où aucune explication n'a besoin d'être affichée. L'impact sur les utilisateurs réels peut être suivi depuis l'écran de monitoring du vService.
`showContent` renvoie à la source en quarantaine un code de statut HTTP et un contenu spécifiques. Par exemple, une page expliquant qu'elle est temporairement limitée en raison d'un trop grand nombre de requêtes peut être affichée. Ce modèle se comporte plus en douceur que le blocage dans les scénarios où un faux positif est possible ou où l'expérience utilisateur est importante. Le contenu du message peut être rédigé selon le langage de support et de marque de l'organisation.
`redirect` sert à rediriger la source en quarantaine vers une autre URL. La cible peut être une page CAPTCHA, un portail d'explication, une page de montée en gamme d'abonnement ou une page de support. Ainsi, la quarantaine devient non pas un simple outil de blocage, mais un moyen d'amener l'utilisateur vers le bon flux métier. Dans les scénarios multi-locataires et SaaS, cette option est particulièrement précieuse.
Le fait qu'une source soit en quarantaine peut être utilisé comme condition dans d'autres règles. Les sources en quarantaine peuvent être redirigées vers un autre backend, recevoir un header spécifique, voir une réponse de contenu particulière ou entrer dans le périmètre d'une seconde règle plus stricte. Cette fonctionnalité transforme une simple règle de quarantaine en un signal qui déclenche un changement de comportement à l'échelle du système. C'est l'un des points différenciateurs les plus importants de TR7.
La mise en quarantaine du trafic peut être utilisée à la fois pour les services HTTP et TCP. Côté HTTP, le comportement est observé au niveau des requêtes ; côté TCP, la décision se prend au niveau de la connexion. Le résultat technique de l'action peut varier selon le protocole ; mais le modèle de base est identique : observer, mettre en isolation temporaire ce qui dépasse le seuil, puis relâcher une fois la durée écoulée.
Dans l'écran de monitoring en direct du vService, les sources actuellement en quarantaine sont listées. L'opérateur peut voir quelle clé est en quarantaine, en raison de quelle règle, et pour combien de temps. En cas de faux positif ou d'utilisateur prioritaire, un retrait manuel est possible. Comme les enregistrements expirés sont nettoyés automatiquement, l'intervention manuelle n'est pas obligatoire.
Sous un même vService, plusieurs règles de quarantaine peuvent fonctionner ensemble. Par exemple, tandis que la première règle affiche une page d'avertissement en cas de trop grand nombre de requêtes, la seconde peut bloquer plus longtemps une source qui persiste. Jusqu'à 5 règles de quarantaine parallèles sont prises en charge par vService. Cette structure crée un contrôle des abus progressant du plus souple au plus ferme.
La mise en quarantaine du trafic se gère opérationnellement avec le cycle de vie des tables, le comportement en cluster, l'effet d'un rechargement, l'écran de monitoring et les enregistrements d'audit.
Chaque règle de quarantaine utilise deux zones de monitoring en direct distinctes, pour l'observation et la quarantaine. Les enregistrements sont conservés sur une durée définie et nettoyés automatiquement à l'expiration du TTL. À chaque nouvelle requête, le comportement de la fenêtre d'observation est mis à jour. Cette structure maintient la quarantaine comme un contrôle comportemental limité dans le temps, et non comme un bannissement permanent.
À chaque requête, la formule de clé est d'abord calculée, puis la valeur d'observation est mise à jour et la condition de quarantaine évaluée. Si la source est déjà en quarantaine, l'action définie est appliquée. Si la source n'est pas en quarantaine, le flux de trafic normal se poursuit. La décision se prend dans le chemin de données à faible coût.
Dans les déploiements à deux nœuds, les tables de quarantaine peuvent être conçues pour fonctionner localement ou de manière synchronisée. Si la synchronisation n'est pas activée, le nouveau nœud actif reconstruit l'historique de quarantaine depuis le début après un failover. Si la synchronisation est activée, l'état de quarantaine peut être préservé après un failover. Ce choix doit être évalué selon le besoin opérationnel et le modèle de déploiement.
Les tables de quarantaine sont conservées en mémoire et ne se comportent pas comme une blacklist permanente. Après un rechargement à chaud ou une réinitialisation de table, l'état de quarantaine actif peut être effacé. C'est un comportement acceptable, car la quarantaine est un mécanisme d'isolation temporaire. Si un bannissement de longue durée est nécessaire, elle doit être utilisée conjointement avec des flux de réputation IP.
Dans l'écran de monitoring du vService, les enregistrements de quarantaine actifs sont visibles et l'opérateur peut retirer une source donnée de la quarantaine. Cette opération supprime l'enregistrement de la table ; la requête suivante est évaluée dans le flux normal. Elle permet une intervention rapide en cas d'utilisateur VIP, de faux positif ou de demande de support.
Les événements de mise en quarantaine et de sortie de quarantaine peuvent être écrits dans les enregistrements d'audit. Si le SIEM log streaming est activé, les événements peuvent être envoyés à un collecteur externe. On peut analyser ultérieurement quelle clé a été mise en quarantaine, en raison de quelle règle, avec quelle action et pour quelle durée.
Le nombre de clés actives et le type de clé influencent la consommation mémoire. Les clés basées sur l'IP sont plus simples, tandis que les clés combinées comme Host+IP+user agent consomment plus d'espace. Comme 5 règles de quarantaine parallèles sont prises en charge par vService, le plan de capacité doit être établi selon le profil de trafic.
Un site e-commerce peut observer les sources qui scrapent les prix avec la clé `ipUa`. Une combinaison IP+user agent dépassant 100 requêtes en 5 minutes est bloquée pendant 30 minutes ; différents utilisateurs réels derrière la même IP peuvent être évalués comme des clés distinctes.
Un portail bancaire peut observer les tentatives répétées sur l'endpoint de connexion par IP ou par IP+user agent. Lorsque le seuil est dépassé, la source est dirigée pendant 60 minutes vers une page explicative et l'utilisateur réel se voit présenter le motif de la limitation temporaire.
Une plateforme SaaS hébergeant plusieurs domaines peut observer séparément le trafic de chaque locataire avec la clé `hostIp`. L'usage agressif d'un locataire peut faire l'objet d'une action de redirection ou de blocage temporaire sans affecter le trafic des autres locataires.
La première règle redirige pendant 10 minutes vers une page d'avertissement la source qui envoie trop de requêtes. Si la source continue à générer du trafic pendant sa quarantaine, la seconde règle entre en jeu et applique un blocage de 60 minutes. Le fait que l'état de quarantaine soit une condition dans d'autres règles rend ce modèle graduel possible.
Isolation temporaire basée sur le comportement, structure de règles composites et visibilité opérateur en direct. Examinons ensemble son fonctionnement dans votre propre environnement.