Mise en production d'un portail B2B dans une DMZ

Contexte

L'entreprise voulait que ses partenaires passent commande en ligne. Un prestataire externe a développé l'application ; mon rôle était de la mettre en production sur l'infrastructure de l'entreprise.

Un serveur joignable depuis Internet se traite comme une zone de confiance nulle : même compromis, il ne doit offrir aucun accès direct au réseau interne. S'y ajoutaient quatre exigences : supervision active avant l'ouverture, accès du prestataire sans logiciel tiers sur le serveur, certificat reconnu par les navigateurs, et aucune coupure aux heures de bureau.

Ce que j'ai fait

1. Isoler le serveurVLAN dédié sur le switch cœur, réseau /30 qui ne laisse place qu'au pare-feu et au serveur, pfSense comme unique passerelle. La VM Windows Server reste hors domaine : compromise, elle n'aurait aucune relation de confiance Kerberos avec les contrôleurs.
2. Définir cinq fluxHTTPS entrant, sortie pour les mises à jour, agent Wazuh vers le SIEM, bureau à distance depuis deux postes d'administration et depuis le VPN.
3. Durcir le serveurPare-feu Windows actif sur les trois profils, paquets bloqués journalisés, RDP restreint aux postes d'administration, toujours en PowerShell : la console graphique désactivait la règle modifiée sans prévenir. Agent Wazuh « Active » avant l'ouverture du portail.
4. Encadrer le prestataireSon outil gratuit de prise en main coupait les sessions au bout de 30 à 45 minutes et aurait ouvert un tunnel sortant vers un service tiers. Je lui ai ouvert un accès par le VPN WireGuard, tracé dans Firezone ; profil et mot de passe transmis par deux canaux distincts.
5. Publier en HTTPSDemande de certificat RSA 2048 bits générée dans IIS, la clé privée ne quittant pas le serveur. Certificat wildcard lié au port 443 avec SNI, puis TLS 1.0 et 1.1 désactivés dans SCHANNEL après un premier audit SSL Labs.

Voir les détails techniques

Flux ouverts à la mise en ligne (août 2026)

Flux autorisé	Détail	À quoi il sert
Internet → serveur	TCP 443 uniquement, par redirection de port	Publier le portail
Serveur → Internet	Sortie en NAT	Mises à jour
Serveur → SIEM	Ports 1514-1515 de l'agent Wazuh	Remonter les événements de sécurité
Postes d'administration → serveur	RDP depuis deux postes autorisés	Administrer le serveur
VPN → serveur	RDP à travers le tunnel WireGuard	Interventions du prestataire

Cisco IOS-XE et pfSense · correction de l'adresse dupliquée

! Switch cœur : l'interface du VLAN DMZ porte-t-elle une adresse ?
SW-CORE# show ip interface brief | include Vlan<DMZ>
Vlan<DMZ>  <adresse de la passerelle DMZ>   YES manual up    up

! Avant de la retirer : rien d'autre ne dépend de cette interface
SW-CORE# show running-config interface Vlan<DMZ>
SW-CORE# show ip route | include <réseau DMZ>

! Correction : plus d'adresse, le VLAN reste actif en couche 2
SW-CORE(config)# interface Vlan<DMZ>
SW-CORE(config-if)# no ip address
SW-CORE# write memory          ! seulement après validation

# pfSense : purge des seuls états du serveur, les autres sessions restent
pfctl -k <adresse du serveur>

PowerShell · pare-feu Windows

# Pare-feu actif sur les trois profils, paquets bloqués journalisés
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True
Set-NetFirewallProfile -Profile Domain,Public,Private -LogBlocked True `
    -LogFileName "%systemroot%\system32\LogFiles\Firewall\pfirewall.log"

# RDP limité aux postes d'administration (adresses masquées)
$rdp = "Bureau à distance - Mode utilisateur (TCP entrant)"
Set-NetFirewallRule -DisplayName $rdp -RemoteAddress $postesAdmin
Enable-NetFirewallRule -DisplayName $rdp

Le pare-feu traduisait-il les adresses vers la DMZ ? Si oui, la restriction RDP par adresse n'aurait servi à rien. Le journal du pare-feu Windows a tranché : les paquets arrivaient avec l'adresse réelle du poste d'administration.

Le trafic du prestataire contournait le tunnel. Les adresses autorisées (AllowedIPs) de son profil ne couvraient que le réseau interne, pas la plage de la DMZ : le trafic partait vers sa box Internet. Plage de la DMZ ajoutée dans Firezone.

Difficulté HTTPS	Cause	Correction
Première demande de certificat refusée	Nom commun saisi « *exemple.fr », sans le point	Nouvelle demande avec « *.exemple.fr », acceptée
Le nom du portail renvoyait encore, chez certains résolveurs, vers une ancienne adresse	Un ancien enregistrement générique (*) de la zone, encore en cache	Attendre l'expiration du TTL
Note B sur SSL Labs	TLS 1.0 et 1.1 encore acceptés	Désactivation dans le registre (SCHANNEL), puis redémarrage

PowerShell · TLS 1.0 et 1.1 refusés (extrait simplifié)

foreach ($p in 'TLS 1.0', 'TLS 1.1') {
    $k = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\$p\Server"
    New-Item $k -Force | Out-Null
    New-ItemProperty -Path $k -Name 'Enabled' -Value 0 -PropertyType DWord -Force
    New-ItemProperty -Path $k -Name 'DisabledByDefault' -Value 1 -PropertyType DWord -Force
}
# SCHANNEL ne relit ces clés qu'au redémarrage

Le serveur, installé en édition d'évaluation (180 jours), a été converti en édition Standard avec DISM, sans réinstallation, puis vérifié avec slmgr.vbs /dli.

L'incident

Le diagnostic complet, étape par étape, dans un article →

Résultats

Sept tests menés en production, tous concluants : TCP vers un DNS public, vers le dépôt et vers le manager Wazuh ; passerelle à moins de 1 ms sans perte ; RDP accepté depuis un poste autorisé et refusé depuis un autre ; portail joignable en HTTPS depuis un réseau mobile 5G, certificat reconnu.

Au second audit SSL Labs, les quatre critères sont au vert : le serveur ne négocie plus qu'en TLS 1.3, avec TLS 1.2 en repli. Ce projet prolonge la DMZ pfSense montée en laboratoire pendant mon BTS, cette fois avec un service réel, et s'appuie sur le switch cœur migré en juillet.

Ce que j'améliorerais

• Sur une prochaine DMZ, je doublerais chaque filtrage réseau d'un filtrage sur le serveur lui-même, y compris pour les accès qui arrivent par le VPN : chaque couche doit filtrer sans dépendre d'une autre.
• Pour un prestataire, je prévoirais dès le départ des droits par utilisateur côté serveur VPN et une authentification à deux facteurs : les adresses autorisées d'un client WireGuard règlent le routage, pas l'accès.
• Avant de configurer une passerelle, vérifier qu'aucun équipement du segment ne porte déjà son adresse (table ARP, configuration du switch cœur) : ce contrôle aurait évité plusieurs semaines de blocage.

Compétences

• Conception de DMZ
• pfSense et filtrage des flux
• Diagnostic ARP et états du pare-feu
• Windows Server et IIS
• Certificats et durcissement TLS
• Encadrement d'un prestataire

Pour aller plus loin

• Le ping passe, mais aucune connexion TCP ne sort : Un serveur en DMZ qui répond au ping mais n'ouvre aucune connexion TCP, une table d'états pfSense qui se contredit, et une adresse de passerelle portée par deux équipements.