Jusqu'? pr駸ent, la machine Paradise de notre r駸eau n'a pas 騁? tr鑚 utilis馥. Son activit? r駸eau est restreinte ? celle du r駸eau sky.net. Alors que Phoenix, lui, peut se connecter au r駸eau internet.net. Tout cela n'est pas tr鑚 juste, aussi allons nous y rem馘ier. Comment ? En transformant tout simplement Phoenix en une passerelle entre les r駸eaux sky.net et internet.net.

Dans tout ce qui suit, nous allons nous arranger pour que paradise.sky.net puisse se connecter au serveur web web.internet.net.

Sous Windowsョ, ce que nous allons faire s'appelle du "partage de connexion Internet", ce qui est tout ? fait vrai : Phoenix va partager sa connexion ? Internet avec les machines du r駸eaux sky.net.

Pour r饌liser ceci, il nous faut r饌liser plusieurs op駻ations :

• La premi鑽e, c'est de charger les modules dont nous allons avoir besoin. En premier, nous avons besoin du module de NAT, c'est ? dire "iptables_nat". Comme nous voulons aussi faire du suivi de connexion sur les paquets NAT, nous chargerons de m麥e les modules NAT FTP et IRC, "ip_nat_ftp" et "ip_nat_irc" :

  [root@phoenix /]# modprobe iptable_nat
  [root@phoenix /]# modprobe ip_nat_ftp
  [root@phoenix /]# modprobe ip_nat_irc
  

• Bien entendu, tout comme nous initialisons la table "Filter" nous devons initialiser la tables NAT :

  [root@phoenix /]# iptables -t nat -F
  [root@phoenix /]# iptables -t nat -X
  

• Pour ce qui est des cibles par d馭aut des cha?nes de la table NAT, nous acceptons toutes les connexions. Il n'est pas n馗essaire de faire pointer ces cibles sur "DROP", car la s馗urit? est 騁ablie au niveau de la table "Filter", par le "DROP" par d馭aut de la cha?ne FORWARD :

  [root@phoenix /]# iptables -t filter -P FORWARD DROP
  [root@phoenix /]# iptables -t nat -P PREROUTING ACCEPT
  [root@phoenix /]# iptables -t nat -P POSTROUTING ACCEPT
  [root@phoenix /]# iptables -t nat -P OUTPUT ACCEPT
  

• Bien, maintenant nous allons faire suivre sur le r駸eau internet.net, les connexions issues du r駸eau sky.net. Bien entendu, nous ne ferons suivre que les connexions qui sont ? destination du r駸eau internet.net, et non celles destin馥s ? la machine Phoenix elle-m麥e. Pour cela, nous allons avoir besoin d'utiliser la table "Filter" (he oui, encore !), afin de faire suivre les paquets venant de la carte eth0 (phoenix0.sky.net) ? la carte eth1 (phoenix1.internet.net), et vice versa. En plus de cela, comme ce sont uniquement les connexions initialis馥s par le r駸eau interne que nous d駸irons faire sortir, nous rajouterons un peu de suivi de connexion.

  [root@phoenix ]# iptables -t filter -A FORWARD -i eth0 -o eth1 -s 192.168.0.0/24 -d 0.0.0.0/0 \
   -m state --state ! INVALID -j ACCEPT
  [root@phoenix ]# iptables -t filter -A FORWARD -i eth1 -o eth0 -s 0.0.0.0/0 -d 192.168.0.0/24 \
   -m state --state ESTABLISHED,RELATED -j ACCEPT
  

  L'accumulation des param鑼res "-i", "-o", "-s", "-d" et "--state" permettent de garantir que seul les connexions initialis馥s par le domaine sky.net seront autoris馥s ? passer, et non l'inverse.
  

