Cloudflare devant un site piraté : ce que ça masque, ce que ça cache
Cloudflare devant un site piraté masque l'IP d'origine — parfois à l'attaquant, parfois à vos journaux. Passez en développement pour voir ce que l'origine sert vraiment, videz le cache après nettoyage, relisez Workers et Page Rules. Orange cloud n'est pas un constat de propreté. Ne grisez pas le nuage le soir J : vous exposez l'IP. Mode développement plus purge suffisent presque toujours.
Les IP réelles, parfois l'attaquant, parfois vos journaux. Passez en développement pour voir l'origine, videz le cache après nettoyage, vérifiez les workers et les pages rules.
Ce que le proxy masque, ce qu'il cache
Le proxy (nuage orange) termine TLS chez Cloudflare et parle à votre origine. Le public ne voit pas l'IP de l'hébergeur. Utile contre certains scans directs. Inutile contre un FTP déjà ouvert, un voisin de compte, un Worker malveillant. WAF après piratage : le filtre. Ici : le proxy et ses recoins.
Il « cache » aussi vos access.log d'origine : beaucoup d'IP Cloudflare, vrai client dans un header si vous l'avez configuré. Pendant l'incident, ça brouille. Mode développement + lecture des logs Cloudflare (s'ils existent) + logs origine.
Il peut cacher le malware aux visiteurs via le cache, ou le leur resservir après que vous ayez nettoyé l'origine. Les deux arrivent. D'où le mode développement plus une purge globale, pas une URL.
Mode développement : voir l'origine
Development mode (ou bypass cache sur l'URL) : vous voyez ce que PHP sert maintenant. Testez home, une intérieure, checkout, l'URL de phishing. Comparez à la version cachée (navigation privée sans dev).
Ne désactivez pas le proxy (gris) d'un coup « pour simplifier » : vous exposez l'IP, les scans directs reprennent, le DNS met du temps à revenir. Sauf besoin précis (certificat origine, debug dur), restez orange + dev.
Inspection Search Console : Google peut encore voir une version cachée. Purgez, attendez, réinspectez. Tests.
Cache HTML sale : le classique
Purge Everything, pas une URL. Page Rules qui cachent tout le site en HTML : relisez-les. Cache objet côté origine en plus. Cache Redis.
Hostinger, IONOS, plugins : triple cache. Hostinger.
Un réexamen Safe Browsing avec du HTML sale encore en edge = refus. Blacklist.
- Purge globale.
- Règles de cache HTML.
- Test 4G privée après 5 minutes.
Workers, Page Rules, Redirects, Snippets
Un Worker peut réécrire le HTML, rediriger, injecter un JS. Compte Cloudflare forcé = incident sans FTP. Listez Workers, Routes, Redirects, Transform Rules, Custom errors, Snippets. Désactivez ce que vous ne reconnaissez pas, après capture.
C'est le cousin du script tiers, hébergé chez vous côté edge.
Pages (hébergement statique Cloudflare) : autre origine possible, à inventorer si le DNS y pointe encore.
Journaux : IP Cloudflare vs vraie source
Access.log origine remplis d'IP CF : restaurez le vrai client (module hébergeur / headers) pour la suite, pas pour « pister un attaquant » le soir J. Pour dater une entrée, les logs CF (si plan) ou les logs FTP du panel aident plus.
Lire les logs hébergeur. Ticket : demandez FTP logs, pas seulement HTTP.
WAF events CF : bruit de scans, rarement LA backdoor déjà posée.
DNS, SSL, et l'IP réelle exposée trop tôt
Vérifiez les records chez CF comme chez Gandi : un CNAME ou un A gris vers un tiers est un détournement.
Full (strict) vs flexible : un HTTP encore ouvert à l'origine peut servir une vieille version. HTTP ouvert.
Après incident, l'IP d'origine fuitée (historique, e-mail, scan) reste attaquable en direct si le vhost répond. Durcissez l'origine (restriction aux IP CF) à froid, pas en cassant le site le soir J.
WAF déjà là : ne pas tout casser
Ne passez pas Under Attack le vendredi 19 h sur une boutique : vous tuez le checkout. Mode essentiel, dev, purge. Les règles custom illisibles : exportez, puis simplifiez à froid.
Un WAF ne retire pas une backdoor. Firewall vs plugin.
Compte CF : 2FA, users, clés API. Moindre privilège.
Après nettoyage : purge, tests, trente jours
Purge, fin du mode dev, tests visiteurs, inspection GSC. Tests.
Si l'hébergeur a suspendu, le proxy ne rouvre rien. Constat. OVH, guide.
Trente jours : un Worker peut réapparaître si le compte CF n'était pas refermé. Garantie. Créer un compte. Le proxy n'est qu'une couche : origine + edge + DNS.
Ne grisez pas le nuage « pour simplifier » le soir J : vous exposez l'IP et vous cassez le DNS le temps de la propagation. Mode dev + purge suffisent presque toujours.
Compte Cloudflare forcé : l'incident sans FTP
Users CF, clés API, Workers, Redirects, DNS A/CNAME. Si le mot de passe Cloudflare était le même que le panel hébergeur, les deux sont ouverts. 2FA CF après revue des users, nominatif. Moindre privilège. Gandi : vérifiez LiveDNS ET CF, pas l'un des deux.
Un script injecté en edge n'apparaît pas dans Wordfence. Inventaire réseau navigateur + tableau CF. Scripts tiers. Under Attack un vendredi sur une boutique : vous tuez le checkout. Évitez.
Hébergeur suspendu : le proxy ne rouvre rien. Constat origine. Guide. Scan distant encore sale : cache edge, attendez la purge, mode dev, relancez. Un réexamen Safe Browsing avec du HTML encore en edge = refus. Blacklist.