12. iptables cibles et sauts▲
Target/jump indique à la règle que faire avec un paquet qui est sélectionné 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 filter appelée tcp_packets, comme ceci :
iptables -N tcp_packetsNous pouvons alors lui ajouter une cible saut comme :
iptables -A INPUT -p tcp -j tcp_packetsNous 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 a 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'informations sur la traversée des tables et des chaînes, voir le chapitre Traversée des tables et des chaînesTraversée des tables et des chaînes.
D'un autre côté, les cibles spécifient une action à 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, nous les 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. De bons exemples 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, vouloir analyser les valeurs TTL et TOS d'un paquet/flux spécifique. Certaines cibles accepteront 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. Voyons de quelles sortes de cibles il s'agit.
12-1. 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.
12-2. 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'informations 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 11.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'informations, regardez la page Linux Advanced Routing and Traffic Control HOW-TO. |
Fonctionne avec les noyaux Linux 2.5 et 2.6.
12-3. Cible CLUSTERIP▲
La cible CLUSTERIP est utilisée pour créer des clusters (grappes de serveurs) de nœuds répondant à la même adresse IP et MAC. C'est une forme simple de clustering où vous pouvez placer une IP virtuelle (VIP) sur tous les hôtes participant au cluster, et ensuite utiliser le CLUSTERIP sur chaque hôte qui est supposé répondre aux requêtes. La correspondance CLUSTERIP ne nécessite aucun matériel ou machine d'équilibrage de charge, il fait simplement son travail sur chaque partie hôte du cluster de machines. C'est une solution de clustering très simple et non prévue pour des clusters complexes et importants, elle ne possède pas de gestion de détection de collision native, mais peut être implémentée comme un simple script.
Tous les serveurs du cluster utilisent une Multicast MAC commune pour une VIP, et un algorithme spécial est utilisé dans la cible CLUSTERIP pour savoir quels participants au cluster répondront à chaque connexion. Une Multicast MAC est une adresse MAC (adresse matérielle) démarrant avec 01:00:5e. Un exemple d'adresse MAC serait 01:00:5e:00:00:20. La VIP peut être n'importe quelle adresse IP, mais doit être la même sur tous les hôtes.
Souvenez-vous que CLUSTERIP peut interrompre des protocoles comme SSH, etc. La connexion s'acheminera proprement, mais si vous essayez en même temps sur le même hôte, vous pourrez être connecté sur une autre machine du cluster, avec un jeu de clés différent, et votre client ssh peut refuser de se connecter ou afficher des erreurs. Pour cette raison, ça ne fonctionne pas très bien avec certains protocoles, et ce peut être une bonne idée d'ajouter des adresses séparées qui peuvent être utilisées pour la maintenance et l'administration. Une autre solution est d'utiliser les mêmes clés SSH sur tous les hôtes du cluster.
Le cluster peut être en équilibrage de charge avec trois sortes d'empreintes numériques. La première est seulement l'IP source (sourceip), la seconde est la source IP et le port (sourceip-sourceport) et la troisième la source IP le port source et le port destination (sourceip-sourceport-destport). La première est très utile si vous avez besoin de conserver les états entre connexions, par exemple un serveur web avec un panier d'achats virtuel peut conserver les états entre connexions, cet équilibrage de charge peut devenir un peu brouillon -- différentes machines peuvent avoir une charge plus haute que d'autres, etc. --, car les connexions depuis la même IP source iront vers le même serveur. L'empreinte numérique sourceip-sourceport est utile si vous voulez obtenir un équilibrage de charge un peu plus uniforme, et où les états n'ont pas à être conservés sur chaque serveur entre les connexions. Par exemple, une grosse page web de documentation avec peut-être un simple moteur de recherche semble une bonne idée dans ce cas. La troisième empreinte numérique, sourceip-sourceport-destport, peut vous rendre des services si vous avez un hôte sur lequel tournent plusieurs services qui ne nécessitent pas que les états soient préservés entre les connexions. Ce peut être par exemple un simple ntp, dns et serveur web sur le même hôte. Chaque connexion vers chaque nouvelle destination devra être « renégociée » -- actuellement il n'y a pas de négociation, chaque hôte reçoit une connexion.
Chaque cluster CLUSTERIP possède un fichier séparé dans le répertoire /proc/net/ipt_CLUSTERIP, basé sur la VIP du cluster. Si la VIP est 192.168.0.5 par exemple, faire un cat /proc/net/ipt_CLUSTERIP/192.168.0.5 pour voir à quels nœuds la machine répond. Pour faire en sorte que la machine réponde à une autre machine, placez le nœud 2, en utilisant echo « +2 » >> /proc/net/ipt_CLUSTERIP/192.168.0.5. Pour le supprimer lancez echo « -2 » >> /proc/net/ipt_CLUSTERIP/192.168.0.5.
Tableau 11.2. Options de la cible CLUSTERIP
| Option | --new |
| Exemple | iptables -A INPUT -p tcp -d 192.168.0.5 --dport 80 -j CLUSTERIP --new … |
| Explication | Ceci crée une nouvelle entrée CLUSTERIP. Elle doit être placée dans la première règle pour une VIP, et est utilisée pour créer un nouveau cluster. Si vous avez plusieurs règles de connexion vers le même CLUSTERIP vous pouvez omettre le mot-clé --new dans toutes les références secondaires vers la même VIP. |
| Option | --hashmode |
| Exemple | iptables -A INPUT -p tcp -d 192.168.0.5 --dport 443 -j CLUSTERIP --new --hashmode sourceip … |
| Explication | Le mot-clé --hashmode spécifie le genre d'empreinte numérique qui sera créée. L'empreinte numérique a été expliquée ci-dessus. De façon basique sourceip donnera de meilleures performances entre les connexions, mais ne possède pas un bon équilibrage de charge entre les machines. sourceip-sourceport procure un mode de hachage légèrement plus lent et n'a pas une bonne maintenance d'états entre les connexions, mais permet un meilleur équilibrage de charge. La dernière crée des modes de hachage très lents consommant beaucoup de mémoire, mais permet un équilibrage de charge très performant. Elle peut être l'une des trois suivantes :
|
| Option | --clustermac |
| Exemple | iptables -A INPUT -p tcp -d 192.168.0.5 --dport 80 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5e:00:00:20 … |
| Explication | L'adresse MAC que le cluster écoute pour les nouvelles connexions. C'est une adresse Multicast MAC sur laquelle tous les hôtes sont en écoute. Voir plus haut pour plus d'explication. |
| Option | --total-nodes |
| Exemple | iptables -A INPUT -p tcp -d 192.168.0.5 --dport 80 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5e:00:00:20 --total-nodes 2 … |
| Explication | Le mot-clé --total-nodes spécifie combien d'hôtes participent au cluster et répondront aux requêtes. Voir plus haut pour plus d'explication. |
| Option | --local-node |
| Exemple | iptables -A INPUT -p tcp -d 192.168.0.5 --dport 80 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5e:00:00:20 --total-nodes 2 --local-node 1 |
| Explication | C'est le numéro que cette machine a dans le cluster. Le cluster répond en séquence périodiquement, donc une fois qu'une nouvelle connexion est établie par le cluster, la machine suivante répond, et la suivante, ainsi de suite. |
| Option | --hash-init |
| Exemple | iptables -A INPUT -p tcp -d 192.168.0.5 --dport 80 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5e:00:00:20 --hash-init 1234 |
| Explication | Spécifie un grenage aléatoire pour l'initialisation du hachage. |
Cette cible est en violation de la RFC 1812 - Requirements for IP Version 4 Routers aussi méfiez-vous des problèmes qui pourraient survenir. La section 3.3.2 indique qu'un routeur ne doit jamais faire confiance à un autre routeur ou hôte qui indique utiliser une Multicast MAC.
Fonctionne avec les derniers noyaux Linux 2.6, indiqué comme expérimental.
12-4. Cible CONNMARK▲
La cible CONNMARK sert a placer une marque sur une connexion, comme le fait la cible MARK. Elle peut alors être utilisée avec la correspondance connmark pour sélectionner la connexion dans le futur. Par exemple, nous voyons un comportement spécifique dans un en-tête, et nous ne voulons pas marquer juste le paquet, mais la connexion complète. La cible CONNMARK est une solution parfaite dans ce cas.
La cible CONNMARK est disponible dans toutes les chaînes et toutes les tables, mais souvenez-vous que la table NAT n'est traversée seulement que par le premier paquet dans une connexion, ainsi la cible CONNMARK n'aura pas d'effet si vous essayez de l'utiliser sur les paquets suivants le premier. Elle peut prendre une des quatre options différentes ci-dessous :
Tableau 11.3. Options de la cible CONNMARK
| Option | --set-mark |
| Exemple | iptables -t nat -A PREROUTING -p tcp --dport 80 -j CONNMARK --set-mark 4 |
| Explication | Cette option place une marque sur la connexion. La marque peut être un entier long non signé, ce qui indique que des valeurs entre 0 et 4 294 967 295l sont valides. Chaque bit peut aussi être marqué par la commande --set-mark 12/8. Ceci permettra seulement aux bits du masque d'être en dehors des bits de la marque. Dans cet exemple, seul le 4e bit sera placé, pas le 3e. 12 traduit en binaire (1100), et 8 (1000), et seulement les bits placés dans le masque sont autorisés. Hormis cela, seul le 4e bit, ou 8, est placé dans la marque. |
| Option | --save-mark |
| Exemple | iptables -t mangle -A PREROUTING --dport 80 -j CONNMARK --save-mark |
| Explication | L'option de la cible --save-mark sert à sauvegarder les paquets marqués dans la marque de connexion. Par exemple, si vous avez placé un paquet marqué avec la cible MARK, vous pouvez alors déplacer cette marque pour marquer l'ensemble de la connexion avec la correspondance --save-mark. La marque peut aussi être masquée en utilisant l'option --mask décrite plus loin. |
| Option | --restore-mark |
| Exemple | iptables -t mangle -A PREROUTING --dport 80 -j CONNMARK --restore-mark |
| Explication | Cette option de cible restaure le paquet marqué dans la marque de connexion comme défini par CONNMARK. Un masque peut aussi être défini par l'option --mask comme vu plus haut. Si une option mask est placée, seules les options masquées seront placées. Notez que cette option de cible n'est valide que dans la table mangle. |
| Option | --mask |
| Exemple | iptables -t mangle -A PREROUTING --dport 80 -j CONNMARK --restore-mark --mask 12 |
| Explication | L'option --mask doit être utilisée avec les options --save-mark et --restore-mark. L'option --mask spécifie que devraient être appliquées les valeurs de marque que fournissent les deux autres options. Par exemple, si restore-mark de l'exemple ci-dessus est à 15, ceci veut dire que la marque est 1111 en binaire, tandis que le masque est à 1100. 1111 et 1100 égale 1100. |
Fonctionne avec les noyaux Linux 2.6.
12-5. Cible CONNSECMARK▲
La cible CONNSECMARK place une marque dans le contexte de sécurité SELinux vers ou depuis une marque de paquet. Pour plus d'informations sur SELinux voir Security-Enhanced Linux. La cible n'est valide que dans la table mangle, elle est utilisée conjointement avec la cible SECMARK, laquelle sert à placer la marque d'origine, ensuite CONNSECMARK place la marque sur la connexion complète.
SELinux est en dehors du propos de ce document, mais de façon basique c'est un ajout de Mandatory Access Control à Linux. Il est plus précis que la plupart des systèmes de sécurité d'origine de beaucoup de Linux/Unix. Chaque objet peut avoir des attributs ou des contextes de sécurité, connecté à lui, et ces attributs sont ensuite sélectionnés pour permettre ou refuser à une tâche spécifique d'être exécutée. Cette cible permet à un contexte de sécurité d'être placé sur une connexion.
Tableau 11.4. Options de la cible CONNSECMARK
| Option | --save |
| Exemple | iptables -t mangle -A PREROUTING -p tcp --dport 80 -j CONNSECMARK --save |
| Explication | Sauvegarde la marque du contexte de sécurité du paquet vers la connexion si la connexion n'est pas marquée avant. |
| Option | --restore |
| Exemple | iptables -t mangle -A PREROUTING -p tcp --dport 80 -j CONNSECMARK --restore |
| Explication | Si le paquet ne possède pas de marque de contexte de sécurité, l'option --restore placera cette marque associée avec la connexion sur le paquet. |
12-6. 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 sélectionné, 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 11.5. Options de la 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 sélectionnés. L'exemple ci-dessus enverra 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 :
iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IPMaintenant, 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é.
- Le paquet quitte l'hôte connecté allant vers $INET_IP et la source $EXT_BOX.
- Le paquet atteint le pare-feu.
- Le pare-feu DNAT le paquet et envoie celui-ci à travers les différentes chaînes, etc.
- Le paquet quitte le pare-feu pour aller vers le $HTTP_IP.
- 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ée comme passerelle pour $EXT_BOX. Normalement, ça devrait être la passerelle par défaut du serveur HTTP.
- Le pare-feu Un-DNAT le paquet de nouveau, ainsi le paquet semble provenir du pare-feu lui-même.
- 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.
- Le paquet quitte la $LAN_BOX vers $INET_IP.
- Le paquet atteint le pare-feu.
- 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.
- Le paquet quitte le pare-feu et atteint le serveur HTTP.
- 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).
- 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 entrants 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 envoie au client. La règle ressemble à ceci :
iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IPSouvenez-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 sélectionnons 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 journalisera toutes ces requêtes provenant de l'Internet comme si elles provenaient du pare-feu.
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 rendre la règle SNAT plus spécifique dans sa partie sélection, 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 en 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_IPTous 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 survenir.
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 filter (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.
12-7. Cible DROP▲
La cible DROP fait exactement ce qu'elle veut dire, elle supprime des paquets morts et n'effectue aucun autre processus supplémentaire. Un paquet qui s'apparie parfaitement à une 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 quelques hôtes. 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, même par des intermédiaires comme les routeurs.
Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.
12-8. 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'informations sur DSCP, voyez la 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, celles-ci pouvant ne pas être très appropriées pour des transferts 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 11.6. 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 --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'informations 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.
12-9. 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 limites d'un flux doivent négocier l'ECN. Si nous l'activons, un des hôtes n'est pas informé de cela, et ne peut répondre proprement aux notifications ECN.
Tableau 11.7. 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'informations. |
Fonctionne avec les noyaux Linux 2.5 et 2.6.
12-10. 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. Mais 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 autres 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ûr à 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 s'apparient exactement aux niveaux de syslogd, et fonctionnent seulement sur les messages de journalisation depuis les fonctionnalités du noyau. Pour plus d'informations, 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 11.8. 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, placez kern.=info /var/log/iptables dans votre fichier syslog.conf et ensuite laissez tous vos messages de LOG dans iptables utiliser 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'informations 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.
12-11. 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'informations 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 11.9. 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.
12-12. 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, cela 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. Lorsqu'une IP différente est attribuée, la connexion est perdue, et il est inutile 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 11.10. Options de la 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 d'autres 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 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.
12-13. 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 pour 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ête 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, du 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 scénario 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 !
12-14. Cible NETMAP▲
NETMAP est une nouvelle implémentation 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 standard. 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 11.11. 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.
12-15. Cible NFQUEUE▲
La cible NFQUEUE est utilisée de la même façon que la cible QUEUE, et elle est, en gros, une extension de celle-ci. NFQUEUE permet d'envoyer des paquets pour des files d'attente séparées et spécifiques. La file d'attente est identifiée par un id de 16 bits.
Cette cible nécessite le support de nfnetlink_queue dans le noyau pour fonctionner. Pour plus d'informations sur ce que vous pouvez faire avec NFQUEUE voir QUEUE targetQUEUE target.
Tableau 11.12. Options de la cible NFQUEUE
| Option | --queue-num |
| Exemple | iptables -t nat -A PREROUTING -p tcp --dport 80 -j NFQUEUE --queue-num 30 |
| Explication | L'option --queue-num spécifie quelle file d'attente utiliser et vers où envoyer les données. Si cette option n'est pas placée, la file d'attente par défaut sera à 0. Le chiffre de la file d'attente est un entier non signé de 16 bits, ce qui veut dire qu'elle peut prendre n'importe quelle valeur comprise entre 0 et 65 535. La valeur 0 par défaut est aussi utilisée par la cible QUEUE. |
Fonctionne avec les noyaux Linux 2.6.14 et supérieur.
12-16. Cible NOTRACK▲
Cette cible sert à annuler le traçage de connexion pour tous les paquets sélectionnés dans cette règle. Cette cible a été présentée dans la section Connexions non tracées et la table rawConnexions non tracées et la table raw du chapitre La machine d'étatLa machine d'état.
La cible ne prend pas d'option et est très facile à utiliser. Sélectionnez les paquets que vous ne voulez pas tracer, et placez NOTRACK dans les règles sélectionnant les paquets.
La cible n'est valide que dans la table raw.
Fonctionne avec les derniers noyaux Linux 2.6.
12-17. QUEUE target▲
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 du 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.
Dans le noyau 2.6.14 le comportement de netfilter a changé. Un nouveau système de dialogue avec QUEUE a été matérialisé, appelé nfnetlink_queue. La cible QUEUE est, de façon basique, un pointeur vers NFQUEUE 0 aujourd'hui. Pour les questions de programmation, voir le lien ci-dessus. Requiert le module nfnetlink_queue.ko.
Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.
12-18. 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 11.13. Options de la 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.
12-19. Cible REJECT▲
La cible REJECT fonctionne à la base comme la cible DROP, mais elle renvoie 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 11.14. Options de la 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 sélectionne 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'informations dans l'annexe Types ICMPAnnexe C. 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'informations 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.
12-20. 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, rencontre une règle qui le sélectionne 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 rencontre une règle --jump RETURN dans la chaîne INPUT. Il sera alors dropé selon le comportement par défaut décrit plus haut, et plus aucune action ne sera faite dans cette chaîne.
Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.
12-21. 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.15. Options 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 le signe -. Ces adresses IP, et toutes les autres comprises dans cette plage, sont des adresses que nous NATons en utilisant 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 fondé 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.
12-22. Cible SECMARK▲
La cible SECMARK sert à placer une marque dans un contexte de sécurité sur un paquet, comme défini par SELinux et les systèmes de sécurité. Elle en est encore dans son enfance sous Linux, mais devrait prendre de plus en plus de place dans le futur. SELinux est hors de propos de ce document, je vous suggère de voir la page Security-Enhanced Linux pour plus d'informations.
En bref, SELinux est un système nouveau et amélioré pour ajouter un Mandatory Access Control (MAC) à Linux, implémenté par la NSA comme test du concept. SELinux place des attributs de sécurité pour différents objets et ensuite les sélectionne dans des contextes de sécurité. La cible SECMARK sert à placer un contexte de sécurité sur un paquet qui peut être utilisé dans des sous-systèmes de sécurité.
La cible SECMARK n'est valide que dans la table mangle.
Tableau 11.16. Options de la cible SECMARK
| Option | --selctx |
| Exemple | iptables -t mangle -A PREROUTING -p tcp --dport 80 -j SECMARK --selctx httpcontext |
| Explication | L'option --selctx sert à spécifier quel contexte de sécurité placer sur un paquet. Le contexte peut ensuite être utilisé pour sélectionner les systèmes de sécurité de Linux. |
12-23. 11.23. 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 (donc non routables sur l'Internet). 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 11.17. 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 comme 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 transitant 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 indiqué 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.
12-24. 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 11.18. 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 placé 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.
12-25. Cible TOS▲
La cible TOS sert à disposer le champ Type de Service dans un 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 peuvent être utilisés 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 versions anciennes (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 11.19. Options de la 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 examiné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é à l'utilisation des valeurs nommées disponibles (qui sont plus ou moins standard), 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.
12-26. Cible TTL▲
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 ceci 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'informations 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 Annexe E,Annexe E. 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 11.20. Options de la 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 peut être les serveurs DNS, pour lesquels 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 sélectionner 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.txtTtl-inc.txt. |
Fonctionne avec les noyaux Linux 2.3, 2.4, 2.5 et 2.6.
12-27. Cible ULOG▲
La cible ULOG sert à la journalisation des paquets sélectionnés de l'espace utilisateur. Si un paquet est examiné 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 11.21. Options de la 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 standard. Cette option préfixe toutes les entrées du journal avec un préfixe utilisateur. Il peut être de 32 caractères de longueur, il est le plus utilisé pour distinguer les différents messages du 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 normalement, 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.
12-28. Prochain chapitre▲
Dans le prochain chapitre, nous verrons comment déboguer vos scripts de pare-feu et quelles techniques sont disponibles pour cela. Nous montrerons le débogage simple avec les commandes bash et echo, et des outils plus complexes comme nmap et nessus.