Filtrage avec Pfsense

Haute disponibilité

Il n’est pas rare que des professionnels utilisent le terme ‘pare-feu’ pour désigner un UTM, bien que le pare-feu ne soit qu’une fonctionnalité de l’UTM. Cette confusion découle du rôle prédominant du pare-feu dans le contrôle du trafic réseau, ce qui conduit souvent à une utilisation interchangeables des termes.

Si le rôle d’un pare-feu se limite à du filtrage par adresse IP ou par port, l’usage d’un UTM va permettre, entre autres, d’étendre les possibilités de filtrage.

Le filtrage demeure un pilier essentiel pour réguler et sécuriser le trafic circulant à travers un réseau informatique. PfSense, offre une diversité de méthodes de filtrage, chacune conçue pour répondre à des besoins spécifiques en matière de sécurité. Dans ce chapitre nous nous concentrerons sur les filtrages suivants :

• Filtrage par Adresse IP et Port :

Le filtrage par adresse IP et port représente une approche centrale dans la gestion du trafic réseau. En contrôlant le flux en fonction des adresses IP source et destination, ainsi que des numéros de port, cette méthode offre une gestion fine et précise des connexions. Elle permet aux administrateurs de définir des règles spécifiques, autorisant ou bloquant le trafic en fonction du destinataire, de l’expéditeur ou encore des ports qui seront utilisés.

• Filtrage Web :

L’application de politiques de filtrage web dans pfSense offre une protection supplémentaire en restreignant l’accès à des catégories de sites spécifiques. Reposant sur des critères tels que le contenu, les mots-clés, ou d’autres caractéristiques, cette méthode s’avère particulièrement utile pour garantir une utilisation responsable d’Internet, tout en réduisant l’exposition aux menaces en ligne.

• Filtrage DNS :

Le filtrage DNS constitue une ligne de défense contre les menaces en ligne et permet un contrôle avancé sur l’accès à Internet. En bloquant ou en autorisant l’accès à des domaines spécifiques, cette méthode offre une granularité dans la gestion des ressources accessibles depuis le réseau. Elle permet également de prévenir l’accès à des sites potentiellement malveillants, renforçant ainsi la sécurité globale du réseau.

Le filtrage par adresse IP et par port

À l’arrivée d’un paquet sur pfSense, le système examine les informations extraites de son en-tête, telles que les adresses IP et les ports de l’expéditeur et du destinataire. Ces données sont utilisées par l’UTM pour vérifier la conformité aux règles de filtrage. Si une règle correspondante est trouvée, l’action associée (autorisation ou blocage) est appliquée. En l’absence de règle correspondante, le paquet est rejeté, car le pare-feu ne dispose pas d’instructions claires sur la façon de le traiter.

Nous avons donc 3 actions possibles :

• Autoriser (Permit) :

Lorsqu’une règle de filtrage indique l’action “Permit”, le pare-feu autorise le passage du paquet en fonction des critères définis. Cela signifie que le paquet est autorisé à atteindre sa destination conformément aux règles définies. L’autorisation est généralement utilisée pour permettre le passage du trafic considéré comme légitime et sécurisé.

• Bloquer (Deny) :

L’action “Deny” est une mesure restrictive qui interdit le passage du paquet en fonction des règles définies. Cette action est couramment utilisée pour empêcher l’accès à des ressources spécifiques ou pour bloquer des communications jugées indésirables, tout en fournissant une trace des événements.

• Refus Implicite (Implicit Deny) :

Si aucun des critères de filtrage ne correspond à un paquet, le pare-feu applique le refus implicite. Cela signifie que, par défaut, le pare-feu rejette le paquet silencieusement sans indication explicite ou notification. Il s’agit d’une mesure de sécurité par défaut pour tout trafic qui ne correspond à aucune règle explicite, protégeant ainsi le réseau contre un accès non autorisé.

