[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pf(4) schemantics

On Wed, Mar 19, 2003 at 11:27:26PM +0100, Henning Brauer wrote:
> > 1. What's the reason why packets 'travel' across an interface twice
> > (both in and out)? This makes, IMHO, writing very tight rules a bit
> > tricky. Especially if you want to start off with 'block all'.
> they come in on one interface and eventually go out on an interface. might
> be the same, might be different, depending on routing table and destination.
Well, yeah, they do, but why have pf(4) look at them both on in and out
and on the same interface?
> > 2. Say I 'block all' and then want to pass some traffic from $net_a to
> > $net_b. First, I need 2 rules to allow {in,out} traffic from $net_a and
> > then 2 rules to allow {in,out} traffic back from $net_b. Sure, you can
> > group the {in,out} rules in one, i.e. pass from $net_a to $net_b.
> > 
> > Now, what could be very nice is to pf(4) behave more like the following,
> > 
> > - from pf(4) point of view, there is only inbound traffic from an
> >   interface. I.e. all traffic originating from $net_a towards other
> >   networks is always inbound for pf(4).
> > - when I write a rule like 'pass from $net_a to $net_b', I don't need
> >   to write another rule saying 'pass from $net_b to $net_a'. pf(4) takes
> >   care of that (we are statefull, right?)
> eek?
No clear? Let me rephrase. Why not filter on inbound traffic only, even
though you have 'block all' in your ruleset?
The commerical firewall I was talking about previously is Cisco PIX. It
behaves likes this. Ascii art comming,
net_a ------> pf(4) <------- net_b, and _not_
net_a <-----> pf(4) <-------> net_b
> > - say I have 5 interfaces (or 10 VLANs) I filter on. However, not all of
> >   the networks need to talk to each other. I.e. I could have a $net_c
> >   that will not talk to $net_a, but will talk to $net_b. It could be
> >   nice to be able to define this. Otherwise, the traffic never gets
> >   routed by pf(4).
> what? pf never routes traffic until explicitely told to route via route-to.
> then what you want in these cases with a shitload of (probably
> vlan-)interfaces, is to define the policy on each. wait, ascii art.
Of course, kernel does, pf(4) only looks at the traffic. However, it
might be useful is certain situations. Like, 10 VLAN's, but I only want
to filter on 5. With a rule 'block all', all 10 VLAN traffic would be
blocked, right?
To rephrase, it could be nice if I could define which interfaces pf(4)
should care about. Something like,
set filter interface {vlan01, vlan02, vlan03}
The rest is invisible to pf(4).
>               -----------------------
> ----vlan1----|						|> ----vlan2----|						|> ----vlan3----|						|-----uplink1
> ----vlan4----|						|> ----vlan5----|  OpenBSD             |> ----vlan6----|	 					|> ----vlan7----|						|-----uplink2
> ----vlan8----|						|> ----vlan9----|						|> ----vlan0----|						|> 			  -----------------------
nice art ;)
> hmm, suprise, that looks exactly like my setup ;-)
> so, let's go on. in vlan01, you have just a webserver. the policy is easy:
> pass out on vlan1 proto tcp to $vlan1_webserver port { 80 443 } \
>         keep state
> pass in on vlan1 proto { tcp udp } to $resolvers port 53 \
>         keep state
What's your external inteface (assuming vlan01 is behing a firewall)?
Say it's vlan11. Hence, you need
pass in on vlan11 proto tcp to $vlan1_webserver port { 80 443} \
	keep state
pass out on vlan11 proto tcp to $vlan1_webserver port { 80 443} \
	keep state
and assuming you have 'block all'. Right?
> in vlan02, you have just a smtp server, and apply similar rules.
> on the external interfaces, let's call them dc0 and dc1, you just do spoof
> protection.
> int_nets="{ vlan1-network vlan2-network .. vlan10-network }"
> ext_ifs="{ dc0 dc1 }"
> block on $ext_ifs
> pass on lo0 quick
> block in quick to self
> pass in on $ext_ifs to $int_nets keep state
> pass out on $ext_ifs from $int_nets keep state
> that's it, basically. add some rules to allow some icmp, the box itself to
> reach its resolvers etc, and you are done.
> with hammering the policy for each vlan on the vlan interface, you have
> something very nice achieved. if a box on vlan1 wants to reach a box in
> vlan7, it needs to pass the outgoing policy for vlan1 as well as the
> incoming one for vlan7.
> the only little confusing thing is that all directions are logically
> backwards. passing traffic to a webserver _IN_ results in a rule like "pass
> _OUT_ on vlan1 ..." (emphasis added, of course). but that you get used to
> quickly.
> so, I really don't get what you are proposing.
Well, you managed to confuse me now. Let's throw in some simplified
ascii and sample rules,
$ext_if <-----> pf(4) <----> $int_if
ext_if = "fxp0"
int_if = "fxp1"
ext_net = ""
int_net = ""
webserver = ""
block in all
block out all
## allow traffic on $ext_if to $webserver on 80/tcp and 443/tcp
pass in on $ext_if proto tcp from any to $webserver port {80, 443} \
	keep state
This would not work. Why? We need to pass out on $ext_if as well (since
pf(4) filters on both directions). Not only that, we need to pass in/out
on $int_if as well, since 'block in/out all' applies to all interfaces.
What could be nice is to have this kind of rule working. pf(4) could
allow traffic back from $webserver, even though I have 'block in/out
all'. This is how PIX works.
Am I being a bit more clear now? Or am I _totally_ misunderstanding
pf(4) innerworkings? ;)
// haver