Généralités | (Haut de page) |

Depuis la version 2.4, Linux contient un module destiné au filtrage réseau, Netfilter. Il se configure au moyen d'un outil appelé iptables.

Le filtrage réseau consiste en l'examen des paquets réseaux et à prendre des décisions sur le traitement à leur appliquer. C'est ce que fait un pare-feu ou, en anglais, firewall. Avec un système GNU/Linux, pour configurer des règles de pare-feu, il faudra donc simplement utiliser Netfilter à l'aide d'iptables.

Cet article s'interesse uniquement au filtrage réseau IPV4 (qui est probablement celui que vous utilisez si cela ne vous évoque rien). Cela est possible pour d'autres protocoles et les principes exposés ici resteront pour la plupart valides.

Présentation de Netfilter | (Haut de page) |

Netfilter travaille sur des paquets réseaux. Il s'agit de parties des informations transmises. Pour, par exemple, télécharger un fichier, celui-ci est découpé en plusieurs paquets avant de transiter sur le réseau. Chacun de ces paquets comporte en plus des données, des informations ajoutées par les couches réseaux. Ce sont sur ces informations que s'effectueront les tests de filtrage.

La couche réseau Linux présente plusieurs points d'accès (en anglais hook). Netfilter dispose de fonctions de rappel (callback). Celles-ci sont des suites d'instructions qui précisent ce qui doit être fait lorsque survient un événement.

Concrètement, lorsqu'un paquet réseau atteint un de ces points d'accès, il est passé à Netfilter par l'intermédiaire de sa fonction de rappel. Il est alors examiné pour prendre une décision concernant son traitement futur.

Netfilter se comporte comme un automate qui compare le paquet successivement à plusieurs règles. Et selon le résultat du test, le paquet est traité ou transmis au test suivant.

Les tables, chaînes et cibles | (Haut de page) |

Aux points d'accès sont associées des chaînes de traitement. C'est dans celles-ci que sont effectués les tests. Elles sont regroupées par tables selon le type de traitement.

Les tables sont ajoutées par des modules. Il en existe 3 principales pouvant être utilisées. Voici ci-après leurs noms et la tâche à laquelle elles sont destinées.

A l'intérieur d'une table, on peut trouver plusieurs chaînes. Ce sont elles qui contiendront les règles à appliquer aux paquets. Ces règles seront évaluées séquentiellement. On trouve deux types de chaînes.

Tout d'abord celles qui sont associées aux différents points d'entrées existants. Un paquet atteignant un de ces points sera envoyé vers la chaîne associée. Ce sont les fonctions de rappel evoquées précédemment qui réalisent cela. Elles effectuent les uns après les autres les tests que contient la chaîne. Ces chaînes sont en nombre fini et ne sont pertinentes que pour certaines tables. Le tableau suivant les liste, en indiquant quelle table a une chaîne de ce type.

On trouve aussi des chaînes utilisateurs. Elles peuvent librement être créées mais ne seront pas associées à un point d'accès. En fait on ne pourra rentrer dans une de ces chaînes que si une règle d'une des chaînes existantes dirige le paquet vers celle-ci.

Enfin, le dernier élément important est la notion de cible. Il s'agit du traitement que l'on décide d'appliquer au paquet. C'est la cible qui se chargera de faire les opérations nécessaires. En plus de celles prédéfinies, il est possible d'indiquer comme cible une chaîne utilisateur. Cela permet d'imbriquer différents tests et traitements.

Chaque chaîne peut être vue comme un ensemble de tests, chacun ayant pour résultat l'envoi du paquet vers la cible spécifiée si la condition est vérifiée. Si ce n'est pas le cas, on passe à la suivante. En arrivant à la fin d'une des chaînes du tableau précédent, une cible par défaut est utilisée. A la fin d'une chaîne utilisateur, si aucune décision n'a été prise, on revient à la chaîne appelante.

Voici les cibles prédéfinies les plus courantes :

Présentation d'iptables | (Haut de page) |

iptables est l'outil qui est fourni à l'administateur pour agir sur tous les concepts vus précédemment et pour modifier les règles de filtrage donc.

La première option à connaître est -t qui permet de spécifier le nom de la table sur laquelle porteront les autres paramètres. Si cette option n'est pas spécifiée, ce sera par défaut la table filter.

On peut aussi demander à iptables de charger un module particulier avec l'option -m. Ce module peut ajouter de nouvelles tables ou de nouvelles manières de tester les paquets.

Il faut ensuite indiquer une commande pour indiquer par exemple qu'une nouvelle règle doit être ajoutée dans la chaîne spécifiée. Ci-après la liste des options les plus courantes pour spécifier une commande. Une seule à la fois peut être présente, et toutes devront être suivies du nom de la chaîne à prendre en compte.

Quelques exemples montreront l'utilisation de ces options.

Les tests de concordance et options de cible | (Haut de page) |

Pour pouvoir créer des règles, il faut effectuer des tests de concordance. Ceux-ci définissent les caractéristiques que doivent présenter les paquets pour être concernés par la règle, et donc être dirigés vers la cible spécifiée.

Certains paramètres de tests ne sont valables que si d'autres options sont précisées. Le tableau suivant, qui présente les plus utilisés de ces tests, indiquera donc le contexte d'utilisation qui correspondra aux autres options nécessaires (avec leurs paramètres) s'il y en a.

