TP – Un pare-feu à trois zones et un serveur web en DMZ

BTS SIO SISR 1re année – Bloc 2 – S15 – binôme : un tape, l'autre lit ; on échange les rôles à chaque partie

Note

But. L'entreprise SimIO veut publier son site web sans exposer son réseau interne. Tu construis un pare-feu Linux à trois zones (interne, DMZ, externe), tu y mets un serveur web en DMZ, tu publies ce serveur vers l'extérieur par une redirection de port, puis tu prouves par des tests et par une capture de trames que les règles font ce que tu crois.

Durée : 3 h (parties A à F), plus le bilan. Prérequis : cours S15 lu.

Note

Comment ce TP fonctionne. Avant de manipuler, tu écris ce que tu anticipes (« J'anticipe »). Puis tu testes et tu notes ce que tu constates. Les commandes sont données quand on ne peut pas les deviner ; ton travail est de comprendre ce qu'elles font (« Je comprends »). Un bilan de compétences clôt la séance.

Binôme : ____________ / ____________

Warning

Environnement réel. Ce TP se fait sur trois ou quatre machines virtuelles Debian, pas dans un simulateur : c'est ce qui lui permet d'alimenter une fiche de réalisation. Les identifiants de TP (utilisateur tech, mot de passe commun donné par l'enseignant) sont des identifiants de laboratoire, communs à la classe : ne les reprends pas dans une réalisation présentée à l'épreuve.

Contraintes

Les adresses ci-dessous sont imposées ; l'adresse 203.0.113.0/24 est une plage réservée à la documentation : elle n'est pas routée sur Internet, ce qui rend le TP sans risque.
La politique par défaut du pare-feu est drop : tout flux non prévu dans la matrice reste fermé.
Chaque règle écrite est justifiée par une ligne de la matrice des flux.
Les captures d'écran sont datées (heure visible).

Le réseau à construire

Machine	Rôle	Interface (VirtualBox)	Adresse
FW	Pare-feu et routeur (Debian, 3 cartes)	carte 1 : réseau interne `wan`	`203.0.113.1/24`
		carte 2 : réseau interne `lan`	`192.168.10.1/24`
		carte 3 : réseau interne `dmz`	`192.168.20.1/24`
EXT	Poste « Internet »	réseau interne `wan`	`203.0.113.10/24`, passerelle `203.0.113.1`
PC-LAN	Poste interne	réseau interne `lan`	`192.168.10.10/24`, passerelle `192.168.10.1`
SRV-DMZ	Serveur web (Apache)	réseau interne `dmz`	`192.168.20.10/24`, passerelle `192.168.20.1`

Tip

Trois machines Debian peuvent partir d'un même clone lié : tu gagnes du temps. Le nom des interfaces (enp0s3, enp0s8, enp0s9…) dépend de la VM : relève-le avec ip -br link et adapte les règles de ce TP à tes noms.

Partie A – Préparer le réseau (≈ 30 min)

But : quatre machines qui se voient chacune dans leur réseau, et un pare-feu qui route.

Préparation (une fois, avec Internet). Les réseaux internes de VirtualBox n'ont pas d'accès à Internet : installe d'abord les paquets, avec la carte de chaque VM en NAT : sudo apt update && sudo apt install -y tcpdump curl sur toutes les machines, apache2 sur SRV-DMZ et sur EXT, nftables sur FW. (Ou utilise les VM préparées par l'enseignant.)
Dans VirtualBox, règle ensuite les cartes réseau de chaque VM en réseau interne avec le nom du tableau (wan, lan, dmz).
Sur chaque machine, attribue l'adresse du tableau. Exemple sur FW (adapte les noms d'interface) :

sudo ip addr add 203.0.113.1/24 dev enp0s3
sudo ip addr add 192.168.10.1/24 dev enp0s8
sudo ip addr add 192.168.20.1/24 dev enp0s9
sudo ip link set enp0s3 up; sudo ip link set enp0s8 up; sudo ip link set enp0s9 up

Sur les autres machines : une seule adresse, et la route par défaut vers le pare-feu (sudo ip route add default via 192.168.10.1 sur PC-LAN, par exemple). 3. Sur FW, active le routage :

sudo sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/99-forward.conf

J'anticipe. Sans aucune règle de pare-feu, PC-LAN pourra-t-il joindre SRV-DMZ ? Et EXT pourra-t-il joindre PC-LAN ? ______________________

