Cloudflare sous le capot : comment ça marche et comment les attaquants contournent la protection
Ce qui se passe vraiment quand une requête touche un site protégé par Cloudflare, comment Turnstile distingue les bots des humains, et les techniques utilisées pour trouver le serveur d'origine derrière le proxy.
La plupart des développeurs connaissent Cloudflare comme “le truc qui se met devant ton site et bloque les bots.” Cette description est exacte mais incomplète. Comprendre comment ça fonctionne vraiment change la façon dont on le configure, et comment on pense aux failles qu’il laisse ouvertes.
Cet article couvre trois points : ce que Cloudflare fait au niveau réseau, comment Turnstile fonctionne sous le capot, et les techniques utilisées pour trouver les serveurs d’origine et contourner la protection anti-bots. La dernière section est formulée de façon défensive : si vous savez comment les attaques fonctionnent, vous savez quoi fermer.
1. Ce qu’est vraiment Cloudflare
Cloudflare n’est pas un reverse proxy qui tourne sur un serveur quelque part. C’est un réseau edge distribué mondialement avec plus de 300 points de présence (PoPs). Quand vous mettez votre domaine derrière Cloudflare, vous routez tout le trafic à travers ce réseau avant qu’il n’atteigne jamais votre serveur.
Le mécanisme est l’anycast routing. Cloudflare annonce la même adresse IP depuis chaque PoP simultanément. Quand un utilisateur envoie une requête vers votre site, le routage BGP la dirige automatiquement vers le PoP le plus proche, pas vers votre serveur d’origine. À partir de là, Cloudflare décide quoi en faire.
Utilisateur à Tokyo
|
| (l'anycast route vers le PoP le plus proche)
v
PoP Cloudflare Tokyo
|-- en cache ? → servir depuis l'edge, origine jamais touchée
|-- bloquée ? → retourner 403, origine jamais touchée
|-- challenge ? → lancer Turnstile, origine jamais touchée
|-- propre ? → transmettre à l'origine, retourner la réponse
v
Votre serveur d'origine
La terminaison TLS se fait au PoP edge, pas sur votre origine. Cloudflare détient le certificat, déchiffre la requête, l’inspecte, puis la rechiffre pour le trajet vers votre origine (en supposant que SSL entre Cloudflare et l’origine est activé, ce qui devrait être le cas).
C’est pourquoi Cloudflare peut inspecter le trafic HTTPS pour les règles WAF sans attaque man-in-the-middle : vous leur déléguez explicitement ce déchiffrement.
2. Les couches entre une requête et votre serveur
Une requête arrivant à un PoP Cloudflare passe par plusieurs couches de décision dans l’ordre :
La mitigation DDoS s’exécute en premier. Les floods volumétriques sont absorbés au niveau réseau. Les floods HTTP sont identifiés par le débit, le pattern et la réputation.
La réputation IP et le géofencing vérifie l’IP source contre la base de données de menaces de Cloudflare. Les IPs de botnets connus, de nœuds de sortie Tor ou de plages datacenter reçoivent un score.
Le WAF inspecte la couche HTTP : headers, chemin, paramètres de requête, corps. Cloudflare maintient un ensemble de règles couvrant l’OWASP Top 10 et les CVE connus.
La gestion des bots (Turnstile est la partie visible) attribue à chaque requête un score bot de 1 à 99. Score 1 : presque certainement un bot. Score 99 : presque certainement humain.
Le cache est la dernière couche avant l’origine. Si la réponse est cacheable et qu’une copie fraîche existe au PoP, Cloudflare la sert sans toucher à votre serveur.
3. Comment fonctionne Turnstile
Turnstile est le remplacement du CAPTCHA par Cloudflare. Contrairement au reCAPTCHA v2, il n’a pas de challenge visuel : l’objectif est de vérifier qu’un visiteur est humain sans lui faire résoudre quoi que ce soit.
1. Le widget charge un challenge JavaScript depuis l’edge de Cloudflare. Le script est différent à chaque requête, ce n’est pas un fichier statique qu’on peut analyser une fois.
2. Le script collecte des signaux passifs :
- Timing : combien de temps chaque opération JS a-t-elle pris ? Les browsers headless tournant à plein régime CPU ont un timing suspicieusement uniforme.
- Interaction : la souris a-t-elle bougé avant la soumission du formulaire ? Les frappes clavier ont-elles des délais naturels ?
- Empreinte du navigateur : rendu canvas, renderer WebGL, polices installées, sortie du contexte audio.
- Environnement :
navigator.webdriverest-il exposé ? Les outils de développement sont-ils ouverts ?
3. Cloudflare passe ces signaux dans un modèle entraîné sur des milliards de requêtes et émet un token signé si la requête semble humaine.
4. Votre backend vérifie le token contre l’API siteverify de Cloudflare :
POST https://challenges.cloudflare.com/turnstile/v0/siteverify
{
"secret": "votre-clé-secrète",
"response": "token-du-widget"
}
Si votre backend ne fait pas cet appel, la protection est entièrement côté client et contournable trivialement en sautant l’étape de soumission du formulaire.
4. Trouver le serveur d’origine derrière Cloudflare
Si un attaquant trouve votre IP d’origine, il peut contourner Cloudflare entièrement en envoyant des requêtes directement à cette IP. Votre WAF, votre protection DDoS et Turnstile disparaissent tous.
Voici les techniques couramment utilisées, par ordre de fréquence de succès.
Historique des certificats SSL
Avant de mettre un domaine derrière Cloudflare, il avait un certificat émis directement vers l’origine. Les logs de transparence des certificats sont publics et enregistrent chaque certificat jamais émis :
https://crt.sh/?q=example.com
Si l’IP d’origine apparaît dans un certificat avant l’activation de Cloudflare, elle est dans le log pour toujours.
Historique DNS
Avant Cloudflare, votre enregistrement A pointait directement vers votre origine. Ces anciens enregistrements sont archivés par SecurityTrails, DNSDumpster et ViewDNS.info, souvent avec des horodatages indiquant exactement quand vous avez basculé.
Sous-domaines pas derrière Cloudflare
Beaucoup d’équipes proxifient www et l’apex mais laissent d’autres sous-domaines avec un nuage gris (non proxifié) par accident :
ftp.example.com: legacy, pointe souvent vers l’originedev.example.com,staging.example.com: oubliésapi.example.com: parfois bypass le proxy pour des raisons de latence
Une passe d’énumération de sous-domaines révèle lesquels résolvent vers une IP non-Cloudflare.
Enregistrements MX
Les serveurs mail ne peuvent pas être proxifiés par Cloudflare. Votre enregistrement MX pointe directement vers un serveur mail, souvent sur le même bloc IP que votre serveur web :
dig MX example.com # → mail.example.com
dig A mail.example.com # → 203.0.113.42
Enregistrements SPF
Les enregistrements SPF listent chaque IP autorisée à envoyer des emails en votre nom. Ils incluent souvent votre serveur d’origine ou les plages IP de votre hébergeur :
dig TXT example.com
# v=spf1 ip4:203.0.113.0/24 include:sendgrid.net ~all
Shodan et empreinte de certificat
Si votre origine utilise un certificat origin Cloudflare, son empreinte est la même quelle que soit la façon d’y accéder. Shodan et Censys indexent les certificats TLS sur tout l’espace IPv4 : cherchez l’empreinte de votre certificat pour trouver l’IP brute.
5. Contourner Turnstile
Services de résolution
2captcha, Anti-Captcha et CapSolver utilisent des travailleurs humains qui lancent une vraie session navigateur et renvoient le token. Ça fonctionne mais c’est lent (plusieurs secondes par token) et coûte de l’argent par résolution. Pratique à faible volume, coûteux à grande échelle.
Spoofing de navigateur headless
Playwright et Puppeteer combinés avec des plugins stealth patchent les propriétés détectables :
navigator.webdrivermis àundefined- Empreinte canvas spoofée
- Mouvements de souris et timing de frappe réalistes
- User agent Chrome complet
Un navigateur headless bien configuré peut passer Turnstile à un taux raisonnable. Le modèle de Cloudflare est continuellement mis à jour, mais c’est une course aux armements permanente.
Ce qui arrête vraiment la plupart des bots
Le widget Turnstile visible n’est pas la principale ligne de défense. Le score bot de Cloudflare, construit à partir de signaux au niveau réseau (réputation IP, ASN, débit de requêtes, empreinte TLS) capture bien plus de trafic que le challenge JS. Une requête venant d’AWS Lambda avec un User-Agent propre a quand même un ASN datacenter : ça seul fait monter le score bot avant que le moindre JS s’exécute.
Turnstile seul, validé uniquement côté client, est faible. C’est la combinaison du scoring réseau et de l’analyse comportementale qui rend le système efficace.
6. Comment vraiment protéger votre origine
Utilisez Cloudflare Tunnel. C’est la seule approche qui cache complètement votre IP d’origine. cloudflared ouvre une connexion sortante depuis votre serveur vers le réseau de Cloudflare. Aucun port entrant ouvert, aucune IP à trouver.
cloudflared tunnel create mon-tunnel
cloudflared tunnel route dns mon-tunnel example.com
cloudflared tunnel run mon-tunnel
Si vous ne pouvez pas utiliser Tunnel, pare-feu votre origine aux IPs Cloudflare uniquement. Cloudflare publie sa liste complète d’IPs sur cloudflare.com/ips-v4. N’autorisez que ces plages sur les ports 80 et 443. Bloquez tout le reste.
Proxifiez chaque sous-domaine. Auditez vos enregistrements DNS. Chaque sous-domaine qui devrait être proxifié doit avoir le nuage orange activé. Les enregistrements à nuage gris pointant vers votre origine sont un bypass par conception.
Gardez le mail sur une IP séparée. Votre serveur mail ne devrait pas partager une IP ou un bloc IP avec votre serveur web.
Validez Turnstile côté serveur, toujours. Le token doit être vérifié par votre backend à chaque soumission de formulaire.
Vérifiez votre historique de certificats maintenant. Passez votre domaine dans crt.sh et SecurityTrails. Si votre ancienne IP d’origine est visible, soit vous changez d’IP (et utilisez Tunnel à l’avenir), soit vous misez entièrement sur l’approche pare-feu.
Cloudflare est une protection genuinement excellente, mais ce n’est pas une boîte noire qu’on active et oublie. Les failles sont bien connues, exploitées systématiquement, et toutes fermables avec les étapes ci-dessus.