Firewall Linux : nftables, iptables, UFW et firewalld en 2026

Un firewall Linux repose toujours sur le même moteur : Netfilter, le sous-système de filtrage intégré au noyau, piloté par des outils en espace utilisateur comme nftables, iptables, UFW ou firewalld. Le choix de l'outil dépend surtout de la distribution : nftables est natif sur Debian, UFW est l'interface proposée par Ubuntu et firewalld équipe Red Hat Enterprise Linux, Fedora, AlmaLinux ou Rocky Linux. Sur la plupart des serveurs récents, les commandes iptables sont d'ailleurs déjà traduites en règles nftables sans que l'administrateur s'en aperçoive. Le véritable enjeu n'est donc pas l'outil, mais la politique : refus par défaut, accès d'administration restreint, IPv6 traité comme IPv4, journalisation exploitable et procédure de retour arrière. Ce guide détaille ces outils, des configurations commentées, les pièges courants (Docker, verrouillage SSH, règles non persistantes) et une méthode de durcissement. Pour protéger un réseau complet plutôt qu'un seul serveur, consultez notre guide d'installation et de configuration du pare-feu OPNsense.

Firewall Linux : définition et rôle de Netfilter dans le noyau

La documentation de sécurité d'Ubuntu rappelle que toutes les solutions de pare-feu modernes sous Linux utilisent Netfilter pour filtrer les paquets. Deux composants de ce sous-système jouent le rôle de filtre : l'ancien iptables et son successeur nftables, entré dans le noyau principal avec la version 3.13 en 2014. Les outils que l'administrateur manipule ne sont que des interfaces vers ce moteur.

On parle de pare-feu d'hôte lorsque les règles protègent la machine elle-même, et de pare-feu réseau lorsque la machine Linux route du trafic entre plusieurs segments. Le même noyau sait faire les deux. Un serveur web exposé utilise surtout le filtrage en entrée, tandis qu'une passerelle Linux exploite aussi le transit et la traduction d'adresses (NAT, Network Address Translation).

Les points d'accroche de Netfilter

Netfilter insère des points d'accroche, appelés hooks, à des étapes précises du trajet d'un paquet. Le hook prerouting voit le paquet dès son arrivée, avant la décision de routage. Ensuite, input traite ce qui est destiné à la machine locale, forward ce qui la traverse, output ce qu'elle émet, et postrouting intervient juste avant la sortie sur l'interface réseau.

Chaque chaîne de règles est rattachée à l'un de ces hooks avec une priorité. Pour un pare-feu d'hôte, la chaîne d'entrée concentre l'essentiel du travail. Pour un routeur ou un hôte de conteneurs, la chaîne de transit devient au moins aussi importante. Comprendre ce découpage évite une erreur fréquente : filtrer l'entrée en oubliant que le trafic routé vers des conteneurs ou des machines virtuelles ne passe pas par elle.

Le suivi de connexion, cœur du filtrage à états

Le suivi de connexion (connection tracking, ou conntrack) mémorise l'état de chaque flux : nouveau, établi, lié à un flux existant ou invalide. Grâce à lui, une seule règle suffit à accepter les réponses aux connexions légitimes, sans ouvrir de ports en retour. La documentation d'Ubuntu précise qu'iptables et nftables savent travailler avec ou sans état, et qu'UFW est conçu pour filtrer avec état.

iptables, nftables, UFW et firewalld : qui fait quoi ?

La confusion vient du fait que ces quatre noms ne désignent pas des produits concurrents de même niveau. nftables et iptables sont deux interfaces de bas niveau vers Netfilter. UFW (Uncomplicated Firewall) et firewalld sont des gestionnaires de plus haut niveau qui génèrent des règles pour l'un ou l'autre. Sur un système récent, la commande iptables elle-même est souvent une couche de compatibilité, appelée iptables-nft, qui écrit en réalité dans nftables.

La documentation d'Ubuntu indique ainsi que le moteur nftables est utilisé par défaut derrière les commandes iptables depuis Ubuntu 20.10. Debian a fait la même bascule avec Debian 10 « Buster » en 2019, et firewalld utilise nftables comme moteur par défaut depuis sa version 0.6.0, publiée en juillet 2018. Pour savoir quel moteur est actif, la commande iptables -V affiche la mention « nf_tables » ou « legacy ».

