disabling stateful firewalls for DNS traffic

[Lawrence K. Chen, P.Eng.]

This is March, right?

I probably should've tried this on one DNS server, instead of all of
them.  I removed state tracking on outbound to port 53 traffic....and
nothing could be resolved.

And, couldn't fix without manual intervention, as cfagent (cfengine)
couldn't resolve its policy server....

And, as soon as I fixed one system....I started getting the flood of
pages from our nagios :)

Hmmm, I guess in order to have no state tracking on outbound...I would
need to open the inbound wide, because it can't use state tracking to
decide if something coming back to a random port is supposed to be
coming back....

I guess I was kind of hoping that this might be the answer on why two of
my resolvers get inconsistent results on reply size testing.

It either says somewhere around 3830+/-10 or it'll say only 1086
bytes.....run a watch on the command every 61 seconds....

Its probably something else that causing the issue...the main obvious
difference is that these two servers are behind our F5.

On 03/01/14 08:30, Chuck Anderson wrote:
> In the following two Best Practices documents, it is recommended to
> disable stateful firewalls for DNS traffic (outbound on recursive
> servers, and inbound on authoritative servers).  Can people share
> their Linux iptables configurations for how they have accomplished
> this?
> 
> https://deepthought.isc.org/article/AA-00874/0/Best-Practices-for-those-running-Recursive-Servers.html
> 
>     "Disable the use of stateful firewalls/packet filters on your
>     servers for outbound query traffic (iterative queries made by a
>     recursive server to authoritative Internet servers).
>     Administrators often consider the impact of stateful firewalls and
>     load balancers on inbound client queries, but then fail to
>     consider their impact on resolver query traffic."
> 
> https://deepthought.isc.org/article/AA-00892/0/Best-Practices-for-those-running-Authoritative-Servers.html
> 
>     "In most instances we would not recommend the use of inbound
>     packet filtering for authoritative nameservers, Response Rate
>     Limiting is the recommended solution.  However there are some
>     circumstances where filtering at very high inbound packet rates
>     can be helpful - please contact ISC if you think you might benefit
>     from our operational experience in this area.
> 
> The typical vendor defaults I've seen don't follow this advice.  For
> example, on Red Hat-like servers, stateful rules like the following
> are often implemented with rules added to non-open recursive servers
> to allow only your internal network to connect to port 53:
> 
> *filter
> :INPUT DROP
> :FORWARD DROP
> :OUTPUT ACCEPT
> -A INPUT -i lo -j ACCEPT
> -A INPUT -m icmp -p icmp --icmp-type any -j ACCEPT
> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -s $INTERNALNET -j ACCEPT
> -A INPUT -m state --state NEW -m udp -p udp --dport 53 -s $INTERNALNET -j ACCEPT
> -A INPUT -j LOG
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
> -A FORWARD -j LOG
> COMMIT
> 
> and for authoritative-only servers allowing any sources to connect to
> port 53:
> 
> *filter
> :INPUT DROP
> :FORWARD DROP
> :OUTPUT ACCEPT
> -A INPUT -i lo -j ACCEPT
> -A INPUT -m icmp -p icmp --icmp-type any -j ACCEPT
> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
> -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
> -A INPUT -j LOG
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
> -A FORWARD -j LOG
> COMMIT
> 
> 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.
> 
> Thanks.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally