B3-11

Durcir les serveurs Linux et Windows

Réduire la surface d'attaque d'un serveur Debian et d'un serveur Windows en suivant un référentiel, puis mesurer le résultat et surveiller les journaux de sécurité.

Version en ligne

SIO2 · semestre 35 h (cours + TP)Bloc 3 – CybersécuritéMémo · Portail SIO

L'essentiel

Durcir = réduire la surface d'attaque : services, comptes, logiciels, droits et interfaces exposés.
Trois principes : moindre service, moindre privilège, défense en profondeur.
On s'appuie sur un référentiel (ANSSI, CIS) et on justifie chaque écart.
Debian : unattended-upgrades, services inutiles purgés, comptes nominatifs avec sudo.
SSH : clés ed25519, PermitRootLogin no, PasswordAuthentication no, AllowGroups ; tester avec sshd -t.
Fail2ban bannit une adresse après maxretry échecs dans findtime, pendant bantime ; sur Debian 13, backend = systemd.
Pare-feu local : tout refuser en entrée, ouvrir le strict nécessaire, SSH avant ufw enable.
Windows : rôles minimaux, comptes d'administration séparés, verrouillage, LAPS, pare-feu sur 3 profils, Defender, SMBv1 absent.
Mesurer avant et après : Lynis (Linux), PingCastle (AD).
Surveiller 4625, 4720, 4732, 4740, 1102 et les échecs SSH, journaux envoyés hors du serveur.

À retenir

Un durcissement se justifie : chaque réglage appliqué est rattaché à une règle d'un référentiel (« ANSSI GNU/Linux, niveau minimal », « CIS Windows Server 2025, niveau 1 »), et chaque écart volontaire est noté avec sa raison. C'est ce document que demandent un auditeur et le jury de l'épreuve E6.

Piège classique

Avant de verrouiller root ou d'interdire les mots de passe en SSH, vérifie que ton compte nominatif fonctionne : ouvre une seconde session, teste sudo -v, et garde la première ouverte. Sinon, seule la console Proxmox de la VM permettra de récupérer la main.

Piège Debian 12 et 13

Debian n'écrit plus /var/log/auth.log par défaut : les journaux sont dans journald. Sur Debian 13, le paquet fail2ban règle déjà la prison sshd sur le journal systemd ; le piège vient d'un jail.local repris d'un serveur Debian 12 ou modifié à la main (backend = auto, logpath = /var/log/auth.log) : Fail2ban cherche alors un fichier qui n'existe pas et ne bannit personne. Écrire backend = systemd dans la prison reste une bonne pratique. Contrôle avec sudo fail2ban-client status sshd : le compteur « Currently failed » doit bouger quand tu rates une connexion.

À retenir

Les journaux d'un serveur compromis ne sont plus fiables : on les envoie en continu vers un serveur de journalisation (syslog, fiche B2-29) ou un SIEM comme Wazuh (fiche B3-13), où l'attaquant ne peut pas les effacer. Le durcissement se mesure avant et après, et se contrôle ensuite à intervalle régulier.

Commandes clés

Pour…	Commandes
Mises à jour automatiques	`apt install unattended-upgrades` · `dpkg-reconfigure -plow unattended-upgrades`
Voir ce qui écoute	`ss -tlnp` · `systemctl disable --now SERVICE` · `apt purge PAQUET`
Clé SSH	`ssh-keygen -t ed25519` · `ssh-copy-id` · `sshd -t` puis `systemctl reload ssh`
Fail2ban	`fail2ban-client status sshd` · `fail2ban-client set sshd unbanip IP`
Pare-feu local	`ufw default deny incoming` · `ufw allow from RÉSEAU to any port 22 proto tcp` · `ufw enable`
Contrôles Windows	`Get-NetFirewallProfile` · `Get-MpComputerStatus` · `Get-LapsADPassword`
Audit	`lynis audit system` · PingCastle (healthcheck AD)