Pourquoi nftables remplace iptables

Le wiki du projet nftables résume les différences. Il n'existe plus de tables ni de chaînes prédéfinies : l'administrateur ne crée que ce dont il a besoin. La famille inet applique une même table à IPv4 et IPv6, ce qui supprime les scripts dupliqués. Les ensembles et dictionnaires natifs remplacent des centaines de règles linéaires, et une règle peut combiner plusieurs actions, par exemple journaliser puis rejeter.

Autre progrès décisif : avec l'option -f, nftables lit tout le fichier de configuration et remplace l'ancienne politique en une seule opération atomique. Il n'existe donc plus d'instant où le pare-feu est à moitié chargé, contrairement aux anciens scripts shell enchaînant des dizaines de commandes iptables. Pour un nouveau déploiement, écrire directement en nftables est le choix le plus durable.

Configurer un firewall Linux sur Debian avec nftables

Depuis Debian 10, le filtrage réseau repose par défaut sur nftables, et les commandes iptables restent disponibles grâce à la couche iptables-nft. Le paquet nftables fournit un service systemd qui charge le fichier /etc/nftables.conf au démarrage. Une installation standard ne charge cependant aucune politique restrictive : c'est à l'administrateur d'écrire et d'activer la sienne, idéalement dès la mise en service du serveur.

Debian 13 « trixie », publiée le 9 août 2025, ajoute un point d'attention pour le durcissement réseau. Selon les notes de version de Debian 13, systemd-sysctl ne lit plus /etc/sysctl.conf : les paramètres réseau du noyau doivent désormais être placés dans des fichiers /etc/sysctl.d/*.conf. Un ancien réglage oublié dans le fichier historique cesse donc silencieusement de s'appliquer après la mise à niveau.

Une politique de base commentée

L'exemple suivant protège un serveur web Debian. Il refuse tout par défaut en entrée et en transit, accepte les réponses aux connexions établies, autorise HTTPS pour tous et SSH (Secure Shell) uniquement depuis deux postes d'administration. Les adresses utilisent la plage réservée à la documentation : adaptez-les à votre réseau. Les messages ICMPv6 indispensables au fonctionnement d'IPv6 restent autorisés.

#!/usr/sbin/nft -f
# /etc/nftables.conf - serveur web Debian (exemple a adapter)
flush ruleset

table inet filtrage {
    set admin_v4 {
        type ipv4_addr
        elements = { 192.0.2.10, 192.0.2.11 }
    }

    chain input {
        type filter hook input priority filter; policy drop;
        iif "lo" accept
        ct state invalid drop
        ct state established,related accept
        icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert, packet-too-big, destination-unreachable, time-exceeded, parameter-problem } accept
        icmp type { destination-unreachable, time-exceeded } accept
        icmp type echo-request limit rate 5/second accept
        ip saddr @admin_v4 tcp dport 22 ct state new accept
        tcp dport 443 ct state new accept
        limit rate 10/minute burst 20 packets log prefix "nft-input-refus: " level info
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

La dernière règle journalise un échantillon des paquets refusés, avec une limite de débit pour ne pas saturer les journaux lors d'un balayage de ports. La chaîne de sortie reste ouverte dans cet exemple ; sur un serveur sensible, la restreindre aux destinations utiles (dépôts de mises à jour, DNS, serveur de journaux) limite fortement l'exfiltration et les connexions de retour d'un attaquant.

Valider, appliquer et persister sans se verrouiller

Une erreur de syntaxe ou une règle SSH mal placée suffit à couper l'accès distant. La méthode sûre consiste à sauvegarder la configuration en place, à vérifier le nouveau fichier sans l'appliquer, puis à programmer un retour arrière automatique que l'on annule seulement après avoir confirmé l'accès depuis une nouvelle session. Ne fermez jamais la session SSH en cours avant d'avoir validé une seconde connexion.

sudo cp /etc/nftables.conf /root/nftables.conf.bak     # sauvegarde
sudo nft -c -f /etc/nftables.conf                      # verification, rien n'est applique
sudo systemd-run --unit=fw-rollback --on-active=5min /usr/sbin/nft -f /root/nftables.conf.bak
sudo nft -f /etc/nftables.conf                         # application atomique
# Ouvrir une NOUVELLE session SSH ; si elle fonctionne, annuler le retour arriere :
sudo systemctl stop fw-rollback.timer
sudo systemctl enable --now nftables                   # chargement au demarrage

Cette discipline vaut pour tous les outils. Sur un serveur hébergé, vérifiez aussi que vous disposez d'une console hors bande (console série, interface du fournisseur ou accès de l'hyperviseur) avant toute modification importante. Le coût de cette précaution est de quelques minutes, celui d'un verrouillage peut être une intervention physique.

