← Tous les projets

• Linux
• iptables
• nftables
• ipset
• Fail2ban
• Coraza

iptables est l’interface historique de configuration du pare-feu du noyau Linux : elle permet de définir des règles de filtrage, de NAT et de journalisation du trafic réseau, organisées en tables et chaînes (INPUT, OUTPUT, FORWARD…). C’est l’outil de base pour sécuriser un serveur exposé, limiter les ports ouverts, ou router du trafic entre interfaces.

Historique

iptables apparaît avec le noyau Linux 2.4 en 1999, en remplacement d’ipchains, en s’appuyant sur le framework de filtrage réseau Netfilter introduit dans le noyau. Il devient pendant plus de quinze ans la méthode standard de pare-feu sous Linux, avant que le projet Netfilter ne développe nftables (disponible depuis le noyau 3.13, 2014) comme successeur, avec une syntaxe unifiée IPv4/IPv6 et de meilleures performances.

Avantages des versions récentes

• nftables : remplace progressivement iptables, règles plus lisibles, gestion native IPv4/IPv6 dans un seul jeu de règles, meilleures performances sur de gros ensembles de règles.
• Compatibilité iptables-nft : permet de continuer à utiliser la syntaxe iptables historique tout en s’appuyant sur le moteur nftables en arrière-plan, pour une migration progressive.
• Ensembles (sets) et maps : structures de données efficaces pour gérer de grandes listes d’IP ou de ports sans dégrader les performances, bien supportées par nftables.

Bannissement par pays avec ipset

Pour bloquer des pays entiers sans alourdir le pare-feu, j’utilise des listes ipset. Un ipset est une structure du noyau qui stocke des milliers de plages d’adresses IP dans une table de hachage : une seule règle iptables interroge la liste, avec un temps de recherche quasi constant, là où des milliers de règles individuelles ralentiraient chaque paquet.

• Une liste par pays à bannir, remplie avec les plages d’adresses IP attribuées à ce pays.
• Une règle iptables en tête de la chaîne INPUT qui rejette (DROP) tout paquet dont l’adresse source figure dans la liste.
• Les listes se mettent à jour à chaud, sans recharger les règles ni couper les connexions existantes.

Le trafic indésirable est ainsi écarté dès le noyau, avant même d’atteindre le reverse proxy ou l’application.

Bannissement des scans OWASP avec Fail2ban et Coraza

Le filtrage par pays ne suffit pas : un scanner de vulnérabilités peut venir de n’importe où. Une seconde couche réagit au comportement :

1. Coraza, le WAF (moteur compatible ModSecurity et OWASP Core Rule Set), analyse chaque requête et détecte les signatures d’attaque : injections SQL, XSS, traversée de répertoires, sondes de scanners.
2. Chaque requête bloquée est écrite dans le journal Coraza.
3. Fail2ban surveille ce journal avec un filtre dédié : une IP qui déclenche plusieurs règles OWASP en peu de temps est identifiée comme un scan.
4. La « jail » bannit l’adresse pendant 1 heure en ajoutant une règle de rejet dans iptables. Le ban expire seul, ce qui limite l’impact d’un faux positif.

Mon expertise

Je protège mes serveurs en deux couches complémentaires :

• bannissement par pays avec des listes ipset, interrogées par une seule règle iptables en tête de la chaîne INPUT ;
• bannissement des scans OWASP : le WAF Coraza refuse les requêtes d’attaque, et Fail2ban bannit pendant 1 heure, dans iptables, les adresses qui les déclenchent.