Chapitre 5.5 — fail2ban & MàJ auto

⏱️ TL;DR — Deux dernières défenses avant de clore le durcissement. fail2ban surveille les logs et bannit temporairement les IP qui multiplient les tentatives de connexion ratées (bruteforce SSH surtout) : on installe, on active la jail sshd, on règle bantime/findtime/maxretry dans /etc/fail2ban/jail.local. Les mises à jour de sécurité automatiques (unattended-upgrades) appliquent seules les correctifs de sécurité, pour ne pas dépendre de ta vigilance. Puis on déroule la grande checklist de durcissement initial : le récapitulatif de toute la partie, à cocher sur chaque serveur neuf. Ce chapitre clôt la mise en sécurité de base — après lui, ton VPS est prêt à héberger la prod.

🎯 Objectifs

• Installer et configurer fail2ban pour bannir les IP qui bruteforcent SSH.
• Régler une jail : bantime, findtime, maxretry, et débannir une IP au besoin.
• Activer les mises à jour de sécurité automatiques avec unattended-upgrades.
• Décider entre redémarrages automatiques et manuels après mise à jour.
• Dérouler la checklist complète de durcissement initial d’un VPS.

fail2ban : bannir les bruteforceurs

Même avec PasswordAuthentication no (chapitre 5.3), ton serveur reçoit en permanence des tentatives de connexion de robots. Elles échouent (pas de mot de passe accepté), mais elles polluent les logs et consomment des ressources. fail2ban ajoute une réponse active : il lit les logs, repère les IP qui accumulent les échecs, et les bannit en insérant une règle de pare-feu temporaire. Une IP qui tente 5 connexions ratées se retrouve bloquée pour un temps donné.

fail2ban fonctionne par jails (« cellules ») : chaque jail surveille un service (SSH, Nginx…) avec ses propres règles. La plus importante est la jail sshd.

Installer et démarrer

🐚 Au terminal — en deploy avec sudo :

sudo apt update
sudo apt install fail2ban            # installe fail2ban
sudo systemctl enable --now fail2ban # démarre le service ET l'active au boot
sudo systemctl status fail2ban       # vérifie qu'il tourne

Le enable --now fait d’une pierre deux coups : il démarre le service tout de suite (--now) et l’active au démarrage (enable) — pour qu’il revienne après un reboot. (Rappel Partie 3 sur systemd.)

Configurer : jail.local, pas jail.conf

fail2ban lit /etc/fail2ban/jail.conf, mais ne modifie jamais ce fichier : il est écrasé aux mises à jour du paquet. La bonne pratique est de créer /etc/fail2ban/jail.local, qui surcharge le .conf et survit aux updates.

sudo nano /etc/fail2ban/jail.local

Un contenu de départ raisonnable pour protéger SSH :

[DEFAULT]
# Durée du bannissement (ici 1 heure). "-1" bannirait de façon permanente.
bantime = 1h
# Fenêtre d'observation : les échecs sont comptés sur cette durée.
findtime = 10m
# Nombre d'échecs toléré dans findtime avant bannissement.
maxretry = 5
 
[sshd]
enabled = true

Les trois réglages clés :

• maxretry — le nombre de tentatives ratées autorisées avant de bannir (ici 5).
• findtime — la fenêtre dans laquelle ces tentatives sont comptées (ici 10 minutes). 5 échecs en 10 min → ban.
• bantime — la durée du bannissement (ici 1 heure). On peut l’allonger, voire activer un bantime croissant pour les récidivistes (voir la doc).

La section [sshd] avec enabled = true active la jail SSH. Applique la config en rechargeant fail2ban :

sudo systemctl restart fail2ban

Surveiller et débannir

sudo fail2ban-client status                 # liste les jails actives
sudo fail2ban-client status sshd            # détail de la jail sshd : IP bannies, compteurs
sudo fail2ban-client set sshd unbanip 203.0.113.42   # débannir une IP (ex. toi, banni par erreur)

fail2ban-client status sshd te montre combien d’IP sont bannies et lesquelles. Le unbanip est essentiel à connaître : si tu te bannis toi-même (mot de passe raté plusieurs fois, ou un script qui reconnecte en boucle), tu débannis ton IP avec cette commande — via la console de secours du fournisseur si tu es coupé de SSH.

