Guide de durcissement Linux 2026 : Protégez vos serveurs

En mars 2026, les équipes CERT de Red Hat, Debian et SUSE ont publié des avis de sécurité en cascade concernant le noyau Linux : élévation de privilèges via io_uring, exécution de code arbitraire, contournement de politiques SELinux. Ces vulnérabilités touchent des serveurs non patchés depuis des semaines. Si vous gérez des serveurs Linux en production, le durcissement n'est plus une option : c'est votre première ligne de défense.

Ce guide couvre les étapes essentielles à appliquer en 2026 : mises à jour noyau, verrouillage SSH, règles nftables, tuning sysctl, journalisation auditd, fail2ban et mises à jour automatiques. Toutes les commandes sont testées et prêtes pour la production.

1. Mises à jour système et correctifs noyau

L'action la plus impactante reste de maintenir le noyau et les paquets à jour. Les CVE récentes (élévation de privilèges io_uring, bugs de gestion GPU, instabilité des compteurs ARM64) ont été corrigées en quelques jours — mais uniquement pour les systèmes sur des noyaux supportés.

RHEL / Rocky Linux / AlmaLinux

# Mise à jour complète du système
sudo dnf update -y

# Vérifier la version du noyau actuel
uname -r

# Lister les noyaux installés
rpm -qa kernel | sort

# Conserver seulement les 2 derniers noyaux
sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --setopt=installonly_limit=2 --save

Debian / Ubuntu

# Mise à jour complète incluant le noyau
sudo apt update && sudo apt full-upgrade -y

# Vérifier si un redémarrage est nécessaire
cat /run/reboot-required 2>/dev/null && echo "Redémarrage requis !" || echo "Pas de redémarrage nécessaire"

# Supprimer les anciens noyaux
sudo apt autoremove --purge -y

Conseil : Abonnez-vous aux avis de sécurité Red Hat ou aux annonces Debian Security pour être notifié des patches critiques dès leur publication.

2. Durcissement de l'accès SSH

SSH est le principal vecteur d'accès à distance — et le plus ciblé. La configuration par défaut sur la plupart des distributions n'est pas adaptée à une exposition en production. Voici une configuration /etc/ssh/sshd_config durcie :

# /etc/ssh/sshd_config — Baseline durci 2026

# Changer le port par défaut (réduit le bruit des scans automatisés)
Port 2222

# Désactiver la connexion root
PermitRootLogin no

# Auth par clé uniquement — PLUS de mots de passe
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

# Autoriser uniquement des utilisateurs spécifiques
AllowUsers deploy ops-admin

# Durcissement protocole et crypto
Protocol 2
KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256
Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com

# Durcissement des sessions
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2

# Désactiver les fonctionnalités inutiles
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PrintMotd no

# Niveau de logs pour audit
LogLevel VERBOSE

# Appliquer et vérifier la config
sudo sshd -t && sudo systemctl reload sshd
echo "Config SSH valide et rechargée"

Générer des clés Ed25519 robustes (préférable à RSA en 2026) :

# Sur votre poste de travail
ssh-keygen -t ed25519 -C "ops-admin@entreprise.com" -f ~/.ssh/id_ed25519_prod

# Copier sur le serveur
ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub -p 2222 ops-admin@votre-serveur-ip

# Tester la connexion AVANT de fermer la session actuelle !
ssh -p 2222 -i ~/.ssh/id_ed25519_prod ops-admin@votre-serveur-ip

3. Configuration du pare-feu avec nftables

nftables a définitivement remplacé iptables sur les distributions Linux modernes. Il offre de meilleures performances, des mises à jour de règles atomiques et une syntaxe plus claire. Voici un jeu de règles de base solide :

# /etc/nftables.conf — Règles baseline serveur

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Autoriser le loopback
        iif lo accept

        # Autoriser les connexions établies/liées
        ct state established,related accept

        # Supprimer les paquets invalides
        ct state invalid drop

        # Autoriser ICMP (ping) — limité en débit
        ip protocol icmp limit rate 5/second accept
        ip6 nexthdr icmpv6 limit rate 5/second accept

        # Autoriser SSH sur port personnalisé
        tcp dport 2222 ct state new limit rate 10/minute accept

        # Autoriser HTTP/HTTPS (supprimer si pas un serveur web)
        tcp dport { 80, 443 } accept

        # Logger et supprimer tout le reste
        log prefix "nft-dropped: " flags all counter drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

# Appliquer le jeu de règles
sudo nft -f /etc/nftables.conf

# Activer nftables au démarrage
sudo systemctl enable --now nftables

# Vérifier les règles actives
sudo nft list ruleset

4. Durcissement du noyau avec sysctl

Le noyau Linux expose des centaines de paramètres configurables via /proc/sys/. Plusieurs d'entre eux impactent directement la posture de sécurité : protection de la pile réseau, randomisation mémoire et contrôles des privilèges.

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

# ========================
# Durcissement pile réseau
# ========================

# Désactiver le routage IP (sauf si c'est un routeur)
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# Prévenir les attaques SYN flood
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048

# Ignorer les broadcasts ICMP (mitigation attaque Smurf)
net.ipv4.icmp_echo_ignore_broadcasts = 1

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

# Désactiver le routage par source
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Logger les paquets suspects
net.ipv4.conf.all.log_martians = 1

# ========================
# Sécurité noyau
# ========================

# Restreindre l'accès à dmesg aux admins
kernel.dmesg_restrict = 1

# Masquer les pointeurs noyau aux utilisateurs non privilégiés
kernel.kptr_restrict = 2

