aboutsummaryrefslogtreecommitdiff
path: root/it_IT.ISO8859-15/articles/filtering-bridges/article.xml
blob: 8b5a6fe2e5914e9d3e533b4f78d8f7999add5335 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
<?xml version="1.0" encoding="iso-8859-15"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
	"../../../share/xml/freebsd50.dtd">
<!--
     The FreeBSD Italian Documentation Project

     $FreeBSD$
     Original revision: 1.21
-->
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="it">
  <info><title>Filtering Bridges</title>
    

    <authorgroup>
      <author><personname><firstname>Alex</firstname><surname>Dupre</surname></personname><affiliation>
          <address><email>ale@FreeBSD.org</email></address>
        </affiliation></author>
    </authorgroup>

    <legalnotice xml: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>
  </info>

  <sect1 xml: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 xml: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 xml: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 <link xlink:href="&url.books.handbook;/kernelconfig-building.html">
        Building and Installing a Custom Kernel</link> dell'handbook.</para>
    </sect2>

    <sect2 xml: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 xml: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 <filename>fxp0</filename> (nel nostro
      caso) deve essere menzionata nella sezione ifconfig del file
      <filename>/etc/rc.conf</filename>, mentre la <filename>xl0</filename>
      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 xml: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 <filename>fxp0</filename> e <filename>xl0</filename> 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.[blah]=[blah]</literal>
      di queste righe al file <filename>/etc/sysctl.conf</filename>, in modo che
      vengano eseguite all'avvio della macchina.</para>
  </sect1>

  <sect1 xml: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
      <filename>lo0</filename>, 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
      <filename>fxp0</filename> collegata all'esterno (Internet) e la
      <filename>xl0</filename> verso l'interno (<acronym>LAN</acronym>).
      La macchina bridge ha assegnato l'IP
      <systemitem class="ipaddress">1.2.3.4</systemitem>
      ( 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
      fxp0</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 xml: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>