⚠️ Piège — Se bannir soi-même. Un findtime/maxretry trop stricts, ou un script qui rate ses reconnexions, et fail2ban bloque ton IP. Tu ne peux alors plus te connecter en SSH depuis chez toi. Deux parades : garde la console de secours du fournisseur (accès hors SSH) pour lancer unbanip, et mets ton IP fixe (si tu en as une) en liste blanche via ignoreip dans jail.local. Ne fixe pas non plus un bantime permanent trop agressif au début.

💡 Réflexe — Ajoute ton réseau de confiance à ignoreip pour ne jamais te bannir :

[DEFAULT]
ignoreip = 127.0.0.1/8 203.0.113.42   # localhost + ton IP fixe (adapte)

fail2ban ne bannira jamais une IP listée là. Utile pour ton poste ou le réseau du bureau — à condition d’avoir une IP fixe.

🔒 Sécurité — fail2ban ne remplace pas les clés SSH et le pare-feu : il les complète. Avec PasswordAuthentication no, le bruteforce ne peut de toute façon rien forcer ; mais fail2ban coupe le bruit (moins de logs, moins de charge) et bloque les IP hostiles au niveau réseau. C’est une couche de plus dans la défense en profondeur : clés + root off + pare-feu + fail2ban. Chacune tient si une autre faiblit.

Les mises à jour de sécurité automatiques

Tu as mis le système à jour au chapitre 5.1. Mais de nouvelles failles sont découvertes chaque semaine, avec leurs correctifs. Compter sur ta vigilance pour lancer apt upgrade régulièrement est fragile : on oublie, on part en vacances, et une faille critique reste ouverte. La solution : automatiser l’application des correctifs de sécurité avec unattended-upgrades.

Installer et activer

sudo apt update
sudo apt install unattended-upgrades       # souvent déjà présent sur Ubuntu
sudo dpkg-reconfigure --priority=low unattended-upgrades
# Ouvre un dialogue : réponds "Oui" pour activer les MàJ automatiques.

dpkg-reconfigure affiche un dialogue simple : répondre oui active le mécanisme et crée la configuration de base. Le comportement se règle finement dans /etc/apt/apt.conf.d/50unattended-upgrades (quelles origines de paquets accepter) et /etc/apt/apt.conf.d/20auto-upgrades (à quelle fréquence).

Ce qu’on automatise (et ce qu’on n’automatise pas)

Le réglage par défaut d’unattended-upgrades est prudent : il n’applique que les mises à jour de sécurité, pas toutes les mises à jour. C’est exactement ce qu’on veut : les correctifs de sécurité partent seuls (le risque de les retarder dépasse le risque qu’ils cassent quelque chose), tandis que les montées de version plus larges restent manuelles (tu les appliques quand tu peux surveiller).

Dans /etc/apt/apt.conf.d/50unattended-upgrades, la liste des origines autorisées ressemble à ceci (extrait) — on garde la ligne security active :

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    // les autres origines (updates, etc.) sont souvent commentées par défaut
};

Redémarrages : automatiques ou manuels ?

Certains correctifs (surtout le noyau) ne prennent effet qu’après un redémarrage. unattended-upgrades peut redémarrer automatiquement, à une heure creuse :

Unattended-Upgrade::Automatic-Reboot "true";           // autoriser le reboot auto
Unattended-Upgrade::Automatic-Reboot-Time "04:00";     // à 4h du matin

C’est un arbitrage :

• Reboot automatique — le correctif noyau s’applique sans intervention, au prix d’une micro-coupure nocturne. Idéal pour un serveur où quelques secondes d’indispo à 4h ne gênent personne.
• Reboot manuel — tu gardes Automatic-Reboot "false" et tu redémarres toi-même au moment choisi (fenêtre de maintenance). Plus de contrôle, mais il faut penser à le faire (le fichier /var/run/reboot-required t’indique qu’un reboot est en attente).

