Saint-Jacques — SISR, session Novembre 2023

Mission A1 — Vérification des accès au réseau

Le public accède aux applications qui lui sont réservées par deux voies (doc. 3 et 6) :

• À distance, via le portail internet de la mairie (saintjacques.fr), depuis n’importe quel terminal : consultation des menus de cantine, inscriptions/paiements du périscolaire, demandes de subventions, annuaire public, etc.
• Sur place, via les postes mis à disposition du public dans les locaux (médiathèque : 4 postes, CCAS : 2, EHPAD : 2…), connectés au VLAN public, et via les points d’accès Wi-Fi ouverts WF-SPEC et WF-MEDIAT.

1. Vol ou usurpation d’identifiants (mot de passe faible, hameçonnage, post-it) permettant d’ouvrir une session légitime.
2. Accès physique à un poste laissé déverrouillé/sans session fermée, ou branchement sur une prise réseau accessible (accueil, salle ouverte au public).
3. Rebond depuis le réseau public vers le VLAN mairie en cas de cloisonnement défaillant (cf. A1.3), ou via un point d’accès Wi-Fi ouvert mal isolé.

L’affectation au VLAN repose sur l’adresse MAC de la carte réseau. Or une adresse MAC :

• n’est pas un secret : elle circule en clair sur le réseau et peut être lue (sniffing) ;
• est facilement falsifiable (MAC spoofing) : n’importe quel système permet de la réécrire en quelques secondes.

Un attaquant copie la MAC d’un poste autorisé et bascule ainsi dans le VLAN mairie — c’est exactement ce qui s’est produit avec le poste « Hacké par K » de la médiathèque, qui a pu imprimer via le VLAN interne. Le critère d’appartenance n’authentifie ni le poste ni l’utilisateur.

Mettre en place le contrôle d’accès au port basé sur l’authentification 802.1X (les commutateurs sont déjà de niveau 3, donc compatibles). Le poste (ou l’utilisateur) doit s’authentifier auprès du switch via EAP / serveur RADIUS avant d’obtenir un accès ; l’affectation du VLAN devient dynamique selon l’identité validée, et non selon une MAC falsifiable. À défaut de RADIUS, on peut renforcer par port-security (verrouillage d’une MAC apprise par port + désactivation du port en cas d’anomalie), mais 802.1X reste la réponse robuste sans ajout d’équipement.

Mission A2 — Vérification de l’infrastructure de crise

Non. La réplication recopie fidèlement l’état d’origine, y compris les altérations : suppression, corruption, chiffrement par rançongiciel ou erreur humaine sont répliqués immédiatement sur le site de secours. Elle assure la disponibilité (bascule en cas de panne matérielle d’un site), pas l’intégrité historique. Seule une sauvegarde versionnée et conservée dans le temps permet de revenir à un état antérieur sain.

Critère	Postes médiathèque reconfigurés	Postes dédiés (salle technique secours)
Disponibilité / rapidité	Reconfiguration manuelle (changement de VLAN), délai en pleine crise	Immédiatement prêts, préconfigurés et durcis
Sécurité	Postes publics exposés (Wi-Fi ouvert, malware, MAC spoofing — cf. A1) → risque élevé	Isolés du public, durcis, à jour → risque maîtrisé
Coût	Faible (mutualisation du parc existant)	Plus élevé (postes immobilisés, maintenance)

Conclusion : les postes dédiés sont à privilégier pour des services critiques ; la solution médiathèque n’est qu’un palliatif économique mais peu sûr.

1. Périmètre incomplet : le NAS-VIDEO (vidéosurveillance) n’est pas répliqué alors que ces fichiers sont importants en cas d’enquête judiciaire → perte définitive en cas de sinistre du site principal. Les fichiers des écoles ne sont répliqués que tous les semestres → perte de plusieurs mois de données.
2. Fréquences incohérentes : les VM ne sont répliquées qu’une fois par semaine (dimanche) alors que le SAN-1 est répliqué en temps réel → on peut basculer sur des VM datant d’une semaine pointant vers des données du jour : incohérence applicative, voire indisponibilité au redémarrage des services critiques (états civils, mandats, paie).

Non. Le doc. A1 indique qu’une seule sauvegarde complète (la dernière) reste disponible sur SAN-2. Or l’attaque décrite n’a été découverte que 3 jours après la modification frauduleuse : si la sauvegarde saine avait été écrasée entre-temps, la restauration aurait été impossible. Il faut conserver plusieurs générations (rétention) : par exemple une stratégie GFS (quotidiennes sur 7–14 jours, hebdomadaires sur 4–5 semaines, mensuelles sur 12 mois), couvrant largement un délai de détection de plusieurs jours.

La mairie est responsable de traitement au sens du RGPD :

