Sécuriser mon infrastructure

Je mets en œuvre un équipement de sécurité

Un réseau qui s'ouvre, un risque qui grandit

DKTOYS grandit : l'entrepôt et le siège de Dunkerque accueillent chaque mois de nouveaux postes, une succursale vient d'ouvrir à Reims, et un site e-commerce est en projet pour vendre les jouets directement en ligne. Chaque nouvelle ouverture — un lien vers Reims, une future publication sur Internet — est aussi une nouvelle porte d'entrée potentielle pour un attaquant. Le fil conducteur de ce cours est de sécuriser progressivement cette infrastructure : ce premier chapitre pose la pièce maîtresse, l'équipement de sécurité en coupure entre le réseau de DKTOYS et le monde extérieur, sur lequel s'appuieront tous les chapitres suivants (ACL, accès Internet, DMZ, VPN).

Les missions du cours fixent le cap : sécuriser les flux internes, contrôler les accès Internet, publier un serveur dans une DMZ, configurer le VPN. Ce chapitre ne détaille pas une procédure d'installation pas-à-pas — les supports disponibles ne la couvrent pas — mais pose les principes et la configuration de base d'un pare-feu, indispensables avant d'aborder les chapitres suivants.

Choisir l'équipement : un pare-feu pfSense en coupure

DKTOYS retient pfSense, un système d'exploitation pare-feu/routeur open source, pour tenir ce rôle sur son site de Dunkerque (siège + entrepôt). Le même choix sera dupliqué à l'ouverture du site de Reims, pour homogénéiser l'administration entre les deux sites. Un pare-feu comme pfSense se positionne en coupure entre les réseaux qu'il sépare : tout paquet qui veut passer d'un réseau à l'autre transite obligatoirement par lui, ce qui en fait le point de contrôle central de la sécurité périmétrique.

Les interfaces réseau d'un pare-feu

Un pare-feu pfSense distingue plusieurs interfaces, chacune reliée à un réseau de confiance différent. Chez DKTOYS, pfSense DKTOYS-DK n'est pas l'équipement qui sépare les VLAN entre eux : ce rôle revient à SW-DKTOYS-DISTRIBUTION, le commutateur de niveau 3 du cours « Configurer les éléments actifs de mon réseau », qui porte l'ensemble des VLAN du site (Commercial, Administration, Entrepôt, Voix, Serveurs, Supervision) et assure lui-même tout le routage — et le filtrage par listes de contrôle d'accès — entre eux. pfSense DKTOYS-DK se limite à la bordure Internet du site, avec trois interfaces seulement :

L'interface WAN est la seule directement exposée à Internet : c'est elle qui reçoit le trafic entrant non sollicité, et c'est sur elle que portent en priorité les règles de filtrage. L'interface LAN, elle, ne voit passer que du trafic déjà routé par SW-DKTOYS-DISTRIBUTION — qu'il s'agisse d'un poste du VLAN Commercial ou d'un serveur du VLAN Supervision, tout emprunte cette même liaison de transit vers le pare-feu, qui n'a donc besoin d'aucune interface dédiée par VLAN. L'interface DMZ, elle, fait exception : pfSense DKTOYS-DK la porte directement, sans passer par le commutateur, ce qui l'isole complètement du reste du réseau interne (détaillé au chapitre consacré à la publication en DMZ).

À Reims, le routeur R-DKTOYS-REIMS (cours « Configurer les éléments actifs de mon réseau ») route déjà les VLAN de la succursale par sous-interfaces et porte sa propre sortie Internet, avec sa propre ligne publique. Un pare-feu pfSense dédié, pfSense DKTOYS-REIMS, est prévu pour homogénéiser l'administration entre les deux sites et pour porter, plus loin dans ce cours, le tunnel VPN vers Dunkerque ; son WAN (203.0.113.50) reste distinct de celui de pfSense DKTOYS-DK.

Le principe : tout bloquer, autoriser explicitement

La configuration par défaut d'un pare-feu correctement durci repose sur un principe simple, retrouvé plus loin dans ce cours avec les listes de contrôle d'accès : tout ce qui n'est pas explicitement autorisé est refusé. C'est ce qu'on appelle le deny implicite. Concrètement sur pfSense, cela se traduit par des règles posées dans Firewall > Rules, une liste par interface, évaluées de haut en bas :

• une règle Pass laisse passer le trafic qui correspond aux critères définis (interface, protocole, source, destination, port) ;
• une règle Block (ou Reject) refuse explicitement un trafic donné ;
• à défaut de règle correspondante, le trafic est bloqué par défaut sur toute interface autre que LAN.

Cette logique s'applique dès l'interface WAN : par défaut, aucun flux entrant depuis Internet n'est autorisé vers le LAN de DKTOYS — chaque service qui devra être exposé (messagerie, futur site e-commerce) fera l'objet d'une règle précise, abordée dans les chapitres sur la DMZ et le reverse proxy.

