Protection DDoS hybride — Vitesse sur site, échelle du cloud

La protection DDoS hybride associe deux couches de mitigation qui, prises isolément, échouent chacune dans le sens opposé : un déploiement WanGuard sur site qui détecte et filtre les attaques localement en quelques secondes, et un scrubbing cloud en amont qui absorbe les floods plus volumineux que ce que vos liens montants peuvent physiquement transporter. ITORO conçoit la répartition des tâches entre les deux, afin que les attaques quotidiennes soient traitées à votre bordure et que seuls les véritables événements à l’échelle du térabit soient escaladés en amont.

Pourquoi une seule couche ne suffit jamais

Un appliance purement sur site est rapide et peu coûteux à exploiter, mais il ne peut nettoyer que le trafic qui l’atteint — dès qu’une attaque dépasse la capacité de votre lien montant, la congestion se produit à la bordure de votre opérateur, en amont de tout équipement que vous possédez. Un service purement cloud résout le problème de capacité, mais ajoute une redirection permanente, une facturation à l’événement ou au gigabit nettoyé, et une latence de détection mesurée en dizaines de secondes le temps que le trafic soit rerouté. L’hybride garde le trafic normal local et sur votre réseau, et ne fait appel à la capacité cloud que lorsque la physique de l’attaque l’exige.

La répartition des tâches

Sur site : WanGuard assure la détection et le filtrage chirurgical

WanGuard ingère le NetFlow/sFlow/IPFIX de vos routeurs de bordure Juniper MX ou autres, et construit une base de référence en temps réel de ce qui constitue la normalité par préfixe, par hôte, par protocole. Lorsqu’une anomalie franchit le seuil, il élimine le trafic incriminé grâce aux filtres granulaires WanFilter ou pousse une règle BGP FlowSpec vers le routeur lui-même — en filtrant sur la source, la destination, les ports, le protocole, la longueur de paquet ou les drapeaux TCP. C’est chirurgical : une seule signature d’amplification NTP ou un unique /32 attaqué peut être filtré tandis que le reste du sous-réseau continue de servir. Le temps de réaction se compte en secondes, et cela ne coûte rien au gigabit puisque tout tourne sur votre propre matériel.

En amont : scrubbing cloud et opérateur pour le plafond volumétrique

Certains floods sont tout simplement plus gros que vos tuyaux. Pour ceux-là, WanGuard signale automatiquement la couche suivante. Le RTBH (Remotely Triggered Black Hole) est l’outil brut et universellement pris en charge — il null-route la destination attaquée à la bordure de votre amont, sacrifiant une cible pour protéger tout le reste. Là où votre opérateur de transit ou un centre de scrubbing le prend en charge, le BGP FlowSpec peut être propagé en amont à la place, n’éliminant que les flux malveillants et gardant la cible en ligne. La couche cloud est dimensionnée pour le trafic que vos propres liens montants ne pourraient jamais absorber.

Quand chaque couche entre en jeu

• Fonctionnement normal : tout reste local. Aucune redirection, aucune latence ajoutée, aucun trafic sortant facturé au compteur.
• Attaque typique (qui tient dans vos liens montants) : WanGuard filtre à la bordure avec WanFilter ou FlowSpec en quelques secondes. Le cloud n’est jamais sollicité.
• Liens montants approchant la saturation : WanGuard escalade automatiquement — FlowSpec ou RTBH signalé en amont, ou déviation vers un centre de scrubbing — avant que la congestion ne dégrade le trafic légitime.

Prévisibilité des coûts face au tout-cloud

Le scrubbing cloud permanent vous facture chaque mois la capacité et le trafic propre, que vous soyez attaqué ou non, et les gros événements peuvent générer des dépassements imprévisibles. Un modèle hybride inverse cette logique : votre coût fixe est la plateforme WanGuard sur site, qui traite l’écrasante majorité des incidents à coût marginal nul, et vous ne puisez dans la capacité amont — et ne la payez — que pendant les rares événements qui l’exigent réellement. Pour les FAI, les opérateurs télécoms et les centres de données au trafic stable ponctué de pics occasionnels, c’est généralement à la fois moins cher et plus prévisible. Voir la tarification transparente.

Un scénario réaliste : carpet-bomb contre flood ciblé

Les deux couches justifient leur présence dans des attaques différentes. Un flood ciblé — disons 8 Gbit/s de réflexion DNS visant une seule IP client — est du pain bénit pour la couche sur site : WanGuard l’identifie, l’élimine avec une règle FlowSpec sur le MX, et personne d’autre ne s’en aperçoit. Un carpet-bomb est plus difficile : le même volume total est éparpillé sur des centaines de destinations dans un /22, chaque flux individuel trop faible pour déclencher un seuil par hôte, mais l’agrégat saturant votre bordure. Ici, la détection au niveau du sous-réseau et de l’agrégat de WanGuard compte, et si le total dépasse malgré tout vos liens montants, la réponse honnête est le scrubbing en amont — un RTBH par /32 mettrait la moitié de vos clients dans un trou noir. Nous concevons les seuils et l’escalade pour les deux cas, plutôt que de supposer que toutes les attaques se ressemblent.

Foire aux questions

Protection DDoS sur site ou cloud — laquelle est la meilleure ?

Ni l’une ni l’autre, seule. Le sur site l’emporte sur la vitesse et le coût pour les attaques que vous rencontrez le plus souvent ; le cloud l’emporte sur la capacité brute pour les rares floods les plus volumineux. L’hybride utilise chacune là où elle est la plus forte.

La protection hybride ajoute-t-elle de la latence ?

Non. Le trafic normal reste local et non redirigé. La capacité amont n’est engagée que pendant les événements volumétriques exceptionnels, pas en régime permanent.

Pouvez-vous garantir qu’aucune attaque ne passera jamais ?

Non, et nous ne le prétendrons pas. Nous concevons une mitigation en couches pour maintenir les services disponibles sur l’ensemble de la plage de menaces réaliste, et nous sommes explicites sur le point où une attaque doit être absorbée en amont plutôt qu’à votre bordure.

Devons-nous remplacer nos Juniper MX ou nos routeurs existants ?

Généralement non. WanGuard fonctionne aux côtés de votre bordure existante, consommant le NetFlow/sFlow/IPFIX pour la détection et utilisant le BGP FlowSpec et le RTBH pour programmer la mitigation sur les routeurs que vous exploitez déjà.