Éléments de réponse

Oui aux deux : FW est un routeur et, sans règle, il transmet tout. EXT peut joindre PC-LAN si EXT connaît une route vers 192.168.10.0/24 (par exemple sudo ip route add 192.168.0.0/16 via 203.0.113.1). Ce que le TP va fermer, c'est précisément ce que le routage laisse ouvert par défaut.

Point de contrôle : depuis PC-LAN, ping 192.168.20.10 répond. Depuis SRV-DMZ, ping 192.168.10.10 répond aussi (c'est le problème à corriger). Recopie le résultat : ______________________

Je comprends. Pourquoi la ligne net.ipv4.ip_forward=1 est-elle écrite dans un fichier de /etc/sysctl.d/ en plus de la commande sysctl -w ? ______________________

Éléments de réponse

sysctl -w modifie le réglage du noyau pour la session en cours : il disparaît au redémarrage. Le fichier dans /etc/sysctl.d/ le rend permanent.

Partie B – Installer le serveur web de la DMZ (≈ 15 min)

But : un service à publier.

Sur SRV-DMZ, Apache est installé (préparation) : vérifie systemctl status apache2.
Personnalise la page : echo "<h1>SimIO – serveur web en DMZ</h1>" | sudo tee /var/www/html/index.html.
Vérifie qu'Apache écoute : sudo ss -tlnp | grep :80.
Depuis PC-LAN : curl http://192.168.20.10.

Point de contrôle : curl affiche la page. Recopie la ligne obtenue : ______________________

Partie C – La politique par défaut et la matrice (≈ 20 min)

But : écrire sur papier ce que le pare-feu devra faire, avant de taper une règle.

Complète la matrice des flux de SimIO d'après le cahier des charges :

les postes internes accèdent au web (80, 443) et au DNS (53) d'Internet ;
les postes internes administrent le serveur de la DMZ en SSH (22) et consultent son site (80) ;
Internet accède au site web uniquement, sur le port 8080 du pare-feu (redirigé vers le port 80 du serveur) ;
la DMZ n'a aucun accès au LAN ;
l'administration SSH du pare-feu n'est possible que depuis le LAN.

Source ↓ / Destination →	FW	LAN	DMZ	WAN
LAN
DMZ
WAN

J'anticipe. Quelle sera la politique par défaut des chaînes input et forward ? Quelle est la conséquence si on oublie d'autoriser les réponses (established) ? ______________________

Éléments de réponse

Politique drop partout. Sans la règle ct state established,related accept, le pare-feu laisserait passer la demande (par exemple vers le web) mais jetterait la réponse : rien ne fonctionnerait, même pour les flux autorisés.

Partie D – Écrire le jeu de règles nftables (≈ 45 min)

But : appliquer la matrice avec nftables.

Sur FW, nftables est installé (préparation) : vérifie nft --version.
Écris /etc/nftables.conf (avec sudo nano) :

#!/usr/sbin/nft -f
flush ruleset

table inet filtre {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    ct state invalid drop
    iif "lo" accept
    icmp type echo-request accept
    iifname "enp0s8" tcp dport 22 accept
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    ct state invalid drop
    # LAN vers Internet : web et DNS
    iifname "enp0s8" oifname "enp0s3" tcp dport { 80, 443 } accept
    iifname "enp0s8" oifname "enp0s3" udp dport 53 accept
    # LAN vers DMZ : web et administration
    iifname "enp0s8" oifname "enp0s9" tcp dport { 22, 80 } accept
    # Internet vers DMZ : uniquement le web redirigé
    iifname "enp0s3" oifname "enp0s9" ip daddr 192.168.20.10 tcp dport 80 ct status dnat accept
    # DMZ vers LAN : rien (politique par défaut)
  }
}

table ip nat {
  chain prerouting {
    type nat hook prerouting priority -100;
    iifname "enp0s3" tcp dport 8080 dnat to 192.168.20.10:80
  }
  chain postrouting {
    type nat hook postrouting priority 100;
    oifname "enp0s3" masquerade
  }
}

Vérifie la syntaxe avant d'appliquer : sudo nft -c -f /etc/nftables.conf (aucune sortie = pas d'erreur).
Applique : sudo nft -f /etc/nftables.conf, puis rends-le permanent : sudo systemctl enable --now nftables.
Relis ce qui est chargé : sudo nft list ruleset.

