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.

L’article Filtrage DNS et IP avec PfBlockerNG est apparu en premier sur Pandawan.

Le filtrage WEB

Le filtrage web contribue de manière indéniable à l’optimisation de la bande passante et de la sécurité informatique. Son intérêt est donc double, d’une part en bloquant l’accès à des sites internet gourmands en bande passante, le filtrage web contribue à une utilisation plus efficace des ressources réseau. Cela peut améliorer les performances globales du réseau, assurer une connectivité plus rapide et plus stable, et éviter la congestion inutile de la bande passante. D’autres part en restreignant l’accès à des sites potentiellement dangereux ou inappropriés, le filtrage web contribue à prévenir les infections par des logiciels malveillants. Le filtrage web est une composante à part entière de la stratégie de sécurité informatique, fournissant un moyen proactif de protéger le réseau, les utilisateurs et les données contre diverses menaces en ligne tout en favorisant un environnement de travail efficace et sûr.

Pour permettre de filtrer des sites WEB, nous devons mettre en place un outils d’inspection de requêtes http, en effet, dans l’entête de la requête nous retrouverons l’URL cible, cette URL sera ensuite comparée :

• Avec une Blacklist, si l’url est présente, l’accès sera alors refusé
• Avec une Whitelist, si l’url est présente, l’accès sera autorisé
  
  

Dans beaucoup de cas, une blacklist est utilisé, ainsi toutes les urls ne figurant pas dans la blacklist sera accepté. Dans la blacklist, nous retrouverons des urls, mais aussi des mots clés, si l’url contient un de ses mots clé alors le site ne sera pas accessible.

Différence entre proxy et filtrage WEB

Dans de très nombreux cas de figure, le filtrage WEB sera associé à un proxy, c’est pour cela que certain confond ses deux composants mais qui jouent un rôle bien distinct. Le filtrage WEB, comme nous l’avons écrit plus tôt, est un outil qui nous permet de bloquer ou d’autoriser l’accès à des sites internet. Le proxy quant à lui, est un serveur mandataire, c’est-à-dire que le client le sollicite pour accéder à des ressources sur internet et c’est le proxy qui va lui remettre les informations émanant de Internet. L’utilisateur ne sera ainsi jamais connecté directement sur Internet. L’intérêt du proxy est d’économiser la bande passante, en effet, lorsqu’un utilisateur demande une ressource sur un internet, il contactera le proxy, ensuite le proxy va rechercher cette ressource sur Internet pour la remettre à l’utilisateur mais en plus de faire cela, il va stocker cette ressource dans son cache et si un autre utilisateur fait la même demande, le proxy ira la récupérer directement dans son cache. Au vu du rôle central du serveur proxy, nous y installons la solution de filtrage mais il est tout à fait possible d’avoir un proxy sans solution de filtrage et il est également possible d’avoir une solution de filtrage sans proxy.

Dans pfSense, le filtrage web n’est pas composant autonome, mais plutôt une fonctionnalité qui nécessite l’association avec un serveur proxy web. Ce serveur proxy, appelé SQUID, est intégré à pfSense mais peut également être installé sur une machine dédiée. Pour des questions de faciliter, nous l’utiliserons avec pfSense.

Installation et configuration de SQUID.

SQUID n’est pas intégré nativement à pfSense, il nous faut l’installer. En effet, pfSense propose d’étendre ses outils en mettant à disposition des packages. L’ensemble de ses packages sont disponible en déroulant le menu « System » et en sélectionnant « Package Manager»

Nous nous rendrons ensuite dans l’onglet « Available Packages ». Dans le champ « Search Item » dans la section « Search », nous renseignerons le nom de l’outil que nous souhaitons installer et nous terminerons en cliquant sur le bouton « Search ».

Dans la liste des résultats, nous pouvons lire dans la description de « squid », que cela sera la version 3.5 de squid qui sera installé qui est une version qui date de juillet 2018, cette version n’est actuellement plus maintenue et comme nous pouvons nous en rendre compte en nous rendant à cette page, https://www.cvedetails.com/vulnerability-list/vendor_id-9950/product_id-17766/version_id-1468085/Squid-cache-Squid-3.5.28.html, cette version fait l’objet d’un très grand de CVE .

Bon à savoir :
Une CVE (Common Vulnerabilities and Exposures) est une identification unique attribuée à une vulnérabilité. C’est une référence standard pour suivre et échanger des informations sur les failles de sécurité, facilitant la communication et la gestion des risques.

De plus, en nous rendant dans la documentation de pfSense traitant des packages, à l’adresse suivante : https://docs.netgate.com/pfsense/en/latest/packages/list.html , nous pouvons lire que l’entreprise derrière pfSense préconise de ne pas l’installer et que ce package va disparaitre de pfSense dans un avenir proche.pour en savoir plus, nous voous invitons à vous rendre sur la documentation officiel de pfsense

Ce point nous permet d’intégrer dans cette documentation un autre concept de la sécurité, à savoir, s’assurer d’utiliser des versions d’outils qui soit maintenu par son éditeur. Lorsque l’éditeur indique une dépréciation, cette période de dépréciation des outils que nous utilisons devrait être une période où nous devrions rechercher des alternatifs. Une des alternatifs possible et c’est celle que nous mettrons en place dans cette documentation est l’installation de la dernière version de SQUID sur une machine dédiée. Cela nous permet à la fois d’avoir une version maintenue de SQUID mais aussi d’appliquer l’adage « Ne pas mettre tous ses œufs dans le même panier », en d’autres termes, il faut diversifier ses outils de renforcement de la sécurité. Laisser toutes la sécurité sur un équipements peut être vu comme un SPoF (Single Point of Failure).

Dans l’aricle «Installation Pfsense sur VMWare Workstation », pour le serveur WEB, nous avions installé la distribution Almalinux pour le serveur WEB. Pour l’installation du serveur proxy, nous vous proposons d’installer UBUNTU dans sa version actuel LTS. Comme pour le serveur WEB, nous veillerons à faire une installation minimale. Les informations de cette machine

• Cette machine sera installée dans le réseau LAN et sera joignable à l’adresse IP 10.1.0.4/24.
• La passerelle sera l’adresse IP virtuelle de notre LAN 10.1.0.252
• Son serveur DNS sera notre DNS local 10.1.0.3
• La machine se nommera SQUID.
  

Nous ne détaillerons pas l’installation d’Ubuntu Server.

Installation de SQUID

Après avoir mis à jour la liste des paquets disponibles sur les dépôts configuré par défaut, nous mettrons à jours les paquets actuellement installé.

belkhrissi@squid:~$ sudo apt update -y
belkhrissi@squid:~$ sudo apt upgrade -y

Dans la distribution Ubuntu, nous avons un pare-feu baptisé UFW, s’il est maintenant disponible par défaut, il n’est pas activé. Nous commencerons par activer UFW.

  belkhrissi@squid:~$ sudo ufw enable

Dans les dépôts officiels, le paquet squid est présent, c’est cette version que nous installerons.

  belkhrissi@squid:~$ sudo apt install squid squid-openssl -y

La version qui sera installé, sera la version 5.7 qui n’est pas la dernière version.

Il serait tout à fait envisageable d’installer SQUID depuis les sources mais cela peut poser d’autres problèmes. En général, sauf cas particulier, l’utilisation des paquets gérés par le système d’exploitation est recommandée. Les paquets facilitent la gestion, la maintenance et la sécurité du logiciel sur le système.

Configuration de SQUID

Le fichier de configuration « squid.conf » présent dans le répertoire « /etc/squid/ » est très documenté, ce qui en fait plus une documentation qu’un fichier de configuration. Nous allons garder copier l’original puis modifier ce fichier en supprimant toutes les lignes commentées.

  belkhrissi@squid:~$ sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.original

Pour supprimer tous les commentaires du fichier de configuration /etc/squid/squid.conf, c’est-à-dire supprimer toutes les lignes qui commence par le caractère #, nous utiliserons l’outils « sed » et nous utiliserons une expression régulière.

  belkhrissi@squid:~$ sudo sed -i '/^\s*#/d; /^\s*$/d' /etc/squid/squid.conf

« sed » est l’outil de traitement de texte en ligne de commande.

« i » indique à sed de modifier le fichier.

« /^\s*#/d » est la commande « sed » qui indique de supprimer (d) toutes les lignes qui commencent (^) par aucun ou plusieurs espaces (\s*) suivis d’un caractère #.

« /^\s*$/d » supprime les lignes vides

Si nous affichons le nombre de ligne nous pouvons voir que nous somme passer d’un peu plus de 9100 lignes à un peu une trentaine de lignes.

Nous analyserons se fichier et l’adapterons à nos besoins.

  belkhrissi@squid:~$ sudo vim /etc/squid/squid.conf

Dans la première partie du fichier de configuration, il s’agit essentiellement de la déclaration des ACL (Access Control Lists) pour les différents réseaux. Pour lister ses réseaux, SQUID s’appuie sur des RFC. Ces ACL spécifient les plages d’adresses IP qui sont considérées comme faisant partie du réseau local.

Dans notre contexte, nous pourrions supprimer ses lignes et créer une ACL pour notre réseau local.

Nous créerons également une ACL liée au port. Dans notre cas de figure, nous n’avons autorisé que le port 80 et 443 dans notre pfSense donc nous pouvons effacer la pré-configuration et ne créer qu’une ACL, « ports_autorise » où nous y déclarons le port 80 et 443.

Nous allons ensuite indiquer des directives basées sur les ACLs que nous avons précédemment créé. Les directives sont associées au paramètres « http_access », nous adapterons ses directives à notre contexte. Nous autoriserons les ports autorisés, la machine locale, le LAN et nous interdirons les autres ports ou adresses. De plus, nous modifierons le port d’écoute par défaut

Le paramètre coredum_dir permet de définir où seront stocker les fichiers de vidage en cas de plantage. Ils seront utiles pour le dépannage. Nous ajouterons une autre directive qui va nous permettre de définir un répertoire pour stocker le cache.

• aufs : Le type de stockage du cache, aufs est efficace pour le cache en lecture seul.
  
• /var/spool/squid : Le répertoire où le cache sera stocké.
  
• 5000 : La taille maximale du cache en mégaoctets soit 5 Go dans notre cas
  
• 16 : Le nombre de niveaux d’arborescence dans la hiérarchie du cache.
  
• 256 : Le nombre maximum d’objets dans chaque niveau de l’arborescence du cache.
  

En ce qui concerne la configuration du rafraîchissement de notre cache, nous maintiendrons la dernière ligne et y apporterons une modification en ajoutant à la fin de la ligne le terme « last-modified ». Cette configuration vise à conditionner le rafraîchissement de la page à chaque modification, en limitant cette mise à jour à des changements de plus de 20%. Si la ressource à actualiser est une page web affichant une horloge mise à jour chaque seconde, le paramètre « last-modified » change potentiellement chaque seconde. En fixant le seuil de changement à 20%, nous réduisons le risque de surconsommation de bande passante associé à des mises à jour fréquentes.

