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

Various whitespaces and lines length fixes

Browse source 
PR:		docs/39510
Submitted by:	Alex Dupre <sysadmin@alexdupre.com>
Approved by:	keramida
This commit is contained in:
Marc Fonvieille 2002-06-23 20:52:24 +00:00
parent 77b67b247b
commit f4128cc579
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=13463
1 changed files with 95 additions and 82 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -59,8 +59,9 @@
alcun problema di assegnazione di indirizzi IP.</para>
<note>
<para>La traduzione italiana di <quote>firewall</quote> &egrave; <quote>muro anti incendio</quote>,
<emphasis>non</emphasis> <quote>muro di fuoco</quote> come molti pensano. Nel corso
<para>La traduzione italiana di <quote>firewall</quote> &egrave;
<quote>muro anti incendio</quote>, <emphasis>non</emphasis>
<quote>muro di fuoco</quote> 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>
@ -89,18 +90,19 @@
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>
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 pi&ugrave; vecchio e
collaudato metodo di installazione. Per prima cosa bisogna aggiungere le
seguenti righe al file di configurazione del kernel:</para>
collaudato metodo di installazione. Per prima cosa bisogna
aggiungere le seguenti righe al file di configurazione del
kernel:</para>
<programlisting>options BRIDGE
options IPFIREWALL
@ -141,10 +143,11 @@ options IPFIREWALL_VERBOSE</programlisting>
(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; <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&agrave; di non rimanere erroneamente tagliati fuori dalla rete).
iniziare attiviamo il firewall in modalit&agrave; <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&agrave; di non rimanere
erroneamente tagliati fuori dalla rete).
Inserite queste linee nel file <filename>/etc/rc.conf</filename>:</para>
<programlisting>firewall_enable="YES"
@ -154,8 +157,9 @@ 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; <option>open</option> (come descritto
nel file <filename>/etc/rc.firewall</filename>), la terza a non
kernel), la seconda a impostarlo in modalit&agrave;
<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>
@ -194,7 +198,8 @@ firewall_logging="YES"</programlisting>
<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; <option>open</option>, non impedir&agrave; nessuna operazione.</para>
modalit&agrave; <option>open</option>, 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>
@ -229,21 +234,24 @@ firewall_logging="YES"</programlisting>
<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&eacute; non tutte le
regole per il firewall, in modo da rendere sicura la rete interna.
Ci sono delle complicazioni nel fare questo, perch&eacute; 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 <option>out</option> oppure <option>xmit</option> non
verr&agrave; mai eseguita. Personalmente uso <option>in via</option> 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 <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>
solo in ingresso, quindi qualsiasi regola che usi <option>out</option>
oppure <option>xmit</option> non verr&agrave; mai eseguita. Personalmente
uso <option>in via</option> 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
<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 &egrave; il concetto di stateful filtering.
Questo &egrave; un grande miglioramento per il traffico
@ -252,13 +260,15 @@ firewall_logging="YES"</programlisting>
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; <quote>ricordarsi</quote> 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>
sessione unica. Ma con un firewall che pu&ograve;
<quote>ricordarsi</quote> 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
@ -279,8 +289,9 @@ firewall_logging="YES"</programlisting>
<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>
<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>
@ -356,16 +367,18 @@ add drop log all from any to any</programlisting>
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&eacute; <quote>relay</quote> e <quote>ns</quote>
man page &man.ipfw.8;). Bisogna notare che, affinch&eacute;
<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 &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&eacute; il nome host (cosa necessaria se la macchina
&egrave; IP-less).</para>
scheda di rete. In alternativa &egrave; possibile specificare
direttamente l'indirizzo IP anzich&eacute; 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 <option>reset</option> o <option>forward</option> per i pacchetti
avranno sempre usato una regola <option>reset</option> o
<option>forward</option> 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&eacute; la
@ -383,10 +396,10 @@ add drop log all from any to any</programlisting>
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 <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>
<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">