From owner-freebsd-doc Wed Jun 19 5:31:31 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8218F37B414 for ; Wed, 19 Jun 2002 05:30:11 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g5JCUBP86107; Wed, 19 Jun 2002 05:30:11 -0700 (PDT) (envelope-from gnats) Received: from vaio.alexdupre.com (212-41-211-209.adsl.galactica.it [212.41.211.209]) by hub.freebsd.org (Postfix) with ESMTP id BDF5737B416 for ; Wed, 19 Jun 2002 05:24:04 -0700 (PDT) Received: from vaio.alexdupre.com (localhost [127.0.0.1]) by vaio.alexdupre.com (8.12.2/8.12.2) with ESMTP id g5JCgj8g000734 for ; Wed, 19 Jun 2002 14:42:45 +0200 (CEST) (envelope-from alex@vaio.alexdupre.com) Received: (from alex@localhost) by vaio.alexdupre.com (8.12.2/8.12.2/Submit) id g5JCgjMq000733; Wed, 19 Jun 2002 14:42:45 +0200 (CEST) Message-Id: <200206191242.g5JCgjMq000733@vaio.alexdupre.com> Date: Wed, 19 Jun 2002 14:42:45 +0200 (CEST) From: Alex Dupre Reply-To: Alex Dupre To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/39510: [Update article] Filtering bridges (Italian version) Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 39510 >Category: docs >Synopsis: [Update article] Filtering bridges (Italian version) >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: maintainer-update >Submitter-Id: current-users >Arrival-Date: Wed Jun 19 05:30:11 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Alex Dupre >Release: FreeBSD 4.5-ALEXDUPRE i386 >Organization: >Environment: System: FreeBSD vaio.alexdupre.com 4.5-ALEXDUPRE FreeBSD 4.5-ALEXDUPRE #0: Fri Apr 12 14:12:57 CEST 2002 alex@vaio.alexdupre.com:/usr/obj/usr/src/sys/VAIO i386 >Description: Sync'd to English version >How-To-Repeat: >Fix: --- article_it.diff begins here --- --- it_IT.ISO8859-15/articles/filtering-bridges/article.sgml.orig Wed Jun 19 11:43:37 2002 +++ it_IT.ISO8859-15/articles/filtering-bridges/article.sgml Wed Jun 19 14:34:10 2002 @@ -24,15 +24,15 @@ 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 + 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. 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 è simile a uno + differenti. Sotto molti punti di vista un brigde è simile a uno switch Ethernet con solo due porte. @@ -44,14 +44,14 @@ 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 + 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 (ISP), vuoi perché il router non - supporta tali funzionalità. È in questi casi che l'utilizzo + supporta tali funzionalità. È in questi casi che l'utilizzo di un filtering bridge diventa altamente consigliato. Un firewall basato su bridge può essere configurato e inserito @@ -60,7 +60,7 @@ La traduzione italiana di "firewall" è "muro anti incendio", - non "muro di fuoco" come molti pensano. Nel corso + non "muro di fuoco" come molti pensano. Nel corso dell'articolo, comunque, manterrò i termini tecnici nella loro lingua originale in modo da non creare confusione o ambiguità. @@ -71,14 +71,14 @@ Metodi d'installazione Aggiungere le funzionalità di bridge a una macchina FreeBSD non - è difficile. Dalla release 4.5 è possibile caricare tali + è difficile. Dalla release 4.5 è possibile caricare tali funzionalità come moduli anziché dover ricompilare il - kernel, semplificando di gran lunga la procedura. Nelle prossime + kernel, semplificando di gran lunga la procedura. Nelle prossime sottosezioni spiegherò entrambi i metodi di installazione. Non seguite entrambe le istruzioni: le - procedure sono a esclusione. Scegliete + procedure sono a esclusione. Scegliete l'alternativa che meglio si adatta alle vostre esigenze e capacità. @@ -88,27 +88,27 @@ 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à - 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. + tipo PCI bus mastering. Le scelte migliori sono ancora le Intel + EtherExpress Pro seguite dalle 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. Configurazione del Kernel 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: + collaudato metodo di installazione. Per prima cosa bisogna aggiungere + le seguenti righe al file di configurazione del kernel: options BRIDGE options IPFIREWALL options IPFIREWALL_VERBOSE La prima riga serve a compilare il supporto per il bridge, la - seconda il firewall e la terza le funzioni di logging del firewall. - + seconda il firewall e la terza le funzioni di logging del + firewall. Adesso è necessario compilare e installare il nuovo kernel. Si possono trovare le istruzioni nella sezione bridge_load="YES" In questo modo all'avvio della macchina verrà caricato - insieme al kernel anche il modulo bridge.ko. Non + insieme al kernel anche il modulo bridge.ko. Non è necessario invece aggiungere una riga per il modulo ipfw.ko in quanto verrà caricato in automatico dallo script /etc/rc.network dopo aver @@ -139,13 +139,14 @@ 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 /etc/rc.conf. La regola di - default del firewall è di rifiutare tutti i pacchetti IP. Per - iniziare attiviamo il firewall in modalità '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à di non rimanere erroneamente tagliati fuori dalla rete). - Inserite queste linee nel file /etc/rc.conf: + alcune modifiche al file /etc/rc.conf. La regola di + default del firewall è di rifiutare tutti i pacchetti IP. Per + iniziare attiviamo il firewall in modalità , + 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 + /etc/rc.conf: firewall_enable="YES" firewall_type="open" @@ -154,39 +155,39 @@ La prima riga serve ad attivare il firewall (e a caricare il modulo ipfw.ko nel caso non fosse già compilato nel - kernel), la seconda a impostarlo in modalità 'open' (come descritto - nel file /etc/rc.firewall), la terza a non - visualizzare il caricamento delle regole e la quarta ad abilitare il + kernel), la seconda a impostarlo in modalità + (come descritto nel file /etc/rc.firewall), la terza + a non visualizzare il caricamento delle regole e la quarta ad abilitare il supporto per il logging. 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 + 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 + 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 DNS), visto che il - bridge verrà attivato alla fine della procedura di avvio. Questo + bridge verrà 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 /etc/rc.conf, mentre la xl0 - no. Assegnare IP a entrambe le schede di rete non ha molto senso, a meno + 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. - C'è un'altra cosa importante da sapere. Quando si utilizza IP + C'è un'altra cosa importante da sapere. Quando si utilizza IP sopra Ethernet ci sono due protocolli Ethernet in uso: uno è IP, - l'altro è ARP. ARP permette + l'altro è ARP. ARP permette la conversione dell'indirizzo IP di una macchina nel suo indirizzo - Ethernet (livello MAC). Affinché due macchine + Ethernet (livello MAC). Affinché due macchine separate dal bridge riescano a comunicare tra loro è necessario che - il bridge lasci passare i pacchetti ARP. Tale + il bridge lasci passare i pacchetti ARP. Tale protocollo non fa parte del livello IP, visto che è presente solo - con IP sopra Ethernet. Il firewall di FreeBSD agisce esclusivamente sul + 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 è configurato per non lasciar passare nulla. @@ -194,7 +195,8 @@ 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à 'open', non impedirà nessuna operazione. + modalità , non impedirà nessuna + operazione. Se ci dovessero essere dei problemi, è il caso di scoprire ora da cosa derivino e risolverli prima di continuare. @@ -218,7 +220,7 @@ 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ì, + possibilità di comunicazione tra di loro. Se è così, il prossimo passo è quello di aggiungere le parti net.link.ether.[blah]=[blah] di queste righe al file /etc/sysctl.conf, in modo che @@ -229,45 +231,48 @@ Configurazione del Firewall 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 + 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 + 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 'out' oppure 'xmit' non - verrà mai eseguita. Personalmente uso 'in via' che è una - sintassi più antica, ma che ha un senso quando la si legge. - Un'altra limitazione è 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). + solo in ingresso, quindi qualsiasi regola che usi + oppure non verrà mai eseguita. Personalmente + uso che è una sintassi più antica, + ma che ha un senso quando la si legge. Un'altra limitazione è che + si possono usare solo i comandi e + per i pacchetti filtrati dal bridge. Cose avanzate + come , o + 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). Nuovo in FreeBSD 4.0 è il concetto di stateful filtering. Questo è 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, + 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ò "ricordarsi" di un - pacchetto UDP in uscita e permette una risposta nei - minuti successivi, gestire i servizi UDP è - semplice. L'esempio seguente mostra come fare. La stessa cosa è - 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. + sessione unica. Ma con un firewall che può + ricordarsi di un pacchetto UDP in uscita + e permette una risposta nei minuti successivi, gestire i servizi + UDP è semplice. L'esempio seguente mostra come + fare. La stessa cosa è 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. - Vediamo un esempio di configurazione. Bisogna notare che all'inizio + Vediamo un esempio di configurazione. Bisogna notare che all'inizio del file /etc/rc.firewall ci sono già delle regole standard per l'interfaccia di loopback lo0, quindi non ce ne occuperemo più ora. Le regole personalizzate andrebbero messe in un file a parte (per esempio /etc/rc.firewall.local) e caricate all'avvio modificando la riga del file /etc/rc.conf dove era - stata definita la modalità 'open' con: + stata definita la modalità con: firewall_type="/etc/rc.firewall.local" @@ -279,7 +284,7 @@ Per il nostro esempio immaginiamo di avere l'interfaccia fxp0 collegata all'esterno (Internet) e la - xl0 verso l'interno (LAN). La + xl0 verso l'interno (LAN). La macchina bridge ha assegnato l'IP 1.2.3.4 (è impossibile che il vostro ISP vi assegni un indirizzo di classe A di questo tipo, ma per l'esempio va bene). @@ -332,61 +337,62 @@ add drop log all from any to any Coloro che hanno configurato un firewall in precedenza potrebbero aver - notato che manca qualcosa. In particolare, non ci sono regole contro lo + notato che manca qualcosa. In particolare, non ci sono regole contro lo spoofing, difatti non abbiamo aggiunto: add deny all from 1.2.3.4/8 to any in via fxp0 Ovvero, non far entrare dall'esterno pacchetti che affermano di venire - dalla rete interna. Questa è una cosa che solitamente viene fatta + 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 + generando falsi pacchetti che sembrano venire dall'interno. Il problema è che c'è almeno un host sull'interfaccia esterna che non si può ignorare: il router. Solitamente, però, gli ISP eseguono il controllo anti-spoof sui loro router e quindi non ce ne dobbiamo preoccupare. L'ultima riga sembra un duplicato della regola di default, ovvero non - far passare nulla che non sia stato specificatamente permesso. In + far passare nulla che non sia stato specificatamente permesso. In verità c'è una differenza: tutto il traffico sospetto verrà loggato. 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 + 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é 'relay' e 'ns' - siano interpretati correttamente, la risoluzione dei nomi deve funzionare - prima 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). + man page &man.ipfw.8;). Bisogna notare che, affinché + relay e ns siano interpretati correttamente, + la risoluzione dei nomi deve funzionare prima 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). 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 - è 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 - IRC (le richieste ident devono andare in - timeout). + avranno sempre usato una regola o + per i pacchetti ident (porta 113 + TCP). 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 IRC + (le richieste ident devono andare in timeout). 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 è + 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 + 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 '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. + locale userà il normale stack IP per le connessioni. Perciò + due regole per gestire due casi differenti. Le regole in via + fxp0 funzionano in entrambi i casi. In + generale, se usate regole attraverso il packet + filter, dovrete fare un'eccezione per i pacchetti generati localmente, in + quanto non entrano tramite nessuna interfaccia. --- article_it.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message