• « . » indique toutes les URL
• « 0 » : indique le délai minimum de rafraichissement en minute
• « 20% » : pourcentage des données obsolètes que nous tolérons.
• « 4320 »: correspond en nombre de jours le délai maximum d’un fichier sans rafraîchissement
• Last-Modified, permet à Squid de vérifier qu’il possède bien la dernière version du fichier.
  

Fichier squid.conf

#Déclaration de notre réseau LAN
acl mon_lan src 10.1.0.0/24
#Déclaration des ports autorisés
acl port_autorise port 443
acl port_autorise port 80
#Autorisation pour les ports définis dans port_autorise 
http_access allow port_autorise
http_access allow localhost
http_access allow mon_lan
#Interdiction pour les autres ports
http_access deny all
#Configuration du port autorisé à recevoir les requêtes des clients
http_port 8443
#Configuration des répertoires utiles à squid
coredump_dir /var/spool/squid
cache_dir aufs /var/spool/squid 5000 16 256
#Rafraichir le cache si la page a été modifiée 
refresh_pattern .               0       20%     4320 last-modified

Après avoir effectué toutes les modifications, que nous avons vu, nous sauvegarderons notre fichier « /etc/squid/squid.conf » et nous redémarrerons le service SQUID.

  belkhrissi@squid:~$ sudo systemctl restart squid

Dans le pare-feu de la machine exécutant SQUID, nous autoriserons les connexions entrantes depuis n’importe quelle adresse IP du réseau 10.1.0.0/24 vers l’adresse IP spécifique 10.1.0.4 sur le port 8443

  belkhrissi@squid:~$ sudo ufw allow from 10.1.0.0/24 to 10.1.0.4 port 8443

Configuration des clients

Afin que SQUID soit utilisé par nos clients, nous devons configurer les machines de notre réseau. Pour cela nous avons deux possibilités, les configurer manuellement, ce qui peut s’avérer long mais qui peut être un paramètre intégrer dans le fichier de réponse du master de déploiement. La seconde option s’est de créer une GPO. Dans ce document, nous détaillerons la seconde option.

Dans la version Windows Server 2022, nous n’avons pas de GPO à configurer pour Edge, nous devons les télécharger les politiques depuis le site de Microsoft en nous rendant sur l’url : https://www.microsoft.com/fr-fr/edge/business/download?form=MA13FQ.

Une fois le fichier CAB télécharger, nous allons effectuer en double-cliquant dessus et décompresser l’archive en choisissant l’option Extraire du menu contextuel.

Sur le contrôleur de domaine, nous ouvrirons la console d’administration « Gestion de stratégie de groupe ». Après avoir déplier le nœud du domaine, nous allons nous rendre dans « Objet de Stratégie de groupe ». Dans la partie de droite, après avoir fait un clic-droit, nous sélectionnerons « Nouveau ». Nous donnerons un nom à notre « Nouvel objet GPO » et nous cliquerons sur le bouton « OK » pour valider notre choix.

Après avoir avoir sélectionner « Modifier » dans le menu contextuel de notre nouvel objet, nous allons nous rendre dans « Configuration ordinateur > Stratégies > Modèles d’administration », nous ouvrions le menu contextuel de « Modèles d’administration » et nous sélectionnerons l’option « Ajout/Suppression de modèles ».

Après avoir cliqué sur le bouton Ajouter, nous allons parcourir le contenu de notre disque pour sélectionner le fichier « msedge.adm » présent dans l’archive que nous avons téléchargée et décompressée un peu plus tôt dans ce chapitre. Le fichier msedge est présent dans « \MicrosoftEdgePolicyTemplates\windows\adm\fr-FR ».

Dans l’objet Modèle d’administration, nous retrouvons un sous-dossier « Modèle d’administration classique (ADM ) », en ouvrant ce dossier, nous avons deux autres dossier Mircrosoft Edge et Microsoft Edge – Paramètre par défaut (les utilisateurs peuvent les modifier). Pour ce qui nous concerne, nous sélectionnerons le premier, c’est-à-dire Microsoft Edge, puis « Serveur Proxy », nous aurons alors accès à la GPO « Paramètres du proxy », nous la modifierons.

Après avoir choisi l’option « Activé », nous allons renseigner l’adresse IP de notre serveur proxy sans oublier d’indiquer le port d’écoute de SQUID, nous validerons cette configuration en cliquant sur « Appliquer » puis sur le bouton « OK » pour fermer la fenêtre.

Nous lierons cette stratégie de groupe à une unité d’organisation qui regrouperons les PC du LAN, cette OU n’étant pas encore créé, nous la créerons et nous y mettrons notre client. Ensuite, nous glisserons cet objet vers cet OU.

Pour que notre machine cliente prenne en compte cette stratégie de groupe, nous redémarrerons la machine. Au redémarrage de la machine, nous vérifierons que la stratégie c’est bien appliqué sur notre machine cliente, pour cela, nous allons nous rendre dans « Paramètres du proxy », nous aurons accés à la configuration « au paramètre proxy ». Nous cliquerons sur le bouton « Configurer », nous aurons accès à la configuration de notre proxy.

Configuration de la règle de pare-feu

Dans notre scénario, nous voulons que les utilisateurs passent par le serveur SQUID, pour aller sur Internet. Cette politique devra être imposer à nos utilisateurs, nous allons donc modifier la règle nous permettant d’accéder à Internet, pour que nos utilisateurs n’aient pas d’autres choix que de passer par notre proxy.

Dans pfSense, nous allons créer un nouvel alias pour notre serveur proxy et un nouvel Alias pour le port d’écoute de notre proxy.

Dans notre LAN, nous allons autoriser nos machines du LAN à ne communiquer qu’en HTTPS et HTTP. Pour créer cette règle, il est essentiel de bien comprendre qu’un client souhaitant se rendre sur Internet, il utilisera un port dynamique appelé aussi les ports éphémères pour envoyer une requête vers le port 80 ou 443.

Dans certain UTM, il existe un objet créer par défaut (alias dans pfSense) qui regroupera les ports éphémères, ce qui n’est pas le cas pour pfSense, nous le créerons. Notons ici que nous allons indiquer une étendue sous la forme <port_debut>:<port_fin>

Bon à savoir :
Le choix d’utiliser la plage 49152:65535 est motivé par la RFC 6335 qui spécifie les procédures générales pour l’allocation des ports.

Nous allons ensuite nous rendre sur la page des règles de notre LAN puis nous éditerons notre autorisant les connexions vers Internet.

Pour arriver à ce niveau de granularité, nous devons cliquer sur le bouton « Display Advanced » dans la section source.

Dans le paramètre Source Port Range, dans la liste déroulante « From », nous sélectionnerons « (other) » puis dans le champ « Custom », nous indiquerons le nom de l’alias de nos ports éphémères, nous aurons la même configuration pour le paramétrage de  « To »

Pour la destination, nous indiquerons l’Alias de notre serveur SQUID et dans le port de destination, nous indiquerons le port d’écoute de SQUID.

Depuis notre poste client, nous tenterons de nous connecter à un site internet, par exemple nous testerons une connexion au moteur de recherche Google en tapant dans la barre d’adresse « google.fr ». Nous aurons alors une erreur.

En analysant la page d’erreur, nous pouvons constater, que le navigateur a tenté de se connecter à http://google.fr, nous retentons en forçant le protocole « https ». Cette tentative se conclu également par un échec. Mais cette fois ce n’est pas notre proxy qui nous envoie la réponse d’erreur.

Nous regarderons les logs de connexion du côté de SQUID pour investiguer.

  belkhrissi@squid:~$ sudo tail -f /var/log/squid/access.log | grep google.fr

« HIER_DIRECT » indique que le cache n’a pas été utilisé donc nous pouvons affirmer que cela n’est pas dû à un problème de cache. Nous avons ensuite 503 qui correspond au code erreur HTTP, le serveur distant n’a pas pu traiter la demande.

De plus, « NONE_NONE/503 » indique que la requête n’a pas été satisfaite par le cache, aucune tentative de revalidation n’a été faite, et le serveur a renvoyé une réponse avec le code d’erreur HTTP 503.

La requête CONNECT est utilisée pour établir une connexion tunnel entre le client et le serveur distant sans déchiffrement intermédiaire donc CONNECT indique que le client a envoyé une requête CONNECT au proxy Squid.

En rapprochant ses logs et notre fichier de configuration, nous pouvons constater que nous interceptons le trafic HTTP sur le port 8443.

Nous n’avons pas configuré SQUID pour configurer l’interception des requêtes HTTPS. Lorsque Squid intercepte une requête HTTPS, il agit comme une interface intermédiaire entre le client et le serveur distant. Cette interception permet à Squid d’inspecter le trafic HTTPS, même si ce dernier est chiffré. Lorsque le client émet une requête HTTPS, Squid intercepte cette requête. Squid procède au déchiffrement de la requête HTTPS à l’aide de sa clé SSL privée. Ce déchiffrement permet à Squid d’inspecter le contenu de la requête, y compris les en-têtes HTTP et les données. À cet étape, Squid peut effectuer différentes opérations d’inspection, telles que l’application de règles de filtrage, la journalisation ou la modification du trafic en fonction de sa configuration.

Après l’inspection, Squid rechiffre la requête en utilisant le certificat SSL/TLS du serveur distant. Cette étape est cruciale pour transmettre la requête initiale de manière sécurisée au serveur distant sans compromettre la confidentialité des données. La requête rechiffrée est ensuite redirigé vers le serveur distant comme si elle provenait directement du client. Ce mécanisme, est appelé « SSL Bump » dans SQUID.

Dans ce processus, nous voyons que nous avons besoin d’une nouvelle clé privé et de son certificat. Nous stockerons cette clé et ce certificat dans un répertoire que nous créerons.

belkhrissi@squid:~$ sudo mkdir /etc/squid/ssl/
belkhrissi@squid:~$ cd /etc/squid/ssl/
belkhrissi@squid:/etc/squid/ssl# openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -keyout cle_squid.key -out squid_ca.crt

Pour des raisons techniques spécifiques à Squid et à la manière dont il gère les certificats, nous devons convertir le certificat au format DER.

  belkhrissi@squid:/etc/squid/ssl#:~$ openssl x509 -in squid_ca.crt -outform DER -out squid_ca.der

Nous allons ensuite configurer le tunnel de communication qui permettra la négociation entre SQUID et les machines souhaitant se connecter sur internet. Lors de cette phase de négociation, il y aura un échange de clé pour chiffrer et déchiffre les données. On utilise la négociation « diffie-hellmann »

  belkhrissi@squid:/etc/squid/ssl# openssl dhparam -outform PEM -out dhparam.pem 2048

Pour que SQUID puisse utiliser la clé et les certificats, nous allons rendre l’utilisateur lié au service squid propriétaire du répertoire dans lequel sont stockées ses éléments. Cet utilisateur sur Ubuntu se nomme « proxy » et son groupe est également nommé « proxy ». Nous ajusterons les droits en autorisant que la lecture sur nos certificats et notre clé à notre utilisateur proxy.

belkhrissi@squid:/etc/squid/ssl# chown -R proxy:proxy /etc/squid/ssl/ 
belkhrissi@squid:/etc/squid/ssl# chmod 400 /etc/squid/ssl/*