# Restreindre ptrace aux processus parents uniquement
kernel.yama.ptrace_scope = 1

# Activer ASLR (Address Space Layout Randomization)
kernel.randomize_va_space = 2

# ========================
# Sécurité système de fichiers
# ========================

# Prévenir les hard links vers des fichiers qui ne vous appartiennent pas
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

# Restreindre les core dumps
fs.suid_dumpable = 0

# Appliquer immédiatement sans redémarrage
sudo sysctl -p /etc/sysctl.d/99-hardening.conf

# Vérifier un paramètre clé
sysctl kernel.randomize_va_space
# Attendu : kernel.randomize_va_space = 2

5. Journalisation d'audit avec auditd

Les logs d'audit sont votre piste forensique. En cas d'incident, auditd vous dit exactement ce qui s'est passé, qui l'a fait, et quand. Configurez-le pour tracer les opérations privilégiées, les modifications de fichiers et les événements d'authentification.

# Installer auditd
sudo dnf install -y audit audit-libs   # RHEL
# sudo apt install -y auditd            # Debian

sudo systemctl enable --now auditd

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

-D
-b 8192
-f 1

# Identité et authentification
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
-w /etc/ssh/sshd_config -p wa -k sshd

# Commandes privilégiées
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands
-w /usr/bin/sudo -p x -k sudo_usage
-w /bin/su -p x -k su_usage

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

# Charger les nouvelles règles
sudo augenrules --load
sudo systemctl restart auditd

# Tester : vérifier l'usage de sudo dans le log d'audit
sudo ausearch -k sudo_usage -ts today | aureport -f -i | head -20

6. Fail2ban et protection anti-brute force

Même avec une auth par clé uniquement, les scanners automatisés vont marteler votre serveur 24h/24. Fail2ban surveille les logs et bannit dynamiquement les contrevenants via des règles de pare-feu.

# Installer fail2ban
sudo dnf install -y fail2ban    # RHEL
# sudo apt install -y fail2ban  # Debian

sudo systemctl enable --now fail2ban

# /etc/fail2ban/jail.d/sshd-custom.conf

[sshd]
enabled  = true
port     = 2222
filter   = sshd
logpath  = %(sshd_log)s
backend  = %(syslog_backend)s
maxretry = 3
bantime  = 3600      ; 1 heure
findtime = 600       ; fenêtre de 10 minutes
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24  ; IPs de gestion en whitelist

# Appliquer et redémarrer
sudo systemctl restart fail2ban

# Surveiller les IPs bannies en temps réel
sudo fail2ban-client status sshd

# Débannir manuellement une IP si nécessaire
sudo fail2ban-client set sshd unbanip 203.0.113.42

7. Mises à jour de sécurité automatiques

Le patching manuel est lent et source d'erreurs. Activez les mises à jour automatiques de sécurité pour que les CVE critiques soient corrigées sans attendre la prochaine fenêtre de maintenance.

RHEL / Rocky Linux (dnf-automatic)

sudo dnf install -y dnf-automatic

# Configurer les mises à jour de sécurité uniquement
sudo sed -i 's/^upgrade_type.*/upgrade_type = security/' /etc/dnf/automatic.conf
sudo sed -i 's/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf

# Activer le timer (s'exécute quotidiennement)
sudo systemctl enable --now dnf-automatic.timer
systemctl status dnf-automatic.timer

Debian / Ubuntu (unattended-upgrades)

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# Vérifier ce qui serait mis à jour
sudo unattended-upgrade --dry-run --debug 2>&1 | grep "Checking"

Checklist de durcissement rapide

Utilisez cette checklist avant de considérer un serveur prêt pour la production :

• ✅ Système entièrement mis à jour, noyau à la dernière version stable (6.18.x LTS ou supporté par la distro)
• ✅ SSH : auth par clé uniquement, pas de root, port personnalisé, chiffrement robuste
• ✅ Pare-feu actif (nftables) : politique DROP par défaut, seuls les ports nécessaires ouverts
• ✅ Durcissement sysctl appliqué : ASLR, SYN cookies, log des martians, restriction ptrace
• ✅ auditd actif avec règles couvrant l'auth, sudo et les fichiers sensibles
• ✅ Fail2ban surveillant SSH et les services exposés
• ✅ Mises à jour automatiques de sécurité activées et vérifiées
• ✅ SELinux/AppArmor en mode enforcing (pas permissive !)
• ✅ Services inutiles désactivés : systemctl list-units --state=running
• ✅ Compte root verrouillé : sudo passwd -l root

Conclusion

Le durcissement d'un serveur Linux en 2026 n'est pas une tâche ponctuelle — c'est une pratique continue. Les vulnérabilités noyau divulguées en mars 2026 rappellent que même les systèmes d'exploitation les plus stables nécessitent une attention constante. Les étapes de ce guide — patching, SSH, pare-feu, paramètres noyau, logs d'audit et mises à jour automatiques — constituent une base de défense en profondeur solide.

Aucune de ces mesures n'est une solution miracle, mais ensemble elles réduisent drastiquement votre surface d'attaque. Un serveur qui se compromet en moins de 5 minutes devient un serveur qui demanderait des mois d'effort soutenu — faisant de vous une cible difficile que les attaquants passeront volontiers.

Prochaines étapes : Intégrez OpenSCAP pour le scan de conformité, ssh-audit pour vérifier votre configuration SSH, et Lynis pour des audits automatisés de durcissement. Ces outils identifieront les lacunes manquantes et vous donneront un score de sécurité mesurable à améliorer dans le temps.