L'erreur la plus courante dans la protection DDoS traditionnelle est d'appliquer le même seuil fixe à chaque service. Une règle simple comme « bloquer au-delà de 100 requêtes par seconde » peut réagir trop lentement pour un service à faible trafic et produire des faux blocages pour un site e-commerce lors d'une campagne. Chaque application a son propre volume de trafic normal, sa distribution de chemins, son profil client et son comportement de connexion.
Les attaques L7 DDoS n'arrivent pas toujours avec des comptages de paquets élevés ou des taux de requêtes élevés. Les attaques de style Slowloris — faible taux mais nombreuses connexions ouvertes — ainsi que les floods de connexions SSL, les taux d'erreur en hausse, le comportement des bots et la charge concentrée sur des endpoints spécifiques peuvent tous déjouer la logique classique de rate-limit. Prendre des décisions depuis un seul compteur est donc insuffisant.
Un autre problème est que les actions de protection sont souvent uniformes. Si chaque requête suspecte est immédiatement abandonnée, les utilisateurs légitimes sont affectés ; si un captcha est affiché dans tous les cas, l'expérience utilisateur se dégrade. Le drop silencieux est correct dans certains scénarios, la redirection dans d'autres, une page informative dans d'autres encore, et un captcha auto-hébergé dans d'autres encore.
La bonne approche consiste à apprendre le comportement du trafic par service, évaluer ensemble les signaux L4 et L7 et choisir l'action sur la base des conditions. Les règles de liste blanche, le comportement de chemin, le nombre de connexions, le taux de requêtes, le score bot et la réputation IP doivent tous participer au même pipeline de décision.
TR7 Adaptive DDoS Learning offre ce modèle : il surveille le trafic du service, convertit le comportement appris en recommandations de politique et applique des actions de protection contrôlées avec l'approbation de l'opérateur.
TR7 applique les décisions DDoS via la collecte de compteurs, les conditions combinées, les baselines apprises et un modèle d'action gradué.
TR7 suit le comportement des connexions, requêtes, erreurs et SSL via des compteurs globaux et par clé de suivi. Ces chiffres forment les signaux centraux pour les conditions DDoS par service.
`ddosCond` permet de combiner plusieurs conditions ACL avec une logique AND, OR et NOT. Les décisions peuvent donc être basées non seulement sur le taux de requêtes mais aussi sur le nombre de connexions SSL, le taux d'erreur, le score bot, la réputation IP ou le comportement de chemin.
Le comportement du service, des chemins et des requêtes est analysé depuis les données de trafic et de logs historiques. Les valeurs apprises sont présentées à l'opérateur comme recommandations et deviennent une politique applicable une fois approuvées.
TR7 prend en charge les actions deny, redirect, showContent et showCaptcha. Selon la sensibilité du service, l'opérateur peut choisir le drop silencieux, la redirection, une page de réponse personnalisée ou un captcha auto-hébergé.
Adaptive DDoS Learning combine les signaux de trafic par service avec le comportement appris pour offrir une protection L4/L7 plus précise.
TR7 utilise un modèle d'indicateur pouvant marquer l'état DDoS au niveau global. Lorsqu'un service ou une condition de suivi déclenche un état d'attaque, cette information peut être utilisée comme signal dans d'autres décisions de protection. Le DDoS est donc traité comme faisant partie du comportement système global, pas seulement comme un événement de requête isolé. Les équipes opérationnelles obtiennent une vue plus claire du mode de protection global lors d'un incident.
Parallèlement au signal global, un indicateur DDoS par requête est également disponible. Si une requête a été interceptée par une condition DDoS peut être déterminé au niveau transaction. L'action est donc appliquée uniquement au flux pertinent — il n'est pas nécessaire de placer tout le trafic dans le même panier inutilement. Un comportement finement granulaire réduit le risque de faux positifs.
TR7 peut suivre différentes clés telles que le taux de requêtes HTTP, le taux d'erreur HTTP, le taux de connexion, le nombre de connexions actives et le nombre de connexions SSL. Le comportement L7 est prédominant pour les services HTTP ; les signaux basés sur les connexions sont prépondérants pour les services TCP. Cette distinction permet de sélectionner le bon indicateur DDoS pour chaque type de service, de sorte que les décisions sont basées sur l'ensemble de signaux approprié plutôt qu'un seul compteur.
Une fenêtre de suivi plus courte détecte plus rapidement les rafales d'attaque rapides ; une fenêtre plus longue rend visible le comportement lent et soutenu. TR7 rend cette durée configurable par besoin de service. Les fenêtres courtes par défaut conviennent pour un démarrage rapide, mais la politique de production doit être façonnée selon le profil du service. Cette flexibilité aide à distinguer les pics de trafic soudains de campagne du comportement DDoS lent.
`ddosWhitelistCond` peut exempter des IP spécifiques, des ASN, des chemins ou des sources de trafic de confiance des actions DDoS. C'est particulièrement important pour les bots de moteurs de recherche, les intégrations d'entreprise, les systèmes de surveillance ou le trafic API partenaire. La liste blanche ne doit pas être une liste statique ; elle peut être écrite avec une logique de condition pour un contrôle plus fin. Les flux critiques pour l'activité restent accessibles même lorsque la protection devient plus agressive.
TR7 prend en charge les actions deny, redirect, showContent et showCaptcha. deny est l'approche de drop silencieux la plus agressive ; redirect déplace le trafic vers un autre emplacement ; showContent retourne une page personnalisée avec un code de statut spécifique ; showCaptcha initie la vérification utilisateur. Cette variété signifie que toutes les attaques ne sont pas traitées avec le même niveau de force. L'opérateur sélectionne la bonne réponse en fonction de la valeur du service et du risque de faux positifs.
TR7 peut servir des pages de vérification multilingues dans les scénarios de challenge DDoS. Ces pages présentent le flux de contrôle aux utilisateurs sans dépendre d'un service tiers externe. L'approche de challenge auto-hébergé est un avantage dans les secteurs sensibles au partage des données et à la conformité. Au lieu d'afficher simplement une erreur, les utilisateurs reçoivent une expérience de vérification contrôlée.
TR7 peut dériver un profil normal par service depuis les données de logs et de trafic historiques. Le trafic attendu par chemin, le taux d'erreur typique ou le comportement de charge peuvent être présentés à l'opérateur comme recommandations. L'opérateur les révise et les approuve pour les convertir en conditions DDoS. Cette approche facilite la construction de politiques depuis le vrai trafic observé plutôt que d'écrire des seuils à l'aveugle.
Les scores de protection bot peuvent être utilisés comme signaux auxiliaires dans les décisions DDoS. Des facteurs tels que l'IP de datacenter, la sortie Tor, la mauvaise réputation IP, l'analyse du user agent, l'empreinte d'en-tête et l'empreinte TLS peuvent tous affecter le score de risque. Lorsque le score bot dépasse un seuil configuré, une action deny, redirect ou captcha peut être déclenchée. La protection DDoS ne regarde donc pas seulement le volume mais aussi la qualité du client.
TR7 peut utiliser 13 catégories de réputation IP comme signaux de décision : proxy ouvert, mauvais bot, brute force, attaque d'application web, SQL injection, hacking, attaque DDoS, hôte compromis, scan de ports, spam web, spam email, spam de blog et IP VPN. Ces catégories ne doivent pas être déterminantes seules — elles contribuent un poids de risque supplémentaire dans une condition combinée. Les sources connues malveillantes sont donc séparées du trafic utilisateur normal plus rapidement, rendant la politique de protection plus consciente du contexte.
TR7 peut dériver des recommandations par service depuis des signaux tels que le taux de connexion, les connexions actives, le taux de requêtes, le taux d'erreur et le comportement de chemin. Ces recommandations sont révisées par l'opérateur plutôt qu'appliquées à l'aveugle. Les valeurs approuvées sont converties en conditions DDoS et politiques d'action. Ce modèle maintient l'automatisation sous contrôle — l'apprentissage, l'approbation humaine et la politique applicable fonctionnent ensemble.
L'équipe opérationnelle peut également activer manuellement l'état DDoS lors d'une attaque. C'est utile pour prendre rapidement des mesures de protection sans attendre que l'apprentissage automatique ou les déclencheurs de condition s'activent. Le mode manuel fournit une couche de défense temporaire particulièrement lors du processus de réponse aux incidents. Les conditions identifiées après l'incident peuvent être formalisées en politique permanente.
La protection DDoS adaptive est opérée conjointement avec les seuils, la composition des conditions, la sélection des actions, les règles de liste blanche, le score bot et le comportement des challenges.
Lorsque le score de protection bot atteint un seuil configuré, des actions telles que deny, redirect ou captcha peuvent être déclenchées. Ce seuil doit être appliqué avec soin selon la sensibilité du service. L'évaluer avec le comportement des requêtes et les conditions de liste blanche — plutôt que de se fier uniquement au score bot — produit des résultats plus fiables.
Le modèle de suivi DDoS global peut maintenir un compteur pour l'état du système unique. Cette structure aide à comprendre l'état d'attaque à l'échelle du système aux côtés des conditions par service. Lors d'un incident, les équipes opérationnelles surveillent non seulement une seule requête mais aussi le signal de comportement agrégé.
Lorsque l'indicateur DDoS est actif, l'action de protection sélectionnée est appliquée. deny fournit le drop silencieux ; redirect effectue la redirection ; showContent sert du contenu personnalisé ; showCaptcha initie le flux de challenge. La sélection d'action doit être faite selon la valeur du service, l'expérience utilisateur et la gravité de l'attaque.
Dans l'action showContent, le code de statut, le content-type et le profil de contenu sont tous personnalisables. Cela permet d'afficher le propre message de l'organisation aux utilisateurs plutôt qu'une erreur générique. La fonctionnalité est précieuse pour les fenêtres de maintenance, la communication lors d'incidents et la messagerie de conformité.
L'action showCaptcha peut invoquer le propre module CAPTCHA de TR7, réduisant la dépendance à un service de vérification tiers externe. Cette approche offre un flux de vérification plus contrôlé pour les organisations sensibles à la protection des données et aux exigences réglementaires.
Plusieurs signaux peuvent être combinés dans `ddosCond` en utilisant une logique AND, OR et NOT. Par exemple, un taux de requêtes élevé peut être évalué avec une concentration de chemin spécifique et une catégorie de réputation IP plutôt qu'isolément. Cela réduit les faux positifs tout en permettant une action plus ciblée.
Les équipes e-commerce peuvent utiliser des conditions DDoS par service pour séparer un pic de trafic lors d'une campagne d'une vraie attaque. Les crawlers de confiance ou les sources partenaires sont mis en liste blanche tandis que le comportement anormal de chemin et de requêtes est mappé vers des actions de protection.
Les applications bancaires peuvent surveiller conjointement le taux de requêtes HTTP, le nombre de connexions SSL et le taux d'erreur sur le trafic de connexion. Lorsque les seuils sont dépassés, des actions redirect, captcha ou deny sont appliquées selon la politique de service.
Les portails publics peuvent utiliser leurs propres pages de challenge TR7 sans envoyer des données vers un service de vérification externe. Le contenu multilingue maintient le flux de vérification utilisateur sous contrôle institutionnel.
Les attaques générant un nombre élevé de connexions ouvertes malgré un faible taux de requêtes peuvent être surveillées via le comportement de nombre de connexions et de durée. TR7 rend visibles les patterns d'attaque lente épuisant les connexions — pas seulement les floods à PPS élevé.
Parcourez l'apprentissage de baseline, les conditions combinées et le modèle d'action gradué sur vos propres services.