Chapitre 5.4 — Le pare-feu (UFW)

⏱️ TL;DR — Un pare-feu décide quels ports sont joignables depuis l’extérieur. Sur Ubuntu/Debian, UFW (Uncomplicated Firewall) est la surcouche simple de nftables/iptables. La philosophie : tout fermer par défaut (ufw default deny incoming), puis ouvrir seulement le nécessaire — SSH (pour ne pas se couper l’accès), le port 80 (HTTP) et 443 (HTTPS). Le piège mortel : activer UFW sans avoir autorisé SSH d’abord → tu te coupes toi-même l’accès au serveur. On n’ouvre jamais les ports de base de données (5432, 3306) au monde : la base reste locale. Résultat : une seule poignée de ports ouverts, tout le reste rejeté d’office.

🎯 Objectifs

• Comprendre le rôle d’un pare-feu et la philosophie deny-by-default.
• Configurer UFW : politique par défaut, ouverture de SSH/80/443, activation, vérification.
• Éviter le piège classique : s’enfermer dehors en activant UFW sans autoriser SSH.
• Savoir ce qu’il ne faut jamais ouvrir (5432, 3306) et pourquoi.
• Situer UFW par rapport à nftables/iptables en dessous.

À quoi sert un pare-feu

Ton serveur fait tourner des services qui écoutent sur des ports (rappel : ss -tulpn du chapitre 5.1). Chaque port ouvert est une porte vers la machine. Sans pare-feu, tous les ports ouverts par un service sont joignables depuis Internet — y compris ceux que tu n’avais pas l’intention d’exposer (une base mal configurée, un outil de debug, un service installé par un paquet).

Le pare-feu est le videur à l’entrée : il applique des règles qui disent quels ports sont accessibles de l’extérieur, indépendamment de ce que les services font. Même si un service se met à écouter sur 0.0.0.0 par erreur, le pare-feu peut bloquer l’accès. C’est une couche de défense qui ne dépend pas de la config de chaque logiciel — d’où sa valeur.

🔒 Sécurité — Le pare-feu, c’est la défense en profondeur appliquée au réseau : même si un service est mal configuré ou compromis, un port fermé au pare-feu n’est pas joignable. Tu ne comptes pas sur le fait que chaque service écoute au bon endroit ; tu poses une barrière au-dessus. La bonne posture n’est pas « fermer les ports dangereux » mais « tout fermer, n’ouvrir que l’indispensable ». On liste ce qu’on autorise, pas ce qu’on interdit.

UFW : la surcouche simple

Sous le capot, Linux filtre le réseau avec nftables (ou l’ancien iptables) : puissant, mais la syntaxe est rébarbative. UFW (Uncomplicated Firewall) est une surcouche qui traduit des commandes lisibles en règles nftables/iptables. Pour un serveur classique, UFW suffit amplement — on gère quelques ports, pas une architecture réseau complexe.

Sur Ubuntu, UFW est souvent déjà installé. Sinon :

sudo apt update
sudo apt install ufw

⚠️ Piège — LIS CECI AVANT DE TOUCHER À UFW — Le danger n°1 : activer UFW alors qu’il rejette tout, SANS avoir autorisé SSH. Comme la politique par défaut est deny incoming, le ufw enable coupe immédiatement ta connexion SSH en cours — et tu ne peux plus te reconnecter. Tu es enfermé dehors sur ta propre machine. L’ordre est donc impératif : on autorise SSH d’abord, on active ensuite. Ne fais jamais ufw enable avant ufw allow OpenSSH.

La séquence sûre, dans l’ordre

Voici l’ordre à respecter religieusement. On règle la politique par défaut, on ouvre SSH d’abord, puis les ports web, et on active en dernier.

🐚 Au terminal — en deploy avec sudo :

# 1. Politique par défaut : tout ce qui ENTRE est refusé, tout ce qui SORT est autorisé
sudo ufw default deny incoming        # rejette toute connexion entrante non explicitement autorisée
sudo ufw default allow outgoing       # laisse le serveur initier des connexions sortantes (MàJ, etc.)
 
# 2. AUTORISER SSH EN PREMIER (sinon on se coupe l'accès à l'étape 5 !)
sudo ufw allow OpenSSH                 # ouvre le port SSH (22) via le profil applicatif "OpenSSH"
# Si tu as changé le port SSH : sudo ufw allow 2222/tcp  (adapte au port choisi)
 
# 3. Ouvrir le web : HTTP et HTTPS
sudo ufw allow 80/tcp                  # HTTP (Nginx en aura besoin ; sert aussi au challenge Let's Encrypt)
sudo ufw allow 443/tcp                 # HTTPS
 
# 4. Vérifier les règles AVANT d'activer
sudo ufw show added                    # liste les règles qui seront appliquées
 
# 5. Activer le pare-feu (demande confirmation : la connexion SSH pourrait être coupée)
sudo ufw enable                        # active UFW ; comme SSH est autorisé, ta session tient
 
# 6. Contrôler l'état final
sudo ufw status verbose                # affiche la politique par défaut et la liste des ports ouverts

Détaillons les deux verbes de politique par défaut :

• default deny incoming — tout ce qui arrive de l’extérieur est rejeté, sauf ce que tu autorises explicitement. C’est le cœur du deny-by-default.
• default allow outgoing — le serveur peut initier des connexions sortantes (pour apt update, appeler une API, envoyer un mail). On ne bride pas le trafic sortant sur un serveur classique.

Le profil OpenSSH est un raccourci applicatif : UFW connaît des profils prêts à l’emploi (dans /etc/ufw/applications.d) qui ouvrent les bons ports. ufw allow OpenSSH ouvre le port SSH (22 par défaut). Tu peux aussi ouvrir un port numérique : ufw allow 22/tcp.

