Didacticiel sur Iptables, version 1.2.0

XVIII. Exemples de scripts▲

L'objectif de ce chapitre est de vous fournir une brève explication de chaque script disponible avec ce didacticiel, et quels services ils fournissent. Ces scripts ne sont en aucun cas parfaits, et peuvent ne pas correspondre tout à fait à ce que vous en attendez. C'est une aide pour vous assister dans la création de scripts selon vos besoins. La première section indique la structure que j'ai établie dans chaque script, ansi nous pourrons retrouver notre chemin plus facilement.

XVIII-A. Structure du script rc.firewall.txt▲

Tous les scripts de ce didacticiel ont été écrits pour une structure spécifique. La raison pour ça est qu'ils sont assez similaires entre eux ce qui permet de façon aisée de voir les différences. Cette structure est à peu près bien documentée dans ce bref chapitre. Il vous donnera un idée de pourquoi ces scripts ont été écrits, et pourquoi j'ai choisi cette structure.

Même si c'est la structure que j'ai choisi, notez qu'elle peut ne pas être la meilleure pour vos scripts. Elle vise une lecture et une compréhension faciles pour nos besoins.

XVIII-A-1. La structure▲

C'est la structure de tous les scripts de ce didacticiel. S'ils diffèrent quelque part c'est probablement une erreur de ma part, sauf si spécifié explicitement.

Configuration - En premier lieu nous avons les options de configuration que le reste du script utilisera. Les options de configuration seront toujours les premières dans chaque script.
- Internet - C'est la section de configuration qui concerne la connexion Internet. Vous pouvez la passer si vous n'avez pas de connexion Internet. Notez qu'il pourrait y avoir d'avantage de sous-sections ici, mais nous n'indiquons que celles concernant l'Internet.
- - DHCP - Si nécessaire nous ajouterons les options de configuration spécifique à DHCP ici.
  - PPPoE - Si l'utilisateur désire ce script spécifique, et qu'il utilise une connexion PPPoE, nous ajouterons les options ici.
- LAN - S'il y a un réseau local derrière le pare-feu, nous ajouterons les options le concernant ici. C'est le cas la plupart du temps, donc cette section sera toujours disponible.
- DMZ - Si nécessaire, nous ajouterons la configuration de la DMZ ici. Beaucoup de scripts n'ont pas cette section, principalement parce que dans un réseau domestique, ou pour une petite entreprise il n'y en a pas.
- Localhost - Cette section concerne l'hôte local. Ces options ne changent pratiquement jamais.
- iptables - Section qui concerne la configuration spécifique d'iptables. Dans la plupart des cas elle ne nécessite qu'une variable qui nous indique où iptables est situé.
- Other - S'il y a d'autres options et variables spécifiques, elles devront être placées dans la sous-section concernée (si elles appartiennent à la connexion Internet, elles seront placées dans la sous-section Internet, etc.). Si elles ne vont nulle part elles seront placées dans les sous-sections des options de configuration.
Module loading - Cette section contient une liste de modules. La première partie concerne les modules nécessaires, la seconde les modules non nécessaires.

Notez que certains modules peuvent accroître la sécurité, ou ajouter certaines possibilités, et donc peuvent être ajoutés même s'ils ne sont pas obligatoires. Ils seront indiqués dans certains cas dans les scripts.

