aboutsummaryrefslogtreecommitdiff
path: root/it_IT.ISO8859-15/articles
diff options
context:
space:
mode:
Diffstat (limited to 'it_IT.ISO8859-15/articles')
-rw-r--r--it_IT.ISO8859-15/articles/filtering-bridges/article.sgml440
1 files changed, 226 insertions, 214 deletions
diff --git a/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml b/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml
index f2f946136f..95934191f6 100644
--- a/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml
+++ b/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml
@@ -13,7 +13,6 @@
<author>
<firstname>Alex</firstname>
<surname>Dupre</surname>
-
<affiliation>
<address><email>sysadmin@alexdupre.com</email></address>
</affiliation>
@@ -24,17 +23,17 @@
<abstract>
<para>Spesso &egrave; 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 &egrave; chiamato bridge. Un sistema FreeBSD con due
- interfacce di rete &egrave; sufficiente per raggiungere lo scopo.</para>
-
- <para>Un bridge funziona individuando gli indirizzi del livello MAC
- (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 &egrave; simile a uno switch Ethernet con
- solo due porte.</para>
+ 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 &egrave; chiamato bridge. Un sistema FreeBSD con due
+ interfacce di rete &egrave; 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 &egrave; simile a uno
+ switch Ethernet con solo due porte.</para>
</abstract>
</articleinfo>
@@ -42,29 +41,29 @@
<title>Perch&egrave; usare un filtering bridge?</title>
<para>Sempre pi&ugrave; 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&agrave; 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 &egrave;
- 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&agrave; di packet filtering dei router pu&ograve; non essere
- applicabile, vuoi per problemi di suddivisione delle sottoreti, vuoi
- perch&egrave; il router &egrave; di propriet&agrave; del fornitore di
- accesso (ISP), vuoi perch&egrave; il router non supporta tali
- funzionalit&agrave;. E' in questi casi che l'utilizzo di un filtering bridge
- diventa altamente consigliato.</para>
+ delle connessioni a banda larga (xDSL) e a causa della riduzione del
+ numero di indirizzi IPv4 disponibili, molte societ&agrave; 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
+ &egrave; 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&agrave; di packet filtering dei router pu&ograve; non
+ essere applicabile, vuoi per problemi di suddivisione delle sottoreti,
+ vuoi perch&egrave; il router &egrave; di propriet&agrave; del fornitore di
+ accesso (<acronym>ISP</acronym>), vuoi perch&egrave; il router non
+ supporta tali funzionalit&agrave;. &Egrave; in questi casi che l'utilizzo
+ di un filtering bridge diventa altamente consigliato.</para>
<para>Un firewall basato su bridge pu&ograve; essere configurato e inserito
- direttamente tra il router xDSL e il vostro hub/switch Ethernet senza alcun
- problema di assegnazione di indirizzi IP.</para>
+ 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 "firewall" &egrave; "muro anti incendio",
- <emphasis>non</emphasis> "muro di fuoco" come molti pensano. Nel corso
- dell'articolo, comunque, manterr&ograve; i termini tecnici nella loro
- lingua originale in modo da non creare confusione o
- ambiguit&agrave;.</para>
+ <emphasis>non</emphasis> "muro di fuoco" come molti pensano. Nel corso
+ dell'articolo, comunque, manterr&ograve; i termini tecnici nella loro
+ lingua originale in modo da non creare confusione o
+ ambiguit&agrave;.</para>
</note>
</sect1>
@@ -72,63 +71,66 @@
<title>Metodi d'installazione</title>
<para>Aggiungere le funzionalit&agrave; di bridge a una macchina FreeBSD non
- &egrave; difficile. Dalla release 4.5 &egrave; possibile caricare tali
- funzionalit&agrave; come moduli anzich&egrave; dover ricompilare il kernel,
- semplificando di gran lunga la procedura. Nelle prossime sottosezioni
- spiegher&ograve; entrambi i metodi di installazione.</para>
+ &egrave; difficile. Dalla release 4.5 &egrave; possibile caricare tali
+ funzionalit&agrave; come moduli anzich&egrave; dover ricompilare il
+ kernel, semplificando di gran lunga la procedura. Nelle prossime
+ sottosezioni spiegher&ograve; 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&agrave;.</para>
+ procedure sono <emphasis>a esclusione</emphasis>. Scegliete
+ l'alternativa che meglio si adatta alle vostre esigenze e
+ capacit&agrave;.</para>
</important>
<para>Prima di continuare &egrave; necessario assicurarsi di avere almeno
- due schede di rete Ethernet che supportino la modalit&agrave; 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 EtherExpress Pro seguite
- dalle 3Com 3c9xx subito dopo. Per comodit&agrave; nella configurazione del
- firewall pu&ograve; 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>
+ due schede di rete Ethernet che supportino la modalit&agrave; 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
+ EtherExpress Pro seguite dalle 3Com 3c9xx subito dopo. Per comodit&agrave;
+ nella configurazione del firewall pu&ograve; 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&igrave; avete deciso di utilizzare il piu' vecchio e collaudato
- metodo di installazione. Per prima cosa bisogna aggiungere le seguenti
- righe al file di configurazione del kernel:</para>
+ <para>Cos&igrave; avete deciso di utilizzare il pi&ugrave; vecchio e
+ collaudato metodo di installazione. Per prima cosa bisogna aggiungere le
+ seguenti righe al file di configurazione del kernel:</para>
-<programlisting>options BRIDGE
+ <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 &egrave; necessario compilare e installare il nuovo kernel.
- Si possono trovare le istruzioni nella sezione <ulink
- url="../../../en_US.ISO8859-1/books/handbook/kernelconfig-building.html">
- Building and Installing a Custom Kernel</ulink> dell'handbook.</para>
+ Si possono trovare le istruzioni nella sezione <ulink
+ url="../../../en_US.ISO8859-1/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&ugrave; semplice metodo di
- installazione, l'unica cosa da fare &egrave; aggiungere la seguente riga
- al file <filename>/boot/loader.conf</filename>:</para>
+ installazione, l'unica cosa da fare &egrave; 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&agrave; caricato
- insieme al kernel anche il modulo <filename>bridge.ko</filename>. Non
- &egrave; necessario invece aggiungere una riga per il modulo
- <filename>ipfw.ko</filename> in quanto verr&agrave; caricato in automatico
- dallo script <filename>/etc/rc.network</filename> dopo aver seguito i
- passi della prossima sezione.</para>
+ insieme al kernel anche il modulo <filename>bridge.ko</filename>. Non
+ &egrave; necessario invece aggiungere una riga per il modulo
+ <filename>ipfw.ko</filename> in quanto verr&agrave; caricato in
+ automatico dallo script <filename>/etc/rc.network</filename> dopo aver
+ seguito i passi della prossima sezione.</para>
</sect2>
</sect1>
@@ -136,145 +138,153 @@ options IPFIREWALL_VERBOSE</programlisting>
<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 &egrave; di rifiutare tutti i pacchetti IP. Per
- iniziare attiviamo il firewall in modalit&agrave; '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&agrave; di non rimanere erroneamente tagliati fuori dalla rete).
- Inserite queste linee nel file <filename>/etc/rc.conf</filename>:</para>
-
-<programlisting>firewall_enable="YES"
+ (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 &egrave; di rifiutare tutti i pacchetti IP. Per
+ iniziare attiviamo il firewall in modalit&agrave; '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&agrave; 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&agrave; compilato nel
- kernel), la seconda a impostarlo in modalit&agrave; '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 supporto per il
- logging.</para>
+ <filename>ipfw.ko</filename> nel caso non fosse gi&agrave; compilato nel
+ kernel), la seconda a impostarlo in modalit&agrave; '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
+ supporto per il logging.</para>
<para>Per quanto riguarda la configurazione delle interfacce di rete, il
- metodo pi&ugrave; utilizzato &egrave; 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&agrave; ancora pi&ugrave; nascosta in quanto
- inaccessibile dalla rete: per configurarla occorrer&agrave; 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 &egrave;
- necessario assegnare un IP all'interfaccia esterna (quella collegata a
- Internet, dove risiede il server DNS), visto che il bridge verr&agrave;
- attivato alla fine della procedura di avvio. Questo vuol dire che
- l'interfaccia fxp0 (nel nostro caso) deve essere menzionata nella sezione
- ifconfig del file <filename>/etc/rc.conf</filename>, mentre la xl0 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>
+ metodo pi&ugrave; utilizzato &egrave; 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&agrave; ancora pi&ugrave; nascosta in quanto
+ inaccessibile dalla rete: per configurarla occorrer&agrave; 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 &egrave;
+ necessario assegnare un IP all'interfaccia esterna (quella collegata a
+ Internet, dove risiede il server <acronym>DNS</acronym>), visto che il
+ bridge verr&agrave; 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'&egrave; un'altra cosa importante da sapere. Quando si utilizza IP
- sopra Ethernet ci sono due protocolli Ethernet in uso: uno &egrave; IP,
- l'altro &egrave; ARP. ARP permette la conversione dell'indirizzo IP di una
- macchina nel suo indirizzo Ethernet (livello MAC). Affinch&egrave; due
- macchine separate dal bridge riescano a comunicare tra loro &egrave;
- necessario che il bridge lasci passare i pacchetti ARP. Tale protocollo non
- fa parte del livello IP, visto che &egrave; presente solo con IP sopra
- Ethernet. Il firewall di FreeBSD agisce esclusivamente sul livello IP e
- quindi tutti i pacchetti non IP (compreso ARP) verranno inoltrati senza
- essere filtrati, anche se il firewall &egrave; configurato per non lasciar
- passare nulla.</para>
+ sopra Ethernet ci sono due protocolli Ethernet in uso: uno &egrave; IP,
+ l'altro &egrave; <acronym>ARP</acronym>. <acronym>ARP</acronym> permette
+ la conversione dell'indirizzo IP di una macchina nel suo indirizzo
+ Ethernet (livello <acronym>MAC</acronym>). Affinch&egrave; due macchine
+ separate dal bridge riescano a comunicare tra loro &egrave; necessario che
+ il bridge lasci passare i pacchetti <acronym>ARP</acronym>. Tale
+ protocollo non fa parte del livello IP, visto che &egrave; 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 &egrave; configurato per non lasciar passare nulla.</para>
<para>Ora &egrave; 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&agrave; attivato e il firewall, essendo in
- modalit&agrave; 'open', non impedir&agrave; nessuna operazione.</para>
+ come in precedenza: appariranno dei nuovi messaggi riguardo al bridge e al
+ firewall, ma il bridge non sar&agrave; attivato e il firewall, essendo in
+ modalit&agrave; 'open', non impedir&agrave; nessuna operazione.</para>
<para>Se ci dovessero essere dei problemi, &egrave; il caso di scoprire ora
- da cosa derivino e risolverli prima di continuare.</para>
+ 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 fxp0 e xl0 con i propri):</para>
+ 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_cfg=fxp0:0,xl0:0</userinput>
+ <screen>&prompt.root; <userinput>sysctl net.link.ether.bridge_cfg=fxp0:0,xl0:0</userinput>
&prompt.root; <userinput>sysctl net.link.ether.bridge_ipfw=1</userinput>
&prompt.root; <userinput>sysctl net.link.ether.bridge=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>
+ la seconda abilita il firewall sul bridge ed infine la terza attiva il
+ bridge.</para>
<para>A questo punto dovrebbe essere possibile inserire la macchina tra
- due gruppi di host senza che venga compromessa qualsiasi possibilit&agrave;
- di comunicazione tra di loro. Se &egrave; cos&igrave;, il prossimo passo
- &egrave; quello di aggiungere le parti net.link.ether.[blah]=[blah] di
- queste righe al file <filename>/etc/sysctl.conf</filename>, in modo che
- vengano eseguite all'avvio della macchina.</para>
+ due gruppi di host senza che venga compromessa qualsiasi
+ possibilit&agrave; di comunicazione tra di loro. Se &egrave; cos&igrave;,
+ il prossimo passo &egrave; 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
+ vengano eseguite all'avvio della macchina.</para>
</sect1>
<sect1 id="filtering-bridges-ipfirewall">
<title>Configurazione del Firewall</title>
<para>Ora &egrave; 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&egrave; non tutte le
- funzionalit&agrave; del firewall sono disponibili sui pacchetti inoltrati
- dal bridge. Inoltre, c'&egrave; 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&agrave; mai eseguita. Personalmente uso 'in via' che &egrave; una
- sintassi pi&ugrave; antica, ma che ha un senso quando la si legge. Un'altra
- limitazione &egrave; 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>
+ regole per il firewall, in modo da rendere sicura la rete interna. Ci sono
+ delle complicazioni nel fare questo, perch&egrave; non tutte le
+ funzionalit&agrave; del firewall sono disponibili sui pacchetti inoltrati
+ dal bridge. Inoltre, c'&egrave; 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&agrave; mai eseguita. Personalmente uso 'in via' che &egrave; una
+ sintassi pi&ugrave; antica, ma che ha un senso quando la si legge.
+ Un'altra limitazione &egrave; 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>
<para>Nuovo in FreeBSD 4.0 &egrave; il concetto di stateful filtering.
- Questo &egrave; un grande miglioramento per il traffico UDP, 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'&egrave; modo di gestire questo
- breve scambio di dati come una sessione unica. Ma con un firewall che
- pu&ograve; "ricordarsi" di un pacchetto UDP in uscita e permette una
- risposta nei minuti successivi, gestire i servizi UDP &egrave; semplice.
- L'esempio seguente mostra come fare. La stessa cosa &egrave; possibile farla
- con i pacchetti TCP. 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>
+ Questo &egrave; 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'&egrave; modo di gestire questo breve scambio di dati come una
+ sessione unica. Ma con un firewall che pu&ograve; "ricordarsi" di un
+ pacchetto <acronym>UDP</acronym> in uscita e permette una risposta nei
+ minuti successivi, gestire i servizi <acronym>UDP</acronym> &egrave;
+ semplice. L'esempio seguente mostra come fare. La stessa cosa &egrave;
+ 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&agrave; delle
- regole standard per l'interfaccia di loopback (lo0), quindi non ce ne
- occuperemo pi&ugrave; 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&agrave;
- 'open' con:</para>
-
-<programlisting>firewall_type="/etc/rc.firewall.local"</programlisting>
-
- <important><para>Bisogna specificare il path <emphasis>completo</emphasis>
- del file, altrimenti non verr&agrave; caricato con il rischio di rimanere
- tagliati fuori dalla rete.</para></important>
-
- <para>Per il nostro esempio immaginiamo di avere l'interfaccia fxp0
- collegata all'esterno (Internet) e la xl0 verso l'interno (LAN). La macchina
- bridge ha assegnato l'IP 1.2.3.4 (&egrave; impossibile che il vostro ISP vi
- assegni un indirizzo di classe A di questo tipo, ma per l'esempio va
- bene).</para>
-
-<programlisting># Le connessioni di cui abbiamo mantenuto lo stato vengono fatte passare subito
+ del file <filename>/etc/rc.firewall</filename> ci sono gi&agrave; delle
+ regole standard per l'interfaccia di loopback
+ <devicename>lo0</devicename>, quindi non ce ne occuperemo pi&ugrave; 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&agrave; 'open' con:</para>
+
+ <programlisting>firewall_type="/etc/rc.firewall.local"</programlisting>
+
+ <important>
+ <para>Bisogna specificare il path <emphasis>completo</emphasis>
+ del file, altrimenti non verr&agrave; 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>
+ (&egrave; impossibile che il vostro <acronym>ISP</acronym> vi assegni un
+ indirizzo di classe A di questo tipo, 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
@@ -298,9 +308,9 @@ add pass ip from any to any in via xl0
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
+# 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 le richieste ident: &egrave; meglio piuttosto che aspettare che vadano in timeout
+# Lascia passare i controlli ident: &egrave; meglio che aspettare che vadano andare 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
@@ -322,70 +332,72 @@ add pass icmp from any to any icmptypes 11
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>
+ 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>
+ <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 &egrave; 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 &egrave; che
- c'&egrave; <emphasis>almeno</emphasis> un host sull'interfaccia esterna che
- non si pu&ograve; ignorare: il router. Solitamente, per&ograve;, gli ISP
- eseguono il controllo anti-spoof sui loro router e quindi non ce ne dobbiamo
- preoccupare.</para>
+ dalla rete interna. Questa &egrave; 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
+ &egrave; che c'&egrave; <emphasis>almeno</emphasis> un host
+ sull'interfaccia esterna che non si pu&ograve; ignorare: il router.
+ Solitamente, per&ograve;, 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&agrave; c'&egrave; una differenza: tutto il traffico sospetto
- verr&agrave; loggato.</para>
-
- <para>Ci sono due regole per permettere il traffico SMTP e DNS 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 &egrave; altro che
- uno specifico esempio (il formato delle regole &egrave; spiegato
- dettagliatamente nella man page &man.ipfw.8;). Bisogna notare che,
- affinch&egrave; 'relay' e 'ns' siano interpretati correttamente, la
- risoluzione dei nomi deve funzionare PRIMA che il bridge sia attivato.
- Questo &egrave; un chiaro esempio che dimostra l'importanza di settare l'IP
- sulla corretta scheda di rete. In alternativa &egrave; possibile specificare
- direttamente l'indirizzo IP anzich&egrave; il nome host (cosa necessaria se
- la macchina &egrave; IP-less).</para>
+ far passare nulla che non sia stato specificatamente permesso. In
+ verit&agrave; c'&egrave; una differenza: tutto il traffico sospetto
+ verr&agrave; 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 &egrave; altro che uno specifico
+ esempio (il formato delle regole &egrave; spiegato dettagliatamente nella
+ man page &man.ipfw.8;). Bisogna notare che, affinch&egrave; 'relay' e 'ns'
+ siano interpretati correttamente, la risoluzione dei nomi deve funzionare
+ <emphasis>prima</emphasis> che il bridge sia attivato. Questo &egrave; un
+ chiaro esempio che dimostra l'importanza di settare l'IP sulla corretta
+ scheda di rete. In alternativa &egrave; possibile specificare direttamente
+ l'indirizzo IP anzich&egrave; il nome host (cosa necessaria se la macchina
+ &egrave; 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 TCP). Sfortunatamente, questa non &egrave; una scelta
- applicabile con il bridge, quindi la cosa migliore &egrave; lasciarli
- passare fino alla destinazione. Finch&egrave; la macchina di destinazione
- non ha un demone ident attivo, questa tecnica &egrave; relativamente
- sicura. L'alternativa &egrave; proibire le connessioni sulla porta 113,
- creando qualche problema con servizi tipo IRC (le richieste ident devono
- andare in timeout).</para>
+ avranno sempre usato una regola 'reset' o 'forward' per i pacchetti
+ ident (porta 113 <acronym>TCP</acronym>). Sfortunatamente, questa non
+ &egrave; una scelta applicabile con il bridge, quindi la cosa migliore
+ &egrave; lasciarli passare fino alla destinazione. Finch&egrave; la
+ macchina di destinazione non ha un demone ident attivo, questa tecnica
+ &egrave; relativamente sicura. L'alternativa &egrave; 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 &egrave;
- che c'&egrave; una regola per lasciar comunicare la macchina bridge e
- un'altra per gli host della rete interna. Ricordate che questo &egrave;
- 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&agrave; attraverso il bridge, mentre la macchina
- locale user&agrave; il normale stack IP per le connessioni. Perci&ograve;
- due regole per gestire due casi differenti. Le regole 'in via fxp0'
- 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>
+ che c'&egrave; una regola per lasciar comunicare la macchina bridge e
+ un'altra per gli host della rete interna. Ricordate che questo &egrave;
+ 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&agrave; attraverso il bridge, mentre la macchina
+ locale user&agrave; il normale stack IP per le connessioni. Perci&ograve;
+ 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>
</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>
+ 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&agrave; di bridging in FreeBSD e per il tempo che mi ha
- dedicato rispondendo ad alcune mie domande a riguardo.</para>
- </sect1>
+ delle funzionalit&agrave; di bridging in FreeBSD e per il tempo che mi ha
+ dedicato rispondendo ad alcune mie domande a riguardo.</para>
+ </sect1>
</article> \ No newline at end of file