Contourner Cloudflare : Accéder au serveur d’origine tout en évitant le WAF

Cloudflare est l’un des fournisseurs de services de sécurité et de performance web les plus populaires, offrant une protection contre les attaques par déni de service distribué (DDoS) et un pare-feu d’application web (WAF) pour protéger les sites web contre les vulnérabilités courantes. Cependant, si le serveur d’origine d’un site web n’est pas correctement configuré, un attaquant peut contourner Cloudflare et accéder directement au serveur, rendant les protections du WAF inefficaces. Cet article explore comment les attaquants identifient l’adresse IP d’origine et comment vous pouvez sécuriser votre infrastructure contre ces techniques.

CloudFare Logo

Comment fonctionne Cloudflare

Normalement, Cloudflare agit comme un proxy inverse. Lorsqu’un utilisateur visite un site protégé, sa requête est dirigée vers le réseau de Cloudflare. Cloudflare inspecte la requête, bloque les menaces potentielles via son WAF, puis récupère le contenu du serveur d’origine pour le renvoyer à l’utilisateur. L’adresse IP réelle du serveur d’origine est masquée derrière les adresses IP de Cloudflare.

Pourquoi contourner Cloudflare ?

Contourner Cloudflare permet à un attaquant de :

  1. Lancer des attaques DDoS directement sur le serveur d’origine.
  2. Exploiter des vulnérabilités web que le WAF de Cloudflare aurait normalement bloquées.
  3. Éviter les limitations de débit (rate limiting) et les contrôles de sécurité basés sur la réputation IP.

Techniques pour trouver l’IP d’origine

1. Enregistrements DNS historiques

Même si un site utilise Cloudflare aujourd’hui, il ne l’a peut-être pas toujours fait. Des services comme SecurityTrails ou DNSHistory conservent des archives des anciens enregistrements DNS. Si l’adresse IP du serveur n’a pas été modifiée lors du passage à Cloudflare, elle peut être trouvée dans ces bases de données.

2. Sous-domaines non protégés

