DevSecOps

Hardening Linux pour débutant : guide 2026

Hardening Linux pour débutant 2026 : durcissement système pas à pas, SSH, sudo, firewall, kernel parameters, CIS Benchmarks, outils Lynis et OpenSCAP.

Naim Aouaichia
17 min de lecture
  • Hardening
  • Linux
  • Ubuntu
  • Debian
  • SSH
  • Firewall
  • CIS Benchmark
  • Lynis
  • auditd
  • Débutant

Le hardening Linux désigne l'ensemble des actions de configuration et de durcissement visant à réduire la surface d'attaque d'un système Linux en production. Pour un débutant en 2026, un hardening de base couvre 10 domaines et prend 2-4 heures sur un serveur Ubuntu ou Debian standard : patch management (unattended-upgrades), utilisateurs et sudo (pas de root direct), SSH (clés uniquement, fail2ban), firewall (ufw ou nftables deny par défaut), kernel parameters (sysctl sécu), systemd hardening (services durcis), file system (partitions, permissions), logging et audit (auditd, journald), MAC (AppArmor ou SELinux), désactivation des services inutiles. Les référentiels standardisés sont les CIS Benchmarks (par distribution), le guide ANSSI Hygiène informatique, NIST SP 800-123, DISA STIG. Les outils d'audit dominants 2026 sont Lynis (gratuit, 2-5 min de scan, score sur 100), OpenSCAP (profils de conformité CIS/STIG/ANSSI) et Chef InSpec. Contrairement à une idée reçue, le hardening Linux reste central en 2026 avec Kubernetes : les nodes K8s sont des Linux hosts dont la sécurité conditionne la plateforme entière (voir Container escape : explication). Cet article détaille les 10 domaines avec commandes concrètes pour un débutant, les 7 actions prioritaires premiers 2-4 heures, les outils d'audit, un playbook Ansible type, et les erreurs classiques à éviter.

1. Modèle de menace : pourquoi hardener un serveur Linux

Avant les actions techniques, comprendre les menaces qu'on cherche à contrer.

1.1 Les 5 vecteurs d'attaque dominants 2026

VecteurDescriptionImpact typique
SSH brute-forceBotnets scannant Internet pour tenter des credentials faiblesAccès shell initial
CVE kernel non patchéExploitation d'une vulnérabilité kernel publiquePrivilege escalation local
Services exposés vulnérablesServices sur ports publics avec CVE ou config par défautRCE (Remote Code Execution)
Misconfigurationsudo trop permissif, permissions fichiers laxistesEscalade de privilèges
Supply chainPaquet installé depuis source non-trustedBackdoor persistante

1.2 Chiffres marquants 2024-2026

  • IBM Cost of a Data Breach Report 2024 : breaches via CVE non patchée = 4,17 M$ moyen.
  • Verizon DBIR 2024 : 180 % de hausse de l'exploitation de vulnérabilités comme vecteur initial en 2023-2024.
  • Shodan Q3 2024 : environ 3 millions de serveurs SSH exposés publiquement, dont 15-25 % encore vulnérables à des credentials faibles.
  • CVE kernel Linux : environ 100-150 CVE publiées par an touchant le kernel upstream, plus sévères en privilège escalation.

2. Les 7 actions prioritaires (2-4 heures pour un débutant)

Séquence ordonnée couvrant 80 % du risque pour un débutant.

2.1 Action 1 — Mises à jour et patch management automatique

Ubuntu / Debian

# Mise à jour complète immédiate
sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y
 
# Activation unattended-upgrades (security uniquement)
sudo apt install -y unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
 
# Vérification config (doit inclure les lignes -security)
sudo cat /etc/apt/apt.conf.d/50unattended-upgrades | grep -E "security|Unattended"
 
# Logs
tail -f /var/log/unattended-upgrades/unattended-upgrades.log

RHEL / Rocky / AlmaLinux

sudo dnf update -y
sudo dnf install -y dnf-automatic
 
# Configuration security 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
 
# Activation du timer
sudo systemctl enable --now dnf-automatic.timer

Résultat attendu : patches sécurité appliqués automatiquement sous 24 h, sans intervention manuelle, sans risque de casse majeure (security updates sont audités upstream).

2.2 Action 2 — Utilisateur non-root avec sudo

Création du user et désactivation du login root

