Myon — SISR, session 2022

Mission A1 — Étude du réseau de vidéosurveillance

Les équipements à représenter et leurs VLAN (document 4) :

Équipement	VLAN	Réseau
12 caméras IP Lesquin	70 (VIDEO)	192.168.70.0/24
4 caméras IP Mâcon	71 (VIDEO-MAC)	192.168.71.0/24
Enregistreur NVR4432	70 (port 5 de SW2)	192.168.70.0/24
Commutateurs XG-7100 (SW1 / SW21)	routage inter-VLAN + pare-feu	—
Tunnel VPN IPsec Lesquin ⇄ Mâcon	porte le VLAN 71 vers le NVR	—

Flux : caméras Lesquin (VLAN 70) → SW1-2/SW1-3 → NVR (même VLAN 70) ; caméras Mâcon (VLAN 71) → SW21 → VPN IPsec → SW1 → NVR.

• Depuis Internet : caméras sur VLAN dédiés (70/71) non routés vers le WAN ; aucune règle NAT/port forwarding ne les expose (doc A2 ne redirige que la DMZ 192.168.51.1) et le pare-feu XG-7100 bloque par défaut (règle 9999 deny). Les caméras de Mâcon passent par le tunnel VPN IPsec chiffré, inaccessible de l’extérieur.
• Utilisateur local malveillant : la segmentation VLAN isole le réseau vidéo des réseaux utilisateurs ; un poste d’un autre VLAN n’atteint le VLAN 70 que si le pare-feu inter-VLAN l’autorise — ce qui n’est pas le cas.

Mission A2 — Migration et sécurisation d’une application métier

L’application est joignable de l’extérieur via le port 5433 → 5000 redirigé vers la DMZ 192.168.51.1 (doc A2/A3). Il faut rediriger le flux interne (port 5000) de Lxd1 vers Lxd2 : modifier l’adresse NAT de destination interne de la règle de port forwarding (et/ou la réservation DHCP) pour pointer sur Lxd2. Les règles de filtrage WAN (NAT 5433→5000, allow 5000 vers la DMZ) restent inchangées car elles visent l’adresse de passerelle DMZ, pas l’IP propre du serveur.

L’attaque vient des IP 193.14.78.1 et 5.49.250.12 sur le port 443. On ajoute deux règles de blocage explicite :

Numéro	Protocole	IP source	Port src	IP dest	Port dest	Règle
5	tcp	193.14.78.1	*	192.168.51.1	443	deny
6	tcp	5.49.250.12	*	192.168.51.1	443	deny

Emplacement : en tête de table, AVANT la règle 20 (allow 443). Un pare-feu applique la première règle correspondante ; placées après le allow, elles seraient inopérantes. D’où des numéros inférieurs (5 et 6) à la règle 20.

fail2ban. Il surveille les journaux (serveur web/pare-feu), détecte les échecs d’authentification répétés depuis une même IP et bannit dynamiquement l’adresse (règle de pare-feu temporaire). Avantages : automatisation (plus besoin d’ajouter chaque IP à la main, ce que le pirate contourne en changeant d’adresse), seuils et durées configurables, réaction en quasi temps réel — il traite la variabilité des IP sources que le filtrage statique ne couvre pas.

Rubrique	Repère(s)	Justification
Élément	[ i1 ] Serveur	l’attaque vise un serveur web (Lxd1)
Nature	[ n20 ] Tentative de cyberattaque + [ n11 ] Accès non autorisé	brute force / authentification frauduleuse
Données compromises ?	[ c2 ] Non	l’attaque a échoué
RH contacté ?	[ r2 ] Non	pas de harcèlement
Mesures d’urgence	[ u7 ] Autre : « Blocage des IP sources sur le pare-feu + fail2ban »	mesure appliquée

([ i11 ] et [ n24 ] non requis ici ; [ u7 ] reçoit la phrase de description.)

a) En mode promiscuité, l’interface accepte et remonte au système toutes les trames du segment, y compris celles non destinées à sa propre adresse MAC (au lieu de les filtrer). Indispensable à une sonde IDS pour analyser tout le trafic.

