Le filtrage avec iptables


précédentsommairesuivant

15. 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, ainsi nous pourrons retrouver notre chemin un peu plus facilement.

15-1. 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 une 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 choisie, notez qu'elle peut ne pas être la meilleure pour vos scripts. Elle vise une lecture et une compréhension faciles pour nos besoins.

15-1-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.
1.1. 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 davantage de sous-sections ici, mais nous n'indiquons que celles concernant l'Internet.
1.1.1.DHCP - Si nécessaire nous ajouterons les options de configuration spécifique à DHCP ici.
1.1.2.PPPoE - Si l'utilisateur désire ce script spécifique, et qu'il utilise une connexion PPPoE, nous ajouterons les options ici.
1.2. 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.
1.3. 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.
1.4. Localhost - Cette section concerne l'hôte local. Ces options ne changent pratiquement jamais.
1.5. 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é.
1.6. 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 optionnels.
2.1. 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.
2.2. 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.

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.

Dans les dernières versions d'iptables, les modules sont automatiquement chargés, mais il vaut mieux, dans une perspective de contrôle, de les indiquer dans votre propre script. Par exemple, les assistants conntrack ne sont jamais chargés automatiquement.

  • 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.
3.1. 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.
3.2. 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 leurs spécifications de règles dans le même ordre que la sortie de la commande iptables -L.
4.1. Filter table - En premier nous voyons la table filter et son contenu. En priorité nous configurons toutes les stratégies de la table.
4.1.1.Set policies - Configuration des stratégies par défaut pour les chaînes système. Normalement je mets les stratégies à DROP pour les chaînes de la table filter, et spécifie ACCEPT pour 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.
4.1.2.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.
4.1.3.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.
4.1.4.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 pour résoudre les problèmes.

4.1.5.FORWARD chain - Ici nous ajoutons les règles de la chaîne FORWARD.
4.1.6.OUTPUT chain - En dernier, nous ajoutons les règles de la chaîne OUTPUT.
4.2. 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é.
4.2.1.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és ici, car certaines choses dangereuses peuvent survenir dans certains cas. Je laisse ces chaînes à ACCEPT, car il n'y a aucune raison de ne pas le faire.
4.2.2.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.
4.2.3.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.
4.2.4.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.
4.2.5.POSTROUTING chain - La chaîne POSTROUTING sera utilisée par les scripts que j'ai écrits, 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.
4.2.6.OUTPUT chain - Cette chaîne est à peine utilisée dans les scripts. Je n'ai trouvé aucune bonne raison de m'en servir.
4.3. 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.
4.3.1.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.
4.3.2.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.
4.3.3.Create content in user specified chains - Ici plus aucun script de ce didacticiel ne contiendra de règles.
4.3.4.PREROUTING - Ici plus aucun script de ce didacticiel ne contiendra de règles.
4.3.5.INPUT chain - Ici plus aucun script de ce didacticiel ne contiendra de règles.
4.3.6.FORWARD chain - Ici plus aucun script de ce didacticiel ne contiendra de règles.
4.3.7.OUTPUT chain - Ici plus aucun script de ce didacticiel ne contiendra de règles.
4.3.8.POSTROUTING chain - Ici plus aucun script de ce didacticiel ne contiendra de 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 explication assez rapide.

15-2. rc.firewall.txt

Image non disponible

Le rc.firewall.txt est le noyau sur lequel le reste des scripts est basé. Le chapitre Chapitre 14,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 Section 14.4, « rc.DHCP.firewall.txt »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 davantage 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

15-3. rc.DMZ.firewall.txt

Image non disponible

Le script rc.DMZ.firewall.txtJ.2. Exemple rc.DMZ.firewall script 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 c'est la DMZ dans laquelle nous faisons du NAT pair à pair. Par exemple, si quelqu'un sur l'Internet envoie 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.

15-4. rc.DHCP.firewall.txt

Image non disponible

