Durcissement Linux 2026 : Guide Hardening CIS Benchmark

Le durcissement Linux est un exercice à la fois ancien et toujours actuel. Ancien, parce que les bases (suppression des services inutiles, séparation des privilèges, journalisation) sont stables depuis vingt ans. Actuel, parce que les menaces évoluent rapidement (rootkits eBPF, kernel exploits modernes, attaques sur la chaîne d'approvisionnement comme XZ Utils en 2024) et que les obligations réglementaires se durcissent (NIS2, ISO 27001:2022, certification HDS, qualification SecNumCloud). Ce guide complet 2026 propose une méthodologie opérationnelle de hardening pour serveurs Linux Debian, Ubuntu et RHEL/Rocky/AlmaLinux, alignée sur le CIS Benchmark v3 et le guide d'hygiène ANSSI. Vous y trouverez les commandes prêtes à l'emploi, les fichiers de configuration commentés, les pièges classiques et un script d'audit complet à intégrer dans votre pipeline CI/CD ou votre baseline Ansible.

1. Pourquoi durcir Linux en 2026 ?

Linux est partout : selon le rapport StackOverflow Developer Survey 2025, plus de 80% des serveurs dans le cloud public tournent sous Linux, et la part de marché des containers Linux sur l'edge dépasse 90%. Cette omniprésence en fait une cible privilégiée pour les attaquants. Le rapport CrowdStrike 2026 indique que les compromissions de serveurs Linux ont augmenté de 142% entre 2022 et 2025, portées par trois familles de menaces : les rootkits eBPF capables de masquer leur présence aux EDR classiques, les ransomwares Linux ciblant les hyperviseurs ESXi et Proxmox, et les attaques de supply chain (paquets PyPI/npm malveillants, comme dans l'incident XZ Utils CVE-2024-3094).

1.1 Conformité réglementaire

Plusieurs cadres réglementaires imposent désormais un niveau de durcissement vérifié :

• NIS2 — Article 21 : mesures techniques et organisationnelles, dont le durcissement systèmes documenté et audité annuellement.
• ISO 27001:2022 — Contrôle A.8.9 : Configuration management exige une baseline de sécurité documentée.
• HDS (Hébergeur de Données de Santé) — Référentiel HDS 2023 chapitre 7.10 : durcissement obligatoire selon état de l'art.
• SecNumCloud 3.2 — Exigences ANSSI pour qualification cloud souverain, ch. 19.
• PCI DSS 4.0 — Requirement 2.2 : configurations sécurisées des composants système.

1.2 Approche par couches

Un durcissement Linux efficace s'organise en cinq couches concentriques, du plus profond au plus exposé. Cette structure facilite la priorisation et l'audit.

Couche	Composants	Objectif	Outils
1. Noyau	Paramètres kernel, modules, sysctl	Réduire la surface kernel, prévenir LPE	sysctl, modprobe, lockdown
2. MAC	SELinux ou AppArmor	Cloisonner les processus	semanage, aa-genprof
3. Services	sshd, systemd, daemons	Limiter exposition réseau	systemctl, firewall
4. Comptes	PAM, sudo, mots de passe	Authentification forte	PAM, pam_pwquality
5. Audit	auditd, journald, rsyslog	Traçabilité, détection	auditd, AIDE, SIEM

2. CIS Benchmark Linux : la référence opérationnelle

Le Center for Internet Security (CIS) publie depuis 2003 des Benchmarks de durcissement consensuels, élaborés par des centaines d'experts internationaux. En 2026, les Benchmarks Linux les plus utilisés sont CIS Ubuntu 24.04 v2.0, CIS Debian 12 v1.0, CIS RHEL 9 v2.0 et CIS Rocky Linux 9 v2.0. Chaque benchmark contient entre 200 et 300 contrôles répartis en deux niveaux et deux profils (Server, Workstation).

2.1 Les deux niveaux CIS

• Level 1 — Mesures de base à appliquer sans impact fonctionnel. Cible : tout serveur Linux en production.
• Level 2 — Mesures avancées potentiellement intrusives (désactivation services, paramètres restrictifs). Cible : environnements à haute sensibilité.