En d’autres termes dès lors que nous utilisons un pare-feu soit le paquet est explicitement autorisé soit il est refusé. Il est important de noter que les règles sont appliquées au paquet de façon séquentielle, c’est-à-dire qu’il y aura un ordre. A la réception du paquet par pfSense, le pare-feu va vérifier s’il existe une correspondance avec la première règle, si ce n’est pas le cas, il vérifiera la correspondance avec la suivante et ainsi de suite. PfSense s’arrêtera de vérifier les correspondances dés qu’il en trouvera une, c’est-à-dire, si dans notre pare-feu nous avons 10 règles et que pfSense trouve une correspondance dès la deuxième règle, il n’ira pas plus loin dans sa recherche de correspondance. Pour prendre un exemple concret, imaginons un pare-feu avec une première règle qui bloquerais tout et une seconde règle qui autoriserait tout. Vu que la première correspondrait, le pare-feu n’ira jamais lire la seconde règle.

Mise en place de règle de pare-feu

Précédemment, lorsque nous avons configurer le protocole XML-RPC, nous avons constaté que par défaut lorsque nous ajoutons une interface et que celle-ci n’est pas assigner en tant qu’interface LAN mais que OPT, l’interface n’as aucune règle de pare-feu préconfigurer. De ce fait, les échanges entre nos deux pfSense n’était pas explicitement autorisés, donc implicitement refusés. Il nous a fallut créer une règle de pare-feu pour permettre à nos deux pfSense de communiquer. La règle que nous avions mis en place est trop permissive. Pour rappel, nous avions autorisés toutes les communications en TCP. Nous allons modifier cette règle pour la rendre plus précise, sur pfSense1 (pfSense Master). Nous allons nous rendre dans le tableau des règles de l’interface OPT2, en sélectionnant « Rules » dans le menu déroulant « Firewall » qui correspond à l’interface par laquelle les deux pfSense sont configurées pour faire transiter la configuration à l’aide du protocole XML-RPC.

Ensuite, nous nous rendrons sur l’onglet OPT2 qui est l’interface par laquelle les deux pfSense sont configurées pour faire transiter la configuration à l’aide du protocole XML-RPC.

Dans le fonctionnement de pfSense, les informations XML-RPC sont encapsulé dans du HTTPS, nous pourrions donc n’autoriser que le trafic HTTPS entre pfsense1 et pfsense2. Nous allons donc autoriser le protocole HTTPS sur le réseau OPT2. Pour modifier une règle nous allons cliquer sur le bouton Modifier représenté par l’icône crayons.

Dans le formulaire, nous allons nous rendre dans la section « Source ». Dans la liste déroulante source, nous sélectionnerons « OPT2 subnet » qui correspond au réseau 10.3.0.0/24.

Dans la section « Destination », nous sélectionnerons le réseau OPT2, nous préciserons nous préciserons le protocole en sélectionnant « HTTPS » dans la liste déroulante « From » et « To ».

Il peut s’avérer pratique d’ajouter une description, surtout lors des phases d’audit des pares-feux.

Nous validerons cette configuration en cliquant sur le bouton « Save ».

Cette règle devra être ensuite appliquer en cliquant sur le bouton « Apply change ».

Nous testerons que le XML-RPC est toujours fonctionnel. Nous déroulerons Status, pour accéder à l’outil Filter Reload et nous lancerons une synchronisation de configuration

Nous devrions avoir un message en fin de processus qui nous indiquer que la synchronisation s’est déroulée avec succès.

Règles de filtrage à déployer dans un LAN.

En général, un utilisateur devrait pouvoir accéder à Internet ainsi qu’aux divers services notamment les services proposés par le contrôleur de domaine disponible dans le système d’information. Pour la consultation de sites web, les requêtes HTTP, HTTPS, et DNS doivent être autorisées. Cependant, par défaut sur pfSense, les utilisateurs du réseau local (LAN) ont un accès illimité, ce qui peut poser des problèmes de sécurité. Dans un contexte axé sur la sécurité, les utilisateurs doivent être limités au strict minimum. Contrairement à la configuration par défaut sur pfSense, l’accès des utilisateurs devrait être restreint aux protocoles HTTP, HTTPS et DNS.

