Sécurité du démarrage : GRUB, LUKS, Secure Boot

Dès qu'un attaquant atteint la console ou détient votre disque éteint, la plupart des contrôles logiciels configurés pour le système en marche cessent de s'appliquer. Les permissions de fichiers, la politique sudo et SELinux sont appliquées par un noyau que l'attaquant peut remplacer ou contourner. La sécurité du démarrage et la sécurité physique constituent la couche qui décide qui est autorisé à lancer ce noyau, et si les octets sur le plateau ont un sens pour un voleur. Cet article couvre le chargeur GRUB, le chiffrement intégral LUKS, Secure Boot, ainsi que les réglages firmware et console qui referment les dernières brèches.

Le modèle de menace

L'accès physique et console met en échec la plupart du durcissement à l'exécution. Un attaquant au clavier peut interrompre GRUB, ajouter init=/bin/bash ou rd.break à la ligne de commande du noyau et obtenir un shell root sans aucun mot de passe. Un disque volé peut être monté en lecture-écriture sur une autre machine, exposant chaque fichier non chiffré quels que soient ses bits de mode — voir filesystem-permissions pour comprendre pourquoi les permissions seules ne sont pas un contrôle de confidentialité. Les entrées de démarrage mono-utilisateur et de récupération sont conçues pour accorder un root non authentifié à des fins de réparation, ce qui est exactement ce que cherche un attaquant. Le scénario evil-maid est plus subtil : un bref moment sans surveillance permet à quelqu'un d'altérer /boot ou le chargeur pour capturer votre phrase secrète au prochain démarrage. Aucune configuration interne au système n'arrête cela une fois que l'attaquant contrôle la chaîne de démarrage ; les contrôles ci-dessous agissent donc avant et autour du noyau.

Protéger GRUB par mot de passe

Générez un mot de passe haché et définissez un superutilisateur afin que l'édition du menu et les entrées de récupération exigent une authentification, tandis que le démarrage normal reste sans surveillance.

grub-mkpasswd-pbkdf2
# copiez la chaîne grub.pbkdf2.sha512.<...> obtenue

Ajoutez un bloc superutilisateur à /etc/grub.d/40_custom :

cat <<'EOF' | sudo tee -a /etc/grub.d/40_custom
set superusers="admin"
password_pbkdf2 admin grub.pbkdf2.sha512.10000.AB12...CD34
EOF

Par défaut, cela verrouille chaque entrée du menu. Pour que la machine puisse tout de même démarrer le noyau par défaut sans mot de passe — en ne protégeant que l'édition et la récupération — marquez les entrées normales --unrestricted. Sous Debian/Ubuntu, il s'agit de la ligne CLASS dans /etc/grub.d/10_linux ; les actions d'édition (e) et de ligne de commande (c) restent réservées au superutilisateur. Régénérez la configuration avec le chemin propre à votre distribution :

# Debian / Ubuntu
sudo update-grub

# RHEL / Fedora / openSUSE (BIOS)
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
# RHEL UEFI : /boot/efi/EFI/<distro>/grub.cfg

Chiffrer le disque avec LUKS

LUKS chiffre un périphérique bloc, rendant un disque volé ou copié illisible sans la phrase secrète. L'approche la plus propre est d'activer le chiffrement dans l'installeur, qui met en place le conteneur LUKS, l'invite de déverrouillage et /etc/crypttab pour vous. Pour chiffrer un périphérique supplémentaire après coup :

sudo cryptsetup luksFormat /dev/sdb1
sudo cryptsetup luksOpen /dev/sdb1 cryptdata
sudo mkfs.ext4 /dev/mapper/cryptdata

Persistez le mappage pour qu'il se déverrouille au démarrage via /etc/crypttab, puis référencez /dev/mapper/cryptdata dans /etc/fstab :

# <nom>      <périphérique>                    <clé>  <options>
cryptdata  UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxx  none   luks

Chiffrez toujours le swap également : sinon, des pages de mémoire, y compris des clés et des données déchiffrées, y sont écrites en clair. Utilisez une clé aléatoire dans crypttab pour que le swap soit re-chiffré à chaque démarrage :

cryptswap  /dev/sdc1  /dev/urandom  swap,cipher=aes-xts-plain64,size=256

Secure Boot et le noyau

Secure Boot fait vérifier par le firmware UEFI la signature du chargeur (shim), de GRUB et du noyau face aux clés de la base db de la plateforme, refusant tout élément non signé ou altéré. Les noyaux et le shim des distributions sont livrés pré-signés. Vérifiez l'état actuel :

mokutil --sb-state          # attendu : SecureBoot enabled
bootctl status | grep -i secure

Secure Boot se combine au mode lockdown du noyau, automatiquement activé en mode integrity lorsque Secure Boot est actif, interdisant même à root de charger des modules non signés ou de lire la mémoire du noyau. Poursuivez avec kernel-hardening, et veillez à verrouiller les comptes de démarrage selon accounts-privileges.

Réglages firmware et console

Définissez un mot de passe superviseur BIOS/UEFI et désactivez le démarrage depuis USB, CD et réseau dans le firmware, afin qu'un attaquant ne puisse pas contourner votre disque chiffré en démarrant son propre support. Enfin, empêchez un utilisateur en console de déclencher un redémarrage incontrôlé :

sudo systemctl mask ctrl-alt-del.target

Vérifier

Confirmez que chaque contrôle est réellement en vigueur :

sudo grep -E 'superusers|password_pbkdf2' /boot/grub*/grub.cfg
sudo cryptsetup status cryptdata
mokutil --sb-state
systemctl is-enabled ctrl-alt-del.target   # attendu : masked

Si GRUB demande des identifiants à l'édition, que le périphérique LUKS apparaît actif, que Secure Boot est activé et que Ctrl+Alt+Del est masqué, la chaîne de démarrage est durcie de bout en bout.