Loading AI tools
logiciel informatique De Wikipédia, l'encyclopédie libre
Netfilter est un cadriciel (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.
| Développé par | L'équipe Netfilter |
|---|---|
| Écrit en | C |
| Système d'exploitation | GNU/Linux |
| Environnement | GNU/Linux |
| Type | Pare-feu |
| Licence | GNU GPL |
| Site web | http://netfilter.org/ |
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].
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.
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 :
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.
Le projet netfilter/iptables a été lancé en 1998 par Rusty Russell (en), 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 . En , Harald Welte a été fait président de la coreteam et, en , 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 , 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.
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
