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