DMZ avec pfSense et proxy inverse HAProxy

Une DMZ (zone démilitarisée) est un réseau isolé, branché sur une interface dédiée du pare-feu, qui accueille les serveurs joignables depuis Internet ; le pare-feu n'y laisse entrer que les services publiés et n'en laisse presque rien sortir vers le réseau interne. Ce chapitre met en œuvre la DMZ de Sorbier sur pfSense : architecture, serveur, services que le pare-feu rend à la DMZ, cloisonnement entre serveurs, puis publication par un proxy inverse HAProxy avec un certificat Let's Encrypt.

Pourquoi une DMZ

Un serveur publié sur Internet sera attaqué : ce n'est pas une hypothèse. La DMZ limite les conséquences de sa compromission. Si srv-web est piraté, l'attaquant se retrouve dans un réseau d'où il ne peut joindre ni les postes, ni l'annuaire, ni les partages : seulement l'API de srv-gestion, sur un port, et l'envoi de ses journaux. Le choix des zones et des flux, et la comparaison des architectures, sont expliqués dans le cours Cybersécurité des infrastructures ; ici, on construit.

La DMZ de Sorbier

• Interface : vtnet2, branchée sur le pont vmbr2 de Proxmox, lui-même relié au switch de la DMZ par le port eno3 de l'hôte. Une carte et un pont dédiés plutôt qu'un VLAN du trunk interne : une erreur de configuration du trunk ne peut pas mélanger la DMZ et l'intérieur, et la séparation se voit sur le schéma.
• Adressage : 192.168.10.224/28, passerelle 192.168.10.238 (pfSense). srv-web est en 192.168.10.225.
• Serveur : srv-web, une machine virtuelle Debian 13 qui fait tourner le site de suivi des livraisons ; sa carte est branchée sur vmbr2, sans étiquette.

Configuration réseau de srv-web (/etc/network/interfaces) :

auto ens18
iface ens18 inet static
    address 192.168.10.225/28
    gateway 192.168.10.238

Et son résolveur, dans /etc/resolv.conf : nameserver 192.168.10.238. srv-web n'est pas membre du domaine Active Directory et n'interroge pas les contrôleurs de domaine : une machine de la DMZ ne doit avoir aucune raison de parler à l'annuaire.

Ce que pfSense rend à la DMZ

Le pare-feu fournit à la DMZ les services de base, pour qu'elle n'ait besoin d'aucun serveur interne :

• le DNS : le résolveur Unbound du pare-feu écoute par défaut sur toutes les interfaces (Services > DNS Resolver, champ Network Interfaces) ; srv-web l'interroge sur 192.168.10.238 ;
• l'heure : Services > NTP, cocher l'interface DMZ dans Interface ; pfSense synchronise sa propre horloge sur des serveurs publics et la sert à la DMZ ;
• les journaux : srv-web les envoie à Wazuh par son agent, seul flux vers l'intérieur avec l'API.

Les règles de l'onglet DMZ sont au chapitre 5 ; la redirection du port 443 au chapitre 6.

Cloisonner les serveurs de la DMZ entre eux

Le jour où la DMZ accueille un deuxième serveur (le relais de messagerie, le serveur SFTP des transporteurs), ces serveurs sont dans le même réseau : ils se parlent sans passer par pfSense. Si l'un est compromis, il attaque l'autre. Trois parades :

C'est la micro-segmentation, présentée dans le cours Cybersécurité des infrastructures : on combine en général le pare-feu de l'hyperviseur et celui du serveur.

Le proxy inverse : pourquoi

Une redirection de port envoie les paquets tels quels au serveur : le pare-feu ne regarde pas ce qu'ils contiennent. Un proxy inverse (reverse proxy) reçoit lui-même la connexion du client, déchiffre le HTTPS, lit la requête, puis ouvre une seconde connexion vers le serveur interne. Il apporte :