Anatomie d'une règle de pare-feu

Une règle pfSense (Pass ou Block) se construit toujours à partir des mêmes champs, quelle que soit l'interface sur laquelle elle est posée — ce sont ces mêmes champs qui reviendront au chapitre consacré à la publication en DMZ :

Documenter systématiquement le champ Description n'est pas une formalité : sur un pare-feu qui accumule des règles au fil des mois (nouvelle succursale, nouveau service publié), c'est souvent le seul moyen de comprendre six mois plus tard pourquoi une règle existe, avant de décider de la conserver ou de la supprimer.

L'ordre des règles compte

Les règles d'une interface ne sont pas évaluées globalement mais de haut en bas, et c'est la première règle qui correspond au paquet qui décide de son sort — les suivantes ne sont même pas examinées. Une conséquence très concrète : une règle large placée trop haut annule silencieusement toutes les règles plus fines placées en dessous.

Sur l'interface DMZ de DKTOYS, par exemple, une règle qui bloque DMZ net → LAN net doit impérativement être placée avant une éventuelle règle autorisant DMZ net → any ; dans l'ordre inverse, la seconde laisserait passer le trafic vers le LAN avant même que la règle de blocage ne soit lue. La règle générale de rédaction est donc : du plus spécifique au plus général, les exceptions et interdictions ciblées en haut, les autorisations larges en bas.

Block ou Reject : deux façons de refuser

pfSense propose deux actions de refus, qui ne se comportent pas de la même manière :

Côté WAN, Block est le choix par défaut et le bon réflexe : ne rien répondre prive un scanner d'informations sur la présence de machines. Côté LAN en revanche, Reject améliore nettement le confort de diagnostic — un poste de l'entrepôt qui tente un accès interdit obtient une erreur immédiate, ce qui évite les tickets « le réseau est lent » qui sont en réalité des flux bloqués en attente d'expiration.

Factoriser avec les alias

Un alias pfSense est un nom symbolique qui regroupe un ensemble d'adresses IP, de réseaux ou de ports, et qui peut ensuite être utilisé dans les champs Source, Destination ou Port d'une règle (c'est ce que propose l'option Single host or alias dans le champ Destination). Plutôt que de multiplier des règles quasi identiques, DKTOYS peut ainsi définir :

L'intérêt est double : les règles restent lisibles, et l'ajout d'un serveur ou d'un poste se fait en modifiant l'alias une seule fois, sans reprendre chaque règle qui le référence.

Journaliser pour diagnostiquer

Chaque règle pfSense peut être configurée pour journaliser les paquets qu'elle traite (case Log packets that are handled by this rule). Les entrées correspondantes se consultent ensuite dans Status > System Logs > Firewall, avec l'interface, l'adresse source, la destination et la règle concernée.

C'est l'outil de diagnostic de premier niveau quand un flux ne passe pas : le journal indique si le paquet a bien atteint le pare-feu, sur quelle interface, et quelle règle l'a bloqué — ce qui permet de distinguer immédiatement un problème de filtrage d'un problème de routage ou de configuration côté poste. Attention toutefois à ne pas activer la journalisation sur toutes les règles d'un coup : le volume produit sur l'interface WAN d'un site exposé rend rapidement les journaux illisibles. On journalise ce que l'on diagnostique, puis on désactive.

Les flux visés pour DKTOYS-DK

La cible à atteindre pour le site de Dunkerque, une fois l'ensemble du cours déroulé, se résume en quelques lignes :

Ce tableau est la feuille de route du cours : chaque ligne correspond à une configuration qui sera posée dans l'un des chapitres suivants. Une distinction structure l'ensemble : pfSense DKTOYS-DK filtre tout ce qui franchit la bordure Internet du site (proxy, DMZ, VPN), tandis que le filtrage entre VLAN internes (VLAN 30 vers les VLAN de bureau) relève de SW-DKTOYS-DISTRIBUTION, détaillé au chapitre suivant.

Un équipement qui porte bien plus que le filtrage

