/*
* Tradotto da Mirco Uccheddu
* Nella speranza che sia utile alla comprensione dell'implementazione dei
* firewalls e alla diffusione del software libero in Italia.
* Non sono un traduttore professionista, quindi alcune parti potrebbero sembrare
* poco chiare, anche perche' la traduzione l'ho fatta al volo e senza ausilio di
* vocabolario ;-)
* Se proprio non resistete alla voglia di contattarmi uccheddu[at]tiscali.es
* Mi piacerebbe sapere in che modo questo documento vi e' stato utile, quindi
* contattatemi per farmelo sapere.
*/
The OpenBSD Packet Filter HOWTO
Wouter Coene
version 20020405.2, generated April 5, 2002
available at http://www.inebriated.demon.nl/pf-howto/
Contents
1 Introduction . .. . . . . . . . .. . . . . . . . . . . .. . . . . .. 3
1.1 utenza di riferimento . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Status . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 3
1.3 Copyright e licenze . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Contattare l'autore . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Il firewalling di base . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 base rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 more advanced rules . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Keeping state . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Breaking from rulesets: the quick keyword . . . . . . . . . . . . . . 8
2.5 Matching network interfaces . . . . . . . . . . . . . . . . . . . . . 8
2.6 Matching TCP ags . . . . . . . . . . . . . . . . . . . . . . .. . . . 8
2.7 Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 9
2.8 Variable expansion . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.9 Ruleset optimization: skip steps . . . . . . . . . . . . . . . . . .. 10
2.10 Putting it all together . . . . . . . . . . . . . . . . . . .. . . . 11
2.11 Loading your ruleset . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Filtering Bridges. . . . .. . . . . . . . . . . . .. . . . . .. . . . . 13
3.1 Two directions . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Stateful filtering . .. . . . . . . . . . . . . . . . . . . . . . . . 13
4 Firewalling tricks . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 State modulation . . .. . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Packet normalization . . .. . . . . . . . . . . . . . . . . . . . . . 15
5 Migrating from IPFilter . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1 head and group are gone . . . . . . . . . . . . . . . . . . . . . . . 17
6 Other documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7 Ringraziameti . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. 19
1 INTRODUZIONE
1 Introduzione
Il Packet Filter di OpenBSD e' il pacchetto ufficiale per quanto riguarda il
firewalling che fa' parte del kernel di OpenBSD fin dalla versione 3.0.Questo
documento descrive come impostare e amministrare le direttive del PF
e i mappaggi del NAT.(network address translation n.d.r.)
1.1 A chi e' rivolto
Questo documento e' rivolto agli amministratori di reti e di sistema con
almeno una basilare conoscenza del (inter)networking e dei protocolli di
rete. La conoscenza di altri sistemi di firewall non e' richiesta ma puo'
aiutare nel capire gli argomenti piu' complessi. 1.2 Status Questo
documento e' in fase di sviluppo, pertanto l'argomento OpenBSD Pf non e' ancora
da considerarsi trattato in modo completo ed esauriente.
Lista del da farsi: _ Network Address Translation _ IPv6 _ more notes regarding
the extensive feature set of the pfctl command _ AuthPF
1.3 Copyright and license The OpenBSD Packet Filter HOWTO version 20020405.2
Copyright (C) Wouter Coene, 2001, 2002. Redistribution and use in source and
binary forms, with or without modi_- cation, are permitted provided that the
following conditions are met: _ Redistributions of source code must retain the
above copyright notice, this list of conditions and the following disclaimer. _
Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution. 1 INTRODUCTION 4 _ The name of
the author may not be used to endorse or promote products derived from this
software without speci_c prior written permission. _ This software may not be
mass-distributed for sale without informing the author at least two weeks in
advance. THIS DOCUMENT IS PROVIDED BY THE AUTHOR \AS IS" AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE. 1.4 Contacting the author You can contact theWouter Coene
through email at wouter@inebriated.demon.nl, or via snail-mail: De Deel 17 3471
EN Kamerik The Netherlands
2 BASIC FIREWALLING
2 Basic firewalling
Si suppone che un firewall protegga una rete da potenziali attacchi
provenienti da un'altra rete, questo viene fatto attraverso
l'ispezionamento dei pacchetti che viaggiano tra le due reti, e imponendo delle
restrizioni sui tipi, gli obiettivi e persino il contenuto dei pacchetti.
Questa sezione spiega come impostare il firewalling usando PF. Per questa
sezione usero' una rete di tipo aziendale e il firewall come esempio. La rete
in se consiste di una tcp/ip network con indirizzi 260.250.1.0/24.Ci saranno un
server web aziendale avente ip 260.250.1.3, e un firewall avente due schede di
rete (chiamate NIC dora in poi ), denominate xl0 and xl1 rispettivamente. La
rete aziendale e' connessa all'interfaccia xl1 , l'interfaccia collegata ad
internet
e' connessa alla NIC xl0.
2.1 Direttive di base
Il componente di firewalling di PF usa dei tipi di direttive che
descrivono delle azioni da eseguirsi per certi pacchetti.Queste direttive
sono lette da un file e caricate nel kernel di OBSD usando il comando pfctl
(per ulteriori informazioni per il caricamento delle direttive, vedi la
sezione 2.1.1).
Il contenuto di detto file di direttive puo' assomigliare al seguente
block in all
pass in all
Analizziamo cosa succede in questo caso la prima direttiva dice al PF di
bloccare tutti i pacchetti in entrata.A differenza di altri firewalls, PF non
ferma la lettura della direttiva quando trova una corrispondenza. Invece,
memorizza il blocco del pacchetto, e continua nella lettura della direttiva
successiva. La direttiva successiva dice al PF di passare tutti I pacchetti
in arrivo qualunque sia la loro destinazione. Ancora una volta PF memorizza la
direttiva e passa alla direttiva successiva. Nel momento in cui arriva
alla fine delle direttive, PF inizia ad eseguire le operazioni memorizzate
fino a quel momento, in questo caso l'ultima direttiva memorizzata diceva a
PF di far passare I pacchetti, quindi esegue. Questo non sembra molto
utile in verita', quindi tentiamo qualcosa di piu' stimolante.
Accettiamo le connessioni al server web dell'azienda avente ip 260.250.1.31.
Puoi tentare qualcosa del genere:
2 FIREWALLING DI BASE
block in all
pass in from any to 260.250.1.3/32
Nuovamente, la prima direttiva dice al PF che deve memorizzare di bloccare
questo pacchetto anche se corrisponde a qualsiasi altra direttiva. La seconda
direttiva dice al PF di far passare i pacchetti che hanno come destinazione l'ip
260.250.1.3, dove /32 sta per la corrispondenza di tutti i 32 bits dell
indirizzo. Potreste chiedervi, e per quanto riguarda il traffico di ritorno? La
risposta e' piuttosto semplice, basta accettare il traffico proveniente da
260.250.1.3
e destinato ovunque.
block in all
pass in from any to 260.250.1.3/32
pass in from 260.250.1.3/32 to any
2.2 Altre direttive avanzate
Supponiamo che si decida di far funzionare un altro sito web nel server web
dell'azienda, e che il suddetto sito abbia delle informazioni sensibili e che
pertanto non debba essere visibile dall' esterno.Questo sito web, al contrario
del precedente, sara' accessibile dalla porta tcp non standard 8000
Quindi non avremo da filtrare soltanto l'indirizzo di destinazione, ma anche
quello relativo alla porta tcp , per essere sicuro che nessuno dall'esterno
possa connettersi alla porta 8000
ed accedere a dei dati sensibili.:
block in all
pass in proto tcp from any to 260.250.1.3/32 port = 8000
pass in proto tcp from 260.250.1.3/32 port = 8000 to any
Come puoi vedere, non stiamo filtrando soltanto il numero della porta, ma stiamo
anche dicendo al PF di permettere ai pacchetti tcp di passare attraverso il
firewall verso il webserver dell'azienda. Questo e' nessessario perche' il
protocollo IP di per se' non conosce i numeri delle porte.
Solo TCP e UDP possono distinguere tra diverse porte.
2.3 Keeping state
La componente firewall del PF e' in grado di ricordare quale sessione
TCP,UDP,ICMP e' stata creata, e puo' filtrare i pacchetti in accordo con questa
tabella di sessione.
Questo comportamento del PF e' chiamato "keeping state".
2 FIREWALLING DI BASE 7
Ogni volta che PF vede un pacchetto corrispondente ad una direttiva di keep
state, PF crea una nuova voce all'interno della tabella di keep state basata
sulle informazioni contenute nel pacchetto. Questo genera il passaggio di
susseguenti pacchetti della stessa sessione senza attraversare la corrispondete
fase della direttiva . Il keeping state nelle connessioni TCP coinvolge il
delicato controllo del numero di sequenza TCP dei pacchetti verso la tavola di
"state", e rifiutando i pacchetti che non corrispondono allo "state" della
tavola stessa, diminuendo quindi la possibilita' che degli hosts dietro il
firewall aventi delle lacune nel implementazione dello stack della connessione
TCP ne traggano vantaggio. Nel "Keeping state" delle sessioni UDP, PF permette
un singolo ritorno di pacchetto per ciascun pacchetto corrispondente la
direttiva creata dalla tavola di stato. Supponiamo che si decida che quell web
browsing sia possible solo dalla rete della nostra azienda, la quale richiede il
passaggio sia delle connessioni TCP verso la porta 80 sia le richieste verso la
porta UDP 53 del DNS. Usando il PF state engine per questo scopo e' un modo
sicuro di permettere cio' senza allo stesso tempo aprire l'intera rete agli
attacchi dall'esterno. Mentre si e' in questa condizione, si puo' usare lo
"state engine" anche per permettere l'accesso al server web della'azienda, col
risultato di avere un maggiore controllo all'accesso di detto server web:
block in all
pass in proto udp from 260.250.1.0/24 to any port = 53 keep state
pass in proto tcp from 260.250.1.0/24 to any port = 80 keep state
pass in proto tcp from any to 260.250.1.3/32 port = 80 keep state
La terza direttiva abilita gli hosts all'interno dell'azienda di effettuare
delle connesioni alla porta http di host esterni, facendo im modo che PF crei
una nuova voce nella sua "state table" per queste connessioni.L'ultima direttiva
dice al PF di fare la stessa cosa per le connessioni effettuate dall'esterno
verso il server web dell'azienda, rendendo in questo modo obsoleta la direttiva
per il traffico di ritorno quando non stavamo usando ancora lo "state engine".
Usando lo "state engine" puo' sembrare che stiamo caricando di lavoro extra ill
nostro firewall, rallentando in questo modo il traffico.Ad ogni modo, attraverso
il controllo della "state table" in PF e' molto piu' veloce che la comparazione
singolo delle direttive Una tipica raccolta di direttive avente 50 direttive
necessita di circa 50 comparazioni, laddove una "table state" di 50.000
direttive, grazie alla sua struttura binaria ad albero, impiega solo 16
comparazioni. Questo fatto, combinato all' aggiunta sicurezza , fa' in modo che
valga maggiormente la pena di usare lo "state engine", anche per le direttive
piu' semplici, che potrebbero essere create molto
piu' semplicemente senza.
2 FIREWALLING DI BASE 8
2.4 Breaking from rulesets: the quick keyword
Alcune volte puo' essere appropriato fare in modo che PF fermi immediatamente la
comparazione della direttiva e fare cio' che dovrebbe fare quando un pacchetto
coincide una direttiva specifica. Per fare cio' con PF si usa la parola
"quick". Nel momento in cui si verifica una coincidenza nella direttiva che
contiene l'opzione quick avremo come risultato la terminazione della
comparazione del pacchetto in questione.
Cio' e' particolarmente utile per proteggere la vostra rete dagli attacchi
effettuati attraverso
pacchetti spooffati, come mostrano le seguenti direttive:
block in all
block in quick from 10.0.0.0/8 to any
block in quick from 172.16.0.0/12 to any
block in quick from 192.168.0.0/16 to any
block in quick from 255.255.255.255/32 to any
pass in all
Questa direttiva dice a PF di scartare immediatamente I pacchetti originari da
10.0.0.0/8, 172.16.0.0/12.,192.168.0.0/16 e 255.255.255.255/32.Gli altri
pacchetti sono lasciati passare. Il risultato di cio' e' una grande
velocizzazione se usato in modo appropriato per direttive atte a vagliare una
grossa quantita' di traffico, perche' PF non cerchera' delle corrispondenze
nelle direttive successive.
2.5 Matching network interfaces
É inoltre possibile stabilire l'interfaccia nella quale il pacchetto e'
ricevuto. Adattiamo le nostre precedenti direttive anti-spoof tenendo in mente
la struttura della
nostra rete aziendale:
block in all
block in quick on xl0 from 10.0.0.0/8 to any
block in quick on xl0 from 172.16.0.0/12 to any
block in quick on xl0 from 192.168.0.0/16 to any
block in quick on xl0 from 255.255.255.255/32 to any
pass in all
2.6 Matching TCP ags
Per abilitare il blocco di un pacchetto non valido, si puo' istruire PF a
filtrare nei TCP ags usando le parole chiave "flags", seguite da una lista di
ags cui devono coincidere, una barra
"/" opzionale e una maschera ag opzionale.
2 FIREWALLING DI BASE 9
Per ogni pacchetto PF cancella tutto tranne gli ags che sono stati specificati
nella maschera, e poi controlla e verifica negli ags che dovrebbero essere
tenuti controllati. Quindi dicendo che "flags S/SA" dice al PF prima di
mascherare tutto tranne SYN e ACK poi di controllare se SYN e' stato impostato.
Sono riconosciuti I seguenti ags::
F : FIN, per le connessioni in chiusura
S : SYN, per le connessione in fase di apertura
R : RST, per l'azzeramento della connessione
P : PSH, per essere sicuri che I dati siano arrivati
A : ACK, per I pacchetti di riconscimento
U : URG, per indicare che il pacchetto e' urgente
Per esempio , un pacchetto che richiede una nuova connessione imposta soltanto
il SYN ag, e il pacchetto di riconoscimento imposta imposta sia il SYN che l'
ACK ag. E un pacchetto di rifiuto della connessione imposta ACK e RST. Usando
una non valida combinazione di ags TCP e' un modo molto usato di scannerizzare
host remoti in modo segreto per trovarvi delle porte aperte. Usando questi le
parole chiave flags, si puo' difendere il proprio sistema contro questi scan
segreti, e forzare i port scanners ad usare dei tipi di scan che siano molto
piu' riconoscibili e individuabili. Prendiamo l'esempio del nostro "state
-keeping" piu' nuovo di questo how-to.Noi vogliamo in questo caso rafforzare
soltanto i pacchetti di tipo TCP, dei quali sono impostati solo gli ags SYN
e ACK , prendiamo una voce nella tabella di stato:
block in all
pass in proto udp from 260.250.1.0/24 to any port = 53 keep state
pass in proto tcp from 260.250.1.0/24 to any port = 80 \
flags S/SA keep state
pass in proto tcp from any to 260.250.1.3/32 port = 80 \
flags S/SA keep state
Questo dovrebbe fare in modo da prevenire le tecniche di port scanning
menzionate precedentemente.
2.7 Sets
È possibile, invece di una singola sorgente o host di destinazione, specificare
una lista di hosts. Questo e' possibile racchiudendo gli host tra parentesi
grafe {} e separandoli tra loro con delle virgole:
2 BASIC FIREWALLING 10
Quindi se la tua vecchia direttiva e' rappresentata in .questo modo:
block in quick on xl0 from 10.0.0.0/8 to any
block in quick on xl0 from 172.16.0.0/12 to any
block in quick on xl0 from 192.168.0.0/16 to any
block in quick on xl0 from 255.255.255.255/32 to any
Puoi rimpiazzarla in modo equivalente cosi':
block in quick on xl0 from { 10.0.0.0/8, 172.16.0.0/12, \
192.168.0.0/16, 255.255.255.255/32 } to any
Cio' puo' essere fatto anche per quanto riguarda le interface (NIC), i
protocolli e le porte Il programma pfctl dividera' tali regole per ogni
combinazione, quindi PF ottimizza le regole con tecnica descritta nella sezione
2.9. In aggiuntaaumenta la leggibilita' attraverso l'ordine di magnitudine per
grandi liste di hosts, interfacce o porte.
2.8 Espansione di variabili
PF supporta anche l'espansione di variabili, modellate dopo quelle della shell.
Le variabili sono definite attraverso l'assegnazione di valori, e espanse
attraverso la il propendimento del nome della variabile con il simbolo del
dollaro $.
webserver="260.250.1.3/32"
pass in from any to $webserver port = 80 keep state
Il valore che gli si vuole assegnare deve essere tra doppie virgolette "valore".
2.9 Ottimizzazione delle regole: gli skip steps
Al contrario di IPFilter, il PF di OpenBSD non supporta i gruppi di parole
chiave. Gli sviluppatori di PF hanno scelto uno schema chiamato "skip steps",
nel quale le regole sono ottimizzate automaticamente.
Consideriamo una regola come questa:
block in quick on xl0 from 10.0.0.0/8 to any
block in quick on xl0 from 172.16.0.0/12 to any
block in quick on xl0 from 192.168.0.0/16 to any
block in quick on xl0 from 255.255.255.255/32 to any
2 BASIC FIREWALLING 11
Per ogni pacchetto in arrivo, questa regola e' valutata dall'alto verso I basso.
Immagina che un pacchetto sia ricevuto nell'interfaccia xl1.La prima regola e'
vagliata ma risulta non essere coincidente.Dal momento in cui le altre regole
si applicano anche all'interfaccia xl0, PF puo' passare oltre e ignorare queste
regole. Quando si carica una lista di regole I seguenti parametri sono
comparati tra le regole successive (in questo ordine):
1. interfaccia
2. protocollo
3. indirizzo di provenienza
4. porta di provenienza
5. indirizzo di destinazione
6. porta di destinazione
Per ogni regola, PF calcola un cosiddetto skip step per ognuno di questi
parametri, il quale dice a PF quante regole successive hanno lo stesso valore
per il parametro. Se un pacchetto in entrata nell' interfaccia xl1 non coincide
con la nostra regola di esempio, PF nota che il pacchetto in entrata
sull'interfaccia non coincide la stessa nella prima regola, e siccome le prime
tre regole contengono tale interfaccia, vengono ignorate anche queste ultime.
Quindi se si vuole massimizzare la perfomance dele proprie regole, si dovrebbe
ordinare le proprie regole per interfaccia, protocollo, porta e indirizzo
di provenienza e infine per indirizzo e porta di destinazione in
questo ordine.
2.10 Mettendole tutte insieme
Mettiamo tutto insieme tutto quello che abbiamo imparato su PF usando il piu
recente esempio della rete aziendale.Il risultato e' il seguente:
#Configuriamo alcune variabili
external="xl0"
internal="xl1"
corporate="260.250.1.0/24"
webserver="260.250.1.3/32"
private="{ 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, \
255.255.255.255/32 }"
2 BASIC FIREWALLING 12
# block by default
block in all
# Permettiamo il web browsing dall'interno della nostra rete
pass in quick on $internal proto udp from $corporate to any \
port = 53 keep state
pass in quick on $internal proto tcp from $corporate to any \
port = 80 flags S/SA keep state
# scarta gli spoofed packets
block in quick on $external from $private to any
# Permetti l'accesso del web server aziendale da internet
pass in quick on $external proto tcp from any to $webserver \
port = 80 flags S/SA keep state
Abbiamo ora un firewall sicuro.Certamente, questa non e' l'unica cosa
neccessaria per rendere sicura l'intera rete aziendale, ma come nostra prima
linea di difesa non e' per niente male.
2.11 Loading your ruleset
Una volta che si e' soddisfatti delle proprie regole, le si puo' salvare in
/etc/pf.conf,
poi basta riavviare la macchina o eseguire il seguente commando:
pfctl -R /etc/pf.conf
Affinche' il file delle regole venga caricato automaticamente ad ogni riavvio
della macchina
ricordarsi di impostare
pf=YES in /etc/rc.conf.
3 FILTERING BRIDGES 13
3 Filtering Bridges
Un bridge (ponte n.d.r.), o ripetitore, e' una periferica di rete che connette
due o piu' segmenti di rete tra loro.Solitamente si tratta da una semplice
macchina che semplicemente ripete ogni pacchetto in entrata negli altri segmenti
di rete. Ad ogni modo, un OpenBSD puo essere usato per il cosiddetto bridging,
che permette di usare PF per filtrare il trafffico tra i segmenti di rete.
Questa sezione spiega come configurare un bridge di tipo filtering usando
OpenBSD e PF. La rete usata nell' esempio e' quella di una universita', gli ip
di tipo ipv4 sono 10.0.0.0/8, consistente in un largo numero di clients
rappresentati dalle workstations degli studenti., un server web avente
indirizzo ip 10.0.0.1/32, e un shell server avente indirizzo 10.0.0.2/32.
Per ragioni di sicurezza, il segmento di rete dello staff dell'universita'
e' separato da quello degli studenti, il cui traffico e' filtrato con minimi
cambiamenti alla topologia della rete. La decisione e' stata quindi quella di
usare un OpenBSD, con la rete degli studenti connessa all'interfaccia xl0, e la
rete server connessa all' interfaccia xl1.
3.1 Two directions
I pacchetti che attraversano il bridge passano per PF due volte: passano
attraverso una interfaccia ed escono dall'altra.Pertanto la nostra lista di
regole deve permettere sia il traffico in uscita che quello in entrata,
cosicche' dobbiamo partire dalle seguenti regole:
pass in on xl0 any
pass out on xl0 any
pass in on xl1 any
pass out on xl1 any
Questo permette la traffico ricevuto in entrambe le interfacce xl0 e xl1
di entrare nel bridge e permettere al suddetto traffico di essere instradato nel
segmento di rete corretto:
3.2 Stateful filtering
il PF di OpenBSD ha questa buona caratteristica chiamata keeping state,
descritta nella sezione 2.3, la quale puo' essere usata nella rete presa ad
esempio per aumentare la sicurezza del segmento di rete dei server.Ad ogni modo,
c'e' una cosa di cui dobbiamo tenere conto quando ci apprestiamo ad usare gli
stateful filtering:le voci nella tabella di stato (state table n.d.r.)
sono indicizzate da una chiave consistente da:
3 FILTERING BRIDGES
Indirizzi di provenienza e di destinazione e le porte TCP , dove l'ordine di
queste coppie e' rilevante. Sia il pacchetto in uscita da A a B crea una nuova
voce nella tavola di stato,PF farà passare tutti i pacchetti in uscita da A a
B, e i pacchetti in entrata da A a B, il che in un caso non-bridged e'
perfettamente chiaro è ovvio. Ad ogni modo, quando si usa lo state keeping in
un bridge, il pacchetto passa attraverso PF due volte;uno in entrata da una
interfaccia e l'altro in uscita nell'altra. Ci sono due soluzioni a questo
problema.Una creando due voci ognuna per ogni interfaccia, usando due direttive
con l'opzione keeping state. Questa, ad ogni modo, aumenta il carico del
servente bridge, e non è raccomandata, dal momento che l'altra soluzione è
più elegante. Dalla prospettiva di PF, i pacchetti passano due volte
attraverso il bridge, se si guarda una sola interfaccia, si vedrà esattamente
lo stesso traffico, è diversa soltanto la direzione. Quindi, possiamo
ignorare una interfaccia e filtrare soltanto sull'altra. Vorremmo applicare il
keep state nelle connessioni sia del webserver sia del shell server, e dal
momento che noi abilitiamo il traffico della rete studenti, filtreremo
nell'interfaccia
xl0, semplicemente facendo passare il traffico nella xl1:
# alcune variabili
web="10.0.0.1/32"
shell="10.0.0.2/32"
# permettti il traffico di attraversare l'interfaccia xl1
pass in quick on xl1 all
pass out quick on xl1 all
# Di default blocchiamo tutto il traffico da e per l'interfaccia xl0
block in on xl0 all
block out on xl0 all
# permetti le connesisoni verso il webserver e il shell server
pass in quick on xl0 proto tcp from any to $web \
port = 80 flags S/SA keep state
pass in quick on xl0 proto tcp from any to $shell \
port = { 22, 23 } flags S/SA keep state
2A purely psychological reason
4 Trucchetti per il FIREWALLING 15
4 Firewalling tricks
Per aumentare la sicurezza del/degli host/s,PF possiede una serie di
funzionalita' uniche per correggere errori nello stack dell'implementazione
dello TCP/IP, le quali sono descritte
nella sezione seguente.
4.1 State modulation
Al fine di assicurare l'esatta consegna dei pacchetti tcp e prevenire il
dirottamento delle connessioni, il protoccolo TCp utilizza uno schema
sequenziale di numeri nel quale è scelta una sequenza casuale di numeri (ISN)
all' inizio della connesione, la quale è incrementata per ogni byte trasmesso.
Comunque, molte popolari implementazioni TCP usano una generazione casuale di
numeri molto povera di questi ISNs3, rendendo queste connesioni vulnerabili nei
confronti di persone maliziose. Questo è il motivo per il quale gli sviluppatori
del PF di OBSD hanno deciso di implementare lo state modulation. Ciò porta alla
geerazione di una generazione casuale di numeri maggiore per le connessioni che
corrispondo alla direttiva (rule) del PF, traducendo i sequence numeri dei
pacchetti passanti attraverso il firewall dall ISn generato dall'host verso
l'ISn generato dal firewall e viceversa. Ciò può essere fatto aggiungendo la
parola chiave modulate state alle direttive di PF, come questa, il cui scopo è
proteggere la rete definita nel capitolo precedente:
pass in quick on xl1 proto tcp from 260.250.1.0/24 to any \ flags S/SA modulate
state
Il modulate state implica il keep State, descritto nella sezione 2.3
4.2 Packet normalization
dal momento che alcuni stack IP non implementato correttamente il packet
defragmentation, il PF di OBSD rende disponibile la direttiva scrub.Se un
pacchetto corrisponde ad una direttiva di tipo scrub, il componente di
normalizzazione di PF si sincera che il pacchetto sia defframmentato e
completamnete liberato di tutte le anomalie prima che sia mandato verso la sua
destinazione naturale
4.3
For more information about ISN generation, along with a survey of the ISN
generation on some popular operating systems, see
http://razor.bindview.com/publish/papers/
tcpseq.html
4.4
At the time of writing, it is not entirely clear to me how this interacts with
state keeping. Could any of the PF developers comment on this?
4.5
FIREWALLING TRICKS 16
Normalizing all incoming network tra_c would require a rule such as this:
scrub in all
Using the scrub directive uses quite an amount of server resources, so its use
should be limited to protecting only the weak TCP/IP stack implementations.
Additional options that apply to the scrub directive are:
no-df clear the don't fragment bit from a matching IP packet.
min-ttl number enforce a minimum time to live for matching IP packets,
dropping packets that don't match the requirement.
5 MIGRATING FROM IPFILTER 17
5 Migrating from IPFilter
The ruleset model OpenBSD PF uses was modelled after that of IPFilter.
There are also quite a few di_erences, which this section tries to document.
5.1 head and group are gone
The head and group keywords, which were used in IPFilter to group a
number of rules, are no longer needed under OpenBSD PF. If you used to
use head and group, you'll have to manually re-order your rulesets so they'll
work under OpenBSD PF.
OpenBSD PF has an automatic scheme for ruleset optimization, called skip
step. See section 2.9 for more information.
6 OTHER DOCUMENTATION 18
6 Other documentation
There are a number of sources for information on OpenBSD PF and _rewalls
in general available on the Internet. Here's a short summary of stu_ that
might be interesting:
http://www.benzedrine.cx/pf.html The original homepage of what is
now OpenBSD PF.
http://www.obfuscation.org/ipf/ The IPFilter HOWTO. Though the
HOWTO you're reading right now tries to be as complete as possible
with regard to OpenBSD PF, it might be interesting to look at
OpenBSD PF's roots too.
http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html The Linux Firewall
and Proxy HOWTO, which also covers the subject of setting up
user-space proxies such as Squid and SOCKS. Written for Linux, but
might be of interest to OpenBSD users as well.
http://www.openbsd.org/cgi-bin/man.cgi?query=pfctl&sektion=8&format=html
OpenBSD manual page on the pfctl program.
http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&sektion=5&format=html
OpenBSD manual page on the format of OpenBSD PF rulesets.
http://www.openbsd.org/cgi-bin/man.cgi?query=pf&sektion=4&format=html
OpenBSD manual page on the pf device. Mainly of interest for developers.
7 THANKS 19
7 Thanks
The author would like to thank the following people for providing help with
some of the more complicated subjects, for clarifying some of the internal
workings of OpenBSD PF, for pointing out errors or mistakes in previous
versions of this document, or generally for making suggestions (in alphabetical
order):
_ Matthew Clarke
_ Mike Frantzen
_ Markus Friedl
_ Artur Grabowski
_ Daniel Hartmeier
_ Erik Liden
_ Rod Whitworth
_ Jim Zajkowski
Stampa