←

</Contexte>

Dans le cadre d'une infrastructure sécurisée, ce projet vise à déployer un pare-feu pfSense pour segmenter le réseau en zones (LAN, DMZ, AGENCE/SERVEURS) et appliquer des politiques de sécurité adaptées, en cohérence avec le principe de défense en profondeur.

Pourquoi mettre en place pfSense et la segmentation réseau ?

  • Réduire la surface d'attaque : cloisonner les flux et limiter les déplacements latéraux.
  • Centraliser le contrôle des accès : pare-feu stateful, NAT, proxys, listes noires.
  • Standardiser la sécurité : règles homogènes, journalisation, supervision.
  • Préparer la production : base pour la haute disponibilité (CARP) et le durcissement.

Problématique

Comment concevoir et paramétrer un pare-feu pfSense multi-zones garantissant l'isolation DMZ/LAN/AGENCE tout en permettant les flux nécessaires (AD, DNS, Web), avec des règles explicites, auditables et facilement maintenables ?

Méthodologie

  1. Préparer l'adressage — Définir les sous-réseaux et l'affectation des interfaces.
  2. Attribuer les interfaces — WAN / LAN / DMZ / SERVEURS depuis l'assistant pfSense.
  3. Configurer DHCP — LAN dynamique, DMZ et AGENCE en IP statiques.
  4. Définir les règles de filtrage — Politiques par zone selon le principe du moindre privilège.
  5. Mettre en place le proxy filtrant — Squid + SquidGuard avec blacklist académique.
  6. Valider par des tests fonctionnels — DNS, accès web, vérification des blocages.

</Architecture>

Architecture cible

pfSense est déployé avec 4 interfaces dédiées à chaque zone de sécurité :

🌐 WAN

Interface externe — accès Internet entrant. Seuls HTTP/HTTPS vers SRV-WEB (DMZ) sont publiés.

🖥 LAN — 10.0.20.0/24

Réseau utilisateurs. DHCP actif (Kea). Accès Internet filtré par Squid/SquidGuard.

🔒 DMZ — 10.0.30.0/24

Zone exposée. SRV-WEB (10.0.30.10). Accès LAN bloqué par défaut.

⚙ SERVEURS — 10.0.10.0/24

DC01 (10.0.10.10). Flux AD/DNS/LDAP/Kerberos stritement contrôlés.

Schéma LAB pfSense

Figure 1 — Schéma du laboratoire pfSense (interfaces et zones)

⚠️ Disclaimer LAB : à utiliser uniquement en laboratoire/maquette. Ne pas déployer tel quel en production sans durcissement (règles sortantes restrictives, haute disponibilité, segmentation avancée, supervision).

</Réalisation>

1) Attribution des interfaces

Depuis l'assistant initial de pfSense, attribuer les interfaces physiques/virtuelles aux zones WAN/LAN/DMZ/SERVEURS puis configurer les adresses IPv4 statiques des interfaces internes.

Attribution interfaces pfSense

Figure 2 — Attribution des interfaces pfSense

2) Service DHCP

Activer le serveur DHCP sur LAN et imposer Kea DHCP à la place de ISC DHCP (déprécié) ; désactiver le DHCP en DMZ et AGENCE pour imposer des IP statiques aux différents services.

Configuration DHCP pfSense

Figure 3 — Configuration du service DHCP (Kea) sur l'interface LAN

3) Règles de filtrage (Firewall)

  • DMZ → LAN : BLOQUER par défaut ; n'autoriser que les flux nécessaires (DNS interne si requis).
  • LAN → Internet : autoriser selon politique ; restreindre vers DMZ (HTTP/HTTPS vers SRV-WEB pour maintenance).
  • AGENCE/SERVEURS ↔ LAN/AD : autoriser les flux d'administration AD strictement nécessaires (LDAP/Kerberos/DNS, RPC).
  • WAN → DMZ : publier uniquement les services (HTTP/HTTPS) vers SRV-WEB ; aucun accès direct au LAN.

Règles WORDPRESS — Section DMZ

Règles DMZ WordPress

Figure 4 — Règles de pare-feu pfSense sur l'interface DMZ (WordPress)

Règles AD — Section SERVEURS

Règles AD pfSense 1
Règles AD pfSense 2
Règles AD pfSense 3

Figure 5 — Règles de pare-feu sur l'interface SERVEURS (Active Directory)

⚠️ Limiter la plage RPC dynamique (49152–65535) au strict nécessaire et filtrer par IP source/destination ; en production, préférer un durcissement et une supervision active des journaux.

</Filtrage>

4) Proxy filtrant (Squid + SquidGuard)

Installer les paquets Squid et SquidGuard depuis le gestionnaire de paquets pfSense, appliquer une blacklist académique et définir une politique deny par défaut — l'utilisation de l'IA sera en allow.

Configuration Squid

Figure 6 — Configuration du proxy Squid

URL regroupant des sites à blacklister :

http://dsi.ut-capitole.fr/blacklists/download/blacklists_for_pfsense.tar.gz
SquidGuard blacklist
SquidGuard config 2
SquidGuard config 3

Figure 7 — Configuration SquidGuard et import de la blacklist

Activer les logs afin de savoir quel ordinateur (et quel utilisateur si LDAPS) se connecte sur les sites restreints :

Logs Squid
Logs Squid détail

Figure 8 — Activation des journaux Squid

Pour éviter les contournements via le navigateur de recherche, activer cette option :

Anti-contournement 1
Anti-contournement 2

Figure 9 — Option anti-contournement du proxy

Résultat avec une erreur de connexion sur un site bloqué :

Blocage SquidGuard

Figure 10 — Page de blocage SquidGuard

Une fois SquidGuard configuré et activé (cocher les deux cases — la première active le filtrage, la seconde rend SquidGuard fonctionnel), mettre en place le proxy sur le client via GPO Windows Server :

SquidGuard activé
GPO proxy
GPO proxy 2

Figure 11 — Déploiement du proxy via GPO Windows Server

Validation et tests

  • Résolution DNS depuis un poste LAN ; ping des passerelles et hôtes clés.
  • Accès web depuis LAN/AGENCE et vérification du blocage via SquidGuard.
  • Vérifier que DMZ → LAN est bloqué par défaut ; n'ouvrir que les flux nécessaires.

</Conclusion>

Résultats et livrables

  • Pare-feu pfSense opérationnel avec 4 zones isolées (WAN/LAN/DMZ/SERVEURS).
  • Règles de filtrage par zone documentées et testées.
  • Proxy Squid + SquidGuard avec blacklist académique déployé sur LAN.
  • Configuration DHCP Kea sur LAN, IP statiques sur DMZ/SERVEURS.

Problèmes rencontrés / Solutions

  • Ordre des règles : remonter les autorisations spécifiques au-dessus des blocs génériques.
  • Redirections : vérifier l'interface cible et les ports publiés.

Perspectives d'avenir

  • Redondance pfSense (CARP) — Haute disponibilité avec basculement automatique.
  • Durcissement des règles sortantes — Restriction maximale des flux autorisés.
  • Centralisation des logs — Envoi vers un SIEM (Graylog, ELK) pour corrélation.
  • Supervision continue — Intégration Zabbix pour la surveillance du pare-feu.

— Fin du document —