Deux mots, deux comportements opposés
Un hébergeur peut réagir de deux façons face à un flood, et le secteur vend les deux sous le nom de « protection DDoS ». La première est l'absorption : le trafic est aspiré vers une couche de scrubbing en amont de votre serveur, les paquets d'attaque y sont abandonnés, les paquets légitimes continuent leur chemin, et votre service reste joignable pendant toute la durée de l'attaque. La seconde est le blackholing — aussi appelé null-routing, ou RTBH d'après la RFC 5635 — où votre adresse IP est retirée de la table de routage, si bien que plus rien ne l'atteint. Le flood cesse de frapper le datacentre. Vos utilisateurs aussi, votre supervision aussi, et votre session SSH aussi. L'attaquant obtient exactement le résultat qu'il a payé.
Les deux relèvent d'une ingénierie réelle, et aucun des deux n'est malhonnête en soi. Le blackholing existe parce qu'absorber un flood volumineux coûte de l'argent bien réel — le transit est facturé au volume, la capacité de scrubbing s'achète et se provisionne — et un hébergeur low-cost qui null-route un client pour maintenir quatre cents autres en ligne prend une décision défendable. Le piège est dans le pronom. « protection DDoS » est vraie dans les deux cas ; ce qui change, c'est le service de qui est protégé. Lisez chaque fiche tarifaire en gardant cette question en tête.
| Réponse | Trafic d'attaque | Votre service | Généralement décrit comme |
|---|---|---|---|
| Scrubbing / absorption | Filtré en amont, abandonné en périphérie | Reste en ligne, généralement sans changement visible | « mitigation permanente », « anycast scrubbing » |
| Blackhole / null-route | Abandonné avec votre trafic légitime | Hors ligne pendant toute la durée — généralement 1–24 h | « Protection jusqu'à X Gbps », « suspension IP temporaire » |
| Rate-limit en périphérie uniquement | Partiellement abandonné, en partie au hasard | Dégradé — les utilisateurs réels constatent de la perte de paquets | « Protection de base incluse » |
| Rien (l'opérateur décide) | Atteint le rack jusqu'à ce qu'un amont blackhole le préfixe | Hors ligne, tout comme vos voisins de rack | « protection DDoS disponible » |
Lire les clauses en petits caractères avant de payer
Le vocabulaire vous trahit. « Protection jusqu'à 10 Gbps » est un plafond, et la phrase qui suit immédiatement — celle sur le trafic dépassant la limite — est la clause de null-route. « IP protégée disponible en option » signifie que l'adresse fournie par défaut n'est pas protégée. « Par incident » signifie qu'une facture arrive après l'attaque. « Usage raisonnable » attachée à la mitigation signifie un quota d'attaques par mois, au-delà duquel vous êtes livré à vous-même. Aucune de ces formules n'est un mensonge ; elles sont simplement écrites pour être survolées sans qu'on s'y attarde.
Un exemple nommé et documenté publiquement, parce que c'est une politique documentée et non une rumeur : BuyVM vend des adresses filtrées DDoS comme option séparée à $3/mois par IP, et les adresses non filtrées sont null-routées pendant qu'une attaque est en cours. Nous le décrivons sans trop d'éditorialisation sur notre page de comparaison BuyVM, parce qu'une IP non filtrée bon marché est un produit parfaitement raisonnable quand on sait que c'est ce qu'on a acheté. Le mode d'échec, c'est de le découvrir à 3h00 avec un booter en cours d'exécution.
Quatre questions à poser à l'avant-vente avant la première facture. Quelle est la capacité de mitigation, et ce chiffre est-il l'agrégat ou la valeur disponible en un seul point de présence ? Un « réseau de 2 Tbps » qui se termine dans un seul centre de scrubbing n'a qu'un seul tuyau à remplir. La mitigation est-elle incluse dans ce plan, ou est-ce une option ? Y a-t-il des frais par incident ou un quota mensuel d'événements mitigés ? À quel seuil null-routez-vous, et pour combien de temps ? Un hébergeur qui répond à cette dernière question par un chiffre vaut mieux qu'un hébergeur qui y répond par des adjectifs.
Les trois couches, et pourquoi la couche détermine qui peut résoudre le problème
Couche 3/4 volumétrique. Floods SYN, floods UDP, et réflexion ou amplification via des services NTP, DNS, memcached, CLDAP et SSDP ouverts. L'attaquant dépense un peu de bande passante en amont et en récupère un multiple dirigé contre vous. C'est un problème de bande passante et de pps, et il est catégoriquement insoluble sur votre serveur : le temps que votre noyau puisse abandonner le paquet, le tuyau qui le transporte est déjà plein. Rien dans nftables ne vous sauve ici. Seule la capacité en amont le peut.
Couche 4, épuisement d'état. Floods SYN, ACK et de connexions dimensionnés non pas pour remplir le tuyau mais pour remplir une table — le backlog SYN du noyau, la table conntrack, la file d'attente accept de votre application. La bande passante peut être dérisoire : quelques centaines de Mbps suffisent à faire tomber une machine mal réglée, pendant que le graphique côté hébergeur ressemble à un après-midi tranquille. Cette couche vous appartient réellement à moitié : elle est survivable avec tcp_syncookies, un nf_conntrack_max correctement dimensionné, et des limites par source — et elle ne l'est pas sans eux.
Couche 7, application. Floods HTTP composés de requêtes individuellement valides — véritables handshakes TLS, chaînes User-Agent crédibles, parfois de vrais navigateurs — visant ce qui, sur votre site, coûte cher : recherche, connexion, panier, une page de listing adossée à une base de données. La classe HTTP/2 Rapid Reset a montré à quel point peu de mégabits suffisent quand chaque requête coûte plus cher au serveur qu'au client. Un équipement de scrubbing ne peut pas voir à l'intérieur d'une session TLS qu'il ne termine pas, donc cette couche est gérée soit par des règles en périphérie, soit par votre propre reverse proxy — jamais par de la capacité volumétrique brute.
| Couche | Attaque typique | Taille typique | Où elle doit être arrêtée | Corrigible sur votre machine ? |
|---|---|---|---|---|
| L3/L4 volumétrique | Flood UDP, amplification DNS/NTP/memcached | 5 Gbps – 1+ Tbps | En amont, en périphérie | Non — le tuyau se remplit en premier |
| L4, épuisement d'état | Flood SYN / ACK, épuisement conntrack | 0.1 – 10 Gbps | Périphérie, plus réglage du noyau | Partiellement — syncookies, dimensionnement conntrack |
| L7 application | Flood de requêtes HTTP(S), slow POST, Rapid Reset | Souvent sous 1 Gbps | Règles en périphérie ou votre reverse proxy | Oui — rate-limit, challenge, cache |
Une vraie attaque, ça fait quelle taille, honnêtement ?
Environ neuf attaques sur dix qui frappent un petit serveur offshore proviennent d'un booter ou d'un stresser — un service par abonnement coûtant $10 à $30 par mois qui revend de la capacité d'amplification à la minute. Ils délivrent quelque chose entre 5 et 50 Gbps en rafales de quelques minutes, et c'est exactement ce à quoi fait face un serveur Minecraft, un réseau IRC, un relais Tor, un forum avec un ex-modérateur remonté, ou un lobby de jeu compétitif. Cette tranche est entièrement survivable, et elle est aussi entièrement suffisante pour faire tomber un VPS non protégé à $5.
La tranche suivante — 100 à 400 Gbps depuis un botnet loué — arrive quand quelqu'un a une rancune précise et un budget. C'est rare contre les petites cibles et routinier contre les sites de jeu d'argent, de streaming et pour adultes. Au-dessus se trouvent les événements record rapportés par les grands fournisseurs de mitigation, désormais mesurés en plusieurs térabits par seconde et en centaines de millions de requêtes par seconde ; les chiffres trimestriels de Cloudflare Radar constituent la référence publique habituelle. Vous n'êtes presque certainement pas la cible visée par l'un de ces événements.
Vous pouvez néanmoins en être la victime collatérale, et c'est la partie que personne ne met sur une fiche tarifaire : les dommages collatéraux voyagent par préfixe. Si un hébergeur blackhole à une granularité de /24 — beaucoup le font, car c'est le plus petit préfixe que la plupart des carriers acceptent pour le RTBH — alors une attaque visant une seule adresse de votre sous-réseau met hors ligne toutes les adresses qu'il contient. Votre disponibilité dépend des ennemis d'un inconnu. La marge de capacité est ce qui évite d'avoir un jour à prendre cette décision.
Nos propres chiffres, pour donner un étalon plutôt que pour nous vanter : 1 Tbps de scrubbing anycast L3/L4 réparti sur quatre points de présence, chacun capable d'absorber environ 300 Gbps à lui seul, avec une détection automatique en moins de deux secondes. Le plus gros événement que nous ayons absorbé pour un client dépassait 600 Gbps contre un serveur de jeu, et les connexions des joueurs n'ont pas chuté. L'architecture est documentée plus en détail sur la page réseau.
Inclus, par incident, ou quota — la structure commerciale compte
Il existe trois façons de vendre la mitigation, et elles produisent des factures très différentes. Inclus : le coût est intégré au tarif du plan, et une attaque ne change rien à ce que vous payez. Par incident : vous êtes facturé pour chaque événement mitigé, parfois par heure de mitigation. Quota : un nombre d'événements par mois, ou une clause « usage raisonnable » qui laisse l'hébergeur décider quand vous en avez eu assez.
Le modèle par incident n'est pas une arnaque. Le trafic scrubbé traverse quand même le transit de l'hébergeur avant d'être abandonné, et le transit est facturé au 95e centile ou contre un débit engagé — une campagne soutenue contre un client est une vraie ligne sur la facture de quelqu'un. Le problème n'est pas l'équité, c'est la prévisibilité : sous une campagne de deux semaines, un hébergeur facturant à l'incident transforme une attaque contre vous en facture pour vous, ce qui revient à une seconde attaque avec des étapes en plus. Demandez quel modèle s'applique avant d'en avoir besoin.
Notre position, énoncée clairement pour être vérifiable : le bouclier est activé par défaut sur chaque plan, du Starter à $8.50 au Citadel à $299.50, sans opt-in, sans frais par incident, sans quota mensuel et sans clause « usage raisonnable » attachée à la mitigation. C'est le même fabric sur le VPS le moins cher que sur la plus grosse machine dédiée — voir les plans VPS et les tiers dédiés. Ce qui évolue avec le tier, c'est l'uplink et le jeu de règles Layer 7 optionnel, pas le fait d'être défendu ou non.
La diffusion anycast, et pourquoi le temps de détection prime sur la capacité affichée
Un centre de scrubbing unique a un plafond dur : le transit vers ce seul bâtiment. Il a aussi un coût en latence, car pendant la mitigation, tout le trafic de tout le monde est d'abord acheminé vers ce bâtiment — la raison pour laquelle certains hébergeurs deviennent visiblement plus lents pour les utilisateurs européens dès qu'une attaque commence, et le restent jusqu'à ce qu'elle s'arrête.
L'anycast change l'arithmétique avant même qu'aucun matériel n'intervienne. Le même préfixe est annoncé depuis chaque point de présence, si bien qu'un botnet réparti mondialement est divisé entre ces points par la seule topologie d'internet : une attaque de 600 Gbps lancée depuis partout arrive sous forme d'environ 150 Gbps en quatre endroits plutôt que 600 Gbps en un seul. La diffusion fait l'essentiel du travail ; le matériel de scrubbing n'a plus qu'à gérer ce qui reste une fois que la géographie l'a déjà divisé.
Le temps de détection est le chiffre sous-estimé. Une mitigation qui s'enclenche en deux secondes est invisible pour une session TCP ; une mitigation qui s'enclenche en soixante secondes arrive après que vos utilisateurs ont rechargé deux fois et sont partis, et après qu'un lobby de jeu s'est vidé. Quand un hébergeur cite la capacité mais pas la latence de détection, demandez le second chiffre — c'est celui qui détermine si vos utilisateurs ont ne serait-ce que remarqué quelque chose.
Si vous apportez votre propre préfixe, le blackholing devient un scalpel que vous tenez, plutôt que quelque chose qu'on vous fait subir. Nos communautés BGP couvrent la dé-préférence par carrier (cs:100:carrier), le prepend régional (cs:200:region) et le blackhole sélectif (cs:666:prefix), afin que vous puissiez null-router une seule adresse sous attaque pendant que le reste de votre allocation continue de servir. C'est le blackholing utilisé correctement : chirurgical, bref, et à votre décision.
La complication offshore : un proxy américain en façade annule l'intérêt de la démarche
Le conseil standard sur tous les forums est « mettez-le simplement derrière Cloudflare, le tier gratuit suffit ». Pour un site ordinaire, c'est un bon conseil. Si vous avez choisi un hébergeur offshore pour des raisons juridictionnelles, ce conseil réimporte discrètement tout ce que vous aviez laissé derrière vous : une société de droit américain termine désormais votre TLS et voit votre trafic en clair, reçoit les plaintes d'abus et de droit d'auteur et agit dessus selon sa propre politique, détient un compte rattaché à une adresse e-mail et généralement un moyen de paiement, et peut se voir signifier une procédure judiciaire américaine. Que votre hébergeur ignore une notification DMCA ne vaut pas grand-chose si votre CDN, lui, l'honore — les mécanismes sont détaillés dans l'explicatif DMCA-ignored et l'exposition juridictionnelle dans le guide des 14-Eyes.
Un proxy ne cache pas non plus votre origine, sauf si vous restreignez le firewall de l'origine aux seuls préfixes du proxy, et que vous le maintenez ainsi. Même alors, l'adresse fuite par l'historique DNS passif, par les logs de certificate transparency si l'origine a déjà répondu en TLS sous son propre nom, par du courrier envoyé directement depuis la machine, par un vieil enregistrement A jamais retiré, et par toute page d'erreur qui renvoie le nom d'hôte propre du serveur. C'est ainsi que les sites « protégés » finissent quand même par tomber : des accès directs à l'origine. Le guide de l'hébergement anonyme détaille toute la surface de fuite.
Si vous voulez une couche proxy sans le coût juridictionnel, faites-la tourner vous-même : une seconde petite instance dans la même juridiction ou une juridiction compatible, terminant le TLS sous votre propre clé, avec le firewall de l'origine n'acceptant que cette adresse. Vous gardez le cache et le filtrage des requêtes, et aucun tiers ne rejoint la chaîne de confiance. Les deux machines sont derrière le même fabric de scrubbing, donc le proxy n'est pas une nouvelle cible fragile.
Ce qui reste de votre ressort, sur la machine
Le scrubbing en amont protège le tuyau. Il ne règle pas votre noyau, et la bande d'épuisement d'état est celle où un serveur mal réglé meurt sous une attaque que le réseau a à peine enregistrée. La liste courte, dans l'ordre où elle rapporte : activez net.ipv4.tcp_syncookies et augmentez net.ipv4.tcp_max_syn_backlog (les paramètres sont documentés dans la référence ip-sysctl du noyau) ; dimensionnez nf_conntrack_max au nombre de connexions réellement attendu, ou utilisez notrack pour le trafic de jeu UDP à haut débit afin que la table ne soit jamais consultée ; ajoutez des limites par source dans nftables plutôt que de compter sur la périphérie pour être chirurgicale.
Côté application, limit_req et limit_conn dans nginx ne coûtent rien et arrêtent la plupart des floods L7 qui ne sont pas délibérément façonnés pour ressembler à du trafic humain. Mettez en cache tout ce qui peut l'être, car la meilleure cible d'un attaquant est toujours cette unique page que vous générez depuis la base de données à chaque requête. Gardez SSH et tout panneau de contrôle hors de l'adresse qui sert la charge publique, ou derrière une allowlist.
Une direction que l'on oublie : ne devenez pas un réflecteur. Un résolveur DNS ouvert, un démon NTP mal configuré ou un memcached exposé sur votre machine vous transforme en rouage de l'attaque d'amplification de quelqu'un d'autre, et les abus sortants sont traités bien plus sévèrement que les abus entrants — le délai de réponse publié dans notre AUP est un null-route et une suspension sous deux heures. Les floods entrants sont quelque chose qui vous arrive ; les floods sortants sont quelque chose dont vous êtes responsable.
La checklist à dérouler avant d'acheter
Neuf questions, dans l'ordre qui départage les hébergeurs le plus vite. Quelle est la capacité de mitigation, et est-elle par point de présence ou agrégée ? Est-elle incluse dans le prix du plan ou vendue par IP ? Y a-t-il des frais par incident, ou un quota d'événements mitigés par mois ? Quelle est la latence de détection ? Le filtrage Layer 7 est-il seulement disponible, et sur quels tiers ? À quel seuil et pour quelle durée null-routez-vous, et êtes-vous prévenu quand cela arrive ? La mitigation change-t-elle mon routage ou ma latence pendant qu'elle est active ? La protection porte-t-elle sur l'adresse que j'obtiens par défaut ? Et — celle que presque personne ne pose — que conservez-vous de mon trafic pendant que la mitigation tourne ?
Cette dernière question compte plus sur ce marché que sur n'importe quel autre. Le scrubbing signifie que quelque chose en amont regarde vos paquets. Demandez ce qui survit à l'événement. Notre réponse, et elle ne change pas pendant une attaque : la détection tourne sur des compteurs agrégés en périphérie — paquets et bits par seconde, par préfixe — pas sur des enregistrements par flux conservés, et la position permanente de ni netflow, ni PCAP, ni mirroring NIC publiée dans la politique de confidentialité s'applique pendant la mitigation exactement comme le reste du temps. Un hébergeur incapable de répondre à cela vous dit quelque chose.
Si les réponses reviennent maigres, le repli est bon marché : achetez un mois du plus petit plan, pointez une sonde de supervision dessus, et demandez directement au support ce qui se passe quand la machine est frappée. Il n'y a ni contrat ni frais de mise en place ici, donc un hébergeur qui esquive la question par écrit ne vous coûte que $8.50 à découvrir. Déployez un Starter, ou lisez VPS contre dédié si la charge est assez grosse pour que la réponse change le tier.