Firewall Linux sur Ubuntu : maîtriser UFW sans se tromper

Sur Ubuntu, l'outil de configuration du pare-feu proposé par défaut est UFW. La documentation officielle précise qu'il est installé mais désactivé par défaut, qu'il sert de surcouche à iptables comme à nftables et qu'il filtre avec état. Une fois activé, son profil standard refuse les connexions entrantes et autorise les connexions sortantes. Il cible principalement les pare-feux d'hôte, ce qui correspond à l'usage le plus courant sur un serveur Ubuntu.

La première règle à créer est celle qui préserve l'accès d'administration. Autorisez SSH avant d'exécuter ufw enable, sinon la session distante peut être coupée dès l'activation. Restreindre SSH à une plage d'adresses d'administration vaut mieux qu'une ouverture à tout Internet. Les commentaires de règle, disponibles dans les versions récentes, facilitent les revues ultérieures.

sudo ufw status verbose                       # etat actuel
sudo ufw default deny incoming
sudo ufw default deny routed
sudo ufw default allow outgoing
sudo ufw allow from 192.0.2.0/28 to any port 22 proto tcp comment 'SSH administration'
sudo ufw allow 443/tcp comment 'HTTPS public'
sudo ufw logging low
sudo ufw enable
sudo ufw status numbered                      # verifier et numeroter les regles

Limitation de débit et profils d'applications

Lorsque SSH doit rester joignable depuis Internet, la règle ufw limit 22/tcp refuse une adresse qui tente six connexions ou plus en trente secondes, d'après la page de manuel d'UFW. Attention : une règle « limit » accepte tout ce qu'elle ne bloque pas, elle ouvre donc le port à tous. Elle ne remplace ni l'authentification par clé, ni la désactivation de la connexion directe du compte root.

Les profils d'applications, stockés dans /etc/ufw/applications.d, décrivent les ports d'un logiciel et s'utilisent avec ufw app list puis ufw allow suivi du nom du profil. Ils sont pratiques, mais vérifiez leur contenu avec ufw app info : un profil peut ouvrir plus de ports que nécessaire, par exemple une interface d'administration en plus du service public.

Le piège Docker : des ports publiés hors du contrôle d'UFW

La documentation de Docker est explicite : Docker et UFW utilisent les règles de pare-feu de façons incompatibles. Lorsqu'un port de conteneur est publié, le trafic est détourné dans la table NAT avant d'atteindre les chaînes d'entrée et de sortie qu'utilise UFW. Un port publié par Docker peut donc rester joignable alors qu'UFW affiche une politique de refus.

Les parades sont connues : publier les ports uniquement sur l'adresse locale (127.0.0.1:8080:80) derrière un proxy inverse, filtrer dans la chaîne prévue par Docker pour les règles utilisateur, ou placer l'hôte derrière un pare-feu réseau. Dans tous les cas, contrôlez l'exposition réelle par un balayage depuis l'extérieur plutôt qu'en lisant la sortie de ufw status.

firewalld sur RHEL, Fedora, AlmaLinux et Rocky Linux

firewalld est le démon de pare-feu de la famille Red Hat. Son projet le décrit comme un pare-feu géré dynamiquement, organisé en zones qui attribuent un niveau de confiance aux interfaces, aux connexions ou aux adresses sources. Il gère IPv4, IPv6 et les ponts Ethernet, et sépare la configuration d'exécution (runtime) de la configuration permanente. Depuis la version 0.6.0, son moteur par défaut est nftables.

