Vous utilisez Cloudflare et vous êtes quand même attaqué ? 7 voies cachées de fuite d'IP d'origine et guide de protection

Le blog est down, 20 Go de trafic facturés en un jour, arrêt pour impayé — alors que vous utilisez Cloudflare. Les logs montrent que l’attaque n’est pas passée par Cloudflare : connexions directes à l’IP du serveur d’origine. L’attaquant contourne le CDN et frappe le serveur réel : c’est le problème de fuite d’IP d’origine.

C’est fréquent. Beaucoup pensent que Cloudflare suffit, mais l’IP d’origine est déjà exposée via l’historique DNS, les en-têtes mail ou le scan de sous-domaines. Cet article couvre les voies de fuite, la détection et une protection complète.

Pourquoi l’IP d’origine fuit

Qu’est-ce qu’une fuite d’IP d’origine et quels risques

Avec un CDN comme Cloudflare, les visiteurs atteignent les nœuds Cloudflare, qui relaient vers votre serveur (origine). L’attaquant ne voit normalement que l’IP Cloudflare.

S’il obtient l’IP d’origine, le CDN ne protège plus : attaque directe, contournement du WAF et des autres défenses.

Conséquences :

• Serveur hors service : DDoS sur l’origine, panne
• Facture de trafic : facturation au volume, coût imprévu
• Vol de données : contournement du WAF si failles présentes

Selon le rapport Cloudflare T4 2024, attaque record observée de 5,6 Tbps.

Même quelques gigabits peuvent faire tomber un petit serveur.

[Image : schéma du fonctionnement du CDN]

Prompt : server behind CDN shield, user traffic flow through cloudflare nodes, simplified diagram, tech blue color scheme, professional illustration

Les 7 voies courantes de fuite d’IP d’origine

Voici les 7 voies les plus fréquentes, du risque le plus élevé au plus faible.

Voie 1 : historique DNS (risque : élevé)

La plus courante et la plus négligée.

Beaucoup pointent d’abord le domaine vers l’IP réelle, puis ajoutent Cloudflare. Les enregistrements ont été collectés par SecurityTrails, DNSdumpster, etc.

J’ai fait cette erreur : IP réelle au lancement, Cloudflare six mois après. SecurityTrails affichait encore les anciens enregistrements.

Voie 2 : en-têtes du serveur mail (risque : élevé)

Très discret.

E-mails d’inscription, mot de passe, RSS : les en-têtes contiennent l’IP d’envoi. Serveur mail maison ou envoi depuis le serveur web = fuite.

L’attaquant s’inscrit, ouvre le message original, cherche le champ Received : IP réelle visible.

La première fois que j’ai constaté cette fuite, j’étais surpris : on n’imagine pas que le mail expose l’IP.

Voie 3 : scan de sous-domaines (risque : moyen-élevé)

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Vous protégez example.com, mais mail.example.com, admin.example.com, dev.example.com ?

Souvent en direct vers l’IP d’origine. sublist3r, OneForAll : lister, ping ; un sous-domaine qui renvoie l’IP réelle suffit.

Même sur un autre hôte, si même plage C (ex. 192.168.1.x), l’attaquant peut cibler la plage.

Voie 4 : fuite dans le code source (risque : moyen)

Pages de test, debug :

• phpinfo() laissé en place
• .git accessible
• logs d’erreur verbeux
• API en dur avec IP au lieu du domaine

J’ai vu un info.php oublié indexé par un moteur de recherche : toutes les infos serveur visibles. Erreur fréquente.

Voie 5 : requêtes SSL (risque : moyen)

Certificate Transparency enregistre tous les certificats. crt.sh, Censys : historique et IP liées.

Si le certificat était sur l’IP d’origine avant Cloudflare, la trace peut rester. Ce n’est pas systématique, mais c’est une voie réelle.

Voie 6 : résolution DNS à l’étranger (risque : moyen-faible)

Certains CDN n’ont des nœuds qu’en Chine. À l’étranger, la requête DNS peut renvoyer l’IP d’origine plutôt que celle du CDN. Cloudflare est mondial, donc peu concerné ; pour un petit CDN local, attention. Test simple : résolution avec Google DNS (8.8.8.8) ou Cloudflare DNS (1.1.1.1) — l’IP renvoyée est-elle bien un nœud CDN ?

Voie 7 : scan de plage C et sites sur le même serveur (risque : faible)

Plusieurs sites sur un serveur : un site non protégé aide à localiser les autres. Recherche ip:xxx.xxx.xxx.xxx sur Bing/Google ou scan de la plage C.

[Image : infographie des 7 voies de fuite]

