Table des matières Page précédente Page suivante

III-7 Le suivi de connexion (conntrack)

III-7-1 Comment leurrer un firewall en une leçon...

Phoenix se trouve toujours dans la configuration Netfilter définie par le script "iptables-basic-2.sh", et Pirate ne nous voit toujours pas en utilisant la commande "nmap". Oui, mais notre intrus n'est pas un petit plaisantin. Comme nous, il sait lire le "man nmap", et il connaît l'option "-g"...

Notre intrus va donc se connecter en temps que root sur sa propre machine, et lancer la commande "nmap phoenix1.internet.net -g 80" :
[root@pirate /]# nmap phoenix1.internet.net -g 80

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on phoenix1.internet.net (10.0.0.1):
(The 1585 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp
23/tcp     open        telnet
25/tcp     open        smtp
53/tcp     open        domain
80/tcp     open        http
110/tcp    open        pop-3
111/tcp    open        sunrpc
139/tcp    open        netbios-ssn
307/tcp    filtered    unknown
404/tcp    filtered    nced
443/tcp    open        https
511/tcp    filtered    passgo
578/tcp    filtered    ipdd
607/tcp    filtered    nqs
3306/tcp   open        mysql
6000/tcp   open        X11

Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds
Horreur sans nom ! Contrairement à la précédente commande "nmap", non seulement notre intrus a réussi à nous retrouver, mais en plus il voit tout nos ports ouverts ! Arggggg, tout ce travail pour rien ! Netfilter ne serait il qu'un gadget inutile ?

Non, en fait c'est tout à fait naturel et cela prouve la protection complètement insuffisante d'un firewall basé uniquement sur l'ouverture des ports. L'image ci-contre le montre bien. C'est une capture des connexions réseaux faite par "Ethereal" sur phoenix1.internet.net. On y voit :
  • En rouge : Pirate ouvre une connexion venant du port 80, et à destination d'un port de Phoenix sur lequel il suppose que tourne un démon. Il commence une "handshake" tout à fait classique (SYN), auquel répond Phoenix par un "RESET" (RST, ACK), disant que ce port (932) n'est pas ouvert.
  • En bleu : là encore, Pirate ouvre une connexion venant du port 80. Mais cette fois ci, Phoenix l'informe que le port ("pop3" <=> 110) est ouvert. Poliment, Pirate referme la connexion (RST) afin de ne pas donner l'éveil à Phoenix. Mais au passage, il a pu noter que le port en question était ouvert... Victoire sur tout la ligne pour l'intrus...
Comme on le voit, l'utilisation du paramètre "-g 80" permet de configurer "nmap" en lui disant de se faire passer pour un serveur web ("HTTP" <=> 80). Cette option n'est utilisable que parce que l'intrus a lancé la commande en temps que root. Mais qu'importe, l'intrus est forcément root sur sa machine. Et dans notre configuration de Netfilter, comme nous avons explicitement autorisé les connexions rentrantes venant du port 80, Netfilter ne peut pas interdire ce port scanning... Quant à interdire les connexions venant du port 80, c'est tout bonnement impossible, car sinon nous ne pourrions plus accéder à des sites web...

Analyse d'un 'nmap -g 80'
Analyse d'un 'nmap -g 80'
On peut se demander si un tel port scanning a un réel intérêt. Bon, l'intrus sait que nos ports sont ouverts. Oui, et alors ? La belle affaire ! Notre Netfilter est là pour nous protéger, non ? Non, malheureusement pas avec une configuration si pitoyables...

Bon, notre intrus n'est pas né de la dernière pluie, et il connaît aussi le programme "nc" ("nc - TCP/IP swiss army knife", "man nc" pour plus d'informations). Avec ce programme, il va pouvoir ouvrir une connexion TCP/IP depuis son port 80, vers le port 80 de Phoenix, et envoyer toutes les commandes qu'il veut. Comme part exemple un "GET /index.html" qui permet de télécharger la page "/index.html". Cette commande est la base du protocole HTTP, et votre navigateur le fait pour ainsi dire tout le temps.
[root@pirate /]# nc -p 80 phoenix1.internet.net 80
GET /
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="GENERATOR" content="Mozilla/4.61 [en] (X11; I; Linux 2.2.9-23mdk i686) [Netscape]">
   <meta name="Author" content="MandrakeSoft">
   <title>Welcome to the Advanced Extranet Server, ADVX!</title>
La fin de la réponse a été coupée, car inutile. On voit bien ici la réponse du serveur web de Phoenix, qui affiche tout naturellement une page web de notre réseau local... Que le lecteur continue de s'inquiéter, ce qui est fait ici très simplement avec un serveur web, peut l'être tout autant avec un serveur un peu plus sensible, comme par exemple le partage de fichier "Samba" ou "NFS". Il ne faut pas grand chose en fait, juste un peu modifier les sources de programmes comme "smbmount" ou "mount"...