b) Un commutateur n’envoie à chaque port que le trafic qui le concerne. Pour que la sonde Snort (port 23, Debian Snort) voie tout le trafic DMZ, configurer une recopie de ports (SPAN / port mirroring) sur SW2 : recopier les ports DMZ (Lxd1 = port 21, Lxd2 = port 22, uplink SW1) vers le port 23.

Le ping utilise ICMP. Les serveurs Lxd1/Lxd2 sont en DMZ (192.168.51.0/24). Premières règles personnelles → sid ≥ 1000001 (doc A6). Une règle par serveur (ou une seule sur le réseau DMZ) :

alert icmp any any -> 192.168.51.21 any (msg:"Ping vers serveur web Lxd1"; sid:1000001; rev:1;)
alert icmp any any -> 192.168.51.22 any (msg:"Ping vers serveur web Lxd2"; sid:1000002; rev:1;)

(Variante condensée : alert icmp any any -> 192.168.51.0/24 any (msg:"Ping vers serveurs web DMZ"; sid:1000001; rev:1;).)

Mission A3 — Sécurisation du réseau sans-fil (Wifi)

• Authentification individuelle (WPA2-Enterprise/802.1X) : chaque mécanicien s’authentifie avec son compte AD au lieu d’une passphrase partagée (WPA-PSK) connue de tous et non révocable individuellement.
• Centralisation et traçabilité : comptes gérés dans l’annuaire ; on sait qui se connecte ; révocation immédiate au départ d’un salarié sans changer la clé pour tous (NPS réutilise l’identité existante).

1. WPA2-Enterprise (802.1X) avec chiffrement AES-CCMP (abandon du WPA-PSK).
2. Filtrage des adresses MAC (ACL MAC, doc A7) pour n’autoriser que les tablettes connues.
3. Cloisonnement VLAN 80 : maintenir l’absence d’accès Internet pour le Wifi tablettes.
4. Réduction de la puissance d’émission (limiter le débordement hors des locaux) et surveillance des points d’accès non autorisés (rogue AP).

Toute entreprise qui procure un accès (journaux de connexion Wifi) est assimilée à un fournisseur d’accès — LCEN art. 6-II, décret du 24 mars 2006 et loi antiterroriste du 23 janvier 2006 (doc A8) : obligation de conserver les données techniques de connexion 1 an (date/heure, adresse MAC, mode), puis anonymisation. Ces données ne révèlent pas le contenu des communications et leur traitement respecte le RGPD.

• Réglementation : collecter nom, société, adresse électronique = traitement de données personnelles (RGPD) → information du visiteur, finalité, durée limitée, base légale. L’obligation de conservation des logs (1 an) subsiste : journaliser l’attribution bon ↔ visiteur pour identifier l’auteur d’un usage litigieux.
• Sécurité : Wifi visiteurs isolé (VLAN distinct, pas d’accès au réseau interne ni aux serveurs), accès temporaire (bon à durée de vie limitée, usage unique). Le portail captif ne doit pas exposer les autres VLAN.

Mission B1 — Amélioration de la sûreté du serveur de stockage

a) Le RAID 0 ne fait qu’entrelacer les données sur les 12 disques (performance) : aucune redondance. La défaillance d’un seul disque entraîne la perte totale des données → pas de sûreté.

b) Volume utile (12 × 2 To = 24 To bruts) :

Niveau	Tolérance de panne	Volume utile	Adapté ?
RAID 5	1 disque	(12−1)×2 = 22 To	oui
RAID 6	2 disques	(12−2)×2 = 20 To	recommandé
RAID 10	1 par miroir	24/2 = 12 To	non (inférieur à 18 To)

→ RAID 6 : meilleure sûreté (tolère 2 pannes simultanées, risque réel de double panne pendant la reconstruction avec 12 disques) et 20 To utiles ≥ 18 To requis. Le RAID 10 (12 To) est insuffisant.