Le script rc.DHCP.firewall.txtJ.4. Exemple rc.DHCP.firewall script est à peu près identique au Section 14.2, « rc.firewall.txt »J.1. Exemple rc.firewall script. Cependant, il n'utilise pas la variable STATIC_IP, ce qui est la principale différence avec le script rc.firewall.txt. La raison en 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 faisons 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 sélectionnent 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 Annexe E,Annexe E. 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 davantage 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 exemple, par le démon PPP, il suspendra toutes les connexions actives à cause des règles NEW non-SYN (voir la section Section B.2, « Paquets NEW non-SYN »B.2. Paquets NEW non-SYN).
  • 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.

15-5. rc.UTIN.firewall.txt

Image non disponible

Le script rc.UTIN.firewall.txtJ.3. Exemple rc.UTIN.firewall script 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 à 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.

15-6. rc.test-iptables.txt

Le script rc.test-iptables.txtJ.6. Exemple rc.test-iptables script 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 l'ip_forwarding, ou le masquerading, etc. Il fonctionnera dans la plupart des cas, si vous avez une configuration avec 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.

15-7. rc.flush-iptables.txt

Le script rc.flush-iptables.txtrc.flush-iptables.txtJ.5. Exemple rc.flush-iptables script ne devrait pas être appelé script à proprement parler. Ce script 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 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.

15-8. Limit-match.txt

Le script limit-match.txt est un miroir 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.

 
Sélectionnez
#!/bin/bash
#
# limit-match.txt - Example rule on how the limit match could be used.
#
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

iptables -A INPUT -p icmp --icmp-type echo-reply -m limit --limit \
3/minute --limit-burst 5 -j DROP

15-9. 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 examinée.

 
Sélectionnez
#!/bin/bash
#
# pid-owner.txt - Example rule on how the pid-owner match could be used.
#
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

PID=`ps aux |grep inetd |head -n 1 |cut -b 10-14`

/usr/local/sbin/iptables -A OUTPUT -p TCP -m owner --pid-owner $PID -j ACCEPT

15-10. Recent-match.txt

Ce script recent-match.txt indique comment la correspondance recent est utilisée. Pour une explication complète regardez la section Section 10.3.19, « Correspondance Recent » du Chapitre 11,Correspondances Iptables.

 
Sélectionnez
#!/bin/bash
#
# recent-match.txt - Example rule on how the recent match could be used.
#
# Copyright (C) 2005  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

iptables -N http-recent
iptables -N http-recent-final
iptables -N http-recent-final1
iptables -N http-recent-final2

iptables -A INPUT -p tcp --dport 80 -j http-recent


#
# http-recent-final, has this connection been deleted from httplist or not?
# 
#
iptables -A http-recent-final -p tcp -m recent --name httplist -j \
http-recent-final1
iptables -A http-recent-final -p tcp -m recent --name http-recent-final -j \
http-recent-final2

#
# http-recent-final1, this chain deletes the connection from the httplist 
# and adds a new entry to the http-recent-final
#
iptables -A http-recent-final1 -p tcp -m recent --name httplist \
--tcp-flags SYN,ACK,FIN FIN,ACK --close -j ACCEPT
iptables -A http-recent-final1 -p tcp -m recent --name http-recent-final \
--tcp-flags SYN,ACK,FIN FIN,ACK --set -j ACCEPT

#
# http-recent-final2, this chain allows final traffic from non-closed host
# and listens for the final FIN and FIN,ACK handshake.
#
iptables -A http-recent-final2 -p tcp --tcp-flags SYN,ACK NONE -m recent \
--name http-recent-final --update -j ACCEPT
iptables -A http-recent-final2 -p tcp --tcp-flags SYN,ACK ACK -m recent \
--name http-recent-final --update -j ACCEPT
iptables -A http-recent-final2 -p tcp -m recent --name http-recent-final \
--tcp-flags SYN,ACK,FIN FIN --update -j ACCEPT
iptables -A http-recent-final2 -p tcp -m recent --name http-recent-final \
--tcp-flags SYN,ACK,FIN FIN,ACK --close -j ACCEPT

#
# http-recent chain, our homebrew state tracking system.
#

