B3-11 Durcir les serveurs Linux et Windows

1. La surface d'attaque d'un serveur

Un attaquant ne peut exploiter que ce qui existe : un service qui écoute sur le réseau, un compte qui peut se connecter, un logiciel installé mais jamais mis à jour. L'ensemble de ces points d'entrée forme la surface d'attaque. Plus elle est grande, plus il y a de chances qu'une faille y soit présente.

Le durcissement ne concerne pas que le réseau. La surface d'attaque comprend aussi :

2. Les principes et les référentiels

Durcir ne s'improvise pas : on suit des principes simples et un référentiel reconnu, qui liste les réglages à appliquer et permet de justifier ses choix devant un responsable ou un jury.

• Moindre serviceN'installer et n'activer que ce qui est nécessaire au rôle du serveur. Un serveur web n'a pas besoin d'interface graphique, d'imprimante partagée ni de serveur de messagerie.
• Moindre privilègeChaque compte, chaque service n'a que les droits dont il a besoin. On administre avec un compte nominatif qui élève ses droits ponctuellement (sudo, compte d'administration séparé), jamais en session root permanente.
• Défense en profondeurPlusieurs barrières indépendantes : pare-feu réseau, pare-feu local, authentification forte, mises à jour, journalisation. Si l'une cède, les autres tiennent encore.
• TraçabilitéTout accès et toute action d'administration laissent une trace horodatée, conservée hors du serveur : sans traces, impossible de comprendre une attaque.

2.1 Les référentiels à connaître

3. Debian : mises à jour, services et comptes

Sur Debian, le durcissement commence toujours par trois chantiers : garder le système à jour sans dépendre d'une intervention humaine, retirer ce qui ne sert pas, et organiser les comptes pour que personne ne travaille en root.

3.1 Les mises à jour de sécurité automatiques

La plupart des attaques réussies exploitent une faille déjà corrigée par l'éditeur, mais pas encore installée. Le paquet unattended-upgrades installe chaque jour, sans intervention, les mises à jour de la branche sécurité de Debian.

3.2 Moindre service : retirer le superflu

1. Lister ce qui écoute : sudo ss -tlnp (TCP) et sudo ss -ulnp (UDP). Chaque ligne doit être justifiée par le rôle du serveur.
2. Lister les services actifs : systemctl list-units --type=service --state=running.
3. Supprimer ce qui ne sert pas (sudo apt purge rpcbind) ou, à défaut, l'arrêter et l'empêcher de redémarrer (sudo systemctl disable --now cups).
4. Restreindre l'écoute des services locaux : une base de données utilisée par le serveur lui-même écoute sur 127.0.0.1 seulement.

3.3 Les comptes et sudo

On administre avec un compte nominatif (adm-lmartin) membre du groupe sudo, et on laisse le compte root sans connexion directe. Chaque commande passée avec sudo est journalisée avec le nom de son auteur : la traçabilité est assurée.

4. Durcir SSH et bloquer la force brute

SSH est la porte d'administration des serveurs Linux : elle est scannée en permanence par des robots qui essaient des milliers de couples identifiant/mot de passe. Trois mesures la rendent quasiment imprenable : l'authentification par clé, l'interdiction de root et le bannissement automatique des adresses qui insistent.

4.1 L'authentification par clé

Avec une paire de clés, le serveur envoie un défi que seule la clé privée de l'administrateur peut signer. Aucun mot de passe ne circule, et deviner une clé ed25519 est hors de portée.

Depuis un poste Linux, la copie se fait en une commande : ssh-copy-id adm-lmartin@172.16.50.11.

4.2 La configuration du serveur SSH

On ne modifie pas le fichier principal : on ajoute un fichier dans /etc/ssh/sshd_config.d/, lu en premier. Ainsi, une mise à jour du paquet ne remplace pas nos réglages.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowGroups ssh-admins
X11Forwarding no

• PermitRootLogin noLe compte root, que tous les robots essaient en premier, ne peut plus se connecter en SSH.
• PasswordAuthentication noPlus aucune connexion par mot de passe : seules les clés sont acceptées, la force brute devient inutile. KbdInteractiveAuthentication no ferme la variante « clavier interactif ».
• MaxAuthTries 3 · LoginGraceTime 30Trois essais par connexion et 30 secondes pour s'authentifier : les tentatives coûtent plus cher à l'attaquant.
• AllowGroups ssh-adminsSeuls les membres de ce groupe peuvent ouvrir une session SSH, même si d'autres comptes existent sur le serveur.

