Masquer l’IP de votre site

Masquer l’IP de votre site: méthode fiable et check‑list

But: empêcher que l’adresse IP de votre serveur d’origine soit visible/atteignable publiquement. La méthode standard est d’utiliser un proxy/CDN en frontal et de verrouiller l’origine.


Plan en 5 étapes (recommandé)

  1. Placez le site derrière un CDN/proxy
  • Services: Cloudflare, Fastly, Akamai, OVH CDN, CloudFront + ALB, etc.
  • Activez le proxy sur les enregistrements DNS de votre domaine (ex. “nuage orange” chez Cloudflare).
  • Vérifiez que les requêtes passent bien par l’IP du CDN (un “curl -I votre‑domaine” doit renvoyer des en‑têtes du CDN).
  1. Changez l’IP d’origine (fortement conseillé si l’ancienne a déjà fuité)
  • Migrez le site vers un nouveau serveur ou demandez une nouvelle IP.
  • Ne communiquez jamais ce nouvel host publiquement (utilisez un hostname dédié, ex. origin.example.com, non proxifié et non devinable).
  1. Verrouillez l’accès direct à l’origine
  • Pare‑feu: autorisez uniquement les IP des PoP du CDN, refusez tout le reste (en IPv4 et IPv6).
    • Exemple Nginx (en plus du firewall) avec Cloudflare:# Fichier listant les CIDR du CDN include /etc/nginx/snippets/cdn-ips.conf; map $remote_addr $allow_cdn { default 0; # cf. cdn-ips.conf définit des "geo" ou "map" pour chaque plage -> 1 } server { listen 80; listen 443 ssl; if ($allow_cdn = 0) { return 403; } # bloque accès direct # ... }
    • Exemple iptables (schéma):# Politique par défaut: DROP # Autoriser seulement les plages du CDN sur 80/443 iptables -A INPUT -p tcp --dport 80 -s <CIDR_CDN> -j ACCEPT iptables -A INPUT -p tcp --dport 443 -s <CIDR_CDN> -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j DROP iptables -A INPUT -p tcp --dport 443 -j DROP
  • Host header + mTLS: activez “Authenticated Origin Pulls”/“Shielding” si dispo pour s’assurer que seul le CDN parle à l’origine (certificat client).
  1. Hygiène DNS stricte
  • Ne publiez aucun A/AAAA pointant directement sur l’origine. Servez le site via CNAME/A du CDN uniquement.
  • Mettez vos sous‑domaines sensibles en privé:
    • origin.example.com: résolu seulement en interne/VPN (split‑horizon) ou protégé par ACL.
    • Évitez les fuites: dev., staging., test., direct., serveur., panel., ftp. Ne les faites pas pointer sur l’origine publique.
  • Séparez le mail: utilisez un service SMTP/MX distinct (pas le même serveur que le web).
  1. Éliminez les fuites applicatives
  • Liens/URLs absolus: dans WordPress, vérifiez “Adresse web du site (URL)” et “Adresse WordPress (URL)”; corrigez médias/sitemaps/canoniques pour éviter l’IP.
  • Envoi d’emails: si le serveur web envoie des mails directement, les en‑têtes “Received:” peuvent exposer l’IP. Utilisez un SMTP tiers (Sendgrid, Mailgun, Postmark, OVH MX Plan…).
  • FTP: n’utilisez que SFTP/SSH; évitez le FTP passif qui peut révéler IP.
  • Robots et fichiers publics: ne publiez pas volontairement l’IP dans readme, docs, ou scripts.

Tests rapides de non‑exposition

  • DNS: “dig A/AAAA example.com” ne doit pas retourner l’IP d’origine (vous verrez celle du CDN).
  • Accès direct: “curl -I http://VOTRE_IP_ORIGINE/” doit échouer (DROP) ou renvoyer 403.
  • Recherche passive: vérifiez qu’aucun sous‑domaine public ne pointe vers l’origine (outils de “passive DNS”).
  • IPv6: testez aussi l’IP v6; beaucoup de fuites viennent d’une v6 laissée ouverte.

Points d’attention importants

  • Si l’IP a déjà circulé (historique DNS, archives, scans), changez‑la. Une fois connue, elle sera testée en direct.
  • Appliquez les règles firewall aux deux piles IP (v4 et v6).
  • Certificats: les logs de transparence révèlent vos domaines, pas l’IP d’origine; c’est normal.
  • E-mails: hébergez le MTA ailleurs; configurez SPF, DKIM, DMARC pour ce prestataire.
  • Services annexes: n’exposez pas phpMyAdmin, panel d’hébergement, graphiques de monitoring sur le même hôte/port.

Alternatives et compléments

  • Reverse proxy auto‑hébergé (Nginx/HAProxy) devant l’origine, avec la même logique d’allowlist IP si vous utilisez un CDN “origin shield”.
  • Bastion/VPN: placez l’origine dans un réseau privé, accessible seulement via VPN ou tunnel depuis le CDN/edge.
  • WAF/CDN: activez cache, WAF, rate limiting et bot management; ça n’aide pas à “masquer” l’IP en soi, mais réduit l’intérêt de la cibler.