Pourquoi un CDN masque l'IP d'origine (et c'est voulu)

Vous recherchez un grand site web en vous attendant à obtenir l'adresse de son serveur, et vous recevez à la place quelque chose qui appartient à Cloudflare, Fastly ou Akamai. Rien n'a mal tourné. Vous voyez exactement ce que le domaine publie, et l'adresse du vrai serveur n'a jamais figuré dans le DNS.

Ce que fait réellement un CDN

Un réseau de diffusion de contenu (CDN) est une flotte de serveurs répartis dans le monde entier. Au lieu que chaque visiteur se connecte à votre unique serveur d'origine, il se connecte au nœud du CDN le plus proche, qui sert directement le contenu en cache et va chercher à l'origine tout ce qui lui manque.

L'argument de performance est simple : un visiteur à Singapour qui se connecte à un serveur en Virginie subit environ 200 ms de latence aller-retour à chaque requête. Un nœud périphérique à Singapour réduit cela à quelques millisecondes pour le contenu en cache.

Pour que cela fonctionne, le domaine doit se résoudre vers le CDN plutôt que vers l'origine. Ce n'est pas un effet secondaire : c'est tout le mécanisme. Si le DNS renvoyait l'adresse de votre origine, les visiteurs s'y connecteraient directement et le CDN n'interviendrait jamais.

Comment reconnaître une adresse de CDN

• Le DNS inverse nomme le fournisseur. L'adresse se résout en quelque chose comme *.cloudflare.com, *.fastly.net ou *.cloudfront.net. Voyez le DNS inverse.
• La même adresse sert de nombreux sites sans rapport. Les nœuds de périphérie sont par conception une infrastructure partagée.
• Des emplacements différents obtiennent des réponses différentes. Le routage géographique vous envoie vers le nœud le plus proche, donc l'adresse varie selon l'endroit d'où vous interrogez.
• Le CNAME pointe vers un nom d'hôte du fournisseur. Un enregistrement comme www.example.com CNAME example.com.cdn.cloudflare.net est sans ambiguïté.

dig +short example.com
dig +short -x 104.21.32.47

La deuxième commande est une recherche inverse. Si elle renvoie le nom d'hôte d'un fournisseur, vous avez votre réponse.

Pourquoi l'origine est volontairement cachée

La dissimulation n'est pas un sous-produit. C'est une propriété de sécurité pour laquelle on paie.

Ce que cela implique pour un résultat de recherche

Cela change la façon dont vous devez lire la réponse, pas la justesse de la réponse.

Conséquences pratiques :

• La géolocalisation n'a aucun sens. La ville du nœud de périphérie vous indique où vous êtes routé, pas où se trouvent l'entreprise ou ses données.
• Les recherches d'IP inversées ne sont que du bruit. Des milliers de domaines sans rapport partagent légitimement une même adresse de périphérie.
• L'adresse n'est pas stable. Les CDN réattribuent constamment leurs adresses de périphérie. Ne la codez pas en dur et ne construisez pas de règles de pare-feu autour d'elle.
• La bloquer bloque tout le monde. Bloquer une adresse de périphérie partagée affecte tous les sites derrière ce nœud.

Une remarque sur la tentative de trouver l'origine malgré tout

Des articles décrivent des techniques pour démasquer les serveurs d'origine : archives DNS historiques, journaux de transparence des certificats, sous-domaines qui n'ont jamais été placés derrière le CDN, en-têtes d'e-mails envoyés par l'origine.

Toutes fonctionnent en exploitant une erreur commise par la cible, pas en déjouant le CDN. Et la raison pour laquelle quelqu'un a caché une origine est généralement qu'il est attaqué. Sonder l'infrastructure d'une autre organisation pour déjouer une protection qu'elle a délibérément déployée n'est pas un acte neutre, et dans de nombreuses juridictions, ce n'est pas non plus un acte légal.

L'outil de recherche affiche l'ensemble des enregistrements publics de n'importe quel domaine, y compris la chaîne de CNAME, ce qui est généralement le moyen le plus rapide de confirmer qu'un site est derrière un CDN.