Didacticiel sur Iptables, version 1.2.0


précédentsommairesuivant

XV. Iptables cibles et sauts

Target/jump indique à la règle que faire avec un paquet qui est parfaitement apparié avec la section correspondance de la règle. Il existe deux cibles de base, les cibles ACCEPT et DROP, que nous verrons en premier. Cependant, avant, jetons un bref regard sur la façon dont un saut est construit.

La spécification saut est faite exactement de la même façon que la définition cible, sauf qu'elle nécessite une chaîne dans la même table. Pour faire un saut vers une chaîne spécifique, il faut bien sûr que la chaîne existe. Comme nous l'avons déjà expliqué, une chaîne définie par l'utilisateur est créée avec la commande -N. Par exemple, nous créons une chaîne dans la table filtre appelée tcp_packets, comme ceci :

 
Sélectionnez
iptables -N tcp_packets

Nous pouvons alors lui ajouter une cible saut comme :

 
Sélectionnez
iptables -A INPUT -p tcp -j tcp_packets

Nous pourrons alors faire un saut depuis la chaîne INPUT vers la chaîne tcp_packets et commencer à traverser la chaîne. Quand nous atteignons la fin de cette chaîne, nous retournons vers la chaîne INPUT et le paquet démarre sa traversée de la règle une étape après qu'il ait fait le saut vers l'autre chaîne (tcp_packets dans ce cas). Si le paquet est ACCEPT dans une des sous-chaînes, elle sera ACCEPT dans la chaîne de sur-ensemble également et ne traversera plus aucune des chaînes de sur-ensemble. Cependant, notez que le paquet traversera toutes les autres chaînes des autres tables. Pour plus d'information sur la traversée des tables et des chaînes, voir le chapitre Traversée des tables et des chaînes.

D'un autre côté, les cibles spécifient une action a effectuer sur le paquet en question. Nous pouvons, par exemple, DROP ou ACCEPT selon ce que nous voulons faire. Il existe aussi plusieurs autres actions que nous pouvons effectuer, que nous décrirons plus tard dans cette section. Certaines cibles stopperont le paquet dans sa traversée des chaînes, comme décrit au-dessus. De bons exemples de ces règles sont DROP et ACCEPT. les règles qui sont stoppées, ne passeront plus à travers aucune règle suivante sur la chaîne ou sur une chaîne supérieure. D'autres cibles, peuvent avoir une action sur le paquet, lequel ensuite continuera à traverser les règles suivantes. Un bon exemple de ceci peuvent être les cibles LOG, ULOG et TOS. Ces cibles peuvent journaliser les paquets, les analyser et les passer à d'autres règles dans le même ensemble de chaînes. Nous pouvons, par exemple, de plus vouloir analyser les valeurs TTL et TOS d'un paquet/flux spécifique. Certaines cibles accepterons des options supplémentaires (quelle valeur TOS utiliser, etc.), tandis que d'autres n'en ont pas nécessairement besoin - mais peuvent en inclure si nous le souhaitons (journaliser les préfixes, masquer les ports, etc.). Nous essaierons de couvrir tous ces sujets quand nous verrons la description des cibles. Regardons de quelles sortes de cible il s'agit.

XV-A. Cible ACCEPT

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.

XV-B. Cible CLASSIFY

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

Option --set-class
Exemple iptables -t mangle -A POSTROUTING -p tcp --dport 80 -j CLASSIFY --set-class 20:10
Explication La cible CLASSIFY prend seulement un argument, le --set-class. Il indique à la cible comment classer le paquet. Ce classement prend deux valeurs séparées par le signe deux points (:), comme ceci MAJOR:MINOR. Encore une fois, si vous voulez plus d'information, regardez la page Linux Advanced Routing and Traffic Control HOW-TO.

XV-C. Cible DNAT

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