- Required modules - Cette section contient les modules obligatoires et, peut être, des modules spéciaux qui ajoutent à la sécurité ou des services supplémentaires pour l'administrateur ou les clients
- Non-required modules - Section qui contient les modules non obligatoires pour les opérations normales. Tous ces modules peuvent être commentés par défaut. Si vous voulez ajouter le service en question, décommentez-le.
proc configuration - Cette section concerne toute configuration particulière nécessaire pour le système de fichiers proc. Si certaines de ces options sont obligatoires, elles seront listées ici, elles sont commentées par défaut, et indiquées comme configurations proc non obligatoires. Beaucoup de configurations proc utiles seront indiquées, mais pas toutes et de loin.
- Required proc configuration - Section qui contient les configurations proc obligatoires pour que le script fonctionne. Elle peut aussi contenir des configurations qui accroissent la sécurité, ou ajoutent des services supplémentaires pour l'administrateur ou les clients.
- Non-required proc configuration - Cette section pourrait contenir les configurations proc non obligatoires mais qui peuvent être utiles. Elles sont toutes commentées, car elles ne sont pas nécessaires pour l'instant pour que le script fonctionne. Cette liste n'est de loin pas complète.
rules set up - Maintenant le script est prêt pour y insérer la table de règles. J'ai choisi de diviser toutes les règles en noms de table et de chaîne dans la table de règles, pour rendre plus facile à lire ce qui suit. Toutes les chaînes utilisateur spécifiées sont créées avant de faire quoi que ce soit d'autre. J'ai aussi choisi de placer les chaînes et leur spécifications de règles dans le même ordre que la sortie de la commande iptables -L.
- Filter table - En premier nous voyons la table filter et son contenu. En priorité nous configurons toutes les stratégies de la table.
- - Set policies - Configuration des stratégies par défaut pour les chaînes système. Normalement je met les stratégies à DROP pour les chaînes de la table filtre, et spécifie ACCEPT les services et les flux que je veux autoriser. De cette façon nous nous débarrassons de tous les ports que nous ne voulons pas autoriser.
  - Create user specified chains - Ici nous créons toutes les chaînes utilisateur que nous voulons utiliser dans cette table. Nous ne pourrons pas utiliser ces chaînes dans les chaînes système si elles ne sont pas déjà créées, le mieux est de le faire le plus tôt possible.
  - Create content in user specified chains - Après avoir créé les chaînes utilisateur nous pouvons rentrer toutes les règles dans ces chaînes. Vous pouvez aussi les rentrer plus tard dans le script, c'est comme vous voulez.
  - INPUT chain - Ici nous ajouterons toutes les règles de la chaîne INPUT.

Nous utiliserons le modèle de sortie de la commande iptables -L comme vous pourrez le voir. Il n'y a pas de raison pour que vous conserviez cette structure, cependant, essayez d'éviter de mélanger les données provenant de différentes tables et chaînes car elles deviendraient plus difficiles à lire et à résoudre les problèmes.

- - FORWARD chain - Ici nous ajoutons les règles de la chaîne FORWARD.
  - OUTPUT chain - En dernier, nous ajoutons les règles de la chaîne OUTPUT.
- nat table - Après la table filtre occupons nous de la table nat. Nous le faisons après la table filtre pour plusieurs raisons. La première c'est que nous ne voulons pas activer l'ensemble du mécanisme de forwarding et les fonctions NAT trop tôt, ce qui pourrait conduire les paquets à traverser le pare-feu au mauvais moment (i.e., quand le NAT est activé, mais que les règles de filtre ne le sont pas). Ainsi, je vois la table nat comme une sorte de couche qui se lie à la table filter et en quelque sorte l'entoure. La table filter sera donc le noyau, tandis que la table nat agira comme une couche autour de la table filter, et enfin la table mangle entourera la table nat comme une seconde couche. Ceci peut être faux dans certaines perspectives mais pas trop loin de la réalité.
- - Set policies - En premier nous plaçons les stratégies par défaut dans la table nat. Normalement, avec la stratégie ACCEPT placée au début ce sera suffisant. Cette table n'est pas utilisée pour le filtrage, et les paquets ne seront pas DROP ici, car certaines choses dangereuses peuvent survenir dans certains cas. Je laisse ces chaînes à ACCEPT car il y a aucune raison de ne pas le faire.
  - Create user specified chains - Ici nous créons les chaînes utilisateur que nous voulons insérer dans la table nat. Normalement je n'en ai pas, mais j'ai ajouté cette section juste au cas où. Notez que les chaînes utilisateur doivent être créées avant qu'elles soient utilisées dans les chaînes système.
  - Create content in user specified chains - Maintenant il est temps d'ajouter toutes les règles des chaînes utilisateur dans la table nat. C'est la même chose que pour les chaînes utilisateur dans la table filter. Nous les ajoutons ici car il n'y a aucune raison de ne pas le faire.
  - PREROUTING chain - La chaîne PREROUTING est utilisée pour faire du DNAT sur les paquets quand nous en avons besoin. Dans beaucoup de scripts cette fonctionnalité n'est pas utilisée, ou alors elle est désactivée. La raison en étant que nous ne voulons pas créer de gros trous dans notre réseau local sans savoir ce que nous faisons. Dans certains scripts nous l'avons activé par défaut car le seul but de ces scripts et de procurer certains services.
  - POSTROUTING chain - La chaîne POSTROUTING sera utilisée par les scripts que j'ai écrit car la plupart d'entre eux dépendent du fait que nous avons un ou plusieurs réseaux locaux que nous voulons protéger de l'Internet. Principalement nous essaierons d'utiliser la cible SNAT, mais dans certains cas nous devrons utiliser la cible MASQUERADE.
  - OUTPUT chain - Cette chaîne est à peine utilisée dans les scripts. Je n'ai trouvé aucune bonne raison de m'en servir.