Le RAID 5 n’est pas une sauvegarde : il protège de la panne d’un disque, mais pas d’une suppression/altération de fichiers (erreur, malveillance, rançongiciel), d’une corruption logique, d’un sinistre (incendie, vol) ni d’une double panne. La sauvegarde vers le NAS offre une copie indépendante et historisée, restaurable en cas de perte logique ou de désastre.

• Juridique : données sous droit français/UE → RGPD applicable, hors d’atteinte de législations extraterritoriales (Cloud Act) ; souveraineté et exigences sectorielles.
• Technique : faible latence avec Lesquin (meilleur débit de sauvegarde), support/SLA en français, conformité possible (SecNumCloud / HDS).

SFTP (ou SCP), encapsulés dans SSH : transfert chiffré (confidentialité + intégrité) avec authentification par clés, contrairement à FTP/HTTP (en clair). SFTP est préférable à FTPS (un seul port, traversée de pare-feu simple) pour des sauvegardes automatisées.

Mission B2 — Mise en place de délégation de droits (sudo)

sudo autorise un utilisateur à exécuter uniquement certaines commandes précises avec les droits de root, sans donner le mot de passe root ni un accès complet. Chaque informaticien se connecte avec son compte et n’obtient les privilèges que pour les commandes nécessaires (alias NET : ifup/ifdown, édition de interfaces/resolv.conf). On accorde le minimum requis, avec traçabilité (qui a lancé quoi, quand) et NOEXEC qui bloque l’évasion par shell.

a) Risque : dans sudo antérieur à 1.9, un utilisateur autorisé à exécuter une commande en tant qu’un autre utilisateur que root pouvait contourner la restriction via sudo -u#-1 commande. L’UID -1 n’existe pas mais est interprété comme 0 = root → exécution avec les privilèges root = élévation de privilèges non prévue.

b) Machines concernées : tous les serveurs Linux en sudo ≤ 1.8.x où une délégation autorise l’exécution en tant qu’un utilisateur ciblé (SRV1, Debian10, Debian Snort, Lxd1, Lxd2, LxdTest). Les machines Windows ne sont pas concernées (pas de sudo).

• Ligne 3 — stocke dans empreinteAttendue l’empreinte de référence du .deb publiée par l’éditeur (valeur de confiance).
• Ligne 4 — calcule l’empreinte réelle du fichier téléchargé (sha1sum).
• Ligne 5 — compare les deux ; si identiques, le fichier est authentique et intègre (non corrompu/altéré) et seulement alors il est installé (dpkg -i).

Ces lignes vérifient l’intégrité et l’authenticité du paquet avant installation.

Remarque : la ligne 3 fournit un hash de 64 caractères (SHA-256) alors que la ligne 4 utilise sha1sum (SHA-1, 40 car.) — incohérence d’algorithme ; et la comparaison devrait utiliser = (chaînes) plutôt que -eq (numérique). Le principe reste valide.

Mission B3 — Sécurisation de la messagerie

a) TLS chiffre le canal client (Outlook) ⇄ serveur : confidentialité (un attaquant réseau ne lit ni le trafic ni le mot de passe), intégrité des échanges et authentification du serveur (certificat). Il protège la transmission des courriels et des identifiants.

b) Non. TLS ne sécurise que le transport. En cas de vol de l’identifiant/mot de passe, l’attaquant se connecte à la boîte et lit tous les courriels stockés en clair sur le serveur. TLS ne protège pas le contenu au repos ni contre un accès authentifié frauduleux : il faut un chiffrement de bout en bout.

Chiffrement de bout en bout (clé publique du destinataire, clé privée sur badge BIP — doc B6), par rapport à TLS seul :

• Confidentialité de bout en bout : seul le destinataire (clé privée sur carte à puce) lit le message ; il reste chiffré au repos sur les serveurs, illisible même en cas de vol des identifiants ou de compromission du serveur.
• Authenticité / non-répudiation : associé à une signature (clé privée de l’expéditeur), il prouve l’origine et l’intégrité du message.
• Maîtrise de l’accès : la clé privée étant sur le badge personnel, sans la carte le courriel ne peut pas être lu.