Bon, si à ce stade je n'ai pas réussi à capter toute votre attention sur ce problème, vous pouvez définitivement arrêter la lecture de ce document, et continuer de vous faire allégrement pirater ! Smiley

III-7-2 ... Et comment renvoyer l'intrus dans sa niche

Toujours là ? Parfait, passons à la solution de ce problème :

Bien, le problème ici est que notre intrus peut rentrer comme il veut par les différents ports que nous aurions laissé ouverts afin que nous, nous puissions aller sur Internet. En fait, il faudrait que notre firewall soit semi-perméable, c'est à dire qu'il ne laisse entrer des connexions venant du port 80, que si elles viennent en réponse de connexions qui auraient été initialisées par Phoenix. C'est justement ce que permet le module de suivi de connexion (conntrack) de Netfilter.

Cette technique est vraiment une avancée en matière de firewall. Netfilter se base sur la poignée de main ("handshake", que nous avons vu au 1er chapitre), afin de déterminer si une connexion a été initialisée par Phoenix ou non. Pour toute nouvelle connexion sortante, il associe l'état "NEW" ("nouveau" en anglais) à la connexion, et stocke cette information en mémoire. Quand il verra arriver d'autres connexions venant de l'extérieur en réponse à cette connexion "NEW", il leur attribuera alors l'état "ESTABLISHED" ("établie" en anglais). Ainsi, pour une connexion rentrante et qui ne se trouve pas déjà dans la mémoire de Netfilter, celui-ci pourra en déduire qu'elle a été initialisée par l'extérieur, et lui attribuera l'état "INVALID". Dans ce cas, et si il a été configuré pour, Netfilter pourra refuser ("DROP") ou rejeter ("REJECT") cette connexion.

Il existe un dernier statut intéressant pour le suivi de connexion, il s'agit du statut "RELATED" : Il existe certains protocoles, comme le FTP ou l'IRC par exemple, qui ne répondent pas toujours sur le port qui a initialisé la connexion. Au lieu de cela, ils initialisent eux-mêmes une connexion sur un autre port de la machine demandant l'information. Vous pouvez trouver une excellente explication sur le fonctionnement de ce mode particulier du protocole FTP sur ce site (la partie sur le "mode passif"). Pour certains de ces protocoles particuliers, Netfilter est capable de comprendre que cette nouvelle connexion rentrante est en fait en relation avec une autre connexion précédemment établie par la machine elle-même. Pour ce type de connexion, elle leur attribue le statut de "RELATED" (pour "relative" en anglais).

Suivi de connexion
Suivi de connexion
Voyons maintenant comment mettre en oeuvre cette technique. Le système de suivi de connexion de Netfilter n'est pas forcément compilé dans le kernel, donc si ce n'est pas le cas, vous devez d'abord charger le module "ip_conntrack" :
[root@phoenix /]# modprobe ip_conntrack
Si vous envisagez d'utiliser vos clients FTP en mode passif, ou que vous compter utiliser l'IRC, vous avez la possibilité de charger les modules "ip_conntrack" qui supportent ces protocoles :
[root@phoenix /]# modprobe ip_conntrack_ftp
[root@phoenix /]# modprobe ip_conntrack_irc
Enfin, pour voir la listes des modules "ip_conntrack" qui sont installés sur votre machine :
[root@phoenix /]# uname -a
Linux phoenix.sky.net 2.4.21-0.13mdksmp #1 SMP Fri Mar 14 13:41:18 EST 2003 i686 unknown unknown GNU/Linux
[root@phoenix /]# find /lib/modules/2.4.21-0.13mdksmp/ -iname "ip_conntrack_*"
/lib/modules/2.4.21-0.13mdksmp/kernel/net/ipv4/netfilter/ip_conntrack_ftp.o.gz
/lib/modules/2.4.21-0.13mdksmp/kernel/net/ipv4/netfilter/ip_conntrack_proto_gre.o.gz
/lib/modules/2.4.21-0.13mdksmp/kernel/net/ipv4/netfilter/ip_conntrack_h323.o.gz
/lib/modules/2.4.21-0.13mdksmp/kernel/net/ipv4/netfilter/ip_conntrack_irc.o.gz
/lib/modules/2.4.21-0.13mdksmp/kernel/net/ipv4/netfilter/ip_conntrack_pptp.o.gz
Maintenant, comment indiquer à Netfilter que nous ne désirons laisser passer que les connexions sortantes initialisées par la machine, mais aussi de ne laisser passer que celles qui sont en réponse avec les premières ? C'est tout simplement aussi facile que ce que nous venons de dire :
[root@phoenix /]# iptables -A OUTPUT -o eth1 -s 10.0.0.1  -d 0.0.0.0/0
                           -p all -m state --state ! INVALID           -j ACCEPT