Avant de passer à la mise en place des règles arrêtons-nous pour analyser le besoin. Aujourd’hui la majorité des sites internet utilisent le protocole HTTPS. De plus les utilisateurs ne devraient utiliser que le DNS local, c’est-à-dire celui qui est intégré à l’Active Directory. Par conséquent, nous allons configurer les règles qui vont dans ce sens. Nous créerons une première règle de sortir des requêtes HTTPS.

La seconde règle va concerner les autorisation de notre contrôleur de domaine dont les requêtes DNS, nous rentrerons en détails sur ce sujet après avoir créer la régle pour autoriser les requêtes DNS.

Autoriser les utilisateurs du LAN à envoyer des requêtes HTTPS

Dans pfsense, nous allons dérouler le menu « Firewall » et sélectionner « Rules ».

Nous supprimerons les deux règles créer par défaut, nous les sélectionnerons, puis nous créerons sur le bouton « Delete », nous oublierons d’appliquer les changements après avoir confirmer notre choix.

Nous créerons ensuite une nouvelle règle, nous cliquerons sur l’un des deux boutons « Add ».

Dans la section « Source », dans la liste déroulante, nous sélectionnerons « LAN subnets ».

Dans la section « Destination », nous déroulerons la liste déroulante « From » et nous sélectionnerons HTTPS, nous en ferons de même pour la liste déroulante « To ».

Nous enregistrons et appliquerons cette configuration.

Autoriser les utilisateurs à faire des requêtes sur le contrôleur de domaine

Un contrôleur de domaine (Domain Controller en anglais) est un serveur qui est géré par le service d’annuaire Active Directory. Ces serveurs occupent une position centrale dans les systèmes d’information en fournissant divers services tels que la gestion des identités, l’authentification des utilisateurs, et la gestion des ressources du réseau. Les principales fonctions d’un contrôleur de domaine sont les suivants :

• Service d’Annuaire : Le contrôleur de domaine stocke une base de données d’annuaire qui contient des informations sur les objets du réseau, tels que les utilisateurs, les groupes, les ordinateurs et d’autres ressources. Cela permet une gestion centralisée des identités et des ressources.
• Authentification des Utilisateurs : Lorsqu’un utilisateur tente de se connecter au réseau, le contrôleur de domaine vérifie les informations d’identification de l’utilisateur et authentifie l’accès. Ceci est réalisé en utilisant le protocole d’authentification Kerberos.
• Gestion des Politiques de Sécurité : Les contrôleurs de domaine permettent de définir et de distribuer des politiques de sécurité à travers le réseau. Cela inclut des politiques telles que les stratégies de mot de passe, les stratégies de verrouillage de compte, et d’autres paramètres de sécurité.
• Réplication d’Annuaire : Dans les environnements avec plusieurs contrôleurs de domaine, les informations d’annuaire sont répliquées entre les contrôleurs de domaine pour assurer la cohérence des données.
• Autorisation d’Accès aux Ressources : Les contrôleurs de domaine permettent de définir des autorisations d’accès aux ressources du réseau en associant des utilisateurs et des groupes à des autorisations spécifiques.
• Distribution des Services : Certains services réseau, tels que les services d’impression et les partages de fichiers, peuvent être gérés et distribués par le contrôleur de domaine.
• Service DNS : Active Directory dépend fortement du service DNS (Domain Name System). Les contrôleurs de domaine fournissent également des services DNS pour résoudre les noms d’ordinateurs en adresses IP et vice versa.

En prenant en considération les services proposées par un contrôleur de domaine, nous allons pouvoir définir les ports qui sont sollicités.

Transport	Service	Port	Utilisation
TCP/UDP	Kerberos	88	Authentification sécurisée
TCP	LDAP	389	Accès aux services d’annuaire
TCP	LDAPS	636	Accès aux services d’annuaire de manière sécurisée
TCP	LDAP pour Catalogue Global	3268	Recherche dans le catalogue global (non sécurisé)
TCP	LDAPS pour Catalogue Global	3269	Recherche dans le catalogue global (sécurisé)
TCP/UDP	DNS	53	Résolution de noms de domaine
TCP	SMB over TCP	445	Partage de fichiers et d’imprimantes (TCP)
TCP	NETBIOS	139	Services de noms et de sessions NetBIOS

