La saturation
Inondations de requêtes : le lien est rempli avant même que vos serveurs soient sollicités.
Tout service exposé sur Internet doit être considéré comme une cible potentielle, y compris ce que personne ne consulte. Pour une banque en ligne ou un opérateur de paiement, deux risques distincts se posent : être rendu injoignable, et voir ses applications exploitées.
Le problème
La première cherche à vous rendre inaccessible : saturer votre liaison ou épuiser vos serveurs. Vos systèmes fonctionnent parfaitement, mais plus personne ne peut y accéder. L’effet commercial est celui d’une panne totale.
La seconde cherche à entrer : exploiter une faille de votre application, une bibliothèque tierce que vous n’avez pas écrite, ou une interface programmatique conçue pour votre application mobile et jamais protégée comme le site web.
Inondations de requêtes : le lien est rempli avant même que vos serveurs soient sollicités.
Bibliothèques et greffons tiers composent l’essentiel d’une application moderne - et sa surface d’attaque.
Faire tomber le DNS suffit à vous rendre injoignable, sans toucher à un seul de vos serveurs.
Diagnostic
Trois sujets se cachent derrière « protéger notre site » : la disponibilité, l’application elle-même, et la couche de résolution que personne ne surveille.
Si la seule réponse envisagée est « appeler l’opérateur », la protection anti-DDoS manque : elle filtre le trafic d’attaque en amont, afin de limiter son impact sur votre infrastructure et vos liaisons.
S’il est en surveillance, il n’arrête rien. Le sujet n’est pas d’en acheter un autre, mais de réduire les faux positifs jusqu’à pouvoir activer le blocage.
Rarement. Les interfaces destinées aux applications mobiles et aux partenaires échappent souvent aux protections prévues pour le navigateur.
Si la réponse est floue, c’est un angle mort complet. La protection du DNS traite à la fois la saturation et le détournement de vos noms.
Cette question tranche entre le mode hébergé et le boîtier local, avant toute discussion technique. Nous l’instruisons en premier.
Les solutions
Elles se complètent : garder le service joignable face aux attaques, le maintenir disponible sous la charge, filtrer ce qui arrive, et protéger la couche dont tout dépend.
Le trafic d’attaque est écarté dans les centres de nettoyage : votre liaison ne voit passer que le trafic légitime.
Voir la solution →Un pare-feu applicatif dont l’argument central est le taux de faux positifs - donc la possibilité de l’utiliser vraiment en blocage.
Voir la solution →Défense du DNS contre la saturation, le détournement et l’empoisonnement du cache, en externe comme en interne.
Voir la solution →Répartition de charge, haute disponibilité et pare-feu applicatif pour publier vos applications.
Voir la solution →Par où commencer
L’ordre suit la gravité immédiate : être injoignable se voit tout de suite et se chiffre en transactions perdues, une faille applicative peut rester silencieuse des mois.
Palier 1
Protection anti-DDoS et défense du DNS. Peu coûteux, rapide à mettre en place, et cela couvre le risque le plus visible.
Palier 2
Cadrer une phase d’observation avec des critères de sortie, qualifier vos parcours métier, puis activer filtre par filtre.
Palier 3
Les API destinées aux applications mobiles et aux partenaires, souvent oubliées du périmètre initial.
Le palier 1 se prépare à froid : une bascule anti-DDoS suppose un accord préalable avec votre opérateur. La négocier pendant l’attaque est la garantie de perdre plusieurs heures.
Un partenaire, pas seulement un revendeur
Le passage en mode blocage est le seul moment qui compte dans un projet de protection applicative. Tout ce qui précède sert à le préparer.
Nous fixons dès le départ la durée et les critères de sortie de l’apprentissage, pour qu’il ne devienne pas permanent.
Un parcours de virement ou de souscription a des motifs particuliers. Nous les qualifions avant qu’ils ne soient pris pour des attaques.
La bascule anti-DDoS suppose un accord avec votre fournisseur d’accès. Nous menons cette négociation avec vous, en amont.
Nous déclenchons une bascule hors attaque pour vérifier que la procédure fonctionne réellement.
Nous recensons vos services exposés, évaluons votre exposition actuelle et cadrons la bascule avec votre opérateur. Réponse sous 24 heures ouvrées.