Durcir l'infrastructure

Démarche. Pour chaque action, demande-toi ce qu’elle change : la capacité à fonctionner malgré une panne (sûreté), ce qui est exposé (surface), un réglage (configuration), une faille publiée (correction), la trace (journalisation) ou la preuve de conformité (audit).

Familles de référentiels. ISO/IEC 27002:2022 : norme. ANSSI-BP-028 : guide de bonnes pratiques. RFC 5425 : standard technique (transport de syslog sur TLS). CIS Benchmark : guide de bonnes pratiques. WPA3 : standard technique de la Wi-Fi Alliance.

1. t : sockets TCP ; u : sockets UDP ; l : seulement celles qui sont en écoute ; p : affiche le processus ; n : adresses et ports en chiffres (pas de résolution de noms).

2. Trois services écoutent :

3. 0.0.0.0 signifie toutes les adresses IPv4 de la machine : le service répond sur chaque interface, y compris celles qui n’ont pas à le proposer. C’est contraire à la règle de l’ANSSI de réduire la surface des services réseau (R80).

4. Décisions :

5. On lance un balayage de ports depuis une autre machine du réseau, par exemple nmap -n -Pn -sT -sU -p T:1-65535,U:514 10.20.50.20 depuis LAB-LOG01. Précaution : ne balayer que des machines dont on a la charge, dans un périmètre autorisé par écrit (sinon, risque pénal : art. 323-1 C. pén.).

1. sshd -t contrôle la syntaxe : toutes les directives sont valides. Il ne contrôle pas que la configuration respecte le socle : c’est le rôle de sshd -T (configuration effective) comparé à la règle.