# Initial stage of the tcp connection SYN/ACK handshake
iptables -A http-recent -p tcp --tcp-flags SYN,ACK,FIN,RST SYN -m recent \
--name httplist --set -j ACCEPT
iptables -A http-recent -p tcp --tcp-flags SYN,ACK,FIN,RST SYN,ACK -m recent \
--name httplist --update -j ACCEPT
# Note that at this state in a connection, RST packets are legal (see RFC 793).
iptables -A http-recent -p tcp --tcp-flags SYN,ACK,FIN ACK -m recent \
--name httplist --update -j ACCEPT

# Middle stage of tcp connection where data transportation takes place.
iptables -A http-recent -p tcp --tcp-flags SYN,ACK NONE -m recent \
--name httplist --update -j ACCEPT
iptables -A http-recent -p tcp --tcp-flags SYN,ACK ACK -m recent \
--name httplist --update -j ACCEPT

# Final stage of tcp connection where one of the parties tries to close the 
# connection.
iptables -A http-recent -p tcp --tcp-flags SYN,FIN,ACK FIN -m recent \
--name httplist --update -j ACCEPT
iptables -A http-recent -p tcp --tcp-flags SYN,FIN,ACK FIN,ACK -m recent \
--name httplist -j http-recent-final

# Special case if the connection crashes for some reason. Malicious intent or 
# no.
iptables -A http-recent -p tcp --tcp-flags SYN,FIN,ACK,RST RST -m recent \
--name httplist --remove -j ACCEPT

15-11. Sid-owner.txt

Le script 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 examinées actuellement.

 
Sélectionnez
#!/bin/bash
#
# sid-owner.txt - Example rule on how the sid-owner match could be used.
#
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

SID=`ps -eo sid,args |grep httpd |head -n 1 |cut -b 1-5`

/usr/local/sbin/iptables -A OUTPUT -p TCP -m owner --sid-owner $SID -j ACCEPT

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

 
Sélectionnez
#!/bin/bash
#
# ttl-inc.txt - short script to increase TTL of all packets on port 33434 - 33542
#
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

/usr/local/sbin/iptables -t mangle -A PREROUTING -p TCP --dport 33434:33542 -j \
TTL --ttl-inc 1

15-13. iptables-save ruleset

Un petit exemple de script utilisé dans le chapitre Chapitre 9,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.

 
Sélectionnez
#!/bin/bash
#
# iptsave-ruleset.txt - Example script used to create iptables-save data.
#
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

INET_IFACE="eth0"
INET_IP="195.233.192.1"

LAN_IFACE="eth1"

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP


iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i $INET_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $LAN_IFACE -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP

15-14. Prochain chapitre

Dans le prochain chapitre nous verrons certaines interfaces graphiques disponibles pour iptables et netfilter. C'est loin d'être une liste complète de toutes les interfaces existantes. Ces interfaces tentent principalement de simplifier la création de scripts iptables, et vous permettent de gagner du temps.


précédentsommairesuivant

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Copyright © 2001-2006 Oskar Andreasson
La permission est accordée de copier, distribuer et/ou modifier ce document selon les termes de la « GNU Free Documentation License », version 1.1; en précisant les sections « Introduction » et toutes les sous-sections, avec les en-têtes « Auteur: Oskar Andreasson ». Une copie de la licence est inclue dans la section intitulée « GNU Free Documentation License ».
Tous les scripts de ce tutoriel sont couverts par la GNU General Public License. Les scripts sont de source libre; vous pouvez les redistribuer et/ou les modifier selon les termes de la GNU General Public License publiée par la « Free Software Foundation », version 2.
Ces scripts sont distribués dans l'espoir qu'ils seront utiles, mais SANS AUCUNE GARANTIE; sans même la garantie implicite qu'ils soient VENDABLES ou une QUELCONQUE APTITUDE POUR UN PROPOS PARTICULIER. Voir la GNU General Public License pour plus de détails.
Vous devriez avoir une copie de la GNU General Public License dans ce tutoriel, dans la section intitulée « GNU General Public License »; si ce n'est pas le cas, écrivez à la Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.