• Conservation limitée : les données ne sont gardées que le temps de leur utilité, avec des durées inscrites au registre des traitements tenu par le DPO (base active → archivage intermédiaire → suppression).
• Sécurité appropriée : mesures techniques et organisationnelles protégeant contre destruction, perte, altération, accès non autorisé, proportionnées à la nature des données (la police municipale ≠ une newsletter).
• Droit d’accès : communiquer l’intégralité des données d’une personne, qu’elles soient actives ou archivées.
• Traçabilité : toute consultation des archives doit être tracée.

Mettre en œuvre une sauvegarde externalisée hors site respectant la règle 3-2-1 (3 copies, 2 supports, 1 hors site). Concrètement : une copie déconnectée/immuable (bandes LTO sorties de l’armoire et déportées, ou stockage objet immuable WORM chez un hébergeur souverain conforme RGPD). Étant déconnectée du réseau, elle reste hors d’atteinte d’une attaque chiffrant simultanément SAN-1 et SAN-2.

Préconiser un second lien de secours, physiquement distinct du premier. La mairie maîtrise déjà la radiofréquence (doc. 5 : liens 64 Mb/s EHPAD, 32 Mb/s centre aéré) : un lien hertzien point-à-point entre les deux sites offre un chemin alternatif ne passant pas par la borne technique vulnérable, et une liaison ADSL/SDSL d’un FAI distinct fournit un accès internet de secours au site de secours. On obtient à la fois la redondance inter-site et la connectivité internet.

Mission A3 — Disponibilité des liaisons externes

a) Objectif : rendre un service indisponible en le saturant. Principe : un attaquant pilote un botnet (machines compromises réparties) qui envoie simultanément un volume massif de requêtes/paquets (SYN flood, UDP flood, requêtes HTTP…) jusqu’à épuiser la bande passante ou les ressources (CPU, table de connexions) de la cible.

b) Un pare-feu ne suffit pas : il peut filtrer et limiter certains flux, mais il est lui-même dimensionné en débit/sessions et placé en coupure — une attaque volumétrique sature son lien amont (la liaison FAI) avant ses règles, ou épuise sa table d’états. La protection efficace se situe en amont : anti-DDoS de l’opérateur/FAI, scrubbing, CDN/répartition, limitation de débit. Le pare-feu est une brique complémentaire, pas une contre-mesure pleinement suffisante.

1. Préparation : tester hors production (maquette/fenêtre de maintenance), définir le critère de succès (bascule actif/passif sans coupure perceptible) et prévenir les parties prenantes.
2. Test de bascule (failover) : simuler la panne du pare-feu actif (arrêt/débranchement) et vérifier que le passif prend le relais automatiquement, sessions maintenues.
3. Simulation DDoS contrôlée : générer un trafic d’attaque maîtrisé (hping3, ou un outil de stress en labo isolé) vers une IP de test et observer la tenue de la grappe (supervision, logs Stormshield).
4. Mesure & rapport : relever disponibilité, temps de bascule, pertes ; revenir à l’état nominal et documenter les résultats.

Mission B1 — Protection contre les rançongiciels

Tout équipement exécutant du code et accédant à des fichiers : postes de travail des agents et postes publics, serveurs de virtualisation (SRV-HYPERV1→4) et leurs VM, serveur de fichiers, NAS (NAS-ECOLES, NAS-VIDEO), SAN-1/SAN-2 via les partages, ainsi que les supports amovibles (clés USB). Tout volume réseau monté/partagé est une cible de propagation.

• Agents de la mairie : indisponibilité des applications métier (états civils, mandats, paie) — jusqu’à une semaine lors de la 2ᵉ attaque — et perte de travail en cours.
• Administrés / public : impossibilité d’obtenir des actes, de payer le périscolaire, d’accéder aux services en ligne ; fuite possible de leurs données personnelles.
• Service informatique / direction : charge de remédiation (isolement, restauration), atteinte à l’image de la collectivité, risque juridique et financier.

1. Désactiver l’autorun/autoplay et bloquer/contrôler les ports USB par stratégie (GPO, blocage des périphériques de stockage non approuvés).
2. Antivirus/EDR à jour avec analyse automatique de tout support amovible avant ouverture.
3. Sensibilisation : interdire l’usage de clés d’origine externe, fournir des sas de décontamination (station blanche analysant le média avant transfert).

1. Filtrage de la messagerie (anti-spam/anti-phishing, réécriture et analyse des URL, sandboxing des pièces jointes).
2. Filtrage web / proxy bloquant les domaines malveillants (cf. B1.6) et EDR détectant les outils d’attaque (CobaltStrike, Mimikatz…).
3. Segmentation réseau + moindre privilège pour limiter le déplacement latéral une fois le poste compromis.

a) Processus :

