Table des matières Page précédente Page suivante Version mono-page

III-10 Autres astuces

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 ACCEPT
Vous 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 ! Smiley Vous trouverez un peu plus loin le script "iptables-extrem-drop.sh" qui configure la table "Mangle" de cette manière.

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 utilisateurs

Nous 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 DROP
Dans 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 DROP
Puis, 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 LogDrop
Et les réseaux externes :
[root@phoenix /]# iptables -t filter -A INPUT -i eth1 -p icmp -j LogDrop
Téléchargez On note au passage que notre chaîne "LogDrop" peut être appelée à n'importe quelle occasion, avec une règle "parente" ayant ou non beaucoup d'options. Le script vu ci-dessus se trouve ici.

III-10-3 Règles courtes ou longues ?

III-10-3-1 Description du problème

Dans 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 ACCEPT
Petits rappels sur la définition de ces paramètres :
ParamètreDescription
-iNom de l'interface d'entrée ("Input" en anglais) qu'a utilisé le paquet pour rentrer dans la machine.
-oNom de l'interface de sortie ("Output" en anglais) qu'utilisera le paquet pour sortir de la machine.
-sAdresse IP source ("Source" en anglais) du paquet
-dAdresse IP cible ("Destination" en anglais) du paquet

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 ACCEPT
Et 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 ? Smiley

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".
  • Soit les développeurs de ces scripts n'ont pas pris en compte le problème du spoofing, et auquel cas je ne vous conseille pas d'utiliser ces scripts là.
  • Soit au contraire ils ont pris en compte le problème du spoofing, mais pour cela ils utilisent des techniques particulières :
Dans ces deux cas, un lecture approfondit du script est nécessaire, de même que sa compréhension globale. Je reviendrais un peu plus en détail sur ces techniques particulières dans le chapitre suivant.

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

Téléchargez Nous avons vu jusqu'à présent un bon nombre de fonctionnalités de Netfilter grâce aux commandes "iptables". J'ai donc écrit un script qui regroupe toutes ces fonctionnalités en un seul script que vous pouvez utiliser chez vous. Ce script est téléchargeable ici.

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 :
  • LAN_* (Local Area Network) : ces variables définisent le réseau local. Dans notre exemple, il s'agit du réseau "sky.net".
  • WAN_* (Wan Area Network) : là, il s'agit des variables définissant le réseau Internet. Elles sont spécialement conçues pour un réseau connecté par l'intermédiaire d'une passerelle. Or, vous devez plutôt avoir un modem RTC/RNIS/ADSL pour vous connecter, non ? Dans ce cas, il vous faudra donc décommenter le 2nd paquet de lignes "WAN_*", qui définirons vos paramètres de connexion Internet. La seule variable qu'il faudra bien vérifier est "WAN_INTERFACE=ppp0", mais à priori, vous ne vous connectez à Internet que par l'interface "ppp0". Dans le doute, et une fois que votre connexion Internet est activée, les commandes "/sbin/ifconfig" et "/sbin/route" vous donnerons plus d'informations.
  • NAT (Network Adress Translation) : cette variable définit si oui ou non vous voulez autorisez les machines de votre réseau interne à se connecter à Internet.
  • PF_* (Port Forwarding) : ces variables définissent si ou non vous voulez faire du port forwarding. Notez que j'ai pris ici l'exemple le plus simple : le HTTP ne demande en effet qu'un seul port omnidirectionnel. Si vous voulez faire du port forwarding sur du FTP, ce sera un peu plus compliqué, car il faut laisser passer le canal de données (FTP-DATA) qui utilise le port 20 du coté client. Pour le P2P, c'est votre port de connexion (par exemple, "4660") qu'il faudra laisser passer en entrée.