pfSense n'est pas seulement un filtre de paquets : c'est une plateforme de sécurité (on parle d'UTM, Unified Threat Management, pour un équipement qui regroupe plusieurs fonctions de sécurité) sur laquelle s'installent des services complémentaires, via System > Package Manager. Pour DKTOYS, ce sont précisément ces services qui feront l'objet des chapitres suivants :

• le proxy web (squid/squidGuard) pour filtrer la navigation des postes, au chapitre 3 ;
• le portail captif, alternative d'authentification des accès réseau — que le chapitre 3 demandera justement de désactiver, car il entre en conflit avec le proxy ;
• le serveur VPN (OpenVPN, IPsec) pour les nomades et le lien avec Reims, aux chapitres 9 à 11 ;
• la gestion de certificats intégrée (autorité de certification interne), indispensable au proxy comme au VPN, et détaillée au chapitre 7 consacré à la PKI.

Sauvegarder la configuration avant d'y toucher

Toute la configuration de pfSense — interfaces, règles, alias, services — tient dans un unique fichier XML exportable depuis Diagnostics > Backup & Restore. Prendre cette sauvegarde avant chaque modification significative est le réflexe qui distingue une intervention maîtrisée d'une intervention risquée : une règle mal posée sur l'interface LAN peut couper l'accès à l'interface d'administration elle-même, et la restauration du fichier XML est alors le chemin le plus court pour revenir à un état fonctionnel. Pour DKTOYS, cette sauvegarde doit être conservée hors du pare-feu, avec les autres sauvegardes de l'entreprise.

Le pare-feu n'est pas le routeur inter-VLAN

Point important pour ne pas confondre les rôles au fil des chapitres suivants : pfSense DKTOYS-DK ne route pas entre les VLAN internes de Dunkerque. Ce routage — Commercial vers Serveurs, Administration vers Entrepôt, etc. — est intégralement assuré par SW-DKTOYS-DISTRIBUTION, via les interfaces virtuelles de VLAN (SVI) posées au cours « Configurer les éléments actifs de mon réseau ». La route par défaut de ce commutateur pointe vers pfSense DKTOYS-DK : c'est donc uniquement le trafic qui sort du site — vers Internet, ou vers la DMZ — qui atteint le pare-feu, déjà routé entre VLAN par le commutateur en amont.

Ce que pfSense DKTOYS-DK fait, en revanche : il assure le NAT/PAT de tout ce trafic sortant vers Internet, sur son unique adresse publique WAN — les adresses privées du plan DKTOYS (10.30.0.0/16) n'étant pas routables sur Internet — il publie le serveur web en DMZ sur les ports 80 et 443 (chapitre 4), et il termine les tunnels VPN, nomades et site à site (chapitres 9 à 11). Comme le pare-feu ne voit arriver, sur son interface LAN, que du trafic déjà routé et regroupé par le commutateur, une seule règle de traduction d'adresses suffit à couvrir l'ensemble des VLAN du site, sans déclaration séparée par VLAN.

Segmenter avant de filtrer

Séparer le VLAN 10 (Commercial), le VLAN 20 (Administration) et le VLAN 30 (Entrepôt) sur des réseaux IP distincts, comme le prévoit le plan retenu au cours « Configurer les éléments actifs de mon réseau », n'est pas qu'une question d'organisation : c'est la condition pour pouvoir ensuite appliquer des règles différenciées entre ces zones — un terminal logistique de l'entrepôt n'a par exemple aucune raison d'accéder directement aux serveurs de gestion du Commercial ou de l'Administration. Le chapitre suivant, consacré aux listes de contrôle d'accès (ACL) posées sur SW-DKTOYS-DISTRIBUTION, reprend précisément ce cas pour filtrer les flux entre le VLAN 30 et les VLAN de bureau.

Ce que les supports ne couvrent pas

Les supports de ce cours n'abordent pas l'installation et la mise en service initiale de pfSense (installation depuis l'image ISO, assignation des interfaces physiques en console, premier accès à l'interface web) : ils partent tous d'un pare-feu déjà opérationnel, avec ses interfaces WAN et LAN configurées, et travaillent ensuite dans Firewall > Rules, Services ou System > Package Manager. Ce chapitre suit la même logique et pose les principes de filtrage plutôt qu'une procédure d'installation. Les points présentés ici sur l'ordre d'évaluation, la distinction Block/Reject, les alias, la journalisation et la sauvegarde de configuration relèvent du fonctionnement standard de pfSense et des bonnes pratiques d'exploitation, et non d'une procédure décrite dans un support particulier.

Ce qu'il faut retenir

DKTOYS s'appuie sur un pare-feu pfSense positionné en coupure entre son réseau interne et Internet, avec trois interfaces seulement (WAN, un unique LAN de transit vers SW-DKTOYS-DISTRIBUTION, DMZ) qui séparent les zones de confiance — le routage et le filtrage entre les VLAN internes restant entièrement portés par ce commutateur de niveau 3, en amont du pare-feu. La règle de base de tout filtrage est le deny implicite : rien ne passe sauf ce qui est explicitement autorisé par une règle Pass, et les règles d'une interface sont évaluées de haut en bas, la première correspondance l'emportant — d'où l'importance de leur ordre. Block ne répond rien à l'émetteur là où Reject lui renvoie une erreur, les alias gardent les règles lisibles, la journalisation sert au diagnostic ciblé, et une sauvegarde de configuration précède toute modification sensible. Ce socle — interfaces bien posées, segmentation en VLAN portée par le commutateur, principe du moindre privilège appliqué aux flux — conditionne tous les chapitres suivants de ce cours : sécurisation du LAN par ACL, contrôle des accès Internet, publication en DMZ et VPN.