SA Blanca — SISR, session 2025

Mission A1 — Analyse et interventions immédiates

Le micrologiciel stocke la table d’adresses MAC (table CAM) dans une RAM de taille limitée. Les LED orange clignotant des ports, combinées à la lenteur générale, indiquent que cette table est saturée : le commutateur ne peut plus apprendre/associer correctement les adresses MAC. Ne sachant plus sur quel port envoyer une trame, il bascule en mode « fail-open » et inonde chaque trame sur tous les ports (comportement de concentrateur/hub). D’où la lenteur extrême.

a) Sur la capture du poste 192.168.10.86, les trames destinées à d’autres adresses IP/MAC que les siennes ne devraient pas apparaître. En commutation normale, un poste ne reçoit que ses trames unicast + les broadcasts. Leur présence prouve que le commutateur inonde tout le trafic (table MAC saturée).

b) La table d’adresses MAC est saturée d’entrées illégitimes : un même port a appris un nombre anormalement élevé d’adresses MAC (des milliers de MAC sources falsifiées). Le commutateur, à court de mémoire, ne commute plus → il diffuse.

c) Les autres commutateurs reçoivent eux aussi ce flot de trames diffusées, ce qui propage la saturation et le ralentissement à tout le VLAN 10 (effet boule de neige sur le cœur et la distribution).

a) Risque RGPD : le serveur NAS 192.168.10.243 héberge des données personnelles (clients et utilisateurs). En mode inondation, les trames vers/depuis le NAS sont diffusées à tous les postes → un attaquant (ou un poste quelconque) peut les capturer : c’est une atteinte à la confidentialité des données personnelles (manquement à l’obligation de sécurité de l’article 32 du RGPD).

b) Évolution d’architecture : isoler les serveurs dans un VLAN dédié (VLAN serveurs), séparé du VLAN 10 des postes, avec filtrage inter-VLAN sur le cœur (C1/C2) ou le pare-feu interne. Ainsi une saturation côté postes n’expose plus le trafic serveur, et l’accès au NAS est contrôlé.

La priorité P2 n’est plus d’actualité : l’activité de toute l’organisation est désormais bloquée (impact maximal, urgence maximale). Il faut la réévaluer en P1 (priorité critique).

Redémarrer (ou isoler physiquement) le commutateur en défaut : cela vide la table MAC saturée et rétablit, au moins temporairement, une commutation normale. Le point de blocage levé : l’interface de gestion étant inaccessible, on agit physiquement (interrupteur d’arrêt d’urgence de l’armoire) plutôt que par configuration.

Mission A2 — Recherche des causes

C’est le MAC flooding (inondation de la table MAC). Les symptômes — saturation de la table CAM, basculement en mode concentrateur, lenteur généralisée — sont la signature du MAC flooding. L’ARP spoofing viserait des hôtes précis (empoisonnement du cache ARP) sans saturer la table MAC ni ralentir tout le réseau.

En analysant les statistiques du nombre d’adresses MAC par port, on repère le port qui présente un nombre d’adresses MAC anormalement élevé : c’est là qu’est branché l’appareil qui génère les milliers de MAC falsifiées.

Le MAC flooding est une attaque par déni de service (saturation → blocage) doublée d’une finalité d’interception/écoute : en forçant le commutateur à inonder, l’attaquant peut capturer (sniffer) le trafic normalement non destiné à son port.

Mission A3 — Remédiation

a) La sécurité des ports (port security) répond partiellement : elle limite le nombre d’adresses MAC autorisées par port → elle empêche le flooding. Mais elle ne couvre pas à elle seule le besoin de détection/traçabilité et d’alerte exprimé (savoir quand et où l’incident se reproduit).

b) La réaction la plus adaptée à une violation est le shutdown (désactivation du port fautif) : il isole et neutralise immédiatement l’équipement attaquant (ce que demande la responsable), tout en remontant l’événement. (Le mode restrict tracerait sans couper, mais le sujet exige d’isoler.)

a) Un trap SNMP est plus pertinent qu’une supervision active (interrogation périodique) car il est émis immédiatement par le commutateur au moment de la violation : l’alerte est en temps réel, sans attendre le prochain cycle d’interrogation (qui retarderait la détection).

b) SNMPv3 sécurise la supervision via le mode authPriv :

• authentification de l’utilisateur (identifiant + condensat du mot de passe, ex. SHA) → garantit l’origine ;
• chiffrement des messages (ex. AES) → garantit la confidentialité.

Contrairement à SNMP v1/v2c (community string en clair), v3 protège donc à la fois l’authentification, l’intégrité et la confidentialité des échanges.

Pour vérifier que le commutateur résiste désormais au MAC flooding, on rejoue l’attaque de façon contrôlée avec macof (générateur d’inondation d’adresses MAC) : si la sécurité des ports est active, le port passe en violation/shutdown au lieu d’inonder.

Mission B1 — Justification de la solution

Le Wi-Fi interne repose sur un SSID + mot de passe partagé : toute personne connaissant ce mot de passe accède au réseau interne (et pas seulement à Internet). Critères de sécurité non respectés :

• Confidentialité : un visiteur/apprenant ponctuel atteint les ressources internes (serveurs, NAS) ;
• Intégrité : possibilité de modifier/altérer des données depuis ce point d’accès ;
• Disponibilité : un appareil hostile connecté peut perturber le réseau (ex. l’attaque MAC flooding précédente).

1. Il isole les apprenants ponctuels du réseau interne : ils n’obtiennent qu’un accès Internet, pas un accès aux ressources de l’entreprise.
2. Il assure traçabilité et responsabilisation : inscription + acceptation des CGU → chaque accès est identifié.

Brancher le Wi-Fi invité directement sur le pare-feu interne (et non sur le cœur de réseau) permet de filtrer tout son trafic et de l’isoler : il ne peut pas atteindre les VLAN internes, seul le passage explicitement autorisé (Internet) est permis.

Mission B2 — Mise en œuvre du portail captif

Donnée demandée	Pertinente ?	Traitement justifié
Téléphone professionnel	Oui	B (contact commercial)
Téléphone personnel	Non (minimisation)	aucun
Poste / service / type d’emploi	Oui	C (statistiques de formation)
Formation suivie	Oui	C (corrélation avec les formations)

Principe RGPD : minimisation — ne collecter que ce qui est nécessaire au traitement (le téléphone personnel n’est justifié par aucun des traitements A/B/C).

Sur l’interface Wi-Fi invité du pare-feu interne, rediriger le trafic HTTP (80) et HTTPS (443) des utilisateurs non authentifiés vers la page d’authentification du portail captif :

# Source : réseau Wi-Fi invité | utilisateur NON authentifié
Redirection  src=WiFi_Invité  dport=80,443  ->  Portail_captif (page d'auth)

Politique « tout interdit par défaut », puis on autorise selon l’authentification :

# 1. Utilisateur AUTHENTIFIÉ : accès Internet web autorisé
Autoriser  src=WiFi_Invité(authentifié)  dst=Internet  proto=HTTP,HTTPS
# 2. Utilisateur NON authentifié : seule la redirection portail est permise
Autoriser  src=WiFi_Invité(non-auth)     dst=Portail_captif
# 3. Tout le reste (vers les VLAN internes notamment) : interdit
Interdire  src=WiFi_Invité  dst=any