Quelques remarques à propos de ce script :
  • Toutes les règles Netfilter qui contrôlent l'accès à Internet utilisent l'adresse IP externe de la machine ("WAN_IP"). Comme expliqué juste au-dessus, c'est un choix technique afin d'améliorer la sécurité, et certains pourront le contester, entre autre pour des problèmes de performances. Beaucoup de scripts que vous trouverez sur Internet n'utilisent pas ces options ("-d $WAN_IP" pour les règles "INPUT" et "-s $WAN_IP" pour les règles "OUTPUT"), et ne restreignent tout simplement pas les connexions externes à l'adresse IP externe. Par exemple, au lieu d'écrire :
    [root@phoenix /]# iptables -t filter -A OUTPUT -o $WAN_INTERFACE -s $WAN_IP -d $WAN_NETWORK \
                               -p all -m state --state ! INVALID           -j ACCEPT
    [root@phoenix /]# iptables -t filter -A INPUT  -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP \
                               -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
    
    Ces autres scripts écriraient :
    [root@phoenix /]# iptables -t filter -A OUTPUT -o $WAN_INTERFACE -d $WAN_NETWORK \
                               -p all -m state --state ! INVALID           -j ACCEPT
    [root@phoenix /]# iptables -t filter -A INPUT  -i $WAN_INTERFACE -s $WAN_NETWORK \
                               -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
    
    Bien que ce choix ait l'avantage d'offrir une sécurité supplémentaire, il a un inconvénient important : pour que ce script soit fonctionnel, il faut le lancer à chaque fois que la configuration réseau change, c'est à dire à chaque connexion à Internet. Et c'est la commande (barbare ?) "/sbin/ifconfig | grep "P-t-P" | sed "s/^[: a-z]*\([.0-9]*\).*/\1/g"" qui va se charger de trouver l'adresse IP internet de votre machine. Aussi, plutôt que de le lancer manuellement, vous pouvez laisser Linux s'en occuper pour vous. En effet, à chaque fois que la connexion ppp est initialisée, Linux exécute le script "/etc/sysconfig/network-scripts/ifup-ppp" (*). Vous n'avez donc qu'à rajouter une ligne lançant ce script au début de ce fichier. Par exemple, quelque chose comme "/usr/local/sbin/iptables-final-1.sh".

    Pour des raisons de sécurité, je vous conseille de donner la propriété de ce fichier au root, et de le laisser en écriture uniquement pour le super utilisateur.
    Exemple :
    [root@phoenix /]# chown root:root /usr/local/sbin/iptables-final-1.sh
    [root@phoenix /]# chmod 755 /usr/local/sbin/iptables-final-1.sh
    
    (*): en fait, ce n'est pas une obligation absolue. Et cela dépend en partie de l'outil que vous utilisez pour vous connecter sur Internet.
    Par exemple, pour ma connexion modem j'utilise l'interface graphique "/usr/bin/kppp". Et ce programme propose de lancer un script une fois la connexion Internet établie. C'est là que l'on pourrait mettre le "/usr/local/sbin/iptables-final-1.sh" Options de Kppp
    Kppp avec lancement du script de firewall
    Si par contre vous utiliser un script ADSL pour vous connecter à Internet, par exemple "/usr/sbin/adsl-start" (modem pppoE) ou "/usr/sbin/startadsl" (modem Sagem USB F@st), vous pouvez lancer en une commande votre script de connexion à Internet et le script de firewall :
    [root@phoenix /]# /usr/sbin/adsl-start && /usr/local/sbin/iptables-final-1.sh
    [root@phoenix /]# /usr/sbin/startadsl && sleep 10 && /usr/local/sbin/iptables-final-1.sh
    
    Le "sleep 10" permet d'attendre 10 secondes entre l'exécution du script ADSL, et celui du firewall. Ceci est rendu nécessaire car au jour où j'écris ces lignes (version "eagle-1.0.4" pour le modem Sagem), ce driver ADSL rend la main avant la fin de l'établissement de la connexion ADSL.
  • Lancer un tel script de firewall a cependant un désavantage : Comme il faut attendre que la connexion Internet soit opérationnelle avant de lancer le script, il va s'écouler un "certain temps" entre ces 2 opérations pendant lequel votre machine ne sera pas sécurisée. La "fenêtre" temporelle sans protection sera assez courte, une dizaine de secondes tout au plus, mais cela peut être considéré comme trop risqué.

    Aussi vaut il mieux:
    • commencer par interdire toute connexion entrante ou sortante de notre machine. Pour cela, on mettra toutes les règles de filtrages à "DROP".
    • établir la connexion à Internet.
    • et enfin lancer notre script de firewall.

    Téléchargez Afin d'interdire temporairement toutes les connexions, on pourra par exemple utiliser le script iptables-final-pre-1.sh.

    Exemple d'utilisation :
    • Connexion ADSL en pppoE :
      [root@phoenix /]# /usr/local/sbin/iptables-final-pre 1.sh && /usr/sbin/adsl-start && \
                        /usr/local/sbin/iptables-final-1.sh
      
    • Connexion ADSL avec le modem "Sagem USB F@st" :
      [root@phoenix /]# /usr/local/sbin/iptables-final-pre 1.sh && /usr/sbin/startadsl && \
                        sleep 10 && /usr/local/sbin/iptables-final-1.sh
      
    • Connexion modem RTC via Kppp : Options de Kppp
      Kppp avec lancement de scripts avant et après la connexion
  • Dans ce script, vous pouvez voir que les règles de port forwarding sont situées avant celles d'IP masquerading. Simple effet de style de ma part ? Non, pas du tout. Un paquet venant d'Internet et à destination du port 80 de la machine satisfait à 2 règles de la chaîne "FORWARD" :
    iptables -t filter -A FORWARD -i $WAN_INTERFACE -o $LAN_INTERFACE -s $WAN_NETWORK \
             -d $LAN_NETWORK -p $PF_PROTO --dport $PF_PORT -m state \
             --state ! INVALID           -j ACCEPT
    iptables -t filter -A FORWARD -i $WAN_INTERFACE -o $LAN_INTERFACE -s $WAN_NETWORK \
             -d $LAN_NETWORK -p all -m state \
             --state ESTABLISHED,RELATED -j ACCEPT
    
    De même que pour les paquets sortants de la machine et ayant pour source le port 80 :
    iptables -t filter -A FORWARD -i $LAN_INTERFACE -o $WAN_INTERFACE -s $LAN_NETWORK \
             -d $WAN_NETWORK -p $PF_PROTO --sport $PF_PORT -m state \
             --state ESTABLISHED,RELATED -j ACCEPT
    iptables -t filter -A FORWARD -i $LAN_INTERFACE -o $WAN_INTERFACE -s $LAN_NETWORK \
             -d $WAN_NETWORK -p all -m state \
             --state ! INVALID           -j ACCEPT
    
    Dans les 2 cas, la 1ère règle est une règle de port forwarding et la 2nd d'IP masquerading. Mais comme les 2ndes règles sont plus générales que les premières, les statistiques de Netfilter (commande "iptables -L -n -v -t filter") sont faussées si les règles d'IP masquerading sont placées avant les règles de port forwarding.

    Cet exemple est intéressant, car c'est un des fameux cas où l'ordre des commandes "iptables" a une certaine importance. Comment cela je chipote ? Et bien oui... Smiley
  • Notez enfin que les différents modules de Netfilter ("iptable_nat", "ip_nat_ftp", etc ...) ne sont chargés que si c'est nécessaire. On aurait par contre pu tous les charger "en bloc" au début du script.

