XIV. Correspondances▲
Cette section permet d'approfondir les correspondances. Elles sont intentionnellement classées en cinq catégories distinctes. En premier, on trouve les correspondances génériques qui s'emploient avec toutes les règles. Ensuite, il y a les correspondances TCP qui ne s'appliquent qu'aux paquets TCP. De même, il y a les correspondances UDP qui ne s'appliquent qu'aux paquets UDP, et les correspondances ICMP qui ne s'appliquent qu'aux paquets ICMP. Et à la fin, on décrit les correspondances spéciales, comme les correspondances d'état, de propriétaire, de limite, etc... Ces dernières correspondances sont réparties en autant de sous-catégories, même si elles ne se révèlent pas singulièrement si différentes. J'espère que cette répartition est suffisamment cohérente pour être compréhensible.
Comme vous l'avez peut être déjà compris si vous avez lu les chapitres précédents, une correspondance est quelque chose qui spécifie une condition spéciale dans le paquet et qui doit être vraie (ou fausse). Une seule règle peut contenir plusieurs correspondances de cette sorte. Par exemple, nous voulons apparier des paquets issus d'un hôte spécifique sur notre réseau local, et seulement des ports particuliers sur cet hôte. Nous utilisons alors les correspondances qui indiquent la règle à appliquer à la cible - ou saut - sur les paquets qui ont une adresse source spécifique, arrivant sur l'interface connectée au réseau local et ces paquets doivent être sur un des ports spécifiés. Si une de ces correspondances est erronée (ex. l'adresse source est incorrecte, mais le reste est correct), la règle complète échoue et la règle suivante est testée sur le paquet. Si toutes les correspondances sont vraies, la cible spécifiée par la règle est appliquée.
XIV-A. Correspondances génériques▲
Les correspondances génériques désignent un type de correspondance toujours disponible, et ce quel que soit le protocole concerné ou les extensions de correspondances chargées. Autrement dit, ces correspondances ne requièrent aucun paramètre particulier. La correspondance --protocol a été délibérément incluse ici, bien qu'elle s'adresse spécifiquement aux protocoles. Par exemple, si vous désirez utiliser une correspondance TCP, vous devez appeler la correspondance --protocol et lui fournir TCP pour option. Pourtant, --protocol est également en elle-même une correspondance générique, puisqu'elle permet d'établir une correspondance avec des protocoles différents. Les correspondances suivantes sont donc toujours disponibles.
Tableau 1. Correspondances génériques
| Correspondance | -p, --protocol |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp |
| Explication | Cette correspondance permet de vérifier le type de protocole, par exemple TCP, UDP ou ICMP. De plus, le protocole doit nécessairement soit faire partie des protocoles définis en interne comme TCP, UDP ou ICMP, soit prendre une valeur spécifiée dans le fichier /etc/protocols, ce qui, si elle ne s'y trouve pas, retourne une erreur. Le protocole peut aussi être entré sous forme d'un nombre entier. A titre d'exemple, le protocole ICMP est identifié par la valeur entière 1, TCP par la valeur 6 et UDP par 17. Et finalement, le protocole peut aussi prendre la valeur ALL. ALL signifie tous, donc il établit une correspondance avec tous les protocoles TCP, UDP et ICMP. La commande accepte aussi une liste de protocoles séparés par des virgules, telle que udp,tcp qui permet d'établir une correspondance avec tous les paquets UDP et TCP. Si on désigne le protocole par la valeur zéro (0), ceci est équivalent à ALL, soit tous les protocoles, qui est aussi la valeur par défaut si la correspondance --protocol est omise. Cette correspondance peut également être inversée à l'aide du symbole !. Dans ce cas, --protocol ! tcp identifie les protocoles différents de TCP, et établit donc une correspondance avec UDP et ICMP. |
| Correspondance | -s, --src, --source |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -s 192.168.1.1 |
| Explication | C'est la correspondance de source. Elle sert à sélectionner les paquets à partir de leur adresse IP source. La forme principale permet d'établir une correspondance avec des adresses IP uniques, telles que 192.168.1.1. Mais il est possible d'employer un masque réseau sous une forme binaire de type CIDR, en spécifiant le nombre de "1" dans la partie gauche du masque réseau. Par exemple, ajouter /24 signifie utiliser le masque réseau 255.255.255.0. Ainsi, un intervalle complet d'adresses IP peut être détecté, comme celui d'un réseau local ou d'un sous-réseau derrière un pare-feu. La commande ressemble alors à 192.168.0.0/24, qui établit une correspondance avec les paquets de l'intervalle 192.168.0.x. Une autre méthode consiste à utiliser un masque réseau ordinaire de la forme 255.255.255.255, ce qui donne au final 192.168.0.0/255.255.255.0. On peut également inverser la sélection avec un ! comme précédemment. Ainsi, avec une correspondance du type --source ! 192.168.0.0/24, on établit une correspondance avec tous les paquets dont l'adresse source n'appartient pas à l'intervalle 192.168.0.x. Le comportement par défaut sélectionne toutes les adresses IP. |
| Correspondance | -d, --dst, --destination |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -d 192.168.1.1 |
| Explication | -i, --in-interfaceLa correspondance --destination est utilisée pour sélectionner les paquets à partir de leur(s) adresse(s) destination. Ceci fonctionne sensiblement comme la correspondance --source et avec la même syntaxe, excepté qu'on s'intéresse ici à la destination des paquets. Pour correspondre avec un intervalle d'adresses IP, on peut ajouter un masque réseau soit sous sa forme exacte, soit avec le nombre de 1 compris dans la partie gauche du masque réseau sous forme binaire. voici des exemples : 192.168.0.0/255.255.255.0 et 192.168.0.0/24. Les deux sont parfaitement équivalents. Il est toujours possible d'inverser la sélection à l'aide du signe ! comme précédemment. --destination ! 192.168.0.1 établit une correspondance avec tous les paquets sauf ceux qui sont destinés à l'adresse IP 192.168.0.1. |
| Correspondance | -i, --in-interface |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -i eth0 |
| Explication | Cette correspondance est destinée à sélectionner les paquets issus d'une certaine interface. Remarquez que cette option n'est autorisée que dans les chaînes INPUT, FORWARD et PREROUTING, et qu'elle retourne une erreur si elle est utilisée ailleurs. Si aucune interface n'est spécifiée, le comportement par défaut présuppose que le caractère + a été omis. Ce caractère permet d'établir une correspondance avec une chaîne de caractères (composée de lettres et chiffres). Un simple + stipule au noyau de reconnaître tous les paquets sans identifier leur interface d'origine. Le caractère + peut également être juxtaposé au type d'interface, donc eth+ désigne tous les périphériques Ethernet. Le sens de cette option peut être inversée à l'aide du symbole !. Une ligne dont la syntaxe est -i ! eth0 cherche à correspondre à toutes les interfaces d'entrée, sauf eth0. |
| Correspondance | -o, --out-interface |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A FORWARD -o eth0 |
| Explication | La correspondance --out-interface permet de sélectionner les paquets en fonction de l'interface par laquelle ils sortent. Remarquez que cette correspondance n'est disponible que pour les chaînes OUTPUT, FORWARD et POSTROUTING, à l'opposé de la correspondance --in-interface. A part ça, elle fonctionne presque de la même façon. L'extension + traduit une correspondance avec des périphériques similaires, ainsi eth+ établit une correspondance avec tous les périphériques de type eth, et ainsi de suite. Pour inverser le sens de la sélection, utilisez le signe ! exactement comme pour la correspondance --in-interface. Si aucune interface de sortie n'est spécifiée avec --out-interface, le comportement par défaut accepte tous les périphériques, indépendemment de la direction prise par les paquets. |
| Correspondance | -f, --fragment |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -f |
| Explication | Cette correspondance est destinée à sélectionner le deuxième fragment et les suivants d'un paquet fragmenté. En fait, dans le cas d'un paquet fragmenté, il est impossible de connaître ni les ports source ou destination des fragments, ni les types ICMP, ni d'autres choses encore. Ainsi, les paquets fragmentés peuvent être utilisés dans des cas très particuliers pour organiser des attaques contre des ordinateurs. De tels fragments ne correspondent à aucune autre règle, ce qui a conduit à créer celle-ci. Cette option peut aussi être employée avec le symbole ! ; mais exceptionnellement ici, le signe ! doit précéder la correspondance, c'est-à-dire ! -f. Quand cette correspondance est inversée, elle sélectionne tous les fragments d'en-tête et/ou tous les paquets non fragmentés. Ceci signifie qu'on établit une correspondance avec tous les premiers fragments des paquets fragmentés, et pas avec les deuxièmes, troisièmes, et ainsi de suite. On établit aussi une correspondance avec les paquets qui n'ont pas été fragmentés pendant le transfert. Notez qu'il y a d'excellentes options de défragmentation dans le noyau, et qui peuvent se substituer à cette correspondance. Notez également que si vous utilisez du traçage de connexion, vous ne verrez aucun paquet fragmenté, puisqu'ils sont pris en compte avant d'atteindre les chaînes ou les tables dans iptables. |
XIV-B. Correspondances implicites▲
Cette section se charge de décrire les correspondances chargées implicitement. Les correspondances implicites sont sous-jacentes, acquises et automatiques. Par exemple, lorsqu'on établit une correspondance avec --protocol tcp sans autre critère. Il y a actuellement trois types de correspondances implicites pour trois différents protocoles : les correspondances TCP, les correspondances UDP et les correspondances ICMP. Les correspondances basées sur TCP contiennent un ensemble de critères uniquement valables pour les paquets TCP. De même pour les correspondances UDP et ICMP. D'un autre côté, il peut aussi y avoir des correspondances explicites, c'est-à-dire chargées explicitement. Les correspondances explicites ne sont ni sous-jacentes, ni automatiques, vous devez obligatoirement les spécifier. Pour celles-ci, utilisez l'option -m ou --match, qui est abordée dans la section suivante.
XIV-B-1. Correspondances TCP▲
Ces correspondances sont dédiées à un protocole, et en l'occurence elles sont seulement disponibles pour des paquets ou des flux TCP. Pour utiliser ces correspondances, vous devez ajouter --protocol tcp à la ligne de commande avant de vous en servir. Notez bien que --protocol tcp doit précéder (donc être situé à gauche) les correspondances spécifiques au protocole. Celles-ci peuvent être chargées implicitement de la même façon que peuvent l'être les correspondances UDP et ICMP. Les autres correspondances sont développées à la suite de cette section.
Tableau 2. Correspondances TCP
| Correspondance | --sport, --source-port |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp --sport 22 |
| Explication | La correspondance --source-port permet de sélectionner des paquets à partir de leur port source. Sans cela, on sous-entend tous les ports source. La correspondance accepte indifféremment un nom de service ou un numéro de port. Si vous spécifiez un nom de service, celui-ci doit figurer dans le fichier /etc/services, parce qu'iptables s'appuie sur ce fichier pour identifier le service. Si vous spécifiez le port par son numéro, la règle sera chargée légèrement plus vite, puisqu' iptables n'a pas à valider le nom du service. Cependant, la correspondance risque d'être un peu plus difficile à lire qu'avec un nom de service. Si vous écrivez une table de règles constituée de plus de 200 règles, vous devriez utiliser les numéros de port, car la différence devient sensible (sur une machine lente, ceci peut conduire à un écart de 10 secondes, si vous avez défini une table de règles contenant au moins 1000 règles). La correspondance --source-port permet aussi de sélectionner n'importe quel intervalle de ports. Par exemple, --source-port 22:80 établit une correspondance avec tous les ports source compris entre 22 et 80. Si vous omettez la spécification du premier port, le port 0 est implicitement considéré. Ainsi, --source-port :80 permet d'établir une correspondance avec les ports de 0 à 80. Et si vous omettez la spécification du dernier port, le port 65535 est considéré. Ainsi, --source-port 22: permet d'établir une correspondance avec tous les ports de 22 à 65535. Si vous intervertissez les ports de l'intervalle, iptables corrige automatiquement en réordonnant les numéros. Donc, écrire --source-port 80:22 est naturellement interprété --source-port 22:80. Une correspondance peut être inversée en ajoutant le symbole !. Par exemple, --source-port ! 22 signifie établir une correspondance avec tous les ports sauf le port 22. L'inversion peut s'appliquer aussi à un intervalle de ports, comme par exemple --source-port ! 22:80 qui établit une correspondance avec tous les ports sauf ceux de l'intervalle 22 à 80. Notez que cette correspondance n'accepte pas plusieurs ports ou intervalles de ports distincts. Pour plus d'information sur cette possibilité, consultez l'extension de correspondance multiport. |
| Correspondance | --dport, --destination-port |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp --dport 22 |
| Explication | Cette correspondance permet de sélectionner des paquets TCP en fonction de leur port destination. Elle s'appuie sur la même syntaxe que la correspondance --source-port. Elle comprend les spécifications de ports et d'intervalle de ports, ainsi que l'option d'inversion. De même, elle intervertit si nécessaire les premier et dernier ports dans la spécification d'intervalle, comme ci-dessus. Cette correspondance considère également par défaut les valeurs de ports de 0 et 65535 si les extrémités d'intervalle sont omises. En définitive, elle fonctionne exactement selon la même syntaxe que --source-port. Notez que cette correspondance n'accepte pas plusieurs ports ou intervalles de ports distincts. Pour plus d'information sur cette possibilité, consultez l'extension de correspondance multiport. |
| Correspondance | --tcp-flags |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -p tcp --tcp-flags SYN,FIN,ACK SYN |
| Explication | Cette correspondance permet de sélectionner les paquets à partir de leurs fanions TCP. En premier, la correspondance requiert une liste de fanions à tester (un masque) suivie de la liste des fanions qui doivent être positionnés à 1 (donc activés). Dans les deux listes, les fanions sont séparés par des virgules. La correspondance reconnaît les fanions SYN, ACK, FIN, RST, URG et PSH. Elle accepte aussi les mots ALL (tous) et NONE (aucun) dont le sens est plutôt intuitif : ALL équivaut à tous les fanions et NONE à aucun. Typiquement, --tcp-flags ALL NONE vérifie tous les fanions TCP et établit une correspondance si aucun n'est activé (donc positionné à 1). Cette option peut également être inversée à l'aide du signe !. Par exemple, spécifier ! SYN,FIN,ACK SYN revient à faire correspondre les paquets qui possèdent les bits ACK et FIN activés, mais pas le bit SYN. Notez que la séparation des fanions par des virgules ne doit inclure aucune espace, comme vous pouvez le voir dans l'exemple ci-dessus. |
| Correspondance | --syn |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -p tcp --syn |
| Explication | La correspondance --syn est plus ou moins une relique du règne d'ipchains. Elle perdure pour garantir une certaine rétro-compatibilité et simplifier la transition vers iptables. Elle permet d'établir une correspondance avec des paquets s'ils possèdent le bit SYN activé et les bits ACK et RST désactivés. Cette commande se comporte rigoureusement comme la correspondance --tcp-flags SYN,RST,ACK SYN. Les paquets de ce type servent principalement aux demandes de connexion en provenance de serveurs. Si vous bloquez ces paquets, vous devriez effectivement empêcher toutes les tentatives de connexions entrantes. Toutefois, vous ne bloquerez pas les connexions sortantes, qui sont mises à profit aujourd'hui par de nombreux exploits (par exemple, détourner un service légitime pour installer localement un programme ou créer une liaison à partir d'une connexion existante sur votre hôte au lieu d'ouvrir un nouveau port). Cette correspondance peut également être inversée à l'aide du signe !. Ainsi, ! --syn correspond à tous les paquets ayant les bits RST ou ACK activés, autrement dit les paquets appartenant à une connexion déjà établie. |
| Correspondance | --tcp-option |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -p tcp --tcp-option 16 |
| Explication | Cette correspondance permet d'établir une correspondance avec des paquets suivant leurs options TCP. Une option TCP identifie une partie spécifique de l'en-tête des paquets. Cette partie contient 3 champs différents. Le premier a une longueur de 8 bits et décrit les options utilisées dans ce flux ; le deuxième s'étend aussi sur 8 bits et précise la longueur du champ des options. L'information de longueur du champ doit son existence au caractère optionnel des options TCP. Pour être conforme aux standards, il n'est pas utile d'implémenter toutes les options, il suffit de les identifier. Si elles ne sont pas prises en charge, on lit seulement l'information de longueur afin de sauter par-dessus ces données. Cette correspondance permet de sélectionner plusieurs options TCP en fonction de leurs valeurs numériques. Elle peut également être inversée avec le signe !, de telle sorte que la correspondance s'établisse avec toutes les options TCP sauf celle passée en paramètre. Pour obtenir la liste complète des options, consultez le site Internet Engineering Task Force qui contient une liste de toutes les valeurs standardes employées sur Internet. |
XIV-B-2. Correspondances UDP▲
Cette section décrit les correspondances qui fonctionnent seulement avec des paquets UDP. Elles sont chargées implicitement lorsque la correspondance --protocol UDP est spécifiée et elles ne sont effectivement disponible qu'après cette spécification. Notez que les paquets UDP ne sont pas orientés connexion, et par conséquent ils ne possèdent pas de fanions particuliers pour informer du rôle joué par le datagramme tel que l'ouverture ou la fermeture d'une connexion, ou encore le simple envoi de données. Les paquets UDP ne nécessitent aucun accusé de réception. S'ils s'égarent sur le réseau, ils n'engendrent aucune action (aucun message d'erreur de type ICMP n'est expédié). Autrement dit, il existe nettement moins de correspondances associées aux paquets UDP qu'aux paquets TCP. Notez que la machine d'état fonctionne sur tous les types de paquets, même si les paquets UDP et ICMP appartiennent à des protocoles sans connexion. La machine d'état fonctionne quasiment de la même façon pour les paquets UDP que pour les paquets TCP.
Tableau 3. Correspondances UDP
| Correspondance | --sport, --source-port |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p udp --sport 53 |
| Explication | Cette correspondance fonctionne exactement comme son équivalent pour TCP. Elle permet d'établir des correspondances avec des paquets à partir de leurs ports source UDP. Elle prend en charge les intervalles de ports, les ports uniques et les inversions de ports selon la même syntaxe. Pour spécifier un intervalle de ports UDP, vous pouvez utiliser 22:80 qui établit une correspondance avec les ports UDP de 22 à 80. Si le premier numéro est omis, il est considéré par défaut comme étant le port 0. Si le dernier numéro est omis, le port 65535 est pris par défaut. Si le port le plus grand est mis avant le plus petit, les numéros sont intervertis automatiquement. Dans le cas d'un port UDP unique, la syntaxe se calque sur l'exemple ci-dessus. Pour inverser la correspondance de port, il suffit d'insérer le signe !. Dans --source-port ! 53, la correspondance s'établit avec tous les ports sauf le numéro 53. Cette correspondance comprend les noms de service, du moment qu'ils sont disponibles dans le fichier /etc/services. Notez que cette correspondance n'accepte pas les ports et les intervalles de ports distincts. Pour davantage d'information, consultez l'extension de correspondance multiport. |
| Correspondance | --dport, --destination-port |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p udp --dport 53 |
| Explication | Cette correspondance s'apparente fortement à --source-port décrite ci-dessus. Elle est aussi très proche de la correspondance TCP équivalente, sauf qu'elle s'applique aux paquets UDP. Elle établit une correspondance à partir du port destination UDP. Elle accepte les intervalles de ports, les ports uniques et les inversions. Pour sélectionner un port unique, vous pouvez utiliser par exemple --destination-port 53 ; pour l'inverser, ce sera plutôt --destination-port ! 53. La première commande sélectionnne tous les paquets UDP en direction du port 53, alors que la seconde sélectionne tous les paquets sauf ceux destinés au port 53. Pour spécifier un intervalle de ports, utilisez par exemple --destination-port 9:19 pour établir une correspondance avec tous les paquets destinés aux ports UDP compris entre 9 et 19. Si le premier port est omis, on considère le port 0 par défaut. Si le second est omis, on considère le port 65535 par défaut. Si le port le plus grand est placé avant le plus petit, ils sont interchangés automatiquement pour que le plus petit port précède le plus grand. Notez que cette correspondance n'accepte pas les ports et intervalles de ports distincts. Pour plus d'information, consultez l'extension de correspondance multiport. |
XIV-B-3. Correspondances ICMP▲
Abordons maintenant les correspondances ICMP. Les paquets ICMP sont de nature éphémère, c'est-à-dire qu'ils ont la vie courte, plus courte que les paquets UDP dans le sens où ils sont sans connexion. Le protocole ICMP sert principalement aux messages d'erreur, aux contrôles de connexion, et d'autres choses du même acabit. ICMP n'est pas un protocole subordonné au protocole IP, mais plutôt qui enrichit le protocole IP et concourt à la gestion des erreurs. L'en-tête des paquets ICMP ressemble à celle des paquets IP, mais diffère sur certains aspects. La caractéristique primordiale de ce protocole provient du type d'en-tête, qui traduit la raison d'être du paquet. A titre d'exemple, si on tente d'accéder à une adresse IP inaccessible, on récupère normalement en retour un ICMP host unreachable (machine inaccessible). Pour visualiser la liste complète des types ICMP, consultez l'annexe Types ICMP. Une seule correspondance ICMP spécifique est disponible pour les paquets ICMP, et heureusement, elle devrait suffire. Cette correspondance est chargée implicitement quand on spécifie --protocol ICMP, et on en dispose automatiquement. Notez que toutes les correspondances génériques sont utilisables, et qu'elles permettent par exemple de sélectionner les adresses source et destination.
Tableau 4. Correspondances ICMP
| Correspondance | --icmp-type |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p icmp --icmp-type 8 |
| Explication | Cette correspondance permet de spécifier le type ICMP à sélectionner. Les types ICMP peuvent être définis soit par leur valeur numérique, soit par leur nom. Les valeurs numériques sont spécifiés dans le RFC 792. Pour afficher la liste complète des noms ICMP, exécutez la commande iptables --protocol icmp --help ou consultez l'annexe Types ICMP. Cette correspondance peut être inversée en insérant le signe ! de cette façon : --icmp-type ! 8 ou --icmp-type 8/0. Pour une liste complète des noms, tapez iptables -p icmp --help. |
XIV-C. Correspondances explicites▲
Les correspondances explicites ont besoin d'être chargés spécifiquement à l'aide de l'option -m ou --match. Par exemple, les correspondances d'état requiert la directive -m state avant d'entrer la véritable correspondance à prendre en compte. Certaines de ces correspondances sont spécifiques à un protocole. Certaines peuvent aussi être détachées de tout protocole spécifique - par exemple les états de connexion. Ils sont identifiés par NEW (pour le premier paquet d'une connexion non encore établie), ESTABLISHED (pour une connexion déjà enregistrée dans le noyau), RELATED (pour une nouvelle connexion créée par une connexion plus ancienne et déjà établie), etc. Parmi ces correspondances explicites, quelques-une peuvent avoir évolué pour des questions de test ou d'expérimentation, ou simplement pour mettre en évidence les capacités d'iptables. Par conséquent, ceci signifie que l'intégralité de ces correspondances n'est pas à première vue indispensable. Néanmoins, il y a de grandes chances que vous trouviez certaines des ces correspondances explicites particulièrement utiles. Et de nouvelles apparaissent en permanence, lors de chaque nouvelle version d'iptables. Que vous leur découvriez ou non une utilisation dépend de votre imagination et de vos besoins. Pour comprendre la différence entre une correspondance chargée implicitement et une chargée explicitement, il faut savoir que la première est chargée automatiquement quand par exemple vous établissez une correspondance avec une propriété des paquets TCP, alors que la seconde n'est jamais chargée automatiquement - c'est à vous de révéler et d'activer une correspondance explicite.
XIV-C-1. Correspondance AH/ESP▲
Ces correspondances sont utilisées pour les protocoles IPSEC AH et ESP. IPSEC sert à créer des tunnels sécurisés par dessus une connexion Internet non sécurisée. Les protocoles AH et ESP sont utilisés par IPSEC pour créer ces connexions sécurisées. Les correspondances AH et ESP sont deux correspondances séparées, mais elles sont toutes les deux décrites ici car elles se ressemblent beaucoup, et toutes les deux ont le même usage.
Je ne rentrerai pas dans les détails d'IPSEC ici, regardez les pages suivantes pour plus d'information :
- RFC 2401 - Security Architecture for the Internet Protocol
- FreeS/WAN
- IPSEC Howto
- Linux Advanced Routing and Traffic Control HOW-TO
Il existe aussi des tonnes de documentation sur l'Internet à ce sujet.
Pour utiliser les correspondances AH/ESP, vous devrez vous servir de -m ah pour charger les correspondances AH, et -m esp pour charger les correspondances ESP.
Dans les noyaux 2.2 et 2.4, Linux utilise une chose appelée FreeS/WAN pour l'implémentation de IPSEC, mais à partir des noyaux 2.5.47 et supérieurs, ceux-ci ont une implémentation directe de IPSEC et donc ne nécessitent pas de patcher le noyau. C'est une réécriture complète de l'implémentation de IPSEC dans Linux.
Tableau 5. Options des correspondances AH
| Correspondance | --ahspi |
| Noyau | 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p 51 -m ah --ahspi 500 |
| Explication | Ceci vérifie le numéro de l'Index du Paramètre de Sécurité (SPI) des paquets AH. Notez que vous devez spécifier le protocole, car AH s'exécute sur un protocole différent des standards TCP, UDP et ICMP. Le numéro SPI est utilisé en conjonction avec les adresses source et destination et les clés secrètes pour créer une association de sécurité (SA). SA identifie chacun des tunnels IPSEC pour tous les hôtes. SPI est utilisé uniquement pour distinguer chaque tunnel IPSEC connecté entre deux identiques. Utiliser la correspondance --ahspi, nous permet de vérifier un paquet basé sur le SPI des paquets. Cette correspondance peut vérifier une chaîne complète de valeur SPI en utilisant un signe :, comme 500:520, qui vérifiera toute la chaîne des SPI. |
Tableau 6. Options des correspondances ESP
| Correspondance | --espspi |
| Noyau | 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p 50 -m esp --espspi 500 |
| Explication | La contrepartie de l'Index des Paramètres de Sécurité (SPI) est utilisée de la même façon que la variante AH. La correspondance semble exactement la même, avec seulement la différence esp/ah. Bien sûr, cette correspondance peut apparier un ensemble complet de numéros SPI de la même façon que la variante AH de la correspondance SPI, comme --espi 200:250 qui apparie la totalité de la chaîne des SPI. |
XIV-C-2. Correspondance conntrack▲
La correspondance conntrack est une version étendue de la correspondance état, qui rend possible l'appariement des paquets de façon un peu plus grossière. Ce qui vous permet d'avoir l'information directement disponible dans un système de traçage de connexion, sans applications frontales, comme dans la correspondance état. Pour plus de détails sur le système de traçage de connexion, regardez le chapitre La machine d'état.
Il existe nombre de différents appariements dans la correspondance conntrack, pour différents champs dans le système de traçage de connexion. Ils sont indiqués ensemble dans la liste ci-dessous. Pour charger ces correspondances, vous devez spécifier -m conntrack.
Tableau 7. Options de correspondance conntrack
| Correspondance | --ctstate |
| Noyau | 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m conntrack --ctstate RELATED |
| Explication | Cette correspondance est utilisée pour apparier l'état d'un paquet, selon l'état conntrack. Elle est utilisée pour apparier plus finement les mêmes états que dans la correspondance state d'origine. Les entrées valides pour cette correspondance sont : INVALIDESTABLISEDNEWRELATEDSNATDNAT Les entrées peuvent être utilisées l'une avec l'autre en les séparant par une virgule. Par exemple, -m conntrack --ctstate ESTABLISHED,RELATED. Elles peuvent aussi être interverties en mettant un ! avant --ctstate. Exemple : -m conntrack ! --ctstate ESTABLISHED,RELATED, qui apparie tout sauf les états ESTABLISHED et RELATED. |
| Correspondance | --ctproto |
| Noyau | 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m conntrack --ctproto TCP |
| Explication | Ceci apparie le protocole, de la même façon que le fait --protocol. Il peut prendre les mêmes types de valeurs, et on peut l'intervertir en utilisant le signe !. Exemple, -m conntrack ! --ctproto TCP apparie tous les protocoles sauf TCP. |
| Correspondance | --ctorigsrc |
| Noyau | 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m conntrack --ctorigsrc 192.168.0.0/24 |
| Explication | --ctorigsrc est une correspondance basée sur la spécification de la source IP d'origine de l'entrée conntrack en rapport avec le paquet. La correspondance peut être inversée en utilisant le ! entre le --ctorigsrc et la spécification IP, comme --ctorigsrc ! 192.168.0.1. Elle peut aussi prendre un masque de réseau de forme CIDR, comme --ctorigsrc 192.168.0.0/24. |
| Correspondance | --ctorigdst |
| Noyau | 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m conntrack --ctorigdst 192.168.0.0/24 |
| Explication | Cette correspondance est utilisée de la même façon que --ctorigsrc, sauf qu'elle apparie sur le champ destination de l'entrée conntrack. Elle possède la même syntaxe. |
| Correspondance | --ctreplsrc |
| Noyau | 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m conntrack --ctreplysrc 192.168.0.0/24 |
| Explication | La correspondance --ctreplysrc est utilisée pour l'appariement basé sur la réponse source du conntrack d'origine du paquet. C'est à peu près la même chose que le --ctorigsrc, mais nous apparions la réponse source attendue des paquets envoyés. Cette cible peut, bien sûr, être inversée et adresser une chaîne complète d'adresses, de la même façon que la cible précédente dans cette classe. |
| Correspondance | --ctrepldst |
| Noyau | 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m conntrack --ctreplydst 192.168.0.0/24 |
| Explication | La correspondance --ctreplydst est la même que --ctreplysrc, avec la différence qu'elle apparie la réponse de destination de l'entrée conntrack qui a apparié la paquet. Elle peut être inversée, et accepte les chaînes, comme la correspondance --ctreplysrc. |
| Correspondance | --ctstatus |
| Noyau | 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m conntrack --ctstatus RELATED |
| Explication | Ceci apparie les statuts de la connexion, comme décrit dans la chapitre La machine d'état. Ces statuts sont les suivants : NONE - La connexion ne possède aucun statut. EXPECTED - Cette connexion est en attente et a été ajoutée par les gestionnaires d'attente. SEEN_REPLY - La connexion a vu une réponse mais n'en est cependant pas assurée. ASSURED - La connexion est certaine et ne sera pas supprimée tant que le délai d'attente ne sera pas atteint ou qu'elle sera interrompue d'une autre façon. Elle peut aussi être inversée par le signe !. Exemple, -m conntrack ! --ctstatus ASSURED qui apparie tout sauf le statut ASSURED. |
| Correspondance | --ctexpire |
| Noyau | 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m conntrack --ctexpire 100:150 |
| Explication | Cette correspondance sert à apparier les paquets basés sur la longueur du temps d'expiration de l'entrée conntrack, mesuré en secondes. Elle peut soit prendre une seule valeur, ou une chaîne comme dans l'exemple au-dessus. Elle peut aussi être inversée avec le signe !, comme -m conntrack ! --ctexpire 100. Ceci apparie chaque temps d'expiration, qui n'est pas exactement de 100 secondes. |
XIV-C-3. Correspondance DSCP▲
Cette correspondance est utilisée pour apparier les paquets basés sur leur champ DSCP (Differentiated Services Code Point). C'est documenté dans la RFC RFC 2638 - A Two-bit Differentiated Services Architecture for the Internet. La correspondance est chargée en spécifiant -m dscp. Elle peut prendre deux options mutuellement incompatibles, décrites ci-dessous.
Tableau 8. Options de correspondance DSCP
| Correspondance | --dscp |
| Noyau | 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m dscp --dscp 32 |
| Explication | Cette option prend une valeur DSCP soit en décimal soit en hexadécimal. Si la valeur de l'option est en décimal, elle sera écrite comme 32 ou 16, etc. Si elle est écrite en hexadécimal, elle pourrait être préfixée avec des 0x, comme ça : 0x20. Elle peut aussi être inversée par le signe !, comme : -m dscp ! --dscp 32. |
| Correspondance | --dscp-class |
| Noyau | 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m dscp --dscp-class BE |
| Explication | La correspondance --dscp-class sert à l'appariement d'une classe Diffserv d'un paquet. Les valeurs peuvent être l'une des classes BE, EF, AFxx ou CSxx comme spécifié dans les diverses RFC. Elle peut être inversée de la même façon qu'avec l'option --dscp. |
Notez que les options de classes --dscp et dscp-class sont mutuellement exclusives et ne peuvent pas être utilisées conjointement l'une avec l'autre.
XIV-C-4. Correspondance ECN▲
ECN est utilisé pour l'appariement sur les différents champs ECN dans les en-têtes TCP et IPv4. ECN est décrit en détail dans la RFC RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP. La correspondance est chargée par -m ecn dans la ligne de commande. Elle prend trois options différentes, comme décrit ci-dessous.
Tableau 9. Options de la correspondance ECN
| Correspondance | --ecn |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m ecn --ecn-tcp-cwr |
| Explication | Cette correspondance est utilisée pour apparier le bit CWR (Congestion Window Received), s'il a été placé. Le fanion CWR est placé pour notifier l'autre point limite de la connexion reçu (ECE), et qui a été réactivé. Par défaut elle vérifie si le bit CWR est placé, mais la correspondance peut aussi être inversée par le signe !. |
| Correspondance | --ecn-tcp-ece |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m ecn --ecn-tcp-ece |
| Explication | Cette correspondance peut être utilisée pour apparier le bit ECE (ECN-Echo). Le ECE est placé une fois que les points limite aient reçu un paquet avec un bit CE placé par un routeur. Le point limite place alors le ECE en renvoyant la paquet ACK, pour le notifier à l'autre point limite. Cet autre point limite envoie alors un paquet CWR comme décrit dans l'explication de --ecn-tcp-cwr. C'est le comportement par défaut si le bit ECE est placé, mais peut être interverti par le signe !. |
| Correspondance | --ecn-ip-ect |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m ecn --ecn-ip-ect 1 |
| Explication | --ecn-ip-ect est utilisée pour apparier les codes caractères ECT (ECN Capable Transport). Les codes caractères ECT possèdent plusieurs types. Principalement, ils sont utilisés pour savoir si la connexion a les possibilités ECN en plaçant un des deux bits à 1. ECT est aussi utilisé par les routeurs pour indiquer qu'ils sont en processus d'engorgement, en plaçant les deux points limite ECT à 1. les valeurs ECT sont toutes disponibles dans la table Champ ECN dans IP ci-dessous. La correspondance peut être inversée par un !, exemple ! --ecn-ip-ect 2 qui va apparier toutes les valeurs ECN sauf le point limite ECT(0). la chaîne de valeur correcte dans Iptables est de 0 à 3. Voir ci-dessous pour les valeurs : |
Tableau 10. Champ ECN dans IP
| Valeur Iptables | ECT | CE | [Obsolète] Noms RFC 2481 pour les bits ECN |
|---|---|---|---|
| 0 | 0 | 0 | Not-ECT, ie. pas de possibilité de connexion non-ECN |
| 1 | 0 | 1 | ECT(1), nouvelle convention de nommage des points limite ECT dans la RFC 3168 |
| 2 | 1 | 0 | ECT(0), nouvelle convention de nommage des points limite ECT dans la RFC 3168 |
| 3 | 1 | 1 | CE (Congestion Experienced), utilisé pour notifier les points limite pour l'engorgement. |
XIV-C-5. Correspondance Helper▲
C'est plutôt une correspondance pas très orthodoxe en comparaison des autres, dans ce sens qu'elle utilise une syntaxe spécifique de bit. Elle est utilisée pour apparier les paquets, basés sur l'assistant conntrack en relation avec le paquet. Par exemple, regardons une session FTP. La session Contrôle est ouverte, et les ports/connexion sont négociés pour la session Données dans la session Contrôle. Le module assistant ip_conntrack_ftp va trouver cette information, et créer une entrée dans la table conntrack. Maintenant, quand un paquet entre, nous pouvons voir quel protocole est en relation, et pouvons apparier le paquet dans nos propres tables de règles basées sur l'assistant qui a été utilisé.
Tableau 11. Options de correspondance Helper
| Correspondance | --helper |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m helper --helper ftp-21 |
| Explication | L'option --helper est utilisée pour spécifier une valeur de chaîne, indiquant à la correspondance quelle assistant conntrack apparier. Dans sa forme basique, elle peut ressembler à --helper irc. C'est l'endroit où la syntaxe démarre en variant par rapport à la syntaxe normale. Nous pouvons aussi choisir d'apparier seulement les paquets basés sur tel port que l'original a pris. Exemple, la session Contrôle FTP est normalement transférée sur le port 21, mais il peut aussi bien être sur le port 954 ou un autre. Nous pouvons alors spécifier quel port sera utilisé, comme --helper ftp-954. |
XIV-C-6. Correspondance de plage IP▲
La correspondance de plage IP est utilisée pour apparier les plages IP, comme les correspondances --source et --destination peuvent le faire. Cependant, cette correspondance ajoute une sorte d'appariement différent dans le sens qu'elle peut apparier dans la forme IP à IP, ce que les correspondances --source et --destination sont incapables de faire. Ceci peut être nécessaire dans certains réglages de réseaux spécifiques, et elle est légèrement plus souple.
Tableau 12. Options de correspondance de plage IP
| Correspondance | --src-range |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m iprange --src-range 192.168.1.13-192.168.2.19 |
| Explication | Ceci apparie une plage d'adresses source IP. La plage inclut chaque adresse depuis la première jusqu'à la dernière, ainsi l'exemple ci-dessus inclut toutes les adresses depuis 192.168.1.13 jusqu'à 192.168.2.19. Elle peut aussi être inversée avec le !. L'exemple du dessus ressemblera alors à -m iprange ! --src-range 192.168.1.13-192.168.2.19, qui va apparier chaque adresse, sauf celles spécifiées. |
| Correspondance | --dst-range |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m iprange --dst-range 192.168.1.13-192.168.2.19 |
| Explication | --dst-range fonctionne exactement de la même façon que la correspondance --src-range, sauf qu'elle apparie la destination IP au lieu de la source IP. |
XIV-C-7. Correspondance Length▲
La correspondance Length est utilisée pour apparier les paquets basés sur leur longueur. C'est très simple. Si vous voulez limiter la longueur des paquets pour quelque étrange raison, ou bloquer ce qui ressemble à un ping-of-death, utilisez cette correspondance.
Tableau 13. Options de correspondance Length
| Correspondance | --length |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m length --length 1400:1500 |
| Explication | L'exemple --length va apparier tous les paquets de longueur comprise entre 1400 et 1500 octets. Elle peut être inversée en utilisant le signe !, comme ça : -m length ! --length 1400:1500. Elle peut aussi être utilisée pour apparier certaines tailles seulement, supprimant le signe :, comme ceci : -m length --length 1400. La plage est, bien sûr, inclusive, ce qui inclut tous les paquets dont la longueur est comprise dans les valeurs que vous avez spécifiées. |
XIV-C-8. Correspondance Limit▲
L'extension de correspondance limit doit être chargée explicitement avec l'option -m limit. Cette correspondance peut être employée avantageusement pour limiter la journalisation de certaines règles, etc. Par exemple, vous pouvez établir une correspondance avec tous les paquets qui n'excèdent pas une quantité donnée, et au-delà de ce seuil, limiter la journalisation de l'évènement en question. Considérez ce seuil comme une limite temporelle : vous pouvez limiter le nombre de correspondances d'une certaine règle dans un certain laps de temps, par exemple pour atténuer l'impact des attaques de type déni de service (DoS). C'est d'ailleurs la principale application qu'on en fait, mais naturellement, il en existe d'autres. La correspondance limit peut également être inversée en ajoutant le symbole ! juste après le mot limit. Elle s'exprime alors sous la forme -m limit ! --limit 5/s, autrement dit tous les paquets sont sélectionnés quand la limite est dépassée.
Pour décrire plus précisément la correspondance limit, c'est essentiellement un filtre à seau de jetons ("token bucket filter"). Considérez un seau percé qui laisse fuir N paquets par unité de temps. N est défini en fonction du nombre de paquets que nous voulons sélectionner, ainsi si nous voulons 3 paquets, le seau laisse fuir 3 paquets par unité de temps. L'option --limit détermine le nombre de paquets qui peuvent remplir le seau par unité de temps, alors que l'option --limit-burst définit la contenance initiale du seau. Par conséquent, en définissant --limit 3/minute --limit-burst 5, puis en recevant 5 correspondances, le seau sera vidé. Après une attente de 20 secondes, le seau est rempli d'un nouveau jeton, et ainsi de suite jusqu'à ce que le paramètre --limit-burst soit atteint ou jusqu'à ce que les jetons soient tous utilisés.
Considérez l'exemple ci-dessous pour approfondir sur ce fonctionnement.
- On définit une règle avec les paramètres -m limit --limit 5/second --limit-burst 10/second. Le paramètre limit-burst du seau à jetons est fixé initialement à 10. Chaque paquet qui établit une correspondance avec la règle consomme un jeton.
- On reçoit alors des paquets qui correspondent à la règle, 1-2-3-4-5-6-7-8-9-10, tous arrivent dans un intervalle de 1/1000ème de seconde.
- Le seau de jetons se retrouve complètement vide. Et puisque le seau est vide, les paquets qui rencontrent la règle ne peuvent plus correspondre et poursuivent leur route vers la règle suivante, ou subissent le comportement par défaut de la chaîne.
- Pour chaque tranche de 1/5ème de seconde sans qu'un paquet ne corresponde, le compteur de jetons augmente de 1, jusqu'à un maximum de 10. Et 1 seconde après avoir reçu 10 paquets, on aura de nouveau 5 jetons de moins.
- Et naturellement, le seau sera vidé d'1 jeton par paquet reçu.
Tableau 14. Options de la correspondance limit
| Correspondance | --limit |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -m limit --limit 3/hour |
| Explication | Ceci définit le taux de correspondance moyen maximum pour la correspondance limit. Il est spécifié par un nombre suivi éventuellement d'une unité de temps. Les unités suivantes sont actuellement reconnues : /second, /minute, /hour et /day. La valeur par défaut est fixée à 3 correspondances par heure, soit 3/hour. Ceci indique à la correspondance limit combien de fois la correspondance avec un paquet est autorisé par unité de temps (par exemple par minute). |
| Correspondance | --limit-burst |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -m limit --limit-burst 5 |
| Explication | Ceci définit la réserve maximale (ou la salve) de la correspondance limit. Il indique à iptables le nombre maximum de paquets pouvant correspondre pendant l'unité de temps donnée. Ce nombre est décrémenté de 1 après chaque unité de temps (spécifiée par l'option --limit) pendant laquelle l'évènement ne s'est pas produit, jusqu'à atteindre la plus faible valeur, 1. Si l'évènement se produit de façon répétée, le compteur est alors incrémenté jusqu'à atteindre la valeur de réserve maximale, et ainsi de suite. La valeur par défaut de --limit-burst est 5. Pour comprendre simplement comment ceci fonctionne, utilisez le script d'exemple Limit-match.txt composé d'une règle. Grâce à ce script, vous pouvez voir vous-mêmes comment fonctionne le règle limit, en envoyant des paquets d'écho (de type ping) à des intervalles différents et en différentes rafales. Toutes les réponses d'écho seront bloquées jusqu'à ce que le seuil de réserve maximale soit de nouveau atteint. |
XIV-C-9. Correspondance MAC▲
La correspondance MAC (Ethernet Media Access Control) permet de sélectionner des paquets à partir de leur adresse MAC source. Lors de l'écriture de ce document, cette correspondance s'avère quelque-peu limitée, cependant elle pourrait être plus évoluée à l'avenir, donc plus utile.
Remarquez que l'utilisation de ce module impose de le charger explicitement avec l'option -m mac. Il est nécessaire de le rappeler ici vu le nombre de personne croyant pouvoir l'invoquer seulement par -m mac-source, ce qui n'est pas possible.
Tableau 15. Options de la correspondance MAC
| Correspondance | --mac-source |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -m mac --mac-source 00:00:00:00:00:01 |
| Explication | Cette correspondance permet de sélectionner des paquets à partir de leur adresse MAC source. L'adresse MAC doit être spécifiée de la forme XX:XX:XX:XX:XX:XX, autrement elle n'est pas valide. La correspondance peut être inversée avec le signe ! et ressemble alors à --mac-source ! 00:00:00:00:00:01. Autrement dit, ceci inverse le sens de la corrrespondance, en sélectionnant tous les paquets sauf ceux possédant l'adresse MAC spécifiée. Notez que comme les adresses MAC ne sont utilisées que dans les réseaux de type Ethernet, cette correspondance ne s'applique qu'aux interfaces Ethernet. La correspondance MAC est valide seulement dans les chaînes PREROUTING, FORWARD et INPUT, et nulle-part ailleurs. |
XIV-C-10. Correspondance mark▲
L'extension de correspondance mark permet de sélectionner des paquets à partir de leur marquage. Le marquage désigne un champ particulier, pris en charge uniquement au sein du noyau, et lié aux paquets circulant à travers la machine. Le marquage peut être employé par différentes routines du noyau pour des tâches comme de la régulation de trafic ou du filtrage. Aujourd'hui, il n'existe qu'un seul moyen de définir un marquage sous Linux, c'est la cible MARK dans iptables. Auparavant, il s'agissait de la cible FWMARK dans ipchains, et c'est pourquoi nombre de gens se réfère encore à FWMARK dans les documentations avancées sur le routage. Le champ de marquage est actuellement défini comme un entier non signé, soit 4294967296 valeurs possibles sur un système 32 bits. En d'autres termes, vous ne risquez pas de sitôt de dépasser cette limite.
Tableau 16. Options de la correspondance mark
| Correspondance | --mark |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -t mangle -A INPUT -m mark --mark 1 |
| Explication | Cette correspondance permet de sélectionner des paquets qui ont été préalablement marqués. Les marquages peuvent être positionnés avec la cible MARK développée dans la section suivante. Tous les paquets transitant par Netfilter se voient affectés d'un champ de marquage spécial. Notez que ce champ de marquage n'est propagé en aucune manière, que ce soit à l'intérieur ou à l'extérieur du paquet. Il reste exclusivement à l'intérieur de la machine qui l'a créé. Si le champ de marquage est égal à la valeur de l'option --mark, il y a correspondance. Le champ de marquage est un entier non signé, par conséquent 4294967296 différents marquages peuvent exister. Vous pouvez également utiliser un masque avec le marquage. Dans ce cas, la spécification de marquage ressemble, par exemple, à --mark 1/1. Quand un masque est spécifié, on effectue un ET logique avec le marquage spécifié avant de réaliser la comparaison réelle. |
XIV-C-11. Correspondance multiport▲
L'extension de correspondance multiport permet de spécifier plusieurs ports et intervalles et ports destination. Sans cette possibilité, vous devriez utiliser différentes règles du même genre, juste pour établir une correspondance avec différents ports.
Vous ne pouvez pas utiliser simultanément la correspondance de port standard et la correspondance multiport. Par exemple, il est inutile d'écrire : --sport 1024:63353 -m multiport --dport 21,23,80, car ça ne marchera pas. Si vous le faites quand même, iptables considèrera le premier élément de la règle et ignorera l'instruction multiport.
Tableau 17. Options de la correspondance multiport
| Correspondance | --source-port |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m multiport --source-port 22,53,80,110 |
| Explication | Cette correspondance coïncide avec plusieurs ports source. Au maximum, 15 ports peuvent être spécifiés. Les ports doivent être séparés par des virgules, comme dans l'exemple ci-dessus. Cette correspondance ne peut être employée qu'avec les correspondances -p tcp ou -p udp. C'est principalement une version améliorée de la correspondance classique --source-port. |
| Correspondance | --destination-port |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m multiport --destination-port 22,53,80,110 |
| Explication | Cette correspondance coïncide avec plusieurs ports destination. Elle fonctionne exactement de la même façon que la correspondance de port source mentionnée précédemment, excepté qu'elle s'applique aux ports destination. Elle dispose aussi d'une limite de 15 ports, et ne peut être employée qu'avec -p tcp et -p udp. |
| Correspondance | --port |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m multiport --port 22,53,80,110 |
| Explication | Cette extension de correspondance permet de sélectionner les paquets à partir à la fois de leur port destination et de leur port source. Elle fonctionne de la même façon que les correspondances --source-port et --destination-port présentées ci-dessus. Elle accepte 15 ports au maximum, et ne peut être employée qu'avec -p tcp et -p udp. Notez que la correspondance --port ne peut sélectionner que les paquets qui viennent et vont vers le même port, par exemple, du port 80 au port 80, du port 110 au port 110, etc. |
XIV-C-12. Correspondance owner▲
L'extension de correspondance owner permet de sélectionner des paquets à partir de l'identité du processus qui les a créés. Le propriétaire ("owner") peut être spécifié comme étant l'identifiant de l'utilisateur qui a lancé la commande en question, de son groupe, du processus, de la session, ou bien de la commande elle-même. A l'origine, cette extension a été écrite pour donner un exemple des utilisations possibles d'iptables. La correspondance owner fonctionne seulement dans la chaîne OUTPUT pour des raisons évidentes : il est presque impossible d'extraire des éléments d'information sur l'identité de l'instance ayant envoyé un paquet à partir de l'autre extrémité, et où a lieu le saut intermédiaire avant la destination finale. Et même dans la chaîne OUTPUT, ce n'est pas vraiment fiable puisque certains paquets peuvent ne pas avoir de propriétaire. Les célèbres paquets de ce genre sont, entre-autres, les réponses ICMP. Donc les réponses ICMP ne correspondront jamais.
Tableau 18. Options de la correspondance owner
| Correspondance | --uid-owner |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A OUTPUT -m owner --uid-owner 500 |
| Explication | Avec cette correspondance, le paquet est sélectionné s'il a été créé par l'identifiant d'utilisateur (UID) donné. Ceci permet d'établir une correspondance avec les paquets sortants basée sur celui qui les a créés. Une utilisation possible serait d'empêcher tout utilisateur autre que root d'ouvrir de nouvelles connexions extérieures au pare-feu. Une autre possibilité pourrait être d'empêcher tout le monde sauf l'utilisateur http d'envoyer des paquets à partir du port HTTP. |
| Correspondance | --gid-owner |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A OUTPUT -m owner --gid-owner 0 |
| Explication | Cette correspondance permet de sélectionner des paquets à partir de leur identifiant de groupe (GID). Ainsi on établit une correspondance avec tous les paquets associés au groupe auquel appartient l'utilisateur ayant créé le paquet. Par exemple, ceci permet d'empêcher tous les utilisateurs sauf ceux appartenant au groupe network de naviguer sur Internet, ou comme précédemment, d'autoriser seulement les membres du groupe http à créer des paquets sortants par le port HTTP. |
| Correspondance | --pid-owner |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A OUTPUT -m owner --pid-owner 78 |
| Explication | Cette correspondance permet de sélectionner des paquets à partir de l'identifiant de processus (PID) qui est responsable d'eux. Cette correspondance est un peu plus difficile à utiliser, mais il est possible, par exemple, d'autoriser seulement le PID 94 à envoyer des paquets par le port HTTP (si le processus HTTP n'est pas un fil d'exécution, bien sûr). Une autre alternative serait d'écrire un petit script qui récupère le PID à partir de la sortie d'une commande ps pour un "daemon" spécifique, et qui ajoute ensuite une règle pour le numéro récupéré. Pour donner un exemple, vous pouvez élaborer une règle comme celle présente dans l'exemple Pid-owner.txt. |
| Correspondance | --sid-owner |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A OUTPUT -m owner --sid-owner 100 |
| Explication | Cette correspondance permet de sélectionner des paquets à partir de l'identifiant de session (SID) utilisé par le programme en question. La valeur du SID d'un processus est celle du processus lui-même et de tous les processus découlant du processus d'origine. Ces derniers peuvent être un fil d'exécution ("thread"), ou un processus fils du processus d'origine. Donc par exemple, tous les processus HTTPD devraient posséder le même SID que leur processus parent (le processus HTTPD d'origine), si le HTTPD appartient à un fil d'exécution (comme la plupart des processus HTTPD, Apache et Roxen par exemple). Ceci est illustré par un petit script qui s'appelle Sid-owner.txt. Celui-ci pourrait éventuellement être lancé toutes les heures et enrichi de code supplémentaire pour vérifier que l'exécution du processus HTTPD est toujours en cours et le redémarrer sinon, avant de vider et redéfinir la chaîne OUTPUT si nécessaire. |
XIV-C-13. Correspondance type de paquet▲
Cette correspondance sert à apparier les paquets basés sur leur type. C'est à dire, ceux destinés à une personne précise, à tout le monde ou à un groupe de machines spécifique ou encore des utilisateurs. Ces trois groupes sont généralement appelés unicast, broadcast et multicast, comme nous l'avons vu dans le chapitre Rappel TCP/IP. La correspondance est chargée par la commande : -m pkttype.
Tableau 19. Options de correspondance type de paquet
| Correspondance | --pkttype |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A OUTPUT -m owner --pkttype unicast |
| Explication | La correspondance --pkttype sert à indiquer quel type de paquet apparier. Elle peut prendre soit unicast, broadcast ou multicast comme argument, voir l'exemple. Elle peut aussi être inversée par ! comme ceci : -m pkttype --pkttype ! broadcast, qui va apparier tous les autres types de paquets. |
XIV-C-14. Correspondance Recent▲
La correspondance Recent est une système plutôt important et complexe, qui nous permet d'apparier des paquets basés sur les événements récents. Exemple, si nous voulons voir une sortie de connexion IRC, nous pouvons placer l'adresse IP dans une liste d'hôtes, et avoir une autre règle qui permet des requêtes d'identification en retour d'un serveur IRC dans les 15 secondes de veille du paquet d'origine.
Avant nous pouvons avoir une vue plus précise de cette correspondance, et voyons comment elle fonctionne. En premier, nous utilisons différentes règles pour utiliser l'appariement récent. Celui-ci se sert de plusieurs listes d'événements récents. Par défaut la liste utilisée est DEFAULT. Nous créons une nouvelle entrée dans la liste avec cette option, ainsi une fois qu'une règle est complètement appariée (l'option placée est toujours une correspondance), nous pouvons ajouter une entrée dans la liste récente spécifiée. L'entrée de la liste contient un horodatage, et l'adresse source IP utilisée dans le paquet qui déclenche l'option. Une fois ceci fait, nous pouvons utiliser une série d'options différentes pour apparier cette information, comme la mise à jour des entrées d'horodatage, etc.
Enfin, si nous voulons pour quelque raison supprimer une entrée de la liste, nous pouvons le faire en supprimant la correspondance du module récent. Toutes les règles utilisant la correspondance Recent, doivent charger ce module (-m recent). Voyons en les options.
Tableau 20. Options de la correspondance Recent
| Correspondance | --name |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A OUTPUT -m recent --name examplelist |
| Explication | L'option "name" donne le nom de la liste à utiliser. Par défaut la liste DEFAULT est utilisée, ce qui n'est probablement pas ce que nous voulons si nous nous servons de plus d'une liste. |
| Correspondance | --set |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A OUTPUT -m recent --set |
| Explication | Ceci crée une nouvelle entrée dans la liste récente, qui contient un horodatage et l'adresse source IP de l'hôte qui a déclenché la règle. |
| Correspondance | --rcheck |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A OUTPUT -m recent --name examplelist --rcheck |
| Explication | L'option --rcheck vérifie si l'adresse IP source du paquet est dans la liste nommée. Si c'est le cas, la correspondance renvoit un "vrai", dans le cas contraire elle renverra un "faux". Cette option peut être inversée avec le signe !. Dans ce dernier cas, elle renverra vrai si l'adresse IP source n'est pas dans la liste, et faux si elle est dans la liste. |
| Correspondance | --update |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A OUTPUT -m recent --name examplelist --update |
| Explication | Cette correspondance est vraie si la source est disponible dans la liste spécifiée et met à jour le dernier horodatage dans la liste. Elle peut aussi être inversée par le ! devant le module. Exemple, ! --update. |
| Correspondance | --remove |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -m recent --name example --remove |
| Explication | Cette correspondance essaie de trouver l'adresse source du paquet dans la liste, et renvoit un vrai si le paquet est présent. Elle supprimera aussi l'entrée de liste correspondante de la liste. Cette commande peut être inversée avec le signe !. |
| Correspondance | --seconds |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -m recent --name example --check --seconds 60 |
| Explication | Cette correspondance n'est valide seulement qu'avec les commandes --check et --update. Le module --seconds est utilisé pour spécifier le délai de mise à jour de la colonne "dernier apperçu" dans la liste récente. Si la colonne dernier apperçu est plus ancienne qu'un certain nombre de secondes, la correspondance renvoit faux. Si la correspondance récent fonctionne anormalement, l'adresse source doit toujours être dans la liste pour un retour vrai de la correspondance. |
| Correspondance | --hitcount |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -m recent --name example --check --hitcount 20 |
| Explication | La correspondance --hitcount doit être utilisée avec les commandes --check ou --update, elle limitera la vérification aux seuls paquets vus par le compteur. Si cette correspondance est utilisée avec la commande --seconds, cela nécessite que le compteur de paquets spécifié soit vu dans le bloc de temps. Elle peut être inversée par le signe ! devant la commande. Avec la commande --seconds, elle indique le maximum de paquets qui peuvent avoir été vus durant le bloc de temps spécifié. Si les deux correspondances sont inversées, alors un maximum de paquets peuvent avoir été vus durant le dernier minimum de secondes. |
| Correspondance | --rttl |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -m recent --name example --check --rttl |
| Explication | La correspondance --rttl vérifie que la valeur TTL du paquet est la même que celle du paquet original utilisé pour placer l'entrée dans la liste récente. Ceci peut être utilisé pour vérifier que les adresses sources de personnes n'ont pas été mystifiées (spoofing) pour interdire aux autres l'accès à leur serveurs en faisant usage de la correspondance recent. |
| Correspondance | --rsource |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -m recent --name example --rsource |
| Explication | La correspondance --rsource indique au module recent de sauvegarder l'adresse source et les ports dans la liste recent. C'est le comportement par défaut. |
| Correspondance | --rdest |
| Noyau | 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -m recent --name example --rdest |
| Explication | --rdest est l'opposé de --rsource en ce qu'elle indique à la correspondance recent d'enregistrer l'adresse et le port de destination dans la liste recent. |
j'ai créé un petit exemple de script sur la façon d'utiliser la correspondance recent, vous pouvez le trouver dans la section Recent-match.txt.
En bref, c'est une pauvre variation de la machine d'état disponible dans netfilter. Cette version fut créé avec à l'esprit un serveur http, mais qui fonctionnera avec n'importe quelle connexion TCP. En premier, nous avons créé deux chaînes nommées http-recent et http-final. La chaîne http-recent est utilisée aux étapes du démarrage de la connexion, et pour la transmission des données, tandis que la chaîne http-final est utilisée pour les derniers FIN, FIN/ACK dans l'établissement de la liaison.
C'est une très mauvaise alternative pour la machine d'état et elle ne dispose pas de toutes les possibilités de la machine d'état. Cependant, c'est un bon exemple de ce qui peut être fait avec la correspondance Recent sans être trop spécifique. N'utilisez pas cet exemple en production. Il est lent, gère mal les cas spéciaux, et ne doit être jamais utilisé que comme un exemple.
Par exemple, il ne gère pas les ports fermés dans une connexion, les établissements de liaison FIN asynchrones (où une des parties connectée se ferme, tandis que l'autre continue d'envoyer des données), etc.
Suivons un paquet à travers l'exemple de la table de règles. D'abord le paquet entre dans la chaîne INPUT, et nous l'envoyons à la chaîne http-recent.
- Le premier paquet sera un paquet SYN, et n'aura pas de bit ACK, FIN ou RST placé. Il est apparié en utilisant la ligne --tcp-flags SYN,ACK,FIN,RST SYN. À ce niveau nous ajoutons la connexion à httplist avec la ligne -m recent --name httplist --set. Enfin nous acceptons le paquet.
- Après le premier paquet nous recevons un paquet SYN/ACK indiquant que le paquet SYN a été reçu. Ceci peut être apparié en utilisant la ligne --tcp-flags SYN,ACK,FIN,RST SYN,ACK. FIN et RST sont illégaux à ce niveau. Nous mettons à jour l'entrée dans httplist par -m recent --name httplist --update et finalement nous avons l'ACCEPT du paquet.
- Maintenant nous obtenons un paquet final ACK, venant du créateur de la connexion, nous permettant de savoir que le SYN/ACK a été envoyé par le serveur. SYN, FIN et RST sont illégaux à ce point de la connexion, et la ligne ressemblera à --tcp-flags SYN,ACK,FIN,RST ACK. Nous mettons à jour la liste de la même façon que dans l'étape précédente, et nous avons l'ACCEPT.
- À ce niveau, la transmission de données peut démarrer. La connexion ne contiendra jamais aucun paquet SYN maintenant, mais contiendra des paquets ACK pour permettre de savoir que les données sont envoyées. Chaque fois que nous voyons un paquet comme celui-là, nous mettons à jour la liste et ACCEPT les paquets.
- La transmission peut être terminée de deux façons, la plus simple est le paquet RST. RST réinitialisera la connexion et la coupera. Avec FIN, la connexion sera coupée sans plus envoyer de données. Le destinataire du FIN, pourra toujours envoyer des données, et nous arrivons à l'étape finale de la connexion.
- Dans les chaînes http-recent-final nous vérifions si le paquet est toujours dans la httplist, et si c'est le cas, nous l'envoyons à la chaîne http-recent-final1. Dans cette chaîne nous supprimons la connexion de la httplist l'ajoutons à la liste http-recent-final. Si la connexion a déjà été supprimée et déplacée vers la liste http-recent-final, nous envoyons le paquet vers la chaîne http-recent-final2.
- Dans la chaîne http-recent-final2, nous attendons que la partie non fermée finisse d'envoyer ses données, et fermons ensuite la connexion. Une fois ceci fait, la connexion est tout simplement supprimée.
Comme nous l'avons vu la liste recent peut devenir tout à fait complexe, mais elle nous donne un vaste éventail de possibilités si nécessaire. Encore une fois, nous ne réinventons pas la roue. Si la fonctionnalité que vous désirez est déjà implémentée, utilisez la au lieu d'essayer de créer votre propre solution.
XIV-C-15. Correspondance state▲
L'extension de correspondance state est associée au code de traçage de connexion dans le noyau. La correspondance d'état accède à l'état du traçage de connexion des paquets grâce à la machine de "conntracking". Elle permet de savoir dans quel état se trouve la connexion, et fonctionne pour quasiment tous les protocoles y-compris les protocoles sans état tels que ICMP et UDP. Dans tous les cas, la connexion est sujette à un dépassement de temps établi par défaut ("default timeout") et sera, le cas échéant, supprimée de la base de données du traçage de connexion. Cette correspondance exige d'être chargée explicitement en ajoutant la directive -m state à la règle. Vous disposerez alors d'une nouvelle correspondance appelée state. Le concept de correspondance d'état est couvert plus en détail dans le chapitre La machine d'état, étant donné que le sujet est assez vaste.
Tableau 21. Correspondances de state
| Correspondance | --state |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -m state --state RELATED,ESTABLISHED |
| Explication | Cette option indique à la correspondance state dans quels états doivent être les paquets pour être sélectionnés. Actuellement, 4 états sont disponibles : INVALID, ESTABLISHED, NEW et RELATED. INVALID signifie que le paquet n'est associé à aucun flux, ni à aucune connexion connus, et qu'il peut contenir des données ou des en-têtes erronés. ESTABLISHED signifie que le paquet est lié à une connexion déjà établie, qui a vu passer des paquets dans les deux directions et qui est considérée valide. NEW signifie que le paquet a démarré ou démarrera une nouvelle connexion, ou bien qu'il est associé à une connexion qui n'a pas vu passer des paquets dans les deux directions. Enfin, RELATED signifie que le paquet démarre une nouvelle connexion et qu'il est associé à une connexion déjà établie. Ceci peut évoquer par exemple un transfert de données par FTP, ou une erreur ICMP associée à une connexion TCP ou UDP. Notez que l'état NEW n'examine pas les bits SYN des paquets TCP qui tentent de démarrer une nouvelle connexion. Par conséquent, cet état ne devrait pas être utilisé tel quel dans les situations où il n'existe qu'un seul pare-feu, ou quand il n'y a pas d'équilibrage de charge entre les différents pare-feux. Cependant, cet état se révèle utile dans certains cas. Pour en savoir plus, consultez le chapitre La machine d'état. |
XIV-C-16. Correspondance TCPMSS▲
La correspondance tcpmss est utilisée pour apparier un paquet basé sur la Maximum Segment Size (Tailles maximum de segment) dans TCP. Ceci vérifie seulement la validité des paquets SYN et SYN/ACK. Pour une explication plus détaillée de la valeur MSS, voir l'appendice, Options TCP la RFC 793 - Transmission Control Protocol et la RFC 1122 - Requirements for Internet Hosts - Communication Layers. Cette correspondance est chargée en utilisant -m tcpmss et prend uniquement cette option.
Tableau 22. Options de correspondance TCPMSS
| Correspondance | --mss |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp --tcp-flags SYN,ACK,RST SYN -m tcpmss --mss 2000:2500 |
| Explication | L'option --mss indique à la correspondance tcpmss quel Maximum Segment Sizes apparier. Ceci peut être soit une simple valeur MSS, soit une plage de valeurs MSS séparées par :. La valeur peut être inversée par le signe !, comme dans l'exemple suivant : -m tcpmss ! --mss 2000:2500 Cet exemple vérifiera toutes les valeurs MSS, sauf les valeurs comprises dans la plage de 2000 à 2500. |
XIV-C-17. Correspondance TOS▲
La correspondance TOS peut servir à sélectionner les paquets à partir de leur champ de TOS. TOS signifie type de service; il est constitué de 8 bits et se situe dans l'en-tête IP. Cette correspondance est chargée explicitement en ajoutant -m tos à la règle. Elle est normalement utilisée afin d'informer les hôtes intermédiaires de l'ordre de priorité du flux et de son contenu (ce n'est pas vraiment le cas, mais il informe des besoins spécifiques au flux, comme une réexpédition aussi rapide que possible, ou un impératif de débit). Les différents routeurs et administrateurs gèrent ces valeurs de façon variable. La plupart ne s'en préoccupent pas du tout, alors que d'autres font de leur mieux pour servir les paquets en question et les données qu'ils contiennent.
Tableau 23. Correspondance TOS
| Correspondance | --tos |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A INPUT -p tcp -m tos --tos 0x16 |
| Explication | Cette correspondance s'utilise tel que décrit ci-dessus. Elle sélectionne les paquets à partir de leur champ de TOS et de sa valeur. Ceci peut être employé avec le programme iproute2 et les fonctions avancées de routage de Linux pour effectuer un marquage des paquets pour une usage ultérieur. La correspondance prend en option une valeur hexadécimale ou numérique, ou éventuellement un des noms fournis par la commande 'iptables -m tos -h'. Actuellement, elle donne les noms suivants : Minimize-Delay 16 (0x10), Maximize-Throughput 8 (0x08), Maximize-Reliability 4 (0x04), Minimize-Cost 2 (0x02), et Normal-Service 0 (0x00). Minimize-Delay signale de minimiser le retard pour les paquets qui traversent - les services classiques qui requièrent ceci peuvent être, par exemple, telnet, SSH et FTP-control. Maximize-Throughput précise de trouver un chemin qui offre le plus haut débit possible - un protocole typique est FTP-data. Maximize-Reliability indique de maximiser la fiabilité de la connexion, donc d'utiliser des lignes aussi fiables que possible - deux exemples typiques sont BOOTP et TFTP. Minimize-Cost signale de minimiser le coût des paquets qui traversent tous les liens vers le client ou le serveur ; par exemple, déterminer la route qui offre le voyage le moins cher de bout en bout. Des exemples de protocoles classiques qui peuvent l'utiliser sont RTSP ("Real Time Stream Control Protocol" ou protocole de contrôle de flux temps-réel) et d'autres protocoles de flux vidéo/radio. Enfin, Normal-Service désigne tout protocole classique n'ayant aucun besoin particulier. |
XIV-C-18. Correspondance TTL▲
La correspondance TTL permet de sélectionner les paquets à partir de leur champ TTL ("Time To Live" ou durée de vie) localisé dans l'en-tête IP. Le champ TTL contient 8 bits de données, et il est décrémenté de 1 à chaque fois qu'il est traité par un hôte intermédiaire entre le client et l'hôte destinataire. Si le TTL atteint 0, un message ICMP type 11 code 0 (TTL égal à 0 pendant le transit) ou code 1 (TTL égal à 0 pendant le réassemblage) est transmis à l'expéditeur du paquet pour l'informer du problème. Cette correspondance est utilisée seulement pour sélectionner les paquets à partir de leur TTL, et non pour effectuer un changement quel qu'il soit. Celui-ci, soit dit en passant, s'applique à tout type de correspondance. Pour charger cette correspondance, vous devez ajouter -m ttl à la règle.
Tableau 24. Correspondances TTL
| Correspondance | --ttl |
| Noyau | 2.3, 2.4, 2.5 et 2.6 |
| Exemple | iptables -A OUTPUT -m ttl --ttl 60 |
| Explication | Cette option de correspondance permet de spécifier la valeur TTL à sélectionner. Cette option requiert une valeur numérique et établit une correspondance avec cette valeur dans le paquet. Aucune inversion n'est disponible et il n'y a rien d'autre, en particulier, à sélectionner. Mais ceci peut être utile, par exemple, pour déboguer votre réseau local - c'est-à-dire les hôtes de votre LAN qui semblent présenter des problèmes de connexion avec un hôte sur Internet - ou pour trouver d'éventuelles entrées de chevaux de Troie, etc. Les possibilités de cette option sont relativement limitées, cependant son intérêt dépend essentiellement de votre imagination. Un exemple pourrait être de trouver des hôtes avec de mauvaises valeurs par défaut de TTL (pouvant être la conséquence d'un pile TCP/IP mal implémentée, ou simplement d'un défaut de configuration). |
XIV-C-19. 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.