2. Le fichier principal inclut d’abord sshd_config.d/*.conf, dans l’ordre alphabétique : 05-installation.conf est lu avant 50-durcissement.conf. Or OpenSSH retient la première valeur lue : PasswordAuthentication yes (du fichier 05) l’emporte sur no (fichier 50), et PermitRootLogin prohibit-password (fichier 05) l’emporte sur PermitRootLogin no écrit plus bas dans le fichier principal. prohibit-password (affiché without-password par sshd -T, ancien nom de la même valeur) autorise root avec une clé.

3. Deux corrections :

   • supprimer (ou vider) 05-installation.conf, déposé par l’outil d’installation ;
   • renommer le fichier de Lucas pour qu’il soit lu en premier (01-durcissement.conf) et y ajouter PermitRootLogin no.

   La première est préférable : deux fichiers contradictoires restent un piège pour le prochain technicien. On peut combiner : supprimer le fichier 05 et nommer le fichier du socle 10-… pour qu’il passe avant ceux que d’autres outils pourraient déposer.

4. Sur la maquette, après suppression du fichier 05 :

maxauthtries 3
permitrootlogin no
passwordauthentication no
x11forwarding no
allowgroups ssh-admins

passwordauthentication no et permitrootlogin no sont bien attendus.

5. Directives à ajouter (trois au choix, parmi celles du socle) : ListenAddress <adresse d'administration> (écoute limitée, NT OpenSSH R25) ; AllowTcpForwarding no (le serveur ne sert pas de tunnel, R27) ; LogLevel VERBOSE (journalise l’empreinte de la clé utilisée : imputabilité) ; LoginGraceTime 30 (connexions en attente coupées vite) ; ClientAliveInterval 300 et ClientAliveCountMax 2 (session muette fermée) ; PermitRootLogin no (si le fichier 05 n’est pas supprimé).

1. Gravité qualitative (score de base). V1 9,3 : critique (9,0 à 10). V2 8,8 : élevée (7,0 à 8,9). V3 8,5 : élevée. V4 2,1 : faible (0,1 à 3,9).

2. Vecteur de V3. AV:L : l’attaquant agit localement, depuis la machine ; AC:L et AT:N : pas de protection particulière à contourner ni de condition sur la cible ; PR:L : il lui faut déjà un compte ordinaire ; UI:N : aucune action d’un utilisateur ; VC:H/VI:H/VA:H : il obtient un impact élevé sur la confidentialité, l’intégrité et la disponibilité de la machine (il devient root) ; SC:N/SI:N/SA:N : pas d’impact direct sur d’autres systèmes.

3. Métrique de menace. E:A : vulnérabilité attaquée (exploitation signalée) ; E:P : preuve de concept publiée ; E:U : aucune exploitation signalée. Le score de V2 baisse de 8,8 à 6,7 parce qu’aucune exploitation n’est connue : la probabilité d’attaque à court terme est plus faible.

4. Dates limites. Politique appliquée au score de base, avec la règle prioritaire de l’exploitation :

5. Exposition et respect.

Taux de respect = délais respectés ÷ vulnérabilités = 2 ÷ 4 × 100 = 50 %.

Interprétation : les deux dépassements portent sur les cas les plus graves (une faille exploitée sur un équipement exposé ; une élévation de privilèges). Il faut une procédure d’urgence (astreinte, contournement immédiat) et un suivi quotidien des correctifs à 7 jours.

6. V2. Non. La politique s’applique au score de base (8,8, élevé) : l’absence d’exploitation connue aujourd’hui peut changer demain, et le serveur porte une application utilisée sur tous les sites. Le score de menace sert à ordonner les corrections dans le délai, pas à les reporter au mois suivant.

1. Un avertissement signale un problème qui demande une action ou une décision rapide ; une suggestion propose une amélioration. L’identifiant (SSH-7408, AUTH-9286…) désigne le test : il permet d’en lire le détail (lynis show details SSH-7408), de suivre l’écart d’un audit à l’autre et de l’exclure par un profil.

2. Classement.

3. Profil personnalisé.

# Écarts acceptés (décision J. Maréchal, 20/10/2026)
skip-test=SSH-7408:port
skip-test=AUTH-9286

Chaque ligne est commentée (qui a décidé, pourquoi) et reprise dans le socle comme exception.

4. Calculs.

• Indice : 80 − 66 = + 14 points ; (80 − 66) ÷ 66 × 100 = + 21,21 %.
• Suggestions : (31 − 45) ÷ 45 × 100 = − 31,11 %.

5. Réponse à Julien. Désactiver des tests pour faire monter l’indice ne rend pas le serveur plus sûr : on casse l’instrument de mesure. L’indice n’est pas un objectif ; ce qui compte, c’est que chaque écart restant soit corrigé ou accepté par écrit avec une raison. On n’exclut un test que pour un écart décidé et documenté dans le socle.

1. La surveillance DHCP est active sur le VLAN 10, mais le port 1, qui mène au pare-feu (le vrai serveur DHCP), n’est pas déclaré de confiance. Toutes les réponses DHCP arrivant par ce port sont rejetées : plus aucun poste n’obtient d’adresse. Correction :

interface GigabitEthernet1/0/1
 ip dhcp snooping trust

Comme le pare-feu ne gère pas l’option 82, on ajoute aussi no ip dhcp snooping information option en configuration globale.

2. Autres écarts.

3. Configuration corrigée.

interface range GigabitEthernet1/0/2 - 6
 switchport mode access
 switchport access vlan 10
 switchport nonegotiate
 switchport port-security
 switchport port-security maximum 3
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 spanning-tree portfast
 spanning-tree bpduguard enable
!
interface range GigabitEthernet1/0/7 - 8
 switchport mode access
 switchport access vlan 998
 shutdown

(spanning-tree bpduguard enable peut être remplacé par spanning-tree portfast bpduguard default en configuration globale.) La limite de 3 adresses, valeur de la configuration de référence de Vellacor (SISR-02), couvre le poste et le téléphone IP chaîné derrière lui (la configuration du VLAN de téléphonie, VLAN 40 chez Kervanet, relève de SISR-02).

4. Salle des petits-déjeuners : les ports 7 et 8 sont éteints, le petit commutateur ne s’allume même pas sur le réseau. Réception : dès que le petit commutateur envoie une BPDU, la garde BPDU met le port en « err-disabled » ; s’il n’envoie pas de BPDU (commutateur non administrable), la sécurité de port limite le nombre d’adresses à 3 et signale les suivantes (restrict : trames ignorées, compteur, message de journal et alerte SNMP).

5. Une erreur sur la surveillance DHCP ou l’inspection ARP coupe tout le site (question 1). On essaie donc la configuration en maquette, puis on l’applique en maintenance, site par site, en gardant l’accès console et une copie de la configuration précédente pour revenir en arrière.

1. Points contraires aux recommandations.

2. Plan corrigé.

3. Message (exemple). « Le Wi-Fi des clients est un réseau ouvert : le portail captif ne sert qu’à accepter les conditions d’utilisation, il ne chiffre rien. Un autre client présent dans l’hôtel peut donc lire ce qui n’est pas protégé par HTTPS. Wi-Fi Enhanced Open chiffre chaque connexion séparément, sans mot de passe à distribuer, et reste compatible avec notre portail. Nous proposons de l’activer sur les bornes qui le permettent. »

4. Règles d’administration : identifiants d’usine changés ; administration en HTTPS ou SSH seulement, depuis le VLAN 99 ; micrologiciel à jour à la livraison puis selon la politique de correction ; journaux des bornes envoyés au collecteur ; pas de borne personnelle ; nom de SSID qui ne révèle rien de technique.

1. Volumes.

• Sur un an, brut : 3,27 × 365 = 1 193,55 Go.
• Compressé (10 pour 1) : 1 193,55 ÷ 10 = 119,36 Go.
• Avec la marge de 30 % : 119,36 × 1,3 = 155,16 Go.

Interprétation : 155,16 Go < 500 Go ; le collecteur suffit, avec de la place pour d’autres sources. Attention : les fichiers du jour en cours ne sont pas encore compressés ; la marge couvre cet effet.

2. Royan. Volume : 250 + 9 × 3 = 277 Mo par jour. Débit moyen = 277 × 10⁶ × 8 ÷ 86 400 = 25 648 bit/s ≈ 25,65 kbit/s. Négligeable devant un VPN sur fibre ; il faut seulement surveiller les pointes (attaque, erreur en boucle) et la file d’attente du client si le VPN tombe.

3. Faiblesses de la proposition.

• UDP : pas d’accusé de réception, les messages perdus ne sont pas renvoyés ;
• en clair : les journaux (comptes, adresses, commandes) sont lisibles sur le chemin ;
• aucune authentification : n’importe quelle machine peut se faire passer pour le collecteur ou envoyer de faux journaux ;
• pas de file d’attente : si le collecteur est injoignable, les messages sont perdus.

Configuration corrigée (cours, partie 7) :

action(type="omfwd" target="10.20.99.26" port="6514" protocol="tcp"
       StreamDriver="gtls" StreamDriverMode="1"
       StreamDriverAuthMode="x509/name"
       StreamDriverPermittedPeers="vel-log01.vellacor.example"
       queue.type="LinkedList" queue.size="50000"
       action.resumeRetryCount="-1")

avec, dans global(), l’autorité de certification et le certificat du serveur (le nom autorisé est celui du certificat du collecteur, à adapter).

4. Preuves. Essai positif : logger -t verif-centralisation "test" sur le serveur, puis lecture du message dans le dossier de la machine sur le collecteur, à la bonne heure. Essai négatif : une connexion TLS sans certificat client (ou avec un certificat d’une autre autorité) est refusée par le collecteur.

5. Les journaux contiennent des données personnelles (comptes, adresses IP, heures) : on les garde le temps utile à la sécurité, en général six mois à un an selon la CNIL (B3-07), et la charte de Kervanet annonce un an. Les administrateurs des serveurs surveillés n’ont pas de droit d’écriture sur le collecteur pour respecter la séparation des tâches : un administrateur malveillant, ou un attaquant qui a volé son compte, ne peut pas effacer les traces de ses actions.

1. Comparaison. On compare la version complète du paquet à 1.9.16p2-3+deb13u1. Le suffixe +deb13u1 désigne la première mise à jour de Debian 13 ; +deb13u2, la deuxième, plus récente ; -1 est une révision plus ancienne que -3. (Sur un serveur, dpkg --compare-versions <installée> lt <corrigée> fait la comparaison sans erreur.)

4 serveurs vulnérables sur 7.

2. Le numéro 1.9.16p2 est celui du logiciel d’origine. Debian rétroporte les correctifs sans changer ce numéro : seule la partie après le tiret (révision Debian, suffixe +deb13uN) montre si le correctif est présent. Trois serveurs sont déjà corrigés.

3. CVSS-B 8,5 (≥ 7,0), preuve de concept mais pas d’exploitation signalée et faille locale : délai de 7 jours. Limite : 4/11 + 7 jours = mercredi 11 novembre 2026 (jour férié, mais la limite reste la même : la correction se planifie avant).

4. Expositions.

5. sudo n’est pas un service qui tourne en permanence : chaque commande sudo lance le nouveau programme, aucun redémarrage n’est nécessaire. On le vérifie avec needrestart -r l, qui liste les services utilisant encore une ancienne bibliothèque, et en contrôlant la version installée (dpkg -s sudo). Seule une mise à jour du noyau impose un redémarrage de la machine.

6. Mettre à jour sudo d’abord sur KV-RECETTE (fait le 10/11), vérifier en quelques minutes que KerMaint n’est pas touché (un correctif de sudo ne modifie ni PHP ni Apache), puis appliquer sur KV-KERMAINT dans le délai, après un instantané de la machine virtuelle pour pouvoir revenir en arrière. Attendre la recette complète d’une évolution de KerMaint n’est pas justifié pour ce paquet ; si un report est nécessaire, il se décide par écrit, avec une date.

AMission 1 — Vérifier la conformité

1.1

1.2 Conformes : C6, C8, C11, C12 = 4 ; partiels : C5, C9 = 2 ; non conformes : C1, C2, C3, C4, C7, C10 = 6. Taux de conformité = 4 ÷ 12 × 100 = 33,33 %. Si l’on compte chaque constat partiel pour moitié : (4 + 2 × 0,5) ÷ 12 × 100 = 41,67 %. Les deux sont défendables : on annonce la méthode utilisée.

1.3 Priorités.

BMission 2 — Corriger le commutateur

2.1

! C2 : pas de serveur web d'administration
no ip http server
no ip http secure-server
! C9 : surveillance DHCP et inspection ARP sur les quatre VLAN
no ip dhcp snooping information option
ip dhcp snooping vlan 10,20,30,40
ip arp inspection vlan 10,20,30,40
interface GigabitEthernet1/1/1
 ip arp inspection trust
! C1 : ports libres éteints et isolés
interface range GigabitEthernet1/0/19 - 24 , GigabitEthernet1/1/2 - 4
 switchport mode access
 switchport access vlan 998
 shutdown
! C10 : comptes nominatifs, plus de compte partagé ni de type 7
username lferrandi algorithm-type scrypt secret <secret>
username tgueguen algorithm-type scrypt secret <secret>
no username admin
line vty 0 15
 login local
 transport input ssh

En pratique, on crée les comptes nominatifs avant de supprimer admin, depuis une session console, et l’on garde un compte local de secours sous enveloppe (DAT-NT-25, R18). L’accès à l’administration depuis le VLAN 99 seulement est imposé par le filtrage du pare-feu (B3SISR-02).

2.2 Sans ip dhcp snooping trust sur le port Gi1/1/1, le commutateur aurait rejeté toutes les réponses du pare-feu : plus aucun poste n’aurait obtenu d’adresse (C12), les réceptions auraient été coupées. Vérification avant déploiement : configuration essayée sur la maquette du laboratoire, puis contrôle show ip dhcp snooping (VLAN surveillés, port Gi1/1/1 « trusted ») et show ip dhcp snooping binding (des baux apparaissent), avec un poste de test qui renouvelle son adresse ; application en maintenance avec accès console.

CMission 3 — Traiter les vulnérabilités

3.1 AV:A : attaque depuis le réseau adjacent (ici, le même réseau Wi-Fi) ; AC:L/AT:N : simple ; PR:N/UI:N : sans compte ni action d’un utilisateur ; VC/VI/VA:H : prise de contrôle de la borne ; SC/SI/SA:H : impact élevé sur d’autres systèmes par rebond. Score 9,4 : critique. Dans un hôtel, le réseau adjacent, c’est le Wi-Fi des clients, ouvert à toute personne présente : n’importe quel client peut être l’attaquant.

3.2 Bornes : pas d’exploitation connue, CVSS-B ≥ 7,0 → 7 jours : lundi 16 novembre 2026. Pare-feu : exploitée et exposée → 24 h après l’alerte : mercredi 11 novembre 2026 à 16 h. Dernier pare-feu corrigé le 11/11 à 1 h 30, soit 9 h 30 après l’alerte : délai tenu.

3.3 Le correctif arrive le 20/11, après la limite du 16/11. Conduite : appliquer dès le 9/11 une mesure de contournement (par exemple, si l’éditeur l’indique, couper la fonction vulnérable, renforcer l’isolement entre clients et interdire l’accès aux interfaces des bornes depuis le VLAN 30), documenter l’écart (ticket, décision écrite de Julien Maréchal, information de Kervanet), surveiller les journaux des bornes, puis installer la 7.5 dès sa sortie, en maintenance, avec test d’une borne pilote.

DMission 4 — Centraliser les journaux

4.1 Royan : 250 + 9 × 3 = 277 Mo par jour ; sur un an compressé : 277 × 365 ÷ 10 = 10 110,5 Mo ≈ 10,11 Go.

4.2 TLS (TCP 6514) plutôt qu’UDP 514 : livraison avec accusé de réception et file d’attente si le VPN tombe ; confidentialité des journaux sur le chemin ; authentification mutuelle par certificats (pas de faux collecteur, pas de faux émetteur). Preuve : message de test envoyé depuis le pare-feu et le commutateur de Royan, retrouvé sur VEL-LOG01 dans le dossier de chaque équipement, à la bonne heure ; essai négatif d’une connexion sans certificat, refusée.

EMission 5 — Rendre compte

5.1 Réponse (exemple).

Madame, voici l’état au 11/11/2026. (a) Vellacor a adopté le 20/10/2026 un socle de configuration tiré des guides de l’ANSSI (GNU/Linux, commutateurs, Wi-Fi) ; l’audit du site pilote de Royan montre encore 6 écarts non conformes sur 12 points contrôlés, en cours de correction par ordre de priorité. (b) Les journaux des serveurs sont déjà copiés chez Vellacor ; ceux des pare-feu et des équipements réseau le seront, de façon chiffrée, d’ici fin décembre, pour une conservation d’un an. (c) Notre politique écrite impose 24 h pour une faille exploitée sur un équipement exposé et 7 jours pour une faille critique ou élevée ; en novembre, l’alerte sur les pare-feu a été traitée en 9 h 30. Nous vous transmettrons le tableau de suivi chaque mois.

5.2 Exigences pour la 8e résidence (trois au choix).