Avec ce moteur, firewalld range ses règles dans sa propre table nftables, ce qui réduit les conflits avec les autres logiciels. Le choix du moteur se règle par l'option FirewallBackend du fichier /etc/firewalld/firewalld.conf. La zone par défaut s'appelle public : chaque interface qui n'est pas explicitement affectée à une autre zone en hérite.

Zones, services et règles riches

Plutôt que des ports, firewalld manipule des services nommés (ssh, https, dns) et des règles riches qui combinent source, service et action. L'erreur classique consiste à modifier la configuration d'exécution, à constater que tout fonctionne, puis à perdre les règles au redémarrage. Ajoutez l'option --permanent, rechargez, puis vérifiez la zone active.

sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.0/28" service name="ssh" accept'
sudo firewall-cmd --permanent --zone=public --remove-service=ssh
sudo firewall-cmd --permanent --zone=public --remove-service=cockpit
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-all       # controle final

L'ordre des commandes compte : la règle riche qui autorise SSH depuis le réseau d'administration est ajoutée avant le retrait du service SSH ouvert à tous. Pendant un rechargement, la politique par défaut de firewalld conserve les connexions établies, ce qui protège la session en cours. Retirez enfin les services préinstallés inutiles, comme l'interface web Cockpit lorsqu'elle n'est pas utilisée.

Migrer d'iptables vers nftables sans interruption

Beaucoup de serveurs conservent des scripts iptables écrits il y a des années. Sur une distribution récente, ils fonctionnent encore grâce à la couche iptables-nft, mais leur maintenance devient coûteuse : règles IPv4 et IPv6 séparées, listes d'adresses interminables, absence de chargement atomique. La migration vers nftables se prépare comme un projet, avec un inventaire, une traduction, une relecture et un test en laboratoire.

sudo iptables -V                               # moteur actif : nf_tables ou legacy
sudo iptables-save > /root/regles-v4.txt
sudo ip6tables-save > /root/regles-v6.txt
iptables-restore-translate -f /root/regles-v4.txt > /root/regles-v4.nft
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT   # traduire une seule regle

La traduction automatique n'est qu'un point de départ. Relisez le résultat pour fusionner les politiques IPv4 et IPv6 dans une table inet, remplacer les longues listes d'adresses par des ensembles et supprimer les règles devenues inutiles. Sur un hôte où Docker, libvirt ou un outil de blocage gèrent leurs propres règles, évitez flush ruleset, qui effacerait aussi leurs tables : ne videz que votre propre table.

Construire une politique de filtrage solide et lisible

L'ANSSI (Agence nationale de la sécurité des systèmes d'information) a publié une note technique sur la définition d'une politique de filtrage réseau d'un pare-feu. Le document est volontairement indépendant de la technologie employée, ce qui le rend directement applicable à un pare-feu Linux. Il défend un modèle simple : tout ce qui n'est pas explicitement autorisé est interdit, avec une politique organisée, documentée et maintenable dans le temps.

Traduits pour un serveur Linux, ces principes donnent quelques règles de conception que l'on retrouve dans tous les audits :

• Refus par défaut en entrée et en transit, avec une politique explicite plutôt qu'une règle finale implicite.
• Accès d'administration restreint : SSH, interfaces web et supervision ouverts uniquement aux adresses d'administration ou via un bastion.
• Parité IPv4 et IPv6 : une adresse IPv6 globale sans filtrage équivalent annule la politique IPv4.
• Filtrage en sortie sur les serveurs sensibles, pour limiter les connexions de commande et contrôle et l'exfiltration.
• ICMP raisonné : bloquer tout ICMP casse la découverte de MTU et, en IPv6, la découverte de voisins.
• Traçabilité : chaque règle ouverte porte un commentaire indiquant son objet, son demandeur et, si elle est temporaire, sa date d'expiration.

Durcir le pare-feu Linux et la pile réseau du noyau

Le filtrage n'est qu'une partie du durcissement réseau. Plusieurs paramètres du noyau, réglés par sysctl, réduisent la surface d'attaque : refus des redirections ICMP, filtrage du chemin inverse contre l'usurpation d'adresses, cookies SYN contre les inondations de demandes de connexion et journalisation des paquets aux adresses incohérentes. Ces réglages figurent dans les référentiels de durcissement comme le guide de l'ANSSI pour GNU/Linux et les benchmarks du CIS (Center for Internet Security).

