Avanti Indietro Indice

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:

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