<!doctype linuxdoc system>

<article OPTS="italian">

<title>Firewalling and Proxy Server HOWTO</title>
<author>Mark Grennan, 
<tt>mark@grennan.com</tt>
<date>v0.80, Feb. 26, 2000

<abstract>                 

Questo documento si propone di insegnare le basi dei sistemi firewall e
di fornire alcuni dettagli sull'impostazione dei firewall per
filtering e proxy su un sistema Linux. All'indirizzo
<em>http://www.grennan.com/Firewall-HOWTO.html</em> è disponibile una
versione HTML di questo documento.  
</abstract>

<toc>

<sect>Introduzione
<P>
David Rudder ha scritto la versione originale di questo
Firewall-HOWTO, oramai molte lune fa, e vorrei ancora ringraziarlo per
avermi permesso di aggiornare il suo lavoro.

Vorrei inoltre ringraziare Ian Gough per la gentile assistenza prestata a codesto autore dislessico.

I firewall hanno guadagnato una grande popolarità come ultima novità
in fatto di sicurezza in Internet. Come accade per tutte
le cose che hanno successo, insieme alla fama sono iniziate le
incomprensioni. 
Questo HOWTO spiegherà i concetti base su cosa sia un firewall e 
come impostarne uno.

Personalmente sto utilizzando il kernel 2.2.13 e la RedHat 6.1 per lo
sviluppo di questo howto, e quindi gli esempi qui presenti sono basati
su questa distribuzione.  Se nella propria distribuzione si trovano
delle differenze, invito ad informarmi via email così provvederò ad
aggiornare il documento.

<sect1>Commenti
<p>
Qualsiasi commento è più che benvenuto. <bf>SIETE PREGATI DI
COMUNICARE OGNI INESATTEZZA CONTENUTA IN QUESTO DOCUMENTO!!!</bf> Sono
un essere umano e come tale incline a commettere degli errori. Se ne
riscontrate, renderli noti è nel mio interesse. Cercherò di rispondere
a tutte le e-mail, ma poiché sono molto occupato, non offendetevi se
non potrò farlo.   

<em>Il mio indirizzo email è <bf><url url="mailto:mark@grennan.com" name =
"mark@grennan.com"</bf></em> 

<sect1>Liberatoria
<p>
<bf>NON SONO RESPONSABILE DI EVENTUALI DANNI CAUSATI DA AZIONI
INTRAPRESE BASANDOSI SUL CONTENUTO DI QUESTO DOCUMENTO</bf>. Deve
essere visto come un'introduzione alle modalità di funzionamento dei
firewall e dei proxy server. Non sono, e non pretendo di esserlo, un
esperto di sicurezza. ;-) Sono solo una persona che ha letto troppo e
che ama i computer più di molta altra gente. Vi prego di capire che
sto scrivendo questo documento per aiutare la gente ad informarsi
sull'argomento, ma non sono pronto a scommettere la mia vita
sull'accuratezza del suo contenuto.  

<sect1>Copyright (in inglese)
<p>
Unless otherwise stated, Linux HOWTO documents are copyrighted by
their respective authors. Linux HOWTO documents may be reproduced and
distributed in whole or in part, in any medium physical or electronic,
as long as this copyright notice is retained on all copies. Commercial
redistribution is allowed and encouraged; however, the author would
like to be notified of any such distributions. 
 
All translations, derivative works, or aggregate works incorporating
any Linux HOWTO documents must be covered under this copyright
notice. That is, you may not produce a derivative work from a HOWTO
and impose additional restrictions on its distribution. Exceptions to
these rules may be granted under certain conditions; please contact
the Linux HOWTO coordinator. 

In short, we wish to promote dissemination of this information through
as many channels as possible. However, we do wish to retain copyright
on the HOWTO documents, and would like to be notified of any plans to
redistribute the HOWTOs. 
 
If you have any questions, please email me. (See Above)

<sect1>Perché ho scritto questo documento
<p>
Diversi anni fa, mentre lavoravo per lo Stato dell'Oklahoma come loro
&dquot;Amministratore Internet&dquot; mi è stato chiesto di
&dquot;mettere lo Stato su Internet&quot;, in pratica senza fondi
(nota: al tempo non c'era un tale titolo, ero solamente un tipo che
faceva tutto il lavoro).  Il miglior modo affinché questa cosa
si potesse realizzare era di usare quanto più software libero e hardware di
recupero fosse possibile.  Linux e una manciata di vecchi 486 era tutto
quello di cui disponevo.
 
I firewall commerciali sono MOLTO sovrapprezzo e la documentazione sul
loro funzionamento è considerata quasi top secret. Ho scoperto che
crearmi da solo un firewall era praticamente impossibile.

Al mio lavoro successivo mi è stato chiesto di inserire un 
firewall. Linux aveva appena aggiunto il codice per l'implementazione, così
ancora senza fondi, ho cominciato a realizzarne uno con
Linux. Sei mesi dopo il mio firewall era a posto e questo documento è
stato aggiornato.

<sect1>Letture aggiuntive
<p>
<itemize>
<item><url url="http://sunsite.unc.edu/mdw/HOWTO/Networking-Overview-HOWTO.html" name="The Linux Networking Overview HOWTO">

<item><url url="http://sunsite.unc.edu/mdw/HOWTO/Ethernet-HOWTO.html" name="The Ethernet HOWTO"> 

<item><url url="http://ipchains.nerdherd.org/" name="IPchains Firewalling made Easy!"> 

<item><url url="http://www.linas.org/linux/load.html" name="Linux Network Address Translation"> 

<item><url url="http://sunsite.unc.edu/mdw/HOWTO/NET-3-HOWTO.html" name="The Net-3 HOWTO"> 

<item><url url="http://sunsite.unc.edu/mdw/HOWTO/PPP-HOWTO.html" name="The NET-PPP HOWTO"> 

<item><url url="http://vtun.netpedia.net/" name="The easiest way to create Virtual Tunnels over TCP/IP networks"

</itemize>

[ Altre URL sono da collocare qui ]

<sect>Capire i Firewall
<P>
Un firewall ("parete tagliafuoco") è una struttura intesa ad impedire la
diffusione del fuoco.  Negli edifici i firewall sono i muri in mattone
che dividono completamente le sezioni. In un auto un firewall è la parete 
metallica che separa l'abitacolo dal motore.

I firewall di Internet sono intesi per tenere le fiamme dell'inferno
di Internet fuori dalla propria LAN privata, oppure per conservare i
membri della propria LAN puri e casti negandogli l'accesso a tutte le
tentazioni della diabolica Internet. ;-)

Il primo computer firewall era un host Unix non instradante con
connessioni a due reti diverse. Una scheda di rete era connessa ad
Internet e l'altra ad una LAN privata.
Per raggiungere Internet dalla rete privata, si doveva effettuare il login 
sul server firewall (Unix).
Poi si utilizzavano le risorse del sistema per accedere ad Internet.
Per esempio, si poteva usare X-Windows per lanciare il browser
Netscape nel sistema firewall e poi esportare il display sulla propria
workstation. Il browser in funzione sul firewall aveva quindi accesso ad
entrambe le reti. 

Questo tipo di sistema "dual homed" (un sistema con due connessioni di
rete) è una gran cosa se ci si può FIDARE DI TUTTI i propri utenti.
Si potrebbe quindi semplicemente configurare un sistema Linux e dare un account a
chiunque abbia bisogno di accedere ad Internet. Con questa
impostazione, il solo computer nella propria rete privata che sa
qualcosa del mondo esterno è il firewall. Nessuno può scaricare
qualcosa sulla workstation personale, si deve prima scaricare un
file sul firewall e poi scaricarlo dal firewall nella propria
workstation.

NOTA IMPORTANTE: il 99% delle irruzioni iniziano guadagnando l'accesso
a livello utente sul sistema da attaccare.  Per questo motivo non
raccomando questo tipo di firewall. Inoltre è molto limitante.

<sect1>Politiche di Firewall
<p> 
Non si creda che il firewall sia tutto quello di cui si ha
bisogno. <em>Per prima cosa si decidano delle politiche</em>.
 
I firewall sono usati con due scopi:

<enum> 
<item> tenere fuori la gente (worm / cracker).
<item> tenere dentro la gente (dipendenti / bambini). 
</enum>
 
Quando ho iniziato a lavorare sui firewall mi sorpresi di scoprire che
la compagnia per la quale lavoravo era più interessata a
&dquot;spiare&dquot; i propri dipendenti che a tenere fuori dalla
propria rete i cracker.
 
Almeno nel mio stato (Oklahoma) i datori di lavoro hanno il diritto di
cominciare a controllare le chiamate telefoniche e l'attività Internet non appena
informati i propri dipendenti.
 
Il Grande Fratello non è il governo. Grande Fratello = Grande Business.
 
Non mi si fraintenda.  La gente dovrebbe lavorare, non giocare mentre
è al lavoro. E sento che l'etica nel lavoro si sta sgretolando.
Comunque, ho osservato anche che i tipi del management sono i primi ad
abusare delle regole da loro imposte.
Ho visto continui rimproveri diretti a lavoratori perché cercavano, per andare al lavoro,
gli itinerari dei bus su Internet, quando poi gli stessi manager spendevano ore 
cercando ristoranti raffinati o nightclub per ricevere potenziali clienti. 

La mia soluzione per questo tipo di abusi consiste nel pubblicare su una pagina Web,
a disposizione di chiunque, i log del firewall.

L'affare sicurezza può essere spaventoso. Se amministri un firewall, guardati le spalle.

<sect2>Come determinare una politica per la sicurezza
<p>
Ho consultato diversa documentazione di rilievo su come creare una politica per la sicurezza.
Dopo anni di esperienza posso adesso affermare: non si creda ad una parola.
Creare una politica è semplice.

<P>
<enum>
<item> determinare quali servizi si ha bisogno 
<item> determinare il gruppo di persone che si vuole servire
<item> determinare a quali servizi ogni gruppo ha necessità di accedere
<item> per ciascun gruppo descrivere come si potrebbe rendere sicuro il servizio
<item> scrivere un'espressione che renda tutte le altre forme di accesso una violazione
</enum>

La politica diventerà sempre più complicata nel tempo, però ora non si provi a coprire troppi aspetti. 
La si realizzi semplice e chiara.

<sect1>Tipi di Firewall
<P>
Esistono due tipologie di firewall.

<enum>
<item>Firewall Filtranti - che bloccano i pacchetti di rete
selezionati. 
<item>Proxy Server (talvolta detti firewall) - che fanno le
connessioni di rete per voi. 
</enum>

<sect2>Firewall Filtranti (Packet Filtering Firewall)
<P>
Il Packet Filtering è il tipo di firewall presente nel kernel Linux.
 
Un firewall filtrante funziona a livello di rete.  È permesso ai dati
di lasciare il sistema solo se lo permettono le regole del firewall.
Come i pacchetti arrivano sono poi filtrati in base alle informazioni sul
tipo, sull'indirizzo di provenienza, sull'indirizzo di destinazione e
sulle porte contenute in ciascuno di essi. 

Molti router di rete hanno l'abilità di effettuare alcuni servizi di
firewall. Un firewall filtrante può essere pensato come un tipo
particolare di router. Per questo motivo è necessaria una profonda
conoscenza della struttura dei pacchetti IP per lavorarci.

Poiché sono analizzati e registrati pochissimi dati, i firewall
filtranti occupano meno la CPU, e creano minor latenza nella propria
rete. 

