Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 130netfilter:10-fonction [le 28/03/2025 à 16:44] – [La table «Filter»] prof
+++ 130netfilter:10-fonction [le 05/04/2025 à 16:40] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. prof
@@ Ligne 1: / Ligne 1: @@
-====== Le filtrage de paquets ======
+====== 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. // ([[https://fr.wikipedia.org/wiki/Netfilter|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.
-Pour cette étude, comme d'habitude, une maquette virtuelle fera l'affaire. Reprenons celle utilisée pour l'exposé sur DHCP:
-{{ :090_applicatifs:165dhcp:dhcp_network.svg |Maquette virtuelle}}
-La station qui fait office de routeur/DHCP/DNS va en plus devoir assurer la protection du LAN en vert, autant en IPv4 qu'en IPv6
 ===== Position du problème =====
 Cette station doit:
-  - assurer le routage IPv4 avec un masquage d'adresses, nous avions vu pourquoi dans le chapitre sur l'[[050_profondeurs:040-un-routeur|ajout d'un routeur en IPv4]],
+  - assurer le routage IPv4 avec un masquage d'adresses, nous avions vu pourquoi dans le chapitre sur l'[[050-manips-ipv4:040-un-routeur|ajout d'un routeur en IPv4]],
   - assurer la liaison avec la délégation du bloc IPv6 2a01:e0a:875:b1d2::/64, comme vu dans le chapitre sur [[070-experiencesipv6:030-prefixes_secondaires|Les préfixes secondaires en IPv6]],
   - assurer qu'il soit protégé des agressions de l'extérieur, LAN orange compris, sur ses services DHCP et DNS,
@@ Ligne 14: / Ligne 14: @@
 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'interface((Il faut bien comprendre cette subtilité: Le traitement se fait en entrée, en traversée ou en sortie, aussi bien dans un sens que dans l'autre.)) (enp1s0, enp7s0 et même l'interface «lo»**((ce qui peut arriver si deux process distincts mais locaux tous les deux doivent communiquer entre eux par un socket réseau)), ils vont le faire  par le même point et ceux qui doivent en sortir vont le faire par le même autre point.
 {{ :130netfilter:netfilter2.svg?400|Les poignées de Netfilter}}
-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'interface((Il faut bien comprendre cette subtilité: Le traitement se fait en entrée, en traversée ou en sortie, aussi bien dans un sens que dans l'autre.)) (enp1s0, enp7s0 et même l'interface «lo»**((ce qui peut arriver si deux process distincts mais locaux tous les deux doivent communiquer entre eux par un socket réseau)), 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 modules de traitement des paquets vont se greffer pour permettre le traitement plus ou moins complexe à réaliser. Ces points sont:
+ 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;
-  - NF_IP_LOCAL_IN;
-  - NF_IP_FORWARD;
+  - NF_IP_PRE_ROUTING  ->  **PREROUTING**
-  - NF_IP_LOCAL_OUT;
+  - NF_IP_LOCAL_IN  ->  **INPUT**
-  - NF_IP_POSTROUTING;
+  - NF_IP_FORWARD  ->  **FORWARD**
+  - NF_IP_LOCAL_OUT  ->  **OUTPUT**
+  - NF_IP_POSTROUTING  ->  **POSTROUTING**
 Lorsqu'un paquet entre:
   * soit il entre pour accéder à un process local, par exemple pour mettre à jour le cache DNS, ou pour interroger ce même cache, ou informer du voisinage réseau IPv6,
@@ Ligne 37: / Ligne 41: @@
 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:
-{{:130netfilter:netfiltertables.svg?150 |Les tables et les chaînes}}
+{{:130netfilter:netfiltertables.svg?500 |Les tables et les chaînes}}
   - Le filtrage des paquets,
   - la translation d'adresse,
   - le marquage des paquets.
-=== La table «Filter» ===
+==== 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;
@@ Ligne 48: / Ligne 52: @@
   - **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.