Site public — DMZ

" | sudo tee /var/www/html/index.html sudo systemctl enable --now nginx # Vérifier l'écoute sudo ss -tlnp | grep :80 ``` Fixez l'IP statique de `web-srv` à `192.168.20.10` (via netplan ou réservation DHCP pfSense). Confirmez l'accessibilité depuis pfSense : ```bash # Sur la console pfSense (option 8 = shell) curl http://192.168.20.10 # Doit retourner le HTML ``` ## Phase 3 — interface web pfSense et premières règles Depuis `poste-lan`, ouvrez `https://192.168.10.1` dans un navigateur. Login `admin` / `pfsense` puis assistant initial : changement de mot de passe, configuration DNS, fuseau horaire. Allez dans **Firewall → Rules → DMZ**. Aucune règle n'existe par défaut sur DMZ : tout le trafic *en entrée sur la DMZ* est rejeté. Vous allez ajouter les règles strictement nécessaires. > 🔑 **À retenir** — Sur pfSense, la règle s'écrit *« en entrée sur l'interface »*. Une règle DMZ filtre les paquets qui entrent depuis le réseau DMZ vers le firewall — c'est le sens DMZ → autres zones. ## Phase 4 — publier le site web Vous devez créer **deux choses** pour publier le site : ### NAT Port Forward **Firewall → NAT → Port Forward → Add** : ``` Interface : WAN Protocol : TCP Destination : WAN address Dest port range : 80 Redirect IP : 192.168.20.10 Redirect port : 80 Description : Publication site DMZ Filter rule : Add associated filter rule ``` L'option *Add associated filter rule* crée automatiquement la règle WAN qui autorise ce trafic. Vous pouvez la consulter dans **Firewall → Rules → WAN**. ### Test depuis Internet Depuis la VM `attaquant` (côté WAN), testez : ```bash # Vérifier l'IP WAN du firewall ip route get 8.8.8.8 # Tester l'accès au site publié curl http:// # Doit retourner la page

Site public — DMZ

