Didacticiel sur Iptables, version 1.2.0

Cette cible ne nécessite pas d'autre option. Aussitôt que la spécification de correspondance pour un paquet a été pleinement satisfaite, et que nous spécifions ACCEPT comme cible, la règle est acceptée et ne traversera pas la chaîne ou aucune autre chaîne dans la même table. Notez cependant, qu'un paquet qui a été accepté dans une chaîne peut toujours circuler à travers les chaînes dans d'autres tables, et peut toujours être supprimé à cet endroit là. Il n'y a rien de spécial concernant cette cible, et il n'est pas nécessaire d'y ajouter des options. Pour utiliser cette cible, spécifiez simplement -j ACCEPT.

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

la cible CLASSIFY peut servir à classer les paquets de façon à ce qu'ils puissent être utilisés par deux ou plusieurs qdiscs (Queue Disciplines). Par exemple, atm, cbq, dsmark, pfifo_fast, htb. Pour plus d'information sur qdiscs et le contrôle de trafic, voir la page Linux Advanced Routing and Traffic Control HOW-TO.

La cible CLASSIFY est valide uniquement dans la chaîne POSTROUTING de la table mangle.

Tableau 1. Options de la cible CLASSIFY

La cible DNAT est utilisée pour la Traduction d'Adresse Réseau de Destination, ce qui veut dire qu'elle sert à réécrire l'adresse IP de Destination du paquet. Si un paquet est apparié, et qu'il est la cible de la règle, ce paquet et tous les paquets suivants du même flux seront traduits, et ensuite routés vers le matériel, l'hôte ou le réseau appropriés. Cette cible peut être extrêmement utile, par exemple, quand vous avez un hôte avec un serveur web dans un LAN, mais pas d'IP réelle routable sur l'Internet. Vous pouvez alors indiquer au pare-feu de transférer tous les paquets allant vers son propre port HTTP, vers le serveur web réel dans le LAN. Vous pouvez aussi spécifier une plage d'adresses IP de destination, et le mécanisme DNAT choisira l'adresse IP de destination au hasard pour chaque flux. Nous pourrons donc réaliser une sorte d'équilibrage de charge en faisant ça.

Notez que la cible DNAT est disponible uniquement dans les chaînes PREROUTING et OUTPUT de la table nat. Les chaînes contenant des cibles DNAT ne peuvent pas être utilisées depuis d'autres chaînes, comme la chaîne POSTROUTING.

Tableau 2. Cible DNAT

Comme DNAT nécessite pas mal de travail pour fonctionner correctement, j'ai décidé d'ajouter une explication plus complète sur ce sujet. Prenons un bref exemple pour comprendre comment les choses se passent normalement. Nous voulons publier notre site web via notre connexion Internet. Nous ne possédons qu'une seule adresse IP, et le serveur HTTP est situé dans notre réseau interne. Notre pare-feu possède l'adresse IP externe $INET_IP, et notre serveur HTTP a l'adresse IP interne $HTTP_IP et enfin le pare-feu a l'adresse IP interne $LAN_IP. La première chose à faire est d'ajouter la simple règle suivante à la chaîne PREROUTING dans la table nat :

iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP

Maintenant, tous les paquets provenant de l'Internet et allant vers le port 80 sur notre pare-feu, sont redirigés (ou DNATés) vers notre serveur HTTP interne. Si vous testez ceci depuis L'Internet, tout devrait fonctionner parfaitement. mais, que se passe-t-il si vous essayez de vous connecter depuis un hôte sur le même réseau local que le serveur HTTP ? Il ne fonctionnera tout simplement pas. C'est un réel problème avec le routage. Commençons par voir ce qui se passe dans un cas normal. La machine externe possède une adresse IP $EXT_BOX, pour conserver la lisibilité.

