Correspondance Unclean

La correspondance unclean ne prend aucune option et ne nécessite rien de plus qu'un chargement explicite si vous souhaitez l'utiliser. Notez que cette option est considérée comme expérimentale, qu'elle peut ne pas fonctionner en toutes circonstances et qu'elle ne prendra pas en charge tous les paquetages ou problèmes relatifs à unclean. La correspondance unclean tente de sélectionner les paquets qui paraissent malformés ou inhabituels, comme des paquets avec des en-têtes ou des sommes de contrôle (checksums) erronés. Elle peut être utilisée pour rejeter des connexions (avec la cible DROP) et pour rechercher les flux douteux par exemple. Cela dit, vous devez être conscient qu'il existe un risque d'interruption de connexions saines.

10.4. Prochain chapitre

Dans le prochain chapitre nous parlerons des cibles en détail et ce qu'elles sont capables de faire. Vous y verrez les possibilités de développement de pare-feux de Linux.

CHAPITRE 11

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_packets

Nous pouvons alors lui ajouter une cible saut comme :

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-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, 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 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. Voyons de quelles sortes de cibles il s'agit.

11.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.

Note

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

11.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'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 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'information, regardez la page Linux Advanced Routing and Traffic Control HOW-TO.

Iptables cibles et sauts

Note

Fonctionne avec les noyaux Linux 2.5 et 2.6.

11.3. Cible CLUSTERIP

La cible CLUSTERIP est utilisée pour créer des clusters (grappes de serveurs) de noeuds 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.

Important

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'achat 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 troisè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 noeuds la machine répond. Pour faire en sorte que la machine réponde à une autre machine, placez le noeud 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. Elle peut être l'une des trois suivantes :

•sourceip

•sourceip-sourceport

•sourceip-sourceport-destport

Iptables cibles et sauts

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

équlibrage 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 équlibrage de charge. La dernière crée des modes de hachage très lents consommant beaucoup de mémoire, mais permet un équlibrage de charge très performant.

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.

Avertissement

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.

Note

Fonctionne avec les derniers noyaux Linux 2.6, indiqué comme expérimental.

11.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 4294967295l 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

Iptables cibles et sauts

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.

Note

Fonctionne avec les noyaux Linux 2.6.

11.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'information 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 sytè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.

11.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

Iptables cibles et sauts

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

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

Dans le document Iptables Tutorial 1.2.2 (Page 95-0)