diff options
Diffstat (limited to 'it_IT.ISO8859-15/articles/filtering-bridges/article.xml')
| -rw-r--r-- | it_IT.ISO8859-15/articles/filtering-bridges/article.xml | 441 |
1 files changed, 441 insertions, 0 deletions
diff --git a/it_IT.ISO8859-15/articles/filtering-bridges/article.xml b/it_IT.ISO8859-15/articles/filtering-bridges/article.xml new file mode 100644 index 0000000000..c10f38c210 --- /dev/null +++ b/it_IT.ISO8859-15/articles/filtering-bridges/article.xml @@ -0,0 +1,441 @@ +<?xml version="1.0" encoding="iso-8859-15" standalone="no"?> +<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.2-Based Extension//EN" + "../../../share/sgml/freebsd42.dtd" [ +<!ENTITY % entities PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Entity Set//IT" "../../share/sgml/entities.ent"> +%entities; +]> + +<!-- + The FreeBSD Italian Documentation Project + + $FreeBSD$ + Original revision: 1.21 +--> + +<article lang="it"> + <articleinfo> + <title>Filtering Bridges</title> + + <authorgroup> + <author> + <firstname>Alex</firstname> + + <surname>Dupre</surname> + + <affiliation> + <address><email>ale@FreeBSD.org</email></address> + </affiliation> + </author> + </authorgroup> + + <legalnotice id="trademarks" role="trademarks"> + &tm-attrib.freebsd; + &tm-attrib.3com; + &tm-attrib.intel; + &tm-attrib.general; + </legalnotice> + + <pubdate>$FreeBSD$</pubdate> + + <releaseinfo>$FreeBSD$</releaseinfo> + + <abstract> + <para>Spesso è utile dividere una rete fisica (come una Ethernet) + in due segmenti separati, senza dover creare sottoreti e usare un router + per collegarli assieme. Il dispositivo che collega due reti insieme in + questo modo è chiamato bridge. Un sistema FreeBSD con due + interfacce di rete è sufficiente per raggiungere lo scopo.</para> + + <para>Un bridge funziona individuando gli indirizzi del livello + <acronym>MAC</acronym> (indirizzi Ethernet) dei dispositivi collegati ad + ognuna delle sue interfacce di rete e inoltrando il traffico tra le due + reti solo se il mittente e il destinatario si trovano su segmenti + differenti. Sotto molti punti di vista un brigde è simile a uno + switch Ethernet con solo due porte.</para> + </abstract> + </articleinfo> + + <sect1 id="filtering-bridges-why"> + <title>Perché usare un filtering bridge?</title> + + <para>Sempre più frequentemente, grazie all'abbassamento dei costi + delle connessioni a banda larga (xDSL) e a causa della riduzione del + numero di indirizzi IPv4 disponibili, molte società si ritrovano + collegate ad Internet 24 ore su 24 e con un numero esiguo (a volte nemmeno + una potenza di 2) di indirizzi IP. In situazioni come queste spesso + è desiderabile avere un firewall che regoli i permessi di ingresso + e uscita per il traffico da e verso Internet, ma una soluzione basata + sulle funzionalità di packet filtering dei router può non + essere applicabile, vuoi per problemi di suddivisione delle sottoreti, + vuoi perché il router è di proprietà del fornitore di + accesso (<acronym>ISP</acronym>), vuoi perché il router non + supporta tali funzionalità. È in questi casi che l'utilizzo + di un filtering bridge diventa altamente consigliato.</para> + + <para>Un firewall basato su bridge può essere configurato e inserito + direttamente tra il router xDSL e il vostro hub/switch Ethernet senza + alcun problema di assegnazione di indirizzi IP.</para> + + <note> + <para>La traduzione italiana di <quote>firewall</quote> è + <quote>muro anti incendio</quote>, <emphasis>non</emphasis> + <quote>muro di fuoco</quote> come molti pensano. Nel corso + dell'articolo, comunque, manterrò i termini tecnici nella loro + lingua originale in modo da non creare confusione o + ambiguità.</para> + </note> + </sect1> + + <sect1 id="filtering-bridges-how"> + <title>Metodi d'installazione</title> + + <para>Aggiungere le funzionalità di bridge a una macchina FreeBSD non + è difficile. Dalla release 4.5 è possibile caricare tali + funzionalità come moduli anziché dover ricompilare il + kernel, semplificando di gran lunga la procedura. Nelle prossime + sottosezioni spiegherò entrambi i metodi di installazione.</para> + + <important> + <para><emphasis>Non</emphasis> seguite entrambe le istruzioni: le + procedure sono <emphasis>a esclusione</emphasis>. Scegliete + l'alternativa che meglio si adatta alle vostre esigenze e + capacità.</para> + </important> + + <para>Prima di continuare è necessario assicurarsi di avere almeno + due schede di rete Ethernet che supportino la modalità promiscua + sia in ricezione che in trasmissione, difatti devono essere in grado di + inviare pacchetti Ethernet con qualunque indirizzo, non solo il loro. + Inoltre, per avere un buon rendimento, le schede dovrebbero essere di + tipo PCI bus mastering. Le scelte migliori sono ancora le Intel + ðerexpress; Pro seguite dalle &tm.3com; 3c9xx subito dopo. Per + comodità nella configurazione del firewall può essere + utile avere due schede di marche differenti (che usino drivers + differenti) in modo da distinguere chiaramente quale interfaccia sia + collegata al router e quale alla rete interna.</para> + + <sect2 id="filtering-bridges-kernel"> + <title>Configurazione del Kernel</title> + + <para>Così avete deciso di utilizzare il più vecchio e + collaudato metodo di installazione. Per prima cosa bisogna + aggiungere le seguenti righe al file di configurazione del + kernel:</para> + + <programlisting>options BRIDGE +options IPFIREWALL +options IPFIREWALL_VERBOSE</programlisting> + + <para>La prima riga serve a compilare il supporto per il bridge, la + seconda il firewall e la terza le funzioni di logging del firewall. + </para> + + <para>Adesso è necessario compilare e installare il nuovo kernel. + Si possono trovare le istruzioni nella sezione <ulink + url="&url.books.handbook;/kernelconfig-building.html"> + Building and Installing a Custom Kernel</ulink> dell'handbook.</para> + </sect2> + + <sect2 id="filtering-bridges-modules"> + <title>Caricamento dei Moduli</title> + + <para>Se avete deciso di usare il nuovo e più semplice metodo di + installazione, l'unica cosa da fare è aggiungere la seguente riga + al file <filename>/boot/loader.conf</filename>:</para> + + <programlisting>bridge_load="YES"</programlisting> + + <para>In questo modo all'avvio della macchina verrà caricato + insieme al kernel anche il modulo <filename>bridge.ko</filename>. Non + è necessario invece aggiungere una riga per il modulo + <filename>ipfw.ko</filename> in quanto verrà caricato in + automatico dallo script <filename>/etc/rc.network</filename> dopo aver + seguito i passi della prossima sezione.</para> + </sect2> + </sect1> + + <sect1 id="filtering-bridges-finalprep"> + <title>Preparativi finali</title> + + <para>Prima di riavviare per caricare il nuovo kernel o i moduli richiesti + (a seconda del metodo che avete scelto in precedenza), bisogna effettuare + alcune modifiche al file <filename>/etc/rc.conf</filename>. La regola di + default del firewall è di rifiutare tutti i pacchetti IP. Per + iniziare attiviamo il firewall in modalità <option>open</option>, + in modo da verificare il suo funzionamento senza alcun problema di + filtraggio pacchetti (nel caso stiate eseguendo questa procedura da + remoto, tale accorgimento vi consentirà di non rimanere + erroneamente tagliati fuori dalla rete). + Inserite queste linee nel file <filename>/etc/rc.conf</filename>:</para> + + <programlisting>firewall_enable="YES" +firewall_type="open" +firewall_quiet="YES" +firewall_logging="YES"</programlisting> + + <para>La prima riga serve ad attivare il firewall (e a caricare il modulo + <filename>ipfw.ko</filename> nel caso non fosse già compilato nel + kernel), la seconda a impostarlo in modalità + <option>open</option> (come descritto nel file + <filename>/etc/rc.firewall</filename>), la terza a non + visualizzare il caricamento delle regole e la quarta ad abilitare il + supporto per il logging.</para> + + <para>Per quanto riguarda la configurazione delle interfacce di rete, il + metodo più utilizzato è quello di assegnare un IP a solo una + delle schede di rete, ma il bridge funziona egualmente anche se entrambe o + nessuna delle interfacce ha IP settati. In quest'ultimo caso (IP-less) la + macchina bridge sarà ancora più nascosta in quanto + inaccessibile dalla rete: per configurarla occorrerà quindi entrare + da console o tramite una terza interfaccia di rete separata dal bridge. A + volte all'avvio della macchina qualche programma richiede di accedere alla + rete, per esempio per una risoluzione di dominio: in questo caso è + necessario assegnare un IP all'interfaccia esterna (quella collegata a + Internet, dove risiede il server <acronym>DNS</acronym>), visto che il + bridge verrà attivato alla fine della procedura di avvio. Questo + vuol dire che l'interfaccia <devicename>fxp0</devicename> (nel nostro + caso) deve essere menzionata nella sezione ifconfig del file + <filename>/etc/rc.conf</filename>, mentre la <devicename>xl0</devicename> + no. Assegnare IP a entrambe le schede di rete non ha molto senso, a meno + che durante la procedura di avvio non si debba accedere a servizi presenti + su entrambi i segmenti Ethernet.</para> + + <para>C'è un'altra cosa importante da sapere. Quando si utilizza IP + sopra Ethernet ci sono due protocolli Ethernet in uso: uno è IP, + l'altro è <acronym>ARP</acronym>. <acronym>ARP</acronym> permette + la conversione dell'indirizzo IP di una macchina nel suo indirizzo + Ethernet (livello <acronym>MAC</acronym>). Affinché due macchine + separate dal bridge riescano a comunicare tra loro è necessario che + il bridge lasci passare i pacchetti <acronym>ARP</acronym>. Tale + protocollo non fa parte del livello IP, visto che è presente solo + con IP sopra Ethernet. Il firewall di FreeBSD agisce esclusivamente sul + livello IP e quindi tutti i pacchetti non IP (compreso + <acronym>ARP</acronym>) verranno inoltrati senza essere filtrati, anche se + il firewall è configurato per non lasciar passare nulla.</para> + + <para>Ora è arrivato il momento di riavviare la macchina e usarla + come in precedenza: appariranno dei nuovi messaggi riguardo al bridge e al + firewall, ma il bridge non sarà attivato e il firewall, essendo in + modalità <option>open</option>, non impedirà nessuna + operazione.</para> + + <para>Se ci dovessero essere dei problemi, è il caso di scoprire ora + da cosa derivino e risolverli prima di continuare.</para> + </sect1> + + <sect1 id="filtering-bridges-enabling"> + <title>Attivazione del Bridge</title> + + <para>A questo punto, per attivare il bridge, bisogna eseguire i seguenti + comandi (avendo l'accortezza di sostituire i nomi delle due interfacce di + rete <devicename>fxp0</devicename> e <devicename>xl0</devicename> con i + propri):</para> + + <screen>&prompt.root; <userinput>sysctl net.link.ether.bridge.config=fxp0:0,xl0:0</userinput> +&prompt.root; <userinput>sysctl net.link.ether.bridge.ipfw=1</userinput> +&prompt.root; <userinput>sysctl net.link.ether.bridge.enable=1</userinput></screen> + + <para>La prima riga specifica tra quali interfacce va attivato il bridge, + la seconda abilita il firewall sul bridge ed infine la terza attiva il + bridge.</para> + + <note> + <para>Se hai &os; 5.1-RELEASE o precedenti le variabili sysctl + sono chiamate in modo differente. Guarda &man.bridge.4; per i + dettagli.</para> + </note> + + <para>A questo punto dovrebbe essere possibile inserire la macchina tra + due gruppi di host senza che venga compromessa qualsiasi + possibilità di comunicazione tra di loro. Se è così, + il prossimo passo è quello di aggiungere le parti + <literal>net.link.ether.bridge.<replaceable>[blah]</replaceable>=<replaceable>[blah]</replaceable></literal> + di queste righe al file <filename>/etc/sysctl.conf</filename>, in modo che + vengano eseguite all'avvio della macchina.</para> + </sect1> + + <sect1 id="filtering-bridges-ipfirewall"> + <title>Configurazione del Firewall</title> + + <para>Ora è arrivato il momento di creare il proprio file con le + regole per il firewall, in modo da rendere sicura la rete interna. + Ci sono delle complicazioni nel fare questo, perché non tutte le + funzionalità del firewall sono disponibili sui pacchetti inoltrati + dal bridge. Inoltre, c'è una differenza tra i pacchetti che stanno + per essere inoltrati dal bridge e quelli indirizzati alla macchina locale. + In generale, i pacchetti che entrano nel bridge vengono processati dal + firewall solo una volta, non due come al solito; infatti vengono filtrati + solo in ingresso, quindi qualsiasi regola che usi <option>out</option> + oppure <option>xmit</option> non verrà mai eseguita. Personalmente + uso <option>in via</option> che è una sintassi più antica, + ma che ha un senso quando la si legge. + Un'altra limitazione è che si possono usare solo i comandi + <option>pass</option> e <option>drop</option> per i pacchetti filtrati + dal bridge. Cose avanzate come <option>divert</option>, + <option>forward</option> o <option>reject</option> non sono disponibili. + Queste opzioni possono ancora essere usate, ma solo per il traffico da + e verso la macchina bridge stessa (sempre che le sia stato assegnato + un IP).</para> + + <para>Nuovo in FreeBSD 4.0 è il concetto di stateful filtering. + Questo è un grande miglioramento per il traffico + <acronym>UDP</acronym>, che consiste tipicamente di una richiesta in + uscita, seguita a breve termine da una risposta con la stessa coppia di + indirizzi IP e numeri di porta (ma con mittente e destinatario invertiti, + ovviamente). Per i firewall che non supportano il mantenimento di stato, + non c'è modo di gestire questo breve scambio di dati come una + sessione unica. Ma con un firewall che può + <quote>ricordarsi</quote> di un pacchetto <acronym>UDP</acronym> in + uscita e permette una risposta nei minuti successivi, gestire i + servizi <acronym>UDP</acronym> è semplice. + L'esempio seguente mostra come fare. La stessa cosa è + possibile farla con i pacchetti <acronym>TCP</acronym>. Questo + permette di evitare qualche tipo di attacco denial of service e altri + sporchi trucchi, ma tipicamente fa anche crescere velocemente la + tabella di stato.</para> + + <para>Vediamo un esempio di configurazione. Bisogna notare che all'inizio + del file <filename>/etc/rc.firewall</filename> ci sono già delle + regole standard per l'interfaccia di loopback + <devicename>lo0</devicename>, quindi non ce ne occuperemo più ora. + Le regole personalizzate andrebbero messe in un file a parte (per esempio + <filename>/etc/rc.firewall.local</filename>) e caricate all'avvio + modificando la riga del file <filename>/etc/rc.conf</filename> dove era + stata definita la modalità <option>open</option> con:</para> + + <programlisting>firewall_type="/etc/rc.firewall.local"</programlisting> + + <important> + <para>Bisogna specificare il path <emphasis>completo</emphasis> + del file, altrimenti non verrà caricato con il rischio di + rimanere tagliati fuori dalla rete.</para> + </important> + + <para>Per il nostro esempio immaginiamo di avere l'interfaccia + <devicename>fxp0</devicename> collegata all'esterno (Internet) e la + <devicename>xl0</devicename> verso l'interno (<acronym>LAN</acronym>). + La macchina bridge ha assegnato l'IP + <hostid role="ipaddr">1.2.3.4</hostid> + (è impossibile che il vostro <acronym>ISP</acronym> vi assegni un + indirizzo simile a questo, ma per l'esempio va bene).</para> + + <programlisting># Le connessioni di cui abbiamo mantenuto lo stato vengono fatte passare subito +add check-state + +# Esclude le reti locali definite nell'RFC 1918 +add drop all from 10.0.0.0/8 to any in via fxp0 +add drop all from 172.16.0.0/12 to any in via fxp0 +add drop all from 192.168.0.0/16 to any in via fxp0 + +# Permette alla macchina bridge di connettersi con chi vuole +# (se la macchina è IP-less non includere questi comandi) +add pass tcp from 1.2.3.4 to any setup keep-state +add pass udp from 1.2.3.4 to any keep-state +add pass ip from 1.2.3.4 to any + +# Permette agli host della rete interna di connettersi con chi vogliono +add pass tcp from any to any in via xl0 setup keep-state +add pass udp from any to any in via xl0 keep-state +add pass ip from any to any in via xl0 + +# Sezione TCP +# Permette SSH +add pass tcp from any to any 22 in via fxp0 setup keep-state +# Permette SMTP solo verso il mail server +add pass tcp from any to relay 25 in via fxp0 setup keep-state +# Permette i trasferimenti di zona solo dal name server secondario [dns2.nic.it] +add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state +# Lascia passare i controlli ident: +# è meglio che aspettare che vadano in timeout +add pass tcp from any to any 113 in via fxp0 setup keep-state +# Permette connessioni nel range di "quarantena". +add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state + +# Sezione UDP +# Permette DNS solo verso il name server +add pass udp from any to ns 53 in via fxp0 keep-state +# Permette connessioni nel range di "quarantena". +add pass udp from any to any 49152-65535 in via fxp0 keep-state + +# Sezione ICMP +# Abilita le funzioni di 'ping' +add pass icmp from any to any icmptypes 8 keep-state +# Permette il passaggio dei messaggi di errori del comando 'traceroute' +add pass icmp from any to any icmptypes 3 +add pass icmp from any to any icmptypes 11 + +# Tutto il resto è sospetto +add drop log all from any to any</programlisting> + + <para>Coloro che hanno configurato un firewall in precedenza potrebbero aver + notato che manca qualcosa. In particolare, non ci sono regole contro lo + spoofing, difatti <emphasis>non</emphasis> abbiamo aggiunto:</para> + + <programlisting>add deny all from 1.2.3.4/8 to any in via fxp0</programlisting> + + <para>Ovvero, non far entrare dall'esterno pacchetti che affermano di venire + dalla rete interna. Questa è una cosa che solitamente viene fatta + per essere sicuri che qualcuno non provi a eludere il packet filter, + generando falsi pacchetti che sembrano venire dall'interno. Il problema + è che c'è <emphasis>almeno</emphasis> un host + sull'interfaccia esterna che non si può ignorare: il router. + Solitamente, però, gli <acronym>ISP</acronym> eseguono il controllo + anti-spoof sui loro router e quindi non ce ne dobbiamo preoccupare.</para> + + <para>L'ultima riga sembra un duplicato della regola di default, ovvero non + far passare nulla che non sia stato specificatamente permesso. In + verità c'è una differenza: tutto il traffico sospetto + verrà loggato.</para> + + <para>Ci sono due regole per permettere il traffico <acronym>SMTP</acronym> + e <acronym>DNS</acronym> verso il mail server e il name server, se ne + avete. Ovviamente l'intero set di regole deve essere personalizzato + per le proprie esigenze, questo non è altro che uno specifico + esempio (il formato delle regole è spiegato dettagliatamente nella + man page &man.ipfw.8;). Bisogna notare che, affinché + <quote>relay</quote> e <quote>ns</quote> + siano interpretati correttamente, la risoluzione dei nomi deve funzionare + <emphasis>prima</emphasis> che il bridge sia attivato. Questo è un + chiaro esempio che dimostra l'importanza di settare l'IP sulla corretta + scheda di rete. In alternativa è possibile specificare + direttamente l'indirizzo IP anziché il nome host (cosa necessaria + se la macchina è IP-less).</para> + + <para>Le persone che sono solite configurare un firewall probabilmente + avranno sempre usato una regola <option>reset</option> o + <option>forward</option> per i pacchetti + ident (porta 113 <acronym>TCP</acronym>). Sfortunatamente, questa non + è una scelta applicabile con il bridge, quindi la cosa migliore + è lasciarli passare fino alla destinazione. Finché la + macchina di destinazione non ha un demone ident attivo, questa tecnica + è relativamente sicura. L'alternativa è proibire le + connessioni sulla porta 113, creando qualche problema con servizi tipo + <acronym>IRC</acronym> (le richieste ident devono andare in + timeout).</para> + + <para>L'unica altra cosa un po' particolare che potete aver notato è + che c'è una regola per lasciar comunicare la macchina bridge e + un'altra per gli host della rete interna. Ricordate che questo è + dovuto al fatto che i due tipi di traffico prendono percorsi differenti + attraverso il kernel e di conseguenza anche dentro il packet filter. La + rete interna passerà attraverso il bridge, mentre la macchina + locale userà il normale stack IP per le connessioni. Perciò + due regole per gestire due casi differenti. Le regole <literal>in via + <devicename>fxp0</devicename></literal> funzionano in entrambi i casi. + In generale, se usate regole <option>in via</option> attraverso il + packet filter, dovrete fare un'eccezione per i pacchetti generati + localmente, in quanto non entrano tramite nessuna interfaccia.</para> + </sect1> + + <sect1 id="filtering-bridges-contributors"> + <title>Contributi</title> + + <para>Alcune parti di questo articolo sono state prese, tradotte e + adattate da testi sui bridge, appartenenti alla documentazione di FreeBSD + in lingua inglese, a cura di Nick Sayer e Steve Peterson.</para> + + <para>Un grosso ringraziamento va a Luigi Rizzo per l'implementazione + delle funzionalità di bridging in FreeBSD e per il tempo che mi ha + dedicato rispondendo ad alcune mie domande a riguardo.</para> + </sect1> +</article> |