Les firewalls sous Linux : iptables

Les firewalls sous Linux : iptables A. Alexandre, B. Schueremans, O. Staquet 13 avril 2005 1 Présentation 1.1 Qu est-ce qu un firewall? Un firewall est une passerelle qui restreint le trafic sur le réseau auquel il est connecté (appelé en français un pare-feu). Les buts d un firewall sont multiples. La fonction première d un firewall est de bloquer les paquets non désirés afin de protéger le réseau local. Les firewalls plus évolués permettent cependant de faire bien plus que du filtrage de paquets ; ils peuvent notamment impersonnaliser l émetteur, transférer les paquets vers une autre machine ou un autre port, équilibrer la charge entre différents serveurs ou transférer les paquets d une interface vers une autre en suivant des règles établies au préalable. Nous pouvons catégoriser les firewalls selon deux critères ; leur nature (hardware ou software) et leur mode de fonctionnement (à état ou sans état). Concernant la nature des firewalls, nous distinguons les firewalls hardware et les firewalls software. Les firewalls hardware sont plus performants que les firewalls software mais offrent en général moins de souplesse de configuration pour l administrateur réseau. Cependant, ce manque de souplesse est pallié par du matériel dédié qui permet d obtenir des meilleures performances. Les firewalls software sont des démons ou des morceaux du noyau tournant sur une machine ou un serveur. Il s agit d une couche logicielle supplémentaire qui permet de travailler sur les paquets entrant et sortant des interfaces réseaux. Concernant le mode de fonctionnement, on parle des firewalls à états et des firewalls sans état. Les firewalls sans état utilisent des règles simples ne nécessitant pas de suivi de connexion ou d état (par exemple ; on observe les adresses et les ports source ou destination des paquets). Les firewalls à états permettent un traitement plus évolué des paquets et impliquent un suivi des connexions et des états (par exemple ; on observe dans quel état est la connexion : établie, nouvelle, invalide,...). 1.2 Où placer un firewall? En règle générale, on place le firewall entre le reste du monde (typiquement, une connexion internet) et le réseau de l entreprise. Cependant, les bons adminis- 1

trateurs réseaux préfèrent pratiquer la sécurisation du réseau par niveau. L idée de la sécurisation par niveau est de découper le réseau en couches par groupe de machines qui ont le même niveau de sécurité. Entre chaque niveau (ou zone), on place un firewall supplémentaire qui va encore restreindre un peu plus l accès au niveau suivant. Les niveaux de sécurité s accroissent au fur et à mesure que l on s éloigne de l accès extérieur (le reste du monde). Typiquement, un réseau se compose de deux zones : la zone démilitarisée et le réseau local. La zone démilitarisée contient les différents serveurs accessibles de l extérieur du réseau d entreprise. Le réseau local contient les serveurs propres à l entreprise et les machines clientes de l entreprise. Pour sécuriser un tel réseau, deux possibilités s offrent à nous. Le première consiste à avoir un firewall possédant trois cartes réseaux ; une connectée à la zone démilitarisée, une connectée au réseau local et la dernière connectée au reste de monde. L avantage indéniable est que la configuration de filtrage est centralisée en un même point. L inconvénient est que si le firewall est mal configuré ou attaqué, la zone démilitarisée et le réseau local peuvent être accessibles de l extérieur. La seconde solution, que nous préférons, est d utiliser deux firewalls. Un premier firewall se charge de la protection générale du réseau d entreprise et est connecté d une part à la zone démilitarisée et d autre part, au reste du monde. Il sert de premier filtre. Le deuxième firewall se plaçant entre la zone démilitarisée et le réseau local pour restreindre encore le trafic réseau qui doit circuler vers le réseau local. Nous préférons la seconde solution pour les raisons suivantes. Premièrement, la charge de filtrage est répartie sur deux machines physiques. Deuxièmement, si la sécurité d un des firewalls est remise en cause, l autre (ou les autres suivant le nombre de niveaux de sécurité) assure toujours une partie de la politique de sécurité. 2 Solutions 2.1 Produits commerciaux Parmi les firewalls hardware, on retrouve quelques leaders du marché comme Cisco (avec son PIX 500), 3Com ou encore Watchguard qui propose toute une gamme de systèmes firewall. Il en existe bien d autres mais nous ne citerons que les plus connus. Les prix de ces firewalls hardware s échelonnent de 250 à plus de 5000 euros (pour les modèles 100Mb) suivant la masse de trafic réseau qu ils peuvent filtrer. Pour information, le prix d un Watchguard Gigabit s échelonne entre 10000 et 60000 euros. Deux points importants qu il convient de vérifier avant d acheter un firewall hardware ; il s agit de la souplesse de configuration et de la bande passante de filtrage (la masse de données que le firewall peut traiter par seconde). Les firewalls hardware peuvent sembler d un prix exorbitant mais il faut bien se rendre compte que même un très gros serveur équipé d un firewall software ne 2