I firewall filtranti non forniscono un controllo a livello di
password. Gli utenti non possono identificarsi.  La sola identità che
un utente ha consiste nel numero IP assegnato alla sua macchina.  Ciò può
essere un problema se si intende usare DHCP (assegnazione dinamica
dell'IP).  Poiché le regole sono basate sui numeri IP, dovranno essere
aggiustate non appena saranno assegnati nuovi numeri. 
Non saprei come automatizzare questo processo.

I firewall filtranti sono più trasparenti per gli utenti.  L'utente
non deve impostare regole nella sua applicazione per utilizzare
Internet. Con la maggioranza dei proxy server questo non è vero.

<sect2>Proxy Server
<P>
I Proxy sono principalmente usati per controllare, o monitorare, il
traffico. Alcuni proxy di applicazioni possono fare la cache dei dati
richiesti, ciò abbassa le richieste di banda e diminuisce il tempo
d'accesso per il successivo utente che vuole accedere a quegli stessi
dati.  Inoltre fornisce un'evidenza inequivocabile su quanto è stato
trasferito. 

Esistono due tipi di proxy server.
<enum>
<item>Application Proxy (Proxy di Applicazione) - che fanno il lavoro
al nostro posto.
<item>Proxy SOCKS  - che "incrociano" le comunicazioni.
</enum>
 
<sect2>Application Proxy
<p> 
Il miglior esempio è quello di una persona che effettua un telnet su un altro
computer e poi da qui al resto del mondo.  Solo con un proxy server di
applicazione il processo è automatizzato.  Non appena si fa telnet
verso l'esterno il client per prima cosa vi manda al proxy.  Il proxy
poi si connette al server che si è richiesto (il mondo esterno) e
restituisce i dati.

Poiché i proxy server gestiscono tutte le comunicazioni, possono
registrare qualsiasi cosa vogliono (si vuole).  Per i proxy HTTP (web)
ciò può includere qualsiasi URL che si visita, per i proxy FTP
qualsiasi file si scarica.  Possono anche filtrare parole
&dquot;inappropriate&dquot; dai siti che si visitano o controllare la
presenza di virus.

Gli application proxy server possono autenticare gli utenti. Prima di
effettuare una connessione verso l'esterno, il server può richiedere all'utente, per prima cosa,
di effettuare il login.  Ad un utilizzatore del web ciò comporterà la necessità di un login 
per ogni sito che desidera visitare.

<sect2>Proxy SOCKS
<p>
Un server SOCKS è molto simile ad una vecchia switch board.
Semplicemente incrocia, attraverso il sistema, i "cavi" della propria connessione con un'altra 
connessione esterna.  

La maggior parte dei server SOCKS funziona solamente con connessioni di
tipo TCP e come i firewall filtranti non fornisco l'autenticazione
degli utenti. Possono comunque registrare dove si è connesso ogni
utente. 

<sect>Architettura dei Firewall
<p> 
Si può strutturare la propria rete in un sacco di modi per
proteggere il proprio sistema usando un firewall.

Se si ha una connessione dedicata ad Internet attraverso un router, si
potrebbe collocare il router direttamente nel proprio sistema firewall.
Oppure si potrebbe passare attraverso un hub ("concentratore") per fornire
server a pieno accesso fuori dal proprio firewall.

<sect1> Architettura Dial-up
<p>
Probabilmente si sta facendo uso di un servizio dialup, quale una linea ISDN.  In questo
caso si potrebbe utilizzare una terza scheda di rete per fornire un DMZ
filtrato. Questo dà il pieno controllo sui propri servizi Internet e
li separa dalla propria rete normale.

<verb>
                  __________
   _/\__/\_      |          |          _______________
  |        |     | Sistema  |  (LAN)  |               |
 / Internet \----| Firewall |--(HUB)--| Workstation/s |
 \_  _  _  _/    |__________|         |_______________|
   \/ \/ \/           |
                    (DMZ)
                    (HUB)
</verb>

<sect1> Architettura a Router singolo 

<P>
Caso in cui è presente, tra voi ed Internet, un router o un modem.
Se si possiede il router si potrebbero impostare alcune rigide regole di filtraggio, 
altrimenti se il router appartiene al proprio ISP, si potrebbe richiederne l'inserimento. 

<verb>
                  ________           __________
   _/\__/\_      | Router |         |          |          _______________
  |        |     | oppure |  (DMZ)  | Sistema  |  (LAN)  |               |
 / Internet \----| Modem  |--(HUB)--| Firewall |--(HUB)--| Workstation/s |
 \_  _  _  _/    |________|    |    |__________|         |_______________|
   \/ \/ \/                    |  
                           (Server)    
                           (esterno)
</verb>


<sect1> Server Proxy e Firewall

<P>
Se si vuole monitorare dove vanno gli utenti della propria rete e se la rete è piccola, 
si può integrare un server proxy nel firewall. 
Gli ISP qualche volta lo fanno per stilare una lista degli interessi dei propri clienti da poter 
rivendere ad agenzie di marketing.
<verb>
                   __________
    _/\__/\_      | Proxy /  |          _______________
   |        |     | Sistema  |  (LAN)  |               |
  / Internet \----| Firewall |--(HUB)--| Workstation/s |
  \_  _  _  _/    |__________|         |_______________|
    \/ \/ \/
</verb>

Si può collocare il server proxy nella propria LAN come si vuole.
In questo caso il firewall dovrebbe però contenere delle regole che consentano la connessione ad Internet,
e per i servizi che intende fornire, solo al server proxy.
In questo modo gli utenti potranno accedere ad Internet solamente attraverso il proxy.

<verb>
                  __________
   _/\__/\_      |          |          _______________
  |        |     | Sistema  |  (LAN)  |               |
 / Internet \----| Firewall |--(HUB)--| Workstation/s |
 \_  _  _  _/    |__________|    |    |_______________|
   \/ \/ \/                      |     ______________
                                 |    |              |
                                 +----| Server Proxy |
                                      |______________|
</verb>

<sect1> Configurazioni Internet ridondanti

<P>
Se si sta per avviare un servizio simile a YAHOO, o forse Slashdot, si potrebbe aver bisogno di organizzare il sistema utilizzando
router ridondanti e firewall (consultare l'High Availability HowTo).
Utilizzando tecniche DNS round-robin oppure load-balancing di server, si può creare un servizio 100% uptime.

<verb>

   _/\__/\_                                     _/\__/\_  
  |        |                                   |        | 
 /  ISP #1  \______                 (WAN)_____/ Partner  \
 \_  _  _  _/      |                (HUB)     \_  _  _  _/
   \/ \/ \/        |               ___|____     \/ \/ \/  
                 __|___           |_______ |
   _/\__/\_     |_____ |         |Sistema ||          ______
  |        |   |      ||  (DMZ)  |Firewall||  (LAN)  |      |
 /  ISP #2  \--|Router||--(HUB)--|  (VPN) ||--(HUB)--| WS/s |
 \_  _  _  _/  |______|     |    |________|     |    |______|
   \/ \/ \/                 |         |         |     ______
          |            (Server)   (Server)      |    |      |
  ------  |            (esterno) (condivisi)    +----|Proxy |
 | WS/s | |                                          |______|
 | VPN  |-+
 |______|

</verb>

E' facile che la propria rete possa sfuggire di mano. Si controlli ogni connessione. 
E' sufficiente un utente con un modem per compromettere la LAN.


<sect>Impostazione del firewall Linux filtrante
<p>
<sect1>Requisiti Hardware
<p> 
I firewall filtranti non richiedono hardware particolare, sono
solo un po' più complessi di un semplice router.

Tutto quello di cui si ha bisogno è:
<enum>
<item> un 486-DX66 con 32 mega di memoria
<item> un disco fisso da 250 mega (meglio 500)
<item> connessioni di rete (Schede LAN, Porte Seriali, Wireless?)
<item> monitor e tastiera
</enum>

Con alcuni sistemi utilizzando la console su porta seriale, si possono
pure eliminare il monitor e la tastiera.
Se si ha bisogno di un server proxy che gestisca parecchio traffico,
si dovrebbe acquistare il sistema più potente possibile.  
Questo perché per ogni utente che si connette al sistema, sarà creato un nuovo
processo. Se si hanno 50 o più utenti suppongo che si avrà bisogno di:

<enum>
<item> un Pentium II con 64 mega di memoria
<item> un disco fisso da 2 giga per salvare tutti i log
<item> due connessioni di rete
<item> monitor e tastiera
</enum>

Le connessioni di rete possono essere di qualsiasi tipo (schede NIC, ISDN e anche modem).

<sect>Requisiti Software
<sect1> Selezionare un Kernel
<p> 
Per creare un firewall filtrante non è necessario alcun software particolare. Basta Linux. 
Al momento sto utilizzando la RedHat 6.1.
 
La base del firewall in Linux è stata modificata diverse volte.
Se si sta utilizzando un kernel vecchio (1.0.x o precedente) ci si procuri una nuova copia. 
Queste versioni usano ipfwadm (<bf>http://www.xos.nl/linux/ipfwadm/</bf>) e non sono più supportate. 

Se si sta utilizzando la 2.2.13 o più recente si starà facendo uso di ipchains, sviluppato da 
<bf>http://www.rustcorp.com/linux/ipchains/</bf>.

Se invece si utilizza il nuovo kernel 2.4 esiste una nuova utility per il firewall con diverse nuove caratteristiche.
Scriverò presto qualcosa a riguardo.

<sect1> Selezionare un server proxy
<P>
Se si vuole impostare un server proxy si avrà bisogno di uno dei seguenti pacchetti:
<enum>
<item> Squid
<item> The TIS Firewall Toolkit (FWTK)
<item> SOCKS
</enum>

<p>
Squid è un pacchetto eccellente ed è in grado di sfruttare il proxy trasparente di Linux.
Descriverò di seguito come impostare questo server. 

Al momento della stesura di questo documento, <url url="http://www.networkassociates.com/" name="Network Associates"> e Trusted Information System (TIS) 
si sono uniti, quindi si visitino i loro siti per ottenere informazioni sui cambiamenti.
Nel frattempo, il toolkit dovrebbe essere ancora disponibile, <bf><url url="http://www.tis.com/research/software/" name="http://www.tis.com/research/software/"></bf>.

Trusted Information System ha reso disponibile una collezione di programmi realizzati per facilitare la gestione del firewall.
Con questi strumenti è possibile impostare un daemon per ogni servizio (WWW, telnet, ecc.) che si intende utilizzare.  

<sect>Preparare il sistema Linux

<p>
Si installi il sistema Linux nel modo più compatto possibile. La mia installazione presentava una
configurazione di tipo server quindi ho provveduto a disabilitare i servizi non necessari nel file /etc/inetd.conf.
Per una maggior sicurezza si dovrebbero disinstallare i servizi inutili. 

Siccome la maggior parte delle distribuzioni non fornisce in genere un kernel efficiente per le proprie esigenze, sarà 
necessario compilarne uno proprio. Questa operazione sarebbe meglio effettuarla su un computer diverso dal firewall.
Se si installa sul firewall un compilatore C e le utilità, ci si ricordi di rimuoverle dopo aver completato la configurazione del kernel. 


<sect1>Compilazione del Kernel
<p> 
Si parta con un'installazione minima della propria distribuzione
Linux.  Meno software si installa e meno buchi, backdoor e/o bug ci
saranno ad introdurre problemi di sicurezza nel proprio server.

Si prenda un kernel stabile.  Io sto utilizzando, per il mio sistema, la 2.2.13. 
Quindi questa documentazione è basata sulle sue impostazioni.

È necessario ricompilare il kernel di Linux con le opzioni
appropriate.  Se non si è mai ricompilato il proprio kernel prima
d'ora, si dovrebbe leggere il Kernel HOWTO, l'Ethernet HOWTO e il NET-2
HOWTO.

Qui ci sono le impostazioni di rete che so per certo come funzionanti. 
Ne ho marcate alcune con un ?.  Se si è intenzionati ad utilizzarle, le si abilitino
pure.
Per modificare le impostazioni del mio kernel utilizzo "make menuconfig".

<verb>
    <*> Packet socket
    [ ] Kernel/User netlink socket
    [*] Network firewalls
    [ ] Socket Filtering
    <*> Unix domain sockets
    [*] TCP/IP networking
    [ ] IP: multicasting
    [*] IP: advanced router
    [ ] IP: kernel level autoconfiguration
    [*] IP: firewalling
    [?] IP: always defragment (required for masquerading)
    [?] IP: transparent proxy support
    [?] IP: masquerading
    --- Protocol-specific masquerading support will be built as modules.
    [?] IP: ICMP masquerading
    --- Protocol-specific masquerading support will be built as modules.
    [ ] IP: masquerading special modules support
    [*] IP: optimize as router not host
    < > IP: tunneling
    < > IP: GRE tunnels over IP
    [?] IP: aliasing support
    [*] IP: TCP syncookie support (not enabled per default)
    --- (it is safe to leave these untouched)
    < > IP: Reverse ARP
    [*] IP: Allow large windows (not recommended if <16Mb of memory)
    < > The IPv6 protocol (EXPERIMENTAL)
    ---
    < > The IPX protocol
    < > Appletalk DDP
    < > CCITT X.25 Packet Layer (EXPERIMENTAL)
    < > LAPB Data Link Driver (EXPERIMENTAL)
    [ ] Bridging (EXPERIMENTAL)
    [ ] 802.2 LLC (EXPERIMENTAL)
    < > Acorn Econet/AUN protocols (EXPERIMENTAL)
    < > WAN router
    [ ] Fast switching (read help!)
    [ ] Forwarding between high speed interfaces
    [ ] PU is too slow to handle full bandwidth
    QoS and/or fair queueing  ---> 
</verb>

Dopo aver completato tutte le impostazioni sarà necessario ricompilare, reinstallare il kernel e riavviare.
Io utilizzo il comando:

make dep;make clean;make bzlilo;make modules;make modules_install;init 6 per fare tutto in un colpo solo.

<sect1>Configurazione di due schede di rete
<p>
Se il proprio computer possiede due schede di rete, molto probabilmente
sarà necessario inserire un'istruzione "append" nel proprio file
/etc/lilo.conf, per specificare l'IRQ e l'indirizzo di entrambe le
schede. L'istruzione presente nel mio lilo è la seguente:
<verb>
append=&dquot;ether=12,0x300,eth0 ether=15,0x340,eth1&dquot; 
</verb>

<sect1>Configurazione degli indirizzi di rete
<p> 
Siamo arrivati finalmente alla parte più divertente dell'impostazione. 
Non sto per addentrarmi ad approfondire come impostare una LAN, per risolvere eventuali problemi  
si legga il Networking-HOWTO.

L'obiettivo è di fornire il sistema firewall di due connessioni di rete, 
una diretta verso Internet (versante non sicuro) e una verso la LAN (versante sicuro).

Ad ogni modo, ci sono un paio di decisioni da prendere.

<enum>
<item> Si vogliono utilizzare per la propria rete locale indirizzi IP reali o qualcosa di differente ?
<item> L'indirizzo IP è statico oppure è assegnato dall'ISP ?
</enum>

Dal momento che non si desidera che Internet abbia
accesso ad alcuna parte della rete privata, non è necessario
utilizzare degli &dquot;indirizzi reali&dquot;. 
Si potrebbero prendere degli indirizzi qualsiasi per la propria rete LAN, ma ciò non è raccomandato.
Se i dati dovessero essere instradati fuori dalla LAN, potrebbero giungere ad una porta di un altro sistema.

Esistono comunque molti intervalli di indirizzi internet riservati appositamente per le reti private. 

Tra questi c'è 192.168.1.xxx che utilizzeremo nei nostri esempi.

Sarà inoltre necessario utilizzare l'IP masquerading. 
Con questo procedimento il firewall farà proseguire i pacchetti e, per farli viaggiare in Internet, 
li modificherà utilizzando un indirizzo IP &dquot;REALE&dquot;.  

Utilizzando questi indirizzi IP non-instradabili la propria rete sarà più sicura.
I router internet non invieranno pacchetti con questi indirizzi.

A questo punto potrebbe essere utile leggere l'IP Masquerading HOWTO.

<verb>
            24.94.1.123  __________    192.168.1.1
      _/\__/\_        \ |          | /           _______________
     |        |        \| Sistema  |/           |               |
    / Internet \--------| Firewall |------------| Workstation/s |
    \_  _  _  _/        |__________|            |_______________|
      \/ \/ \/  
</verb>

E' necessario possedere un indirizzo IP &dquot;reale&dquot; da assegnare alla scheda di rete corrispondente ad Internet.
Questo indirizzo può essere assegnato in modo permanente (indirizzo IP statico) oppure 
al momento della connessione alla rete attraverso il processo PPP.
  
Si dovranno quindi assegnare gli indirizzi IP alla rete locale, ad esempio, 192.168.1.1 alla scheda di rete
corrispondente alla LAN. Questo sarà il gateway di default. A tutte le altre macchine nella rete protetta (LAN) 
si potrà assegnare un numero appartenente all'intervallo 192.168.1.xxx (da 192.168.1.2 a 192.168.1.254).  

Io utilizzo la RedHat Linux. Per configurare la rete al momento del boot ho aggiunto un file ifcfg-eth1 
nella directory /etc/sysconfig/network-scripts. Sempre in questa directory si potrebbero trovare anche ifcfg-ppp0 o ifcfg-tr0.
Questi file 'ifcfg-' sono utilizzati dalla RedHat per configurare e abilitare i dispositivi di rete al boot.
Il nome è assegnato in base al tipo di connessione.
 
Segue, come esempio, ifcfg-eth1 (seconda scheda ethernet):

<verb>
    DEVICE=eth1
    IPADDR=192.168.1.1
    NETMASK=255.255.255.0
    NETWORK=192.168.1.0
    BROADCAST=192.168.1.255
    GATEWAY=24.94.1.123
    ONBOOT=yes
</verb>

Se si sta per utilizzare una connessione dialup si dia un'occhiata ai file ifcfg-ppp0 e chat-ppp0.
Questi file controllano la connessione PPP.

Questo file ifcfg potrebbe essere simile a:

<verb>
    DEVICE=&dquot;ppp0&dquot;           
    ONBOOT=&dquot;yes&dquot;
    USERCTL=&dquot;no&dquot;
    MODEMPORT=&dquot;/dev/modem&dquot;      
    LINESPEED=&dquot;115200&dquot;          
    PERSIST=&dquot;yes&dquot;   
    DEFABORT=&dquot;yes&dquot;  
    DEBUG=&dquot;yes&dquot;     
    INITSTRING=&dquot;ATZ&dquot;
    DEFROUTE=&dquot;yes&dquot;  
    HARDFLOWCTL=&dquot;yes&dquot;           
    ESCAPECHARS=&dquot;no&dquot;
    PPPOPTIONS=&dquot;&dquot;   
    PAPNAME=&dquot;LoginID&dquot;           
    REMIP=&dquot;&dquot;        
    NETMASK=&dquot;&dquot;      
    IPADDR=&dquot;&dquot;       
    MRU=&dquot;&dquot;          
    MTU=&dquot;&dquot;          
    DISCONNECTTIMEOUT=&dquot;&dquot;        
    RETRYTIMEOUT=&dquot;5&dquot;
    BOOTPROTO=&dquot;none&dquot;
</verb>


<sect1>Verifica del funzionamento della rete
<p>
Si cominci impartendo i comandi ifconfig e route. Se si possiedono due
schede di rete l'output di ifconfig dovrebbe essere simile al seguente:

<verb>
  #ifconfig
  lo        Link encap:Local Loopback
            inet addr:127.0.0.1  Mask:255.0.0.0
            UP LOOPBACK RUNNING  MTU:3924  Metric:1
            RX packets:1620 errors:0 dropped:0 overruns:0
            TX packets:1620 errors:0 dropped:0 overruns:0
	    collisions:0 txqueuelan:0

  eth0      Link encap:10Mbps Ethernet  HWaddr 00:00:09:85:AC:55
            inet addr:24.94.1.123 Bcast:24.94.1.255  Mask:255.255.255.0
            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
            RX packets:1000 errors:0 dropped:0 overruns:0
            TX packets:1100 errors:0 dropped:0 overruns:0
	    collisions:0 txqueuelan:0
            Interrupt:12 Base address:0x310

  eth1      Link encap:10Mbps Ethernet  HWaddr 00:00:09:80:1E:D7
            inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
            RX packets:1110 errors:0 dropped:0 overruns:0
            TX packets:1111 errors:0 dropped:0 overruns:0
	    collisions:0 txqueuelan:0
            Interrupt:15 Base address:0x350
</verb>
                                        
mentre la propria tabella di instradamento dovrebbe essere:

<verb>
  #route -n
  Kernel routing table
  Destination     Gateway         Genmask         Flags MSS    Window Use Iface
  24.94.1.0       *               255.255.255.0   U     1500   0       15 eth0
  192.168.1.0     *               255.255.255.0   U     1500   0        0 eth1
  127.0.0.0       *               255.0.0.0       U     3584   0        2 lo
  default         24.94.1.123     *               UG    1500   0       72 eth0
</verb>

<bf>Nota:</bf> 24.94.1.0 è il lato Internet di questo firewall e
192.168.1.0 è il lato privato.

Ora è necessario assicurarsi che ogni computer della propria LAN sia in grado di effettuare dei ping verso 
l'indirizzo interno del sistema firewall (192.168.1.1 in questo caso). 
Se non è possibile, si passi nuovamente al NET-2 HOWTO e si lavori ancora un po' sulla rete.
 
Dopodiché, dal firewall, si provi ad effettuare un ping ad un sistema presente in Internet.
Per i miei test utilizzo www.internic.net.
Se non funziona, provare con un server del proprio ISP. Se ancora non funziona allora parte della propria connessione ad Internet è errata.
Si dovrebbe essere in grado di connettersi ovunque in Internet dal proprio firewall. Si dia un'occhiata all'impostazione del proprio 
gateway di default.
Se si sta utilizzando una connessione dialup si faccia un doppio controllo della user ID e della password.
Quindi si rilegga il net-2 HOWTO, e si riprovi.
 
Ora si provi ad effettuare un ping verso l'indirizzo esterno del firewall (24.94.1.123) utilizzando un computer della propria LAN.
Non dovrebbe funzionare. Se funziona allora il masquerading o l'IP Forwarding sono abilitati, oppure si ha già qualche filtro di pacchetti 
impostato. Li si disabilitino e si riprovi. E' necessario assicurarsi che il filtraggio sia a posto.

Per i kernel più recenti della 2.1.102 si può impartire il comando:

<verb>
    echo "0" > /proc/sys/net/ipv4/ip_forward
</verb>

Se si sta utilizzando un vecchio kernel (PERCHÉ ?) sarà necessario ricompilare il kernel con 
il forwarding disabilitato (meglio passare ad un kernel più recente). 

Si provi ad effettuare di nuovo un ping verso l'indirizzo esterno del firewall (24.94.1.123), non dovrebbe funzionare. 

Ora si abiliti l'IP forwarding e/o il masquerading, si dovrebbe essere in grado, da qualsiasi sistema della LAN, 
di effettuare dei ping ovunque in Internet:

<verb>
    echo "1" > /proc/sys/net/ipv4/ip_forward
</verb>

<BF>NOTA IMPORTANTE:</BF>
Se si utilizzano indirizzi IP &dquot;REALI&dquot; per la propria LAN (non 192.168.1.*) e non si riescono ad effettuare i ping verso internet,
ma solo verso il lato internet del firewall, allora ci si assicuri che il proprio ISP instradi i pacchetti per gli indirizzi della 
propria rete privata.

Un test di questo problema può essere effettuato se si ha qualcuno in Internet (diciamo un amico che utilizza un provider locale) 
attraverso l'utilizzo del traceroute verso la propria rete. Se il tracciamento si blocca con il router del proprio provider allora 
significa che il router non inoltra il proprio traffico.  

Funziona ? Splendido. La fase più ardua è compiuta. :-)

<sect1>Sicurezza del Firewall
<p>
Un firewall non è di nessuna utilità se lasciato aperto agli attacchi.
Un &dquot;malintenzionato&dquot; 
potrebbe ottenere l'accesso ad un servizio non del firewall e modificarlo secondo le
proprie esigenze.

Date un'occhiata al file /etc/inetd.conf, utilizzato per configurare inetd, noto anche come &dquot;super server&dquot;.
Esso controlla parecchi demoni che attiva nel momento in cui sono richiesti da pacchetti che arrivano diretti verso 
porte &dquot;note&dquot; (&dquot;well known port&dquot;).

Si possono disabilitare echo, discard, daytime, chargen, ftp, gopher, shell, login, exec, talk, ntalk, pop-2, pop-3, netstat, systat, tftp, bootp,  finger, cfinger, time, swat 
e linuxconfig se presente.
 
Per disabilitare un servizio, si aggiunga un &num; come primo carattere della linea corrispondente al servizio.
Una volta concluso, si invii un SIG-HUP al processo impartendo <bf>&dquot;kill -HUP &lt;pid&gt;&dquot;</bf>, dove &lt;pid&gt; 
è il numero del processo di inetd.
Questo comando obbliga inetd a rileggere il suo file di configurazione (inetd.conf) e a riavviarsi senza dover spegnere il sistema.

Si faccia un test effettuando un telnet alla porta 15 (netstat) del firewall, se si ottiene dell'output allora non si è 
disabilitato questo servizio.
  
    telnet localhost 19

Si può inoltre creare il file /etc/nologin. Si inserisca qualche linea di testo tipo (FILA VIA!).
Quando questo file esiste, login non consentirà agli utenti di connettersi. Essi vedranno il contenuto di questo file ed il 
loro login sarà rifiutato. Solo root potrà accedere.

Se l'utente è root allora il login deve avvenire su una delle tty elencate in /etc/securetty. 
Fallimenti saranno registrati con l'apposita funzione del syslog. 
Con presenti entrambi questi controlli l'unico modo per accedere al firewall è attraverso la console e solo come root.

MAI e poi MAI effettuare un telnet verso un sistema e accedere come ROOT. 
Se è necessario accedere in remoto come root utilizzare SSH (Secure Shell).
Si potrebbe perfino disabilitare il telnet.
 
Se si è davvero paranoici allora si dovrebbe utilizzare lids (Linux Intrusion Detect System), una patch di scoperta delle intrusioni 
per il kernel Linux; può proteggere file importanti evitando che siano modificati. 
Quando è presente, nessuno (incluso root) può cambiare i file, le directory o sotto-directory protette.
Per modificare i file protetti è necessario riavviare il sistema con l'impostazione security=1 nel LILO 
(riavvio in single user mode).

<sect>Impostazione del filtraggio IP (IPFWADM)
<p> 
Se si sta utilizzando un kernel 2.1.102 o più recente passare alla sezione riguardante IPCHAINS.

Nei vecchi kernel l'IP Forwarding è abilitato per default.
Per questo motivo la propria rete dovrebbe cominciare vietando l'accesso a chiunque e cancellando tutte le regole impostate 
l'ultima volta. Questo frammento di script dovrebbe essere collocato nello script di startup della propria rete (/etc/rc.d/init.d/network).

<verb>
  #
  # Imposta IP packet Accounting e Forwarding
  #
  #   Forwarding
  #
  # Di default NEGA tutti i servizi
  ipfwadm -F -p deny
  # Cancella tutti i comandi
  ipfwadm -F -f
  ipfwadm -I -f   
  ipfwadm -O -f
</verb> 

Ora abbiamo il firewall definitivo. Nulla può passare.

Si crei il file /etc/rc.d/rc.firewall. Questo script dovrebbe consentire traffico email, Web e DNS. ;-)

<verb>
#! /bin/sh
#
# rc.firewall
#
# Libreria funzioni.
. /etc/rc.d/init.d/functions

# avvia configurazione.
. /etc/sysconfig/network

# Controlliamo che la rete sia presente
if [ ${NETWORKING} = "no" ]
then
        exit 0
fi
case "$1" in
  start)
  echo -n "Starting Firewall Services: "
  # Inoltro delle email al proprio server
  /sbin/ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 192.1.2.10 25
  # Consenti connessione email verso server email esterni
  /sbin/ipfwadm -F -a accept -b -P tcp -S 192.1.2.10 25 -D 0.0.0.0/0 1024:65535
  # Consenti accesso web al proprio web server
  /sbin/ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 192.1.2.11 80
  # Consenti connessioni Web verso server Web esterni
  /sbin/ipfwadm -F -a accept -b -P tcp -S 192.1.2.* 80 -D 0.0.0.0/0 1024:65535 
  # Consenti traffico DNS
  /sbin/ipfwadm -F -a accept -b -P udp -S 0.0.0.0/0 53 -D 192.1.2.0/24
  ;;
  stop)
  echo -n "Stooping Firewall Services: "
  ipfwadm -F -p deny
  ;;
  status)
  echo -n "Now do you show firewall stats?"
  ;;
  restart|reload)
        $0 stop
        $0 start
        ;;
  *)
        echo "Usage: firewall {start|stop|status|restart|reload}"
        exit 1
