Filtering Bridges
Indietro |  | Avanti

# 5 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 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 `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).

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

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:

    firewall_type="/etc/rc.firewall.local"

> Importante: Bisogna specificare il path completo del file, altrimenti non verrà caricato con il rischio di rimanere tagliati fuori dalla rete.

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` (è impossibile che il vostro ISP vi assegni un indirizzo simile a questo, ma per l'esempio va bene).

    # 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

Coloro che hanno configurato un firewall in precedenza potrebbero aver 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 per essere sicuri che qualcuno non provi a eludere il packet filter, 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 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 per le proprie esigenze, questo non è altro che uno specifico esempio (il formato delle regole è spiegato dettagliatamente nella man page 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).

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

Indietro | Partenza | Avanti
Attivazione del Bridge |  | Contributi

Questo, ed altri documenti, possono essere scaricati da ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Per domande su FreeBSD, leggi la documentazione prima di contattare <questions@FreeBSD.org>.
Per domande su questa documentazione, invia una e-mail a <doc@FreeBSD.org>.