<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>Firewalling and Proxy Server HOWTO: Il proxy server SOCKS</TITLE>
<LINK HREF="Firewall-HOWTO-12.html" REL=next>
<LINK HREF="Firewall-HOWTO-10.html" REL=previous>
<LINK HREF="Firewall-HOWTO.html#toc11" REL=contents>
</HEAD>
<BODY>
<A HREF="Firewall-HOWTO-12.html">Avanti</A>
<A HREF="Firewall-HOWTO-10.html">Indietro</A>
<A HREF="Firewall-HOWTO.html#toc11">Indice</A>
<HR>
<H2><A NAME="s11">11. Il proxy server SOCKS</A></H2>
<P>
<H2><A NAME="ss11.1">11.1 Impostare il server proxy</A>
</H2>
<P>Il proxy server SOCKS è disponibile all'indirizzo <B>http://www.socks.nec.com/</B>.
<P>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.
<P>È importante notare che il proxy server deve essere aggiunto nel file
/etc/inetd.conf. È necessario quindi aggiungere la riga:
<P>
<PRE>
socks stream tcp nowait nobody /usr/local/etc/sockd sockd
</PRE>
<P>per segnalare al server di entrare in esecuzione quando richiesto.
<P>
<H2><A NAME="ss11.2">11.2 Configurare il Proxy Server</A>
</H2>
<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.
<P>
<H3>Il file di accesso</H3>
<P>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:
<P>
<UL>
<LI>L'identificatore (permit/deny)</LI>
<LI>L'indirizzo IP</LI>
<LI>Il modificatore di indirizzo</LI>
</UL>
<P>L'identificatore è di tipo permit oppure deny. È consigliabile avere
sia la riga permit, sia la riga deny.
<P>L'indirizzo IP è un indirizzo a 4 byte come nella tipica notazione
IP. Ossia, 192.168.1.0.
<P>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.
<P>Ad esempio, se la riga è:
<P>
<PRE>
permit 192.168.1.23 255.255.255.255
</PRE>
<P>saranno ammessi solo gli indirizzi IP i cui bit corrispondono a 192.168.1.23, ossia, solo 192.168.1.3. La riga:
<P>
<PRE>
permit 192.168.1.0 255.255.255.0
</PRE>
<P>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:
<PRE>
permit 192.168.1.0 0.0.0.0
</PRE>
<P>dal momento che ammetterà qualsiasi indirizzo, indistintamente.
<P>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:
<P>
<PRE>
permit 192.168.1.0 255.255.255.0
deny 0.0.0.0 0.0.0.0
</PRE>
<P>funzioneranno correttamente. Notare il primo "0.0.0.0" della riga
deny. Con un modificatore 0.0.0.0, il campo dell'indirizzo IP non è
rilevante. Tutti zero è la norma perché è semplice digitarli.
<P>È consentita più di una voce per ciascun tipo.
<P>È 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.
<P>
<H3>Il file di instradamento</H3>
<P>
Il file di instradamento in SOCKS è infelicemente chiamato
"socks.conf". L'"infelicemente" è dovuto al fatto che appare
molto simile a quello del file di accesso, pertanto potrebbe essere facile confonderli.
<P>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>
<P>
<UL>
<LI>deny</LI>
<LI>direct</LI>
<LI>sockd</LI>
</UL>
<P>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.
<P>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:
<P>
<PRE>
direct 192.168.1.0 255.255.255.0
</PRE>
<P>che permette di andare direttamente ovunque nella nostra rete
protetta.
<P>La voce sockd infine specifica al computer quale host ha in esecuzione il demone
server socks. La sintassi è:
<P>
<PRE>
sockd @=<serverlist> <IP address> <modifier>
</PRE>
<P>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.
<P>I campi di indirizzo IP e di modificatore funzionano esattamente come
negli altri esempi.
Attraverso questi è possibile specificare dove devono andare gli indirizzi.
<P>
<H3>DNS presente dietro il Firewall</H3>
<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.
<P>
<P>
<H2><A NAME="ss11.3">11.3 Lavorare con un Proxy Server</A>
</H2>
<P>
<H3>Unix</H3>
<P>
Per fare in modo che le proprie applicazioni funzionino con il proxy
server, dovranno essere "SOCKettizzate". 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. "Finger" diventerà "finger.orig", "telnet" diventerà
"telnet.orig" ecc. Bisognerà inoltre informare SOCKS di ognuno di questi
cambiamenti tramite il file include/socks.h.
<P>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.
<P>
<H3>MS Windows con Trumpet Winsock</H3>
<P>
Trumpet Winsock viene già distribuito con il supporto intrinseco per i
server proxy. Nel menu di "setup", 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.
<P>
<H3>Come far funzionare il Proxy Server con i pacchetti UDP</H3>
<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
<fitz@wang.com>. Sfortunatamente, nel momento in cui viene scritto
questo documento, non è compatibile con Linux.
<P>
<P>
<H2><A NAME="ss11.4">11.4 Svantaggi dei Proxy Server</A>
</H2>
<P>
Il proxy server è soprattutto un <CODE>dispositivo di sicurezza</CODE>. 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:
<P>
<UL>
<LI>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
<CODE>firewall</CODE>, ma dal momento che tutti hanno un accesso proxy
server, nessuno avrà impostato un account per voi.
<P>
</LI>
<LI>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>
</LI>
<LI>L'incapacità di utilizzare i pacchetti UDP rappresenta un grande
svantaggio dei proxy server. Immagino che il supporto UDP sarà
disponibile a breve.
</LI>
</UL>
<P>FTP provoca un altro problema con i proxy server. Quando si riceve o
si esegue un comando <CODE>ls</CODE>, 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.
<P>Inoltre, i proxy server sono lenti. A causa del sovraccarico maggiore,
quasi ogni altro mezzo per ottenere questo accesso sarà più veloce.
<P>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
<CODE><B>ftp://sunsite.unc.edu</B></CODE>, Slirp su
<CODE><B>ftp://blitzen.canberra.edu.au/pub/slirp</B></CODE>, e TIA su
<CODE><B>marketplace.com</B></CODE>. 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.
<P>
<P>
<HR>
<A HREF="Firewall-HOWTO-12.html">Avanti</A>
<A HREF="Firewall-HOWTO-10.html">Indietro</A>
<A HREF="Firewall-HOWTO.html#toc11">Indice</A>
</BODY>
</HTML>
