Durcir le noyau Linux de son NAS selon les normes CIS Level 2

Au-delà du simple pare-feu

Un pare-feu, c'est bien. Fail2ban aussi. Mais honnêtement, c'est juste la surface. Le noyau Linux lui-même, avec tous ses paramètres par défaut trop permissifs, ses modules inutiles qui traînent en mémoire, ses points de montage sans restrictions - c'est une vraie passoire si on ne fait rien. Et ces vecteurs d'attaque ? Ils sont tous bien documentés, répertoriés, exploitables.

Sur mon TerraMaster F4-424 sous Debian 13 (Trixie), j'ai décidé de vraiment serrer les vis. Pas juste taper quelques commandes, mais suivre un vrai benchmark. Les CIS benchmarks (Center for Internet Security) - c'est l'industrie qui en parle, c'est ce qu'on utilise. Ils proposent deux niveaux : Level 1 pour les serveurs normaux, Level 2 pour les vraiment paranoid (ou les data centers). Un NAS qui stocke les photos de famille, c'est le Level 2. Point.

La collection devsec.hardening

J'aurais pu passer ma soirée à appliquer manuellement plus de 200 recommandations CIS. Oui. Au lieu de ça, j'utilise la collection Ansible devsec.hardening. C'est déjà fait. C'est maintenu. La communauté l'a validé.

Le truc intéressant : j'ai organisé tout ça en rôles CIS spécialisés - cis_permissions, cis_accounts, cis_cron, cis_sudo, cis_tcpwrappers, cis_logging, cis_services, cis_ntp. Chacun taggé, chacun indépendant. Besoin de n'exécuter que le logging ? Une commande Ansible, et c'est fait.

Plus de 40 paramètres sysctl à la main

Le fichier /etc/sysctl.d/99-hardening.conf concentre l'essentiel. Pas juste deux ou trois trucs, mais vraiment tout. Voici ce qui compte vraiment :

Protections mémoire et noyau

# Désactiver io_uring (vecteur d'attaque fréquent)
kernel.io_uring_disabled = 2

# Interdire le chargement dynamique de noyaux (kexec)
kernel.kexec_load_disabled = 1

# ASLR complet (randomisation de l'espace d'adressage)
kernel.randomize_va_space = 2

# Restreindre l'accès aux pointeurs noyau dans les logs
kernel.kptr_restrict = 2

# Restreindre dmesg aux utilisateurs root
kernel.dmesg_restrict = 1

# Interdire les core dumps pour les programmes SUID
fs.suid_dumpable = 0

# Restreindre l'accès aux événements perf
kernel.perf_event_paranoid = 3

# Désactiver les vsyscalls (vecteur ROP)
# (configuré via GRUB: vsyscall=none)

Protections réseau

# Reverse path filtering (anti-spoofing)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignorer les redirections ICMP
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Ignorer les requêtes ICMP broadcast
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Protection contre les SYN flood
net.ipv4.tcp_syncookies = 1

# Interdire le routage source
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Désactiver le forwarding IPv6 (le NAS n'est pas un routeur)
net.ipv6.conf.all.forwarding = 0

# Logging des paquets martiens
net.ipv4.conf.all.log_martians = 1

Au total ? Quarante-quelque paramètres. Chacun a une raison d'être, chacun ferme quelque chose. Pas de "au cas où", pas de "j'ai lu que c'était bien". Chacun est documenté dans le benchmark CIS.

GRUB : les paramètres de boot

Certains durcissements doivent être appliqués au démarrage même, au moment où le noyau se charge. C'est la ligne GRUB :

GRUB_CMDLINE_LINUX="slab_nomerge pti=on randomize_kstack_offset=on vsyscall=none debugfs=off"

• slab_nomerge : empêche la fusion des caches slab (limitation des attaques par confusion de types)
• pti=on : Page Table Isolation, la mitigation contre Spectre et Meltdown
• randomize_kstack_offset : la pile noyau est randomisée à chaque syscall
• vsyscall=none : kills les vsyscalls, élimine un gadget ROP connu
• debugfs=off : ferme le filesystem de debug du kernel

Ce truc de slab_nomerge m'a surprise la première fois. C'est spécifique aux attaques modernes, mais une fois que tu comprends ce que ça fait (empêcher de fusionner des structures mémoire différentes), c'est évident.

Blacklister les modules inutiles

Des modules du kernel qu'on ne va jamais utiliser mais qui sont potentiellement exploitables ? Blacklistons-les. C'est dans /etc/modprobe.d/hardening.conf :

# Systèmes de fichiers exotiques
install cramfs /bin/true
install freevxfs /bin/true
install jffs2 /bin/true
install hfs /bin/true
install hfsplus /bin/true
install squashfs /bin/true
install udf /bin/true

# Protocoles réseau rarement utilisés
install dccp /bin/true
install sctp /bin/true
install rds /bin/true
install tipc /bin/true

# USB storage (désactivé sur un NAS headless)
install usb-storage /bin/true

L'astuce install <module> /bin/true ? C'est plus propre qu'un simple blacklist. Pourquoi ? Parce qu'un blacklist peut être contourné par des dépendances, tandis que "installe /bin/true" veut dire "fais rien, silencieusement, et c'est bon". J'ai découvert ça en essayant de blacklister squashfs, qui se chargeait quand même. Une fois le /bin/true en place, terminé.

Durcissement des points de montage

Les points de montage sensibles reçoivent des options restrictives dans /etc/fstab :

tmpfs  /tmp      tmpfs  defaults,noexec,nosuid,nodev  0 0
tmpfs  /dev/shm  tmpfs  defaults,noexec,nosuid,nodev  0 0

• noexec : zéro binaire ne peut s'exécuter (l'attaquant ne peut pas déposer son truc et le lancer)
• nosuid : oublie les bits SUID/SGID
• nodev : création de fichiers device interdite

