sysctl : durcir le noyau et la pile réseau Linux

sysctl règle les paramètres du noyau Linux à chaud : comment la pile réseau traite les paquets, ce que le noyau expose aux processus, comment le système de fichiers se protège. Par défaut, plusieurs de ces réglages favorisent la compatibilité plutôt que la sécurité. Ce guide montre comment établir une baseline, appliquer un jeu de durcissement aligné sur les CIS Benchmarks et ANSSI-BP-028 v2.0 (recommandations R9 « options de configuration du noyau » et R12 « options de configuration du réseau ») de façon persistante, vérifier son effet, et éviter les pièges (un paramètre mal posé peut couper le réseau). Public visé : administrateurs qui durcissent un serveur exposé.

Ce que vous allez apprendre

• Lire et modifier un paramètre noyau (sysctl -n, -w, sysctl.d)
• Capturer une baseline avant de toucher quoi que ce soit
• Appliquer un jeu de durcissement réseau, noyau et fichiers, persistant au reboot
• Vérifier l'effet réel (et pourquoi certains réglages exigent une VM)
• Éviter les réglages qui cassent le routage ou un nœud Kubernetes

Qu'est-ce que sysctl

sysctl est l'interface qui lit et écrit les variables du noyau exposées sous /proc/sys/. Chaque variable a un nom hiérarchique (net.ipv4.ip_forward) qui correspond à un fichier (/proc/sys/net/ipv4/ip_forward).

Action	Commande	Persistance
Lire une valeur	sysctl -n net.ipv4.ip_forward	Sans objet
Modifier à chaud	sysctl -w net.ipv4.ip_forward=0	Perdu au reboot
Rendre persistant	Fichier dans /etc/sysctl.d/ + sysctl --system	Survit au reboot

Glissez pour voir

Pour le durcissement, on écrit toujours dans un fichier de /etc/sysctl.d/ : les modifications à la volée (-w) servent au test mais disparaissent au redémarrage.

Durcir le noyau suppose un vrai noyau

Les paramètres kernel.* et fs.* ne sont pas isolés par namespace : dans un conteneur non privilégié, ils sont en lecture seule. Seuls les paramètres net.* (isolés par l'espace de noms réseau) sont modifiables par conteneur. Pour durcir un noyau, travaillez sur une machine physique ou une VM. Ce guide se valide sur une VM.

Prérequis

• Un serveur Linux (Debian, Ubuntu, RHEL, AlmaLinux, Rocky) ou une VM
• Un accès root (ou sudo)
• Idéalement une VM de test : certains réglages réseau peuvent couper une connexion mal anticipée

Établir une baseline

Avant de durcir, mesurez l'existant. Les valeurs par défaut varient selon la distribution et la version, donc ne supposez rien.

for k in net.ipv4.conf.all.accept_redirects net.ipv4.conf.all.send_redirects \
         net.ipv4.conf.all.rp_filter net.ipv4.conf.all.log_martians \
         kernel.kptr_restrict kernel.yama.ptrace_scope; do
  printf "%-42s = %s\n" "$k" "$(sysctl -n $k)"
done

Sur une Debian 12 fraîche, plusieurs réglages sensibles sont peu sûrs par défaut :

net.ipv4.conf.all.accept_redirects         = 1
net.ipv4.conf.all.send_redirects           = 1
net.ipv4.conf.all.rp_filter                = 0
net.ipv4.conf.all.log_martians             = 0
kernel.kptr_restrict                       = 0
kernel.yama.ptrace_scope                   = 0

Ce sont précisément ces valeurs que le durcissement va corriger. D'autres (comme kernel.randomize_va_space = 2 ou fs.protected_symlinks = 1) sont souvent déjà correctes, mais on les fige quand même pour éviter toute dérive.

Déployer un jeu de durcissement

Placez la configuration dans /etc/sysctl.d/99-hardening.conf. Le préfixe 99- garantit qu'il est lu en dernier (ordre lexical), donc qu'il l'emporte sur les valeurs posées par la distribution.

1. Créer le fichier de durcissement

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

   # --- Reseau : routage et redirections ---
   net.ipv4.ip_forward = 0
   net.ipv4.conf.all.accept_redirects = 0
   net.ipv4.conf.default.accept_redirects = 0
   net.ipv6.conf.all.accept_redirects = 0
   net.ipv4.conf.all.send_redirects = 0
   net.ipv4.conf.default.send_redirects = 0
   net.ipv4.conf.all.accept_source_route = 0
   net.ipv6.conf.all.accept_source_route = 0
   
   # --- Reseau : anti-spoofing et journalisation ---
   net.ipv4.conf.all.rp_filter = 1
   net.ipv4.conf.default.rp_filter = 1
   net.ipv4.conf.all.log_martians = 1
   net.ipv4.icmp_echo_ignore_broadcasts = 1
   net.ipv4.icmp_ignore_bogus_error_responses = 1
   net.ipv4.tcp_syncookies = 1
   net.ipv4.tcp_rfc1337 = 1
   net.ipv6.conf.all.accept_ra = 0
   
   # --- Noyau : exposition d'informations ---
   kernel.kptr_restrict = 2
   kernel.dmesg_restrict = 1
   kernel.randomize_va_space = 2
   kernel.yama.ptrace_scope = 1
   kernel.kexec_load_disabled = 1
   
   # --- Systeme de fichiers ---
   fs.protected_hardlinks = 1
   fs.protected_symlinks = 1
   fs.protected_fifos = 2
   fs.protected_regular = 2
   fs.suid_dumpable = 0

2. Appliquer la configuration

   sudo sysctl --system

   * Applying /etc/sysctl.d/99-hardening.conf ...

   sysctl --system recharge tous les fichiers sysctl.d dans l'ordre. Une valeur refusée (paramètre inconnu sur votre noyau) provoque une ligne d'erreur explicite, sans bloquer le reste.

Le rôle de chaque famille

• redirections / source route : un attaquant sur le réseau ne peut plus détourner votre trafic via des redirections ICMP ou un routage forcé.
• rp_filter : le reverse path filtering strict jette les paquets dont l'adresse source est incohérente avec la route, un anti-spoofing de base.
• kptr_restrict / dmesg_restrict : on cache les adresses noyau et les journaux kernel, qui servent à fiabiliser un exploit.
• ptrace_scope : un processus ne peut plus en espionner un autre hors de sa descendance.

Vérifier l'effet

Relisez les valeurs ciblées : elles doivent avoir basculé.

sysctl net.ipv4.conf.all.rp_filter kernel.kptr_restrict kernel.yama.ptrace_scope

net.ipv4.conf.all.rp_filter = 1
kernel.kptr_restrict = 2
kernel.yama.ptrace_scope = 1

Pour une preuve concrète, regardez l'effet de kptr_restrict = 2 sur les adresses des symboles du noyau :

head -2 /proc/kallsyms

0000000000000000 A fixed_percpu_data
0000000000000000 A __per_cpu_start

Les adresses réelles sont masquées (remplacées par des zéros), même pour root : un exploit local ne peut plus les lire pour contourner l'ASLR du noyau.

Le piège conteneur contre VM

C'est la limite à connaître avant de penser durcir « partout ». Dans un conteneur non privilégié, les paramètres noyau sont en lecture seule :

# Dans un conteneur
sysctl -w kernel.kptr_restrict=2
# sysctl: permission denied on key "kernel.kptr_restrict"

sysctl -w net.ipv4.conf.all.rp_filter=1
# net.ipv4.conf.all.rp_filter = 1   (accepte : net.* est namespace)

Famille	Conteneur non privilégié	VM / physique
kernel.*, fs.*	Lecture seule (refusé)	Modifiable
net.*	Modifiable (isolé par netns)	Modifiable

Glissez pour voir

Concrètement : un durcissement noyau complet ne s'applique qu'au niveau de l'hôte (ou d'une VM), pas depuis un conteneur applicatif. Les conteneurs héritent du noyau durci de l'hôte.