2.2 Catégories de contrôles

Les contrôles CIS sont structurés en 7 catégories. Les pourcentages indiquent la proportion typique de contrôles par catégorie.

Catégorie	Exemples	Part typique
Initial Setup	FS partitioning, modules, GPG, bootloader	15%
Services	Désactivation telnet, FTP, NIS, NFS legacy	20%
Network Configuration	IP forwarding, ICMP, IPv6, firewall	15%
Access & Authentication	PAM, sudo, SSH, mots de passe	20%
Logging & Auditing	auditd, rsyslog, journald, AIDE	15%
System Maintenance	Permissions /etc, cron, world-writable	10%
Mandatory Access Control	SELinux/AppArmor activation	5%

2.3 Outils d'audit automatisé

Trois outils dominent pour auditer un système contre CIS :

• OpenSCAP — Implémentation open source de SCAP par RedHat. Profils CIS, STIG, PCI prêts à l'emploi.
• Lynis — Audit script Bash, scoring 0-100, recommandations détaillées.
• CIS-CAT Pro — Outil officiel CIS (payant), rapports exécutifs.

# Audit OpenSCAP contre CIS RHEL 9
sudo dnf install -y openscap-scanner scap-security-guide
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_workstation_l2 \
  --results-arf results.arf.xml --report report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Audit Lynis (universel)
sudo apt install -y lynis  # ou dnf install lynis
sudo lynis audit system --quick

3. Couche 1 — Durcissement du noyau Linux

Le noyau est la cible ultime de tout attaquant car sa compromission donne accès à toutes les ressources. Le durcissement kernel se joue sur trois axes : paramètres sysctl, modules désactivés et options de boot.

3.1 Paramètres sysctl essentiels

Le fichier /etc/sysctl.d/99-hardening.conf regroupe les paramètres recommandés par le CIS et l'ANSSI. À appliquer avec sysctl --system.

# /etc/sysctl.d/99-hardening.conf
# Réseau — anti-spoofing et DoS
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.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.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.log_martians = 1

# Kernel — anti-LPE
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.yama.ptrace_scope = 2
kernel.kexec_load_disabled = 1
kernel.sysrq = 0
kernel.unprivileged_bpf_disabled = 1
net.core.bpf_jit_harden = 2
kernel.perf_event_paranoid = 3

# FS — protection contre symlink/hardlink attacks
fs.protected_symlinks = 1
fs.protected_hardlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2
fs.suid_dumpable = 0

# ASLR
kernel.randomize_va_space = 2

Chaque paramètre mérite une explication. kernel.kptr_restrict=2 masque les adresses des pointeurs noyau dans /proc, bloquant un vecteur classique d'exploitation. kernel.unprivileged_bpf_disabled=1 empêche les utilisateurs non-root de charger des programmes eBPF, fermant la porte à de nombreux exploits récents (Dirty Pipe en 2022 en a démontré l'importance). fs.protected_symlinks=1 bloque la classe d'attaque symlink race dans /tmp.

3.2 Blacklisting de modules dangereux

Certains modules kernel ne servent à rien en production serveur mais offrent une surface d'attaque ou des vecteurs de DoS. Les désactiver est un quick win.

# /etc/modprobe.d/hardening.conf
# Filesystems obsolètes
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
install vfat /bin/true

# Protocoles réseau rares
install dccp /bin/true
install sctp /bin/true
install rds /bin/true
install tipc /bin/true

# Bluetooth et FireWire (serveurs)
install bluetooth /bin/true
install firewire-core /bin/true
install thunderbolt /bin/true

# USB storage (selon contexte)
# install usb-storage /bin/true

# Régénérer initramfs après modification
update-initramfs -u  # Debian/Ubuntu
dracut -f            # RHEL/Rocky

3.3 Sécurisation du bootloader

GRUB doit avoir un mot de passe pour empêcher la modification des paramètres de boot par un attaquant disposant d'un accès console (utile en datacenter et pour les VMs).