[root@phoenix /]# iptables -A INPUT  -i eth1 -s 0.0.0.0/0 -d 10.0.0.1 
                           -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
  • Le paramètre "-m state" signifie que nous avons besoin du module "state" (celui du suivi de connexion), et de ses options particulières.
  • "--state" indique les états qui vont être utilisés pour nos règles.
  • "! INVALID" : comme vu plus haut, le module de suivi de connexion gère 4 états, NEW, ESTABLISHED, RELATED et INVALID. Ce paramètre indique que l'on accepte uniquement les connexions qui ne sont pas invalides, donc qui sont "NEW, ESTABLISHED, RELATED". Ceci est uniquement un manière plus rapide d'écrire qu'il faut que les connexions soient d'un des 3 états "NEW, ESTABLISHED, RELATED".
Voila, nous venons de terminer notre configuration de Netfilter en utilisant le suivi de connexion. Le script iptables de tout ceci se trouve ici.

Mais est-ce vraiment efficace ? On va le voir tout de suite :
[root@pirate /]# nmap phoenix1.internet.net -g 80 -P0

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
All 1601 scanned ports on phoenix1.internet.net (10.0.0.1) are: filtered

Nmap run completed -- 1 IP address (1 host up) scanned in 1721 seconds
On utilise l'option -P0 pour forcer la connexion par "nmap", vu que Phoenix refuse de répondre aux demandes les plus simples. On remarque que le scan est excessivement long (1721 secondes, soit près d'une demi heure...), car Pirate fait son scan en testant une dizaine de ports en parallèle, mais attends une dizaine de secondes pour chaque groupe de ports testés.
Dans ces conditions, Nmap ne peut déterminer si Phoenix est joignable ou pas.

Sur Phoenix on peut voir par contre qu'un grand nombre de paquets entrants ont été "dropés". Ce sont les tentatives de connexions de "nmap" :
[root@phoenix /]# iptables -L -v -n
Chain INPUT (policy DROP 6571 packets, 268K bytes)
 pkts bytes target     prot opt in     out  source         destination
 3480 2235K ACCEPT     all  --  lo     *    0.0.0.0/0      0.0.0.0/0
    9  2232 ACCEPT     all  --  eth0   *    192.168.0.0/24 192.168.0.0/24
    0     0 ACCEPT     all  --  eth1   *    0.0.0.0/0      10.0.0.1       state RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out  source         destination

Chain OUTPUT (policy DROP 22 packets, 1716 bytes)
 pkts bytes target     prot opt in     out  source         destination
    0     0 ACCEPT     tcp  --  *      *    0.0.0.0/0      0.0.0.0/0      tcp spt:6000
    0     0 ACCEPT     tcp  --  *      *    0.0.0.0/0      0.0.0.0/0      tcp spt:6000
 3480 2235K ACCEPT     all  --  *      lo   0.0.0.0/0      0.0.0.0/0
    9  2232 ACCEPT     all  --  *      eth0 192.168.0.0/24 192.168.0.0/24
   97  9096 ACCEPT     all  --  *      eth1 10.0.0.1       0.0.0.0/0      state NEW,RELATED,ESTABLISHED
La conclusion est sans appel : notre machine est un "trou noir" qui se refuse de répondre aux sollicitations extérieures. Par contre, Phoenix arrive toujours à se connecter sur internet.net :
[olivier@phoenix /]$ ping web.internet.net
PING web.internet.net (10.0.0.200) 56(84) bytes of data.
64 bytes from web.0.0.10.in-addr.arpa (10.0.0.200): icmp_seq=1 ttl=64 time=2.22 ms
64 bytes from web.0.0.10.in-addr.arpa (10.0.0.200): icmp_seq=2 ttl=64 time=0.300 ms

--- web.internet.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1010ms
rtt min/avg/max/mdev = 0.300/1.263/2.227/0.964 ms
[olivier@phoenix /]$ nmap web.internet.net -p 80,443

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on web.0.0.10.in-addr.arpa (10.0.0.200):
Port       State       Service
80/tcp     open        http
443/tcp    open        https

Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds
Victoire ? Cette fois ci, OUI !!! L'intrus ne peut nullement accéder de lui-même à notre machine, toutes ses tentatives de "nmap" échouent. Votre machine a donc été en grande partie sécurisée. Comparé à la situation au début de la lecture de ce document, vous pouvez donc être un peu plus tranquille, et vous avez un peu moins à craindre des intrus. Mais, et comme nous le verrons en conclusion de ce chapitre, ce n'est pas pour autant que vous ne risquez rien.

Bien, maintenant que nous avons sécurisé l'accès à notre machine grâce à la table "Filter", passons aux autres fonctionnalités intéressantes de Netfilter : passons à l'exploitation de la table "NAT".

Table des matières Page précédente Page suivante
Valid XHTML 1.0! Valid CSS!
Site de référence : http://olivieraj.free.fr/ Last modified: Wed Jul 23 19:20:24 CEST 2003