Option --to-destination
Exemple iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 --dport 80 -j DNAT --to-destination 192.168.1.1-192.168.1.10
Explication L'option --to-destination indique au mécanisme DNAT quelle Destination IP placer dans l'en-tête IP, et où sont envoyés les paquets qui sont appariés. L'exemple ci-dessus enverra sur tous les paquets destinés à l'adresse IP 15.45.23.67 dans une plage IP de réseau local comprise entre 192.168.1.1 jusqu'à 192.168.1.10. Notez que, comme décrit précédemment, un simple flux utilisera toujours le même hôte, et chaque flux aura une adresse IP attribuée au hasard, et qui sera toujours en direction de quelque part, dans ce flux. Nous pouvons aussi avoir à spécifier une seule adresse IP, dans ce cas nous serons toujours connectés au même hôte. Notez aussi que nous pouvons ajouter un port ou une plage de ports vers lequel le trafic sera redirigé. Ceci se fait en ajoutant, par exemple, un :80 à l'adresse IP pour laquelle nous voulons traduire les paquets. Une règle peut alors ressembler à --to-destination 192.168.1.1:80 par exemple, ou --to-destination 192.168.1.1:80-100 si nous voulons spécifier une plage de ports. Comme vous pouvez le voir, la syntaxe est à peu près la même que la cible SNAT, même si elles font deux choses totalement différentes. Les spécifications de port sont valides uniquement pour les règles qui précisent les protocoles TCP ou UDP avec l'option --protocol.

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 :

 
Sélectionnez
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 :

 
Sélectionnez
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 :

 
Sélectionnez
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.

XV-D. Cible DROP

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.

XV-E. Cible DSCP

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

Option --set-dscp
Exemple iptables -t mangle -A FORWARD -p tcp --dport 80 -j DSCP --set-dscp 1
Explication Ceci place la valeur DSCP à la valeur spécifiée. Les valeurs peuvent être placées soit par class, voir ci-dessous, soit avec le --set-dscp, qui prend une valeur entière ou une valeur hexadécimale.
Option --set-dscp-class
Exemple iptables -t mangle -A FORWARD -p tcp --dport 80 -j DSCP --set-dscp-class EF
Explication Place le champ DSCP selon une classe Diffserv prédéfinie. Certaines des valeurs possibles sont EF, BE et les valeurs CSxx et AFxx disponibles. Vous pouvez trouver plus d'information sur le site Implementing Quality of Service Policies with DSCP. Notez que les commandes --set-dscp-class et --set-dscp sont mutuellement exclusives, ce qui veut dire que vous ne pouvez pas les utiliser ensemble dans la même commande !

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

XV-F. Cible ECN

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

Option --ecn-tcp-remove
Exemple iptables -t mangle -A FORWARD -p tcp --dport 80 -j ECN --ecn-tcp-remove
Explication La cible ECN prend un seul argument, --ecn-tcp-remove. Ceci indique à la cible de supprimer les bits ECN des en-têtes TCP. Voir au-dessus pour plus d'information.

Fonctionne avec les noyaux Linux 2.5 et 2.6.

XV-G. Options de la cible LOG

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

