Un pare-feu sous Linux est un filtre de paquets implémenté dans le noyau, piloté par une ou plusieurs commandes utilisateur. Il décide, paquet par paquet, ce qui entre ou sort de la machine selon un jeu de règles. C’est la première couche de défense d’un serveur exposé, et la moins coûteuse : aucun service supplémentaire, juste une configuration du noyau déjà en place. Cette page pose les concepts que vous devez maîtriser avant d’ouvrir UFW ou Firewalld — politique par défaut, flux entrants/sortants, ports, état des connexions, et où s’arrête le pare-feu hôte.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Ce qu’est un pare-feu Linux — et ce qu’il n’est pas
- Raisonner en politique par défaut : deny-by-default vs allow-by-default
- Distinguer flux entrant, flux sortant, flux routé
- Comprendre le stateful (suivi de connexion) et pourquoi ça simplifie les règles
- Situer les outils :
nftables(noyau), UFW et Firewalld (frontends) - Savoir quand un pare-feu hôte suffit et quand il faut un pare-feu réseau en complément
Qu’est-ce qu’un pare-feu ?
Section intitulée « Qu’est-ce qu’un pare-feu ? »Un pare-feu est un filtre de paquets : il examine chaque paquet réseau qui traverse la machine et décide, selon des règles, de le laisser passer, de le bloquer, ou de le rediriger.
Sous Linux, ce filtrage est fait dans le noyau par Netfilter, le sous-système historique, piloté aujourd’hui par nftables (et encore par iptables sur les systèmes plus anciens). Les outils que vous utilisez au quotidien — UFW, Firewalld, firewall-cmd, ufw, nft — sont des interfaces qui traduisent vos règles en instructions pour Netfilter.
Ce qu’un pare-feu fait :
- autorise ou refuse le trafic selon source, destination, port, protocole, état de la connexion
- peut rediriger un port vers une autre machine (NAT, forwarding)
- peut journaliser les paquets pour audit
Ce qu’un pare-feu ne fait pas :
- il n’inspecte pas le contenu des paquets chiffrés — TLS passe intact, il voit juste « port 443 »
- il ne remplace pas l’authentification — si vous laissez SSH ouvert sans clé forte, le pare-feu n’y changera rien
- il ne corrige pas une vulnérabilité applicative — un Apache non patché derrière un pare-feu reste vulnérable
Pourquoi un pare-feu même derrière un routeur ?
Section intitulée « Pourquoi un pare-feu même derrière un routeur ? »La question revient souvent : « Mon routeur / mon cloud provider a déjà un pare-feu, pourquoi en mettre un sur la machine ? ». Trois réponses :
- Défense en profondeur — une règle mal configurée au niveau réseau ne doit pas exposer directement un service interne.
- Trafic latéral — deux machines dans le même sous-réseau cloud peuvent se parler sans passer par le security group. Seul le pare-feu hôte filtre entre elles.
- Sortie contrôlée — un pare-feu réseau filtre surtout l’entrée ; contrôler la sortie (exfiltration) se fait plus naturellement côté hôte.
Les concepts clés
Section intitulée « Les concepts clés »Politique par défaut
Section intitulée « Politique par défaut »C’est la règle appliquée quand aucune autre règle n’a matché. Deux postures possibles :
- Deny-by-default — tout est bloqué sauf ce que vous autorisez explicitement. Posture recommandée pour un serveur.
- Allow-by-default — tout passe sauf ce que vous bloquez explicitement. Acceptable sur un poste de dev isolé, rarement ailleurs.
UFW et Firewalld appliquent tous deux un deny-by-default sur le trafic entrant dès qu’ils sont activés, et un allow-by-default sur le trafic sortant. C’est la baseline la plus utile.
Flux entrants, sortants, routés
Section intitulée « Flux entrants, sortants, routés »Netfilter distingue trois trajets possibles pour un paquet :
| Flux | Description | Exemple |
|---|---|---|
| INPUT (entrant) | Paquet destiné à la machine elle-même | Quelqu’un tape votre IP sur port 443 |
| OUTPUT (sortant) | Paquet émis par la machine | Votre serveur contacte le dépôt apt |
| FORWARD (routé) | Paquet qui traverse la machine sans lui être destiné | Routeur Linux, VPN, NAT |
La plupart des serveurs ne routent rien — seuls INPUT et OUTPUT comptent. FORWARD devient pertinent pour un routeur, un hyperviseur KVM ou un pod réseau Kubernetes.
Stateful : le suivi de connexions
Section intitulée « Stateful : le suivi de connexions »Les pare-feux modernes sont stateful : ils se souviennent des connexions déjà ouvertes et laissent automatiquement passer les réponses.
Concrètement : vous n’avez pas besoin d’écrire une règle pour autoriser le retour d’un paquet que vous avez initié. Quand votre serveur fait apt update, le pare-feu retient qu’une connexion sortante vers deb.debian.org:443 a été établie, et il accepte les paquets de retour sans règle explicite.
Les états typiques (visibles dans conntrack -L) :
NEW— première rencontre du paquet (c’est là que la décision d’autorisation se joue)ESTABLISHED— paquet lié à une connexion déjà validéeRELATED— paquet lié à une connexion existante (FTP passif, ICMP en réponse)INVALID— paquet incohérent, à bloquer
Règle d’or : ne filtrez que le NEW. Laissez passer ESTABLISHED et RELATED ; bloquez INVALID. UFW et Firewalld le font pour vous par défaut.
Ports, services, protocoles
Section intitulée « Ports, services, protocoles »Un paquet TCP ou UDP porte un port source et un port destination (0-65535). Les ports bas (< 1024) sont réservés à root.
Quelques ports à mémoriser :
| Port | Protocole | Service |
|---|---|---|
| 22 | TCP | SSH |
| 25 | TCP | SMTP (souvent filtré en sortie par l’hébergeur) |
| 53 | UDP + TCP | DNS |
| 80 | TCP | HTTP |
| 443 | TCP | HTTPS |
| 587 | TCP | SMTP submission (chiffré) |
| 993 | TCP | IMAPS |
| 5432 | TCP | PostgreSQL |
| 6443 | TCP | Kubernetes API |
Les frontends Firewalld et UFW proposent des noms de services (http, ssh, postgresql…) qui se résolvent en port/protocole via /etc/services. Préférer ces noms rend vos règles lisibles et portables.
Comment ça marche sous Linux
Section intitulée « Comment ça marche sous Linux »La couche noyau : nftables ou iptables
Section intitulée « La couche noyau : nftables ou iptables »Tout le filtrage se fait dans le noyau via Netfilter. Deux mécanismes cohabitent :
nftables— standard moderne (depuis Linux 3.13, 2014). Plus expressif, plus performant, syntaxe unifiée. Présent sur RHEL 8+, Debian 10+, Ubuntu 20.04+.iptables— l’ancêtre. Encore là par compatibilité, souvent en wrapper qui traduit versnftablesen interne (iptables-nft).
Vous pouvez écrire des règles nft à la main, mais c’est rare. La quasi-totalité des administrateurs utilisent un frontend.
Les frontends : UFW, Firewalld, direct
Section intitulée « Les frontends : UFW, Firewalld, direct »| Outil | Distribution typique | Points forts |
|---|---|---|
| UFW | Debian, Ubuntu | Syntaxe lisible, installation immédiate, pas de zones |
| Firewalld | RHEL, Fedora, CentOS Stream, Rocky, AlmaLinux | Zones dynamiques, reload à chaud, services pré-définis |
nft direct | Tous | Contrôle total, mais syntaxe plus verbeuse, nécessaire pour cas pointus |
Règle pragmatique : restez sur le frontend par défaut de votre distribution. Ne mélangez pas UFW et Firewalld sur la même machine — ils écrivent tous deux dans Netfilter et se contredisent silencieusement.
Pare-feu hôte vs pare-feu réseau
Section intitulée « Pare-feu hôte vs pare-feu réseau »Deux emplacements possibles, deux rôles complémentaires :
| Type | Où | Exemples | Rôle |
|---|---|---|---|
| Hôte | Sur chaque machine | UFW, Firewalld, nftables | Filtre ce qui entre/sort de la machine elle-même |
| Réseau | Sur le chemin entre plusieurs machines | Routeur, pare-feu cloud (security group AWS, GCP, Azure), OPNsense, pfSense | Filtre à l’entrée du périmètre |
En production sérieuse, vous avez les deux. En homelab ou sur une VM cloud isolée, le pare-feu hôte seul est déjà un progrès considérable face à un serveur sans pare-feu du tout.
Les pare-feux nouvelle génération (NGFW), IDS/IPS et WAF ajoutent des couches d’analyse applicative (inspection du contenu HTTP, détection de signatures d’attaque) — c’est un domaine séparé qui sort du périmètre de cette page.
Pièges courants
Section intitulée « Pièges courants »- Activer le pare-feu sans autoriser SSH — coupure garantie si vous travaillez à distance. Autorisez toujours le port d’administration avant l’activation.
- Oublier
--permanent(Firewalld) — la règle disparaît au prochain reload ou reboot. - Règle allow trop large —
allow from anysur un port applicatif expose sur Internet un service qui devrait être en LAN. Scopez à192.168.0.0/16ou au CIDR du VPN. - Mixer UFW et Firewalld — comportement imprévisible, silences étranges. Choisissez-en un et désactivez l’autre.
- Mixer UFW/Firewalld et des règles
iptablesà la main — les frontends gèrent leurs propres chaînes, une modification manuelle peut être écrasée. - Compter sur le pare-feu pour cacher un service vulnérable — un Nextcloud non patché exposé en LAN reste compromissible.
- Ne pas journaliser — sans journalisation, un paquet bloqué qu’on cherche depuis 3 h reste invisible. Activez temporairement
ufw logging mediumoufirewall-cmd --set-log-denied=unicastpendant le diagnostic.
À retenir
Section intitulée « À retenir »- Un pare-feu Linux est un filtre de paquets dans le noyau (Netfilter), piloté par un frontend (UFW, Firewalld,
nft). - Politique par défaut recommandée :
denyen entrée,allowen sortie. - Les pare-feux modernes sont stateful — filtrez le
NEW, laissez passerESTABLISHED/RELATED, bloquezINVALID. - Trois trajets à connaître : INPUT (pour la machine), OUTPUT (depuis la machine), FORWARD (à travers la machine).
- UFW sur Debian/Ubuntu, Firewalld sur RHEL/Fedora/Rocky — ne pas mélanger.
- Préférer les noms de services (
ssh,http) aux numéros de port pour la lisibilité. - Pare-feu hôte ≠ pare-feu réseau — les deux se complètent, aucun ne remplace l’autre ni ne corrige les bugs applicatifs.
- Toujours autoriser SSH avant l’activation et avoir un accès console de secours.