Netfilter

Netfilter
Développeur	L'équipe Netfilter
Environnement	GNU/Linux
Type	Pare-feu
Licence	GNU GPL
Site web	http://netfilter.org/
modifier

Relation entre certains modules de Netfilter

Netfilter est un framework implémentant un pare-feu au sein du noyau Linux à partir de la version 2.4 de ce dernier. Il prévoit des accroches (hooks) dans le noyau pour l'interception et la manipulation des paquets réseau lors des appels des routines de réception ou d'émission des paquets des interfaces réseau.

La version 1.4.2 a reçu un Certificat de Sécurité de Premier Niveau (CSPN) par l'Agence nationale de la sécurité des systèmes d'information ^[1].

Histoire

Le projet netfilter/iptables a été lancé en 1998 par Rusty Russell, qui était aussi l'auteur du programme précédent, ipchains. Bien que le projet ait grandi, il a fondé le Netfilter Core Team (ou simplement coreteam, équipe de développement principale) en 1999. Le logiciel qu'ils produisent (appelé netfilter à partir de maintenant) est sous la licence GNU General Public License (GPL), et a été intégré dans Linux 2.3 en mars 2000. En août 2003, Harald Welte a été fait président de la coreteam et, en avril 2004, suivant des recherches intensives du projet Netfilter dans des produits commerciaux qui ont distribué le logiciel sans respecter les termes de la licence, Harald Welte a réussi à obtenir une injonction historique contre Sitecom Allemagne qui a refusé de suivre les termes de la licence GPL. En septembre 2007, Patrick McHardy, qui a dirigé le développement de ces dernières années, a été élu nouveau président de la coreteam.

Avant iptables, les principaux logiciels de création de pare-feu sur Linux étaient ipchains (noyau linux 2.2) et ipfwadm (noyau linux 2.0), basé sur ipfw, un programme initialement conçu sous BSDs. ipchains et ipfwadm a modifié le code réseau directement, afin de leur permettre de manipuler les paquets, comme il n'y avait pas de paquet-cadre de contrôle général jusqu'au Netfilter.

Considérant que ipchains et ipfwadm combinaient le filtrage de paquets et NAT (en particulier les trois types de NAT, appelés le masquage, la transmission de port et la redirection), Netfilter sépare les opérations de paquets en plusieurs parties, décrites ci-dessous. Chacune se connecte à différents points d'accès dans les accroches Netfilter pour inspecter les paquets. Les sous-systèmes de connexion suivr (Connection Tracking) et de NAT sont plus généraux et plus puissants que les versions inférieures dans ipchains et ipfwadm.

iptables

Article détaillé : iptables.

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 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).

Connection Tracking

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 "stateful".

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".

Connection Tracking aides

Grâce à l'utilisation de modules de plugin, 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 reconnaitra 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.

Notes et références

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Netfilter » (voir la liste des auteurs)

1. ↑ http://www.ssi.gouv.fr/site_rubrique54_certificat_cspn_2009_04.html

Voir aussi

Articles connexes

• ipchains, le prédécesseur de iptables
• Netlink, une API utilisée par Netfilter extensions

Liens externes

Pages d'accueil :

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

Le workshop :

• http://workshop.netfilter.org/ (en)(fr)
• Workshop résumé/blog (en)(fr)

Documentation :

• “Writing Netfilter Modules” e-book (2009; 2.6 MB PDF) — “écrire des modules de Netfilter” (en)
• Netfilter and Iptables — Stateful Firewalling for Linux (11 octobre 2001) (en)
• ANSSI — Guide de configuration Netfilter (fr)
• IPset par l'exemple (fr)