• Au point o? nous en somme, les paquets venant de sky.net et sortant par l'interface eth1, ont :
  • pour adresse de destination, une adresse du r駸eau internet.net, ce qui est parfaitement normale. Celle de web.internet.net par exemple
  • pour adresse source, l'adresse d'une machine du domaine sky.net, comme par exemple celle de paradise.sky.net (voir lien "(1)"). Oui, mais ce domaine est un r駸eau priv?, dont l'adresse IP n'est pas du tout routable sur Internet. Conclusion : lorsque web.internet.net recevra la requ黎e, il ne saura absolument pas o? envoyer la r駱onse... C'est assez ennuyeux, non ?
  Il va donc falloir que Phoenix subtilise l'adresse IP source des trames qui le traverse, et la remplace par la sienne (voir lien "(2)"). C'est l? qu'intervient (enfin !) la table NAT, avec la cible "MASQUERADE" (pour "masquage" en anglais) :

  [root@phoenix /]# iptables -t nat -A POSTROUTING -o eth1 \
   -s 192.168.0.0/24 -j MASQUERADE
  

  Vous pouvez cependant vous poser la question suivante : que deviennent les paquets revenant du r駸eau internet.net sur l'interface eth1 ? Ils ont pour adresse source web.internet.net, et pour adresse cible phoenix1.internet.net (voir lien "(3)"). Donc si ils sont recopi駸 sur le r駸eau sky.net, ils ne saurons pas qu'ils doivent aller sur paradise.sky.net, non ? En th駮rie, ceci est exacte, et demanderait la mise en place d'une seconde r鑒le de de "MASQUERADE". Mais en fait, c'est inutile, car avec la premi鑽e r鑒le, Netfilter g鑽e une table en m駑oire qui suit ces masquage d'adresses IP, et elle r饌ssigne aux connexions rentrantes la bonnes adresse IP cibles (voir lien "(4)").
  
  En fait, ce serait m麥e terriblement dangereux de mettre en place une telle r鑒le de ce type. En effet, cela pourrait faire passer pour des connexions de Phoenix, des connexions initialis馥s par les machines de internet.net ! C'est comme si vous poussiez vous-m麥e le loup dans la bergerie ! Donc l'utilisation de la table NAT et de la cible "MASQUERADE" doivent se faire avec le plus rigueur possible, souvenez vous en bien.
  
  
• Enfin, maintenant que tout le NAT est configur?, il ne reste plus qu'? autoriser d?ment votre Linux ? faire jouer son r?le de gateway. Pour cela, il faut utiliser simplement 馗rire un "1" dans le "/proc/sys/net/ipv4/ip_forward". Ce fichier est en fait un fichier virtuel, qui permet de dialoguer directement avec le kernel. Nous allons donc utiliser la commande suivante :

  [root@phoenix /]# echo 1> /proc/sys/net/ipv4/ip_forward
  

Masquage d'adresse
Masquage d'adresse

Le NAT 騁ant maintenant configur? et activ?, il reste ? configurer les machines du r駸eau sky.net, afin de leur indiquer quelle est la passerelle. C'est chose faite en lan軋nt par exemple sur paradise.sky.net :

[root@paradise /]# route add default gw phoenix0.sky.net
[root@paradise /]# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default phoenix0.sky.ne 0.0.0.0 UG 0 0 0 eth0

Bien, tout est en place. Voyons ce que cela donne. Depuis paradise.sky.net, tentons une connexion sur web.internet.net:

[olivier@paradise /]$ 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

Bien ! Comme on le voit, la connexion se fait d'un r駸eau ? l'autre, ? travers Phoenix. Op駻ation r騏ssie donc ! Cela qui nous donne l'occasion de trouver ici le script iptables de cet exemple.

Remarques : Dans tout nos exemples, nous avons syst駑atiquement autoris? tout le r駸eau sky.net ? acc馘er ? internet.net. Cependant, nous aurions tr鑚 bien pu limiter cet acc鑚 ? uniquement quelques machines de notre r駸eau interne. Pour cela, il suffit de changer les options "-s" et "-d" de nos r鑒les de "FORWARD", et d'indiquer l'adresse IP de la machine qui est autoris馥 ? passer d'un r駸eau ? un autre.
Exemple :

[root@phoenix ]# iptables -t filter -A FORWARD -i eth0 -o eth1 -s 192.168.0.2 -d 0.0.0.0/0 \
 -m state --state ! INVALID -j ACCEPT
[root@phoenix ]# iptables -t filter -A FORWARD -i eth1 -o eth0 -s 0.0.0.0/0 -d 192.168.0.2 \
 -m state --state ESTABLISHED,RELATED -j ACCEPT

Et qu'en dit la s馗urit? ? Est-ce que par hasard pirate.internet.net peut acc馘er ? paradise.sky.net ? Est-ce possible ? Techniquement oui, il suffit que pirate.internet.net d馗lare phoenix1.internet.net comme 騁ant sa passerelle pour le r駸eau internet.net :

[root@pirate /]# route add default gw phoenix1.internet.net
[root@pirate /]# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default phoenix1.intern 0.0.0.0 UG 0 0 0 eth0