A la lecture de ce tableau, nous devons créer 8 règles et cela n’est que pour autoriser le strictement minimum d’un seul serveur de l’infrastructure. En extrapolant, nous pouvons en déduire, qu’au sein d’un système d’information réel, nous allons avoir un très grand nombre de règles, nous pouvons vite nous y perdre. PfSence offre la possibilité de regrouper un ensemble de protocoles au sein d’un alias, nous créerons deux Alias, ce qui nous permettra de réduire le nombre de règle à 2. Un alias regroupera les services qui peuvent être utiliser en TCP et UDP, le second alias les services qui n’utilisent que le TCP.

Création d’un alias

Dans l’interface d’administration WEB de pfSense, nous déroulerons le menu « Firewall » puis nous allons nous rendre dans le formulaire de création d’alias en sélection « Aliases ».

Nous allons créer des alias qui seront associées à des ports, nous allons donc nous rendre dans l’onglet « Port », puis nous cliquerons sur le bouton « Add ».

Dans la section « Properties » de notre formulaire de création d’alias, nous allons donner un nom à notre alias, ensuite, nous donnerons une description, ce qui pourra faciliter les audits ultérieurs. Nous commencerons par créer l’alias qui regroupera les services basés sur TCP/UDP. Dans cette documentation, il sera nommé DC_TCP_UDP.

Dans le champ Port de la section « Port(s) », nous ajouterons les numéros des ports qui peuvent être utiliser avec le TCP ou le UDP soit le tableau suivant

Transport	Service	Port	Utilisation
TCP/UDP	Kerberos	88	Authentification sécurisée
TCP/UDP	DNS	53	Résolution de noms de domaine

Nous commencerons par le service Kerberos, après avoir indiqué son numéro de port et une description, nous cliquerons sur le bouton « Add Port » pour ajouter le second port.

Après avoir ajouté nos deux ports, nous cliquerons sur le bouton « Save» pour valider la création de cet alias.

Comme très souvent dans pfSense, pour qu’une modification soit prise en compte, il nous faut confirmer ce changement en cliquant sur le bouton « Apply Changes ».

Nous procéderons à la création de l’alias qui regroupera les ports qui s’appuient au protocoles TCP en observant le même processus mais cette fois-ci pour les protocoles suivants :

Transport	Service	Port	Utilisation
TCP	LDAP	389	Accès aux services d’annuaire
TCP	LDAPS	636	Accès aux services d’annuaire de manière sécurisée
TCP	LDAP pour Catalogue Global	3268	Recherche dans le catalogue global (non sécurisé)
TCP	LDAPS pour Catalogue Global	3269	Recherche dans le catalogue global (sécurisé)
TCP	SMB over TCP	445	Partage de fichiers et d’imprimantes (TCP)
TCP	NETBIOS	139	Services de noms et de sessions NetBIOS

Les alias que nous venons de créer vont être par la suite utiliser pour créer nos règles. Avant de créer nos règles de pare-feu et vu que nous sommes en train de configurer, nous vous proposons de créer un autre alias, cette fois il ne regroupera pas des ports mais des adresses IP. En effet, les bonnes pratiques imposent de posséder au moins deux contrôleurs de domaines. Même si dans notre lab, nous en avons créé qu’un seul, nous allons voir comment créer un alias pour regrouper plusieurs adresses IP.

Nous allons nous rendre dans l’onglet « IP », puis nous cliquerons sur le bouton « Add ».

Nous renseignerons les adresses IP de nos contrôleurs de domaines. Dans notre contexte, nous n’en possédant qu’un seul, c’est son adresse que nous ajouterons. Nous terminerons la création de cet alias en cliquant sur le bouton « Save » et nous appliquerons les changements en cliquant sur le bouton « Apply changes ».

Nous en profiterons pour créer un alias qui regroupe le protocole http et https et que sera nommé HTTP_S.

Création règle de pare-feu pour le contrôleur de domaine

Après avoir dérouler le menu « Firewall », nous sélectionnerons le sous-menu « Rules ».

