Exercices corrigés pfSense type E6 et E7 SISR

1. Le pare-feu garde une table des connexions et accepte automatiquement les réponses d'une connexion autorisée : on écrit une seule règle par flux, dans le sens où la connexion s'ouvre, sur l'interface d'entrée. Une règle de retour serait inutile et dangereuse.
2. pfSense applique la redirection avant le filtrage : au moment où les règles sont lues, l'adresse de destination du paquet a déjà été remplacée par l'adresse privée du serveur.
3. Le serveur est joignable depuis Internet, donc exposé aux attaques. En DMZ, s'il est compromis, l'attaquant ne peut joindre que ce que les règles de la DMZ autorisent (l'API, sur un port) ; dans le VLAN SRV, il serait à côté du contrôleur de domaine et des données médicales, sans aucun filtrage entre eux.
4. Une passerelle sur le pare-feu force tout le trafic des invités à passer par ses règles et ses journaux : il est filtré et tracé, et aucun équipement interne ne le route. Sur le switch de cœur, le trafic invité serait routé au milieu du réseau interne, avec au mieux un filtrage sans état et sans journal.

Alias : DC = 10.50.20.10 ; GESTION = 10.50.20.20 ; PACS = 10.50.20.40 ; INTERNES = 10.50.0.0/16, 172.20.0.0/28, 192.168.77.0/24 ; PORTS_AD_TCP = 53, 88, 135, 389, 445, 464, 636, 3268, 3269, 49152:65535 ; PORTS_AD_UDP = 53, 67, 88, 123, 389, 464 ; PORTS_WEB = 80, 443.

Les règles 5 et 6 précèdent la navigation : sans elles, « 80, 443 vers any » donnerait accès aux interfaces web internes et à celle du pare-feu (par son adresse publique). Les deux règles Default allow d'origine, si SOIN était l'ancien LAN, sont supprimées.

IMAGERIE

Les appareils ont des adresses fixes (sinon, ajouter DNS et DHCP vers DC). Ils n'ont aucun besoin d'Internet : des appareils médicaux rarement mis à jour ne doivent rien joindre d'autre.

DMZ

INVITES

Il n'y a pas de contrôleur de domaine pour les invités : s'ils sont servis par le DHCP de l'annuaire à travers le relais, on n'autorise pas l'UDP 67 en unicast, le renouvellement se fera par diffusion (chapitre 8).

1. La règle « Refus final IMAGERIE » : l'échographe envoie vers le port 104 (le port historique de DICOM), alors que la règle 1 n'autorise que le port 11112. Aucune règle ne correspond avant le refus final.
2. (a) Configurer l'échographe pour envoyer sur le port 11112, comme les autres appareils, si le serveur d'images n'écoute que sur ce port ; (b) si le serveur d'images écoute aussi sur 104, ajouter 104 à la règle 1 (alias PORTS_DICOM = 104, 11112). On préfère (a) quand c'est possible : une seule configuration pour tous les appareils, une règle inchangée. Dans les deux cas, on teste et on vérifie que la colonne States de la règle 1 augmente.

Une ligne de refus de la règle 5 (« Refus vers l'interne », si elle est journalisée comme prévu) : par exemple 10.50.10.31:51200 -> 10.50.20.40:11112 TCP:S. 10.50.20.40 fait partie de INTERNES (10.50.0.0/16) : la règle 5 correspond avant la règle 6, qui n'est jamais lue. Correction : remonter la règle 6 au-dessus de la règle 4, avec les autres autorisations vers les serveurs.

1. Une redirection de port : Interface WAN, Protocol TCP, Destination WAN address (198.51.100.33) port 443, Redirect target IP 172.20.0.1, port 443, Filter rule association Add associated filter rule. La règle créée dans l'onglet WAN : Pass, TCP, source any, destination 172.20.0.1, port 443. Même chose pour le port 80 si le site redirige vers HTTPS.
2. (a) Firewall > Virtual IPs : une adresse de type IP Alias sur le WAN, 198.51.100.34/29, pour que le pare-feu réponde pour cette adresse ; (b) Firewall > NAT > Outbound, mode Hybrid ; (c) une règle manuelle : Interface WAN, Source 10.50.20.20/32, Destination any (ou l'adresse du prestataire de SMS), Translation 198.51.100.34. Elle est lue avant les règles automatiques, qui continuent de traduire tout le reste vers 198.51.100.33. (d) Il faut aussi une règle de filtrage sur l'onglet SRV qui autorise GESTION à joindre l'API du prestataire en HTTPS.
3. Le mode hybride : les règles automatiques couvrent tous les réseaux internes, et une seule règle manuelle traite l'exception. En mode manuel, il faudrait écrire et tenir à jour une règle pour chaque réseau ; un VLAN ajouté plus tard et oublié n'aurait plus accès à Internet.
4. Non : le besoin ne concerne que la sortie avec une adresse fixe. Un NAT 1:1 traduirait aussi l'entrée et associerait toute l'adresse publique au serveur de gestion : il suffirait d'une règle WAN trop large pour exposer le serveur qui contient les données des clients. Le NAT sortant hybride répond exactement au besoin.

1. Local Network 10.50.20.40/32 (le seul serveur d'images), Remote Network 192.168.77.0/24. Au plus juste : le tunnel ne transporte que ce qui est nécessaire.
2. TS_UNACCEPTABLE signifie que les sélecteurs n'ont aucun recouvrement : le cabinet a sans doute saisi une autre adresse ou un autre réseau (faute de frappe sur 10.50.20.40, ou 192.168.77.0/24 inversé entre local et distant). Un réseau plus large qui contiendrait 10.50.20.40 (10.50.20.0/24, par exemple) ne donnerait pas cette erreur : en IKEv2, il serait réduit à /32. Compare les deux configurations dans Status > IPsec > SPDs et aligne-les : 192.168.77.0/24 en local et 10.50.20.40/32 en distant chez le cabinet.
3. Les règles de l'onglet IPsec :

Sur le WAN, rien à écrire : pfSense ajoute automatiquement les règles IKE et ESP vers et depuis 203.0.113.90.

1. Au moins 18 blocages en 45 secondes depuis la même adresse : un balayage du réseau interne. La source est dans 10.50.40.0/24, le Wi-Fi invité : un appareil de la salle d'attente cherche les services du contrôleur de domaine, du logiciel de gestion et du poste d'administration.
2. Oui : tout a été bloqué, par la règle « Isolation » (refus de INVITES vers INTERNES) de l'onglet INVITES.
3. Identifier l'appareil (adresse MAC dans le bail DHCP, ticket ou compte du portail captif s'il y en a un) ; le déconnecter et bloquer son adresse MAC sur le Wi-Fi ; conserver les journaux du pare-feu et de Wazuh comme preuve ; vérifier que l'isolation des clients est active sur les bornes ; consigner l'événement et, selon la procédure de la clinique, le déclarer comme incident de sécurité.
4. Une alerte sur le taux d'occupation de la table d'états (une attaque qui ouvre des milliers de connexions la remplit) ou sur le trafic bloqué par interface, collectés par le modèle PFSense by SNMP ; et, côté disponibilité, la perte de réponse SNMP du pare-feu.