GAURA — SISR, session 2025

Mission A1 — Tests d’intrusion (SCAPY sur le VLAN 90)

a) Service visé : le service DHCP.

b) Fonctionnement : l’attaquant inonde le serveur DHCP de fausses requêtes (DHCPDISCOVER/REQUEST avec des adresses MAC falsifiées générées par SCAPY) pour épuiser son pool d’adresses (DHCP starvation).

c) Objectif et type : c’est une attaque par déni de service — le serveur n’a plus d’adresse à distribuer, les clients légitimes ne peuvent plus obtenir de configuration. Elle prépare souvent une attaque de l’homme du milieu.

d) Deux contre-mesures : activer le DHCP snooping (seuls les ports de confiance peuvent répondre/relayer le DHCP) et la sécurité des ports (port security) pour limiter le nombre d’adresses MAC par port.

a) Étapes : une fois le pool du serveur légitime épuisé, l’attaquant met en place un serveur DHCP pirate (rogue DHCP) qui répond aux clients demandant une nouvelle configuration et s’attribue comme passerelle par défaut.

b) Finalité : réaliser une attaque de l’homme du milieu (MITM) — tout le trafic des clients transite par la machine attaquante, qui peut l’intercepter, l’analyser ou le rediriger.

c) Contre-mesure : le DHCP snooping bloque les réponses DHCP provenant de ports non autorisés → le serveur pirate est neutralisé.

Mission A2 — Sécurisation de la DMZ (reverse proxy WAF)

a) Le protocole HTTP circule en clair : pas de confidentialité (écoute possible), pas d’intégrité (modification en transit), pas d’authentification du serveur → exposition au MITM et à l’usurpation.

b) Conséquences pour la collectivité : fuite de données des citoyens (sanctions CNIL/RGPD), atteinte à l’image et à la confiance, et responsabilité juridique de la collectivité (obligations RGS/RGPD).

Si la même clé privée est partagée, la compromission d’un seul serveur (vol de la clé) compromet l’ensemble des serveurs et impose une révocation globale du certificat. Il n’y a aucun cloisonnement : un maillon faible met en danger toute la grappe.

Utiliser des clés et certificats distincts sur le reverse proxy et les serveurs web applique la défense en profondeur / le cloisonnement : le proxy termine le TLS externe (certificat public), puis re-chiffre vers le backend avec un certificat interne. La compromission d’un certificat n’expose pas les autres.

Chiffrer jusqu’aux serveurs web (et pas seulement jusqu’au reverse proxy) protège les données même sur le segment interne (DMZ intermédiaire) : on évite qu’un trafic en clair circule entre le proxy et le backend, où il pourrait être écouté par un attaquant ayant pénétré la DMZ. Confidentialité et intégrité sont assurées sur tout le chemin.

a) Configuration du reverse proxy NGINX ModSecurity WAF vers le backend : on active le WAF puis on relaie en HTTPS vers les serveurs web.

server {
    listen 443 ssl;
    ssl_certificate     /etc/nginx/certs/public.crt;   # certificat public
    ssl_certificate_key /etc/nginx/certs/public.key;
    modsecurity on;                                     # WAF activé
    modsecurity_rules_file /etc/nginx/modsec/main.conf; # règles OWASP CRS
    location / {
        proxy_pass https://backend_web;                 # re-chiffrement vers le backend
        proxy_ssl_verify on;
    }
}

b) Sur les serveurs Apache (backend) : n’écouter qu’en HTTPS, présenter le certificat interne, et n’accepter que les connexions du reverse proxy (filtrage par IP) — l’accès direct depuis Internet est supprimé.

a) Points uniques de défaillance (SPOF) : le reverse proxy unique, le pare-feu interne, ou un serveur web isolé — leur panne coupe l’accès.

b) Haute disponibilité : redonder le reverse proxy (deux instances derrière un répartiteur de charge / VRRP), mettre le pare-feu en cluster, et conserver la grappe de serveurs web en répartition de charge.

Mission B1 — 802.1X sur le réseau filaire

• Client (supplicant) : activer 802.1X sur la carte réseau filaire de l’ordinateur portable, avec la méthode d’authentification retenue (certificat ou identifiant/mot de passe).
• Serveur RADIUS : déclarer le commutateur comme client NAS, et définir la politique : en cas d’authentification réussie → affecter le port au VLAN TEL-PERSO ; sinon → refuser toute communication.
• Commutateur (authenticator) : activer 802.1X sur les ports des bureaux concernés (le poste fixe CCPG reste, lui, sur le VLAN TEL).

Autoriser le flux d’authentification RADIUS entre le commutateur (authenticator) et le serveur RADIUS : UDP port 1812 (authentification) — et UDP 1813 pour la comptabilité (accounting).

1. L’équipement personnel doit disposer d’un système et d’un antivirus à jour (mises à jour de sécurité régulières) avant tout accès au réseau.
2. Interdiction de stocker des données professionnelles en local sur le matériel personnel et obligation de respecter la confidentialité (et d’accepter d’éventuels contrôles).

Mission B2 — Risques restants et solution Cisco ISE

Mesure préconisée	Technologie utilisée	Risque couvert
Cloisonner les appareils personnels	VLAN dédié (TEL-PERSO)	propagation / accès au réseau interne
Chiffrer les flux d’informations	TLS / VPN (IPsec)	écoute, atteinte à la confidentialité/intégrité
Contrôle d’accès robuste de l’utilisateur	802.1X + RADIUS	accès non autorisé au réseau

Cisco ISE est une solution de contrôle d’accès réseau (NAC) centralisée : elle assure le profilage des équipements, le contrôle de posture (elle vérifie que l’appareil personnel a un antivirus/des mises à jour avant d’autoriser l’accès), et applique des politiques d’accès dynamiques par profil, en s’appuyant sur 802.1X/RADIUS. Elle répond précisément au besoin d’intégrer des équipements personnels non maîtrisés tout en maîtrisant les risques.