- mangle table - La dernière table est la table mangle. Normalement je n'utilise pas cette table, sauf pour des besoins spécifiques, comme masquer toutes les machines pour utiliser le même TTL ou pour changer les champs TOS, etc. J'ai choisi de laisser ces parties du script plus ou moins vides, avec quelques exceptions dans lesquelles j'ai ajouté des exemples.
- - Set policies - Place les stratégies par défaut dans la chaîne. C'est la même chose que pour la table nat, à peu près. Cette table n'est pas faite pour le filtrage. Je n'ai placé aucune stratégie dans aucun des scripts de la table mangle, et vous êtes encouragés à en faire autant.
  - Create user specified chains - Crée toutes les chaînes utilisateur. Comme j'ai laissé vide la table mangle, je n'ai créé aucune chaîne ici. Cependant, cette section a été ajoutée juste au cas où vous en auriez besoin dans le futur.
  - Create content in user specified chains - Ici plus aucun script de ce didacticiel ne contiendra des règles.
  - PREROUTING - Ici plus aucun script de ce didacticiel ne contiendra des règles.
  - INPUT chain - Ici plus aucun script de ce didacticiel ne contiendra des règles.
  - FORWARD chain - Ici plus aucun script de ce didacticiel ne contiendra des règles.
  - OUTPUT chain - Ici plus aucun script de ce didacticiel ne contiendra des règles.
  - POSTROUTING chain - Ici plus aucun script de ce didacticiel ne contiendra des règles.

Nous expliquerons en détail comment chaque script est structuré et pourquoi.

Notez que ces descriptions sont assez brèves, et doivent être vues comme une rapide explication.

XVIII-B. rc.firewall.txt▲

Le rc.firewall.txt est le noyau sur lequel le reste des scripts est basé. Le chapitre Fichier rc.firewall expliquera chaque détail du script. Il a été écrit principalement pour un réseau domestique dual. Par exemple, vous avez un LAN et une connexion Internet. Ce script suppose également que vous avez une IP fixe vers l'Internet, et donc que vous n'utilisez pas DHCP, PPP ou SLIP ou un autre protocole qui assigne les IP automatiquement. Si vous cherchez un script pour cela, regardez de plus près rc.DHCP.firewall.txt.

Le script rc.firewall.txt nécessite que les options suivantes soient compilées statiquement dans le noyau, ou comme modules. Sans cela des parties du script seront inutilisables. Vous pourrez avoir besoin de d'avantage d'options, tout dépend de ce que vous voulez utiliser.

CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_TARGET_LOG

XVIII-C. rc.DMZ.firewall.txt▲

Le script rc.DMZ.firewall.txt a été écrit pour les personnes qui ont un réseau de confiance, une DMZ et une connexion Internet. La DMZ est dans ce cas NATée pair-à-pair et nécessite de faire de l'alias d'IP dans le pare-feu, i.e., la machine doit reconnaître les paquets de plus d'une IP. Il existe plusieurs moyens de faire cela, un de ceux-ci est de placer le NAT pair-à-pair, un autre est de créer un sous-réseau, donnant au pare-feu une IP interne et une externe. Vous pouvez alors placer ces IP sur la machine DMZ comme vous le voulez. Notez que ça vous "occupera" deux adresses, une pour l'adresse de diffusion et l'autre pour l'adresse réseau. C'est à vous de décider de l'implémenter ou non. Ce didacticiel vous donne les outils pour créer un pare-feu et faire du NAT, mais ne vous dira pas exactement tout en fonction de vos besoins spécifiques.