Puis, de lancer par exemple un "ping" sur l'adresse IP de paradise.sky.net :

[root@pirate /]# ping -c 3 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
--- 192.168.0.2 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2014ms

Bien, notre machine est correctement s馗uris馥. Tout va donc pour le mieux ? Ind駭iablement, oui. Mais tel un funambule entrain de traverser le vide sur une corde tendue, il ne faut pas grand chose pour que cette 騁at id饌l se transforme en un cauchemar sans nom... Smiley

En effet, regardons les traces qu'on laiss? la derni鑽e connexion de pirate.internet.net dans les statistiques de Netfilter :

[root@phoenix /]# iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 3 packets, 252 bytes)
 pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source destination
 0 0 MASQUERADE all -- * eth1 192.168.0.0/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source destination

Cette commande nous indique que 3 paquets ont 騁? accept駸 par le comportement par d馭aut de la cha?ne "PREROUTING" de la table "NAT". C'est tout ? fait normal, ce sont nos 3 paquets de ping qui arrivent de pirate.internet.net et qui s'appr黎ent ? passer ? travers Phoenix. Mais qui va les arr黎er ?

[root@phoenix /]# iptables -L -v -n -t filter
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source destination
 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
 0 0 ACCEPT all -- eth0 * 192.168.0.0/24 192.168.0.0/24
Chain FORWARD (policy DROP 3 packets, 252 bytes)
 pkts bytes target prot opt in out source destination
 0 0 ACCEPT all -- eth0 eth1 192.168.0.0/24 0.0.0.0/0 state NEW,RELATED,ESTABLISHED
 0 0 ACCEPT all -- eth1 eth0 0.0.0.0/0 192.168.0.0/24 state RELATED,ESTABLISHED
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source destination
 0 0 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
 0 0 ACCEPT all -- * eth0 192.168.0.0/24 192.168.0.0/24

Cette commande l? nous indique que 3 paquets ont 騁? d騁ruits par le comportement par d馭aut de la cha?ne "FORWARD" de la table "Filter". L? encore, c'est ce ? quoi nous attendions. Pourquoi ? Parce qu'aucune des autres r鑒les de la cha?ne "FORWARD" de cette table ne les ont laiss? passer.

Maintenant, changeons seulement le comportement par d馭aut de la table "FORWARD" de la table "Filter" :

[root@phoenix /]# iptables -t filter -P FORWARD ACCEPT

Juste pour information, on pourra t駘馗harger ce m馗hant script iptables ici.

Et relan輟ns notre "ping" depuis pirate.internet.net :

[intrus@pirate /]$ ping -c 3 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=254 time=0.957 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=254 time=0.987 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=254 time=0.957 ms
--- 192.168.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2021ms
rtt min/avg/max/mdev = 0.957/0.967/0.987/0.014 ms

QUOI !?!? Notre intrus peut acc馘er sans probl鑪e ? l'int駻ieur de notre r駸eau ? Diantre, il y a un bug, et un m馗hant ! Et tout cela ? cause d'un malheureuse r鑒le par d馭aut ?

Oui, exactement. Regardons les statistiques d'iptables pour la table "Filter" :

