Chiffrer et durcir un serveur Debian dès l'installation : LUKS, SSH par clés, pare-feu.

01 — La menace oubliéeUn serveur non chiffré se prend par la console, pas par le réseau

Quand on parle de sécuriser un serveur, on pense pare-feu, mots de passe, mises à jour. On pense rarement à la menace la plus directe : l'accès physique ou console. Or les systèmes Linux embarquent, par conception, un mode de maintenance qui donne un shell root sans mot de passe à qui peut interrompre le démarrage — nous détaillons cette procédure, légitime quand on a perdu ses accès, dans notre article sur la reprise d'un accès root perdu.

Concrètement, sont concernés : un serveur dans une baie partagée, une machine virtuelle dont l'hyperviseur est administré par un tiers, un dédié avec console IPMI ou KVM-over-IP, un VPS dont l'hébergeur propose une console web. Dans tous ces cas, une personne disposant de cet accès peut démarrer la machine sur un shell, lire l'intégralité des fichiers, modifier la configuration SSH ou déposer ce qu'elle veut — sans journal, sans trace applicative.

La seule parade structurelle est le chiffrement complet du disque. Et contrairement au reste du durcissement, celui-ci se décide au moment de l'installation : convertir après coup un système en production vers un disque chiffré est une opération lourde, qui impose généralement une réinstallation ou une migration. D'où la règle que nous appliquons systématiquement : on n'installe pas un serveur sans chiffrement.

02 — Le chiffrementLUKS pendant l'installation : trois écrans décisifs

LUKS (Linux Unified Key Setup) est le format standard de chiffrement de disque sous Linux, géré par l'outil cryptsetup. Associé à LVM, il chiffre l'ensemble des volumes logiques du système. Au démarrage, la phrase secrète est demandée avant le montage des systèmes de fichiers — avant même le lancement du système d'initialisation. Tenter de contourner le démarrage normal ne mène donc nulle part : sans la phrase, il n'y a rien à lire.

Premier écran : le partitionnement

Dans l'installateur Debian, à l'étape du partitionnement, retenez « Assisté — utiliser un disque entier avec LVM chiffré ». L'installateur met en place la pile complète (partition chiffrée LUKS, groupe de volumes LVM, volumes système et swap) sans intervention manuelle. Le guide d'installation Debian documente cette option.

Deuxième écran : l'effacement préalable, souvent inutile

Vient ensuite une étape qui déroute : l'installateur propose d'écrire des données aléatoires sur tout le disque, avec une barre de progression qui peut annoncer plusieurs heures. Cette passe sert uniquement à rendre irrécupérables les anciennes données présentes sur le disque avant l'installation. Elle ne conditionne en rien le chiffrement à venir : que vous la laissiez se terminer ou que vous l'annuliez, LUKS sera actif et tout ce qui sera écrit ensuite sera chiffré. Sur un disque neuf ou un volume de VM qui vient d'être créé, annulez-la sans hésiter.

Troisième écran : la phrase secrète

L'installateur demande enfin la phrase secrète de déchiffrement. C'est le secret le plus important de la machine : il conditionne l'accès à toutes les données, et sa perte est sans recours — la FAQ de cryptsetup le répète à l'envi. Visez une phrase longue (une trentaine de caractères), générée aléatoirement, et enregistrez-la dans votre gestionnaire de mots de passe avant de passer à l'écran suivant. Pas en fin d'installation : maintenant.

03 — Les accèsUn utilisateur sudo, et SSH verrouillé sur les clés

Le disque chiffré protège la machine éteinte ou devant sa console. Reste à protéger la machine allumée, c'est-à-dire ses accès réseau. Première étape après le premier démarrage : créer un compte d'administration nominatif et cesser d'utiliser root directement.

apt install sudo -y
adduser votre_admin
usermod -aG sudo votre_admin