# Génération du hash GRUB
grub-mkpasswd-pbkdf2
# Saisir et confirmer le mot de passe
# Copier le hash généré : grub.pbkdf2.sha512...

# /etc/grub.d/40_custom
set superusers="rootadmin"
password_pbkdf2 rootadmin grub.pbkdf2.sha512.10000.HASH...

# Régénération
update-grub        # Debian/Ubuntu
grub2-mkconfig -o /boot/grub2/grub.cfg  # RHEL/Rocky

# Permissions
chmod 600 /boot/grub/grub.cfg
chown root:root /boot/grub/grub.cfg

3.4 Kernel Lockdown et Secure Boot

Le mode kernel lockdown introduit depuis Linux 5.4 (et activé par défaut en mode Secure Boot) restreint l'accès root au noyau (pas de chargement de modules non signés, pas de kexec, /dev/mem bloqué). Recommandé pour les serveurs sensibles. Vérifier l'état :

cat /sys/kernel/security/lockdown
# Sortie attendue : none [integrity] confidentiality
# 'integrity' minimum, 'confidentiality' pour systèmes très sensibles

4. Couche 2 — SELinux et AppArmor

Les modules de contrôle d'accès obligatoire (MAC) sont la deuxième ligne de défense après le noyau. Ils confinent chaque processus à un ensemble de ressources autorisées, indépendamment des permissions DAC traditionnelles. SELinux et AppArmor sont des projets distincts mais répondent au même besoin.

4.1 SELinux (RHEL, Fedora, Rocky, AlmaLinux)

SELinux, développé par la NSA et intégré au noyau Linux depuis 2003, utilise un système d'étiquetage (labels) et de politiques. Trois modes : enforcing (politique appliquée), permissive (politique journalisée mais non bloquante), disabled (jamais en production).

# Vérifier l'état
getenforce
sestatus

# Forcer enforcing
setenforce 1
# Persistant via /etc/selinux/config :
#   SELINUX=enforcing
#   SELINUXTYPE=targeted

# Voir les denials
ausearch -m AVC -ts recent
# Analyser une denial
audit2allow -a

# Politique custom (ne JAMAIS désactiver)
# Créer un module local pour autoriser une action spécifique
audit2allow -a -M my_custom_module
semodule -i my_custom_module.pp

Les politiques par défaut de SELinux confinent une vingtaine de services courants (httpd, mysqld, postgresql, sshd…) via la politique targeted. Pour les environnements très sensibles, la politique mls (Multi-Level Security) offre un cloisonnement quasi militaire (Bell-LaPadula).

4.2 AppArmor (Debian, Ubuntu, SUSE)

AppArmor adopte une approche plus simple basée sur des profils par chemin d'exécutable. Plus facile à apprendre que SELinux mais avec une granularité moindre.

# Statut AppArmor
sudo aa-status

# Lister les profils
ls /etc/apparmor.d/

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

# Mode complain (audit sans bloquer)
sudo aa-complain /etc/apparmor.d/usr.bin.firefox

# Générer un profil pour une application
sudo aa-genprof /usr/local/bin/my-app

# Recharger après modification
sudo systemctl reload apparmor

4.3 Choix SELinux vs AppArmor

Le choix dépend essentiellement de la distribution : SELinux sur RHEL/Rocky/Alma, AppArmor sur Debian/Ubuntu. Migrer entre les deux n'est généralement pas raisonnable. Les organisations multi-distribution gagnent à mutualiser sur OpenSCAP qui couvre les deux.

5. Couche 3 — Durcissement des services

Chaque service exposé est une porte d'entrée potentielle. Le principe directeur : désactiver tout ce qui n'est pas strictement nécessaire.

5.1 Inventaire des services

# Lister les services actifs
systemctl list-units --type=service --state=running

# Lister les ports écoutés
ss -tlnp
ss -ulnp

# Services à désactiver typiquement
for svc in avahi-daemon cups bluetooth rpcbind nfs-server smbd; do
  systemctl disable --now $svc 2>/dev/null
done