# Création user avec sudo
sudo adduser alice
sudo usermod -aG sudo alice  # Debian/Ubuntu
# sudo usermod -aG wheel alice  # RHEL/Rocky
 
# Vérifier l'accès
su - alice
sudo whoami  # doit renvoyer root
 
# Désactiver le login root (après avoir validé sudo pour alice)
sudo passwd -l root
 
# Auditer /etc/sudoers et /etc/sudoers.d/
sudo visudo -c
sudo cat /etc/sudoers.d/*

Règle d'or : jamais alice ALL=(ALL) NOPASSWD: ALL sauf contexte très spécifique. Préférer des sudoers précis par commande autorisée.

2.3 Action 3 — SSH hardening

Vecteur d'attaque numéro un. 90 % du risque vient de la configuration SSH par défaut laxiste.

Configuration /etc/ssh/sshd_config recommandée débutant 2026

# Éditer la config SSH
sudo tee -a /etc/ssh/sshd_config.d/99-hardening.conf << 'EOF'
# Désactiver l'authentification par mot de passe
PasswordAuthentication no
KbdInteractiveAuthentication no
 
# Désactiver login root direct via SSH
PermitRootLogin no
 
# Limiter les users autorisés SSH
AllowUsers alice bob
 
# Limiter les tentatives par connexion
MaxAuthTries 3
 
# Timeout session SSH
ClientAliveInterval 300
ClientAliveCountMax 2
LoginGraceTime 30
 
# Protocoles et algorithmes modernes
Protocol 2
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
 
# Désactiver tunnels et X11 forwarding si non utilisés
X11Forwarding no
AllowTcpForwarding no
GatewayPorts no
PermitTunnel no
EOF
 
# Tester la config avant de reload
sudo sshd -t
 
# Reload sans couper les sessions existantes
sudo systemctl reload sshd

Générer une clé SSH ed25519 côté client et la déployer

# Côté laptop admin
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_serveur
 
# Déployer la clé sur le serveur
ssh-copy-id -i ~/.ssh/id_ed25519_serveur.pub alice@serveur
 
# Tester la connexion
ssh -i ~/.ssh/id_ed25519_serveur alice@serveur

Installer fail2ban contre brute-force

sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.d/sshd.local << 'EOF'
[sshd]
enabled = true
port = 22
maxretry = 3
findtime = 10m
bantime = 24h
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

2.4 Action 4 — Firewall par défaut deny

ufw (Uncomplicated Firewall) Ubuntu

sudo apt install -y ufw
 
# Deny par défaut en entrée, allow en sortie
sudo ufw default deny incoming
sudo ufw default allow outgoing
 
# Autoriser SSH (port 22)
sudo ufw allow 22/tcp
 
# Autoriser les services nécessaires (exemple web)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
 
# Activer
sudo ufw enable
sudo ufw status verbose

nftables (successeur moderne iptables, natif depuis Debian 10, Ubuntu 20.04)

# Exemple de config nftables minimal
sudo tee /etc/nftables.conf << 'EOF'
#!/usr/sbin/nft -f
flush ruleset
 
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif lo accept
    ct state established,related accept
    ct state invalid drop
    ip protocol icmp accept
    tcp dport 22 accept
    tcp dport { 80, 443 } accept
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
  chain output {
    type filter hook output priority 0; policy accept;
  }
}
EOF
 
sudo systemctl enable --now nftables
sudo nft list ruleset

2.5 Action 5 — Désactiver les services non nécessaires

# Lister les services actifs
sudo systemctl list-units --type=service --state=running
 
# Identifier les services non nécessaires (CUPS, Avahi, Bluetooth sur serveur, snapd si non utilisé)
sudo systemctl disable --now cups.service 2>/dev/null
sudo systemctl disable --now avahi-daemon.service 2>/dev/null
sudo systemctl disable --now bluetooth.service 2>/dev/null
 
# Lister les ports en écoute
sudo ss -tulpn
 
# Chaque port ouvert doit être justifié. En cas de doute : disable.

2.6 Action 6 — Audit initial avec Lynis

# Installation
sudo apt install -y lynis
# Ou depuis upstream pour version récente
cd /opt && sudo git clone https://github.com/CISOfy/lynis
cd lynis && sudo ./lynis audit system
 
# Le rapport donne un score (Hardening index) sur 100 et une liste de warnings et suggestions priorisées
# Score cible initial : 70+
# Score cible sous 1 mois : 80+
# Score cible production mature : 85+
 
# Log complet
less /var/log/lynis.log
less /var/log/lynis-report.dat

2.7 Action 7 — Logging et audit initial

journald systemd hardening

# Persistance des logs entre reboots
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
 
# Configuration rétention
sudo tee -a /etc/systemd/journald.conf << 'EOF'
SystemMaxUse=2G
SystemKeepFree=500M
MaxRetentionSec=30day
ForwardToSyslog=yes
Compress=yes
EOF

auditd pour les événements sécurité

sudo apt install -y auditd audispd-plugins
sudo systemctl enable --now auditd
 
# Règles de base (loguer les commandes sudo, modifs /etc, tentatives d'escalade)
sudo tee /etc/audit/rules.d/hardening.rules << 'EOF'
# Fichiers d'authentification
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
 
# SSH config
-w /etc/ssh/sshd_config -p wa -k sshd
 
# Commandes privilégiées
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=-1 -k root-cmd
EOF
 
sudo augenrules --load
sudo systemctl restart auditd
 
# Consulter les events
sudo ausearch -k identity -ts today

3. Les 3 domaines intermédiaires (phase 2, semaines 2-4)

Après les 7 actions prioritaires, montée en maturité progressive.

3.1 Kernel parameters via sysctl

Paramètres kernel pour durcir le comportement réseau et mémoire.

sudo tee /etc/sysctl.d/99-hardening.conf << 'EOF'
# Protection ICMP redirect
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.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
 
# Protection source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
 
# SYN cookies contre SYN flood
net.ipv4.tcp_syncookies = 1
 
# Protection Martian packets (log)
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
 
# Ignorer ICMP echo broadcasts (smurf attack)
net.ipv4.icmp_echo_ignore_broadcasts = 1
 
# ASLR kernel
kernel.randomize_va_space = 2
 
# Protection hardlinks et symlinks contre race conditions
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2
 
# Désactiver coredumps setuid (evite fuite d'infos)
fs.suid_dumpable = 0
 
# Restreindre dmesg aux privileged
kernel.dmesg_restrict = 1
 
# Restreindre ptrace (empêche ptrace across UID arbitraire)
kernel.yama.ptrace_scope = 1
 
# Kexec désactivé (un attaquant root pourrait loader un autre kernel)
kernel.kexec_load_disabled = 1
 
# Désactiver unprivileged user namespaces si non utilisés (containers rootless)
# kernel.unprivileged_userns_clone = 0
EOF
 
sudo sysctl --system

3.2 AppArmor (Ubuntu/Debian) ou SELinux (RHEL)

AppArmor : vérifier qu'il est actif, garder en enforce.

sudo aa-status
# Résultat attendu : profiles are in enforce mode
 
# Si en mode complain, passer en enforce
sudo aa-enforce /etc/apparmor.d/*

SELinux sur RHEL : garder en enforcing.

sudo getenforce  # doit renvoyer Enforcing
sudo setenforce 1  # si permissive, passer enforcing
sudo sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config

3.3 Systemd hardening des services custom

Pour les services applicatifs déployés (ex : une API Node.js ou Python en systemd), durcir l'unit file.

# /etc/systemd/system/myapi.service
[Unit]
Description=My Secure API
After=network.target
 
[Service]
Type=simple
User=myapi
Group=myapi
WorkingDirectory=/opt/myapi
ExecStart=/opt/myapi/venv/bin/python app.py
Restart=on-failure
RestartSec=5s
 
# Hardening systemd
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ReadWritePaths=/opt/myapi/data /var/log/myapi
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=true
ProtectClock=true
ProtectHostname=true
ProtectProc=invisible
ProcSubset=pid
RestrictNamespaces=true
RestrictRealtime=true
RestrictSUIDSGID=true
LockPersonality=true
MemoryDenyWriteExecute=true
SystemCallFilter=@system-service
SystemCallFilter=~@privileged @resources
CapabilityBoundingSet=
AmbientCapabilities=
PrivateDevices=true
PrivateNetwork=false
 
[Install]
WantedBy=multi-user.target

Audit du durcissement d'un service :

systemd-analyze security myapi.service
# Donne un score (lower = better) et liste les propriétés manquantes

4. Les référentiels standardisés à connaître

4.1 CIS Benchmarks (Center for Internet Security)

Le référentiel de facto pour le hardening Linux dans l'entreprise. Disponible gratuitement en PDF sur cisecurity.org/benchmark.

  • CIS Ubuntu Linux 22.04 LTS Benchmark (mise à jour régulière, v2.0.0 2024).
  • CIS Red Hat Enterprise Linux 9 Benchmark.
  • CIS Debian Linux 12 Benchmark.
  • CIS Amazon Linux 2023 Benchmark.

Structure : 2 niveaux (Level 1 server / workstation, Level 2 renforcé). Chaque contrôle numéroté (ex 5.2.1) avec description, audit, remédiation, justification.

Automatisation : OpenSCAP fournit des profils CIS Level 1 et Level 2 scannables en CLI.

4.2 ANSSI Guide d'hygiène informatique

Guide français officiel en 42 règles, version 2024 téléchargeable sur ssi.gouv.fr. Plus concis que CIS, couvre les pratiques fondamentales applicables à toute infrastructure française.

Cible : OIV, OSE, EE/EI sous NIS 2, mais applicable universellement.

4.3 NIST SP 800-123 Guide to General Server Security

Guide US généraliste, moins prescriptif que CIS mais excellent pour comprendre le pourquoi derrière chaque pratique.

4.4 DISA STIG (Security Technical Implementation Guide)

Le plus strict (US Department of Defense). Environ 300-400 contrôles pour RHEL 9 STIG. Overkill pour la plupart des contextes mais référence pour environnements haute sensibilité.

5. Outils d'audit détaillés

5.1 Lynis (recommandé débutant)

Score cible par niveau de maturité

NiveauHardening IndexDurée typique
Installation par défaut Ubuntu/Debian50-60
Après quick wins 2-4h débutant70-75J+1
Après hardening intermédiaire 2 semaines80-85Semaine 2-4
Production mature conforme CIS L185-90Mois 2-6
Haute sensibilité CIS L2 ou STIG90+Chantier dédié

Interprétation des findings : Warning = action prioritaire, Suggestion = à traiter en second temps. Ne pas chercher le score 100 (certaines suggestions ne s'appliquent pas à tous les contextes).

5.2 OpenSCAP

# Installation
sudo apt install -y libopenscap8 openscap-scanner ssg-base
# Sur RHEL : sudo dnf install -y openscap-scanner scap-security-guide
 
# Lister les profils disponibles
oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml
 
# Scan avec profil CIS Level 1 Server
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results /tmp/ssg-results.xml \
  --report /tmp/ssg-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml
 
# Ouvrir le rapport HTML
xdg-open /tmp/ssg-report.html

5.3 Chef InSpec (automation CI)

Framework de tests de conformité scriptables, idéal en CI.

# example.rb - test InSpec basique
control 'ssh-01' do
  impact 1.0
  title 'SSH root login must be disabled'
  describe sshd_config do
    its('PermitRootLogin') { should eq 'no' }
  end
end
 
control 'ssh-02' do
  impact 1.0
  title 'SSH PasswordAuthentication must be disabled'
  describe sshd_config do
    its('PasswordAuthentication') { should eq 'no' }
  end
end

Exécution : sudo inspec exec example.rb.

6. Playbook Ansible type

Pour industrialiser le hardening sur plusieurs serveurs.

# hardening.yml - playbook Ansible minimal
- hosts: linux_servers
  become: true
 
  tasks:
    - name: Apt update and upgrade
      apt:
        update_cache: yes
        upgrade: dist
        autoremove: yes
 
    - name: Install security packages
      apt:
        name:
          - unattended-upgrades
          - fail2ban
          - ufw
          - auditd
          - apparmor
          - apparmor-utils
        state: present
 
    - name: Enable unattended-upgrades
      systemd:
        name: unattended-upgrades
        enabled: yes
        state: started
 
    - name: Configure sshd hardening
      blockinfile:
        path: /etc/ssh/sshd_config.d/99-hardening.conf
        create: yes
        mode: "0644"
        block: |
          PasswordAuthentication no
          PermitRootLogin no
          MaxAuthTries 3
          ClientAliveInterval 300
          X11Forwarding no
      notify: reload sshd
 
    - name: Deploy hardened sysctl
      copy:
        dest: /etc/sysctl.d/99-hardening.conf
        content: |
          net.ipv4.conf.all.accept_redirects = 0
          net.ipv4.tcp_syncookies = 1
          kernel.randomize_va_space = 2
          kernel.yama.ptrace_scope = 1
          fs.protected_symlinks = 1
          fs.protected_hardlinks = 1
      notify: reload sysctl
 
    - name: Configure UFW
      ufw:
        state: enabled
        policy: deny
        logging: "on"
 
    - name: Allow SSH
      ufw:
        rule: allow
        port: "22"
        proto: tcp
 
    - name: Enable fail2ban
      systemd:
        name: fail2ban
        enabled: yes
        state: started
 
    - name: Enable auditd
      systemd:
        name: auditd
        enabled: yes
        state: started
 
  handlers:
    - name: reload sshd
      systemd:
        name: sshd
        state: reloaded
 
    - name: reload sysctl
      command: sysctl --system

Pour production, des rôles Ansible existants : dev-sec/ansible-collection-hardening (projet communautaire maintenu depuis 2014), OpenSCAP Ansible content.

7. Checklist débutant 30 contrôles

checklist_hardening_linux_debutant = {
    # Patch management
    "mises_a_jour_immediates": "apt upgrade ou dnf update exécuté",
    "unattended_upgrades_actif": "Mises à jour sécurité automatiques activées",
    "reboot_apres_kernel": "Reboot planifié si mise à jour kernel",
 
    # Utilisateurs et sudo
    "user_non_root": "User non-root créé avec sudo",
    "root_login_disabled": "passwd -l root appliqué",
    "sudoers_audite": "sudoers propre, pas de NOPASSWD abusif",
 
    # SSH
    "ssh_password_auth_off": "PasswordAuthentication no",
    "ssh_root_login_off": "PermitRootLogin no",
    "ssh_key_ed25519": "Clé SSH ed25519 déployée",
    "fail2ban_actif": "fail2ban activé sur sshd",
    "ssh_max_auth_tries": "MaxAuthTries 3",
 
    # Firewall
    "firewall_deny_default": "Firewall policy deny par défaut",
    "firewall_ports_justifies": "Chaque port ouvert justifié",
 
    # Kernel sysctl
    "sysctl_hardening_deploy": "99-hardening.conf déployé",
    "aslr_active": "kernel.randomize_va_space = 2",
    "ptrace_scope": "kernel.yama.ptrace_scope = 1",
 
    # MAC
    "apparmor_selinux_enforce": "AppArmor ou SELinux en enforce/enforcing",
 
    # Services
    "services_inutiles_off": "CUPS, Avahi, Bluetooth désactivés si non utilisés",
    "ports_ecoute_audits": "ss -tulpn review, chaque port justifié",
 
    # Logging
    "auditd_actif": "auditd installé et running",
    "journald_persistent": "journald logs persistants configurés",
    "retention_logs_30j": "Retention logs 30 jours minimum",
 
    # Systemd hardening services custom
    "services_no_new_privs": "NoNewPrivileges=true sur services applicatifs",
    "services_private_tmp": "PrivateTmp=true sur services applicatifs",
 
    # File system
    "permissions_sensitive_files": "chmod 600 /etc/shadow, /etc/gshadow",
    "tmp_noexec_option": "Montage /tmp avec noexec,nosuid,nodev si possible",
 
    # Audit outils
    "lynis_score_70": "Score Lynis supérieur à 70",
    "openscap_cis_l1_scan": "Scan OpenSCAP CIS Level 1 exécuté",
 
    # Documentation
    "runbook_baseline": "Runbook baseline documenté en markdown",
    "changes_tracked_git": "Config /etc trackée en Git (etckeeper ou Ansible)",
}
 
# Viser 25 plus sur 30 en débutant

8. Erreurs classiques à éviter

Erreur 1 — Désactiver SELinux ou AppArmor

Le pattern toxique numéro un. Solution : passer en permissive temporairement pour debugger, générer les policies manquantes, repasser en enforce.

Erreur 2 — Changer le port SSH vers 2222 comme "sécurité"

Security by obscurity inutile. Les scanners modernes testent tous les ports en quelques heures. Garder SSH 22 avec auth clés + fail2ban + MaxAuthTries 3 est supérieur au changement de port.

Erreur 3 — Ajouter 100 règles iptables custom

Les règles complexes deviennent vite non maintenables et introduisent des failles. Préférer nftables ou ufw simple, quelques règles claires et documentées.

Erreur 4 — Oublier la revue régulière

Un serveur hardené en J0 dérive en 6 mois (nouveaux services installés, patches manqués, règles ajoutées à la volée). Scan Lynis mensuel + revue Git config + audit trimestriel minimum.

Erreur 5 — Hardening sans backups testés

Un hardening agressif peut casser des applications ou bloquer l'accès admin. Toujours tester sur staging, snapshotter avant, documenter les rollbacks.

Erreur 6 — Ignorer les containers sur le node

Hardener le host mais laisser les containers en privileged annule une grande partie du bénéfice. Voir Container escape : explication pour la complémentarité.

Erreur 7 — Confondre hardening et conformité

Un score Lynis 90 n'est pas équivalent à une certification ISO 27001 ou SOC 2. Le hardening contribue à la conformité mais ne la remplace pas (processus, documentation, revues formelles exigés).

Points clés à retenir

  • Hardening Linux = réduction de surface d'attaque par configuration, couvre 10 domaines (patch, users, SSH, firewall, sysctl, systemd, FS, logs, MAC, services).
  • Les 7 actions prioritaires 2-4 heures débutant : mises à jour + unattended-upgrades, user non-root + sudo + désactivation login root, SSH clés + fail2ban + PermitRootLogin no, firewall deny par défaut, désactivation services inutiles, audit Lynis initial, logging auditd.
  • Patch management est l'action numéro un absolue : un serveur non patché depuis 6 mois est plus vulnérable qu'un serveur mal hardené mais patché en 48h.
  • Référentiels 2026 : CIS Benchmarks (par distribution, dominant), ANSSI Guide Hygiène informatique (France), NIST SP 800-123, DISA STIG (haute sensibilité).
  • Outils d'audit : Lynis (gratuit, score sur 100, accessible débutant), OpenSCAP (profils CIS/STIG), Chef InSpec (tests scriptables en CI).
  • Scores Lynis cibles : 70+ après 2-4h, 80+ sous 1 mois, 85+ production mature, 90+ CIS L2 ou STIG.
  • Jamais désactiver AppArmor/SELinux : utiliser permissive puis audit2allow au lieu de disabled.
  • Industrialisation Ansible : rôles communautaires dev-sec/ansible-collection-hardening et OpenSCAP Ansible content.
  • Nodes Kubernetes = Linux hosts : hardening OS reste fondamental même en environnement cloud native (voir Container escape : explication).

Pour aller plus loin

Questions fréquentes

  • Qu'est-ce que le hardening Linux concrètement ?
    Le hardening Linux désigne l'ensemble des actions de configuration et de durcissement visant à réduire la surface d'attaque d'un système Linux en production. Il couvre 10 domaines principaux : mises à jour et patch management, gestion des utilisateurs et sudo, SSH, firewall, kernel parameters via sysctl, systemd hardening des services, file system et permissions, logging et audit via auditd, MAC (AppArmor ou SELinux), désactivation des services non nécessaires. Les référentiels standardisés sont les CIS Benchmarks (par distribution), le guide ANSSI Hygiène informatique, NIST SP 800-123, DISA STIG. Un hardening de base prend 2-4 heures pour un débutant sur un serveur Ubuntu ou Debian standard, utilise des outils comme Lynis et OpenSCAP pour l'audit, et peut être automatisé via Ansible.
  • Par où commencer pour hardener un serveur Linux en 2026 ?
    Les 7 actions prioritaires dans l'ordre. 1) Mises à jour complètes et activation unattended-upgrades pour les patches sécurité automatiques. 2) Création d'un user non-root avec sudo, désactivation du login root direct. 3) SSH : clés uniquement (pas password auth), port 22 standard gardé mais avec fail2ban, désactivation root login SSH. 4) Firewall ufw ou nftables : deny par défaut, allow seulement les ports nécessaires. 5) Désactivation des services non utilisés via systemctl disable. 6) Audit avec Lynis pour obtenir un score de base et une liste de recommandations priorisées. 7) Activation d'auditd pour le logging des événements sécurité. Ces 7 actions couvrent 80 pourcent du risque débutant pour 2-4 heures de travail. Les étapes suivantes (AppArmor fin, kernel sysctl avancé, CIS Benchmark complet) sont progressives sur semaines.
  • Faut-il utiliser SELinux ou AppArmor ?
    Les deux sont des Mandatory Access Control (MAC) et offrent un niveau de sécurité comparable en durcissement ciblé. Le choix dépend principalement de la distribution. SELinux : natif sur RHEL, CentOS, Rocky Linux, AlmaLinux, Fedora, Amazon Linux. Plus fin (3 niveaux : user, role, type), plus difficile à configurer (policies complexes). Mode permissive possible pour observer sans bloquer. AppArmor : natif sur Ubuntu, Debian, SUSE. Profils par application, syntaxe plus simple et accessible. Recommandation débutant 2026 : ne pas désactiver ce qui est fourni par défaut. Sur Ubuntu/Debian, garder AppArmor activé avec profils par défaut. Sur RHEL, garder SELinux en enforcing. Passer en permissive uniquement pour débuguer, jamais en disabled en production. Le passage à SELinux strict ou AppArmor complet par application est un chantier senior, pas un prérequis débutant.
  • Quels outils utiliser pour auditer le hardening d'un serveur ?
    Trois outils dominent en 2026. 1) Lynis (CISOfy, open source gratuit) : le plus accessible, scan complet en 2-5 minutes, donne un score de hardening sur 100 et liste les recommandations priorisées. Utilisation simple : `apt install lynis && lynis audit system`. 2) OpenSCAP (Red Hat, open source) : scan vs profils de conformité standardisés (CIS, STIG, ANSSI). Plus complet mais plus complexe. Utilisation : `oscap xccdf eval --profile cis_level1_server ...`. 3) Chef InSpec ou kube-bench pour Kubernetes : framework de tests de conformité scriptables, idéal en CI. Pour un débutant, démarrer Lynis en semaine 1 (score cible initial 70 plus, objectif 80 plus en 1 mois), puis ajouter OpenSCAP pour valider conformité formelle. Les outils premium (Tenable Nessus, Qualys VMDR) offrent des scans similaires avec dashboards entreprise.
  • Les mises à jour automatiques sont-elles dangereuses ?
    Non en 2026 pour les patches sécurité, oui pour les major version upgrades. Le compromis standard : activer unattended-upgrades sur Ubuntu ou dnf-automatic sur RHEL, limité aux security updates uniquement. Configuration Ubuntu : éditer /etc/apt/apt.conf.d/50unattended-upgrades pour n'inclure que -security repositories, pas les -updates complets. Les risques théoriques (patch qui casse une app) sont faibles sur les security updates modernes, les risques réels (serveur non patché exposé à CVE connues) sont documentés dans 60-70 pourcent des breaches IBM Cost of a Data Breach 2024 et Verizon DBIR 2024. Le ratio risque/bénéfice penche clairement vers l'activation automatique. Pour les workloads critiques, faire les security updates automatiquement en staging d'abord (1-7 jours de décalage) puis prod.
  • Le hardening Linux est-il pertinent en 2026 avec Kubernetes et containers partout ?
    Oui, absolument. Deux raisons. 1) Les nodes Kubernetes sont des Linux hosts qui hébergent les containers : leur hardening conditionne la sécurité de toute la plateforme. Un node mal hardené est un point d'entrée pour un escape container (voir [Container escape : explication](/ressources/devsecops/container-escape-explication)), même si les pods sont restricted. 2) Les serveurs Linux restent massivement utilisés hors containers : VMs cloud, bastions SSH, serveurs bare-metal, bases de données managées, edge computing. Le CIS Benchmark Kubernetes et le CIS Benchmark Linux sont complémentaires : un cluster K8s sécurisé sur un node non hardené est vulnérable. Les bonnes pratiques hardening OS Linux sont **toujours la fondation** d'un stack cloud-native sécurisé 2026.

Écrit par

Naim Aouaichia

Expert cybersécurité et fondateur de Zeroday Cyber Academy

Expert cybersécurité avec un master spécialisé et un parcours hybride : développement, DevOps, DevSecOps, SOC, GRC. Fondateur de Hash24Security et Zeroday Cyber Academy. Formateur et créateur de contenu technique sur la cybersécurité appliquée, la sécurité des LLM et le DevSecOps.