Deuxième étape : basculer SSH sur l'authentification par clés et y interdire à la fois root et les mots de passe. Les tentatives de force brute sur SSH visent des mots de passe ; une clé Ed25519 les rend sans objet. Depuis votre poste :

ssh-keygen -t ed25519 -f ~/.ssh/srv_ed25519
ssh-copy-id -i ~/.ssh/srv_ed25519.pub votre_admin@adresse_du_serveur

Puis, côté serveur, dans /etc/ssh/sshd_config (les directives sont documentées dans sshd_config(5)) :

Port 52410                       # port non standard : moins de bruit dans les journaux
PermitRootLogin no               # root ne se connecte jamais en SSH
PasswordAuthentication no        # clés uniquement
KbdInteractiveAuthentication no
X11Forwarding no

Rechargez le service (systemctl restart sshd) — mais testez la connexion par clé dans un second terminal avant de fermer votre session en cours. Une erreur dans ce fichier verrouille la porte derrière vous ; tant que la première session reste ouverte, vous pouvez corriger.

04 — Le périmètrePare-feu, bannissement automatique, mises à jour sans intervention

UFW : tout refuser, puis ouvrir le strict nécessaire

La politique saine d'un pare-feu de serveur tient en deux règles par défaut : tout trafic entrant refusé, tout trafic sortant autorisé. On n'ouvre ensuite que les ports réellement servis :

apt install ufw -y
ufw default deny incoming
ufw default allow outgoing
ufw allow 52410/tcp comment 'SSH'
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'
ufw enable

Un ufw status verbose doit refléter exactement la liste des services que vous exposez volontairement — ni plus, ni moins. Chaque port ouvert « au cas où » est une surface d'attaque gratuite.

fail2ban : rendre la force brute inopérante

fail2ban lit les journaux d'authentification et bannit temporairement les adresses qui enchaînent les échecs. Même avec SSH en clés seules, il garde son utilité : il coupe court au bruit et protège les autres services qui s'ajouteront. Une configuration de départ dans /etc/fail2ban/jail.local :

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port    = 52410

Puis systemctl enable --now fail2ban. Un détail qui a son importance si le serveur héberge des sites : fail2ban doit bannir les comportements d'attaque, jamais le simple débit de requêtes — sous peine de bannir aussi les robots d'indexation légitimes.

Les mises à jour de sécurité, sans attendre personne

Les vulnérabilités publiées sont exploitées vite, parfois en quelques heures. Le paquet unattended-upgrades applique automatiquement les correctifs de sécurité Debian :

apt install unattended-upgrades apt-listchanges -y
dpkg-reconfigure -plow unattended-upgrades

Répondre « Oui » active l'origine -security. L'ANSSI, dans ses recommandations pour GNU/Linux, insiste sur la rapidité d'application des correctifs comme mesure de première ligne — l'automatisation est le moyen le plus fiable de la garantir.

05 — Le contrôleVérifier avant la mise en production

Quatre commandes suffisent à confirmer que les protections sont bien effectives, et non simplement configurées :

lsblk -f | grep -E 'crypto|LUKS'          # le chiffrement est actif
sshd -T | grep -E 'passwordauth|permitroot'  # no / no attendus
ufw status | head -3                       # Status: active
fail2ban-client status | grep 'Jail list'   # sshd présent

Et pour mesurer ce que le chiffrement change réellement, le tableau parle de lui-même :

Dernier rappel : LUKS et le durcissement réseau ne se substituent pas l'un à l'autre. Le chiffrement répond à l'accès physique, les clés SSH et le pare-feu répondent à l'accès distant ; c'est leur cumul qui constitue une défense en profondeur. Pour la suite du durcissement côté applicatif (en-têtes, TLS, sauvegardes), voyez notre article sur la sécurisation d'un site internet ; et si vous hébergez vos propres machines virtuelles, celui sur l'auto-hébergement ESXi/Proxmox complète le tableau.

Questions fréquentes