1. Le paquet quitte l'hôte connecté allant vers $INET_IP et la source $EXT_BOX.
2. Le paquet atteint le pare-feu.
3. Le pare-feu DNAT le paquet et envoit celui-ci à travers les différentes chaînes, etc.
4. Le paquet quitte la pare-feu pour aller vers le $HTTP_IP.
5. Le paquet atteint le serveur HTTP, et la machine HTTP répond en retour à travers le pare-feu, si c'est cette machine que la base de routage a entré comme passerelle pour $EXT_BOX. Normalement, ça devrait être la passerelle par défaut du serveur HTTP.
6. Le pare-feu Un-DNAT le paquet de nouveau, ainsi le paquet semble provenir du pare-feu lui-même.
7. Le paquet en réponse transite vers le client $EXT_BOX.

Maintenant, voyons ce qui se passe si le paquet est généré par un client sur le même réseau que le serveur HTTP lui-même. Le client possède l'adresse IP $LAN_BOX, tandis que les autres machines ont les mêmes réglages.

1. Le paquet quitte la $LAN_BOX vers $INET_IP.
2. Le paquet atteint le pare-feu.
3. Le paquet est DNATé, et toutes les autres actions requises sont prises, cependant, le paquet n'est pas SNATé, ainsi la même adresse source IP est utilisée pour le paquet.
4. le paquet quitte le pare-feu et atteint le serveur HTTP.
5. Le serveur HTTP essaie de répondre au paquet, et voit dans les tables de routage que le paquet provient d'une machine locale sur le même réseau, et donc tente d'envoyer le paquet directement à l'adresse source IP d'origine (qui devient alors l'adresse IP de destination).
6. Le paquet atteint le client, et le client est dans la confusion car le paquet en retour ne provient pas de l'hôte qui a envoyé la requête d'origine. Donc, le client supprime le paquet, et attend une réponse "réelle".

La solution la plus simple à ce problème est de SNATer tous les paquets entrant dans le pare-feu sortant vers un hôte ou une IP sur lequel nous faisons du DNAT. Exemple, regardons la règle ci-dessus. Nous SNATons les paquets entrants dans notre pare-feu qui sont destinés à $HTTP_IP port 80 et ainsi il est vu que des paquets proviennent d'une $LAN_IP. Ceci force le serveur HTTP à envoyer ces paquets vers notre pare-feu, lequel Un-DNAT ceux-ci et les envoit au client. La règle ressemble à ceci :

iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IP

Souvenez vous que la chaîne POSTROUTING est exécutée en dernier, et donc le paquet sera déjà DNATé une fois qu'il joint cette chaîne spécifique. C'est la raison pour laquelle nous apparions les paquets basés sur une adresse interne.

Cette dernière règle nuira sérieusement à votre journalisation, ainsi il n'est pas recommandé d'utiliser cette méthode, mais l'ensemble de l'exemple est valide. Que se passe-t-il alors, le paquet provient de l'Internet, est SNATé et DNATé et finalement atteint le serveur HTTP (par exemple). Le serveur HTTP voit maintenant les requêtes comme si elles provenaient du pare-feu, et donc les journalisera toutes comme telles.

Ceci peut avoir également d'autres implications plus graves. Prenons un serveur SMTP sur un LAN, qui autorise les requêtes depuis le réseau interne, et vous avez un pare-feu paramétré pour transférer le trafic SMTP vers ce serveur. Vous avez donc créé un serveur SMTP en relais ouvert, avec une journalisation horrible !

Une solution à ce problème est de tout simplement rendre la règle ci-dessus plus précise dans sa partie appariement, et de travailler seulement sur les paquets qui proviennent du LAN. En d'autres termes, ajoutez un -i $LAN_IFACE à l'ensemble de la commande. Ceci fera que la règle ne fonctionnera que sur les flux provenant du LAN, et donc n'affectera pas la source IP, ainsi les journaux seront corrects, sauf pour les flux venant du LAN.

Vous auriez mieux fait, en d'autres termes, de résoudre ces problèmes soit en paramétrant un serveur DNS (serveur de nom) séparé pour votre LAN, soit en paramétrant une DMZ séparée, la dernière étant préférable si vous avez les moyens.

Vous pouvez penser que c'est suffisant, et c'est vrai, sauf à considérer un dernier aspect du scénario. Que se passe-t-il si le pare-feu lui-même essaie d'accéder au serveur HTTP, où va-t-il ? Il tentera malheureusement d'accéder à son propre serveur HTTP, et pas au serveur situé sur $HTTP_IP. Pour parer à ça, nous devons rajouter une règle DNAT à la chaîne OUTPUT. Suivant l'exemple ci-dessus, ça ressemblerait à quelque chose comme :

iptables -t nat -A OUTPUT --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP

Tous les réseaux séparés qui ne sont pas situés sur le même réseau que le serveur HTTP fonctionneront sans soucis, tous les hôtes sur le même réseau que le serveur HTTP pourront s'y connecter et enfin, le pare-feu pourra exécuter ses connexions correctement. Maintenant, tout fonctionne et aucun problème ne devrait arriver.

Tout le monde devrait réaliser que ces règles affectent seulement la façon dont le paquet est DNATé et SNATé. En plus de ces règles, nous avons aussi besoin de règles supplémentaires dans la table filtre (chaîne FORWARD) pour permettre aux paquets de traverser ces chaînes. N'oubliez pas que tous les paquets sont déjà passés par la chaîne PREROUTING, et donc ont vu leur adresse de destination réécrite par DNAT.

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

La cible DROP fait exactement ce qu'elle veut dire, elle efface des paquets et n'effectue aucun autre processus supplémentaire. Un paquet qui apparie parfaitement un règle et est ensuite effacé sera bloqué. Notez que cette action peut avoir, dans certains cas, des effets inattendus, car elle peut laisser des interfaces de connexions mortes sur quelque hôte. Une meilleure solution dans ces cas là serait d'utiliser la cible REJECT, spécialement quand vous voulez bloquer le balayage (scan) de ports pour ne pas donner trop d'informations, ou le filtrage de ports, etc. Notez également que si le paquet subit l'action DROP dans une sous-chaîne, ce paquet ne sera traité dans aucune des chaînes principales, soit dans la table présente ou dans une quelconque autre table. Le paquet est, en d'autres termes, totalement mort. Comme nous l'avons vu précédemment, la cible n'enverra aucune autre sorte d'information dans aucune direction, ni par des intermédiaires comme les routeurs.

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

C'est une cible qui modifie les repères DSCP (Differentiated Services Field) dans un paquet. La cible DSCP peut placer n'importe quelle valeur DSCP dans un paquet TCP, ce qui est un moyen d'indiquer aux routeurs la priorité du paquet en question. Pour plus d'information sur DSCP, voyez la RFC RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.

De façon basique, DSCP est un moyen de différencier divers services de catégories séparées, et leur donner différentes priorités à travers les routeurs. De cette façon, vous pouvez donner à des sessions TCP interactives (comme telnet, SSH, POP3) une très grande vitesse de connexion, ceux-ci pouvant ne pas être très appropriés pour des tranferts importants. Si la connexion est de plus faible importance (SMTP, ou ce que vous voulez classer en basse priorité), vous pouvez employer un temps de latence plus important, ce qui est meilleur marché que d'utiliser des connexions en haute ou basse latence.

Tableau 3. Options de la cible DSCP

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

Cette cible peut être extraordinaire, utilisée correctement. Simplement placée, la cible ECN peut être utilisée pour réinitialiser les bits ECN depuis l'en-tête IPv4, ou les réinitialiser à 0 au moins. ECN est une chose relativement nouvelle sur le net, et il y a quelques problèmes avec elle. Par exemple, elle utilise 2 bits définis dans la RFC originale du protocole TCP comme devant être à 0. Certains routeurs et autres serveurs Internet ne transfèrent pas les paquets dont les bits sont placés à 1. Si vous voulez faire usage d'une partie au moins des fonctionnalités de ECN depuis vos hôtes, vous pourrez par exemple réinitialiser les bits ECN à 0 pour les réseaux spécifiques dont nous savons qu'il y a des problèmes de connexion à cause de ECN.

Notez qu'il n'est pas possible d'activer ECN au milieu d'un flux. Ce n'est pas autorisé selon la RFC, et ne sera possible en aucune façon. Les deux points limite d'un flux doivent négocier l'ECN. Si nous l'activons, un des hôtes n'est pas informé de cela, et ne peux répondre proprement aux notifications ECN.

Tableau 4. Options de la cible ECN

Fonctionne avec les noyaux Linux 2.5 et 2.6.

La cible LOG est spécialement destinée à journaliser des informations détaillées sur les paquets. Ceci peut, par exemple, être considéré comme illégal. Ou la journalisation peut servir à la recherche de bogues et d'erreurs. La cible LOG renverra une information spécifique sur les paquets, comme les en-têtes IP et autre détails considérés comme intéressants. Ceci se réalise par les fonctionnalités de journalisation du noyau, normalement syslogd. Cette information peut alors être lue directement avec la commande dmesg, ou depuis les journaux syslogd, ou avec d'autres programmes ou applications. C'est une excellente cible utilisée comme débogage des tables de règles, ainsi vous pouvez voir où vont les paquets et comment les règles sont appliquées et sur quels paquets. Notez que ce peut être une très bonne idée d'utiliser la cible LOG au lieu de la cible DROP lorsque vous testez une règle dont vous n'êtes pas sûrs à 100% de son efficacité dans un pare-feu en production, car une erreur de syntaxe dans la table de règles pourrait causer de sévères problèmes de connectivité entre vos utilisateurs. Notez aussi que la cible ULOG peut être intéressante si vous utilisez réellement une journalisation extensive, car ULOG supporte directement la journalisation dans les bases de données MySQL et d'autres.

Notez que si vous obtenez une sortie de journalisation directement vers les consoles, ce n'est pas un problème de iptables ou Netfilter, mais plutôt un problème causé par votre configuration de syslogd - probablement /etc/syslog.conf. Pour en savoir plus man syslog.conf.

Vous pourriez aussi désirer revoir les paramétrages de dmesg. dmesg est la commande qui permet de voir sur une console les erreurs envoyées par le noyau. dmesg -n 1 enverra tous les messages sur la console, sauf les messages de panique. Les niveaux de message de dmesg apparient exactement les niveaux de syslogd, et fonctionnent seulement sur les messages de journalisation depuis les fonctionnalités du noyau. Pour plus d'information voir man dmesg.

La cible LOG prend actuellement cinq options qui peuvent être intéressantes si vous recherchez une information précise, ou désirez placer différentes options pour certaines valeurs. Elles sont présentées ci-dessous.

Tableau 5. Options de la cible LOG

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

La cible MARK sert à placer les valeurs de marquage Netfilter qui sont associées à des paquets spécifiques. Cette cible n'est valide que dans la table mangle, et ne fonctionne pas en dehors de celle-ci. Les valeurs MARK peuvent être utilisées conjointement avec les possibilités de routage avancé de Linux pour envoyer différents paquets à travers différentes routes et indiquer d'utiliser différentes disciplines de files d'attente (qdisc), etc. Pour plus d'information sur le routage avancé, voyez le Linux Advanced Routing and Traffic Control HOW-TO. Notez que la valeur de marquage n'est pas incluse dans le paquetage actuel, mais est associée au paquet dans le noyau. En d'autres termes, vous ne pouvez pas placer une MARK pour un paquet et ensuite espérer que la MARK sera toujours présente sur un autre hôte. Si c'est ce que vous voulez, vous feriez mieux d'utiliser la cible TOS qui analysera la valeur TOS dans l'en-tête IP.

Tableau 6. Options de la cible MARK

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

La cible MASQUERADE est utilisée (de façon basique) comme la cible SNAT, mais ne nécessite aucune option --to-source. La raison de ceci est que la cible MASQUERADE a été créée pour fonctionner avec, par exemple, des connexions en dial-up (accès par ligne commutée), ou en DHCP, qui récupèrent des adresses IP dynamiques lors de la connexion au réseau. Ceci veut dire que vous n'utiliserez la cible MASQUERADE qu'avec des connexions fournissant des adresses IP dynamiques. Si vous avez une adresse IP statique, vous utiliserez dans ce cas la cible SNAT.

Quand vous masquez une connexion, ça indique que vous placez l'adresse IP utilisée sur une interface réseau spécifique au lieu de l'option --to-source, et l'adresse IP est automatiquement récupérée depuis cette interface spécifique. La cible MASQUERADE a également pour effet que les connexions sont abandonnées quand une interface est coupée, ce qui est extrêmement intéressant si nous coupons une interface spécifique. Ceci est, en général, le comportement correct avec les lignes en dial-up qui ont sans doute des IP assignées à chaque connexion. Lorsque une IP différente est attribuée, la connexion est perdue, et il est idiot d'en conserver les entrées.

Il est toujours possible d'utiliser la cible MASQUERADE au lieu de SNAT même si vous avez une IP statique, cependant, ce n'est pas très intéressant car ça ajoute un surdébit, et peut aller à l'encontre de vos scripts et les rendre "inutilisables".

Notez que la cible MASQUERADE n'est valide que dans la chaîne POSTROUTING de la table nat, comme la cible SNAT. MASQUERADE ne prend qu'une option spécifiée ci-dessous, et qui est optionnelle.

Tableau 7. Cible MASQUERADE

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

Attention, MIRROR est dangereux et n'a été développé que comme exemple de code pour le nouveau conntrack et NAT. Elle peut provoquer des failles dangereuses, et de très sérieux DDoS/DoS sont possibles si elle est utilisée improprement. Évitez de l'utiliser dans tous les cas ! Elle a été supprimée dans les noyaux 2.5 et 2.6 à cause de ses implications dans la sécurité.

La cible MIRROR est expérimentale, et vous êtes prévenus qu'il peut en résulter de sérieux problèmes de Denial of Service. MIRROR est utilisée pour inverser les champs source et destination dans l'en-tête IP, avant de retransmettre le paquet. Ceci peut causer quelques effets comiques, un cracker a cracké sa propre machine en l'utilisant. Plaçons une cible MIRROR sur le port 80 d'un ordinateur A. Si l'hôte B vient de yahoo.com, et essaie d'accéder au serveur HTTP de A, le cible MIRROR renverra l'hôte yahoo à sa propre page web (car c'est de là que vient la requête).

