Configurare Linux come un Firewall

Firewalling and Proxy Server HOWTO


1. Introduzione

Il Firewall-HOWTO originale è stato scritto da David Rudder,
drig@execpc.com. Vorrei ringraziarlo per avermi consentito di
aggiornare il suo lavoro.

I Firewall hanno raggiunto una grande popolarità recentemente 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 a cosa è un
firewall, come impostarne uno, cosa sono i proxy server, come
impostare i proxy server e le applicazioni di questa tecnologia al di
fuori delle cose strettamente connesse con la sicurezza.


1.1. Commenti

Qualsiasi commento è più che benvenuto. SIETE PREGATI DI COMUNICARE
OGNI INESATTEZZA CONTENUTA IN QUESTO DOCUMENTO!!! 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.

Il mio indirizzo email è markg@netplus.net.


1.2. Avvertenze

NON SONO RESPONSABILE DI EVENTUALI DANNI CAUSATI DA AZIONI BASATE SUL
CONTENUTO DI QUESTO DOCUMENTO. Deve essere visto come un'introduzione
al modo di lavorare dei firewall e dei proxy server. Non sono, e non
pretendo di esserlo, un esperto di sicurezza. Sono solo una persona
che ha letto troppi libri 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 posso
scommettere sull'accuratezza del suo contenuto.


1.3. Copyright (in inglese)

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 contact Mark Grennan at
<markg@netplus.net>.


L'unica licenza valida è quella originale in lingua inglese.
Di seguito ne trovate una traduzione abbastanza fedele che
però non ha alcun valore.


Se non specificato diversamente, il copyright dei documenti HOWTO di
Linux appartiene ai loro rispettivi autori. I documenti HOWTO di Linux
possono essere riprodotti e distribuiti nella totalità o in parte, su
ogni mezzo fisico o elettronico, purché questo messaggio sia contenuto
in tutte le copie. È consentita e incoraggiata la ridistribuzione
commerciale; tuttavia, all'autore piacerebbe ricevere informazioni su
ciascuna di tali distribuzioni.

Tutte le traduzioni, lavori derivati o lavori aggregati che contengono
qualsiasi documento HOWTO di Linux devono essere ricoperti da questo
messaggio di copyright. Ossia, non è possibile produrre un lavoro
derivato da un HOWTO e imporre delle restrizioni addizionali alla sua
distribuzione. Eventuali eccezioni a queste regole possono essere
concesse sotto particolari condizioni; si prega di contattare il
coordinatore degli HOWTO di Linux.

In breve, desideriamo promuovere la diffusione di queste informazioni
attraverso più canali possibile. Tuttavia, vogliamo mantenere il
copyright sui documenti HOWTO, e gradiremmo essere informati su
qualsiasi intenzione di ridistribuire gli HOWTO.

Per qualsiasi domanda, contattare Mark Grennan all'indirizzo
<markg@netplus.net>.


1.4. Perché ho scritto questo documento

Anche se durante gli ultimi anni si sono svolte molte discussioni
relative al firewalling su comp.os.linux.*, ho trovato difficile
reperire le informazioni necessarie per impostare un firewall. La
versione originale di questo HOWTO è stata utile ma incompleta. Spero
che questa versione del Firewall HOWTO di David Rudder possa fornire a
chiunque le informazioni necessarie per creare un firewall funzionante
in poche ore e non in alcune settimane.

Sento anche di dover restituire qualcosa alla comunità di Linux.


1.5. Da fare


· Dare un po' di istruzioni sull'impostazione dei client

· Trovare un buon proxy server UDP che funzioni con Linux


1.6. Ulteriore documentazione


· Il NET-2 HOWTO


· L'Ethernet HOWTO

· Il Multiple Ethernet Mini HOWTO

· Networking with Linux

· Il PPP HOWTO

· TCP/IP Network Administrator's Guide di O'Reilly and Associates

· La documentazione per il TIS Firewall Toolkit

Il sito web della Trusted Information System (TIS) contiene una grande
quantità di documentazione sui firewall e materiale correlato:
http://www.tis.com/.

Inoltre, sto lavorando su un progetto di sicurezza chiamato Secure
Linux. Sul sito web di Secure Linux sto raccogliendo tutte le
informazioni, la documentazione e i programmi necessari per creare un
sistema Linux affidabile. Inviatemi una email se desiderate ricevere
delle informazioni.


2. Comprendere i Firewall

Firewall (che significa letteralmente 'parafiamme', n.d.t.) è un
termine utilizzato per una parte dell'automobile. In essa, i firewall
sono degli oggetti fisici che separano il motore dai passeggeri.
Servono per proteggere i passeggeri nel caso in cui il motore si
incendi, fornendo nel contempo al guidatore la possibilità di accedere
ai controlli del motore.

Un firewall nei computer è un dispositivo che protegge una rete
privata dalla parte pubblica (ossia dal resto di Internet).

Un computer firewall, d'ora in poi denominato "firewall", è in grado
di raggiungere sia la rete protetta, sia Internet. La rete protetta
non può raggiungere Internet, e Internet non può raggiungere la rete
protetta.

Alcuni, per raggiungere Internet dall'interno della rete protetta,
devono eseguire un telnet al firewall e da qui possono utilizzare
Internet.

La forma più semplice di un firewall consiste in un sistema "dual
homed" (ossia, un sistema con due connessioni di rete). Se ci si può
fidare completamente di TUTTI i propri utenti, è possibile configurare
in modo semplice Linux (compilarlo disabilitando l'opzione di IP
forwarding/gatewaying!) e fornire a tutti un account su di esso. In
questo modo, gli utenti potranno collegarsi a tale sistema ed eseguire
telnet, FTP, leggere la posta, e utilizzare ogni altro servizio
fornito. Con questa impostazione, l'unico computer sulla propria rete
privata che conosce tutto del mondo esterno è il firewall. Un altro
sistema sulla propria rete protetta non necessita neanche di un
instradamento predefinito ("default route").

Questo va sottilineato: affinché il firewall suddetto funzioni CI SI
DEVE POTER FIDARE DI TUTTI I PROPRI UTENTI! Per questo motivo non lo
consiglio.


2.1. Svantaggi dei Firewall

