Attachment #22831 for bug #39510

View | Details | Raw Unified | Return to bug 39510
Collapse All | Expand All




    <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
        <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 &egrave; simile a uno
        switch Ethernet con solo due porte.</para>
    </abstract>
  </articleinfo>

      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&eacute; il router &egrave; di propriet&agrave; del fornitore di
      accesso (<acronym>ISP</acronym>), vuoi perch&eacute; il router non
      supporta tali funzionalit&agrave;.  &Egrave; 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

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

    <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&eacute; 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>

      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 pi&ugrave; 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

      <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


    <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; <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"
firewall_type="open"


    <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 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 <acronym>DNS</acronym>), visto che il
      bridge verr&agrave; 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'&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; <acronym>ARP</acronym>.  <acronym>ARP</acronym> permette
      la conversione dell'indirizzo IP di una macchina nel suo indirizzo
      Ethernet (livello <acronym>MAC</acronym>).  Affinch&eacute; due macchine
      separate dal bridge riescano a comunicare tra loro &egrave; necessario che
      il bridge lasci passare i pacchetti <acronym>ARP</acronym>.  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
      <acronym>ARP</acronym>) 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; <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>


    <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
      <literal>net.link.ether.<replaceable>[blah]</replaceable>=<replaceable>[blah]</replaceable></literal>
      di queste righe al file <filename>/etc/sysctl.conf</filename>, in modo che

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

    <para>Nuovo in FreeBSD 4.0 &egrave; il concetto di stateful filtering.
      Questo &egrave; 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'&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>

    <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
      <devicename>lo0</devicename>, 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; <option>open</option> con:</para>

    <programlisting>firewall_type="/etc/rc.firewall.local"</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>
      (&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>

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 <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&agrave; c'&egrave; una differenza: tutto il traffico sospetto
      verr&agrave; 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 &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> 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>

    <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 &egrave; una scelta
      applicabile con il bridge, quindi la cosa migliore &egrave; lasciarli
      passare fino alla destinazione.  Finch&eacute; 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 <acronym>IRC</acronym>
      (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 <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">

Return to bug 39510