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.
La version 2.1 du FWTK se compile beaucoup plus facilement que les précédentes.
EXPLIQUER ICI !!!
Maintenant, lancez make.
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.
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.
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.
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