  Linux IPCHAINS-HOWTO
  Paul Russell, ipchains@rustcorp.com
  Version franaise par Arnaud Launay, zoro@multimania.com
  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.
  ______________________________________________________________________

  Table des matires























































  1. Introduction

     1.1 Qu'est ce que c'est ?
     1.2 Pourquoi ?
     1.3 Comment ?
     1.4 O ?

  2. Bases du filtrage de paquets

     2.1 Qu'est ce que c'est ?
     2.2 Pourquoi ?
     2.3 Comment ?
        2.3.1 Un noyau avec le filtrage de paquets
        2.3.2 ipchains
        2.3.3 Rendre les rgles permanentes

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

     3.1 Le guide du camouflage en 3 lignes par Rusty
     3.2 Publicit gratuite : le zle de WatchGuard
     3.3 Configurations classiques de type pare-feu
        3.3.1 Rseaux privs : caches traditionnels
        3.3.2 Rseaux privs : caches transparents
        3.3.3 Rseaux privs : camouflage
        3.3.4 Rseaux publics
        3.3.5 Services internes limits
     3.4 Pour plus d'informations sur le camouflage

  4. Chanes de protection IP

     4.1 Comment les paquets traversent les filtres
        4.1.1 Utiliser ipchains
        4.1.2 Oprations sur une rgle simple
        4.1.3 Spcifications du filtrage
           4.1.3.1 Spcifier les adresses IP source et destination
           4.1.3.2 Spcifier l'inversion
           4.1.3.3 Spcifier le protocole
              4.1.3.3.1 Spcifier les ports UDP et TCP
              4.1.3.3.2 Spcifier les types et codes ICMP
           4.1.3.4 Spcifier une interface
           4.1.3.5 Spcifier uniquement des paquets TCP SYN
           4.1.3.6 Utiliser les fragments
        4.1.4 Effets de bord du filtrage
           4.1.4.1 Spcifier une destination
           4.1.4.2 Enregistrement des paquets
           4.1.4.3 Manipuler le type de service
           4.1.4.4 Marquage d'un paquet
           4.1.4.5 Oprations sur une chane entire
           4.1.4.6 Crer une nouvelle chane
           4.1.4.7 Supprimer une chane
           4.1.4.8 Vider une chane
           4.1.4.9 Afficher une chane
           4.1.4.10 Remise  zro des compteurs
           4.1.4.11 Choisir une police
        4.1.5 Oprations sur le camouflage
        4.1.6 Vrifier un paquet
        4.1.7 Voir ce qui arrive avec des rgles multiples prcises en une seule fois
     4.2 Exemples utiles
        4.2.1 Utiliser ipchains-save
        4.2.2 Utiliser ipchains-restore

  5. Divers

     5.1 Comment organiser vos rgles pare-feu
     5.2 Ce qu'il ne faut pas filtrer
        5.2.1 Les paquets ICMP
        5.2.2 Connexions TCP au DNS (serveur de nom)
        5.2.3 Cauchemars du FTP
     5.3 Filtrer le ping de la mort (Ping of Death)
     5.4 Filtrer teardrop et bonk
     5.5 Filtrer les bombes  fragments
     5.6 Changer les rgles pare-feu
     5.7 Comment mettre en place la protection contre l'IP spoof ?
     5.8 Projets avancs
        5.8.1 SPF : Stateful Packet Filtering
        5.8.2 Modification des donnes ftp par Michael Hasenstein
     5.9 Extensions futures

  6. Problmes classiques

     6.1 ipchains -L est gel !
     6.2 Le camouflage/redirection ne fonctionne pas !
     6.3 -j REDIR ne marche pas !
     6.4 Les interfaces joker ne fonctionnent pas !
     6.5 TOS ne fonctionne pas !
     6.6 ipautofw et ipportfw ne fonctionnent pas !
     6.7 XosView ne marche pas !
     6.8 Erreur de segmentation avec -j REDIRECT !
     6.9 Je ne peux pas modifier les temps d'attente du camouflage !
     6.10 Je veux firewaller IPX !

  7. Un exemple srieux

     7.1 L'arrangement
     7.2 Buts
     7.3 Avant le filtrage des paquets
     7.4 Filtrage de paquets pour les paquets traversants
        7.4.1 Configurer les sauts de la chane de transmission
        7.4.2 Dfinir la chane icmp-acc
        7.4.3 Bon (interne) vers ZDM (serveurs)
        7.4.4 Mauvais (extrieur) vers ZDM (serveurs)
        7.4.5 Bon (intrieur) vers Mauvais (extrieur).
        7.4.6 ZDM vers Bon (intrieur)
        7.4.7 ZDM vers Mauvais (extrieur)
        7.4.8 Mauvais (extrieur) vers Bon (intrieur)
        7.4.9 Filtrage de paquets pour la machine Linux elle-mme
           7.4.9.1 Interface Mauvais (extrieur)
           7.4.9.2 Interface ZDM
           7.4.9.3 Interface Bon (intrieur)
     7.5 Finalement

  8. Annexe : diffrences entre ipchains et ipfwadm

     8.1 Guide de rfrence rapide
     8.2 Exemples de commandes ipfwadm traduites

  9. Annexe : utiliser le script ipfwadm-wrapper

  10. Annexe : remerciements



  ______________________________________________________________________

  11..  IInnttrroodduuccttiioonn

  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..11..  QQuu''eesstt ccee qquuee cc''eesstt ??

  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1..22..  PPoouurrqquuooii ??

  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1..33..  CCoommmmeenntt ??

  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1..44..  OO ??

  La page officielle est la Page des chanes de filtrage IP de Linux
  <http://www.rustcorp.com/linux/ipchains>.


  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2..  BBaasseess dduu ffiillttrraaggee ddee ppaaqquueettss

  22..11..  QQuu''eesstt ccee qquuee cc''eesstt ??

  Tout le trafic circulant dans un rseau est envoy sous la forme de
  ppaaqquueettss. 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'eennttttee. Le reste du paquet, contenant les
  donnes  transmettre, est couramment appel le ccoorrppss.


  Quelques protocoles, comme le TTCCPP, 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'_e_n_t__t_e des paquets
  lorsque ceux-ci passent, et dcide du destin du paquet entier. Il peut
  dcider de le rreeffuusseerr (le supprimer comme s'il n'avait jamais t
  reu), de l'aacccceepptteerr (le laisser circuler) ou de le rreejjeetteerr (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..22..  PPoouurrqquuooii ??

  Contrle. Scurit. Vigilance.



     CCoonnttrrllee ::
        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).


     SSccuurriitt ::
        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.

     VViiggiillaannccee ::
        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2..33..  CCoommmmeenntt ??

  22..33..11..  UUnn nnooyyaauu aavveecc llee ffiillttrraaggee ddee ppaaqquueettss

  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 _n_o_y_a_u_x
  _d_e _s__r_i_e _2_._0 sont :


  ______________________________________________________________________
          CONFIG_EXPERIMENTAL=y
          CONFIG_FIREWALL=y
          CONFIG_IP_FIREWALL=y
          CONFIG_IP_FIREWALL_CHAINS=y
  ______________________________________________________________________



  Pour les sries de _n_o_y_a_u_x _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.


  22..33..22..  iippcchhaaiinnss

  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
  <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.


  22..33..33..  RReennddrree lleess rrgglleess ppeerrmmaanneenntteess

  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3..  JJee ssuuiiss ttrroouubbll !! RRoouuttaaggee,, ccaammoouuffllaaggee,, rreeddiirreeccttiioonn ddee ppoorrttss,,
  iippaauuttooffww......

  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3..11..  LLee gguuiiddee dduu ccaammoouuffllaaggee eenn 33 lliiggnneess ppaarr RRuussttyy

  Ces lignes prsument que votre interface eexxtteerrnnee 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3..22..  PPuubblliicciitt ggrraattuuiittee :: llee zzllee ddee WWaattcchhGGuuaarrdd

  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 <http://www.watchguard.com>



  33..33..  CCoonnffiigguurraattiioonnss ccllaassssiiqquueess ddee ttyyppee ppaarree--ffeeuu

  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.


  33..33..11..  RRsseeaauuxx pprriivvss :: ccaacchheess ttrraaddiittiioonnnneellss

  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.


  33..33..22..  RRsseeaauuxx pprriivvss :: ccaacchheess ttrraannssppaarreennttss

  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.


  33..33..33..  RRsseeaauuxx pprriivvss :: ccaammoouuffllaaggee

  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.


  33..33..44..  RRsseeaauuxx ppuubblliiccss

  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.


  33..33..55..  SSeerrvviicceess iinntteerrnneess lliimmiittss

  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3..44..  PPoouurr pplluuss dd''iinnffoorrmmaattiioonnss ssuurr llee ccaammoouuffllaaggee

  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
  <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
  <http://www.metalab.unc.edu/LDP>.


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


  44..  CChhaanneess ddee pprrootteeccttiioonn IIPP

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


  44..11..  CCoommmmeenntt lleess ppaaqquueettss ttrraavveerrsseenntt lleess ffiillttrreess

  Le noyau commence avec trois listes de rgles : ces listes sont
  appelles cchhaanneess ddee pprrootteeccttiioonn ou juste cchhaanneess. Ces trois chanes
  sont appelles iinnppuutt (entre), oouuttppuutt (sortie) et ffoorrwwaarrdd
  (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 rroouuttaaggee). 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 rrgglleess. 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 ppoolliiccee 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 :


     SSoommmmee ((cchheecckkssuumm)) ::
        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.


     VVaalliiddiitt ((ssaanniittyy)) ::
        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).


     CChhaannee dd''eennttrree ((iinnppuutt cchhaaiinn)) ::
        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.


     DDeemmaassqquueerraaddee ::
        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.


     DDcciissiioonn rroouuttaaggee ((RRoouuttiinngg ddeecciissiioonn)) ::
        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).


     PPrroocceessssuuss llooccaall ((LLooccaall pprroocceessss)) ::
        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).


     IInntteerrffaaccee lloo ::
        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.


     llooccaall ::
        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.


     ffoorrwwaarrdd cchhaaiinn ::
        Cette chane est traverse par tout paquet qui tente de passer
        par cette machine vers une autre.


     oouuttppuutt cchhaaiinn ::
        Cette chane est traverse par tous les paquets juste avant
        qu'ils ne soient envoys  l'extrieur.


  44..11..11..  UUttiilliisseerr iippcchhaaiinnss

  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.


  44..11..22..  OOpprraattiioonnss ssuurr uunnee rrggllee ssiimmppllee

  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 com
  mande -A (ou -I ou -R). S'il y a des rgles multiples identiques dans
  la mme chane, seule la premire sera supprime.


  44..11..33..  SSppcciiffiiccaattiioonnss dduu ffiillttrraaggee

  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.


  44..11..33..11..  SSppcciiffiieerr lleess aaddrreesssseess IIPP ssoouurrccee eett ddeessttiinnaattiioonn

  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".


  44..11..33..22..  SSppcciiffiieerr ll''iinnvveerrssiioonn

  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.


  44..11..33..33..  SSppcciiffiieerr llee pprroottooccoollee

  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".


  44..11..33..33..11..  SSppcciiffiieerr lleess ppoorrttss UUDDPP eett TTCCPP

  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




  44..11..33..33..22..  SSppcciiffiieerr lleess ttyyppeess eett ccooddeess IICCMMPP

  ICMP permet aussi un argument optionnel, mais comme l'ICMP ne dispose
  pas de ports (ICMP a un ttyyppee et un ccooddee), 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).


  44..11..33..44..  SSppcciiffiieerr uunnee iinntteerrffaaccee

  L'option "-i" spcifie le nom d'une iinntteerrffaaccee  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).


  44..11..33..55..  SSppcciiffiieerr uunniiqquueemmeenntt ddeess ppaaqquueettss TTCCPP SSYYNN

  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 SSYYNN (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.


  44..11..33..66..  UUttiilliisseerr lleess ffrraaggmmeennttss

  Parfois, un paquet est trop large pour rentrer dans le cble en une
  seule fois. Lorsque ceci arrive, le paquet est divis en ffrraaggmmeennttss, 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 _r_i_e_n.
  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 _p_a_s
  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
       #





  44..11..44..  EEffffeettss ddee bboorrdd dduu ffiillttrraaggee

  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.


  44..11..44..11..  SSppcciiffiieerr uunnee ddeessttiinnaattiioonn

  Une ddeessttiinnaattiioonn 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.


  44..11..44..22..  EEnnrreeggiissttrreemmeenntt ddeess ppaaqquueettss

  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'.


  44..11..44..33..  MMaanniippuulleerr llee ttyyppee ddee sseerrvviiccee

  Il y a quatre bits utiliss par eux-mmes dans l'entte IP, appels
  les bits de TTyyppee ooff SSeerrvviiccee (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 rou
       teur 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 accept
       ables 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 config
       urer 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 tou
       jours gagner mme sans changer le TOS, c'est juste que le
       changement du TOS aide  gagner les bnfices sur les pro
       grammes non coopratifs (mais tous les programmes Linux
       standards sont coopratifs).



  44..11..44..44..  MMaarrqquuaaggee dd''uunn ppaaqquueett

  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.


  44..11..44..55..  OOpprraattiioonnss ssuurr uunnee cchhaannee eennttiirree

  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.


  44..11..44..66..  CCrreerr uunnee nnoouuvveellllee cchhaannee

  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.


  44..11..44..77..  SSuupppprriimmeerr uunnee cchhaannee

  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.


  44..11..44..88..  VViiddeerr uunnee cchhaannee

  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 _t_o_u_t_e_s les chanes seront
  vides.




  44..11..44..99..  AAffffiicchheerr uunnee cchhaannee

  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  ports
          10   840 ACCEPT icmp ----- 0xFF 0x00 lo            anywhere  anywhere     any





  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.


  44..11..44..1100..  RReemmiissee  zzrroo ddeess ccoommpptteeuurrss

  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  ports
          10   840 ACCEPT icmp ----- 0xFF 0x00 lo            anywhere  anywhere     any
       # 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" _e_n_s_e_m_b_l_e, 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
       #





  44..11..44..1111..  CChhooiissiirr uunnee ppoolliiccee

  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 ppoolliiccee 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.


  44..11..55..  OOpprraattiioonnss ssuurr llee ccaammoouuffllaaggee

  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 !''.


  44..11..66..  VVrriiffiieerr uunn ppaaqquueett

  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
       #





  44..11..77..  VVooiirr ccee qquuii aarrrriivvee aavveecc ddeess rrgglleess mmuullttiipplleess pprrcciisseess eenn uunnee
  sseeuullee ffooiiss

  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4..22..  EExxeemmpplleess uuttiilleess

  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 ACCEPT
       # 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.


  44..22..11..  UUttiilliisseerr iippcchhaaiinnss--ssaavvee

  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'.
  #





  44..22..22..  UUttiilliisseerr iippcchhaaiinnss--rreessttoorree

  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5..  DDiivveerrss

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


  55..11..  CCoommmmeenntt oorrggaanniisseerr vvooss rrgglleess ppaarree--ffeeuu

  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5..22..  CCee qquu''iill nnee ffaauutt ppaass ffiillttrreerr

  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.


  55..22..11..  LLeess ppaaqquueettss IICCMMPP

  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.





  55..22..22..  CCoonnnneexxiioonnss TTCCPP aauu DDNNSS ((sseerrvveeuurr ddee nnoomm))

  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.


  55..22..33..  CCaauucchheemmaarrss dduu FFTTPP

  L'autre problme classique du filtrage de paquets est celui pos par
  le FTP.  Le FTP a deux mmooddeess ; le mode traditionnel est appel mmooddee
  aaccttiiff et le plus rcent est appel mmooddee ppaassssiiff. 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5..33..  FFiillttrreerr llee ppiinngg ddee llaa mmoorrtt ((PPiinngg ooff DDeeaatthh))

  Les machines Linux sont maintenant immunises du fameux PPiinngg ooff DDeeaatthh,
  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5..44..  FFiillttrreerr tteeaarrddrroopp eett bboonnkk

  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..55..  FFiillttrreerr lleess bboommbbeess  ffrraaggmmeennttss

  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5..66..  CChhaannggeerr lleess rrgglleess ppaarree--ffeeuu

  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5..77..  CCoommmmeenntt mmeettttrree eenn ppllaaccee llaa pprrootteeccttiioonn ccoonnttrree ll''IIPP ssppooooff ??

  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5..88..  PPrroojjeettss aavvaannccss

  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 ssttaatteeffuull iinnssppeeccttiioonn (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.


  55..88..11..  SSPPFF :: SSttaatteeffuull PPaacckkeett FFiilltteerriinngg

  ftp://ftp.interlinx.bc.ca/pub/spf <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.





  55..88..22..  MMooddiiffiiccaattiioonn ddeess ddoonnnneess ffttpp ppaarr MMiicchhaaeell HHaasseennsstteeiinn

  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
  <http://www.csn.tu-chemnitz.de/~mha/patch.ftp-data-2.gz>


  55..99..  EExxtteennssiioonnss ffuuttuurreess

  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 _a_u_s_s_i _d_u_r, et devrait
  autoriser une croissance pour un pare-feu beaucoup plus flexible).


  66..  PPrroobbllmmeess ccllaassssiiqquueess

  66..11..  iippcchhaaiinnss --LL eesstt ggeell !!

  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6..22..  LLee ccaammoouuffllaaggee//rreeddiirreeccttiioonn nnee ffoonnccttiioonnnnee ppaass !!

  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6..33..  --jj RREEDDIIRR nnee mmaarrcchhee ppaass !!

  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6..44..  LLeess iinntteerrffaacceess jjookkeerr nnee ffoonnccttiioonnnneenntt ppaass !!

  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6..55..  TTOOSS nnee ffoonnccttiioonnnnee ppaass !!

  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..66..  iippaauuttooffww eett iippppoorrttffww nnee ffoonnccttiioonnnneenntt ppaass !!

  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6..77..  XXoossVViieeww nnee mmaarrcchhee ppaass !!

  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6..88..  EErrrreeuurr ddee sseeggmmeennttaattiioonn aavveecc --jj RREEDDIIRREECCTT !!

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



  66..99..  JJee nnee ppeeuuxx ppaass mmooddiiffiieerr lleess tteemmppss dd''aatttteennttee dduu ccaammoouuffllaaggee !!

  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6..1100..  JJee vveeuuxx ffiirreewwaalllleerr IIPPXX !!

  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7..  UUnn eexxeemmppllee ssrriieeuuxx

  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7..11..  LL''aarrrraannggeemmeenntt


    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7..22..  BBuuttss

  Sur la machine filtrant les paquets :

     PPIINNGG ttoouutt rrsseeaauu
        Trs utile si la machine est hors-service.

     TTRRAACCEERROOUUTTEE ttoouutt rrsseeaauu
        Une fois de plus, utile pour les diagnostics.

     AAccccss aauu DDNNSS
        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 :

     AAuuttoorriissee WWWWWW,, ffttpp,, ttrraacceerroouuttee eett sssshh vveerrss ll''eexxttrriieeuurr
        Ce sont des services standards  autoriser : on autorise parfois
        les machines internes  tout faire, mais ici nous serons plus
        restrictifs.

     AAuuttoorriissee llee SSMMTTPP vveerrss llee sseerrvveeuurr mmaaiill
        Bien entendu, nous voulons qu'il leur soit possible d'envoyer du
        courrier vers l'extrieur.

     AAuuttoorriissee llee PPOOPP33 vveerrss llee sseerrvveeuurr mmaaiill
        C'est ainsi qu'ils lisent leur courrier.

     AAuuttoorriissee lleess rreeqquutteess DDNNSS vveerrss llee sseerrvveeuurr ddee nnoomm
        Ils doivent pouvoir rechercher des noms externes pour le web, le
        ftp, traceroute ou ssh.

     AAuuttoorriissee rrssyynncc vveerrss llee sseerrvveeuurr wweebb
        C'est ainsi qu'ils synchronisent le serveur web externe avec
        l'interne.

     AAuuttoorriissee lleess rreeqquutteess WWWWWW vveerrss llee sseerrvveeuurr wweebb
        Bien entendu, nous voulons qu'ils puissent se connecteur au
        serveur web externe.

     AAuuttoorriissee llee ppiinngg vveerrss llee ffiillttrree ddee ppaaqquueettss
        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7..33..  AAvvaanntt llee ffiillttrraaggee ddeess ppaaqquueettss


    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7..44..  FFiillttrraaggee ddee ppaaqquueettss ppoouurr lleess ppaaqquueettss ttrraavveerrssaannttss

  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





  77..44..11..  CCoonnffiigguurreerr lleess ssaauuttss ddee llaa cchhaannee ddee ttrraannssmmiissssiioonn

  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





  77..44..22..  DDffiinniirr llaa cchhaannee iiccmmpp--aacccc

  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





  77..44..33..  BBoonn ((iinntteerrnnee)) vveerrss ZZDDMM ((sseerrvveeuurrss))

  Restrictions internes :

    Autorise WWW, ftp, traceroute, ssh vers l'extrieur

    AAuuttoorriissee llee SSMMTTPP vveerrss llee sseerrvveeuurr mmaaiill

    AAuuttoorriissee llee PPOOPP33 vveerrss llee sseerrvveeuurr mmaaiill

    AAuuttoorriissee lleess rreeqquutteess DDNNSS vveerrss llee sseerrvveeuurr ddee nnoomm

    AAuuttoorriissee llee rrssyynncc vveerrss llee sseerrvveeuurr wweebb

    AAuuttoorriissee llee WWWWWW vveerrss llee sseerrvveeuurr wweebb

    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





  77..44..44..  MMaauuvvaaiiss ((eexxttrriieeuurr)) vveerrss ZZDDMM ((sseerrvveeuurrss))


    Restrictions de la ZDM :

    Serveur mail :

    SSMMTTPP vveerrss ll''eexxttrriieeuurr

    AAcccceeppttee llee SSMMTTPP vveennaanntt de l'intrieur et eexxttrriieeuurr

    Accepte le POP3 de l'intrieur

    Serveur de noms :

    EEnnvvooii ddee rreeqquutteess DDNNSS vveerrss ll''eexxttrriieeuurr

    AAcccceeppttee llee DDNNSS vveennaanntt de l'intrieur, eexxttrriieeuurr et du filtre de
     paquets

    Serveur web :

    AAcccceeppttee lleess rreeqquutteess HHTTTTPP vveennaanntt ddee l'intrieur et de ll''eexxttrriieeuurr

    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





  77..44..55..  BBoonn ((iinnttrriieeuurr)) vveerrss MMaauuvvaaiiss ((eexxttrriieeuurr))..


    Restrictions internes :

    AAuuttoorriissee llee WWWWWW,, ffttpp,, ttrraacceerroouuttee,, sssshh vveerrss ll''eexxttrriieeuurr


    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





  77..44..66..  ZZDDMM vveerrss BBoonn ((iinnttrriieeuurr))



    Restrictions internes :

    Autorise WWW, ftp, traceroute, ssh vers l'extrieur

    AAuuttoorriissee SSMMTTPP vveerrss llee sseerrvveeuurr mmaaiill

    AAuuttoorriissee PPOOPP33 vveerrss llee sseerrvveeuurr mmaaiill

    AAuuttoorriissee DDNNSS vveerrss llee sseerrvveeuurr ddee nnoommss

    AAuuttoorriissee rrssyynncc vveerrss llee sseerrvveeuurr wweebb

    AAuuttoorriissee WWWWWW vveerrss llee sseerrvveeuurr wweebb

    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





  77..44..77..  ZZDDMM vveerrss MMaauuvvaaiiss ((eexxttrriieeuurr))



    Restrictions de la ZDM :

    Serveur mail

    SSMMTTPP vveerrss ll''eexxttrriieeuurr

    AAcccceeppttee SSMMTTPP vveennaanntt ddee l'intrieur et de ll''eexxttrriieeuurr

    Accepte POP3 venant de l'intrieur


    Serveur de noms

    EEnnvvooii ddee rreeqquutteess DDNNSS vveerrss ll''eexxttrriieeuurr

    AAcccceeppttee llee DDNNSS ddee l'intrieur, ll''eexxttrriieeuurr et du filtre de paquets


    Serveur web

    AAcccceeppttee HHTTTTPP vveennaanntt ddee l'intrieur et de ll''eexxttrriieeuurr

    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





  77..44..88..  MMaauuvvaaiiss ((eexxttrriieeuurr)) vveerrss BBoonn ((iinnttrriieeuurr))



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


       ipchains -A mauvais-bon -j REJECT


  77..44..99..  FFiillttrraaggee ddee ppaaqquueettss ppoouurr llaa mmaacchhiinnee LLiinnuuxx eellllee--mmmmee



    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





  77..44..99..11..  IInntteerrffaaccee MMaauuvvaaiiss ((eexxttrriieeuurr))



    Machine de filtrage des paquets :

    PPIINNGG ttoouuss lleess rrsseeaauuxx

    TTRRAACCEERROOUUTTEE ttoouuss lleess rrsseeaauuxx

    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





  77..44..99..22..  IInntteerrffaaccee ZZDDMM



    Restrictions du filtre de paquets :

    PPIINNGG ttoouuss lleess rrsseeaauuxx

    TTRRAACCEERROOUUTTEE ttoouuss lleess rrsseeaauuxx

    AAccccss DDNNSS


    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





  77..44..99..33..  IInntteerrffaaccee BBoonn ((iinnttrriieeuurr))



    Restrictions du filtre de paquets

    PPIINNGG ttoouuss lleess rrsseeaauuxx

    TTRRAACCEERROOUUTTEE ttoouuss lleess rrsseeaauuxx

    AAccccss DDNNSS


    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

    AAuuttoorriissee ppiinngg vveerrss llee ffiillttrree ddee ppaaqquueettss


    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7..55..  FFiinnaalleemmeenntt


    Supprime les rgles de bloquage :


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





  88..  AAnnnneexxee :: ddiiffffrreenncceess eennttrree iippcchhaaiinnss eett iippffwwaaddmm

  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8..11..  GGuuiiddee ddee rrffrreennccee rraappiiddee

  [ 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8..22..  EExxeemmpplleess ddee ccoommmmaannddeess iippffwwaaddmm ttrraadduuiitteess

  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9..  AAnnnneexxee :: uuttiilliisseerr llee ssccrriipptt iippffwwaaddmm--wwrraappppeerr

  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, _v_e_u_i_l_l_e_z 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.
  1100..  AAnnnneexxee :: rreemmeerrcciieemmeennttss

  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.








