Option --log-level
Exemple iptables -A FORWARD -p tcp -j LOG --log-level debug
Explication C'est l'option qui indique à iptables et syslog quel niveau de journalisation utiliser. Pour une liste complète des niveaux de journalisation lisez le manuel syslog.conf. Normalement il y a les niveaux de journalisation suivants, ou les priorités qui s'y réfèrent : debug, info, notice, warning, warn, err, error, crit, alert, emerg et panic. le mot-clé error est le même que err, warn est le même que warning et panic le même que emerg. Notez que tous les trois sont obsolètes, en d'autres termes n'utilisez pas error, warn et panic. La priorité définit le niveau de rigueur des messages journalisés. Tous les messages sont journalisés par les fonctionnalités du noyau. En d'autres termes, placer kern.=info /var/log/iptables dans votre fichier syslog.conf et ensuite laisser tous vos messages de LOG dans iptables utilise le niveau info, ce qui fera que tous vos messages apparaîtront dans le fichier /var/log/iptables. Notez qu'il peut y avoir d'autres messages provenant d'autres parties du noyau qui utilisent la priorité info. Pour plus d'information sur la journalisation, je vous recommande de lire les pages de manuel de syslog et syslog.conf comme les autres HOWTO, etc.
Option --log-prefix
Exemple iptables -A INPUT -p tcp -j LOG --log-prefix "INPUT packets"
Explication Cette option indique à iptables de préfixer tous les messages de journalisation avec un préfixe spécifique, qui peut être facilement combiné avec grep ou d'autres outils qui permettent de tracer ces problèmes et les sorties des différentes règles. Le préfixe peut avoir jusqu'à 29 lettres de long, incluant les espaces et autres symboles spéciaux.
Option --log-tcp-sequence
Exemple iptables -A INPUT -p tcp -j LOG --log-tcp-sequence
Explication Cette option journalisera les numéros des Séquences TCP, avec le message de journalisation. Les numéros de Séquences TCP sont des nombres spéciaux qui identifient chaque paquet et qu'ils ajustent dans une séquence TCP, et permettent de savoir comment le flux sera réassemblé. Notez que cette option constitue un risque de sécurité si les journaux sont lisibles par des utilisateurs non autorisés, ou par tout le monde.
Option --log-tcp-options
Exemple iptables -A FORWARD -p tcp -j LOG --log-tcp-options
Explication L'option --log-tcp-options journalise les différentes options des en-têtes des paquets TCP et peuvent être utiles lors du débogage. Cette option ne prend aucun champ de variable, comme beaucoup d'options LOG.
Option --log-ip-options
Exemple iptables -A FORWARD -p tcp -j LOG --log-ip-options
Explication L'option --log-ip-options journalisera la plupart des options des en-têtes de paquets IP. Elle fonctionne exactement comme l'option --log-tcp-options, mais sur les options IP. Ces messages de journalisation peuvent être utiles pour le débogage ou le traçage, comme dans l'option précédente.

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

XV-H. Cible MARK

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

Option --set-mark
Exemple iptables -t mangle -A PREROUTING -p tcp --dport 22 -j MARK --set-mark 2
Explication L'option --set-mark est nécessaire pour placer une marque. --set-mark prend une valeur entière. Par exemple, nous pouvons placer la marque à 2 sur un flux spécifique de paquets, ou sur tous les paquets provenant d'un hôte précis et ensuite faire du routage avancé sur cet hôte, pour augmenter ou diminuer la bande passante du réseau, etc.

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

XV-I. Cible MASQUERADE

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

Option --to-ports
Exemple iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE --to-ports 1024-31000
Explication L'option --to-ports est utilisée pour placer le port source ou des ports sur des paquets sortants. Soit vous pouvez spécifier un seul port comme --to-ports 1025 soit une plage de ports comme --to-ports 1024-3000. En d'autres termes, les délimitations des plages de ports la plus basse et la plus haute séparées par un tiret. Ceci modifie la sélection de port par défaut de SNAT comme décrit dans la section Cible SNAT. L'option --to-ports n'est valide que si la section de correspondance de la règle spécifie les protocoles TCP ou UDP avec la correspondance --protocol.

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

XV-J. Cible MIRROR

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 !

XV-K. Cible NETMAP

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

Option --to
Exemple iptables -t mangle -A PREROUTING -s 192.168.1.0/24 -j NETMAP --to 10.5.6.0/24
Explication C'est la seule option de la cible NETMAP. Dans l'exemple précédent, les hôtes 192.168.1.x seront directement traduits en 10.5.6.x

Fonctionne avec les noyaux Linux 2.5 et 2.6.

XV-L. Cible QUEUE

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.

XV-M. Cible REDIRECT

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

Option --to-ports
Exemple iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
Explication L'option --to-ports spécifie le port de destination, ou la plage de ports, à utiliser. Sans --to-ports, le port de destination n'est jamais modifié. Ceci est spécifié, comme au-dessus --to-ports 8080 dans les cas où nous voulons seulement préciser un seul port. Si nous voulons spécifier une plage de ports, nous écrirons --to-ports 8080-8090, qui indique à la cible REDIRECT de rediriger les paquets vers les ports 8080 jusqu'à 8090. Cette option n'est disponible que dans les règles spécifiant le protocole TCP ou UDP avec le module --protocol.

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

