III-10-1 Règles par défaut ("Policy")Jusqu'à présent, nous avons vu que nous devions initialiser et définir les règles par défaut de ta table "Filter", et parfois celles de la table "NAT". En fait, ce n'est pas tout à fait la bonne manière de faire. A supposer par exemple que vous vouliez faire uniquement du filtrage (option "-t filter"), vous pouvez très bien avoir laissé quelques règles de PREROUTING ou de POSTROUTING activées dans la table NAT. Dans ce cas, vous ne savez pas forcément ce que fait Netfilter, et il se peut qu'avec de telles configurations, il laisse passer des trames sans que vous ne vous en doutiez.Donc il est est primordial que la première chose que vous fassiez dans un script Netfilter soit d'initialiser toutes les tables ("Filter", "NAT" et "Mangle") : [root@phoenix /]# iptables -t filter -F [root@phoenix /]# iptables -t filter -X [root@phoenix /]# iptables -t filter -P INPUT DROP [root@phoenix /]# iptables -t filter -P FORWARD DROP [root@phoenix /]# iptables -t filter -P OUTPUT DROP [root@phoenix /]# iptables -t nat -F [root@phoenix /]# iptables -t nat -X [root@phoenix /]# iptables -t nat -P PREROUTING ACCEPT [root@phoenix /]# iptables -t nat -P OUTPUT ACCEPT [root@phoenix /]# iptables -t nat -P POSTROUTING ACCEPT [root@phoenix /]# iptables -t mangle -F [root@phoenix /]# iptables -t mangle -X [root@phoenix /]# iptables -t mangle -P PREROUTING ACCEPT [root@phoenix /]# iptables -t mangle -P INPUT ACCEPT [root@phoenix /]# iptables -t mangle -P FORWARD ACCEPT [root@phoenix /]# iptables -t mangle -P OUTPUT ACCEPT [root@phoenix /]# iptables -t mangle -P POSTROUTING ACCEPTVous remarquerez que l'on définit à "ACCEPT" les règles par défaut des tables "NAT" et "Mangle". Cela n'a pas trop d'influence sur la sécurité, du moment que vos règles de FORWARD sont bien écrites. Sinon, vous pouvez les mettre à "DROP", mais cela rallongera énormément le code et le temps de développement de votre script Netfilter. Important :Notez cependant que lorsque Netfilter analyse les trames, celle-ci passent en premier à travers les règles de la table "Mangle", puis par les tables "Filter" et "NAT". Donc si vous mettez les règles par défaut de cette table à "DROP" et que vous n'écrivez pas d'autres règles, tous vos paquets réseaux seront supprimés, sans même être analysés par les autres tables. C'est un peu violent comme protection, mais c'est efficace ! ![]() Ce n'est pas non plus une mauvaise chose que de désactiver en début de script, au moins temporairement, le NAT (on ne sait jamais, des fois que vous l'ayez oublié) : echo 0 > /proc/sys/net/ipv4/ip_forward III-10-2 Chaînes utilisateursNous avons peu parlé des chaînes utilisateurs, aussi nous allons y jeter un oeil. Lorsque vous écrivez vos règles Netfilter, il y a parfois des morceaux de code que vous aimeriez mettre en commun. Par exemple, supposons que vous vouliez interdire le "ping" de certaines machines du réseau local ainsi que du réseau externe, mais que vous vouliez aussi "logger" toute utilisation du "ping". Vous auriez alors à écrire quelque chose comme :[root@phoenix /]# iptables -t filter -A INPUT -i eth0 -s 192.168.0.2 -p icmp -j LOG [root@phoenix /]# iptables -t filter -A INPUT -i eth0 -s 192.168.0.2 -p icmp -j DROP [root@phoenix /]# iptables -t filter -A INPUT -i eth0 -s 192.168.0.3 -p icmp -j LOG [root@phoenix /]# iptables -t filter -A INPUT -i eth0 -s 192.168.0.3 -p icmp -j DROP [root@phoenix /]# iptables -t filter -A INPUT -i eth1 -p icmp -j LOG [root@phoenix /]# iptables -t filter -A INPUT -i eth1 -p icmp -j DROPDans ces cas, les règles utilisateurs sont là pour simplifier la vie. Commençons par écrire notre propre règle "LogDrop" qui comme son nom l'indique, va "logger" les trames, puis les supprimer : [root@phoenix /]# iptables -t filter -N LogDrop [root@phoenix /]# iptables -t filter -A LogDrop -j LOG --log-prefix LogDrop [root@phoenix /]# iptables -t filter -A LogDrop -j DROPPuis, appelons la pour nos pings sur les réseaux locaux : [root@phoenix /]# iptables -t filter -A INPUT -i eth0 -s 192.168.0.2 -p icmp -j LogDrop [root@phoenix /]# iptables -t filter -A INPUT -i eth0 -s 192.168.0.3 -p icmp -j LogDropEt les réseaux externes :
[root@phoenix /]# iptables -t filter -A INPUT -i eth1 -p icmp -j LogDrop
![]() III-10-3 Règles courtes ou longues ?III-10-3-1 Description du problèmeDans les différents scripts que nous avons vu jusqu'ici, vous avez pu remarquer que j'écrivais toujours des règles Netfilter assez longues. Et notamment, que ces règles cumulait les paramètres "-i", "-o", "-s", "-d".Par exemple voici un extrait des commandes "iptables" de iptables-conntrack-1.sh pour les connexions au réseau interne "sky.net" : Règles longues : [root@phoenix /]# iptables -t filter -A OUTPUT -o eth0 \ -s 192.168.0.0/24 -d 192.168.0.0/24 -j ACCEPT [root@phoenix /]# iptables -t filter -A INPUT -i eth0 \ -s 192.168.0.0/24 -d 192.168.0.0/24 -j ACCEPTPetits rappels sur la définition de ces paramètres :
Dans le cadre d'une machine dont chaque interface réseau n'a qu'une seule adresse IP, on peut intuitivement "sentir" qu'il y a double emploi entre les paramètres "-i" / "-o" d'un part, et les paramètres "-s" / "-d" d'autre part. Par exemple, tout paquet entrant dans Phoenix par son interface réseau "eth0" est forcément à destination de l'adresse IP de cette interface là, à savoir 192.168.0.1 ou phoenix.sky.net. Non ? Les règles ne pourraient elles pas être plus simplement écrites par : Règles courtes : [root@phoenix /]# iptables -t filter -A OUTPUT -o eth0 -j ACCEPT [root@phoenix /]# iptables -t filter -A INPUT -i eth0 -j ACCEPTEt bien en fait, non il ne faut pas ! A moins que vous ne vouliez absolument laisser des failles de sécurité qu'un enfant de 3 ans pourrait utiliser ? ![]() C'est justement une technique de piratage très classique appelée "spoofing" ("spoof" veut dire "blague", "parodie" en français) qui utilise une astuce exploitant ce défaut de la configuration ci-dessus. Pour cela, le spoofing utilise un procédé technique dont je n'entrerai pas dans les détails : utilisation de la vrai adresse ethernet / MAC de la carte réseau cible, mais d'une adresse IP cible erronée. L'idée de notre intrus est qu'il "forge" lui-même ses propres paquets réseaux (il existe des outils de ce type qui font cela très bien), de tel manière à obliger la machine cible a accepter ces paquets, mais à tenter aussi de bénéficier d'un mauvaise configuration de Netfilter. En fait, grâce à cette technique, il suffit de pas grand chose (*) à notre intrus pour se faire passer pour une machine du réseau interne, et de ce fait, de bénéficier de règles Netfilter sans doute plus "souple". (*) : une règle de FORWARD un peu mal écrite par exemple. De ce fait, et afin d'éviter tout risque de "spoofing", je recommande et j'utilise des règles Netfilter "longues". Si vous cherchez un peu, vous trouverez sur Internet de nombreux scripts "iptables" qui utilisent des règles "courtes".
III-10-3-2 Et pour la connexion WAN (Internet) ?Toujours dans le même domaine, on peut légitimement s'interroger sur l'utilisation de règles longues pour les connexions Internet, ou WAN ("Width Area Network" ou "réseau large" en français).En effet, dans le cadre d'une connexion WAN, c'est le Fournisseur d'Accès Internet (FAI) qui est l'interlocuteur direct de notre machine Linux, et donc c'est en théorie uniquement lui qui peut utiliser une technique de spoofing. On pourrait donc utiliser des règles courtes pour la partie de notre script Netfilter liée à la connexion Internet. Cela nous éviterait donc de devoir utiliser notre adresse IP Internet dans notre script, adresse pas toujours facile à trouver car elle est potentiellement amenée à changer à chaque connexion. Oui, mais pouvons nous vraiment faire confiance à notre FAI ? Personnellement, je ne le fais pas. Et ce, pour la simple raison que je n'ai aucune garantie que son service soit fiable à 100%, et que personne, dans ses propres locaux ou sur Internet, ne puisse prendre la main sur ses systèmes, et ne fasse du spoofing sur ses clients. Enfin, même si le FAI n'est pas en cause, le spoofing peut venir de nos locaux eux-mêmes, a à peine 1,5m de notre machine... En effet, certains modem ADSL sont administrables à distance, non seulement via le câble USB ou ethernet du modem, mais aussi via le câble téléphonique / ADSL ! C'est une (curieuse) fonctionnalité qu'ont mis en place les fabriquants de certains de ces modems, pour entre autre permettre au FAI de mettre à jour certains composants logiciels du modem, que l'on appelle "firmware". Or, cette possibilité technique peut n'être pas fiable à 100%, et un intrus peut prendre la main sur le modem ADSL, et ainsi forger ses propres paquets IP depuis le modem ADSL lui-même... Il y notamment eu des alertes de sécurité faites par le CERT concernant les modems "Alcatel Speed Touch Home ADSL Modem" (la fameuse "raie manta bleue") et "Alcatel 1000 ADSL Network Termination Device", reprises d'ailleurs par d'autres sites. L'outil de test d'intrusion Nessus contient entre autre un module permettant de vérifier si votre modem est vulnérable à ce type d'intrusion. En conclusion, même si les règles "longues" sont plus pénibles à écrire, et qu'elles demandent plus de puissance à votre processeur pour les traiter, elles permettent de sécuriser un peu plus votre machine. Coté protection vis à vis d'Internet, vous pouvez décider de ne pas les mettre en oeuvre, afin par exemple de réduire votre temps de réponse sur Internet (c'est le fameux "ping"), et ainsi d'accélérer vos jeux en ligne. A vous de faire le choix entre besoin de performances et sécurité. III-10-4 Script final d'exemple![]() Avant toute chose, il faudra que vous le configuriez à votre usage. Pour cela, le début du script contient un certain nombre de variables globales, qui définissent le comportement du script :
III-10-5 Sauvegarde des règles NetfilterSupposons que vous n'écriviez pas votre adresse IP Internet dans vos règles Netfilter de "ppp0" (comme décrit ci-dessus), vous avez alors des règles de ce type :[root@phoenix /]# iptables -t filter -A OUTPUT -o ppp0 -d 0.0.0.0/0 \ -p all -m state --state ! INVALID -j ACCEPT [root@phoenix /]# iptables -t filter -A INPUT -i ppp0 -s 0.0.0.0/0 \ -p all -m state --state RELATED,ESTABLISHED -j ACCEPTDans ce cas, vos règles Netfilter sont génériques, et elles n'ont pas besoin d'être modifiées à chaque connexion Internet. Donc vous pouvez écrire vos règles une fois pour toute, et laisser Linux les charger automatiquement au démarrage de votre machine. Pour cela, écrivez vos règles Netfilter dans un script, puis (pour les possesseurs de distributions Mandrake) tapez la commande :
[root@phoenix /]# /etc/rc.d/init.d/iptables save
Enfin, pour que le Netfilter soit opérationnel à chaque démarrage, il faut créer les liens symboliques adéquates dans le /etc/rc.d/ :
[root@phoenix /]# cd /etc/rc.d/rc3.d/ [root@phoenix /]# ln -s ../init.d/iptables s03iptables [root@phoenix /]# cd /etc/rc.d/rc5.d/ [root@phoenix /]# ln -s ../init.d/iptables s03iptablesAu démarrage, votre Linux lancera le script /etc/rc.d/init.d/iptables qui chargera les règles Netfilter précédemment sauvées. Si à un moment vous avez besoin d'arrêter la protection de Netfilter, vous n'avez qu'à lancer la commande suivante :
[root@phoenix /]# /etc/rc.d/init.d/iptables stop
III-10-6 Tests d'intrusionUne fois que toutes vos règles iptables sont écrites, il vous faut vous-mêmes tester la sécurité de votre Linux en pratiquant des tests d'intrusions. Une première approche est d'utiliser "nmap", et de contrôler chacun de vos ports. Cette pratique est très efficace (lisez "man nmap" afin d'utiliser au mieux les options très variées de Nmap), et doit être fait depuis les machines de votre réseau. Pendant vos "attaques" lancées par "nmap", n'oubliez pas de garder un oeil sur votre "/var/log/messages" (par exemple avec un "tail -f /var/log/messages") ou le fichier qui stocke les logs de Netfilter, afin de suivre la progression de l'attaque.Dans le cadre du réseau proposé ici, il m'a été facile de tester les 2 interfaces réseaux de Phoenix, en lançant les tests depuis Paradise et Pirate. Cependant, dans le cadre d'une utilisation personnelle, il est beaucoup plus difficile de tester l'interface réseau externe ("ppp0" par exemple). En effet, si par exemple depuis Phoenix vous lancez un "nmap phoenix1.internet.net", vous ne ferez que tester les règles de "loopback/localhost", comme nous l'avons déjà vu précédemment. Pour que vous obteniez un résultat correct, il vous faut donc changer vos règles de "loopback" par celles que vous avez définies pour "ppp0". Mais cette solution n'est pas forcément très représentative de la réalité, et le mieux serait de tester réellement les paquets arrivant sur "ppp0". Il vous faut donc faire confiance à une personne externe à votre réseau, située sur Internet, pour tester vos règles de Firewall. Pour cela, 3 possibilités :
![]() En fait, tout le mérite en revient au suivi de connexion, qui fait passer notre machine pour un "trou noir". Comme le veut la définition de ce terme, c'est "un corps qui absorbe tout, et qui ne rejette rien"... Quels que soient ces sites, leurs tests ne sont souvent pas très poussés, et se limitent parfois qu'aux seuls ports ouverts par défaut sous Windows®. De plus, un simple test de "port scanning" n'est pas forcément suffisant, et d'autres outils de tests d'intrusion peuvent être utilisés en complément. Mais à ce niveau là, la limite entre tests de sécurité et piratage est très ténue, donc je vous laisserai chercher par vous-même des moyens de tester un peu plus en profondeur votre système... III-10-7 Bilan des scripts / autres scriptsAu cours de ce chapitre III, nous avons vu un certains nombre de scripts. Ils étaient téléchargeable au fur et à mesure des explications, mais en voici un récapitulatif.
A titre d'informations, vous pouvez aussi télécharger quelques scripts supplémentaires :
|
![]() ![]() ![]() |
![]() |
![]() ![]() |
|
Site de référence : http://olivieraj.free.fr/ | Last modified: Wed Mar 10 22:14:32 CET 2004 |