Après nous être rendu sur l’onglet LAN, nous cliquerons sur le bouton, « Add », vu que nous souhaitons la mettre à la suite, nous cliquerons sur le second bouton « Add », celui qui est accompagné d’une flèche vers le bas.

Nous commencerons par les protocoles qui se basent sur TCP/UDP. Dans la section « Edite Firewall Rule », nous déroulerons la liste déroulante « Protocol » et nous sélectionnerons « TCP/UDP ».

Dans la section « Source », nous sélectionnerons dans la liste déroulante « LAN subnets ».

Dans la section « Destination », après avoir sélectionner dans la liste déroulante « Address or Alias », nous renseignerons dans le champ à côté le nom de notre alias qui regroupe les adresses IP des contrôleurs de domaine. Dans le champ « From », nous laisserons sur (Other) puis dans le champ « Custom », nous renseignerons le nom de l’alias associer aux ports qui s’appuient sur le TCP/UDP.

Après avoir indiquer une description de la règle, nous cliquerons sur le bouton « Save » et nous appliquerons ce changement.

Nous copierons cette régler et la modifierons pour qu’elle corresponde à nos besoins, c’est-à-dire, autoriser les connexions de nos clients vers les services hébergées par le contrôleur de domaine qui s’appuie sur le protocole TCP.

Dans le formulaire d’édition de la régle, nous modifierons le paramètre « Protocols » en sélectionnant dans la liste déroulante « TCP ».

Nous modifierons également le champ « Custom » dans la section « Destination », en y indiquant l’alias associer au service qui s’appuie sur le protocole TCP.

On modifiera également la description, puis nous cliquerons sur le bouton « Save » et nous appliquerons les changements.

Nous vérifierons que les utilisateurs sont toujours en mesure de se connecter depuis la machine cliente. Pour être certain que les identifiants de connexion ne soient pas dans le cache de la machine, pour faire le test, nous testerons un nouvel utilisateur dans l’AD puis nous tenterons de nous connecter avec sur notre poste client.

Création règle redirecteur DNS

La règle que nous avons précédemment mis en place, autorise les requêtes vers notre DNS local. Si cette configuration est suffisante pour résoudre les noms locaux, il ne permet pas de résoudre les noms publics, à moins, d’avoir créé l’enregistrement dans notre DNS local. Pour permettre de résoudre les noms publics, il est d’usage d’utiliser un redirecteur vers un DNS publique. Il existe plusieurs fournisseurs qui propose des DNS, parmi eux, nous pouvons lister :

• Google DNS : oogle peut enregistrer des informations, mais il affirme ne pas associer ces données à des informations d’identité personnelle.
• Cloudflare : Cloudflare prétend ne pas conserver les journaux d’adresses IP au-delà de 24 heures et respecte la confidentialité des utilisateurs.
• Quad9 : Quad9 respecte la confidentialité des utilisateurs et ne collecte pas d’informations personnelles identifiables.

Vu que nous sommes dans un contexte visant à améliorer la sécurité, nous vous proposons de nous orienter sur les DNS publique Quad9 et Cloudflare.

Configuration redirecteur DNS

Dans la console DNS de notre contrôleur de domaine, disponible depuis le tableau de bords et atteignable en déroulant le menu, nous allons sélectionner le serveur DNS, puis nous effectuerons un double-clic sur redirecteur

Nous cliquerons ensuite sur le bouton « Modifier » et nous ajouterons les addresses suivantes :

• 9.9.9.9 (Quad9)
• 112.112.112.112 (Quad9)
• 1.1.1.1 (CloudFlare)
• 1.0.0.1 (CloudFlare)

Une fois que nous avons ajouté les adresses IP de nos redirecteurs, nous cliquerons sur le bouton « Appliquer » puis nous fermerons la fenêtre en cliquant sur le bouton « OK ».

Création d’un alias DNS_PUBLIC

Plus tôt, nous avons vu que la création d’un alias pour regrouper au sein d’un même élèment plusieurs port, nous avons également vu que nous pouvions créer des alias basé sur les adresse IP. Nous procéderons de la même façon à la création d’un alias qui regrouperais la liste d’adresse IP configurer dans le paramètre « Redirecteur » des propriétés de notre serveur DNS.

