 |
|
10. Installare il proxy server TIS
10.1 Reperire il software
TIS FWTK è disponibile all'indirizzo http://www.tis.com/research/software/.
Non fate il mio stesso errore. Quando si prelevano i file da TIS, SI LEGGA IL README. TIS fwtk è "racchiuso" in una directory nascosta del loro server.
TIS richiede che venga letto il loro contratto all'indirizzo http://www.tis.com/research/software/fwtk_readme.html e che sia inviata, per apprendere il nome della directory nascosta un'email all'indirizzo fwtk-request@tislabs.com con presente, nel corpo del messaggio, la sola parola accepted
Nessun argomento è richiesto nell'oggetto. Il loro sistema provvederà a inviare il nome della directory (buona per 12 ore) dove poter prelevare il sorgente.
Al momento della stesura, la versione corrente di FWTK è la 2.1.
Ciò che ora rimane da fare è la configurazione del firewall.
10.2 Compilare TIS FWTK
La compilazione della versione 2.1 di FWTK è molto più semplice rispetto a qualsiasi altra versione precedente.
SPIEGA QUI!!!
Ora impartire make.
10.3 Installare TIS FWTK
Digitare make install.
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'.
10.4 Configurare TIS FWTK
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.
Esistono tre file che riguardano questi controlli:
- /etc/services
- Segnala al sistema a quali porte il servizio è presente
- /etc/inetd.conf
- Segnala a inetd quali programmi richiamare quando qualcuno bussa ad una determinata porta
- /usr/local/etc/netperm-table
- Specifica chi può accedere e chi no ai servizi
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.
Il file netperm-table
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.
In questo modo le persone possono identificarsi; il firewall utilizza un programma authsrv 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.
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, è '' authsrv: permit-hosts localhost.
# # 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
Per inizializzare il database e creare il record user administrative, effettuare un su root e avviare ./authsrv nella directory /var/local/etc. Qui è presente una semplice sezione.
Si legga la documentazione di FWTK per imparare come aggiungere utenti e gruppi.
#
# 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
#
I controlli del gateway telnet (tn-gw) sono i primi da impostare.
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).
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.
Il timeout Telnet dovrebbe essere mantenuto breve.
# 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
I comandi r funzionano allo stesso modo del telnet.
# 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
È consigliabile che nessuno possa accedere direttamente al firewall, incluso l'accesso in FTP. Pertanto, non si metta un server FTP sul proprio firewall.
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 }).
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à.
# 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 }
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.
La connessione Web dovrebbe essere tenuta breve. Viene inoltre effettuato un controllo sul tempo di attesa di un utente su una cattiva connessione.
# 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 *
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.
# 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 *
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.
La seconda riga consente al server news di ripassare i dati alla rete protetta.
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.
# 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
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.
# 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
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.
The /etc/services file
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.
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.
telnet-a 24/tcp ftp-gw 21/tcp # questo nome è cambiato auth 113/tcp ident # verifica dell'utente ssl-gw 443/tcp
Avanti Indietro Indice
Hosting by: hurra.com
Generated: 2007-01-26 17:56:19