iptables Firewall : guide du pare-feu serveur Linux

Si tu héberges un serveur de jeu, une application web ou un bot Discord, dès que la machine est exposée à internet elle commence à être scannée. Un iptables firewall te permet de décider précisément quel trafic entre et sort en pilotant la couche de filtrage de paquets (Netfilter) intégrée au noyau Linux : tu n'ouvres que les ports nécessaires et tu refuses silencieusement tout le reste. Dans ce guide, nous allons construire un jeu de règles sécurisé de zéro, écrire les règles de ports et filtrer les attaques les plus courantes, étape par étape.

Comment fonctionne iptables : chaînes et tables

iptables organise les règles en tables et chaînes (chains). Pour un pare-feu du quotidien, la table filter et trois chaînes suffisent :

• INPUT — paquets arrivant au serveur (c'est là que vit notre protection).
• OUTPUT — paquets quittant le serveur.
• FORWARD — paquets routés à travers le serveur vers une autre destination (scénarios routeur/Docker).

Chaque paquet parcourt la chaîne de haut en bas ; la cible (target) de la première règle qui correspond l'emporte : ACCEPT (autoriser), DROP (jeter en silence) ou REJECT (refuser et renvoyer une erreur). Si rien ne correspond, la politique par défaut de la chaîne s'applique. Le principe fondamental d'un pare-feu solide : mettre la politique sur DROP, puis n'ouvrir que ce que tu autorises explicitement.

Ne pas se bloquer soi-même : l'ordre compte

L'erreur la plus courante est de passer la politique en DROP avant d'ajouter la règle SSH, ce qui coupe ta session distante. Donc écris d'abord les règles d'autorisation, durcis la politique en dernier. Libère aussi le loopback et les connexions existantes dès le début :

# Laisser continuer les connexions déjà établies
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Ne jamais bloquer le trafic loopback (127.0.0.1)
iptables -A INPUT -i lo -j ACCEPT

# Jeter les paquets malformés / invalides
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

Cette première règle est cruciale : grâce au module conntrack, les paquets de réponse des connexions lancées par le serveur ou déjà établies passent automatiquement, ce qui évite d'écrire des règles séparées côté OUTPUT.

Règles de ports : n'ouvrir que le nécessaire

Ajoutons maintenant des règles de ports par service. Une configuration typique : SSH (22), HTTP (80), HTTPS (443) et un port de serveur de jeu. -p définit le protocole, --dport le port de destination :

# SSH (ajoute-le en premier, puis verrouille !)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Web
iptables -A INPUT -p tcp --dport 80  -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Exemple de serveur de jeu (ex. Metin2 TCP 13000)
iptables -A INPUT -p tcp --dport 13000 -j ACCEPT

Pour ouvrir plusieurs ports en une seule ligne, utilise le module multiport :

iptables -A INPUT -p tcp -m multiport --dport 80,443,13000 -j ACCEPT

Ouvrir un port uniquement à une IP précise (par exemple SSH seulement depuis ton IP fixe) est bien plus sûr :

iptables -A INPUT -p tcp -s 203.0.113.10 --dport 22 -j ACCEPT

Une fois toutes les règles d'autorisation écrites, durcis les politiques par défaut :

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

Filtrer les attaques de base

Un serveur exposé subit en permanence des scans de ports, du brute-force et des tentatives de paquets falsifiés. Quelques règles ciblées en éliminent ou ralentissent la plupart.

Ralentir le brute-force SSH : avec le module recent, bloque temporairement toute IP qui tente plus de 4 nouvelles connexions SSH en 60 secondes :

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --update --seconds 60 --hitcount 5 --name SSH -j DROP

Scans de ports / drapeaux invalides : les paquets TCP sans aucun drapeau (NULL) ou avec des combinaisons absurdes proviennent généralement d'un outil de scan :

# Paquets NULL
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
# Scan XMAS
iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
# Nouvelles connexions qui ne sont pas SYN
iptables -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP

Limiter le débit ICMP (ping) : plutôt que de désactiver totalement le ping, limiter les requêtes par seconde garde le diagnostic utilisable tout en stoppant les floods :

iptables -A INPUT -p icmp --icmp-type echo-request \
  -m limit --limit 1/second -j ACCEPT

N'oublie pas : iptables seul n'arrête pas un vrai DDoS (un lien saturé dépasse le noyau), mais il réduit fortement le scanning applicatif et le bruit.

Rendre les règles persistantes

Les règles iptables vivent en mémoire et sont perdues au redémarrage. Sur Debian/Ubuntu, le paquet iptables-persistent les sauvegarde et les restaure au démarrage :

sudo apt install iptables-persistent
sudo netfilter-persistent save        # /etc/iptables/rules.v4

Tu peux aussi sauvegarder et restaurer manuellement :

iptables-save  > /etc/iptables/rules.v4
iptables-restore < /etc/iptables/rules.v4

Pour voir les règles avec les numéros de ligne et les supprimer :

iptables -L INPUT -n -v --line-numbers
iptables -D INPUT 3        # supprimer la règle numéro 3

Une note sur nftables et UFW

Sur les distributions modernes, la commande iptables est généralement redirigée vers nftables en arrière-plan (iptables-nft). La syntaxe reste identique, donc tout ce guide fonctionne. Pour de nouveaux projets, apprendre nft directement a du sens, mais d'innombrables docs et scripts existants restent basés sur iptables. Si tu veux une interface plus simple, UFW (Uncomplicated Firewall) enveloppe iptables : des commandes en une ligne comme ufw allow 443/tcp font le même travail. Mais pour vraiment comprendre ce qui se passe, une connaissance de base d'iptables est inestimable.

Questions fréquentes

Faut-il utiliser DROP ou REJECT ?

DROP jette le paquet en silence ; l'émetteur ne peut pas savoir si le port est ouvert, fermé ou protégé par un pare-feu, ce qui ralentit les scanners. REJECT renvoie un message « connexion refusée », pour un retour plus rapide. Sur une chaîne INPUT exposée à internet, on préfère généralement DROP ; sur un réseau interne, REJECT est plus pratique pour des erreurs rapides.

Pourquoi l'ordre des règles compte-t-il autant ?

Parce qu'iptables s'arrête à la première règle correspondante. Si tu places un DROP large en haut, les règles ACCEPT en dessous ne s'exécutent jamais. Place toujours les autorisations étroites/spécifiques en premier et les refus généraux/la politique en dernier.

Faut-il des règles séparées pour IPv6 ?

Oui. iptables ne gère que l'IPv4 ; le trafic IPv6 se configure séparément avec ip6tables. Si ton serveur a de l'IPv6, le laisser sans filtre est une grosse faille, alors écris des règles ip6tables correspondantes avec la même logique.

Tu veux configurer ton serveur de façon sûre et robuste ? Si tu as besoin d'aide pour le pare-feu, le durcissement et le déploiement d'un serveur de jeu, d'un VPS ou d'une infrastructure web, contacte-moi.