TRAINING LAB

Sécuriser les accès à Internet avec pfSense & Squid

pfSense 2.6.0 · Squid · SquidGuard · LightSquid · VMware Workstation 17

Contexte

En prolongement du lab virtualisé de l'étude de cas n°4 (AD DS / DNS / DHCP / WDS sur Windows Server 2022), j'ai ajouté une VM pfSense 2.6.0 pour jouer le rôle de passerelle réseau. L'objectif : sécuriser les accès Internet sortants de toutes les machines du LAN privé (192.168.100.0/24), filtrer le trafic web via un proxy transparent Squid et appliquer des politiques d'accès — reproduisant la sécurité périmétrique d'une infrastructure d'entreprise réelle.

Architecture réseau

Hyperviseur: VMware Workstation Pro 17
VM pfSense: FreeBSD 12 64-bit — 10 Go HDD, 2 Go RAM
WAN (em0): Bridge sur clé 4G de l'hôte — DHCP — 192.168.1.110/24
LAN (em1): VMnet8 (NAT) — 192.168.100.220/24 (passerelle pfSense)
Serveur AD (DCAD22): 192.168.100.250 — AD DS, DNS, DHCP, WDS
Serveur fichiers (SRVSAMBA): 192.168.100.130 — Partages Samba
Clients: 192.168.100.21, 192.168.100.22
Interface web pfSense: https://192.168.100.220

Phases de mise en place

1
Phase 1 — Installation de pfSense
Création d'une nouvelle VM dans VMware Workstation (FreeBSD 12 64-bit, 10 Go, 2 Go RAM) avec deux cartes réseau : NIC 1 en mode Bridged (connectée à la clé 4G USB de l'hôte — WAN), NIC 2 en Custom VMnet8 (LAN privé existant). Démarrage sur l'ISO pfSense 2.6.0, acceptation de la licence, sélection du clavier français, installation standard. Après redémarrage, la console confirme WAN sur em0 (192.168.1.110/24) et LAN sur em1 (192.168.100.220/24).
2
Phase 2 — Alias et règles de pare-feu
Dans l'interface web pfSense, création de deux alias IP sous Firewall → Aliases : 'SRV' (192.168.100.130 = SRVSAMBA, 192.168.100.250 = DCAD22) et 'Client' (192.168.100.21, 192.168.100.22). Configuration des règles LAN : autorisation DNS (UDP 53) depuis l'alias SRV, autorisation ICMP echo-request depuis SRV, puis ajout d'une règle de blocage explicite 'REFUS SRV VERS INTERNET' (IPv4 any depuis SRV) — placée avant la règle allow-all par défaut. Les serveurs peuvent résoudre le DNS et répondre aux pings, mais ne peuvent pas initier de connexions Internet sortantes.
3
Phase 3 — Proxy Squid & SquidGuard
Installation de trois paquets via System → Package Manager : squid (0.4.45_9), squidGuard (1.16.18_20) et LightSquid (3.0.6_9 — tableau de bord de reporting). Configuration de Squid en proxy transparent sur l'interface LAN (port 3128), avec inspection SSL activée via une CA interne générée localement (Pfsense-CA, auto-signée, valide 10 ans, C=FR / ST=Ile de France / O=greta / L=argenteuil). Configuration de SquidGuard avec listes noires d'URL par catégorie. LightSquid activé pour les rapports de trafic par utilisateur, accessibles depuis l'interface pfSense.

Résultats

Passerelle: pfSense 2.6 routant et nattant tout le trafic LAN vers la connexion WAN 4G
Contrôle d'accès: Serveurs (alias SRV) bloqués sur Internet ; exceptions DNS + ICMP uniquement
Filtrage web: Proxy transparent Squid + SquidGuard bloquant les catégories d'URL indésirables
Inspection HTTPS: CA interne auto-signée déployée pour le SSL bump sur le trafic HTTPS sortant
Reporting: Tableau de bord LightSquid fournissant les statistiques d'utilisation web par client
Compétences: pfSense, règles pare-feu, alias IP, proxy Squid, SquidGuard, gestion PKI / CA

Points de sécurité

Règles de moindre privilège : n'autoriser que les ports et destinations strictement nécessaires — la règle allow-all par défaut doit toujours être la dernière, jamais la première.
L'inspection HTTPS implique une décision de confiance : la CA interne (Pfsense-CA) doit être importée comme autorité racine de confiance dans chaque navigateur ou OS client, sinon les sites HTTPS afficheront des avertissements de certificat.
Les listes noires SquidGuard ne fonctionnent que sur HTTP et sur HTTPS intercepté — le trafic contournant le proxy (connexions IP directes, DNS-over-HTTPS) ne sera pas filtré.
La revue des logs fait partie de l'exploitation : les rapports LightSquid et les logs d'accès Squid doivent être consultés régulièrement pour vérifier l'efficacité des règles et détecter les anomalies de trafic.
La maintenance des alias est importante : les alias SRV et Client doivent être mis à jour lorsque le réseau évolue — des alias obsolètes cassent silencieusement la politique de pare-feu.

Captures d'écran