``` Si vous voyez la page, votre Port Forward fonctionne. Sinon, vérifiez : la règle de filtrage WAN existe (pas seulement le NAT), le serveur Nginx tourne sur DMZ, le firewall iptables/ufw du serveur DMZ ne bloque pas le 80. ## Phase 5 — règles inter-zones Vous voulez que **LAN puisse atteindre DMZ pour administration**, mais que **DMZ ne puisse pas atteindre LAN**. C'est la règle d'isolation centrale. ### Règles LAN Par défaut, LAN a une règle « **default allow LAN to any** » qui autorise toute sortie. Remplacez-la par des règles plus précises : ``` 1. Pass : LAN net → DMZ net, ports 22, 80, 443 [administration DMZ] 2. Block : LAN net → DMZ net, any [bloque le reste] 3. Pass : LAN net → !RFC1918, any [sortie Internet uniquement] ``` L'alias `RFC1918` regroupe `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` — créez-le dans Firewall → Aliases si nécessaire. La règle 3 dit *« LAN peut sortir vers Internet mais pas vers d'autres réseaux privés »*. ### Règles DMZ Sur DMZ, vous serrez fortement les sorties : ``` 1. Pass : DMZ net → DMZ address, port 53 [DNS via firewall] 2. Pass : DMZ net → !RFC1918, ports 80, 443 [updates OS] 3. Block : DMZ net → LAN net, any [isolation stricte] 4. Block : DMZ net → any [policy default] ``` Notez l'ordre : la règle de blocage LAN est explicite **avant** le block général. Sur pfSense, l'ordre top-down est crucial. ## Phase 6 — valider par scan Vous allez maintenant prouver que la politique fait ce qu'elle promet. Trois scans depuis trois sources : ### Depuis l'attaquant (WAN) ```bash # Scan TCP des ports les plus courants sudo nmap -sS -T4 -p 1-1024 # Résultat attendu : seul le port 80 ouvert # Tous les autres ports = filtered (drop silencieux pfSense) ``` ### Depuis poste-lan (LAN) ```bash # Scan vers DMZ sudo nmap -sS -T4 192.168.20.10 # Attendu : 22, 80, 443 ouverts (ou filtered si port pas écouté) # Scan vers WAN curl -m 5 https://www.example.com # Attendu : OK, accès Internet fonctionne ``` ### Depuis web-srv (DMZ) ```bash # Tentative vers LAN — DOIT ÉCHOUER ping -c 2 192.168.10.10 # Attendu : 100 % packet loss sudo nmap -sS -T4 192.168.10.0/24 # Attendu : tous filtered (host down apparent) # Sortie Internet — DOIT FONCTIONNER (limité) curl -m 5 https://www.example.com # Attendu : OK ``` Si DMZ peut atteindre LAN, votre règle 3 est mal placée ou mal écrite — corrigez avant de continuer. ## Phase 7 — auditer les logs Tous les paquets bloqués sont logués. Sur pfSense, **Status → System Logs → Firewall** liste les drops récents avec source, destination, port, protocole. ```bash # Sur la console pfSense (shell, option 8) clog -f /var/log/filter.log | head -20 # Filtrer par interface DMZ clog /var/log/filter.log | grep dmz | head ``` Identifiez les drops correspondant à vos tests : la tentative de ping de DMZ vers LAN doit apparaître avec le préfixe `block` et l'interface DMZ. ```mermaid flowchart LR T[Test depuis
chaque zone] --> WAN{WAN scan ?} T --> LAN{LAN tests ?} T --> DMZ{DMZ pivot ?} WAN -->|seul 80 ouvert| OK1[OK] LAN -->|22 80 443 DMZ + Internet| OK2[OK] DMZ -->|Internet OK LAN bloqué| OK3[OK] style T fill:#3b82f6,color:#fff,stroke:none style WAN fill:#f59e0b,color:#fff,stroke:none style LAN fill:#f59e0b,color:#fff,stroke:none style DMZ fill:#f59e0b,color:#fff,stroke:none style OK1 fill:#10b981,color:#fff,stroke:none style OK2 fill:#10b981,color:#fff,stroke:none style OK3 fill:#10b981,color:#fff,stroke:none ``` ## Phase 8 — sauvegarder la configuration Avant de quitter le TP, exportez la configuration en XML pour reproductibilité. **Diagnostics → Backup & Restore → Backup configuration → Download** Ce fichier représente l'intégralité de votre travail. Stockez-le dans un dépôt Git privé (en supprimant les hashes de mots de passe) : vous pourrez restaurer ou cloner cette politique sur un autre pfSense en quelques minutes. ## 🏢 Cas concret Une **PME e-commerce** déploie une infrastructure de type lab interne pour tester les nouvelles règles avant production. L'équipe sécurité reproduit exactement ce TP avec pfSense, mais ajoute une 4ᵉ zone : **GUEST** pour le Wi-Fi visiteurs. La règle GUEST → LAN est en *block all*. La règle GUEST → DMZ est en *block all*. La règle GUEST → Internet est *pass* sur 80/443/53/DNS uniquement (pas de SMB, pas de SIP, pas de torrents). Le débit GUEST est limité à 50 Mbps via le shaper pfSense. L'équipe valide la politique en mettant un poste sur le Wi-Fi visiteurs et en tentant de scanner le LAN — chaque tentative apparaît instantanément en *block* dans `filter.log`. Cette robustesse est documentée pour le RGPD : les invités ne peuvent pas accéder aux données métier, même par accident. Trois mois plus tard, un visiteur connecte un device infecté. Le malware tente une propagation latérale via SMB — bloqué dès le premier paquet sortant. La séparation a fait son travail. ## ⚠️ Pièges fréquents | Piège | Pourquoi ça arrive | Comment l'éviter | |---|---|---| | Règle WAN oubliée après NAT | Confusion NAT vs filter | Cocher *Filter rule association* | | Règle DMZ → LAN après le pass | Ordre de règles incorrect | Toujours block explicite avant tout pass | | Routes asymétriques | Plusieurs gateways non maîtrisés | Une seule default gateway par zone | | MTU incohérent en VLAN | Ajout VLAN sans fragmentation MSS | Activer MSS clamping si VPN | | Logs ignorés en production | Confiance dans la règle écrite | Routine hebdo de revue des drops | ## ✍️ À vous de jouer **Exercice 1** — Réalisez les phases 0 à 6 du TP. Documentez chaque étape avec une capture d'écran ou un copier-coller de la commande exécutée. **Exercice 2** — Ajoutez une 4ᵉ zone GUEST (Wi-Fi visiteurs) avec les règles : pas d'accès LAN, pas d'accès DMZ, accès Internet uniquement sur 80/443/DNS. Validez par scan. **Exercice 3** *(optionnel)* — Activez le package **pfBlockerNG** et configurez un blocage GeoIP : bloquer toute tentative de connexion vers le port 80 du WAN provenant d'un pays hors zone d'activité (à choisir). Vérifiez les statistiques après 24 h. ## 📌 En résumé - Une architecture pfSense multi-zone matérialise **WAN, LAN, DMZ** avec une politique par interface - La **publication** d'un service web exige **NAT Port Forward** **+** règle de filtrage WAN - L'isolation **DMZ → LAN** est la pierre angulaire — toujours block explicite avant tout pass - La **validation** se fait par scan depuis chaque zone, en confrontant les attentes - La **configuration XML** sauvegardée garantit reproductibilité et restauration rapide **➡️ Prochaine leçon** : *IDS/IPS — Suricata, Snort* — vous allez quitter le filtrage statique pour entrer dans la détection active : voir les attaques au lieu de simplement les bloquer.

Account

TP — Architecture pfSense multi-zone

Ressources

Aucune ressource

Ressource

Your Cart

Complete Your Registration

Order Summary

Payment Information