
                             Linux IPCHAINS-HOWTO

Paul Russell, ipchains@rustcorp.com
Version franaise par Arnaud Launay, asl@launay.org

   v1.0.7, 12 mars 1999
     _________________________________________________________________

   _Ce document dcrit l'obtention, l'installation et la configuration du
   logiciel amlior de chanes pare-feu IP pour Linux, et donne quelques
   ides sur l'utilisation que vous pouvez en faire._
     _________________________________________________________________

1. Introduction

   Ceci est le Linux IPCHAINS-HOWTO ; voyez la section O ? pour le site
   principal, qui dtient la dernire version. Vous devriez galement
   lire le Linux NET-3-HOWTO. Les howtos IP-Masquerading, PPP-HOWTO,
   l'Ethernet-HOWTO et le Firewall HOWTO peuvent aussi tre intressants
    lire (une fois de plus, la FAQ de alt.fan.bigfoot peut l'tre
   aussi).

   Si le filtrage des paquets vous semble dpass, lisez la section
   Pourquoi ?, la section Comment ?, et lisez les titres de la section
   Chanes de protection IP.

   Si vous vous adaptez en partant d'ipfwadm, lisez la section
   Introduction, la section Comment ?, et les annexes des sections
   Diffrences entre ipchains et ipfwadm et Utiliser le script
   `ipfwadm-wrapper'.

1.1 Qu'est ce que c'est ?

   Le Linux ipchains est une rcriture du code de firewalling de l'IPv4
   de Linux (qui avait t principalement emprunt  BSD) et une
   rcriture d'ipfwadm, lui mme rcriture d'ipfw de BSD, je crois. Il
   est ncessaire pour administrer le filtrage des paquets IP dans les
   noyaux Linux  partir de la version 2.1.102.

1.2 Pourquoi ?

   L'ancien code de firewalling de Linux ne pouvait grer les fragments,
   utilisait des compteurs 32 bits (au moins sur Intel), ne permettait
   pas la spcification de protocoles autres que TCP, UDP ou ICMP, ne
   pouvait faire de grands changements atomiquement, ne permettait pas la
   spcification de rgles inverses, avait quelques bizarreries, et
   pouvait tre une catastrophe  grer (le rendant propice aux erreurs
   des utilisateurs).

1.3 Comment ?

   Actuellement le code se trouve dans le noyau principal  partir du
   2.1.102. Pour la srie des noyaux 2.0, vous devrez rcuprer une
   correction pour le noyau sur une page web. Si votre noyau 2.0 est plus
   rcent que la correction rcupre, la correction ancienne devrait
   fonctionner ; cette partie des noyaux 2.0 est relativement stable (la
   correction pour le noyau 2.0.34 fonctionne bien sur le noyau 2.0.35).
   Cependant, le correctif 2.0 est incompatible avec les correctifs pour
   l'ipportfw et l'ipautofw, je recommande donc de ne pas l'appliquer, 
   moins que vous n'ayez rellement besoin de l'une des fonctionnalits
   offertes par ipchains.

1.4 O ?

   La page officielle est la Page des chanes de filtrage IP de Linux.

   Il y a une liste de diffusion pour les rapports d'erreurs, les
   discussions, le dveloppement et l'utilisation. Vous pouvez rejoindre
   la liste de diffusion en envoyant un message contenant le mot
   ``subscribe''  ipchains-request de rustcorp.com. Pour crire  la
   liste utilisez `ipchains'  la place de `ipchains-request'.

2. Bases du filtrage de paquets

2.1 Qu'est ce que c'est ?

   Tout le trafic circulant dans un rseau est envoy sous la forme de
   _paquets_. Par exemple, pour charger ce paquetage (disons qu'il fait
   50k) vous avez d recevoir plus ou moins 36 paquets de 1460 octets
   chacun (pour prendre des valeurs au hasard).

   Le dbut de chaque paquet prcise o celui-ci va, d'o il vient, le
   type du paquet, et divers autres dtails administratifs. Le dbut de
   chaque paquet est appel l'_entte_. Le reste du paquet, contenant les
   donnes  transmettre, est couramment appel le _corps_.

   Quelques protocoles, comme le _TCP_, qui est utilis pour le trafic
   web, mail et les connexions  distance, utilisent le concept de
   `connexion' -- avant que le moindre paquet de donnes ne soit envoy,
   divers paquets de configuration (avec des enttes spciales) sont
   changs en disant `je veux me connecter', `OK' et `Merci'. Ensuite
   les paquets normaux sont changs.

   Un filtre de paquet est un logiciel qui regarde l'_entte_ des paquets
   lorsque ceux-ci passent, et dcide du destin du paquet entier. Il peut
   dcider de le _refuser_ (le supprimer comme s'il n'avait jamais t
   reu), de l'_accepter_ (le laisser circuler) ou de le _rejeter_ (effet
   identique au refus, mais il est prcis  la source que le paquet n'a
   pas t accept).

   Sous Linux, le filtrage des paquets est inclus dans le noyau, et il y
   a diverses choses que nous pouvons faire avec les paquets, mais le
   principe gnral (regarder les enttes et dcider du destin du paquet)
   est toujours prsent.

2.2 Pourquoi ?

   Contrle. Scurit. Vigilance.

   _Contrle :_
          Lorsque vous utilisez un ordinateur sous Linux pour connecter
          votre rseau interne  un autre rseau (disons, l'Internet)
          vous aurez l'opportunit de permettre certains types de
          trafics, et d'interdire les autres. Par exemple, l'entte d'un
          paquet contient l'adresse de destination du paquet, et vous
          pouvez ainsi viter que des paquets aillent vers un certain
          endroit du rseau extrieur. Comme autre exemple, j'utilise
          Netscape pour accder aux archives de Dilbert. Il y a des
          publicits provenant de doubleclick.net sur la page, et
          Netscape perd du temps en les chargeant gentiment. Dire au
          filtre des paquets de ne pas autoriser la circulation de
          paquets provenant ou allant vers doubleclick.net rsoud le
          problme (il y a cependant de meilleurs moyens pour y
          parvenir).

   _Scurit :_
          Lorsque votre machine Linux est le seul rempart entre le chaos
          de l'Internet et votre rseau propre et bien ordonn, il est
          utile de savoir que vous pouvez restreindre ce qui vient sonner
           votre porte. Par exemple, vous pouvez autoriser tout ce qui
          sort de votre rseau, mais vous pouvez vous inquiter du fort
          connu 'Ping of Death' pouvant provenir d'intrus extrieurs.
          Comme autre exemple, vous pouvez interdire aux personnes
          extrieures de se connecter en telnet sur votre machine Linux,
          mme si tous vos comptes ont des mots de passe ; peut-tre
          dsirerez-vous (comme la plupart des gens) tre un simple
          observateur sur l'Internet, et non un serveur (de bonne volont
          ou non) -- simplement en ne laissant personne se connecter, le
          filtrage de paquets rejetant tous les paquets entrants utiliss
          pour crer des connexions.

   _Vigilance :_
          Parfois, une machine mal configure du rseau local dcidera
          d'envoyer des paquets au monde extrieur. Il est sympathique de
          pouvoir spcifier au filtre de paquets de vous informer si
          quelque chose d'anormal se produit ; vous pourrez
          ventuellement y faire quelque chose, ou bien laisser libre
          cours  la simple curiosit.

2.3 Comment ?

  Un noyau avec le filtrage de paquets

   Vous aurez besoin d'un noyau disposant du nouveau code de chanes de
   protection IP. Vous pouvez savoir si le noyau que vous utilisez
   actuellement en dispose en cherchant le fichier
   `/proc/net/ip_fwchains'. Si ce fichier existe, alors c'est tout bon.

   Sinon, vous devez crer un noyau contenant le code de chanes de
   protection IP. Tout d'abord, rcuprez les sources du noyau que vous
   dsirez. Si vous avez un noyau dont le numro est suprieur ou gal 
   2.1.102, vous n'aurez pas besoin de le corriger (il se trouve dj
   inclus dans le noyau). Autrement, appliquez le correctif que vous
   trouverez sur la page web liste plus haut, et utilisez la
   configuration dtaille ci-dessous. Si vous ne savez pas comment le
   faire, ne paniquez pas -- lisez le Kernel-HOWTO.

   Les options de configuration que vous devez utiliser pour les _noyaux
   de srie 2.0_ sont :
     _________________________________________________________________

        CONFIG_EXPERIMENTAL=y
        CONFIG_FIREWALL=y
        CONFIG_IP_FIREWALL=y
        CONFIG_IP_FIREWALL_CHAINS=y
     _________________________________________________________________

   Pour les sries de _noyaux 2.1_ ou _2.2_ :
     _________________________________________________________________

        CONFIG_FIREWALL=y
        CONFIG_IP_FIREWALL=y
     _________________________________________________________________

   L'outil ipchains parle au noyau et lui dit quels paquets filtrer. 
   moins que vous ne soyez un programmeur, ou un curieux invtr, c'est
   ainsi que vous contrlerez le filtrage des paquets.

  ipchains

   L'outil ipchains insre et efface des rgles dans la section de
   filtrage de paquets du noyau. Ce qui signifie que quoi que vous
   configuriez, tout sera perdu lors d'un redmarrage ; voyez la section
   Rendre les rgles permanentes pour savoir comment s'assurer que les
   rgles seront restaures au prochain lancement de Linux.

   ipchains remplace ipfwadm, qui tait utilis par l'ancien code
   pare-feu. Il y a un ensemble de scripts utiles disponibles sur le site
   ftp d'ipchains :

   ftp://ftp.rustcorp.com/ipchains/ipchains-scripts-1.1.2.tar.gz

   Cette archive contient un script shell appell ipfwadm-wrapper qui
   vous autorisera  utiliser le filtrage de paquets comme avant. Vous ne
   devriez probablement pas utiliser ce script  moins que vous ne
   souhaitiez un moyen rapide de mettre  jour un systme utilisant
   ipfwadm (ce script est plus lent, ne vrifie pas les arguments, etc.).
   Dans ce cas, vous n'avez pas non plus besoin de ce howto.

   Voyez l'annexe Diffrences entre ipchains et ipfwadm et l'annexe
   Utiliser le script `ipfwadm-wrapper' pour des dtails supplmentaires
   concernant ipfwadm.

  Rendre les rgles permanentes

   Votre configuration actuelle de pare-feu est sauve dans le noyau, et
   sera ainsi perdue lors d'un redmarrage. Je vous recommande d'utiliser
   les scripts `ipchains-save' et `ipchains-restore' pour rendre vos
   rgles permanentes. Pour ce faire, configurez vos rgles, puis
   utilisez (en tant que super-utilisateur) :

# ipchains-save > /etc/ipchains.rules
#

   Crez un script comme le suivant :

#! /bin/sh
# Script to control packet filtering.

# If no rules, do nothing.
[ -f /etc/ipchains.rules ] || exit 0

case "$1" in
    start)
        echo -n "Turning on packet filtering:"
        /sbin/ipchains-restore < /etc/ipchains.rules || exit 1
        echo 1 > /proc/sys/net/ipv4/ip_forward
        echo "."
        ;;
    stop)
        echo -n "Turning off packet filtering:"
        echo 0 > /proc/sys/net/ipv4/ip_forward
        /sbin/ipchains -X
        /sbin/ipchains -F
        /sbin/ipchains -P input ACCEPT
        /sbin/ipchains -P output ACCEPT
        /sbin/ipchains -P forward ACCEPT
        echo "."
        ;;
    *)
        echo "Usage: /etc/init.d/packetfilter {start|stop}"
        exit 1
        ;;
esac

exit 0

   Assurez vous que ceci est lanc suffisamment tt dans la procdure de
   lancement. Dans mon cas (Debian 2.1), j'ai cr un lien symbolique
   appell `S39packetfilter' dans le rpertoire `/etc/rcS.d' (il sera
   ainsi lanc avant S40network).

3. Je suis troubl ! Routage, camouflage, redirection de ports, ipautofw...

   Ce HOWTO a pour sujet le filtrage de paquets. Ce filtrage permet la
   prise de dcision concernant le destin d'un paquet : s'il est autoris
    passer ou non. Cependant, Linux tant le joujou pour bidouilleurs
   qu'il est, vous voudriez probablement en savoir un peu plus.

   Un des problmes est que le mme outil ("ipchains") est utilis pour
   contrler  la fois le camouflage et le cache transparent, alors que
   ce sont des notions spares du filtrage de paquets (l'implmentation
   actuelle de Linux les brouille tous les trois de faon inhabituelle,
   laissant l'impression qu'ils sont trs proches).

   Le camouflage et le cachage sont recouverts par des HOWTOs spars, et
   les possibilits de redirection automatique et de redirection de ports
   sont contrles par des outils spars, mais puisque de nombreuses
   personnes continuent  me harceler  leur propos, je vais ajouter un
   ensemble de scnarios classiques en indiquant les moments o chacun
   doit tre utilis. Les mrites de la scurit de chacun de ces
   scnarios ne seront nanmoins pas discuts ici.

3.1 Le guide du camouflage en 3 lignes par Rusty

   Ces lignes prsument que votre interface _externe_ est appelle
   "ppp0". Utilisez ifconfig pour le vrifier, et ajustez selon votre
   got.

# ipchains -P forward DENY
# ipchains -A forward -i ppp0 -j MASQ
# echo 1 > /proc/sys/net/ipv4/ip_forward

3.2 Publicit gratuite : le zle de WatchGuard

   Vous pouvez acheter des pare-feu tout faits. Un excellent est le
   FireBox de WatchGuard. C'est excellent parce que je l'apprcie, parce
   qu'il est scuris, bas sur Linux, et parce qu'ils financent la
   maintenance d'ipchains ainsi que du nouveau code pare-feu (prvu pour
   le 2.3). En bref, WatchGuard me paye  manger lorsque je travaille
   pour vous. Donc, je vous prierai de prendre leur travail en compte.

   http://www.watchguard.com