Plusieurs de ces paramètres existent en version longue ou abrégée, celle longue étant précédée de -- (deux tirets). Lorsqu'une version courte existe, elle sera indiquée ci-dessous. L'utilisation de l'une ou de l'autre est strictement équivalent.

Une fois spécifiés les critères auxquels doivent répondre les paquets, il faut indiquer vers quelle cible l'envoyer s'il y répond. Cela se fait avec l'option --jump ou en abrégé -j suivie par le nom de la cible.

Certaines de ces cibles nécessitent des options pour les paramétrer. Elles sont indiquées sous la même forme que les options de tests. Ci-suivent les plus couramment utilisées.

Exemples courants | (Haut de page) |

Voici une suite de quelques exemples pouvant être utiles. Ils seront accompagnés d'une explication sur leurs rôles. Vous pouvez aussi vous référer au script de pare-feu que j'utilise.

Cet exemple permet de jeter tout ce qui vient de l'adresse 207.46.134.190. La spécification de la table filter est facultative car par défaut c'est celle qui est utilisée. On pourrait abréger cette commande en la suivante :

Qui produit exactement le même résultat. L'utilisation de -A ajoute cette règle à la fin de la chaîne. Donc si une précédente règle laissait passer des paquets, ils n'arriveront pas jusqu'à celle-ci.

Pour construire un ensemble de règles de filtrage, on commencera généralement par supprimer toutes celles créées précédemment.

Cette commande vide intégralement la table filter de toutes les règles qui auraient précédemment été définies.

Ensuite on indiquera plutôt en premier tout ce que l'on accepte, pour ensuite refuser tout le reste. On commencera donc par des règles ressemblant à la suivante :

Cette règle permet de laisser passer tout le trafic TCP entrant sur le port 80. Ce sera utile par exemple si un serveur web (par défaut sur le port 80) est présent sur la machine. Mais il faut ensuite que les réponses envoyées puissent l'être. Dans ce cas, la règle précédente autorise des personnes extérieures à demander une page. Pour que le serveur puisse la transmettre, il faudra une règle comme suit :

Pour laisser les utilisateurs internes accéder aux sites Internet, on peut définir cette règle :

Celle-ci permet donc de laisser passer les paquets à destination du port 80 d'une machine extérieure. Et pour que les utilisateurs puissent recevoir les pages envoyées par ces machines, il faudra ajouter :

Pour ne pas confondre ce que font les quatre règles précédentes, voici un résumé de ce qu'elles font :

• La première laisse entrer ce qui est pour le port 80 de la machine.
• La deuxième laisse sortir les paquets par le port 80 de la machine.
• La troisième laisse sortir ce qui est pour le port 80 d'une autre machine.
• La quatrième laisse entre ce qui vient du port 80 d'une autre machine.

Dans le cas où ce sont les seules choses permises sur cette machine, on terminera par indiquer que tout le reste doit être ignoré. Arriveront à ce point seulement les paquets qui n'auront pas répondu aux critères précédents. On peut donc alors les jeter (avec la cible DROP). Une règle toute simple pourrait être la suivante :

Ces deux règles indiquent de détruire tous les paquets entrants ou sortants. On peut souhaiter en plus garder une trace de tous ces paquets refusés. Nous allons créer une chaîne utilisateur pour cela :

Cette chaîne porte le nom "bloquer". On y ajoute ensuite une première règle pour l'enregistrement :

Tous les paquets passant par cette chaîne seront enregistré avec le message "Jeté: " devant.

On ajoute ensuite une règle semblable à celle vue plus haut :

Tout ce qui arrive à la fin est donc bloqué. On dirige alors tous les paquets entrants et sortants vers cette chaîne plutôt que vers la cible DROP :

Si aucune connexion de l'extérieur ne doit être possible, si par exemple aucun serveur n'est disponible sur la machine, on peut utiliser une règle se basant sur les états :

Cet exemple est indépendant des précédents. Mais on peut l'utiliser à la place de la règle finale qui rejetait tout pour autoriser les connexions de l'intérieur.

On indique ici que le module state doit être chargé. Puis sur les paquets entrants, on refuse tous ceux qui sont à l'état NEW (nouvelle connexion créée) ou INVALID (non liés à une connexion existante). Cela permet d'empêcher toute connexion depuis l'extérieur. Si des services sont proposés depuis la machine, on fera précéder cette règle par celles permettant d'accepter les paquets sur les ports souhaités.

Un dernier exemple avec les états, qui est un peu le pendant de la règle ci-dessus.

Tous les paquets entrants correspondant à une connexion déjà établie seront acceptés. En plaçant cette règle au début de la chaîne INPUT, cela évite de devoir explicitement laisser passer les paquets entrants vers les ports laissés ouverts pour un service interne (la deuxième règle de la liste de quatre vue précédemment).

Voici donc un petit exemple de script de pare-feu. Dans ce cas, on suppose que le seul serveur tournant sur la machine est un serveur web sur le port 80 et que l'on souhaite refuser toute autre connexion depuis l'extérieur. En revanche, toutes celles qui sont créées depuis l'intérieur doivent pouvoir passer.

En fait, on ne crée de règle explicites que pour la chaîne INPUT dans cet exemple. La chaîne OUTPUT ayant pour politique par défaut ACCEPT, tous les paquets sortants seront donc acceptés.

Ces exemples concernaient la table filter. La page décrivant comment partager une connexion en donne pour la table nat.