Le cœur du système
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. (cf. Wikipédia).
Il y a de nombreuses raisons de faire un tel filtrage, tant en IPv4 qu'en IPv6, la plus souvent pour protéger les systèmes des agressions extérieures (pare-feu), mais pas seulement.
Position du problème
Cette station doit:
-
-
assurer qu'il soit protégé des agressions de l'extérieur,
LAN orange compris, sur ses services DHCP et
DNS,
être tout de même capable d'assurer les dialogues
DNS pour la maintenance de son cache,
assurer au moins un minimum de sécurité pour les clients IPv6 du
LAN vert
Normalement, Netfilter doit permettre de répondre à toutes ces exigences.
Netfilter dans la pile IP
En tout état de cause, dans l'explication qui suit, quelles que soient l'origine des paquets qui entrent dans la pile de protocoles IP quelle que soit l'interface1) (enp1s0, enp7s0 et même l'interface «lo»2), ils vont le faire par le même point et ceux qui doivent en sortir vont le faire par le même autre point.
Netfilter se présente comme une série de 5 “hooks” (points d'accrochage), sur lesquels des chaînes de traitement des paquets vont se greffer pour permettre le traitement plus ou moins complexe à réaliser. Ces points sont:
NF_IP_PRE_ROUTING → PREROUTING
NF_IP_LOCAL_IN → INPUT
NF_IP_FORWARD → FORWARD
NF_IP_LOCAL_OUT → OUTPUT
NF_IP_POSTROUTING → POSTROUTING
Lorsqu'un paquet entre:
En se souvenant toujours que que les décisions à prendre suivront le même ordre, que ce soit enp1s0 en entrée et enp7s0 en sortie ou l'inverse.
Les poignées de Netfilter peuvent se présenter également ainsi:
Bien entendu, tout ceci est schématisé à l'extrême, dans le but de mettre en évidence les points où Netfilter est en mesure d'agir sur les paquets.
Les compétences de Netfilter
A travers ces cinq points d'insertion, Netfilter va être capable :
D'effectuer des filtrages de paquets, principalement pour assurer des fonctions de Firewall. On pourra par exemple interdire à tous les paquets s'adressant au port 23 (Telnet) de passer, mais pas ceux venant de la station d'administration du
LAN vert, Telnet n'étant manipulable que par l'administrateur,
D'effectuer des opérations de NAT (Network Address Translation) Ces fonctions sont particulièrement utiles lorsque l'on veut faire communiquer tout ou partie d'un réseau privé, monté avec des adresses IP privées (192.168.x.x par exemple) avec l'Internet, comme nous l'avons déjà un peu mis en œuvre.
D'effectuer des opérations de marquage des paquets, pour leur appliquer un traitement spécial. Ces fonctionnalités sont particulièrement intéressantes sur une passerelle de réseau d'entreprise, un peu moins pour notre cas de réseau domestique.
Pour réaliser ces opérations, Netfilter est en mesure d'écrire des chaînes de règles dans des tables. Il y a dans Netfilter trois tables qui correspondent aux trois principales fonctions:
Le filtrage des paquets,
la translation d'adresse,
le marquage des paquets.
La table «Filter»
Cette table va contenir des règles de filtrage qui permettront d'agir sur l'avenir des paquets (les cibles) à savoir:
ACCEPT: Le paquet est en règle et va pouvoir poursuivre son chemin;
DROP: Le paquet n'a pas satisfait à l'examen. Il est jeté sans autre forme de procès;
REJECT Ne s'adresse qu'aux paquets contenant du transport TCP. Le paquet est rejeté avec une notification à son émetteur s'il n'a pas passé l'examen.
La table «Filter» peut agir sur les poignées (Hooks):
la chaîne INPUT.
Cette chaîne décidera du sort des paquets entrant localement sur l'hôte ;
la chaîne OUTPUT.
Ici, ce ne sont que les paquets émis par l'hôte local qui seront filtrés ;
la chaîne FORWARD.
Enfin, les paquets qui traversent l'hôte, suivant les routes implantées, seront filtrés ici.
La table «Nat»
Cette table manipule les adresses de l'émetteur ou du destinataire en fonction des critères indiqués dans les règles que l'on y inscrira. Les cibles possibles sont pour cette table:
DNAT permet de changer l'adresse de destination spécifique au PREROUTING
SNAT permet de changer l'adresse de la source spécifique au POSTROUTING
MASQUERADE, nous l'avons évoqué, permet de remplacer l'adresse source par l'adresse de sortie de l'hôte qui effectue le filtrage. Ce n'est utilisable que dans le routage et spécifique au POSTROUTING
REDIRECT permet de changer le port de destination, spécifique au PREROUTING
La table «Mangle»
Initialement utilisable seulement sur les poignées PREROUTING et OUTPUT, son champ d'action a été par la suite étendu aux autres poignées. Les règles inscrites dans cette table sont destinées à faire du marquage de paquets. C'est une fonctionnalité plutôt spécifique à des cas complexes que nous ne développerons pas davantage ici.
Synthèse
Tout ceci peut paraître indigeste à première vue et ça l'est même à seconde vue d'ailleurs. Sans trop chercher à entrer dans des cas d'usage, faisons le point.
Lorsqu'un paquet entre par une quelconque interface (enp1s0
ou enp7s0
dans notre exemple), avec la poignée 1 (Prerouting), il est possible de faire passer le paquet par une série de filtres qui décideront de ce qu'il faut faire avec. Le plus souvent, placer une marque, changer une adresse, un port…
suivant la décision de routage qui suit (le paquet concerne-t-il après Prerouting) un porcess local ou non ?), le paquet sera:
dirigé directement vers la sortie et dans ce cas, il devra subir le jugement des filtres placés par la poignée 3 (Forwarding) qui à leur tour pourront bricoler le paquet ou même le rejeter,
dirigé vers un process local, mais avant de l'atteindre, il devra subir les directives accrochées à la poignée 2 (Input). Quel qu'en soit la raison, si le process local génère une sortie, celle-ci va se taper l'inspection des règles accrochées à la poignée 4 (Output) avant d'y appliquer les décisions de routages (le paquet sortant est-il destiné au réseau local ou à un autre réseau ?)
Dans un cas comme dans l'autre, le paquet va encore être inspecté par les filtres accrochés à la poignée 5 (Postrouting) où il pourra encore être bricolé avant d'enfin sortir vers sa destination finale qui, suivant le cas sera aiguillé vers enp1s0
ou enp7s0
dans notre exemple.