Cacher l’IP de votre serveur d’origine : proxys, CDN et fuites

Placer un CDN ou un reverse proxy devant un site absorbe le trafic et masque l'adresse du serveur, mais seulement tant que l'IP réelle reste inconnue. Les attaquants s'en prennent rarement au CDN. Ils cherchent directement l'origine. Ce guide recense les endroits où l'origine fuit et explique comment faire en sorte qu'elle refuse tout, sauf votre proxy.

Comment les origines sont découvertes

• Historique DNS : des services conservent les anciens enregistrements, si bien qu'une IP utilisée avant l'ajout du CDN reste répertoriée.
• Sous-domaines : des enregistrements mail., ftp. ou dev. qui pointent directement vers le serveur.
• En-têtes d'e-mail : le courrier sortant envoyé depuis le même hôte révèle son IP dans les en-têtes.
• Transparence des certificats et scans d'Internet : les scanners associent un certificat à chaque IP qui le sert.
• Comportement de l'application : les webhooks, les récupérateurs d'images et les fonctions « vérifier cette URL » se connectent vers l'extérieur depuis l'origine.

Étape 1 : repartir de zéro

Si le serveur a déjà été exposé, la solution la plus sûre est une nouvelle IP, ou un nouveau serveur avec migration. Cacher une adresse déjà publique ne fonctionne pas. Planifiez le déménagement avec le guide de migration sans interruption.

Étape 2 : n'accepter le trafic que du proxy

Autorisez les ports web uniquement depuis les plages publiées par le proxy, et rien d'autre. Avec UFW, cela donne ce qui suit, en utilisant les plages publiées par votre fournisseur.

sudo ufw default deny incoming
sudo ufw allow OpenSSH
for ip in $(cat proxy-ranges.txt); do sudo ufw allow from "$ip" to any port 443 proto tcp; done
sudo ufw enable

Actualisez la liste régulièrement, car les plages changent. Pour une garantie renforcée, utilisez l'authentification des requêtes vers l'origine (TLS mutuel) afin que Nginx rejette tout client dépourvu du certificat du proxy.

Étape 3 : séparer tout ce qui peut fuir

• Envoyez les e-mails via un autre hôte ou un relais, jamais depuis l'origine.
• Gardez les sous-domaines non web hors de l'IP d'origine.
• Faites passer les requêtes sortantes de l'application par un proxy ou un worker séparé.
• Servez un bloc serveur Nginx par défaut qui renvoie une réponse vide pour un Host inconnu, afin qu'un scan de l'IP seule ne montre rien.

server {
    listen 443 ssl default_server;
    ssl_reject_handshake on;
}

Étape 4 : tester comme un attaquant

Cherchez votre domaine dans les outils d'historique DNS, scannez votre propre plage d'IP à la recherche du certificat et examinez les en-têtes d'un message de test. Si l'un d'eux révèle l'origine, changez d'IP et recommencez.

Gardez en tête ce que cela fait et ne fait pas : cela protège la disponibilité et la confidentialité de l'adresse. Cela ne cache pas qui possède le compte. Pour cela, lisez à quel point l'hébergement anonyme l'est vraiment, et pour les attaques qui passent la couche réseau, consultez les défenses de couche 7.