aboutsummaryrefslogtreecommitdiff
path: root/it_IT.ISO8859-15/articles/filtering-bridges/article.xml
diff options
context:
space:
mode:
authorGabor Kovesdan <gabor@FreeBSD.org>2012-10-01 09:53:01 +0000
committerGabor Kovesdan <gabor@FreeBSD.org>2012-10-01 09:53:01 +0000
commitb4346b9b2dfe86a97907573086dff096850dcb1d (patch)
tree9b951977cbd22dada9b868ac83b1d56791ea3859 /it_IT.ISO8859-15/articles/filtering-bridges/article.xml
parentbee5d224febbeba11356aa848006a4f5f9e24b30 (diff)
downloaddoc-b4346b9b2dfe86a97907573086dff096850dcb1d.tar.gz
doc-b4346b9b2dfe86a97907573086dff096850dcb1d.zip
- Rename .sgml files to .xml
- Reflect the rename in referencing files Approved by: doceng (implicit)
Notes
Notes: svn path=/head/; revision=39631
Diffstat (limited to 'it_IT.ISO8859-15/articles/filtering-bridges/article.xml')
-rw-r--r--it_IT.ISO8859-15/articles/filtering-bridges/article.xml441
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
+ &etherexpress; 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;&nbsp;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>