III-10-5 Sauvegarde des règles Netfilter

Supposons 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 ACCEPT
Dans 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 s03iptables
Au 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'intrusion

Une 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 :
  • Vous avez un accès en "telnet" ou en "SSH" (ce qui est mieux, car plus sécurisé) sur une machine située sur Internet. Vous vous connectez alors dessus, et vous lancez un "nmap" sur l'adresse IP de votre machine. Attention de ne pas vous tromper d'adresse IP, sinon vous iriez tester les ports d'une autre machine, et son propriétaire pourrait ne pas être très content...
  • Vous demandez à un de vos amis de faire ce test pour vous. Encore faut il qu'il sache ce qu'est "nmap" !
  • Enfin, vous faites faire ce test par un site web. Certains sites proposent gratuitement ce genre de prestation, entre autre pour vous proposer des solutions de firewall ... Windows® Smiley
J'ai testé certains de ces sites, et voici les résultats :
Site de testRésultat
PcFlankPcFlank
DSLreportsDSLreports
Shields UP!Shields UP!
AuditMyPc.comLe site a refusé de tester la machine, ce qui est
apparemment dût à la présence du proxy transparent
de mon fournisseur d'accès à Internet
Sans surprise, non ? Smiley

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 scripts

Au 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.
Nom du scriptDescription
Téléchargez exemple-01.sh Simple script d'illustration des possibilités des scripts.
Téléchargez exemple-02.sh Idem que plus haut, mais ce script peut être exécuté sans lancer un interpréteur "sh".
Téléchargez iptables-basic-1.sh Script iptables simple avec le "bug du localhost" (filtrage excessif lors des auto-connexions).
Téléchargez iptables-basic-2.sh Script iptables simple et corrigé qui permet à la machine de se connecter à elle-même.
Téléchargez iptables-conntrack-1.sh Utilisation du suivi de connexion, plus efficace que le filtrage simple des ports de destination.
Téléchargez iptables-ipmasquerading-1.sh Script permettant le partage de connexion (IP masquerading).
Téléchargez iptables-ipmasquerading-2.sh Second script a ne pas utiliser créant un trou de sécurité par utilisation "à l'envers" de la passerelle.
Téléchargez iptables-portforwarding-1.sh Premier script permettant le port forwarding.
Téléchargez iptables-portforwarding-2.sh Un second script de port forwarding, que je déconseille (voir tout spécialement les explications).
Téléchargez iptables-log-1.sh Script utilisant le système de LOG.
Téléchargez iptables-log-2.sh Ce script là utilise ULOG plutôt que LOG.
Téléchargez iptables-utilisateur-1.sh Script mettant en scène les chaînes utilisateurs.
Téléchargez iptables-final-1.sh Script plus complexe que les précédent, regroupant les différentes fonctionnalités vu dans ce chapitre.
Téléchargez iptables-final-pre-1.sh Permet d'interdire toutes les connexions réseaux. A lancer avant "iptables-final-1.sh".

A titre d'informations, vous pouvez aussi télécharger quelques scripts supplémentaires :
Nom du scriptDescription
Téléchargez iptables-extrem-accept.sh Ce script vide toutes les chaînes prédéfinies et supprime toute les chaînes utilisateurs de toutes les tables. C'est utile si vous voulez revenir à une configuration de Netfilter complètement vierge, et aussi complètement insécurisée. Bref, c'est la configuration que vous avez probablement actuellement !
Téléchargez iptables-extrem-drop.sh Ce script est pour les ultra paranoïaques, car contrairement à son prédécesseur, il interdit toute connexion (après avoir au préalable supprimé toutes les règles et toutes les chaînes utilisateurs). Avec une telle configuration, il ne vous reste plus qu'à débrancher les câbles réseaux de votre machine, et en faire des colliers. Au moins, ils vous seront utiles à quelque chose ! Smiley

Table des matières Page précédente Page suivante Version mono-page
Valid XHTML 1.0! Valid CSS!
Site de référence : http://olivieraj.free.fr/ Last modified: Wed Mar 10 22:14:32 CET 2004