Sécuriser un VPS Linux avec ufw et fail2ban

À la fin de ce bonus ufw fail2ban, vous saurez poser une politique default deny avec ufw, autoriser OpenSSH avant enable, activer la jail sshd de fail2ban, lire les journaux — sans vous lock-out — et croiser avec un Security Group AWS.

Niveau : Débutant+ · Temps estimé : 40–50 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; note Rocky/Alma 9 (firewalld) · Dernière vérification : 2026-09-10

Slug proposé : linux-ufw-fail2ban · Série : Sécurité / Linux Réseau & sécurité (hors menu Basics — draft conservé) · Remplace / fusionne : N/A — création

Prérequis

• Avoir suivi SSH & clés : connexion par clé OK, console / SSM de secours si cloud
• VPS ou VM lab Ubuntu/Debian (pas la prod) ; accès sudo
• Deuxième canal de secours : console provider, session SSH déjà ouverte, ou EC2 + SSM
• Comprendre réseau ip / ss (ports, écoute)

Coût estimé : 0 € en lab local. Sur cloud : Free Tier ; ne testez jamais ufw enable sur une instance sans console de secours.

Ce que nous allons construire

Politique firewall (hôte)
  → ufw default deny incoming / allow outgoing
  → ufw allow OpenSSH  (AVANT enable)
  → ufw enable + status verbose
fail2ban (anti-bruteforce)
  → install · jail sshd · status · journal
Ne pas se lock-out
  → session ouverte · console/SSM · AWS Security Group
Vérification · erreurs · quiz · FAQ

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Sécuriser un VPS : ufw default deny, allow OpenSSH, fail2ban jail sshd et secours console — lab junior DevOps ».)

Bonus de Linux Basics (après le chapitre 8). Prolongement naturel de SSH & clés. Sur AWS, le Security Group filtre avant l’hôte — ufw complète, ne remplace pas.

Étape 1 — Pourquoi ufw + fail2ban sur un VPS

Un VPS exposé sur Internet reçoit du bruit : scans, tentatives SSH. Deux couches complémentaires :

Outil	Rôle
ufw (Uncomplicated Firewall)	Pare-feu hôte : quelles IP/ports entrent
fail2ban	Lit les logs ; ban temporaire les IP qui échouent trop (SSH, etc.)
Security Group (AWS)	Filtre réseau cloud, avant la VM

ufw fail2ban ne remplace pas les clés SSH ni PasswordAuthentication no (tuto 8). C’est la couche « firewall linux » + anti-bruteforce. denyhosts est une ancienne alternative centrée SSH ; fail2ban est plus généraliste et maintenu — d’où l’angle « denyhosts alternative » en 2026.

Règle d’or : autoriser SSH avant ufw enable. Sinon lock-out immédiat.

Étape 2 — Installer et poser la politique ufw (default deny)

Sur Ubuntu/Debian :

sudo apt update
sudo apt install -y ufw
# Politique prudente : tout refuser en entrée, autoriser la sortie
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw status verbose

Commande	Effet
default deny incoming	Aucun port entrant sauf règles explicites
default allow outgoing	La VM peut encore apt, DNS, HTTPS
status verbose	Politique + règles + logging

Rocky/Alma 9 : ufw n’est pas le défaut. Préférez firewalld (firewall-cmd --permanent --add-service=ssh puis --reload). N’activez pas ufw et firewalld en parallèle. Ce bonus reste centré Ubuntu/Debian ; la logique (deny + allow SSH) est la même.

À ce stade status peut encore dire inactive : c’est normal — vous posez la politique avant d’allumer le pare-feu. Ne sautez pas l’étape « allow OpenSSH ».

Étape 3 — Autoriser OpenSSH puis activer (sans se verrouiller)

Avant tout enable : gardez une session SSH ouverte + console provider / SSM.

# Profil OpenSSH (port 22/tcp) — à faire AVANT enable
sudo ufw allow OpenSSH
# Équivalent explicite :
# sudo ufw allow 22/tcp