💡 Réflexe — Pour un premier serveur sans redondance, un reboot automatique en heure creuse (4h) est souvent le meilleur défaut : les correctifs noyau s’appliquent vraiment, sans que tu aies à y penser. Le jour où tu auras plusieurs serveurs derrière un load balancer (Partie 15), tu orchestreras les reboots pour éviter toute coupure visible.

📚 La doc — Les options exactes d’unattended-upgrades sont commentées dans le fichier lui-même (/etc/apt/apt.conf.d/50unattended-upgrades) et dans man unattended-upgrade. Pour fail2ban, man jail.conf et le fichier /etc/fail2ban/jail.conf (à lire, pas à modifier) documentent tous les réglages. Ne devine pas un nom d’option : lis le fichier fourni.

🧭 Sur FormaCampus — Sur formacampus-prod, l’équipe installe fail2ban avec la jail sshd (bantime = 1h, maxretry = 5) et met l’IP fixe du bureau en ignoreip pour que l’ingé ne se bannisse jamais. Elle active unattended-upgrades pour les correctifs de sécurité, avec un reboot automatique à 4h — FormaCampus a peu de trafic la nuit, une micro-coupure nocturne est acceptable, et les failles noyau ne traînent pas ouvertes. Résultat : le serveur se maintient et se défend seul entre deux interventions. C’est ça, un serveur durci : il ne dépend pas de la présence quotidienne d’un humain pour rester sûr.

La checklist de durcissement initial

On y est. Voici le récapitulatif de toute la Partie 5 : la liste des gestes à appliquer sur chaque VPS neuf, dans l’ordre. Garde-la sous la main — c’est ta procédure de provisioning, à rejouer les yeux fermés.

🔒 Sécurité — Cette checklist est la base commune de tout serveur de prod, quel que soit ce qu’il hébergera. Elle applique un principe simple : réduire la surface d’attaque (moins de ports, moins de comptes puissants, pas de mot de passe à forcer) et automatiser la défense (correctifs auto, bannissement auto). Aucun de ces gestes n’est optionnel sur un serveur exposé. Fais-en un rituel : nouveau VPS → checklist → puis seulement, tu installes ce qu’il doit faire tourner.

💡 Réflexe — Plus tard, tu automatiseras cette checklist elle-même : un script shell de provisioning, ou un playbook Ansible, qui applique tous ces gestes en une commande sur un serveur neuf. C’est le prolongement naturel (aperçu en Partie 16). Mais comprends d’abord chaque étape à la main : on n’automatise bien que ce qu’on sait faire soi-même.

Ce que tu as accompli dans cette partie

Tu es parti d’un VPS nu et vulnérable — une IP, un root ouvert, aucune défense. Tu en as fait un serveur à jour, filtré, défendu et autonome : utilisateur deploy avec sudo, root et mot de passe coupés, pare-feu deny-by-default, fail2ban actif, correctifs de sécurité automatiques, swap et réglages système propres. La base de sécurité est posée. Ton serveur peut maintenant recevoir un nom de domaine, Nginx, HTTPS et ta prod — sur des fondations saines.

✏️ Exercices

Exercice 1 — Configure fail2ban. Écris un /etc/fail2ban/jail.local qui : bannit une IP après 4 échecs en 5 minutes, pour 2 heures, active la jail SSH, et ne bannit jamais l’IP 203.0.113.42. Donne aussi la commande pour appliquer, et celle pour voir les IP bannies.

[DEFAULT]
bantime = 2h
findtime = 5m
maxretry = 4
ignoreip = 127.0.0.1/8 203.0.113.42
 
[sshd]
enabled = true

sudo systemctl restart fail2ban

sudo fail2ban-client status sshd

Exercice 2 — Reboot auto ou manuel ? Pour un serveur unique qui héberge le site d’une petite EdTech, avec très peu de trafic entre minuit et 6h, faut-il activer le redémarrage automatique d’unattended-upgrades ? Justifie, et donne le réglage.

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

🧠 Quiz de révision

Fin de la Partie 5. Ton VPS est provisionné et durci : à jour, en deploy + sudo, pare-feu fermé, fail2ban et correctifs automatiques. Il est prêt à exister sur Internet — on lui donne un nom en Partie 6 — Réseau, DNS & domaine.