pourra jamais traiter un trafic d un gigabit par seconde. Parmi les firewalls software, on retrouve des solutions relativement connues comme ZoneAlarm, les produits Symantec Professional, McAffee, 3Com,... Les prix des firewalls software sont nettement moins élevés. On commence dans une fourchette de 50 à 150 euros pour les solutions les plus courantes et on termine vers 1500 à 2000 euros. 2.2 Solutions sous Linux Sous Linux, il existe d une part les solutions commerciales et d autre part un système de filtrage intégré au noyau. Nous allons continuer ce document en nous aventurant dans le système de filtrage intégré au noyau. Le sous-système de traitement de paquets réseau du noyau Linux s appelle Netfilter. Il s agit d un ensemble de fonctionnalités qui peuvent, comme toute partie du noyau, être chargées à l aide de modules ou être intégrées directement dans le noyau. Au cours des versions du noyau Linux, le système Netfilter a évolué et deux versions essentielle se sont dégagées au cours du temps. Notez que nous allons uniquement couvrir les aspects liés au noyau standard et nous ne parlerons pas des noyaux custom tel que LIDS (Linux Detection Intrusion System) ou encore le projet Openwall pour ne citer que les plus connus. Le lecteur désireux d en savoir plus sur ces noyaux spécialisés dans la sécurité peut trouver des informations complémentaires dans les références. 2.2.1 Historiquement : ipchains Dans les noyaux Linux 2.0 et 2.2, le système de traitement de paquets réseaux du noyau s appelait déjà Netfilter et était configuré par la commande ipchains. Nous n allons pas nous attarder sur ipchains. Sachez cependant qu il est encore utilisé par quelques administrateurs mais tend à laisser sa place à iptables que nous verrons dans la suite du document. En annexe de ce document, vous trouverez un résumé des raisons qui ont provoqué la disparition progressive d ipchains. 2.2.2 Actuellement : iptables Depuis le noyau 2.4, la commande employée pour configurer le sous-système du traitement des paquets (Netfilter) est iptables. Ce document couvre le jeu d outils iptables utilisé par les fonctionnalités Netfilter du noyau Linux dans la version 2.4 mais il traite également de la version 2.6. En raison du lien important qui existe entre Netfilter et iptables, nous retiendrons le terme iptables tout au long du document. L idée générale est que des tables regroupent, en fonction de leur rôle respectif, les différentes règles de traitement de paquets d iptables (à savoir : filtrage de 3

paquets, traduction d adresses réseau ou tout autre traitement sur les paquets). Chacune de ces tables possèdent un ensemble de règles qui définiront ce que le firewall doit faire avec les paquets qu il intercepte. La commande iptables permet de configurer un firewall à états ou sans état. Lors de l étude de cas qui va suivre, nous avons opté pour un firewall sans état pour des raisons de performances. Les firewalls à états nécessitent beaucoup plus de ressources au niveau de la machine car le noyau doit suivre toutes les connexions transitant par lui. Nous aborderons néanmoins la configuration de règle utilisant les états d un point de vue théorique dans la section suivante. Le système iptables opère au niveau de la couche OSI 3 (couche réseau ; IP). Pour la couche de niveau 2 (couche liaison), on se tournera vers d autres technologies, telles qu ebtables (Ethernet Bridge Tables). Le travail sur cette couche peut servir par exemple à effectuer du filtrage sur base des adresses MAC. Des informations complémentaires à ce propos sont disponibles dans les références. Examinons maintenant le fonctionnement d iptables en détails. 3 Iptables Nous n allons pas disséquer le mode de fonctionnement d iptables. Dans un souci de concision, nous allons nous limiter aux aspects d iptables utiles dans le cadre du travail d un administrateur système. Afin de bien comprendre le fonctionnement d iptables, nous allons introduire quelques concepts clés qui reviendront tout au long de ce document. Après cela, nous examinerons le fonctionnement d iptables. Et enfin, nous pourrons examiner comment configurer iptables pour répondre à nos besoins. 3.1 Concepts clés Avant d entrer dans le fonctionnement et la configuration du firewall à l aide d iptables, nous devons introduire certains concepts liés aux réseaux et aux firewalls. Examinons ces concepts immédiatement. Une interface réseau est une interface liée à un module réseau dans le noyau linux. Une interface réseau peut être une carte réseau filaire ou sans-fils (eth0, eth1,...) ou un accès point-à-point (ppp0, ppp1,...). Les accès point-à-point sont typiquement utilisés pour des liaisons série (via câble série entre deux machines) ou pour des modems (ADSL, analogique,...). Les interfaces réseaux sont généralement liées à un périphérique physique (noté qu une interface peut être liée à un périphérique logique ; par exemple : une connexion PPP over Ethernet - PPPoE). Un processus local est un programme (démon, kernel ou utilisateur) tournant sur la machine. Au niveau d un firewall, un processus local est un processus qui fonctionne sur la machine faisant office de firewall. En général, il s agit d outils de configuration ou de programmes utilisateurs destinés à personnaliser le comportement du firewall. 4

Un paquet est une unité de données de la couche 3 du modèle TCP/IP. Ces paquets sont constitués d un en-tête et d un corps. L en-tête comprend toutes les informations nécessaires à la gestion du paquet (son transfert, sa priorité, le type de service) qui permettent donc de diriger le paquet ou de le filtrer sans devoir extraire les informations du corps. Le corps contient les données brutes du paquet (ces données correspondent à l unité de la couche 4 ; TCP ou UDP). C est l entête du paquet IP qui est le plus utilisé pour le filtrage du firewall. Remarque : Nous pouvons faire du filtrage plus complexe sur les protocoles des couches supérieures (comme la couche applicative) en utilisant un proxy tel que Squid sous Linux (voir référence). Une cible indique l action à entreprendre lorsqu une règle correspond à un paquet. Les cibles les plus utilisées sont ACCEPT (autoriser le paquet) et DROP (rejeter le paquet), mais il en existe beaucoup d autres. Nous examinerons les cibles en détails dans la section traitant du fonctionnement d iptables. Une règle consiste en un (ou plusieurs) critère(s) de correspondance qui permet (permettent) de distinguer les paquets réseaux qu elle affecte. On dit que le paquet correspond à une règle si tous les critères sont satisfaits. Les correspondances peuvent se faire sur la source ou la destination du paquet mais aussi sur d autres critères dépendant du protocole utilisé. Une règle possède également une cible. Cette cible indiquera la manière dont sera traité le paquet s il correspond à la règle. Nous reparlerons des critères de correspondance et des cibles dans la suite du document. Remarque : Le système Netfilter permet d effectuer des filtrages sur d autres critères que ceux disponibles par défaut. Pour ce faire, il faut charger les modules du noyau ou intégrer les modules nécessaires au noyau. Dans les annexes, nous envisageons brièvement quelques modules complémentaires que nous pouvons utiliser. Un point d entrée décrit le moment où le traitement (le traitement étant défini par la table utilisée ; NAT, FILTER ou MANGLE) sera appliqué sur le paquet. Nous examinerons les points d entrée plus en détails dans la section suivante. Une chaîne est un ensemble de règles liées à un point d entrée. Par défaut, toute table possède des chaînes initialement vides. La politique d une chaîne détermine le sort des paquets qui atteignent le bout de la chaîne sans avoir été envoyés sur une cible. On peut assimiler la politique de chaînes au sort par défaut appliqué aux paquets. La politique d une chaîne peut être soit ACCEPT (accepter les paquets), soit DROP (rejeter le paquet) ; les autres cibles ne sont pas autorisées dans les politiques de chaînes. Une table est un ensemble de chaînes qui effectuent un même type de traitement à des moments différents (les moments d application des règles sont définis par les points d entrées). Il existe trois tables par défaut permettant chacune d effec- 5