Notez que la cible MIRROR n'est valide que dans les chaînes INPUT, FORWARD et PREROUTING, et les chaînes définies par l'utilisateur. Notez aussi que les paquets sortants sont le résultat de la cible MIRROR et ne sont vus par aucune des chaînes normales du filtre, les tables nat ou mangle, qui peuvent provoquer des boucles et autres problèmes. Ceci peut faire que la cible soit la cause de maux de têtes inattendus. Par exemple, un hôte peut envoyer un paquet de mystification vers un autre hôte qui utilise la commande MIRROR avec un TTL de 255, en même temps il mystifie son propre paquet, comme s'il semblait qu'il venait d'un troisième hôte utilisant cette commande MIRROR. Le paquet sera alors renvoyé sans arrêt, pour le nombre de sauts nécessaires pour qu'il soit complété. S'il n'y a qu'un seul saut, le paquet reviendra 240-255 fois. C'est intéressant pour un cracker, en d'autres termes, envoyer 1500 octets de données consomme 380 ko de votre connexion. Notez que ceci est le meilleur scenario pour un cracker.

Fonctionne avec les noyaux Linux 2.3 et 2.4. A été supprimé dans les noyaux 2.5 et 2.6 à cause de problèmes de sécurité. N'utilisez pas cette cible !