esac
</verb>


NOTA: in questo esempio l'email server è presente all'indirizzo 192.1.2.10 dove dovrebbe essere in grado di inviare e riceve sulla porta 25. 

Il server web è presente all'indirizzo 192.1.2.11. Consentiamo a chiunque appartenente alla LAN di accedere ai server web e DNS esterni. 

Ciò non è perfettamente sicuro, in quanto la porta 80 non dovrebbe essere usata come porta web, un hacker acuto potrebbe utilizzarla 
per creare una rete privata virtuale (VPN) attraverso il firewall.
Per raggirare questa situazione è necessario impostare un proxy web, e consentire solo il proxy attraverso il firewall.
Gli utenti della rete LAN devono passare attraverso il proxy per accedere ai server web esterni.

Si potrebbe essere interessati a tenere conto del traffico che passa attraverso il firewall.
Il seguente script conta tutti i pacchetti. E' possibile aggiungere una o due linee per contare i pacchetti diretti solo
verso un determinato sistema.

<verb>          

  # Cancella le regole correnti di "conteggio"
  ipfwadm -A -f
  # Conteggio
  /sbin/ipfwadm -A -f
  /sbin/ipfwadm -A out -i -S 192.1.2.0/24 -D 0.0.0.0/0
  /sbin/ipfwadm -A out -i -S 0.0.0.0/0    -D 192.1.2.0/24
  /sbin/ipfwadm -A in  -i -S 192.1.2.0/24 -D 0.0.0.0/0
  /sbin/ipfwadm -A in  -i -S 0.0.0.0/0    -D 192.1.2.0/24