4.3 Fail2ban : bannir ceux qui insistent

Fail2ban lit les journaux, compte les échecs d'authentification par adresse IP et, au-delà d'un seuil, ajoute une règle de pare-feu qui bloque cette adresse pendant un temps donné.

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 3
ignoreip = 127.0.0.1/8 172.16.99.0/24

[sshd]
enabled = true
backend = systemd

5. Le pare-feu local du serveur

Le pare-feu réseau (pfSense, fiche B3-09) filtre entre les zones. Le pare-feu local protège le serveur lui-même, y compris contre une machine compromise du même VLAN : c'est une enceinte de plus. Sur Debian, UFW (Uncomplicated Firewall) écrit les règles du noyau (nftables) avec une syntaxe simple.

La politique de base est toujours la même : tout refuser en entrée, puis ouvrir uniquement ce qui sert, au plus près de qui en a besoin.

6. Durcir Windows Server

Les principes sont identiques, les outils changent. Sur un contrôleur de domaine comme SRV-01, le durcissement protège aussi tout l'Active Directory : un attaquant qui le compromet devient maître de tous les postes et de tous les comptes.

7. Mesurer le résultat et surveiller

Un durcissement qui ne se mesure pas ne se pilote pas. On utilise des outils d'audit avant et après les réglages, puis on surveille les journaux pour repérer une attaque ou un retour en arrière.

7.1 Les outils d'audit

7.2 Les événements de sécurité à surveiller

8. Vérifier et dépanner

Un durcissement mal appliqué a deux conséquences : il bloque les administrateurs (le cas le plus fréquent) ou il ne protège pas alors qu'on le croit actif. On vérifie donc toujours deux choses : l'accès légitime fonctionne, et l'accès illégitime échoue.

8.1 Entraîne-toi : les tickets du support

Tu es de permanence au support de Brocéliande Logistique pendant la semaine de durcissement. Six tickets arrivent : lis le message, observe le relevé, puis choisis la cause.

sudo ufw default deny incoming
sudo ufw allow 443/tcp
sudo ufw enable

$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/auth.log
$ ls /var/log/auth.log
ls: cannot access '/var/log/auth.log': No such file or directory

$ ls -ld /home/adm-lmartin/.ssh /home/adm-lmartin/.ssh/authorized_keys
drwxrwxrwx 2 adm-lmartin adm-lmartin 4096 .ssh
-rw-rw-rw- 1 adm-lmartin adm-lmartin  104 authorized_keys
$ journalctl -u ssh | tail -1
Authentication refused: bad ownership or modes for directory /home/adm-lmartin/.ssh

ID 4625  Échec d'ouverture de session d'un compte
  Nom du compte : Administrateur
  Type d'ouverture de session : 10 (RemoteInteractive)
  Adresse réseau source : 172.16.70.142

ID 4624  Ouverture de session réussie · svc-sauvegarde · 03:11
ID 1102  Le journal d'audit a été effacé · svc-sauvegarde · 03:12

PS> Get-LapsADPassword -Identity PC-PAIE
(aucun résultat)
PS> Get-ADComputer PC-PAIE | Select DistinguishedName
CN=PC-PAIE,CN=Computers,DC=broceliande,DC=lan

9. À l'examen et en entreprise

10. L'essentiel

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

Les commandes clés

Tout cela tient sur une page : utilise le bouton Mémo à imprimer en haut de la fiche.

11. Quiz noté

12. Exercices : à toi de répondre

Écris ta réponse sous chaque énoncé et envoie-la à ton professeur. Quand il l'a validée, le corrigé s'affiche à la place du cadenas ; s'il te la renvoie « à revoir », lis son commentaire et corrige.

LISTEN 0.0.0.0:22     users:(("sshd"))
LISTEN 0.0.0.0:443    users:(("nginx"))
LISTEN 0.0.0.0:3306   users:(("mariadbd"))
LISTEN 0.0.0.0:111    users:(("rpcbind"))
LISTEN 0.0.0.0:631    users:(("cupsd"))

13. Au labo : durcir SRV-LINUX et SRV-01, mesure à l'appui