NETMAP est une implémentation nouvelle des cibles SNAT et DNAT où la partie hôte de l'adresse IP n'est pas changée. Elle procure une fonction NAT 1:1 pour l'ensemble des réseaux qui n'ont pas de fonctions SNAT et DNAT standards. Par exemple, nous avons un réseau de 254 hôtes utilisant des adresses IP privées (un réseau /24), et nous avons un nouveau réseau /24 d'adresses IP publiques. Au lieu de changer les IP de chacun des hôtes, il sera plus simple d'utiliser la cible NETMAP comme -j NETMAP -to 10.5.6.0/24, tous les hôtes seront vus comme 10.5.6.x quand ils quitteront le pare-feu. Exemple, 192.168.0.26 deviendra 10.5.6.26.

Tableau 8. Options de la cible NETMAP

Fonctionne avec les noyaux Linux 2.5 et 2.6.

La cible QUEUE sert à mettre les paquets en attente pour les programmes et applications du domaine utilisateur. Elle est utilisée conjointement avec des programmes ou des utilitaires étrangers à Iptables et qui peuvent être utilisés, par exemple, pour des réseaux comptables, ou pour des applications avancées et spécifiques qui filtrent ou mettent en cache les paquets. Nous ne parlerons pas de cette cible en détail, car le codage de certaines applications est hors de sujet de ce didacticiel. En premier, ça nous prendrait trop de temps, ensuite cette documentation n'a pas grand chose à faire avec l'aspect programmation de Netfilter et Iptables. Voir le Netfilter Hacking HOW-TO.

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

