Protection DDoS pour sites web : ce qui aide vraiment

Une bonne protection DDoS pour un site web n’est pas un produit unique, mais plusieurs couches qui arrêtent chacune un type d’attaque différent : le filtrage réseau contre les inondations brutes, un reverse proxy devant le site, des règles contre les attaques applicatives et un serveur d’origine qui ne parle qu’à ce proxy. Le moment compte plus que tout, car une protection déjà en place agit dès la première requête, alors qu’une protection ajoutée en pleine attaque vous coûte des heures. Si votre site est attaqué en ce moment, rendez-vous sur la page dédiée aux attaques en cours ou consultez notre guide que faire si votre site subit une attaque DDoS.

Pourquoi la protection doit se trouver devant votre serveur

Un serveur occupé à répondre à des requêtes parasites ne peut pas en même temps décider lesquelles sont parasites. Au moment où une règle de pare-feu ou une extension de sécurité sur votre serveur examine une requête, la bande passante est déjà consommée et PHP a souvent déjà démarré. Une protection efficace filtre le plus loin possible de l’origine.

Pour la prévention, la question utile est de savoir quelle couche arrête quel type d’attaque :

Aucune couche ne couvre tout : un proxy sans durcissement de l’origine peut être contourné, et une origine durcie sans proxy affronte seule chaque inondation HTTP.

Les quatre couches en détail

1. Niveau réseau : inondations volumétriques et de protocole

Les attaques volumétriques saturent la connexion de votre serveur avec plus de trafic qu’elle ne peut en transporter. Rien de ce que vous configurez sur le serveur n’aide, car le lien est saturé avant que votre pare-feu ne voie le moindre paquet. Cette couche est gérée en amont par le réseau de votre hébergeur ou par un service de nettoyage dédié. Votre rôle est de savoir ce que fait votre hébergeur à ce niveau et de cacher l’IP de votre origine derrière un proxy, pour que les attaquants doivent inonder le réseau du proxy plutôt que la connexion de votre serveur.

2. Un reverse proxy devant tout le site

Un reverse proxy de site complet reçoit chaque requête vers votre domaine, répond à ce qu’il peut depuis son cache et transmet le reste à votre origine. Deux effets comptent :

• Les pages en cache ne coûtent presque rien. Une inondation contre votre page d’accueil est inoffensive si cette page est servie depuis l’edge et n’atteint jamais votre serveur.
• Le filtrage a lieu avant l’origine. Les règles, limites de débit et challenges s’exécutent en edge, les requêtes bloquées ne coûtent donc rien à votre serveur.

Assurez-vous que le proxy couvre votre HTML. Un CDN de ressources qui ne sert que les images et les scripts depuis un nom d’hôte séparé accélère le site, mais les requêtes de pages vont toujours directement à votre serveur, et les attaques aussi. Le guide qu’est-ce qu’un CDN explique la différence.

3. WAF, limitation de débit et règles anti-bots pour la couche 7

Les inondations applicatives sont les attaques les plus fréquentes contre les petits et moyens sites, et les plus difficiles à repérer, car chaque requête a l’air légitime. Elles visent les URL qui font le plus travailler votre serveur, alors construisez vos règles autour de celles-ci :

Un pare-feu applicatif web (WAF) avec des jeux de règles gérés bloque aussi les tentatives d’exploitation comme l’injection SQL et le cross-site scripting, et les règles anti-bots tiennent les scrapers à distance. Les règles par pays aident si vous ne servez que quelques marchés, mais préférez un challenge à un blocage strict pour que les clients qui passent par un VPN puissent toujours entrer.

4. Durcissement de l’origine

Un proxy ne vous protège que si les attaquants ne peuvent pas le contourner. Une fois votre site derrière un proxy, verrouillez l’origine :

