🛡️ Hardening Linux — Surface d'attaque & Séance 1

🎯 Objectifs pédagogiques

• Décrire ce qu'est la surface d'attaque d'un système et comment la réduire
• Appliquer le principe du moindre privilège aux services et aux fichiers système
• Identifier les services inutiles et les désactiver avec systemd
• Sécuriser une configuration SSH (port, root login, authentification par clé)
• Installer et configurer Fail2ban pour protéger SSH
• Utiliser Lynis pour auditer et mesurer l'amélioration du durcissement

🔥 Accroche — L'affaire SolarWinds (2020)

En 2020, des attaquants ont compromis le système de build de SolarWinds et injecté un malware dans une mise à jour parfaitement légitime. Plus de 18 000 organisations ont été touchées, dont des agences gouvernementales américaines. L'accès initial a été facilité par des services exposés et des credentials faibles dans des environnements de build. Un durcissement basique — désactivation des services non nécessaires, séparation des comptes, credentials forts — aurait drastiquement réduit la surface d'attaque et limité la propagation.

📖 Section 1 — Concept de durcissement et surface d'attaque

Le durcissement (hardening) d'un système consiste à réduire autant que possible les éléments accessibles à un attaquant. La surface d'attaque désigne l'ensemble des vecteurs potentiels qu'un attaquant peut cibler :

• Ports réseau ouverts et services exposés
• Comptes utilisateurs valides et mal protégés
• Fichiers et répertoires accessibles en écriture
• Protocoles non chiffrés
• Scripts et jobs automatisés vulnérables

Désactiver les services inutiles avec systemd

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

# Identifier les services à désactiver (bluetooth, cups, avahi)
sudo systemctl disable --now bluetooth
sudo systemctl disable --now cups  # Impression — inutile sur un serveur

# Vérifier qu'il ne redémarre pas au boot
systemctl is-enabled bluetooth  # Doit afficher "disabled"

Audit des ports ouverts

Il est essentiel de savoir quels processus écoutent sur le réseau, avec leurs ports et binaire associé :

# Voir tous les ports en écoute avec le processus associé
ss -tlnp
# Ou, si net-tools est installé
netstat -tlnp

# Sortie exemple :
# tcp   0.0.0.0:22    LISTEN   sshd     ← SSH (garder)
# tcp   0.0.0.0:25    LISTEN   postfix  ← Mail (désactiver si inutile)
# tcp   0.0.0.0:111   LISTEN   rpcbind  ← NFS (désactiver si inutile)

Permissions des fichiers critiques

Les permissions attendues sont strictes pour les fichiers sensibles. Les binaires SUID/SGID posent des risques particuliers car ils permettent à un utilisateur non privilégié d'exécuter un binaire avec des droits accrus.

# Droits attendus sur les fichiers sensibles
ls -la /etc/passwd   # -rw-r--r-- (644)
ls -la /etc/shadow   # -rw-r----- (640)
ls -la /etc/sudoers  # -r--r----- (440)

# Trouver tous les fichiers SUID root (à auditer)
find / -perm -4000 -user root -type f 2>/dev/null

📖 Section 2 — Configuration SSH sécurisée et Fail2ban

SSH est l'un des services les plus exposés et paradoxalement l'un des plus mal configurés. Les directives importantes de /etc/ssh/sshd_config :

# /etc/ssh/sshd_config — directives à modifier
Port 2222                    # Changer le port (réduit le "bruit" des scans)
PermitRootLogin no           # Interdire le login direct en root
PasswordAuthentication no    # Préférer les clés aux mots de passe
PubkeyAuthentication yes
MaxAuthTries 3               # 3 tentatives max avant déconnexion
LoginGraceTime 30            # 30 secondes pour s'authentifier
AllowUsers deployer admin    # Whitelist d'utilisateurs autorisés
X11Forwarding no             # Désactiver le forwarding graphique

Génération et déploiement de clés SSH

# Côté client — générer une paire de clés Ed25519 (recommandé)
ssh-keygen -t ed25519 -C "admin@innovattech.fr"

# Copier la clé publique sur le serveur
ssh-copy-id -i ~/.ssh/id_ed25519.pub deployer@debian-srv01

Fail2ban — protection contre les tentatives de force brute

Fail2ban surveille les logs et bannit automatiquement les IPs faisant trop d'échecs d'authentification. Ce n'est pas une solution miracle mais une protection de mitigation efficace.

sudo apt update && sudo apt install -y fail2ban

# Créer /etc/fail2ban/jail.local
# [sshd]
# enabled = true
# maxretry = 5
# bantime = 3600
# findtime = 600

sudo systemctl enable --now fail2ban

# Vérifier les IPs bannies
sudo fail2ban-client status sshd

🛠️ TP — Audit et durcissement de debian-srv01 (85 min)

Scénario : InnovatTech SARL a monté rapidement un serveur Debian 12 "debian-srv01" avec une configuration fonctionnelle mais non sécurisée. Vous êtes l'équipe d'exploitation chargée d'auditer le serveur, d'identifier les problèmes critiques et d'appliquer 5 corrections mesurables.

Vulnérabilités simulées :

• SSH autorise la connexion directe en root (PermitRootLogin yes)
• SSH accepte l'authentification par mot de passe
• Le service cups (impression) est actif sans utilité
• Le service rpcbind est actif (NFS non utilisé)
• /etc/shadow a des permissions trop permissives (644 au lieu de 640)
• Fail2ban n'est pas installé

Étape 1 — Audit initial avec Lynis

sudo apt update && sudo apt install -y lynis
sudo lynis audit system --report-file /tmp/lynis-rapport-before.txt
grep -i "hardening index" /tmp/lynis-rapport-before.txt || true

Étape 2 — Correction 1 : Sécuriser SSH

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl restart ssh
# Vérification
sudo grep -E "PermitRootLogin|PasswordAuthentication" /etc/ssh/sshd_config

Étape 3 — Corrections 2 & 3 : Désactiver cups et rpcbind

sudo systemctl disable --now cups
systemctl is-enabled cups   # → disabled
ss -tlnp | grep -E ":631\b" || echo "CUPS not listening"

sudo systemctl disable --now rpcbind
ss -tlnp | grep -E ":111\b" || echo "rpcbind not listening"

Étape 4 — Correction 4 : Permissions /etc/shadow

sudo chown root:shadow /etc/shadow
sudo chmod 640 /etc/shadow
# Vérification — sortie attendue : -rw-r-----  root shadow
ls -l /etc/shadow

Étape 5 — Correction 5 : Installer Fail2ban

sudo apt update && sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[sshd]
enabled = true
maxretry = 5
bantime = 3600
findtime = 600
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Étape 6 — Relancer Lynis et mesurer l'amélioration

sudo lynis audit system --report-file /tmp/lynis-rapport-after.txt
grep -i "hardening index" /tmp/lynis-rapport-before.txt /tmp/lynis-rapport-after.txt

Livrables : rapport Lynis avant/après · journal des corrections (commande + justification + vérification)

Critère de succès : le Hardening Index augmente d'au moins 10 points.

💬 Synthèse — Question finale

📝 QCM — Testez vos connaissances