# Vérifier que la règle est là (inactive tant que ufw off)
sudo ufw status numbered

# Activer (répondre y) — la session courante reste en général intacte
sudo ufw enable
sudo ufw status verbose

Sortie attendue (extrait) :

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)

Sécuriser SSH côté pare-feu = laisser uniquement le port SSH (et HTTPS si besoin : sudo ufw allow 80,443/tcp). Pas de allow 22 from anywhere plus permissif que nécessaire : en lab cloud, restreignez aussi le Security Group à votre IP (/32).

Tip DevOps : documentez les mêmes ports dans le SG (IaC) et dans ufw. Un port ouvert dans Terraform mais oublié dans ufw = faux « bug réseau » ; l’inverse expose l’hôte si le SG est trop large.

Si vous avez changé le port SSH (Port 2222 dans sshd) :

# Exemple — adapter au port réel
sudo ufw allow 2222/tcp comment 'SSH lab'
sudo ufw delete allow OpenSSH   # si 22 n’écoute plus
sudo ufw reload

Étape 4 — Installer fail2ban et activer la jail sshd

sudo apt install -y fail2ban
# Jail locale (ne pas éditer jail.conf directement — reste écrasable à l’upgrade)
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local 2>/dev/null || true
sudo tee /etc/fail2ban/jail.d/sshd.local >/dev/null << 'JAIL'
[sshd]
enabled = true
port    = ssh
filter  = sshd
backend = systemd
maxretry = 5
findtime = 10m
bantime  = 1h
JAIL
sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Paramètre	Sens lab
maxretry	Échecs avant ban
findtime	Fenêtre de comptage
bantime	Durée du ban (1h en lab ; plus long en prod mûre)
backend = systemd	Lit journald (Ubuntu/Debian modernes)

VPS sécurité de base : jail sshd active + ufw. N’inventez pas 20 jails d’un coup en premier lab.

Sortie attendue de fail2ban-client status sshd : Status for the jail: sshd, Currently banned: 0 (ou une liste d’IP de lab). Si Jail does not exist, le drop-in n’est pas chargé — systemctl restart fail2ban puis re-status.

Étape 5 — Journal, bans et déblocage (lab prudent)

# Logs fail2ban
sudo journalctl -u fail2ban -n 50 --no-pager
# Ban manuel de test (IP de lab jetable — PAS votre IP client)
# sudo fail2ban-client set sshd banip 203.0.113.10
# sudo fail2ban-client set sshd unbanip 203.0.113.10
sudo fail2ban-client status sshd
# ufw : logs éventuels
sudo tail -n 30 /var/log/ufw.log 2>/dev/null || sudo journalctl -k | grep -i ufw | tail -n 20

Lab prudent :

1. Ne bannissez jamais votre propre IP publique sans console de secours.
2. Testez depuis une IP jetable / second réseau si possible.
3. Sur AWS : Security Group + ufw = double filet ; documentez les ports dans le même esprit que EC2 / SSM.

Piège : bannir 203.0.113.10 (documentation RFC) est safe ; bannir l’IP de votre laptop sans console = lock-out. En lab, préférez status + lecture de journal plutôt qu’un ban « pour voir » depuis votre IP réelle.

Étape 6 — Vérification et nettoyage lab

sudo ufw status verbose
sudo systemctl is-active fail2ban
sudo fail2ban-client status sshd
ss -tlnp | grep -E ':22|:ssh' || true
echo "Lab ufw+fail2ban : SSH autorisé, deny incoming, jail sshd — OK"
# Rollback OPTIONNEL (lab jetable uniquement) :
# sudo ufw disable
# sudo systemctl disable --now fail2ban

Validé si : ufw active, règle OpenSSH/22 présente, fail2ban actif, status sshd liste la jail, vous pouvez encore ssh depuis votre client.

Erreurs fréquentes