# Désinstaller paquets obsolètes (CIS L1)
apt remove -y telnet rsh-client talk talkd nis tftp xinetd 2>/dev/null
dnf remove -y telnet rsh-client talk tftp xinetd 2>/dev/null

5.2 Durcissement SSH

SSH est le service le plus exposé et le plus attaqué. Sa configuration mérite un soin particulier.

# /etc/ssh/sshd_config — extraits durcis
Port 22  # Changer port = sécurité par obscurité, non recommandé seul
Protocol 2
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
X11Forwarding no
AllowTcpForwarding no
PermitTunnel no
MaxAuthTries 3
MaxSessions 10
ClientAliveInterval 300
ClientAliveCountMax 0
LoginGraceTime 30
LogLevel VERBOSE
UseDNS no

# Algorithmes — sources : Mozilla, ANSSI
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256

# Restriction par groupe
AllowGroups ssh-users
Match Group sftp-users
  ChrootDirectory /sftp/%u
  ForceCommand internal-sftp
  AllowTcpForwarding no

Tester la configuration avant de l'appliquer : sshd -t -f /etc/ssh/sshd_config. Toujours garder une session SSH ouverte lors du systemctl reload sshd pour pouvoir revenir en arrière en cas de blocage.

5.3 Firewall : nftables ou iptables

Depuis Linux 4.10, nftables remplace iptables. Sur Debian 12 et RHEL 9, nftables est le backend par défaut.

# /etc/nftables.conf — baseline serveur web
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state {established, related} accept
    ct state invalid drop
    iif lo accept
    ip protocol icmp limit rate 5/second accept
    ip6 nexthdr icmpv6 accept
    tcp dport 22 limit rate 5/minute accept comment "SSH rate limit"
    tcp dport {80, 443} accept comment "HTTP/HTTPS"
    log prefix "[nftables drop] " limit rate 10/minute
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
  chain output {
    type filter hook output priority 0; policy accept;
  }
}

# Application
sudo nft -f /etc/nftables.conf
sudo systemctl enable --now nftables

5.4 Fail2ban

Fail2ban bannit dynamiquement les IP brute-forçant les services. Configuration minimale :

# /etc/fail2ban/jail.local
[DEFAULT]
bantime = 24h
findtime = 10m
maxretry = 5
banaction = nftables-multiport

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

6. Couche 4 — Comptes, sudo et PAM

La gestion des comptes utilisateurs et de l'élévation de privilèges constitue la quatrième couche.

6.1 Politique de mot de passe

# /etc/security/pwquality.conf
minlen = 14
minclass = 4
maxrepeat = 2
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
dictcheck = 1
enforce_for_root

# /etc/login.defs
PASS_MAX_DAYS 90
PASS_MIN_DAYS 1
PASS_WARN_AGE 14
ENCRYPT_METHOD YESCRYPT  # Linux moderne ; sinon SHA512
SHA_CRYPT_MIN_ROUNDS 100000
UMASK 027

6.2 PAM : verrouillage après échec

# /etc/security/faillock.conf
deny = 5
unlock_time = 900
fail_interval = 900
even_deny_root
silent

# /etc/pam.d/common-auth (Debian) ou /etc/pam.d/system-auth (RHEL)
auth required pam_faillock.so preauth silent
auth [success=2 default=ignore] pam_unix.so try_first_pass
auth [default=die] pam_faillock.so authfail
auth sufficient pam_faillock.so authsucc

6.3 Sudo et privilèges

L'utilisation directe du compte root doit être interdite, au profit de sudo. Configuration recommandée :

# /etc/sudoers.d/99-hardening
Defaults    use_pty
Defaults    logfile="/var/log/sudo.log"
Defaults    log_input, log_output
Defaults    requiretty
Defaults    !visiblepw
Defaults    timestamp_timeout=15
Defaults    passwd_tries=3
Defaults    env_reset

# Groupe d'admins
%admins ALL=(ALL:ALL) ALL

# Compte de service applicatif (privilèges limités)
appuser ALL=(www-data) NOPASSWD: /usr/bin/systemctl restart nginx