</verb>

Se tutto ciò di cui si ha bisogno è un firewall filtrante allora ci si può fermare qui.
Si effettuino dei test e se la si goda.

<sect>Impostazione del filtraggio IP (IPCHAINS)

<p>
Linux ipchains è la riscrittura del codice IPv4 di filtraggio di Linux e di ipfwadm, il quale a sua volta è 
una riscrittura di ipfw della BSD, credo.
&Egrave; richiesto per l'amministrazione dei filtri dei pacchetti IP nei kernel Linux versione 2.1.102 e successivi.

Il vecchio codice non gestisce i frammenti, ha contatori 32-bit (almeno su Intel), non consente la specificazione di 
protocolli che non siano TCP, UDP o ICMP, non può effettuare grossi cambiamenti atomicamente, 
non è possibile specificare regole inverse, ha alcune bizzarrie, e può essere difficile da utilizzare 
(incline a far commettere errori all'utente). Così almeno secondo l'autore.

Non mi accingo ad approfondire come gestire un firewall con IPChains in quanto esiste un'ECCELLENTE!! HOWTO all'indirizzo 
<url url="http://www.rustcorp.com/linux/ipchains/HOWTO.html" name="http://www.rustcorp.com/linux/ipchains/HOWTO.html">.

Si lavora con le catene per nome. Si parte con tre catene predefinite input, output e forward che non possono essere rimosse.
Si possono anche creare proprie catene. Le regole, da questo sistema, possono essere aggiunte e cancellate. 

Le operazioni per operare su intere catene sono:
<enum>
<item>Crea una nuova catena (-N). 
<item>Cancella una catena vuota (-X). 
<item>Cambia la tattica di una delle catene predefinite (-P). 
<item>Elenca le regole di una delle catene (-L). 
<item>Svuota una catena delle sue regole (-F). 
<item>Azzera i contatori dei pacchetti e dei byte di tutte le regole di una catena (-Z). 
</enum>

Esistono inoltre diversi modi per manipolare le regole di una catena:

<enum>
<item>Appendi una nuova regola ad una catena (-A). 
<item>Inserisci una nuova regola in una determinata posizione della catena (-I). 
<item>Sostituisci una regola presente in una determinata posizione di una catena (-R). 
<item>Cancella una regola presente in una determinata posizione della catena (-D). 
<item>Cancella la prima regola di una catena (-D). 
</enum>

Ci sono anche alcune operazioni riguardanti il masquerading, incluse in ipchains in quanto è una buona collocazione:

<enum>
<item>Elenca le connessioni correntemente mascherate (-M -L).
<item>Imposta i timeout del masquerading (-M -S).
</enum>

Esistono alcuni problemi di tempo riguardanti la modifica delle regole del firewall.

Se non si presta particolare attenzione, si potrebbero far passare dei pacchetti mentre si è nel bel mezzo delle modifiche.

<verb>
     # ipchains -I input 1 -j DENY
     # ipchains -I output 1 -j DENY
     # ipchains -I forward 1 -j DENY
</verb>

     ... effettua le modifiche ...

<verb>
     # ipchains -D input 1
     # ipchains -D output 1
     # ipchains -D forward 1
     # 
</verb>

Questa soluzione scarta tutti i pacchetti per tutta la durata delle modifiche.

Segue un duplicato, adattato per IPChains, delle regole precedenti. 

<verb>
#!/bin/sh
#
# rc.firewall
#
## Svuota tutto, cominciamo da zero
  /sbin/ipchains -F input
  /sbin/ipchains -F output
  /sbin/ipchains -F forward

## Redirezione, necessaria per il proxy HTTP trasparente
  #$IPCHAINS  -A input -p tcp -s 192.1.2.0/24 -d 0.0.0.0/0 80 -j REDIRECT 8080

## Creazione della propria catena
  /sbin/ipchains -N my-chain
  # Consentiamo alle email di giungere al server
  /sbin/ipchains -A my-chain -s 0.0.0.0/0 smtp -d 192.1.2.10 1024:-j ACCEPT
  # Consentiamo connessioni email verso server email esterni
  /sbin/ipchains -A my-chain -s 192.1.2.10 -d 0.0.0.0/0 smtp -j ACCEPT
  # Consentiamo connessioni Web dirette al proprio server Web
  /sbin/ipchains -A my-chain -s 0.0.0.0/0 www -d 192.1.2.11 1024: -j ACCEPT
  # Consentiamo connessioni Web dirette verso server Web esterni
  /sbin/ipchains -A my-chain -s 192.1.2.0/24 1024: -d 0.0.0.0/0 www -j ACCEPT
  # Consentiamo traffico DNS
  /sbin/ipchains -A my-chain -p UDP -s 0.0.0.0/0 dns -d 192.1.2.0/24 -j ACCEPT

## Se si utilizza il masquerading
  # Non mascherare il traffico interno-interno 
  /sbin/ipchains -A forward -s 192.1.2.0/24 -d 192.1.2.0/24 -j ACCEPT
  # Non mascherare direttamente l'interfaccia esterna 
  /sbin/ipchains -A forward -s 24.94.1.0/24 -d 0.0.0.0/0 -j ACCEPT
  # Maschera tutti gli IP interni diretti all'esterno 
  /sbin/ipchains -A forward -s 192.1.2.0/24 -d 0.0.0.0/0 -j MASQ

## Scarta qualsiasi altra cosa
  /sbin/ipchains -P my-chain input DENY
</verb>

Non ci si fermi qui. Questo non è un gran firewall e sono sicuro che si vorranno fornire altri servizi. 
Ancora, si legga l'IPCHAINS-HOWTO.


<SECT>Installare un proxy trasparente SQUID 

<p>
Il proxy squid è disponibile all'indirizzo <bf><url url="http://squid.nlanr.net/" name="http://squid.nlanr.net/"></bf>.

Gli sviluppatori di SQUID mettono a disposizione pacchetti per RedHat e Debian. Se possibile utilizzare uno di questi.

<sect>Installare il proxy server TIS
<p>
<sect1>Reperire il software
<p>
TIS FWTK è disponibile all'indirizzo <bf><url url="http://www.tis.com/research/software/ "
name="http://www.tis.com/research/software/"></bf>.  

<bf>Non fate il mio stesso errore.</bf> 
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 <url url="http://www.tis.com/research/software/fwtk_readme.html "
name="http://www.tis.com/research/software/fwtk_readme.html"> e che sia <bf>inviata, per apprendere il nome della directory nascosta 
un'email all'indirizzo <URL URL="mailto:fwtk-request@tislabs.com" name="fwtk-request@tislabs.com"></bf> 
con presente, nel corpo del messaggio, la sola parola <bf>accepted</bf> 

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.

<sect1>Compilare TIS FWTK

<p> 
La compilazione della versione 2.1 di FWTK è molto più semplice rispetto a qualsiasi altra versione precedente. 

SPIEGA QUI!!!

Ora impartire <bf>make</bf>.

<sect1>Installare TIS FWTK           
<p>
Digitare <bf>make install</bf>.

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'.

<sect1>Configurare TIS FWTK
<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.

Esistono tre file che riguardano questi controlli:

<p>
<itemize>
<item>/etc/services
<itemize>
<item>Segnala al sistema a quali porte il servizio è presente
</itemize>
</itemize>
<itemize>
<item>/etc/inetd.conf
<itemize>
<item>Segnala a inetd quali programmi richiamare quando qualcuno bussa ad una determinata porta 
</itemize>
</itemize>
<itemize>
<item>/usr/local/etc/netperm-table
<itemize>
<item>Specifica chi può accedere e chi no ai servizi
</itemize>
</itemize>

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.

<sect2>Il file netperm-table 
<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.

In questo modo le persone possono identificarsi; il firewall utilizza un programma <bf>authsrv</bf> 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, è '' <tt>authsrv: permit-hosts localhost</tt>.

<verb>
  #
  # 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
</verb>

Per inizializzare il database e creare il record user administrative, effettuare un su root
e avviare <bf>./authsrv</bf> nella directory /var/local/etc.
Qui è presente una semplice sezione.

Si legga la documentazione di FWTK per imparare come aggiungere utenti e gruppi.
<verb>
    #
    # authsrv
    authsrv# list
    authsrv# adduser admin &dquot;Auth DB admin&dquot;
    ok - user added initially disabled
    authsrv# ena admin
    enabled
    authsrv# proto admin pass
    changed
    authsrv# pass admin &dquot;plugh&dquot;
    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
    #
</verb>

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. 

<verb>
  # 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
</verb>

I comandi r funzionano allo stesso modo del telnet.

<verb>
  # 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
</verb>

È 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à.

<verb>
  # 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 }
</verb>

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.

<verb>
  # 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 	* 
</verb>

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.

<verb>
  # 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      *
</verb>

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.
<verb> 
  # 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
</verb>

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.

<verb>
  # 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
</verb>

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.

<sect2>The /etc/services file

<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.

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>
<verb> 
  telnet-a        24/tcp
  ftp-gw          21/tcp    	       # questo nome è cambiato
  auth            113/tcp   ident    # verifica dell'utente
  ssl-gw          443/tcp
</verb>


<sect>Il proxy server SOCKS
<p>
<sect1>Impostare il server proxy

<p>
Il proxy server SOCKS è disponibile all'indirizzo <bf>http://www.socks.nec.com/</bf>.

Decomprimere e decompattare (untar) i file all'interno di una directory del proprio sistema, e seguire le
istruzioni su come effettuare il make. Personalmente ho avuto un paio
di problemi in quest'ultimo caso. Assicurarsi che i Makefile siano corretti.

È importante notare che il proxy server deve essere aggiunto nel file
/etc/inetd.conf. È necessario quindi aggiungere la riga: 

<verb>
  socks  stream  tcp  nowait  nobody  /usr/local/etc/sockd  sockd
</verb>

per segnalare al server di entrare in esecuzione quando richiesto.

<sect1>Configurare il Proxy Server

<p> 
Il programma SOCKS ha bisogno di due file di configurazione
separati. Il primo per specificare gli accessi autorizzati, il secondo
per instradare le richieste al proxy server appropriato. Il file di
accesso dovrebbe essere localizzato sul server. Il file di instradamento
dovrebbe trovarsi su ogni macchina Unix. I computer DOS e
presumibilmente i Macintosh effettueranno il proprio instradamento.

<sect2>Il file di accesso

<p>
Con socks 4.2c Beta, il file di accesso è denominato
&dquot;sockd.conf&dquot;. Dovrebbe contenere 2 righe, una riga permit e una riga
deny. Ogni riga conterrà tre campi:

<itemize>
<item>L'identificatore (permit/deny)
<item>L'indirizzo IP
<item>Il modificatore di indirizzo
</itemize>

L'identificatore è di tipo permit oppure deny. È consigliabile avere
sia la riga permit, sia la riga deny.

L'indirizzo IP è un indirizzo a 4 byte come nella tipica notazione
IP. Ossia, 192.168.1.0. 

Anche il modificatore di indirizzo è un tipico indirizzo IP
rappresentato da un numero di 4 byte e funziona come una netmask.
Supponiamo che questo numero sia a 32 bit (serie di 1 o di 0). Se il bit è un 1, il
bit corrispondente dell'indirizzo che si sta controllando deve essere
uguale al bit corrispondente presente nel campo dell'indirizzo IP.

Ad esempio, se la riga è:

<verb>
    permit 192.168.1.23 255.255.255.255
</verb>

saranno ammessi solo gli indirizzi IP i cui bit corrispondono a 192.168.1.23, ossia, solo 192.168.1.3. La riga:

<verb>
    permit 192.168.1.0 255.255.255.0
</verb>

ammetterà ogni numero all'interno del gruppo da 192.168.1.0 a
192.168.1.255, ossia l'intero dominio di Classe C. Non si dovrebbe invece avere la
riga: 
<verb>
    permit 192.168.1.0 0.0.0.0
</verb>

dal momento che ammetterà qualsiasi indirizzo, indistintamente.

Pertanto, prima di tutto si abilitino tutti gli indirizzi che si vogliono
abilitare e si neghino i restanti. Per ammettere tutti coloro che sono presenti nel dominio
192.168.1.xxx, le righe: 

<verb>
    permit 192.168.1.0 255.255.255.0
    deny 0.0.0.0 0.0.0.0
</verb>

funzioneranno correttamente. Notare il primo &dquot;0.0.0.0&dquot; della riga
deny. Con un modificatore 0.0.0.0, il campo dell'indirizzo IP non è
rilevante. Tutti zero è la norma perché è semplice digitarli.

È consentita più di una voce per ciascun tipo.

È anche possibile fornire o negare gli accessi a degli utenti
specifici, tramite l'autenticazione ident. Non tutti i sistemi
supportano ident, tra cui Trumpet Winsock, pertanto questo argomento
non sarà trattato in questa sede. La documentazione a corredo di socks è del tutto adeguata
riguardo questo argomento.

<sect2>Il file di instradamento

<p> 
Il file di instradamento in SOCKS è infelicemente chiamato
&dquot;socks.conf&dquot;. L'&dquot;infelicemente&dquot; è dovuto al fatto che appare 
molto simile a quello del file di accesso, pertanto potrebbe essere facile confonderli. 

Il file di instradamento informa il client SOCKS quando utilizzare
socks e quando non farlo. Ad esempio, nella nostra rete, 192.168.1.3
non avrà bisogno di utilizzare socks per parlare con 192.168.1.1, il
firewall, in quanto possiede una connessione diretta via
Ethernet e definisce automaticamente 127.0.0.1, ossia il
loopback. Naturalmente non è necessario SOCKS per parlare con se stessi. 
Esistono tre voci:

<p>
<itemize>
<item>deny
<item>direct
<item>sockd
</itemize>

Deny specifica a SOCKS quando respingere una richiesta. Questa
voce possiede gli stessi tre campi già descritti per
sockd.conf: identificatore, indirizzo e modificatore. Generalmente,
dal momento che questo viene gestito anche da sockd.conf, il file di
accesso, il campo del modificatore è impostato a 0.0.0.0. Se si vuole
precludere se stessi dal chiamare qualsiasi posto, può essere fatto in
questo punto. 

La voce direct specifica gli indirizzi per i quali non deve essere
utilizzato socks. Si tratta degli indirizzi che possono essere
raggiunti senza il proxy server. Ancora una volta, abbiamo i tre
campi: identificatore, indirizzo e modificatore. Nel nostro esempio
corrisponderebbe a: 

<verb>
    direct 192.168.1.0 255.255.255.0
</verb>

che permette di andare direttamente ovunque nella nostra rete
protetta.

La voce sockd infine specifica al computer quale host ha in esecuzione il demone 
server socks. La sintassi è:

<verb>
  sockd @=<serverlist> <IP address> <modifier>
</verb>

Si noti la voce @=. Questa permette di impostare gli indirizzi IP di
una lista di proxy server. Nel nostro esempio, viene utilizzato un
unico proxy server. Tuttavia è possibile averne molti per consentire
un carico maggiore e per avere a disposizione una ridondanza in caso
di errore.

I campi di indirizzo IP e di modificatore funzionano esattamente come
negli altri esempi. 
Attraverso questi è possibile specificare dove devono andare gli indirizzi.

<sect2>DNS presente dietro il Firewall
<p>
L'impostazione del Domain Name Service da dietro un firewall è un
compito relativamente semplice. Prima è necessario impostare il
DNS sulla macchina firewall e poi configurare ogni macchina
dietro al firewall in modo che possa utilizzare questo DNS.


<sect1>Lavorare con un Proxy Server

<p>
<sect2>Unix

<p> 
Per fare in modo che le proprie applicazioni funzionino con il proxy
server, dovranno essere &dquot;SOCKettizzate&dquot;. Saranno necessarie due diverse
tipologie di telnet, una per la comunicazione diretta e una per la
comunicazione tramite il proxy server. SOCKS fornisce delle istruzioni
su come SOCKettizzare un programma, come pure un paio di programmi
pre-SOCKettizzati. Se si utilizza una versione SOCKettizzata per andare
direttamente da qualche parte, SOCKS si commuterà automaticamente nella
versione diretta. Per questo motivo si vorranno rinominare tutti i
programmi sulla rete protetta e sostituirli con i programmi
SOCKettizzati. &dquot;Finger&dquot; diventerà &dquot;finger.orig&dquot;, &dquot;telnet&dquot; diventerà
&dquot;telnet.orig&dquot; ecc. Bisognerà inoltre informare SOCKS di ognuno di questi
cambiamenti tramite il file include/socks.h.

Alcuni programmi saranno in grado di gestire l'instradamento e la
SOCKettizzazione per conto loro. Netscape è uno di questi. È possibile
utilizzare un proxy server sotto Netscape inserendo l'indirizzo del
server (192.168.1.1 nel nostro caso) nel campo SOCKS sotto i
Proxy. Ciascuna applicazione avrà bisogno di almeno qualche modifica,
indipendentemente da come gestisce un proxy server.

<sect2>MS Windows con Trumpet Winsock

<p> 
Trumpet Winsock viene già distribuito con il supporto intrinseco per i
server proxy. Nel menu di &dquot;setup&dquot;, si inseriscano l'indirizzo IP del server, e gli
indirizzi di tutti i computer raggiungibili direttamente.
Trumpet provvederà poi a gestire tutti i pacchetti in uscita.

<sect2>Come far funzionare il Proxy Server con i pacchetti UDP

<p> 
Il pacchetto SOCKS funziona solamente con i pacchetti TCP, non con
quelli UDP. Questa caratteristica lo rende leggermente meno
utile. Molti programmi interessanti, come talk e Archie, utilizzano
UDP. Esiste un pacchetto studiato per essere usato come proxy
server per pacchetti UDP denominato UDPrelay, di Tom Fitzgerald
&lt;fitz@wang.com&gt;. Sfortunatamente, nel momento in cui viene scritto
questo documento, non è compatibile con Linux.


<sect1>Svantaggi dei Proxy Server

<p> 
Il proxy server è soprattutto un <tt>dispositivo di sicurezza</tt>. Un suo
utilizzo per aumentare l'accesso ad internet con limitati indirizzi IP
causerà molti svantaggi. Un proxy server consentirà un maggior
accesso dall'interno della rete protetta verso l'esterno, ma manterrà
l'interno completamente inaccessibile dall'esterno. Ciò implica
l'impossibilità di avere connessioni server, talk o archie oppure mail
dirette verso i computer presenti all'interno. Questi svantaggi
potrebbero sembrare irrilevanti, ma bisogna pensare ad essi in questi
termini: 

<itemize>
<item>Un report su cui state lavorando sul vostro computer è stato
lasciato all'interno della rete protetta con firewall. Vi trovate a
casa, e decidete di lavorarci ancora un po'. Ma questo non è
possibile. Non potete raggiungere il vostro computer perché si trova
al di là del firewall. Per prima cosa cercherete di connettervi al
<tt>firewall</tt>, ma dal momento che tutti hanno un accesso proxy
server, nessuno avrà impostato un account per voi.
<p>
<item>Vostra figlia frequenta il college. Volete inviarle un'email. Avete alcuni
affari personali di cui parlare, e preferireste poter ricevere la posta
direttamente sulla vostra macchina. Avete completa fiducia
nell'amministratore del sistema, tuttavia si tratta pur sempre di posta privata.
<p>
<item>L'incapacità di utilizzare i pacchetti UDP rappresenta un grande
svantaggio dei proxy server. Immagino che il supporto UDP sarà
disponibile a breve.

</itemize>

FTP provoca un altro problema con i proxy server. Quando si riceve o
si esegue un comando <tt>ls</tt>, il server FTP apre un socket sulla
macchina client e inoltre la utilizza per inviare le informazioni. Un proxy
server non permetterà queste operazioni, pertanto FTP non funzionerà molto bene.

Inoltre, i proxy server sono lenti. A causa del sovraccarico maggiore,
quasi ogni altro mezzo per ottenere questo accesso sarà più veloce.

Sostanzialmente, se si possiedono gli indirizzi IP, e non ci si
preoccupa della sicurezza, è meglio non utilizzare un firewall e/o i proxy
server. Se non si possiedono gli indirizzi IP, e non ci si preoccupa
della sicurezza, si potrebbe pensare di utilizzare un emulatore IP,
come Term, Slirp o TIA. Term è disponibile su
<tt><bf>ftp://sunsite.unc.edu</bf></tt>, Slirp su
<tt><bf>ftp://blitzen.canberra.edu.au/pub/slirp</bf></tt>, e TIA su
<tt><bf>marketplace.com</bf></tt>. Questi pacchetti saranno più
veloci, consentiranno connessioni 
migliori e forniranno un livello maggiore di accesso alla rete interna
da internet. I proxy server sono ottimi nel caso di reti con molti host
che richiedono di connettersi alla rete esterna al volo, con una sola impostazione e
con poco lavoro successivo.


<sect>Configurazioni avanzate

<p>
Esiste un'altra configurazione di cui vorrei parlare prima di concludere
questo documento. Quelle che ho già descritto probabilmente saranno
sufficienti per la maggior parte delle persone. Tuttavia, ho intenzione
di mostrare una configurazione più avanzata in grado di chiarire alcune
questioni. Se avete domande relative a quanto è stato descritto
finora, o se siete semplicemente interessati alla versatilità dei proxy
server e dei firewall, continuate la lettura.

<sect1>Una rete ampia con enfasi sulla sicurezza

<p>
Supponiamo, ad esempio, di voler mettere in rete il nostro sito. Si
possiedono 50 computer e una sottorete di 32 (5 bit) numeri IP. Servono
diversi livelli di accesso all'interno della rete. Pertanto, è
necessario proteggere certe parti della rete dal resto. 

I livelli sono:
<enum>
<item>Il livello esterno. Si tratta del livello disponibile a
tutti. È il luogo dove si cercano nuovi volontari.
<item><bf>Truppa</bf>. Questo è il livello di persone che hanno superato
il livello esterno. È il luogo dove vengono istruiti sul governo diabolico
e su come fabbricare le bombe.
<item><bf>Mercenari</bf>. Questo è il livello dove sono tenuti i piani
<em>veri</em>. In questo livello sono memorizzate tutte le informazioni su
come il governo del terzo mondo ha intenzione di conquistare il mondo,
i piani che coinvolgono Newt Gingrich, Oklahoma City, i prodotti di
minor importanza e cosa è immagazzinato veramente negli hangar
dell'area 51.
</enum>


<sect2>Impostazione della rete

<p>
I numeri IP sono arrangiati in modo tale che:
<p>
<itemize>
<item>Un numero utilizzato sia 192.168.1.255, che rappresenta l'indirizzo di
broadcast non utilizzabile. 
<item>23 dei 32 indirizzi IP siano allocati a 23 macchine che saranno poi 
accessibili da Internet.
<item>Un IP extra sia assegnato ad una Linux box della rete.
<item>Un IP extra sia assegnato ad un'altra Linux box della rete.
<item>Due IP siano assegnati al router.
<item>Quattro siano lasciati liberi, ma ad essi siano comunque assegnati nomi di
dominio quali paul, ringo, john, e george, tanto per confondere un po' le
idee.
<item>Le reti protette abbiano entrambe gli indirizzi 192.168.1.xxx.
</itemize>

Quindi, vengono costruite due reti separate, ognuna localizzata in stanze 
diverse. L'instradamento può avvenire tramite Ethernet a infrarossi in modo
che sia completamente invisibile alle postazioni esterne.
Fortunatamente, l'ethernet a infrarossi funziona esattamente come l'ethernet
normale.

Queste reti sono entrambe connesse ad una delle box Linux tramite un
indirizzo IP extra.

Esiste un file server che connette le due reti protette. Questo perché i
piani per conquistare il mondo coinvolgono alcune delle Truppe di
livello più alto. Il file server mantiene l'indirizzo 192.168.1.17
della rete della Truppa e l'indirizzo 192.168.1.23 della rete dei
Mercenari. Deve avere due indirizzi IP differenti poiché possiede due
diverse schede Ethernet. L'IP Forwarding è disabilitato. 

Il forwarding IP è disabilitato anche su entrambe le Linux box. Il
router non inoltrerà pacchetti destinati a 192.168.1.xxx se non gli
sarà richiesto esplicitamente di farlo, pertanto Internet non sarà in
grado di entrare. La ragione per cui si è scelto di disabilitare l'IP Forwarding è che
in questo modo i pacchetti provenienti dalla rete della Truppa non
saranno in grado di raggiungere la rete dei Mercenari, e viceversa.

Il server NFS può essere impostato in modo da offrire file diversi a
reti diverse. Questo può tornare utile, e un piccolo trucco con i link
simbolici può fare in modo che i file comuni possano essere condivisi
con chiunque. L'utilizzo di questa impostazione e di un'altra scheda
ethernet può offrire questo unico file server a tutte e tre le reti.


<sect2>Impostazione del Proxy

<p>
Ora, dal momento che tutti e tre i livelli vogliono essere in grado di
monitorare la rete per i propri scopi, tutti e tre hanno bisogno di un
accesso alla rete. La rete esterna è connessa direttamente ad
internet, pertanto in questo caso non dobbiamo preoccuparci dei proxy 
server. Le reti dei Mercenari e della Truppa si trovano al di là del
firewall, pertanto è necessario impostare dei proxy server.

Entrambe le reti hanno un'impostazione molto simile. Ad entrambe vengono
assegnati gli stessi indirizzi IP. Inserirò un paio di parametri, solo
per rendere le cose più interessanti.

<enum>
<item>Nessuno può utilizzare il file server per l'accesso ad Internet.
Questo esporrebbe il file server a virus ed altri problemi, ed è quindi molto
importante e assolutamente da evitare.
<item>Non verrà consentito l'accesso della Truppa al World Wide Web, dal
momento che sono in addestramento, questo potere di recupero di 
informazioni potrebbe essere pericoloso.
</enum>

Pertanto, il file sockd.conf sulla box Linux della Truppa conterrà la
riga: 

<verb>
    deny 192.168.1.17 255.255.255.255
</verb>

e sulla macchina Mercenaria:

<verb>
    deny 192.168.1.23 255.255.255.255
</verb>

Inoltre, la box Linux della Truppa avrà anche la seguente linea:

<verb>
    deny 0.0.0.0 0.0.0.0 eq 80
</verb>

che indica di negare l'accesso a tutte le macchine che cercano di
accedere alla porta uguale (eq) a 80, la porta http. Questa continuerà
a consentire tutti gli altri servizi, nega solo l'accesso al Web.

Quindi, entrambi i file conterranno:

<verb>
    permit 192.168.1.0 255.255.255.0
</verb>

per consentire a tutti i computer sulla rete 192.168.1.xxx di
utilizzare questo proxy server, fatta eccezione per quelli ai quali
l'accesso è già stato negato (cioè, il file server e l'accesso al Web
per la rete Truppa).

