Correspondances explicites

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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

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

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

5. Et naturellement, le seau sera vidé d'1 jeton par paquet reçu.

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.

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.

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.

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.

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.

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.

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.

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

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

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

4. À 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.

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

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

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

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.

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.

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.

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.

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.