Prompt : 7 ways of IP leak infographic, DNS history, email headers, subdomain scan, source code leak, SSL certificate, colorful icons, flat design

Comment détecter une fuite d’IP d’origine

Voici une checklist d’auto-contrôle.

Tableau des outils de détection

Étapes de détection détaillées

Contrôle 1 : historique DNS

Sites utiles :

• SecurityTrails (securitytrails.com) — historique DNS
• DNSdumpster (dnsdumpster.com) — énumération DNS et sous-domaines
• Netcraft (sitereport.netcraft.com) — IP historiques du site

Si vous trouvez l’IP réelle d’avant Cloudflare, la fuite est probable.

Contrôle 2 : en-têtes mail

1. Créez un compte test ou demandez une réinitialisation de mot de passe
2. Ouvrez « message original » ou « afficher le message brut »
3. Cherchez Received ou X-Originating-IP
4. Comparez avec votre IP d’origine

SendGrid, Amazon SES : IP du tiers, pas de problème.

Contrôle 3 : scan de sous-domaines

# Requête dig sur les sous-domaines
dig mail.yourdomain.com
dig admin.yourdomain.com
dig api.yourdomain.com

Outils : Sublist3r, OneForAll. Ping chaque sous-domaine : IP Cloudflare ou la vôtre ?

Contrôle 4 : ping depuis plusieurs régions

• ping.pe — plusieurs nœuds mondiaux
• 17ce.com — test multi-sites (Chine)

Des IP différentes selon la région peuvent indiquer un problème. Avec Cloudflare, vous devriez voir des nœuds CF proches.

Contrôle 5 : certificats SSL

https://crt.sh/?q=yourdomain.com

Vérifiez si un certificat était lié à votre IP d’origine.

Contrôle 6 : moteurs de recherche du cyberspace

• Shodan (shodan.io)
• Censys (censys.io)
• Fofa (fofa.so)

Si le port 80 est ouvert sur l’origine, l’IP peut être indexée.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Contrôle 7 : logs serveur

# Logs Nginx en général
tail -f /var/log/nginx/access.log
# Logs Apache
tail -f /var/log/apache2/access.log

Des accès directs à l’IP d’origine hors plages Cloudflare = quelqu’un tente de contourner le CDN. Les plages officielles sont dans la documentation Cloudflare.

Protection complète

Préparation avant configuration

Préparation 1 : nouvelle IP ou nouveau serveur

Si l’IP a fuité, le plus sûr est de repartir sur une nouvelle IP.

• Nouveau serveur, migration, destruction de l’ancien
• Changement d’IP élastique (Aliyun, Tencent, souvent peu coûteux)
• Nouveau domaine (coûteux, dernier recours)

En phase de démarrage, un nouveau serveur est souvent le plus simple.

Préparation 2 : nettoyer les traces contrôlables

L’historique DNS tiers ne s’efface pas, mais :

• Supprimez phpinfo.php, info.php, etc.
• Désactivez le mode debug et les erreurs affichées
• Bloquez l’accès externe à .git (nginx)
• Pas d’IP en dur dans le code

Préparation 3 : stratégie DNS

• Domaine principal et www : Cloudflare obligatoire
• Tous les sous-domaines publics : Cloudflare (blog, api, img)
• Mail : tiers de préférence
• Admin, base de données : pas de DNS public, accès interne

Bonnes pratiques Cloudflare

Pratique 1 : CDN sur tout le site

Dans DNS Cloudflare, icône nuage par enregistrement :

• Nuage orange : proxy, IP masquée
• Nuage gris : direct vers l’IP d’origine

Tous les noms publics en orange. Nuage gris seulement pour MX, TXT, etc.

[Image : interface DNS Cloudflare]

Prompt : cloudflare DNS settings screenshot, orange cloud vs gray cloud comparison, highlight the proxy status toggle, clean interface, 16:9

Pratique 2 : messagerie tierce

• SendGrid : ~100 mails/jour gratuits
• Amazon SES : payant à l’usage, 62 000 mails/mois gratuits (compte AWS)
• Mailgun : quota gratuit, API pratique

Meilleure délivrabilité qu’un serveur maison.

Pratique 3 : pare-feu, liste blanche Cloudflare

Liste officielle :

https://www.cloudflare.com/ips/

Exemple iptables :

# ⚠️ Important : ne pas bloquer SSH
# Tester d'abord en environnement de test
# Vider les règles existantes
iptables -F
# Autoriser loopback
iptables -A INPUT -i lo -j ACCEPT
# Connexions établies
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH (adaptez le port)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Autoriser les plages Cloudflare sur 80 et 443
# Exemples IPv4 — liste complète sur le site officiel
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 173.245.48.0/20 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 103.21.244.0/22 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 103.22.200.0/22 -j ACCEPT
# ... toutes les plages CF ...
# Refuser le reste sur 80/443
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j DROP
# Sauvegarder
iptables-save > /etc/iptables/rules.v4