# /etc/sysctl.d/60-reseau-durci.conf (serveur qui ne route pas)
net.ipv4.ip_forward = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.tcp_syncookies = 1
# Application : sudo sysctl --system

Ces valeurs conviennent à un serveur qui ne route pas. Un hôte Docker, un hyperviseur ou une passerelle a besoin du transfert IP : désactiver ip_forward y casserait le réseau des conteneurs ou des machines virtuelles. Pour aller plus loin, notre guide de durcissement Linux fondé sur le CIS Benchmark replace ces paramètres dans une démarche complète.

Le pare-feu lui-même peut devenir une cible

Le code de Netfilter s'exécute dans le noyau, avec les privilèges les plus élevés. Une faille dans nf_tables ne permet pas de franchir le pare-feu depuis Internet, mais elle peut offrir à un attaquant déjà présent sur la machine, avec un simple compte utilisateur, une élévation de privilèges jusqu'à root. C'est précisément le cas de CVE-2024-1086, une faille de type « utilisation après libération » (use-after-free).

Fin octobre 2025, plusieurs médias spécialisés ont en outre relayé l'indication de la CISA selon laquelle cette faille est utilisée dans des campagnes de rançongiciel. La réponse est défensive et simple : appliquer les mises à jour du noyau, redémarrer réellement les serveurs, et restreindre la création d'espaces de noms utilisateur non privilégiés lorsque les applications le permettent. Notre article sur l'escalade de privilèges sous Linux et les mesures de durcissement détaille ces protections.

Journaliser, superviser et réagir aux refus

Un pare-feu Linux qui refuse sans tracer ne sert qu'à moitié. Les journaux de refus permettent de repérer un balayage de ports, une application mal configurée ou un poste compromis qui tente de joindre un serveur interne. Avec nftables, l'instruction log accepte un préfixe qui facilite le filtrage ; avec UFW, les entrées portent le préfixe « UFW BLOCK » ; firewalld propose l'option --set-log-denied.

Trois réglages rendent ces journaux exploitables. D'abord, une limite de débit sur les règles de journalisation, pour qu'une attaque n'inonde pas le disque. Ensuite, un envoi centralisé vers un collecteur syslog ou un SIEM (système de gestion des informations et des événements de sécurité), hors de portée d'un attaquant qui prendrait la main sur le serveur. Enfin, des compteurs sur les règles critiques, consultables avec nft list ruleset.

La réaction peut être en partie automatisée. Des outils comme fail2ban ou CrowdSec analysent les journaux d'authentification et alimentent des ensembles nftables pour bloquer temporairement les adresses agressives. Notre guide pour protéger un serveur Linux avec CrowdSec montre comment brancher un bloqueur sur le pare-feu sans alourdir la politique de base.

Tester et auditer un firewall Linux sans risque

Une politique n'est fiable que si elle a été vérifiée depuis l'extérieur. La démarche commence par l'inventaire des services en écoute avec ss -tulpn, qui doit correspondre aux ports ouverts dans le pare-feu. Elle se poursuit par un balayage de ports depuis un segment de test, en IPv4 et en IPv6, puis par la comparaison du résultat avec la matrice de flux attendue.

Le schéma ci-dessous résume la démarche complète, de l'inventaire des flux à la revue périodique. Chaque étape produit une trace exploitable lors d'un audit : liste des services, fichier de règles versionné, journal des changements et rapport de test. Pour un contrôle plus large du serveur, notre méthode pour auditer et sécuriser un serveur Linux avec des outils open source complète ces vérifications.

Retour terrain : Cas typique rencontré en mission — sur un serveur exposé, UFW est actif et n'autorise que SSH et HTTPS, pourtant un balayage externe révèle la base de données d'un conteneur : Docker publie ses ports par des règles de NAT et de transfert que les règles d'entrée d'UFW ne voient pas. S'y ajoutent souvent un SSH ouvert à tout Internet et des règles firewalld appliquées sans --permanent, perdues au redémarrage. Correction retenue : ports publiés sur l'interface locale, filtrage dans la chaîne DOCKER-USER et SSH restreint au bastion d'administration.

Cas particuliers : conteneurs, hyperviseurs et services d'infrastructure

