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 -f -j ACCEPT
-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-QUERY -j ACCEPT
-A DNS-REPLY -p tcp --syn -j DROP
-A DNS-REPLY -p tcp --dport 0:1023 -j DROP
-A DNS-REPLY -p tcp -j ACCEPT
-A DNS-REPLY -p udp --dport 0:1023 -j DROP
-A DNS-REPLY -p udp -j ACCEPT
-A DNS-REPLY -j ACCEPT
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.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
