Infrastructure Web & Mail Sécurisée

AKA Déployer une stack web et transactionnelle propre avec Cloudflare, Mailtrap & Nginx Multi-Vhosts

Quand on héberge plusieurs services web sur un même serveur, concilier isolation des hôtes virtuels (multi-vhosts), étanchéité du serveur d'origine derrière un CDN et délivrabilité des e-mails transactionnels devient vite un casse-tête si l'on ne pose pas un cadre strict dès le départ.

L'objectif ici n'est pas de faire du bricolage, mais d'établir un standard reproductible et durci :

• L'anonymisation stricte de l'IP d'origine (protection contre les attaques directes, les scans automatisés et l'indexation type Shodan/Censys/etc.).
• La sécurisation des flux web via le reverse proxy Cloudflare (WAF, TLS Strict, Authenticated Origin Pulls).
• Une délivrabilité mail optimale via Mailtrap (SMTP Relay sortant) et Cloudflare Email Routing (entrant), sans fuite d'IP dans les en-têtes.

Pour préserver l'anonymat de l'infrastructure d'origine sur un serveur multi-vhosts :

• Fuite par certificat public (CT Logs) : Les certificats Let's Encrypt/ZeroSSL émis publiquement sont indexés dans les journaux de transparence (`crt.sh`, Censys). Parade : Utiliser un certificat interne *Cloudflare Origin CA* (non publié).
• Fuite par scan direct (Sans SNI) : Les moteurs de scan (Shodan, Censys) sondent l'IP directe sur le port 443. Si Nginx répond avec un vhost par défaut contenant le certificat du domaine, l'IP est liée au domaine. Parade : Configurer un `default_server` “Trou Noir” (retourne `444`).
• Fuite par domaine voisin (Vhost non proxifié) : Un sous-domaine en *DNS Only* (nuage gris) sur la même machine compromet l'ensemble des vhosts. Parade : Strictement aucun enregistrement direct vers l'IP publique.

Les enregistrements suivants doivent être déployés dans la zone DNS Cloudflare du domaine :

Ce vhost intercepte toutes les requêtes directes par IP ou utilisant un nom de domaine inconnu/non configuré. Il présente un certificat auto-signé générique et coupe la connexion TCP sans émettre de réponse HTTP.

Génération du certificat factice :

user@host:~/ $ openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout /etc/ssl/private/dummy.key \
  -out /etc/ssl/certs/dummy.crt \
  -subj "/CN=null"

Configuration du vhost par défaut :

# /etc/nginx/conf.d/00-default-blackhole.conf
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
 
    server_name _;
 
    ssl_certificate /etc/ssl/certs/dummy.crt;
    ssl_certificate_key /etc/ssl/private/dummy.key;
 
    # Coupe immédiatement la connexion TCP
    return 444;
}

Pour que les logs et l'application reçoivent la véritable IP du client et non celle des relais Cloudflare :

# /etc/nginx/conf.d/cloudflare-realip.conf
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
 
# IPv6
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;
 
real_ip_header CF-Connecting-IP;

Télécharger le certificat CA public Cloudflare pour Authenticated Origin Pulls :

user@host:~/ $ curl -s https://developers.cloudflare.com/ssl/static/authenticated_origin_pull_ca.pem -o /etc/ssl/certs/cloudflare-origin-pull.crt

Configuration du Vhost sécurisé :

# /etc/nginx/sites-available/app.domain.tld.conf
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
 
    server_name domain.tld www.domain.tld;
 
    # Certificat Cloudflare Origin CA (valide 15 ans, non listé dans les CT logs)
    ssl_certificate /etc/ssl/certs/cloudflare_origin.crt;
    ssl_certificate_key /etc/ssl/private/cloudflare_origin.key;
 
    # Authenticated Origin Pulls (mTLS) : Rejette tout client qui n'est pas Cloudflare
    ssl_client_certificate /etc/ssl/certs/cloudflare-origin-pull.crt;
    ssl_verify_client on;
 
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
 
    location / {
        proxy_pass http://127.0.0.1:8080; # Ou socket PHP-FPM / conteneur applicatif
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Pour router les notifications systèmes et applicatives sans divulguer l'infrastructure :

• Hôte SMTP : `live.smtp.mailtrap.io`
• Port : `587` (STARTTLS) ou `465` (SSL/TLS)
• Authentification : `PLAIN` ou `LOGIN`
• Username : `api` ou token d'authentification Mailtrap
• Expéditeur visible (From) : `notifications@domain.tld` (doit correspondre au domaine validé)
• Adresse de retour (Reply-To) : `contact@domain.tld` (redirigé automatiquement par Cloudflare Email Routing vers votre boîte de réception finale)

• Nettoyage des en-têtes : Veiller à ce que l'application n'injecte pas d'en-tête interne personnalisé révélant des topologies privées (ex: `X-Originating-IP` ou hostname local).
• Flux sortant HTTP (cURL/Webhooks) : Si l'application doit effectuer des requêtes sortantes vers des serveurs tiers, utiliser un proxy sortant dédié pour masquer l'IP réelle de la machine hôte.

# Vérifier l'inclusion SPF
user@host:~/somedir $ dig TXT domain.tld +short

# Vérifier la résolution des clés DKIM Mailtrap
user@host:~/somedir $ dig CNAME rwmt1._domainkey.domain.tld +short
user@host:~/somedir $ dig CNAME rwmt2._domainkey.domain.tld +short

# Vérifier la politique DMARC
user@host:~/somedir $ dig TXT _dmarc.domain.tld +short

Exécuter un test depuis une machine externe vers l'IP publique directe :

# 1. Test direct par IP (Doit être fermé ou retourner HTTP 444 sans certificat exposé)
user@host:~/somedir $ curl -k -v https://<IP_PUBLIQUE_SERVEUR>/

# 2. Test avec en-tête Host forgé (Doit échouer car le mTLS Cloudflare rejette la connexion)
user@host:~/somedir $ curl -k -v -H "Host: domain.tld" https://<IP_PUBLIQUE_SERVEUR>/

*Résultat attendu :* La connexion TLS échoue immédiatement (rejet `ssl_verify_client`) ou retourne un statut vide `444`.