Firewalling and Proxy Server HOWTO Mark Grennan, markg@netplus.net v0.4, 8 Novembre 1996 Questo documento si propone di insegnare le basi dei sistemi firewall e di fornire alcuni dettagli sull'impostazione del filtering e del proxy firewall su un PC basato su Linux. All'indirizzo http://okcfo­ rum.org/~markg/Firewall-HOWTO.html è disponibile una versione HTML di questo documento. 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 . 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 . 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 ", dove è 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 #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 @= 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 . 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 a conquistare il mondo! 10. Nota sulla traduzione La traduzione originale di questo HOWTO è opera della Apogeo , per il libro 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. Conversione in SGML e correzione a cura di Giovanni Bortolozzo bortopluto.linux.it, cui vanno segnalati pure eventuali errori, incongruenze ecc.