Pourquoi sécuriser dès l'installation ?

La sécurité d'un serveur se joue en grande partie au moment de l'installation. Ajouter le chiffrement disque après coup est techniquement possible mais pénible. Le durcissement SSH peut se faire après, mais autant le faire bien dès le départ.

Dans l'article précédent, j'ai montré comment réinitialiser un mot de passe root en bootant en mode single-user via GRUB. C'est une procédure utile quand on a perdu l'accès — mais elle illustre aussi un danger réel : n'importe qui ayant accès à la console peut devenir root en 5 minutes sur un serveur sans chiffrement disque.

🔓
Le scénario d'attaque réel : un technicien du datacenter, un admin ESXi malveillant, ou quelqu'un avec accès à l'IPMI peut booter votre serveur en mode single-user, récupérer tous vos fichiers, modifier votre SSH, ajouter une backdoor — sans laisser de trace. Le chiffrement disque LUKS rend cette attaque impossible sans la passphrase.

Le chiffrement disque LUKS : l'étape clé

LUKS (Linux Unified Key Setup) est le standard de chiffrement disque sous Linux. Activé pendant l'installation Debian, il chiffre l'intégralité du LVM (volumes logiques) avec AES-256. Au démarrage, le système demande la passphrase avant de monter quoi que ce soit — y compris avant de lancer init.

💡
Sur un serveur avec LUKS, passer init=/bin/bash dans GRUB ne donne pas de shell — le système demande la passphrase LUKS. Sans elle : écran noir. C'est exactement ce qu'on veut.

Activer LUKS pendant l'installation Debian

Au moment du partitionnement, choisir « Assisté — utiliser un disque entier avec LVM chiffré ». L'installeur configure automatiquement LUKS + LVM.

Debian GNU/Linux — Installer — Partitionner les disques
Méthode de partitionnement :

Assisté - utiliser un disque entier
Assisté - utiliser un disque entier avec LVM chiffré
Assisté - utiliser un disque entier avec LVM
Manuel

L'effacement du disque : vous pouvez annuler sans risque

Juste après avoir choisi le chiffrement, l'installeur propose d'effacer le disque — c'est-à-dire écrire des données aléatoires sur l'intégralité du disque avant de le chiffrer. L'installeur affiche une barre de progression qui peut prendre des heures sur un grand disque.

Debian GNU/Linux — Installer — Effacement des données sur sda
Effacement des données sur sda en cours...

34%

Durée estimée : 3h 42min

<Annuler>
ℹ️
Vous pouvez cliquer sur Annuler sans aucun risque.
Cet effacement sert uniquement à masquer les anciennes données qui étaient sur le disque avant l'installation — pour empêcher leur récupération forensique. Il n'a aucun impact sur le chiffrement lui-même : que vous annuliez ou non, LUKS sera actif et toutes les données écrites à partir de l'installation seront chiffrées. Sur un disque neuf ou un VPS fraîchement commandé, il est inutile — annulez-le.

La passphrase LUKS : la sauvegarder avant tout

L'installeur demande ensuite la passphrase LUKS. C'est le secret le plus critique du serveur : sans elle, le disque est un bloc de données illisibles. Si vous la perdez, vos données sont définitivement inaccessibles — même avec un accès root.

⚠️
Discipline absolue : sauvegardez la passphrase LUKS dans KeePassXC immédiatement, avant même de terminer l'installation. Pas après. Pas dans 5 minutes. Maintenant.
La perdre = perdre l'accès à toutes vos données, sans recours possible.
Debian Installer — Passphrase LUKS
Phrase secrète de chiffrement :
_

# Utilisez un mot de passe long et unique — 30 caractères minimum
# Exemple de génération :
$ python3 -c "import secrets,string; print(''.join(secrets.choice(string.ascii_letters+string.digits+'{$%&@^~<>*+!?#_=-') for _ in range(32)))"
K7#mP&zR2xWqL@8nT$vB3jH9cYdFw!eA5o
# → 192 bits d'entropie. Sauvegardez dans KeePass AVANT de continuer.

Après l'installation : durcissement du système

Le chiffrement disque est en place. Voici les étapes post-installation pour fermer les autres vecteurs d'attaque.

1

Créer un utilisateur sudo — ne jamais utiliser root en direct

Le compte root ne devrait jamais servir à se connecter en SSH. On crée un utilisateur avec droits sudo, et on désactive la connexion SSH root.

Bash — post-install
root@srv# apt install sudo -y
root@srv# adduser hisham
root@srv# usermod -aG sudo hisham
# L'utilisateur hisham peut maintenant exécuter sudo
2

