Page suivante Page précédente Table des matières

10. Installer le serveur mandataire TIS

10.1 Trouver le logiciel

Le TIS fwtk est disponible à http://www.tis.com/research/software/.

Ne commettez pas l'erreur que j'ai commise : lorsque vous téléchargez les fichiers de TIS, LISEZ LES README. Le TIS fwtk est verrouillé dans un répertoire caché sur leur serveur.

TIS impose que vous lisiez leur accord à

http://www.tis.com/research/software/fwtk_readme.html, puis que vous envoyiez un courriel à fwtk-request@tislabs.com avec le seul mot accepted dans le corps du message pour connaître le nom de ce répertoire caché. Aucun sujet n'est nécessaire pour ce message. Leur système vous enverra en retour le nom du répertoire par courriel (valaple 12 heures) pour charger le source.

A l'instant où j'écris, la version à jour du FWTK est 2.1.

10.2 Compilation du FWTK TIS

La version 2.1 du FWTK se compile beaucoup plus facilement que les précédentes.

EXPLIQUER ICI !!!

Maintenant, lancez make.

10.3 Installation du FWTK TIS

Lancez make install.

Le répertoire d'installation par défaut est /usr/local/etc. Il est possible de changer cela (ce que je n'ai pas fait) vers un répertoire plus sûr. J'ai choisi de changer l'accès à ce répertoire pour le mode "0700".

Tout ce qu'il reste à faire maintenant est de configurer le pare-feu.

10.4 Configuration du FWTK TIS

Maintenant, le plaisir commence vraiment. Nous devons enseigner au système à appeler ces nouveaux services et créer les tables pour les contrôler.

Je ne suis pas en train de ré-écrire le manuel de TIS fwtk ici. Je vais montrer les paramètres que j'ai fait fonctionner et expliquer les problèmes que j'ai rencontrés et comment je les ai contournés.

Trois fichiers définissent ces contrôles :

Pour faire fonctionner fwtk, vous devez éditer 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 système inaccessible.

Le fichier netperm-table

Ce fichier contrôle qui a accès aux services de TIS FWTK. Vous devez penser au trafic qui passe par le pare-feu depuis les deux côtés. Les gens de l'extérieur de votre réseau doivent s'identifier avant d'obtenir l'accès, mais ceux de l'intérieur doivent être autorisés simplement à passer au-travers.

Afin que les gens puissent s'identifier, le pare-feu utilise un programme appelé authsrv pour maintenir une base des noms et mots de passe. La section authentification de netperm-table contrôle l'emplacement et l'accès à la base.

J'ai eu quelques difficultés à fermer l'accès à ce service. Notez que la ligne permit-hosts que je montre utilise un "*" pour donner l'accès à tout le monde. Le paramétrage correct de cette ligne est : authsrv: permit-hosts localhost, si vous arrivez à la faire fonctionner.

        #
        # Table de configuration du mandataire
        #
        # 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 ./authsrv dans le répertoire /var/local/etc pour créer l'enregistrement de l'utilisateur d'administration.

La documentation de FWTK indique la manière 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 contrôles de la passerelle telnet (tn-gw) vont de soi et sont la première chose que vous deviez configurer.

Dans mon exemple, j'autorise une machine du réseau privé à 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 mandataire (permit-hosts * -auth).

J'autorise aussi un autre système (192.1.2.202) à accéder au pare-feu directement sans passer du tout par celui-ci. Les deux lignes inetacl-in.telnetd font cela. J'expliquerai plus loin comment ces lignes sont utilisées.

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 192.1.2.* -passok -xok
        tn-gw:          permit-hosts * -auth
        # Seul l'administrateur peut telneter directement le pare-feu
        # sur le port 24
        netacl-in.telnetd: permit-hosts 192.1.2.202 -exec /usr/sbin/in.telnetd

Les commandes "r-" fonctionnent de la même manière que 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 192.1.2.* -passok -xok
        rlogin-gw:      permit-hosts * -auth -xok
        # Seul l'administrateur peut telneter directement le pare-feu
        # sur le port
        netacl-rlogind: permit-hosts 192.1.2.202 -exec /usr/libexec/rlogind -a

Personne ne devrait avoir accès directement au pare-feu, et cela inclut FTP, donc ne placez pas de serveur FTP sur votre pare-feu.

À nouveau, la ligne permit-hosts autorise quiconque depuis le réseau protégé à accéder librement à InterNet et tous les autres utilisateurs doivent s'authentifier. J'ai ajouté la trace de chaque fichier envoyé et reçu dans mes contrôles (-log { retr stor }).

Le timeout FTP contrôle le temps mis à fermer une mauvaise connexion, ainsi que le temps d'inactivité 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 192.1.2.* -log { retr stor }
        ftp-gw:         permit-hosts * -authall -log { retr stor }

Le web, gopher et le ftp fondé sur un butineur sont contrôlés par le http-gw. Les deux premières lignes créent un répertoire pour stocker les documents ftp et web lorsqu'ils passent au-travers du pare-feu. Je rends root propriétaire de ces fichiers et je les place dans un répertoire accessible seulement par root.

La connexion web doit être maintenue courte. Elle contrôle 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           192.1.2.* -log { read write ftp }
        http-gw:        deny-hosts      * 

Le ssl-gw est juste une passerelle "gruyère". Faites-y attention. Dans cet exemple, j'autorise quiconque depuis le réseau protégé à se connecter en-dehors du réseau sauf les adresses 127.0.0.* et 192.1.1.*, puis seulement sur les ports 443 à 563. Ces derniers sont les ports SSL connus :

        # Regles de passerelle SSL :
        ssl-gw:  timeout 300
        ssl-gw:  hosts   192.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 à un serveur de nouvelles. Dans cet exemple j'autorise quiconque depuis le réseau protégé à se connecter seulement à un système et seulement sur son port de nouvelles.

La seconde ligne permet au serveur de renvoyer ses données au réseau protégé.

Puisque de nombreux clients s'attendent à rester connectés pendant que l'utilisateur lit les nouvelles, le timeout pour un serveur de nouvelles doit être long :

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

La passerelle finger est simple. Quiconque depuis le réseau protégé doit se connecter d'abord, puis nous l'autorisons à utiliser le programme finger du pare-feu. Tout autre reçoit simplement un message :

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

Je n'ai pas configuré les services courriel 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 courriel.

Le fichier /etc/services

C'est là que tout commence. Lorsqu'un client se connecte sur le pare-feu, il le fait sur un port connu (inférieur à 1024). Par exemple, telnet se connecte sur le port 23. Le daemon inetd détecte cette connexion et cherche le nom du service dans le fichier /etc/services. Ensuite, il lance le programme assigné au nom dans le fichier /etc/inetd.conf.

Certains des services que nous créons ne sont pas normalement dans le fichier /etc/services. Vous pouvez assigner à certains d'entre eux le port que vous souhaitez. Par exemple, j'ai assigné 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 pare-feu, il doit utiliser telnet sur le port 24 et non 23 et si vous paramétrez votre netperm-table comme je l'ai fait, vous serez seulement capable de faire cela depuis un système situé à l'intérieur du réseau protégé.

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


Page suivante Page précédente Table des matières