Épreuve blanche n° 1 : un réseau pour les visiteurs

Reformulation. « Créer un périmètre réservé aux visiteurs sur les prises de la salle de réunion : adressage automatique, accès au web, aucun accès au réseau du cabinet ni au pare-feu, sans coupure pour les salariés. »

Implicites et hypothèses.

• Les visiteurs n'ont pas de compte dans l'annuaire : aucune authentification sur ce réseau dans un premier temps.
• Hypothèse à signaler : les salariés utilisent aussi la salle. Après le changement, un salarié branché sur ces prises sera dans le réseau des visiteurs, sans accès à l'intranet. « Je fais l'hypothèse qu'ils se connectent par leur poste habituel ou par une prise hors de la salle. Sinon, il faudrait garder une prise dans le VLAN 10, ou passer à une authentification 802.1X. »
• « Sites web » : je lis HTTP et HTTPS, plus la résolution DNS sans laquelle rien ne fonctionne.
• Les journaux de connexion sont des données personnelles : durée de conservation et information des visiteurs (charte en salle de réunion).
• pfSense relaie déjà le DHCP et ne peut pas être en même temps serveur DHCP : l'étendue des visiteurs va sur les serveurs Windows.

Spécifications techniques.

Outils. Ceux de l'infrastructure : IOS sur SW-CORE, pfSense, la console DHCP ou PowerShell sur SRV-AD1. Alternative écartée : le serveur DHCP de pfSense, incompatible avec le relais déjà en service.

Démarche.

1. Export de config.xml, sauvegarde de la configuration de SW-CORE, instantané de SRV-AD1 et SRV-AD2.
2. SW-CORE : VLAN 40, ports, switchport trunk allowed vlan add 40, enregistrement.
3. pfSense : VLAN 40 sur igb1, interface INVITES en 10.10.40.254/24.
4. SRV-AD1 : étendue, options, ajout au basculement.
5. pfSense : interface INVITES dans le relais DHCP.
6. pfSense : les quatre règles, dans l'ordre.
7. Tests, puis vérification d'un poste du VLAN 10.
8. Rapport de test.

Retour arrière : chaque étape s'annule seule (retirer le VLAN du trunk, supprimer l'interface, l'étendue ou la règle) ; en dernier recours, réimport de config.xml.

Cahier de recette.

1. « Le besoin est d'offrir un accès aux visiteurs, pas de le supprimer : les clients en ont besoin pendant les réunions. Bloquer les ports supprimerait le risque et le service. »
2. « Les serveurs ne reçoivent pas le trafic des visiteurs. Ils reçoivent les requêtes relayées par le pare-feu en unicast, depuis son interface du VLAN 20 (10.10.20.254), avec le champ d'adresse de relais (giaddr) à 10.10.40.254 : c'est à cette adresse que le serveur répond, et c'est ainsi qu'il choisit l'étendue des invités. Le relais est un flux du pare-feu vers les serveurs, pas des visiteurs vers les serveurs : les règles de l'interface INVITES bloquent toujours tout accès direct. Et c'est le seul choix possible, puisque pfSense ne peut pas être à la fois relais et serveur DHCP. »
3. « Son port est dans le VLAN 40 au niveau 2 : ses trames n'arrivent jamais dans le VLAN 10. Son trafic arrive sur l'interface INVITES du pare-feu avec une adresse source qui n'appartient pas au réseau des invités : aucune règle de passage ne correspond, puisqu'elles portent toutes sur la source « INVITES net ». Le trafic est bloqué. »
4. « C'est une limite de la spécification : “sites web”. La messagerie moderne passe par HTTPS dans un navigateur, mais un client de messagerie ou un VPN IPsec utilisent d'autres ports. Je propose de commencer par le web, comme demandé, et de soumettre au responsable l'ouverture de ports supplémentaires, par exemple UDP 500 et 4500 pour un VPN IPsec. »
5. « Je coche l'option de journalisation sur les règles de blocage 2 et 3. Pendant la recette, j'ouvrirai Status > System Logs > Firewall avec un filtre sur l'interface INVITES, juste après les tests T3, T4 et T5. » L'ajustement est noté sur le document : reprends-le dans ton rapport de test.

Le déroulé de Sarah, d'après son journal.

Le rapport de test.

Conclusion. Les quatre exigences sont satisfaites. Ajustement demandé (journalisation des blocages) réalisé. Reste à faire, hors demande : un limiteur de débit pour le réseau des visiteurs, et l'affichage d'une charte en salle de réunion.

Le déroulé de la recette. Rappel du besoin et de l'ajustement (30 secondes). Sur le poste de test : T1, T2, puis T3 à T5, chacun suivi du journal du pare-feu filtré sur INVITES. Sur SW-CORE : show vlan brief et show interfaces trunk. Sur pfSense : l'interface, les quatre règles dans l'ordre, le relais. Sur SRV-AD1 : l'étendue, le bail du poste de test, l'étendue dans la relation de basculement. Puis le rapport de test à l'écran, et le reste à faire.

1. Rejoue T3 en direct, puis montre la ligne du journal : source 10.10.40.50, destination 10.10.20.20, port 445, règle « Bloquer invités vers réseaux privés ». Une démonstration vaut toutes les explications.
2. « Il obtient une adresse du réseau des visiteurs : Internet fonctionne, mais ni l'intranet ni les partages. C'est l'hypothèse que j'ai signalée en phase 1. Deux solutions : garder une prise de la salle dans le VLAN 10, simple mais sans contrôle de qui s'y branche ; ou l'authentification 802.1X sur les ports, avec un serveur RADIUS (NPS sur Windows Server) qui place les postes du domaine dans le VLAN 10 et les autres dans le VLAN 40. La seconde est la bonne solution à terme. »
3. « Le Discover du poste en diffusion, de 0.0.0.0 vers 255.255.255.255, UDP 68 vers 67, puis l'Offer, le Request et l'Ack. Sur l'interface du VLAN 20, on verrait les mêmes messages en unicast entre 10.10.20.254 et les serveurs, le champ giaddr valant 10.10.40.254. »
4. « Oui. L'étendue est dans la relation de basculement : SRV-AD2 continue à distribuer des baux. Je peux le montrer en arrêtant le service DHCP de SRV-AD1 et en renouvelant le bail du poste de test. »
5. « Une borne Wi-Fi reliée à un port en mode trunk ou en accès VLAN 40, avec un réseau sans fil dédié aux visiteurs et l'isolement des clients activé, pour que deux visiteurs ne se voient pas entre eux. Le pare-feu applique les mêmes règles, puisque le trafic arrive par la même interface INVITES. Pour savoir qui se connecte, un portail captif sur pfSense, avec acceptation de la charte. »