Netfilter

Un article de Wikipédia, l'encyclopédie libre.
L’orthographe ou la grammaire de cet article est à vérifier.
Vous pouvez corriger ou créer la discussion.
Image:netfilter-logo.png

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

Netfilter est un cadre qui prévoit des accroches (hooks) dans le noyau Linux pour l'interception et la manipulation des paquets réseau. Décrite moins abstraite, Netfilter est invoquée, par exemple, par les routines de réception ou d'envoi des paquets de/aux interfaces réseau. En tant que fonction principale de Netfilter, elle est appelée avec un paquet. Netfilter parcourt la liste des accroches enregistrées progressivement, lesquels ensuite devront gérer les paquets qu'ils désireront.

Sommaire

[modifier] 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 a grandi, il a fondé le Netfilter Core Team (ou simplement coreteam, équipe de développement principale) en 1999. Les logiciels qu'ils produisent (appelé netfilter à partir de maintenant) sont licence sous la 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ée à suivre les termes. En septembre 2007, Patrick McHardy, qui a dirigé le développement de ces dernières années, a été élu le nouveau président de la coreteam.

Avant d'iptables, les principaux logiciels de création de pare-feu sur Linux ont été ipchains dans Linux 2.2, et ipfwadm dans Linux 2.0, qui est basée sur ipfw de 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érale jusqu'au Netfilter.

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

[modifier] iptables

Article détaillé : iptables.

Les modules du noyau nommé ip_tables, ip6_tables, arp_tables (souligne une partie du nom) et ebtables sont les système 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 tout 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ée suivant de Connection Tracking (mais toujours avant des 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 que l'accroche de filtrage; transformations de SNAT sont appliqués 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 non pas l'intention pour le filtrage d'aucune sorte.
  • enfin, le module iptable_filter enregistre le tableau filter utilisé pour les filtrage générale (firewall).

[modifier] Connection Tracking

Une des caractéristiques importantes construite sur le toit de la Netfilter cadre est Connection Tracking. CT permet au noyau de garder la trace de toutes les connexions réseau logique ou de sessions, et, par conséquent, portent tous les paquets qui composent cet égard. NAT repose 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 l'état haut niveau, tels que l'état TCP ou SCTP. Une partie de la raison en est simplement que, lorsque la transmission de paquets, c'est-à-dire pas de livraison locale, le moteur de TCP ne doit pas nécessairement être invoquée à tous. Même en mode sans-connexion tels que les transmissions UDP, IPsec (AH/ESP), le GRE et autres protocoles de tunneling avoir un, au moins pseudo, état de connexion. L'heuristique de ces protocoles est souvent basé sur une valeur de délai de préréglage de l'inactivité, dont l'expiration après une connexion de Netfilter est abandonnée.

Chaque connexion de Netfilter est identifié par un tuple de (layer-3 protocole, l'adresse source, l'adresse de destination, layer-4 protocole, layer-4 clé). Le clé de layer-4 dépend de la protocole de transport; pour les protocoles TCP/UDP, c'est le numéro de port, pour des tunnels, c'est leur tunnel ID, mais est tout de zéro, comme le clé ne faisait pas partie du tuple. Pour être capable d'inspecter le port TCP dans tous les cas, les paquets seront obligatoirement défragmenté.

Connexions de Netfilter peuvent être manipulées avec le user-space outil conntrack.

iptables peut inspecter les informations de connexion tels que les états, les statuts et plus à faire des règles de filtrage de paquet plus puissant et plus facile à gérer. Le plus souvent, les états sont les suivants:

  • “NEW” (nouveau): le paquet est 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 mis ces attentes en place, par exemple, lorsque le module nf_conntrack_ftp voit un FTP "PASV" command.
  • "INVALID" (invalide): le paquet a été jugée invalide, par exemple, il ne serait pas respecter le diagramme d'état du protocole TCP.
  • "UNTRACKED" (pas-suivante) est un état qui peut être attribué par l'administrateur de contourner Connection Tracking pour un paquet particulier (voir tableau raw ci-dessus)

Un exemple normal serait que le premier paquet que le sous-système CT voit seront classé “nouveaux”, donc la réponse serait classé “établi” et une erreur ICMP serait "liée". Un paquet d'erreur ICMP qui ne correspond à aucun lien connu serait "invalide".

[modifier] Connection Tracking aides

Grâce à l'utilisation de modules de plugin, CT peut être donné connaissance des protocoles de la couche application, et donc comprendre que deux ou plus connexions distinctes sont "liées". Considérons, par exemple, le protocole FTP. Une connexion contrôle est établie, mais chaque fois que fichiers et les 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 seront classés comme "lié" à la place de "nouveaux", comme il est logiquement le cadre d'une connexion existante.

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

[modifier] Voir aussi

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

[modifier] Liens externes

Pages d'acceuil:

Le workshop:

Documentation:

[modifier] Notes

Ce document provient de « http://fr.wikipedia.org/wiki/Netfilter ».
Créer un livre