💡 Réflexe — Avant ufw enable, relis à voix haute : « SSH est-il autorisé ? ». Un sudo ufw show added te montre les règles en attente. Tant que tu vois bien une règle qui autorise SSH (OpenSSH ou ton port custom), tu peux activer sereinement. Filet supplémentaire : garde la console de secours du fournisseur sous la main — elle accède à la machine hors SSH, donc hors pare-feu, si jamais tu t’enfermes.

Vérifier, modifier, supprimer des règles

sudo ufw status verbose           # état complet : politique par défaut + règles actives
sudo ufw status numbered          # règles NUMÉROTÉES (pratique pour en supprimer une)
sudo ufw allow 8080/tcp           # ouvrir un port supplémentaire (ex. pour un test temporaire)
sudo ufw delete allow 8080/tcp    # supprimer cette règle par sa description
sudo ufw delete 3                 # OU supprimer la règle n°3 (numéro vu dans status numbered)
sudo ufw disable                  # désactive UFW (à éviter en prod, sauf dépannage)

Une sortie typique de ufw status verbose sur un serveur web bien réglé :

Status: active
Default: deny (incoming), allow (outgoing), disabled (routed)

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

Trois ports ouverts, tout le reste rejeté. C’est exactement l’objectif : une surface d’attaque minimale.

Ce qu’on n’ouvre JAMAIS : les ports de base de données

Ta base de données (PostgreSQL sur 5432, MySQL/MariaDB sur 3306) tourne sur le même serveur que ton app. L’app lui parle en local, via 127.0.0.1. Il n’y a donc aucune raison d’ouvrir 5432 ou 3306 au monde — et le faire serait une faille majeure.

⚠️ Piège — Ouvrir 5432 ou 3306 « pour se connecter à la base depuis son poste ». C’est une des erreurs les plus dangereuses : une base exposée sur Internet se fait scanner et attaquer en continu, et une seule config faible (mot de passe par défaut, version vulnérable) suffit à tout perdre. Ta base doit écouter en local uniquement (127.0.0.1, réglé côté base — Partie 11) et son port rester fermé au pare-feu. Pour t’y connecter depuis ton poste, on passe par un tunnel SSH (Partie 4, ssh -L), pas par une ouverture de port.

🔒 Sécurité — La règle : le pare-feu n’ouvre que ce qui doit être public. SSH (ton accès), 80 et 443 (le web). Tout le reste — bases, caches (Redis sur 6379), outils d’admin — reste interne à la machine, joignable seulement en 127.0.0.1, jamais via le pare-feu. Si un jour tu dois vraiment exposer un service à une IP précise, UFW le permet finement (sudo ufw allow from 203.0.113.5 to any port 5432), mais le défaut reste fermé au monde.

En dessous : nftables et iptables

UFW ne fait rien de magique : il génère des règles pour nftables (le moteur de filtrage moderne du noyau Linux) ou iptables (l’historique, encore très présent). Tu peux vivre des années sans les toucher directement — UFW couvre les besoins d’un serveur web. Mais il est bon de savoir qu’ils existent : si un jour tu croises des règles iptables -L ou une config nftables, ce sont les couches basses que UFW pilote pour toi.

📚 La doc — man ufw couvre toutes les commandes (profils applicatifs, règles par IP, logging avec ufw logging on). Pour les couches en dessous : man nft (nftables) et man iptables. Pour un serveur web classique, reste sur UFW ; ne descends vers nftables/iptables que si un besoin précis l’exige. N’improvise pas de règles bas niveau de mémoire.

🧭 Sur FormaCampus — Sur formacampus-prod, le front Next.js et l’API Symfony sont derrière Nginx : seul Nginx est joignable de l’extérieur, sur 80 et 443. L’app Node écoute sur 127.0.0.1:3000, l’API sur un autre port local, Postgres sur 127.0.0.1:5432 — aucun n’est ouvert au pare-feu. La config UFW de FormaCampus tient en trois lignes : OpenSSH, 80/tcp, 443/tcp. Tout le reste (Postgres, les ports applicatifs internes) reste fermé au monde et n’est accessible qu’en local, où Nginx et l’app se parlent. Le jour où un scan cherche une base Postgres sur l’IP publique, il ne trouve rien — le port est fermé.

✏️ Exercices

Exercice 1 — La séquence sûre. Écris la suite complète de commandes UFW pour un serveur web (SSH + HTTP + HTTPS), dans le bon ordre, avec un commentaire par ligne. Précise où est le risque de s’enfermer dehors.

sudo ufw default deny incoming     # tout entrant refusé par défaut
sudo ufw default allow outgoing    # sortant autorisé
sudo ufw allow OpenSSH             # SSH D'ABORD (sinon on se coupe l'accès)
sudo ufw allow 80/tcp             # HTTP
sudo ufw allow 443/tcp            # HTTPS
sudo ufw show added               # relire les règles avant d'activer
sudo ufw enable                   # activer (SSH étant autorisé, la session tient)
sudo ufw status verbose           # vérifier l'état final

Exercice 2 — Repère la faute. Un collègue a fait : sudo ufw default deny incoming, sudo ufw allow 5432/tcp, sudo ufw allow 443/tcp, sudo ufw enable. Il est content : « le pare-feu est actif ». Quels sont les deux problèmes ?

🧠 Quiz de révision

Chapitre suivant : 5.5 — fail2ban & MàJ auto — bannir les IP qui bruteforcent, automatiser les correctifs de sécurité, et dérouler la grande checklist de durcissement.