Squid s’appuie sur une base de données pour gérer les certificats racine de diverses autorités de certification de confiance. Ces certificats racine sont utilisés pour vérifier la chaîne de confiance des certificats SSL/TLS émis par les serveurs web.

belkhrissi@squid:/etc/squid/ssl# mkdir -p /var/lib/squid
belkhrissi@squid:/etc/squid/ssl# rm -rf /var/lib/squid/ssl_db
belkhrissi@squid:/etc/squid/ssl# /usr/lib/squid/security_file_certgen -c -s /var/lib/squid/ssl_db -M 20MB
belkhrissi@squid:/etc/squid/ssl# chown -R proxy:proxy /var/lib/squid

Nous avons préparer la partie certificat pour notre serveur SQUID, nous allons intégrer ses informations dans notre fichier de configuration /etc/squid/squid.conf/

  belkhrissi@squid:/etc/squid/ssl#vim /etc/squid/squid.conf

Nous autoriserons le téléchargement de certificats intermédiaires par Squid lorsqu’il intercepte le trafic HTTPS. Au début de fichier, nous allons ajouter :

acl intermediate_fetching transaction_initiator certificate-fetching
http_access allow intermediate_fetching 
cache_effective_user proxy 
cache_effective_group proxy 
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/squid/ssl_db -M 20MB 
sslproxy_cert_error allow all 
ssl_bump stare all 
http_port 8443 tcpkeepalive=60,30,3 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB tls-cert=/etc/squid/ssl/squid_ca.crt tls-key=/etc/squid/ssl/cle_squid.key cipher=HIGH:MEDIUM:!LOW:!RC4:!SEED:!IDEA:!3DES:!MD5:!EXP:!PSK:!DSS options=NO_TLSv1,NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE tls-dh=prime256v1:/etc/squid/ssl/bump_dhparam.pem 

Nous commenterons la ligne suivant que nous avons configurer précédemment.

#http_port 8443 

fichier /etc/squid/squid.conf.

LIGNE A AJOUTER
#######################################################################
acl intermediate_fetching transaction_initiator certificate-fetching
http_access allow intermediate_fetching
#######################################################################
#Déclaration de notre réseau LAN
acl mon_lan src 10.1.0.0/24
#Déclaration des ports autorisés
acl port_autorise port 443
acl port_autorise port 80
#Autorisation pour les ports définis dans port_autorise
http_access allow port_autorise
http_access allow localhost
http_access allow mon_lan
#Interdiction pour les autres ports
http_access deny all
#Configuration du port autorisé à recevoir les requêtes des clients
####LIGNE A COMMENTER
#http_port 8443
#Configuration des répertoires utiles à squid
coredump_dir /var/spool/squid
cache_dir aufs /var/spool/squid 5000 16 256
#Rafraichir le cache si la page a été modifiée
refresh_pattern .               0       20%     4320 last-modified
#LIGNE A AJOUTER
##################################################################################
cache_effective_user proxy
cache_effective_group proxy
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/squid/ssl_db -M 20MB
sslproxy_cert_error allow all
ssl_bump stare all
http_port 8443 tcpkeepalive=60,30,3 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB tls-cert=/etc/squid/ssl/squid_ca.crt tls-key=/etc/squid/ssl/cle_squid.key cipher=HIGH:MEDIUM:!LOW:!RC4:!SEED:!IDEA:!3DES:!MD5:!EXP:!PSK:!DSS options=NO_TLSv1,NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE tls-dh=prime256v1:/etc/squid/ssl/dhparam.pem

Pour que les modifications que nous avons apportées à la configuration de Squid soient prises en compte, nous devons redémarrer le service Squid.

  belkhrissi@squid:/etc/squid/ssl#systemctl restart squid

En cas d’erreur, vous pouvez vérifier si le fichier de configuration ne comporte pas d’erreur à l’aide de la commande suivante :

  belkhrissi@squid:/etc/squid/ssl#squid -k parse

Nous ajouterons une règle dans notre pfSense qui autorisera seulement notre serveur Proxy à se connecter sur internet.

Depuis notre poste client, nous tenterons de nous connecter sur un site internet. Vu que le certificat est celui envoyé par SQUID, nous aurons un message nous informant que le certificat ne peut pas être vérifier et par conséquent il ne peut pas vérifier la légitimité de l’émetteur de notre certificat.

Pour faire reconnaitre ce certificat, il nous faut l’installer dans le magasin « Autorité de certification de confiance ». Pour éviter à devoir le faire sur chacun des machines du réseau, nous allons faire cette action par une GPO.

Dans un premier temps, nous devons récupérer ce certificat. Sur mon poste client, sur ma page web qui m’informe que ma connexion n’est pas privée, nous allons cliquer sur «Non sécurisé» présent sur la barre d’adresse.

Nous cliquerons ensuite sur le message en rouge « La connexion à ce site n’est pas sécurisée », ce qui nous amène vers le détail de cet avertissement, nous cliquerons sur le bouton « certificat ».

Nous aurons alors accès aux informations de notre certificat. En nous rendant sur l’onglet « Détails », nous pourrions enregistrer le certificat en l’exportant.

Une fois le certificat récupérer, nous allons le copier/coller sur notre contrôleur de domaine. Sur notre contrôleur de domaine, nous ouvrirons la console mmc « Gestion des stratégies de groupe » disponible dans le menu « Outils »

Dans le menu contextuel de l’unité d’organisation « Ordinateur », nous sélectionnerons « Créer un objet GPO dans ce domaine, et le lier ici… » et nous lui donnerons un nom Nous modifierons ensuite, cet objet GPO.

Dans l’objet de stratégie de groupe, nous nous rendrons à « Configuration ordinateur » -> « Stratégies » -> « Paramètres Windows » -> « Paramètres de sécurité » -> « Stratégie de clé publique » -> « Autorité de certification racines de confiance ». Dans la partie blanche à droite de la console, nous ouvrirons le menu contextuel à l’aide du clic-droit de la souris, puis nous sélectionnerons « importer ».

Nous serons accompagnés d’un assistant d’import tout au long du processus. Nous passerons le message de bienvenue en cliquant sur le bouton « Suivant ». Nous serons ensuite invités à sélectionner notre certificat, après avoir cliqué sur le bouton « Parcourir », nous sélectionnerons notre certificat, puis nous validerons notre choix en cliquant sur le bouton « Ouvrir », puis sur le bouton « Suivant » pour passer à la suite.

Nous laisserons le choix du magasin du certificat puis après avoir cliquer sur le bouton « Suivant », nous cliquerons sur le bouton « Terminer »

Nous testerons notre Objet GPO en actualisant la page où nous avions un avertissement de sécurité. Nous devrions plus avoir le message d’avertissement et en regardant les informations liées au certificat, nous voyons que la machine SQUID a émis le certificat et que la connexion est sécurisée.

Installation et configuration de SquidGuard

La puissance de Squid en tant que serveur proxy réside dans sa conception modulaire et extensible, qui permet l’ajout de modules complémentaires pour étendre ses fonctionnalités et l’adapter aux besoins spécifiques de l’utilisateur. Parmi les modules complémentaires les plus utilisées nous retrouvons SquidGuard. Ce module va permettre à ajouter à SQUID des fonctionnalités de filtrage, de surveillance ou encore de contrôle d’accès. Nous commencerons par installer SquidGuard.

  belkhrissi@squid:~$ sudo apt install squidguard -y

SquidGuard fonctionne en s’appuyant sur des whitelist ou blacklist, donc soit on interdit soit on autorise une liste d’url ou de mot clé. Dans la majeur parti des cas, SquidGuard s’appuiera sur une liste de site internet à interdire l’accès soit pour des raisons légales soit pour des raisons de politique de sécurité interne à l’entreprise. L’université de Toulouse propose une blacklist gratuite et qui est régulièrement mise à jour. Nous nous appuierons sur cette blacklist. Après avoir créé le répertoire qui contiendra la blacklist, nous le téléchargement directement depuis le site de l’université de Toulouse.