La cible REDIRECT est utilisée pour rediriger les paquets et les flux vers la machine elle-même. Ceci veut dire que nous pouvons, par exemple REDIRECT tous les paquets destinés aux ports HTTP vers un proxy HTTP comme Squid, sur notre propre machine. Les paquets générés localement sont mappés vers les adresses 127.0.0.1. En d'autres termes, elle réécrit les adresses de destination vers votre propre machine pour les paquets qui sont transmis, ou quelque chose comme ça. La cible REDIRECT est très utile quand vous voulez, par exemple, faire du proxy transparent, où l'hôte du LAN n'a pas connaissance du proxy.

Notez que la cible REDIRECT est uniquement valide dans les chaînes PREROUTING et OUTPUT de la table nat. Elle est aussi valide dans les chaînes définies par l'utilisateur. REDIRECT ne prend qu'une option, comme décrit ci-dessous.

Tableau 9. Cible REDIRECT

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

La cible REJECT fonctionne à la base comme la cible DROP, mais elle renvoit un message d'erreur à l'hôte qui a envoyé le paquet. REJECT n'est valide que dans les chaînes INPUT, FORWARD et OUTPUT ou leurs sous-chaînes. Après tout, ce sont les seules chaînes dans lesquelles il soit sensé de placer cette cible. Notez que toutes les chaînes qui utilisent REJECT ne peuvent être invoquées que par INPUT, FORWARD, et OUTPUT, sinon elles ne fonctionnent pas. Il n'y a qu'une option qui contrôle le fonctionnement de cette cible.