Il problema con i firewall filtranti deriva dal fatto che inibiscono
l'accesso alla propria rete da Internet. È posibile accedere ai soli
servizi sui sistemi che contengono dei filtri di passaggio ("pass
filter"). Con un proxy server gli utenti possono connettersi al
firewall e accedere a ogni sistema all'interno della rete privata a
cui hanno accesso.

Inoltre, stanno nascendo quasi ogni giorno nuove tipologie di client e
server. Quando questo accade, è necessario trovare un nuovo modo per
consentire un accesso controllato prima che il servizio possa essere
utilizzato.


2.2. Tipi di Firewall

Esistono due tipologie di firewall.


1. Firewall IP o Filtranti - che bloccano tutto ad eccezione del
traffico di rete selezionato.

2. Proxy Server - che creano le connessioni di rete per voi.


2.2.1. Firewall IP Filtranti

Un firewall filtrante IP funziona a livello di pacchetto. È progettato
per controllare il flusso di pacchetti basandosi sulla sorgente, sulla
destinazione, sulla porta e sull'informazione sul tipo di pacchetto
contenuto in ciascun pacchetto.

Questo tipo di firewall è molto sicuro ma è carente in ogni forma
utile di registrazione delle attività ("logging"). Può bloccare
l'accesso degli utenti al sistema privato ma non è in grado di dire
chi ha eseguito l'accesso ai propri sistemi pubblici o chi ha usato
Internet dall'interno.

I firewall filtranti sono filtri assoluti. Se si vuole dare a qualcuno
un accesso esterno ai propri server privati, non è possibile farlo
senza dare a tutti l'accesso ai server.

Linux ha nel kernel un software di filtraggio dei pacchetti a partire
dalla versione 1.3.x.


2.2.2. Proxy Server

I Proxy server consentono l'accesso indiretto a Internet attraverso il
firewall. Il migliore esempio di come ciò funziona è fornito dal caso
di una persona che esegue un telnet a un sistema e da qui esegue
nuovamente il telnet a un altro sistema. Tale processo è automatico
solo con un proxy server. Quando ci si connette a un proxy server con
il proprio software client, il proxy server avvia il suo software
client (proxy) e fornisce i dati.

Dal momento che i proxy server duplicano tutte le comunicazioni, sono
in grado di mantenere il log di tutto quello che fanno.

Un grande vantaggio dei proxy server consiste nel fatto che sono
completamente sicuri, se configurati correttamente. Non consentiranno
a qualcuno di attraversarli. Non ci sono instradamenti IP diretti.


3. Impostazione del Firewall

3.1. Requisiti hardware

Nel nostro esempio, il computer è un 486-DX66 con 16 MB di memoria e
500MB di partizione Linux. Questo sistema possiede due schede di rete:
una connessa alla propria LAN privata, l'altra connessa alla LAN che
chiameremo 'zona demilitarizzata' (DMZ). Alla DMZ è connesso un
router, a sua volta connesso ad Internet.

Questa è una configurazione abbastanza standard, comunque si potrebbe
utilizzare una scheda di rete e un modem con PPP per connettersi ad
Internet. Il punto è che il firewall deve avere due numeri di rete IP.

Conosco molte persone che hanno a casa propria una piccola LAN con due
o tre computer collegati ad essa. Si potrebbe pensare di mettere tutti
i propri modem in un box Linux (magari un vecchio 386) e connetterli
tutti ad Internet con un bilanciamento del carico (EQL). Con questa
impostazione, quando solo una persona riceve dei dati ha a
disposizione entrambi i modem duplicando quindi la velocità di
trasferimento. :-)


4. Software per firewall

4.1. Pacchetti disponibili

Se tutto quello che si desidera è un firewall filtrante, è necessario
solamente Linux e i pacchetti di rete basilari. Un pacchetto che
potrebbe non essere incluso nella propria distribuzione è l'IP
Firewall Administration tool.

(IPFWADM) Si trova su http://www.xos.nl/linux/ipfwadm/.

Se si vuole impostare un proxy server sarà necessario uno dei seguenti
pacchetti:


1. SOCKS

2. TIS Firewall Toolkit (FWTK)


4.2. Confronto tra TIS Firewall Toolkit e SOCKS