XV-N. Cible REJECT

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

Option --reject-with
Exemple iptables -A FORWARD -p TCP --dport 22 -j REJECT --reject-with tcp-reset
Explication Cette option indique à la cible REJECT quelle réponse envoyer à l'hôte qui a expédié le paquet qui a été rejeté. Quand nous sommes en présence d'un paquet qui apparie une règle dans laquelle nous avons spécifié cette cible, notre hôte envoie la réponse associée, et le paquet est ensuite supprimé, comme pour la cible DROP. Les types suivants de rejet sont valides : icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited et icmp-host-prohibited. Le message d'erreur par défaut expédie un port-unreachable à l'hôte. Tous sont des messages d'erreur ICMP et peuvent être paramétrés comme vous le voulez. Vous trouverez plus d'information dans l'annexe Types ICMP. Enfin, il existe une option supplémentaire appelée tcp-reset, qui peut être utilisée seulement avec le protocole TCP. L'option tcp-reset qui indique le REJECT envoie un paquet TCP RST en réponse à l'hôte expéditeur. Les paquets TCP RST sont utilisés pour clore les connexions TCP. Pour plus d'information sur TCP RST voir la RFC 793 - Transmission Control Protocol. Comme indiqué dans le manuel d'iptables, elle est principalement utilisée pour bloquer les sondeurs d'identité.

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

XV-O. Cible RETURN

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.

XV-P. Cible SAME

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

Option --to
Exemple iptables -t mangle -A PREROUTING -s 192.168.1.0/24 -j SAME --to 10.5.6.7-10.5.6.9
Explication Comme vous pouvez le voir, l'argument --to prend deux adresses IP liées ensemble par un -. Ces adresses IP, et toutes les autres entre, sont des adresses que nous NATons pour utiliser l'algorithme SAME.
Option --nodst
Exemple iptables -t mangle -A PREROUTING -s 192.168.1.0/24 -j SAME --to 10.5.6.7-10.5.6.9 --nodst
Explication Au cours d'une action normale, la cible SAME calcule le suivi de connexions basé sur les adresses IP source et destination. L'option --nodst, permet de n'utiliser que l'adresse IP source pour savoir de quelle IP la fonction NAT se sert pour la connexion spécifique. Sans cet argument, elle utilise une combinaison de l'adresse IP source et destination.

Fonctionne avec les noyaux Linux 2.5 et 2.6.

XV-Q. Cible SNAT

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

Option --to-source
Exemple iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to-source 194.236.50.155-194.236.50.160:1024-32000
Explication L'option --to-source est utilisée pour spécifier quelle source le paquet doit utiliser. Cette option, la plus simple, prend l'adresse IP que nous voulons utiliser pour adresse IP source dans l'en-tête IP. Si nous voulons faire ceci entre plusieurs adresses IP, nous pouvons utiliser une plage d'adresses, séparées par un tiret. Les numéros IP --to--source peuvent alors ressembler à notre exemple ci-dessus : 194.236.50.155-194.236.50.160. L'IP source pour chaque flux que nous ouvrons sera allouée aléatoirement, et un flux utilisera toujours la même adresse IP pour tous les paquets transitants dans ce flux. Nous pouvons aussi spécifier une plage de ports à utiliser par SNAT. Tous les ports source seront alors confinés aux ports spécifiés. Le bit de port de la règle ressemblera alors à notre exemple, :1024-32000. Ce n'est valide que si -p tcp ou -p udp sont spécifiés quelque part dans la correspondance de la règle en question. Iptables essaiera toujours d'éviter de modifier les ports si possible, mais si deux hôtes tentent d'utiliser les mêmes ports, Iptables redirigera un de ceux-là vers un autre port. Si aucune plage de ports n'est précisée, et si elles sont requises, tous les ports source au dessous de 512 seront redirigés vers d'autres ports en dessous de 512. Ceux entre les ports source 512 et 1023 seront redirigés en dessous de 1023. Tous les autres ports seront redirigés vers 1024 et au dessus. Comme établi précédemment, Iptables tentera toujours de conserver les ports source utilisés par la machine établissant la connexion. Notez que ceci n'a rien à voir avec les ports destination, si un client essaie de prendre contact avec un serveur HTTP en dehors du pare-feu, il ne sera pas redirigé vers le port FTP control.

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

