Durcir l'infrastructure

1. Pourquoi durcir

ALes questions de l’assureur

Le 13 octobre 2026, l’assureur de Kervanet Hôtels & Résidences a envoyé un questionnaire avant de renouveler la garantie cyber (B3-01). Trois questions embarrassent Gwenaëlle Le Bihan : « Vos serveurs sont-ils configurés selon un référentiel de sécurité ? Vos journaux sont-ils conservés hors des machines ? En combien de jours corrigez-vous une faille critique ? »

Le 16 octobre, Julien Maréchal ouvre le ticket VEL-2026-4455 pour Lucas Ferrandi, alternant SISR : écrire un socle de durcissement des serveurs Debian et des équipements réseau, l’essayer sur la machine du laboratoire LAB-UBU01, auditer l’existant et préparer les réponses pour le comité de direction du 15 novembre. Ses premiers constats, au 20 octobre, servent de fil au chapitre.

BDurcir, c’est quoi ?

Le durcissement ne remplace ni le pare-feu (B3SISR-02) ni la détection (B3SISR-03). Trois principes le guident : minimiser (ce qui n’existe pas ne peut pas être attaqué), moindre privilège (B3-05) et traçabilité.

2. Choisir un référentiel

ALes familles de référentiels

L’ISO/IEC 27002:2022 contient des mesures que ce chapitre met en œuvre : 8.8 gestion des vulnérabilités techniques, 8.9 gestion des configurations, 8.15 journalisation, 8.17 synchronisation des horloges, 8.20 sécurité des réseaux. Une norme dit quoi obtenir ; un guide technique dit comment le régler sur tel système.

BLes guides de l’ANSSI utiles ici

Le guide GNU/Linux classe chaque recommandation selon quatre niveaux cumulatifs : minimal (à appliquer partout), intermédiaire (dès que possible sur la plupart des systèmes), renforcé (besoin de sécurité fort) et élevé (si l’équipe a les compétences et le temps de le maintenir). Appliquer un niveau suppose d’avoir appliqué ceux du dessous.

CD’autres référentiels

• Les CIS Benchmarks (Center for Internet Security) donnent, système par système, des réglages notés et des procédures de contrôle.
• Le projet libre ComplianceAsCode (contenu utilisé par l’outil OpenSCAP) propose, au 20/10/2026, des profils ANSSI-BP-028 (minimal, intermédiaire, renforcé, élevé) pour Debian 12 et Debian 13 : ils vérifient automatiquement une partie des recommandations.
• Les éditeurs publient aussi leurs guides de durcissement (systèmes, commutateurs, pare-feu).

Quand deux référentiels divergent, on choisit et on écrit le choix. Exemple : Lynis (partie 10) suggère une bannière de connexion, alors que la note de l’ANSSI sur les commutateurs recommande de ne pas en configurer (R23), pour ne rien révéler de l’équipement. Vellacor a retenu un avertissement juridique court, sans aucune information technique, sur les serveurs.

DÉcrire le socle de l’organisation

3. Vérifier la sûreté

ALes éléments à vérifier

Le technicien participe à la vérification : il contrôle des points précis, relève les preuves et signale les écarts. La conception de la haute disponibilité relève de SISR-07, la sauvegarde de B1-05, la supervision de SISR-09.

4. Réduire la surface d’attaque

ARecenser les services à l’écoute

Sur un serveur Linux, la commande ss liste les connexions ; avec -tulpn, elle affiche les ports TCP et UDP en écoute, le processus concerné, et les adresses en chiffres (n). Voici LAB-UBU01 (Ubuntu 24.04 LTS, 10.20.50.20), tel que Lucas l’a reçu au laboratoire le 20/10/2026.

$ ss -tulpn
Netid State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess                          
udp   UNCONN 0      0            0.0.0.0:514       0.0.0.0:*    users:(("rsyslogd",pid=65,fd=6))
tcp   LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=63,fd=3))    
tcp   LISTEN 0      5            0.0.0.0:8000      0.0.0.0:*    users:(("python3",pid=71,fd=3)) 