6.4 MFA SSH

Pour les serveurs sensibles, ajouter un facteur TOTP via libpam-google-authenticator ou intégrer avec un serveur LDAP/SSO.

apt install -y libpam-google-authenticator

# Configuration utilisateur
sudo -u jdoe google-authenticator -d -f -t -r 3 -R 30 -w 3

# /etc/pam.d/sshd — ajouter
auth required pam_google_authenticator.so nullok

# /etc/ssh/sshd_config
KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

7. Couche 5 — Audit et journalisation

Sans audit, aucune détection n'est possible. La journalisation est aussi une exigence réglementaire forte (NIS2, ISO 27001, HDS imposent une rétention de 6 mois minimum).

7.1 auditd : journalisation kernel

Le daemon auditd capture les événements kernel via les audit rules. Ruleset recommandé alignant CIS et MITRE ATT&CK :

# /etc/audit/rules.d/99-hardening.rules
-D
-b 8192
-f 1

# Time changes
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time-change

# Identity files
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k identity
-w /etc/sudoers.d -p wa -k identity

# Login/logout
-w /var/log/lastlog -p wa -k logins
-w /var/run/faillock -p wa -k logins

# Sudo usage
-a always,exit -F arch=b64 -C euid!=uid -F auid!=4294967295 -S execve -k privileged-cmd

# Modifications réseau
-a always,exit -F arch=b64 -S sethostname,setdomainname -k system-locale
-w /etc/hosts -p wa -k system-locale
-w /etc/sysconfig/network -p wa -k system-locale

# Modules kernel
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module,delete_module -k modules

# Audit immutable (rendre les règles permanentes)
-e 2

7.2 Centralisation des logs

Pour répondre aux exigences NIS2, les logs doivent être envoyés vers un SIEM externe immuable. Configuration rsyslog minimale vers un collecteur central :

# /etc/rsyslog.d/99-forward.conf
*.* @@siem.corp.local:6514  # TLS sur TCP

# Avec authentification mutuelle TLS
$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile /etc/ssl/ca.crt
$DefaultNetstreamDriverCertFile /etc/ssl/client.crt
$DefaultNetstreamDriverKeyFile /etc/ssl/client.key
$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer siem.corp.local
$ActionSendStreamDriverMode 1
*.* @@(o)siem.corp.local:6514

7.3 Détection d'intégrité avec AIDE

AIDE (Advanced Intrusion Detection Environment) calcule des hashes de référence des fichiers système et détecte toute modification.

# Installation et init
apt install -y aide
aideinit
# Génère /var/lib/aide/aide.db.new
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Vérification quotidienne via cron
# /etc/cron.daily/aide-check
#!/bin/bash
aide --check | mail -s "AIDE report $(hostname)" sec@corp.local

chmod 700 /etc/cron.daily/aide-check

8. Conteneurs et orchestration : durcissement spécifique

Les serveurs Linux hébergent désormais massivement des conteneurs Docker/Podman et des nœuds Kubernetes. Leur durcissement présente des spécificités.

8.1 Durcissement du daemon Docker

# /etc/docker/daemon.json
{
  "icc": false,
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" },
  "live-restore": true,
  "userland-proxy": false,
  "no-new-privileges": true,
  "userns-remap": "default",
  "selinux-enabled": true
}

8.2 Bonnes pratiques Kubernetes

• Pod Security Standards (PSS) en mode restricted.
• NetworkPolicies par défaut deny-all.
• RBAC strict, pas de cluster-admin pour les pods.
• Audit logs Kubernetes vers SIEM (audit-policy.yaml).
• Scan d'images via Trivy ou Grype dans la CI.
• Admission controller (Kyverno, OPA Gatekeeper).

9. Automatisation : Ansible et CI/CD

Un durcissement manuel n'est pas réplicable. L'industrialisation passe par l'IaC.

9.1 Rôles Ansible reconnus