• N’acceptez le trafic web que depuis le proxy. Configurez le pare-feu du serveur ou de l’hébergeur pour que les ports 80 et 443 n’acceptent que les connexions provenant des plages d’IP publiées par votre fournisseur de proxy.
• Partez du principe que les anciens enregistrements DNS sont connus. Si votre domaine pointait auparavant directement vers votre serveur, les services qui archivent l’historique DNS rendent cette IP facile à trouver. Demandez à votre hébergeur si vous pouvez obtenir une nouvelle IP après la migration.
• Vérifiez les sous-domaines. Des enregistrements comme staging, dev, ftp, cpanel ou mail pointent souvent directement vers le même serveur et révèlent l’origine.
• Séparez la messagerie du serveur web. Si votre enregistrement MX pointe vers le serveur web, ou si le serveur envoie lui-même les e-mails du formulaire de contact, son IP apparaît dans le DNS et dans les en-têtes Received de chaque e-mail. Vérifiez aussi votre enregistrement SPF à la recherche d’entrées ip4: qui trahissent le serveur.

Une vérification rapide montre quels enregistrements pointent vers l’IP de votre origine :

dig +short example.com A
dig +short mail.example.com A
dig +short example.com MX
dig +short example.com TXT

Toute réponse qui contient l’IP de votre serveur est un moyen de contourner votre proxy.

Ce que couvre votre hébergeur, et ce qu’il ne couvre pas

Beaucoup d’hébergeurs filtrent les grandes attaques volumétriques en bordure de leur réseau. Cela protège leur infrastructure et tous leurs clients, ce qui n’est pas la même chose que protéger votre site. Les lacunes typiques :

• Les inondations de couche 7 passent. Quelques centaines de requêtes HTTP par seconde, c’est minuscule pour le réseau d’un datacenter, mais suffisant pour surcharger un CMS ou une boutique typique.
• Le null routing vous met hors ligne. Si une attaque menace le réseau, certains hébergeurs cessent d’acheminer le trafic vers l’IP visée. Les autres clients sont à l’abri, votre site est hors service.
• Les limites de ressources se font sentir. Sur les offres mutualisées ou infogérées, une attaque peut pousser votre compte jusqu’à ses limites de CPU ou de processus, et votre site est bridé.
• Pas de règles par site. En général, vous ne pouvez pas définir vos propres limites de débit ou challenges au niveau du réseau de l’hébergeur.

Posez ces questions à votre hébergeur et conservez les réponses :

1. Quels types d’attaques filtrez-vous, et le filtrage des inondations HTTP (couche 7) fait-il partie de mon offre ?
2. Qu’arrive-t-il à mon site pendant une grosse attaque : bridage, null routing, suspension ?
3. Puis-je restreindre mon serveur pour qu’il n’accepte le trafic web que depuis les plages d’IP d’un proxy ?
4. Comment joindre le support pendant une attaque ?

Comment choisir un service de protection

Si votre hébergeur couvre le niveau réseau mais pas votre application, un service basé sur un proxy comble la lacune. Comparez sur des critères, pas sur des arguments marketing :

• Couverture du site complet. Il fait passer votre HTML par le proxy, pas seulement les ressources statiques.
• Toujours actif. Un filtrage permanent ne nécessite aucune bascule pendant une attaque. Avec les services à la demande, c’est justement le temps de bascule qui pose problème.
• Des outils de couche 7 que vous maîtrisez. Une détection automatique, plus vos propres blocages d’IP, règles par pays, challenges et limites de débit.
• Un cache sûr et de la visibilité. Il respecte vos en-têtes Cache-Control, ne met jamais en cache les paniers ni les pages de clients connectés, et affiche requêtes et erreurs avec des alertes.
• Les bons robots continuent de passer. Les robots des moteurs de recherche et les notifications des prestataires de paiement passent toujours quand les règles se durcissent.
• Un DNS complet. Que vous changiez de serveurs de noms ou d’un seul enregistrement, les enregistrements MX, TXT et SRV doivent continuer de fonctionner. Notre checklist pour changer de serveurs de noms sans interruption traite ce point.
• Facturation pendant les attaques. Demandez comment le trafic d’attaque est décompté du trafic inclus.
• Support. Comment joindre une personne pendant une attaque.

Les recommandations sur le déni de service (en anglais) du National Cyber Security Centre britannique sont une bonne lecture neutre pour planifier.

Une checklist de préparation

Parcourez cette liste une fois, puis revoyez-la tous les quelques mois :