tuer un traitement particulier. La table NAT (Network Address Translation) permet d effectuer de la transformation d adresses (et de port) sur les paquets. La table FILTER permet d effectuer le filtrage des paquets. La table MANGLE permet de modifier de manière spécifique les paquets (suppression de certaines options IP,...). L administrateur peut néanmoins ajouter des tables dites tables utilisateurs qui permettent d effectuer un traitement particulier. Voilà pour les concepts clés. Ils seront très utilisés par la suite et il était donc important de clarifier certaines conventions de nommage. Examinons maintenant le fonctionnement d iptables. 3.2 Fonctionnement d iptables La connaissance du fonctionnement d iptables est le minimum requis pour pouvoir configurer un firewall. La configuration du firewall consiste en l écriture d un ensemble de règles ; cependant, ces règles ne peuvent pas être écrites n importe comment et elles seront évaluées dans un ordre bien précis. C est ce que nous allons examiner dans cette section. Le fonctionnement d iptables repose sur deux points fondamentaux qu il ne faut pas perdre de vue lors de la configuration. Premièrement, les paquets traversent le système d une manière précise pour chacune des tables. C est très important pour déterminer où se situent les points d entrées. Deuxièmement, les paquets sont présentés aux différentes tables et chaînes dans un ordre précis. Mais avant d examiner ces deux points, nous allons voir quels sont les points d entrées disponibles par défaut sous iptables. 3.2.1 Les points d entrées Comme nous l avons dit plus haut, un point d entrée décrit le moment où le traitement (défini par la table utilisée) sera appliqué sur le paquet. Le système iptables définit cinq points d entrée : le pré-routage (PREROUTING), l entrée (INPUT), le transfert (FORWARD), le post-routage (POSTROUTING) et la sortie (OUTPUT). Le point d entrée FORWARD (transfert) permet le traitement des paquets qui arrivent vers une passerelle, arrivant de l une des interfaces réseaux et ressortant immédiatement par une autre. Le point d entrée INPUT (entrée) permet le traitement des paquets immédiatement avant qu ils ne soient délivrés au processus local. Le point d entrée OUTPUT (sortie) permet le traitement des paquets immédiatement après leur génération par un processus local. Le point d entrée POSTROUTING (post-routage) permet le traitement des paquets juste avant qu ils ne sortent par l interface réseau. Le point d entrée PREROUTING (pré-routage) permet le traitement des paquets immédiatement après leur arrivée par l interface réseau (après vérification de leur somme de contrôle et suppression des paquets non autorisés en raison de l activation du mode promiscuous de l interface réseau). 6

Maintenant que nous avons parlé des points d entrée, nous pouvons envisager la manière dont les paquets traversent le système. 3.2.2 Flux de paquets et points d entrées Chacune des tables possède un ensemble de chaînes. Chacune de ces chaînes définit un ensemble de règles à appliquer sur un point d entrée. Nous allons examiner la manière dont les paquets traversent le système pour chacune des tables. Vous remarquerez qu une table n utilise pas forcément tous les points d entrées existants. La table NAT (Network Address Translation) permet d effectuer de la transformation d adresses (et de port) sur les paquets. La figure 1 indique la manière dont les paquets traversent le système lors de la traduction d adresses réseaux. La table FILTER permet de filtrer les paquets. La figure 2 indique la manière dont les paquets traversent le système lors du filtrage de paquets. La table MANGLE permet de modifier de manière spécifique les paquets (comme la suppression de certaines options IP). La figure 3 indique la manière dont les paquets traversent lors de la modification des paquets. FIG. 1 Flux des paquets et points d entrée pour la table NAT Les figures de 1 à 3 nous serons très utiles lors de la configuration du firewall car elles permettent de voir au premier coup d oeil les différents moments correspondants aux points d entrée utilisables. Nous allons maintenant examiner le second aspect important dans la configuration d iptables ; il s agit de l ordre suivant lequel les paquets sont présentés aux tables par défaut et aux chaînes. 3.2.3 Flux de paquets et chaînes Comme nous l avons dit plus haut, les paquets sont présentés aux différentes tables et chaînes dans un ordre précis. Dans cette section, nous allons examiner cet aspect d iptables. Les paquets traversent les chaînes et sont présentés aux règles de la chaîne suivant leur ordre d arrivée. Si un paquet ne correspond à aucun critère de la règle, 7

FIG. 2 Flux des paquets et points d entrée pour la table FILTER FIG. 3 Flux des paquets et points d entrée pour la table MANGLE il est soumis à la règle suivante de la chaîne. Si un paquet atteint la dernière règle sans correspondre à la moindre règle, c est la politique de la chaîne qui lui sera appliquée. L ordre suivant lequel les paquets sont présentés aux tables par défaut et aux chaînes est défini suivant le point de départ et le point d arrivée d un paquet. Un point de départ (ou d arrivée) peut être une interface réseau ou un processus local. On distingue quatre possibilités : Le paquet transite d une interface réseau vers une autre. Le paquet transite d une interface réseau vers un processus local. Le paquet transite d un processus local vers une interface réseau. Le paquet transite d un processus local vers un autre. Les figures 4 à 7 indiquent l ordre suivant lequel les paquets sont présentés aux tables et aux chaînes par défaut. 8

Table MANGLE NAT MANGLE FILTER MANGLE NAT Chaîne PREROUTING PREROUTING FORWARD FORWARD POSTROUTING POSTROUTING FIG. 4 Le paquet transite d une interface réseau vers une autre. Table MANGLE NAT MANGLE FILTER Chaîne PREROUTING PREROUTING INPUT INPUT FIG. 5 Le paquet transite d une interface réseau vers un processus local. Table MANGLE NAT FILTER MANGLE NAT Chaîne OUTPUT OUTPUT OUTPUT POSTROUTING POSTROUTING FIG. 6 Le paquet transite d un processus local vers une interface réseau. Table MANGLE NAT FILTER FILTER MANGLE Chaîne OUTPUT OUTPUT OUTPUT INPUT INPUT FIG. 7 Le paquet transite d un processus local vers un autre. 3.2.4 Les cibles Les cibles permettent de choisir l action à entreprendre lorsqu un paquet correspond à une règle ; elles servent également à indiquer les politiques de la chaîne. Le système de filtrage iptables dispose par défaut de quatre cibles mais elles peuvent être étendues par le biais de modules à adjoindre au kernel. La cible ACCEPT permet d autoriser le paquet à passer au maillon suivant de la chaîne de traitement. La cible DROP permet d arrêter complètement la progression du paquet dans la chaîne. Si vous voulez fournir un retour à l émetteur, utilisez l extension de cible 9