3.3 Configurations classiques de type pare-feu

   Vous tes petiteboite.com. Vous avez un rseau interne, et une
   connexion intermittente (PPP) simple  l'Internet
   (firewall.petiteboite.com a pour IP 1.2.3.4). Vous tes en Ethernet
   sur votre rseau local, et votre machine personnelle s'appelle
   "mamachine".

   Cette section illustrera les diffrents arrangements classiques. Lisez
   attentivement, car ils sont tous subtilement diffrents.

  Rseaux privs : caches traditionnels

   Dans ce scnario, les paquets venant d'un rseau priv ne traversent
   jamais l'Internet, et vice versa. Les adresses IP du rseau priv
   doivent tre assignes en utilisant les adresses prives rserves par
   la RFC 1597 (cd 10.*.*.*, 172.16.*.* ou 192.168.*.*).

   La seule mthode pour que les choses soient connects  l'Internet est
   en se connectant au pare-feu, qui est la seule machine sur les deux
   rseaux qui sont connects plus loin. Vous lancez un programme (sur le
   pare-feu) appell un proxy pour ce faire (il y a des proxy (caches)
   pour le FTP, l'accs web, telnet, RealAudio, les News Usenet et autres
   services). Voyez le Firewall HOWTO.

   Tous les services auxquels vous voulez que l'Internet puisse avoir
   accs doivent tre sur le pare-feu (mais voyez Services internes
   limits plus bas).

   Exemple : autoriser l'accs web d'un rseau priv vers l'Internet.
    1. On a assign les adresses 192.168.1.* au rseau priv, avec
       mamachine tant 192.168.1.100, et l'interface Ethernet du pare-feu
       tant assigne  192.168.1.1.
    2. Un cache web (comme "squid") est install et configur sur le
       pare-feu, disons tournant sur le port 8080.
    3. Netscape sur le rseau priv est configur pour utiliser le
       pare-feu port 8080 comme cache.
    4. Le DNS n'a pas besoin d'tre configur sur le rseau priv.
    5. Le DNS doit tre configur sur le pare-feu.
    6. Le rseau priv n'a pas besoin de disposer de route par dfaut
       (passerelle).

   Netscape sur mamachine lit http://slashdot.org.
    1. Netscape se connecte sur le port 8080 du pare-feu, en utilisant le
       port 1050 de mamachine. Il demande la page web de
       "http://slashdot.org".
    2. Le cache recherche le nom "slashdot.org", et obtient
       207.218.152.131. Il ouvre alors une connexion sur cette adresse IP
       (en utilisant le port 1025 de l'interface externe du pare-feu), et
       demande la page au serveur web (port 80).
    3. En recevant la page web par sa connexion au serveur web, le
       pare-feu copie les donnes vers la connexion de Netscape.
    4. Netscape affiche la page.

   C'est--dire que du point de vue de slashdot.org, la connexion est
   ralise par 1.2.3.4 (interface PPP du pare-feu), port 1025, vers
   207.218.152.131 (slashdot.org) port 80. Du point de vue de mamachine,
   la connexion est faite de 192.168.1.100 (mamachine) port 1050, vers
   192.168.1.1 (interface Ethernet du pare-feu), port 8080.

  Rseaux privs : caches transparents

   Dans ce scnario, les paquets venant du rseau priv ne traversent
   jamais l'Internet, et vice versa. Les adresses IP du rseau priv
   doivent tre assignes en utilisant les adresses prives rserves par
   la RFC 1597 (cd 10.*.*.*, 172.16.*.* ou 192.168.*.*).

   La seule mthode pour que les choses soient connectes  l'Internet
   est en se connectant au pare-feu, qui est la seule machine sur les
   deux rseaux, qui sont connects plus loin. Vous lancez un programme
   (sur le pare-feu) appell un cache transparent pour ce faire ; le
   noyau envoie les paquets sortants au cache transparent au lieu de les
   envoyer plus loin (cd qu'il rend btard le routage).

   Le cachage transparent signifie que les clients n'ont pas besoin de
   savoir qu'il y a un proxy dans l'histoire.

   Tous les services que l'Internet peut utiliser doivent tre sur le
   pare-feu (mais voyez Services internes limits plus bas).

   Exemple : autoriser l'accs web du rseau priv vers l'Internet.
    1. On a assign les adresses 192.168.1.* au rseau priv, avec
       mamachine tant 192.168.1.100, et l'interface Ethernet du pare-feu
       tant assigne  192.168.1.1.
    2. Un proxy web transparent (je prsume qu'il existe des correctifs
       pour squid lui permettant d'oprer de cette faon, sinon, essayez
       "transproxy") est install et configur sur le pare-feu, disons
       tournant sur le port 8080.
    3. On dit au noyau de rediriger les connexions sur le port 80 du
       proxy, en utilisant ipchains.
    4. Netscape, sur le rseau priv, est configur pour se connecter
       directement.
    5. Le DNS doit tre configur sur le rseau priv (cd que vous devez
       faire tourner un serveur DNS de la mme manire que le proxy sur
       le pare-feu).
    6. La route par dfaut (passerelle) doit tre configur sur le rseau
       priv, pour envoyer les paquets au pare-feu.

   Netscape sur mamachine lit http://slashdot.org.
    1. Netscape recherche le nom "slashdot.org", et obtient
       207.218.152.131. Il ouvre alors une connexion vers cette adresse
       IP, en utilisant le port local 1050, et demande la page au serveur
       web (port 80).
    2. Comme les paquets venant de mamachine (port 1050) et allant sur
       slashdot.org (port 80) passent par le pare-feu, ils sont redirigs
       sur le proxy transparent en attente sur le port 8080. Le cache
       transparent ouvre alors une connexion (en utilisant le port local
       1025) vers 207.218.152.131 port 80 (vers lequel les paquets de
       dpart allaient).
    3. Alors que le cache reoit la page web par sa connexion avec le
       serveur web, il copie les donnes vers la connexion avec Netscape.
    4. Netscape affiche la page.

   C'est  dire que du point de vue de slashdot.org, la connexion est
   ralise par 1.2.3.4 (interface PPP du pare-feu) port 1025 vers
   207.218.152.131 (slashdot.org) port 80. Du point de vue de mamachine,
   la connexion est faite  partir de 192.168.1.100 (mamachine) port
   1050, vers 207.218.152.131(slashdot.org) port 80, mais il parle en
   fait au proxy transparent.

  Rseaux privs : camouflage

   Dans ce scnario, les paquets venant du rseau priv ne traversent
   jamais l'Internet sans traitement spcial, et vice versa. Les adresses
   IP du rseau priv doivent tre assignes en utilisant les adresses
   prives rserves par la RFC 1597 (cd 10.*.*.*, 172.16.*.* ou
   192.168.*.*).

   Au lieu d'utiliser un cache, nous utilisons une spcificit spciale
   du noyau nomme "camouflage" (masquerading). Le camouflage rcrit les
   paquets lorsqu'ils passent par le pare-feu, ce qui fait qu'ils
   semblent toujours venir du pare-feu lui-mme. Il rcrit ensuite les
   rponses afin qu'elles semblent venir du destinataire originel.

   Le camouflage dispose de modules spars afin de grer les protocoles
   "tranges", comme FTP, RealAudio, Quake, etc. Pour les protocoles
   vraiment difficiles  grer, la spcificit de "redirection
   automatique" (auto forwarding) peut en grer quelques-uns en
   configurant automatiquement la redirection de ports pour un ensemble
   donn de ports : voyez "ipportfw" (noyaux 2.0) ou "ipmasqadm" (noyaux
   2.1 et suprieurs).

   Tous les services auxquels vous voulez que l'Internet puisse avoir
   accs doivent tre sur le pare-feu (mais voyez Services internes
   limits plus bas).

   Exemple : autoriser l'accs web du rseau priv sur l'Internet.
    1. On a assign les adresses 192.168.1.* au rseau priv, avec
       mamachine tant 192.168.1.100, et l'interface Ethernet du pare-feu
       tant assigne  192.168.1.1.
    2. Le pare-feu est configur pour camoufler tous les paquets venant
       du rseau priv et allant sur le port 80 d'un hte sur Internet.
    3. Netscape est configur pour se connecter directement.
    4. Le DNS doit tre configur correctement sur le rseau priv.
    5. Le pare-feu doit tre la route par dfaut (passerelle) du rseau
       priv.

   Netscape sur mamachine lit http://slashdot.org.
    1. Netscape recherche le nom "slashdot.org", et obtient
       207.218.152.131. Il ouvre alors une connexion vers cette adresse
       IP, en utilisant le port local 1050, et demande la page au serveur
       web (port 80).
    2. Comme les paquets venant de mamachine (port 1050) et allant sur
       slashdot.org (port 80) passent par le pare-feu, ils sont rcrits
       pour venir de l'interface PPP du pare-feu, port 65000. Le pare-feu
       a une adresse Internet valide (1.2.3.4), donc les paquets venant
       de slashdot.org sont routs correctement.
    3. Lorsque les paquets venant de slashdot.org (port 80) sur
       firewall.petiteboite.com (port 65000) arrivent, ils sont rcrits
       pour aller sur mamachine, port 1050. La vritable magie du
       camouflage se trouve ici : il se souvient des paquets sortants
       rcrits afin de pouvoir rcrire les paquets entrants qui en sont
       la rponse.
    4. Netscape affiche la page.

   C'est  dire que du point de vue de slashdot.org, la connexion est
   ralise de 1.2.3.4 (interface PPP du pare-feu), port 65000 vers
   207.218.152.131 (slashdot.org) port 80. Du point de vue de mamachine,
   la connexion est faite entre 192.168.1.100 (mamachine) port 1050, et
   207.218.152.131 (slashdot.org) port 80.

  Rseaux publics

   Dans ce scnario, votre rseau personnel fait partie de l'Internet :
   les paquets peuvent passer sans avoir  changer de rseau. Les
   adresses IP du rseau interne doivent tre assignes en utilisant un
   bloc d'adresses IP, de manire  ce que le reste du rseau sache
   comment vous envoyer des paquets. Ceci implique une connexion
   permanente.

   Dans ce rle, le filtrage de paquets est utilis pour restreindre les
   paquets qui peuvent tre redirigs entre votre rseau et le reste de
   l'Internet, cd pour restreindre le reste de l'Internet  accder
   uniquement au serveur web qui se trouve en interne.

   Exemple : autoriser l'accs web du rseau priv vers l'Internet.
    1. Votre rseau interne dispose du bloc d'adresses IP que vous avez
       enregistr, disons 1.2.3.*.
    2. Le pare-feu est configur pour autoriser tout le trafic.
    3. Netscape est configur pour se connecter directement.
    4. Le DNS doit tre configur correctement sur votre rseau.
    5. Le pare-feu doit tre la route par dfaut (passerelle) pour le
       rseau priv.

   Netscape sur mamachine lit http://slashdot.org.
    1. Netscape recherche le nom "slashdot.org", et obtient
       207.218.152.131. Il ouvre alors une connexion vers cette adresse
       IP, en utilisant le port local 1050, et demande la page au serveur
       web, port 80.
    2. Les paquets passent par votre pare-feu, comme ils passent par
       d'autres routeurs entre vous et slashdot.org.
    3. Netscape affiche la page.

   C'est  dire qu'il n'y a qu'une seule connexion :  partir de
   1.2.3.100 (mamachine) port 1050, vers 207.218.152.131 (slashdot.org)
   port 80.

  Services internes limits

   Il y a quelques trucs que vous pouvez utiliser pour autoriser
   l'Internet  accder  vos services internes, plutt que de faire
   tourner vos services internes sur le pare-feu. Ils fonctionneront soit
   avec un proxy, soit avec une approche type camouflage pour les
   connexions externes.

   L'approche la plus simple est de faire tourner un "redirecteur", qui
   est un cache de pauvre, attendant une connexion sur un port donn, et
   ouvrant une connexion sur un hte et un port interne fix, et copiant
   les donnes entre les deux connexions. Un exemple de ceci est le
   programme "redir". Du point de vue de l'Internet, la connexion est
   faite sur votre pare-feu. Du point de vue de votre serveur interne, la
   connexion est faite par l'interface interne du pare-feu sur le
   serveur.

   Une autre approche (qui ncessite un noyau 2.0 corrig pour ipportfw,
   ou un noyau 2.1 ou suprieur) est d'utiliser la redirection des ports
   du noyau. Il effectue le mme travail que "redir" d'une manire
   diffrente : le noyau rcrit les paquets lorsqu'ils passent, en
   changeant leur adresse de destination et le port pour les faire
   pointer sur un port et un hte interne. Du point de vue de l'Internet,
   la connexion est faite sur votre pare-feu. Du point de vue de votre
   serveur interne, une connexion directe est ralise entre l'hte
   Internet et votre serveur.

3.4 Pour plus d'informations sur le camouflage

   David Ranch a crit un excellent howto tout neuf sur le camouflage,
   qui en grande partie recouvre ce howto. Vous pouvez le trouver sur
   http://www.ecst.csuchico.edu/~dranch/LINUX/index-LINUX.html

   J'espre pouvoir bientt le trouver hberg sous les auspices du LDP
   (Linux Documentation Project), sur http://www.metalab.unc.edu/LDP.

   La page officielle du camouflage se trouve sur http://ipmasq.cjb.net.

4. Chanes de protection IP

   Cette section dcrit tout ce que vous avez rellement besoin de savoir
   pour construire un filtre de paquets adapt  vos besoins.

4.1 Comment les paquets traversent les filtres

   Le noyau commence avec trois listes de rgles : ces listes sont
   appelles _chanes de protection_ ou juste _chanes_. Ces trois
   chanes sont appelles _input_ (entre), _output_ (sortie) et _forward_
   (transmission). Lorsqu'un paquet arrive (disons, par une carte
   Ethernet), le noyau utilise la chane input pour dcider de son
   destin. S'il survit  ce passage, alors le noyau dcide o envoyer le
   paquet par la suite (ceci est appel _routage_). S'il est destin 
   une autre machine, il consulte alors la chane de transmission. Enfin,
   juste avant que le paquet ne ressorte, le noyau consulte la chane de
   sortie.

   Une chane est une vrification de _rgles_. Chaque rgle dit `si
   l'entte de ce paquet ressemble  ceci, alors voil quoi faire de ce
   paquet'. Si la rgle ne vrifie pas le paquet, alors la rgle suivante
   dans la chane est consulte. Enfin, s'il n'y a plus de rgles 
   consulter, alors le noyau regarde la chane _police_ pour dcider ce
   qu'il doit faire. Dans un systme orient scurit, cette police dit
   gnralement au noyau de rejeter ou de refuser le paquet.

   Pour les fans de l'art ASCII, ceci montre le chemin complet d'un
   paquet arrivant  une machine.

        -----------------------------------------------------------------------
------
        |           ACCEPTER/                               interface lo |
        v           REDIRIGER                 _________                  |
--> S --> V --> ______ --> D --> ~~~~~~~~ -->| Chane  |----> _______ -->
    o     a    |chane|    e    {Dcision}   |transfert|     |Chane |ACCEPTER
    m     l    |entre|    m    {Routage }   |_________| --->|sortie |
    m     i    |______|    a     ~~~~~~~~         |      | ->|_______|
    e     d       |        s        |             |      | |     |
    |     i       |        q        |            NON/    | |     |
    |     t       v        u        v           REJET    | |     v
    |           NON/      e    Processus                | |    NON/
    |     |     REJET      r      Local                  | |   REJET
    |     v                |        ---------------------- |
    v    NON               \ ------------------------------/
   NON

   Voici une description point par point de chaque partie :

   _Somme (checksum) :_
          C'est un test vrifiant si le paquet n'a pas t corrompu d'une
          manire ou d'une autre. S'il l'a t, il est refus.

   _Validit (sanity) :_
          Il y a en fait un de ces tests sanitaires avant chaque chane
          de protection, mais les chanes d'entre sont les plus
          importantes. Quelques paquets malforms peuvent rendre confus
          le code de vrification des rgles, et ceux-ci sont refuss ici
          (un message est envoy au syslog si ceci arrive).

   _Chane d'entre (input chain) :_
          C'est la premire chane de protection qui teste le paquet. Si
          le verdict de la chane n'est ni DENY ni REJECT, le paquet
          continue son chemin.

   _Demasquerade :_
          Si le paquet est une rponse  un paquet prcdemment masqu,
          il est dmasqu, et envoy directement  la chane de sortie.
          Si vous n'utilisez pas le masquage IP, vous pouvez mentalement
          supprimer ceci du diagramme.

   _Dcision routage (Routing decision) :_
          Le champ de destination est examin par le code de routage,
          pour dcider si le paquet doit aller vers un processus local
          (voir processus local plus bas) ou transmis  une machine
          distante (voyez les chanes de renvoi plus bas).

   _Processus local (Local process) :_
          Un processus tournant sur la machine peut recevoir des paquets
          aprs l'tape de dcision de routage, et peut envoyer des
          paquets (qui passent par l'tape de dcision de routage, puis
          traversent la chane de sortie).

   _Interface lo :_
          Si les paquets venant d'un processus local sont destins  un
          autre processus local, alors ils passeront par la chane de
          sortie en utilisant l'interface lo, puis reviendront par la
          chane d'entre en utilisant la mme interface. L'interface lo
          est gnralement nomme interface loopback.

   _local :_
          Si le paquet n'a pas t cr par un processus local, alors la
          chane de transmission est vrifie, sinon le paquet se dirige
          vers la chane de sortie.

   _forward chain :_
          Cette chane est traverse par tout paquet qui tente de passer
          par cette machine vers une autre.

   _output chain :_
          Cette chane est traverse par tous les paquets juste avant
          qu'ils ne soient envoys  l'extrieur.

  Utiliser ipchains

   Tout d'abord, vrifiez que vous avez la version d'ipchains  laquelle
   se rfre ce document :

$ ipchains --version
ipchains 1.3.9, 17-Mar-1999

   Notez que je recommande l'utilisation du 1.3.4 (qui ne dispose pas des
   options longues comme `--sport'), ou du 1.3.8 et suivants ; ils sont
   en effet trs stables.

   ipchains dispose d'une page de manuel plutt bien dtaille (man
   ipchains), et si vous avez besoin de plus de dtails en particulier,
   vous pouvez consulter l'interface de programmation (man 4 ipfw), ou le
   fichier net/ipv4/ip_fw.c dans les sources des noyaux 2.1.x, qui est
   (bien videmment) la rfrence.

   Il y a galement une carte de rfrence rapide par Scott Bronson dans
   le paquetage source, aux formats PostScript (TM) a4 et US letter.

   Il y a plusieurs choses diffrentes que vous pouvez faire avec
   ipchains. Tout d'abord les oprations servant  grer les chanes
   entires. Vous commencez avec trois chanes intgres input, output et
   forward que vous ne pouvez effacer.

    1. Crer une nouvelle chane (-N) ;
    2. Supprimer une chane vide (-X) ;
    3. Changer la police d'une chane intgre (-P) ;
    4. Lister les rgles d'une chane (-L) ;
    5. Supprimer les rgles d'une chane (-F) ;
    6. Mettre  zro les compteurs de paquets et d'octets sur toutes les
       rgles d'une chane (-Z).

   Il y a plusieurs moyens pour manipuler les rgles  l'intrieur d'une
   chane :

    1. Ajouter une nouvelle rgle  une chane (-A) ;
    2. Insrer une nouvelle rgle  une position quelconque de la chane
       (-I) ;
    3. Remplacer une rgle  une position quelconque de la chane (-R) ;
    4. Supprimer une rgle  une position quelconque de la chane (-D) ;
    5. Supprimer la premire rgle vrifie dans la chane (-D).

   Il y a quelques oprations pour le masquage, qui se trouvent dans
   ipchains dans l'attente d'un bon endroit pour les mettre :

    1. Lister les connexions masques actuelles (-M -L) ;
    2. Configurer les valeurs de timeout (-M -S) (mais voyez
       id="no-timeout" name="Je ne peux pas modifier les temps d'attente
       du camouflage !">).

   La fonction finale (et peut-tre la plus utile) vous permet de
   vrifier ce qui arriverait  un paquet donn s'il avait  traverser
   une chane donne.

  Oprations sur une rgle simple

   Ceci est le B.A.-Ba d'ipchains ; manipuler des rgles. Plus
   gnralement, vous utiliserez probablement les commandes d'ajout (-A)
   et de suppression (-D). Les autres (-I pour l'insertion et -R pour le
   remplacement) sont des simples extensions de ces concepts.

   Chaque rgle spficie un ensemble de conditions que le paquet doit
   suivre, et ce qu'il faut faire s'il les suit (une "destination"). Par
   exemple, vous pouvez vouloir refuser tous les paquets ICMP venant de
   l'adresse IP 127.0.0.1. Donc, dans ce cas nos conditions sont que le
   protocole doit tre ICMP et que l'adresse source doit tre 127.0.0.1.
   Notre destination est "DENY" (rejet).

   127.0.0.1 est l'interface "loopback", que vous avez mme si vous
   n'avez de connexion rseau relle. Vous pouvez utiliser le programme
   "ping" pour gnrer de tels paquets (il envoie simplement un paquet
   ICMP de type 8 (requte d'cho)  qui tous les htes coopratifs
   doivent obligeamment rpondre avec un paquet ICMP de type 0 (rponse 
   un cho)). Ceci le rend utile pour les tests.

# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
# ipchains -A input -s 127.0.0.1 -p icmp -j DENY
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
#

   Vous pouvez voir ici que le premier ping russit (le "-c 1" dit  ping
   de n'envoyer qu'un seul paquet).

   Puis nous ajoutons (-A)  la chane d'entre ("input"), une rgle
   spcifiant que tous les paquets provenant de 127.0.0.1 ("-s
   127.0.0.1") avec le protocole ICMP ("-p ICMP") doivent tre refuss
   ("-j DENY").

   Ensuite nous testons notre rgle, en utilisant le second ping. Il y
   aura une pause avant que le programme ne se termine, attendant une
   rponse qui ne viendra jamais.

   Nous pouvons supprimer la rgle avec l'un des deux moyens. Tout
   d'abord, puisque nous savons que c'est la seule rgle de la chane
   d'entre, nous pouvons utiliser une suppression numrote, comme
   dans :

        # ipchains -D input 1
        #

   Pour supprimer la rgle numro 1 de la chane d'entre.

   La deuxime possibilit est de copier la commande -A, mais en
   remplaant le -A par -D. C'est utile lorsque vous avez une chane
   complexe de rgles et que vous ne voulez pas avoir  les compter afin
   de savoir que c'est la rgle 37 que vous voulez supprimer. Dans ce
   cas, nous pouvons utiliser :

        # ipchains -D input -s 127.0.0.1 -p icmp -j DENY
        #

   La syntaxe de -D doit avoir exactement les mmes options que la
   commande -A (ou -I ou -R). S'il y a des rgles multiples identiques
   dans la mme chane, seule la premire sera supprime.

  Spcifications du filtrage

   Nous avons vu l'utilisation de "-p" pour spcifier le protocole, et de
   "-s" pour spcifier l'adresse souce, mais il y a d'autres options que
   nous pouvons utiliser pour spcifier les caractristiques des paquets.
   Ce qui suit en est une description exhaustive.

  Spcifier les adresses IP source et destination

   Les adresses IP source (-s) et destination (-d) peuvent tre
   spcifies de quatre faons diffrentes. La faon la plus classique
   est d'utiliser le nom complet, comme "localhost" ou "www.linuxhq.com".
   La deuxime mthode est de spcifier l'adresse IP, comme "127.0.0.1".

   Les deux autres mthodes permettent la spcification d'un groupe
   d'adresses IP, comme "199.95.207.0/24" ou
   "199.95.207.0/255.255.255.0". Toutes deux spcifient toutes les
   adresses IP de 192.95.207.0  192.95.207.255, incluse ; les chiffres
   suivant le "/" indiquent quelles parties de l'adresse IP sont
   significatives. "/32" ou "/255.255.255.255" sont les dfauts
   (vrifient toutes les adresses IP). Pour ne spcifier aucune adresse
   IP, "/0" peut tre utilis, par exemple :

        # ipchains -A input -s 0/0 -j DENY
        #

   Ceci est rarement utilis, car l'effet produit par cette ligne de
   commande est le mme que celui obtenu en ne spcifiant pas l'option
   "-s".

  Spcifier l'inversion

   De nombreuses options, incluant les options "-s" et "-d" peuvent avoir
   leurs propres arguments prcds par "!" (prononc "non") pour ne
   vrifier que les adresses n'tant PAS quivalentes  celles donnes.
   Par exemple, "-s ! localhost" vrifiera tout paquet ne provenant PAS
   de localhost.

  Spcifier le protocole

   Le protocole peut tre spcifi en utilisant l'option "-p". Le
   protocole peut tre soit un nombre (si vous connaissez les valeurs
   numriques des protocoles pour IP), soit le nom des cas spciaux
   parmis "TCP", "UDP" ou "ICMP". La casse n'est pas prise en compte,
   donc "tcp" fonctionne aussi bien que "TCP".

   Le nom du protocole peut tre prfix par un "!", pour l'inverser,
   comme dans "-p ! TCP".

  Spcifier les ports UDP et TCP

   Pour les cas spciaux o un protocole TCP ou UDP est spcifi, il peut
   y avoir un argument supplmentaire indiquant le port TCP ou UDP, ou un
   intervalle (inclusif) de ports (mais voyez Utiliser les fragments plus
   bas). Un intervalle est reprsent en utilisant le caractre ":", par
   exemple "6000:6010", qui couvre 11 ports, du 6000 au 6010, de manire
   inclusive. Si la borne infrieure est omise, alors elle se met par
   dfaut  0. Si la borne suprieure est omise, elle est considre par
   dfaut comme tant 65535. Ainsi, pour spcifier les connexions TCP
   venant des ports infrieurs  1024, la syntaxe pourrait tre "-p TCP
   -s 0.0.0.0/0 :1023". Les numros de ports peuvent tre spcifis par
   leur nom, par exemple "www".

   Notez que la spcification du port peut tre prcde par un "!", qui
   l'inverse. Ainsi, pour spcifier tous les paquets TCP, SAUF un paquet
   WWW, vous pourriez spcifier
-p TCP -d 0.0.0.0/0 ! www

   Il est important de raliser que spcifier

-p TCP -d ! 192.168.1.1 www

   est trs diffrent de
-p TCP -d 192.168.1.1 ! www

   La premire ligne spcifie tout paquet TCP dirig vers le port WWW de
   n'importe quelle machine sauf 192.168.1.1. La seconde spcifie toute
   connexion TCP vers tout port de 192.168.1.1 sauf le port WWW.

   Enfin, le cas suivant spcifie tout, sauf le port WWW et la machine
   192.168.1.1 :
-p TCP -d ! 192.168.1.1 ! www

  Spcifier les types et codes ICMP

   ICMP permet aussi un argument optionnel, mais comme l'ICMP ne dispose
   pas de ports (ICMP a un _type_ et un _code_), ils ont une
   signification diffrente.

   Vous pouvez les spcifier par les noms ICMP (utilisez ipchains -h icmp
   pour lister les noms disponibles) aprs l'option "-s", ou en tant que
   type et code ICMP numrique, o le type suit l'option "-s" et le code
   suit l'option "-d".

   Les noms ICMP sont relativement longs : vous avez uniquement besoin de
   suffisamment de lettres pour rendre chaque nom distinct des autres.

   Voici un petit rsum de quelques-uns des paquets ICMP les plus
   communs :

Numro  Nom                     Utilis par

0       echo-reply              ping
3       destination-unreachable Tout trafic TCP/UDP
5       redirect                Routage, si pas de dmon de routage
8       echo-request            ping
11      time-exceeded           traceroute

   Notez que les noms ICMP ne peuvent tre prcds de "!" pour le
   moment.

   NE PAS, SURTOUT NE PAS bloquer tous les paquets ICMP de type 3 ! (voir
   Paquets ICMP plus bas).

  Spcifier une interface

   L'option "-i" spcifie le nom d'une _interface_  vrifier. Une
   interface est le priphrique physique d'o vient le paquet, ou bien
   par o sort ce paquet. Vous pouvez utiliser la commande ifconfig pour
   lister les interfaces qui sont "up" (cd en fonctionnement).

   L'interface pour les paquets entrants (ie. les paquets traversant la
   chane d'entre) est considre comme tant l'interface d'o les
   paquets proviennent. Logiquement, l'interface des paquets sortants
   (les paquets traversant la chane de sortie) est l'interface o ils
   vont. L'interface pour les paquets traversant la chane de
   retransmission est galement l'interface par laquelle ils sortiront ;
   une dcision plutt arbitraire  mon sens.

   Il est parfaitement autoris de spcifier une interface qui n'existe
   pas au moment de la spcification ; la rgle ne vrifiera rien jusqu'
   ce que l'interface soit mise en place. Ceci est extrmement utile pour
   les connexions ppp intermittentes (habituellement les interfaces du
   type ppp0) et autres.

   En tant que cas spcial, un nom d'interface se finissant par un "+"
   vrifiera toutes les interfaces (qu'elles existent  ce moment ou non)
   qui commencent par cette chane. Par exemple, pour spcifier une rgle
   qui vrifiera toutes les interfaces PPP, l'option -i ppp+ pourrait
   tre utilise.

   Le nom d'interface peut tre prcd par un "!" pour vrifier un
   paquet qui ne vrifie PAS l'(les) interface(s) spcifie(s).

  Spcifier uniquement des paquets TCP SYN

   Il est parfois utile d'autoriser des connexions TCP dans une
   direction, mais pas dans l'autre. Par exemple, vous pouvez vouloir
   autoriser les connexions vers un serveur WWW externe, mais pas les
   connexions venant de ce serveur.

   L'approche nave serait de bloquer les paquets TCP venant du serveur.
   Malheureusement, les connexions TCP utilisent des paquets circulant
   dans les deux sens pour fonctionner.

   La solution est de bloquer uniquement les paquets utiliss pour la
   demande d'une connexion. Ces paquets sont nomms paquets _SYN_ (ok,
   techniquement ce sont des paquets avec le drapeau SYN mis, et les
   drapeaux FIN et ACK supprims, mais nous les appellerons des paquets
   SYN). En interdisant seulement ces paquets, nous pouvons stopper toute
   demande de connexion dans l'oeuf.

   L'option "-y" est utilise pour cel : elle est valide seulement pour
   les rgles qui spcifient TCP comme leur protocole. Par exemple, pour
   spcifier une demande de connexion TCP venant de 192.168.1.1 :
-p TCP -s 192.168.1.1 -y

   Une fois de plus, ce drapeau peut tre invers en le faisant prcder
   par un "!", qui vrifie tout paquet autre que ceux d'initialisation de
   connexion.

  Utiliser les fragments

   Parfois, un paquet est trop large pour rentrer dans le cble en une
   seule fois. Lorsque ceci arrive, le paquet est divis en _fragments_,
   et envoy en plusieurs paquets. Le receveur rassemble les fragments
   pour reconstruire le paquet en entier.

   Le problme avec les fragments se situe dans certaines des
   spcifications listes ci-dessus (en particulier, le port source, le
   port de destination, le type et le code ICMP, ou le drapeau TCP SYN),
   qui demandent au noyau de jeter un regard sur le dbut du paquet, qui
   est contenu seulement dans le premier fragment.

   Si votre machine est la seule connexion vers un rseau extrieur, vous
   pouvez demander  votre noyau Linux de rassembler tous les fragments
   qui passent par lui, en compilant le noyau avec l'option IP: always
   defragment mise  "Y". Ceci vite proprement la plupart des problmes.

   D'autre part, il est important de comprendre comment les fragments
   sont traits par les rgles de filtrage. Toute rgle de filtrage qui
   demande des informations dont nous ne disposons pas ne vrifiera
   _rien_. Ceci signifie que le premier fragment est trait comme tout
   autre paquet. Le deuxime fragment et les suivants ne le seront pas.
   Ainsi, une rgle -p TCP -s 192.168.1.1 www (spcifiant un port source
   de "www" ne vrifiera jamais un fragment (autre que le premier
   fragment). La rgle oppose -p TCP -s 192.168.1.1 ! www ne
   fonctionnera pas non plus.

   Cependant, vous pouvez spcifier une rgle spciale pour le deuxime
   fragment et les suivants, en utilisant l'option "-f". videmment, il
   est illgal de spcifier un port TCP ou UDP, un type ou un code ICMP,
   ou un drapeau TCP SYN dans une rgle de fragment.

   Il est galement autoris de spcifier une rgle qui ne s'applique
   _pas_ au deuxime fragment et aux suivants, en plaant un "!" avant le
   "-f".

   Habituellement, il est considr comme sr de laisser passer le
   deuxime fragment et les suivants, puisque le filtrage s'effectuera
   sur le premier fragment, et prviendra donc le rassemblage sur la
   machine cible. Cependant, des bogues, connus, permettent de crasher
   des machines en envoyant de simples fragments.  vous de voir.

    noter pour les gourous rseau : les paquets malforms (TCP, UDP et
   paquets ICMP trop courts pour que le code pare-feu puisse lire les
   ports ou les types et codes ICMP) sont galement traits comme des
   fragments. Seuls les fragments TCP dbutant en position 8 sont
   supprims explicitement par le code pare-feu (un message doit
   apparatre dans le syslog si cel arrive).

   Par exemple, la rgle suivante supprimera tout fragment allant sur
   192.168.1.1 :


# ipchains -A output -f -d 192.168.1.1 -j DENY
#

  Effets de bord du filtrage

   OK, maintenant nous connaissons tous les moyens pour vrifier un
   paquet en utilisant une rgle. Si un paquet vrifie une rgle, les
   choses suivantes arrivent :

    1. Le compteur d'octets de cette rgle est augment de la taille de
       ce paquet (entte et autres) ;
    2. Le compteur de paquets de cette rgle est incrment ;
    3. Si la rgle le demande, le paquet est enregistr ;
    4. Si la rgle le demande, le champ "Type Of Service" du paquet est
       modifi ;
    5. Si la rgle le demande, le paquet est marqu (sauf dans la srie
       des noyaux 2.0) ;
    6. La destination de la rgle est examine afin de dcider ce que
       nous ferons ensuite du paquet.

   Pour la diversit, je dtaillerai ceux-ci en ordre d'importance.

  Spcifier une destination

   Une _destination_ dit au noyau ce qu'il doit faire d'un paquet qui
   vrifie une rgle. ipchains utilise "-j" (penser  "jump-to") pour la
   spcification de la destination. Le nom de la cible doit comporter
   moins de 8 caractres, et la casse intervient : "RETOUR" et "retour"
   sont totalement diffrents.

   Le cas le plus simple est lorsqu'il n'y a pas de destination
   spcifie. Ce type de rgle (souvent appelle rgle de "comptage") est
   utile pour simplement compter un certain type de paquet. Que cette
   rgle soit vrifie ou non, le noyau examine simplement la rgle
   suivante dans la chane. Par exemple, pour compter le nombre de
   paquets venant de 192.168.1.1, nous pouvons faire ceci :

# ipchains -A input -s 192.168.1.1
#

   (En utilisant "ipchains -L -v" nous pouvons voir les compteurs de
   paquets et d'octets associs  chaque rgle).

   Il y a six destinations spciales. Les trois premires, ACCEPT, REJECT
   et DENY sont relativement simples. ACCEPT autorise le passage du
   paquet. DENY supprime le paquet comme s'il n'avait jamais t reu.
   REJECT supprime le paquet, mais (si ce n'est pas un paquet ICMP)
   gnre une rponse ICMP vers la source pour lui dire que la
   destination n'est pas accessible.

   La suivante, MASQ dit au noyau de camoufler le paquet. Pour que ceci
   fonctionne, votre noyau doit tre compil avec le camouflage IP
   intgr. Pour les dtails sur ceci, voyez le Masquerading-HOWTO et
   l'annexe Diffrences entre ipchains et ipfwadm. Cette destination est
   valide uniquement pour les paquets qui traversent la chane forward.

   L'autre destination majeure spciale est REDIRECT qui demande au noyau
   d'envoyer un paquet vers un port local au lieu de l o il tait
   destin. Ceci peut tre spcifi uniquement pour les rgles spcifiant
   TCP ou UDP en tant que protocole. Optionnellement, un port (nom ou
   numro) peut tre spcifi aprs "-j REDIRECT" qui redirigera la
   paquet vers ce port particulier, mme si celui-ci tait dirig vers un
   autre port. Cette destination est valide uniquement pour les paquets
   traversant la chane input.

   La dernire destination spciale est la RETURN qui est identique  une
   terminaison immdiate de la chane (voir Choisir une police plus bas).

   Toute autre destination indique une chane dfinie par l'utilisateur
   (dcrite dans Oprations sur une chane entire plus bas). Le paquet
   traversera tout d'abord les rgles de cette chane. Si cette chane ne
   dcide pas du destin du paquet, lorsque la traverse de cette chane
   sera acheve, la traverse reprendra sur la rgle suivante de la
   chane courante.

   Il est temps de faire encore un peu d'art ASCII. Considrons deux
   (tranges) chanes : input (la chane intgre) et Test (une chane
   dfinie par l'utilisateur).

              `input'                          `Test'
        -----------------------------    -----------------------------
        | Rgle1: -p ICMP -j REJECT |    | Rgle1: -s 192.168.1.1    |
        |---------------------------|    |---------------------------|
        | Rgle2: -p TCP -j Test    |    | Rgle2: -d 192.168.1.1    |
        |---------------------------|    -----------------------------
        | Rgle3: -p UDP -j DENY    |
        -----------------------------

   Considrons un paquet TCP venant de 192.168.1.1, allant vers 1.2.3.4.
   Il pntre dans la chane input, et est test par la Rgle1 - pas de
   correspondance. La Rgle2 correspond, et sa destination est Test, donc
   la rgle suivante  examiner est le dbut de Test. La Rgle1 de Test
   correspond, mais ne spcifie pas de destination, donc la rgle
   suivante est examine (Rgle2). Elle ne correspond pas, nous avons
   donc atteint la fin de la chane. Nous retournons alors  la chane
   input, dont nous avons juste examin la Rgle2, et nous examinons
   alors la Rgle3, qui ne correspond pas non plus.

   Le chemin suivi par le paquet est donc le suivant :
                                v    __________________________
         `entre'               |   /    `Test'                v
        ------------------------|--/    -----------------------|----
        | Rgle1                | /|    | Rgle1               |   |
        |-----------------------|/-|    |----------------------|---|
        | Rgle2                /  |    | Rgle2               |   |
        |--------------------------|    -----------------------v----
        | Rgle3                /--+---------------------------/
        ------------------------|---
                                v

   Voyez la section Comment organiser vos rgles pare-feu pour les moyens
   d'utiliser efficacement les chanes dfinies par l'utilisateur.

  Enregistrement des paquets

   C'est un effet de bord que la vrification d'une rgle peut avoir ;
   vous pouvez enregistrer les paquets vrifis en utilisant l'option
   "-l". Vous n'aurez gnralement pas besoin de ceci pour les paquets
   habituels, mais ce peut tre une option trs utile si vous dsirez
   tre tenu au courant des vnements exceptionnels.

   Le noyau enregistre cette information de la manire suivante :

Packet log: input DENY eth0 PROTO=17 192.168.2.1:53 192.168.1.1:1025
  L=34 S=0x00 I=18 F=0x0000 T=254

   Ce message d'information est prvu pour tre concis, et contient des
   informations techniques qui ne sont utiles qu'aux gourous rseau, mais
   qui peuvent nanmoins tre intressantes pour le commun des mortels.
   Il se dcompose de la faon suivante :

    1. `input' est la chane qui contenait la rgle correspondant au
       paquet, et qui a caus l'apparition du message.
    2. `DENY' est ce que la rgle a dit au paquet de faire. Si ceci est
       un `-' alors la rgle n'a pas du tout affect le paquet (une rgle
       de comptage).
    3. `eth0' est le nom de l'interface. Puisque ceci tait la chane
       d'entre, cel signifie que le paquet vient de `eth0'.
    4. `PROTO=17' signifie que le paquet tait de protocole 17. Une liste
       des numros de protocoles est donne dans `/etc/protocols'. Les
       plus communs sont 1 (ICMP), 6 (TCP) et 17 (UDP).
    5. `192.168.2.1' signifie que l'adresse IP source du paquet tait
       192.168.2.1.
    6. `:53' signifie que le port source tait le port 53. En regardant
       dans `/etc/services' on voit que ceci est le port `domain' (cd
       que c'est probablement une rponse DNS). Pour UDP et TCP, ce
       numro est le port source. Pour ICMP, c'est le type ICMP. Pour les
       autres, ce sera 65535.
    7. `192.168.1.1' est l'adresse IP de destination.
    8. `:1025' signifie que le port de destination tait 1025. Pour UDP
       et TCP, ce numro est le port de destination. Pour ICMP, il s'agit
       du code ICMP. Pour les autres, ce sera 65535.
    9. `L=34' signifie que le paquet avait une longueur totale de 34
       octets.
   10. `S=0x00' est le champ "Type Of Service" (divisez par 4 pour
       obtenir le Type of Service utilis par ipchains).
   11. `I=18' est l'identificateur de l'IP.
   12. `F=0x0000' est l'offset du fragment 16 bits, avec les options. Une
       valeur dbutant par `0x4' ou `0x5' signifie que le bit "Don't
       Fragment" (ne pas fragmenter) est mis. `0x2' ou `0x3' signifie que
       le bit "More Fragments" (des fragments suivent) est mis ; attendez
       vous  recevoir plus de fragments aprs. Le reste du nombre est le
       dcalage de ce fragment, divis par 8.
   13. `T=254' est la dure de vie du paquet. On soustrait 1  cette
       valeur  chaque saut (hop), et on dbute gnralement  15 ou 255.
   14. `(#5)' il peut y avoir un numro entre parenthses sur les noyaux
       les plus rcents (peut-tre aprs le 2.2.9). Il s'agit du numro
       de la rgle qui a caus l'enregistrement du paquet.

   Sur les systmes Linux standards, la sortie du noyau est capture par
   klogd (dmon d'information du noyau) qui le repasse  syslogd (dmon
   d'information du systme). Le fichier `/etc/syslog.conf' contrle le
   comportement de syslogd, en spcifiant une destination pour chaque
   "partie" (dans notre cas, la partie est le "noyau") et un "niveau"
   (pour ipchains, le niveau utilis est "info").

   Par exemple, mon /etc/syslog.conf (Debian) contient deux lignes qui
   vrifient `kern.info' :

kern.*                          -/var/log/kern.log
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

   Ceci signifie que les messages sont dupliqus dans `/var/log/kern.log'
   et `/var/log/messages'. Pour plus de dtails, voyez `man syslog.conf'.

  Manipuler le type de service

   Il y a quatre bits utiliss par eux-mmes dans l'entte IP, appels
   les bits de _Type of Service_ (TOS). Ceux-ci ont pour effet de
   modifier la manire dont les paquets sont traits : les quatres bits
   sont "Minimum Delay", "Maximum Throughput", "Maximum Reliability" et
   "Minimum Cost". Un seul de ces bits est autoris  tre plac. Rob van
   Nieuwkerk, l'auteur du code de gestion du TOS, les dcrit comme suit :

     Tout spcialement, le "Minimum Delay" est important pour moi. Je le
     mets pour les paquets "interactifs" dans mon routeur principal
     (Linux). Je suis derrire une connexion modem 33,6k. Linux rend les
     paquets prioritaires en 3 queues. De cette faon, j'obtiens des
     performances interactives acceptables tout en faisant de gros
     transferts de fichiers en mme temps. (Cel pourrait mme tre
     encore mieux s'il n'y avait pas de grosse queue dans le pilote
     srie, mais le temps de latence est maintenu en dessous des 1,5
     secondes pour l'instant).

   Note : bien entendu, vous n'avez aucun contrle sur les paquets
   arrivants ; vous pouvez seulement contrler la priorit des paquets
   qui quittent votre machine. Pour ngocier les priorits de chaque
   ct, un protocole comme RSVP (dont je ne connais rien) doit tre
   utilis.

   L'utilisation la plus commune est de placer les connexions telnet et
   contrle du ftp en "Minimum Delay" et les donnes FTP en "Maximum
   Throughput". Ceci peut tre fait de la manire suivante :

ipchains -A output -p tcp -d 0.0.0.0/0 telnet -t 0x01 0x10
ipchains -A output -p tcp -d 0.0.0.0/0 ftp -t 0x01 0x10
ipchains -A output -p tcp -s 0.0.0.0/0 ftp-data -t 0x01 0x08

   L'option "-t" prend deux paramtres supplmentaires, tous les deux en
   hexadcimal. Ceci permet un contrle complexe des bits du TOS : le
   premier masque est AND avec le TOS actuel du paquet, et ensuite le
   deuxime masque est XOR avec lui. Si cel est trop confus, utilisez
   simplement le tableau suivant :

Nom du TOS              Valeur          Utilisations typiques

Minimum Delay           0x01 0x10       ftp, telnet
Maximum Throughput      0x01 0x08       ftp-data
Maximum Reliability     0x01 0x04       snmp
Minimum Cost            0x01 0x02       nntp

   Andi Kleen revient sur ce point pour ce qui suit (modrment dit
   pour la postrit) :

     Peut-tre serait-il utile d'ajouter une rfrence au paramte
     txqueuelen de ifconfig dans la discussion sur les bits TOS. La
     longueur par dfaut de la queue d'un priphrique est rgle pour
     les cartes ethernet, sur les modems elle est trop longue et rend le
     fonctionnement de la planification 3 bandes (qui place la queue en
     fonction du TOS) sous-optimal. C'est donc une bonne ide de le
     configurer avec une valeur comprise entre 4 et 10 sur un modem ou
     un lien RNIS b simple : sur les priphriques rapide une queue plus
     longue est ncessaire. C'est un problme des 2.0 et 2.1, mais dans
     le 2.1 c'est une option de ifconfig (dans les nettools rcents),
     alors que dans le 2.0 il ncessite une modification des sources des
     pilotes du priphrique pour le changer.

   Ainsi, pour voir les bnfices maximum des changements de TOS pour les
   liaisons modem PPP, ajoutez un `ifconfig $1 txqueuelen' dans votre
   script /etc/ppp/ip-up. Le nombre  utiliser dpend de la vitesse du
   modem et de la taille du tampon du modem ; voici  nouveau les ides
   d'Andi :

     La meilleure valeur pour une configuration donne ncessite de
     l'exprimentation. Si les queues sont trop courtes sur le routeur,
     alors les paquets sauteront. Bien sr, on peut toujours gagner mme
     sans changer le TOS, c'est juste que le changement du TOS aide 
     gagner les bnfices sur les programmes non coopratifs (mais tous
     les programmes Linux standards sont coopratifs).

  Marquage d'un paquet

   Ceci permet des interactions complexes et puissantes avec la nouvelle
   implmentation de Quality of Service d'Alexey Kuznetsov, ainsi que de
   la redirection base sur le marquage dans la dernire srie de noyaux
   2.1. Des dtails supplmentaires vont arriver puisque nous l'avons
   dans la main. Cette option est toutefois ignore dans la srie des
   noyaux 2.0.

  Oprations sur une chane entire

   Une des options les plus utiles d'ipchains est la possibilit de
   regrouper des rgles dans des chanes. Vous pouvez appeller les
   chanes de la manire qui vous plat, tant que les noms ne sont pas
   ceux des chanes intgres (input, output et forward) ou des
   destinations ((MASQ, REDIRECT, ACCEPT, DENY, REJECT ou RETURN). Je
   suggre d'viter compltement les noms en majuscules, car je pourrais
   les utiliser pour des extensions futures. Le nom de la chane ne doit
   pas dpasser 8 caractres.

  Crer une nouvelle chane

   Crons une nouvelle chane. tant un type imaginatif, je l'appellerai
   test.

# ipchains -N test
#

   C'est aussi simple. Maintenant vous pouvez y rajouter des rgles,
   comme dtaill ci-dessus.

  Supprimer une chane

   La suppression d'une chane est tout aussi simple.

# ipchains -X test
#

   Pourquoi "-X" ? Eh bien, toutes les bonnes lettres taient dj
   prises.

   Il y a quelques restrictions  la suppression des chanes : elles
   doivent tre vides (voir Vider une chane plus bas) et elles ne
   doivent pas tre la destination d'une quelconque rgle. Vous ne pouvez
   pas supprimer les chanes intgres.

  Vider une chane

   Il y a un moyen simple de vider toutes les rgles d'une chane, en
   utilisant la commande "-F".

# ipchains -F forward
#

   Si vous ne spcifiez pas de chane, alors _toutes_ les chanes seront
   vides.

  Afficher une chane

   Vous pouvez afficher toutes les rgles d'une chane en utilisant la
   commande "-L".

# ipchains -L input
Chain input (refcnt = 1): (policy ACCEPT)
target     prot opt    source                destination           ports
ACCEPT     icmp -----  anywhere              anywhere              any
# ipchains -L test
Chain test (refcnt = 0):
target     prot opt    source                destination           ports
DENY       icmp -----  localnet/24           anywhere              any
#

   La "refcnt" liste pour test est le nombre de rgles qui ont test
   comme destination. Ceci doit tre gal  zro (et la chane doit tre
   vide) avant que cette chane ne puisse tre supprime.

   Si le nom de la chane est omis, toutes les chanes sont listes, mme
   les chanes vides.

   Il y a trois options qui peuvent accompagner "-L". L'option "-n"
   (numrique) est trs utile et empche ipchains d'essayer de vrifier
   les adresses IP, ce qui (si vous utilisez DNS comme la plupart des
   gens) causera de longs dlais si votre DNS n'est pas configur
   proprement, ou si vous filtrez les requtes DNS. Ceci affichera
   galement les ports par leur numro plutt que par leur nom.

   L'option "-v" vous montrera tous les dtails des rgles, comme les
   compteurs de paquets et d'octets, les masques de TOS, l'interface, et
   les marques de paquets. Autrement, ces valeurs seront omises. Par
   exemple :

# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
 pkts bytes target prot opt   tosa tosx ifname  mark  source    destination  po
rts
   10   840 ACCEPT icmp ----- 0xFF 0x00 lo            anywhere  anywhere     an
y

   Notez que les compteurs de paquets et d'octets sont affichs en
   utilisant les suffixes "K", "M" ou "G" pour 1000, 1.000.000 et
   1.000.000.000, respectivement. En utilisant galement l'option "-x"
   (dveloppe les nombres), ipchains affichera les nombres en entier,
   quelque soit leur taille.

  Remise  zro des compteurs

   Il est parfois utile de pouvoir remettre  zro les compteurs. Ceci
   peut tre fait par l'option "-Z" (compteurs  Zro). Par exemple :

# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
 pkts bytes target prot opt   tosa tosx ifname  mark  source    destination  po
rts
   10   840 ACCEPT icmp ----- 0xFF 0x00 lo            anywhere  anywhere     an
y
# ipchains -Z input
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
 pkts bytes target prot opt   tosa tosx ifname  mark  source      destination
 ports
    0     0 ACCEPT icmp ----- 0xFF 0x00 lo            anywhere    anywhere
 any
#

   Le problme de cette approche est que parfois vous voudrez connatre
   les valeurs du compteur tout de suite aprs la remise  zro. Dans
   l'exemple ci-dessus, quelques paquets peuvent passer entre les
   commandes "-L" et "-Z". Pour cette raison, vous pouvez utiliser le
   "-L" et le "-Z" _ensemble_, pour remettre  zro les compteurs tout en
   les lisant. Malheureusement, si vous fates ceci, vous ne pouvez
   oprer sur une seule chane : vous devrez lister et remettre  zro
   toutes les chanes en une seule fois.

# ipchains -L -v -Z
Chain input (policy ACCEPT):
 pkts bytes target prot opt   tosa tosx ifname  mark  source      destination
 ports
   10   840 ACCEPT icmp ----- 0xFF 0x00 lo            anywhere    anywhere
 any

Chain forward (refcnt = 1): (policy ACCEPT)
Chain output (refcnt = 1): (policy ACCEPT)
Chain test (refcnt = 0):
    0     0 DENY   icmp ----- 0xFF 0x00  ppp0         localnet/24 anywhere
 any
# ipchains -L -v
Chain input (policy ACCEPT):
 pkts bytes target prot opt   tosa tosx ifname  mark  source      destination
 ports
   10   840 ACCEPT icmp ----- 0xFF 0x00 lo            anywhere    anywhere
 any

Chain forward (refcnt = 1): (policy ACCEPT)
Chain output (refcnt = 1): (policy ACCEPT)
Chain test (refcnt = 0):
    0     0 DENY   icmp ----- 0xFF 0x00 ppp0          localnet/24 anywhere
any
#

  Choisir une police

   Nous avons dissert sur ce qui se passe lorsqu'un paquet atteint la
   fin de la chane intgre, lorsque nous avons discut sur la manire
   dont un paquet parcourait les chanes dans Spcifier une destination
   plus haut. Dans ce cas, la _police_ de la chane dtermine le destin
   du paquet. Seules les chanes intgres (input, output et forward) ont
   des polices, car si un paquet atteint la fin d'une chane dfinie par
   l'utilisateur, le paquet revient sur la chane prcdente.

   La police peut tre une des quatre premires destinations spciales :
   ACCEPT, DENY, REJECT ou MASQ. MASQ est la seule destination valide
   pour la chane "forward".

   Il est galement important de noter qu'une destination RETURN dans une
   rgle de l'une des chanes intgres est utile pour expliciter la
   destination de la chane lorsqu'un paquet correspond  la rgle.

  Oprations sur le camouflage

   Il y a plusieurs paramtres que vous pouvez modifier pour le
   camouflage IP. Ils sont intgrs avec ipchains car il n'est pas
   vident d'crire un outil spar pour eux (bien que ceci devrait
   changer).

   La commande du camouflage IP est "-M", et peut tre combine avec "-L"
   pour lister les connexions actuellement camoufles, ou avec "-S" pour
   configurer les paramtres du camouflage.

   La commande "-L" peut tre accompagne par "-n" (montre des nombres 
   la place des noms de machines et de ports) ou "-v" (affiche les deltas
   dans les squences de nombres pour la connexion camoufle, au cas o
   vous vous demanderiez).

   La commande "-S" doit tre suivie par trois valeurs de fin d'attente,
   toutes en secondes : pour les sessions TCP, pour les sessions TCP
   prcdes d'un paquet FIN, et pour les paquets UDP. Si vous ne voulez
   pas changer l'une de ces valeurs, donnez-lui simplement une valeur de
   "0".

   Les valeurs par dfaut sont listes dans
   "/usr/src/linux/include/net/ip_masq.h", actuellement 15 minutes, 2
   minutes et 5 minutes, respectivement.

   La valeur change le plus souvent est la premire, pour le FTP (voir
   Cauchemars du FTP plus bas).

   Notez que les problmes avec la mise en place de temps de fin
   d'attente sont lists dans Je n'arrive pas  configurer mes temps
   d'attente !.

  Vrifier un paquet

   Parfois, vous voulez savoir ce qui arrive lorsqu'un certain paquet
   entre dans votre machine, par exemple pour dboguer votre chane
   pare-feu. ipchains dispose de la commande "-C" pour autoriser cel, en
   utilisant exactement les mmes routines que celles que le noyau
   utilise pour vrifier les vrais paquets.

   Vous spcifiez sur quelle chane le paquet doit tre test en mettant
   son nom aprs l'argument "-C". Mme si le noyau commence toujours par
   traverser les chanes input, output ou forward, vous tes autoris 
   commencer en traversant n'importe quelle chane pour tester.

   Les dtails du "paquet" sont spcifis en utilisant la mme syntaxe
   que celle utilise pour spcifier les rgles pare-feu. En particulier,
   un protocole ("-p"), une adresse source ("-s"), une adresse de
   destination ("-d") et une interface ("-i") sont ncessaires. Si le
   protocole est TCP ou UDP, alors une source unique et une destination
   unique doivent tre spcifies, et un type et un code ICMP doivent
   tre spcifis pour le protocole ICMP ( moins que l'option "-f" soit
   spcifie pour indiquer une rgle de fragment, auquel cas ces options
   sont illgales).

   Si le protocole est TCP (et que l'option "-f" n'est pas spcifie),
   l'option "-y' doit tre explicite, afin d'indiquer que le paquet test
   doit tre configur avec le bit SYN.

   Voici un exemple de test d'un paquet TCP SYN venant de 192.168.1.1,
   port 60000, et allant sur 192.168.1.2, port www, arrivant de
   l'interface eth0 et entrant dans la chane "input" (il s'agit d'une
   initialisation classique d'une connexion WWW) :

# ipchains -C input -p tcp -y -i eth0 -s 192.168.1.1 60000 -d 192.168.1.2 www
packet accepted
#

  Voir ce qui arrive avec des rgles multiples prcises en une seule fois

   Parfois, une simple ligne de commande peut affecter de multiples
   rgles. Ceci se fait par deux mthodes. Premirement, si vous
   spcifiez un nom de machine qui correspond (en utilisant DNS)  de
   multiples adresses IP, ipchains agira comme si vous aviez tap de
   multiples commandes avec chaque combinaison d'adresses.

   Ainsi, si le nom de machine "www.foo.com" correspond  trois adresses
   IP, et si le nom de machine "www.bar.com" correspond  deux adresses
   IP, alors la commande "ipchains -A input -j reject -s www.bar.com -d
   www.foo.com" ajoutera six rgles  la chane input.

   L'autre mthode pour avoir ipchains ralisant de multiples actions est
   d'utiliser l'option bidirectionnelle ("-b"). Cette option fait agir
   ipchains comme si vous aviez tap la commande deux fois, la deuxime
   fois avec les arguments "-s" et "-d" inverss. Ainsi, pour viter la
   transmission soit de, soit vers 192.168.1.1, vous pourriez utiliser la
   commande :

# ipchains -b -A forward -j reject -s 192.168.1.1
#

   Personnellement, je n'aime pas beaucoup l'option "-b" ; si vous
   prfrez la convivialit, voyez Utiliser ipchains-save plus bas.

   L'option -b peut tre utilise avec les commandes insrer ("-I"),
   supprimer ("-D") (mais pas avec la variation qui prend un numro de
   rgle), ajouter ("-A") et vrifier ("-C").

   Une autre option utile est "-v" (bruyant) qui imprime exactement ce
   que ipchains fait avec vos commandes. Ceci est utile si vous traitez
   avec des commandes qui peuvent affecter de multiples rgles. Par
   exemple, nous devons ici vrifier le comportement de fragments entre
   192.168.1.1 et 192.168.1.2.

# ipchains -v -b -C input -p tcp -f -s 192.168.1.1 -d 192.168.1.2 -i lo
  tcp opt   ---f- tos 0xFF 0x00  via lo    192.168.1.1  -> 192.168.1.2    * ->
  *
packet accepted
  tcp opt   ---f- tos 0xFF 0x00  via lo    192.168.1.2  -> 192.168.1.1    * ->
  *
packet accepted
#

4.2 Exemples utiles

   J'ai une connexion intermittente en PPP (-i ppp0). Je rcupre les
   news (-p TCP -s news.virtual.net.au nntp) et le courrier (-p TCP -s
   mail.virtual.net.au pop-3)  chaque fois que je me connecte. J'utilise
   la mthode ftp de Debian pour mettre ma machine  jour rgulirement
   (-p TCP -y -s ftp.debian.org.au ftp-data). Je visionne le web au
   travers du proxy de mon FAI (Fournisseur d'Accs Internet) lorsque je
   suis en ligne (-p TCP -d proxy.virtual.net.au 8080), mais je dteste
   les publicits de doubleclick.net des Archives de Dilbert (-p TCP -y
   -d 199.95.207.0/24 et -p TCP -y -d 199.95.208.0/24).

   J'autorise les gens  essayer le ftp sur ma machine lorsque je suis en
   ligne (-p TCP -d $LOCALIP ftp), mais je n'autorise personne de
   l'extrieur  prtendre avoir une adresse IP sur mon rseau interne
   (-s 192.168.1.0/24). Ceci est communment appel IP spoofing, et il y
   a un meilleur moyen de se protger dans les noyaux 2.1.x et suivants :
   voir Comment mettre en place la protection contre l'IP spoof ?.

   Cette configuration est relativement simple, car il n'y a pour
   l'instant aucune autre machine sur mon rseau interne.

   Je ne veux pas que des processus locaux (ie. Netscape, lynx, etc.) se
   connectent  doubleclick.net :

# ipchains -A output -d 199.95.207.0/24 -j REJECT
# ipchains -A output -d 199.95.208.0/24 -j REJECT
#

   Maintenant je dsire changer les priorits des divers paquets sortants
   (il n'y a pas vraiment d'intrt  le faire pour les paquets
   entrants). Puisqu'il y a un certain nombre de ces rgles, il y a
   intrt  les mettre ensemble dans une seule chane, nomme ppp-out.

# ipchains -N ppp-out
# ipchains -A output -i ppp0 -j ppp-out
#

   Dlai minimal pour le trafic web et telnet :

# ipchains -A ppp-out -p TCP -d proxy.virtual.net.au 8080 -t 0x01 0x10
# ipchains -A ppp-out -p TCP -d 0.0.0.0 telnet -t 0x01 0x10
#

   Cot faible pour les donnes ftp, nntp et pop-3 :

# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 ftp-data -t 0x01 0x02
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 nntp -t 0x01 0x02
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 pop-3 -t 0x01 0x02
#

   Il y a quelques restrictions sur les paquets venant de l'interface
   ppp0 ; crons une chane nomme "ppp-in" :

# ipchains -N ppp-in
# ipchains -A input -i ppp0 -j ppp-in
#

   Maintenant, aucun des paquets venant de ppp0 ne doit prtendre avoir
   une adresse source de la forme 192.168.1.*, donc nous les enregistrons
   et les interdisons :

# ipchains -A ppp-in -s 192.168.1.0/24 -l -j DENY
#

   J'autorise l'entre des paquets UDP pour le DNS (je fais tourner un
   serveur de nom cache qui renvoie toutes les demandes sur 203.29.16.1,
   donc je m'attend  des rponses DNS venant uniquement de l), l'entre
   du ftp, et le retour des donnes ftp (ftp-data) uniquement (ce qui
   doit tre uniquement entre un port strictement suprieur  1023, et
   pas sur les ports X11 autour de 6000).

# ipchains -A ppp-in -p UDP -s 203.29.16.1 -d $LOCALIP dns -j ACCEPT
# ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 1024:5999 -j ACCE
PT
# ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 6010: -j ACCEPT
# ipchains -A ppp-in -p TCP -d $LOCALIP ftp -j ACCEPT
#

   Enfin, les paquets local vers local sont OK :

# ipchains -A input -i lo -j ACCEPT
#

   Maintenant, ma police par dfaut sur la chane input est DENY, ce qui
   fait que tout le reste disparat :

# ipchains -P input DENY
#

   NOTE : Je ne configurerais pas mes chanes dans cet ordre, car des
   paquets pourraient passer durant la configuration. Le moyen le plus
   sr est gnralement de configurer la police  DENY tout d'abord, et
   ensuite d'insrer les rgles. Bien sr, si vos rgles ont besoin
   d'effectuer des demandes DNS pour rsoudre des noms de machines, vous
   pourriez avoir des problmes.

  Utiliser ipchains-save

   Configurer des chanes pare-feu de la manire exacte dont vous le
   voulez, et se rappeller ensuite des commandes que vous avez utilis
   pour le faire la fois suivante est insupportable.

   Donc, ipchains-save est un script qui lit votre configuration actuelle
   des chanes et la sauve dans un fichier. Pour le moment, je
   conserverais le suspens en ce qui concerne l'utilit de
   ipchains-restore.

   ipchains-save peut sauver une chane seule, ou toutes les chanes (si
   aucun nom de chane n'a t spcifi). La seule option actuellement
   autorise est le "-v" qui affiche les rgles (vers stderr)
   lorsqu'elles sont sauves. La police de la chane est aussi sauve
   pour les chanes input, output et forward.

# ipchains-save > my_firewall
Saving `input'.
Saving `output'.
Saving `forward'.
Saving `ppp-in'.
Saving `ppp-out'.
#

  Utiliser ipchains-restore

   ipchains-restore remet les chanes que vous avez sauv avec
   ipchains-save. Il peut prendre deux options : "-v" qui dcrit chaque
   rgle lorsqu'elle est ajoute, et "-f" qui force le nettoyage des
   chanes dfinies par l'utilisateur si elles existent, comme dcrit
   plus bas.

   Si une chane dfinie par l'utilisateur est trouve  l'entre,
   ipchains-restore vrifie que cette chane existe dj. Si elle existe,
   alors vous serez interrog pour savoir si la chane doit tre nettoye
   (suppression de toutes les rgles) ou si la restauration de la chane
   doit tre saute. Si vous spcifiez "-f" sur la ligne de commande,
   vous ne serez pas interrog ; la chane sera nettoye.

   Par exemple :

# ipchains-restore < my_firewall
Restoring `input'.
Restoring `output'.
Restoring `forward'.
Restoring `ppp-in'.
Chain `ppp-in' already exists. Skip or flush? [S/f]? s
Skipping `ppp-in'.
Restoring `ppp-out'.
Chain `ppp-out' already exists. Skip or flush? [S/f]? f
Flushing `ppp-out'.
#

5. Divers

   Cette section contient toutes les informations et les questions
   frquemment poses que je ne pouvais faire entrer dans la structure
   ci-dessus.

5.1 Comment organiser vos rgles pare-feu

   Cette question ncessite un peu de rflexion. Vous pouvez tenter de
   les organiser pour optimiser la vitesse (minimiser le nombre de
   vrifications de rgles pour la plupart des paquets) ou pour augmenter
   la maniabilit.

   Si vous avez une connexion intermittente, disons une connexion PPP,
   vous pouvez configurer la premire rgle de la chane d'entre pour
   tre `-i ppp0 -j DENY' au lancement, puis avoir quelque chose comme
   ceci dans votre script ip-up :

# Re-cre la chane "ppp-in"
ipchains-restore -f < ppp-in.firewall

# Remplace la rgle DENY par un saut vers la chane se chargeant du ppp
ipchains -R input 1 -i ppp0 -j ppp-in

   Votre script ip-down pourrait ressembler  a :

ipchains -R input 1 -i ppp0 -j DENY

5.2 Ce qu'il ne faut pas filtrer

   Il y a un certain nombre de choses auxquelles vous devez faire
   attention avant de commencer  filtrer quelque chose que vous n'auriez
   pas voulu filtrer.

  Les paquets ICMP

   Les paquets ICMP sont utiliss (entre autres choses) pour indiquer des
   problmes aux autres protocoles (comme TCP et UDP). Les paquets
   "destination-unreachable" (destination non accessible) en particulier.
   Le bloquage de ces paquets signifie que vous n'obtiendrez jamais les
   erreurs "Host unreachable" ou "No route to host" ; toute connexion
   attendra une rponse qui ne viendra jamais. C'est irritant, mais
   rarement fatal.

   Un problme plus inquitant est le rle des paquets ICMP dans la
   dcouverte MTU. Toutes les bonnes implmentations de TCP (y compris
   celle de Linux) utilisent la recherche MTU pour tenter de trouver quel
   est le plus grand paquet qui peut atteindre une destination sans tre
   fragment (la fragmentation diminue les performances, principalement
   lorsque des fragments occasionnels sont perdus). La recherche MTU
   fonctionne en envoyant des paquets avec le bit "Don't Fragment" mis,
   et en envoyant ensuite des paquets plus petits s'il reoit un paquet
   ICMP indiquant "Fragmentation needed but DF set"
   (`fragmentation-needed'). C'est un paquet de type
   "destination-unreachable", et s'il n'est jamais reu, l'hte local ne
   rduira pas le MTU, et les performances seront abyssales ou
   inexistantes.

   Notez qu'il est commun de bloquer tous les messages ICMP de
   redirection (type 5) ; ils peuvent tre utiliss pour manipuler le
   routage (bien que les piles IP bien conues disposent de gardes-fou),
   et sont donc souvent considrs comme quelques peu risqus.

  Connexions TCP au DNS (serveur de nom)

   Si vous tentez de bloquer toutes les connexions TCP sortantes,
   rappellez vous que le DNS n'utilise pas toujours UDP ; si la rponse
   du serveur dpasse les 512 octets, le client utilise une connexion TCP
   (allant toujours sur le port numro 53) pour obtenir les donnes.

   Ceci peut tre un pige car le DNS fonctionnera "en gros" si vous
   interdisez de tels transferts TCP ; vous pouvez exprimenter des
   dlais longs et tranges, et d'autres problmes lis au DNS si vous le
   faites.

   Si les demandes de votre DNS sont toujours diriges vers les mmes
   sources externes (soit directement en utilisant la ligne nameserver
   dans /etc/resolv.conf ou en utilisant un serveur de noms cache en mode
   de redirection), alors vous n'aurez besoin d'autoriser que les
   connexions du port domain sur ce serveur de nom  partir du port local
   domain (si vous utilisez un serveur de nom cache) ou d'un port lev
   (> 1023) si vous utilisez /etc/resolv.conf.

  Cauchemars du FTP

   L'autre problme classique du filtrage de paquets est celui pos par
   le FTP. Le FTP a deux _modes_ ; le mode traditionnel est appel _mode
   actif_ et le plus rcent est appel _mode passif_. Les navigateurs web
   utilisent souvent le mode passif par dfaut, mais les programmes de
   ftp en ligne de commmande utilisent en gnral par dfaut le mode
   actif.

   En mode actif, lorsque l'hte distant dsire envoyer un fichier (ou
   mme les rsultats d'une commande ls ou dir), il essaye d'ouvrir une
   connexion TCP sur la machine locale. Cel signifie que vous ne pouvez
   filtrez ces connexions TCP sans supprimer le FTP actif.

   Si vous avez comme option l'utilisation du mode passif, alors tout va
   bien ; le mode passif fait passer les connexions de donnes du client
   au serveur, mme pour les donnes arrivantes. Autrement, il est
   recommend de n'autoriser que les connexions TCP vers les ports
   suprieurs  1024 et de les interdire entre 6000 et 6010 (6000 est
   utilis par X-Windows).

5.3 Filtrer le ping de la mort (Ping of Death)

   Les machines Linux sont maintenant immunises du fameux _Ping of
   Death_, qui implique l'envoi de paquets ICMP illgalement grands qui
   font dborder les buffers de la pile TCP du rcepteur et causent de
   gros dgts.

   Si vous voulez protger des machines qui peuvent tre vulnrables, vos
   pouvez simplement bloquer les fragments ICMP. Les paquets ICMP normaux
   ne sont pas assez gros pour ncessiter la fragmentation, et vous ne
   casserez rien  part les gros pings. J'ai entendu parler (non
   confirm) de rapports comme quoi quelques systmes ont seulement
   besoin du dernier fragment d'un paquet ICMP dform pour les
   corrompre, donc bloquer seulement le premier fragment n'est pas
   recommand.

   Mme si tous les programmes exploitant cette erreur que j'ai vu
   utilisent l'ICMP, il n'y a pas de raisons qu'un fragment TCP ou UDP
   (ou d'un protocole inconnu) ne puisse tre utilis pour cette attaque,
   donc le bloquage des fragments ICMP est seulement une solution
   temporaire.

5.4 Filtrer teardrop et bonk

   Teardrop et Bonk sont deux attaques (principalement contre les
   machines sous Microsoft Windows NT) qui reposent sur des fragments
   superposs. Avoir votre routeur Linux dfragmenter, ou interdisant
   tous les fragments vers vos machines vulnrables sont d'autres
   options.

5.5 Filtrer les bombes  fragments

   Quelques piles TCP moins fiables sont connues pour avoir des problmes
    grer de larges ensembles de fragments de paquets lorsqu'elles ne
   reoivent pas tous les fragments. Linux n'a pas ce problme. Vous
   pouvez filtrer les fragments (ce qui peut casser les utilisations
   lgitimes) ou compiler votre noyau avec l'option "IP: always
   defragment" mise sur "Y" (seulement si votre machine Linux est la
   seule route possible pour ces paquets).

5.6 Changer les rgles pare-feu

   Il y a quelques problmes de temps qui sont impliqus dans la
   modification des rgles pare-feu. Si vous n'y faites pas attention,
   vous pouvez laisser entrer des paquets lorsque vous avez fait la
   moiti de vos changements. Une approche simpliste serait de faire la
   suite :

# ipchains -I input 1 -j DENY
# ipchains -I output 1 -j DENY
# ipchains -I forward 1 -j DENY

... Mise en place des changements ...

# ipchains -D input 1
# ipchains -D output 1
# ipchains -D forward 1
#

   Ceci supprime tous les paquets pour la dure des changements.

   Si vos changements sont restreints  une chane simple, vous pouvez
   crer une nouvelle chane avec les nouvelles rgles, et ensuite
   remplacer ("-R") la rgle qui pointait sur la vieille chane par une
   qui pointe sur la nouvelle chane ; ensuite, vous pouvez supprimer la
   vieille chane. Le remplacement se fera  vitesse atomique.

5.7 Comment mettre en place la protection contre l'IP spoof ?

   L'IP spoofing est une technique dans laquelle un hte envoie des
   paquets qui prtendent venir d'un autre hte. Puisque le filtrage des
   paquets prend ses dcisions sur la base de cette adresse source, l'IP
   spoofing est utilis pour abuser les filtres de paquets. Elle est
   galement utilise pour cacher l'identit d'un attaquant utilisant les
   techniques SYN, Teardrop, Ping of Death et autres drivs (ne vous
   inquitez si vous ne savez pas ce que c'est).

   Le meilleur moyen de se protger de l'IP spoofing est la vrification
   de l'adresse source, et il est ralis par le code de routage, et non
   par le pare-feu et autres.
   Cherchez un fichier nomm /proc/sys/net/ipv4/conf/all/rp_filter. S'il
   existe, alors l'activation de la vrification de l'adresse source 
   chaque lancement est la bonne solution pour vous. Pour se faire,
   insrez les lignes suivantes quelque part dans vos scripts
   d'initialisation, avant l'initialisation des interfaces rseau :

# This is the best method: turn on Source Address Verification and get
# spoof protection on all current and future interfaces.
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
  echo -n "Setting up IP spoofing protection..."
  for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
      echo 1 > $f
  done
  echo "done."
else
  echo PROBLEMS SETTING UP IP SPOOFING PROTECTION.  BE WORRIED.
  echo "CONTROL-D will exit from this shell and continue system startup."
  echo
  # Start a single user shell on the console
  /sbin/sulogin $CONSOLE
fi

   Si vous ne pouvez faire ceci, vous pouvez insrer manuellement les
   rgles pour protger chaque interface. Ceci ncessite la connaissance
   de chaque interface. La srie des noyaux 2.1 et suprieurs rejette
   automatiquement les paquets qui prtendent venir des adresses 127.*
   (rserves pour l'interface de loopback, lo).

   Par exemple, disons que vous avez trois interfaces, eth0, eth1 et
   ppp0. Nous pouvons utiliser ifconfig pour nous donner les adresses et
   les masques de rseau de chaque interface. Disons que eth0 est
   rattache  un rseau 192.168.1.0 avec le masque de sous-rseau
   255.255.255.0, eth1 est raccorde  un rseau 10.0.0.0 avec le masque
   de sous-rseau 255.0.0.0, et ppp0 connecte  l'Internet (o toutes
   les adresses sauf les adresses IP prives rserves sont autorises),
   nous insrerions les rgles suivantes :

# ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY
# ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY
#

   Cette approche n'est pas aussi bonne que l'approche par vrification
   de l'adresse source, parce que si votre rseau change, vous devrez
   changer vos rgles pare-feu pour tre  jour.

   Si vous utilisez un noyau de srie 2.0, vous pouvez galement vouloir
   protger l'interface loopback, en utilisant une rgle telle que :

# ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY
#

5.8 Projets avancs

   Il y a une bibliothque dans l'espace utilisateur que j'ai crit et
   qui est inclue avec la distribution source, nomme "libfw". Elle
   utilise la capacit de IP Chains 1.3 et suivants pour copier un paquet
   vers l'espace utilisateur (via l'option du noyau IP_FIREWALL_NETLINK).

   La valeur "mark" peut tre utilise pour spcifier les paramtres de
   Qualit de Service pour les paquets, ou pour spcifier comment les
   paquets doivent tre renvoys. Je ne l'ai cependant jamais utilise,
   mais si vous voulez crire sur ce sujet, contactez moi.

   Des choses comme le _stateful inspection_ (je prfre le terme
   "pare-feu dynamique") peuvent tre implmentes dans l'espace
   utilisateur en utilisant cette bibliothque. D'autres ides gniales
   peuvent tre le contrle des paquets sur une base "par utilisateur" en
   faisant une demande sur un dmon rsidant dans l'espace utilisateur.
   Ceci devrait tre relativement simple.

  SPF : Stateful Packet Filtering

   ftp://ftp.interlinx.bc.ca/pub/spf est le site du projet SPF de Brian
   Murrell, qui permet le suivi de connexion dans l'espace utilisateur.
   Ceci ajoute une dose significative de scurit pour les sites  faible
   bande passante.

   Il y a peu de documentation pour le moment, mais voici un message que
   Brian a envoy  la liste de diffusion en rpondant  quelques
   questions :


> Je prsume qu'il fait exactement ce que je veux~: installer une rgle de
> "retour" temporaire pour laisser entrer des paquets en rponse  une
> requte extrieure.

Yup, c'est exactement ce  quoi il sert. Plus il comprendra de protocoles,
plus il obtiendra de rgles de retour exactes. Pour l'instant il supporte
(de mmoire, excusez les erreurs ou les omissions) le FTP ( la fois actif et
passif, intrieur et extrieur), un peu de RealAudio, de traceroute, d'ICMP et
d'un ICQ basique (transmission des serveurs ICQ, connexions TCP directes, mais
hlas la seconde connexion directe TCP pour des trucs comme le transfert de
fichiers, etc., ne sont pas encore prsentes)

> S'agit-il d'un remplaant pour ipchains ou d'un ajout~?

C'est un ajout. Pensez  ipchains comme tant le moteur pour autoriser et
empcher les paquets de traverser une machine Linux. SPF est le pilote, grant
et surveillant constamment le traffic et disant  ipchains comment changer ses
polices pour reflter les changements dans les schmas du traffic.

  Modification des donnes ftp par Michael Hasenstein

   Michael Hasenstein de SuSE a cod un correctif pour le noyau qui
   ajoute le suivi des connexions ftp  ipchains. Celui-ci peut tre
   trouv sur http://www.csn.tu-chemnitz.de/~mha/patch.ftp-data-2.gz

5.9 Extensions futures

   Les codes de pare-feu et de NAT sont en cours de remise  jour pour le
   2.3. Les plans et les discussions sont disponibles sur l'archive de
   netdev, et sur la liste ipchains-dev. Ces extensions doivent nettoyer
   de nombreux problmes d'utilisation (rellement, la mise en place du
   pare-feu et le camouflage ne devrait pas tre _aussi dur_, et devrait
   autoriser une croissance pour un pare-feu beaucoup plus flexible).

6. Problmes classiques

6.1 ipchains -L est gel !

   Vous bloquez probablement les demandes DNS ; il finira probablement
   par stopper. Essayez d'utiliser l'option "-n" (numrique) d'ipchains,
   qui supprimera la recherche des noms.

6.2 Le camouflage/redirection ne fonctionne pas !

   Vrifiez si la redirection de paquets est active (dans les noyaux
   rcent, elle est dsactive par dfaut ce qui signifie que les paquets
   ne tentent jamais de traverser la chane "forward"). Vous pouvez
   changer ce dfaut (en tant que super-utilisateur) en tapant

# echo 1 > /proc/sys/net/ipv4/ip_forward
#

   Si ceci marche pour vous, vous pouvez le mettre quelque part dans vos
   scripts de lancement, de manire  ce que la redirection soit active
    chaque fois ; vous devrez toutefois configurer votre pare-feu avant
   le lancement de cette commande, autrement il peut y avoir passage de
   paquets.

6.3 -j REDIR ne marche pas !

   Vous devez autoriser la retransmission des paquets (voir plus haut)
   pour que celle-ci fonctionne ; sinon le code de routage supprime le
   paquet. Ainsi, si vous utilisez juste la redirection sans avoir de
   transmission, vous devez y faire attention.

   Notez que REDIR (dans la chane d'entre) n'affecte pas les connexions
   d'un processus local.

6.4 Les interfaces joker ne fonctionnent pas !

   Il y avait une erreur dans les versions 2.1.102 et 2.1.103 du noyau
   (et dans quelques anciens correctifs que j'avais sorti) qui faisait
   planter les commandes ipchains utilisant une interface joker (comme -i
   ppp+).

   Cette erreur a t corrige dans les noyaux rcents, et dans le
   correctif 2.0.34 du site web. Vous pouvez aussi le corriger  la main
   dans les sources du noyau en changeant la ligne 63 de
   include/linux/ip_fw.h :

#define IP_FW_F_MASK    0x002F  /* All possible flag bits mask   */

   Ceci doit en fait tre "0x003F". Corrigez et recompilez le noyau.

6.5 TOS ne fonctionne pas !

   C'est de ma faute : la configuration du champ Type of Service ne
   change pas le Type of Service dans les noyaux 2.1.102  2.1.111. Ce
   problme a t corrig dans le 2.1.112.

6.6 ipautofw et ipportfw ne fonctionnent pas !

   Pour les 2.0.x, c'est vrai ; je n'ai pas le temps de crer et de
   maintenir un correctif de taille gigantesque pour ipchains et
   ipautofw/ipportfw.

   Pour les 2.1.x, rcuprez ipmasqadm de Juan Ciarlante sur
<url url="http://juanjox.linuxhq.com/"
        name="http://juanjox.linuxhq.com/">

   et utilisez-le exactement de la manire dont vous auriez utilis
   ipautofw ou ipportfw,  part qu' la place de ipportfw vous devez
   taper ipmasqadm portfw, et  la place de ipautofw vous devez taper
   ipmasqadm autofw.

6.7 XosView ne marche pas !

   Mettez  jour  la version 1.6.0 ou suprieure, qui ne ncessite pas
   de rgle pare-feu pour les noyaux 2.1.x. Il semblerait tre  nouveau
   cass dans le 1.6.1 ; veuillez voir l'auteur (ce n'est pas de ma
   faute !).

6.8 Erreur de segmentation avec -j REDIRECT !

   C'tait une erreur dans ipchains version 1.3.3. Veuillez mettre 
   jour.

6.9 Je ne peux pas modifier les temps d'attente du camouflage !

   C'est vrai (pour les noyaux 2.1.x) jusqu'au et incluant le 2.1.112.
   Ceci est pour le moment vigoureusement traqu, et au moment o vous
   lirez ce document il se pourrait que ce soit rsolu. Ma page web
   contiendra un correctif lorsqu'il sera disponible.

6.10 Je veux firewaller IPX !

   Ainsi qu'un certain nombre d'autres personnes, il semble. Mon code
   couvre seulement IP, malheureusement. Du bon ct, tout est l pour
   pouvoir firewaller IPX ! Vous devrez juste crire le code ; je vous
   aiderai joyeusement l o ce sera possible.

7. Un exemple srieux

   Cet exemple est extrait du tutorial donn par Michael Neuling et
   moi-mme en mars 1999 lors du LinuxWorld ; ce n'est pas le seul moyen
   de rgler le problme donn, mais c'est probablement le plus simple.
   J'espre que vous le jugerez informatif.

7.1 L'arrangement

     * Un rseau interne camoufl (sous divers systmes d'exploitation),
       que nous appellerons "BON" ;
     * des serveurs exposs dans un rseau spar (nomm "ZDM" pour Zone
       Dmilitarise) ;
     * une connexion PPP  l'Internet (nomm "MAUVAIS").

   Rseau externe (MAUVAIS)
           |
           |
       ppp0|
    ---------------
    | 192.84.219.1|             Rseau des serveurs (ZDM)
    |             |eth0
    |             |----------------------------------------------
    |             |192.84.219.250 |             |              |
    |             |               |             |              |
    |192.168.1.250|               |             |              |
    ---------------          --------       -------        -------
           | eth1            | SMTP |       | DNS |        | WWW |
           |                 --------       -------        -------
           |              192.84.219.128  192.84.219.129  192.84.218.130
           |
   Rseau Interne (BON)

7.2 Buts

   Sur la machine filtrant les paquets :

   _PING tout rseau_
          Trs utile si la machine est hors-service.

   _TRACEROUTE tout rseau_
          Une fois de plus, utile pour les diagnostics.

   _Accs au DNS_
          Pour rendre ping et DNS plus utile.

    l'intrieur de la Zone Dmilitarise :

   Serveur mail
     * SMTP vers l'extrieur
     * Accepte le SMTP de l'intrieur et de l'extrieur
     * Accepte le POP3 de l'intrieur

   Serveur de nom
     * Envoi de requtes DNS vers l'extrieur
     * Accepte les requtes DNS de l'intrieur, l'extrieur, et du filtre
       de paquets

   Serveur web
     * Accepte les requtes HTTP de l'intrieur et de l'extrieur
     * Accs rsync de l'intrieur

   En interne :

   _Autorise WWW, ftp, traceroute et ssh vers l'extrieur_
          Ce sont des services standards  autoriser : on autorise
          parfois les machines internes  tout faire, mais ici nous
          serons plus restrictifs.

   _Autorise le SMTP vers le serveur mail_
          Bien entendu, nous voulons qu'il leur soit possible d'envoyer
          du courrier vers l'extrieur.

   _Autorise le POP3 vers le serveur mail_
          C'est ainsi qu'ils lisent leur courrier.

   _Autorise les requtes DNS vers le serveur de nom_
          Ils doivent pouvoir rechercher des noms externes pour le web,
          le ftp, traceroute ou ssh.

   _Autorise rsync vers le serveur web_
          C'est ainsi qu'ils synchronisent le serveur web externe avec
          l'interne.

   _Autorise les requtes WWW vers le serveur web_
          Bien entendu, nous voulons qu'ils puissent se connecteur au
          serveur web externe.

   _Autorise le ping vers le filtre de paquets_
          Il est courtois de l'autoriser ; ils peuvent ainsi tester si le
          pare-feu est coup (ainsi nous ne serons pas tenus responsables
          si un site extrieur est coup).

7.3 Avant le filtrage des paquets

     * Protection anti-spoofing
       Puisque nous n'avons pas de routage asymtrique, nous pouvons
       simplement mettre en marche l'anti-spoofing pour toutes les
       interfaces.

# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; done
#

     * Mettre en place des rgles de filtrage en interdiction (DENY)
       totale :
       Nous autorisons tout de mme le traffic local, mais nous
       interdisons tout le reste.

# ipchains -A input -i ! lo -j DENY
# ipchains -A output -i ! lo -j DENY
# ipchains -A forward -j DENY
#

     * Configurer les interfaces
       Ceci est gnralement ralis par les scripts de lancement. Fates
       bien attention  ce que les rgles ci-dessus soient insres avant
       que les interfaces ne soient configures, afin de prvenir le
       passage de paquets avant l'insertion des rgles.
     * Insertion des modules de camouflage par protocole
       Nous devons insrer le module de camouflage du FTP, ainsi le ftp
       passif et actif fonctionnera `uniquement' du rseau interne.

# insmod ip_masq_ftp
#

7.4 Filtrage de paquets pour les paquets traversants

   Avec le camouflage, il vaut mieux filtrer la chane de retransmission.

   Cassez la chane de retransmission en plusieurs chanes utilisateurs
   dpendant des interfaces sources/destination ; ceci ramne le problme
    des problmes plus grables.

ipchains -N bon-zdm
ipchains -N mauvais-zdm
ipchains -N bon-mauvais
ipchains -N zdm-bon
ipchains -N zdm-mauvais
ipchains -N mauvais-bon

   ACCEPTer les codes standards d'erreur ICMP est un fait classique, nous
   lui crons donc une chane.

ipchains -N icmp-acc

  Configurer les sauts de la chane de transmission

   Malheureusement, nous connaissons seulement (dans la chane de
   transmission) quelle est l'interface externe. Ainsi, pour se
   reprsenter de quelle interface vient le paquet, nous utilisons
   l'adresse source (l'anti-spoofing vite les problmes lis aux
   adresses).

   Notez que nous enregistrons tout ce qui ne vrifie aucune de ces
   rgles (cependant, ceci ne devrait jamais arriver).

ipchains -A forward -s 192.168.1.0/24 -i eth0 -j bon-zdm
ipchains -A forward -s 192.168.1.0/24 -i ppp0 -j bon-mauvais
ipchains -A forward -s 192.84.219.0/24 -i ppp0 -j zdm-mauvais
ipchains -A forward -s 192.84.219.0/24 -i eth1 -j zdm-bon
ipchains -A forward -i eth0 -j mauvais-zdm
ipchains -A forward -i eth1 -j mauvais-bon
ipchains -A forward -j DENY -l

  Dfinir la chane icmp-acc

   Les paquets correspondant  l'une des erreurs ICMP sont accepts,
   sinon le contrle les rendra  la chane appellante.

ipchains -A icmp-acc -p icmp --icmp-type destination-unreachable -j ACCEPT
ipchains -A icmp-acc -p icmp --icmp-type source-quench -j ACCEPT
ipchains -A icmp-acc -p icmp --icmp-type time-exceeded -j ACCEPT
ipchains -A icmp-acc -p icmp --icmp-type parameter-problem -j ACCEPT

  Bon (interne) vers ZDM (serveurs)

   Restrictions internes :
     * Autorise WWW, ftp, traceroute, ssh vers l'extrieur
     * _Autorise le SMTP vers le serveur mail_
     * _Autorise le POP3 vers le serveur mail_
     * _Autorise les requtes DNS vers le serveur de nom_
     * _Autorise le rsync vers le serveur web_
     * _Autorise le WWW vers le serveur web_
     * Autorise le ping vers le filtre de paquets

   On pourrait utiliser le camouflage du rseau interne vers la ZDM, mais
   ici nous ne le ferons pas. Puisque personne du rseau interne ne
   devrait tenter de choses dmoniaques, nous enregistrons les paquets
   qui sont interdits.

ipchains -A bon-zdm -p tcp -d 192.84.219.128 smtp -j ACCEPT
ipchains -A bon-zdm -p tcp -d 192.84.219.128 pop-3 -j ACCEPT
ipchains -A bon-zdm -p udp -d 192.84.219.129 domain -j ACCEPT
ipchains -A bon-zdm -p tcp -d 192.84.219.129 domain -j ACCEPT
ipchains -A bon-zdm -p tcp -d 192.84.218.130 www -j ACCEPT
ipchains -A bon-zdm -p tcp -d 192.84.218.130 rsync -j ACCEPT
ipchains -A bon-zdm -p icmp -j icmp-acc
ipchains -A bon-zdm -j DENY -l

  Mauvais (extrieur) vers ZDM (serveurs)

     * Restrictions de la ZDM :
          + Serveur mail :
               o _SMTP vers l'extrieur_
               o _Accepte le SMTP venant_ de l'intrieur et _extrieur_
               o Accepte le POP3 de l'intrieur
          + Serveur de noms :
               o _Envoi de requtes DNS vers l'extrieur_
               o _Accepte le DNS venant_ de l'intrieur, _extrieur_ et
                 du filtre de paquets
          + Serveur web :
               o _Accepte les requtes HTTP venant de_ l'intrieur et de
                 _l'extrieur_
               o Accs rsync de l'intrieur
     * Les trucs  autoriser du rseau extrieur vers la ZDM
          + N'enregistre pas les violations, elles peuvent arriver.

ipchains -A mauvais-zdm -p tcp -d 192.84.219.128 smtp -j ACCEPT
ipchains -A mauvais-zdm -p udp -d 192.84.219.129 domain -j ACCEPT
ipchains -A mauvais-zdm -p tcp -d 192.84.219.129 domain -j ACCEPT
ipchains -A mauvais-zdm -p tcp -d 192.84.218.130 www -j ACCEPT
ipchains -A mauvais-zdm -p icmp -j icmp-acc
ipchains -A mauvais-zdm -j DENY

  Bon (intrieur) vers Mauvais (extrieur).

     * Restrictions internes :
          + _Autorise le WWW, ftp, traceroute, ssh vers l'extrieur_
          + Autorise SMTP vers le serveur mail
          + Autorise POP-3 vers le serveur mail
          + Autorise DNS vers le serveur de nom
          + Autorise rsync vers le serveur web
          + Autorise WWW vers le serveur web
          + Autorise ping vers le filtre de paquets
     * Un grand nombre de gens autorisent tout venant de l'intrieur vers
       les rseaux extrieurs, puis ajoutent des restrictions. Nous
       sommes fascistes.
          + Enregistre les violations.
          + Le ftp passif est gr par le module de camouflage.

ipchains -A bon-mauvais -p tcp --dport www -j MASQ
ipchains -A bon-mauvais -p tcp --dport ssh -j MASQ
ipchains -A bon-mauvais -p udp --dport 33434:33500 -j MASQ
ipchains -A bon-mauvais -p tcp --dport ftp --j MASQ
ipchains -A bon-mauvais -p icmp --icmp-type ping -j MASQ
ipchains -A bon-mauvais -j REJECT -l

  ZDM vers Bon (intrieur)

     * Restrictions internes :
          + Autorise WWW, ftp, traceroute, ssh vers l'extrieur
          + _Autorise SMTP vers le serveur mail_
          + _Autorise POP3 vers le serveur mail_
          + _Autorise DNS vers le serveur de noms_
          + _Autorise rsync vers le serveur web_
          + _Autorise WWW vers le serveur web_
          + Autorise ping vers le filtre de paquets
     * Si nous camouflions le rseau intrieur de la ZDM, nous
       refuserions simplement les paquets venant d'un autre moyen. Tel
       quel, il autorise uniquement les paquets qui peuvent provenir
       d'une connexion pr-tablie.

ipchains -A zdm-bon -p tcp ! -y -s 192.84.219.128 smtp -j ACCEPT
ipchains -A zdm-bon -p udp -s 192.84.219.129 domain -j ACCEPT
ipchains -A zdm-bon -p tcp ! -y -s 192.84.219.129 domain -j ACCEPT
ipchains -A zdm-bon -p tcp ! -y -s 192.84.218.130 www -j ACCEPT
ipchains -A zdm-bon -p tcp ! -y -s 192.84.218.130 rsync -j ACCEPT
ipchains -A zdm-bon -p icmp -j icmp-acc
ipchains -A zdm-mauvais -j DENY -l

  ZDM vers Mauvais (extrieur)

     * Restrictions de la ZDM :
          + Serveur mail
               o _SMTP vers l'extrieur_
               o _Accepte SMTP venant de_ l'intrieur et de _l'extrieur_
               o Accepte POP3 venant de l'intrieur
          + Serveur de noms
               o _Envoi de requtes DNS vers l'extrieur_
               o _Accepte le DNS de_ l'intrieur, _l'extrieur_ et du
                 filtre de paquets
          + Serveur web
               o _Accepte HTTP venant de_ l'intrieur et de _l'extrieur_
               o Accs rsync de l'intrieur
     *

ipchains -A zdm-mauvais -p tcp -s 192.84.219.128 smtp -j ACCEPT
ipchains -A zdm-mauvais -p udp -s 192.84.219.129 domain -j ACCEPT
ipchains -A zdm-mauvais -p tcp -s 192.84.219.129 domain -j ACCEPT
ipchains -A zdm-mauvais -p tcp ! -y -s 192.84.218.130 www -j ACCEPT
ipchains -A zdm-mauvais -p icmp -j icmp-acc
ipchains -A zdm-mauvais -j DENY -l

  Mauvais (extrieur) vers Bon (intrieur)

     * Nous n'autorisons rien (de non camoufl)  passer du rseau
       extrieur vers le rseau intrieur.

ipchains -A mauvais-bon -j REJECT

  Filtrage de paquets pour la machine Linux elle-mme

     * Si nous dsirons utiliser le filtrage de paquets sur les paquets
       arrivant sur la machine elle-mme, nous devons filtrer la chane
       d'entre. Nous crons une chane pour chaque interface de
       destination :

ipchains -N mauvais-if
ipchains -N zdm-if
ipchains -N bon-if

     * Crons les sauts vers elles :

ipchains -A input -d 192.84.219.1 -j mauvais-if
ipchains -A input -d 192.84.219.250 -j zdm-if
ipchains -A input -d 192.168.1.250 -j bon-if

  Interface Mauvais (extrieur)

     * Machine de filtrage des paquets :
          + _PING tous les rseaux_
          + _TRACEROUTE tous les rseaux_
          + Accs DNS
     * L'interface extrieure reoit aussi des rponses aux paquets
       camoufls, les erreurs ICMP leur correspondant et les rponses
       PING.

ipchains -A mauvais-if -i ! ppp0 -j DENY -l
ipchains -A mauvais-if -p TCP --dport 61000:65096 -j ACCEPT
ipchains -A mauvais-if -p UDP --dport 61000:65096 -j ACCEPT
ipchains -A mauvais-if -p ICMP --icmp-type pong -j ACCEPT
ipchains -A mauvais-if -j icmp-acc
ipchains -A mauvais-if -j DENY

  Interface ZDM

     * Restrictions du filtre de paquets :
          + _PING tous les rseaux_
          + _TRACEROUTE tous les rseaux_
          + _Accs DNS_
     * L'interface ZDM reoit les rponses DNS, ping et les erreurs ICMP

ipchains -A zdm-if -i ! eth0 -j DENY
ipchains -A zdm-if -p TCP ! -y -s 192.84.219.129 53 -j ACCEPT
ipchains -A zdm-if -p UDP -s 192.84.219.129 53 -j ACCEPT
ipchains -A zdm-if -p ICMP --icmp-type pong -j ACCEPT
ipchains -A zdm-if -j icmp-acc
ipchains -A zdm-if -j DENY -l

  Interface Bon (intrieur)

     * Restrictions du filtre de paquets
          + _PING tous les rseaux_
          + _TRACEROUTE tous les rseaux_
          + _Accs DNS_
     * Restrictions intrieures :
          + Autorise WWW, ftp, traceroute, ssh vers l'extrieur
          + Autorise SMTP vers le serveur mail
          + Autorise POP3 vers le serveur mail
          + Autorise DNS vers le serveur de noms
          + Autorise rsync vers le serveur web
          + Autorise WWW vers le serveur web
          + _Autorise ping vers le filtre de paquets_
     * L'interface intrieure reoit les pings, les rponses ping et les
       erreurs ICMP.

ipchains -A bon-if -i ! eth1 -j DENY
ipchains -A bon-if -p ICMP --icmp-type ping -j ACCEPT
ipchains -A bon-if -p ICMP --icmp-type pong -j ACCEPT
ipchains -A bon-if -j icmp-acc
ipchains -A bon-if -j DENY -l

7.5 Finalement

     * Supprime les rgles de bloquage :

ipchains -D input 1
ipchains -D forward 1
ipchains -D output 1

8. Annexe : diffrences entre ipchains et ipfwadm

   Quelques-uns de ces changements sont le rsultat de changements du
   noyau, et quelques autres sont un rsultat des diffrences entre
   ipchains et ipfwadm.

    1. De nombreux arguments ont t modifis : les majuscules indiquent
       dornavant une commande, et les minuscules indiquent une option.
    2. Les chanes arbitraires sont supportes, ainsi mme les chanes
       intgres ont des noms complets plutt que des options (cd,
       "input"  la place de "-I").
    3. L'option "-k" a saut : utilisez "! -y".
    4. L'option "-b" insre/ajoute/supprime actuellement deux rgles,
       plutt qu'une rgle "bidirectionnelle" simple.
    5. L'option "-b" peut tre passe  "-C" pour effectuer deux
       vrifications (une dans chaque direction).
    6. L'option "-x" de "-l" a t remplace par "-v".
    7. Les ports sources et destinations multiples ne sont plus
       supports. Heureusement, la possibilit d'employer un intervalle
       de port aura le mme effet.
    8. Les interfaces peuvent seulement tre spcifies par leur nom (pas
       par leurs adresses). L'ancienne smantique a t silencieusement
       change dans la srie des noyaux 2.1, de toute manire.
    9. Les fragments sont examins, mais pas automatiquement autoriss.
   10. On s'est dbarrass des chanes de comptage explicites.
   11. On peut crire des rgles qui porteront uniquement sur certains
       protocoles IP.
   12. L'ancien comportement de vrification de SYN et ACK (qui tait
       auparavant ignor pour les paquets non TCP) a chang ; l'option
       SYN n'est plus valide pour les rgles non spcifiques au TCP.
   13. Les compteurs sont maintenant de 64 bits sur les machines 32 bits,
       et non plus 32 bits.
   14. L'inversion des options est dornavant supporte.
   15. Les codes ICMP sont maintenant supports.
   16. Les interfaces joker sont maintenant supportes.
   17. Les manipulations de TOS sont maintenant vrifies : l'ancien code
       du noyau les stoppait silencieusement pour vous en manipulant
       (illgalement) le bit TOS "Must Be Zero" ; ipchains retourne
       maintenant une erreur si vous essayez, de mme que pour d'autres
       cas illgaux.

8.1 Guide de rfrence rapide

   [ Dans l'ensemble, les arguments des commandes sont en MAJUSCULES, et
   les options des arguments sont en minuscules ]

   Une chose  noter, le camouflage est spcifi par "-j MASQ" ; ceci est
   compltement diffrent de "-j ACCEPT", et n'est pas trait comme un
   effet de bord, au contraire d'ipfwadm.

===========================================================================
| ipfwadm      | ipchains              | Notes
---------------------------------------------------------------------------
| -A [both]    | -N acct               | Cre une chane "acct"
|              |& -I 1 input -j acct   | ayant des paquets entrants et
|              |& -I 1 output -j acct  | sortants qui la traversent.
|              |& acct                 |
---------------------------------------------------------------------------
| -A in        | input                 | Une rgle sans destination
---------------------------------------------------------------------------
| -A out       | output                | Une rgle sans destination
---------------------------------------------------------------------------
| -F           | forward               | Utilise a comme [chane].
---------------------------------------------------------------------------
| -I           | input                 | Utilise a comme [chane].
---------------------------------------------------------------------------
| -O           | output                | Utilise a comme [chane].
---------------------------------------------------------------------------
| -M -l        | -M -L                 |
---------------------------------------------------------------------------
| -M -s        | -M -S                 |
---------------------------------------------------------------------------
| -a policy    | -A [chain] -j POLICY  | (voir -r et -m).
---------------------------------------------------------------------------
| -d policy    | -D [chain] -j POLICY  | (voir -r et -m).
---------------------------------------------------------------------------
| -i policy    | -I 1 [chain] -j POLICY| (voir -r et -m).
---------------------------------------------------------------------------
| -l           | -L                    |
---------------------------------------------------------------------------
| -z           | -Z                    |
---------------------------------------------------------------------------
| -f           | -F                    |
---------------------------------------------------------------------------
| -p           | -P                    |
---------------------------------------------------------------------------
| -c           | -C                    |
---------------------------------------------------------------------------
| -P           | -p                    |
---------------------------------------------------------------------------
| -S           | -s                    | Prend seulement un port ou un
|              |                       | intervalle, pas de multiples.
---------------------------------------------------------------------------
| -D           | -d                    | Prend seulement un port ou un
|              |                       | intervalle, pas de multiples.
---------------------------------------------------------------------------
| -V           | <none>                | Utilise -i [nom].
---------------------------------------------------------------------------
| -W           | -i                    |
---------------------------------------------------------------------------
| -b           | -b                    | Dornavant cre deux rgles.
---------------------------------------------------------------------------
| -e           | -v                    |
---------------------------------------------------------------------------
| -k           | ! -y                  | Ne fonctionne pas  moins que
|              |                       | -p tcp ne soit galement spcifi.
---------------------------------------------------------------------------
| -m           | -j MASQ               |
---------------------------------------------------------------------------
| -n           | -n                    |
---------------------------------------------------------------------------
| -o           | -l                    |
---------------------------------------------------------------------------
| -r [redirpt] | -j REDIRECT [redirpt] |
---------------------------------------------------------------------------
| -t           | -t                    |
---------------------------------------------------------------------------
| -v           | -v                    |
---------------------------------------------------------------------------
| -x           | -x                    |
---------------------------------------------------------------------------
| -y           | -y                    | Ne fonctionne pas  moins que
|              |                       | -p tcp ne soit galement spcifi.
---------------------------------------------------------------------------

8.2 Exemples de commandes ipfwadm traduites

   Ancienne commande : ipfwadm -F -p deny

   Nouvelle commande : ipchains -P forward DENY

   Ancienne commande : ipfwadm -F -a m -S 192.168.0.0/24 -D 0.0.0.0/0

   Nouvelle commande : ipchains -A forward -j MASQ -s 192.168.0.0/24 -d
   0.0.0.0/0

   Ancienne commande : ipfwadm -I -a accept -V 10.1.2.1 -S 10.0.0.0/8 -D
   0.0.0.0/0

   Nouvelle commande : ipchains -A input -j ACCEPT -i eth0 -s 10.0.0.0/8
   -d 0.0.0.0/0

   (Notez qu'il n'y a pas d'quivalent pour la spcification des
   interfaces par leur adresse : utilisez le nom de l'interface. Sur
   cette machine, 10.1.2.1 correspond  eth0).

9. Annexe : utiliser le script ipfwadm-wrapper

   Le script shell ipfwadm-wrapper doit tre un remplacement d'ipfwadm
   pour la compatibilit descendante avec ipfwadm 2.3a.

   La seule option qu'il ne peut vraiment pas supporter est l'option
   "-V". Lorsqu'elle est utilise, un avertissement est affich. Si
   l'option "-W" est galement utilise, l'option "-V" est ignore.
   Autrement, le script essaye de trouver le nom de l'interface associe
    cette adresse, en utilisant ifconfig. Si a ne marche pas (comme
   pour une interface dsactive), alors il sortira avec un message
   d'erreur.

   Cet avertissement peut tre supprim soit en changeant le "-V" pour un
   "-W", ou en dirigeant la sortie standard du script vers /dev/null.

   Si vous trouvez des erreurs dans ce script, ou une modification entre
   les effets du vrai ipfwadm et de ce script, _veuillez_ me rapporter le
   problme : envoyez un courrier  ipchains@rustcorp.com avec le sujet
   "BUG-REPORT". Veuillez lister la version d'ipfwadm (ipfwadm -h), votre
   version d'ipchains (ipchains --version), la version du script
   d'emballage (ipfwadm-wrapper --version). Envoyez moi galement la
   sortie de ipchains-save. Merci d'avance.

   Le mlange d'ipchains avec le script ipfwadm-wrapper se fait  votre
   propre pril.

10. Annexe : remerciements

   Un grand merci  Michael Neuling, qui a crit la pr-version du code
   d'IP chains en travaillant pour moi. Des excuses publiques pour avoir
   rejet son ide de cache des rsultats, qu'Alan Cox a propos plus
   tard et que j'ai finalement commenc  implmenter, ayant vu l'erreur
   de mon ct.

   Merci  Alan Cox pour son support technique par email 24h/24, et pour
   ses encouragements.

   Merci  tous les auteurs du code d'ipfw et d'ipfwadm, spcialement Jos
   Vos. Rester aux chevilles des gants et tout a... Ceci s'applique
   galement  Linux Torvalds et  tous les bricoleurs du noyau et de
   l'espace utilisateur.

   Merci aux beta testeurs, chasseurs d'erreurs diligents, surtout Jordan
   Mendelson, Shaw Carruthers, Kevin Moule, Dr. Liviu Daia, Helmut Adams,
   Franck Sicard, Kevin Littlejohn, Matt Kemner, John D. Hardin, Alexey
   Kuznetsov, Leos Bitto, Jim Kunzman, Gerard Gerritsen, Serge Sivkov,
   Andrew Burgess, Steve Schmidtke, Richard Offer, Bernhard Weisshuhn,
   Larry Auton, Ambrose Li, Pavel Krauz, Steve Chadsey, Francesco
   Potorti` et Alain Knaff.