Rôle	Auteur	Couverture
ansible-lockdown/RHEL9-CIS	Ansible Lockdown	CIS RHEL 9 L1+L2 complet
ansible-lockdown/UBUNTU24-CIS	Ansible Lockdown	CIS Ubuntu 24.04
dev-sec/linux-baseline	DevSec	Baseline générique
komitee/Cyber-OPS-Linux	Communauté	ANSSI + STIG

# Exemple d'utilisation
git clone https://github.com/ansible-lockdown/RHEL9-CIS
cd RHEL9-CIS
# Personnaliser defaults/main.yml
ansible-playbook -i inventory site.yml --check  # dry-run
ansible-playbook -i inventory site.yml

9.2 Intégration CI/CD

Intégrer un scan OpenSCAP dans la pipeline CI permet de bloquer les déploiements non conformes. Exemple GitLab CI :

hardening_scan:
  stage: validate
  image: redhat/ubi9
  script:
    - dnf install -y openscap-scanner scap-security-guide
    - oscap xccdf eval --profile cis_workstation_l2 --results-arf out.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml || true
    - oscap xccdf generate report out.xml > report.html
  artifacts:
    paths: [report.html, out.xml]
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

10. Cas réels et leçons retenues

L'analyse de plusieurs incidents Linux 2024-2025 montre les chemins d'attaque les plus fréquents et les défenses qui auraient fait la différence.

10.1 Cas XZ Utils (CVE-2024-3094)

L'introduction d'une backdoor dans xz, visant sshd, a été l'attaque supply-chain la plus sophistiquée de 2024. Les serveurs avec liblzma non patché et SSH exposé ont été menacés. Défenses qui ont permis d'éviter la compromission : a) Secure Boot et kernel lockdown qui bloquaient certains chemins de la backdoor, b) systèmes en versions stables n'incluant pas xz 5.6.0/5.6.1, c) audit sortant détectant les connexions C2 sortantes.

10.2 Compromission via cron exposé

Un attaquant a exploité un cron exécuté en root traitant des fichiers d'un répertoire accessible en écriture par un utilisateur web. La défense : umask 027 strict, exécution des crons sous utilisateurs non privilégiés, vérification systématique des permissions de répertoires consommés par root.

10.3 Rootkit eBPF

Plusieurs rootkits 2024-2025 (Symbiote, BPFDoor) abusent d'eBPF pour se masquer aux outils userland. La désactivation de kernel.unprivileged_bpf_disabled=1 et l'audit des programmes BPF chargés (bpftool prog) sont essentiels.

11. Script d'audit rapide

Le script suivant effectue un audit express en moins de 5 minutes, utile pour vérifier rapidement la posture d'un serveur.

#!/bin/bash
# audit-hardening.sh — quick check
set -e
SCORE=0; MAX=0

check() {
  MAX=$((MAX+1))
  if eval "$2"; then
    echo "[OK]  $1"
    SCORE=$((SCORE+1))
  else
    echo "[KO]  $1"
  fi
}

check "Pas de root SSH" "grep -qE '^PermitRootLogin no' /etc/ssh/sshd_config"
check "Pas d'auth password SSH" "grep -qE '^PasswordAuthentication no' /etc/ssh/sshd_config"
check "ASLR activé" "[ \"$(cat /proc/sys/kernel/randomize_va_space)\" = '2' ]"
check "kptr_restrict=2" "[ \"$(cat /proc/sys/kernel/kptr_restrict)\" = '2' ]"
check "unprivileged_bpf désactivé" "[ \"$(cat /proc/sys/kernel/unprivileged_bpf_disabled)\" = '1' ]"
check "SELinux/AppArmor actif" "getenforce 2>/dev/null | grep -q Enforcing || aa-status 2>/dev/null | grep -q enforce"
check "auditd actif" "systemctl is-active auditd | grep -q active"
check "rsyslog actif" "systemctl is-active rsyslog | grep -q active"
check "Firewall actif" "systemctl is-active nftables firewalld | grep -q active"
check "AIDE installé" "command -v aide >/dev/null"
check "UMASK 027" "grep -qE '^UMASK\s+027' /etc/login.defs"
check "Telnet absent" "! command -v telnet >/dev/null"

