Dans le cadre de la mise en place de stratégies de sécurité pour les systèmes d’information, l’accent doit être mis sur la manière dont les utilisateurs interagissent avec Internet. Comme nous l’avons exploré dans les chapitres précédents, le filtrage des flux Internet et l’emploi de serveurs proxy filtrants sont des mesures fondamentales pour diminuer significativement les risques en ligne. Cependant, ces techniques peuvent être efficacement complétées par d’autres méthodes, telles que le filtrage DNS.
Le filtrage DNS, qui repose sur le rôle central du Domain Name System dans la résolution des noms de domaine, offre une opportunité supplémentaire de réguler l’accès à des sites web spécifiques. Cette approche est largement adoptée par les fournisseurs d’accès Internet pour une variété de raisons, y compris la sécurité, la conformité réglementaire et le contrôle parental. Elle permet de bloquer proactivement l’accès aux sites web potentiellement dangereux ou non conformes aux politiques définies, en intervenant dès la phase de résolution de nom de domaine.
Bon à savoir :
Dans le serveur proxy filtrant, le filtrage se fera au niveau de la requête HTTP alors que le filtrage DNS se fera en inspectant la requête DNS
PfSense propose un package nommée pfBlockerNG qui va agir en tant qu’intermédiaire entre les machines clients et le serveur DNS de l’entreprise.
PfBlockerNG fonctionne de manière similaire à un proxy web filtrant, mais au lieu de se concentrer sur les requêtes HTTP, il cible les requêtes DNS. Il intègre des listes noires et blanches comprenant des domaines de sites publicitaires (remplaçant ainsi des outils comme ADBLOCK), ainsi que des IP ou domaines à réputation négative, comme ceux impliqués dans le phishing. Ces listes, nommées DNSBL (DNS Block List), permettent également de bloquer des systèmes autonomes (AS) pour une sécurité accrue.
Bon à savoir :
Un Système Autonome (AS) est un ensemble de réseaux IP sous une seule administration sur Internet
Installation de pfBlockerNG
pfBlocker est fourni sous forme de Package, qu’il faudra installer en déroulant le menu » System » puis « package Manager ».
Pour installer pfBlockerNG dans pfSense, accédez à l’onglet “Available Packages” dans la barre de recherche. Saisissez « pfblockerng » dans le champ « search term », puis lancez la recherche en cliquant sur « Search ». Une fois pfBlockerNG affiché, procédez à son installation en cliquant sur le bouton « Install ».
Après avoir cliqué sur le bouton « Confirm » l’installation se lance.
L’outil pfBlockerNG est disponible dans le menu « Firewall », nous allons nous y rendre pour le configurer.
Lors du premier accès à pfBlockerNG, nous avons accès à l’assistant de configuration, plus précisément à la page de bienvenue, nous cliquerons sur le bouton Next deux fois, pour commencer le paramétrage de pfBlockerNG.
Nous devons sélectionner qu’elle est notre interface inbound et outbound. L’interface « inbound » est l’interface qui accueille le flux à destination de l’intérieur de notre réseau, en d’autres termes, c’est l’interface LAN. L’interface outbound, c’est l’interface qui va accueillir les flux à destination de l’extérieur de notre réseau, généralement l’interface WAN.
En considérant cette description de ce qu’est l’interface inbound, qui est le trafic entrant et outbound le trafic sortant, nous sélectionnerons l’interface WAN dans la liste de sélection « Select Inbound Firewall Interface » et LAN dans la liste de sélection « Select outbound Firewall interface ».
Traditionnellement, une VIP est en effet utilisée dans des environnements de réseau pour des fonctions telles que la répartition de charge (load balancing) ou la redondance, permettant à plusieurs serveurs ou dispositifs de répondre à la même adresse IP. Cette approche facilite la gestion du trafic réseau et augmente la disponibilité des services, puisque la VIP peut être automatiquement réaffectée à un autre serveur en cas de défaillance du serveur principal.
Cependant, dans le contexte de pfBlockerNG, l’expression « VIP address » est utilisée de manière un peu différente. Ici, elle désigne une adresse IP spécifiée pour recevoir le trafic qui a sera bloqué ou filtré par les règles de pfBlockerNG. Cette utilisation s’écarte de la notion traditionnelle de VIP en ce sens qu’elle n’est pas destinée à la répartition de charge ou à la redondance, mais plutôt comme une méthode pour gérer et isoler le trafic non autorisé ou indésirable.
En spécifiant une adresse IP en dehors des plages normalement utilisées sur les réseaux configurés sur Pfsense, on s’assure que le trafic bloqué est dirigé vers un « cul-de-sac » où il ne peut ni affecter le réseau ni atteindre des ressources légitimes. Cette pratique peut également faciliter le monitoring et l’audit du trafic bloqué, car toute activité dirigée vers cette adresse peut être considérée comme suspecte ou non désirée.
Par défaut l’option DNSBL (Domain Name System Block List) Whitelist est activé. Comme souvent, dans des systèmes de sécurités visant à bloquer du trafic, il se peut que nous ayons des faux-positifs, c’est-à-dire du trafic légitime qui soit bloqué. Pour éviter les désagréments provoquer par un blocage non désiré, nous pouvons indiquer une liste d’adresse IP qui ne doit pas être bloquer. Nous laisserons donc cette option activée.
Dans notre lab, nous sommes en ipv4, il n’est donc pas forcément nécessaire d’activer IPv6BL.
Nous avons fini la configuration de PfBlockerNG
pfBlockerNG met à jour ses données pour nous garantir que votre installation de pfBlockerNG fonctionne avec les données les plus récentes et les plus pertinentes pour le filtrage du trafic. Par défaut une tâche planifier s’exécute toutes les heures pour maintenir ses informations à jours.
Nous affinerons notre configuration en nous rendant dans l’onglet « General », dans la section « IP Interface/Rules Configuration » nous activons l’option « Floating Rules » et « Kill states ».
L’option « Floating rules » nous offrira une interface de gestion spécifique, ce qui aura l’avantage d’apporter des options supplémentaires (par exemple appliquer une règle sur plusieurs interfaces) en plus de séparer les règles de notre pare-feu au règles dédiées à PfBlockerNG.
L’option « kill states » va tuer les connexions vers ou en provenance d’adresse IP indésirables ou non autorisées.
Nous validerons cette modification en cliquant sur le bouton « Save IP settings »
Pour que les modifications soit pris en compte, nous devons recharger la configuration en nous rendant dans l’onglet Update, puis nous sélectionnerons « Reload » puis « All » et nous terminerons par cliquer sur le bouton « Run » pour recharger la nouvelle configuration.
Dans la section Log, nous pouvons suivre l’état d’avancement de notre mise à jour.
Gestion des listes de blocage
La gestion des adresses Ipv4 qui vont être bloquées par PfBlockerNG est à administrable depuis l’interface de gestion de pfBlockerNG, disponible en déroulant le menu Firewall où nous sélectionnerons PfBlockerNG.
Nous nous rendrons ensuite sur l’onglet « IP » où nous sélectionnerons IPv4. Nous avons alors accès à la liste des adresses IP bloqué. Dans la liste configurée par défaut, nous avons l’action « Deny Outbound », c’est-à-dire une interdiction au niveau des flux sortants, c’est-à-dire, dans notre contexte que les utilisateurs de notre LAN ne pourront pas se rendre sur les adresses IP présentent dans la liste « PR1 ». Il peut être pertinent d’interdire les flux sortants, comme c’est actuellement le cas mais aussi les flux entrant en provenant des IP contenu dans cette liste. Ainsi nos utilisateurs n’auront pas le droit d’accéder à cette liste mais les adresses IP contenu dans cette liste seront bloquées par PfBlockerNG, cela se fera en sélectionnant « Deny Both » dans la colonne action.
Pour voir le contenu de cette liste, nous cliquerons sur l’icône crayon en fin de ligne.
Nous voyons que cette liste est en réalité plusieurs listes émanant de plusieurs fournisseurs. Pour voir le contenu d’une liste, il nous suffira de copier son url puis de la coller dans la barre d’adresse d’un navigateur web.
Les listes présentes dans la section « IPv4 Source Definition » sont disponible dans l’onglet « Feeds ».
Les listes de blocage sont réparties en catégories telles que IPv4, IPv6, ou listes noires DNS (DNSBL), et l’attrait d’activer toutes ces listes est compréhensible, visant à intensifier le blocage du trafic réseau. Cependant, cette stratégie comporte plusieurs conséquences potentielles. D’une part, elle peut conduire à une augmentation des faux positifs, entraînant un blocage inapproprié de trafic légitime. Cela se traduirait par un nombre accru de demandes d’assistance, imposant une charge de travail supplémentaire significative pour l’administrateur en charge du système de filtrage. En outre, l’activation exhaustive des listes pourrait également impacter négativement les performances de pfSense, à cause de la surcharge résultante du traitement d’un volume élevé de règles de filtrage.
Il serait plus prudent d’ajouter une liste, puis, la tester en production avant de passer à la suivante. Pour notre exemple, nous ajouterons à notre filtrage la « DNSBL easylist », pour cela, nous allons nous rendre dans la section « DNSBL Category » et nous cliquerons sur le signe « + » en fin de ligne. Cette liste, comme notre liste PR1 est une liste qui regroupe plusieurs listes.
Nous allons ensuite être redirigé vers la page de configuration DNSBL, nous activerons la liste en sélectionnant « ON » dans la liste déroulante « State » disponible dans la section « DNSBL Source Définition ».
Dans les settings, nous voyons qu’il n’y aura pas d’action ou plus précisément que l’action est désactivée, pour l’activer nous sélectionnerons « Unbound » qui est le serveur DNS intégrer à Pfsense.
Nous validerons cet ajout en cliquant sur le bouton « Save DNSBL Settings » disponible en bas de page.
Pour que la configuration soit prise en compte, nous devons mettre à jours nos règles. Nous nous rendrons dans l’onglet « Update », nous sélectionnerons l’option « Update », puis nous exécuterons ses paramètres en cliquant sur le bouton « Run ».
La liste que nous venons d’ajouter est un bloqueur de publicité, c’est cette même liste qui est souvent utilisé dans les plugins Adblock Plus, uBlock Origin, etc… Dans notre cas, cela permettra de ne pas à avoir besoin d’ajouter les bloqueurs sur chaque machine, le blocage se fera au niveau du DNS. Encore faut-il que les requêtes des DNS des clients transite par PfBlockerNG. Dans notre infrastructure, nous avons un serveur DNS intégré à l’Active Directory, si nous modifions le DNS de nos clients, les enregistrements contenus dans notre DNS local ne seront plus accessibles par nos machines clientes, ceux qui inclut toutes les résolutions de nom nécessaire pour l’authentification Kerberos. En revanche, nous pouvons configurer pfSense par l’intermédiaire du service « Unbound » pour relayer les requêtes DNS. En somme, le client enverra ses requêtes DNS vers Unbound où elles seront filtrées par PfBlockerNG, si la requête est jugée légitime, elle sera relayée à notre DNS, dans le cas contraire, elle sera envoyée vers l’adresse VIP [10.10.10.1] que nous avons configurer plus tôt.
Nous avons donc besoin d’un résolveur DNS dans Pfsense, pour activer cette fonctionnalité, nous déroulerons le menu « Services » et nous sélectionnerons « DNS Resolver ».
Nous activerons le service en cochant la case « Enable ».
Nous sélectionnerons ensuite les interfaces sur lesquels le service DNS Resolveur sera autorisé à recevoir, c’est-à-dire toutes les adresse. Nous autoriserons les interface LAN et WAN à faire des requêtes DNS soit sur le WAN soit sur le LAN
Pour ce qui concerne la configuration générale, nous en avons terminé, nous enregistrons cette configuration en cliquant sur le bouton « Save ».
Il nous faudra confirmer les changements en cliquant sur le bouton « Apply Change ».
Dans la section située plus bas sur cette page, nous trouvons deux options importantes : « Host Overrides » et « Domain Overrides ». La fonction « Host Overrides » vous donne la possibilité de définir une résolution DNS sur mesure pour un nom d’hôte déterminé. Autrement dit, vous pouvez manuellement assigner une adresse IP spécifique à un nom d’hôte donné au sein de votre réseau. Cela revient à créer un enregistrement de type A (pour IPv4) ou AAAA (pour IPv6), selon le protocole IP utilisé. D’autre part, l’option « Domain Overrides » est conçue pour orienter l’ensemble des requêtes concernant un domaine spécifique (et l’ensemble de ses sous-domaines) vers un serveur DNS dédié. Cette fonctionnalité est particulièrement utile pour orchestrer la résolution DNS de domaines complets au sein de votre infrastructure réseau.
À titre d’exemple, pour rediriger les requêtes DNS afin de résoudre les noms appartenant à notre domaine interne, nous préciserons notre domaine ainsi que l’adresse IP de notre serveur. Nous allons appliquer concrètement cet exemple pour configurer notre service de redirection DNS.
Dans le formulaire d’ajout de domaine, nous indiquerons notre domaine, l’adresse IP du serveur DNS qui gère cette zone. Nous pouvons également mettre une description même si cette option est facultative pour le bon fonctionnement. Nous terminerons en cliquant sur le bouton « Save » pour enregistrer cette configuration.
Nous devons voir dans la section « Domain Overrides », les informations que nous venons de renseigner.
Plus tôt, lorsque nous avions configurer l’authentification LDAPS, nous avions modifié la configuration de Pfsense afin qu’il utilise le serveur DNS de notre domaine pour résoudre les noms locaux, ce qui était nécessaire pour la résolution du Distinguished Name du certificat. De plus, nous avions créé un « Alias » DNS_PUBLIC lorsque nous avons traité du concept de filtrage dans pfSense.
Dans cette partie, nous avons rediriger les requêtes DNS de notre zone vers le serveur DNS intégrer à notre AD. Il est donc inutile de conserver notre Pfsense en tant que client DNS du serveur DNS local. Nous indiquerons donc un autre serveur DNS, cette fois-ci un DNS public. Ainsi, notre DNS Forwarder aura le rôle d’aiguilleur, soit la requête est destiné à notre domaine dans quel cas nous solliciterons le DNS local, soit la requête ne concerne pas notre domaine et elle sera redirigé vers un DNS public. Nous cloisonnerons ainsi nos requêtes DNS, ce qui nous permettra d’avoir un meilleur contrôle sur les requêtes DNS, ce qui peut être fortement utile si nous voulons augmenter le niveau de sécurité.
Dans pfSense, nous allons modifier le serveur DNS en déroulant le menu « System » puis en sélectionnant « General Settings ».
Dans la section General Server Settings, nous indiquerons une adresse DNS présente dans notre Alias DNS_PUBLIC. Pour ajouter, les autres adresses, il nous suffira de cliquer sur « Add DNS Server » et de renseigner l’adresse IP du server DNS.
Notre configuration devrait ressembler à cela :
Nous modifierons également le comportement du service DNS, nous l’avions précédemment modifié pour que les requêtes DNS soit seulement effectué par notre DNS local, nous redéfinissons ce paramètre en choisissant la valeur par défaut de pfSense, c’est-à-dire « Use local DNS (127.0.0.1),fall back to remote DNS Servers (Default) ».
Pour valider cette configuration, nous descendrons en bas de page et nous cliquerons sur le bouton « Save ».
Dans les règles de filtrages que nous avons configurées, nous avions autorisé que notre contrôleur de domaine à faire des requêtes DNS vers l’extérieur, nous devons donc modifier cette règle pour autoriser pfSense à faire des requêtes vers les DNS Public. Nous déroulerons le menu Firewall puis nous allons nous sélectionnerons « Rules ».
Pour modifier une règle, nous avons besoin de l’éditer, nous cliquerons sur l’icône « crayon » en fin de ligne.
Nous modifierons la source et nous autoriserons seulement l’interface WAN, c’est-à-dire « WAN address » à effectuer des requêtes sur les DNS Public.
On en profitera pour modifier la description.
Nous sauvegardons cette configuration en cliquant sur le bouton « Save ».
Nous appliquerons ensuite les changements.
Nous testerons ensuite que nous puissions exécuter des requêtes DNS à l’aide de l’utilitaire DNS Lookup disponible dans le menu « Diagnostics ».
Nous devrions voir le résultat de la résolution qui se traduit par une adresse en IPv4 et une adresse en IPv6, nous aurons également les délais de résolution.
Nous testerons la résolution de nom en local.
Depuis notre machine cliente sous Windows 11, nous tenterons de nous connecter à un site internet qui a habituellement des pubs, nous ne devrions pas les voir.
La combinaison de Squid et de PfBlockerNG permet une gestion granulaire du trafic, du filtrage DNS au filtrage d’URL, en passant par le contrôle d’accès basé sur des politiques. De plus, Squid améliore les performances du réseau grâce à son cache, tandis que pfBlockerNG et SquidGuard réduisent le risque de charger des contenus indésirable ou inutiles.
En somme, l’utilisation combinée de pfBlockerNG et de Squid avec SquidGuard dans pfSense crée un écosystème robuste pour le filtrage de contenu, le contrôle d’accès et l’amélioration de la sécurité réseau, tout en optimisant l’utilisation de la bande passante et les performances du réseau.