REJECT. La cible QUEUE permet d envoyer le paquet vers l espace utilisateur (c est-àdire du code qui ne fait pas partie du noyau). Cette cible est utilisée pour étendre les fonctionnalités du firewall par des extensions faites maison. Reportez-vous à la man page de libipq pour de plus amples informations (lien disponible dans les références). La cible RETURN permet, lorsqu elle est appelée depuis une règle contenue dans une chaîne utilisateur, d arrêter le traitement de cette chaîne et de recommencer la traversée de la chaîne appelante. Cette traversée recommence à la règle suivant celle qui avait ladite chaîne pour cible. Si cette cible est appelée depuis une règle contenue dans une chaîne intégrée, on arrête le traitement du paquet et on lui applique la politique par défaut de la chaîne. Il existe d autres cibles disponibles mais la place nous manque. Le lecteur pourra trouver des informations complémentaires dans la bibliographie. 3.3 Configuration d iptables Maintenant, nous allons décrire la syntaxe de la commande iptables. Comme nous l avons dit plus haut, c est à l aide de cette commande que nous configurons les règles du firewall. Nous allons nous limiter aux options les plus courantes et nous renvoyons le lecteur aux man pages d iptables pour de plus amples informations (lien dans les références). La plupart des commandes d iptables peuvent être regroupées en sous-commandes, règles de correspondance et options. Nous allons examiner chacune de ces catégories. 3.3.1 Les options Nous introduisons les options en premier lieu car nous allons en avoir besoin pour exemplifier les sous-commandes et les règles de correspondances. Remarque : Il nous est difficile d introduire quelques exemples ici. Nous utiliserons ces options dans les exemples quand nous introduirons les sous-commandes et les règles de correspondances. Voici quelques options que nous utiliserons par la suite. -h (-help) Affiche la liste des commandes iptables. -j cible [options] (-jump) Détermine le sort des paquets correspondant à la règle. La cible peut être le nom d une chaîne utilisateur, l une des cibles par défaut ou encore une extension iptables (auquel cas des options supplémentaires peuvent être passées). 10

-t table (-table) La sous-commande affecte la table passée en argument. Si cette option n est pas utilisée, la commande affectera par défaut la table filter. 3.3.2 Les sous-commandes d iptables Chaque commande iptables peut contenir une sous-commande d exécution d une certaine opération sur une table donnée (spécifié par l option -t table). Comme nous l avons dit plus haut, une règle est composée d un ou plusieurs critères de correspondance qui vont permettre de matcher un paquet et de l envoyer sur une cible. La commande iptables permet d ajouter des règles à l aide de la sous-commande -A (-append). Par exemple, si nous voulons ajouter une règle à la table FILTER dans la chaîne INPUT, nous utiliserons une commande comme celle-ci : iptables -t FILTER -A INPUT règle Nous verrons lors de la section suivante comment écrire des règles de correspondance. Nous pouvons également définir la politique de la chaîne d une manière similaire en utilisant la sous-commande -P (-policy). iptables -t FILTER -P INPUT DROP Remarquez que les cibles autorisées pour les politiques de chaînes sont uniquement les cibles intégrées. Voici un bref résumé des autres sous-commandes que nous allons utiliser. -A chaîne règle (-append) Ajoute la règle à la fin de la chaîne. -F [chaîne] (-flush) Supprime toutes les règles de la chaîne (ou toutes les règles de toutes les chaînes si aucune chaîne n est spécifiée). -L [chaîne] (-list) Liste les règles de la chaîne (ou toutes les chaînes si aucune n est indiquée). -N chaîne (-new-chain) Crée une nouvelle chaîne utilisateur. -P chaîne cible (-policy) Règle sur cible la politique par défaut de la chaîne intégrée. N est valable que pour les chaînes et cibles intégrées. 11

-X [chaîne] Supprime la chaîne utilisateur (ou toutes les chaînes utilisateurs si aucune n est spécifiée). Remarque : Nous pouvons également supprimer des chaînes ou des règles, insérer des règles à un endroit précis de la chaîne, renommer ou remplacer des règles,etc... Pour des raisons de simplicité et pour ne pas transformer ce document en man pages, nous n en parlons pas. 3.3.3 Les règles de correspondance Il existe des livres entiers parlant des différents critères utilisables pour définir une correspondance. Nous n allons pas toutes les examiner et nous vous renvoyons à la référence [3] pour un traitement plus en profondeur du sujet. Les options les plus souvent utilisées pour les règles de correspondances sont les sources et les destinations. Nous pouvons définir la source du paquet de deux manières ; en spécifiant l interface réseau par laquelle le paquet arrive ou en spécifiant une adresse IP source (adresse IP seule ou réseau avec masque). Pour ce faire, nous avons les options -i (-in-interface) pour spécifier l interface et -s (-source) pour spécifier l adresse (ou le réseau) source. Par exemple, la commande suivante permet d ajouter une règle sur la chaîne INPUT de la table FILTER (table utilisée par défaut) qui va vérifier les paquets provenant de l interface ppp0 et de l adresse IP 10.0.0.10 pour les jeter (DROP). iptables -A INPUT -i ppp0 -s 10.0.0.10 -j DROP Pour pouvoir définir un réseau, il nous suffit d indiquer le masque réseau de la manière suivante (pour le réseau de classe C 10.0.0.0). iptables -A INPUT -i ppp0 -s 10.0.0.0/24 -j DROP Nous pouvons établir le même type de critères pour l interface réseau de sortie et pour l adresse de destination avec les options -o (-out-interface) et -d (-destination). Par exemple, nous désirons jeter tous les paquets provenant de l interface ppp0 et ayant pour source n importe quelle adresse IP (0.0.0.0/0) dont la destination est l interface réseau eth0 pour une machine ayant l IP 192.168.0.5. -i ppp0 -s 0.0.0.0/0 -o eth0 -d 192.168.0.5 -j DROP Nous pouvons établir d autres règles de correspondances plus complexes travaillant sur le protocole TCP/UDP et permettant des règles de correspondances sur 12

