Hardening et sécurisation avancée de pfSense (12 blocs)

Contexte

Après l’installation de pfSense CE 2.8.1 sur la Sophos SG210 recyclée, j’ai entrepris une phase de hardening structurée en 12 blocs pour renforcer la sécurité du routeur/firewall du homelab. L’infrastructure comprend deux instances pfSense : une physique (pfsense-sophos, Sophos SG210) et une VM miroir (pfsense-vm sur PVE-02, CTID documenté) — d’où l’importance d’une procédure de synchronisation et de bascule.

Les 12 blocs de hardening

Blocs 1-5 — Durcissement de l’administration

Bloc 1 — Identité et accès

• Changement du compte admin par défaut (mot de passe fort, stocké dans Vaultwarden)
• Accès WebUI (443) restreint à l’interface MGMT (172.16.10.0/24) uniquement
• Désactivation de l’accès WebUI sur le WAN

Bloc 2 — NTP sécurisé

• Remplacement des serveurs NTP par défaut (0.pfsense.pool.ntp.org) par des sources fiables
• Restriction du service NTP aux VLANs internes uniquement

Bloc 3 — DNS sécurisé (DNS over TLS / HTTPS)

• Configuration du resolver DNS (Unbound) avec DNS over TLS vers des résolveurs de confiance
• Validation DNSSEC activée
• Blocage des requêtes DNS non chiffrées sortantes

Bloc 4 — Logging et audit

• Activation des logs détaillés par règle firewall
• Configuration de l’envoi des logs vers le serveur de supervision (syslog distant — en cours)
• Conservation des logs locaux avec rotation

Bloc 5 — Sauvegardes

• Export XML de la configuration complet (menu Diagnostics → Backup)
• Procédure documentée de restauration rapide

Blocs 6-11 — Sécurité réseau et filtrage

Bloc 6 — Révision des règles firewall

• Audit complet des règles par interface VLAN (principe du moindre privilège)
• Suppression des règles trop permissives héritées de l’installation

Bloc 7 — Filtrage inter-VLAN résiduel

• pfSense conserve le filtrage WAN→LAN et les flux que le Cisco 3560-CX ne peut pas intercepter
• Règles explicites : GUEST et IOT n’ont pas accès aux services d’administration

Bloc 8 — NAT sortant manuel

• Passage en mode NAT manuel (pas de NAT automatique)
• Règles de masquage par VLAN source (outbound masquerade vers WAN)

Bloc 9 — SNMP sécurisé

• Community string non triviale (pas public / private)
• Restriction par IP source : seul le LXC Zabbix (VLAN 10 MGMT) est autorisé à interroger SNMP

Bloc 10 — Packages de sécurité

• Installation et configuration de pfBlockerNG (blocage publicités/malwares par DNS)
• Évaluation de Suricata / Snort sur l’interface WAN (IDS/IPS)

Bloc 11 — Dashboard et exposition réduite

• Nettoyage du dashboard WebUI (widgets superflus supprimés)
• Désactivation des services non utilisés (mDNS/Avahi si non requis, etc.)

Bloc 12 — Synchronisation physique ↔ VM et résilience

• Procédure documentée de bascule entre pfsense-sophos (physique) et pfsense-vm (VM PVE-02)
• Synchronisation de la configuration XML entre les deux instances
• Tests de validation post-bascule (connectivité WAN, règles firewall, DNS)
• Avantage : si le Sophos SG210 tombe en panne, la VM prend le relais en quelques minutes

Résultat

Pare-feu durci selon les bonnes pratiques, avec :

• Accès d’administration restreint au VLAN MGMT uniquement
• Logs complets pour audit et détection d’incidents (vers Loki via syslog prévu)
• Isolation réseau vérifiée par tests (ping inter-VLAN bloqués selon politique ACL Cisco)
• Résilience assurée par la double instance physique/VM et la procédure de bascule documentée

Compétences mobilisées

Ce projet couvre directement la cybersécurité d’une infrastructure réseau (B3.5), la sécurisation des équipements et usages (B3.3), la garantie de disponibilité et d’intégrité via les sauvegardes et la synchronisation (B3.4), et l’évolution d’une infrastructure existante (B2.3).