Warning

Ne te coupe pas l'accès. Si tu administres FW par SSH depuis le LAN, la règle input du port 22 doit être présente avant d'appliquer la politique drop. Garde une console VirtualBox ouverte sur FW.

Je comprends. Explique, avec tes mots, chacune de ces lignes :

Ligne	Ce qu'elle fait
`ct status dnat accept`	______________________
`policy drop` dans `forward`	______________________
`masquerade` dans `postrouting`	______________________
`dnat to 192.168.20.10:80`	______________________

Éléments de réponse

ct status dnat accept : n'accepte que les paquets qui ont été redirigés par la règle de NAT destination. Un paquet qui viendrait d'Internet vers le port 80 sans passer par la redirection serait refusé.
policy drop dans forward : tout ce qui traverse le pare-feu et n'est pas explicitement autorisé est jeté.
masquerade : remplace l'adresse source des paquets sortant par la WAN par l'adresse du pare-feu ; les réponses reviennent au pare-feu qui les renvoie à la bonne machine.
dnat to 192.168.20.10:80 : réécrit la destination (adresse et port) : l'extérieur parle au port 8080 du pare-feu, le serveur reçoit sur son port 80.

Partie E – Prouver : tests et captures (≈ 45 min)

But : vérifier chaque ligne de la matrice, y compris les refus.

J'anticipe. Remplis la colonne « J'anticipe » (autorisé ou refusé), puis teste et remplis « Je constate ».

N°	Test	Commande
1	PC-LAN → web d'Internet (EXT)	`curl http://203.0.113.10` (Apache installé sur EXT pour le test)
2	PC-LAN → SRV-DMZ en SSH	`ssh tech@192.168.20.10`
3	PC-LAN → SRV-DMZ web	`curl http://192.168.20.10`
4	EXT → site publié	`curl http://203.0.113.1:8080`
5	EXT → SRV-DMZ directement	`curl --max-time 5 http://192.168.20.10`
6	EXT → PC-LAN	`ping -c 2 192.168.10.10`
7	SRV-DMZ → PC-LAN	`ping -c 2 192.168.10.10`
8	SRV-DMZ → PC-LAN SSH	`ssh tech@192.168.10.10`
9	EXT → SSH du pare-feu	`ssh tech@203.0.113.1`

Note

Pour que EXT puisse joindre 203.0.113.1, EXT est dans le même réseau wan. Pour les tests 5 et 6, EXT doit connaître une route vers les réseaux privés (sudo ip route add 192.168.0.0/16 via 203.0.113.1) : c'est justement le pare-feu qui doit refuser, pas l'absence de route.

Éléments de réponse

1 autorisé (et sur EXT, l'adresse source vue est 203.0.113.1) ; 2 autorisé ; 3 autorisé ; 4 autorisé (redirection) ; 5 refusé (délai dépassé) ; 6 refusé ; 7 refusé ; 8 refusé ; 9 refusé.

Capturer la preuve

Sur EXT, lance une capture : sudo tcpdump -i enp0s3 -n tcp port 80.
Depuis PC-LAN, refais le test 1 : repère l'adresse source vue par EXT.
Sur FW, capture côté DMZ : sudo tcpdump -i enp0s9 -n tcp port 80, puis refais le test 4 depuis EXT : repère l'adresse de destination vue par le serveur.
Refais le test 7 en observant tcpdump sur FW côté LAN (-i enp0s8 -n icmp) : le paquet arrive-t-il sur le LAN ?

Je comprends. Que prouvent ces trois captures ? ______________________

Éléments de réponse

L'adresse source vue par EXT est celle du pare-feu (203.0.113.1) et non celle de PC-LAN : le masquerade fonctionne. 2. Le serveur reçoit une connexion dont la destination est 192.168.20.10:80, alors que EXT visait 203.0.113.1:8080 : le dnat fonctionne. 3. Aucun paquet n'apparaît sur le LAN : le pare-feu a jeté la demande avant qu'elle ne sorte côté LAN : la DMZ est bien isolée.

Point de contrôle : colle ici les trois captures datées (ou leur texte).

Partie F – Un accès SFTP restreint pour un prestataire (≈ 30 min)

But : un prestataire dépose des fichiers sur SRV-DMZ, sans accès à la machine et sans pouvoir sortir de son dossier.

Sur SRV-DMZ : crée le groupe et l'utilisateur.

sudo groupadd sftpusers
sudo useradd -g sftpusers -d /depot -s /usr/sbin/nologin presta
echo "presta:MotDePasseTP" | sudo chpasswd     # identifiant de laboratoire

Prépare le dossier : le dossier racine de la cage doit appartenir à root et ne pas être modifiable par d'autres, le dossier de dépôt à l'utilisateur.

sudo mkdir -p /srv/sftp/presta/depot
sudo chown root:root /srv/sftp /srv/sftp/presta
sudo chmod 755 /srv/sftp /srv/sftp/presta
sudo chown presta:sftpusers /srv/sftp/presta/depot

À la fin de /etc/ssh/sshd_config, ajoute :

Match Group sftpusers
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Vérifie et recharge : sudo sshd -t && sudo systemctl reload ssh.
Depuis PC-LAN : sftp presta@192.168.20.10, puis pwd, ls, put fichier.txt depot/, cd ...
Essaie ssh presta@192.168.20.10 : que se passe-t-il ?

J'anticipe. Pourquoi le dossier /srv/sftp/presta doit-il appartenir à root ? Que fait ForceCommand internal-sftp ? ______________________

Éléments de réponse

sshd refuse une cage dont la racine est modifiable par l'utilisateur (il pourrait la détourner pour s'échapper). ForceCommand internal-sftp impose le sous-système SFTP : même avec un mot de passe valide, le prestataire n'obtient jamais de terminal.