<p>
Il file sockd.conf della Truppa avrà il seguente formato:
<verb>
    deny 192.168.1.17 255.255.255.255
    deny 0.0.0.0 0.0.0.0 eq 80
    permit 192.168.1.0 255.255.255.0
</verb>
mentre il file Mercenario avrà:
<verb>
    deny 192.168.1.23 255.255.255.255
    permit 192.168.1.0 255.255.255.0
</verb>

Questo dovrebbe configurare tutto correttamente. Ogni rete è isolata di
conseguenza, con l'appropriato numero di interazioni.
Tutti dovrebbero essere felici.

<sect> Semplificare la gestione 
<p>
<sect1> Tool per il firewall
<p>
Esistono molti pacchetti software che sono in grado di rendere più 
semplice la gestione del firewall.

Si presti però attenzione, non si utilizzino questi tool almeno che non 
se ne possa fare a meno.
Questi script inducono a commettere errori con la stessa facilità con 
cui permettono di gestire le regole.

Sia le interfacce grafiche sia quelle basate sul web sono state sviluppate 
per operare con le regole di filtraggio di Linux. 
Alcune compagnie hanno perfino creato dei firewall commerciali basati su Linux, 
utilizzando proprie box con proprio codice di gestione (bello).

In realtà non sono un fan delle GUI. Comunque, ho utilizzato firewall con interfacce
GUI per un po' di tempo e ho constatato che in effetti aiutano a fornire un comodo report 
di tutte le regole, per una rapida occhiata. 