Sécurité et points de vigilance

Certains réglages cassent des cas légitimes. Adaptez avant d'appliquer en masse :

• ip_forward = 0 coupe le routage. Un routeur, une passerelle NAT, un nœud Kubernetes ou un hôte Docker ont besoin de ip_forward = 1. Ne durcissez ce paramètre que sur un serveur applicatif simple.
• rp_filter = 1 (strict) casse le routage asymétrique et les hôtes multi-homés. En cas de doute, utilisez la valeur 2 (mode lâche), qui garde une protection sans rejeter le trafic légitime.
• accept_ra = 0 suppose une IPv6 configurée statiquement. Sur un réseau qui distribue les préfixes par Router Advertisement, gardez-le activé.
• Toujours tester sur une VM ou via une console de secours (KVM/IPMI) : un mauvais réglage réseau appliqué à distance peut vous couper l'accès.

Pour industrialiser ces réglages sur un parc, le module ansible.posix.sysctl applique et rend persistants ces paramètres de façon idempotente.

Dépannage

Symptôme	Cause probable	Solution
permission denied on key kernel.*	Exécution dans un conteneur	Appliquer sur l'hôte ou une VM
Le réglage revient à l'ancienne valeur après reboot	Modifié avec -w au lieu d'un fichier sysctl.d	Écrire dans /etc/sysctl.d/ puis sysctl --system
Une valeur de sysctl.d est ignorée	Un fichier au préfixe plus élevé la réécrit	Vérifier l'ordre avec sysctl --system ; nommer en 99-
Perte de connectivité après application	ip_forward=0 ou rp_filter=1 sur un routeur/multi-homé	Restaurer via console, ajuster (ip_forward=1, rp_filter=2)
unknown key à l'application	Paramètre absent sur ce noyau	Retirer la ligne ou ignorer (non bloquant)

Glissez pour voir

À retenir

• sysctl règle le noyau à chaud ; pour durcir, on écrit dans /etc/sysctl.d/ (persistant)
• Capturez une baseline d'abord : les défauts varient selon la distribution
• Cibles clés : redirections, rp_filter, kptr_restrict, ptrace_scope, protections fs
• kptr_restrict = 2 masque les adresses noyau (vérifiable dans /proc/kallsyms)
• En conteneur, seuls les net.* sont modifiables : le durcissement noyau se fait sur l'hôte/VM
• Attention à ip_forward et rp_filter : ils cassent routeurs et hôtes multi-homés

Prochaines étapes

Tracer avec auditd Compléter le durcissement noyau par une piste d'audit : qui modifie quoi sur le serveur.

CIS Benchmarks Le référentiel d'où viennent ces valeurs : mapper chaque paramètre à un contrôle CIS.

ANSSI BP-28 Les recommandations françaises de durcissement, paramètres noyau inclus.

Automatiser avec Ansible Appliquer ces réglages sysctl de façon idempotente sur tout un parc.

×

📖 Voir la documentation →