Dans le menu « Firewall », nous sélectionnerons ensuite sur « Aliases ».

Après avoir vérifier que nous sommes bien dans l’onglet IP, nous cliquerons sur le bouton « Add ».

Comme nous l’avons fait précédemment en créant l’alias le contrôleur de domaine, après avoir donné un nom et une description à notre alias, nous renseignerons les 4 adresses IP de nos redirecteurs DNS, nous sauvegarderons les paramètres de cet alias en cliquant sur le bouton « Save » puis nous appliquerons les changement en cliquant sur le bouton « Apply changes »

Nous avons maintenant tout le nécessaire pour créer notre régle de pare-feu. Dans le menu Firewall, nous nous rendrons dans la page « Rules ».

Dans l’onglet LAN, cliquez sur le bouton « Add » avec la flèche vers le haut. En effet, précédemment, nous avions créé une règle permettant aux machines du réseau local (LAN) d’envoyer des requêtes exclusivement au DNS local (alias DC_TCP_UDP). Dans notre configuration, le contrôleur de domaine se trouve dans notre LAN. Par conséquent, si cette règle est positionnée avant celle qui autorise notre contrôleur de domaine à interroger les DNS publics, il ne sera pas autorisé à envoyer une requête DNS vers les DNS publics. Étant donné que la lecture des règles est séquentielle et qu’une fois qu’une règle peut s’appliquer, elle prend effet, le pare-feu n’ira pas au-delà dans la lecture des règles.

Dans la section « Edit Firewall Rule », nous sélectionnerons TCP/UDP.

Dans la section « Source », nous sélectionnerons « Address or Alias », puis dans le champ « Source Address » nous renseignerons l’alias de nos contrôleurs de domaine DC.

Dans la section « Destination », nous sélectionnerons également « Address or Alias » mais cette fois nous indiquerons le nom de l’alias faisant référence aux adresses IP des DNS configurer dans le redirecteur de notre serveur local DNS. Nous limiterons les autorisations de communication aux protocoles DNS.

Après avoir renseigné une description, nous cliquerons sur le bouton « Save » pour enregistrer cette configuration puis nous appliquerons les changements en cliquant sur le bouton « Apply changes ».

Depuis notre poste client, nous allons vérifier que nous avons bien un connexion Internet.

Organiser ses règles.

Organiser ses règles peut être considérer comme quelques choses de purement cosmétique mais qui en réalité nous fera gagner du temps sur les audits ou le maintien en condition opération. Nous créerons une catégorie

• DNS Public
• Internet
• Contrôleur de domaine »

Nous créerons des catégories à l’aide de l’outils « Separator ».

Après avoir renseigner un nom, nous cliquerons sur « Save ».

Nous allons ensuite déplacer cette ligne en la glissant juste avant la règle de pare-feu que nous avons créer pour autoriser le DC à envoyer des requêtes DNS vers les redirecteurs DNS que nous avons configurer. Nous validons cette modification en cliquant sur le bouton « Save ».

Nous créerons un deuxième séparateur qui regroupera les règles pour les connexion vers le WEB puis une dernière catégorie pour les règles concernant les autorisation liées aux connexion vers le contrôleur de de domaine.

La mise en place de règles de pare-feu basées sur le principe du moins de privilèges possible est une stratégie de base pour renforcer la sécurité des réseaux. En limitant l’accès aux ressources essentiellement et uniquement aux connexions nécessaires, on réduit significativement la surface d’attaque. Chaque règle doit être soigneusement définie en fonction des besoins spécifiques de l’infrastructure, en prenant en compte les protocoles, les ports, les adresses IP.

De plus, nous rappelons ici l’importance de maintenir une vigilance constante, de revoir régulièrement les règles du pare-feu pour les adapter aux évolutions de l’infrastructure, et de surveiller attentivement le trafic réseau pour détecter toute anomalie. En suivant ces principes, on établit une base solide pour renforcer la sécurité tout en facilitant la gestion efficace du trafic au sein du réseau.

Filtrage Web avec Pfsense, Squid & SquidGuard