XV-R. Cible TCPMSS

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

Option --set-mss
Exemple iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --set-mss 1460
Explication L'argument --set-mss place une valeur MSS spécifique pour tous les paquets sortants. Dans l'exemple ci-dessus, nous plaçons le MSS de tous les paquets SYN sortants sur l'interface eth0 à 1460 octets -- le MTU normal pour l'ethernet est de 1500 octets, moins 40 octets soit 1460 octets. MSS doit seulement être placé correctement dans le paquet SYN, ensuite les hôtes pairs s'occupent du MSS automatiquement.
Option --clamp-mss-to-pmtu
Exemple iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --clamp-mss-to-pmtu
Explication --clamp-mss-to-pmtu place automatiquement le MSS à la bonne valeur, et désormais vous n'aurez plus besoin de le disposer explicitement. Il est mis de façon automatique en PMTU (Path Maximum Transfer Unit) moins 40 octets, ce qui est une valeur raisonnable pour la plupart des applications.

Fonctionne avec les noyaux Linux 2.5 et 2.6.

XV-S. Cible TOS

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

Option --set-tos
Exemple iptables -t mangle -A PREROUTING -p TCP --dport 22 -j TOS --set-tos 0x10
Explication L'option --set-tos indique à l'analyseur TOS quelle valeur placer sur les paquets qui sont appariés. L'option prend une valeur numérique, soit en hexadécimal soit en décimal. Comme la valeur TOS consiste en 8 bits, la valeur peut être 0-255, ou en hexadécimal 0x00-0xFF. Notez que dans la cible TOS standard vous êtes limités à l'utilisation des valeurs nommées disponibles (qui sont plus ou moins standards), comme mentionné précédemment. Ces valeurs sont Minimize-Delay (valeur décimale 16, valeur hexadécimale 0x10), Maximize-Throughput (valeur décimale 8, valeur hexadécimale 0x08), Maximize-Reliability (valeur décimale 4, valeur hexadécimale 0x04), Minimize-Cost (valeur décimale 2, valeur hexadécimale 0x02), ou Normal-Service (valeur décimale 0, valeur hexadécimale 0x00). La valeur par défaut pour la plupart des paquets est Normal-Service, ou 0. Notez que vous pouvez, bien sûr, utiliser les noms au lieu des valeurs hexadécimales pour placer la valeur TOS; en fait, c'est généralement recommandé, car les valeurs associées avec les noms peuvent être changées par la suite. Pour une liste complète des "valeurs descriptives", tapez la commande : iptables -j TOS -h.

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

XV-T. Cible TTL

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

