disabling stateful firewalls for DNS traffic

Phil Mayers p.mayers at imperial.ac.uk
Sat Mar 1 15:35:25 UTC 2014

On 01/03/2014 14:30, Chuck Anderson wrote:

> How should these rules be changed to adhere to the Best Practices
> while not breaking anything and still allowing the servers to do their
> own DNS lookups?  I know theoretically how I would do this, but I'm
> looking for others' experiences.

There are probably an arbitrary number of ways to skin this cat.

We ensure the DNS service runs on a separate IP to any other traffic on 
the box. We also ensure that inbound queries hit one IP, outbound go 
from another.

We then have something similar to this:

-A INPUT -d <auth/recursive service ip> -j DNS-QUERY
-A INPUT -d <recursive query-source>    -j DNS-REPLY

-A DNS-QUERY -p udp --dport 53 -j ACCEPT
-A DNS-QUERY -p tcp --dport 53 -j ACCEPT
-A DNS-QUERY -p udp -j DROP
-A DNS-QUERY -p tcp -j DROP

-A DNS-REPLY -p tcp --syn -j DROP
-A DNS-REPLY -p tcp --dport 0:1023 -j DROP
-A DNS-REPLY -p udp --dport 0:1023 -j DROP

The DNS-QUERY chain allows all traffic inbound to port 53 and fragments, 
and denies all other TCP/UDP. It permits all others, which is relatively 
open but you could lock this down to allowing ICMP etc. if you wanted.

The DNS-REPLY chain drops tcp syn and dst port <1024 tcp/udp. It then 
allows all TCP/UDP (including frags), which is needed as bind uses 
random query source ports. You could of course put DROP statements in 
higher up if you know you have non-bind processes listening on high(er) 
ports. Same comment as above for the final ACCEPT.

It should go without saying that -j LOG is an extremely bad idea; if you 
must do this, supplement it with a -m limit which is "light" state, one 
counter/timestamp per rule. Avoid -m hashlimit!

If you can't spare the 2 extra IPs for this, it should be obvious how to 
merge these two rulesets - split off into chains based on dport - but 
the IP separation has other advantages.

These are relatively open rules and in particular they have some weak 
spots around fragmentation attacks, but have a couple of advantages; 
they're completely stateless, easy to understand, and most importantly 
serve as part of a defense-in-depth; we use these rules, tcpwrappers, 
SELinux confinement, bind ACLs and network-level ACLs at our border to 
ensure it's all locked down.

The advice to not statefully process DNS traffic is excellent advice. 
Personal experience is that suddenly being a node which attackers try to 
reflect from can really ruin your day if you're stateful.

More information about the bind-users mailing list