  Adaptation   francaise  Bernard  Choppy,  choppy@imaginet.fr
  19 novembre 1997 Le HOWTO du  Firewalling  et  des  serveurs
  Proxy
  David Rudder, drig@execpc.com (originellement par Mark Gren-
  nan)
  v0.4, 8 novembre 1996 -

  Ce document est destine a enseigner les bases d'un firewall ainsi  que
  pour  donner quelques details sur la configuration d'un firewall aussi
  bien filtrant que serveur proxy sur un PC  sous  Linux.   Une  version
  HTML  de la version originale en anglais de ce document est disponible
  a http://okcforum.org/~markg/Firewall-HOWTO.html.

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

  Ce  Firewall-HOWTO  a  ete  originellement  ecrit  par  David  Rudder,
  mailto:drig@execpc.com.   Je voudrais le remercier de m'avoir autorise
  a mettre son travail a jour.

  Les firewalls ont obtenu une grande renommee en  tant  que  "nec  plus
  ultra"  de  la securite sur Internet.  Comme de nombreuses choses dont
  la renommee grandit, une certaine incomprehension s'y est jointe.   Ce
  HOWTO  presente  les  bases  de  la  definition  d'un  firewall, de sa
  configuration, des serveurs  proxy,  de  leur  configuration,  et  des
  applications de cette technologie hors du contexte de la securite.

  NdT  :  Diverses traductions ont ete proposees pour le terme _f_i_r_e_w_a_l_l,
  dont pare-feu, coupe-feu, mur anti-feu, etc.  Aucune ne  correspondant
  actuellement au concept precis de firewall en anglais (il s'agit d'une
  piece automobile separant l'habitacle du moteur), l'auteur  a  prefere
  conserver ce terme de firewall, plutot qu'une traduction arbitraire.

  11..11..  RReeaaccttiioonnss

  Toute reaction est la bienvenue.  _S_I_G_N_A_L_E_Z _T_O_U_T_E _I_N_E_X_A_C_T_I_T_U_D_E _D_A_N_S _C_E_T
  _A_R_T_I_C_L_E _S_'_I_L _V_O_U_S _P_L_A_I_T _!  Je suis humain, et donc sujet aux  erreurs.
  Si vous en trouvez, il m'interesse au plus haut point de les corriger.
  Je tenterai de repondre a tout e-mail, mais je suis  occupe,  donc  ne
  m'en veuillez pas si ce n'est pas le cas pour le votre.

  _M_o_n _a_d_r_e_s_s_e _e_-_m_a_i_l _e_s_t _: _m_a_i_l_t_o_:_m_a_r_k_g_@_n_e_t_p_l_u_s_._n_e_t_.

  11..22..  AAvveerrttiisssseemmeenntt

  _J_E _N_E _S_U_I_S _R_E_S_P_O_N_S_A_B_L_E _D_'_A_U_C_U_N _D_O_M_M_A_G_E _R_E_S_U_L_T_A_N_T _D_'_A_C_T_I_O_N_S _F_O_N_D_E_E_S _S_U_R
  _L_E _P_R_E_S_E_N_T _D_O_C_U_M_E_N_T_.  Ce document est concu comme une introduction  au
  fonctionnement des firewalls et des serveurs proxy.  Je ne suis, ni ne
  pretends etre un expert es securite.  Je suis simplement  un  individu
  qui  a  trop  lu  et  qui  apprecie les ordinateurs plus que d'autres.
  Considerez que j'ecris ceci pour familiariser les gens avec ce  sujet,
  et  que  je ne suis pas pret a perdre ma jeunesse dans l'exactitude de
  ce qui s'y trouve.

  NdT : Pour sa part, le traducteur emet les memes reserves  que  celles
  de l'auteur.

  11..33..  CCooppyyrriigghhtt

  Sauf mention contraire, les documents Linux HOWTO sont la propriete de
  leurs auteurs respectifs.  Les  documents  Linux  HOWTO  peuvent  etre
  reproduits  et  distribues  en totalite ou en partie, sur tout support
  physique ou electronique, tant  que  cette  notice  de  copyright  est
  presente   sur   chaque  copie.   La  redistribution  commerciale  est
  autorisee et encouragee ; neammoins, l'auteur souhaite etre informe de
  toute distribution de ce genre.

  Toute  traduction,  travail  derive,  ou  agregat  incorporant tout ou
  partie d'un ou plusieurs documents Linux HOWTO doit etre  couvert  par
  ce  meme  copyright.   Ce qui veut dire que vous ne pouvez produire un
  travail derive d'un HOWTO et imposer des restrictions  supplementaires
  concernant  sa distribution.  Des exceptions a ces regles peuvent etre
  delivrees sous certaines conditions ; contactez  le  coordinateur  des
  Linux HOWTO.

  En   bref,  nous  souhaitons  promouvoir  la  dissemination  de  cette
  information a travers autant de canaux que possible.  Neammoins,  nous
  souhaitons  conserver  un  copyright  sur les documents HOWTO, et etre
  avises de tout plan de distribution les concernant.

  Si  vous  avez  des  questions,  veuillez  contacter  Mark  Grennan  a
  mailto:markg@netplus.net.

  NdT  :  Le  traducteur  se met aussi a disposition, soit pour repondre
  directement, dans la mesure de ses faibles moyens, a  toute  question,
  soit  pour  transmettre et traduire, entre l'auteur et l'interlocuteur
  francophone.  Son adresse est : mailto:choppy@imaginet.fr

  11..44..  LLeess rraaiissoonnss qquuii mmee ppoouusssseenntt aa eeccrriirree cceeccii

  Meme s'il y a eu de nombreux fils de  discussion  sur  comp.os.linux.*
  dans  les dernieres annees sur les firewall, j'ai trouve difficilement
  les informations dont j'avais besoin  pour  monter  un  firewall.   La
  version  originelle  de  ce HOWTO etait utile, mais encore incomplete.
  J'espere que cette version completee du Firewall HOWTO de David Rudder
  fournira  a  chacun  l'information  necessaire  pour creer un firewall
  operationnel en quelques heures, et non en quelques semaines.

  Je pense aussi devoir rendre quelque chose a la communaute Linux.

  11..55..  RReessttee aa ffaaiirree

  +o  donner quelques instructions sur la configuration des clients ;

  +o  trouver un bon serveur proxy UDP qui fonctionne sous Linux.

  11..66..  AAuuttrreess lleeccttuurreess

  +o  le NET-2 HOWTO ;

  +o  l'Ethernet HOWTO ;

  +o  le Multiple Ethernet mini HOWTO ;

  +o  Networking with Linux ;

  +o  le PPP HOWTO ;

  +o  TCP/IP Network Administrator's Guide chez O'Reilly&Associates ;

  +o  La documentation de la boite a outils de firewall TIS.

  Le site web de Trusted Information System (TIS)  dispose  d'une  bonne
  collection  de  documentaions  sur  les firewalls et sujets connexes :
  http://www.tis.com.

  Je travaille aussi sur un  projet  de  securite  appele  _S_e_c_u_r_e  _L_i_n_u_x
  (Linux  securise).  Je  collecte  sur  le  site  de _S_e_c_u_r_e _L_i_n_u_x toute
  information, documentation  et  programme  necessaire  pour  creer  un
  systeme  Linux  securise.  Envoyez-moi un e-mail si vous souhaitez des
  informations.

  22..  CCoommpprreennddrree lleess ffiirreewwaallllss

  Firewall est un terme automobile.  Dans une voiture, un  firewall  est
  une piece qui separe le bloc-moteur du compartiment passagers.  Il est
  prevu pour  proteger  les  passagers  en  cas  de  feu  au  moteur  en
  maintenant le controle de ce dernier par le conducteur.

  En informatique, un firewall est un peripherique qui protege la partie
  privee d'un reseau de la partie publique (InterNet en entier).

  L'ordinateur firewall, ci-apres  denomme  "firewall",  peut  atteindre
  aussi  bien  le reseau protege qu'InterNet.  Le reseau protege ne peut
  atteindre InterNet, et ce dernier, a son tour, ne  peut  atteindre  le
  reseau protege.

  Pour  atteindre InterNet depuis l'interieur du reseau protege, il faut
  se connecter au firewall par  le  reseau,  puis  utiliser  InterNet  a
  partir de la.

  La  forme  la plus simple de firewall est un systeme a deux connexions
  reseau.  Si vous pouvez AVOIR CONFIANCE EN TOUS vos utilisateurs, vous
  pouvez     configurer    simplement    Linux    (compile    avec    IP
  forwarding/gatewaying OFF !) et leur donner a chacun un compte dessus.
  Il  pourront  des  lors  se connecter dessus, et utiliser FTP, lire le
  courrier et utiliser tout autre  service  que  vous  fournirez.   Avec
  cette  configuration,  le  seul  ordinateur  de votre reseau prive qui
  sache quelque chose du monde exterieur est le  firewall.   Les  autres
  systemes  sur  votre  reseau protege ne necessitent meme pas une route
  par defaut.

  Cela doit etre reformule.  Pour que le firewall ci-dessus  fonctionne,
  VVOOUUSS  DDEEVVEEZZ  AAVVOOIIRR  CCOONNFFIIAANNCCEE  EENN  TTOOUUSS  VVOOSS  UUTTIILLIISSAATTEEUURRSS !!  Je ne le
  recommande pas.

  22..11..  IInnccoonnvveenniieennttss ddeess ffiirreewwaallllss

  Le probleme  des  firewalls  filtrants  reside  dans  le  fait  qu'ils
  empechent l'acces l'interieur depuis InterNet.  Seuls les services sur
  les systemes disposant de filtres de passage sont  accessibles.   Avec
  un  serveur  proxy,  les utilisateurs peuvent se loger sur le firewall
  puis acceder a tout systeme interne auquel ils ont acces.

  De meme, de nouveaux types de clients reseau apparaissent a  peu  pres
  chaque  jour.   Lorsque  c'est le cas, vous devez trouver une nouvelle
  maniere d'autoriser l'acces controle avant que ces  services  puissent
  etre utilises.

  22..22..  TTyyppeess ddee ffiirreewwaallllss

  Il y a deux types de firewalls :

  1. firewalls  IP ou filtrants - ils bloquent tout le trafic sauf celui
     selectionne ;

  2. serveurs proxy - ils realisent les connexions reseau pour vous.

  22..22..11..  ffiirreewwaallllss ffiillttrraannttss IIPP

  Un firewall filtrant IP fonctionne au niveau  paquet.   Il  est  concu
  pour  controler  le  flux  de  paquets  en  fonction  de l'origine, la
  destination, le port et l'information de type de paquet contenue  dans
  chacun de ceux-ci.

  Ce type de firewall est tres sur mais incomplet en termes de connexion
  aisee.  Il peut bloquer l'acces des gens a un systeme  prive  mais  ne
  vous indiquera pas qui a accede a vos systemes publics ni qui a accede
  a InterNet depuis l'interieur.

  Les firewalls filtrants sont des filtres absolus.  Meme si vous voulez
  donner acces a quelqu'un d'exterieur sur vos serveurs prives, ce n'est
  pas possible sans donner acces aux serveurs a tout le monde.

  Linux inclut un logiciel de filtrage de paquets dans les noyaux depuis
  1.3.x.

  22..33..  SSeerrvveeuurrss pprrooxxyy

  Les  serveurs  proxy  permettent  l'acces  indirect  a InterNet depuis
  l'arriere d'un firewall.  Le meilleur  exemple  du  fonctionnement  de
  ceux-ci  est  celui  d'une  personne  se connectant a un systeme puis,
  depuis celui-ci, a un autre.  C'est seulement avec  un  serveur  proxy
  que  ce  processus  est automatique.  Lorsque vous vous connectez a un
  serveur proxy a l'aide de votre  logiciel  client,  le  serveur  proxy
  demarre  son  propre  logiciel  client  (proxy)  et  vous transmet les
  donnees.

  Puisque les serveurs proxy dupliquent toutes  les  communications,  il
  speuvent enregistrer toute leur activite.

  L'idee   majeure   concernant  les  serveurs  proxy  est  qu'ils  sont
  completement surs, lorsqu'ils sont configures  correctement.   Ils  ne
  permettront  a personne d'entrer au-travers d'eux.  Il n'existe pas de
  route IP directe.

  33..  CCoonnffiigguurreerr llee ffiirreewwaallll

  33..11..  MMaatteerriieell nneecceessssaaiirree

  Pour notre exemple, l'ordinateur est un 486-DX66 avec 16 Mo de RAM  et
  500  Mo  de partition Linux.  Ce systeme dispose de deux cartes reseau
  dont l'une est connectee a notre reseau prive et l'autre a  un  reseau
  que  nous  appellerons  "zone demilitarisee" (ZD).  La ZD dispose d'un
  routeur connectee a InterNet.

  Il s'agit d'une configuration assez standard en  entreprise.   Il  est
  possible  d'utiliser  une seule carte reseau et un modem avec PPP vers
  InterNet.  Le principal est que le  firewall  doit  disposer  de  deux
  adresses IP.

  Je  connais  un  tas  de gens qui ont un petit reseau a la maison avec
  deux ou trois ordinateurs dessus.   Il  est  possible  d'envisager  de
  placer  tous les modems sur une machine Linux (peut-etre un vieux 386)
  et de tous les connecter a InterNet avec l'equilibrage de charge (load
  balancing).  Avec cette configuration, lorsque quelqu'un transfere des
  donnees, la presence de deux modems peut doubler  la  bande  passante.
  :-)

  44..  LLooggiicciieell ddee ffiirreewwaallll

  44..11..  PPaaqquueettaaggeess ddiissppoonniibblleess

  Si  tout  ce  qu'il  vous  faut  est un firewall filtrant, vous n'avez
  besoin que de Linux et des paquetages reseau de  base.   Un  paquetage
  qui peut n'etre pas inclus dans votre distribution est le "IP Firewall
  Administration tool" (IPFWADM).

  Il est disponible sur : http://www.xos.nl/linux/ipfwadm/

  Si vous voulez configurer un serveur proxy, il vous faut l'un  de  ces
  paquetages :

  +o  SOCKS ;

  +o  TIS Firewall Toolkit (FWTK).

  44..22..  FFWWTTKK ccoonnttrree SSOOCCKKSS

  Trusted   Information   Systems   (http://www.tis.com)   a  sorti  une
  collection de programmes destines a faciliter la mise  en  place  d'un
  firewall.  Les programmes font fondamentalement la meme chose que ceux
  du paquetage SOCKS, mais avec une strategie de conception  differente.
  La  ou  SOCKS  a  un  programme  qui  couvre  toutes  les transactions
  InterNEt, TIS fournit un programme pour chaque utilitaire qui souhaite
  utiliser le firewall.

  Pour distinguer l'un de l'autre, nous allons utiliser l'exemple du web
  et de l'acces telnet.  Avec SOCKS,  on  configure  un  fichier  et  un
  daemon.   A  l'aide  de  ceux-ci,  aussi  bien  telnet que le web sont
  actives, ainsi que tout autre service qui n'a pas ete desactive.

  Avec la boite a outils TIS, on configure un daemon pour telnet et pour
  le  web,  ainsi  qu'un  fichier pour chaque.  Une fois cela fait, tout
  autre acces Internet reste interdit jusqu'a son  activation  expresse.
  Si le daemon d'un service precis n'a pas ete fourni (comme pour talk),
  il existe un daemon "pret-a-brancher", mais ce n'est ni aussi  souple,
  ni aussi aise a configurer que pour les autres outils.

  Cela  peut sembler une difference mineure, mais c'en est une majeure :
  SOCKS  vous  permet  d'etre  faineant.   Avec  un  serveur  SOCKS  mal
  configure,  quelqu'un  peut  avoir  plus  d'acces vers InterNet depuis
  l'interieur que ce qu'il avait ete prevu initialement.  Avec la  boite
  a  outils  TIS,  les  gens  de l'interieur ont seulement les acces que
  l'administrateur systeme souhaite qu'ils aient.

  SOCKS est plus facile a configurer, a  compiler  et  permet  une  plus
  grande  souplesse.   La  boite  a  outils  TIS  est  plus sure si l'on
  souhaite reguler les utilisateurs de l'interieur du reseau.  Les  deux
  fournissent une protection absolue depuis l'exterieur.

  Je parlerai de l'installation des deux.

  55..  PPrreeppaarreerr llee ssyysstteemmee LLiinnuuxx

  55..11..  CCoommppiilleerr llee nnooyyaauu

  Commencez  avec  une  installation  propre de votre distribution Linux
  (j'ai utilise RedHat 3.0.3 et  les  exemples  sont  fondes  sur  cette
  distribution).   Moins vous installez de logiciel, moins votre systeme
  aura de trous de securite, portes derobees et/ou  bogues  susceptibles
  d'induire des problemes de securite dans votre systeme, donc installez
  le moins possible d'applications.

  Prenez un noyau stable.  J'ai utilise le noyau Linux 2.0.14  pour  mon
  systeme.  La documentation est donc fondee sur ses parametres.

  Vous  devez  recompiler le noyau Linux avec les options appropriees. A
  ce point, je vous renvoie au Kernel HOWTO, a l'Ethernet  HOWTO  et  au
  NET-2 HOWTO si vous ne l'avez pas encore fait.

  Voici  les  parametres  reseau  que  je  sais  fonctionner  dans "make
  config" :

  1. Dans la configuration generale :

     a. Activez le support du reseau ;

  2. Dans les options reseau :

     a. Activez le firewall reseau,

     b. Activez le protocole TCP/IP,

     c. Desactivez la  transmission/routage  IP  (forwarding/gatewaying)
        (SAUF si vous voulez utiliser le filtrage IP),

     d. Activez le Firewalling IP,

     e. Activez   la  trace  des  paquets  de  firewall  (ce  n'est  pas
        indispensable, mais c'est une bonne idee),

     f. DESactivez le masquage (masquerading - je ne traite pas ce sujet
        ici),

     g. Activez la gestion des comptes (accounting),

     h. DESactivez le tunneling,

     i. DESactivez l'aliasing,

     j. DESactivez le mode de compatibilite PC/TCP,

     k. DESactivez l'ARP inverse (Reverse ARP),

     l. Activez l'abandon des trames routees par la source ;

  3. Dans le support des interfaces reseau :

     a. Activez le support des equipements reseau,

     b. Activez le support du pseudo-pilote reseau,

     c. Activez Ethernet (10 ou 100Mbit),

     d. Choisissez votre carte reseau ;

  Ensuite,  vous  pouvez  recompiler,  reinstaller le noyau et rebouter.
  Les cartes reseau doivent apparaitre dans la  sequence  de  demarrage.
  Sinon,  plongez-vous  a  nouveau  dans les autres HOWTO jusqu'a ce que
  cela fonctionne.

  55..22..  CCoonnffiigguurreerr ddeeuuxx ccaarrtteess rreesseeaauu

  Si vous avez deux cartes reseau dans  votre  ordinateur,  vous  devrez
  tres  certainement  ajouter  un  parametre "append" dans votre fichier
  /etc/lilo.conf pour decrire les IRQ et adresses des deux  cartes.   Le
  mien se presente ainsi :

          append="ether=12,0x300,eth0 ether=15,0x340,eth1"

  55..33..  CCoonnffiigguurreerr lleess aaddrreesssseess rreesseeaauu

  C'est la partie reellement interessante.  Vous avez quelques decisions
  a y prendre.  Puisque nous ne souhaitons pas laisser InterNet  acceder
  au  reseau  prive,  il  n'est  pas  necessaire d'utiliser des adresses
  reelles.  Un certain nombre d'adresses InterNet ont  ete  laissees  de
  cote  pour  les  reseaux  prives.   Puisque  tout le monde a besoin de
  toujours plus d'adresses et puisque celles-ci ne peuvent circuler  sur
  InterNet, il s'agit d'un bon choix.

  Parmi  celles-ci,  nous  utiliserons  celles de 192.168.2.xxx pour nos
  exemples.

  Votre firewall proxy sera membre des  deux  reseaux  et  ainsi  pourra
  passer les donnees vers et depuis le reseau prive.

              199.1.2.10   __________    192.168.2.1
        _  __  _        \ |          | /           _______________
       | \/  \/ |        \| Systeme  |/           | Station(s) de |
      / InterNet \--------| Firewall |------------|    travail    |
      \_/\_/\_/\_/        |__________|            |_______________|

  Si  vous  vous  preparez a utiliser un firewall filtrant, ces adresses
  sont  encore  correctes.   Vous  devrez  utiliser   le   masquage   IP
  (masquerading)  pour  que  cela  fonctionne.   Avec  ce  processus, le
  firewall route les paquets et les transforme en adresses IP  "reelles"
  pour circuler sur InterNet.

  Assignez  l'adresse  IP  reelle  a  la  carte  reseau du cote InterNet
  (exterieur).   Assignez  192.168.2.1  a  la  carte  Ethernet  du  cote
  interieur.   Il  s'agira  de votre adresse proxy/gateway.  Vous pouvez
  assigner une adresse de la plage 192.168.2.2 a 192.168.2.254 a  toutes
  les autres machines du reseau protege.

  Puisque  j'utilise  RedHat  Linux  (Eh, les gars, faudrait voir a m'en
  offrir une copie, vu la pub ? ;-), pour configurer le reseau  lors  du
  demarrage  j'ai  ajoute  un  fichier  "ifcfg-eth1"  dans le repertoire
  /etc/sysconfig/network-scripts.  Ce fichier est lu lors  du  processus
  de demarrage pour configurer le reseau et les tables de routage.

  Voici l'allure de mon fichier ifcfg-eth1 :

          #!/bin/sh
          #>>>type de peripherique : ethernet
          #>>>declaration de variables :
          DEVICE=eth1
          IPADDR=192.168.2.1
          NETMASK=255.255.255.0
          NETWORK=192.168.2.0
          BROADCAST=192.168.2.255
          GATEWAY=199.1.2.10
          ONBOOT=yes
          #>>>fin de declaration de variables

  Vous   pouvez   aussi   utiliser   ces  scripts  pour  vous  connecter
  automatiquement par modem  chez  votre  fournisseur.   Jetez  un  coup
  d'oeil au script ipup-ppp.

  Si vous utilisez un modem pour votre connexion InterNet, votre adresse
  IP sera assignee a votre machine a l'instant de la connexion.

  55..44..  TTeesstteerr llee rreesseeaauu

  Commencer par controler ifconfig et route.  Si vous avez  deux  cartes
  reseau, votre ifconfig doit afficher quelque chose qui ressemble a :

          #ifconfig
          lo      Link encap:Local Loopback
                  inet addr:127.0.0.0  Bcast:127.255.255.255  Mask:255.0.0.0
                  UP BROADCAST LOOPBACK RUNNING  MTU:3584  Metric:1
                  RX packets:1620 errors:0 dropped:0 overruns:0
                  TX packets:1620 errors:0 dropped:0 overruns:0

          eth0    Link encap:10Mbps Ethernet  HWaddr 00:00:09:85:AC:55
                  inet addr:199.1.2.10 Bcast:199.1.2.255  Mask:255.255.255.0
                  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                  RX packets:0 errors:0 dropped:0 overruns:0
                  TX packets:0 errors:0 dropped:0 overruns:0
                  Interrupt:12 Base address:0x310

          eth1    Link encap:10Mbps Ethernet  HWaddr 00:00:09:80:1E:D7
                  inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
                  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                  RX packets:0 errors:0 dropped:0 overruns:0
                  TX packets:0 errors:0 dropped:0 overruns:0
                  Interrupt:15 Base address:0x350

  et votre table de routage :

          #route -n
          Kernel routing table
          Destination  Gateway      Genmask        Flags MSS   Window Use Iface
          199.1.2.0    *            255.255.255.0  U     1500  0       15 eth0
          192.168.2.0  *            255.255.255.0  U     1500  0        0 eth1
          127.0.0.0    *            255.0.0.0      U     3584  0        2 lo
          default      199.1.2.10   *              UG    1500  0       72 eth0

  NNoottee::  199.1.2.0  est  l'adresse  du  cote  InterNet  du  firewall  et
  192.168.2.0 celle du cote prive.

  Ensuite, essayez un ping sur InterNet  depuis  le  firewall.   J'avais
  l'habitude d'utiliser nic.ddn.mil comme point de test.  C'est toujours
  un bon test, mais  il  a  prouve  qu'il  etait  moins  fiable  que  je
  l'esperais.   Si  cela  ne fonctionne pas des l'abord, essayez un ping
  sur quelques autres sites qui ne soient pas connectes a  votre  reseau
  local.   Si cela ne fonctionne pas, alors votre PPP est mal configure.
  Relisez le NET-2 HOWTO, et essayez a nouveau.

  Maintenant, essayez des ping sur les machines du reseau protege depuis
  le  firewall.  Tous les ordinateurs doivent etres capables d'atteindre
  tous les autres.  Dans le cas contraire, repassez une couche de  NET-2
  HOWTO et retravaillez encore un peu votre reseau.

  Puis,  chaque  machine du reseau protege doit etre capable d'atteindre
  le firewall par ping. Sinon, retournez une fois de plus en arriere.

  Ensuite, essayez d'atteindre l'adresse exterieure du  firewall  depuis
  l'interieur  du  reseau  protege  (Note  :  il  ne s'agit d'aucune des
  adresses 192.268.2.xxx).  Si vous le pouvez, c'est que vous n'avez pas
  desactive  la  transmission  IP.  Assurez-vous que ce soit bien ce que
  vous souhaitez.  Si vous le laissez actif, vous devrez  travailler  le
  filtrage IP decrit plus loin dans ce document.

  Enfin,   essayez   d'atteindre  Internet  depuis  l'arriere  de  votre
  firewall.  Utilisez la meme adresse que  celle  qui  avait  fonctionne
  avant  (par exemple, nic.ddn.mil).  De meme, si vous avez desactive la
  transmission IP, cela ne devrait pas fonctionner, mais si vous  l'avez
  activee, cela devrait.

  Si  vous  avez  active  la  transmission  IP  et que vous utilisez une
  adresse IP "reelle" (pas 192.168.2.*) pour votre reseau prive  et  que
  vous  ne  puissiez atteindre InterNet, mais seulement le cote InterNet
  de votre firewall, controlez si le prochain routeur transmet bien  les
  paquets  pour votre adresse de reseau prive (votre fournisseur devrait
  avoir realise cela pour vous).

  Le fait d'assigner le 192.168.2.* au reseau protege  indique  qu'aucun
  paquet  ne  peut lui etre transmis.  Si vous avez deja lu plus loin et
  que le masquage IP soit active, ce test devrait fonctionner.

  Vous avez maintenant une configuration de base.

  55..55..  SSeeccuurriisseerr llee ffiirreewwaallll

  Le firewall n'est d'aucune utilite s'il reste ouvert aux attaques  via
  un  service  inutilise.  Un "mechant" peut obtenir l'acces au firewall
  et le modifier pour ses desseins propres.

  Commencez par desactiver tous les services  inutilises.   Regardez  le
  fichier  /etc/inet.conf.   Ce  fichier  controle  ce  qu'on appelle le
  "super-serveur".  Cela controle un tas  de  daemons  serveurs  et  les
  execute sur demande.

  Desactivez  definitivement  netstat,  systat,  tftp,  bootp et finger.
  Pour desactiver un service, placez simplement un "#" devant.  Ensuite,
  envoyez  un  signal  SIG-HUP  au  processus  inetd,  selon  la syntaxe
  suivante : kkiillll --HHUUPP <<ppiidd>>, ou "pid" est le numero du processus inetd.
  Cela force inetd a relire son fichier de configuration (inetd.conf) et
  a se relancer.

  Testez le resultat par telnet sur le port 15 du firewall, qui  est  le
  port  de  netstat.   Si vous obtenez une reponse de netstat, c'est que
  vous n'avez pas relance inetd correctement.

  66..  CCoonnffiigguurraattiioonn dduu ffiillttrraaggee IIPP ((IIPPFFWWAADDMM))

  Pour commencer,  vous  devez  avoir  active  la  transmission  IP  (IP
  forwarding)  dans  le  noyau  et  votre  systeme  doit  etre  actif et
  transmettre tout ce que vous lui  envoyez.   Vos  tables  de  routages
  doivent  etre en place et vous devez etre en mlesure d'acceder a tout,
  aussi bien a l'exterieur depuis l'interieur  qu'a  l'interieur  depuis
  l'exterieur.

  Cela dit, nous construisons un firewall, donc il nous faut commencer a
  reduire ce a quoi tout le monde a acces.

  Dans mon systeme,  j'ai  cree  quelques  scripts  pour  parametrer  le
  comportement  de  transmission  et de la trace.  J'appelle ces scripts
  depuis ceux de /etc/rc.d afin que mon systeme soit  configure  des  le
  lancement.

  Par  defaut,  le  systeme  de  transmission IP route tout.  Pour cette
  raison, votre script de firewall doit commencer par interdire  l'acces
  a  tout  et  par  vider  toutes les regles de trace en place depuis la
  derniere fois qu'il a  ete  lance.   Le  script  suivant  effectue  le
  travail :

          #
          # configuration de la transmission IP et
          # de la trace
          #
          #   Transmission
          #
          # Par defaut INTERDIRE tous les services
          ipfwadm -F -p deny
          # Vider toutes les regles de trace
          ipfwadm -F -f
          ipfwadm -I -f
          ipfwadm -O -f

  Maintenant,  nous  avons  un  firewall absolu.  Rien ne peut passer au
  travers.  Sans doute devez-vous transmettre  quelques  services,  donc
  voici quelques exemples que vous devriez trouver utiles :

          # Autoriser l'acces de l'e-mail au serveur
          ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 192.1.2.10 25

          # Autoriser les connexions e-mail vers les serveurs exterieurs
          ipfwadm -F -a accept -b -P tcp -S 196.1.2.10 25 -D 0.0.0.0/0 1024:65535

          # Autoriser les connexions web vers le serveur web
          /sbin/ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 196.1.2.11 80

          # Autoriser les connexions web vers les serveurs web exterieurs
          /sbin/ipfwadm -F -a accept -b -P tcp -S 196.1.2.* 80 -D 0.0.0.0/0 1024:65535

          # Autoriser le trafic DNS
          /sbin/ipfwadm -F -a accept -b -P udp -S 0.0.0.0/0 53 -D 196.1.2.0/24

  Il peut etre aussi interessant de tracer le trafic qui passe par votre
  firewall.  Ce script compte chaque paquet.  Vous  pouvez  ajouter  une
  ligne  ou  deux  pour  tracer  les  paquets  qui  vont vers un systeme
  particulier.

          # Vider les regles de trace en cours
          ipfwadm -A -f
          # Trace
          /sbin/ipfwadm -A -f
          /sbin/ipfwadm -A out -i -S 196.1.2.0/24 -D 0.0.0.0/0
          /sbin/ipfwadm -A out -i -S 0.0.0.0/0 -D 196.1.2.0/24
          /sbin/ipfwadm -A in -i -S 196.1.2.0/24 -D 0.0.0.0/0
          /sbin/ipfwadm -A in -i -S 0.0.0.0/0 -D 196.1.2.0/24

  Si tout ce que vous cherchez est un  firewall  filtrant,  vous  pouvez
  vous arreter ici.  Amusez-vous bien :-)

  77..  IInnssttaalllleerr llee sseerrvveeuurr pprrooxxyy TTIISS

  77..11..  TTrroouuvveerr llee llooggiicciieell

  Le TIS fwtk est disponible a ftp://ftp.tis.com.

  Ne  commettez pas l'erreur que j'ai commise : Lorsque vous telechargez
  les ficheirs de TIS, LISEZ LES README.  Le  TIS  fwtk  est  verrouille
  dans  un  repertoire  cache  sur  leur  serveur.   TIS impose que vous
  envoyiez uunn ee--mmaaiill aa mmaaiillttoo::ffwwttkk--rreeqquueesstt@@ttiiss..ccoomm avec le seul mot SSEENNDD
  dans le corps du message pour connaitre le nom de ce repertoire cache.
  Aucun sujet n'est necessaire  pour  ce  message.   Leur  systeme  vous
  enverra  en  retour  le  nom  du  repertoire  par e-mail (en gros sous
  12 heures) pour charger le source.

  A l'instant ou j'ecris, TIS diffuse  la  version  2.0(beta)  du  fwtk.
  Cette   version   semble   se  compiler  correctement  (avec  quelques
  exceptions) et tout fonctionne pour moi.  C'est la  version  qui  sera
  couverte  ici.   Lorsque  le  code final sera disponible, je mettrai a
  jour le HOWTO.

  Pour installer le  fwtk,  creez  un  repertoire  fwtk-2.0  dans  votre
  repertoire  /usr/src.   Deplacez votre copie de fwtk (fwtk-2.0.tar.gz)
  dans ce repertoire et de-tarez-le (tar zxf fwtk-2.0.tar.gz).

  Le fwtk ne route pas les documents web SSL, mais il existe  un  module
  complementaire  ecrit par Jean-Christophe Touvet.  Il est disponible a
  ftp://ftp.edelweb.fr/pub/contrib/fwtk/ssl-gw.tar.Z.  Christophe Touvet
  ne fournit aucun support pour ce code.

  J'utilise  une  version  modifiee  ecrite  par  Eric  Wedel qui inclut
  l'acces  aux  serveurs  de  nouvelles  securises  Netscape.   Il   est
  disponible  a ftp://ftp.mdi.meridian-data.com/pub/tis.fwtk/ssl-gw/ssl-
  gw2.tar.Z.

  Notre exemple s'appuie sur la version modifiee d'Eric Wedel.

  Pour l'installer, creez simplement un  repertoire  ssl-gw  dans  votre
  repertoire /usr/src/fwtk-2.0 et placez-y les fichiers.

  Lorsque  j'ai  installe  cette  passerelle,  il  necessitait  quelques
  modifications avant de se compiler avec le reste du paquetage.

  La premiere modification etait dans le fichier ssl-gw.c.  Je  me  suis
  rendu compte qu'il omettait l'inclusion d'un fichier necessaire :

          #if defined(__linux)
          #include        <sys/ioctl.h>
          #endif

  Ensuite, aucun fichier Makefile n'est fourni.  J'en ai copie un depuis
  un des autres repertoires des passerelles et remplace  le  nom  de  la
  passerelle avec ssl-gw.

  77..22..  CCoommppiilleerr llee TTIISS ffwwttkk

  La  version 2.0 du fwtk se compile nettement plus facilement qu'aucune
  des versions precedentes.  J'ai encore trouve quelques petites  choses
  qui  devaient  etre  changees  avant  que  la  version beta se compile
  correctement.  Esperons que ces modifications seront realisees dans la
  version finale.

  Pour   les   corriger,   commencez   par   aller  dans  le  repertoire
  /usr/src/fwtk/fwtk et copiez  le  fichier  Makefile.config.linux  par-
  dessus le Makefile.config.

  NNee llaanncceezz ppaass ffiixxmmaakkee..  Les instructions vous disent de le faire.  Son
  execution casse les Makefiles de tous les repertoires.

  J'ai une correction pour fixmake.  Le probleme est que le  script  sed
  ajoute un "." et un """ sur la ligne d'include de chaque Makefile.  Le
  script sed suivant fonctionne :

          sed 's/^include[        ]*\([^  ].*\)/include \1/' $name .proto > $name

  Ensuite,  il   faut   editer   le   fichier   Makefile.config.    Deux
  modifications sont necessaires.

  L'auteur  definit  le repertoire source dans son repertoire personnel.
  Nous compilons notre code dans /usr/src, donc vous  devez  changer  la
  variable FWTKSRCDIR pour tenir compte de cela :

          FWTKSRCDIR=/usr/src/fwtk/fwtk

  Par ailleurs, au moins certains systemes Linux utilisent la base gdbm.
  Le Makefile.config utilise dbm.   Il  est  possible  que  vous  deviez
  changer cela.  J'ai du le faire pour RedHat 3.0.3 :

          DBMLIB=-lgdbm

  La  derniere correction est dans le x-gw.  Le bogue de la version beta
  est dans le code socket.c.   Pour  le  corriger,  retirez  les  lignes
  suivantes du code :

          #ifdef SCM_RIGHTS  /* 4.3BSD Reno et suivants */
                             + sizeof(un_name->sun_len) + 1
          #endif

  Si  vous  avez  ajoute  ssl-gw dans votre repertoire source fwtk, vous
  devez l'ajouter dans la liste des repertoires dans le Makefile :

          DIRS=   smap smapd netacl plug-gw ftp-gw tn-gw rlogin-gw http-gw x-gw ssl-gw

  Maintenant, vous pouvez lancer mmaakkee.

  77..33..  IInnssttaalllleerr llee TTIISS ffwwttkk

  Lancer mmaakkee iinnssttaallll.

  Le repertoire d'installation  par  defaut  est  /usr/local/etc.   Vous
  pouvez  modifier  cela  (je  ne l'ai pas fait) pour un repertoire plus
  securise.  J'ai choisi de placer les droits d'acces a ce repertoire  a
  700 ("chmod 700").

  Ce qu'il reste au moins maintenant est de configurer le firewall.

  77..44..  MMaaiinntteennaanntt,, llee ppllaaiissiirr ccoommmmeennccee vvrraaiimmeenntt..  NNoouuss ddeevvoonnss eennsseeiiggnneerr
  aauu ssyysstteemmee aa aappppeelleerr cceess nnoouuvveeaauuxx sseerrvviicceess eett ccrreeeerr  lleess  ttaabblleess  ppoouurr
  lleess  ccoonnttrroolleerr..  JJee nnee ssuuiiss ppaass eenn ttrraaiinn ddee rree--eeccrriirree llee mmaannuueell ddee TTIISS
  ffwwttkk iiccii..  JJee vvaaiiss mmoonnttrreerr lleess ppaarraammeettrreess qquuee jj''aaii ffaaiitt ffoonnccttiioonnnneerr eett
  eexxpplliiqquueerr  lleess pprroobblleemmeess qquuee jj''aaii rreennccoonnttrreess eett ccoommmmeenntt jjee lleess aaii ccoonn--
  ttoouurrnneess..  TTrrooiiss ffiicchhiieerrss ddeeffiinniisssseenntt cceess ccoonnttrroolleess :: CCoonnffiigguurreerr llee TTIISS
  ffwwttkk

  +o  /etc/services  :  indique  au  systeme  sur  quel port se trouve un
     service ;

  +o  /etc/inetd.conf : indique a inetd le  programme  a  lancer  lorsque
     quelqu'un appelle un port de service ;

  +o  /usr/local/etc/netperm-table  :  indique  aux  services  fwtk a qui
     autoriser ou interdire l'acces au service.

  Pour faire fonctionner fwtk, vous devez editer ces fichiers de bas  en
  haut.  Editer le fichier des services sans que les fichiers inetd.conf
  ou  netperm-table  soient   corrects   peut   rendre   votre   systeme
  inaccessible.

  77..44..11..  LLee ffiicchhiieerr nneettppeerrmm--ttaabbllee

  Ce  fichier controle qui a acces aux services de TIS fwtk.  Vous devez
  penser au trafic qui passe par le firewall depuis les deux cotes.  Les
  gens  de  l'exterieur  de  votre  reseau  doivent  s'identifier  avant
  d'obtenir l'acces, mais ceux de  l'interieur  doivent  etre  autorises
  simplement a passer au-travers.

  Afin  que  les  gens  puissent  s'identifier,  le  firewall utilise un
  programme appele aauutthhssrrvv pour maintenir une base des noms et  mots  de
  passe.    La   section   authentification  de  netperm-table  controle
  l'emplacement et l'acces a la base.

  J'ai eu quelques difficultes a fermer l'acces a ce service.  Notez que
  la  ligne permi-hosts que je montre utilise un "*" pour donner l'acces
  a tout le monde.   Le  parametrage  correcte  de  cette  ligne  est  :
  authsrv:   premit-hosts   localhost,   si  vous  arrivez  a  la  faire
  fonctionner.

          #
          # Table de configuration proxy
          #
          # Regles d'authentification client et serveur
          authsrv:        database /usr/local/etc/fw-authdb
          authsrv:        permit-hosts *
          authsrv:        badsleep 1200
          authsrv:        nobogus true
          # Applications client utilisant le serveur d'authentification
          *:              authserver 127.0.0.1 114

  Pour initialiser la base, passez root  et  lancez  ..//aauutthhssrrvv  dans  le
  repertoire /var/local/etc pour creer l'enregistrement de l'utilisateur
  d'administration.

  Lisez  la  documentation  de  fwtk  pour  la  maniere  d'ajouter   des
  utilisateurs et des groupes.

  Voici un exemple de session :

          #
          # authsrv
          authsrv# list
          authsrv# adduser admin "Auth DB admin"
          ok - user added initially disabled
          authsrv# ena admin
          enabled
          authsrv# proto admin pass
          changed
          authsrv# pass admin "plugh"
          Password changed.
          authsrv# superwiz admin
          set wizard
          authsrv# list
          Report for users in database
          user   group  longname           ok?    proto   last
          ------ ------ ------------------ -----  ------  -----
          admin         Auth DB admin      ena    passw   never
          authsrv# display admin
          Report for user admin (Auth DB admin)
          Authentication protocol: password
          Flags: WIZARD
          authsrv# ^D
          EOT
          #

  Les  controles  de la passerelle telnet (tn-gw) vont de soi et sont la
  premiere chose que vous deviez configurer.

  Dans mon exemple, j'autorise une machine du reseau prive a passer sans
  s'authentifier  (permit-hosts  19961.2.*  -passok).  En revanche, tout
  autre utilisateur doit entrer ses nom et mot de passe pour utiliser le
  proxy (permit-hosts * -auth).

  J'autorise  aussi un autre systeme (196.1.2.202) a acceder au firewall
  directement sans  passer  du  tout  par  celui-ci.   Les  deux  lignes
  inetacl-in.telnetd  font  cela.   J'expliquerai  plus loin comment ces
  lignes sont utilisees.

  Le timeout de telnet doit rester court :

          # regles de passerelle telnet :
          tn-gw:          denial-msg      /usr/local/etc/tn-deny.txt
          tn-gw:          welcome-msg     /usr/local/etc/tn-welcome.txt
          tn-gw:          help-msg        /usr/local/etc/tn-help.txt
          tn-gw:          timeout 90
          tn-gw:          permit-hosts 196.1.2.* -passok -xok
          tn-gw:          permit-hosts * -auth
          # Seul l'administrateur peut telneter directement le firewall
          # sur le port 24
          netacl-in.telnetd: permit-hosts 196.1.2.202 -exec /usr/sbin/in.telnetd

  Les commandes "r" fonctionnent de la meme maniere que pour telnet :

          # regles de passerelle rlogin :
          rlogin-gw:      denial-msg      /usr/local/etc/rlogin-deny.txt
          rlogin-gw:      welcome-msg     /usr/local/etc/rlogin-welcome.txt
          rlogin-gw:      help-msg        /usr/local/etc/rlogin-help.txt
          rlogin-gw:      timeout 90
          rlogin-gw:      permit-hosts 196.1.2.* -passok -xok
          rlogin-gw:      permit-hosts * -auth -xok
          # Seul l'administrateur peut telneter directement le firewall
          # sur le port
          netacl-rlogind: permit-hosts 196.1.2.202 -exec /usr/libexec/rlogind -a

  Personne ne devrait avoir  acces  directement  au  firewall,  et  cela
  inclut FTP, donc ne placez pas de serveur FTP sur votre firewall.

  A  nouveau,  la ligne permit-hosts autorise quiconque depuis le reseau
  protege a acceder librement a InterNet et tous les autres utilisateurs
  doivent s'authentifier.  J'ai ajoute la trace de chaque fichier envoye
  et recu dans mes controles (-log { retr stor }).

  LE timeout FTP controle le temps mis a fermer une mauvaise  connexion,
  ainsi que le temps d'inactivite maximal d'une session ouverte :

          # regles de passerelle ftp :
          ftp-gw:         denial-msg      /usr/local/etc/ftp-deny.txt
          ftp-gw:         welcome-msg     /usr/local/etc/ftp-welcome.txt
          ftp-gw:         help-msg        /usr/local/etc/ftp-help.txt
          ftp-gw:         timeout 300
          ftp-gw:         permit-hosts 196.1.2.* -log { retr stor }
          ftp-gw:         permit-hosts * -authall -log { retr stor }

  Le  web,  gopher et le ftp fonde sur un butineur sont controles par le
  http-gw.  Les deux premieres lignes creent un repertoire pour  stocker
  les  documents  ftp  et web lorsqu'ils passent au-travers du firewall.
  Je rends root proprietaire de ces fichiers et je  les  place  dans  un
  repertoire accessible seulement par root.

  La  connexion  web doit etre maintenue courte.  Elle controle le temps
  durant lequel un utilisateur attendra lors d'une mauvaise connexion :

          # regles de passerelle www et gopher :
          http-gw:        userid          root
          http-gw:        directory       /jail
          http-gw:        timeout 90
          http-gw:        default-httpd   www.afs.net
          http-gw:        hosts           196.1.2.* -log { read write ftp }
          http-gw:        deny-hosts      *

  Le ssl-gw est juste une  passerelle  "gruyere".   Faites-y  attention.
  Dans  cet  exemple, j'autorise quiconque depuis le reseau protege a se
  connecter  en-dehors  du  reseau  sauf  les  adresses   127.0.0.*   et
  192.1.1.*,  puis seulement sur les ports 443 a 563.  Ces derniers sont
  les ports SSL connus :

          # ssl gateway rules:
          ssl-gw:  timeout 300
          ssl-gw:  hosts   196.1.2.* -dest { !127.0.0.* !192.1.1.* *:443:563 }
          ssl-gw:  deny-hosts *

  Voici  un  exemple  d'utilisation  de  plug-gw  pour   autoriser   des
  connexions  a  un  serveur  de nouvelles.  Dans cet exemple j'autorise
  quiconque depuis le reseau protege  a  se  connecter  seulement  a  un
  systeme et seulement sur son port de nouvelles.

  La  seconde  ligne permet au serveur de renvoyer ses donnees au reseau
  protege.

  Puisque de nombreux clients s'attendent a rester connecte pendant  que
  l'utilisateur  lit  les  nouvelles,  le  timeout  pour  un  serveur de
  nouvelles doit etre long :

          # passerelle plug-in pour les nouvelles :
          plug-gw: timeout 3600
          plug-gw: port nntp 196.1.2.* -plug-to 199.5.175.22 -port nntp
          plug-gw: port nntp 199.5.175.22 -plug-to 196.1.2.* -port nntp

  La passerelle finger est simple.  Quiconque depuis le  reseau  protege
  doit  se  connecter  d'abord,  puis  nous  l'autorisons  a utiliser le
  programme  finger  du  firewall.   Tout  autre  recoit  simplement  un
  message :

          # Autorise le service finger :
          netacl-fingerd: permit-hosts 196.1.2.* -exec /usr/libexec/fingerd
          netacl-fingerd: permit-hosts * -exec /bin/cat /usr/local/etc/finger.txt

  Je  n'ai  pas  configure  les  services  e-mail  ni  X-Window, donc je
  n'inclus pas les exemples.  Si  quelqu'un  dispose  d'un  exemple  qui
  fonctionne, qu'il me l'envoie par e-mail.

  77..44..22..  LLee ffiicchhiieerr iinneettdd..ccoonnff

  Voici   un   fichier   inetd.conf  complet.   Tous  les  services  non
  indispensables ont ete places en commentaire.  J'ai inclus le  fichier
  complet  pour  indiquer  quoi  desactiver,  ainsi  que  la  maniere de
  configurer les nouveaux services du firewall :

          #echo    stream tcp  nowait  root       internal
          #echo    dgram  udp  wait   root        internal
          #discard stream tcp  nowait  root       internal
          #discard dgram  udp  wait   root        internal
          #daytime stream tcp  nowait  root       internal
          #daytime dgram  udp  wait   root        internal
          #chargen stream tcp  nowait  root       internal
          #chargen dgram  udp  wait   root        internal
          # passerelle firewall FTP
          ftp-gw   stream tcp nowait.400 root /usr/local/etc/ftp-gw ftp-gw
          # passerelle firewall Telnet
          telnet   stream tcp nowait root /usr/local/etc/tn-gw /usr/local/etc/tn-gw
          # services locaux telnet
          telnet-a stream  tcp  nowait root /usr/local/etc/netacl in.telnetd
          # passerelle firewall Gopher
          gopher stream tcp nowait.400 root /usr/local/etc/http-gw /usr/local/etc/http-gw
          # passerelle firewall WWW
          http    stream tcp  nowait.400 root /usr/local/etc/http-gw /usr/local/etc/http-gw
          # passerelle firewall SSL
          ssl-gw stream tcp nowait root /usr/local/etc/ssl-gw ssl-gw
          # NetNews firewall proxy (using plug-gw)
          nntp stream tcp nowait root /usr/local/etc/plug-gw plug-gw nntp
          #nntp stream tcp nowait root /usr/sbin/tcpd in.nntpd
          # passerelle firewall SMTP (e-mail)
          #smtp stream tcp nowait root /usr/local/etc/smap smap
          #
          # Shell, login, exec et talk sont des protocoles BSD.
          #
          #shell stream tcp nowait root /usr/sbin/tcpd in.rshd
          #login stream tcp nowait root /usr/sbin/tcpd in.rlogind
          #exec  stream tcp nowait root /usr/sbin/tcpd in.rexecd
          #talk  dgram  udp wait   root /usr/sbin/tcpd in.talkd
          #ntalk dgram  udp wait   root /usr/sbin/tcpd in.ntalkd
          #dtalk stream tcp wait nobody /usr/sbin/tcpd in.dtalkd
          #
          # services Pop et e-mail imap et autres
          #
          #pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
          #pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
          #imap  stream tcp nowait root /usr/sbin/tcpd imapd
          #
          # Le service InterNet UUCP
          #
          #uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l
          #
          # Le service tftp sert essentiellement pour bouter. De nombreux sites
          # l'utilisent seulement sur les "serveurs de boot"
          # Ne pas decommenter sauf s'il vous le *faut*.
          #
          #tftp   dgram udp wait root /usr/sbin/tcpd in.tftpd
          #bootps dgram udp wait root /usr/sbin/tcpd bootpd
          #
          # Finger, systat et netstat donnent des informations qui peuvent etre
          # utiles a des "craqueurs de systemes" potentiels. De nombreux
          # sites coisissent de desactiver certains ou tous ces services
          # pour ameliorer la securite.
          #
          # cfinger est GNU finger, qui n'est pas utilise dans RHS Linux
          #
          finger   stream tcp nowait root  /usr/sbin/tcpd in.fingerd
          #cfinger stream tcp nowait root  /usr/sbin/tcpd in.cfingerd
          #systat  stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx
          #netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat -f inet
          #
          # Le service Time sert a la synchronisation des horloges.
          #
          #time stream tcp nowait root /usr/sbin/tcpd in.timed
          #time dgram  udp wait   root /usr/sbin/tcpd in.timed
          #
          # Authentification
          #
          auth    stream tcp wait   root /usr/sbin/tcpd in.identd -w -t120
          authsrv stream tcp nowait root /usr/local/etc/authsrv authsrv
          #
          # Fin de inetd.conf

  77..44..33..  LLee ffiicchhiieerr //eettcc//sseerrvviicceess

  C'est la que tout commence.   Lorsqu'un  client  se  connecte  sur  le
  firewall,  il  le  fait  sur  un  port  connu (inferieur a 1024).  Par
  exemple, telnet se connecte sur le port 23.  Le daemon  inetd  detecte
  cette  connexion  et  cherche  le  nom  du  service  dans  le  fichier
  /etc/services.  Ensuite, il lance le programme assigne au nom dans  le
  fichier /etc/inetd.conf.

  Certains  des services que nous creons ne sont pas normalement dans le
  fichier /etc/services.  Vous pouvez assigner a certains d'entre eux le
  port  que vous souhaitez.  Par exemple, j'ai assigne le port telnet de
  l'administrateur (telnet-a) sur le port 24.  Pous pouvez l'assigner au
  port  2323  si  vous  voulez.   Pour  que  l'administrateur  (VOUS) se
  connecte directement sur le firewall, il doit utiliser telnet  sur  le
  port  24 et non 23, et si vous parametrez votre netperm-table comme je
  l'ai fait, vous serez  seulement  capable  de  faire  cela  depuis  un
  systeme situe a l'interieur du reseau protege.

          telnet-a   24/tcp
          ftp-gw     21/tcp          # ce nom est modifie
          auth       113/tcp  ident  # Verification utilisateur
          ssl-gw     443/tcp

  88..  LLee sseerrvveeuurr pprrooxxyy SSOOCCKKSS

  88..11..  IInnssttaallllaattiioonn dduu sseerrvveeuurr pprrooxxyy

  Le     serveur     proxy     SOCKS     est     disponible     sur    :
  ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-
  src.tgz.   Il  ya aussi un exemple de fichier de configuration dans ce
  repertoire "socks-conf".  decompressez et "detarez" les fichiers  dans
  un  repertoire  de  votre  systeme, et suivez les instructions pour le
  confectionner.  J'ai eu quelques problemes pour le realiser.  Verifiez
  les Makefiles.

  Une  chose  importante  est que le serveur proxy doit etre ajoute dans
  /etc/inetd.conf.  Vous devez ajouter une ligne :

          socks  stream  tcp  nowait  nobody  /usr/local/etc/sockd  sockd

  pour indiquer au serveur de s'executer sur demande.

  88..22..  CCoonnffiigguurraattiioonn dduu sseerrvveeuurr pprrooxxyy

  Le programme de connexion necessite  deux  fichiers  de  configuration
  distincts  :  l'un  pour  indiquer  les  acces autorises, l'autre pour
  rediriger les requetes vers le serveur proxy  approprie.   Le  fichier
  d'autorisations d'acces doit se trouver sur le serveur.  Le fichier de
  routage peut etre  place  sur  n'importe  quelle  machine  Unix.   Les
  ordinateurs  DOS et, je pense, les Macintosh font leur propre routage.

  88..22..11..  LLee ffiicchhiieerr dd''aacccceess

  Avec socks4.2 beta, le fichier  d'acces  s'appelle  "sockd.conf".   Il
  doit  contenir  deux  lignes  : une ligne d'autorisations et une ligne
  d'interdictions.  Chaque ligne presente trois champs :

  +o  l'identificateur (permit ou deny)

  +o  l'adresse IP

  +o  le modificateur d'adresse

  L'identificateur est soit permit, soit deny.  Vous devez  avoir  aussi
  bien une ligne permit qu'une ligne deny.

  L'adresse  IP  contient  une  adresse  a  quatre  octets  en  notation
  classique IP, soit, par exemple, 192.168.2.0.

  Le masque de modification d'adresse est aussi  une  adresse  a  quatre
  octets en notation classique IP, et fonctionne comme un masque reseau.
  Representez-vous ce nombre sur 32 bits.  Si un bit est  a  1,  le  bit
  correspondant  de  l'adresse qu'il controle doit concorder avec le bit
  correspondant du champ de l'adresse IP.

  Par exemple, une ligne :

               permit 192.168.2.23 255.255.255.255

  autorisera  seulement  l'adresse  dont   chaque   bit   correspond   a
  192.168.2.23, donc seulement 192.168.2.23.

  Tandis que la ligne :

               permit 192.168.2.0 255.255.255.0

  autorisera  toute  adresse du groupe 192.168.2.0 a 192.168.2.255, soit
  tout le domaine de classe C.

  Il ne faut pas specifier la ligne :

               permit 192.168.2.0 0.0.0.0

  qui autoriserait toute adresse, sans distinction.

  Bien,  d'abord  autorisez  toute  adresse  que  vous  souhaitez,  puis
  interdisez   le  reste.  Pour  autoriser  quiconque  dans  le  domaine
  192.168.2.xxx, les lignes :

               permit 192.168.2.0 255.255.255.0
               deny 0.0.0.0 0.0.0.0

  fonctionneront tres bien. Notez le premier  "0.0.0.0"  dans  la  ligne
  "deny".   Avec  un  modificateur  de  0.0.0.0, le champ adresse IP n'a
  aucune importance.  Tous les champs a 0 est la norme, car c'est facile
  a ecrire.

  On peut utiliser plusieurs lignes de chaque type.

  Des utilisateurs specifiques peuvent aussi se voir accorder ou refuser
  l'acces.  Cela est realise par l'authentification d'identite. Tous les
  systemes  ne  supportent  pas  le  systeme  ident,  y  compris Trumpet
  Winsock, donc nous n'irons pas plus loin en ce qui concerne  cela.  La
  documentation de socks est tout a fait adequate.

  88..22..22..  LLee ffiicchhiieerr ddee rroouuttaaggee

  Le  fichier  de  routage de socks est betement nomme "socks.conf".  Je
  dis "betement", car il est si proche du nom du fichier  d'acces  qu'il
  est aise de les confondre.

  Le  fichier  de  routage sert a indiquer aux clients de socks quand il
  est necessaire d'utiliser celui-ci.  Par exemple, dans  notre  reseau,
  192.168.2.3 ne necessite pas l'usage de socks pour communiquer avec le
  firewall 192.168.2.1.  Il  a  une  connection  directe  Ethernet.   Il
  definit  127.0.0.1, le port de bouclage, automatiquement.  Evidemment,
  il n'est  pas necessaire d'utiliser socks pour  vous  parler  a  vous-
  meme.  Il y a trois entrees :

  +o  deny

  +o  direct

  +o  sockd

     L'entree  "deny"  indique a socks quand rejeter une requete.  Cette
     entree  a  les  trois  memes  champs  que  ceux  de  sockd.conf   :
     identificateur,  adresse  et modificateur.  Generalement, puisqu'il
     est aussi manipule par sockd.file, le  fichier  d'acces,  le  champ
     modificateur  est  positionne  a  0.0.0.0.   Si  vous  voulez  vous
     proteger de tout appel externe, vous pouvez le faire la.

  L'entree "direct" indique pour quelles adresses ne pas utiliser socks.
  Il  s'agit  des adresses pouvant etre atteintes sans le serveur proxy.
  A nouveau, nous avons les trois champs :  identificateur,  adresse  et
  modificateur.  Dans notre exemple, nous aurions :

               direct 192.168.2.0 255.255.255.0

  Donnant  ainsi  l'acces  direct  pour  toute  machine  de notre reseau
  protege.

  L'entree "sockd" indique a l'ordinateur l'emplacement du demon serveur
  de socks.  La syntaxe est la suivante :

               sockd @=<liste de serveurs> <adresse IP> <modificateur>

  Notez  l'entree @=.  Elle vous permet de configurer les adresses IP de
  plusieurs serveurs proxy.  Dans notre exemple, nous utilisons un  seul
  serveur  proxy,  mais vous pouvez en avoir plusieurs pour permettre un
  plus grand trafic et pour assurer une tolerance aux pannes.

  Les champs adresse IP et modificateur  fonctionnent  exactement  comme
  dans  les autres exemples.  Vous specifiez ainsi ou va quelle adresse.

  88..22..33..  DDNNSS ddeeppuuiiss ll''aarrrriieerree dd''uunn ffiirreewwaallll

  Configurer un service  de  noms  de  domaines  depuis  l'arriere  d'un
  firewall  est  une  tache  relativement simple.  En gros, il vous faut
  configurer le DNS sur la machine firewall.  Ensuite, indiquez a chaque
  machine deriere le firewall d'utiliser celui-ci.

  88..33..  TTrraavvaaiilllleerr aavveecc uunn sseerrvveeuurr pprrooxxyy

  88..33..11..  UUnniixx

  Pour faire fonctionner vos applications avec un serveur proxy, celles-
  ci  doivent  etre  "SOCK-ifiees".   Il   vous   faudra   deux   telnet
  differents  : un pour la communication directe, et un autre pour celle
  avec le serveur proxy.  Le paquetage socks  contient  des  indications
  pour SOCK-ifier un programme, ainsi qu'un certain nombre de programmes
  pre-SOCK-ifies.  Si vous utilisez la version SOCK-ifiee pour  aller  a
  un  emplacement direct, socks basculera automatiquement sur la version
  directe pour vous.  Pour cette raison, il nous faut renommer tous  les
  programmes  sur notre reseau protege et les remplacer par leur version
  SOCK-ifiee.   "Finger"   devient   "Finger.orig",   "telnet"   devient
  "telnet.orig", etc.  Vous devez indiquer chacun d'eux a socks a l'aide
  du fichier include/socks.

  Certains programmes traitent le  routage  et  la  SOCK-ification  eux-
  memes.   Netscape  est  l'un  d'entre  eux.   Vous  pouvez utiliser un
  serveur  proxy  sous  Netscape  en  donnant   l'adresse   du   serveur
  (192.168.2.1  dans le cas qui nous interesse) dans le champ SOCKs sous
  Proxies.  Chaque application necessite au moins un petit coup  d'oeil,
  quelle que soit son attitude vis-a-vis d'un serveur proxy.

  88..33..22..  MMSS WWiinnddoowwss aavveecc TTrruummppeett WWiinnssoocckk

  Trumpet   Winsock   contient  des  fonctionnalites  de  serveur  proxy
  incluses.  Dans le menu "setup", donnez l'adresse IP du serveur, ainsi
  que  celles  de tous les ordinateurs directement accessibles.  Trumpet
  se debrouillera alors avec tous les paquets sortants.

  88..44..  FFaaiirree ffoonnccttiioonnnneerr llee sseerrvveeuurr pprrooxxyy aavveecc lleess ppaaqquueettss UUDDPP

  Le paquetage socks fonctionne seulement avec les paquets TCP, pas avec
  les  UDP.   Cela  le  rend  quelque  peu  moins  utile.   De  nombreux
  programmes  tres  utiles,  comme  talk  et  Archie, utilisent UDP.  Il
  existe un paquetage prevu pour etre utilise comme serveur  proxy  pour
  les  paquets  UDP  appele  UDPrelay,  de Tom Fitzgerald fitz@wang.com.
  Malheureusement, a l'heure ou ces lignes sont ecrites,  il  n'est  pas
  compatible avec Linux.

  88..55..  IInnccoonnvveenniieennttss ddeess sseerrvveeuurrss pprrooxxyy

  Le  serveur  proxy  est,  avant  tout,  un  systeme  de securite.  Son
  utilisation pour augmenter le nombre d'acces Internet avec  un  nombre
  limite  d'adresses  aura  de nombreux inconvenients.  Un serveur proxy
  autorisera un plus grand acces de l'interieur du reseau  protege  vers
  l'exterieur,  mais  laissera  l'interieur  totalement  inaccessible de
  l'exterieur.  Ce qui implique aucun serveur, aucune connexion talk  ni
  Archie,  ni  e-mail  direct  vers les ordinateurs de l'interieur.  Ces
  inconvenients peuvent sembler legers, mais regardez-les  sous  l'angle
  suivant :

  +o  Vous  avez  laisse  un  document  en  cours  sur votre ordinateur a
     l'interieur du reseau protege.  Vous etes a la maison,  et  decidez
     que  vous  voulez  retravailler  celui-ci.   Vous ne le pouvez pas.
     Vous ne pouvez atteindre votre ordinateur, car il est  derriere  le
     firewall.  Vous essayez de vous loger d'abord sur le firewall, mais
     comme tout le monde a acces au serveur proxy, Persoinne ne  vous  a
     cree de compte dessus.

  +o  Votre  fille  va  a l'universite.  Vous souhaitez lui envoyer un e-
     mail.  Vous avez differents choses de caractere prive  a  discuter,
     et  prefereriez  recevoir  directement  votre  courrier  sur  votre
     machine.  Vous avez  pleine  confiance  dans  votre  administrateur
     reseau, mais, malgre tout, il s'agit de courrier prive.

  +o  L'impossibilite  d'utiliser  les  paquets  UDP  represente  un gros
     inconvenient  avec  les  serveurs  proxy.    Je   pense   que   les
     fonctionnalites UDP arriveront sous peu.

  FTP  cause  un  autre  probleme  avec les serveurs proxy : Lorsque FTP
  recupere un e liste de fichiers, le serveur ouvre une  socket  sur  la
  machine client pour lui anvoyer les informations.  Un serveur proxy ne
  permettra pas cela, donc FTP en particulier ne fonctionne pas.

  De plus, les serveurs proxy sont lents.  A cause de la degradation  du
  rapport  information/protocole,  n'importe  quel autre moyen d'obtenir
  cet acces sera plus rapide.

  En resume, si vous  avez  les  adresses  IP  necessaires,  et  que  la
  securite ne soit pas un imperatif pour vous, n'utilisez ni un firewall
  ni un serveur proxy.  Si vous n'avez pas suffisamment  d'adresses  IP,
  mais  que,  de  meme,  la securite n'est pas fondamentale, vous pouvez
  jeter un coup d'oeil aux emulateurs IP,  comme  Term,  Slirp  ou  TIA.
  Term  est  disponible  sur ftp://sunsite.unc.edu, Slirp est disponible
  sur ftp://blitzen.canberra.edu.au/pub/slirp et TIA est disponible  sur
  marketplace.com.   Ces  paquetages  iront  plus  vite,  permettront de
  meilleures connexions, et fourniront un acces superieur a  l'interieur
  du  reseau  depuis  InterNet.   Les serveur proxy sont utiles pour ces
  reseaux qui comportent de nombreuses machines se connectant au  vol  a
  InterNet, avec un setup et peu de travail ensuite.

  99..  CCoonnffiigguurraattiioonnss aavvaanncceeeess

  Je  voudrais  aborder une configuration particuliere avant de refermer
  ce  document.   Celle  que   j'ai   soulignee   precedemment   suffira
  probablement  pour  de  nombreux  cas.   Neammoins,  je  pense  que la
  situation  suivante  montrera  une  configuration  plus  avancee   qui
  eclaircira  certains  points  d'ombre.   S'il vous reste des questions
  apres ce que je viens de decrire, ou simplement que l'adaptabilite des
  serveurs proxy et des firewalls vous interesse, lisez encore.

  99..11..  UUnn ggrraanndd rreesseeaauu aavveecc sseeccuurriittee rreennffoorrcceeee

  Disons,  par  exemple, que vous etes le gourou de la secte de la 23eme
  Cabale de la Discorde du Milwaukee.  Vous souhaitez mettre votre  site
  en  reseau.   Vous  avez  cinquante  ordinateurs  et un sous-reseau de
  trente-deux adresses IP (sur cinq bits).  Vous avez differents niveaux
  d'acces.  Vous dites a vos disciples differentes choses en fonction de
  leur niveau.  C'est pourquoi vous devez proteger certaines parties  du
  reseau du reste.

  (NdT  :  Le  traducteur  a  conserve la 23eme Cabale de la Discorde du
  Milwaukee, issue du texte  initial,  contrairement  a  ce  qui  a  ete
  modifie   dans   les   versions  plus  recentes  (millisha  :  version
  militarisee) qui serait moins explicite du  principe  pour  un  public
  francophone).

  Les niveaux sont les suivants :

  1. Le  niveau exterieur.  C'est celui qui est montre a tout un chacun.
     En gros, c'est l'histoire et les ragots sur Eris, la divinite de la
     Discorde, et tout le reste du dogme.

  2. Sage.  C'est  le niveau des gens qui ont passe le niveau exterieur.
     C'est la que vous leur dites que la discorde  et  la  structure  ne
     font qu'un, et qu'Eris est aussi le dieu tout-puissant.

  3. Adepte.   C'est la que se trouve le plan reel.  Dans ce niveau sont
     stockees toutes les informations sur la maniere dont la  secte  des
     Discordiens  prendra  le  pouvoir  sur le monde, a l'aide d'un plan
     deviationniste, mais humoristique, impliquant PetitMou, HAL,  R2D2,
     Nounours  et  cinq  cents cristaux, tous marques "80585,9999999997"
     par erreur.

  99..11..11..  LLaa ccoonnffiigguurraattiioonn dduu rreesseeaauu

  Les numeros IP sont arranges ainsi :

  +o  l'adresse 192.168.2.255 est l'adresse de diffusion,  et  n'est  pas
     disponible ;

  +o  23  des  32  adresses  IP  sont  allouees  a 23 machines qui seront
     accessibles depuis InterNet ;

  +o  Une adresse IP  supplementaire  va  a  une  machine  Linux  sur  ce
     reseau ;

  +o  Une autre va a une autre machine Linux de ce reseau ;

  +o  2 numeros IP vont au routeur .

  +o  4  sont  laissees  libres, mais recoivent les noms de domaine paul,
     ringo, george et john, juste pour compliquer un peu les choses ;

  +o  Les reseaux proteges ont tous deux des adresses 192.168.2.xxx.

  Puis, deux reseaux separes sont  construits,  chacun  dans  une  piece
  differente.   Ils  sont routes par Ethernet infrarouge pour les rendre
  completement  invisibles  de  la  piece   exterieure.    Par   chance,
  l'Ethernet  infrarouge fonctionne tout a fait comme l'Ethernet normal,
  donc il nous suffit de les considerer comme normaux.
  Ces reseaux sont connectes chacun a sa machine Linux avec une  adresse
  IP supplementaire.

  Un  serveur  de fichiers relie les deux reseaux proteges.  C'est parce
  que les plans pour prendre le pouvoir sur le monde prennent en  compte
  certains  des  sages  les  plus  eleves.  Le serveur de fichiers a les
  adresses 192.168.2.17 pour le reseau des sages et 192.168.2.23 pour le
  reseau des adeptes.  Il doit avoir des adresses IP differentes, car il
  doit avoir deux cartes Ethernet differentes.  La transmission IP y est
  desactivee.

  La  transmission  IP est aussi desactivee sur les deux machines Linux.
  Le routeur ne transmettra pas les  paquets  destines  a  192.168.2.xxx
  sauf  si  on  lui  demande explicitement de le faire, donc InterNet ne
  pourra pas entrer.  La raison de la desactivation de  la  transmission
  IP  ici  est d'empecher les paquets du reseau des sages d'atteindre le
  reseau des adeptes, et vice versa.

  Le serveur NFS peut aussi etre  configure  pour  presenter  differents
  fichiers aux differents reseaux.  Cela peut devenir pratique, et assez
  astucieux d'utiliser les liens symboliques pour partager les  fichiers
  communs.  Cette configuration associee a une autre carte Ethernet peut
  ainsi permettre l'usage d'un seul serveur de fichiers pour  les  trois
  reseaux.

  99..11..22..  LLaa ccoonnffiigguurraattiioonn pprrooxxyy

  Maintenant, puisque les trois niveaux doivent etre capables de piloter
  le reseau pour leurs propres besoins deviationnistes, tous  les  trois
  ont  besoin  d'un  acces  InterNet.   Le reseau exterieur est connecte
  directement a celui-ci, donc nous n'avons pas a nous  preoccuper  d'un
  serveur proxy ici.  Les reseaux des sages et des adeptes sont derriere
  des firewalls, il est donc necessaire de leur configurer des  serveurs
  proxy.

  Les  deux  reseaux  seront configures de maniere similaire.  Tous deux
  ont les  memes  adresses  IP  assignees.   Je  vais  ajouter  quelques
  parametres, afin de rendre les choses encore plus interessantes :

  1. Personne  ne  peut  utiliser  le  serveur  de fichiers pour l'acces
     internet.  Cela exposerait le serveur  de  fichiers  aux  virus  et
     autres  choses  desagreables, et il est tres important, donc il est
     derriere les limites ;

  2. Nous ne voulons pas donner aux sages l'acces au World Wide Web.  Il
     sont  encore  en  entrainement,  et  cette  puissance  de recherche
     d'informations peut se reveler dangereuse.

  Ainsi, le fichier sockd.conf de la machine Linux des sages  contiendra
  cette ligne :

               deny 192.168.2.17 255.255.255.255

  Et sur la machine des adeptes :

               deny 192.168.2.23 255.255.255.255

  Et la machine Linux des sages contiendra cette ligne :

               deny 0.0.0.0 0.0.0.0 eq 80

  Cela  indique  l'interdiction d'acces pour toutes les machines tentant
  d'acceder au port 80, le port http.  Cela laisse l'acces  a  tous  les
  autres services, et interdit juste l'acces Web.

  Ensuite, les deux fichiers auront :

               permit 192.168.2.0 255.255.255.0

  pour   permettre  a  tous  les  ordinateurs  du  reseau  192.168.2.xxx
  d'utiliser ce serveur proxy sauf pour ceux  a  qui  cela  a  deja  ete
  interdit  (i.e.  le  serveur de fichiers et l'acces Web pour le reseau
  des sages).

  Le fichier sockd.conf du reseau des sages aura l'allure suivante :

               deny 192.168.2.17 255.255.255.255
               deny 0.0.0.0 0.0.0.0 eq 80
               permit 192.168.2.0 255.255.255.0

  et le fichier des adeptes aura celle-ci :

               deny 192.168.2.23 255.255.255.255
               permit 192.168.2.0 255.255.255.0

  Cela doit tout configurer correctement.  Chaque reseau est isole comme
  il  faut,  avec  le  niveau d'interaction approprie.  Chacun peut etre
  heureux.  Maintenant, prenez le pouvoir sur le monde !

