FreeBSD Bugzilla – Attachment 22831 Details for
Bug 39510
[Update article] Filtering bridges (Italian version)
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Help
|
New Account
|
Log In
Remember
[x]
|
Forgot Password
Login:
[x]
[patch]
article_it.diff
article_it.diff (text/plain), 23.87 KB, created by
Alex Dupre
on 2002-06-19 13:30:11 UTC
(
hide
)
Description:
article_it.diff
Filename:
MIME Type:
Creator:
Alex Dupre
Created:
2002-06-19 13:30:11 UTC
Size:
23.87 KB
patch
obsolete
>--- it_IT.ISO8859-15/articles/filtering-bridges/article.sgml.orig Wed Jun 19 11:43:37 2002 >+++ it_IT.ISO8859-15/articles/filtering-bridges/article.sgml Wed Jun 19 14:34:10 2002 >@@ -24,15 +24,15 @@ > <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 >+ 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 >+ differenti. Sotto molti punti di vista un brigde è simile a uno > switch Ethernet con solo due porte.</para> > </abstract> > </articleinfo> >@@ -44,14 +44,14 @@ > 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 >+ 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 >+ 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 >@@ -60,7 +60,7 @@ > > <note> > <para>La traduzione italiana di "firewall" è "muro anti incendio", >- <emphasis>non</emphasis> "muro di fuoco" come molti pensano. Nel corso >+ <emphasis>non</emphasis> "muro di fuoco" 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> >@@ -71,14 +71,14 @@ > <title>Metodi d'installazione</title> > > <para>Aggiungere le funzionalità di bridge a una macchina FreeBSD non >- è difficile. Dalla release 4.5 è possibile caricare tali >+ è difficile. Dalla release 4.5 è possibile caricare tali > funzionalità come moduli anziché dover ricompilare il >- kernel, semplificando di gran lunga la procedura. Nelle prossime >+ 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 >+ procedure sono <emphasis>a esclusione</emphasis>. Scegliete > l'alternativa che meglio si adatta alle vostre esigenze e > capacità.</para> > </important> >@@ -88,27 +88,27 @@ > 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 >- EtherExpress Pro seguite dalle 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> >+ tipo PCI bus mastering. Le scelte migliori sono ancora le Intel >+ EtherExpress Pro seguite dalle 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> >+ 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> >+ 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 >@@ -126,7 +126,7 @@ > <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 >+ 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 >@@ -139,13 +139,14 @@ > > <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à 'open', 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> >+ 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" >@@ -154,39 +155,39 @@ > > <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à 'open' (come descritto >- nel file <filename>/etc/rc.firewall</filename>), la terza a non >- visualizzare il caricamento delle regole e la quarta ad abilitare il >+ 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 >+ 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 >+ 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 >+ 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 >+ 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 >+ <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 >+ 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 >+ 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 >+ 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 >+ 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> >@@ -194,7 +195,8 @@ > <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à 'open', non impedirà nessuna operazione.</para> >+ 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> >@@ -218,7 +220,7 @@ > > <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ì, >+ possibilità di comunicazione tra di loro. Se è così, > il prossimo passo è quello di aggiungere le parti > <literal>net.link.ether.<replaceable>[blah]</replaceable>=<replaceable>[blah]</replaceable></literal> > di queste righe al file <filename>/etc/sysctl.conf</filename>, in modo che >@@ -229,45 +231,48 @@ > <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 >+ 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 >+ 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 'out' oppure 'xmit' non >- verrà mai eseguita. Personalmente uso 'in via' che è una >- sintassi più antica, ma che ha un senso quando la si legge. >- Un'altra limitazione è che si possono usare solo i comandi 'pass' e >- 'drop' per i pacchetti filtrati dal bridge. Cose avanzate come 'divert', >- 'forward' o 'reject' 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> >+ 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, >+ 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ò "ricordarsi" 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> >+ 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 >+ <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à 'open' con:</para> >+ stata definita la modalità <option>open</option> con:</para> > > <programlisting>firewall_type="/etc/rc.firewall.local"</programlisting> > >@@ -279,7 +284,7 @@ > > <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 >+ <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 di classe A di questo tipo, ma per l'esempio va bene).</para> >@@ -332,61 +337,62 @@ > 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 >+ 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 >+ 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 >+ 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 >+ 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 >+ 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é 'relay' e 'ns' >- 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> >+ 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 'reset' o 'forward' 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> >+ 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 è >+ 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 >+ 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 'in via >- <devicename>fxp0</devicename>' funzionano in entrambi i casi. In generale, >- se usate regole 'in via' attraverso il packet filter, dovrete fare >- un'eccezione per i pacchetti generati localmente, in quanto non entrano >- tramite nessuna interfaccia.</para> >+ 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">
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 39510
: 22831