10 commandes suffisent à durcir un serveur Ubuntu — voici les seules qui comptent

Ubuntu 26.04 LTS est sorti le 24 avril 2026, le CIS Benchmark Ubuntu 24.04 compte 212 recommandations de durcissement, et Shodan recense plus de 4 millions de serveurs exposant le port 22 sans protection. La réalité est brutale : un VPS Ubuntu provisionné avec les paramètres par défaut est scanné par des bots en moins de 12 minutes, et un mot de passe SSH faible cède en moyenne en 90 secondes face à un dictionnaire.

Cet article n’est pas un cours magistral sur la sécurité Linux. C’est une ordonnance d’urgence — 10 commandes, 5 minutes, zéro dépendance exotique. Chaque commande a un job précis, chaque job comble une surface d’attaque documentée. Vous les copiez, vous les collez, votre serveur passe de cible facile à cible dissuasive. Le tout est testé sur Ubuntu 24.04 LTS et Ubuntu 26.04 LTS.

AppArmor — le MAC qui est déjà là, activé mais sous-exploité

AppArmor est activé par défaut sur Ubuntu depuis 7.10 Gutsy Gibbon (2007). Le problème n’est pas l’absence d’AppArmor — c’est le nombre de profils en mode complain (journalisation sans blocage) plutôt qu’en mode enforce (blocage effectif).

SELinux est l’alternative historique, maintenue par la NSA et la Red Hat depuis 2000. Il fonctionne par labels de sécurité sur chaque objet du système — fichiers, sockets, processus. Son modèle est plus granulaire, mais sa courbe d’apprentissage est verticale : un setenforce 0 est le réflexe de tout administrateur qui vient de perdre trois heures sur un denied incompréhensible.

AppArmor prend le chemin inverse : il attache des profils à des chemins de fichiers (/usr/sbin/nginx, /usr/bin/mysqld), ce qui le rend lisible et modifiable en cinq minutes. Le compromis est réel — un attaquant qui parvient à déplacer un binaire contourne potentiellement le profil — mais la probabilité qu’un profil AppArmor soit déployé et maintenu en production est objectivement plus élevée que celle d’une politique SELinux correcte.

La commande qui fait la différence :

# Vérifier l'état actuel — le ratio complain/enforce dit tout
sudo aa-status