Option --ttl-set
Exemple iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 64
Explication L'option --ttl-set indique à la cible TTL quelle valeur placer sur le paquet en question. Une bonne valeur serait aux alentours de 64. Ce n'est ni trop long ni trop court. Ne placez pas cette valeur trop haut, car elle peut affecter votre réseau. Cette cible peut être utilisée pour limiter la distance de vos clients. Un bon exemple de ceci peuvent être les serveurs DNS, où nous ne voulons pas que les clients soient trop éloignés.
Option --ttl-dec
Exemple iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-dec 1
Explication L'option --ttl-dec indique à la cible TTL de décrémenter la valeur TTL d'un montant précis après le --ttl-dec. En d'autres termes, si le TTL d'un paquet entrant était de 53 et que nous avons ajouté --ttl-dec 4, le paquet quittera l'hôte avec une valeur de 49. La raison en est que le code réseau décrémentera automatiquement la valeur TTL par 1, donc le paquet sera décrémenté en 4 étapes, de 53 à 49. Ceci peut être utilisé quand nous voulons limiter l'éloignement de clients utilisant nos services. Exemple, les hôtes utilisent toujours un DNS proche, et donc nous pouvons apparier tous les paquets quittant notre serveur DNS et réduire la distance en plusieurs étapes. Bien sûr, le --set-ttl peut être une meilleure idée pour cet usage.
Option --ttl-inc
Exemple iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-inc 1
Explication L'option --ttl-inc indique à la cible TTL d'incrémenter la valeur Time To Live d'une valeur spécifiée avec --ttl-inc. Ceci indique que nous voulons augmenter le TTL avec une valeur spécifiée dans l'option --ttl-inc, et que si nous spécifions --ttl-inc 4, un paquet entrant avec un TTL de 52 quittera l'hôte avec un TTL de 56. Notez que la même chose dans l'exemple --ttl-dec s'applique ici, dans lequel le code réseau décrémentait automatiquement la valeur TTL par 1, ce qui est toujours le cas. Ceci peut être utilisé pour rendre notre pare-feu un peu plus furtif pour les traceroutes parmi d'autres choses. En mettant le TTL à une valeur plus haute pour tous les paquets entrants, nous rendons effectivement le pare-feu plus dissimulé pour les traceroutes. Les traceroutes sont des choses adorables et détestables, car elles fournissent d'excellentes informations sur les problèmes de connexion et indiquent à quel endroit ils se produisent, mais en même temps ils fournissent au hacker/cracker des informations dans le sens montant s'il nous a pris pour cible. Pour un bon exemple de son utilisation, voir le script Ttl-inc.txt.

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

XV-U. Cible ULOG

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

Option --ulog-nlgroup
Exemple iptables -A INPUT -p TCP --dport 22 -j ULOG --ulog-nlgroup 2
Explication L'option --ulog-nlgroup indique à la cible ULOG à quel groupe netlink envoyer les paquets. Il existe 32 groupes netlink, qui sont simplement spécifiés 1-32. Si nous voulons joindre le groupe netlink 5, nous écrirons simplement --ulog-nlgroup 5. Le groupe netlink par défaut est 1.
Option --ulog-prefix
Exemple iptables -A INPUT -p TCP --dport 22 -j ULOG --ulog-prefix "SSH connection attempt: "
Explication L'option --ulog-prefix fonctionne comme la valeur de préfixe de la cible LOG. Cette option préfixe toutes les entrées du journal avec un préfixe utilisateur. Il peut être de 32 caractères de longueur, et est le plus utilisé pour distinguer différents messages de journal et d'où ils proviennent.
Option --ulog-cprange
Exemple iptables -A INPUT -p TCP --dport 22 -j ULOG --ulog-cprange 100
Explication L'option --ulog-cprange indique à la cible ULOG combien d'octets du paquet envoyer au démon de l'espace utilisateur de ULOG. Si nous spécifions 100 ou plus, nous copierons 100 octets du paquet vers l'espace utilisateur, ce qui inclura l'en-tête complet en l'espérant, plus certaines données. Si nous spécifions 0, le paquet complet sera copié vers l'espace utilisateur, sans faire attention à la taille des paquets. La valeur par défaut est 0, ainsi l'ensemble du paquet sera copié vers l'espace utilisateur.
Option --ulog-qthreshold
Exemple iptables -A INPUT -p TCP --dport 22 -j ULOG --ulog-qthreshold 10
Explication Cette option --ulog-qthreshold indique à la cible ULOG combien de paquets seront en attente dans le noyau avant d'envoyer les données vers l'espace utilisateur. Par exemple, si nous indiquons un seuil de 10 ou plus, le noyau accumulera 10 paquets, et les transmettra ensuite à l'espace utilisateur comme un simple message netlink multiparties. La valeur par défaut ici est à 1 à cause de la compatibilité de l'affichage précédent, le démon de l'espace utilisateur ne connaissant pas le nombre de messages multiparties précédents.

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


précédentsommairesuivant

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

La permission est accordée de copier, distribuer et/ou modifier ce document selon les termes de la "GNU Free Ducomentation License", version 1.1; en précisant les sections "Introduction" et toutes les sous-sections, avec les en-têtes "Auteur: Oskar Andreasson".