gfcc (GTK+ Firewall Control Center) è un'applicazione GTK+, basata su ipchains, che consente di 
controllare le tattiche e le regole del firewall di Linux.
Si vada all'indirizzo <url url="http://icarus.autostock.co.kr/" name="http://icarus.autostock.co.kr"> e ci si procuri 
la propria copia. Questo è un tool davvero buono.

Sono disponibili parecchi script per impostare un firewall, uno script davvero completo è presente 
all'indirizzo <url url="http://www.jasmine.org.uk/~simon/bookshelf/papers/instant-firewall/instant-firewall.html" 
name="http://www.jasmine.org.uk/~simon/bookshelf/papers/instant-firewall/instant-firewall.html">. 
Un altro script ben fatto è disponibile all'indirizzo <url url="http://www.pointman.org/" name="http://www.pointman.org/">. 

Kfirewall è un'interfaccia GUI per ipchains o ipfwadm (dipende dal proprio kernel) <url url="http://megaman.ypsilonia.net/kfirewall/" 
name="http://megaman.ypsilonia.net/kfirewall/">.

FCT è un tool di configurazione di firewall basato su HTML. 
Comprende generazione automatica di script per comandi di filtraggio IP (ipfwadm) su firewall 
con interfacce multiple e per qualsiasi servizio internet <url url="http://www.fen.baynet.de/~ft114/FCT/firewall.htm" 
name="http://www.fen.baynet.de/~ft114/FCT/firewall.htm">.

