secure-os.org

Durcissement Linux en 2026 : le guide threat-model-first

published 12 juin 2026 · #linux #durcissement #sysctl #apparmor

Terminal montrant les paramètres sysctl de durcissement et le statut AppArmor sur fond sombre

La plupart des guides de durcissement Linux sont des listes de contrôle. Ils vous disent quels paramètres sysctl définir, quels services désactiver, quels modules noyau mettre en liste noire. Ils répondent rarement à la question préalable : contre quelle menace vous défendez-vous réellement ?

La réponse change le travail. Un journaliste qui protège ses sources contre des malwares ciblés a besoin de mesures très différentes d’un administrateur système qui réduit la surface d’attaque sur un serveur sans menaces physiques. Ce guide va du modèle de menace aux mesures, pas l’inverse.


Étape zéro : définir votre modèle de menace

Avant de toucher un seul fichier de configuration, répondez à ces quatre questions :

  1. Qui est l’adversaire ? Opportuniste, criminel organisé, enquêteur d’entreprise, État-nation ?
  2. Qu’est-ce qu’il cherche ? Fichiers sur disque, communications, identifiants, votre identité, vos contacts ?
  3. Comment va-t-il s’introduire ? Exploit réseau, accès physique, chaîne d’approvisionnement, ingénierie sociale ?
  4. Quelles ressources a-t-il ? Temps, argent, zero-days, autorité légale ?

Durcissement noyau : paramètres sysctl

Les paramètres suivants sont appropriés pour la plupart des installations de bureau et serveur durcies. Ils ne nécessitent pas de matériel spécialisé et n’ont pas d’impact significatif sur les performances.

# /etc/sysctl.d/99-hardening.conf

# Restreindre les pointeurs noyau depuis l'espace utilisateur
kernel.kptr_restrict=2

# Restreindre l'accès à dmesg (prévient la lecture d'adresses mémoire noyau)
kernel.dmesg_restrict=1

# Désactiver la touche SysRq (prévient certaines attaques d'accès physique)
kernel.sysrq=0

# Restreindre ptrace aux processus avec CAP_SYS_PTRACE
kernel.yama.ptrace_scope=2

# Désactiver les espaces de noms utilisateur non privilégiés
kernel.unprivileged_userns_clone=0

# Désactiver eBPF non privilégié (surface d'attaque significative)
kernel.unprivileged_bpf_disabled=1

# Activer les cookies SYN TCP
net.ipv4.tcp_syncookies=1

# Désactiver les redirections ICMP
net.ipv4.conf.all.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0

# Activer le filtrage de chemin inverse
net.ipv4.conf.all.rp_filter=1

# Désactiver les core dumps
fs.suid_dumpable=0

# Restreindre le suivi des liens symboliques et physiques
fs.protected_symlinks=1
fs.protected_hardlinks=1

Appliquer immédiatement sans redémarrage :

sudo sysctl -p /etc/sysctl.d/99-hardening.conf

Contrôle d’accès obligatoire : AppArmor vs SELinux

AppArmor (Ubuntu, Debian, SUSE par défaut) utilise des profils basés sur les chemins. Chaque application reçoit un profil qui spécifie quels fichiers elle peut lire, écrire ou exécuter.

# Vérifier le statut AppArmor
sudo apparmor_status

# Mettre un profil en mode enforce
sudo aa-enforce /etc/apparmor.d/usr.bin.firefox

# Installer des profils supplémentaires
sudo apt install apparmor-profiles apparmor-profiles-extra

SELinux (Fedora, RHEL par défaut) utilise des politiques basées sur les étiquettes. Plus granulaire qu’AppArmor mais nettement plus complexe à maintenir. Sur Fedora, vérifiez que SELinux est en mode Enforcing :

getenforce
# Doit afficher : Enforcing

Ne désactivez pas SELinux. En cas de refus, diagnostiquez avec ausearch -m avc -ts recent | audit2allow -a.


Paramètres de démarrage noyau

À ajouter dans GRUB_CMDLINE_LINUX de /etc/default/grub, puis sudo update-grub :

# Activer toutes les atténuations de vulnérabilités CPU
mitigations=auto

# Randomiser l'allocation des pages
page_alloc.shuffle=1

# Activer le verrouillage noyau (mode Integrity)
lockdown=integrity

# Forcer la signature des modules
module.sig_enforce=1

Durcissement des systèmes de fichiers et des services

Options de montage dans /etc/fstab

# /tmp : pas d'exécution, pas de fichiers de périphérique, pas de bits SUID
tmpfs /tmp tmpfs defaults,noexec,nodev,nosuid 0 0

# /home : pas de fichiers de périphérique, pas de SUID
/dev/mapper/home /home ext4 defaults,nodev,nosuid 0 2

Désactiver les services inutilisés

# Services courants à désactiver sur un bureau sans serveur réseau
sudo systemctl disable cups avahi-daemon bluetooth

Liste de contrôle par modèle de menace

Opportuniste / malware de masse : paramètres sysctl ci-dessus, AppArmor/SELinux en enforce, disque chiffré (LUKS), mises à jour régulières.

Attaquant ciblé avec accès réseau : ajoutez la minimisation des services, un pare-feu restrictif (nftables/ufw), le sandboxing des applications, la surveillance des sorties réseau.

Adversaire avec accès physique : chiffrement complet du disque avec phrase de passe robuste + sauvegarde d’en-tête, Secure Boot avec clés personnalisées, Tails OS pour les opérations sensibles, considérez Qubes OS pour la compartimentation. Consultez la charte Secure Desktops.


FAQ

Q : Désactiver les espaces de noms utilisateur non privilégiés casse-t-il des applications ? R : Oui — notamment le sandboxing Chromium sur certains systèmes et certains environnements d’exécution de conteneurs (Docker/Podman rootless). Sur desktop Ubuntu/Debian, vous devrez probablement réactiver pour Chromium.

Q : Faut-il utiliser un noyau durci (linux-hardened sous Arch) ? R : linux-hardened sous Arch Linux applique un ensemble raisonnable de correctifs de durcissement et vaut la peine d’être utilisé sur Arch. Le noyau en amont a absorbé beaucoup de fonctionnalités anciennement exclusives à grsecurity (KASLR, stack protector, FORTIFY_SOURCE).

Q : Fedora ou Ubuntu est-il plus durci par défaut ? R : Les deux incluent MAC en mode enforce (SELinux sur Fedora, AppArmor sur Ubuntu), des valeurs par défaut modernes pour les atténuations noyau et des mises à jour de sécurité automatiques. Fedora livre généralement les versions noyau plus rapidement. Pour un poste durci, les deux sont un bon point de départ.