Un jour, sans prévenir, votre site devient injoignable. Pas une panne : un déluge. Des centaines de milliers de requêtes ou des dizaines de gigabits par seconde s’abattent sur votre infrastructure jusqu’à la noyer. C’est une attaque par déni de service distribué — un DDoS — et contrairement à une idée reçue, ça ne vise plus seulement les banques et les géants du web.
Les outils d’attaque se louent à l’heure, pour quelques euros. Un concurrent peu scrupuleux, un maître-chanteur, un militant : n’importe qui peut déclencher une attaque contre n’importe quelle PME. La vraie question n’est donc pas « est-ce que ça m’arrivera », mais « mon hébergeur tient-il debout quand ça arrive ». Voici comment on s’y prend chez Datacampus, couche par couche.
Faits clés
- 3 familles d’attaques : volumétrique (saturer la bande passante), protocolaire (épuiser les équipements), applicative (noyer le serveur web).
- AS50446 : notre propre numéro de système autonome, condition d’une vraie maîtrise du routage.
- Transits multiples + peering (Cogent, Arelion, Orange, Cloudflare ; France-IX et NineIX) : pas de point de défaillance unique à l’entrée du réseau.
- RPKI : signature cryptographique des routes pour empêcher le détournement de trafic (BGP hijacking).
- Cloudflare Magic Transit : filtrage des attaques volumétriques en bordure du réseau mondial, en continu.
Une attaque DDoS, c’est quoi au juste ?
« Distribué » (le premier D de DDoS) signifie que l’attaque vient de milliers de machines à la fois : des objets connectés piratés, des serveurs compromis, des botnets loués. Impossible de simplement « bloquer une adresse IP ». On distingue trois familles, qui ne se combattent pas au même endroit :
Saturer le tuyau par un volume brut de trafic (UDP flood, amplification DNS/NTP). Se mesure en gigabits ou térabits par seconde. Se combat en amont, sur un réseau capable d’absorber le volume.
Épuiser les ressources des équipements (pare-feu, load balancer) en abusant des protocoles (SYN flood, qui laisse des connexions à moitié ouvertes). Le volume peut être modéré, l’effet dévastateur.
Noyer le serveur applicatif sous des requêtes en apparence légitimes (HTTP flood, recherches coûteuses répétées). Discret, redoutable, et qui se traite au niveau de l’application.
Cette distinction est cruciale, parce qu’aucune solution unique ne couvre tout. Méfiez-vous de quiconque vous vend une « protection DDoS » magique : la bonne défense est en couches.
Première ligne : un réseau qu’on maîtrise vraiment
Beaucoup d’hébergeurs louent leur connectivité à un tiers et n’ont aucune main sur le routage. Nous avons fait l’inverse : Datacampus exploite son propre système autonome, l’AS50446. Un « AS » (Autonomous System), c’est l’unité de base du routage sur Internet : avoir le sien, c’est annoncer soi-même ses adresses IP au reste du monde via le protocole BGP, et donc décider par où entre et sort le trafic.
Au-dessus, on ne dépend pas d’un seul fournisseur : quatre opérateurs de transit (Cogent, Arelion, Orange, Cloudflare) et du peering sur les points d’échange France-IX et NineIX. Si un lien tombe ou se sature, le trafic emprunte les autres. Pas de point de défaillance unique à la porte d’entrée. C’est le b.a.-ba, mais c’est la fondation : on en parle en détail dans notre article BGP, AS, peering : comprendre le réseau d’un hébergeur.
RPKI : empêcher qu’on détourne votre trafic
Le routage Internet repose historiquement sur la confiance : n’importe quel réseau peut, par erreur ou par malveillance, annoncer « c’est moi qui héberge ces adresses IP » et détourner le trafic vers lui. C’est le BGP hijacking, et il a déjà coupé ou intercepté le trafic de services majeurs.
La parade s’appelle RPKI (Resource Public Key Infrastructure). Le principe : le titulaire légitime d’un bloc d’adresses publie une autorisation signée cryptographiquement (une ROA, Route Origin Authorization) qui déclare quel AS a le droit d’annoncer ce bloc. Les réseaux qui font de la validation (ROV) rejettent alors les annonces non conformes.
Chez Datacampus, RPKI est activé : nos routes sont signées, et les annonces invalides sont écartées. C’est une brique de l’initiative MANRS (Mutually Agreed Norms for Routing Security), le standard de bonne conduite du routage. Concrètement : on réduit fortement le risque que votre trafic parte ailleurs que chez nous.
Magic Transit : encaisser le déluge volumétrique
Contre les attaques volumétriques, la seule défense qui tient est d’avoir plus de capacité que l’attaquant, et de filtrer le plus loin possible de votre serveur. C’est exactement ce que fait Cloudflare Magic Transit, que nous avons déployé.
Le mécanisme, en trois temps :
Le trafic entrant est attiré vers le centre Cloudflare le plus proche de sa source, grâce à l’annonce BGP en anycast. L’attaque est donc diluée sur un réseau mondial avant même d’approcher nos installations.
Le trafic est inspecté et le malveillant (UDP flood, SYN flood, amplification…) est bloqué automatiquement, en quelques secondes, au plus près de la source. La protection L3/L4 est toujours active, sans bascule à déclencher.
Seul le trafic légitime nous est rendu via des tunnels dédiés. Vos visiteurs ne voient rien : le service continue pendant que l’attaque est filtrée en bordure.
L’avantage d’un dispositif always-on : pas de fenêtre de bascule pendant laquelle l’attaque passe. Le filtrage est permanent, transparent en temps normal.
Et la couche applicative (L7) ? Soyons honnêtes
Magic Transit excelle sur les couches réseau (L3/L4). Mais une attaque applicative (L7) — des requêtes HTTP qui ressemblent à du trafic normal — se traite ailleurs : au niveau de l’application elle-même et d’un éventuel reverse proxy / WAF. Aucune protection réseau ne dispense de bonnes pratiques côté applicatif.
C’est un travail partagé : nous fournissons un réseau qui encaisse le volume, et nous vous accompagnons sur la limitation de débit, la mise en cache, le durcissement de votre application. Le sujet rejoint nos bases de la protection d’un site web, qui restent valables quelle que soit la taille de l’attaque.
Une protection DDoS sérieuse, ce n’est pas un bouton magique : c’est un réseau redondant, des routes signées, un filtrage volumétrique en bordure, et une application durcie. Chaque couche compte.
Comment Datacampus protège ses clients, en résumé
AS50446, quatre transits, peering France-IX et NineIX. Pas de fournisseur unique à l’entrée : si un lien sature, le trafic passe ailleurs.
RPKI activé, dans l’esprit MANRS : nos préfixes sont signés, les annonces invalides écartées. Moins de risque de détournement.
Cloudflare Magic Transit en bordure de réseau mondial, filtrage L3/L4 permanent, sans interruption de service pendant l’attaque.
Pas de call center : en cas d’incident, vous parlez directement à ceux qui opèrent le réseau. C’est décisif quand chaque minute compte.
TL;DR, ce qu’il faut retenir
- Le DDoS vise tout le monde, pas que les géants : les attaques se louent pour quelques euros.
- Trois familles d’attaques (volumétrique, protocolaire, applicative), qui se combattent à des endroits différents.
- AS50446 + transits multiples + peering : une entrée de réseau redondante, sans point de défaillance unique.
- RPKI signe les routes et bloque le détournement de trafic (BGP hijacking).
- Magic Transit absorbe et filtre les attaques volumétriques en bordure, en continu.
- La couche applicative (L7) reste un travail partagé : aucune protection réseau ne remplace une application durcie.
Vous voulez savoir comment votre infrastructure actuelle tiendrait face à une attaque, ou bâtir un hébergement résilient dès le départ ? Parlez à notre équipe, ou découvrez notre infogérance et nos niveaux de SLA.
FAQ — Protection DDoS d’un hébergeur
Qu’est-ce qu’une attaque DDoS ?
Une attaque par déni de service distribué (DDoS) consiste à submerger une infrastructure depuis des milliers de machines à la fois, jusqu’à la rendre indisponible. On distingue les attaques volumétriques (saturer la bande passante), protocolaires (épuiser les équipements) et applicatives (noyer le serveur web sous des requêtes).
Une PME peut-elle être visée par un DDoS ?
Oui. Les outils d’attaque se louent pour quelques euros, ce qui met n’importe quelle entreprise à portée d’un concurrent, d’un maître-chanteur ou d’un militant. La vraie question n’est pas de savoir si l’attaque arrivera, mais si l’hébergement résiste quand elle survient.
Qu’est-ce que le RPKI et à quoi sert-il ?
Le RPKI (Resource Public Key Infrastructure) permet au titulaire légitime d’un bloc d’adresses IP de signer cryptographiquement quel système autonome a le droit de l’annoncer (via une ROA). Les réseaux qui valident ces signatures rejettent les annonces frauduleuses, ce qui protège contre le détournement de trafic (BGP hijacking). Datacampus a RPKI activé.
Comment fonctionne Cloudflare Magic Transit ?
Magic Transit attire le trafic vers le réseau mondial Cloudflare via une annonce BGP en anycast, y filtre les attaques de couche réseau (L3/L4) automatiquement et en continu, puis restitue le trafic légitime à l’hébergeur via des tunnels dédiés. La protection est permanente (always-on), sans fenêtre de bascule.
La protection réseau suffit-elle contre toutes les attaques ?
Non. Le filtrage réseau (L3/L4) ne couvre pas les attaques applicatives (L7), qui imitent du trafic HTTP légitime. Celles-ci se traitent au niveau de l’application : limitation de débit, mise en cache, pare-feu applicatif et durcissement. Une défense efficace est toujours en couches.
Pourquoi avoir son propre système autonome (AS) compte ?
Disposer de son propre AS (ici AS50446) permet d’annoncer soi-même ses adresses IP en BGP et de maîtriser le routage : choisir ses opérateurs de transit, multiplier les chemins, activer RPKI. Un hébergeur sans AS propre dépend entièrement du routage d’un tiers.
Pour aller plus loin :
• Cloudflare — Magic Transit (DDoS protection for networks)
• MANRS — Mutually Agreed Norms for Routing Security (RPKI)
• Sur datacampus.fr : BGP, AS, peering expliqués · Protéger son site web : les bases · Le datacenter Cassin1 · Infogérance · Nos niveaux de SLA