04 - La sécurité offerte par un CDN : DDoS, WAF et bot protection

Ce que tu vas apprendre

Comment Cloudflare absorbe les attaques DDoS
Le WAF et les regles de firewall
La détection de bots et le rate limiting
Comment cacher l'IP de ton origin

Prerequisites

02 - Configurer Cloudflare : Cloudflare actif sur ton domaine

La protection DDoS

Une attaque DDoS (Distributed Denial of Service), c'est des milliers ou millions de requêtes envoyees simultanément vers ton serveur pour le saturer. Un VPS a 10 euros/mois ne tient pas face a ca. Meme un serveur dédié a ses limites.

Cloudflare absorbe ces attaques a la périphérie de son réseau avant qu'elles n'atteignent ton origin. Leur capacité réseau dépassé 280 Tbps. En 2024, ils ont mitige une attaque DDoS de 5,6 Tbps (la plus grosse jamais enregistree a l'epoque, un botnet Mirai de 13 000 appareils IoT). Ton VPS n'aurait meme pas eu le temps de loguer la première requête.

Le truc vraiment bien : la protection DDoS est incluse dans le plan gratuit, sans limite de volume. Pas de surcharge en cas d'attaque, pas de facturation a l'usage. Cloudflare a fait ce choix stratégique parce que plus ils voient de trafic, mieux leurs algorithmes de détection fonctionnent. Tu en profites directement.

Pour mon site paltemps.fr, je n'ai jamais subi d'attaque DDoS serieuse (le site n'est pas assez interessant pour ca). Mais j'ai vu dans les analytics Cloudflare des pics de trafic suspect bloques automatiquement. Des rafales de requêtes depuis des plages d'IP connues pour l'hébergement de bots, filtrees sans que je fasse quoi que ce soit.

Le WAF (Web Application Firewall)

Le WAF analyse les requêtes HTTP entrantes et bloque celles qui correspondent a des patterns d'attaque connus. Injections SQL, XSS, path traversal, inclusion de fichiers distants. Les classiques de l'OWASP Top 10.

Sur le plan gratuit, tu as acces aux regles managees de base. Le plan Pro ($20/mois) debloque le WAF complet avec les regles OWASP et des regles spécifiques a des CMS (WordPress, Joomla, etc.).

Ce qui est accessible gratuitement, ce sont les Custom Rules (anciennement Firewall Rules). Tu as droit a 5 regles sur le plan gratuit. Quelques exemples concrets :

Bloquer tout le trafic d'un pays spécifique :

(ip.geoip.country eq "XX")
Action: Block

Exiger un challenge JS pour acceder a l'admin :

(http.request.uri.path contains "/admin")
Action: Managed Challenge

Rate limiter les tentatives de login :

(http.request.uri.path eq "/api/login" and http.request.method eq "POST")
Action: Rate Limit (5 requetes par minute par IP)

Les Custom Rules utilisent un langage d'expression spécifique a Cloudflare (Wirefilter syntax). C'est lisible, bien documente, et beaucoup plus puissant que ce que tu pourrais faire avec iptables ou fail2ban sur ton VPS.

La détection de bots

Pas tous les bots sont malveillants. Googlebot, Bingbot, les crawlers de réseaux sociaux : ceux-la, tu les veux. Les scrapers agressifs, les credential stuffers, les vulnerability scanners : ceux-la, non.

Cloudflare Bot Management (plan Enterprise) utilise du machine learning, du fingerprinting JavaScript et de l'analyse comportementale pour classifier les bots. Sur le plan gratuit, tu as "Bot Fight Mode" qui détecté et bloque les bots les plus evidents.

Le système de challenge a beaucoup evolue. L'ancien CAPTCHA (cocher des bus et des feux de circulation) est remplace par le "Managed Challenge". Cloudflare décidé si l'utilisateur doit voir un challenge interactif ou si une vérification invisible (JS challenge) suffit. L'experience utilisateur est nettement meilleure qu'avant.

Dans les Firewall Events du dashboard, tu peux voir en temps réel les requêtes bloquees, challengees ou autorisees. C'est un bon reflexe de vérifier cette page de temps en temps. Tu y decouvres des trucs surprenants. Quand j'ai regarde les logs de paltemps.fr pour la première fois, j'ai trouve des centaines de requêtes vers /wp-login.php, /.env, /xmlrpc.php. Mon site n'utilise pas WordPress et n'a pas de fichier .env expose, mais les bots essaient quand meme.

Cacher l'IP de ton origin

Quand tu actives le proxy Cloudflare (nuage orange), l'IP de ton VPS n'apparaît plus dans les réponses DNS. Les utilisateurs voient les IP de Cloudflare. C'est une protection de base mais elle a une faille : si ton IP origin a deja ete exposee (dans un vieux record DNS, dans un email envoye depuis le serveur, dans un historique Shodan), un attaquant peut la trouver et attaquer directement.

Quelques mesures supplementaires :

Authenticated Origin Pulls : tu configures ton serveur pour n'accepter les connexions HTTPS que si elles presentent un certificat client Cloudflare. Meme si quelqu'un trouve ton IP, il ne peut pas se connecter directement. Avec Caddy, la config ressemble a ca :

tonsite.fr {
    tls {
        client_auth {
            mode require_and_verify
            trusted_ca_cert_file /etc/caddy/cloudflare-origin-pull-ca.pem
        }
    }
    reverse_proxy localhost:3000
}

Firewall VPS : configure iptables ou ufw pour n'accepter le trafic HTTP/HTTPS que depuis les plages d'IP de Cloudflare. Cloudflare publie ses plages sur https://www.cloudflare.com/ips/. Un script cron qui met à jour les regles firewall toutes les semaines, c'est simple et efficace.

bash# Exemple avec ufw
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
    ufw allow from $ip to any port 443
done
ufw deny 443

Under Attack Mode

Quand tu subis une attaque active et que la protection automatique ne suffit pas, Cloudflare a un bouton panique : "I'm Under Attack Mode". Ca force un challenge JavaScript de 5 secondes sur chaque visiteur avant de le laisser acceder au site.

C'est agressif (chaque visiteur voit une page d'attente), mais ca filtre efficacement le trafic automatise. J'ai du l'activer une seule fois, par curiosite plus que par nécessité. Desactive-le des que l'attaque est terminee, sinon tu penalises tes vrais utilisateurs.

Le rate limiting

Le rate limiting permet de limiter le nombre de requêtes par IP sur une periode donnee. Sur le plan gratuit, tu as une regle de rate limiting. Le plan Pro en offre plus.

Mon usage typique : limiter les endpoints d'API sensibles. 10 requêtes par minute sur /api/auth/*, 30 requêtes par minute sur /api/search. Quand la limite est atteinte, Cloudflare renvoie un 429 (Too Many Requests) sans que la requête touche ton origin.

C'est plus fiable que du rate limiting applicatif parce que la requête est bloquee avant d'arriver sur ton serveur. Ton VPS ne consomme aucune ressource pour gerer le trafic abusif.

Prochain article : Optimiser les performances avec Cloudflare.

Navigation : Precedent : 03 - CDN devant un bucket | Suivant : 05 - Optimisation avancee

Sources

Cloudflare DDoS Protection par Cloudflare
Record-breaking 5.6 Tbps DDoS attack par Cloudflare Blog
Cloudflare WAF Documentation par Cloudflare Docs
Authenticated Origin Pulls par Cloudflare Docs

Retrouve d'autres articles techniques sur paltemps.fr.