Le script rc.DMZ.firewall.txt nécessite que ces options soient compilées dans votre noyau, soit de façon statique soit comme modules. Sans ces options vous ne pourrez pas utiliser les fonctionnalités de ce script. Vous obtiendriez des erreurs sur les modules et les cibles/sauts ou les correspondances. Si vous envisagez de faire du contrôle de trafic ou quelque chose comme ça, vous devez vérifier que toutes les options obligatoires sont compilées dans votre noyau.

CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_TARGET_LOG

Vous devez avoir deux réseaux internes pour ce script comme vous pouvez le voir sur l'image. L'un utilise la plage IP 192.168.0.0/24 et correspond au réseau de confiance. L'autre utilise la plage IP 192.168.1.0/24 et est la DMZ dans laquelle nous faisons du NAT pair-à-pair. Par exemple, si quelqu'un sur l'Internet envoit un paquet vers notre DNS_IP, nous utilisons DNAT pour expédier ce paquet vers notre DNS sur le réseau DMZ. Quand le DNS voit le paquet, il sera destiné à l'adresse IP du réseau interne DNS, et pas vers l'IP DNS externe. Si le paquet n'était pas traduit, le DNS ne répondrait pas à ce paquet. Voyons à quoi ressemble le code DNAT :

Sélectionnez

$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $DNS_IP \
--dport 53 -j DNAT --to-destination $DMZ_DNS_IP

En premier, DNAT ne peut être exécuté que dans la chaîne PREROUTING de la table nat. Le protocole TCP sur $INET_IFACE avec une destination IP qui apparie $DNS_IP, est dirigé vers le port 53, qui est le port TCP pour la zone de transferts entre serveurs de noms. Ensuite nous spécifions où nous voulons envoyer le paquet avec l'option --to-destination et lui donnons la valeur de la $DMZ_DNS_IP, en d'autres termes l'IP de notre réseau DNS ou DMZ. C'est du DNAT de base. Après ça la réponse au paquet DNATé est envoyée au pare-feu, qui le "déNATe" automatiquement.

Nous devrions en avoir suffisamment compris pour pouvoir saisir l'ensemble de ces scripts. S'il y a quelque chose que vous ne comprenez pas dans ce didacticiel, faites moi un mail c'est sans doute une erreur de ma part.

XVIII-D. rc.DHCP.firewall.txt▲

Le script rc.DHCP.firewall.txt est à peu près identique au rc.firewall.txt. Cependant, il n'utilise pas la variable STATIC_IP, ce qui est la principale différence avec le script rc.firewall.txt. La raison est qu'il ne fonctionne pas avec une connexion IP dynamique. Les modifications à effectuer sur le script d'origine sont minimes, cependant, certaines personnes m'ont demandé si ce script est une bonne solution. Il permet d'utiliser des connexions DHCP, PPP et SLIP pour l'Internet.

Le script rc.DHCP.firewall.txt nécessite que les options suivantes soient compilées statiquement dans le noyau, ou comme modules, pour fonctionner correctement.

CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_TARGET_MASQUERADE
CONFIG_IP_NF_TARGET_LOG

le principal changement dans ce script consiste en la suppression de la variable STATIC_IP et à supprimer toute référence à cette variable. Le script filtrera maintenant sur la variable INET_IFACE. En d'autres termes -d $STATIC_IP a été changé en -i$INET_IFACE. C'est la seule modification qu'il est réellement nécessaire de faire.

