Configurer un pare-feu léger sur votre serveur cloud (guide UFW)

VPS Linux fraîchement installé, IP publique exposée : les scanners s’en mêlent tout de suite. Nous avons suivi un Ubuntu 22.04 au premier démarrage : en moins de quatre heures, plus de mille tentatives de brute force SSH du monde entier dans /var/log/auth.log. Le groupe de sécurité du fournisseur cloud filtre une partie du trafic, mais le pare-feu au niveau système reste la deuxième ligne de défense que vous maîtrisez vraiment.

Sur les serveurs Ubuntu / Debian, UFW (Uncomplicated Firewall) est quasiment la réponse par défaut : syntaxe simple, intégration transparente avec iptables, documentation solide. Cet article ne détaille pas des dizaines de règles en chaîne iptables, mais condense en checklist un flux UFW validé en production — installation, ouverture SSH, ports web, coexistence avec Docker, coordination avec les groupes de sécurité cloud, et surtout : configurer le pare-feu sans vous enfermer dehors.

Prérequis : vous êtes connecté en SSH ou via la console cloud (VNC), avec les droits sudo. Si SSH ne répond plus, consultez d’abord notre guide de dépannage SSH refusé sur serveur Linux pour distinguer problème réseau et pare-feu, puis revenez ici.

Pourquoi un pare-feu sur un serveur cloud ?

Beaucoup pensent : « J’ai un groupe de sécurité, rien à faire sur le système. » En réalité, les rôles diffèrent : le groupe de sécurité cloud filtre en amont de la carte virtuelle, géré depuis la console web ; UFW filtre au niveau netfilter du noyau, géré en ligne de commande. Une seule couche, c’est verrouiller la porte d’entrée en laissant la chambre ouverte — mouvement latéral, services exposés par erreur, reverse shell après compromission : il faut des règles au niveau OS.

UFW reste, comme décrit dans la documentation officielle Ubuntu UFW, un frontal iptables : ufw allow 22 devient des règles ACCEPT. Syntaxe proche du langage naturel, ufw status numbered pour voir la politique d’un coup d’œil, modifications sans se perdre.

Étape 1 : installer et vérifier UFW

Ubuntu Desktop et la plupart des images serveur incluent UFW ; les images minimales, pas toujours. Vérifiez d’abord :

sudo apt update
                sudo apt install ufw -y

                # État actuel (inactive = pas encore activé)
                sudo ufw status verbose

                # Démarrage auto (configurer les règles avant enable)
                sudo systemctl enable ufw

Si la sortie indique Status: inactive, vous pouvez ajouter les règles une par une sans effet immédiat — c’est la meilleure fenêtre de configuration. Ne lancez jamais ufw enable avant d’avoir autorisé SSH, sinon vous perdez l’accès distant sur-le-champ.

Étape 2 : autoriser SSH (la règle la plus importante)

SSH est votre canal d’administration : à autoriser en premier. Si sshd écoute sur un port non standard (par ex. 2222), le port dans la règle doit correspondre à sshd_config, et le groupe de sécurité doit être aligné.

# Port par défaut 22
                sudo ufw allow 22/tcp comment 'SSH'

                # Port personnalisé
                sudo ufw allow 2222/tcp comment 'SSH custom'

                # IP de sortie bureau uniquement (prod recommandé)
                sudo ufw allow from 203.0.113.50 to any port 22 proto tcp

                # Par nom de service (si défini dans /etc/services)
                sudo ufw allow OpenSSH

Vérifiez que sshd écoute bien : sudo ss -tlnp | grep ssh. 0.0.0.0:22 ou [::]:22 indique un service OK. Si ListenAddress vaut 127.0.0.1, UFW ne suffira pas — c’est un problème sshd, pas pare-feu.

Pour l’alignement port SSH et groupe de sécurité, voir notre FAQ pare-feu surface d’exposition minimale sur hôte Linux cloud, avec une matrice SSH/HTTPS pour la planification long terme.

Étape 3 : politique par défaut

La baseline UFW recommandée : refuser tout entrant, autoriser tout sortant. Sortant ouvert pour apt, APIs, DNS ; entrant resserré aux ports de service explicitement nécessaires.

sudo ufw default deny incoming
                sudo ufw default allow outgoing

                # Règles numérotées (pour suppression)
                sudo ufw status numbered

Pour la conformité, vous pouvez restreindre le sortant : ufw default deny outgoing puis allow out pour DNS (53), HTTPS (443), etc. Pour la plupart des serveurs web/API, « sortant ouvert, entrant à la demande » offre le meilleur rapport effort/sécurité.

Étape 4 : ouvrir les ports métier

Ajoutez des règles selon vos services réels. Combinaisons courantes :

# HTTP / HTTPS (Nginx, Caddy, Apache)
                sudo ufw allow 80/tcp
                sudo ufw allow 443/tcp

                # Ou raccourci par nom de service
                sudo ufw allow 'Nginx Full'

                # Dev : Node ou autre port temporaire
                sudo ufw allow 3000/tcp comment 'dev API'

                # Panneau admin depuis IP source précise
                sudo ufw allow from 198.51.100.0/24 to any port 8080 proto tcp

En production : ce qui peut passer par un reverse proxy en 443 ne doit pas exposer 3000/8080 directement. Dans UFW, ouvrez seulement 22 + 80 + 443, application sur 127.0.0.1, terminaison TLS via Nginx ou Caddy — la surface d’attaque rétrécit immédiatement.

Étape 5 : activer et vérifier

Une fois les règles en place, activez UFW :

sudo ufw enable
                # Avertit d’une possible coupure SSH — confirmer avec y

                sudo ufw status verbose
                sudo ufw status numbered

Depuis une autre machine : nc -zv your.server.ip 22 doit répondre open ; un port non autorisé (ex. 3306) doit timeout ou refused. SSH coupé ? Console cloud/VNC immédiatement : sudo ufw disable, identifiez la règle manquante, recommencez.

Avancé : limitation, suppression, ordre des règles

UFW va au-delà de allow — scénarios fréquents :

# Limitation : anti brute force SSH (6 tentatives/30 s)
                sudo ufw limit 22/tcp

                # Supprimer par numéro (status numbered d’abord)
                sudo ufw delete 3

                # Refuser une IP précise
                sudo ufw deny from 192.0.2.100

                # Réinitialiser toutes les règles (prudence)
                sudo ufw reset

ufw limit s’appuie sur le module iptables recent pour la fréquence de connexion — efficace pour SSH, mais ne remplace ni clés SSH ni désactivation du mot de passe. Les règles s’évaluent dans l’ordre d’ajout ; les plus spécifiques doivent précéder les générales. Un allow inefficace ? Vérifiez un deny ultérieur qui le recouvre.

UFW avec Docker / Kubernetes

Le cas où UFW semble « configuré mais sans effet ». Docker insère par défaut ses propres chaînes iptables et peut contourner UFW — vous croyez 3306 fermé, le port du conteneur reste visible sur Internet.

Solutions (par ordre de préférence) :

• Conteneur lié à 127.0.0.1 seulement — -p 127.0.0.1:3000:3000, reverse proxy sur l’hôte
• Pas de ports dans docker-compose — réseau interne + reverse proxy
• Docker "iptables": false (règles de forwarding à maintenir — utilisateurs avancés)
• Groupe de sécurité cloud en filet final si Docker contourne UFW

Sur les nœuds K8s, Calico/Cilium gèrent leurs NetworkPolicies ; UFW complète au niveau nœud. Pour un VPS seul en Docker Compose, le premier point (loopback) suffit souvent.

Coordonner groupe de sécurité et UFW

Configurez les deux couches avec une politique cohérente : groupe autorise 22, UFW doit allow 22 ; groupe bloque 3306, un allow UFW n’ouvre pas Internet — mais des machines internes compromises peuvent scanner, donc UFW doit quand même deny.

Répartition conseillée :

• Groupe de sécurité : grossier, 22/80/443, source IP resserrée au bureau ou CDN
• UFW : fin, commentaires par service, limit SSH, blocage IP malveillantes
• fail2ban : couche dynamique, lecture des logs

Après modification, sonde externe : nmap -p 22,80,443,3306 your.server.ip (vos machines uniquement !). 3306 open sans exposition DB voulue ? Vérifiez le binding Docker ou l’adresse d’écoute de l’app.

Dépannage : service inaccessible après activation UFW

Dans cet ordre — la plupart des cas en dix minutes :

• sudo ufw status verbose — règles actives ? Port et protocole (tcp/udp) corrects ?
• sudo ss -tlnp — l’app écoute sur 0.0.0.0 et pas seulement 127.0.0.1 ?
• Règles entrantes du groupe de sécurité alignées ?
• Docker contourne-t-il UFW ?
• sudo ufw disable temporaire pour comparer (puis réactiver)

Une seule IP source en échec ? Cherchez deny from ou bannissement fail2ban. Les logs UFW sont peu verbeux par défaut ; si besoin LOGLEVEL=medium dans /etc/ufw/ufw.conf, sudo ufw reload, paquets refusés dans /var/log/ufw.log.

Checklist de mise en production (à copier)

Machine neuve ou réinstallation — exécutez dans l’ordre :

sudo apt install ufw -y
                sudo ufw default deny incoming
                sudo ufw default allow outgoing
                sudo ufw allow 22/tcp comment 'SSH'      # ou votre port personnalisé
                sudo ufw allow 80/tcp
                sudo ufw allow 443/tcp
                sudo ufw limit 22/tcp                    # optionnel : limitation SSH
                sudo ufw enable
                sudo ufw status verbose

N’oubliez pas le durcissement système : clés SSH, désactivation connexion root par mot de passe, mises à jour via unattended-upgrades. Le pare-feu est une frontière, pas une panacée — mais il bloque la majorité des scans automatisés le temps de sécuriser plus en profondeur.