Précautions :

1. Tester en environnement de test
2. Garder l’accès SSH (port 22 ou le vôtre)
3. Tester depuis un autre appareil (ex. téléphone)
4. Préférer le groupe de sécurité du fournisseur cloud

Après configuration, testez l’accès direct à l’IP d’origine en 4G : cela doit échouer.

[Image : schéma pare-feu]

Prompt : firewall protection layers diagram, cloudflare IP whitelist, block non-cloudflare traffic, security shield icon, professional tech illustration

Pratique 4 : désactiver la réponse au ping

# Désactiver ping
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
# Permanent dans /etc/sysctl.conf
net.ipv4.icmp_echo_ignore_all = 1
# Puis
sysctl -p

Le scan de plage ne recevra pas de réponse ICMP.

Mesures avancées

Mesure 1 : Cloudflare Tunnel (ex-Argo Tunnel)

cloudflared se connecte à Cloudflare ; pas besoin d’ouvrir 80/443 ; trafic via tunnel.

# Installer cloudflared
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
dpkg -i cloudflared-linux-amd64.deb
# Connexion Cloudflare
cloudflared tunnel login
# Créer le tunnel
cloudflared tunnel create mytunnel
# Route DNS
cloudflared tunnel route dns mytunnel yourdomain.com
# Lancer
cloudflared tunnel run mytunnel

Très efficace pour masquer l’IP ; configuration un peu plus longue ; fonctions avancées parfois payantes.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Mesure 2 : rotation périodique de l’IP

Tous les 3 à 6 mois pour les sites à haut risque : même si l’ancienne IP a fuité, l’attaquant frappe dans le vide. Coût à évaluer selon l’importance du site.

Mesure 3 : surveillance du trafic anormal

# Exemple de script simple
tail -f /var/log/nginx/access.log | grep -v -E "(173\.245\.|103\.21\.|103\.22\.)" | while read line
do
    echo "Alert: accès hors IP CF! $line"
    # Alerte mail ou SMS
done

Mesure 4 : pas d’IP en dur dans le code

// Mauvais exemple
fetch('http://123.456.78.90/api/data')
// Bon exemple
fetch('https://api.yourdomain.com/data')

Déjà fuité : que faire

Étape corrective 1 : changer l’IP immédiatement

Coût indicatif :

• Changement d’IP : souvent gratuit ou 10-20 ¥
• Nouveau VPS 1 vCPU / 2 Go : ~30-50 ¥/mois
• Migration : ~30 minutes pour un petit site

Gardez l’ancien serveur quelques jours avant suppression.

Étape corrective 2 : liste blanche pare-feu

Référez-vous à la section iptables ou au groupe de sécurité. Ne vous enfermez pas hors SSH : j’ai déjà dû passer par la console VNC du fournisseur après une mauvaise règle.

Étape corrective 3 : Cloudflare Rate Limiting

Limite par IP. Pro (~20 $/mois) : règles fines, ex. 10 requêtes / 10 secondes, Challenge ou blocage.

Étape corrective 4 : IP anti-DDoS dédiée

Aliyun, Tencent, Baidu : facturation par bande passante ou par attaque. Pertinent pour e-commerce ou jeux ; souvent cher pour un blog personnel.

Étape corrective 5 : surveillance et réaction

• Alertes Cloudflare
• Zabbix, Prometheus
• Bascule DNS vers serveur de secours si attaque

La rapidité compte : des heures de retard peuvent coûter cher en trafic facturé.

Conclusion

La fuite d’IP d’origine est un problème systémique : DNS, mail, sous-domaines, SSL — les voies sont nombreuses.

Mesures clés :

1. CDN global — tous les noms publics en nuage orange
2. Liste blanche pare-feu — dernière ligne de défense
3. Mail externalisé — SendGrid, SES, etc.
4. Auto-contrôle régulier — outils de cet article

Pas encore sur Cloudflare ? Partez sur de bonnes bases. Déjà en place ? Dix minutes de vérification.

Si l’IP a fuité : nouvelle IP, pare-feu, surveillance — le risque reste maîtrisable.

La protection est continue : chaque nouveau sous-domaine en proxy, chaque changement de config sans exposer l’IP, contrôles réguliers.

Commencez par SecurityTrails sur votre domaine. En cas de problème, suivez les étapes de cet article — mieux vaut prévenir qu’un serveur down et une facture de trafic surprise.