• Contacts. Le support de l’hébergeur avec votre numéro client, votre agence ou votre développeur, votre fournisseur de protection, et la personne qui décide de désactiver des fonctions ou d’informer les clients.
• Accès. Au moins deux personnes peuvent se connecter au registrar, au DNS et au tableau de bord du proxy, chacune avec son propre compte et une authentification à deux facteurs.
• DNS. Gardez un export à jour de votre zone et sachez quels enregistrements doivent rester joignables.
• Supervision. Une surveillance externe de disponibilité, des alertes sur les pics de trafic et la hausse des erreurs 5xx, et une vue sur le CPU de votre origine.
• Procédure d’urgence. Une page avec les règles plus strictes à activer, les fonctions coûteuses que vous pouvez couper pendant une journée (recherche en direct, widgets de recommandation, appels d’API externes) et un court message pour les clients.
• Test de l’origine. Vérifiez que votre origine refuse le trafic direct, avec l’IP de votre serveur :

curl -sI --max-time 10 --resolve www.example.com:443:203.0.113.10 https://www.example.com/

Si cette commande renvoie une réponse au lieu d’expirer ou d’être refusée, votre origine accepte encore du trafic qui contourne le proxy.

Comment fast.site vous aide

fast.site est un reverse proxy de site complet placé devant votre hébergement existant. Vous gardez votre hébergeur et faites pointer les serveurs de noms de votre domaine vers fast.site. Dès lors, chaque requête atteint d’abord le réseau edge et y est filtrée avant que quoi que ce soit ne soit transmis à votre origine. fast.site gère votre zone DNS, y compris les enregistrements MX, TXT et SRV, comme décrit dans la documentation DNS.

La détection DDoS de couche 7 fonctionne automatiquement sur tous les domaines, sans configuration. Vous pouvez aussi bloquer des IP et des plages CIDR, bloquer des pays ou leur imposer un challenge CAPTCHA, créer vos propres règles de challenge et définir des limites de débit par IP. Des jeux de règles gérés filtrent l’injection SQL, le XSS et les mauvais bots. La documentation sur la sécurité liste toutes les options.

Le cache soulage aussi votre serveur : les pages publiques affichent fs-cache: HIT et sont servies depuis l’edge, tandis que les paniers, les commandes et les sessions connectées affichent BYPASS. Les statistiques montrent les requêtes, les taux d’erreur et la bande passante de l’origine, et des alertes d’anomalie signalent les pics de trafic. La protection réseau de la connexion de votre origine reste du ressort de votre hébergeur, alors réservez l’accès à votre origine au proxy.

Mettez tout en place à tête reposée et mesurez le résultat sur votre propre site. Vous pouvez l’essayer avec un essai gratuit de 7 jours, sans carte bancaire. Les offres sont détaillées sur la page des tarifs.

Questions fréquentes

Les petits sites ont-ils besoin d’une protection DDoS ?

La taille ne protège pas. Les petits sites tombent sous une inondation HTTP modeste, et sur un hébergement mutualisé, une attaque contre un site voisin peut aussi toucher le vôtre. Si une interruption vous coûte des commandes, des prospects ou votre réputation, une protection devant le site vaut la peine d’être mise en place.

La protection DDoS est-elle incluse dans mon hébergement web ?

Souvent en partie. Beaucoup d’hébergeurs filtrent les grandes inondations réseau pour protéger leur infrastructure, mais les inondations applicatives contre votre site passent généralement, et certains hébergeurs appliquent un null routing à l’IP attaquée. Demandez précisément quels types d’attaques sont couverts.

Un CDN protège-t-il contre les attaques DDoS ?

Seulement s’il fait passer tout votre site par son proxy et filtre le trafic avant qu’il n’atteigne votre serveur. Un CDN de ressources sur un nom d’hôte séparé ne protège pas vos pages, car les requêtes HTML vont toujours directement à votre origine.

Une protection DDoS ralentit-elle mon site ?

Un proxy ajoute une étape entre le visiteur et le serveur, mais les pages en cache servies depuis un edge proche arrivent souvent plus vite. Cela dépend de votre site et de vos visiteurs, alors faites une comparaison avant/après comme décrit dans notre guide pour mesurer la vitesse d’un site.