Tableau 10. Cible REJECT

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

La cible RETURN stoppe un paquet traversant la chaîne dans laquelle la règle est placée. Si c'est une sous-chaîne d'une autre chaîne, le paquet continuera sa route vers les chaînes supérieures comme si rien ne s'était passé. Si cette chaîne est la chaîne principale, par exemple la chaîne INPUT, le paquet aura le comportement par défaut. Ce comportement par défaut est normalement ACCEPT, DROP ou similaire.

Exemple, un paquet entre dans la chaîne INPUT et rencontre une règle qui l'apparie et indique --jump EXAMPLE_CHAIN. Ce paquet traversera alors EXAMPLE_CHAIN, et soudain il rencontre une règle qui a la cible --jump RETURN. Il retournera alors vers la chaîne INPUT. Un autre exemple, si le paquet rencontrera une règle --jump RETURN dans la chaîne INPUT. Il sera alors droppé selon le comportement par défaut décrit plus haut, et plus aucune action sera faite dans cette chaîne.

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

La cible SAME fonctionne à peu près comme SNAT, mais diffère légèrement. À la base, SAME tentera d'utiliser la même adresse IP en sortie pour toutes les connexions initiées par un hôte sur le réseau. Par exemple, vous avez un réseau en /24 (192.168.1.0) et 3 adresses IP (10.5.6.7-9). Maintenant, si 192.168.1.20 sort de l'adresse .7 une première fois, le pare-feu tentera de conserver à cette machine toujours la même adresse IP.

