|
|
1. Firewall sous noyau linux 2.0
1.1. Introduction.
1.2. Filtrage sous noyau Linux 2.0.
2. Firewall sous noyau linux 2.4, utilisation de NETFILTER
2.1. Mécanismes de filtrage du noyau.
2.2. Translations d'adresses et masquerading.
2.3. Trajet des paquets.
2.4. Configuration du noyau et installation des outils.
3. Utilisation d'iptables.
3.1. Manipulation des chaines.
3.2. Manipulation des règles.
4. Exemple de règles.
4.1. Exemple de règles de filtrage.
4.2. Exemple de partage de connexion à Internet.
5. Configuration des clients.
6. Annexes.
6.1. Autres possibilitées de filtrage via Netfilter.
6.2. Rèférences.
1. Firewall sous noyau Linux 2.0
1.1. Introduction
Un firewall est un élément filtrant en 2 réseaux. Il permet de limiter les accès entrants et sortants.
LINUX permet de construire de manière assez simple un firewall, soit en utilisant les fonctionnalités
de filtrage de paquets IP du noyau 2.0 et +, soit en utilisant un package de proxy server comme
TIS (http://www.tis.com )
ou bien
SOCKS ( ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz ).
Voici une liste de documents traitant du sujet firewall sous LINUX:
Le Firewall-HOWTO
Building a LINUX firewall sur http://www.ssc.com
Linux firewall facilities for kernel-level packet screening sur http://simba.xos.nl/linux/ipfwadm/paper
Nous traiterons en exemple le système de filtrage de paquets du noyau LINUX.
1.2. Filtrage par le noyau LINUX-2.0
Ce noyau contient des fontionnalités de filtrage de paquets IP. Pour pouvoir utiliser ces fontions,
vous devez configurer le noyau de la manière suivante:
1. General setup
a. Turn Networking Support ON
2. Under Networking Options
a. Turn Network firewalls ON
b. Turn TCP/IP Networking ON
c. Turn IP forwarding/gatewaying ON
d. Turn IP Firewalling ON
e. Turn IP firewall packet loggin ON (this is not required but it is a good idea)
f. Turn IP: masquerading OFF (I am not covering this subject here.)
g. Turn IP: accounting ON
h. Turn IP: tunneling OFF
i. Turn IP: aliasing OFF (ou ON si une seule carte réseau)
j. Turn IP: PC/TCP compatibility mode OFF
k. Turn IP: Reverse ARP OFF
l. Turn Drop source routed frames ON
3. Under Network device support
a. Turn Network device support ON
b. Turn Dummy net driver support ON
c. Turn Ethernet (10 or 100Mbit) ON
d. Select your network card
La machine utilisée comme firewall doit avoir 2 adresses IP:
une du coté réseau privé
une du coté réseau public (Internet)
Les adresses 192.168.2.x sont prévues pour être utilisées comme adresses de réseau privé, elles ne seront
jamais routées sur Internet.
Le firewall peut avoir soit 2 cartes ethernet (recommandé), soit utiliser l’IP aliasing avec
une seule carte.
La détection d’une deuxième carte est fait en ajoutant l’option suivante lors du boot par LILO:
append= »ether=0,0,eth1 »
Si il est nécessaire de fournir d’autres paramètres sur la carte, on pourra utiliser une syntaxe comme:
append= »ether=12,0x300,eth0 ether=15,0x340,eth1 »
D’autres configurations possibles dans le document Ethernet-HOWTO
L’IP aliasing est natif dans le noyau 2.0. On pourra ajouter une nouvelle adresse IP en utilisant
la syntaxe:
ifconfig eth0:0 192.168.1.1
route add -host 192.168.1.1 dev eth0:0
D’autres configurations possibles dans le document NET-2-HOWTO
Le noyau est capable de filtrer les paquets au niveau:
entrées (input, -I)
sorties (output, -O)
passage (forward, -F)
Le plus simple est d’utiliser la commande ipfwadm-2.3.0 disponible sur:
http://simba.xos.nl/linux/ipfwadm
On peut rendre le FW complètement étanche par:
ipfwadm -F -p deny
# Flush all commands
ipfwadm -F -f
ipfwadm -I -f
ipfwadm -O -f
Si l’on veut autoriser les connexions sortantes sur le port TCP 23, on utilise la syntaxe suivante:
ipfwadm -O -a accept -b -P tcp -S 0.0.0.0/0 23
et en entrant:
ipfwadm -I -a accept -b -P tcp -S 0.0.0.0/0 23
On peut lister les règles par:
ipfwadm -I -l
Autres exemples de configurations:
# Forward email to your server
ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 199.1.2.10 25
# Forward email connections to outside email servers
ipfwadm -F -a accept -b -P tcp -S 199.1.2.10 25 -D 0.0.0.0/0 1024:65535
# Forward Web connections to your Web Server
/sbin/ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 196.1.2.11 80
# Forward Web connections to outside Web Server
/sbin/ipfwadm -F -a accept -b -P tcp -S 199.1.2.* 80 -D 0.0.0.0/0 1024:65535
# Forward DNS traffic
/sbin/ipfwadm -F -a accept -b -P udp -S 0.0.0.0/0 53 -D 199.1.2.0/24
2. Firewalls et partages de connexion à Internet; Utilisation de NetFilter
Supposons qu’une machine située sur un réseau local a accès à Internet. Il peut être intéressant
de faire en sorte que les autres machines du réseau puissent également y accéder, en utilisant cette
machine comme passerelle. Ceci est parfaitement réalisable et ne pose aucun autre problème que la
définition des règles de routage si toutes les machines ont une adresse IP attribuée par l’IANA.
Cependant, ceci est rarement le cas, car les réseaux locaux utilisent normalement les adresses réservées
à cet usage, qui ne sont pas routables sur Internet. Dans ce cas, il est évident que les machines du réseau
local ne pourront pas envoyer de paquets sur Internet, et qu’a fortiori elles ne recevront jamais de
paquets provenant d’Internet. Heureusement, il existe une technique nommée masquerading, basée
sur un mécanisme de translations d’adresses (« NAT » en anglais, abréviation de « Network Address
Translation »), qui permet de modifier les paquets émis à destination d’Internet à la volée, afin de
pouvoir partager une connexion Internet même avec des ordinateurs qui utilisent des adresses locales.
Comme nous allons le voir, partager une connexion à Internet avec d’autre ordinateurs d’un réseau local
est un jeu d’enfant sous Linux grâce à cette technique. Il faut toutefois bien se rendre compte que le fait
que fournir un accès à Internet à un réseau local pose des problèmes de sécurité majeurs. Pour des
réseaux locaux familiaux, les risques de piratages sont bien entendu mineurs, mais lorsque la connexion
à Internet est permanente ou lorsque les données circulant sur le réseau local sont sensibles, il faut tenir
compte des risques d’intrusion. Lorsque l’on utilise des adresses IP dynamiques, il est relativement difficile
d’accéder à des machines du réseau local, sauf si la passerelle expose des services internes au reste du réseau.
En revanche, si les adresses utilisées sont fixes et valides sur Internet, le risque devient très important.
La configuration de la passerelle doit donc se faire avec soin dans tous les cas, et l’installation d’un Firewall
est plus que recommandée (un « firewall », ou « pare-feu » en français, est un dispositif qui consiste à protéger
un réseau local du « feu de l’enfer » d’Internet, sur lequel tous les crackers sont supposés grouiller).
Les paragraphes suivants exposent les mécanismes de filtrage de paquets réseau de Linux, qui sont utilisées
tant pour définir les règles de protection contre les intrusions indésirables sur un réseau par l’intermédiaire d’une
passerelle que pour effectuer des traitements sur les paquets. Cependant, de tous ces traitements, nous ne
verrons que la translation d’adresses, car c’est sans doute celui que la plupart des gens cherchent à utiliser.
2.1. Mécanismes de filtrage du noyau
Linux est capable de filtrer les paquets circulant sur le réseau et d’effectuer des translations d’adresses depuis
la version 2.0, cependant, les techniques utilisées ont été profondément remaniées à chaque version. À partir
de la version 2.4.0, une architecture extensible a été mise en place et semble répondre à tous les besoins de
manière simple : Netfilter.
Netfilter est simplement une série d’entrée dans les couches réseau du noyau au niveau desquels des modules
peuvent s’enregistrer afin d’effectuer des contrôles ou des traitements particuliers sur les paquets. Il existe
un entrée en chaque point clé du trajet suivi par les paquets dans les couches réseau du noyau, ce qui permet
d’intervenir de manière souple et à n’importe quel niveau. Un certain nombre de modules permettant d’effectuer
les traitements les plus courants sont fournis directement dans le noyau, mais l’architecture Netfilter est
suffisamment souple pour permettre le développement et l’ajout des modules complémentaires qui pourraient
être développés par la suite.
Les fonctionnalités fournies par ces modules sont regroupées par domaine fonctionnel. Ainsi, les modules
permettant de réaliser des Firewall se chargent spécifiquement de donner les moyens de filtrer les paquets
selon des critères bien définis, et les modules permettant d’effectuer des translations d’adresses ne prennent
en charge que la modification des adresses sources et destination des paquets à la volée. Afin de bien les
identifier, ces fonctionnalités sont regroupées dans ce que l’on appelle des tables . Une table n’est en fait rien
d’autre qu’un ensemble cohérent de règles permettant de manipuler les paquets circulant dans les couches
réseau du noyau. Les tables les plus couramment utilisées sont les tables « filter » et « nat », qui permettent
respectivement de réaliser des Firewall et d’effectuer des translations d’adresses.
Chaque table utilise ses propres points d’entrées de Netfilter. Pour chacun de ces points d’entrée, des listes
de règles de gestion des paquets peuvent être définies. Ces listes sont communément appelées des chaînes .
Il y a donc toujours une chaîne de règles prédéfinie pour chaque point d’entrée. L’utilisateur peut bien entendu
définir de nouvelles chaînes et les utiliser dans les chaînes prédéfinies.
Les règles permettent de spécifier les paquets qui les vérifient, selon des critères précis, comme par exemple
leur adresse source ou le type de protocole qu’ils transportent. Les règles indiquent également les traitements
qui seront appliqués à ces paquets. Par exemple, il est possible de détruire purement et simplement tous les
paquets provenant d’une machine considérée comme non sûre si l’on veut faire un Firewall. On pourra aussi
envoyer ces paquets dans une autre chaîne, qui peuvent indiquer d’autres règles et d’autres traitements.
Les critères de sélection des paquets des règles de filtrage se basent sur les informations de l’en-tête de ces
paquets. Rappelez-vous que chaque paquet de données émis sur le réseau transporte avec lui des informations
nécessaires au fonctionnement dudit réseau, entre autres les adresses source et destination du paquet. Ce sont
sur ces informations que la sélection des paquets est effectuée dans Netfilter. Dans le cas d’un protocole
encapsulé dans un autre protocole, comme par exemple un paquet TCP dans un paquet IP, les informations
du protocole encapsulé peuvent également être utilisées, si l’on a chargé des modules complémentaires dans
NetFilter. Par exemple, le numéro de port TCP peut faire partie des critères de sélection d’une règle.
Les traitements que l’on peut appliquer à un paquet sont également fournis par des modules de Netfilter. Les
traitements les plus simples sont bien entendus fournis en standard avec le noyau. En général, on peut
chercher à réaliser les opérations suivantes sur un paquet :
l’enregistrer, pour analyse ultérieure ;
le rediriger vers un port local, pour traitement par un programme dédié (par exemple, par un serveur proxy) ;
l’accepter, l’abandonner ou le rejeter directement (le rejet se distingue de l’abandon par l’émission d’une
notification « hôte inaccessible » à la machine ayant émis le paquet) ;
le modifier, et en particulier, le marquer pour le reconnaître dans un traitement ultérieur ou effectuer une
translation d’adresses ;
l’envoyer dans une autre chaîne pour effectuer des vérifications complémentaires ;
le faire sortir immédiatement de la chaîne courante.
De plus, les statistiques tenues par le noyau pour la règle ainsi vérifiée sont mises à jour. Ces statistiques
comprennent le nombre de paquets qui ont vérifié cette règle ainsi que le nombre des octets que ces paquets
contenaient.
Lorsqu’un paquet arrive à la fin d’une chaîne (soit parce qu’il n’a pas été rejeté ou détruit par une rèfle de
Firewalling, soit parce qu’il ne correspond aux critères d’aucune règle, ou soit parce qu’il est arrivé à ce stade
après avoir subi des modifications), le noyau revient dans la chaîne appelante et poursuit le traitement du paquet.
Si la chaîne au bout de laquelle le paquet arrive est une chaîne prédéfinie, il n’y a plus de chaîne appelante, et le
sort du paquet est déterminé par ce qu’on appelle la politique. La politique (« policy » en anglais) des chaînes
prédéfinies indique donc ce que l’on doit faire avec les paquets qui arrivent en fin de chaîne. En général, on
utilise une politique relativement stricte lorsqu’on réalise un Firewall, qui rejette tous les paquets par défaut et
qui n’ont pas été accepté explicitement par une règle de la chaîne.
Note: Certains paquets peuvent être découpés en plusieurs paquets plus petits lors de la traversée d’un réseau.
Par exemple, un paquet TCP un peu trop gros et initialement encapsulé dans un seul paquet IP peut se voir
répartir sur plusieurs paquets IP. Ceci peut poser quelques problèmes aux règles de filtrage, puisque dans ce
cas les données spécifiques à TCP (par exemple les numéros de ports) ne sont disponibles que sur le premier
paquet IP reçu, pas sur les suivants. C’est pour cette raison que le noyau peut effectuer une « défragmentation »
des paquets lorsque cela est nécessaire, et que les paquets transmis par la passerelle ne sont pas toujours
strictement identitiques aux paquets qu’elle reçoit.
2.2. Translations d’adresses et masquerading
Nous avons vu que grâce aux mécanismes de filtrage du noyau, il est possible de modifier les paquets à la volée.
Il peut être intéressant de modifier un paquet pour diverses raisons, les trois plus intéressantes étant sans doute
de le marquer à l’aide d’un champ spécial dans son en-tête afin de le reconnaître ultérieurement, de modifier
sa priorité pour permettre un traitement privilégié ou au contraire en arrière plan de ce type de paquet (libérant
ainsi les ressources réseau pour d’autres connexions), et de modifier ses adresses sources et destination, pour
effectuer une translation d’adresse. Nous allons nous intéresser plus particulièrement aux différentes formes
de translation d’adresses dans la suite de cette section.
Une translation d’adresse n’est en fait rien d’autre qu’un remplacement contrôlé des adresses sources ou des
adresses destination de tous les paquets d’une connexion. En général, ceci permet de détourner les connexions
réseau ou de simuler une provenance unique de plusieurs connexions. Par exemple, les connexions à Internet
peuvent être détournées vers un proxy fonctionnant sur la passerelle de manière transparente, en modifiant les
adresses destination des paquets émis par les clients. De même, il est possible de simuler un seul serveur en
remplaçant à la volée les adresses source des paquets que la passerelle envoie sur Internet.
On distingue donc deux principaux types de translation d’adresses : les translations d’adresses sources et les
translation d’adresse destination. Parmi les translations d’adresses source se trouve un cas particulier particulièrement
intéressant : le « masquerading ». Cette technique permet de remplacer toutes les adresses sources des paquets
provenant des machines d’un réseau local par l’adresse de l’interface de la passerelle connectée à Internet, tout
en conservant une trace des connexions réseau afin d’acheminer vers leur véritable destinataire les paquets de
réponse. Ainsi, une seule connexion à Internet peut être utilisée par plusieurs machines distinctes, même si elles
ne disposent pas d’adresses IP fournies par l’IANA.
Lorsqu’une machine du réseau local envoie un paquet à destination d’Internet, ce paquet est donc acheminé vers
la passerelle, qui est la route par défaut. Celle-ci commence par modifier leur adresse source et mettre sa propre
adresse à la place, puis les transfert vers la machine du fournisseur d’accès. Tous les paquets émis par les machines
du réseau local semblent donc provenir de cette passerelle, et seront acheminés normalement à destination. En fait,la
complication provient des paquets réponse, puisque les machines situées sur Internet croient que la machine avec
laquelle elles communiquent est la passerelle. Les paquets réponse sont donc tous envoyés à la passerelle directement,
et celle-ci doit retrouver la machine du réseau local à laquelle ce paquet est destiné. Cette opération est réalisée de
différentes manières selon les protocoles utilisés, et elle suppose que la passerelle conserve en permanence une trace
des connexions réseaux effectuées par les machines du réseau local.
Pour TCP, ce suivi de connexion est réalisé en modifiant également le port source des paquets provenant des machines
locales. La passerelle utilise un port unique pour chaque connexion, qui va lui permettre de retrouver la machine à laquelle
un paquet est destiné lorsqu’elle en reçoit un provenant d’Internet. Par exemple, si une machine locale fait une
connexion à Internet, la passerelle alloue un nouveau numéro de port pour cette connexion et modifie tous les paquets
sortants comme ayant été émis par la passerelle elle-même, sur ce port. Lorsque l’autre machine prenant part à la connexion,
située sur Internet, envoie un paquet réponse, celui-ci sera à destination de la passerelle, avec comme port destination le
port de la connexion. La passerelle peut donc retrouver, à partir de ce port, l’adresse de la machine destination réelle, ainsi
que le port source que cette machine utilisait initialement. La passerelle modifie donc ces deux champs du paquet, et le
renvoie sur le réseau local. Finalement, la machine destination reçoit le paquet sur son port, et ce paquet semble provenir
directement d’Internet, comme si la connexion avait été directe. Notez bien que la passerelle ne modifie pas les adresses
sources des paquets provenant d’Internet, elle ne fait que les réacheminer vers la bonne destination.
Ainsi, le masquerading est un mécanisme complètement transparent pour les machines du réseau local. En revanche, pour
les machines de l’Internet, il ne semble y avoir qu’un seul interlocuteur : la passerelle. Celle-ci utilise des numéros de
ports variés, mais ceci ne les regarde pas. Les machines du réseau local sont donc complètement « masquées » par la
passerelle, d’où le nom de masquerading.
Tout ce travail effectué par la passerelle nécessite un traitement spécifique sur chaque paquet qu’elle achemine, et
consomme bien entendu des ressources système. Cependant, les débits utilisés pour les connexions à Internet, même
les plus rapides, sont très loin de mettre à genoux une passerelle sous Linux, même sur les plus petites machines
(386 et 486). Vous voilà rassuré, et peut-être aurez-vous trouvé d’ici peu une utilité à l’un de ces dinosaures qui
traînent encore dans votre garage?
2.3. Trajet des paquets
Il existe cinq points d’entrée au total pour les modules de Netfilter dans le code des couches réseau IP de Linux. À
ces cinq points d’entrée correspondent cinq chaînes prédéfinies, qui peuvent être accédées par l’intermédiaire des
diverses tables de Netfilter. Les paragraphes suivants décrivent ces cinq chaînes, ainsi que l’ordre dans lequel les
paquets les traversent.
Les paquets réseau provenant de l’extérieur sont d’abord contrôlés par le noyau afin de détecter les erreurs les
plus simples. Les paquets mal formés ou corrompus sont systématiquement éliminés à ce niveau, avant même
d’atteindre le code de Netfilter. Les autres paquets commencent alors leur trajet dans les couches de plus haut niveau.
C’est à ce moment là qu’ils rencontrent la chaîne PREROUTING, qui est la première chaîne prise en compte. Cette
chaîne précède le code de routage, qui est en charge de déterminer le trajet que le paquet devra suivre par la suite à
partir de l’adresse destination des paquets. C’est donc dans cette chaîne que l’on pourra modifier l’adresse destination
des paquets, si l’on veut faire une translation d’adresse destination. Cette chaîne est donc utilisable dans la table nat.
Les paquets qui traversent la chaîne PREROUTING sont ensuite orientés par le code de routage de Linux. S’ils sont
à destination de la machine locale, ils rencontrent une autre chaîne prédéfinie : la chaîne INPUT. C’est à ce niveau
que l’on peut empêcher un paquet d’entrer dans le système, aussi cette chaîne est-elle naturellement disponible dans
la table filter.
Les autres paquets doivent être transférés vers une autre machine, souvent par une autre interface réseau. Ils traversent
alors la chaîne FORWARD. Cette chaîne permet de contrôler les paquets qui transitent au travers d’une passerelle, et
fait donc partie de la table filter.
Les paquets qui sont acceptés par la chaîne FORWARD retournent ensuite dans le code de routage du noyau, afin de
déterminer l’interface réseau par laquelle ils doivent être réémis. Une fois ceci réalisé, ils sont prêts à être réémis, mais
ils doivent auparavant traverser la chaîne POSTROUTING. C’est dans cette dernière chaîne que se font les translations
d’adresse source, aussi est-elle accessible dans la table nat.
Enfin, les paquets émis par la machine locale à destination de l’extérieur doivent impérativement traverser la chaîne
OUTPUT, dans laquelle on pourra filtrer les informations sortantes. Cette chaîne est donc accessible dans la table filter.
Les paquets qui se révèlent avoir le droit de sortir traversent alors de code de routing, puis, tout comme les paquets qui
ont été transférés, entrent dans la chaîne POSTROUTING. La chaîne OUTPUT est également accessible au travers de
la table nat, afin de permettre la modification des adresses destination des paquets avant leur routage.
Note: Pour des raisons de clarté, les chaînes prédéfinies et les points d’entrée de Netfilter ont été volontairement
confondus dans ce paragraphe. En fait, il faut bien comprendre que les chaînes appartiennent aux tables, et qu’il
peut exister plusieurs chaînes du même nom dans plusieurs tables différentes. L’ajout d’une règle dans une chaîne
ne se fait donc que pour une table donnée, les autres tables ne contiendront donc pas cette règle. En revanche, les
paquets qui traversent ces chaînes le font bien lorsqu’ils sont au niveau du point d’entrée correspondant dans le code
des couches réseau de Linux.
2.4. Configuration du noyau et installation des outils
Les fonctionnalités de Netfilter sont toutes fournies par le noyau lui-même, aussi leur configuration doit-elle se faire
au niveau du noyau. La manière de procéder pour configurer le noyau sera indiquée ultérieurement dans le paragraphe
traitant de la compilation du noyau. Sachez cependant que les options à activer pour mettre en place les fonctionnalités
de filtrage des paquets et de translation d’adresses sont les suivantes :
« Network packet filtering (replace ipchains) », pour activer les fonctionnalités de filtrage des paquets en général ;
« Network packet filtering debugging », pour obtenir les message de débogage du noyau. Ces messages peuvent
être très utiles pour mettre au point les règles de filtrage
« Connection tracking (required for masq/NAT) » (menu « IP: Netfilter Configuration »), pour permettre le
suivi des connexions auxquelles appartiennent les paquets IP reçus par la passerelle. Cette option est nécessaire
pour réaliser un partage de connexion à Internet ;
« FTP protocol support », pour permettre la gestion des connexions FTP, qui exigent un traitement particulier pour
les translations d’adresses ;
« IP tables support (required for filtering/masq/NAT) », pour permettre la gestion des tables de Netfiler ;
« Packet filtering », pour inclure le support de la table « filter ». Cette option est nécessaire pour réaliser un Firewall ;
« REJECT target support », pour permettre le rejet des paquets (par défaut, seul l’abandon des paquets est fourni
dans le code de filtrage) ;
« Full NAT », pour inclure la table « nat » de Netfilter. Cette option est nécessaire pour réaliser un partage de
connexion à Internet ;
« MASQUERADE target support », pour permettre le masquerading afin de réaliser un partage de connexion à Internet.
Vous devrez ensuite compiler le noyau et les modules, et les installer comme indiqué dans la partie traitant de
la compilation du noyau.
Note: Le noyau de Linux dispose d’un paramètre global permettant de contrôler le routage des paquets IP d’une
interface réseau à une autre. Par défaut, ce paramètre est à 0, ce qui implique que la transmission des paquets ne
sera pas autorisée. Il faut donc activer ce paramètre à chaque démarrage afin de pouvoir utiliser votre passerelle Linux
Ceci peut être réalisé en écrivant la valeur 1 dans le fichier /proc/sys/net/ipv4/ip_forward du système
de fichiers virtuel /proc/ :
echo « 1 » > /proc/sys/net/ipv4/ip_forward
La manipulation des chaînes et la manipulation des règles de Netfilter se fait grâce à l’outil iptables . Cette commande doit
normalement avoir été installée par votre distribution, toutefois si ce n’est pas le cas, vous pouvez la compiler manuellement.
Pour cela, il vous faudra récupérer l’archive des sources d’iptables. Cette archive peut être trouvée sur Internet. La
version courante est la 1.1.2, aussi l’archive se nomme-t-elle iptables-1.1.2.tar.bz2.
L’installation d’iptables ne pose pas de problème particuliers en soi. Vous devrez d’abord décompacter l’archive avec
les deux commande suivantes :
bunzip2 iptables-1.1.2.tar.bz2 tar xf iptables-1.1.2.tar
puis modifier le fichier Makefile pour définir les répertoires d’installation dans les variables LIBDIR, BINDIR et MANDIR.
En général, les répertoires utilisés seront respectivement les répertoires /usr/lib/, /usr/bin/ et /usr/man/. Une fois
ceci fait, il ne restera plus qu’à compiler le tout avec la commande make et à faire l’installation avec la commande
make install.
3. Utilisation d’iptables
Il est possible, grâce à iptables, d’effectuer toutes les opérations d’administration désirées sur les tables de Netfilter.
Vous pourrez donc créer des nouvelles chaînes, les détruire, définir leur politique par défaut, ainsi que manipuler les
règles de ces chaînes (en ajouter, en supprimer ou en remplacer une). En fait, iptables dispose d’un grand nombre d’options,
et seules les options les plus importantes seront présentées ici. Vous pouvez lire la page de manuel iptables si vous désirez
plus de renseignements sur la manipulation des chaînes et des règles de filtrage du noyau.
3.1. Manipulation des chaînes
Toutes les options peuvent être utilisées avec toutes les les tables gérées par le noyau. La table sur laquelle une
commande s’applique peut être précisée à l’aide de l’option -t. Si cette option n’est pas fournie, la table utilisée par
défaut sera la table filter, qui est celle qui est normalement utilisée pour définir des règles de filtrages des paquets
dans un Firewall.
La création d’une nouvelle chaîne se fait simplement avec l’option -N :
<
iptables [-t table] -N chaîne
où chaîne est le nom de la chaîne à créer. Il est interdit d’utiliser un des mots-clés réservé par iptables . En pratique,
il est recommandé d’utiliser des noms de chaînes en minuscules, car les chaînes prédéfinies sont en majuscules.
Une chaîne peut être détruite avec l’option -X :
iptables [-t table] -X chaîne
Une chaîne ne peut être détruite que lorsqu’elle ne contient plus de règles. De plus, il est impossible de détruire les
chaînes prédéfinies d’une table.
Vous pouvez lister l’ensemble des règles d’une chaîne avec l’option -L :
iptables [-t table] -L chaîne
Enfin, il est possible de supprimer toutes les règles d’une chaîne avec l’option -F :
iptables [-t table] -F chaîne
où chaîne est le nom de la chaîne dont on veut lister les règles.
3.2. Manipulation des règles
La syntaxe générale pour ajouter une règle dans une chaîne est la suivante :
iptables [-t table] -A chaîne [-s source] [-d destination] [-p protocole] [-i itfsource] [-o itfdest] [-j cible]
où :
table est la table dans laquelle se trouve la chaîne manipulée (par défaut, il s’agit de la table filter) ;
chaîne est le nom de la chaîne à laquelle la règle doit être ajoutée ;
source est l’adresse source du paquet ;
destination est l’adresse destination du paquet ;
protocole est le protocole du paquet (spécifié avec son numéro de port ou par le nom du protocole tel qu’il est déclaré
dans le fichier /etc/services) ;
itfsource est le nom de l’interface réseau source par laquelle le paquet doit arriver ;
itfdest est le nom de l’interface destination par laquelle le paquet doit sortir ;
et cible est la cible des paquets qui vérifient les critères de sélection de la règle.
Chacun des paramètres placé entre crochets dans la syntaxe est facultatif, mais il faut au moins qu’un critère de sélection
soit donné (sur les adresses sources ou destination, ou sur le port ou l’interface).
Les adresses sources et destination peuvent être indiquées directement par le nom des machines (comme par exemple
« www.monrezo.com ») ou par leurs adresses IP. Vous pouvez spécifier directement toutes les adresses d’un réseau avec
la syntaxe « réseau/masque ». Il est également possible d’utiliser la syntaxe « réseau/n », où « n » est le nombre de bits
mis à 1 dans le masque de sous réseau. Ainsi, réseau/24 est équivalent à réseau/255.255.255.0, réseau/16 à réseau/255.255.0.0
etc? Par extension, « réseau/0 » peut être utilisé pour spécifier toutes les adresses possibles (dans ce cas, l’adresse
donnée pour le réseau n’est pas prise en compte).
La cible détermine les opérations qui seront appliquées à ces paquets. Les cibles autorisées dépendent de la chaîne
dans laquelle la règle est ajoutée, ainsi que des modules de Netfilter qui ont été compilés. Les principales cibles
sont les suivantes :
ACCEPT, pour accepter le paquet qui vérifie le critère de sélection de la règle ;
DROP, pour éliminer purement et simplement le paquet ;
REJECT, pour rejeter le paquet (en signalant l’erreur à la machine émettrice). Cette cible n’est utilisable que
dans les chaînes INPUT, FORWARD et OUTPUT, ainsi que dans les chaînes utilisateurs appelées à partir de ces chaînes ;
QUEUE, pour envoyer le paquets à un programme utilisateur capable de communiquer avec NetFilter ;
RETURN, pour sortir de la chaîne immédiatement, ou appliquer la règle de la politique par défaut pour les chaînes prédéfinies ;
REDIRECT, pour rediriger le paquet sur une autre machine, souvent la machine locale. Cette cible n’est utilisable
qu’avec la table nat, car il s’agit d’une translation d’adresse. On ne peut l’utiliser que dans les chaînes PREROUTING
et OUTPUT et les chaînes utilisateur appelées à partir de ces chaînes ;
SNAT, pour permettre la modification des adresses sources des paquets. Cette cible n’est bien entendu accessible
qu’au niveau de la table nat. Comme la modification de l’adresses source n’a de signification que pour les paquets devant
sortir de la passerelle, cette cible ne peut être utilisée que dans la chaîne POSTROUTING et les chaînes utilisateur
appelées à partir de cette chaîne ;
DNAT, pour effectuer la modification des adresses destination des paquets, afin par exemple de les détourner vers
une autre machine que celle vers laquelle ils devaient aller. Cette cible n’est accessible que dans la table nat, et n’est
utilisable que dans les chaînes PREROUTING et OUTPUT ainsi que dans les chaînes utilisateur appelées à partir
de ces chaînes ;
MASQUERADE, pour effectuer une translation d’adresse sur ce paquet, dans le but de réaliser un partage de
connexion à Internet. Cette cible n’est accessible que dans la chaîne POSTROUTING de la table nat, ainsi que
dans les chaînes utilisateur appelées à partir de cette chaîne. ;
Toute autre spécification de destination doit être le nom d’une chaîne utilisateur, avec les règles de laquelle le
paquet devra être testé. Si aucune cible n’est spécifiée, aucune action n’est prise et la règle suivante est traitée.
Cependant, les statistiques de la règle sont toujours mises à jour.
La suppression d’une règle d’une chaîne se fait avec la commande suivante :
iptables -D chaîne numéro
où chaîne est la chaîne dont on veut supprimer la règle, et numéro est le numéro de la règle à supprimer dans cette
chaîne. Il est également possible d’utiliser l’option -D avec les mêmes options que celles qui ont été utilisées lors de
l’ajout de la règle, si l’on trouve cela plus pratique.
Enfin, la politique d’une chaîne, c’est à dire la cible par défaut, peut être fixée avec l’option -P :
iptables -P chaîne cible
où chaîne est l’une des chaînes prédéfinie, et cible est l’une des cibles ACCEPT ou DROP . Remarquez que l’on
ne peut pas définir de politique pour les chaînes créées par l’utilisateur, puisque les paquets reprennent les vérifications
de la chaîne appelante lorsqu’ils sortent de la chaîne appelée.
4. Exemple de règles
Ce paragraphe a pour but de présenter quelques unes des règles les plus classiques. Le but est ici de présenter les
principales fonctionnalités d’iptables et non de réaliser un Firewall fiable. Reportez-vous à des documents plus
spécialisés pour cela.
4.1. Exemple de règles de filtrage
Les règles de filtrage peuvent être utilisées pour mettre en place un Firewall afin de protéger votre réseau.
La définition des règles de filtrage constitue bien souvent l’essentiel du problème, et nécessite bien entendu de
parfaitement savoir ce que l’on veut faire. De manière générale, la règle d’or en matière de sécurité informatique
est de tout interdire par défaut, puis de donner les droits au compte goutte. C’est exactement ce que permet de faire
la police des chaînes. On définira donc toujours la police par défaut des chaînes pour utiliser la cible DROP. Ceci
peut être réalisé simplement avec les trois commandes suivantes :
iptables -P INPUT -j DROP iptables -P FORWARD -j DROP iptables -P OUTPUT -j DROP
Ces règles commencent par blinder la passerelle pour ne rien laisser entrer, ne rien laisser passer et ne rien laisser sortir.
Dans ce cas, on ne craint plus rien, mais on ne peut plus rien faire non plus (pas même en local). Aussi faut-il redonner
les droits nécessaires pour permettre l’utilisation normale de votre système. Par exemple, on peut autoriser l’arrivée et
l’émission de tous les paquets du réseau local avec les règles suivantes :
iptables -A INPUT -s 192.168.0.0/24 -i eth0 -j ACCEPT iptables -A OUTPUT -s 127.0.0.0/8 -o eth0 -j ACCEPT
et autoriser la communication des paquets de la machine locale vers la machine locale (ces paquets sont vitaux !) :
iptables -A OUTPUT -s 127.0.0.0/8 -o lo -j ACCEPT iptables -A INPUT -d 127.0.0.0/8 -i lo -j ACCEPT
Comme vous pouvez le constater, ces règles ne permettent l’entrée des paquets prétendant provenir du réseau local (c’est
à dire les paquets ayant comme adresse source une adresse de la forme 192.168.0.0/24) que par l’interface réseau connectée
au réseau local (dans notre exemple, il s’agit de l’interface réseau eth0). De même, seule la machine locale peut émettre des
paquets sur le réseau local. Il va de soi que ces paramètres sont trop restrictifs pour réaliser une passerelle. Dans ce cas, on
devra relâcher un peu plus de contraintes, et en utilisant des règles de filtrages plus fine. On devra autoriser le routage des
paquets (chaîne FORWARD), par exemple en n’autorisant que les paquets provenant d’un ensemble de machines considérées
comme fiables. Notez que ces règles sont beaucoup trop restrictives pour permettre un accès à Internet (et, a fortiori une
intrusion provenant d’Internet?).
Les règles présentées ici se basent uniquement sur les adresses sources et destination des paquets, ainsi que sur les
interfaces réseau par lesquelles ils entrent et ressortent. Sachez cependant que l’on peut réaliser des règles beaucoup plus
fines, qui se basent également sur les protocoles réseau utilisés, et, pour chaque protocole, sur des critères spécifiques à
ces protocoles. Vous pouvez consulter la page de manuel d’iptables pour plus de détails à ce sujet.
4.2. Exemple de partage de connexion à Internet
Le masquerading est un cas particulier de translation d’adresse source. En effet, celle-ci est couplée d’un suivi des
connexions, afin d’effectuer la translation d’adresses destination des paquets réponse renvoyés par les serveurs sur
Internet pour les acheminer vers la machine du réseau local qui a initié la connexion.
En pratique, seule la chaîne POSTROUTING sera utilisée pour le masquerading, parce que c’est à ce niveau que la
translation d’adresses est effectuée. La mise en ½uvre du masquerading se fait extrêmement simplement, puisqu’il
suffit de spécifier que toutes les paquets du réseau local sortants de l’interface réseau connectée sur Internet doivent
subir le masquerading. En général, l’interface de la connexion à Internet est une interface PPP, aussi la commande à utiliser
est-elle simplement la suivante :
iptables -t nat -A POSTROUTING -s réseau/24 -o ppp0 -j MASQUERADE
où réseau est l’adresse de votre réseau (par exemple, 192.168.0.0). Notez que la commande donnée ci-dessus suppose
que votre réseau soit de classe C, car le masque de sous réseau utilisé est 255.255.255.0. La cible spécifiée pour tous
les paquets provenant de votre réseau local sortant par l’interface ppp0 est donc MASQUERADE , ce qui active la
translation d’adresses. Remarques que les paquets provenant de la machine locale ne subissent pas le masquerading,
car c’est complètement inutile.
Note: Les chaînes et leurs règles ne sont pas enregistrées de manière permanente dans le système. Elles sont perdues
à chaque redémarrage de la machine, aussi faut-il les redéfinir systématiquement. Ceci peut être réalisé dans les scripts
de démarrage de votre système.
N’oubliez pas que votre passerelle doit définir une route par défaut pour que tous les paquets qui ne sont pas destinés
au réseau local soient envoyés par l’interface réseau connectée à Internet. Cette route par défaut est établie automatiquement
lorsque vous vous connectez à Internet à l’aide de PPP. Dans les autres cas, vous aurez à la définir manuellement.
Le routage des paquets est, par défaut, désactivé sous Linux. Si votre distribution ne le fait pas, vous aurez également
à ajouter une ligne telle que celle-ci :
# Activation du routage : echo « 1 » > /proc/sys/net/ipv4/ip_forward
dans vos scripts de démarrage de votre système.
Assurez-vous que les règles de filtrage que vous utilisez permettent bien aux machines du réseau local d’accéder à Internet,
et réciproquement, que les machines d’Internet peuvent leur répondre. Sans cela, toute tentative de masquerading sera
vouée à l’échec, avant même d’atteindre la chaîne POSTROUTING.
5. Configuration des clients
La configuration des autres machines du réseau est très simple. Vous devrez tout d’abord définir la machine possédant la
connexion à Internet comme passerelle par défaut de tous vos postes clients. Cette opération peut se réaliser de
différentes manière selon le système d’exploitation utilisé par ces machines. Sous Linux, il suffit d’utiliser la commande suivante :
route add default gw passerelle eth0
où passerelle est l’adresse de votre passerelle vers Internet sur le réseau local. Cette commande suppose que l’adaptateur
réseau utilisé est eth0
La deuxième étape est ensuite de donner accès aux postes clients au DNS de votre fournisseur d’accès. Ceci permettra
en effet d’utiliser les noms de machines autres que ceux de votre réseau local. Encore une fois, la manière de procéder
dépend du système utilisé. Sous Linux, il suffit d’ajouter les adresses IP des serveurs de noms de domaines de votre
fournisseur d’accès dans le fichier de configuration /etc/resolv.conf.
6. ANNEXES
6.1. Autres possibilités
mac : vérifie l'adresse mac source
limit : limite le rythme maximal de correspondance d'une règle (défaut 3/h)
limite le nombre de paquets journalisés par seconde :
iptables -A FORWARD -m limit --limit 3/s -j LOG
limite le nombre de paquets SYN par seconde :
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
limite l'efficacité des scanners de ports
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
limite le nombre de requêtes icmp de type echo-request par seconde
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -j DROP
owner : correspond à un paquet généré localement par :
un utilisateur (uid) : --uid-owner userid
iptables -A OUTPUT -m state --state NEW -p tcp --syn --dport 80 -m owner ! --uid-owner 0 -j ACCEPT
iptables -A OUTPUT -p tcp --syn --dport 80 -j DROP
un groupe (gid) : --uid-owner groupid
un processus (pid) : --pid-owner processid
une session (sid) : --sid-owner processid
Attention :
owner ne peut être appliqué qu'à la chaine OUTPUT
certains paquets n'ont pas de propriétaire : les réponses icmp...
Cette option est unique : aucun autre filtre IP ne la possède sous Unix.
6.2. Références
site principal netfilter / iptables :
http://netfilter.samba.org/
|