Point de contrôle : le dépôt fonctionne, cd .. reste dans la cage, ssh est refusé. Recopie les messages : ______________________

Pour aller plus loin

Journaliser les refus : ajoute une règle log prefix "FW-DROP " counter drop à la fin de la chaîne forward, puis lis journalctl -k | grep FW-DROP.
Version routeur Cisco : écris la même séparation LAN/DMZ avec des ACL étendues dans le simulateur réseau ; compare avec un pare-feu à état.
Nettoyer les règles : chaque règle sans compteur incrémenté pendant les tests est-elle utile ?

Retour en entreprise (si ta situation le permet)

Observer : demande à ton tuteur quel pare-feu protège l'entreprise, combien de zones, où est la DMZ (si elle existe).
Documenter : compare la matrice de ton entreprise (ou son principe) à celle de ce TP.
Réaliser : seulement avec l'accord de ton tuteur, relève la liste des règles d'un pare-feu existant (anonymisée).

Rendu

Compte rendu PDF, nommé RENDU-B2-S15-NOM.pdf, contenant : la matrice des flux complétée, le fichier nftables.conf commenté, le tableau de tests avec « J'anticipe » et « Je constate », les captures datées, la démonstration SFTP et tes réponses aux questions « Je comprends ».

Bilan de la séance

Remplis ce bilan seul, honnêtement : il sert à décider ce qu'il faut reprendre. Niveau : Non maîtrisé, Maîtrise partielle, Bonne maîtrise ou Excellente maîtrise (le vocabulaire des grilles nationales d'évaluation) ; Non évalué si tu n'as pas travaillé la compétence aujourd'hui.

Compétence du référentiel	Ce que j'ai fait dans cette séance	Niveau
B2.1 – Concevoir une solution d'infrastructure réseau
B2.2 – Installer, tester et déployer une solution d'infrastructure réseau
B2.3 – Exploiter, dépanner et superviser une solution d'infrastructure réseau
B3.3 – Sécuriser les équipements et les usages des utilisateurs
B3.5A – Assurer la cybersécurité d'une infrastructure réseau, d'un système, d'un service

Note

Les codes sont ceux du référentiel (l'arrêté numérote des activités : les codes « B… » sont un usage courant).

Je sais faire, sans aide :

Expliquer le rôle d'un pare-feu et la différence entre filtrage sans état et avec état ;
Concevoir un réseau à trois zones (interne, DMZ, externe) ;
Écrire des règles de filtrage avec nftables et les tester ;
Configurer un NAT (partage d'accès et redirection de port) ;
Déployer un accès SFTP restreint à un dossier ;
Vérifier avec Wireshark qu'une règle fait ce qu'on croit.

Ce que je dois reprendre : ______________________

Ma question à poser à l'enseignant : ______________________