belkhrissi@squid:~$ sudo mkdir /etc/squidguard/blacklist
belkhrissi@squid:~$ sudo wget http://dsi.ut-capitole.fr/blacklists/download/blacklists.tar.gz  belkhrissi@squid:~$sudo tar xf blacklists.tar.gz
belkhrissi@squid:~$sudo cp -R blacklists/* /etc/squidguard/blacklist/
belkhrissi@squid:~$chown -R proxy:proxy /etc/squidguard/blacklist/

La liste fournit par l’université de Toulouse propose des listes de domaine, d’url ou encore d’expression qui vont est catégorisée.

Pour bloquer des catégories, il nous faudra les déclarés dans le fichier de configuration /etc/squidguard/squidGuard.conf. Avant de modifier ce fichier, nous allons garder copier la configuration originale.

  belkhrissi@squid:~$ sudo cp /etc/squidguard/squidGuard.conf /etc/squidguard/squidGuard.conf.orginal

Nous repartirons d’un fichier vierge.

belkhrissi@squid:~$ sudo su
root@squid:/home/belkhrissi# echo " " > /etc/squidguard/squidGuard.conf
root@squid:/home/belkhrissi# vim /etc/squidguard/squidGuard.conf

Nous commencerons par déclarer les catégories en indiquant leurs emplacements. Pour notre test, nous bloquerons les sites pour adultes, audio-video ou encore agressif, ses catégories sont disponibles ensuite dans une base de données que nous allons générer par la suite

#Emplacement de la base de données
dbhome /var/lib/squidguard/db
logdir /var/log/squid

#Déclaration des catégories
dest porn {
   domainlist /etc/squidguard/blacklist/porn/domains
   urllist /etc/squidguard/blacklist/porn/urls
 }
dest adult {
    domainlist /etc/squidguard/blacklist/adult/domains
    urllist /etc/squidguard/blacklist/porn/urls
}
dest audio-video {
    domainlist /etc/squidguard/blacklist/audio-video/domains
    urllist /etc/squidguard/blacklist/audio-video/urls
}
dest aggressive {
   domainlist /etc/squidguard/blacklist/aggressive/domains
   urllist /etc/squidguard/blacklist/aggressive/urls
 }

Ensuite, nous procéderons à la création d’une ACL (Liste de Contrôle d’Accès). Dans cette ACL, nous établirons une règle par défaut. Cette règle par défaut aura pour objectif de restreindre l’accès aux catégories que nous avons préalablement définies. Pour ce faire, nous utiliserons le mot-clé « pass », suivi du nom de la catégorie précédé du symbole d’exclamation « ! ». Par exemple, « pass !audio-video » signifiera « bloquer la catégorie audio-vidéo ».

Chaque fois qu’un utilisateur se verra refuser l’accès, il sera automatiquement redirigé vers une page web spécifique, pour ce faire un serveur APACHE a été installer sur le serveur qui héberge SQUID. Sans trop rentrer dans le détail voici la procédure d’installation est de configuration

root@squid:~#apt install apache2
root@squid:~#echo " " > /var/www/html/index.html
root@squid:~#vim /var/www/html/index.html
###Contenu de index.html###
<!DOCTYPE html>
<html>
<head>
      <meta charset="UTF-8">
      <title>Accès bloqué</title>
 <style>
 body {
 font-family: Arial, sans-serif;
 background-color: #f5f5f5;
 margin: 0;
 padding: 0;
 text-align: center;
 }
 .container {
 background-color: #fff;
 border-radius: 10px;
 box-shadow: 0 0 10px rgba(0, 0, 0, 0.2);
 margin: 100px auto;
 max-width: 400px;
 padding: 20px;
 }

 h1 { color: #e74c3c;}
 p { color: #333;}
 </style>
 </head>
  <body>
<div class="container">
      <h1>Accès bloqué</h1>
      <p>Le site web que vous tentez d'accéder est bloqué en raison de la politique de sécurité de l'entreprise.</p>
      <p>Veuillez contacter le service informatique ou l'administrateur système si vous avez des questions ou si vous pensez que cette restriction est incorrecte.</p>
 </div>
 </body>
  ###Fin du Contenu de index.html###

root@squid:~#a2enmod ssl 
root@squid:~#mkdir /etc/apache2/ssl
root@squid:~#openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
root@squid:~#vim /etc/apache2/sites-available/squidguard-ssl.conf

###Contenu de squidguard-ssl.conf ###
<VirtualHost *:443>
      ServerName block.elkhrissi.lab
      DocumentRoot /usr/lib/cgi-bin/
      SSLEngine on
      SSLCertificateFile /etc/apache2/ssl/apache.crt
      SSLCertificateKeyFile /etc/apache2/ssl/apache.key
      ErrorLog ${APACHE_LOG_DIR}/error.log
      CustomLog ${APACHE_LOG_DIR}/access.log combined
  </VirtualHost>
  ###Fin du contenu de squidguard-ssl.conf ###

root@squid:~#ufw allow 443/tcp
root@squid:~#a2ensite squidguard-ssl
root@squid:~#systemctl reload apache2

Nous pouvons maintenant utiliser le serveur WEB pour indiquer que le site internet sur lequel il souhaite se rendre a été bloqué.

default { 
          pass !porn !adult !aggressive !audio-video all
          redirect https://block.elkhrissi.lab/
          }
 }

Exemple de fichier squidGuard.conf

#Emplacement de la base de données
dbhome /var/lib/squidguard/db
logdir /var/log/squid
#Déclaration des catgories
dest porn {
      domainlist /etc/squidguard/blacklist/porn/domains
      urllist /etc/squidguard/blacklist/porn/urls
}
dest adult {
     domainlist /etc/squidguard/blacklist/adult/domains
     urllist /etc/squidguard/blacklist/porn/urls
}
dest audio-video {
     domainlist /etc/squidguard/blacklist/audio-video/domains
     urllist /etc/squidguard/blacklist/audio-video/urls
}
dest aggressive {
      domainlist /etc/squidguard/blacklist/aggressive/domains
      urllist /etc/squidguard/blacklist/aggressive/urls
}
#Création d'une ACL
acl {
      default {
          pass !porn !adult !aggressive !audio-video all
          redirect https://block.elkhrissi.lab/
      }
 }

Dans cette configuration, nous lirons que nous avons rediriger les utilisateurs qui

Nous allons ensuite rediriger les requêtes http(s) qui sont intercepté par SQUID vers squidGuard en spécifiant l’accès à son fichier de configuration.

  root@squid:/home/belkhrissi# vim /etc/squid/squid.conf

A la fin du fichier nous ajouterons les lignes suivantes pour demander à SQUID d’aller consulter la configuration de squidGuard et nous configurerons le nom de sous-processus de squid pour exécuter squidGuard et nous autoriserons les redirections de squidGuard.

# Emplacement du fichier de configuration de SquidGuard
url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf
url_rewrite_children 5
url_rewrite_access deny CONNECT
url_rewrite_access allow all

Plus tôt nous avons spécifier l’emplacement de la base de données et nous avions préciser qu’il nous faudra la générer, c’est ce que nous allons faire maintenant.

  root@squid:/home/belkhrissi# squidGuard -d 2 -C all

Bon à savoir :
La commande SquidGuard -d 2 -C all peut être simplifier en squidGuard -C all pour créer la base de données, l’option « -d 2 » permet d’avoir une sortie détaillée et ainsi voir si nous rencontrons des erreurs.

Pour que les modifications soient prises en considération, nous redémarrerons le service SQUID.

  root@squid:/home/belkhrissi# systemctl restart squid

Nous tenterons de nous connecter à un site internet d’une des catégories que nous avons interdites, nous devrions être bloqué.

Bon à savoir :
Certain site internet peuvent être configurer, pour des raisons de sécurité, l’accés à votre page web de redirection, cela sera le cas par exemple avec les services « prime video »

Dans les logs de connexion /var/log/squid/access.log, nous voyons que « lorsque que la machine 10.1.0.10 tente de se connecter à Netflix, il rediriger vers https://block.elkhrissi.lab

Sur le plan technique, il est tout à fait envisageable de substituer l’adresse IP par le nom de l’utilisateur, mais cela doit être réalisé en pleine conformité avec la législation en vigueur. En effet, le règlement général sur la protection des données (RGPD) exige une transparence totale dans le processus de collecte des données. Il convient de rappeler que du point de vue juridique, une entreprise est généralement considérée comme un fournisseur d’accès Internet, ce qui la soumet aux mêmes obligations légales, notamment en ce qui concerne la conservation des journaux de connexion. Dans le cas où vous souhaiteriez identifier des individus plutôt que des adresses IP privées, il n’est pas nécessaire de solliciter leur consentement préalable. Cependant, vous avez l’obligation de mettre en place un registre de traitement des données, indiquant clairement qui est responsable de ce processus et spécifiant les modalités pour que les utilisateurs puissent exercer leur droit d’accès, de rectification, de suppression ou de modification des données.

Il est important de noter que cette documentation n’a pas pour vocation de servir de fondement juridique. Par conséquent, nous vous encourageons vivement à consulter un juriste ou un avocat spécialisé dans ce domaine pour obtenir des informations plus détaillées. Il convient de souligner que l’identification des utilisateurs comporte inévitablement des considérations juridiques spécifiques.

L’article Filtrage Web avec Pfsense, Squid & SquidGuard est apparu en premier sur Pandawan.

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.

Bon à savoir : Un UTM est souvent perçu comme un pare-feu avec des fonctionnalités de sécurité supplémentaires.

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.

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

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 :

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.

Bon à savoir : Le concept de l’Alias dans pfSense n’est pas exclusif à cet UTM. Nous retrouvons le même principe chez les autres éditeurs tel que Fortinet ou encore Stormshield sous le nom d’objet.

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.

L’article Filtrage avec Pfsense est apparu en premier sur Pandawan.

Lors de l’introduction à la sécurité des accès, nous avons abordé les principes fondamentaux de la sécurité informatique à travers la Triade CIA, qui englobe la Confidentialité, l’Intégrité, et la Disponibilité. Nous avons examiné brièvement la confidentialité en attribuant des droits aux utilisateurs selon leurs besoins spécifiques, et nous avons également abordé l’intégrité en introduisant le chiffrement dans les communications entre pfSense et notre contrôleur de domaine. À présent, nous nous tournons vers la disponibilité.

Bon à savoir :L’utilisation des termes « sommairement » et « effleuré » souligne que ces mesures, bien que significatives, ne constituent qu’une partie d’une approche globale de la sécurité. Elles nécessitent d’être complétées par une politique de sécurité adaptée et une architecture en phase avec le contexte de déploiement de l’UTM. Il est essentiel de reconnaître que le risque zéro n’est pas réaliste, et que les mesures de sécurité visent à atténuer les risques tout en minimisant les conséquences d’une éventuelle attaque.

Dans pfSense, le cluster offre la possibilité d’avoir un unique nœud actif désigné en tant que « Master », tandis que les autres nœuds ont le statut de « Backup ». Chaque nœud du cluster envoie régulièrement des annonces CARP. Si un nœud cesse d’émettre ces annonces, il est considéré comme non opérationnel. Si le nœud « Master » ne diffuse plus d’annonces CARP, un autre nœud en statut « Backup » prendra automatiquement sa place. Nous dédierons un réseau pour les annonces CARP, c’est également à travers ce réseau que nous configurerons le protocole pfsync et le XML-RPC.

Modification du LAB Pfsense

Le schéma de nouveau Lab sera le suivant :

Ajout d’une interface réseau

Dans VMware Workstation, nous ajouterons un nouveau réseau VMNET3.

Sur notre pfSense nous ajouterons une carte réseau (VMNET3).

Sur l’interface web d’administration de « pfsense1 », après avoir ajouté la 4^ème interface réseau, nous allons nous rendre dans le menu Interfaces où nous sélectionnerons « Assignments ».

Nous pouvons voir la liste de nos interfaces, dans cette liste, la dernière interface est marquée comme valide et n’est pas assignée, nous cliquerons sur le bouton « Add » qui se trouve à la fin de la ligne pour l’assigner et nous validerons cette modification en cliquant sur le bouton « Save ».

Après avoir créé l’interface OPT2, nous allons la configurer en lui attribuant une configuration réseau. Dans le menu déroulant « Interfaces », nous sélectionnerons l’interface « OPT2 ».

Dans la section « General Configuration », nous cocherons l’option « Enable » pour activer cette interface. Ensuite, dans la liste déroulantes « IPv4 Configuration type », nous sélectionnerons « Static IPv4 ».

Dans la section « Static IPv4 », nous renseignerons une adresse IP et un masque de sous-réseau.

Une fois cette modification apportée, nous cliquerons sur le bouton « Save » pour les sauvegarder. Un message en haut de page s’affiche nous demandant d’appliquer les changements. Nous cliquerons sur le bouton « Apply Changes »

Pour des questions de confort, nous renommerons également notre pfSense. Dans le Menu « System », nous sélectionnerons « General Setup ».

Dans la section « System », nous modifierons le nom de notre pfSense dans le champ « Hostname », nous validerons ce choix en cliquant sur le bouton « Save »

Sur la page d’accueil, nous pouvons constater les changements.

Les changements ont été fait sur le 1^er pfSense, nous allons pouvoir passer au second.

Bon à savoir : Notre lab intégre un dns, nous pouvons créer une nouvelle entrée pour utiliser le nom du pfsense.

Ajout d’un nouveau pfSense

L’installation du second pfSense se fera de la même manière que celle que nous avons vu plus tôt dans cette documentation à l’exception que nous aurons 4 interfaces. Contrairement au premier, nous ne configurerons pas l’authentification LDAP. Pour des questions pratiques, nous renommerons le premier pfSense, « pfsense1 » et le second sera nommée « pfsense2 ».

Configuration de la Haute Disponibilité

Pour la configuration de la Haute Disponibilité, nous apporterons des modifications sur « pfsense1 » et « pfsense2 ». Dans un premier temps, nous allons devoir activer et configurer la synchronisation des connexions, c’est-à-dire pfsync et XML-RPC. La configuration de ces deux protocoles se configure sur la même page de l’interface d’administration. Quant au CARP, nous le configurerons à part, après avoir configurer les protocoles pfsync et XML-RPC.

Configuration des protocoles pfsync et XML-RPC

Pfsense1

PfSense offre une interface d’administration spécialement dédiée à la configuration de la haute disponibilité. Pour accéder à cette interface, sur pfsense1, nous nous rendrons dans le menu déroulant « System » et nous sélectionnerons « High Availability Sync ».

La première section, « State Synchronisation Settings », se concentre sur pfsync. Pour commencer, nous activerons la synchronisation des états en cochant la case « pfsync transfers state insertion, update, and deletion messages between firewalls». Ensuite, nous dédierons l’interface OPT2 au protocole pfsync, pour cela, dans la liste déroulante, nous sélectionnerons, l’interface « OPT2 ». Nous forcerons pfsense1 à se synchroniser avec pfsense2. Nous renseignerons donc l’adresse IP de l’interface OPT2 de pfsense2, dans le champ « pfsync Synchronize Peer IP ».

Bon à savoir : Dans le cas où il y aurait un nombre de nœud supérieur à 2, le champ « pfsync Synchronisze Peer IP » doit être vide, ainsi une adresse multicast sera utilisée.

Dans la section suivante, nous configurerons le protocole XML-RPC. Nous indiquerons que le XML-RPC se synchronisera avec notre pfsense2 sur l’interface OPT2, nous renseignerons donc l’adresse IP de l’interface OPT2 de pfsense2.

Nous devons ensuite renseigne les informations d’identifications de pfsense2. Idéalement, nous devrions créer un compte qui soit dédié, puis pour terminer, nous sélectionnerons les options que nous souhaitons synchroniser.

Pfsense2

Pour la configuration de pfsense2, nous allons avoir, à peu de chose près, la même configuration. Dans pfsense2, nous allons nous rendre dans l’interface de configuration de la haute disponibilité.

La différence avec la configuration de pfsense1, c’est qu’ici, nous n’allons configurer que la section « State Synchronization Settings (pfsync) » et plus précisément les paramètres suivants :

• Synchronize states
• Synchronize interface
• Pfsync Synchronize Peer IP

Après avoir valider, nous nous rendrons sur pfsense1 où nous pouvons voir que nous avons une alerte, en cliquant sur cette alerte, nous en avons le détail qui nous indique une erreur au niveau du XML-RPC, plus précisément qu’il y a une erreur de communication entre pfsense1 et pfsense2.

Cette information est tout à fait normale dans le contexte d’utilisation de pfSense, en effet, par défaut, lorsque nous ne sommes par l’interface assigné au LAN, aucune communication est autorisée. Pour autoriser la communication entre pfsense1 et pfsense2 sur le port 443, Il nous faut nous rendre dans le menu « Firewall », puis sélectionner Rules où nous allons nous rendre dans l’onglet « OPT2 ».

Cette configuration sera à faire sur les deux pfSense.

Après avoir cliqué sur un des deux bouton « Add », nous validerons le formulaire de création de nouvelle règle en cliquant directement sur « Save ». Nous verrons ce point un peu plus tard dans ce document. Après avoir cliqué sur « Save », nous devons confirmer en cliquant sur le bouton « Apply change ».

Pour vérifier que la synchronisation est opérationnelle, nous déroulerons le menu « Status » et nous sélectionnerons « Filter reload » et nous cliquerons sur le bouton « Force Config Sync ».

Dans le résultat de la synchronisation, à la fin du journal, nous devons voir un message nous indiquant que la synchronisation a été effectué avec succès.

Configuration du protocole CARP

Comme nous l’avons annoncé précédemment, le protocole CARP va nous permettre de configurer une adresse IP virtuelle appelé au VIP pour virtual IP, qui agira comme un aiguilleur, en transférant les trames vers le UTM qui a le statut « master ».

Nous configurerons une VIP pour les interfaces suivantes :

• WAN
• LAN
• OPT1

Sur pfSense1, nous allons dérouler le menu « Firewall » et nous allons sélectionner « Virtuals IP ».

Pour ajouter une VIP, nous cliquerons sur le bouton « Add » pour accéder au formulaire de création.

Nous devons préciser qu’elle sera le Type d’adresse ip virtuelle, dans notre cas, nous en avions discutez plus tôt c’est CARP. Après avoir choisi l’option CARP, nous allons nous renseigner le champ Address(es), nous lui attribuerons l’adresse 10.0.0.252 et un masque de sous-réseau de 24 bits. L’adresse VIP et les adresse configurer sur les interfaces WAN de nos pfSense forment un groupe nommé VHID (Virtual HOST IDentifier), l’accès à ce groupe est sécurisé par un mot de passe, nous devons créer un mot de passe pour ce VHID. Une fois que nous avons configurer les différents paramètres de notre VIP, nous allons les valider en cliquant sur le bouton « Save » sans oublier d’appliquer ses changements en cliquant ensuite sur le bouton « Apply Changes »

Nous réitérons ces opérations sur les interfaces LAN etOPT1.

Récapitulatif des adresses IP virtuelles.

La réplication des configurations étant activé et configuré pfsense2 doit avoir la même configuration. Après nous être assuré que cela soit bien le cas, nous allons nous déroulerons le menu Status des deux pfSense où nous sélectionnerons CARP (failover). Nous devons avoir un pfSense qui héberge les interface Master et le second doit héberger les interfaces au statut BACKUP.

Pour tester que cela fonctionne, nous allons nous rendre sur le poste client de notre LAN, modifier les paramètre réseau en configurant la passerelle avec l’adresse ip virtuelle de notre LAN.

Nous ouvrirons 3 invites de commande :

• Le premier enverra un ping continue vers une adresse publique
• Le deuxième enverra un ping continue vers pfsense1.
• Le dernier enverra un ping continue vers sa passerelle, soit l’adresse IP virtuelle.

Nous allons ensuite éteindre pfsense1 et retourner sur notre poste client. Nous constatons que nous avons perdu un ping sur le premier terminal, tandis que le second terminal n’arrive plus à joindre pfsense1 et notre adresse IP est toujours joignable.

La mise en place d’un cluster pfSense constitue une solution performante visant à renforcer la disponibilité, la sécurité, et à assurer le maintien opérationnel des services. En plus de fournir une résilience en cas de défaillance, cette approche permet la mise à jour individuelle de chaque nœud sans impact sur les utilisateurs.

L’article Haute disponibilité avec Pfsense est apparu en premier sur Pandawan.

La gestion des identités et des autorisations constitue un pilier essentiel de la sécurité informatique, une importance qui prend tout son sens lors du renforcement des mesures de sécurité. En effet, l’un des principes fondamentaux de la sécurité informatique est la Triade CIA (Confidentialité, Intégrité, Disponibilité) :

• Confidentialité : Garantir que les informations soient accessibles uniquement aux personnes autorisées.
• Intégrité : Assurer l’exactitude et l’intégrité des informations, empêchant toute modification non autorisée.
• Disponibilité : Garantir que les informations soient disponibles et accessibles en fonction des besoins.

Les UTM n’échappent pas à ses règles, bien au contraire.

Gestion des comptes utilisateurs

L’identifiant de connexion, s’il est partagé, peut être considéré comme générique, sauf dans le cas où un seul administrateur a accès à pfSense. Pour assurer la confidentialité, il est impératif d’avoir un compte distinct pour chaque utilisateur, configuré avec les droits appropriés. La gestion de la confidentialité intègre 3 principes :

• Identification : ‘utilisateur fournit des informations d’identification telles qu’un nom d’utilisateur.
• Authentification : Le système vérifie ces informations d’identification en les comparant à une base de données d’utilisateurs autorisés.
• Accès : Si l’authentification réussit, l’utilisateur est autorisé à accéder aux ressources ou aux données spécifiques pour lesquelles il est autorisé.

Ajouter une source d’authentification

La gestion des utilisateurs peut se faire en utilisant les comptes internes ou alors en nous appuyant sur l’Active Directory, cela permet d’avoir une source unique d’authentification ce qui nous simplifiera la gestion et qui nous permet de conserver une cohérence dans la politique de sécurité des mots de passe (mot de passe complexe, changement régulier, etc…).

Pour l’organisation de notre Active Directory, sur le contrôleur de domaine, à l’aide de la console « Utilisateurs et ordinateurs Active Directory », nous allons créer une unité d’organisation que nous nommerons pfSense.

Dans l’unité d’organisation que nous venons de créer, nous allons créer deux groupes de sécurité global, « pf_administrateur » et « pf_technicien ».

Les membres du groupe « pf_administrateur » auront un accès total alors que les membres du groupe « pf_technicien » auront un accès limité.

Nous créerons également 2 comptes utilisateur, le premier, « pf_admin », sera membre du groupe de sécurité « pf_administrateur » et le second « pf_tech » sera membre du groupe de sécurité « pf_technicien ».

Nous créerons un compte pfSense qui sera un compte de service, nous y reviendrons un peu plus tard dans cette documentation.

A l’étape suivante, nous allons ajouterons à pfSense notre Active Directory, comme source d’authentification.

Une fois que les utilisateurs ont été créés, nous accéderons à l’interface d’administration de pfSense. Nous naviguerons vers le menu « System » et cliquerons sur « User Manager ».

Nous allons ensuite, nous rendre dans l’onglet, « Authentication Servers », puis sur le bouton « Add » pour avoir accès au formulaire web d’ajout d’un serveur d’authentification.

Dans la section « Server Settings », nous indiquerons un nom et nous laisserons le type LDAP proposé par défaut.

Hostname or IP Address : Indiquer l’IP ou le nom de votre contrôleur de domaine. Dans le cas où vous indiqueriez votre FQDN, il faudra être sûr que votre Pfsense est client de votre serveur DNS.

Search scope : Dans la liste déroulante, nous allons étendre la recherche dans toute l’arborescence de l’AD

Base DN : Le « Distinguished Name » de notre AD

Authentication containers : le Distinguished name de l’Unité d’organisation ou conteneur que l’on souhaite lier à l’authentification de pfSense.

• Bind anonymous – Bind credential : En décochant Bind anonymous, nous refusons les requête LDAP anonyme, il nous voudra donc indiquer un identifiant et un mot de passe qui sera autorisé à se connecter. Un peu plus tôt dans cette documentation, nous avions créé un compte « pfsense », sans l’associer à un groupe, c’est ici qu’il va avoir son utilité. Il sera dédié à pfSense.
• Initial Template : Choisissez Microsoft AD

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

Notre Active Directory est maintenant présent dans la liste des serveurs d’authentification de pfSense.

Pour tester notre nouvelle source d’authentification, nous déroulerons le menu « Diagnostics », puis nous sélectionnerons « Authentication ».

Nous accédons à un formulaire pour tester les authentifications. Dans la liste déroulante « Authentication Server », nous sélectionnerons le nom que nous avons donnée à notre nouvelle source d’authentification, dans cette documentation, le nom est « Active Directory ».

Nous testerons avec l’utilisateur « pf_tech », nous renseignerons son nom d’utilisateur et son mot de passe.

Après avoir renseigner tous les champs, nous cliquerons sur le bouton « Test »..

Dans la capture ci-dessus, nous pouvons lire dans le bandeau vert que l’ajout de de serveur d’authentification est fonctionnelle.

Gestion des accès

Nos utilisateurs que nous avons créés doivent être exclusive à pfSense si nous souhaiter garder l’approche du minimum de privilèges et par extension à l’approche plus générale qu’est le « Zero Trust ». Il nous faut bloquer l’ouverture des sessions sur des postes ou des serveurs de notre infrastructure en utilisant les comptes dédiés à pfSense. Dans le gestionnaire de stratégie de groupe de notre contrôle de domaine, nous avons un objet de stratégie de groupe à créer et à lier à notre unité d’organisation pfSense.

Dans le menu « Outils » du Gestionnaire de serveur de notre contrôleur de domaine, nous sélectionnerons « Gestion des stratégies de groupe ».

Dans le menu latéral, nous nous rendrons dans le nœud de notre domaine :  Forêt : « votre_nom_de_forêt » > domaine > « votre_nom_de_forêt » .Dans le menu contextuel de l’unité d’organisation, nous sélectionnerons « Créer un objet GPO dans ce domaine, et le lier ici … » puis nous donnerons un nom à notre nouvel objet GPO.

L’étape suivant consistera à modifier cette stratégie, dans le menu contextuel de notre nouvel objet GPO, nous sélectionnerons « Modifier ».

Notre stratégie est une configuration d’ordinateur, nous sélectionnerons donc « Stratégies » qui se trouve en dessous de « Configuration ordinateur ».

Nous avons 3 choix possible, Paramètre logiciel, Paramètre Windows et Modèle d’administration. Pour ce qui nous concerne, c’est un paramètre de sécurité Windows, nous déplierons « Paramètre Windows », et nous déplierons « Paramètre de sécurité » pour pouvoir sélectionner « Stratégies locales ».

Nous rentrerons ensuite dans les « Attribution des droits utilisateurs » et nous modifierons les propriétés du paramètre « Interdire l’ouverture d’une session locale » en y effectuant un doucle-clic.

Nous cocherons la case « Définir ces paramètres de stratégie », puis nous cliquerons sur le bouton « Ajouter un utilisateur ou un groupe ». Dans la fenêtre Ajouter un utilisateur ou un groupe, nous cliquerons sur le bouton « Parcourir… » pour sélectionner le groupe pf_administrateur, pf_technicien et notre utilisateur pfsense.

Nous validerons ce choix en cliquant sur OK à chaque fenêtre.

Pour vérifier que notre stratégie est bien fonctionnelle, nous tenterons de nous connecter sur notre poste client avec l’un des comptes pour lequel nous avons interdit l’ouverture de session locale.

Attribution des droits aux utilisateurs pfSense

PfSense offre une fonctionnalité puissante permettant la création de groupes d’utilisateurs, offrant ainsi une gestion fine des privilèges et des accès. Cette approche flexible permet d’attribuer des droits différenciés en fonction du profil de chaque utilisateur. Par exemple, les droits d’accès d’un technicien de proximité ne seront pas les mêmes que ceux d’un administrateur, chaque utilisateur jouant un rôle défini avec un périmètre d’action spécifique au sein du système d’information.

Dans notre laboratoire, nous avons choisi d’utiliser notre contrôleur de domaine comme source d’authentification. Nous continuerons à exploiter cette source pour la création de nos groupes. Une fois ces groupes établis dans notre Active Directory, nous les associerons à des groupes préalablement créés dans PfSense.

Dans notre Active Directory, nous avons créés deux groupes, pf_administrateur et pf_technicien. Dans notre mise en pratique, pf_administrateur aura tous les droits et pf_technicien aura des droits plus restreints.

Avant d’attribuer les droits à nos groupes, nous créerons deux groupes dans notre pfSense et nous lierons ses groupes à nos deux groupes de sécurité présent dans notre Active Directory.

Dans pfSense, nous déroulerons le menu « System » pour nous rendre dans le menu « User Manager ».

Ensuite nous nous rendrons dans l’onglet « Groups » où nous cliquerons sur le bouton « Add ».

Dans le formulaire de création du groupe, nous indiquerons le nom de notre groupe, il doit être strictement identique au nom de notre groupe de sécurité créé dans notre Active Directory, c’est dû au fait qu’il porte le même nom qu’ils sont liés.

Après avoir renseigner le nom, nous préciserons que le groupe est disponible à distance. Dans la liste déroulante « Scope », nous sélectionnerons « Remote ». Nous pouvons éventuellement ajouter une description. Pour valider, nous cliquerons sur le bouton « Save ».

De la même façon, nous ajouterons le deuxième groupe, pf_technicien.

Nos deux groupes ont été ajouté à notre pfSense.

Les groupes étant créé, nous ajusterons leurs droits. La gestion des droits se fait dans les paramètres du groupes concernés, il nous faut donc modifier le groupe. Pour ce faire, nous cliquerons sur le bouton modifier représenté par un crayon dans la colonne action.

Pour le groupe pf_administrateur, nous lui attribuerons tout les droits. Nous cliquerons sur le bouton modifier.

En bas de page, dans la section « Assigned Privileges », nous cliquerons sur « Add » pour afficher les options privilèges que nous pouvons attribuer au groupe pf_administrateur.

Dans la liste de choix, nous avons accès à la liste de tous les privilèges que nous pouvons attribuer à notre groupe. Dans notre cas, nous souhaitons lui donner tout les droits, c’est-à-dire lui donner accès à tout les paramètres de notre pfSense. Nous sélectionnerons donc « WebCfg – All pages ».

Pour valider notre choix, nous cliquerons sur le bouton « Save » présent en bas de page.

Dans les paramètres de notre groupe, nous constaterons que les privilèges ont été ajouter. Nous enregistrerons notre modification en cliquant sur le bouton « Save ».

Pour le groupe pf_technicien, nous lui attribuerons des accès plus restreint c’est-à-dire, le droit de voir les logs du pare-feu, les logs système, le graphique trafic ; il aura également la possibilité de faire des requêtes ICMP. Ses paramètres sont liées au accès aux pages suivant.

• WebCFG – Dashboard
• WebCFG – Diagnostics :Ping
• WebCFG – Diagnostics :Traceroute
• WebCFG – Status : Logs :System
• WebCFG – Status : Logs :Firewall
• WebCFG – Status : Traffic Graph

Pour modifier les droits, nous allons nous modifierons notre groupe, puis nous lui attribuerons les priviléges listé ci-dessus.

Avant de tester que nos modifications sont fonctionnelles, nous modifierons la source d’authentification utiliser par défaut. Dans l’onglet, Setting, nous sélectionnerons « Active Directory » dans la liste déroulante « Authentication Server » puis nous validerons ce choix en cliquant sur le bouton « Save ».

Nous testerons en premier lieu avec l’utilisateur « pf_tech » est membre du groupe pf_technicien qui a des droits restreints. Nous constaterons que nous avons bien un accès restreint au vu du nombre d’élément que compose notre menu.

Pour le compte pf_admin, nous constaterons qu’il aura tous les accès.

Renforcement de la sécurité LDAP

LDAP (Lightweight Directory Access Protocol) est un protocole largement utilisé pour l’authentification et l’accès aux services d’annuaire. Cependant, comme tout protocole, il présente certaines faiblesses en termes de sécurité. Par défaut, LDAP transmet les données en clair, exposant ainsi les informations sensibles, y compris les identifiants, à d’éventuels attaquants qui pourraient intercepter le trafic réseau.

Nous constaterons cette faiblesse à l’aide une mise en pratique utilisant Wireshark. Sur notre machine physique, si ce n’est pas déjà fait, nous installerons WireShark pour sniffer notre réseau. Après avoir installé Wireshark, nous sélectionnerons l’interface réseau « VMware Network Adapter VMNET1 », en double cliquant dessus.

A l’aide d’un filtre d’affichage, nous listerons que les communications LDAP, renseigner ldap dans le champs filtre puis valider à l’aide du bouton [entrée] du clavier.

Depuis notre interface d’administration de pfSense, nous nous identifierons, ce qui générera du trafic LDAP qui seront visibles dans Wireshark

Sur la première ligne du trafic réseau de Wireshark, nous ouvrirons le menu contextuel, nous sélectionnerons « Suivre », puis « TCP stream », cela nous permettra de retracer toutes les communications LDAP liée à cet échange..

Nous constaterons que le mot de passe transite dans le réseau en claire.

Il est fréquent d’entendre dans les services informatiques qu’il faut désactiver le protocole Telnet présent par défaut dans les équipements réseau. La raison à cela, est la même que celle décrit dans cette section. LDAP et Telnet bien qu’ils jouent un rôle bien distinct, partage cette même faiblesse, à savoir une communication non chiffrée.

Cette faiblesse peut être atténuée en utilisant LDAP avec StartTLS ou en établissant des connexions sécurisées via LDAPS, c’est cette deuxième option que nous allons explorer dans cette documentation.

Pour configurer le LDAPS, il est essentiel de comprendre son fonctionnement. Le LDAPS est un protocole qui vise à sécuriser les communications LDAP en utilisant le protocole TLS (Transport Layer Security), qui est également connu sous le nom de SSL (Secure Sockets Layer). Le protocole LDAP fonctionne à la couche 7 du modèle OSI (couche application), tandis que le TLS opère aux niveaux des couches 6 (présentation) et 4 (transport).

D’un point de vue fonctionnel, dans notre contexte, lorsqu’une requête LDAP est émise par pfSense, elle est chiffrée à l’aide d’une clé publique. Le serveur Active Directory réceptionne la requête, la déchiffre à l’aide de sa clé privée, puis traite la demande de manière sécurisée.

Nous avons donc besoin d’avoir un générateur de clé, ce générateur de clé est une fonctionnalité des autorités de certification. L’autorité de certificat sera en charge de créer les couples de clé, 1 privé qui sera utilisé par notre contrôleur de domaine et une clé publique qui sera distribué aux clients, dans notre cas, à pfSense.

L’autorité de certification aura également la charge de certifié de l’authenticité de la clé publique, ce qui donnera lieu à un certificat numérique, ce certificat sera signé par la clé privée. Lorsque la connexion entre notre pfSense et notre client est établie, c’est-à-dire que les 3 handshake (SYN, SYN-ACK, ACK) du protocole TCP ont été effectué, pfSense va demander le certificat d’authenticité au serveur Active directory. Pfsense soumettra ce certificat à une autorité de certification pour qu’il le valide.

En utilisant LDAPS, nous chiffrons les messages LDAP pour assurer la confidentialité des données transitant entre pfSense et le serveur Active Directory. De plus, en vérifiant le certificat d’authenticité du serveur auprès de l’autorité de certification, nous nous assurons de l’identité légitime du serveur. Ainsi, LDAPS offre à la fois la confidentialité et l’authenticité dans les communications LDAP, renforçant la sécurité de l’ensemble du processus.

Mise en place d’une autorité de certification

Microsoft propose un service de rôle à déployer pour mettre en place une autorité de certification. Sur notre contrôleur de domaine, nous installerons le rôle AD CS, nous en auront besoin pour activer le service de rôle Autorité de certification.

Dans le gestionnaire de serveur, nous cliquerons sur Ajouter des rôles et des fonctionnalités.

Nous allons ensuite passer le message présentant l’assistant d’ajout des rôles et des fonctionnalités. Dans la fenêtre « Sélectionner le type d’installation », nous cliquerons sur le bouton « Suivant ».

Après avoir indiqué sur quel serveur nous souhaitons ajouter le rôle, nous sommes amené à sélectionner le rôle que nous souhaitons installer.

Nous n’ajouterons pas de fonctionnalités, ce qui nous emmène à la fenêtre de présentation du rôle Service de certificats Active Directory.

Par défaut, le service de rôle proposé est « autorité de certification », pour notre lab, nous n’aurons besoin que de ce service de rôle, nous pouvons cliquer sur le bouton suivant et confirmer notre choix en cliquant sur le bouton « Installer » dans la fenêtre qui suit.

Après avoir installé le rôle AD CS et le service de rôle Autorité de Certification, nous devons le configurer. Confirmer les identifiants puis cliquer sur le bouton « Suivant »

Nous activerons l’Autorité de certification en cochant la case « Autorité de Certification ». Nous aurons ensuite le choix entre installer une autorité de certification d’entreprise ou une autorité de certification autonome. Notre choix se portera sur la première option, c’est-à-dire l’installation d’une autorité de certification d’entreprise. De manière générale, lorsque nous voulons déployer une autorité de certification en local sans avoir à mettre en place une infrastructure de clé publique (PKI – Public Key Infrastructure), l’option d’installation d’une autorité de certification d’entreprise sera privilégiée.

Dans Windows Server, il existe deux types d’autorité de certification, l’autorité racine ou l’autorité de certification secondaire, cela permet de répartir la charge et la responsabilité des actions de notre autorité de certification, dans notre cas, nous aurons qu’un seul serveur, par conséquent, nous sélectionnerons Autorité de certification racine, nous créerons ensuite la clé privée qui permettra à l’autorité de certification de signé les certificats.

La configuration de la clé privée passe par le paramétrage de 3 éléments :

• Le chiffrement
• Le nom de l’AC
• Période de validité.

Pour ce qui concerne le chiffrement, nous utiliserons les valeurs qui nous sont proposées par défaut, il en sera de même pour le nom de l’AC. Concernant la durée de validité, nous mettrons une durée volontairement longue, 100 ans Nous laisserons les emplacements par défaut de la base de données de certificats et du journal de la base de données de certificats. En résumé, hormis pour la fenêtre « Période de validité », toutes les autres fenêtres conserverons leurs valeurs par défaut.

Nous arrivons aux étapes finales. Après avoir vérifié les informations que nous avons renseignées, nous pouvons cliquer sur le bouton « Configurer ». Nous terminerons en cliquant sur le bouton « Fermer » à la fin de la configuration.

L’installation du rôle AD CS va entraîner des modifications au niveau du système d’exploitation. Pour que ces changements soient pris en compte, il nous faut redémarrer le serveur. Après les modifications apportées au niveau du système d’exploitation, d’autres changements interviennent, par exemple, les certificats doivent être activés et configurés, ce qui nécessitera également un redémarrage. Entre les deux redémarrages, nous attendrons quelques minutes (environ 5 minutes devraient être suffisantes) pour que les premières modifications aient le temps d’être appliquées et prises en compte.

Au redémarrage du serveur, nous testerons que notre AD CS est bien fonctionnel, Microsoft met à disposition un utilitaire baptisé ldp.exe, accessible dans C:\Windows\System32\.

Nous nous connecterons à notre serveur Active Directory, nous déroulerons le menu Connexion, et nous sélectionnerons « Se connecter… ». L’outils étant exécuté sur notre serveur Active Directory, nous renseignerons « Localhost » dans le champ « Serveur », nous cocherons la case SSL, et nous indiquerons le port par défaut du protocole LDAPS, c’est-à-dire 636. Une fois que toutes ses informations ont été renseigner dans la fenêtre « Se connecter », nous cliquerons sur le bouton « OK ».

Dans la réponse, il ne doit y avoir aucune erreur, et nous devons recevoir la confirmation que la connexion a été établie.

Chiffrement des requêtes LDAP avec LDAPS

Pour chiffrer notre communication, nous aurons besoin de notre clé publique sur pfSense. Il faudra donc l’exporter depuis notre serveur AD CS, puis l’importer dans pfSense.

Sur le Serveur Active Directory où nous avons installé le rôle AD CS, nous allons nous rendre dans le magasin de certificat. Après avoir ouvert la fenêtre « Exécuter » à l’aide de la combinaison de touche [windows] + [R], nous ouvrirons l’outil MMC.

Dans l’outil MMC, nous déroulerons le menu « Fichier », puis nous sélectionnerons « Ajouter/Supprimer un composant enfichable ».

Dans les composants, nous sélectionnerons Certificats, en précisant que cette console gérera un compte ordinateur, cette option sera proposée après avoir cliqué sur le bouton « Ajouter ».

Après avoir cliqué sur suivant dans la fenêtre « Composant logiciel enfichable Certificats », nous préciserons que ce composant gérera l’ordinateur local. Après avoir cliqué sur Terminer, nous cliquerons sur le bouton « OK » pour valider notre choix.

Nous déroulerons ensuite « Certificats ordinateurs », « Autorités de certification racines de confiance », pour nous rendre dans le conteneur Certificats. Nous retrouvons les certificats de notre autorité de certification, nous le sélectionnerons puis nous afficherons le menu contextuel à l’aide du clic-droit de la souris. Dans le menu contextuel, nous sélectionnerons « Exporter » accessible sur la liste « Toutes les tâches ». Cette action aura pour effet d’ouvrir l’assistant d’exportation de certificat.

Après avoir passé le message de bienvenu de l’assistant d’exportation de certificat, nous conserverons la proposition du format faite par défaut, à savoir, l’option « X.509 binaire encodé en base 64 (*.cer).

Nous exporterons ce certificat sur notre bureau, nous devrons également lui donner un nom. La fenêtre suivante, nous amène à la fin de l’assistant Exportation du Certificat, nous cliquerons sur le bouton « Terminer ».

Ce certificat devra être importer dans pfSense, pour des raisons pratiques, nous accéderons à l’interface Web de gestion de notre pfSense depuis le navigateur de notre contrôleur de domaine. Après nous être authentifier, nous déroulerons le menu System et nous sélectionnerons « Certificates ».

Pour importer notre certificat, après avoir vérifié que nous sommes bien dans l’onglet « Authorities », nous cliquerons sur le bouton « Add», ce qui nous permettra d’accès au formulaire d’importation de certificat.

Dans la section « Create / Edit CA », nous attribuerons un nom à notre Autorité de certification, nous déroulerons la liste Method pour sélectionner « Import an existing Certificate ».

Dans la zone de texte « Certificate data », nous ajouterons le contenu du certificat que nous avons exporter. Pour récupérer le contenu, il nous faut l’ouvrir avec le bloc-notes de Windows.

Une fois le contenu du bloc-notes de Windows copier, nous retournerons dans notre formulaire d’importation de certificat et nous collerons le contenu de notre certificat dans le champ « Certificate Data », puis nous sauvegardons cette configuration en cliquant sur le bouton « Save »

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

Pour que le certificat puisse être vérifier, il faut que notre pfSense puisse résoudre les noms de notre domaine Active Directory. Nous allons nous en assurer en déroulant le menu « System » de pfSense et nous nous rendrons dans « General Setup ».

Dans la section « DNS Server Settings », nous vérifierons que le Server DNS est bien notre contrôleur de domaine.

Nous allons nous assurer également qu’il utilise le DNS de notre domaine, nous allons donc le forcer à l’utiliser.

Après avoir sauvegarder ses changements, nous allons modifier la configuration de notre server d’authentification. Nous déroulerons le menu « System », puis nous nous rendrons dans l’onglet « Authentification Servers » de « User Manager ». Nous cliquerons sur le bouton modifier pour activer le LDAPS.

Dans la section « LDAP Server Settings », nous remplacerons l’adresse IP par le nom complet de notre contrôleur de domaine. Dans le champ « Port Value », nous indiquerons le port de LDAPS soit 636 et nous modifierons également le champs « Transport » où nous sélectionnerons dans la liste déroulante « SSL/TLS Encrypted ». Nous devons également préciser que le nom de l’autorité de certification qui va gérer les certificats de cette connexion, c’est bien entendu le nom que nous avons indiqué précédemment lorsque nous avons importé le certificat de notre AD CS vers pfSense.  Les autres éléments que nous avions configurés resterons les mêmes. Nous validerons cette configuration en cliquant sur le bouton « Save ».

Nous testerons que notre authentification est toujours fonctionnelle, nous en profiterons également pour vérifier que la connexion est bien chiffrée. Après avoir ouvert Wireshark sur notre machine physique et sélectionné l’interface VMNET1.

Dans pfSense, nous allons dérouler le menu « Diagnostics », puis nous sélectionnerons « Authentication ».

Après avoir renseigner les informations d’identification de l’un de nos utilisateurs, nous cliquerons sur le bouton « Test ».

Dans Wireshark, nous pouvons remarquer que plus aucune requête LDAP passe en claire dans notre réseau.

Pour renforcer la sécurité, nous pourrions exploiter des outils IAM (Identity and Access Management), qui rassemblent divers processus, technologies et politiques. Ces outils visent à gérer et sécuriser l’accès aux ressources en attribuant des droits granulaires aux utilisateurs.

L’article Sécurisé l’accès à Pfsense est apparu en premier sur Pandawan.

Présentation du lab

La configuration réseau sur VMware Workstation

Nous aurons besoin de 3 VMNet :

• VMNET1 : Host only – réseau 10.1.0.0/24 – LAN
• VMNET2: Host only – réseau 10.2.0.0/24 – DMZ
• VMNET8: NAT – réseau 10.0.0.0/24 – Internet (ce réseau simulera le réseau internet)

Les machines virtuelles

Nous ne rentrerons pas dans le détail de l’installation des serveurs et de la machine client. Nous nous arrêterons à une présentation des configurations et des services qui y sont installées Le réseau local (LAN) héberge un domaine Active Directory nommé «elkhrissi.lab », comprenant un contrôleur de domaine. Un poste client exécutant un Windows sera installé et intégré au domaine.

Le serveur Web, localisé dans la zone démilitarisée (DMZ), ne fera pas partie du domaine. Il exécutera la distribution Almalinux installé en mode minimal, c’est-à-dire sans interface graphique. Pour des questions de confort, il sera plus pratique d’utiliser un client SSH (Putty, Mobaxterm, etc). Le service httpd sera installé, le pare-feu est activé et configuré pour autoriser les requêtes http (port 80).

Installation et configuration de base de Pfsense

L’installation de pfSense, un UTM (Unified Threat Management) open source basé sur FreeBSD, optimise et sécurise la gestion des passerelles pour les réseaux LAN et DMZ. En intégrant pfSense dans notre infrastructure, nous établissons une passerelle de sécurité robuste qui non seulement assure le filtrage de trafic à travers le pare-feu, mais enrichit également notre réseau avec des fonctionnalités de sécurité avancées. Pour ce faire, nous procédons à la connexion de pfSense à la fois aux réseaux LAN et DMZ, tout en le reliant directement à Internet, garantissant ainsi une protection complète et une gestion efficace du trafic réseau.

Les étapes d’installation

Nous lançons la machine et acceptons la licence pfSense. Puis, nous choisissons ‘Install’ pour commencer l’installation de pfSense.

Nous arrivons ensuite sur la configuration du système de fichier, nous avons 4 choix possibles :

Auto (ZFS) : Zettabyte File System est un système de fichiers avancé qui offre de nombreuses fonctionnalités. Permis ses fonctionnalité nous pouvons lister la gestion avancée des volumes, la déduplication, la compression, la réparation automatique des erreurs, etc. Il prend en charge la gestion dynamique des volumes, ce qui signifie que vous pouvez ajouter ou retirer des disques sans avoir à redémarrer le système. ZFS offre une meilleure gestion des instantanés (snapshots) pour la sauvegarde et la restauration du système.

Auto (UFS) : UFS (Unix File System) est un système de fichiers plus traditionnel et plus simple, utilisé depuis longtemps dans les systèmes basés sur Unix. Il offre des fonctionnalités de base sans les fonctionnalités avancées de ZFS. UFS est généralement moins gourmand en ressources que ZFS, ce qui peut être important dans des environnements où les ressources sont limitées.

Manual :Manual vous permet de personnaliser davantage la configuration des partitions et du système de fichiers. Vous pouvez définir manuellement les partitions, les points de montage et d’autres paramètres de stockage. Cette option est généralement utilisée par des utilisateurs avancés qui ont des exigences spécifiques en matière de configuration du stockage.

Shell : L’option Shell donne accès à une ligne de commande (shell) où vous pouvez effectuer des opérations manuelles et avancées. Cela peut être utile pour les utilisateurs qui souhaitent effectuer des opérations spécifiques via la ligne de commande ou qui ont besoin d’un accès direct pour résoudre des problèmes.

Nous choisirons l’option Auto (ZFS) et nous passerons à l’installation.

Dans la configuration de notre machine, nous n’avons qu’un seul disque, nous n’avons donc pas d’autre possibilité que de sélectionner l’option « strip » et nous sélectionner notre disque à l’aide de la barre d’espace de de notre clavier.

Ensuite, nous confirmerons notre souhait d’utiliser ce disque pour l’installation de pfSense.

A la fin de l’installation de Pfsense, nous redémarrerons la machine après l’installation.

Après redémarrage, la machine affiche des informations et un menu. Le menu révèle deux interfaces réseau configurées : WAN et LAN. WAN obtient sa configuration via DHCP de VMware Workstation. L’interface LAN est configurée manuellement avec l’adresse IP 192.168.1.1/24 par pfSense.  

Après le redémarrage, nous consultons les informations et le menu. L’interface WAN et l’interface LAN, sont configurées par défaut. WAN se configure via DHCP de VMware Workstation. LAN reçoit manuellement 192.168.1.1/24 de pfSense. Nous vérifierons ensuite si LAN correspond bien à VMnet1.

Configuration des interface réseau

D’abord, nous identifions les interfaces réseau de notre pfSense virtuel. Nous accédons aux options via le menu contextuel de l’onglet VM dans VMware Workstation.

Après avoir sélectionner l’adapteur réseau, nous cliquerons sur le bouton « Advanced », nous aurons alors accès à l’adresse MAC de l’interface sélectionnée.

Dans le contexte de cet article, les adaptateurs réseaux ont les adresses MAC suivants :

Association des interfaces

Pour chacune de ses interfaces, nous leurs attribuerons des périmètres spécifique, WAN, LAN, OPT1. OPT1 sera notre DMZ. Pour ce faire, dans le menu de pfSense, nous sélectionnerons l’option 1 – Assign interface. Nous voyons la liste de nos interfaces. Il nous ait proposée de configurer des vlan, dans notre contexte, nous n’en avons pas besoin, nous indiquerons non à l’aide de la touche [n] de notre clavier. Notons que le clavier est en QWERTY

En tenant compte des adresses MAC de nos adaptateurs réseau mentionnées précédemment, les associations des interfaces sera la suivante :

La première assignation demandée est l’interface WAN, qui correspond dans notre lab à em0. Ensuite, nous assignerons l’interface LAN en indiquant em1. Puis nous terminons en assignant notre dernière interface réseau au périmètre OPTION1. Pour terminer, nous validerons en acceptant de continuer.

Après l’application des changements, nous observons l’ajout de la troisième interface.

Désactivation du DHCP dans Vmware Workstation

La prochaine étape sera de modifier les configurations réseaux des interfaces. VMWARE utilise l’identifiant d’hôte 254 pour son DHCP. Nous désactiverons le DHCP sur le réseau VMNET1 et VMNET2 pour pouvoir utiliser le HostID 254 . Pour effectuer cette modification, nous déroulerons le menu « Edit de VMware Workstation » . Dans la liste déroulante nous sélectionnons « Virtual Network editor » et cliquerons sur le bouton « Change Settings ».

Pour VMNET1 et VMNET2, nous décocherons l’option « Use local DHCP service to distribute IP address to VMs », nous appliquerons cette nouvelle configuration en cliquant sur le bouton « Apply » puis nous nous terminerons en cliquant sur le bouton « OK ».

Nous allouerons l’identifiant hôte 254 aux zones LAN et OPT1 ; ces deux interfaces agiront en tant que passerelles pour leurs réseaux respectifs.

Configuration Interface LAN

Dans le menu pfSense, nous sélectionnerons le menu 2 – Set Interface(s) IP address, puis nous sélectionnerons notre interface WAN soit le choix 2 – LAN (em1 – static).

 Nous préciserons que nous ne souhaitons pas utiliser serveur DHCP pour configurer cette interface. Nous attribuerons l’adresse 10.1.0.254/24.

Nous n’aurons pas de passerelle située en amont, nous déléguerons à pfSense le rôle de routeur unique au sein de notre infrastructure. Dans une configuration d’entreprise, il est fréquent de mettre l’adresse IP du routeur du fournisseur d’accès à Internet, dans notre lab, nous n’en avons pas, donc il nous suffira d’appuyer sur la touche [entrée] pour ne pas configurer de « gateway upstream ». Nous n’configurons pas l’IPv6 dans notre contexte et répondons [n] pour « non » à la configuration du DHCPv6 demandée. Nous ignorerons la configuration de l’adresse IPv6 en appuyant sur le bouton « Entrée ».

Nous n’aurons pas besoin de DHCP pour notre environnement de lab, de ce fait nous répondrons [n]. Par la suite, il nous ait demandé d’activer le HTTP, nous y répondrons par [n] pour non. Nous en avons terminé avec cette interface, nous pouvons passer à la seconde interface en appuyant sur la touche « Entrée » pour continuer.

Du fait que nous avons répondu [n] au fait d’active le HTTP, l’interface d’administration sera accessible en HTTPS. Nous avons un accès à notre interface d’administration qui sera accessible à l’url https://10.1.0.254.

Configuration Interface OPT1

Pour l’interface de OPT1, nous observerons la même logique que pour l’interface LAN.

La configuration des interfaces est maintenant terminée, nous pouvons voir cette nouvelle configuration sur l’écran principal de notre machine pfSense.

Configuration de base

La configuration de base de Pfsense se fera à l’aide de se GUI. Pour cela, nous avons besoin de configurer notre client situé dans le LAN pour qu’il puisse y accéder.

Configuration du client Windows

Depuis notre machine cliente, nous allons nous rendre sur l’interface d’administration de pfSense. Pour que cela soit possible, nous devons avoir une configuration réseau qui inclus une adresse IPv4 dans le réseau de 10.1.0.0/24 et aussi, mais nous l’avons vu plus tôt, un adapteur réseau connecté au VMNET1. Du fait que nous avons désactivé le DHCP de VMware Workstation et que nous n’avons pas configuré le DHCP dans pfSense, nous devons configurer manuellement l’interface réseau. Pour cette documentation, la configuration réseau de la machine cliente, sera la suivant :

• Adresse IP : 10.1.0.10/24
• Passerelle : 10.1.0.254 (interface de pfsense)
• DNS : 10.1.0.3 (IP du Contrôleur de domaine, qui héberge DNS intégré à l’Active Directory).

Accéder à la GUI de pfsense

Depuis le navigateur, nous allons nous rendre sur l’interface d’administration de pfSense en renseignant l’adresse IP de l’interface LAN dans la barre d’adresse en utilisant le protocole HTTPS. Le certificat de pfSense étant auto-signé, nous aurons un message nous indiquant que la connexion n’est pas privée. Après avoir cliquer sur le bouton « avancé », nous cliquerons sur le lien « Continuer vers 10.1.0.254 (non sécurisé)

Après avoir renseigner les identifiants et le mot de passe par défaut suivant :

• Nom d’utilisateur : pfsense
• Mot de passe : pfsense

Configuration de base à l’aide du GUI de Pfsense

Nous avons ensuite accès à l’assistant de paramétrage de pfSense, puis à un message publicitaire de Netgate, qui est l’entreprise derrière le développement de pfSense.

Nous renseignons un nom d’hôte, le nom de notre de domaine, et l’adresse IP de notre serveur DNS. Par la suite, nous cocherons l’option « Override DNS ». Le fait de cocher cette option permettra aux requêtes DNS d’être traiter par le DNS local.

Nous configurerons les informations du serveur de temps, ici, nous utiliserons le serveur NTP par défaut et nous précisons notre fuseau horaire.

Finalisation des configurations des interfaces

Nous passons ensuite à la configuration des interfaces :

Pour l’interface WAN, il nous faudra décocher les options :

• Block private networks from entering via WAN
• Block non-Internet routed networks from entering via WAN

Ses deux options, block les adresses IP privée sur l’interface qui, normalement, devrait avoir une adresse IP public. Dans notre contexte de LAB, nous avons des adresses IP privées et si nous laissons ses deux cases cochées nous ne pourrons pas avoir d’accès à Internet.

Pour ce qui concerne l’interface LAN, la configuration a été faite, nous pouvons cliquer sur le bouton « Next ».

Modification du mot de passe par défaut

Nous modifierons le mot de passe et le confirmerons avant de cliquer sur le bouton « Next ».

Fin de la configuration de base

Pour que les modifications que nous avons apportées soient prise en considération, nous devons recharger la configuration.

Après le rechargement de la configuration, nous avons accès au bouton « Finish ».

Après avoir cliqué sur le bouton « Finish », nous devons accepter les termes du copyright, nous aurons alors accès au tableau de bord avec notamment le support de Netgate Services and support que nous allons supprimer en cliquant sur la croix présente dans le titre de l’encadré.

Vérifier de la connectivité

Avant de terminer cette partie, nous allons vérifier que nous avons bien un accès à Internet. Nous déroulerons le menu déroulant Diagnostics et nous sélecterons l’outils « Ping ».

Après avoir renseigner un nom de domaine public dans le champ Hostname, nous cliquerons sur le bouton « Ping ».

L’article Installation Pfsense sur VMWare Workstation est apparu en premier sur Pandawan.