Tableau 11. Optiond de la cible SAME

Fonctionne avec les noyaux Linux 2.5 et 2.6.

La cible SNAT est utilisée pour la Traduction d'Adresse Réseau Source, ce qui veut dire que cette cible réécrira l'adresse IP source dans l'en-tête IP du paquet. Exemple, quand plusieurs hôtes doivent partager une connexion Internet. Nous pouvons alors activer le transfert d'IP (IP Forwarding) dans le noyau, et écrire une règle SNAT qui traduira tous les paquets sortants du réseau local vers l'IP source de notre connexion Internet. Sans cela, le monde extérieur ne saurait pas où envoyer les paquets en réponse, car les réseaux locaux utilisent la plupart du temps des adresses IP spécifiées par le IANA et qui sont allouées aux LAN. Si nous transférons les paquets tels quels, personne sur l'Internet ne saura qu'ils proviennent de nous. La cible SNAT fait toutes les traductions nécessaires pour réaliser ce genre de chose, permettant à tous les paquets quittant notre LAN d'être vus comme provenant d'un hôte unique, qui pourrait être notre pare-feu.

SNAT n'est valide que dans la table nat, à l'intérieur de la chaîne POSTROUTING. C'est, en d'autres termes, la seule chaîne dans laquelle vous pouvez utiliser SNAT. Seul le premier paquet d'une connexion est analysé par SNAT, et ensuite tous les paquets utilisant la même connexion seront également SNATés. De plus, les règles initiales de la chaîne POSTROUTING seront appliquées à tous les paquets du même flux.

Tableau 12. Options de la cible SNAT

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

La cible TCPMSS peut être utilisée pour modifier la valeur MSS (Maximum Segment Size) des paquets TCP SYN que le pare-feu examine. La valeur MSS sert à contrôler la taille maximum des paquets d'une connexion spécifique. Dans des circonstances normales, ceci indique la taille de la valeur MTU (Maximum Transfert Unit), moins 40 octets. Elle est utilisée pour éviter que certains fournisseurs d'accès ou serveurs bloquent la fragmentation ICMP des paquets, ce qui peut provoquer des problèmes mystérieux, qui peuvent être décrits principalement par le fait que tout fonctionne parfaitement au niveau de notre routeur/pare-feu, mais que nos hôtes locaux derrière le pare-feu ne peuvent échanger des paquets importants. Ceci peut se traduire par certaines choses comme des serveurs de courrier capables d'envoyer des petits mails, mais pas des gros, des navigateurs web qui se connectent mais ensuite se figent en ne recevant aucune donnée, une connexion ssh propre, mais dont le scp est suspendu après l'établissement de la liaison. Autrement dit, tout ce qui utilise des paquets importants sera incapable de fonctionner.

La cible TCPMSS est capable de résoudre ces problèmes, en changeant la taille des paquets sortants d'une connexion. Notez que nous avons uniquement besoin de placer le MSS sur le paquet SYN, les hôtes s'occupant du MSS après ça. La cible prend deux arguments.

Tableau 13. Options de la cible TCPMSS

Fonctionne avec les noyaux Linux 2.5 et 2.6.

La cible TOS sert à disposer le champ Type de Service dans une en-tête IP. Le champ TOS consiste en 8 bits utilisés pour aider au routage de paquets. C'est un des champs qui peut être utilisé directement dans iproute2 et son sous-système pour les stratégies de routage. Notez de plus, que si vous maintenez plusieurs pare-feux et routeurs séparés, c'est le seul moyen pour propager les informations de routage dans les paquets entre ces routeurs et pare-feux. Comme noté précédemment, la cible MARK - laquelle dispose un MARK associé à un paquet spécifique - est disponible seulement dans le noyau, et ne peut pas être propagée avec le paquet. Si vous avez besoin de propager des informations de routage pour un paquet spécifique ou un flux, vous devrez donc placer le champ TOS, qui a été créé pour ça.

