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.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.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.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.
|
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▲
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▲
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 :
$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▲
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 :
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▲
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 :
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.
#!/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.
#!/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.
#!/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.
#!/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.
#!/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.
#!/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.