¶ Introduction
L'une des principales fonctions réalisées par pfSense est le filtrage du flux réseau, grâce notamment à la mise en place de règles (ACL) décidant quel trafic est autorisé ou bloqué entre les réseaux. Nous allons ici découvrir le fonctionnement de ces règles en les mettant en pratique autour d’un réseau local (LAN) et d’un réseau "démilitarisé" (DMZ).
¶ Mise en place de l'environnement
Voici le schéma de l'infrastructure que nous allons utiliser pour nos travaux :
¶ pfSense
Cette VM pfSense est évidemment au cœur de nos travaux. Nous la créons selon le procédé habituel, sur une base simple :
Création de la VM pfSense ; ne pas oublier de choisir le modèle FreeBSD x64
Lors de la création (en mode expert), valider les propositions par défaut (1 CPU, RAM 1GB, stockage 16 GB)
Indications après la création de la VM :
- Désactiver Audio et USB
- Interface réseau 1 : bridgée sur une interface physique (filaire de préférence)
- Interface réseau 2 : réseau interne, nommé LAN
Résumé de la configuration de la VM pfSense
Démarrer la VM et réaliser l’installation, en terminant par la commande init 0 depuis le Shell, afin d’éteindre la VM.
Retirer le lecteur optique, puis redémarrer pour finaliser la configuration initiale, qui doit être automatique :
L’écran d’accueil de la console pfSense post-installation
Pour plus d'informations et de détails concernant l'installation de pfSense sous VirtualBox, rendez-vous ici https://melot.fr/labo-virtuel-personnel-pfsense/
Nous allons maintenant configurer l’adresse IP LAN de pfSense (option 2 de la console).
La valeur
Xest personnelle et vous est attribuée en début de séance. Si vous réalisez ce TP en solo, utilisez la valeur 100.
- Adresse IP : 10.X.1.1/24
- Ne pas configurer IPv6
- Mettre en place le serveur DHCP avec le pool d’IP : 10.X.1.[100-199]
Exemple avec X = 100 :
Configuration de l’adresse IP du LAN …
… et activation du serveur DHCP sur le LAN
Eteindre le système (option 6) et réaliser un cliché instantané de la VM, appelé post installation :
Un cliché instantané permet la sauvegarde d’un état fonctionnel de la VM.
Eteindre et démarrer de nouveau la VM pfSense, en mode sans affichage, afin de ne pas encombrer l’espace de travail de la machine hôte.
¶ Client Windows
Cette machine cliente est dans notre contexte destinée à l’administrateur du réseau.
Utiliser le mode expert, et cocher l’option Skip Unattended Installation.
Pour le hardware et le stockage, laisser les propositions par défaut.
Puis ajustez ensuite la configuration :
- Système :
- 4 GB RAM
- 2 CPU
- Pointage : Souris PS/2
- Désactiver Audio et USB
- Interface réseau 1 sur le réseau interne « LAN »
Lancer la VM pour procéder à l’installation de MS Windows. Choisir de préférence la version Windows Pro N (version exempte de logiciels superflus, ou bloatwares)
Une fois l’installation de Windows terminée, insérer le CD des Additions invité de VirtualBox :
L’image ISO des Additions invité va être insérée dans le lecteur optique de la VM.
Puis procéder à l’installation du package :
Ce package installe les pilotes et outils nécessaires à une intégration plus confortable de Windows dans VirtualBox : graphisme, dossiers partagés, copier/coller, glisser/déposer, ... Concernant ces deux dernières options, il faut les activer dans le menu Périphériques.
Redémarrer la VM comme proposé à la fin de l’installation.
Eteindre la VM et en faire un cliché instantané, appelé post installation, afin de sauvegarder là aussi cet état primordial de la VM.
¶ Configuration de pfSense
¶ Réglages initiaux
Dans ce qui suit, remplacez
Xetdomainepar les valeurs individuelles qui vous sont indiquées. A défaut, utilisez 100 et votre nom.
Depuis la VM Windows, ouvrir le navigateur web pour vous connecter sur l’interface webadmin de pfSense : http://10.X.1.1
Après la saisie des credentials par défaut de pfSense (admin et pfsense), l’assistant d’installation (wizard) se lance automatiquement ; il vous permet de configurer :
- Hostname : firewall
- Domaine : domaine.lan
- DNS 1 : 1.1.1.1
- DNS 2 : 1.0.0.1
- Override : décocher
- Time server : laisser la proposition de serveur NTP
- Time zone : Europe/Paris
- Interface WAN : décocher les options block RFC1918 networks et block bogon networks
- Adresse IP (déjà définie) :
10.X.1.1 / 24 - Mot de passe : à modifier selon votre choix
Le tableau de bord (dashboard) de pfSense après la configuration initiale.
¶ Création d'un deuxième réseau local DMZ
Ajouter une troisième interface réseau sur la VM pfSense (après l’avoir éteinte bien sûr), connectée à un réseau interne appelé DMZ :
Activation de l’interface #3 depuis le panneau de configuration de la VM sur VirtualBox dans le réseau interne DMZ
Redémarrez ensuite pfSense (toujours sans affichage), et connectez-vous à l’interface WebAdmin.
Rendez-vous sur Interfaces / assignements ; une nouvelle interface em2 est disponible, prête à être configurée :
Cliquez sur + Add puis Save
Configurez ensuite l’interface logique OPT1 qui vient d’être associée à l’interface physique :
Indications :
- Enable interface : cocher pour l’activer
- Description : DMZ
- Configuration IPv4 : Static
- Configuration IPv6 : None
- Adresse IPv4 :
10.X.2.1 / 24 - Ne pas ajouter de passerelle (comme préconisé)
- Ne pas bloquer les réseaux privés ni les réseaux bogon
Sauvegardez, puis appliquez les changements. Le tableau de bord indique désormais l’état de cette nouvelle interface :
Le dashboard avec la nouvelle interface DMZ visible
Pour plus de clarté, nous allons désactiver IPv6 sur nos interfaces :
- Désactivez si nécessaires les services DHCPv6 (serveur et RA) pour l’interface LAN (si l'interface LAN n'a pas d'IPv6, ces services ne sont pas actifs)
- Désactivez si nécessaire l’IPv6 sur l’interface LAN,
- Enfin, sur l’interface WAN, désactivez l’IPv6 :
¶ Mise en place des services de pfSense
Nous allons configurer un service DHCP pour chacune des interfaces, ainsi que le service DNS.
¶ DHCP
Ce service est déjà actif sur le LAN, nous allons simplement vérifier que la plage d’attribution est bien de 100 à 199.
Depuis la version 2.7.2 de pfSense, vous êtes invités à basculer du service historique (et déprécié) ISC vers le nouveau KEA. Il faut en effet réaliser cette bascule dans les paramètres. Ceci aura pour effet de modifier la plage DHCP mise en place auparavant.
L’interface d’administration du service DHCP v4, avec un onglet pour chaque interface dont l'adresse IP est fixe (ici LAN et DMZ)
Sauvegardez si besoin ces changements, puis activer le service DHCP de façon identique sur l’interface DMZ :
Enfin, nous allons attribuer une IP fixe à notre VM Windows en utilisant un bail statique sur le serveur DHCP :
- Affichez les baux en cours, la VM doit apparaître (sinon, renouvelez son bail, selon la méthode de votre choix ; vous en trouverez une quelques lignes plus bas) :
La page d’état des baux DHCP de pfSense : un seul bail en cours sur LAN, pour la VM Windows.
Lancer l’action add static mapping sur la ligne correspondante, et fixez l’adresse sur 10.X.1.50 :
Attention au niveau du hostname, il faudra probablement supprimer le
.final
Sauvegardez, appliquez les changements, puis renouvelez le bail DHCP de la machine Windows :
Commandes réalisées depuis une console cmd avec élévation de privilèges. Après renouvellement, la VM Windows a obtenu l’adresse IPv4 prévue par le bail statique.
L’état des baux de pfSense confirme cette attribution statique, en indiquant que la machine est en ligne :
¶ DNS
Dans notre contexte, pfSense est le serveur DNS ; nous allons configurer ce service (qui par défaut est déjà activé).
Ce serveur DNS est censé prendre en charge les requêtes DNS provenant des réseaux locaux, et les résoudre soit localement (pour les noms de machines locales notamment), soit en interrogeant des serveurs DNS externes, sur l’interface WAN ; ces serveurs ont été définis au moment de la configuration initiale de pfSense.
Indications :
- Interfaces réseau d’écoute : sélectionnez LAN, DMZ et localhost
- Interface de sortie : sélectionnez WAN
Sauvegardez et appliquez les changements.
¶ Ajout d'un serveur dans le réseau DMZ
Désormais, nous allons préparer une VM Debian core selon le procédé habituel, dont l’interface est connectée sur le réseau interne LAN :
Pour plus d'informations et de détails sur l'installation d'une VM Debian core sous VirtualBox, rendez-vous ici : https://melot.fr/labo-virtuel-personnel-debian-serveur/
Configurez ainsi la VM :
- Préparation du hardware : par défaut (1 CPU, 2GB RAM, HDD 20GB)
- Pendant l’installation de l'OS :
- hostname : utilisez votre nom
- utilisateur standard : idem
- n’installer aucun complément (tout décocher)
- Après l’installation, en ligne de commande (root) :
- Lancer les mises à jour apt (update, upgrade)
- Installer sudo, ssh et nginx :
# apt install sudo ssh nginx - Promouvoir l’utilisateur standard comme sudoer :
# adduser nom sudo
Une fois la machine terminée, connectez-la sur le réseau DMZ, puis redémarrez-la. La console DHCP de pfSense nous indique un nouveau client sur le réseau DMZ :
Depuis la VM Windows, on peut voir que les services de la VM Debian sont accessibles :
Depuis un navigateur WEB, connecté sur l’adresse IP de la VM Debian, on obtient en réponse la page par défaut du serveur NGINX.
Ou encore avec ssh :
Depuis PowerShell sur la VM Windows, connexion en ssh sur la VM Debian.
Les deux VM ne sont pas sur le même réseau : c’est donc la fonction de routage (niveau 3) de pfSense qui opère ici, en permettant à un hôte du LAN de se connecter à un hôte de la DMZ.
¶ Gestion des règles de pare-feu
On peut constater cependant que, même si elle accessible depuis le LAN (comme nous l'avons vu ci-dessus), la VM Debian n’accède pas à internet :
Aucune réponse sur un simple ping, pas même sur l’IP du pfSense lui-même.
En effet, comparons les règles de pare-feu des interfaces LAN et DMZ :
Les règles ACL sur LAN. La première (anti-lockout) est une règle système issue des paramètres avancés, active par défaut, pour éviter de perdre l’accès à l’interface Web de pfSense depuis le LAN. Les deux suivantes donnent un accès ouvert (
*.*) depuis tout le réseau LAN (LAN subnets).
Les règles ACL sur DMZ : aucune règle définie, c’est pour cela que la VM Debian ne peut rien joindre.
En revanche, de façon implicite, pfSense autorise les connexions établies, c’est pourquoi depuis la VM Windows sur le LAN, on peut établir une connexion sur le serveur Debian (car le LAN est autorisé à sortir partout). Il s’agit alors, du côté Debian, d’une connexion établie, puisque non initiée par elle.
¶ Création d'une première règle
Dans un premier temps, nous allons autoriser le réseau DMZ à sortir partout sur IPv4, comme ce qui existe par défaut sur l’interface LAN :
Rendez-vous sur le menu Firewall / Rules / DMZ
Cliquer sur ajouter (add) ; il y a deux boutons : un pour ajouter en tête de liste, l’autre pour ajouter en fin de liste.
- Action : pass ; la règle autorise le passage du paquet
- Interface : DMZ ; l'interface par laquelle entre le paquet sur pfSense
- Famille d’adresses : IPv4
- Protocole : any (= n'importe quel protocole)
- Source : DMZ subnets ; ceci désigne la plage IP associée au réseau DMZ (ici 10.100.2.0/24) ainsi que tous les sous-réseaux associés (subnets) ; il s'agit donc toute machine située (et correctement identifiée) dans ce réseau
- Destination : any ; le paquet peut avoir n’importe quelle destination
- Log : cocher si on veut avoir un journal spécifique de cette règle ; dans le cas présent ce n’est pas utile, car énormément d’informations variées vont passer par cette règle. Mais on peut vouloir dans certains cas avoir une traçabilité complète de tout le trafic (il faut prévoir le stockage en conséquence)
- Description : une description du rôle de cette règle (texte libre)
Validez, et appliquez les modifications (pour que la règle soit activée)
Les règles ACL sur DMZ : il y a désormais la règle que nous verrons de créer.
Dès lors, la VM Debian doit pouvoir accéder à Internet :
Lancement d’un ping vers l’IP 1.1.1.1 depuis la VM Debian via la connexion SSH depuis la VM Windows. Un ping vers pfSense fonctionne également.
Sur l’écran webadmin pfSense (qu’il faut rafraîchir), on voit la quantité de données qui passe par la règle, ainsi que le nombre d’états actifs :
L’information contient un lien vers la table des états :
On voit ici la « trace » du PING lancé depuis cette VM vers 1.1.1.1
Avant d’aller plus loin, modifiez la configuration du serveur Debian pour qu’il ait l’adresse IP fixe 10.X.2.10/24 sur son interface connectée dans la DMZ.
Indice :
Et enfin, il convient de désactiver le service DHCP sur le réseau DMZ.
¶ Mise en place de règles plus strictes
Les règles de base que nous venons de mettre en place sont bien évidemment trop permissives si on veut garantir un minimum de maîtrise et de sécurité sur les échanges réseau.
Nous allons mettre en place maintenant une politique plus fine.
¶ Désactivation de la règle "anti-lockout"
La première règle visible sur l'interface LAN est une règle système évitant de perdre accidentellement l'accès à l'interface webadmin. Pour plus de clarté, nous allons la désactiver, depuis le menu system > advanced > admin access :
L'accès ne sera pas perdu, grâce à la règle restante qui autorise tout le trafic depuis le réseau LAN.
¶ Règles pour le réseau LAN
-
on désactive la règle déjà présente qui autorise le trafic IPv6. Il ne reste alors qu'une seule règle :
-
1/ Seul l’administrateur peut se connecter en HTTP (tcp/80) à l’interface web de pfSense. Créer pour cela un alias IP de l’adresse 10.X.1.50 ainsi :
-
2/ Seul l'administrateur peut se connecter en SSH (tcp/22) sur le serveur Debian. (Créer un alias IP de 10.X.2.10 = SERVEUR_WEB)
-
3/ Les hôtes du LAN peuvent se connecter au service DNS (udp/53) de pfSense ("this firewall")
-
4/ Toute autre connexion à pfSense est bloquée
-
5/ Les hôtes du LAN ne peuvent pas joindre la DMZ
-
6/Les hôtes du LAN peuvent se connecter sur tout site web sur internet (http ou https). Créer un alias de ports pour ces deux protocoles :
-
7/ Tout autre trafic est bloqué.
¶ Règles pour le réseau DMZ
- 1/ Aucun hôte de la DMZ n’est autorisé à contacter pfSense, sauf le service DNS
- 2/ Aucun hôte de la DMZ n’est autorisé à contacter le réseau LAN
- 3/ Le serveur Debian n’est pas autorisé à contacter une adresse IP RFC1918 (Créer un alias pour désigner les trois réseaux RFC1918)
- 4/ Les hôtes de la DMZ peuvent se connecter librement à Internet (Pour l’exemple, car cette règle n’est pas très sécurisée)
¶ Règles pour le WAN
- 1/ Toute connexion entrante sur le port tcp/80 (http) est acceptée et redirigée vers le serveur WEB (VM Debian)
Attention cette entrée est liée à une règle NAT/PAT, il faut donc utiliser le menu firewall / NAT pour la créer (pfSense crée la règle de firewall automatiquement avec la règle NAT)
- 2/ Les
ping(icmp - echo request) sont autorisés depuis internet sur l'adresse IP WAN du pfSense - 3/ Toute autre connexion entrante est bloquée.
¶ Une dernière modification
- Autorisez les machines du LAN à se connecter au serveur WEB de la DMZ (en http, sur le port 80)
¶ Synthèse (corrigés)
jouez le jeu ! ne dévoilez les réponses qu'après avoir créé vos propres règles !
¶ Pour aller plus loin
Voici enfin quelques ressources pour approfondir le sujet :
- Un article de Provya sur la configuration du firewall pfSense selon les recommandations de l’ANSSI
- Informations détaillées sur le fonctionnement des règles de pare-feu dans la documentation pfSense