[root@phoenix /]# iptables -L -v -n -t filter
Chain INPUT (policy DROP 0 packets, 0 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 dpt:6000
 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6000
 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
 0 0 ACCEPT all -- eth0 * 192.168.0.0/24 192.168.0.0/24
Chain FORWARD (policy ACCEPT 3 packets, 252 bytes)
 pkts bytes target prot opt in out source destination
 3 252 ACCEPT all -- eth0 eth1 192.168.0.0/24 0.0.0.0/0 state NEW,RELATED,ESTABLISHED
 0 0 ACCEPT all -- eth1 eth0 0.0.0.0/0 192.168.0.0/24 state RELATED,ESTABLISHED
Chain OUTPUT (policy DROP 0 packets, 0 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
 0 0 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
 0 0 ACCEPT all -- * eth0 192.168.0.0/24 192.168.0.0/24

Voil? quelque chose de tr鑚 int駻essant :

• 3 paquets sont pass駸 par la cible "ACCEPT" par d馭aut de la cha?ne "Filter". Se sont les 3 pings venant de pirate.internet.net? destination de paradise.sky.net. Notre trou de s馗urit? se trouve ind駭iablement ici.
• 3 autres paquets ont utilis駸 la r鑒le bas馥 sur du suivi de connexion, partant du r駸eau sky.net et allant sur internet.net. Bien s?r, c'est tout ? fait normal. Car pour Netfilter, une connexion sky.net -> internet.net est bien initialis馥 ou en relation avec une autre...

Regardons maintenant les statistiques de la table "NAT" :

[root@phoenix /]# iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 3 packets, 252 bytes)
 pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 3 packets, 252 bytes)
 pkts bytes target prot opt in out source destination
 0 0 MASQUERADE all -- * eth1 192.168.0.0/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source destination

3 paquets sont pass駸 par les cha?nes "PREROUTING" puis "POSTROUTING" afin de sortir du r駸eau internet.net et atteindre le r駸eau sky.net. Par contre, il n'y a pas de traces des paquets de r駱onse de paradise.sky.net ? pirate.internet.net. Ceci est d? au m馗anisme interne de Netfilter qui identifie les connexions en r駱onse, et qui ne les fait pas passer par la table NAT. C'est pour cela, et comme vu plus haut, qu'il n'y a pas besoin d'馗rire des r鑒les sp馗ifiques pour le "MASQUERADING rentrant".

De cette (longue) explication nous pourrons en tirer 3 le輟ns :

• Il faut toujours initialiser les cibles par d馭aut, m麥e pour les cha?nes des tables que nous ne pensons peut-黎re pas utiliser. Il faut en toute situation conna?tre l'騁at de de ces cibles. Un script Netfilter devrait donc toujours commencer par :

  # Initialisation de la table FILTER
  iptables -t filter -F
  iptables -t filter -X
  iptables -t filter -P INPUT DROP
  iptables -t filter -P OUTPUT DROP
  iptables -t filter -P FORWARD DROP
  # Initialisation de la table NAT
  iptables -t nat -F
  iptables -t nat -X 
  iptables -t nat -P PREROUTING ACCEPT
  iptables -t nat -P POSTROUTING ACCEPT
  iptables -t nat -P OUTPUT ACCEPT
  # Initialisation de la table MANGLE
  iptables -t mangle -F
  iptables -t mangle -X 
  iptables -t mangle -P PREROUTING ACCEPT
  iptables -t mangle -P INPUT ACCEPT
  iptables -t mangle -P OUTPUT ACCEPT
  iptables -t mangle -P FORWARD ACCEPT
  iptables -t mangle -P POSTROUTING ACCEPT
  

• Avant de mettre en place un syst鑪e de NAT, il faut bien prendre en compte tous les param鑼res, et se rendre compte de l'impact que cela peut avoir sur la s馗urit? de votre r駸eau. Il n'y a rien de pire que de copier/coller un mauvais morceau de script "iptables", et de se dire que cela doit bien marcher tout seul. Voir de bidouiller affreusement le script dans son coin, et de jouer ? l'apprenti sorcier ! Smiley
• En cas de doute, ou de probl鑪e sur l'utilisation de Netfilter, il ne fait pas h駸iter ? utiliser la commande "iptables -L -v -t [table]" qui donne plein d'informations quand aux nombre de paquets passant par une r鑒le ou un comportement par d馭aut.

Bien, l'IP masquerading 騁ant vu, passons au port forwarding.

Bien cach? derri鑽e notre firewall Phoenix, notre r駸eau sky.net ne craint plus grand chose. De plus, avec ce que nous avons vu au chapitre pr馗馘ent, les machines de notre r駸eau local peuvent rejoindre le r駸eau internet.net.

Maintenant, nous voudrions avoir un serveur (HTTP, FTP, IRC, peer-to-peer, etc...) qui puisse proposer des informations et des services non plus sur le r駸eau sky.net, mais carr駑ent sur le r駸eau internet.net. L'emplacement d'un tel service devrait se faire en toute logique sur la machine Phoenix, qui est le seul acc鑚 que nous ayons sur le r駸eau internet.net. Mais ceci serait une tr鑚 mauvaise id馥. Pourquoi ? Parce qu'un tel acc鑚 est in騅itablement une faille dans notre syst鑪e de s馗urit?. Gr稍e ? ce service que nous proposons, l'intrus pourrait essayer de se l'accaparer, puis d'en profiter pour prendre la main sur Phoenix, et d'enfin de court-circuiter toutes nos r鑒les Netfilter. Notre machine se trouverait alors sans aucune protection vis ? vis de l'ext駻ieur... Inqui騁ant, non ? Au minimum, il faudrait configurer ce service pour fonctionner sous un utilisateur n'ayant que peu de droits, et en plus dans un chroot. Mais m麥e avec cela, la s馗urit? ne pourrait pas 黎re garantie.

Alors, comment faire ? C'est l? qu'intervient le suivi de port ("port fowarding" en anglais). L'id馥 d'un tel syst鑪e est que toute connexion entrante sur un certain port de phoenix1.internet.net (par exemple le port 80, pour du HTTP), soit automatiquement redirig馥 vers une autre machine de sky.net : paradise.sky.net par exemple. Vu de l'ext駻ieur, on aurait l'impression que le port 80 de phoenix1.internet.net serait ouvert, mais en fait, ce serait le port 80 de paradise.sky.net qui serait r馥llement ouvert, et sur lequel tournerait un serveur Apache.

Est-ce r馥llement une "solution miracle" ? Presque, mais ? condition de prendre quelques pr馗autions :

• Dans cette configuration, nous ne faisons que d駱lacer le probl鑪e de s馗urit? sur Paradise. Il faut donc que cette machine soit tr鑚 bien s馗uris馥, avec les param騁rages vus dans la section "risque" du chapitre II. Mais ce ne sera pas suffisant.
• Paradise devenant donc un serveur web ? part enti鑽e, et du fait des risques 駭onc駸, Phoenix devra donc s'en m馭ier comme de la peste. Fini les gentilles r鑒les Netfilter laissant paradise.sky.net pleinement acc馘er ? phoenix0.sky.net. Il faudra durcir tout cela, et utiliser le conntrack ! Dans notre esprit, paradise.sky.net devra devenir aussi soup輟nnable que pirate.internet.net.
• Enfin, dans le cas o? un intrus prendrait le contr?le de Paradise, et m麥e si Phoenix ? des r鑒les Netfilter tr鑚 strictes, rien n'emp鹹herait l'intrus de s'attaquer ? une autre machine du r駸eau sky.net ! Voir dans le pire des cas, de s'approprier le contr?le d'une autre machine de sky.net, puis d'attaquer Phoenix par l'arri鑽e, en profitant d'騅entuelles r鑒les Netfilter plus souples vis ? vis de ce 2nd h?te...

En terme de s馗urit? informatique, la parano?a peut devenir un jeu d'esprit o? il faut syst駑atiquement envisager les pires cas, et les hypoth鑚es les plus tordues. Dans le cas de notre r駸eau, les 3 probl鑪es ci-dessus peuvent 黎res r馮l駸 par une technique plut?t efficace, appel馥 DMZ ("DeMilitarized Zone ou "Zone D?Militaris馥" en fran軋is). La mise en place d'une telle DMZ se fait en installant une 3鑪e carte r駸eau sur Phoenix ("eth2"), sur laquelle on ne reliera que une seule machine qui ne servira qu'au seul usage de serveur web. On appellera cette machine DMZ, tout simplement. Voir ? ce sujet l'illustration ci-contre. Mais ceci sort du cadre de ce document, et d'un r駸eau personnel, je n'en parlerai donc pas plus longuement. DMZ
DMZ pour port fowarding

Mais revenons ? un r駸eau un peu plus simple, et baissons d'un cran notre parano?a. Nous allons supposer que la machine qui h饕ergera notre serveur HTTP est fiable, et que personne ne peut en prendre la main (ceci n'est qu'une hypoth鑚e bien s?r !). Nous la laisserons donc dans le r駸eau sky.net, en compagnie des autres machines de notre r駸eau interne.

Que devons nous faire ?

• Tout d'abord, nous devons initialiser la table NAT, tout comme nous l'avons fait pour le IP masquerading. Et aussi bien s?r charger le module "iptables_nat" :

  [root@phoenix /]# modprobe iptable_nat
  [root@phoenix /]# iptables -t nat -F
  [root@phoenix /]# iptables -t nat -X
  [root@phoenix /]# iptables -t filter -P FORWARD DROP
  [root@phoenix /]# iptables -t nat -P PREROUTING ACCEPT
  [root@phoenix /]# iptables -t nat -P POSTROUTING ACCEPT
  [root@phoenix /]# iptables -t nat -P OUTPUT ACCEPT
  

• Comme nous voulons partager un serveur HTTP, il peut 黎re int駻essant d'autoriser les machines de internet.net de pouvoir utiliser le "ping" sur notre serveur. Ce n'est absolument pas une obligation, mais cela peut-黎re pratique pour les Internautes qui, avant de lancer la connexion HTTP, v駻ifient que notre machine est bien active. Ce choix rel钁e plus d'une bonne mani鑽e qu'autre chose, et n'est donc pas obligatoire. Notre "port forwarding" pourra tr鑚 bien marcher sans cela. On utilise quand m麥e du "suivi de connexion", afin de ne pas accepter les paquets ICMP volontairement mal format駸 :

  [root@phoenix /]# iptables -t filter -A INPUT -i eth1 -s 0.0.0.0/0 -d 10.0.0.1 \
   -p icmp -m state --state ! INVALID -j ACCEPT
  [root@phoenix /]# iptables -t filter -A OUTPUT -o eth1 -s 10.0.0.1 -d 0.0.0.0/0 \
   -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT
  

  Au passage, vous noterez qu'il n'est pas n馗essaire d'ouvrir d'autres acc鑚. Et notamment via les cha?nes "INPUT" et "OUTPUT" afin autoriser l'馗hange avec le port 80. Pourquoi ? Simplement parce que dans le cas du port forwarding, les trames ? destination de paradise.sky.net ne sont pas destin馥s aux processus locaux, et donc elle ne passent pas ? travers les cha?nes "INPUT" et "OUTPUT". En fait, comme on le verra tout de suite, seul la cha?ne "FORWARD" de la table "Filter" devra 黎re modifi馥.
• Nous allons maintenant faire suivre un certain type de paquets de l'interface "eth1" ? l'interface "eth0" : Ce sera les paquets ? destination du serveur HTTP. De m麥e que nous laisserons passer les paquets en r駱onse. L? encore, nous utilisons du "conntrack" afin d'am駘iorer la s馗urit? de ce suivi de port :

  [root@phoenix /]# iptables -t filter -A FORWARD -i eth1 -o eth0 -s 0.0.0.0/0 \
   -d 192.168.0.2 -p tcp --dport 80 \
   -m state --state ! INVALID -j ACCEPT
  [root@phoenix /]# iptables -t filter -A FORWARD -i eth0 -o eth1 -s 192.168.0.2 \
   -d 0.0.0.0/0 -p tcp --sport 80 \
   -m state --state RELATED,ESTABLISHED -j ACCEPT
  

• Nous arrivons ? la 1er sp馗ificit? du "port forwarding". Pour les paquets entrant sur phoenix1.internet.net et ? destination du port 80, nous allons modifier l'adresse de destination. Ce ne sera plus phoenix1.internet.net, mais paradise.sky.net, c'est ? dire notre r馥l serveur HTTP. Pour cela, nous allons utiliser dans la table NAT, la cha?ne "PREROUTING" et la cible "DNAT" (pour "Destination Network Adress Translation" en anglais).

  [root@phoenix /]# iptables -t nat -A PREROUTING -i eth1 -s 0.0.0.0/0 \
   -d 10.0.0.1 -p tcp --dport 80 \
   -m state --state ! INVALID -j DNAT --to-destination 192.168.0.2:80
  

  Au passage, on voit que l'on peut aussi modifier le port de destination, et mettre autre chose que 80. Cela peut-黎re utile si le serveur HTTP sur paradise.sky.net tourne sur autre chose que le port 80.
• La seconde sp馗ificit? du "port forwarding", c'est de modifier aussi l'adresse source de la requ黎e. En effet, si nous laissons l'adresse source actuelle (une adresse de 10.0.0.0/8 par exemple), paradise.sky.net sera bien ennuy? pour r駱ondre, car ce sera une adresse d'un r駸eau qu'il ne peut pas joindre. ノvidement, nous pourrions indiquer ? paradise.sky.net que phoenix0.sky.net est une passerelle, et dans ce cas l? les paquets retrouveraient tout de suite la sortie du r駸eau sky.net. Mais, et m麥e si cette solution marche effectivement tr鑚 bien, c'est une solution particuli鑽ement mal propre, comme nous le verrons un peu plus loin. Donc, modifions cette adresse source :

  [root@phoenix /]# iptables -t nat -A POSTROUTING -o eth0 -s 0.0.0.0/0 \
   -d 192.168.0.2 -p tcp --dport 80 \
   -m state --state ! INVALID -j SNAT --to-source 192.168.0.1
  

• Bien, au niveau de Netfilter, tout est configur?. Il nous reste qu'? activer le NAT par la commande que nous connaissons d駛? :

  [root@phoenix /]# echo 1> /proc/sys/net/ipv4/ip_forward
  

Le script iptables d馗rit ici est t駘馗hargeable ici.

Il ne nous reste plus qu'? v駻ifier que pirate.internet.net a bien acc鑚 ? phoenix1.internet.net :

[intrus@pirate /]$ telnet phoenix1.internet.net 80
Escape character is '^]'.
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>
 <LINK REL="SHORTCUT ICON" HREF="/favicon.ico">
<!-- Background white, links blue (unvisited), navy (visited), red (active) --> </head>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#000080" alink="#FF0000">
<table border=0>
<tr>
<td valign=top><a href=http://www.advx.org><img border=0 src=/icons/advx.png
ALT="Powered by ADVX.org software" height=47 width=102 align=LEFT></a></td>
<td valign=top width=100%><h2><center>Welcome to paradise.sky.net
</center></h2>
</td></tr>

La fin de la r駱onse a 騁? tronqu馥. Bien que l'on acc鐡e ? phoenix1.internet.net, c'est paradise.sky.net qui r駱ond. Regardons maintenant le log du serveur Apache de paradise.sky.net :

[root@paradise /]# tail -1 /var/log/httpd/access_log
192.168.0.1 - - [06/Jul/2003:21:02:21 +0200] "GET /" 200 6988 "-" "-"

On voit la connexion faite par pirate.internet.net, et le t駘馗hargement de la page web. Cependant, on notera que l'adresse IP qui est log馥 n'est pas celle de pirate.internet.net, mais bien celle de phoenix1.internet.net, ce qui est tout ? fait normal, du fait de l'utilisation de la cible "SNAT".

Enfin, regardons ce que nous donne les statistiques de Netfilter sur Phoenix :

[root@phoenix /]# iptables -L -v -n -t filter
Chain INPUT (policy DROP 0 packets, 0 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 dpt:6000
 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6000
 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
 0 0 ACCEPT all -- eth0 * 192.168.0.0/24 0.0.0.0/0
 0 0 ACCEPT icmp -- eth1 * 0.0.0.0/0 10.0.0.1 state NEW,RELATED,
 ESTABLISHED
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source destination
 8 430 ACCEPT tcp -- eth1 eth0 0.0.0.0/0 192.168.0.2 tcp dpt:80 state
 NEW,RELATED,ESTABLISHED
 8 7412 ACCEPT tcp -- eth0 eth1 192.168.0.2 0.0.0.0/0 tcp spt:80 state
 RELATED,ESTABLISHED
Chain OUTPUT (policy DROP 0 packets, 0 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
 0 0 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
 0 0 ACCEPT all -- * eth0 0.0.0.0/0 192.168.0.0/24
 0 0 ACCEPT icmp -- * eth1 10.0.0.1 0.0.0.0/0 state RELATED,
 ESTABLISHED
[root@phoenix /]# iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source destination
 1 60 DNAT tcp -- eth1 * 0.0.0.0/0 10.0.0.1 tcp dpt:80 state NEW,RELATED,
 ESTABLISHED to:192.168.0.2:80
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source destination
 1 60 SNAT tcp -- * eth0 0.0.0.0/0 192.168.0.2 tcp dpt:80 state NEW,RELATED,
 ESTABLISHED to:192.168.0.1

La requ黎e et l'envoi de la page HTML ont demand駸 au total 2 fois 8 paquets, qui sont pass駸 ? travers les cha?nes "FORWARD".

On voit bien que les paquets entrant dans phoenix1.internet.net sont bien pass駸 par les cibles "DNAT" et "SNAT" des cha?nes "PREROUTING" et "POSTROUTING". Par contre ces statistiques ne montre pas les paquets en r駱onses ? la demande de connexion. C'est d? ? la m麥e routine de suivi de connexion de Netfilter que pour l'IP masquerading.

Nous pourrions nous arr黎er ici pour le port fowarding, mais un dernier point est int駻essant ? soulever : que se passe t'il si nous n'incluons pas la r鑒les SNAT, ce qui est indiqu? plus haut comme 騁ant une "m騁hode sale" ?

Commen輟ns par retirer cette r鑒le :

[root@phoenix /]# iptables -D POSTROUTING 1 -t nat

Puis, indiquons ? Paradise que sa passerelle est phoenix0.sky.net

[root@paradise /]# route add default gw phoenix0.sky.net
[root@paradise /]# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default phoenix0.sky.ne 0.0.0.0 UG 0 0 0 eth0

Et maintenant, demandons ? nouveau notre page HTML depuis pirate.internet.net. Suite ? cette connexion, les statistiques d'"iptables" nous donne :

[root@phoenix /]# iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source destination
 1 60 DNAT tcp -- eth1 * 0.0.0.0/0 10.0.0.1 tcp dpt:80 state NEW,RELATED,
 ESTABLISHED to:192.168.0.2:80
Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes)
 pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

Comme pr馗馘emment, un paquet est pass? par le cha?ne "PREROUTING", mais aucun n'est pass? par de r鑒les "POSTROUTING". Et pour cause, il n'y en a plus. Par contre, le paquet de retour est pass? par la r鑒le par d馭aut de la cha?ne POSTROUTING... C'est parce que les paquets n'empruntent pas les m麥es canaux en entr馥 et en sortie que j'estime cette m騁hode comme 騁ant "sale".

Enfin ce qui est le plus int駻essant c'est le log d'Apache sur paradise.sky.net :

[root@paradise /]# tail -1 /var/log/httpd/access_log
10.0.0.66 - - [06/Jul/2003:22:27:43 +0200] "GET /" 200 6988 "-" "-"

Cette fois ci, c'est bien l'adresse IP de la machine ? distance qui est stock馥, forc駑ent, puisque Phoenix ne la dissimule plus.

Vous trouverez le script de cet exemple ici, mais comme indiqu?, plus haut c'est la m騁hode "sale" pour effectuer du port forwarding...

Ceci conclue donc l'utilisation du port forwarding. Dans le cadre d'un usage personnel, cette technique est assez peu utile : qui chez lui h饕erge son propre serveur HTTP, FTP, IRC, etc...

Pas utile donc ? En fait non, il y a bien un usage personnel fort utile o? l'on peut utiliser le port forwarding, et qui est particuli鑽ement ? la mode au jour o? j'馗ris ces lignes : il s'agit du peer-to-peer (P2P). C'est un syst鑪e d'馗hange de fichiers ? travers Internet, o? toutes les machines connect馥s partagent des fichiers sur un morceau de son disque dur. Chaque machine agit donc ? la fois comme un client et un serveur. Une grand partie des clients pour ce type d'馗hange se trouvant sous Windowsョ, et comme c'est un OS dont l'usage courant est peu orient? sur la s馗urit?, on peut utiliser le port forwarding de Linux pour le prot馮er.

Avec les explications ci-dessus, vous pouvez sans difficult? 馗rire vos propres scripts iptables afin de renvoyer vos connexions entrantes vers la machine sur lequel tourne votre client P2P. Cependant, souvenez vous que vous ne faites que d駱lacer le probl鑪e de s馗urit? sur cette machine ci, et donc que c'est ? vous d'en assurer la responsabilit?. Si cette machine est par exemple sous Windowsョ, la pr駸ence de Netfilter en t黎e de votre r駸eau ne vous dispense pas de mettre en place un firewall logiciel sur cette machine, afin par exemple de surveiller ce que fait votre Windowsョ. Ceci 騁ant, je me lave les mains de ce que vous pourriez faire de l'usage du port forwarding et du P2P. Et si je ne fournis aucun script d'exemple, c'est entre autre parce que je n'utilise pas ce type de logiciel... Smiley

Enfin, je dirais que la mise en place du port forwarding n'est pas forc駑ent ce qui se fait le plus facilement, bien qu'en fait les r鑒les ne soit pas beaucoup plus complexes que pour l'IP masquerading. Sur Internet, vous trouverez beaucoup de bribes d'explications sur cette techniques, et beaucoup de scripts plus o? moins bien fait ? ce sujet. M馭iez vous donc de ce que vous trouverez. Le mieux est sans aucun doute de tester votre configuration par 騁ape, et de regarder syst駑atiquement les statistiques d'iptables afin de voir par o? passent vos paquets. D'une mani鑽e g駭駻ale, si les paquets utilisent les cibles par d馭aut de PREROUTING ou de POSTROUTING, c'est qu'il y a probablement une mauvaise configuration de votre script. Enfin, comme indiqu? dans les 2 scripts "iptables-portforwarding-*.sh" que vous pouvez t駘馗harger, vous avez la possibilit? d'utiliser la cible LOG afin d'analyser quelles sont les paquets qui utilisent ces cibles par d馭aut.