Souvent, seuls le domaine principal (https://www.google.com/search?q=exemple.com) et le sous-domaine www sont protégés par Cloudflare. D’autres sous-domaines comme https://www.google.com/search?q=dev.exemple.com, https://www.google.com/search?q=staging.exemple.com, ou https://www.google.com/search?q=ftp.exemple.com peuvent pointer directement vers la même adresse IP d’origine sans passer par le proxy de Cloudflare.

3. Certificats SSL/TLS

L’utilisation de moteurs de recherche de certificats comme Censys ou Shodan permet de rechercher des serveurs qui présentent un certificat SSL spécifique. Si un serveur web utilise un certificat SSL pour le domaine cible mais n’est pas masqué par Cloudflare, son adresse IP sera exposée dans les résultats de recherche.

4. En-têtes d’e-mails

Si le serveur web envoie des e-mails (via un formulaire de contact ou une réinitialisation de mot de passe), l’en-tête de l’e-mail reçu peut contenir l’adresse IP réelle du serveur dans le champ « Received » ou « X-Originating-IP ».

5. Requêtes sortantes via des vulnérabilités (SSRF)

Si le site web possède une vulnérabilité de type Server-Side Request Forgery (SSRF), un attaquant peut forcer le serveur à effectuer une requête vers un serveur externe contrôlé par l’attaquant. L’adresse IP de la requête entrante sur le serveur de l’attaquant sera celle du serveur d’origine.

Exemple de contournement de cloudfare via SecurityTrails

SecurityTrails est une plateforme d’intelligence de données spécialisée dans l’inventaire des actifs exposés sur internet. Pour un auditeur en cybersécurité ou un Red Teamer, c’est un outil indispensable lors de la phase de reconnaissance (Recon).

Security Trails logo

Cloudflare masque l’adresse IP du serveur en redirigeant le trafic via son réseau. Cependant, avant l’activation de Cloudflare, le site était accessible directement via une adresse IP publique. SecurityTrails conserve l’historique des enregistrements DNS, y compris ceux antérieurs à l’ajout du site à Cloudflare.

Comment procéder ?

  1. Accédez à SecurityTrails et créez un compte si nécessaire.
Allez sur SecurityTrails et creez son compte
tableau de bord de SecurityTrails

Au sein du tableau de bord de SecurityTrails recherchez le domaine ciblé dans la barre de recherche.

prenons le cas du domaine www.g2.com

Consultez l’onglet Données historiques pour voir les anciennes adresses IP associées au domaine.

Historical Data Button
resultat des historiques sur les noms de domaines

Comme vous pouvez le constater, nous disposons de l’historique DNS de notre domaine, actuellement hébergé sur Cloudflare, mais qui l’était auparavant sur Amazon.

Malheureusement, il est possible que ce site ne soit plus hébergé sur le serveur Amazon. Dans ce cas, nous devons vérifier si le site fonctionnant sur le serveur d’origine est identique à celui fonctionnant sur notre instance Cloudflare, et inclure les deux résultats (code source du frontend).

Comment tester les similitudes entre Cloudflare et le serveur d’origine ?

Comparer les en-têtes de réponse HTTP

Utilisez curl avec l’option -H pour définir l’en-tête Host et -k pour contourner la vérification du certificat SSL :

curl -Ik -H "Host: targetsite.com" https://targetsite.com # Via Cloudflare
curl -Ik -H "Host: targetsite.com" https://origin-ip-address # Directement vers le serveur d'origine suspecté
Recherchez des similitudes dans les en-têtes, tels que server, x-powered-by ou toute information d'empreinte unique.`

Récupérer le contenu de la page d’accueil

Comparer les réponses HTML brutes :

curl -ks -H "Host: targetsite.com" https://targetsite.com > cloudflare.html
curl -ks -H "Host: targetsite.com" https://origin-ip-address > origin.html
diff cloudflare.html origin.html

Si le résultat est similaire, l’adresse IP d’origine est probablement correcte.

Vérification du chargement des ressources

Vérifiez que les ressources (JS, CSS, images) sont identiques :

curl -ks -H "Host: targetsite.com" https://adresse-ip-origine | grep -Eo '(http|https)://[^"]+'

Comparez les URL des images et des scripts avec celles du site protégé par Cloudflare.

Remarque : Certains serveurs peuvent bloquer l’accès direct par adresse IP. Dans ce cas, essayez d’accéder à différents sous-domaines ou d’utiliser un navigateur web avec des en-têtes Host modifiés.

Références :

https://www.zenrows.com/blog/bypass-cloudflare

Comment prévenir le contournement de Cloudflare

1. Autoriser uniquement les adresses IP de Cloudflare

La méthode la plus efficace consiste à configurer le pare-feu de votre serveur (iptables, ufw, ou le groupe de sécurité de votre fournisseur cloud) pour n’accepter que le trafic provenant des plages d’adresses IP de Cloudflare. Tout trafic direct vers l’IP d’origine sera ainsi bloqué.

2. Authenticated Origin Pulls

Cloudflare propose une fonctionnalité appelée « Authenticated Origin Pulls ». Elle utilise des certificats TLS pour s’assurer que toute requête arrivant sur votre serveur d’origine provient bien de Cloudflare et non d’un tiers.

3. Changer l’IP d’origine après la configuration

Si vous venez de configurer Cloudflare pour un site qui était auparavant exposé publiquement, changez l’adresse IP de votre serveur. Cela rendra les enregistrements DNS historiques obsolètes.

4. Masquer les sous-domaines

Assurez-vous que tous les sous-domaines actifs sont configurés avec le nuage orange dans le panneau DNS de Cloudflare ou supprimez les enregistrements inutiles qui pourraient pointer directement vers votre infrastructure.

Conclusion

La sécurité offerte par Cloudflare n’est robuste que si le serveur d’origine reste confidentiel. En comprenant comment les attaquants cherchent à exposer l’adresse IP réelle de votre infrastructure, vous pouvez mettre en place les contrôles nécessaires pour garantir que tout votre trafic passe bien par les filtres de sécurité de Cloudflare.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *