Configuration de pare-feu : UFW, iptables et conception de stratégies de sécurité

Un SMS d’alerte serveur vous arrache du sommeil — une base de données de test subit un scan anormal. Une fois connecté, le pare-feu est éteint. Vous l’activez et découvrez un fouillis de règles de test, sans limitation de débit sur SSH.

Cette expérience rappelle une réalité : beaucoup configurent un pare-feu en copiant quelques commandes, ignorent la différence entre UFW et iptables, et ne pensent jamais à une stratégie de sécurité cohérente. Voyons tout cela en détail.

Comment fonctionne le pare-feu Linux

Avant le pare-feu lui-même, clarifions un concept souvent confondu : Netfilter. Beaucoup croient qu’iptables est le pare-feu — ce n’est pas exact.

Netfilter est le framework de traitement des paquets dans le noyau Linux. Il place des « hooks » aux points clés de la pile réseau ; chaque paquet peut y déclencher une logique personnalisée — blocage, modification, journalisation.

iptables, UFW et nftables ne sont que des interfaces utilisateur. Les règles que vous écrivez sont converties au format Netfilter et exécutées dans le noyau.

Image simple : Netfilter, ce sont les vannes sous la chaussée ; iptables, la molette manuelle ; UFW, le panneau tactile — même objectif, ergonomie différente.

Évolution des outils utilisateur

Les outils de pare-feu Linux ont beaucoup évolué :

• iptables : outil historique (vers 2000). Accès direct à Netfilter, syntaxe complexe, puissance maximale.
• nftables : successeur moderne (2014). Syntaxe unifiée, meilleures performances ; Ubuntu récent l’utilise souvent en backend.
• UFW (Uncomplicated Firewall) : simplification Ubuntu (2008). Toujours iptables/nftables en dessous, commandes très courtes.
• firewalld : gestion dynamique sur les distributions Red Hat, modifications à chaud sans couper les connexions.

Cet article se concentre sur UFW et iptables, les plus utilisés en production. nftables est plus moderne mais conceptuellement proche ; maîtriser iptables facilite la transition.

UFW : rendre la configuration moins pénible

Pourquoi UFW est si populaire

Qui a manipulé iptables connaît la prudence extrême — une option mal placée et SSH disparaît, vous êtes dehors.

UFW mise sur la simplicité. Une commande ouvre un port, sans mémoriser -A INPUT -p tcp --dport 22 -j ACCEPT.

Comparaison :

iptables :

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

UFW :

ufw allow ssh

La différence parle d’elle-même. UFW gère protocole, suivi d’état et IPv6 ; vous dites simplement « j’ouvre SSH ».

Configuration de base : partir de zéro

Sur un serveur neuf, voici la séquence recommandée :

Étape 1 : politique par défaut

Elle définit le comportement quand aucune règle ne correspond. Principe de sécurité : tout refuser à l’entrée, tout autoriser à la sortie.

sudo ufw default deny incoming   # Refuser toutes les connexions entrantes
sudo ufw default allow outgoing   # Autoriser toutes les connexions sortantes

Sans règle explicite, personne n’entre. Beaucoup laissent « allow » par défaut — le serveur reste une porte ouverte.

Étape 2 : ouvrir les ports nécessaires

Piège classique : ouvrez SSH avant d’activer le pare-feu, sinon la session distante tombe.

sudo ufw allow ssh        # SSH (port 22)
sudo ufw allow 80/tcp     # HTTP
sudo ufw allow 443/tcp    # HTTPS

SSH sur un port personnalisé (2222) :

sudo ufw allow 2222/tcp

Étape 3 : activer le pare-feu

sudo ufw enable

Un avertissement apparaît : « This may disrupt existing ssh connections » — pas de panique si allow ssh a été exécuté. Confirmez avec y.

Étape 4 : vérifier l’état

sudo ufw status verbose

Exemple de sortie :

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)

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

Status: active confirme que le pare-feu fonctionne.

Techniques avancées : renforcer la configuration

Profils d’application (App Profiles)

UFW propose des profils pour Nginx, Apache, OpenSSH, etc.

Lister les profils :

sudo ufw app list

Exemple :

Available applications:
  Apache
  Apache Full
  Apache Secure
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

Ouvrir via le nom d’application :

sudo ufw allow 'Nginx Full'

HTTP (80) et HTTPS (443) d’un coup — pratique.

Limitation de débit : anti force brute

SSH subit souvent des attaques par dictionnaire :

sudo ufw limit ssh

Plus de 6 tentatives en 30 secondes depuis une IP → blocage temporaire. Plus sûr qu’un simple allow ssh.

Restreindre par adresse IP

Parfois, seule une IP doit accéder à un service — par exemple l’admin MySQL depuis le réseau interne :

# Autoriser uniquement 192.168.1.100 pour MySQL
sudo ufw allow from 192.168.1.100 to any port 3306

# Refuser une IP malveillante
sudo ufw deny from 203.0.113.100

Journalisation

Les logs aident au diagnostic :

sudo ufw logging on
sudo ufw logging medium   # Niveaux : low/medium/high

Fichier /var/log/ufw.log, par exemple :

Mar 15 10:23:45 server kernel: [UFW BLOCK] IN=eth0 OUT= MAC=... SRC=203.0.113.100 DST=... PROTO=TCP SPT=54321 DPT=22

[UFW BLOCK] signifie un paquet refusé.

Limites d’UFW

UFW a des frontières :

• NAT et redirection : support limité ; scénarios complexes → iptables
• Chaînes personnalisées : pas de chaînes ni de conditions imbriquées
• Filtrage par contenu : impossible (ex. payload HTTP malveillant)

Au-delà, direction iptables.

iptables : contrôle fin

Architecture d’iptables

Plus complexe qu’UFW, la logique reste claire : tables → chaînes → règles.

Tables

Chaque table a un rôle :

• filter (défaut) : filtrage accept/reject
• nat : translation d’adresses (NAT)
• mangle : TOS, TTL, métadonnées
• raw : exceptions, contournement du suivi de connexion

La plupart du temps, on travaille sur filter.

Chaînes

Ensemble ordonné de règles. Sur filter, cinq chaînes intégrées :

• INPUT : paquets entrants (destination = cette machine)
• OUTPUT : paquets sortants (source = cette machine)
• FORWARD : transit (machine relais)
• PREROUTING : avant routage
• POSTROUTING : après routage

Au quotidien : INPUT et OUTPUT ; FORWARD pour routeur ou passerelle.

Ordre de correspondance

Les règles s’évaluent de haut en bas ; la première correspondance s’applique, le reste est ignoré.

Exemple :

iptables -A INPUT -s 192.168.1.100 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -j DROP

192.168.1.100 correspond à la première règle ACCEPT. Inverser l’ordre : 192.168.1.100 serait DROP avant d’atteindre ACCEPT.

Principe clé : règles spécifiques en haut, générales en bas.

Décomposition de la syntaxe

Format de base :

iptables -t table -A chaîne conditions -j action

Paramètres courants :

• -t : table (filter par défaut)
• -A : ajouter en fin (Append)
• -I : insérer (Insert)
• -D : supprimer (Delete)
• -L : lister (List)
• -F : vider (Flush)
• -P : politique par défaut (Policy)

Conditions

• -s : IP source
• -d : IP destination
• -p : protocole (tcp, udp, icmp)
• --sport / --dport : ports source/destination
• -i / -o : interface entrante/sortante
• -m state --state : suivi d’état

Actions (Target)

• ACCEPT : accepter
• DROP : abandon silencieux
• REJECT : refus avec message
• LOG : journaliser sans bloquer
• RETURN : revenir à la chaîne parente

Configuration production : pare-feu sécurisé

Étape 1 : vider les règles existantes

sudo iptables -F
sudo iptables -X
sudo iptables -t nat -F
sudo iptables -t mangle -F

Étape 2 : politique par défaut

sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

Étape 3 : connexions établies

Crucial pour le trafic de retour :

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Votre requête sort en OUTPUT (ACCEPT) ; la réponse arrive en INPUT. Sans cette règle, DROP bloque la réponse.

Étape 4 : ports nécessaires

# SSH
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# HTTP
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# HTTPS
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Étape 5 : ICMP (optionnel)

# Autoriser ping
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Ou refuser ping
sudo iptables -A INPUT -p icmp -j DROP

Étape 6 : journalisation

Avant le DROP final :

sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 4

--limit 5/min évite l’explosion des logs.

Étape 7 : DROP explicite

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

La politique INPUT est déjà DROP ; une règle explicite clarifie l’intention :

sudo iptables -A INPUT -j DROP

Étape 8 : persistance

sudo apt install iptables-persistent
sudo netfilter-persistent save

Ou manuellement :

sudo iptables-save > /etc/iptables/rules.v4
sudo ip6tables-save > /etc/iptables/rules.v6  # IPv6

Consulter les règles

sudo iptables -L -n -v --line-numbers

• -n : affichage numérique
• -v : compteurs détaillés
• --line-numbers : numéros de règles

Exemple :

Chain INPUT (policy DROP 0 packets, 0 bytes)
num  pkts bytes target     prot opt in     out     source               destination
1      42  2848 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state ESTABLISHED,RELATED
2       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
3       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
4       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
5       0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 5/min burst 5 LOG flags 0 level 4 prefix "iptables denied: "
6       0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

UFW ou iptables : que choisir

Différence centrale : simplicité vs flexibilité

La vérité sur les performances

Même moteur noyau. Seul le nombre de règles influence la latence de correspondance — négligeable sur un serveur modeste.

Recommandations

Préférez UFW :

• VPS, cloud, serveur dédié
• Web, API
• Pas de NAT complexe
• Admin non spécialiste réseau
• Réponse d’urgence à une attaque

Préférez iptables :

• Passerelle, routeur, VPN
• NAT, redirection, load balancing
• Règles multi-niveaux
• Déploiements massifs scriptés
• Filtrage avancé (contenu, débit, horaires)
• Équipe réseau dédiée

Mélanger les deux ?

Déconseillé. Conflits possibles sur les mêmes règles Netfilter.

Exemple : SSH ouvert via iptables, puis refusé par UFW — la dernière règle gagne, vous êtes dehors.

Si vous devez combiner, UFW insère ses règles entre before.rules et after.rules ; des règes iptables directes peuvent être écrasées.

Principes de conception d’une stratégie de sécurité

Maîtriser l’outil ne suffit pas ; il faut une stratégie cohérente. Ajouter des règles au hasard laisse des failles.

Principe 1 : refus par défaut (Default Deny)

Pierre angulaire de la sécurité.

Idée : tout refuser sauf autorisation explicite.

L’approche inverse — tout ouvrir puis bloquer — échoue car :

1. Vous ne connaissez pas tous les ports à risque (65535 ports scannables)
2. Un oubli = une porte ouverte

Bonne pratique :

# UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing

# iptables
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT ACCEPT

N’ouvrez que le strict nécessaire. Pour chaque port : à quoi sert-il ? Peut-on restreindre la source ?

Principe 2 : moindre privilège

Chaque règle doit être la plus étroite possible.

Ports :

• ❌ ufw allow 3306 (MySQL ouvert au monde)
• ✅ ufw allow from 192.168.1.100 to any port 3306

Services :

• ❌ Tous les ports internes exposés
• ✅ Seulement Web/API publics ; interne via VPN ou réseau privé

SSH :

• ❌ ufw allow ssh sans restriction
• ✅ ufw allow from IP_entreprise to any port 22 + ufw limit ssh

Principe 3 : défense en profondeur (Defense-in-Depth)

Le pare-feu n’est qu’une couche :

1. Réseau (UFW/iptables) : trafic malveillant
2. Application (WAF) : SQLi, XSS HTTP
3. Hôte (SELinux/AppArmor) : permissions processus
4. Détection (IDS/IPS) : comportements anormaux
5. Audit : logs, scans de vulnérabilités

Exemple : port 80 ouvert → WAF filtre les payloads → SELinux limite les fichiers du serveur Web → l’application valide encore les entrées.

Principe 4 : segmentation réseau

Un grand réseau ne doit pas être uniforme.

Modèle typique :

• DMZ : services publics (Web, mail)
• Intranet : bases, services internes
• Management : ops, monitoring, logs

Bénéfices : isolement des incidents, limitation de propagation, permissions granulaires.

La chaîne FORWARD segmente avec iptables :

# DMZ vers intranet : MySQL uniquement
iptables -A FORWARD -s dmz_network -d internal_network -p tcp --dport 3306 -j ACCEPT
iptables -A FORWARD -s dmz_network -d internal_network -j DROP

Principe 5 : audit et mise à jour

La configuration n’est pas figée.

Revue des règles :

• Mensuel : règles obsolètes (ports de test oubliés)
• Trimestriel : adéquation aux changements métier
• Annuel : nettoyage et optimisation

Analyse des logs :

• Hebdomadaire : IPs bloquées, motifs
• Alertes sur seuils
• Traçabilité des attaques

