os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add Italian translation of filtering-bridges article

Browse source 
Submitted by:   Alex Dupre <sysadmin@alexdupre.com>
PR:             docs/34821
This commit is contained in:
Alexey Zelkin 2002-02-11 20:27:24 +00:00
parent f875943cc9
commit b67740a69b
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=12160
2 changed files with 405 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
it_IT.ISO8859-15/articles/filtering-bridges/Makefile Normal file
View file

@ -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"

391
it_IT.ISO8859-15/articles/filtering-bridges/article.sgml Normal file
View file

@ -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>