aboutsummaryrefslogtreecommitdiff
path: root/it_IT.ISO8859-15/articles
diff options
context:
space:
mode:
authorAlexey Zelkin <phantom@FreeBSD.org>2002-02-11 20:27:24 +0000
committerAlexey Zelkin <phantom@FreeBSD.org>2002-02-11 20:27:24 +0000
commitb67740a69bd60d8acd5dc18d372f0250de72715e (patch)
tree1e6a6af2a4c2097e62167e4adf5c5722fd052400 /it_IT.ISO8859-15/articles
parentf875943cc9ea8da69c1a7d5ff0bbcf824c94025a (diff)
downloaddoc-b67740a69bd60d8acd5dc18d372f0250de72715e.tar.gz
doc-b67740a69bd60d8acd5dc18d372f0250de72715e.zip
Add Italian translation of filtering-bridges article
Submitted by: Alex Dupre <sysadmin@alexdupre.com> PR: docs/34821
Notes
Notes: svn path=/head/; revision=12160
Diffstat (limited to 'it_IT.ISO8859-15/articles')
-rw-r--r--it_IT.ISO8859-15/articles/filtering-bridges/Makefile14
-rw-r--r--it_IT.ISO8859-15/articles/filtering-bridges/article.sgml391
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