<sect1> Tool generici

<p>
Webmin è un pacchetto di amministrazione generale del sistema.
Non è di aiuto per gestire le regole del firewall ma è comunque utile per abilitare e disabilitare 
i demoni e i processi.
Questo programma è VERAMENTE buono, spero che J. Cameron includa un modulo per IPCHAINS.

Se siete un ISP, vi interesserà sapere qualcosa a riguardo di IPFA (IP Firewall Accounting) 
<url url="http://www.soaring-bird.com/ipfa/" name="http://www.soaring-bird.com/ipfa/">. 
Consente di gestire log per mese/giorno/minuto, inoltre ha una GUI per l'amministrazione basata sul Web.

<SECT> Raggirare un firewall proxy
<P>
Giusto per rovinare la giornata, e per far tenere i piedi per terra circa la sicurezza, 
descriverò quanto sia facile raggirare un firewall proxy.

Ora dopo aver fatto tutto quanto descritto in questo documento si ha un server ed una rete veramente sicuri.
Si possiede un DMZ e nessuno può accedere alla rete, inoltre si registrano tutte le connessioni effettuate 
verso il mondo esterno.
Tutti gli utenti passano per il proxy e nessuno può accedere ad Internet direttamente. 

Uno degli utenti, con una connessione dedicata propria, viene però a conoscenza di 
<url url="http://www.nocrew.org/software/httptunnel.html" name="httptunnel">.
httptunnel crea un canale dati virtuale bidirezionale incapsulato in richieste HTTP.
Se desiderato le richieste HTTP possono essere inviate attraverso il proxy HTTP. 

Oppure, nel loro sistema, gli utenti potrebbero installare una Virtual Private Network (vpn).
Visitare: <url url="http://sunsite.auc.dk/vpnd/" name="http://sunsite.auc.dk/vpnd/">

O ancora questo utente potrebbe aggiungere un modem al sistema NT e accedere all'instradamento.

Infine sulla workstation, nella LAN privata, potrebbe cambiare il gateway di default in modo che punti al 
nuovo instradamento verso Internet.

Ora, dalla workstation, si può andare ovunque. L'unica cosa che l'amministratore del firewall potrebbe notare è 
che qualcuno si sta connettendo con un accesso DNS molto lungo.

Siete pronti a conquistare il mondo!


<SECT> APPENDICE A - Script di esempio
<p>

<SECT1> Script RC usando GFCC
<P>
<verb>
#!/bin/bash
#
# Firewall Script - Versione 0.9.1
#
# chkconfig: 2345 09 99
# description: script firewall per i kernel 2.2.x

# Da impostare per i test:
# set -x
#
# NOTE:
#
#  Questo script è stato scritto per la RedHat 6.1 o più recente.
#
#  Prestare attenzione per quanto riguarda l'offerta di servizi pubblici quali web o ftp server.
#
# INSTALLAZIONE:
#  1. si collochi questo file nella directory /etc/rc.d/init.d  (si deve essere root..)
#     lo si chiami con qualcosa come "firewall"    :-)
#     lo si renda di proprietà del root -->  "chown root.root (filename)"
#     lo si renda eseguibile -->  "chmod 755 (filename)"
#  2. si utilizzi GFCC per creare le regole per il firewall ed esportale in un file
#     con nome /etc/gfcc/rules/firewall.rule.sh
#
#  3. si aggiunga il firewall alla struttura init della RH --> "chkconfig --add (filename)"
#     Al successivo boot del router, tutto dovrebbe sistemarsi automagicamente!
#     si dorma pure tranquilli la notte sapendo di essere *MENO* vulnerabile di prima...
#
# NOTE SULLE VERSIONI:
#   30 Jan, 2000 - Modificato per lo script GFCC 
#   11 Dec, 1999 - aggiornamento di Mark Grennan &lt;mark@grennan.com&gt;
#   20 July, 1999 - scrittura iniziale - Anthony Ball &lt;tony@LinuxSIG.org&gt;

################################################

# Libreria funzioni.
. /etc/rc.d/init.d/functions

# Configurazione rete.
. /etc/sysconfig/network

# Controlla che la rete sia presente.
[ ${NETWORKING} = "no" ] && exit 0

# Controlla cosa è stato richiesto
case "$1" in

  start)
	# Inizia a fornire gli accessi 
	action "Starting firewall: " /bin/true
	/etc/gfcc/rules/firewall.rule.sh
	echo
	;;

  stop)
	action "Stoping firewall: " /bin/true
	echo 0 > /proc/sys/net/ipv4/ip_forward
	/sbin/ipchains -F input
	/sbin/ipchains -F output
	/sbin/ipchains -F forward

	echo
	;;

  restart)
	action "Restarting firewall: " /bin/true
	$0 stop
	$0 start

	echo
	;;

  status)
	# Visualizza elenco di tutte le regole
	/sbin/ipchains -L
	;;

  test)
	action "Test Mode firewall: " /bin/true
	/sbin/ipchains -F input
	/sbin/ipchains -F output
	/sbin/ipchains -F forward
	echo 1 > /proc/sys/net/ipv4/ip_forward
	/sbin/ipchains -A input -j ACCEPT
	/sbin/ipchains -A output -j ACCEPT
	/sbin/ipchains -P forward DENY
	/sbin/ipchains -A forward -i $PUBLIC -j MASQ

	echo
	;;

  *)
	echo "Usage: $0 {start|stop|restart|status|test}"
	exit 1

esac
</verb>
<P>

<SECT1> GFCC script
<p>
Questo script è stato generato da Graphical Firewall program (GFCC).  
Questo non è l'insieme delle regole in funzione, è l'insieme delle regole
esportate.
<verb>

#!/bin/sh
# Generato da Gtk+ firewall control center

IPCHAINS=/sbin/ipchains


localnet="192.168.1.0/24"
firewallhost="192.168.1.1/32"
localhost="172.0.0.0/8"
DNS1="24.94.163.119/32"
DNS2="24.94.163.124/32"
Broadcast="255.255.255.255/32"
Multicast="224.0.0.0/8"
Any="0.0.0.0/0"
mail_grennan_com="192.168.1.1/32"
mark_grennan_com="192.168.1.3/32"

$IPCHAINS -P input DENY
$IPCHAINS -P forward ACCEPT
$IPCHAINS -P output ACCEPT

$IPCHAINS -F
$IPCHAINS -X

# regole catena input
$IPCHAINS -A input -s $Any -d $Broadcast -j DENY 
$IPCHAINS -A input -p udp -s $Any -d $Any netbios-ns -j DENY 
$IPCHAINS -A input -p tcp -s $Any -d $Any netbios-ns -j DENY 
$IPCHAINS -A input -p udp -s $Any -d $Any netbios-dgm -j DENY 
$IPCHAINS -A input -p tcp -s $Any -d $Any netbios-dgm -j DENY 
$IPCHAINS -A input -p udp -s $Any -d $Any bootps -j DENY 
$IPCHAINS -A input -p udp -s $Any -d $Any bootpc -j DENY 
$IPCHAINS -A input -s $Multicast -d $Any -j DENY 
$IPCHAINS -A input -s $localhost -d $Any -i lo -j ACCEPT 
$IPCHAINS -A input -s $localnet -d $Any -i eth1 -j ACCEPT 
$IPCHAINS -A input -s $localnet -d $Broadcast -i eth1 -j ACCEPT 
$IPCHAINS -A input -p icmp -s $Any -d $Any -j ACCEPT 
$IPCHAINS -A input -p tcp -s $Any -d $Any -j ACCEPT ! -y 
$IPCHAINS -A input -p udp -s $DNS1 domain -d $Any 1023:65535 -j ACCEPT 
$IPCHAINS -A input -p udp -s $DNS2 domain -d $Any 1023:65535 -j ACCEPT 
$IPCHAINS -A input -p tcp -s $Any -d $Any ssh -j ACCEPT 
$IPCHAINS -A input -p tcp -s $Any -d $Any telnet -j ACCEPT 
$IPCHAINS -A input -p tcp -s $Any -d $Any smtp -j ACCEPT 
$IPCHAINS -A input -p tcp -s $Any -d $Any pop-3 -j ACCEPT 
$IPCHAINS -A input -p tcp -s $Any -d $Any auth -j ACCEPT 
$IPCHAINS -A input -p tcp -s $Any -d $Any www -j ACCEPT 
$IPCHAINS -A input -p tcp -s $Any -d $Any ftp -j ACCEPT 
$IPCHAINS -A input -s $Any -d $Any -j DENY -l 

# regole catena forward
$IPCHAINS -A forward -s $localnet -d $Any -j MASQ 

# regole catena output

</verb>


