Netfilter

Les modules du noyau nommés ip_tables, ip6_tables, arp_tables (les soulignements font partie du nom) et ebtables sont les systèmes des accroches de Netfilter. Ils fournissent un système basé sur des tableaux pour définir des règles de pare-feu qui filtrent les paquets ou les transforment. Les tableaux peuvent être administrés par les outils utilisateur iptables, ip6tables, arptables et ebtables, respectivement.

Chaque tableau est en fait sa propre accroche, et chaque tableau a été créé pour servir un but précis. En ce qui concerne Netfilter, généralement l'exécution de ces tableaux dans un ordre précis par rapport aux autres tableaux. Toutefois, tous les tableaux vont exécuter la même fonction de traitement de tableau pour les parcourir et exécuter des règles.

Les chaînes, à cet égard, correspondent à l'endroit où la pile de Netfilter a été invoquée, comme la réception de paquets (PREROUTING), rendu sur place (INPUT), transmise (FORWARD), généré localement (OUTPUT) et envoyer/envoyant des paquets (POSTROUTING). Les modules de Netfilter qui ne prévoient pas de tableaux (voir ci-dessous) peuvent également vérifier l'origine des paquets pour choisir leur mode de fonctionnement.

• le module iptable_raw, lorsqu'il est chargé, peut enregistrer une accroche qui sera appelée avant toutes les autres accroches. Il fournit un tableau appelé raw que l'on peut utiliser pour filtrer des paquets avant qu'ils n'atteignent les opérations nécessitant plus de mémoire, comme Connection Tracking.
• le module iptable_mangle enregistre une accroche et le tableau mangle, qui est consulté après Connection Tracking (mais toujours avant les autres tableaux), pour apporter des modifications au paquet, qui peuvent influencer d'autres règles, telles que le NAT ou le filtrage.
• le module iptable_nat enregistre deux accroches : Les transformations de DNAT sont appliquées avant l'accroche de filtrage ; les transformations de SNAT sont appliquées ensuite. Le tableau nat qui est mis à la disposition de iptables est simplement une « base de données de configuration » pour les mappages NAT, et n'est destiné à aucun filtrage d'aucune sorte.
• enfin, le module iptable_filter enregistre le tableau filter utilisé pour le filtrage général (firewall).

Une des caractéristiques importantes construites sur le framework Netfilter est Connection Tracking. CT permet au noyau de garder la trace de toutes les connexions réseau logiques ou de sessions, et, par conséquent, porte tous les paquets qui composent cette connexion. NAT s'appuie sur cette information pour traduire tous les paquets de la même manière, et iptables peut utiliser cette information pour agir comme un pare-feu avec persistance.

L'état de connexion est cependant complètement indépendant de tout état haut niveau, tel que l'état TCP ou SCTP. Une partie de la raison en est que, lorsque les paquets ne font que transiter (pas de livraison locale), le moteur de TCP ne doit pas nécessairement être invoqué. Même les modes sans-connexion tels que les transmissions UDP, IPsec (AH/ESP), le GRE et autres protocoles de tunneling ont au moins un pseudo-état de connexion. L'heuristique de ces protocoles est souvent basée sur une valeur de délai de l'inactivité préréglée, après expiration de laquelle une connexion Netfilter est abandonnée.

Chaque connexion Netfilter est identifiée de façon unique par un tuple (protocole de couche 3, adresse source, adresse de destination, protocole de couche 4, clé de couche 4). La clé de couche 4 dépend du protocole de transport : pour les protocoles TCP/UDP c'est le numéro de port; pour des tunnels, c'est leur tunnel ID. Dans le cas contraire, la clé prend la valeur zéro comme si elle ne faisait pas partie du tuple. Pour être capable d'inspecter le port TCP, les paquets seront obligatoirement défragmentés.

Les connexions Netfilter peuvent être manipulées avec l'outil conntrack.

Iptables peut inspecter les informations de connexion tels que les états, les statuts etc. pour rendre les règles de filtrage de paquets plus puissantes et plus faciles à gérer. Le plus souvent, les états sont les suivants :

• “NEW” (nouveau) : le paquet essaie de créer une nouvelle connexion
• "ESTABLISHED" (établi) : le paquet fait partie d'une connexion déjà existante
• "RELATED" (liée) : cet état est attribué à un paquet qui est l'ouverture d'une nouvelle connexion, et qui a été « attendu ». Les mini-ALGs susmentionnés mettent ces attentes en place, par exemple, lorsque le module nf_conntrack_ftp voit une commande FTP "PASV".
• "INVALID" (invalide) : le paquet a été jugé invalide. La cause la plus fréquente est qu'il ne respecterait pas le diagramme d'état du protocole TCP.
• "UNTRACKED" (non-suivant) : état spécial qui peut être attribué par l'administrateur pour contourner Connection Tracking (voir tableau raw ci-dessus)

En pratique, le premier paquet que le sous-système conntrack perçoit est donc classé « nouveau ». Le paquet de réponse est classé « établi ». À l'inverse, une erreur ICMP est « liée », et un paquet d'erreur ICMP qui ne correspond à aucune connexion connue est catégorisé « invalide ».

Grâce à l'utilisation de modules greffons (plugins), CT peut prendre connaissance des protocoles de la couche application, et donc comprendre que deux connexions distinctes ou plus sont « liées ». Considérons, par exemple, le protocole FTP. Une connexion contrôle est établie, mais chaque fois que des données sont transférées, une connexion séparée est établie pour les transférer. Lorsque le module nf_conntrack_ftp est chargé, le premier paquet d'une connexion de données FTP sera classé comme « lié » à la place de « nouveau », comme il fait logiquement partie d'une connexion existante.

Les aides n'inspectent qu'un paquet à la fois. Si des informations vitales pour CT sont divisées en deux paquets — en raison de la fragmentation IP ou de la segmentation TCP — l'aide ne reconnaîtra pas nécessairement les modèles et ne saura donc pas s'acquitter de son fonctionnement. La fragmentation IPv4 est traitée avec le sous-système CT exigeant la défragmentation, même si la segmentation TCP n'est pas traitée. En cas de FTP, les paquets sont réputés ne pas être segmentés « près de » la commande PASV avec des tailles de secteur (MSS) et ne sont donc pas traités par Netfilter.

• ipchains, le prédécesseur de iptables
• nftables, successeur et remplaçant actuel de Netfilter
• BPfilter, autre remplaçant
• Netlink, une API utilisée par Netfilter extensions

Pages d'accueil :

• Netfilter/iptables project (en)
• conntrack-tools (en)
• ipset (en)
• ulogd (en)
• Workshop Netfilter (en)(fr)

Documentation :

• Writing Netfilter Modules (2009; 2.6 MB PDF) Écrire des modules de Netfilter (en)
• ANSSI — Guide de configuration Netfilter (PDF) (fr)
• Firewall et sécurité d'un réseau personnel sous Linux (fr)