echo "---"
echo "Score : $SCORE / $MAX"

12. Maintenance et patch management

Un système durci aujourd'hui ne le sera plus dans six mois sans entretien. Le patching reste la mesure la plus efficace, devant tous les durcissements avancés.

12.1 Patch management automatisé

• unattended-upgrades (Debian/Ubuntu) — application automatique des security updates.
• dnf-automatic (RHEL/Rocky) — équivalent côté RHEL.
• kpatch / livepatch — application de patches kernel sans reboot.
• Foreman/Katello, Spacewalk, Red Hat Satellite — gestion centralisée multi-serveurs.

12.2 Cycle de vérification

Mensuel : revue des paquets installés vs nécessaires. Trimestriel : audit OpenSCAP complet. Annuel : revue de la politique de durcissement par rapport aux nouvelles versions CIS Benchmark. Après chaque CVE critique : application en moins de 7 jours pour serveurs exposés, 30 jours pour internes.

13. Cas spécifique : durcissement d'un serveur web Linux exposé

Un serveur web Internet-facing concentre l'essentiel des risques. Voici une checklist consolidée spécifique, à compléter avec les éléments précédents.

13.1 Architecture recommandée

L'architecture défensive typique pour un site exposé combine plusieurs couches. Au front, un WAF (Web Application Firewall) en mode reverse proxy filtre les attaques applicatives (OWASP Top 10). Derrière, un load balancer terminait le TLS et répartit la charge. Les serveurs applicatifs exécutent Nginx ou Apache en mode unprivileged sous un utilisateur dédié (www-data, nginx). Une base de données isolée sur un sous-réseau privé reçoit les connexions exclusivement depuis les serveurs applicatifs. Cette ségrégation permet de limiter l'impact d'une compromission applicative.

13.2 Durcissement Nginx

# /etc/nginx/nginx.conf — extraits durcis
user www-data;
worker_processes auto;
worker_rlimit_nofile 65535;

events {
  worker_connections 10240;
  use epoll;
  multi_accept on;
}

http {
  server_tokens off;
  client_max_body_size 10M;
  client_body_timeout 12;
  client_header_timeout 12;
  send_timeout 10;
  keepalive_timeout 15;
  keepalive_requests 100;

  # TLS — config Mozilla Modern
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
  ssl_prefer_server_ciphers off;
  ssl_session_cache shared:SSL:50m;
  ssl_session_timeout 1d;
  ssl_session_tickets off;
  ssl_stapling on;
  ssl_stapling_verify on;

  # Headers sécurité (s'appliquent à tous les vhosts)
  add_header X-Frame-Options "SAMEORIGIN" always;
  add_header X-Content-Type-Options "nosniff" always;
  add_header Referrer-Policy "strict-origin-when-cross-origin" always;
  add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
  add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
  add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'" always;

  # Rate limiting
  limit_req_zone $binary_remote_addr zone=app:10m rate=10r/s;
  limit_conn_zone $binary_remote_addr zone=connlimit:10m;

  # Cacher les pages d'erreur génériques
  error_page 401 402 403 404 /404.html;
  error_page 500 502 503 504 /50x.html;
}

13.3 Isolation systemd

Les services exposés gagnent à être encadrés par des directives systemd de cloisonnement. Exemple pour un service applicatif Python :

# /etc/systemd/system/myapp.service
[Service]
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/venv/bin/gunicorn myapp.wsgi:application

# Cloisonnement
NoNewPrivileges=true
PrivateTmp=true
PrivateDevices=true
ProtectSystem=strict
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=true
ProtectClock=true
ProtectHostname=true
ProtectProc=invisible
RestrictRealtime=true
RestrictNamespaces=true
RestrictSUIDSGID=true
LockPersonality=true
MemoryDenyWriteExecute=true
SystemCallArchitectures=native
SystemCallFilter=@system-service
CapabilityBoundingSet=
AmbientCapabilities=

# Chemins en écriture explicites
ReadWritePaths=/var/log/myapp /var/lib/myapp

FAQ

SELinux ou AppArmor : lequel est le plus sécurisé ?