• plusieurs sites sur une seule adresse publique et un seul port 443 : le proxy choisit le serveur selon le nom demandé (suivi.sorbier.example, transporteurs.sorbier.example) ;
• la terminaison TLS au même endroit, avec des certificats Let's Encrypt renouvelés automatiquement ;
• la répartition de charge et le contrôle de santé quand il y a plusieurs serveurs pour un même site (cours Haute disponibilité) ;
• un serveur caché : le client ne voit que le proxy ; on peut ajouter des en-têtes de sécurité, limiter les méthodes HTTP, refuser les chemins d'administration.

Sorbier publie aujourd'hui un seul site : la redirection de port suffit. Quand le portail des transporteurs ouvrira, sur un second serveur de la DMZ, il faudra publier deux sites sur la même adresse : c'est le moment de passer au proxy inverse. Sur pfSense, il s'installe en paquet : HAProxy.

Installer HAProxy et ACME

System > Package Manager > Available Packages : installe haproxy (le paquet stable ; haproxy-devel suit la branche de développement) et acme (le client du protocole ACME, celui de Let's Encrypt). Les menus apparaissent dans Services.

Le port 443 du pare-feu. HAProxy va écouter sur l'adresse publique, port 443. Or l'interface web de pfSense écoute déjà sur le port 443 de toutes les adresses du pare-feu : HAProxy ne pourrait pas démarrer. Change d'abord le port de l'interface web : System > Advanced > Admin Access, TCP port 10443, puis reconnecte-toi sur https://192.168.10.222:10443. Mets à jour la règle d'administration de l'onglet ADMIN si elle vise le port 443.

Le certificat. Services > ACME Certificates :

1. Onglet Account keys : Add, un nom, ACME Server Let's Encrypt Production ACME v2 (le serveur Staging sert aux essais, ses certificats ne sont pas reconnus), une adresse électronique de l'équipe ; Create new account key, puis Register ACME account key.
2. Onglet Certificates : Add, Name suivi-sorbier, le compte créé, une clé privée ECDSA ou RSA, et dans Domain SAN list le nom suivi.sorbier.example avec sa méthode de validation. La méthode DNS (par l'interface de programmation de l'hébergeur DNS, ou manuelle) prouve la possession du domaine sans ouvrir de port ; la méthode HTTP impose que le port 80 de l'adresse publique réponde au défi.
3. Dans Actions list, une commande qui recharge HAProxy après chaque renouvellement.
4. Issue/Renew : le certificat apparaît dans System > Cert. Manager et se renouvellera seul.

Configurer HAProxy

Services > HAProxy, trois onglets :

1. Backend : Add, nom be_suivi. Dans Server list, une ligne : nom srv-web, adresse 192.168.10.225, port 443, case de chiffrement (Encrypt (SSL)) cochée si le serveur parle HTTPS (recommandé : le trafic reste chiffré jusqu'au serveur). Health check method : HTTP, sur une page légère du site. HAProxy retire de la rotation un serveur qui ne répond plus.
2. Frontend : Add, nom fe_https. Listen address : WAN address (IPv4), port 443, case SSL Offloading cochée. Type : http / https (offloading). Default Backend : be_suivi. Dans la section du certificat (SSL Offloading), choisis le certificat suivi-sorbier. Pour un second site, une règle de contrôle d'accès (Access Control lists) du type « l'en-tête Host vaut transporteurs.sorbier.example » et une action Use Backend vers son propre backend.
3. Settings : Enable HAProxy, un nombre maximal de connexions adapté à la mémoire, Save, Apply Changes.

Il reste à remplacer la redirection de port par une règle qui autorise le trafic vers le pare-feu lui-même : Firewall > NAT > Port Forward, supprime la redirection du port 443 (sa règle associée disparaît avec elle) ; puis Firewall > Rules > WAN : Pass, TCP, source any, destination WAN address, port 443, description « HTTPS vers HAProxy ». HAProxy ouvre ensuite lui-même la connexion vers srv-web : c'est un flux émis par le pare-feu, autorisé en sortie.

Redirection de port ou proxy inverse ?

Exercices