Les hôtes de conteneurs demandent une attention particulière. Docker crée ses propres règles pour les réseaux en pont, active le transfert IP et, d'après sa documentation, règle alors la politique de transit sur « drop » pour éviter que l'hôte ne serve de routeur. Avec firewalld, Docker ajoute une zone nommée docker dont la cible est ACCEPT. Ces comportements doivent être documentés dans la politique de filtrage.

Sur un hyperviseur, le filtrage se fait à plusieurs niveaux : l'hôte, les ponts virtuels et chaque machine invitée. Proxmox VE, par exemple, propose un pare-feu au niveau du centre de données, du nœud et de la machine virtuelle, qui s'articule avec ses réseaux définis par logiciel. Notre article sur le SDN de Proxmox VE 9, ses zones, VNets et pare-feux détaille cette organisation.

Les services d'infrastructure méritent des règles fines. Un annuaire LDAP (Lightweight Directory Access Protocol) ne doit répondre qu'aux serveurs et postes qui l'interrogent, de préférence sur le port chiffré 636 ; consultez notre guide pour installer et configurer OpenLDAP sur Debian. De même, un serveur web exposé n'a besoin que de HTTPS, avec un certificat géré proprement, par exemple via une PKI AD CS pour les serveurs Linux Apache ou Nginx.

Erreurs fréquentes et bonnes pratiques d'exploitation

Les mêmes erreurs reviennent d'un serveur à l'autre, quelle que soit la distribution. La plupart ne relèvent pas de la technique pure mais de l'exploitation : absence de procédure, outils mélangés, règles temporaires devenues permanentes. Les corriger demande surtout de la méthode.

1. Mélanger plusieurs outils : UFW, firewalld et un script nft actifs en même temps produisent des règles concurrentes. Un seul outil de gestion par serveur, les autres désactivés.
2. Oublier IPv6 : des règles iptables sans équivalent ip6tables laissent la machine joignable en IPv6. La famille inet de nftables règle le problème.
3. Ne pas persister les règles : règles nft tapées à la main, firewalld modifié sans --permanent, et tout disparaît au redémarrage.
4. Bloquer tout ICMP : cela casse la découverte de MTU et, en IPv6, la découverte de voisins.
5. Croire UFW sur parole avec Docker : seul un balayage externe montre l'exposition réelle.
6. Ouvrir sans expiration : une règle « pour un test » survit souvent des années sans commentaire ni propriétaire.

À l'inverse, une exploitation saine repose sur quelques habitudes : un fichier de règles versionné, une revue au moins annuelle, une comparaison automatique entre ports en écoute et ports autorisés, et des alertes sur les modifications du pare-feu. L'outil nft monitor affiche en temps réel les changements de règles, ce qui aide à détecter une modification inattendue.

Firewall Linux d'hôte ou pare-feu réseau dédié ?

Le pare-feu d'hôte et le pare-feu réseau ne répondent pas à la même question. Le premier protège une machine, même si un autre serveur du même segment est compromis, et suit la machine partout, y compris dans le cloud. Le second cloisonne des zones entières, centralise la politique et les journaux, et reste en place même si un administrateur désactive par erreur le filtrage d'un serveur.

La bonne architecture combine les deux. Un pare-feu réseau, qu'il s'agisse d'une appliance ou d'une solution open source comme OPNsense, sépare Internet, la DMZ (zone démilitarisée) et les réseaux internes. Le firewall Linux de chaque serveur applique ensuite le moindre privilège au plus près des services. Cette défense en profondeur limite les mouvements latéraux, qui passent souvent sous le radar d'un filtrage uniquement périmétrique.

À lire aussi : les types de pare-feu informatique ; les NGFW ; les pare-feu matériels comme le Cisco ASA.

Questions fréquentes

Conclusion

Un firewall Linux efficace dépend moins du nom de l'outil que de la rigueur de sa politique. Netfilter et nftables forment le socle commun de Debian, Ubuntu et de la famille Red Hat ; UFW et firewalld en simplifient l'usage. En 2026, les priorités restent : refus par défaut, un seul outil, parité IPv4 et IPv6, administration restreinte, journaux centralisés, noyau à jour et tests externes. Associez ce filtrage d'hôte à un pare-feu réseau, comme dans notre guide OPNsense.