Add Italian translation of filtering-bridges article

Submitted by:   Alex Dupre <sysadmin@alexdupre.com>
PR:             docs/34821

2 files changed, 405 insertions, 0 deletions

diff --git a/it_IT.ISO8859-15/articles/filtering-bridges/Makefile b/it_IT.ISO8859-15/articles/filtering-bridges/Makefile
new file mode 100644
index 0000000000..886e21cc9d
--- /dev/null
+++ b/it_IT.ISO8859-15/articles/filtering-bridges/Makefile
@@ -0,0 +1,14 @@
+# $FreeBSD$
+
+DOC?= article
+
+FORMATS?= html
+
+INSTALL_COMPRESSED?=gz
+INSTALL_ONLY_COMPRESSED?=
+
+SRCS= article.sgml
+
+DOC_PREFIX?= ${.CURDIR}/../../..
+
+.include "${DOC_PREFIX}/share/mk/doc.project.mk"
diff --git a/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml b/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml
new file mode 100644
index 0000000000..f2f946136f
--- /dev/null
+++ b/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml
@@ -0,0 +1,391 @@
+<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
+<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
+%man;
+<!ENTITY % ISOlat1 PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1//EN">
+%ISOlat1;
+]>
+
+<article>
+  <articleinfo>
+    <title>Filtering Bridges</title>
+
+    <authorgroup>
+      <author>
+        <firstname>Alex</firstname>
+        <surname>Dupre</surname>
+        
+        <affiliation>
+          <address><email>sysadmin@alexdupre.com</email></address>
+        </affiliation>
+      </author>
+    </authorgroup>
+    
+    <pubdate>$FreeBSD$</pubdate>
+
+    <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>
+    </abstract>
+  </articleinfo>
+
+  <sect1 id="filtering-bridges-why">
+    <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>
+    
+    <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>
+    
+    <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>
+    </note>
+  </sect1>
+
+  <sect1 id="filtering-bridges-how">
+    <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>
+    
+    <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>
+    </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>
+    
+    <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>
+      
+<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 &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>
+    </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>
+          
+      <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>
+    </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 &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>
+
+    <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>
+    
+    <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>
+    
+    <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>
+    
+    <para>Se ci dovessero essere dei problemi, &egrave; 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 fxp0 e xl0 con i propri):</para>
+
+<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>
+
+    <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>
+  </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>
+
+    <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>
+
+    <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
+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.68.0.0/16 to any in via fxp0
+
+# Permette alla macchina bridge di connettersi con chi vuole
+# (se la macchina &egrave; 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
+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
+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 &egrave; 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 &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>
+
+    <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>
+
+    <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>
+
+    <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>
+  </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&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