Filtro NAT e IP di origine in PF, usando OpenBSD> = 4.7

Ho appena letto un libro su PF (The Book Of PF, No Starch), ma c'è una domanda a cui non ha risposto.

Se ho una macchina gateway che utilizza due interfacce, $ int_if e $ ext_if e I NAT i pacchetti provenienti da $ int_if: net (che è, diciamo, 10.0.0.0/24) a $ ext_if usando match, quando viene applicato il NAT ? Prima o dopo le regole di filtraggio?

Esempio:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
pass out on $ext_if from 10.0.0.0/24
block drop out on $ext_if from 10.0.0.23

Funziona? O ottiene l'IP di origine di un pacchetto proveniente da 10.0.0.23 NATed all'indirizzo $ ext_if prima del controllo se viene valutato da 10.0.0.23?

Questo diagramma non è utile per rispondere a questa domanda, penso, ma è comunque interessante: [ http://www.benzedrine.cx/pf_flow.png ]

Se leggi le FAQ su PF NAT [ http://www.openbsd.org/faq/pf/nat.html ], in particolare la sezione "Configurazione di NAT", troverai queste frasi:

Quando un pacchetto viene selezionato da una regola di corrispondenza, i parametri (ad es. Nat-to) in quella regola vengono ricordati e vengono applicati al pacchetto quando viene raggiunta una regola di passaggio corrispondente al pacchetto. Ciò consente a un'intera classe di pacchetti di essere gestita da un'unica regola di abbinamento e quindi è possibile prendere decisioni specifiche sull'autorizzazione del traffico con regole di blocco e passaggio.

Penso che suona come se non fosse come ho detto nel paragrafo sopra, quindi l'IP sorgente viene "ricordato" fino a quando non viene presa una decisione sull'azione da fare con il pacchetto. Se viene presa la decisione, viene applicato il NATting.

Cosa ne pensi?

PS: Questa è una domanda abbastanza teorica. Se sei un po 'pragmatico, lo farai in questo modo:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
block drop from 10.0.0.23
# or, explicitly,
# block drop in on $int_if from 10.0.0.23

Quindi la blockregola viene già applicata quando il pacchetto arriva su $ int_if.

EDIT: Un'altra possibilità è, ovviamente, decidere prima del NAT:

pass from 10.0.0.0/24
block drop from 10.0.0.23
match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)

Se arriva un pacchetto da .23, prima corrisponde alla prima regola, quindi alla seconda e alla terza "regola". Ma poiché la seconda regola è l'ultima decisione sul passaggio / blocco, il pacchetto viene bloccato. Giusto?

Sì, è abbastanza teorico, quello che hai chiesto, ma una domanda molto interessante.

La matchregola verrà applicata quando agisce sull'ultima regola corrispondente. matchle regole sono "appiccicose", come hai menzionato. Lo scopo principale di loro è quello di essere in grado di impostare cose come una regola NAT una volta, e non dover mettere nat-to alla fine di un mucchio di regole che hai sul traffico in uscita.

Nel tuo esempio il pacchetto verrà eliminato. Avrei dovuto guardare il codice o chiedere Henning Brauer per essere certi se si salta completamente il controllo NAT nel caso goccia, ma sarebbe non vengo NATted fuori.

Penso che la tua regola sia coperta dal Libro di PF (hai ottenuto la 2a edizione?), Ma non credo che siano espliciti al riguardo con la regola della partita.

Per favore, correggimi se ho sbagliato, vuoi passare tutti i pacchetti in uscita da 10.0.0.0/24 ma vuoi bloccare 10.0.0.23? In tal caso, modifica la regola in:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
block drop out quick on $ext_if from 10.0.0.23
pass out on $ext_if from 10.0.0.0/24

Basta usare quickper impedire al firewall di continuare il filtraggio (simile ad breakalcuni linguaggi di programmazione).

http://www.openbsd.org/faq/pf/filter.html#quick

La parola chiave rapida

Come indicato in precedenza, ciascun pacchetto viene valutato dal set di regole del filtro dall'alto verso il basso. Per impostazione predefinita, il pacchetto è contrassegnato per il passaggio, che può essere modificato da qualsiasi regola e può essere modificato avanti e indietro più volte prima della fine delle regole del filtro. L'ultima regola corrispondente "vince". C'è un'eccezione a ciò: l'opzione rapida su una regola di filtro ha l'effetto di annullare qualsiasi ulteriore elaborazione della regola e fa sì che venga intrapresa l'azione specificata. Diamo un'occhiata a un paio di esempi:

Sbagliato:

block in on fxp0 proto tcp to port ssh
pass  in all 

In questo caso, la linea di blocco può essere valutata, ma non avrà mai alcun effetto, poiché è seguita da una linea che passerà tutto.

Meglio:

block in quick on fxp0 proto tcp to port ssh
pass  in all 

Queste regole vengono valutate in modo leggermente diverso. Se la linea di blocco viene abbinata, a causa dell'opzione rapida, il pacchetto verrà bloccato e il resto del set di regole verrà ignorato.