[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-pf
Subject:    Re: PF and NAT order question - 3.0
From:       Daniel Hartmeier <daniel () benzedrine ! cx>
Date:       2002-08-08 17:49:05
[Download RAW message or body]

On 2002-08-08 14:38:12, Steven Cardinal wrote:

> I'm finding that nat rules seem to apply prior to firewall rules, which is
> causing some problems with my desired security stance. Is there a way to
> force the firewall rules to be applied prior to NAT?

No, but read on.

> Let's take internal web surfers - I allow users coming from the internal net
> into int_if on port 80 and keep state
> I then want to allow those same addresses out on ext_if with port 80 and
> keep state.  This doesn't work, because NAT has already re-written the
> address to that of the external interface. So to get it to work, I need to
> allow port 80 out from the external interface address.  I really don't think
> my firewall should be able to surf the web.

Yes, it's not easily possible to distinguish outgoing connections that
originate from the firewall itself and those that are NATed. But
there's very little reason to do that. The firewall is one of the more
trusted hosts on your network, and it shouldn't have any user accounts
besides those needed to maintain the rule set. Hence, as long as it
isn't compromised, the only user opening connections from the firewall
itself is root. If it should ever be compromised, the rule set is
irrelevant anyway, since the intruder can just remove it. And there
are cases where a legitimate root might want to initiate http or ftp
connections from the firewall, for instance to fetch patches etc.

If you have ordinary user accounts on the firewall and services
running on it, you should consider moving those onto a separate
machine instead.

With -current, you can use the 'user/group' parameters to have filter
rules apply only to NATed connections (user unknown) or connections
originating from the firewall (user != unknown).

The reverse case, where you might want to prevent certain local hosts
from connecting out, is of course simpler: you just filter that on the
internal interface. The translation happens before filtering, but
those connections first pass through the internal interface, and
there's no translation on that interface yet.

> Regarding the inbound web to a redirected site, I get the same issue.  If I
> add a rule for safety, blocking inbound to my private addresses, my web
> server becomes inaccessible, because NAT redirected the external address to
> the internal address before the firewall rules. So now it looks like traffic
> to be blocked.

Yes, you have to pass the redirected incoming connection, but you
can restrict it to a single host, as you already do.

The point is that nobody (besides your ISP, maybe) is able to send you
IP packets with destination 10.10.100.100. Only packets with
destination address $ext_if will be routed to you. And even if an
attacker would be able to get a connection to your firewall using the
destination address 10.10.100.100, that's not an issue: he could just
as well use $ext_if.

You can also filter incoming connections from the Internet on the
internal interface, and there you can use the source address to
distinguish between connections from the Internet and the firewall
itself, if you like.

> It also plays havoc with the ftp-proxy stuff, I've had to allow special
> access to lo0 to get that working!

In general, I would always pass traffic on lo0 as you do. DNS
resolution and mail on the firewall itself will break if you block it
completely, and there's no reason to block it from a security point of
view. If you have doubts, run tcpdump on lo0 and see what's going through
there.

There's a couple of odd things in your rule set left, like "from { !a,
!b }" which doesn't have the effect you want (it matches any packet),
and I don't understand the reason for the lass pass rule.

Daniel

[prev in list] [next in list] [prev in thread] [next in thread]