<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>Firewalling and Proxy Server HOWTO: Installare il proxy server TIS</TITLE>
<LINK HREF="Firewall-HOWTO-11.html" REL=next>
<LINK HREF="Firewall-HOWTO-9.html" REL=previous>
<LINK HREF="Firewall-HOWTO.html#toc10" REL=contents>
</HEAD>
<BODY>
<A HREF="Firewall-HOWTO-11.html">Avanti</A>
<A HREF="Firewall-HOWTO-9.html">Indietro</A>
<A HREF="Firewall-HOWTO.html#toc10">Indice</A>
<HR>
<H2><A NAME="s10">10. Installare il proxy server TIS</A></H2>
<P>
<H2><A NAME="ss10.1">10.1 Reperire il software</A>
</H2>
<P>TIS FWTK è disponibile all'indirizzo <B>
<A HREF="http://www.tis.com/research/software/ ">http://www.tis.com/research/software/</A></B>.
<P><B>Non fate il mio stesso errore.</B>
Quando si prelevano i file da TIS, SI LEGGA IL README. TIS fwtk è "racchiuso" in una directory nascosta del loro server.
<P>TIS richiede che venga letto il loro contratto all'indirizzo
<A HREF="http://www.tis.com/research/software/fwtk_readme.html ">http://www.tis.com/research/software/fwtk_readme.html</A> e che sia <B>inviata, per apprendere il nome della directory nascosta
un'email all'indirizzo
<A HREF="mailto:fwtk-request@tislabs.com">fwtk-request@tislabs.com</A></B>
con presente, nel corpo del messaggio, la sola parola <B>accepted</B>
<P>Nessun argomento è richiesto nell'oggetto.
Il loro sistema provvederà a inviare il nome della directory (buona per 12 ore) dove poter prelevare il sorgente.
<P>Al momento della stesura, la versione corrente di FWTK è la 2.1.
<P>Ciò che ora rimane da fare è la configurazione del firewall.
<P>
<H2><A NAME="ss10.2">10.2 Compilare TIS FWTK</A>
</H2>
<P>
La compilazione della versione 2.1 di FWTK è molto più semplice rispetto a qualsiasi altra versione precedente.
<P>SPIEGA QUI!!!
<P>Ora impartire <B>make</B>.
<P>
<H2><A NAME="ss10.3">10.3 Installare TIS FWTK </A>
</H2>
<P>Digitare <B>make install</B>.
<P>La directory di default dell'installazione è /usr/local/etc.
E' possibile cambiarla (non l'ho fatto) con una più sicura.
Ho scelto di cambiare l'accesso a questa directory con 'chmod 700'.
<P>
<H2><A NAME="ss10.4">10.4 Configurare TIS FWTK</A>
</H2>
<P>
Ora comincia il vero divertimento. E' necessario imparare il sistema per chiamare questi nuovi servizi e creare le tabelle per controllarli.
Non ho intenzione qui di riscrivere il manuale di TIS FWTK, voglio solo mostrare le impostazioni che ho trovato
funzionanti e spiegare i problemi che ho incontrato e come li ho risolti.
<P>Esistono tre file che riguardano questi controlli:
<P>
<P>
<UL>
<LI>/etc/services
<UL>
<LI>Segnala al sistema a quali porte il servizio è presente</LI>
</UL>
</LI>
</UL>
<UL>
<LI>/etc/inetd.conf
<UL>
<LI>Segnala a inetd quali programmi richiamare quando qualcuno bussa ad una determinata porta </LI>
</UL>
</LI>
</UL>
<UL>
<LI>/usr/local/etc/netperm-table
<UL>
<LI>Specifica chi può accedere e chi no ai servizi</LI>
</UL>
</LI>
</UL>
<P>Perché FWTK funzioni, è necessario modificare questi file da principio.
Modificare i file dei servizi senza che siano impostati correttamente i file inetd.conf o netperm-table
può rendere il proprio sistema inaccessibile.
<P>
<H3>Il file netperm-table </H3>
<P>
Questo file controlla chi può accedere ai servizi di TIS FWTK. Il traffico si può considerare
diretto ad entrambi i lati del firewall.
Le persone all'esterno della propria rete dovrebbero identificarsi prima di poter guadagnare
l'accesso, mentre agli utenti della rete locale dovrebbe essere consentito di passare.
<P>In questo modo le persone possono identificarsi; il firewall utilizza un programma <B>authsrv</B> per mantenere un database
delle user ID e delle password. La sezione della netperm-table riguardante l'autenticazione controlla dove è collocato il database e
chi vi può accedere.
<P>Ho avuto alcuni problemi nel chiudere l'accesso a questo servizio. Nota infatti la presenza nella linea permit-hosts del carattere "*" usato
per consentire l'accesso a chiunque.
L'impostazione corretta di questa linea, se vi dovesse funzionare, è '' <CODE>authsrv: permit-hosts localhost</CODE>.
<P>
<PRE>
#
# Tabella di configurazione del proxy
#
# server di autenticazione e regole clienti
authsrv: database /usr/local/etc/fw-authdb
authsrv: permit-hosts *
authsrv: badsleep 1200
authsrv: nobogus true
# Applicazioni client che utilizzano il server authentication
*: authserver 127.0.0.1 114
</PRE>
<P>Per inizializzare il database e creare il record user administrative, effettuare un su root
e avviare <B>./authsrv</B> nella directory /var/local/etc.
Qui è presente una semplice sezione.
<P>Si legga la documentazione di FWTK per imparare come aggiungere utenti e gruppi.
<PRE>
#
# 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
#
</PRE>
<P>I controlli del gateway telnet (tn-gw) sono i primi da impostare.
<P>Nell'esempio, autorizzo gli host presenti all'interno della rete privata
a passare senza autenticarsi (permit-hosts 19961.2.* -passok).
Ogni altro utente invece dovrà inserire il proprio user ID e
la password per utilizzare il proxy (permit-hosts * -auth).
<P>Inoltre, consento ad un altro sistema (196.1.2.202) di accedere
direttamente al firewall senza passare attraverso il firewall
stesso. Le due righe inetacl-in.telnetd servono a definire questo. Più avanti
sarà spiegato come queste righe sono richiamate.
<P>Il timeout Telnet dovrebbe essere mantenuto breve.
<P>
<PRE>
# regole del gateway 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
# Solo l'amministratore può effettuare telnet direttamente al Firewall
# tramite la Porta 24
netacl-in.telnetd: permit-hosts 192.1.2.202 -exec /usr/sbin/in.telnetd
</PRE>
<P>I comandi r funzionano allo stesso modo del telnet.
<P>
<PRE>
# rlogin gateway rules:
# regole gateway 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
# Solo l'Amministratore può eseguire direttamente il telnet al Firewall
netacl-rlogind: permit-hosts 192.1.2.202 -exec /usr/libexec/rlogind -a
</PRE>
<P>È consigliabile che nessuno possa accedere direttamente al firewall,
incluso l'accesso in FTP. Pertanto, non si metta un server FTP sul
proprio firewall.
<P>Inoltre, la riga permit-hosts consente a chiunque all'interno della rete
protetta di accedere liberamente ad Internet, mentre tutti gli altri
devono autenticarsi. Ai miei controlli sono stati aggiunti il log di ogni
file inviato e ricevuto (-log { retr stor }).
<P>Il timeout ftp controlla quanto tempo ci vuole per far cadere una
cattiva connessione come pure quanto a lungo può rimanere aperta una
connessione senza attività.
<P>
<PRE>
# regole gateway 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 }
</PRE>
<P>I web, gopher e browser basati su ftp sono stravolti dall'http-gw. Le
prime due righe creano una directory dove poter memorizzare i documenti
ftp e web esattamente come passano attraverso il firewall. Ho reso questi file di
proprietà di root e li ho collocati in una directory accessibile solo dal
root.
<P>La connessione Web dovrebbe essere tenuta breve. Viene inoltre effettuato un controllo
sul tempo di attesa di un utente su una cattiva connessione.
<P>
<PRE>
# regole gateway www e 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 *
</PRE>
<P>ssl-gw è di fatto un semplice gateway "passatutto". Prestategli
attenzione. In questo esempio consento a tutti all'interno
della rete protetta di connettersi a qualsiasi server al di fuori
della rete, fatta eccezione per gli indirizzi 127.0.0.* e 192.1.1.*, e
solo sulle porte da 443 a 563. Le porte da 443 a 563 sono
conosciute come porte SSL.
<P>
<PRE>
# regole gateway ssl:
ssl-gw: timeout 300
ssl-gw: hosts 192.1.2.* -dest { !127.0.0.* !192.1.1.* *:443:563 }
ssl-gw: deny-hosts *
</PRE>
<P>Segue un esempio di come utilizzare il plug-gw per consentire
connessioni ad un server news. Nell'esempio, si abilitano tutti gli
utenti all'interno della rete privata a connettersi ad un solo sistema e
solo alla sua porta news.
<P>La seconda riga consente al server news di ripassare i
dati alla rete protetta.
<P>Dal momento che la maggior parte dei client si aspettano di restare
connessi mentre gli utenti leggono le news, il timeout per un server
di news dovrebbe essere lungo.
<PRE>
# NetNews Pluged gateway
plug-gw: timeout 3600
plug-gw: port nntp 192.1.2.* -plug-to 24.94.1.22 -port nntp
plug-gw: port nntp 24.94.1.22 -plug-to 192.1.2.* -port nntp
</PRE>
<P>Il gateway finger è semplice. Chiunque dall'interno della rete protetta
deve prima di tutto eseguire il login e solo dopo può ottenere l'abilitazione a
utilizzare il programma finger sul firewall. Tutti gli altri invece ricevono
semplicemente un messaggio.
<P>
<PRE>
# Abilitazione del servizio finger
netacl-fingerd: permit-hosts 192.1.2.* -exec /usr/libexec/fingerd
netacl-fingerd: permit-hosts * -exec /bin/cat /usr/local/etc/finger.txt
</PRE>
<P>Non ho impostato i servizi Mail e X-windows pertanto non aggiungo
degli esempi in merito. Se qualcuno possiede un esempio funzionante è
pregato di inviarmi un'email.
<P>
<H3>The /etc/services file</H3>
<P>
Qui è dove tutto comincia.
Quando un client si connette al firewall lo fa su una porta conosciuta
(minore di 1024). Ad esempio telnet si connette sulla porta 23. Il
demone inetd "sente" questa connessione e cerca il nome di questo servizio
nel file /etc/services. Quindi, richiama il programma assegnato al
nome nel file /etc/inetd.conf.
<P>Alcuni dei servizi che stiamo creando non si trovano normalmente nel
file /etc/services. È possibile assegnare alcuni di essi ad una porta
qualsiasi. Ad esempio, ho assegnato la porta corrispondente al telnet
dell'amministratore (telnet-a) alla porta 24. Volendo, lo si può
assegnare alla porta 23. Affinché l'amministratore (ossia voi stessi)
possa connettersi direttamente al firewall è necessario eseguire il
telnet alla porta 24 e non alla 23, e se il file netperm-table viene
impostato, come ho fatto io, sarà possibile farlo solamente da un
sistema all'interno della propria rete protetta.
<P>
<P>
<PRE>
telnet-a 24/tcp
ftp-gw 21/tcp # questo nome è cambiato
auth 113/tcp ident # verifica dell'utente
ssl-gw 443/tcp
</PRE>
<P>
<P>
<HR>
<A HREF="Firewall-HOWTO-11.html">Avanti</A>
<A HREF="Firewall-HOWTO-9.html">Indietro</A>
<A HREF="Firewall-HOWTO.html#toc10">Indice</A>
</BODY>
</HTML>
