Netfilter - Définition

Introduction

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 Sécurité des Systèmes d'Information (ANSSI) [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.

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.