Pour /proc, on ajoute hidepid=2 qui empêche les utilisateurs lambda de voir les processus des autres :

proc  /proc  proc  defaults,hidepid=2  0 0

J'ai testé ça en enlevant hidepid=2 pendant une semaine. C'est étonnant ce qu'on peut apprendre sur la machine juste en regardant /proc. Bon, réactivé.

AppArmor en mode enforce

AppArmor fournit du MAC (Mandatory Access Control). Même si un processus se fait compromettre, il ne peut toucher qu'à ce que son profil autorise. Sur Debian 13, AppArmor est activé par défaut mais souvent en mode "complain" (juste logger). Le hardening le passe en enforce :

aa-enforce /etc/apparmor.d/*

C'est un changement mineur, juste une commande. Mais c'est la différence entre "on sait ce qui s'est passé" et "on empêche que ça se passe".

Les politiques de mots de passe (NIST SP 800-63B)

Les recommandations NIST, pas au pif :

# /etc/security/pwquality.conf
minlen = 15          # 15 caractères minimum
minclass = 3         # Au moins 3 classes de caractères
maxrepeat = 3        # Max 3 caractères identiques consécutifs

# /etc/login.defs
PASS_MAX_DAYS  365   # Expiration à 365 jours
PASS_MIN_DAYS  1     # 1 jour minimum entre les changements
LOGIN_RETRIES  3     # 3 tentatives de login
LOGIN_TIMEOUT  60    # Timeout de 60 secondes
UMASK          077   # Permissions restrictives par défaut

Et le verrouillage de compte après 3 échecs avec un délai de 15 minutes via PAM (pam_faillock). Les core dumps ? Globalement désactivés dans /etc/security/limits.conf.

J'ai mis le timeout à 60 secondes. La première fois, 60 secondes c'est long. Après deux jours, on oublie qu'c'est là.

Mises à jour automatiques sans surprise

unattended-upgrades applique les correctifs de sécurité quotidiennement, avec un reboot automatique à 4h du matin si besoin :

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Un NAS non patché, c'est un NAS qui va être compromis un jour. J'ai choisi 4h. Personne n'est en train de regarder son Jellyfin à 4h du matin (du moins je l'espère pour vous). C'est un compromis que tout le monde vit mal les deux premières semaines, puis on oublie.

AIDE : surveiller l'intégrité des fichiers

AIDE (Advanced Intrusion Detection Environment) : tu lui dis "voici ma baseline", puis il cherche qui a touché à quoi. Des logs exécutoires. Après 3 mois, ça détecte un changement anormal avant même que l'attaquant se rende compte qu'il a laissé des traces.

# Initialisation de la base
aide --init
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Vérification quotidienne (via cron)
aide --check

Si un binaire système change sans raison - et il y a peu de bonnes raisons - AIDE le voit.

Audit logging avec auditd

auditd traçe les événements de sécurité. Plus de 40 règles :

# /etc/audit/rules.d/hardening.rules

# Surveillance des changements d'authentification
-w /etc/passwd -p wa -k auth_changes
-w /etc/shadow -p wa -k auth_changes
-w /etc/group -p wa -k auth_changes

# Surveillance de sudo
-w /etc/sudoers -p wa -k sudo_changes
-w /etc/sudoers.d/ -p wa -k sudo_changes

# Chargement de modules noyau
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

# Changements réseau
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k network

# Surveillance des packages
-w /usr/bin/dpkg -p x -k packages
-w /usr/bin/apt -p x -k packages

# Surveillance de systemd
-w /etc/systemd/ -p wa -k systemd
-w /usr/lib/systemd/ -p wa -k systemd

Ces logs ? Essentiels pour après. Qui a fait quoi, quand, avec quel outil. C'est pas pour l'examen, c'est pour dire "OK, à 14h27 quelqu'un a modifié sudoers et changé le hostname". Bon, à partir de là tu investigues.

Ce qu'il faut retenir

CIS Level 2 sur un NAS domestique ? Ça peut sembler paranoid. Mais voilà le truc : chaque paramètre ferme quelque chose de réel, de documenté. Ce n'est pas du folklore de forum. Grâce à la collection devsec.hardening et aux rôles Ansible, ça s'applique en une commande et ça se maintient sans effort. Le vrai travail, c'est comprendre ce que chaque règle fait. C'est pas "appliquer un benchmark", c'est vraiment connaître sa machine. Et c'est ce qui change tout.