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 :
|
 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 !  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 |
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_ircEnfin, 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.gzMaintenant, 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
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,ESTABLISHEDLa 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 secondsVictoire ? 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". |
|