Symptôme	Cause	Correction
SSH coupé juste après ufw enable	Pas de allow OpenSSH avant	Console provider / SSM ; ufw allow OpenSSH && ufw reload
ufw status → inactive	Jamais enable	sudo ufw enable après les allows
fail2ban ne ban rien	Jail sshd off / mauvais backend	jail.d/sshd.local + systemctl restart fail2ban
Ban de votre propre IP	Trop de mauvais mots de passe / retries	unbanip + console ; passez aux clés (tuto 8)
Conflit Rocky	ufw + firewalld ensemble	Un seul moteur : firewalld sur Rocky/Alma
Port custom SSH refusé	ufw autorise encore 22 seulement	ufw allow PORT/tcp du vrai sshd
ufw enable demande y/N	Confirmation interactive	Répondre y ; ou ufw --force enable en script lab documenté
Jail sshd OK mais 0 ban après attaque simulée	Logs ailleurs / backend	Vérifier backend = systemd et journalctl -u ssh

Quiz (3 questions)

1. Quelle commande doit précéder ufw enable sur un VPS SSH ?
– A. ufw default allow incoming
– B. ufw allow OpenSSH (ou le port SSH réel)
– C. ufw reset obligatoire

2. À quoi sert fail2ban par rapport à ufw ?
– A. À remplacer entièrement le pare-feu
– B. À bannir temporairement des IP après trop d’échecs (ex. jail sshd), en plus du firewall
– C. À générer des clés SSH

3. Sur Rocky/Alma 9, quel outil est le défaut recommandé dans ce bonus ?
– A. Uniquement ufw
– B. firewalld (éviter le duo ufw+firewalld)
– C. denyhosts uniquement

Réponses : 1‑B · 2‑B · 3‑B

FAQ

Comment activer ufw sans se lock-out SSH ?
Posez default deny incoming, puis ufw allow OpenSSH (ou le port réel), ensuite ufw enable. Gardez une session ouverte et une console / SSM de secours. C’est le cœur de sécuriser ssh côté pare-feu hôte.

fail2ban remplace-t-il denyhosts ?
Oui en pratique : denyhosts était limité à SSH ; fail2ban lit les journaux et bannit via iptables/nft (intégré à ufw). Jail sshd = point de départ VPS.

ufw suffit-il sur AWS sans Security Group ?
Non. Le Security Group filtre avant l’instance ; ufw protège l’hôte. Croisez les deux (IP admin en /32 dans le SG + OpenSSH dans ufw). Voir démarrer avec AWS.

Comment lever un ban fail2ban sans rebooter ?
sudo fail2ban-client set sshd unbanip IP puis status sshd pour confirmer. Si l’IP revient dans la foulée, corrigez la cause (mot de passe / mauvaise clé) côté client — le ban n’est qu’un pansement.

Pour aller plus loin

• man ufw, man fail2ban-client, jail.conf(5)
• Durcissement sshd : SSH & clés (étape aperçu)
• Cloud : Security Groups + EC2 / SSM
• Hub : Linux Basics

Maillage série Linux Basics (P5)

← Précédent	Se connecter en SSH avec des clés
→ Suivant	Bonus standalone — retour au hub Linux Basics
Hub	Linux Basics
Aussi	Réseau ip / ss / curl · EC2 + SSM · Démarrer avec AWS (Security Groups)

---

Meta publication (à remplir dans Rank Math / SEO)

• Title SEO : ufw et fail2ban : sécuriser SSH sur un VPS (2026)
• Meta description (≤ 155) : Activer ufw, autoriser SSH sans se verrouiller, installer fail2ban. Bonus série Linux Basics.
• Focus keyphrase : ufw fail2ban
• KW secondaires : firewall linux, sécuriser ssh, denyhosts alternative, vps sécurité
• Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
• Image mise en avant : assets/web/devopelastichayway/cover-linux-ufw-fail2ban-1200x630.webp (Visuels Linux — WebP 1200×630)
• Catégorie : Linux · Niveau : Débutant+
• Slug : linux-ufw-fail2ban