Il proxy server SOCKS è disponibile all'indirizzo http://www.socks.nec.com/.
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:
socks stream tcp nowait nobody /usr/local/etc/sockd sockd
per segnalare al server di entrare in esecuzione quando richiesto.
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.
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 è 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 è:
permit 192.168.1.23 255.255.255.255
saranno ammessi solo gli indirizzi IP i cui bit corrispondono a 192.168.1.23, ossia, solo 192.168.1.3. La riga:
permit 192.168.1.0 255.255.255.0
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:
permit 192.168.1.0 0.0.0.0
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:
permit 192.168.1.0 255.255.255.0
deny 0.0.0.0 0.0.0.0
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.
È 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.
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.
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:
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:
direct 192.168.1.0 255.255.255.0
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 è:
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. Attraverso questi è possibile specificare dove devono andare gli indirizzi.
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.
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.
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.
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.
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.
Il proxy server è soprattutto un dispositivo di sicurezza. 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:
firewall, ma dal momento che tutti hanno un accesso proxy
server, nessuno avrà impostato un account per voi.
FTP provoca un altro problema con i proxy server. Quando si riceve o
si esegue un comando ls, 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
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 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.