IP d'origine derrière un CDN : comment elle fuit et comment la verrouiller

La porte d'entrée et la porte de derrière

Un CDN ou un WAF cloud se place devant le serveur et prend en charge le nom d'hôte. Pointez un scanner sur ce nom d'hôte et la requête va au edge : le TLS du edge, les en-têtes du edge, les rate limits et les règles du edge. Un rapport vert est un rapport sur le edge. L'origine, le serveur réel, n'a pas été touchée par ce scan, et tout ce qu'elle expose directement reste exposé à quiconque l'atteint par adresse plutôt que par nom.

Par où l'origine fuit

L'adresse est rarement bien cachée, parce que le domaine la publie pour d'autres usages. L'enregistrement SPF est le cas le plus courant. Une politique SPF qui utilise le mécanisme a autorise l'enregistrement A du domaine lui-même à envoyer du courrier, et cet enregistrement A est l'origine derrière le CDN. Le mécanisme mx pointe vers les hôtes de messagerie, souvent dans la même plage. Un ip4: littéral l'écrit en toutes lettres.

$ dig +short TXT example.com
"v=spf1 a mx ip4:<address> include:_spf.<mail-provider> ~all"
$ dig +short MX example.com
$ dig +short A mail.example.com ftp.example.com staging.example.com origin.example.com

Au-delà du SPF : des sous-domaines qui n'ont jamais été placés derrière le CDN (mail, ftp, un panneau de contrôle, staging, un hôte d'origine nu), qui résolvent directement vers le serveur. Les journaux de transparence des certificats, qui enregistrent chaque certificat émis pour un nom, y compris celui de l'hôte d'origine. Les bases de DNS passif, qui conservent l'enregistrement A d'avant l'introduction du CDN. Les en-têtes Received de tout e-mail envoyé par le serveur web, qui nomment l'hôte d'où il est parti. Et les fonctions applicatives qui font se connecter le serveur vers l'extérieur sur demande, comme les pingbacks et les tests de webhook, qui montrent l'adresse de connexion à quiconque reçoit l'appel.

Épinglez l'origine et scannez ce qu'un attaquant scanne

Une fois l'adresse connue, faites ignorer le CDN à vos outils. curl le fait par requête ; les scanners qui ne le peuvent pas reçoivent une entrée dans le fichier hosts. Lancez le scan depuis une machine qui n'est pas sur votre réseau ni sur aucune liste d'autorisation à laquelle l'origine fait confiance, car un scan depuis une adresse de confiance rapporte ce que voient les adresses de confiance.

# per request, no hosts-file change
$ curl --resolve example.com:443:<address> -sI https://example.com/

# for tools without --resolve
$ echo "<address>  example.com" | sudo tee -a /etc/hosts

Gardez deux colonnes dans le résultat. La colonne infrastructure : quels ports répondent, quelles versions de TLS sont acceptées, si les bannières livrent des noms de logiciels. La colonne application : des endpoints sans authentification qui énumèrent les utilisateurs, des fichiers de debug ou de logs lisibles dans la racine web, des chemins d'administration accessibles sans second facteur, des composants en retard sur leur version actuelle. Une machine durcie qui sert une application ouverte n'est pas un site sécurisé, et les deux colonnes ne se moyennent pas en un seul verdict.

Verrouillez l'origine sur le CDN

Le correctif structurel se fait à l'origine, pas au edge. Les ports web ne répondent qu'aux plages d'adresses publiées du CDN, tout le reste étant refusé par défaut. Sur un hôte firewalld :

# load the CDN's published ranges into an ipset, then allow only them on 443
$ firewall-cmd --permanent --new-ipset=cdn-v4 --type=hash:net
$ firewall-cmd --permanent --ipset=cdn-v4 --add-entries-from-file=cdn-ranges-v4.txt
$ firewall-cmd --permanent --zone=public --remove-service=http
$ firewall-cmd --permanent --zone=public --remove-service=https
$ firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source ipset="cdn-v4" port port="443" protocol="tcp" accept'
$ firewall-cmd --reload
$ firewall-cmd --ipset=cdn-v4 --get-entries

Deux détails décident si cela tient. Les plages du CDN changent, donc le fichier est rafraîchi depuis la liste publiée du CDN selon un calendrier et l'ipset rechargé avec lui. Et chaque préfixe d'une liste d'autorisation est relu après chargement : une longueur de préfixe mal tapée d'un caractère laisse entrer une grande partie d'Internet et paraît normale dans le fichier.

Les plages d'adresses sont le premier verrou, pas le seul. La plupart des CDN peuvent authentifier leurs pulls vers l'origine avec un certificat client ; exigez-le au niveau du serveur web, pour qu'une requête venant d'une plage du CDN sans ce certificat soit tout de même refusée. Supprimez ensuite les fuites qui restent : un enregistrement SPF qui ne nomme que les hôtes qui envoient du courrier, aucun sous-domaine non proxifié pointant vers l'origine et, lorsque c'est possible, une nouvelle adresse d'origine une fois le verrou en place, car l'ancienne reste dans le DNS passif indéfiniment.

Vérifiez depuis l'extérieur

Relancez le scan épinglé depuis le même point d'observation non fiable. L'origine refuse la connexion sur le port 443, et le nom d'hôte est toujours servi via le CDN. Répétez après chaque changement des plages ou de la configuration du serveur web ; faire de cela une vérification permanente plutôt qu'une opération ponctuelle est le sujet de prouvez que c'est fermé depuis l'extérieur.

$ curl --resolve example.com:443:<address> -m 5 -sI https://example.com/ ; echo "exit $?"
exit 28
# a timeout (28) or a refused connection (7) is the correct answer from the locked origin