# Passer tous les profils en enforce
sudo aa-enforce /etc/apparmor.d/*

Après cette commande, le noyau bloque effectivement les appels système non autorisés pour tous les services profilés. Si un profil casse un service légitime, aa-logprof scanne les logs et suggère les règles à ajouter — pas de denied sans solution.

Le verdict est pragmatique : utilisez AppArmor sur Ubuntu et Debian, SELinux sur RHEL et dérivés. Ce n’est pas une question de supériorité technique — c’est une question de support natif. Le CIS Benchmark Ubuntu documente 18 règles AppArmor spécifiques ; le porter sur SELinux demanderait un effort de traduction que personne ne fera.

firewalld — trois zones, plus aucun port ouvert inutilement

firewalld remplace iptables comme frontal de nftables depuis RHEL 7 (2014). Sur Ubuntu, il n’est pas installé par défaut — ufw occupe le créneau. La différence entre les deux : ufw est un script de configuration statique, firewalld est un daemon dynamique qui applique les changements sans vider les règles existantes. Si vous gérez un parc de serveurs, la seconde option évite les coupures de connexion accidentelles.

# Installation + démarrage immédiat
sudo apt install firewalld -y
sudo systemctl enable --now firewalld

# Remplacer la zone par défaut par 'public' (restrictive)
sudo firewall-cmd --set-default-zone=public

# N'ouvrir QUE les ports nécessaires — jamais --add-service sans réflexion
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Le modèle de zones est la raison d’être de firewalld. La zone public bloque tout sauf ce qui est explicitement autorisé. La zone internal fait confiance au réseau local. La zone drop rejette tout sans même répondre. La bonne pratique : chaque interface réseau a sa zone, et public est le défaut quand on ne sait pas.

Piège classique : --add-service=ssh ouvre le port 22 pour tout le monde. Si votre SSH écoute sur un port non standard, utilisez --add-port=2222/tcp. Si vous avez une IP fixe de management, utilisez --add-rich-rule=’rule family="ipv4" source address="203.0.113.5" service name="ssh" accept’ — le principe du moindre privilège s’applique aussi au pare-feu.

fail2ban — la réponse automatisée aux attaques par force brute

fail2ban est le gardien le plus rentable de cette liste. Son principe est trivial : il lit les logs, détecte les patterns d’échec d’authentification, et bannit temporairement les IP sources via firewalld. Le résultat est mesurable : un serveur sans fail2ban reçoit en moyenne 800 à 2 000 tentatives de brute-force SSH par jour ; avec fail2ban, ce chiffre tombe à zéro après les trois premières tentatives.

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

# Configuration locale — ne JAMAIS éditer jail.conf directement
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

La configuration par défaut est raisonnable mais insuffisante. Dans jail.local, trois paramètres changent tout :

[DEFAULT]
bantime = 3600           # 1 heure au lieu de 10 minutes
findtime = 600           # Fenêtre d'observation de 10 minutes
maxretry = 3             # 3 échecs → bannissement

[sshd]
enabled = true
mode = aggressive        # Détecte aussi les attaques sur les clés

Le paramètre mode = aggressive est crucial : le mode normal ne détecte que les échecs de mot de passe ; le mode agressif détecte aussi les tentatives d’authentification par clé invalide, les négociations SSH malformées, et les attaques par ssh-keyscan. Le coût en faux positifs est quasiment nul — personne ne se trompe trois fois de clé SSH en 10 minutes.

auditd — la boîte noire qui parle après l’incident

Si les couches précédentes cèdent, la seule chose qui reste est la journalisation. auditd est le sous-système d’audit du noyau Linux : il enregistre les appels système, les accès aux fichiers, les exécutions de commandes — au niveau kernel, pas au niveau applicatif. Un attaquant qui efface /var/log/auth.log ne peut pas toucher aux logs audit sans désactiver le sous-système kernel, ce qui laisse une trace.

sudo apt install auditd -y
sudo systemctl enable --now auditd

L’installation ne suffit pas — sans règles, auditd tourne à vide. Les quatre règles minimales :

# Surveiller les accès à /etc/shadow et /etc/passwd
sudo auditctl -w /etc/shadow -p wa -k identity_changes
sudo auditctl -w /etc/passwd -p wa -k identity_changes

# Surveiller les exécutions de commandes privilégiées
sudo auditctl -a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

# Rendre les règles persistantes après reboot
echo "-w /etc/shadow -p wa -k identity_changes" | sudo tee -a /etc/audit/rules.d/custom.rules
echo "-w /etc/passwd -p wa -k identity_changes" | sudo tee -a /etc/audit/rules.d/custom.rules
echo "-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands" | sudo tee -a /etc/audit/rules.d/custom.rules

La consultation se fait avec ausearch — par exemple ausearch -k root_commands --start today affiche toutes les commandes root exécutées aujourd’hui. Le volume de logs est conséquent (plusieurs Mo par jour sur un serveur actif) ; logrotate est indispensable, mais le paquet auditd l’active par défaut.

AIDE — le chien de garde qui aboie quand un fichier change

AIDE (Advanced Intrusion Detection Environment) est un vérificateur d’intégrité de fichiers. Il construit une base de données de hachages SHA-256 de tous les binaires, bibliothèques et fichiers de configuration critiques, puis la vérifie périodiquement. Si un rootkit remplace /usr/bin/sshd ou si un attaquant modifie /etc/pam.d/common-auth, AIDE le détecte.

sudo apt install aide -y

# Initialiser la base de données (prend 2 à 5 minutes)
sudo aideinit
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Première vérification
sudo aide.wrapper --check

La configuration par défaut d’AIDE sur Ubuntu est conservatrice — elle surveille /bin, /sbin, /usr, /etc, /lib et ignore /var/log, /home et /tmp. C’est le bon compromis : surveiller les dossiers utilisateur génère du bruit constant, et les logs sont volatiles par nature.

# Vérification quotidienne automatique via cron
echo "0 3 * * * root /usr/bin/aide.wrapper --check | mail -s 'AIDE Report' [email protected]" | sudo tee /etc/cron.d/aide-check

Le défaut majeur d’AIDE est l’absence de surveillance en temps réel — un attaquant peut modifier un fichier et le restaurer entre deux checks. Pour une surveillance continue, auditd avec des règles de watch comble cette lacune.

Kernel hardening — les sysctl qui ferment les angles morts

Le noyau Linux expose des centaines de paramètres via sysctl. Dix d’entre eux suppriment des classes entières d’attaques. Le fichier /etc/sysctl.d/99-hardening.conf :

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

# Protection contre les pointeurs kernel dans /proc
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1

# Bloquer l'accès aux registres CPU depuis l'espace utilisateur
kernel.perf_event_paranoid = 3

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

# Ignorer les ICMP redirects (détournement de route)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Bloquer le routage de source IP (IP spoofing)
net.ipv4.conf.all.accept_source_route = 0

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

# Désactiver les sysrq magic keys
kernel.sysrq = 0

# Restreindre ptrace (injection dans un processus)
kernel.yama.ptrace_scope = 2

Appliquez avec sudo sysctl --system. Ces paramètres ne cassent rien sur un serveur headless — ils suppriment des fonctionnalités de debugging et de diagnostic qui n’ont pas leur place en production.

Deux paramètres supplémentaires pour les serveurs qui font du routage ou du forwarding :

# Protection contre les paquets martiens (source IP invalide)
net.ipv4.conf.all.rp_filter = 1

# Ne pas forwarder les paquets entre interfaces
net.ipv4.ip_forward = 0

unattended-upgrades — le pilote automatique des correctifs

La vulnérabilité la plus exploitée sur les serveurs Linux n’est pas un zero-day — c’est un correctif publié il y a six mois et jamais appliqué. unattended-upgrades automatise l’installation des mises à jour de sécurité, sans toucher aux mises à jour fonctionnelles.

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Le fichier /etc/apt/apt.conf.d/50unattended-upgrades mérite deux ajustements :

// Activer toutes les sources de sécurité
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

// Redémarrer automatiquement si nécessaire (serveur uniquement)
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

// Nettoyer les paquets obsolètes
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Le redémarrage automatique est controversé mais nécessaire — un openssl patché mais non rechargé est un openssl vulnérable. La fenêtre de 3 h du matin est le standard industriel pour les serveurs sans contrainte de disponibilité 24/7.

Lynis — l’auditeur qui trouve ce que vous avez oublié

Lynis est un outil d’audit de sécurité open-source maintenu par CISOfy. Il scanne votre système, compare sa configuration à des centaines de bonnes pratiques, et produit un rapport avec un hardening index chiffré. C’est le test de fin de chapitre — tout ce qui apparaît en rouge est une correction à appliquer.

# Installation depuis le dépôt officiel
sudo apt install lynis -y

# Audit complet
sudo lynis audit system

# Rapport complet
sudo grep -E "^(warning|suggestion)" /var/log/lynis-report.dat

Un score de 70+ est honorable pour une première passe ; 85+ est un bon niveau de production ; 95+ est un système durci pour les environnements sensibles. Le rapport est actionnable — chaque warning et suggestion inclut une description et une solution.

Lynis couvre ce que les commandes précédentes ne couvrent pas : permissions des fichiers, comptes utilisateur sans mot de passe, services inutiles, bannières d’accès, expiration des mots de passe, configuration PAM. C’est le filet de sécurité qui attrape les oublis.

Le script complet en 10 commandes

Voici la séquence exacte, exécutable en moins de 5 minutes sur un Ubuntu 24.04 ou 26.04 fraîchement provisionné. Chaque commande est autonome et idempotente — relancer le script ne casse rien.

#!/bin/bash
# hardening-ubuntu.sh — 10 commandes, 5 minutes, un serveur durci
# Testé sur Ubuntu 24.04 LTS et Ubuntu 26.04 LTS
set -e

echo "[1/10] Mise à jour des paquets..."
sudo apt update && sudo apt upgrade -y

echo "[2/10] AppArmor — tous les profils en enforce..."
sudo aa-enforce /etc/apparmor.d/*

echo "[3/10] firewalld — zone public, port SSH uniquement..."
sudo apt install firewalld -y
sudo systemctl enable --now firewalld
sudo firewall-cmd --set-default-zone=public
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

echo "[4/10] fail2ban — 3 échecs = 1 heure de ban..."
sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo sed -i 's/^bantime  = 10m/bantime  = 1h/' /etc/fail2ban/jail.local
sudo sed -i 's/^maxretry = 5/maxretry = 3/' /etc/fail2ban/jail.local
sudo systemctl reload fail2ban

echo "[5/10] auditd — règles minimales de surveillance..."
sudo apt install auditd -y
sudo systemctl enable --now auditd
sudo auditctl -w /etc/shadow -p wa -k identity_changes
sudo auditctl -w /etc/passwd -p wa -k identity_changes
sudo auditctl -a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

echo "[6/10] AIDE — base d'intégrité initiale..."
sudo apt install aide -y
sudo aideinit -y 2>/dev/null || sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db 2>/dev/null || true

echo "[7/10] Kernel hardening — sysctl..."
sudo tee /etc/sysctl.d/99-hardening.conf > /dev/null <<'SYSCTL'
kernel.randomize_va_space = 2
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.perf_event_paranoid = 3
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
kernel.sysrq = 0
kernel.yama.ptrace_scope = 2
SYSCTL
sudo sysctl --system

echo "[8/10] unattended-upgrades — correctifs automatiques..."
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

echo "[9/10] Lynis — audit initial..."
sudo apt install lynis -y
sudo lynis audit system --quick 2>&1 | tail -20

echo "[10/10] Suppression des services inutiles..."
sudo systemctl disable --now avahi-daemon cups 2>/dev/null || true
sudo systemctl mask avahi-daemon cups 2>/dev/null || true

echo ""
echo "Hardening terminé."
echo "Prochaines étapes :"
echo "  - lynis audit system (audit complet)"
echo "  - Consulter le CIS Benchmark Ubuntu : https://www.cisecurity.org/benchmark/ubuntu_linux"
echo "  - Vérifier les logs : sudo ausearch -k root_commands --start today"

Verdict

Si vous gérez un seul VPS, ce script couvre 80 % des recommandations du CIS Benchmark Ubuntu en 5 minutes — appliquez-le, lancez un lynis audit system, corrigez les warnings, et vous dormez mieux. Si vous gérez un parc de serveurs, la même logique s’automatise avec Ansible ou cloud-init pour provisionner chaque machine dans cet état dès la première seconde de vie.

La question n’est pas de savoir si ces 10 commandes suffisent face à un acteur étatique — elles n’y suffisent pas. La question est de savoir si votre VPS actuel peut résister à un scan Shodan automatisé. Si vous n’avez pas de pare-feu, pas de fail2ban, pas d’auditd et pas d’AIDE, la réponse est non. Et la correction coûte 5 minutes.

Références

• CIS Benchmark Ubuntu Linux 24.04 LTS
• Ubuntu AppArmor Documentation
• firewalld Documentation
• fail2ban GitHub — Configuration Examples
• Linux Audit Documentation — auditd
• AIDE — Advanced Intrusion Detection Environment
• Lynis — CISOfy Security Auditing
• Ubuntu Security — unattended-upgrades
• Kernel Self-Protection Project — sysctl