Il y a plusieurs choses à penser. Nous ne pouvons pas faire de filtrage sur ce qui dépend de la chaîne INPUT, par exemple, --in-interface $LAN_IFACE --dst $INET_IP. Ceci nous force à faire du filtrage uniquement sur les interfaces dans le cas où les machines internes doivent accéder à une IP Internet adressable. Un bon exemple est si nous faisont tourner un serveur HTTP sur notre pare-feu. Si nous allons sur la page principale (i.e., http://192.168.0.1/), qui contient des liens statiques vers le même hôte (i.e., http://foobar.dyndns.net/fuubar.html), qui pourrait être une solution dyndns, nous rencontrons un problème. La machine NATée cherchera le DNS pour l'IP du serveur HTTP, et ensuite tentera d'accéder à cette IP. Dans le cas où nous filtrons sur l'interface et l'IP, la machine NATée sera incapable d'accéder au HTTP car la chaîne INPUT DROP les paquets. Ceci s'applique aussi dans le cas où nous avons une IP statique, mais dans ces cas nous pouvons contourner le problème en ajoutant des règles qui apparient les paquets de l'interface LAN pour notre INET_IP, et les plaçons à ACCEPT.

Comme vous l'avez vu plus haut, ce peut être une bonne idée de faire un script qui traite les IP dynamiques d'une meilleure façon. Nous pouvons par exemple faire un script qui récupère l'IP depuis ifconfig et l'ajoute à une variable, dans l'initialisation de la connexion Internet. Un bon moyen pour faire ça, serait d'utiliser, par exemple, les scripts ip-up fournis par pppd ou tout autre programme. Voir sur le site linuxguruz.org qui possède une quantité de scripts disponibles en téléchargement. Le lien est dans l'annexe Autres ressources et liens.

Ce script peut être un peu moins sûr que le rc.firewall.txt. Je vous préviens qu'il est d'avantage ouvert aux attaques depuis l'extérieur.

Il est également possible d'ajouter certaines choses comme cela dans votre script :

Sélectionnez

INET_IP=`ifconfig $INET_IFACE | grep inet | cut -d : -f 2 | \
cut -d ' ' -f 1`

La commande ci-dessus récupère automatiquement l'adresse IP de la variable $INET_IFACE, affiche la ligne qui contient l'adresse IP et la transforme en une adresse IP gérable. Pour une façon plus élaborée de faire ceci, vous pouvez appliquer des bouts de code disponibles dans le script retreiveip.txt, qui récupère automatiquement votre adresse IP Internet quand vous lancez le script. Notez que cette façon de faire peut conduire à un comportement un peu aléatoire, comme le blocage des connexions depuis votre pare-feu en interne. Les comportements étranges les plus courants sont décrits dans la liste suivante.

Si le script est lancé depuis un script exécuté par, par exemple, le démon PPP, il suspendra toutes les connexions actives à cause des règles NEW non-SYN (voir la section Paquets état NEW sans bit SYN placé).
Si vous avez des règles statiques, il est plus difficile d'ajouter et d'enlever ces règles tout le temps, sans modifier celles déjà existantes. Par exemple, si vous voulez bloquer l'accès des hôtes de votre LAN au pare-feu, mais en même temps exécuter un script depuis le démon PPP, comment ferez vous sans effacer vos règles actives qui bloquent le LAN ?
Ce n'est pas nécessairement compliqué, mais peut conduire à des compromis sur la sécurité. Si le script est très simple, il est facile de corriger les problèmes.

XVIII-E. rc.UTIN.firewall.txt▲

Le script rc.UTIN.firewall.txt bloque le LAN qui est situé derrière nous. En d'autres termes, nous ne faisons pas confiance aux réseaux auxquels nous sommes connectés. Nous n'autorisons personne de notre LAN à se connecter à l'Internet, sauf pour des tâches spécifiques. Les seules choses autorisées sont les accès POP3, HTTP et FTP. Nous ne faisons également pas confiance aux utilisateurs internes pour accéder au pare-feu comme pour les utilisateurs sur l'Internet.

Le script rc.UTIN.firewall.txt nécessite que les options suivantes soient compilées en statique dans le noyau, ou en modules. Sans une ou plusieurs des ces options, le script ne fonctionnera pas correctement ou sera même inutilisable. Si vous modifiez ce script vous aurez peut être besoin d'options supplémentaires qui devront aussi être compilées dans le noyau.

CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_TARGET_LOG

Le script suit la règle d'or de ne faire confiance en personne, pas même en vos propres employés. C'est malheureux à dire, mais une grande partie du hacking/cracking dans une entreprise provient du personnel interne. Ce script vous donne quelques clés pour remédier à ça. Il n'est pas très différent du script rc.firewall.txt.

XVIII-F. rc.test-iptables.txt▲

Le script rc.test-iptables.txt peut être utilisé pour tester toutes les différentes chaînes, mais il peut nécessiter quelques adaptations en fonction de votre configuration, comme l'activation de ip_forwarding, ou le masquerading, etc. Il fonctionnera dans la plupart des cas, si vous avez une configuration des tables de base chargées dans le noyau. Certaines cibles LOG sont activées ce qui permet de journaliser les requêtes et les réponses aux pings. De cette façon vous aurez des informations sur les chaînes traversées et dans quel ordre. Par exemple, lancez ce script et faites :

Sélectionnez

ping -c 1 host.on.the.internet

Et tail -n 0 -f /var/log/messages pendant que vous exécutez la première commande. Ceci vous indiquera les diverses chaînes utilisées, et dans quel ordre, jusqu'à ce que les entrées du journal s'arrêtent pour quelque raison.

Ce script a été écrit dans un but de test uniquement. En d'autres termes, ce n'est pas une bonne idée d'avoir des règles comme celles-là qui journalisent tout car vos fichiers de log se rempliront très vite et il pourrait être confronté à une attaque de type DoS.

XVIII-G. rc.flush-iptables.txt▲

Le script rc.flush-iptables.txt ne devrait pas être appelé script à proprement parler. Ce script rc.flush-iptables.txt réinitialise toutes les tables et les règles. Il commence en activant par défaut les stratégies en mode ACCEPT sur les chaînes INPUT, OUTPUT et FORWARD de la table filter. Après ça nous réinitialisons les stratégies des chaînes PREROUTING, POSTROUTING et OUTPUT de la table nat. Nous faisons ça en premier ainsi nous ne sommes pas gênés par les fermetures de connexion. Ce script a pour but la mise en place de votre pare-feu et de le tester.

Après cela nous réinitialisons toutes les chaînes, en premier la table filter et ensuite la table NAT. De cette façon nous savons qu'il n'y a pas de règles redondantes. Quand tout ceci est fait, nous passons à la section suivante dans laquelle nous supprimons toutes les chaînes utilisateur dans les tables NAT et filter. Quand cette étape est terminée, nous considérons que le script est achevé. Vous pouvez ajouter des règles pour réinitialiser votre table mangle si vous l'utilisez.

Un dernier mot. Certaines personnes m'ont demandé de mettre ce script dans la syntaxe du rc.firewall original utilisé par Red Hat Linux où vous tapez quelque chose comme rc.firewall start et le script démarre. Cependant, je ne l'ai pas fait car il s'agit d'un didacticiel destiné à vous donner des idées, et il ne devra pas grossir démesurément avec des syntaxes particulières. Ajouter des syntaxes et autres scripts shell peut aussi le rendre plus difficile à lire.

XVIII-H. Limit-match.txt▲

Le script limit-match.txt est un mirroir du script test qui vous permet de tester la correspondance limit et de voir comment elle fonctionne. Chargez ce script, et ensuite envoyez des paquets à différents intervalles. Toutes les réponses seront bloquées jusqu'à ce que le seuil limite soit atteint.

XVIII-I. Pid-owner.txt▲

Le script pid-owner.txt est un petit exemple qui indique comment vous pouvez utiliser la correspondance PID. Il ne fait rien de réel, mais vous permet une fois exécuté la commande iptables -L -v de savoir quelle règle est actuellement appariée.

XVIII-J. Recent-match.txt▲

Ce script recent-match.txt indique comment la correspondance recent est utilisée. Pour une explication complète regardez la section Correspondance Recent du chapitre Correspondances.

XVIII-K. Sid-owner.txt▲

Le sid-owner.txt est un petit exemple montrant comment utiliser la correspondance SID. Il n'a rien de réel, en lançant la commande iptables -L -v vous verrez les règles appariées actuellement.

XVIII-L. Ttl-inc.txt▲

Un petit exemple ttl-inc.txt. Il indique comment rendre invisible le pare-feu/routeur aux traceroutes, lesquels révèlent beaucoup d'informations utiles aux attaquants possibles.

XVIII-M. Iptables-save▲

Un petit example script utilisé dans le chapitre Sauvegarde et restauration des tables de règles importantes pour illustrer comment iptables-save peut être utilisé. Ce script ne doit être utilisé que comme une référence, il ne fonctionne pas.