Lecture : trois services écoutent sur 0.0.0.0, toutes les adresses de la machine : une réception syslog (UDP 514) inutile hors d’un collecteur, un serveur web de test oublié (port 8000) et SSH.

On vérifie aussi depuis le réseau. Lucas lance un balayage de ports depuis la maquette voisine LAB-LOG01 (10.20.50.42), sur sa propre machine de laboratoire :

$ nmap -n -Pn -sT -sU -p T:1-65535,U:514 10.20.50.20
Nmap scan report for 10.20.50.20
Host is up (0.00011s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT     STATE         SERVICE
22/tcp   open          ssh
8000/tcp open          http-alt
514/udp  open|filtered syslog

BFermer ce qui ne sert pas

La règle de l’ANSSI est double : n’installer que les paquets strictement nécessaires (R58) et désactiver les services qui ne servent pas (R62) ; pour les services réseau, réduire la surface exposée (R80), par exemple en n’écoutant que sur l’adresse utile.

Après le traitement, LAB-UBU01 n’expose plus que SSH, et seulement sur son adresse :

$ ss -tulpn
Netid State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess                             
tcp   LISTEN 0      128      10.20.50.20:22        0.0.0.0:*    users:(("sshd",pid=42577,fd=3))    

Le balayage depuis LAB-LOG01 ne trouve plus que 22/tcp open ssh.

Le même raisonnement s’applique aux constats de Kervanet. Sur KV-RECETTE, le serveur web de développement oublié depuis la recette du 9 octobre est arrêté, et la consigne de recette précise désormais qu’un outil de test s’arrête à la fin de la séance. À l’inverse, MariaDB, sur KV-KERMAINT, montre le bon réglage : elle n’est appelée que par KerMaint, installé sur la même machine, et n’écoute que sur 127.0.0.1 (directive bind-address, réglage du paquet Debian, SLAM-06) ; le port 3306 n’est pas joignable du réseau. L’interface web de KV-TEL doit passer en HTTPS et n’être joignable que depuis le VLAN d’administration, ce que le pare-feu doit aussi imposer (B3SISR-02).

CSupprimer les comptes par défaut

L’ANSSI demande de désactiver les comptes inutilisés (R30) ; les comptes d’administration et leurs revues sont traités en B3-05 : ici, on vérifie qu’aucun équipement n’a gardé ses identifiants d’usine.

5. Durcir un serveur Linux

ARenforcer SSH

Tu as vu en B3-05 les directives qui protègent les comptes (PermitRootLogin no, AllowGroups, PasswordAuthentication no, double authentification) et en B3-06 l’authentification par clé. Le socle les complète par des réglages qui réduisent ce qu’une session permet et ce qu’un attaquant peut tenter.

Sur Debian 13 comme sur Ubuntu, le fichier principal /etc/ssh/sshd_config commence par Include /etc/ssh/sshd_config.d/*.conf. On ne modifie donc pas le fichier livré : on ajoute un fichier dans sshd_config.d, qui survit aux mises à jour du paquet.

Voici le fichier essayé sur LAB-UBU01 (OpenSSH 9.6p1 ; mêmes directives dans OpenSSH 10.0 de Debian 13) :

$ cat /etc/ssh/sshd_config.d/10-durcissement.conf
# Socle SSH des serveurs Debian gérés par Vellacor (version du 20/10/2026)
ListenAddress 10.20.50.20
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowGroups ssh-admins
MaxAuthTries 3
LoginGraceTime 30
MaxSessions 2
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitUserEnvironment no
TCPKeepAlive no
LogLevel VERBOSE
Banner /etc/issue.net

On contrôle la syntaxe avant de recharger le service, en gardant une session ouverte (B3-05) :

$ sshd -t && echo syntaxe OK
syntaxe OK

Puis on lit la configuration effective, avant et après :

BRégler le noyau et les droits

Le noyau Linux expose des paramètres réglables (sysctl). La recommandation R12 de l’ANSSI fixe ceux de la pile IPv4 : un serveur qui n’est pas un routeur ne relaie pas les paquets, n’accepte pas les redirections ICMP ni le routage par la source, vérifie l’adresse d’origine des paquets (reverse path filtering) et journalise les paquets aux adresses impossibles (martians). On les écrit dans un fichier de /etc/sysctl.d/, appliqué au démarrage :

$ cat /etc/sysctl.d/60-durcissement-reseau.conf
# Paramètres réseau IPv4 (inspirés de la recommandation R12 de l'ANSSI, guide BP-028 v2.0)
net.ipv4.ip_forward = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.tcp_syncookies = 1

sysctl -p /etc/sysctl.d/60-durcissement-reseau.conf applique le fichier tout de suite ; sysctl net.ipv4.ip_forward lit une valeur. Les autres paramètres du noyau se testent d’abord en maquette.

Deux réglages de comptes complètent le socle :

• le masque par défaut des fichiers créés (UMASK dans /etc/login.defs) passe de 022 à 027 : un nouveau fichier n’est plus lisible par « les autres » (R36 de l’ANSSI, qui fixe 0077 pour les sessions des utilisateurs et en général 0027 pour les services) ;
• les vidages mémoire (core dumps), qui peuvent contenir des mots de passe en clair, sont interdits par la ligne * hard core 0 dans /etc/security/limits.conf.

6. Corriger les vulnérabilités

ALes sources d’information

Le CERT-FR (centre gouvernemental de veille, d’alerte et de réponse, rattaché à l’ANSSI, site cert.cyber.gouv.fr) publie plusieurs types de documents, reconnaissables à leur référence. Au 20/10/2026, sa page d’accueil en présente six types, dont les quatre suivants (les autres : menaces et incidents, indicateurs de compromission).

Un flux RSS permet de recevoir ces publications. L’organisation de la veille (abonnements, tri, corrélation avec l’inventaire) est traitée en B3SISR-03 ; ici, tu apprends à exploiter un avis pour un serveur.

BLire un score CVSS 4.0

Le CVSS (Common Vulnerability Scoring System), publié par le FIRST, note la gravité d’une vulnérabilité de 0 à 10. Au 20/10/2026, la version en vigueur est la 4.0, publiée en novembre 2023 ; beaucoup d’avis anciens donnent encore un score en 3.1. Les deux versions ne se comparent pas directement : on note toujours la version avec le score.

Le groupe de menace contient la maturité de l’exploitation E : A attaquée (exploitée), P preuve de concept publiée, U aucune exploitation signalée. Le score est alors noté CVSS-BT (base et menace), au lieu de CVSS-B pour la base seule.

CVersion affichée et version corrigée

Le 1er juillet 2024, le CERT-FR a publié l’alerte CERTFR-2024-ALE-009 sur la faille CVE-2024-6387 d’OpenSSH (surnommée « regreSSHion ») : exécution de code à distance avec les droits de root, sans authentification, sur les versions 8.5p1 à 9.7p1 ; le score donné par l’organisme qui a enregistré la CVE est 8,1 en CVSS 3.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). L’alerte, close le 7 octobre 2024, recommandait le correctif de l’éditeur ou de la distribution, avec un contournement temporaire (LoginGraceTime 0, au prix d’un risque de déni de service).

LAB-UBU01 affiche OpenSSH 9.6p1, dans la plage vulnérable. Est-il vulnérable ? Pas forcément : les distributions rétroportent les correctifs de sécurité dans leur propre version du paquet, sans changer le numéro de la version d’origine. Le journal des modifications du paquet le montre :

$ dpkg -s openssh-server | grep ^Version
Version: 1:9.6p1-3ubuntu13.20
$ zcat /usr/share/doc/openssh-server/changelog.Debian.gz | grep -B4 -A1 'CVE-2024-6387.patch'
openssh (1:9.6p1-3ubuntu13.3) noble-security; urgency=medium

  * SECURITY UPDATE: remote code execution via signal handler race
    condition (LP: #2070497)
    - debian/patches/CVE-2024-6387.patch: don't log in sshsigdie() in log.c.
    - CVE-2024-6387

Le correctif de CVE-2024-6387 est entré dans le paquet 1:9.6p1-3ubuntu13.3 (juin 2024) ; la machine a une version plus récente du paquet, donc corrigée, même si elle affiche « 9.6p1 ».

DLa politique de correction des serveurs

Le 20/10/2026, Julien Maréchal a validé les délais proposés par Lucas pour les serveurs et équipements gérés par Vellacor.

Le paquet unattended-upgrades (B3-04) installe seul les mises à jour de sécurité des serveurs internes de Vellacor, sauf sur KV-KERMAINT, où une mise à jour de PHP passe d’abord par la recette (B1-11) : exception écrite au socle.

7. Centraliser les journaux

AJournald et rsyslog

Sur Debian 13, deux outils coexistent :

• systemd-journald reçoit les messages du système et des services et les range dans un journal binaire, lu avec journalctl ; depuis Debian 12, rsyslog n’est plus installé par défaut et le journal est conservé dans /var/log/journal ;
• rsyslog, à installer (apt install rsyslog rsyslog-gnutls), écrit des fichiers texte et surtout transmet les messages à un autre serveur, au format syslog.

Pour que le journal local survive aux redémarrages et ne remplisse pas le disque, Vellacor fixe ses réglages dans un fichier de /etc/systemd/journald.conf.d/ (directives de la page de manuel journald.conf(5)) :

[Journal]
Storage=persistent
SystemMaxUse=1G

Storage=persistent impose l’écriture sur disque ; SystemMaxUse limite la place occupée par le journal.

BEnvoyer les journaux en TLS

Le protocole syslog circule historiquement en clair sur le port UDP 514 : n’importe quel équipement du chemin peut lire les messages, et rien ne garantit qu’ils arrivent. C’est le cas chez Vellacor depuis 2023 : les serveurs Debian de Vellacor et de Kervanet envoient leurs journaux en UDP au collecteur VEL-LOG01 (Debian 13, 10.20.99.26, dans le VLAN 99 d’administration, seul réseau de Vellacor admis dans les tunnels vers Kervanet), à travers le VPN. Lucas propose le transport TCP chiffré par TLS (RFC 5425, port 6514) avec des certificats des deux côtés.

Il essaie la configuration au laboratoire : LAB-UBU01 envoie ses journaux à une maquette de collecteur, LAB-LOG01 (10.20.50.42), avec des certificats d’une autorité de test (rsyslog 8.2312 ; même syntaxe pour la version de Debian 13). Côté client, un fichier de /etc/rsyslog.d/ :

$ cat /etc/rsyslog.d/90-centralisation.conf
# Envoi de tous les journaux vers le collecteur, en TCP chiffré par TLS (port 6514)
global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog-tls/ca.crt"
  DefaultNetstreamDriverCertFile="/etc/rsyslog-tls/lab-ubu01.crt"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog-tls/lab-ubu01.key"
)
action(type="omfwd" target="10.20.50.42" port="6514" protocol="tcp"
       StreamDriver="gtls" StreamDriverMode="1"
       StreamDriverAuthMode="x509/name"
       StreamDriverPermittedPeers="lab-log01.vellacor.example"
       queue.type="LinkedList" queue.size="50000"
       action.resumeRetryCount="-1")

• StreamDriver="gtls" et StreamDriverMode="1" imposent TLS ;
• StreamDriverAuthMode="x509/name" vérifie le certificat du collecteur et son nom (StreamDriverPermittedPeers) : un faux collecteur est refusé ;
• la file d’attente (queue.*) garde les messages si le collecteur est injoignable, et action.resumeRetryCount="-1" réessaie sans fin.

Côté collecteur, l’entrée TCP exige un certificat client valide (x509/certvalid) et range les messages par machine :

# Collecteur de journaux (maquette LAB-LOG01) : réception TLS sur 10.20.50.42:6514
global(
  workDirectory="/var/spool/rsyslog/collecteur"
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog-tls/ca.crt"
  DefaultNetstreamDriverCertFile="/etc/rsyslog-tls/lab-log01.crt"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog-tls/lab-log01.key"
)
module(load="imtcp" StreamDriver.Name="gtls" StreamDriver.Mode="1"
       StreamDriver.AuthMode="x509/certvalid")
template(name="ParHote" type="string"
         string="/var/log/distant/%HOSTNAME%/%PROGRAMNAME%.log")
ruleset(name="distant") { action(type="omfile" dynaFile="ParHote") }
input(type="imtcp" address="10.20.50.42" port="6514" ruleset="distant")

Lucas vérifie la syntaxe (rsyslogd -N1), redémarre le service, puis envoie un message de test (au laboratoire, la socket locale de rsyslog est /run/devlog ; sur un serveur, logger sans -u suffit) :

$ rsyslogd -N1 -f /etc/rsyslog.conf
rsyslogd: version 8.2312.0, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.
$ logger -u /run/devlog -t verif-centralisation -p auth.notice "test de centralisation des journaux"
(sur le collecteur LAB-LOG01)
$ ls -R /var/log/distant
/var/log/distant:
lab-ubu01

/var/log/distant/lab-ubu01:
verif-centralisation.log
$ tail -n 1 /var/log/distant/lab-ubu01/verif-centralisation.log
2026-10-21T00:30:27+02:00 lab-ubu01 verif-centralisation: test de centralisation des journaux
(essai négatif : un client sans certificat envoie un faux message)
$ printf '<13>Oct 21 10:00:00 intrus faux: message non autorisé\n' | openssl s_client -connect 10.20.50.42:6514 -CAfile ca.crt -quiet
verify return:1
verify return:1
$ ls /var/log/distant
lab-ubu01

Le message de test arrive dans le dossier de lab-ubu01, avec l’heure exacte. Dans l’essai négatif, le client vérifie bien le certificat du collecteur (verify return:1), mais il n’a pas de certificat à présenter : le collecteur refuse la session et le faux message n’est écrit nulle part (aucun dossier intrus).

CLes équipements réseau

Les pare-feu et les commutateurs doivent aussi envoyer leurs journaux. Sur OPNsense, une cible distante se déclare dans System > Settings > Logging, onglet Remote (transport, port, adresse, certificat pour TLS). Sur un commutateur de type Cisco IOS, logging host <adresse> désigne le collecteur, et l’ANSSI demande au moins de journaliser les authentifications et tentatives d’authentification (DAT-NT-25, R11). L’analyse de ces journaux, les alertes et la corrélation relèvent de B3SISR-03.

8. Sécuriser les commutateurs

AProtéger l’administration du commutateur

Les commandes de cette partie sont celles d’un commutateur à ligne de commande de type Cisco IOS (guides de configuration Cisco IOS XE 17.12 pour Catalyst 9300 et guide Cisco « Harden IOS Devices », vérifiés le 20/10/2026). Les commutateurs d’autres marques ont des fonctions équivalentes sous d’autres noms.

BLes attaques de niveau 2

Le niveau 2 (liaison) est celui des adresses MAC, des VLAN et de l’arbre couvrant (SISR-02). Plusieurs attaques l’exploitent, souvent depuis une simple prise réseau.

CLes ports et les VLAN

La note de l’ANSSI sur les commutateurs pose des règles simples : interdire la configuration automatique des ports (R26), placer les ports inutilisés dans un VLAN de quarantaine et les désactiver (R27), ne jamais utiliser le VLAN par défaut (R28) et choisir un VLAN natif différent du VLAN par défaut, non attribué aux ports d’accès (R29).

DLa configuration d’un commutateur de TRA

Pour la 8e résidence (La Tranche-sur-Mer, site TRA, réseaux 10.48.x.0/24), Lucas prépare la configuration de KV-TRA-SW02, commutateur des bureaux de 8 ports (SISR-01) : port 1, liaison vers KV-TRA-SW01 et le pare-feu, qui sert de serveur DHCP ; ports 2 à 4, les 3 postes administratifs branchés derrière leur téléphone IP ; port 5, l’imprimante (VLAN 20) ; port 6, la borne KV-TRA-AP02 ; ports 7 et 8, libres. Il reprend la configuration de référence des commutateurs de Kervanet (SISR-02) et y ajoute l’inspection ARP. Extrait, à essayer d’abord en maquette :

! — protections globales —
ip dhcp snooping vlan 10,20,30,40
no ip dhcp snooping information option
ip dhcp snooping
ip arp inspection vlan 10,20,30,40
spanning-tree portfast bpduguard default
no ip http server
no ip http secure-server
!
! — liaison vers le reste du réseau (port de confiance) —
interface GigabitEthernet1/0/1
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,30,40,99
 switchport nonegotiate
 ip dhcp snooping trust
 ip arp inspection trust
!
! — postes des bureaux (derrière leur téléphone) —
interface range GigabitEthernet1/0/2 - 4
 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
 storm-control broadcast level 5.00
!
! — ports libres —
interface range GigabitEthernet1/0/7 - 8
 switchport mode access
 switchport access vlan 998
 shutdown

Quelques choix à expliquer : maximum 3 est la valeur de la configuration de référence de Vellacor pour un poste branché derrière son téléphone IP (SISR-02) ; restrict laisse le poste légitime travailler et signale l’intrus, quand shutdown coupe tout ; no ip dhcp snooping information option évite que le commutateur ajoute l’option 82, que le serveur DHCP du pare-feu ne gère pas ; la garde BPDU est activée globalement sur tous les ports PortFast. Les ports 5 (imprimante, une seule adresse autorisée) et 6 (borne, liaison 802.1Q des VLAN 10, 30 et 99, natif 999) suivent les modèles de SISR-02.

Pour vérifier : show port-security interface <port> (maximum, mode, violations), show ip dhcp snooping et show ip dhcp snooping binding (ports de confiance, table des baux), show ip arp inspection vlan 10 et show interfaces status err-disabled (ports coupés par une protection).

EIsoler l’administration

Pour tous les équipements (commutateurs, bornes, onduleur, hyperviseurs, pare-feu), les interfaces d’administration n’écoutent que dans le réseau d’administration (VLAN 99 de chaque site, joignable seulement depuis le VLAN 99 de Vellacor ; PA-022 ; la note DAT-NT-25 vise même une séparation physique, R2), en protocole chiffré, avec des comptes nominatifs (B3-05).

9. Sécuriser le Wi-Fi

ALes modes de sécurité

Le Wi-Fi du personnel de Kervanet (KV-Personnel, VLAN 10) fonctionne en WPA2/WPA3 Personnel, c’est-à-dire en mode de transition, avec une clé partagée inchangée depuis 2023 : tout salarié parti la connaît. La cible est WPA3-Entreprise avec certificats de poste (projet 802.1X de B3-05) ; en attendant, la clé doit être changée et sa rotation planifiée.

BSéparer et administrer

L’ANSSI recommande de placer chaque réseau Wi-Fi dans son propre VLAN, de filtrer les flux entre réseaux au pare-feu, d’isoler le réseau des invités, de ne pas masquer le SSID mais de choisir un nom qui ne révèle rien, et d’administrer les bornes comme tout équipement : identifiants d’usine changés, protocoles chiffrés (TLS, SSH), interface d’administration dans le réseau d’administration, mises à jour rapides, événements envoyés à la supervision.

Le Wi-Fi des clients (VLAN 30) est un réseau ouvert avec portail captif : ouvert veut dire non chiffré, un autre client peut écouter ce qui n’est pas protégé par TLS. La Wi-Fi Alliance propose Wi-Fi Enhanced Open, qui chiffre chaque connexion sans mot de passe commun et reste compatible avec les portails captifs ; Lucas propose de l’activer si les bornes le permettent, et de vérifier l’isolation entre clients (deux téléphones du même réseau ne doivent pas se voir).

10. Auditer la conformité

ALynis, un outil d’audit

Lynis est un outil libre d’audit de sécurité pour Linux et les autres systèmes de type Unix. Il s’installe par le paquet de la distribution (apt install lynis) ou depuis le site de l’éditeur, qui publie des versions plus récentes (3.1.7 du 25/06/2026). Lancé en root par lynis audit system, il exécute plusieurs centaines de tests sans modifier la configuration et produit :

• des avertissements (warnings) : problèmes à traiter en priorité ;
• des suggestions : améliorations possibles, chacune avec un identifiant de test (SSH-7408, AUTH-9286…) ;
• un indice de durcissement (hardening index) sur 100, qui résume l’état et permet de suivre l’évolution ;
• un journal (/var/log/lynis.log) et un rapport pour les scripts (/var/log/lynis-report.dat).

BLire un rapport

Lucas audite LAB-UBU01 avant et après le durcissement des parties 4 et 5 (Lynis 3.1.7, option --quick, 20/10/2026). Avant :

  Warnings (4):
  ! Found one or more vulnerable packages. [PKGS-7392] 
  ! Nameserver 10.20.50.53 does not respond [NETW-2704] 
  ! Couldn't find 2 responsive nameservers [NETW-2705] 
  ! iptables module(s) loaded, but no rules active [FIRE-4512] 
  Suggestions (45):
  Hardening index : 66 [#############       ]
  Tests performed : 250

Après :

  Warnings (4):
  ! Found one or more vulnerable packages. [PKGS-7392] 
  ! Nameserver 10.20.50.53 does not respond [NETW-2704] 
  ! Couldn't find 2 responsive nameservers [NETW-2705] 
  ! iptables module(s) loaded, but no rules active [FIRE-4512] 
  Suggestions (31):
  Hardening index : 80 [################    ]
  Tests performed : 249

Lecture : l’indice passe de 66 à 80 (+ 14 points) et les suggestions de 45 à 31 ; les avertissements restent 4. Les suggestions disparues correspondent aux réglages appliqués (SSH, masque 027, vidages mémoire, envoi des journaux à un hôte distant) et aux deux écarts déclarés dans le profil (port 22, durée de vie des mots de passe). Les avertissements restants se traitent un par un : PKGS-7392 signale des paquets à mettre à jour (règle S-04, politique de correction) ; NETW-2704 et NETW-2705 viennent de la maquette isolée, dont le résolveur de test ne répond pas : propres au laboratoire ; FIRE-4512 relève qu’aucune règle de pare-feu local n’est chargée : le filtrage relève de B3SISR-02, et un pare-feu local sur les serveurs est à décider dans le socle.

La commande lynis show details SSH-7408 affiche ensuite, ligne par ligne, ce que le test a vérifié (option trouvée, valeur, verdict).

CTrier les résultats

Les écarts acceptés se déclarent dans un profil personnalisé (/etc/lynis/custom.prf), qui complète le profil par défaut. La directive skip-test exclut un test entier ou une seule option d’un test :

$ cat /etc/lynis/custom.prf
# Écarts acceptés pour les serveurs Debian de Kervanet (décision J. Maréchal)
# Port SSH 22 conservé : service joignable seulement depuis le réseau d'administration
skip-test=SSH-7408:port
# Pas d'expiration périodique des mots de passe (ANSSI, CNIL) ; comptes d'administration par clé
skip-test=AUTH-9286

DLa fiche de conformité

Le résultat de l’audit se présente dans une fiche de conformité : une ligne par règle du socle, son état, la preuve et la suite donnée.

Taux de conformité de l’extrait : 5 règles conformes sur 7 contrôlées, soit 5 ÷ 7 × 100 = 71,43 %, une règle partielle et une non conforme, chacune avec une action.

11. Intégrer la sécurité au projet

ALes exigences dès le départ

Le raccordement de la 8e résidence (TRA) sera conduit au premier trimestre 2027 (B1-10, SISR-01). Lucas propose d’ajouter au cahier des charges une rubrique « Sécurité », tirée du socle, pour que le site naisse durci au lieu d’être corrigé après coup.

BDe la recette à l’acceptation du risque

La recette de sécurité exécute chaque test, positif et négatif, et en garde la preuve (B3-05). Ce qui ne passe pas est corrigé avant la mise en service, ou accepté par écrit par le client, avec une date de correction. L’ANSSI appelle homologation la décision formelle, par une autorité, d’accepter les risques résiduels d’un système d’information avant sa mise en service (guide « L’homologation de sécurité des systèmes d’information », publié le 01/04/2025) ; obligatoire pour certains systèmes publics, la démarche est une bonne pratique pour toute organisation. Pour Kervanet, l’autorité est la direction (Yannick Le Floc’h), sur proposition de Vellacor.

Erreurs fréquentes et points de vigilance

L’essentiel du chapitre

Sources et références

• Arrêté du 29/04/2019 (BTS SIO) modifié par les arrêtés des 8/07/2024 et 22/11/2024 ; référentiel de la fiche RNCP40792, bloc 3, activité A3.5.
• ANSSI (messervices.cyber.gouv.fr, consulté le 20/10/2026) : ANSSI-BP-028 v2.0 du 03/10/2022 (niveaux et R12, R30, R33, R36 lus dans le PDF ; liste R1 à R80 vérifiée dans le fichier de contrôles du projet ComplianceAsCode) ; PA-022 v3.0 (page du 11/05/2021) ; DAT-NT-007 v1.3 du 17/08/2015 ; DAT-NT-25 v1.0 du 24/06/2016 (R1 à R30) ; architecture d’un système de journalisation (page du 28/01/2022) ; « Les essentiels : sécurisation des réseaux Wi-Fi » v1.0 (08/2026) ; « L’homologation de sécurité des systèmes d’information » (page du 01/04/2025).
• CERT-FR (cert.cyber.gouv.fr) : page d’accueil et alerte CERTFR-2024-ALE-009 ; enregistrement CVE-2024-6387 (API du programme CVE) ; FIRST, spécification CVSS v4.0 ; consultés le 20/10/2026.
• ISO/IEC 27002:2022, intitulés des mesures 8.8, 8.9, 8.15, 8.17, 8.20 (table de correspondance de NQA, consultée le 20/10/2026).
• Cisco (consultés le 20/10/2026) : guides de configuration Cisco IOS XE Dublin 17.12.x pour Catalyst 9300 (sécurité, niveau 2, VLAN), document 222274 (surveillance DHCP), « Harden IOS Devices » (13608, mis à jour le 12/09/2024).
• Wi-Fi Alliance, page « Security » ; IETF, RFC 5425 ; Debian, notes de publication de Debian 12 (§ 5.1.7) ; journald.conf(5) ; documentation d’OPNsense (journalisation distante) ; documentation et journal des versions de Lynis ; consultés le 20/10/2026.
• Commandes exécutées le 20/10/2026 sur LAB-UBU01 (Ubuntu 24.04 LTS : OpenSSH 9.6p1, rsyslog 8.2312.0, Lynis 3.1.7, nmap 7.94, OpenSSL 3.0.13).

Contenu original FuturBTS. Vellacor Services Numériques, Kervanet Hôtels & Résidences et les personnes citées sont fictifs ; les noms de domaine sont tirés du domaine réservé .example, les adresses du plan d’adressage fictif du fil rouge. Les configurations d’équipements sont des exemples pédagogiques à essayer en maquette. Aucun passage, exemple ou exercice n’est repris d’un manuel existant.