les ports. Pour spécifier le protocole que nous désirons vérifier, nous utilisons l option -p. A partir de là, nous pouvons spécifier des options liées au protocole. Par exemple, si nous désirons établir un critère sur le port de destination du protocole TCP, nous écrirons une ligne de ce type. iptables -A INPUT -i ppp0 -s 0.0.0.0/0 -p tcp --destination-port 80 -j ACCEPT D autres protocoles sont disponibles comme le protocole ICMP (Internet Control Management Protocol destinés aux contrôles. Pour ce protocole, nous disposons également d autres options. -i ppp0 -s 0.0.0.0/0 -o eth0 -d 192.168.0.0/24 -p icmp --icmp-type address-mask-reply -j DROP Comme nous l avons dit plus haut, il faudrait un livre complet pour expliciter toutes les règles de correspondances possibles. Nous n allons donc pas nous avancer plus en avant dans les règles de correspondances et nous allons directement passer à un cas pratique. Remarque : Les différents protocoles gérés par iptables sont gérés par modules du noyau. Pour ajouter la gestion de règle de suivi de connexion ou pour prendre en charge d autres protocoles, il est nécessaire d adjoindre ces modules au noyau. Vous trouverez les principaux modules de Netfilter expliqués brièvement en annexe de ce document. 3.4 Pour la suite du document... Dans la suite du document, nous allons vous présenter une étude de cas sur base d une configuration réseau relativement habituelle pour une entreprise. Lors de cette étude de cas, nous allons utiliser et illustrer les différentes fonctionnalités fournies par le système Netfilter du noyau linux. Pour chacune de ses fonctionnalités, nous allons vous présenter les buts de l opération et comment mettre cette fonctionnalité en oeuvre. 4 Étude de cas Voyons sur base d un schéma qui nous suivra tout au long du document les endroits où se placent les firewalls dans une configuration d entreprise standard à deux niveaux de sécurité. 13

Dans notre exemple, les deux niveaux de sécurité sont la zone démilitarisée (DMZ) et la zone sécurisée (LAN). La figure 8 illustre le réseau de notre étude de cas. La DMZ se compose de serveurs qui sont accessibles du monde extérieur. Dans notre cas, nous avons deux serveurs web ; un serveur web vitrine (dénommé WEB, 192.168.0.2) et un serveur web interne (dénommé INTRAWEB, 192.168.0.3). Nous avons également un serveur de mail qui assure les services smtp et pop3 (dénommé MAIL, 192.168.0.3). Le serveur web vitrine est accessible de l extérieur via le port tcp 80. Le serveur web destiné aux commerciaux est accessible de l extérieur via le port tcp 8080 mais il fonctionne sur le port 80 dans le réseau d entreprise. Le serveur de mail fournit les services de transfert smtp sur le port 25 et les services de relevé de boite pop3 sur le port 110. Le LAN se compose de deux serveurs et des clients. Les clients se dénomment CLIENTx (x allant de 1 à 99) et utilisent une plage d adresse de 192.168.1.101 à 192.168.1.199. Ils sont autorisés à accéder aux serveurs de la DMZ et ont le droit d accéder à internet pour les services http (web, port 80) et dns (l entreprise ne possède pas de serveur DNS, port 53). Le LAN comprend également deux serveurs ; un serveur applicatif (dénommé APPS, 192.168.1.2) et un serveur de base de données (dénommé SQL, 192.168.1.3). Le serveur applicatif tourne sur le port 1200 et le serveur de base de données tourne sur le port 1300. Seuls les clients peuvent accéder à ces deux serveurs. FIG. 8 Schéma du réseau de l étude de cas 14

Entre le reste du monde et le réseau d entreprise, on va placer un firewall que nous appellerons firewall principal (dénommé FW-MAIN). Entre la DMZ et le LAN, nous allons placer un second firewall que nous appellerons firewall secondaire (dénommé FW-2). Dans notre cas, les firewalls sont configurables au travers du protocole SSH (SSH est un système de console distant sécurisé). L adresse IP qui est attribuée au firewall principal pour l interface réseau exposée au reste du monde est fixe (il s agit de 192.168.10.1). Les clients extérieurs au réseau d entreprise ne verront aucune autre interface que cette dernière. La politique que nous allons mettre en oeuvre est la suivante. Le firewall principal (FW-MAIN) va assurer les services suivants : bloquer tous les paquets ROW FW-MAIN. bloquer tous les paquets DMZ FW-MAIN sauf le protocole SSH (port 22). bloquer tous les paquets ROW DMZ. bloquer tous les paquets DMZ ROW sauf les ping (protocole ICMP), les services web, le dns (qui sont nécessaires à l accès internet des clients) et le smtp provenant du serveur MAIL. transférer les accès web vitrine du ROW (port 80) vers le serveur WEB (port 80). transférer les accès web interne du ROW (port 8080) vers le serveur INTRA- WEB (port 80). transférer les accès smtp et pop3 (port 25 et 110) vers le serveur MAIL (port 25 et 110). impersonnaliser tous les paquets DMZ ROW. Le firewall secondaire (FW-2) se trouvant entre la zone démilitarisée et la zone sécurisée va assurer les services suivants : bloquer tous les paquets DMZ FW-2. bloquer tous les paquets LAN FW-2 sauf le protocole SSH (port 22). bloquer tous les paquets DMZ LAN. bloquer tous les paquets LAN DMZ sauf les ping (protocole ICMP), les services web, le dns, le smtp et le pop3. impersonnaliser tous les paquets LAN DMZ. Certains aspects de cette politique de sécurité pourront paraître obscurs ou accessoires, nous justifierons chacun de ces points dans la suite du document. 4.1 Configuration du firewall principal Le firewall principal a pour buts essentiels de protéger le réseau d entreprise des attaques générales provenant de l extérieur et de cacher la structure du réseau. En effet, une fois le firewall principal complètement configuré, les clients extérieurs à l entreprise communiqueront exclusivement avec l interface extérieure du réseau (192.168.10.1). Ils ignoreront tout de la machine avec laquelle ils communiquent. En plus de ne pas divulguer la topologie du réseau d entreprise, nous pouvons, 15

au travers des transferts de ports, ajouter des serveurs ou placer plusieurs serveurs qui rendent le même service dans la DMZ (afin d équilibrer la charge de travail par exemple) sans avoir à modifier le nom de domaine extérieur. Il suffit de changer la configuration du forward de port pour changer de serveur. Nous allons commencer par un fichier de configuration nu que nous allons améliorer et affiner au cours des étapes qui suivent. Le fichier de configuration complet du firewall principal se trouve en annexe. 4.1.1 Étape : Initialisation basique Avant de se lancer dans la configuration proprement dite, nous allons déterminer quels sont les éléments dont nous avons besoin. Par élément, nous entendons les noms de réseaux, les adresses IP des machines, les noms des interfaces,... Pour faciliter l écriture (et surtout la lecture) du fichier de configuration, nous allons définir une série de variables dans le fichier de configuration. Dans le firewall principal, ces lignes de définition de variables sont les suivantes : IFACE_ROW=eth1 IFACE_DMZ=eth0 NET_DMZ=192.168.0.0/24 EVERYBODY=0.0.0.0/0 IP_ROW=192.168.10.1 IP_DMZ=192.168.0.1 IP_FW2=192.168.0.5 IP_WEB=192.168.0.2 IP_INTRAWEB=192.168.0.3 IP_MAIL=192.168.0.4 Dans ces quelques variables, nous définissons les interfaces réseaux de notre firewall (IFACE_ROW et IFACE_DMZ). Ces interfaces dépendent bien entendu de la machine et des connexions physiques des réseaux. Ensuite, nous définissons deux ranges de réseau : le réseau de la DMZ (NET_DMZ) et toutes les adresses réseaux (par le biais de 0.0.0.0/0, que nous appelons EVERYBODY). En plus de cela, nous ajoutons les différentes adresses IP des machines avec lesquelles le firewall devra dialoguer. Dans ces adresses IP, on retrouve les adresses IP du firewall (des deux côtés ; IP_ROW et IP_DMZ) et les différentes machines du réseau DMZ. Il peut sembler superflu de définir toutes les machines de réseau DMZ. En fait, la politique de sécurité que nous désirons mettre en oeuvre sera très stricte au sein de la zone démilitarisée. La DMZ va voir transiter des paquets provenant de machines extérieures au réseau d entreprise ; chacune de ces entrées extérieures est un risque d attaque. 16

En limitant les transits aux seules adresses que nous avons définies préalablement, nous limitons le risque d attaque sur un serveur qui ne devrait pas être vu de l extérieur. Par exemple, imaginons que le serveur web vitrine montre des signes de vieillesse. L entreprise décide de placer un second serveur web dans la zone DMZ pour effectuer une mise à jour du site internet (en ajoutant des services dynamiques par exemple). Ce nouveau serveur va rester dans la DMZ le temps du développement du nouveau site. Or, sous certaines conditions, un agent extérieur pourrait faire des requêtes sur ce serveur (qui n est pas encore en production) et donc, utiliser une faille sur ce serveur à des fins malveillantes (ce qui est probable vu que le service est encore en développement). Cela peut arriver si on autorise les transferts (FORWARD) vers l entièreté du réseau DMZ. C est pour cela que nous allons faire des transferts (FORWARD) uniquement vers des adresses IP définies préalablement. Après avoir défini ces quelques variables, nous allons vider les chaînes existantes dans le firewall. De cette manière, on est sûr et certain des valeurs initiales des règles de notre firewall. Pour ce faire, nous effectuons un flush des tables. iptables -t filter -F iptables -t nat -F iptables -t mangle -F La dernière étape de l initialisation consiste à créer une chaîne utilisateur qui va nous permettre de journaliser les éliminations des paquets indésirables. Cette chaîne n est pas indispensable mais elle est très utile lors de la configuration ou la maintenance du firewall. L idée est de créer une chaîne LOGDROP, cette chaîne va simplement logguer le paquet avant de le dropper (jeter). Cette chaîne va être définie comme ceci : iptables -X iptables -N LOGDROP iptables -A LOGDROP -j LOG --log-prefix "FW-DROP:" iptables -A LOGDROP -j DROP La première ligne (option -X) sert simplement à effacer toutes les chaînes utilisateurs. Nous faisons ça pour les mêmes raisons que nous remettons les règles des tables à zéro (le flush ci-dessus). Ensuite, nous créons une nouvelle chaîne LOGDROP (option -N) et nous ajoutons deux règles. La première va nous permettre de logguer les paquets en indiquant le préfixe spécifié. Ces lignes seront ajoutées aux logs du noyau dans /var/log/messages. Le seconde règle permet de jeter le paquet. Ce système de logging précédant le drop est très utile à la mise au point et à la maintenance du firewall car de cette manière, on peut examiner les journaux pour savoir plusieurs choses. Tout d abord, on peut examiner les paquets louches 17

qui sont jetés ; comme les paquets passant par des ports utilisés par les virus ou les chevaux de Troie. De plus, lorsqu un nouveau logiciel doit être installé sur une machine client, on peut voir que c est le firewall qui empêche les paquets de sortir (et donc, ce n est pas un problème de logiciel). Cela peut paraître idiot mais bon nombre de sociétés se plaignent car un logiciel ne fonctionne pas alors que c est simplement leur firewall qui ne laisse pas sortir (ou entrer) les paquets. Pour utiliser cette chaîne de règles par la suite, on va simplement l utiliser comme cible. Nous verrons cela dans les prochaines étapes. Les prochaines étapes se feront de manières progressives afin d introduire des commandes simples pour ensuite examiner des concepts plus avancés. 4.1.2 Étape : filtrage des paquets ROW FW-MAIN La première étape de notre étude de cas est très simple. Le but est de bloquer tous les paquets provenant du ROW et dont la destination est le firewall lui-même. Remarque : Cette règle sera déjà remplacée à l étape suivante (c est pour cela qu elle ne se trouve pas dans le fichier annexé) mais elle va servir de base pour examiner la syntaxe de la commande iptables dans un environnement réel. Examinons cette première règle : iptables -A INPUT -j LOGDROP Donc, en fait, nous ajoutons une règle (option -A) au point d entrée INPUT. La table sur laquelle on travaille n est pas spécifiée ; c est parce qu on utilise la table par défaut FILTER. Comme nous l avons dit plus haut, une règle est composée de critères de correspondance et d une cible (c est-à-dire, l action à entreprendre). Dans notre cas, le premier critère est que le paquet provienne de l interface IFACE_ROW (le reste du monde (option -i, qui signifie input). Le deuxième critère concerne l adresse source du paquet ; ici, nous prenons les paquets provenant du réseau EVERYBODY (option -s, qui signifie source). Le sort du paquet est d être loggué avant d être jeté. Nous effectuons cela en envoyant le paquet sur la chaîne LOGDROP que nous avons définie préalablement. La cible est annoncée par l option -j. 4.1.3 Étape : filtrage des paquets DMZ FW-MAIN Maintenant que nous avons examiné comment ajouter une règle au firewall, nous allons pouvoir aller plus vite dans la configuration du firewall principal. Nous allons remplacer la règle précédente en utilisant la politique de chaîne. Comme nous l avons dit plus haut, la politique d une chaîne détermine le sort des paquets qui atteignent le bout de la chaîne sans avoir été envoyés sur une cible. On 18

peut considérer la politique de chaîne comme le sort par défaut des paquets arrivant sur une chaîne. Le but de cette étape est de filtrer les paquets arrivant sur le firewall ; c est-àdire les paquets qui sont adressés à un processus local. Nous devons jeter tous les paquets sauf ceux destinés au serveur SSH utilisé pour la configuration du firewall. Cependant, par souci de sécurité, nous allons autoriser les connexions au firewall uniquement en provenance de la DMZ. Voyons les règles qui vont remplacer la règle de l étape précédente. iptables -A INPUT -i $IFACE_DMZ -s $NET_DMZ -p tcp --destination-port ssh -j ACCEPT iptables -A INPUT -j LOGDROP La première règle autorise les paquets provenant du réseau DMZ (et venant physiquement de l interface reliée au DMZ) qui ont pour port de destination le port par défaut du serveur SSH. La deuxième règle définit la politique de la chaîne en jetant tous les paquets ne correspondant pas à la première règle. Une petite remarque doit être notifiée. Il peut sembler superflu d indiquer l interface réseau d entrée des paquets. En fait, on indique l interface physique de connexion du réseau pour éviter les IP spoofing. L IP spoofing est une technique de hacking consistant à utiliser l adresse IP d une machine, ou d un équipement, afin d en usurper l identité. Elle permet de récupérer l accès à des informations en se faisant passer pour la machine dont on spoofe l adresse IP. C est pour cette raison que la spécification de l interface réseau sur laquelle on travaille est très importante pour garantir une meilleure sécurité. Remarque : Les ports que nous indiquons dans les règles sont toujours des acronymes. Nous pouvons indiquer les numéros de port directement. Cependant, il est plus simple d utiliser un nom de service pour des raisons de lisibilité. Les correspondances entre les noms de service et les ports sont indiquées dans le fichier /etc/services. Ce sont les seules règles qui seront appliquées pour les flux de paquets provenant d une interface réseau vers un processus local. Notez que les paquets de type ICMP (les ping) destinés au firewall seront également jetés. Cette technique simple de rejeter les pings permet de limiter les attaques proférées par les hackers du dimanche (ils essaient un ping, la machine ne réponds pas, ils pensent qu il n y a pas de machine). De plus, elle évite certaines attaques de type deny-of-service. Ces attaques consistent à envoyer un très grand nombre de paquets inutiles à partir de plusieurs machines différentes pour que le firewall passe son temps à répondre aux pings et ne puissent plus rendre les services pour lesquels il est conçu. 19

4.1.4 Étape : filtrage des paquets ROW DMZ Maintenant, nous allons filtrer les paquets provenant du ROW et qui sont destinés à la DMZ. Le but de notre firewall à ce niveau est d empêcher toutes intrusions dans le réseau DMZ. Dans les étapes qui suivent, nous allons être un peu moins restrictifs pour autoriser les services et les réponses aux requêtes des clients (qui se trouvent dans le LAN). Dans un premier temps, nous bloquons tous les transferts de paquets du ROW vers le DMZ : -o $IFACE_DMZ -d $NET_DMZ -j LOGDROP De nouveau, cette règle va rapidement être obsolète par l utilisation de la politique de chaîne. Passons tout de suite à l étape suivante. 4.1.5 Étape : filtrage des paquets DMZ ROW Lors de cette étape, nous désirons filtrer les paquets sortant de la zone DMZ. Les sorties autorisées sont les pings, les requêtes http et les requêtes dns (pour les noms de domaine) ayant pour origine les clients. Les requêtes smtp sont également autorisées pour le serveur MAIL. Voyons comment nous allons configurer tout ça : -i $IFACE_DMZ -s $IP_FW2 -o $IFACE_ROW -d $EVERYBODY -p icmp -j ACCEPT -i $IFACE_DMZ -s $IP_FW2 -o $IFACE_ROW -d $EVERYBODY -p tcp --destination-port www -j ACCEPT -i $IFACE_DMZ -s $IP_FW2 -o $IFACE_ROW -d $EVERYBODY -p tcp --destination-port domain -j ACCEPT -i $IFACE_DMZ -s $IP_MAIL -o $IFACE_ROW -d $EVERYBODY -p tcp --destination-port smtp -j ACCEPT Et la politique de chaîne sera, comme vous vous en doutez : -j LOGDROP 20

Dans ces quelques lignes, nous attirons l attention sur le fait que les services qui seront utilisés par les clients (qui se trouvent derrière le firewall secondaire) doivent provenir de IP_FW2 ; et donc, du firewall secondaire directement. Cela est dû au fait que le firewall secondaire impersonnalisera les paquets provenant du LAN. Nous reviendrons sur l impersonnalisation des paquets un peu plus tard. Cependant, ces quelques lignes ne suffiront pas à autoriser la navigation web pour les clients ; pour la bonne et simple raison que nous autorisons uniquement les sorties du DMZ vers le ROW. Mais les paquets de réponses provenant du ROW pour les clients ne seront pas autorisés (à cause de la politique générale de la chaîne). C est pour cette raison que nous devons spécifier quelques règles supplémentaires pour autoriser les réponses provenant du ROW mais uniquement les réponses ; nous faisons ça en ajoutant un critère sur le port source du paquet. Voici les quelques lignes à ajouter pour que le surf sur le web et les pings fonctionnent sur les machines clientes : -o $IFACE_DMZ -d $IP_FW2 -p icmp --icmp-type echo-reply -j ACCEPT -o $IFACE_DMZ -d $IP_FW2 -p tcp --source-port www -j ACCEPT -o $IFACE_DMZ -d $IP_FW2 -p tcp --source-port domain -j ACCEPT Sans oublier les réponses aux requêtes smtp envoyés par le serveur MAIL : -o $IFACE_DMZ -d $IP_MAIL -p tcp --source-port smtp -j ACCEPT Une petite remarque s impose pour le protocole ICMP permettant les pings. Pour autoriser uniquement les réponses, nous indiquons que les paquets de type ICMP pouvant passer sont uniquement des echo-reply. Avec ces lignes de configuration, les clients peuvent surfer sur le web et le serveur MAIL peut envoyer ses requêtes SMTP. Examinons maintenant comment transférer les accès provenant de l extérieur sur les différents serveurs se trouvant dans la DMZ. 21

4.1.6 Étape : transfert des paquets de FW-MAIN serveurs DMZ La prochaine étape consiste à effectuer un transfert de port (et d adresse) lorsque certains paquets arrivent sur l interface du ROW. Cette pratique est courante dans les réseaux d entreprises pour plusieurs raisons. Premièrement, le coût d une adresse IP fixe sur internet est relativement élevé et donc, les entreprises en ont généralement une seule. Cependant, plusieurs services doivent être fournis sur cette adresse IP (dans notre cas, nous avons le web vitrine, le web interne pour les commerciaux, le relevé de boîte POP3 et les arrivée d émail SMTP). Or, dans une grande structure où les services sont fréquemment utilisés, la charge de travail est trop importante pour un seul serveur. C est pour cela que plusieurs serveurs se partagent la charge dans la DMZ et donc, le firewall (qui est connecté sur l IP fixe) doit transmettre le travail à qui de droit. Deuxièmement, les accès provenant de l extérieur (et donc, à risque) sont centralisés sur une seule machine qui s occupera du filtrage ; il s agit du firewall. En limitant au maximum les accès au firewall, nous limitons les dangers auxquels sont exposés les serveurs. Étant donné qu ils sont cachés derrière le firewall, c est le firewall qui sera attaqué. Et donc, on peut concentrer la politique de sécurité à un seul endroit ; le firewall. Dernièrement, les serveurs seront cachés du monde extérieur à l aide du forward de port et de l impersonnalisation des paquets. Un attaquant pensera dialoguer uniquement avec le firewall alors qu en réalité, il dialogue avec un serveur dont il ne connaît pas l adresse, ni même l existence. Ce qui limite le risque d attaque directe sur un des serveurs. Pour effectuer un transfert de port, nous allons simplement utiliser la table NAT (Network Address Translation). Le NAT va nous permettre de modifier les paquets arrivant pour un des serveurs alors que la destination originale est l adresse IP du firewall côté ROW. Examinons ces quelques lignes : iptables -t nat -A PREROUTING -d $IP_ROW -p tcp --destination-port www -j DNAT --to-destination $IP_WEB iptables -t nat -A PREROUTING -d $IP_ROW -p tcp --destination-port 8080 -j DNAT --to-destination $IP_INTRAWEB:80 iptables -t nat -A PREROUTING -d $IP_ROW -p tcp --destination-port smtp 22

-j DNAT --to-destination $IP_MAIL iptables -t nat -A PREROUTING -d $IP_ROW -p tcp --destination-port pop3 -j DNAT --to-destination $IP_MAIL Quelques commentaires s imposent. Prenons le premier forward de port destiné au serveur WEB. On voit que l on ajoute une règle à la table NAT (via l option -t nat). Les critères de correspondance indiquent que l on prend les paquets provenant de n importe où transitant par l interface réseau liée au ROW. La destination du paquet est IP_ROW, c est-à-dire l adresse IP sur internet de l entreprise. Le protocole à examiner est tcp sur le port 80 (le web). En résumé, on prend les paquets arrivant sur le port 80 du firewall. Cette règle est appliquée sur le point d entrée PREROUTING, c est-à-dire immédiatement après leur arrivée par l interface réseau. Le paquet vérifiant ces critères est envoyé sur la cible DNAT ; c est-à-dire Destination Network Address Translation. Le but est de changer l adresse de destination du paquet ; on spécifie la nouvelle adresse et le nouveau port de destination via l option -to-destination. Dans notre cas, on envoie le paquet sur l adresse IP du serveur WEB sans changer le port (car on n a pas indiquer de changement de port comme pour le serveur INTRAWEB). Cependant, au vu de la figure 4 qui indique l ordre des chaînes, notre paquet doit encore passer par la chaîne FORWARD. Or, la chaîne FORWARD ne connaît aucune règle qui laisse passer les paquets fraîchement modifiés en destination des serveurs de la DMZ ; nous devons donc les autoriser : -o $IFACE_DMZ -d $IP_WEB -p tcp --destination-port www -j ACCEPT -o $IFACE_DMZ -d $IP_INTRAWEB -p tcp --destination-port www -j ACCEPT -o $IFACE_DMZ -d $IP_MAIL -p tcp --destination-port smtp -j ACCEPT -o $IFACE_DMZ -d $IP_MAIL -p tcp --destination-port pop3 -j ACCEPT 23

Et suite à ceci, nous sommes confrontés au même problème que quelques étapes plus haut. Les clients provenant du ROW peuvent envoyer des requêtes à nos serveurs de la DMZ mais nos serveurs ne peuvent pas répondre. Nous ajoutons donc les FORWARD des réponses dans les règles du firewall : -i $IFACE_DMZ -s $IP_WEB -o $IFACE_ROW -d $EVERYBODY -p tcp --source-port www -j ACCEPT -i $IFACE_DMZ -s $IP_INTRAWEB -o $IFACE_ROW -d $EVERYBODY -p tcp --source-port www -j ACCEPT -i $IFACE_DMZ -s $IP_MAIL -o $IFACE_ROW -d $EVERYBODY -p tcp --source-port smtp -j ACCEPT -i $IFACE_DMZ -s $IP_MAIL -o $IFACE_ROW -d $EVERYBODY -p tcp --source-port pop3 -j ACCEPT Avec ces quelques lignes supplémentaires, les clients du ROW peuvent consulter nos serveurs en s adressant au firewall. Examinons maintenant la dernière étape de la configuration de notre firewall. 4.1.7 Étape : impersonnalisation des paquets La dernière étape est l impersonnalisation des paquets. Avant de voir ce que cela apporte et comment le faire, nous allons expliquer brièvement ce qu est l impersonnalisation. L impersonnalisation consiste à cacher qui est réellement l expéditeur du paquet. C est-à-dire que lors du passage dans le firewall, le paquet est modifié et le firewall devient l expéditeur du paquet. Dans ce cas, le firewall est appelé aussi proxy transparent. De cette manière, les machines extérieures au réseau ignorent les IP des machines du réseau car tous les paquets semblent provenir d une seule et même IP, celle du firewall. Cette technique de proxy transparent est utilisée pour deux raisons. La première est logique, si on ne possède qu une adresse IP sur internet et que le paquet contient comme expéditeur une adresse du réseau local. Lorsque le receveur du paquet va émettre sa réponse, il va l émettre à destination de l expéditeur du paquet contenu dans la requête de départ. Or, l adresse IP de notre machine du réseau local est peut-être utilisée par une autre machine qui, elle, est connectée directement à internet ; c est donc cette seconde machine qui recevra le paquet de réponse. Avec l impersonnalisation des paquets, notre firewall sait qui a envoyé le 24