¶ 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 :
Nous allons partir depuis le miniLAB avec les deux Debian située pour le moment dans le LAN, puis adapter en conséquence.
Toutes les VM sont éteintes.
Démarrez la VM pfSense.
¶ Configuration du LAN
Nous allons dans un premier temps configurer l’adresse IP LAN (option 2 de la console).
La valeur
xsur le schéma est personnelle et vous est attribuée en début de séance. Si vous réalisez ce TP en solo, utilisez la valeur100.
- 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 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.
¶ 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.
Démarrez la VM Debian GUI et ouvrez 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.
Si vous avez déjà effectué la configurationinitiale de pfSense, vous pouvez relancer le wizard depuis le menu system.
Le wizard va vous permettre de configurer pfSense ainsi :
- 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 du réseau DMZ
Ajoutez 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 :
Redémarrez ensuite pfSense (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 de configuration :
- 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écessaire 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 Cliente GUI en utilisant un bail statique sur le serveur DHCP :
- Affichez les baux en cours, la VM doit apparaître (sinon, renouvelez son bail) :
La page d’état des baux DHCP de pfSense : un seul bail en cours sur LAN, pour la VM Cliente.
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 GUI (vous pouvez par exemple la redémarrer).
L’état des baux de pfSense confirme ensuite 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
Il est par défaut déjà activé, sauf si vous avez réalisé la configuration initiale de pfSense.
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
La sélection multiple est possible ici en maintenant enfonce la touche Ctrl
Sauvegardez et appliquez les changements.
¶ Gestion du serveur
¶ Déplacement sur DMZ
Désormais, nous allons déplacer la VM Debian core dont l’interface est connectée sur le réseau interne LAN.
La VM étant éteinte, connectez-la sur le réseau DMZ depuis l'interface de VirtualBox, puis démarrez-la.
¶ Modification de l'IP fixe
Depuis la console, il faut modifier son adresse IP fixe selon notre contexte. Il faut reprendre pour cela la méthode habituelle (modifier le fichier /etc/network/interfaces), telle que ce qui a été fait lors de la finalisation du miniLAB, avec ces éléments :
address 10.x.2.10/24
gateway 10.x.2.1
dns-nameservers 10.x.2.1
¶ Test SSH
Après redémarrage du serveur debian-core, il doit être possible de se connecter en ssh sur debian-core depuis la VM GUI :
ssh pascal@10.x.2.10
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 :
# essayez :
ping -c4 1.1.1.1
# ou encore
ping -c4 10.x.2.1
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 (ici10.x.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 :
# ping d'une ip publique :
ping -c4 1.1.1.1
# ou encore de la passerelle locale :
ping -c4 10.x.2.1
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, nous allons installer sur le serveur Debian un serveur web Nginx :
sudo apt update && sudo apt upgrade
sudo apt install nginx
systemctl status nginx
Enfin, le réseau DMZ n'étant pas censé accueillir "d'invités", il convient de désactiver le service DHCP associé, depuis le webadmin de pfSense.
¶ 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’adresse10.x.1.50ainsi :
-
2/ Seul l'administrateur peut se connecter en SSH (
tcp/22) sur le serveur Debian. (Créer un alias IP de10.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 menufirewall > NATpour 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