SELinux offre une granularité supérieure et des politiques plus exhaustives, ce qui en fait techniquement la solution la plus robuste. AppArmor compense par une simplicité d'écriture et de maintenance des profils. En pratique, un système Debian/Ubuntu avec AppArmor bien configuré est aussi sûr qu'un système RHEL avec SELinux par défaut. Le pire dans les deux cas est de désactiver le MAC sous prétexte qu'il bloque une application : il faut toujours analyser les denials et créer un module/profil custom.

Faut-il appliquer tout le CIS Benchmark Level 2 sur un serveur de production ?

Pas nécessairement. Certains contrôles L2 ont un impact fonctionnel important (désactivation du transfert TCP, restrictions IPv6, désactivation USB). Une approche pragmatique consiste à appliquer 100% du L1 puis à évaluer chaque contrôle L2 en fonction du contexte (serveur web, base de données, bastion). Documenter formellement chaque exception et la justifier en audit.

Comment durcir un serveur Linux déjà en production sans casser les applications ?

Procéder en 4 étapes : 1) clone de la VM en environnement test, 2) application du durcissement complet sur le clone, 3) tests fonctionnels exhaustifs, 4) déploiement progressif en production avec rollback préparé. Chaque modification doit pouvoir être annulée individuellement. Les modifications les plus risquées (firewall, SELinux enforcing, désactivation services) doivent être appliquées hors plages d'activité métier.

Le durcissement Linux est-il compatible avec les environnements DevOps modernes ?

Totalement. Au contraire, l'IaC (Ansible, Terraform, Pulumi) et la CI/CD facilitent énormément la reproductibilité du durcissement. Les images golden (Packer + Ansible) intégrant le durcissement dès la construction sont devenues la norme dans les organisations matures. L'approche "immutable infrastructure" élimine la dérive de configuration et garantit le maintien du niveau de durcissement à chaque déploiement.

Quels outils utiliser pour la détection en temps réel sur Linux durci ?

Plusieurs solutions complémentaires : auditd pour la collecte kernel, Falco pour la détection comportementale eBPF (open source CNCF), osquery pour les requêtes système temps réel, et un EDR commercial (CrowdStrike, SentinelOne, Wazuh open source) pour la corrélation avancée. La centralisation vers un SIEM (Splunk, Elastic, Wazuh) avec règles MITRE ATT&CK est l'aboutissement.

Combien de temps faut-il pour durcir un serveur Linux ?

Un durcissement complet manuel d'un serveur Linux représente 2 à 4 jours-homme pour un opérateur expérimenté incluant les tests. Avec un playbook Ansible mature (rôle CIS), le temps de déploiement tombe à 15-30 minutes par serveur. La première mise en place du playbook et son adaptation au contexte demandent typiquement 10 à 20 jours-homme.

Conclusion & Pour approfondir

Le durcissement Linux en 2026 n'est plus un exercice optionnel mais une exigence à la fois technique et réglementaire. Les cinq couches présentées dans ce guide (noyau, MAC, services, comptes, audit) couvrent l'essentiel des contrôles attendus par le CIS Benchmark, l'ANSSI et les auditeurs NIS2. La clé de la réussite tient en trois principes : industrialiser via Ansible et la CI/CD pour garantir la reproductibilité, auditer en continu via OpenSCAP ou Lynis pour détecter les dérives, et maintenir la posture par un patching strict et une formation continue des équipes. Un serveur durci en 2026 ne diffère pas fondamentalement d'un serveur durci en 2016 dans ses principes, mais l'outillage et la maturité des distributions ont rendu l'exercice à la fois plus accessible et plus indispensable face à des attaquants qui n'ont jamais été aussi sophistiqués.

• Audit et sécurisation serveur Linux open source — approche pratique
• Escalade de privilèges Linux et durcissement — vecteurs LPE
• Élévation de privilèges Linux : SUID et kernel — défense ciblée
• Forensics Linux : artefacts et investigation — réponse à incident
• Linux kernel exploitation : techniques LPE — perspective offensive