Adaptation :

• Nouveau service : évaluation risque avant ouverture
• Incident : blocage IP, renforcement limit
• Évolution métier : suppression des règles inutiles

Production : éviter les pièges

Étapes sécurisées

1. Tester d’abord

Ne testez jamais une nouvelle règle directement en production. VM de test ou environnement dev d’abord.

2. Garder une sortie SSH

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Vérifiez SSH avant activation. Port personnalisé :

# UFW
ufw allow 2222/tcp

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT

3. Ouvrir progressivement

SSH d’abord, connexion validée, puis Web, puis le reste.

4. Documenter les changements

Date, contenu, motif, validation. Git pour les fichiers de règles ou un registre dédié.

Erreurs fréquentes

Erreur 1 : verrouillage SSH

Symptôme : connexion SSH coupée après activation.

Cause : SSH non autorisé ou mauvais ordre (DROP avant ACCEPT).

Prévention :

1. Identifier le port SSH actuel
2. ufw allow ssh puis ufw enable
3. Pour iptables, règle SSH avant DROP

Urgence :

• VPS : console fournisseur
• Cloud : mode recovery / rescue
• Physique : accès local

Erreur 2 : ordre des règles

Symptôme : port autorisé mais inaccessible.

Cause : DROP matché avant ACCEPT.

Diagnostic :

iptables -L -n -v --line-numbers

Correction :

iptables -D INPUT 3
iptables -I INPUT 2 -p tcp --dport 80 -j ACCEPT

Erreur 3 : absence de persistance

Symptôme : règles perdues au reboot.

Solution :

# Ubuntu/Debian
sudo apt install iptables-persistent
sudo netfilter-persistent save

# CentOS/RHEL
sudo service iptables save

UFW persiste sans action supplémentaire.

Erreur 4 : IPv6 oublié

Symptôme : IPv4 OK, IPv6 inaccessible.

Cause : iptables ne couvre que IPv4.

Solution :

sudo ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo ip6tables-save > /etc/iptables/rules.v6

UFW gère IPv6 automatiquement.

Dépannage

1. État du pare-feu

# UFW
sudo ufw status verbose

# iptables
sudo iptables -L -n -v

2. Connectivité des ports

# Depuis l'extérieur
telnet server_ip 22
nc -zv server_ip 80

# Local
sudo netstat -tulnp | grep :22

3. Logs

# UFW
tail -f /var/log/ufw.log

# iptables
tail -f /var/log/kern.log | grep "iptables"

4. Désactivation temporaire

# UFW
sudo ufw disable

# iptables
sudo iptables -F

Testez la connectivité, puis réactivez immédiatement — sans pare-feu, le serveur est nu.

Synthèse : bâtir votre système de pare-feu

Choix d’outil

• Scénarios simples : UFW, quelques minutes, serein
• Scénarios complexes : iptables, passerelle, NAT, filtrage avancé
• Pas de mélange : un seul outil, une seule source de vérité

Principes

• Refus par défaut à l’entrée
• Moindre privilège et restriction IP
• Défense en profondeur avec WAF, SELinux, etc.
• Segmentation DMZ / intranet / management
• Audit mensuel, trimestriel, annuel

Points pratiques

• SSH en premier avant toute activation
• Ordre des règles iptables : du spécifique au général
• Persistance iptables obligatoire
• IPv6 : ip6tables ou UFW automatique
• Test avant production
• Logs activés et analysés

Pour aller plus loin

• nftables : successeur d’iptables
• firewalld : gestion dynamique
• WAF : Nginx ModSecurity, Cloudflare WAF
• Détection : Fail2ban, OSSEC
• SELinux/AppArmor : contrôle au niveau hôte

La configuration du pare-feu est la base de la sécurité serveur. Maîtriser UFW et iptables, comprendre les principes de stratégie — et votre serveur ne ressemblera plus à une maison sans serrure. Les SMS à trois heures du matin deviendront plus rares.

Références

• UFW Essentials: Common Firewall Rules and Commands - DigitalOcean
• UFW vs iptables: Simple Firewall Rules That Actually Work - WeHaveServers
• Difference Between ufw vs. nftables vs. iptables - Baeldung on Linux
• Firewall Design Principles In Network Security - Fortinet
• Linux Firewall: Configuration, Tools, Best Practices - TuxCare
• Ubuntu Community Help Wiki - UFW