Configurer le pare-feu pfSense : l'essentiel

pfSense est un pare-feu libre et gratuit, basé sur FreeBSD, qui s'administre par une interface web : filtrage avec état, NAT, VLAN, VPN, portail captif, IPS et filtrage DNS. C'est le pare-feu du labo de Sorbier et le plus utilisé en BTS SIO SISR, en TP comme pour les réalisations de l'E6 ; OPNsense, né d'une reprise de son code, fonctionne de la même façon. Ce chapitre donne l'essentiel pour l'architecture de ce cours : installer, déclarer les interfaces et les VLAN, écrire des règles avec des alias, publier un service, lire les journaux et sécuriser le pare-feu lui-même.

pfSense ou OPNsense ?

Les deux font le même travail et la logique est identique, avec des noms de menus un peu différents. Chez Sorbier, comme dans tous les cours SISR du site, le pare-feu est pfSense CE : les exemples le suivent, et les équivalents OPNsense sont signalés quand ils diffèrent. En entreprise, tu croiseras aussi des pare-feu commerciaux : Stormshield (français, qualifié par l'ANSSI, très présent dans les administrations et les établissements scolaires), Fortinet, Sophos, Palo Alto, et les passerelles UniFi, courantes dans les PME.

Installer pour un TP

Pour t'entraîner, une machine virtuelle suffit (Proxmox VE, VirtualBox, VMware) :

1. Crée une VM avec 2 processeurs, 2 Go de mémoire, 16 Go de disque et au moins deux cartes réseau : une vers ton réseau « Internet » (WAN), une vers un réseau interne isolé (LAN).
2. Installe depuis l'image officielle (système de fichiers ZFS proposé par défaut).
3. Au premier démarrage, la console demande d'assigner les interfaces : laquelle est le WAN, laquelle est le LAN. Le LAN prend l'adresse 192.168.1.1/24 et distribue des adresses par DHCP.
4. Depuis une VM cliente du LAN, ouvre https://192.168.1.1. L'assistant de configuration demande le nom, le DNS, le fuseau horaire, la configuration WAN, l'adresse LAN et le nouveau mot de passe administrateur.

Interfaces et VLAN

Chaque réseau que le pare-feu route est une interface. Pour les VLAN de Sorbier, transportés sur un seul câble (trunk 802.1Q) depuis le switch de cœur :

1. Interfaces > Assignments > VLANs : crée un VLAN par réseau sur la carte physique reliée au switch (par exemple igb1) : tag 10, tag 20, tag 30, tag 40, tag 50, tag 99. Le port en face, sur le switch, doit être configuré en trunk avec ces mêmes VLAN.
2. Interfaces > Assignments : ajoute chaque VLAN comme interface, active-la, renomme-la (POSTES, SERVEURS…) et donne-lui son adresse statique, qui sera la passerelle du VLAN (192.168.10.126/26 pour POSTES).
3. La DMZ peut utiliser une troisième carte physique, reliée à un switch dédié : c'est plus simple à lire et un problème sur le trunk n'affecte pas la DMZ.
4. Services > DHCP Relay : chez Sorbier, le DHCP est assuré par srv-ad. Maintenant que le pare-feu route les VLAN, c'est lui qui relaie les demandes DHCP des interfaces POSTES, ENTREPOT, VISITEURS et TELEPHONIE vers 192.168.10.177. Sur SERVEURS, DMZ et ADMIN, pas de DHCP : adresses fixes. Dans un TP sans serveur Windows, utilise plutôt Services > DHCP Server sur chaque interface : pfSense refuse d'être à la fois serveur et relais DHCP. Pour VISITEURS, l'idéal serait un serveur DHCP sur le pare-feu lui-même, pour que rien du réseau invité n'atteigne un serveur interne : OPNsense permet de mélanger serveur et relais selon l'interface.

Les alias

Un alias donne un nom à une adresse, un réseau, une liste de ports ou d'adresses (Firewall > Aliases). Les règles deviennent lisibles, et une modification se fait à un seul endroit.

Un alias de type Host accepte des noms DNS : pfSense les résout régulièrement et met la liste d'adresses à jour. Un alias de type URL Table télécharge une liste d'adresses publiée sur Internet (listes de blocage, plages d'un fournisseur).

Les règles de filtrage dans pfSense

Les règles se trouvent dans Firewall > Rules, un onglet par interface. Quatre points à connaître :

• une règle s'applique au trafic qui entre dans le pare-feu par cette interface ;
• les règles sont lues de haut en bas, la première qui correspond gagne ; un glisser-déposer change l'ordre ;
• une interface sans règle bloque tout ce qui entre ;
• les objets spéciaux simplifient l'écriture : POSTES subnets (le réseau de l'interface), POSTES address (l'adresse du pare-feu sur cette interface), This Firewall (toutes ses adresses).

Une règle se remplit avec ces champs :

L'interface LAN créée à l'installation contient trois règles automatiques : la règle anti-lockout (elle garantit l'accès à l'interface web depuis le LAN) et deux règles Default allow LAN to any (IPv4 et IPv6). Ces dernières autorisent tout : on les remplace par des règles précises une fois la politique écrite.

Sur le WAN, deux cases de Interfaces > WAN sont à laisser cochées : Block private networks (refuse les paquets venant d'Internet avec une adresse source privée, forcément usurpée) et Block bogon networks (refuse les plages qui ne devraient jamais apparaître sur Internet).

NAT : publier un service

Firewall > NAT > Port Forward crée une redirection : interface WAN, protocole TCP, adresse de destination WAN address, port 443, redirection vers SRV_WEB port 443. Laisse le choix Filter rule association sur l'option qui crée la règle associée : pfSense ajoute alors dans l'onglet WAN la règle qui autorise le flux vers 192.168.10.225.

Le NAT sortant (Firewall > NAT > Outbound) est en mode automatique : tous les réseaux internes sortent avec l'adresse publique du WAN. On passe en mode hybride ou manuel seulement pour un besoin particulier (une adresse publique dédiée à un serveur, par exemple).

Lire les journaux du pare-feu

Status > System Logs > Firewall affiche les paquets qui ont correspondu à une règle journalisée, et par défaut ceux refusés par la règle de blocage implicite.

TCP:S signale un paquet SYN, le début d'une connexion. Les trois premières lignes montrent une même adresse d'Internet qui essaie SSH, RDP et SMB en une seconde : un balayage de ports, bloqué. La dernière ligne est bien plus inquiétante : le serveur web de la DMZ tente d'ouvrir un partage SMB sur le serveur de fichiers. Un serveur web n'a aucune raison de le faire : il est peut-être compromis, et c'est exactement le cas où la DMZ joue son rôle.

D'autres outils aident au diagnostic :

• Diagnostics > States : la table d'états, les connexions en cours ;
• Diagnostics > Packet Capture : une capture de trames sur une interface, à ouvrir dans Wireshark (lire une capture) ;
• Status > System Logs > Settings : l'envoi des journaux vers un serveur syslog distant, indispensable pour les conserver hors du pare-feu (chapitre 13).

Sécuriser le pare-feu lui-même

Le pare-feu est l'équipement le plus exposé : il doit être le mieux protégé.

• Mot de passe administrateur robuste, changé à l'installation, et un compte nominatif par administrateur (System > User Manager) plutôt que le compte admin partagé.
• Interface web accessible seulement depuis le réseau d'administration : désactive la règle anti-lockout (System > Advanced > Admin Access) après avoir créé une règle qui autorise HTTPS vers le pare-feu depuis ADMIN uniquement. Jamais d'accès à l'interface web depuis le WAN.
• Certificat de l'interface web signé par l'autorité interne, pour ne plus habituer les administrateurs à cliquer sur « continuer malgré l'avertissement » (chapitre 6).
• SSH désactivé, ou limité à l'authentification par clé, depuis ADMIN.
• Mises à jour suivies : le pare-feu est la cible favorite des attaquants, et les failles des équipements périmétriques font régulièrement l'objet d'alertes du CERT-FR.
• Sauvegarde de la configuration (Diagnostics > Backup & Restore) : un fichier config.xml qui contient toute la configuration, y compris des secrets (clés VPN, mots de passe). Chiffre la sauvegarde (case Encrypt this configuration file) et range-la hors du pare-feu.
• Haute disponibilité si l'activité ne supporte pas d'interruption : deux pare-feu en grappe avec CARP (adresse virtuelle partagée) et pfsync (synchronisation de la table d'états), pour qu'une panne passe inaperçue. Le chapitre Redondance de passerelle du cours Haute disponibilité détaille CARP, VRRP et HSRP.

Tester une règle

Une règle n'est terminée que lorsqu'elle est testée, dans les deux sens : le flux autorisé passe, un flux voisin interdit est bloqué.

# Depuis un poste du VLAN 10 : le flux autorisé doit répondre True
Test-NetConnection 192.168.10.177 -Port 389
# Un flux interdit (SMB vers la DMZ) doit répondre False
Test-NetConnection 192.168.10.225 -Port 445

Depuis Linux, nc -zv 192.168.10.177 389 fait la même vérification. Regarde ensuite le journal du pare-feu : la tentative interdite doit y apparaître, avec la règle qui l'a bloquée. C'est la preuve à mettre dans ta documentation ou dans ton compte rendu d'E6.

Exercices