• En cas de violation, le responsable de traitement notifie la CNIL dans les 72 heures après en avoir pris connaissance (sauf risque improbable pour les droits et libertés).
• Si la violation engendre un risque élevé, il doit en outre informer sans délai les personnes concernées (les administrés).
• La violation est consignée dans un registre interne des violations.

b) Objectif pour chaque partie prenante :

• CNIL : permettre le contrôle et, le cas échéant, l’accompagnement/sanction ; vérifier l’adéquation des mesures.
• Personnes concernées : leur permettre de se protéger (changer leurs mots de passe, surveiller un usage frauduleux de leurs données).
• Mairie : démontrer sa conformité et limiter sa responsabilité.

Déployer un proxy / serveur mandataire de filtrage web avec liste blanche/liste noire de catégories d’URL. Principe : toutes les requêtes HTTP/HTTPS des postes transitent par le proxy, qui compare l’URL/domaine demandé à une base de réputation et autorise ou bloque selon la politique (catégorie, réputation). On peut compléter par un filtrage DNS (résolution bloquée des domaines malveillants) — concrètement applicable sur le pare-feu UTM Stormshield (filtrage URL intégré).

Mission B2 — Sécurisation des liaisons inter-sites

Un tunnel VPN IPSec assure, pour les décideurs :

• Confidentialité : les données échangées entre sites sont chiffrées (illisibles si interceptées) ;
• Intégrité : toute altération des paquets en transit est détectée ;
• Authentification : seules les passerelles légitimes (certificats/PSK) établissent le tunnel ;
• Anti-rejeu : un attaquant ne peut rejouer d’anciens paquets capturés.

En phase 2, deux canaux unidirectionnels sont ouverts, chacun avec sa propre clé : ESP-SA1 et ESP-SA2 (IKEv1) / CHILD-SA1 et CHILD-SA2 (IKEv2). Chaque extrémité détient les deux clés : l’une pour chiffrer ce qu’elle envoie, l’autre pour déchiffrer ce qu’elle reçoit.

   PARE-FEU mairie (A)                            PARE-FEU site secours (B)
   ┌──────────────────┐                           ┌──────────────────┐
   │  chiffre avec     │ ── ESP-SA1 (sens A→B) ──▶ │  déchiffre avec   │
   │     ESP-SA1       │                           │     ESP-SA1       │
   │                   │ ◀── ESP-SA2 (sens B→A) ── │  chiffre avec     │
   │  déchiffre avec   │                           │     ESP-SA2       │
   │     ESP-SA2       │                           │                   │
   └──────────────────┘                           └──────────────────┘

• A → B : A chiffre avec ESP-SA1, B déchiffre avec ESP-SA1.
• B → A : B chiffre avec ESP-SA2, A déchiffre avec ESP-SA2.

La même clé sert donc au chiffrement d’un côté et au déchiffrement de l’autre (chiffrement symétrique), mais un sens = une clé dédiée, ce qui isole les deux flux.

a) Objectif d’une PKI : garantir l’authenticité d’une clé publique en délivrant des certificats signés par une autorité de certification (AC) de confiance, et gérer leur cycle de vie (émission, distribution, révocation). La confiance dans l’AC fonde la fiabilité de l’authentification (doc. B2/B3).

b) Pourquoi l’IGC plutôt que la PSK (recommandations ANSSI, doc. B3) :

• Révocation rapide d’une clé compromise (ex. vol d’un poste) sans intervenir sur tous les équipements ;
• Ajout/retrait d’hôtes simplifié (pas de re-déploiement d’un secret partout) ;
• Pas de secret unique partagé dont la fuite compromettrait l’ensemble du parc ;
• la PSK est à réserver aux tests/diagnostics ; une longueur inférieure à 100 bits est jugée risquée. Pour un système en production, l’IGC est la bonne pratique.

Mission B3 — Mise en œuvre du télétravail

Restreindre les utilisateurs Denis Barbier et Bruno Paillard au seul https://collab.saintjacques.fr. Il faut remplacer la règle trop permissive par une règle explicite et restrictive :

• Source : les utilisateurs nomades Denis Barbier et Bruno Paillard (via le tunnel VPN nomade) ;
• Destination : l’objet collab.saintjacques.fr (serveur Nextcloud en DMZ) ;
• Service : HTTPS (TCP 443) uniquement ;
• Action : autoriser.

Puis, conformément au deny par défaut, supprimer/abaisser toute règle plus large autorisant ces utilisateurs vers d’autres destinations, de sorte que tout autre flux soit refusé.

L’authentification VPN repose sur un certificat (clé privée) propre au poste, pas sur un simple secret partagé. En cas de vol du portable, l’administrateur révoque immédiatement le certificat (publication dans la CRL/OCSP) : le pare-feu rejette toute tentative de connexion présentant ce certificat révoqué, sans avoir à reconfigurer les autres équipements ni changer un secret commun. L’accès du poste volé est neutralisé de façon ciblée et immédiate.