<SECT1> Script RC senza GFCC
<P>
Questo è l'insieme delle regole scritte di mio pugno per il firewall. 
Non si è utilizzato GFCC.
<verb>

  #!/bin/bash
  #
  # Firewall Script - Versione 0.9.0

  # chkconfig: 2345 09 99
  # description: script firewall per kernel 2.2.x

  # Da impostare per i test: 
  # set -x

  #
  # NOTE:
  #
  #  Questo script è stato realizzato per essere utilizzato con la RedHat 6.0 o versioni più recenti.
  #
  #  Questo script dovrebbe funzionare con la maggior parte dei router, dial-up e modem. 
  #  E' stato scritto per le distribuzioni RedHat.
  #
  #  Prestare attenzione nel caso si desideri offrire servizi pubblici come web o ftp server.
  #
  # INSTALLAZIONE:
  #  1. Questo file è pensato per un sistema RedHat. Dovrebbe 
  #     funzionare, forse senza apportare modifiche, anche su altre distro, ma 
  #     ancora...chi lo sa ?!!? Queste istruzioni riguardano i sistemi RedHat.
  #
  #  2. si collochi questo file in /etc/rc.d/init.d  (si dovrà essere l'utente root..)
  #     e lo si denomini con qualcosa come "firewall"    :-)
  #     lo si renda di proprietà del root -->  "chown root.root <filename>"
  #     lo si renda eseguibile -->  "chmod 755 <filename>"
  #
  #  3. Si impostino i valori in base alla propria rete, alle interfacce interne, e 
  #     ai server DNS.
  #     Si rimuovano i commenti alle linee presenti più avanti per abilitare 
  #     i servizi opzionali verso l'interno, 
  #     ci si assicuri che il proprio NIC interno sia "eth0" (altrimenti si cambi il valore 
  #     presente più avanti).
  #     lo si provi -->  "/etc/rc.d/init.d/<filename> start"
  #     si visualizzi un elenco delle regole -->  "ipchains -L -n"
  #     si sistemi tutto ciò che non va...  :-)
  #
  #  4. Si aggiunga il firewall alla struttura init della RH --> "chkconfig --add <filename>"
  #     Al boot successivo del root tutto dovrebbe impostarsi automagicamente!
  #     si dorma pure tranquilli la notte sapendo di essere *MENO* vulnerabile di prima...
  #
  # NOTE SULLE VERSIONI:
  #   20 July, 1999 - scrittura iniziale - Anthony Ball <tony@LinuxSIG.org>
  #   11 Dec, 1999 - aggiornamenti di Mark Grennan <mark@grennan.com>
  #

  ################################################
  #  Sostituire i valori sottostanti con quelli
  #  della propria rete locale.

  PRIVATENET=xxx.xxx.xxx.xxx/xx

  PUBLIC=ppp0
  PRIVATE=eth0

  # i propri server dns
  DNS1=xxx.xxx.xxx.xxx
  DNS2=xxx.xxx.xxx.xxx

  ################################################

  # alcuni pratici valori generici da usare 
  ANY=0.0.0.0/0
  ALLONES=255.255.255.255

  # Libreria funzioni.
  . /etc/rc.d/init.d/functions

  # Configurazione rete.
  . /etc/sysconfig/network

  # Controlliamo che la rete sia presente.
  [ ${NETWORKING} = "no" ] && exit 0

  # Vediamo cosa è stato richiesto.
  case "$1" in

    start)
          # Inizia a fornire gli accessi 
          action "Starting firewall: " /bin/true

          ##
          ## Setup 
          ##
          # Ripulisci tutte le liste
          /sbin/ipchains -F input
          /sbin/ipchains -F output
          /sbin/ipchains -F forward

          # Blocca qualsiasi cosa
          /sbin/ipchains -I input 1 -j DENY

          # imposta la tattica a deny (per default è ACCEPT)
          /sbin/ipchains -P input DENY
          /sbin/ipchains -P output ACCEPT
          /sbin/ipchains -P forward ACCEPT

          # Abilitiamo il packet forwarding
          echo 1 > /proc/sys/net/ipv4/ip_forward

          ##
          ## Installazione dei moduli
          ##
          # Inserire il modulo ftp attivo. Questo permetterà ftp non-passivo verso 
          # le macchine della rete locale (ma non verso il router in quanto non mascherato).
          if ! ( /sbin/lsmod | /bin/grep masq_ftp > /dev/null ); then
              /sbin/insmod ip_masq_ftp
          fi

          ##
          ## Alcune caratteristiche riguardanti la sicurezza
          ##
          # Abilitare il Source Address Verification su tutte le interfacce 
          # presenti e future per ottenere la protezione dallo spoof.
          if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
              for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
                  echo 1 > $f
              done
          else
              echo
		  echo "PROBLEMI NELL'ABILITARE LA PROTEZIONE DALL'IP SPOOFING.  FARE ATTENZIONE. "
              echo
          fi

          # scarta bcasts sulle interfacce restanti
          /sbin/ipchains -A input -d 0.0.0.0 -j DENY
          /sbin/ipchains -A input -d 255.255.255.255 -j DENY

          # scarta i seguenti senza loggarli in quanto tendono ad essere molti...
          /sbin/ipchains -A input -p udp -d $ANY 137 -j DENY   # NetBIOS su IP
          /sbin/ipchains -A input -p tcp -d $ANY 137 -j DENY   #   ""
          /sbin/ipchains -A input -p udp -d $ANY 138 -j DENY   #   ""
          /sbin/ipchains -A input -p tcp -d $ANY 138 -j DENY   #   ""
          /sbin/ipchains -A input -p udp -d $ANY 67 -j DENY    # bootp
          /sbin/ipchains -A input -p udp -d $ANY 68 -j DENY    #   ""
          /sbin/ipchains -A input -s 224.0.0.0/8 -j DENY       # indirizzi Multicast

          ##
          ## Permetti alla rete locale di uscire
          ##
          # accetta tutti i pacchetti sull'interfaccia loopback
          /sbin/ipchains -A input -i lo -j ACCEPT

          # accetta tutti i pacchetti provenienti dalle interfacce interne "fidate"
          /sbin/ipchains -A input -i $PRIVATE -s $PRIVATENET -d $ANY -j ACCEPT
          /sbin/ipchains -A input -i $PRIVATE -d $ALLONES -j ACCEPT

          ##
          ## Permetti accessi dall'esterno ai servizi del firewall (se si vuole osare)
          ##
          # accetta pacchetti ICMP
          /sbin/ipchains -A input -p icmp -j ACCEPT
          # accetta pacchetti TCP
          /sbin/ipchains -A input -p tcp ! -y -j ACCEPT

          # permetti richieste DNS (al firewall)
          /sbin/ipchains -A input -p udp -s $DNS1 domain -d $ANY 1023: -j ACCEPT
          /sbin/ipchains -A input -p udp -s $DNS2 domain -d $ANY 1023: -j ACCEPT
          # o (IDEA MIGLIORE) esegui un server DNS caching sul router e usa le 
          # seguenti due linee al loro posto ...
          # /sbin/ipchains -A input -p udp -s $DNS1 domain -d $ANY domain -j ACCEPT
          # /sbin/ipchains -A input -p udp -s $DNS2 domain -d $ANY domain -j ACCEPT

          # rimuovi il commento dalla seguente linea per accettare richieste ssh 
          /sbin/ipchains -A input -p tcp -d $ANY 22 -j ACCEPT

          # rimuovi il commento dalla seguente linea per accettare richieste telnet (PESSIMA IDEA!!) 
          /sbin/ipchains -A input -p tcp -d $ANY telnet -j ACCEPT

          # rimuovi il commento dalla seguente linea per permettere NTP (network time protocol) verso il router
          # /sbin/ipchains -A input -p udp -d $ANY ntp -j ACCEPT

          # rimuovi il commento dalla seguente linea per permettere SMTP (non per i client mail - solo server)
          /sbin/ipchains -A input -p tcp -d $ANY smtp -j ACCEPT

          # rimuovi il commento per permettere POP3 (per client mail)
          /sbin/ipchains -A input -p tcp -d $ANY 110 -j ACCEPT

          # rimuovi il commento dalla seguente linea per inviare mail o effettuare ftp 
          /sbin/ipchains -A input -p tcp -d $ANY auth -j ACCEPT

          # rimuovi il commento alla seguente linea per permettere HTTP (solo se si sta eseguendo un web server sul router)
          /sbin/ipchains -A input -p tcp -d $ANY http -j ACCEPT

          # rimuovi il commento alla seguente linea per accettare richieste FTP
          /sbin/ipchains -A input -p tcp -d $ANY ftp -j ACCEPT

          ##
          ## Masquerading 
          ##
          # maschera i pacchetti provenienti dalla rete locale 
          /sbin/ipchains -A forward -s $PRIVATENET -d $ANY -j MASQ

          ##
          ## scarta QUALSIASI altra cosa e registrala in /var/log/messages
          ##
          /sbin/ipchains -A input -l -j DENY

          # Rimuovi il blocco
          /sbin/ipchains -D input 1

          ;;

    stop)
          action "Stoping firewall: " /bin/true
          echo 0 > /proc/sys/net/ipv4/ip_forward
          /sbin/ipchains -F input
          /sbin/ipchains -F output
          /sbin/ipchains -F forward

          echo
          ;;

    restart)
          action "Restarting firewall: " /bin/true
          $0 stop
          $0 start

          echo
          ;;

    status)
          # Elenca le impostazioni
          /sbin/ipchains -L
          ;;

    test)
          ##
          ##     E' alquanto semplice  
          ##    (Non è AFFATTO sicuro)
          action "WARNING Test Firewall: " /bin/true
          /sbin/ipchains -F input
          /sbin/ipchains -F output
          /sbin/ipchains -F forward
          echo 1 > /proc/sys/net/ipv4/ip_forward
          /sbin/ipchains -A input -j ACCEPT
          /sbin/ipchains -A output -j ACCEPT
          /sbin/ipchains -P forward DENY
          /sbin/ipchains -A forward -i $PUBLIC -j MASQ

          echo
          ;;

    *)
          echo "Usage: $0 {start|stop|restart|status|test}"
          exit 1

  esac


esac

</VERB>

<SECT> APPENDICE B - Script RC VPN per la RedHat
<p>

<VERB>

  #!/bin/sh
  #
  # vpnd            Questo script basato sulla shell provvederà ad avviare e
  #                 a chiudere vpnd (Virtual Privage Network connections).  
  #
  # chkconfig: - 96 96
  # description: vpnd
  #

  # Libreria funzioni.
  . /etc/rc.d/init.d/functions

  # Configurazione rete.
  . /etc/sysconfig/network

  # Controlla che la rete sia presente.
  [ ${NETWORKING} = "no" ] && exit 0

  [ -f /usr/sbin/vpnd ] || exit 0

  [ -f /etc/vpnd.conf ] || exit 0

  RETVAL=0

  # Vediamo cosa è stato richiesto. 
  case "$1" in
    start)
          # Avvia i daemon.
          echo -n "Starting vpnd: "
          daemon vpnd
          RETVAL=$?
          [ $RETVAL -eq 0 ] && touch /var/lock/subsys/vpnd
          echo
          ;;
    stop)
          # Ferma i daemon.
          echo -n "Shutting down vpnd: "
          killproc vpnd
          RETVAL=$?
          [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/vpnd
          echo
          ;;
    restart)
          $0 stop
          $0 start
          ;;
    *)
          echo "Usage: vpnd {start|stop|restart}"
          exit 1
  esac

  exit $RETVAL

</VERB>





<sect>Nota sulla traduzione
<P>
La traduzione originale di questo HOWTO è opera della Apogeo <url
url="http://www.apogeonline.com/">, per il libro <bf/Linux HowTo (La
bibbia di Linux)/ realizzato in
collaborazione con il Pluto. L'Apogeo ha gentilmente concesso questa
ed altre traduzioni ad ILDP per la sua diffusione elettronica.
<P>
Conversione in SGML e correzione a cura di Giovanni Bortolozzo
<htmlurl url="mailto:borto@pluto.linux.it"
name="bortopluto.linux.it">, cui vanno segnalati pure eventuali
errori, incongruenze ecc.</P>
<P>Aggiornamento alla versione 0.80 ad opera di Marco Masetti <htmlurl url="mailto:marcomas@libero.it"
name="marcomas@libero.it">.
</P> 

</article>