La Trusted Information System (http://www.tis.com) ha messo a
disposizione un insieme di programmi studiati per facilitare il
`firewalling'. I programmi fanno sostanzialmente le stesse cose fatte
dal pacchetto SOCKS, ma con una strategia di progettazione differente.
Mentre Socks ha un solo programma che copre tutte le transazioni con
Internet, TIS fornisce un programma per ogni utility che intenda
utilizzare il firewall.

Per fare un paragone, utilizziamo l'esempio dell'accesso world wide
web e Telnet. Con SOCKS, si imposta un file di configurazione e un
demone. Attraverso questo file e questo demone, sono abilitati sia
telnet che WWW, come pure ogni altro servizio che non è stato
disabilitato.

Con il toolkit TIS, si imposta un demone per il WWW e uno per telnet,
come pure un file di configurazione per ognuno di essi. Dopo aver
fatto questo, altri accessi ad Internet sono proibiti se non impostati
esplicitamente. Se non è stato fornito il demone per una utility
specifica (come, ad esempio, talk), esiste un demone "plug-in", ma non
può essere considerato né così flessibile, né così semplice da
impostare, come gli altri tool.

Sebbene possa sembrare una cosa di poco conto, si tratta invece di una
differenza sostanziale. SOCKS permette di essere 'trasandati'. Con un
server SOCKS impostato con superficialità, qualcuno dall'interno
potrebbe ottenete un accesso ad Internet maggiore di di quanto si
desiderasse consentire. Con il toolkit TIS, le persone dall'interno
avranno solo gli accessi desiderati dall'amministratore del sistema.

SOCKS è più semplice da impostare, più facile da compilare e consente
una flessibilità maggiore. Il tollkit TIS è più sicuro se si vogliono
regolamentare gli utenti all'interno della rete protetta. Entrambi
forniscono protezione assoluta dall'esterno.

Verrà di seguito trattata l'installazione e l'impostazione di
entrambi.


5. Preparazione del sistema Linux

5.1. Compilazione del kernel

Si inizi con un'installazione pulita della propria distribuzione Linux
(io ho utilizzato RedHat 3.0.3 e gli esempi qui riportati si basano su
questa distribuzione). Meno software è stato installato, meno buchi,
porte di servizio ("backdoor") e/o bachi ci saranno in grado di
introdurre problemi di sicurezza nel proprio sistema; pertanto si
installi solamente un insieme minimo di applicazioni.

Si prenda un kernel stabile. Io ho utilizzato il kernel Linux 2.0.14
per il mio sistema. Pertanto, questa documentazione si basa sulle sue
impostazioni.

È necessario ricompilare il kernel Linux con le opzioni appropriate. A
questo punto, sarebbe utile dare un'occhiata al Kernel HOWTO,
all'Ethernet HOWTO, e il NET-2 HOWTO se non lo si ha ancora fatto.

Di seguito sono riportate le releative impostazioni di rete, che so
funzionanti nel 'make config';


1. Sotto "General setup"

a. Abilitare il "Networking Support"

2. Sotto "Networking Options"

a. Abilitare "Network firewalls"

b. Abilitare "TCP/IP Networking"

c. Disabilitare "IP forwarding/gatewaying" (A MENO CHE non si
voglia usare il filtraggio IP)

d. Abilitare "IP Firewalling"

e. Abilitare "IP firewall packet loggin" (ciò non è strettamente
necessario ma è comunque una buona idea)

f. Disabilitare "IP: masquerading" (non trattero questa cosa qui.)

g. Abilitare "IP: accounting"

h. Disbilitare "IP: tunneling"

i. Disbilitare "IP: aliasing"

j. Dibilitare "IP: PC/TCP compatibility mode"

k. Disabilitare "IP: Reverse ARP"

l. Abilitare "Drop source routed frames"

3. Sotto "Network device support"

a. Abilitare "Network device support"

b. Abilitare "Dummy net driver support"

c. Abilitare "Ethernet (10 or 100Mbit)"

d. Selezionare la propria scheda di rete


Ora è possibile ricompilare, reinstallare il kernel e riavviare il
sistema. La propria scheda (o schede) di rete dovrebbe essere mostrata
nella sequenza di avvio. Se questo non accade, consultare nuovamente
gli altri HOWTO finché non funziona.


5.2. Configurazione di due schede di rete

Se il proprio computer possiede due schede di rete, molto
probabilmente ci sarà bisogno di inserire un'istruzione "append" nel
proprio file /etc/lilo.conf per descrivere l'IRQ e l'indirizzo di
entrambe le schede. L'istruzione che io uso per lilo è:

append="ether=12,0x300,eth0 ether=15,0x340,eth1"


5.3. Configurazione degli indirizzi di rete

Questa è una parte molto interessante. Devono essere prese alcune
decisioni. Dal momento che non desideriamo che Intenet abbia accesso
ad alcuna parte della rete privata, non abbiamo bisogno di utilizzare
degli indirizzi reali. Esistono molti indirizzi internet messi da
parte per le reti private. Dal momento che ognuno ha bisogno di più
indirizzi e questi indirizzi non possono attraversare Internet, si
tratta di una buona scelta.

Tra quelli messi da parte c'è 192.168.2.xxx che utilizzeremo nei
nostri esempi.

Il proprio proxy firewall sarà un membro di entrambe le reti, pertanto
sarà in grado di passare i dati da e verso la rete privata.


199.1.2.10 __________ 192.168.2.1
_ __ _ \ | | / _______________
| \/ \/ | \| Firewall |/ | |
/ Internet \--------| System |------------| Workstation/s |
\_/\_/\_/\_/ |__________| |_______________|

Se si ha intenzione di utilizzare un firewall filtrante, è ancora
possibile utilizzare questi numeri. Però affinché ciò sia possibile si
deve usare il mascheramento IP. Con questo processo il firewall
inoltrerà i pacchetti e li tradurrà in indirizzi IP "REALI" per
viaggiare su Internet.

È necessario assegnare alla scheda di rete l'indirizzo IP reale sul
lato Internet, ed assegnare 192.168.2.1 alla scheda Ethernet sul lato
interno. Questo sarà il proprio indirizzo IP proxy/gateway. È
possibile assegnare a tutte le altre macchine nella rete protetta dei
numeri all'interno del range 192.168.2.xxx (da 192.168.2.2 a
192.168.2.254).
Dal momento che utilizzo Linux RedHat per configurare la rete
all'avvio del sistema, ho aggiunto un file 'ifcfg-eth1' nella
directory /etc/sysconfig/network-scripts. Questo file viene letto
durante il processo di boot per impostare la rete e le tabelle di
instradamento.

Il mio file ifcfg-eth1 è una cosa del genere:


#!/bin/sh
#>>>Tipo di dispositivo: ethernet
#>>>Dichiarazioni delle variabili:
DEVICE=eth1
IPADDR=192.168.2.1
NETMASK=255.255.255.0
NETWORK=192.168.2.0
BROADCAST=192.168.2.255
GATEWAY=199.1.2.10
ONBOOT=yes
#>>>Fine delle dichiarazioni delle variabili

È anche possibile utilizzare questi script per connettersi
automaticamente via modem al proprio provider. Si dia un'occhiata allo
script ipup-ppp.

Se si ha intenzione di utilizzare un modem per le proprie connessioni
Internet, il proprio indirizzo IP esterno verrà assegnato dal provider
al momento della connessione.


5.4. Verifica del funzionamento della rete

Si inizi controllando con ifconfig e route. Se si possiedono due
schede di rete l'output di ifconfig dovrebbe assomigliare a:


#ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.0 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:1620 errors:0 dropped:0 overruns:0
TX packets:1620 errors:0 dropped:0 overruns:0

eth0 Link encap:10Mbps Ethernet HWaddr 00:00:09:85:AC:55
inet addr:199.1.2.10 Bcast:199.1.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
Interrupt:12 Base address:0x310

eth1 Link encap:10Mbps Ethernet HWaddr 00:00:09:80:1E:D7
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
Interrupt:15 Base address:0x350

e la propria tabella di instradamento dovrebbe essere:


#route -n
Kernel routing table
Destination Gateway Genmask Flags MSS Window Use Iface
199.1.2.0 * 255.255.255.0 U 1500 0 15 eth0
192.168.2.0 * 255.255.255.0 U 1500 0 0 eth1
127.0.0.0 * 255.0.0.0 U 3584 0 2 lo
default 199.1.2.10 * UG 1500 0 72 eth0

Nota: 199.1.2.0 è il lato Internet di questo firewall e 192.168.2.0 è
il lato privato.

Ora si provi a fare ping ad internet dal firewall. Io di solito
utilizzo nic.ddn.mil come sito per il test. Si tratta ancora di un
buon test, tuttavia è stato dimostrato che è meno affidabile di quanto
sperassi. Se non funziona immediatamente, si tenti di eseguire il ping
ad un paio di altri siti non connessi alla propria LAN. Se non
funziona, significa che il proprio PPP non è impostato correttamente.
Si rilegga il NET-2 HOWTO, e si ritenti.

A questo punto, tentare il ping ad un host all'interno della rete
protetta dal firewall. Tutti i computer dovrebbero essere in grado di
eseguire il ping l'uno con l'altro. Se questo non accade, leggere
nuovamente il NET-2 HOWTO e lavorare ancora un po' sulla rete.

Ora si provi a fare ping all'indirizzo esterno del firewall
dall'interno della rete protetta (NOTA: questo non è nessuno dei
numeri IP 192.168.2.xxx). Se è stato possibile, non è stato
disabilitato l'IP Forwarding. Assicurarsi che ciò sia quello che si
desidera. Se lo si lascia abilitato sarà necessario leggere anche il
paragrafo relativo al filtraggio IP all'interno di questo documento.

Adesso, tentare di eseguire il ping ad Internet dall'interno del
proprio firewall. Utilizzare lo stesso indirizzo che prima funzionava
(ossia, nic.ddn.mil). Ancora una volta, se l'IP Forwarding è
disabilitato, questo tentativo non dovrebbe funzionare. Ma se è
abilitato, dovrebbe farlo.

Se è abilitato l'IP Forwarding e si sta utilizzando un indirizzo IP
"REALE" (non 192.168.2.*) per la propria rete privata, e non si riesce
ad eseguire il ping ad Internet sebbene lo si riesca a fare al lato
Internet del proprio firewall, controllare se il router successivo
stia in effetti instradando pacchetti per il proprio indirizzo privato
(potrebbe accadere che il proprio provider lo debba fare per noi).

Se si è assegnata la propria rete protetta a 192.168.2.*, nessun
pacchetto può essere instradato ad essa. Se si è abilitato il
mascheramento IP, questa verifica dovrebbe funzionare.

Ora il vostro sistema di base è impostato.


5.5. Sicurezza del Firewall

Un firewall non è di nessuna utilità se lasciato aperto agli attacchi
effettuabili attraverso un servizio non utilizzato. Un 'cattivone'
potrebbe ottenere l'accesso al firewall e modificarlo secondo le
proprie esigenze.

Si inizi disabilitando di tutti i servizi non necessari. Si dia
un'occhiata al file /etc/inetd.conf. Questo file controlla quello ciò
viene detto un "super server". Controlla una grande quantità di demoni
del server e li avvia quando richiesto.


Si disabiliti una volta per tutte netstat, systat, tftp, bootp e
finger. Per disabilitare un servizio, mettere un # come primo
carattere della linea del servizio. Una volta fatto, inviare un SIG-
HUP al processo digitando il comando "kill -HUP <pid>", dove <pid> è
il numero di processo di inetd. Ciò farà sì che inetd rilegga il suo
file di configurazione (inetd.conf) e si riavvii.

Verificare l'impostazione eseguendo un telnet alla porta 15 sul
firewall, la porta netstat. Se si ottiene l'output di netstat, non è
stato riavviato correttamente inetd.


6. Impostazione del filtraggio IP (IPFWADM)

Per iniziare, si dovrebbe aver abilitato l'IP Forwarding nel proprio
kernel e il proprio sistema dovrebbe essere avviato ed eseguire il
forwarding di qualsiasi cosa gli venga inviata. Le proprie tabelle di
instradamento dovrebbero essere a posto e si dovrebbe essere in grado
di accedere a qualsiasi cosa, sia dall'interno verso l'esterno, che
dall'esterno verso l'interno.

Ma dal momento che sta costruendo un firewall, si deve cominciare
limitando quello a cui tutti hanno accesso.

Nel mio sistema ho creato un paio di script per impostare la politica
di forwarding e di accounting. Questi script vengono richiamati dagli
script /etc/rc.d, pertanto il mio sistema viene configurato al momento
dell'avvio.

Di default il sistema di IP Forwarding nel kernel Linux inoltra tutto.
Per questo motivo, il proprio script firewall dovrebbe iniziare con il
negare l'accesso a tutto e reimpostare tutte le regole ipfw che
c'erano l'ultima volta che è stato eseguito. Questo script permette di
ottenere l'effetto desiderato.


#
# Imposta IP packet Accounting e Forwarding
#
# Forwarding
#
# Di default NEGA tutti i servizi
ipfwadm -F -p deny
# Scarica tutti i comandi
ipfwadm -F -f
ipfwadm -I -f
ipfwadm -O -f

Ora abbiamo il firewall finale. Niente può attraversarlo. Senza dubbio
esistono dei servizi verso i quali è necessario l'inoltro (forward),
pertanto seguono alcuni esempi che potrebbero essere utili.

# Inoltro delle email al proprio server
ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 192.1.2.10 25

# Inoltro delle connessioni email verso server email esterni
ipfwadm -F -a accept -b -P tcp -S 196.1.2.10 25 -D 0.0.0.0/0 1024:65535

# Inoltro delle connessioni Web al proprio Web Server
/sbin/ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 196.1.2.11 80

# Inoltro delle connessioni Web a un Web Server esterno
/sbin/ipfwadm -F -a accept -b -P tcp -S 196.1.2.* 80 -D 0.0.0.0/0 1024:65535

# Inoltro del traffico DNS
/sbin/ipfwadm -F -a accept -b -P udp -S 0.0.0.0/0 53 -D 196.1.2.0/24

È probabile che siate anche interessati all'avere un resoconto del
traffico che passa attraverso il proprio firewall. Questo script conta
ogni pacchetto. Si potrebbe aggiungere una riga o due per contare solo
i pacchetti che vanno verso un singolo sistema.


# Scarica tutte le regole di accounting correnti
ipfwadm -A -f
# Accounting
/sbin/ipfwadm -A -f
/sbin/ipfwadm -A out -i -S 196.1.2.0/24 -D 0.0.0.0/0
/sbin/ipfwadm -A out -i -S 0.0.0.0/0 -D 196.1.2.0/24
/sbin/ipfwadm -A in -i -S 196.1.2.0/24 -D 0.0.0.0/0
/sbin/ipfwadm -A in -i -S 0.0.0.0/0 -D 196.1.2.0/24

Se tutto quello che si voleva era un firewall filtrante, ci si può
fermare qui.


7. Installazione del Proxy Server TIS

7.1. Come ottenere il software


Il TIS FWTK è disponibile presso ftp://ftp.tis.com/.

Non ripetete il mio errore. Quando si esegue l'ftp dei file da TIS, SI
LEGGA IL README. L'fwtk TIS si trova in una directory nascosta sul
loro server. TIS richiede che si invii una email a fwtk-
request@tis.com con sola la parola SEND nel corpo del messaggio per
sapere il nome di questa directory nascosta. Il loro sistema, quindi,
invierà in risposta il nome della directory (valida per 12 ore) per
eseguire il download dei sorgenti.

Mentre sto scrivendo questo documento TIS sta rilasciando la versione
2.0 (beta) dell'FWTK. Questa versione sembra non avere problemi di
compilazione (con alcune eccezioni) e tutto sembra funzionare per il
meglio. Nel seguito verrà trattata proprio questa versione. Quando
verrà rilasciato il codice finale, aggiornerò l'HOWTO.

Per installare l'FWTK, creare una directory fwtk-2.0 all'interno della
propria directory /usr/src. Spostare la copia dell'FWTK
(fwtk-2.0.tar.gz) in questa directory ed eseguire l'untar (tar zxf
fwtk-2.0.tar.gz).

L'FWTK non fa il proxy di documenti web SSL, ma esiste un'aggiunta
scritta da Jean-Christophe Touvet. È disponibile presso
ftp://ftp.edelweb.fr/pub/contrib/fwtk/ssl-gw.tar.Z. Touvet non
supporta questo codice.

Io sto usando una versione modificata che include l'accesso ai server
news sicuri di Netscape scritta da Eric Wedel. È disponibile presso
ftp://mdi.meridian-data.com/pub/tis.fwtk/ssl-gw/ssl-gw2.tar.Z.

Nell'esempio verrà utilizzata la versione di Eric Wedel.

Per installarla, creare semplicemente una directory ssl-gw all'interno
della propria directory /usr/src/fwtk-2.0 e metterci i file.

Quando ho installato questo gateway, sono state necessarie alcune
modifiche prima di poter essere compilato con il resto del toolkit.

La prima modifica ha riguardato il file ssl-gw.c. Ho scoperto che non
includeva un file include necessario.


#if defined(__linux)
#include <sys/ioctl.h>
#endif

In secondo luogo, c'erano problemi con il Makefile. Ne ho copiato uno
dalle altre directory gateway e ho sosrituito il nome del gateway con
ssl-gw.


7.2. Compilazione dell'FWTK TIS

La versione 2.0 dell'FWTK può esere compilata molto più facilmente
rispetto alle versioni più vecchie. Ho trovato un altro paio di cose
da modificare prima di poter compilare correttamente la versione BETA.
Si spera che queste modifiche siano fatte nella versione finale.

Per correggere il tutto, si inizi spostandosi nella directory
/usr/src/fwtk/fwtk e copiando il file Makefile.config.linux sul file
Makefile.config.

NON ESEGUIRE FIXMAKE. Le istruzioni dicono di farlo. Ma se viene
fatto, rovinerà i makefile in ogni directory.

Il problema dipende dal fatto che lo script sed aggiunge un '.' ' e un
'' alla riga include di ogni Makefile. Questo script sed funziona.


sed 's/^include[ ]*\([^ ].*\)/include \1/' $name .proto > $name

Per continuare, bisogna modificare il file Makefile.config. Queste
sono le due modifiche che dobbiamo fare.

L'autore ha impostato la directory sorgente nella propria home
directory. Stiamo compilando il codice in /usr/src, pertanto si
dovrebbe cambiare la variabile FWTKSRCDIR.


FWTKSRCDIR=/usr/src/fwtk/fwtk

In secondo luogo, almeno qualche sistema Linux utilizza il database
gdbm. Il Makefile.config usa dbm. Potreste aver bisogno di modificare
questo. Io l'ho dovuto fare per RedHat 3.0.3.


DBMLIB=-lgdbm

L'ultimoìa correzione riguarda l'x-gw. Il baco nella versione BETA
risiede nel codice socket.c. Per sistemarlo, rimuovere le seguenti
righe di codice.


#ifdef SCM_RIGHTS /* 4.3BSD Reno and later */
+ sizeof(un_name->sun_len) + 1
#endif

Se è stato aggiunto ssl-gw alla propria directory sorgente FWTK, sarà
necessario aggiungerlo alla lista delle directory nel Makefile.


DIRS= smap smapd netacl plug-gw ftp-gw tn-gw rlogin-gw http-gw x-gw ssl-gw

Ora eseguire make.


7.3. Installazione dell'FWTK TIS

Eseguire make install.

La directory di installazione di default è /usr/local/etc. Potrebbe
essere sostituita (anch'io l'ho fatto) con una directory più sicura.
Ho deciso di modificare l'accesso a questa directory con 'chmod 700'.

Ora non resta che configurare il firewall.


7.4. Configurazione dell'FWTK TIS

Ora inizia il divertimento. Bisogna insegnare al sistema a chiamare
questi nuovi servizi e a creare le tabelle per controllarli.

Non ho intenzione di riscrivere il manuale di FWTK TIS in questo
documento. Mostrerò semplicemente le impostazioni che si sono
dimostrate funzionanti, inoltre spiegherò i problemi che ho
riscontrato e come sono riuscito a superarli.

I file che determinano i controlli sono tre.

/etc/services
Dice al sistema su quali porte si trova un servizio.

/etc/inetd.conf
Dice a inetd quale programma chiamare quando qualcuno "bussa"
alla porta di un servizio.

/usr/local/etc/netperm-table
Dice ai servizi dell'FWTK a chi abilitare e a chi negare un
servizio.


Per fare in modo che l'FWTK funzioni, questi file dovrebbero essere
modificati partendo dall'ultimo. La modifica dei file services senza
che siano stati impostati correttamente il file inetd.conf o netperm-
table potrebbe rendere il sistema inaccessibile.


7.4.1. Il file netperm-table

Questo file controlla chi può accedere ai servizi dell'FWTK TIS.
Bisognerebbe considerare il traffico utilizzando il firewall da
entrambe le parti. Gli utenti all'esterno della propria rete
dovrebbero identificarsi prima di ottenere l'accesso, ma gli utenti
dall'interno della propria rete potrebbero avere il permesso per
attraversarlo semplicemente.

Il firewall utilizza un programma denominato authsrv per mantenere un
database degli user ID e delle password degli utenti. La sezione per
l'autenticazione di netperm-table controlla dove risiede il database e
chi può accedervi.

Ho avuto qualche problema nel chiudere l'accesso a questo servizio. Si
noti che la riga premit-hosts mostrata utilizza un '*' per dare
l'accesso a tutti. L'impostazione corretta per questa riga consiste in
''authsrv: premit-hosts localhost'' se siete in grado di renderla
funzionante.


#
# Tabella di configurazione del Proxy
#
# Regole di autentificazione di server e client
authsrv: database /usr/local/etc/fw-authdb
authsrv: permit-hosts *
authsrv: badsleep 1200
authsrv: nobogus true
# Applicazioni Client che usano il server di Autentificazione
*: authserver 127.0.0.1 114

Per inizializzare il database, si faccia su a root ed si esegua
./authsrv nella directory /var/local/etc per creare il registro utenti
amministrativo. Viene di seguito riportato una sessione d'esempio.

Si invita a leggere la documentazione FWTK per imparare ad aggiungere
utenti e gruppi.

#
# authsrv
authsrv# list
authsrv# adduser admin "Auth DB admin"
ok - user added initially disabled
authsrv# ena admin
enabled
authsrv# proto admin pass
changed
authsrv# pass admin "plugh"
Password changed.
authsrv# superwiz admin
set wizard
authsrv# list
Report for users in database
user group longname ok? proto last
------ ------ ------------------ ----- ------ -----
admin Auth DB admin ena passw never
authsrv# display admin
Report for user admin (Auth DB admin)
Authentication protocol: password
Flags: WIZARD
authsrv# ^D
EOT
#

I controlli del gateway telnet (tn-gw) sono i primi da impostare.

Nell'esempio, ho supposto che gli host all'interno della rete privata
possano passare senza autenticarsi (permit-hosts 19961.2.* -passok).
Tuttavia, ogni altro utente deve inserire il proprio user ID e
password per utilizzare il proxy (permit-hosts * -auth).

Inoltre, consento a un altro sistema (196.1.2.202) di accedere
direttamente al firewall senza passare attraverso il firewall stesso.
Le due righe inetacl-in.telnetd definiscono questo. Più avanti viene
spiegato come sono richiamate queste righe.

Il timeout Telnet dovrebbe essere mantenuto breve.


# regole del gateway telnet:
tn-gw: denial-msg /usr/local/etc/tn-deny.txt
tn-gw: welcome-msg /usr/local/etc/tn-welcome.txt
tn-gw: help-msg /usr/local/etc/tn-help.txt
tn-gw: timeout 90
tn-gw: permit-hosts 196.1.2.* -passok -xok
tn-gw: permit-hosts * -auth
# Solo l'amministratore può fare telnet direttamente al Firewal
# tramite la Porta 24
netacl-in.telnetd: permit-hosts 196.1.2.202 -exec /usr/sbin/in.telnetd

I comandi r funzionano nello stesso modo di telnet.

# 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 196.1.2.* -passok -xok
rlogin-gw: permit-hosts * -auth -xok
# Solo l'Amministratore può eseguire direttamente il telnet al Firewall
netacl-rlogind: permit-hosts 196.1.2.202 -exec /usr/libexec/rlogind -a

È consigliabile che nessuno possa accedere direttamente al firewall,
incluso l'accesso in FTP. Pertanto, non mettere 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 i 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 rimane aperta una
connessione senza attività.


# regole gateway ftp:
ftp-gw: denial-msg /usr/local/etc/ftp-deny.txt
ftp-gw: welcome-msg /usr/local/etc/ftp-welcome.txt
ftp-gw: help-msg /usr/local/etc/ftp-help.txt
ftp-gw: timeout 300
ftp-gw: permit-hosts 196.1.2.* -log { retr stor }
ftp-gw: permit-hosts * -authall -log { retr stor }

I web, gopher e browser basati su ftp sono stravolti dall'http-gw. Le
prime due righe creano una directory per memorizzare i documenti ftp e
web come passano attraverso il firewall. Ho reso questi file di
proprietà di root e li ho messi in una directory accessibile solo da
root.

La connessione Web dovrebbe essere breve. Viene effettuato un
controllo sul tempo di attesa di un utente su una cattiva connessione.


# regole gateway www e gopher:
http-gw: userid root
http-gw: directory /jail
http-gw: timeout 90
http-gw: default-httpd www.afs.net
http-gw: hosts 196.1.2.* -log { read write ftp }
http-gw: deny-hosts *

L'ssl-gw è di fatto un semplice gateway "passatutto". Fare attenzione
ad esso. In questo esempio consento a tutti all'interno della rete
protetta di connettersi a qualsiasi server al di fuori della rete,
fatta eccezione per gli indirizzi 127.0.0.* e 192.1.1.* e solo sulle
porte da 443 a 563. Le porte da 443 a 563 sono conosciute come porte
SSL.


# regole gateway ssl:
ssl-gw: timeout 300
ssl-gw: hosts 196.1.2.* -dest { !127.0.0.* !192.1.1.* *:443:563 }
ssl-gw: deny-hosts *

Segue un esempio di come utilizzare il plug-gw per consentire
connessioni a un server di news. Nell'esempio, si abilitano tutti gli
utenti all'interno della rete privata a connettersi a un solo sistema
e solo alla sua porta di news.

La seconda riga consente agli utenti del server di news di ripassare i
dati alla rete protetta.

Dal momento che la maggior parte dei client si aspettano di restare
connessi mentre gli utenti leggono le news, il timeout per un server
di news dovrebbe essere lungo.


# NetNews Pluged gateway
plug-gw: timeout 3600
plug-gw: port nntp 196.1.2.* -plug-to 199.5.175.22 -port nntp
plug-gw: port nntp 199.5.175.22 -plug-to 196.1.2.* -port nntp

Il gateway finger è semplice. Chiunque dall'interno della rete
protetta deve prima eseguire il login e quindi ottiene l'abilitazione
a utilizzare il programma finger sul firewall. Tutti gli altri
ricevono semplicemente un messaggio.


# Abilitazione del servizio finger
netacl-fingerd: permit-hosts 196.1.2.* -exec /usr/libexec/fingerd
netacl-fingerd: permit-hosts * -exec /bin/cat /usr/local/etc/finger.txt

Io 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 una email.

 

7.4.2. Il file inetd.conf

Di seguito viene riportato un file /etc/inetd.conf completo. Tutti i
servizi non necessari sono stati commentati. È stato incluso il file
completo per mostrare cosa disabilitare, come pure per mostrare come
impostare i nuovi servizi firewall.


#echo stream tcp nowait root internal
#echo dgram udp wait root internal
#discard stream tcp nowait root internal
#discard dgram udp wait root internal
#daytime stream tcp nowait root internal
#daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
# FTP firewall gateway
ftp-gw stream tcp nowait.400 root /usr/local/etc/ftp-gw ftp-gw
# Telnet firewall gateway
telnet stream tcp nowait root /usr/local/etc/tn-gw /usr/local/etc/tn-gw
# local telnet services
telnet-a stream tcp nowait root /usr/local/etc/netacl in.telnetd
# Gopher firewall gateway
gopher stream tcp nowait.400 root /usr/local/etc/http-gw /usr/local/etc/http-gw
# WWW firewall gateway
http stream tcp nowait.400 root /usr/local/etc/http-gw /usr/local/etc/http-gw
# SSL firewall gateway
ssl-gw stream tcp nowait root /usr/local/etc/ssl-gw ssl-gw
# NetNews firewall proxy (using plug-gw)
nntp stream tcp nowait root /usr/local/etc/plug-gw plug-gw nntp
#nntp stream tcp nowait root /usr/sbin/tcpd in.nntpd
# SMTP (email) firewall gateway
#smtp stream tcp nowait root /usr/local/etc/smap smap
#
# Shell, login, exec e talk sono protocolli BSD.
#
#shell stream tcp nowait root /usr/sbin/tcpd in.rshd
#login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
#talk dgram udp wait root /usr/sbin/tcpd in.talkd
#ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
#dtalk stream tcp waut nobody /usr/sbin/tcpd in.dtalkd
#
# Servizi dmail pop e imap
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
#imap stream tcp nowait root /usr/sbin/tcpd imapd
#
# Servizio UUCP Internet.
#
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l
#
# Il servizio Tftp è fornito essenzialmente per l'avvio. La maggior
# parte dei siti lo eseguono solo su macchine che si comportano come
# "boot server". Non scommentare a meno che non si abbia *bisogno*
# di usarlo.
#
#tftp dgram udp wait root /usr/sbin/tcpd in.tftpd
#bootps dgram udp wait root /usr/sbin/tcpd bootpd
#
# Finger, systat e netstat forniscono informazioni utente che
# potrebbero essere preziose per potenziali "system crackers". Molti
# siti scelgono di disabilitare alcuni o tutti questi servizi per
# aumentare la sicurezza.
#
# cfinger è per il finger GNU, che attualmente non è in uso nel
# Linux RHS
#
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
#cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd
#systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx
#netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat -f inet
#
# Il servizio time viene utilizzato per la sincrinizzazione del clock.
#
#time stream tcp nowait root /usr/sbin/tcpd in.timed
#time dgram udp wait root /usr/sbin/tcpd in.timed
#
# Autenticazione
#
auth stream tcp wait root /usr/sbin/tcpd in.identd -w -t120
authsrv stream tcp nowait root /usr/local/etc/authsrv authsrv
#
# Fine di inetd.conf

7.4.3. Il file /etc/services

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 a una porta
qualsiasi. Ad esempio, io ho assegnato la porta di telnet
dell'amministratore (telnet-a) alla porta 24. Volendo, lo si può
assegnare alla porta 23. Affinchè l'amministratore (ossia voi stessi)
possa connettersi direttamente al firewall è necessario eseguire il
telnet alla porta 24 e non alla 23 e se il file netperm-table viene
impostato, come ho fatto io, sarà possibile farlo solamente da un
sistema all'interno della propria rete protetta.


telnet-a 24/tcp
ftp-gw 21/tcp # questo nome è cambiato
auth 113/tcp ident # Verifica dell'utente
ssl-gw 443/tcp

8. Il Proxy Server SOCKS

8.1. Impostazione del Proxy Server

Il proxy server SOCKS è disponibile su
ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-
src.tgz. In questa directory, esiste anche un esempio di file di
configurazione denominato "socks-conf". Decomprimere ed eseguire
l'untar dei file all'interno di una directory del proprio sistema, e
seguire le istruzioni su come effettuare make. Personalmente ho avuto
un paio di problemi durante make. Assicurarsi che i Makefile siano
corretti.

È importante notare che il proxy server deve essere aggiunto in
/etc/inetd.conf. È necessario aggiungere una riga:


socks stream tcp nowait nobody /usr/local/etc/sockd sockd

per dire al server di entrare in esecuzione quando richiesto.

8.2. Configurazione del Proxy Server

Il programma SOCKS ha bisogno di due file di configurazione separati.
Il primo per informare sugli 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 eseguiranno da se il proprio
instradamento.


8.2.1. Il file di accesso

Con socks 4.2c Beta, il file di accesso è denominato "sockd.conf".
Dovrebbe contenere 2 righe, una riga permit e una riga deny. Ogni riga
conterrà tre campi:


· L'Identificatore (permit/deny)

· L'indirizzo IP

· Il modificatore di indirizzo

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 in una tipica notazione IP.
Ossia, 192.168.2.0.

Anche il modificatore di indirizzo è un tipico indirizzo IP
rappresentato da un numero di 4 byte. Funziona come un netmask.
Supponiamo che questo numero sia a 32 bit (1 o 0). Se il bit è un 1,
il bit corrispondente dell'indirizzo che sta controllando deve essere
uguale al corrispondente bit nel campo dell'indirizzo IP.

Ad esempio, se la riga è:


permit 192.168.2.23 255.255.255.255

saranno ammessi solo gli indirizzi IP i cui bit corrispondono
192.168.2.23, ossia, solo 192.168.2.23. La riga:


permit 192.168.2.0 255.255.255.0

ammetterà ogni numero all'interno del gruppo da 192.168.2.0 a
192.168.2.255, l'intero dominio di Classe C. Non si dovrebbe avere la
riga:


permit 192.168.2.0 0.0.0.0

dal momento che ammetterà ogni indirizzo, indistintamente.

Pertanto, prima di tutto abilitare tutti gli indirizzi che si vogliono
abilitare, negare i restanti. Per ammettere tutti nel dominio
192.168.2.xxx, le righe:

permit 192.168.2.0 255.255.255.0
deny 0.0.0.0 0.0.0.0

funzioneranno correttamente. Notare "0.0.0.0" iniziale nella riga
deny. Con un modificatore di 0.0.0.0, il campo dell'indirizzo IP non è
rilevante. Tutti zero è la norma perché è semplice digitarli.

È consentito più di una voce di ciascun tipo.

È anche possibile fornire o negare gli accessi a degli utenti
specifici, tramite l'autentificazione ident. Non tutti i sistemi
supportano ident, tra cui Trumpet Winsock, pertanto questo argomento
non sarà trattato in questa sede. Si veda la documentazione di socks
per maggiori informazioni.


8.2.2. Il file di instradamento

Il file di instradamento in SOCKS è infelicemente chiamato
"socks.conf". Il nome è molto simile a quello del file di accesso,
pertanto potrebbe essere facile confonderli.

Il file di instradamento informa il client SOCKS su quando utilizzare
socks e quando non farlo. Ad esempio, nella nostra rete, 192.168.2.3
non avrà bisogno di utilizzare socks per parlare con 192.168.2.1, il
firewall, in quanto possiede una connessione diretta via Ethernet e
definisce automaticamente 127.0.0.1, il loopback. Naturalmente non è
necessario SOCKS per parlare a se stessi.

Esistono tre voci:

· deny

· direct

· sockd

Deny informa SOCKS su quando respingere una richiesta. Questo 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 informa sugli 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. Il nostro esempio
avrebbe:


direct 192.168.2.0 255.255.255.0

che permette di andare direttamente a qualsiasi cosa nella nostra rete
protetta.

La voce sockd informa il computer su quali host possiedono il demone
di server socks. La sintassi è:

sockd @=<serverlist> <IP address> <modifier>

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.

8.2.3. DNS da dietro un firewall

L'impostazione del Domain Name Service da dietro un firewall è un
compito relativamente semplice. È necessario solamente impostare il
DNS sulla macchina con firewall. Quindi configurare ogni macchina
dietro al firewall in modo che possa utilizzare questo DNS.


8.3. Lavorare con un Proxy Server

8.3.1. Unix

Per fare in modo che le proprie applicazioni funzionino con il proxy
server, devono essere ``SOCKettizzate''. Sono necessarie due diverse
tipologie di telnet, una per la comunicazione diretta, 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, vogliamo
rinominare tutti i programmi sulla rete protetta e sostituirli con i
programmi SOCKettizzati. "finger" diventa "finger.orig", "telnet"
diventa "telnet.orig" ecc. Bisogna 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.2.1 nel nostro caso) nel campo SOCKS sotto i Proxy.
Ogni applicazione avrà bisogno di almeno qualche modifica,
indipendentemente da come gestisce un proxy server.


8.3.2. MS Windows con Trumpet Winsock

Trumpet Winsock viene già distribuito con il supporto intrinseco per i
server proxy. Nel menu di "setup", inserire l'indirizzo IP del server,
e gli indirizzi di tutti i computer raggiungibili direttamente.
Quindi, Trumpet gestirà tutti i pacchetti in uscita.


8.3.3. Come far funzionare il Proxy Server con i pacchetti UDP

Il pacchetto SOCKS funziona solamente con i pacchetti TCP, non con
quelli UDP. Questa caratteristica lo rende leggermente meno utile.
Molti programmi utili, come talk e Archie, utilizzano UDP. Esiste un
pacchetto studiato per essere usato come un proxy server per pacchetti
UDP denominato UDPrelay, di Tom Fitzgerald <fitz@wang.com>.
Sfortunatamente, nel momento in cui viene scritto questo documento,
non è compatibile con Linux.

8.4. Svantaggi dei Proxy Server

Il proxy server è, soprattutto, un dispositivo di sicurezza. Un suo
utilizzo per aumentare l'accesso ad internet con indirizzi IP limitati
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:


· 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 cercate di connettervi
al firewall, ma dal momento che tutti hanno un accesso proxy
server, nessuno ha impostato un account per voi.

· Vostra figlia va al college. Volete inviarle una 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 di posta privata.

· L'incapacità di utilizzare i pacchetti UDP rappresenta un grande
svantaggio dei proxy server. Immagino che le carateristiche UDP
saranno disponibili a breve.

FTP provoca un altro problema con un proxy server. Quando si riceve o
si esegue un comando ls, il server FTP apre un socket sulla macchina
client e invia le informazioni attraverso esso. Un proxy server non
permetterà di farlo, pertanto FTP non funziona 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, 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 utilizare un emulatore IP,
come Term, Slirp o TIA. Term è disponibile su ftp://sunsite.unc.edu,
Slirp su ftp://blitzen.canberra.edu.au/pub/slirp, e TIA su
marketplace.com. Questi pacchetti saranno più veloci, consentiranno
connessioni migliori e forniranno un livello maggiore di accesso alla
rete interna da Internet. I proxy server vanno bene per le reti con
molti host che si vogliono connettere alla rete esterna con una sola
impostazione e con poco lavoro successivo.


9. Configurazioni avanzate

Esiste un'altra configurazione di cui vorrei parlare prima di chiudere
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 relativamente a quanto è
stato descritto finora, o se siete semplicemente interessati alla
versatilità dei proxy server e dei firewall, continuate la lettura.

9.1. Una rete ampia con enfasi sulla sicurezza

Supponiamo, ad esempio, di voler mettere in rete il proprio 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:

1. Il livello esterno. Si tratta del livello disponibile a tutti. È il
luogo dove si cercano nuovi volontari.

2. Truppa. Questo è il livello di persone che hanno superato il
livello esterno. È il luogo vengono istruiti sul governo diabolico
e su come fabbricare delle bombe.

3. Mercenari. Questo è il livello dove sono tenuti i piani veri. 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
bassa importanza e cosa è immagazzinato veramente nell'hangar
dell'area 51.


9.1.1. Impostazione della rete

I numeri IP sono costruiti in modo che:


· Un numero è 192.168.2.255, che rappresenta l'indirizzo di
trasmissione e non è utilizzabile.

· 23 dei 32 indirizzi IP sono allocati a 23 macchine che saranno
accessibili da Internet.

· Un IP extra va ad una Linux box sulla rete.

· Un IP extra va a un'altra Linux box sulla rete.

· Due IP vanno al router.

· Quattro sono lasciati liberi, ma ad essi sono assegnati nomi di
dominio quali paul, ringo, john, e george, tanto per confondere un
po' le idee.

· Le reti protette hanno entrambe gli indirizzi 192.168.2.xxx.

Quindi, vengono costruite due reti separate, ognuna localizzata in
posti diversi. L'istradamento può avvenire tramite Ethernet a
infrarossi in modo che sia completamente invisibile alle postazioni
esterne. Fortunatamente, ethernet a infrarossi funziona esattamente
come ethernet normale.

Queste reti sono entrambe connesse a uno dei box Linux tramite un
indirizzo IP extra.

Esiste in 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.2.17
della rete della Truppa e l'indirizzo 192.168.2.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.2.xxx se non gli
viene richiesto esplicitamente di farlo, pertanto Internet non sarà in
grado di entrare. La ragione per cui disabilitare 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.


9.1.2. Impostazione del Proxy

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.


1. Nessuno può utilizare il file server per l'accesso ad Internet.
Questo espone il file server a virus e altri problemi, ed è molto
importante, pertanto da evitare.

2. Non verrà consentito l'accesso della Truppa al World Wide Web. dal
momento che sono in addestramento, questo potere di recuperare le
informazioni potrebbe essere pericoloso.

Pertanto, il file sockd.conf sul box Linux della Truppa conterrà la
riga:


deny 192.168.2.17 255.255.255.255

e sulla macchina Mercenari:


deny 192.168.2.23 255.255.255.255

Inoltre, il box Linux della Truppa conterrà la riga:


deny 0.0.0.0 0.0.0.0 eq 80

che indica di negare l'accesso al tutte le macchine che cercano di
accedere alla porta uguale (eq) a 80, la porta http. Questo continuerà
a consentire tutti gli altri servizi, ma nega solamente l'accesso a
Web.

Quindi, entrambi i file conterranno:


permit 192.168.2.0 255.255.255.0


per consentire a tutti i computer sulla rete 192.168.2.xxx di
utilizzare questo proxy server fatta eccezione per quelli ai quali
l'accesso è già stato negato (cioè, il file server e l'accesso a Web
per la rete Truppa).

Il file sockd.conf della Truppa avrà il seguente formato:


deny 192.168.2.17 255.255.255.255
deny 0.0.0.0 0.0.0.0 eq 80
permit 192.168.2.0 255.255.255.0

e il file Mercenari:


deny 192.168.2.23 255.255.255.255
permit 192.168.2.0 255.255.255.0

Questo dovrebbe configurare tutto correttamente. Ogni rete è isolata
di conseguenza, con l'appropriato numero di interazioni.

Ora siete pronti !

Copyright (c) 2000-3000 by Eduardo Palena - Napolifirewall.com