Il existe un grand nombre de routeurs sur Internet qui font du mauvais travail à ce sujet, ce qui fait qu'il peut être moins utile maintenant d'essayer de faire de l'analyse TOS avant d'envoyer les paquets sur Internet. Dans le meilleur des cas les routeurs ne font pas attention au champ TOS. Dans le pire, ils examineront le champ TOS et feront de mauvaises choses. Cependant, le champ TOS peut être placé avec une grande utilité si vous avez un grand WAN ou LAN avec de multiples routeurs. Vous avez la possibilité de donner aux paquets différentes routes et préférences, basées sur leur valeur TOS.

La cible TOS ne place que des valeurs spécifiques, ou valeurs nommées sur des paquets. Ces valeurs prédéfinies peuvent être trouvées dans les fichiers include du noyau, ou plus précisément le fichier Linux/ip.h. Les raisons sont multiples, et vous n'aurez actuellement besoin de placer aucune autre valeur; cependant, il existe d'autres moyens par rapport à cette limitation. Pour contourner cette limitation de ne pouvoir placer que des valeurs nommées sur les paquets, vous pouvez utiliser le patch FTOS disponible sur le site Paksecured Linux Kernel patches maintenu par Matthew G. Marsh. Attention, soyez prudents avec ce patch ! Vous ne devriez pas avoir besoin d'autre chose que les valeurs par défaut, sauf dans des cas extrêmes.

Cette cible n'est valide que dans la table mangle et ne peut être utilisée hors de celle-ci.

Notez aussi que certaines anciennes versions (1.2.2 ou avant) d'Iptables fournissaient une implémentation de cette cible qui ne fixait pas la somme de contrôle dans l'analyse, ce qui corrompait les paquets et provoquait des connexions qui n'aboutissaient pas.

TOS ne prend qu'une option décrite ci-dessous.

Tableau 14. Cible TOS

Fonctionne avec les noyaux 2.3, 2.4, 2.5 et 2.6.

Ce patch nécessite le TTL du patch-o-matic disponible dans le répertoire de http://www.netfilter.org/.

La cible TTL modifie le champ Durée de Vie (Time To Live) dans l'en-tête IP. Une application très utile de ceci est de pouvoir changer toutes les valeurs de durée de vie en une valeur identique pour tous les paquets sortants. Une raison de faire ça peut être que, vous avez un fournisseur d'accès un peu rigide qui ne vous permet pas d'avoir plus d'une machine connectée à la même connexion Internet. En mettant toutes les valeurs TTL à la même valeur, il sera plus difficile pour lui de voir ce que vous faites. Nous pouvons alors réinitialiser la valeur TTL de tous les paquets sortants à une valeur standard, comme 64 ainsi que spécifié dans le noyau Linux.

Pour plus d'information pour savoir comment placer la valeur par défaut utilisée dans Linux, lisez le ip-sysctl.txt, que vous pouvez trouver dans l'annexe Autres ressources et liens.

La cible TTL n'est valide que dans la table mangle, et nulle part ailleurs. Elle prend trois options, décrites ci-dessous.

Tableau 15. Cible TTL

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.

La cible ULOG sert à la journalisation des paquets appariés de l'espace utilisateur. Si un paquet est apparié et la cible ULOG placée, l'information du paquet est multidiffusée avec le paquet complet à travers une interface de connexion réseau. Un ou plusieurs processus espace utilisateur peuvent souscrire aux divers groupes de multidiffusion et recevoir le paquet. C'est une possibilité de journalisation plus complète et plus sophistiquée qui est utilisée par Iptables et Netfilter. Cette cible nous permet de journaliser l'information dans des bases de données MySQL, ou autres bases, rendant plus simple la recherche de paquets spécifiques, et groupant les entrées de journal. Vous pouvez trouver les applications domaine utilisateur ULOGD à ULOGD project page.

Tableau 16. Cible ULOG

Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.