SSH : clé uniquement, pas de mot de passe

L'authentification par mot de passe SSH est le vecteur de brute-force le plus courant. On bascule en clé Ed25519 et on désactive tout le reste.

Machine locale — générer la clé SSH
$ ssh-keygen -t ed25519 -C "hisham@srv-web" -f ~/.ssh/srv_web_ed25519
Generating public/private ed25519 key pair.
Your identification has been saved in ~/.ssh/srv_web_ed25519
$ ssh-copy-id -i ~/.ssh/srv_web_ed25519.pub -p 41532 hisham@192.168.1.102
Number of key(s) added: 1
/etc/ssh/sshd_config — durcissement
# Changer le port par défaut (réduit le bruit dans les logs)
Port 41532

# Interdire la connexion root en SSH
PermitRootLogin no

# Clés uniquement — pas de mot de passe
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM no

# Désactiver X11 forwarding (inutile sur un serveur)
X11Forwarding no

root@srv# systemctl restart sshd
⚠️
Testez la connexion SSH avec la clé dans une autre fenêtre avant de fermer la session courante. Si vous avez fait une erreur dans sshd_config, vous aurez encore la session ouverte pour la corriger.
3

Firewall UFW : n'autoriser que ce qui est nécessaire

Par défaut, bloquer tout le trafic entrant sauf SSH et les services exposés.

Bash — UFW
root@srv# apt install ufw -y
root@srv# ufw default deny incoming
root@srv# ufw default allow outgoing
root@srv# ufw allow 41532/tcp comment 'SSH'
root@srv# ufw allow 80/tcp comment 'HTTP'
root@srv# ufw allow 443/tcp comment 'HTTPS'
root@srv# ufw enable
Firewall is active and enabled on system startup
root@srv# ufw status verbose
Status: active
To Action From
41532/tcp ALLOW IN Anywhere
80/tcp ALLOW IN Anywhere
443/tcp ALLOW IN Anywhere
4

fail2ban : bloquer les brute-forces automatiquement

fail2ban surveille les logs SSH et bannit automatiquement les IPs qui accumulent des échecs d'authentification.

Bash — fail2ban
root@srv# apt install fail2ban -y
root@srv# cat /etc/fail2ban/jail.local
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port = 41532
logpath = %(sshd_log)s
backend = %(syslog_backend)s

root@srv# systemctl enable --now fail2ban
root@srv# fail2ban-client status sshd
|- Filter
| |- Currently banned: 0
5

Mises à jour de sécurité automatiques

Les failles critiques sont souvent exploitées dans les heures suivant leur publication. Automatiser les mises à jour de sécurité réduit drastiquement la fenêtre de vulnérabilité.

Bash — unattended-upgrades
root@srv# apt install unattended-upgrades apt-listchanges -y
root@srv# dpkg-reconfigure -plow unattended-upgrades
# Répondre "Oui" → active les mises à jour auto de sécurité

# Vérifier la config :
root@srv# cat /etc/apt/apt.conf.d/50unattended-upgrades | grep -v '^//' | grep -v '^$'
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};

Vérification finale

Avant de mettre le serveur en production, voici le checklist rapide :

Bash — checklist sécurité
# 1. LUKS actif ?
root@srv# lsblk -f | grep -E 'crypto|LUKS'
sda5 crypto_LUKS 2 ...

# 2. SSH : PasswordAuthentication désactivé ?
root@srv# sshd -T | grep -E 'passwordauth|permitroot'
passwordauthentication no
permitrootlogin no

# 3. UFW actif ?
root@srv# ufw status | head -3
Status: active

# 4. fail2ban actif ?
root@srv# fail2ban-client status | grep 'Jail list'
Jail list: sshd

Ce que le chiffrement LUKS change concrètement

Pour être très concret : voici ce qu'un attaquant peut faire selon la configuration du serveur.

Scénario Sans LUKS Avec LUKS
Boot GRUB + init=/bin/bash Shell root immédiat Demande passphrase LUKS
Retrait du disque dur Données lisibles en clair Données illisibles (AES-256)
Boot sur clé USB externe Accès total aux fichiers Blobs chiffrés uniquement
Snapshot VMware volé Disque virtuel lisible Données illisibles
🛡️
La passphrase LUKS ne remplace pas le mot de passe root — ce sont deux protections complémentaires. LUKS protège contre l'accès physique. Le mot de passe root (et SSH key-only) protège contre les accès réseau. Les deux ensemble donnent une défense en profondeur.