Open DNS Resolver reflection attack Mitigation
Is there any publicly available rate limiting for BIND? How about host-based IDS that can be used to trigger rtbh or iptables? Google and Level3 manage to run open resolvers, why cant I? Joe
On Jun 9, 2012, at 2:09 AM, Joe Maimon wrote:
Google and Level3 manage to run open resolvers, why cant I?
Because they have probably have opsec resources you don't. If you can't defend it/keep it from being abused, don't do it. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
Dobbins, Roland wrote:
On Jun 9, 2012, at 2:09 AM, Joe Maimon wrote:
Google and Level3 manage to run open resolvers, why cant I?
Because they have probably have opsec resources you don't. If you can't defend it/keep it from being abused, don't do it.
;>
I think I will explore my options first. Until then, its whack a mole. Joe
On Fri, Jun 08, 2012 at 03:09:04PM -0400, Joe Maimon <jmaimon@ttec.com> wrote a message of 7 lines which said:
Is there any publicly available rate limiting for BIND?
Not as far as I know. I'm not sure it would be a good idea. BIND is feature-rich enough.
How about host-based IDS that can be used to trigger rtbh or iptables?
What I do (I manage a small and experimental open resolver) is to use iptables this way (porting it to IPv6 is left as an exercice): iptables -A INPUT -p udp --dport 53 -m hashlimit \ --hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \ --hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP So, every prefix (length 28) can send 20 r/s with allowed bursts of 100. This requires a Netfilter >= 1.4 (recent options of module hashlimit). Most iptables recipes that you find on the Web are not well suited to DNS. They use connection tracking, for instance, while, with the DNS, every request/response is a "connection". I have a more complete article on this setup but in french only <http://www.bortzmeyer.org/rate-limiting-dns-open-resolver.html>.
Google and Level3 manage to run open resolvers, why cant I?
You have less money :-)
Stephane Bortzmeyer wrote:
On Fri, Jun 08, 2012 at 03:09:04PM -0400, Joe Maimon<jmaimon@ttec.com> wrote a message of 7 lines which said:
Is there any publicly available rate limiting for BIND?
Not as far as I know. I'm not sure it would be a good idea. BIND is feature-rich enough.
I really hope you have a minority viewpoint on this one. I would really like to see it.
How about host-based IDS that can be used to trigger rtbh or iptables?
What I do (I manage a small and experimental open resolver) is to use iptables this way (porting it to IPv6 is left as an exercice):
iptables -A INPUT -p udp --dport 53 -m hashlimit \ --hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \ --hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP
So, every prefix (length 28) can send 20 r/s with allowed bursts of 100. This requires a Netfilter>= 1.4 (recent options of module hashlimit).
Missing the amplification factor goodness google says they have, but I'll take it. https://developers.google.com/speed/public-dns/docs/security
Most iptables recipes that you find on the Web are not well suited to DNS. They use connection tracking, for instance, while, with the DNS, every request/response is a "connection".
I have a more complete article on this setup but in french only <http://www.bortzmeyer.org/rate-limiting-dns-open-resolver.html>.
This sounds promising. I will give it a spin. Thank you!
Google and Level3 manage to run open resolvers, why cant I?
You have less money :-)
With help like yours, I hope to compensate for that. Joe
On Jun 8, 2012, at 12:26 PM, Stephane Bortzmeyer wrote:
On Fri, Jun 08, 2012 at 03:09:04PM -0400, Joe Maimon <jmaimon@ttec.com> wrote a message of 7 lines which said:
Is there any publicly available rate limiting for BIND?
Not as far as I know. I'm not sure it would be a good idea. BIND is feature-rich enough.
How about host-based IDS that can be used to trigger rtbh or iptables?
What I do (I manage a small and experimental open resolver) is to use iptables this way (porting it to IPv6 is left as an exercice):
iptables -A INPUT -p udp --dport 53 -m hashlimit \ --hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \ --hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP
IPv6 should be a simple matter of putting the same line in your ip6tables file. Owen
On Fri, Jun 08, 2012 at 12:56:23PM -0700, Owen DeLong <owen@delong.com> wrote a message of 28 lines which said:
IPv6 should be a simple matter of putting the same line in your ip6tables file.
My experience with attack mitigation is that tools do not always work as advertised and sometimes do bad things (such as crashing the machine). So, I agree, it "should be a simple matter" but I prefer to test first. [For instance, my IPv4 rule required a maximum of 2^28 buckets in memory while an IPv6 rule with --hashlimit-srcmask 64 would require a maximum of 2^64 buckets... What will be the effect on the system memory?]
On Jun 8, 2012, at 1:11 PM, Stephane Bortzmeyer wrote:
On Fri, Jun 08, 2012 at 12:56:23PM -0700, Owen DeLong <owen@delong.com> wrote a message of 28 lines which said:
IPv6 should be a simple matter of putting the same line in your ip6tables file.
My experience with attack mitigation is that tools do not always work as advertised and sometimes do bad things (such as crashing the machine). So, I agree, it "should be a simple matter" but I prefer to test first.
I'm using a much simpler: -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -m limit --limit 30/minute --limit-burst 90 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -m limit --limit 30/minute --limit-burst 90 -j ACCEPT (v4 and v6 identical rules) and it seems to be working so far. YMMV.
[For instance, my IPv4 rule required a maximum of 2^28 buckets in memory while an IPv6 rule with --hashlimit-srcmask 64 would require a maximum of 2^64 buckets... What will be the effect on the system memory?]
True, but, if you leave 28 in place, it will only require 2^28 buckets for IPv6 as well. You might want to bump up the allowed qps since there can be quite a few more hosts per /28, but, otherwise should still be reasonably feasible. Owen
Joe Maimon <jmaimon@ttec.com> writes:
Is there any publicly available rate limiting for BIND?
How about host-based IDS that can be used to trigger rtbh or iptables?
Google and Level3 manage to run open resolvers, why cant I?
rate limiting on recursive servers is complicated by the lack of caching in most stub resolvers and applications. this makes it hard to tell by pure automation when a request flow is a spoof-source attack and when not. for most of us this isn't a problem since we'll put access control lists on our recursive name servers, only allowing queries from on-campus or on-net. for intentionally open resolvers, i expect there's a lot of monitoring and hand tuning, and that many deliberately low-grade attacks get by. noting that there are at least 15 million open recursive servers (most in low-quality CPE boxes front-ending cable or DSL links), an attacker has a long menu of places to send a small number of queries (to each) so that any rate limiting done by any one of the open recursive servers would not defend any victims against spoofed-source. spoofed-source is becoming wildly more popular. that's probably where to fix this. also the 15 million open recursives would be good to see fixed. at the moment most attacks are using authority servers, where it's far easier to automatically tell attack flows from non-attack flows. -- Paul Vixie KI6YSY
participants (5)
-
Dobbins, Roland -
Joe Maimon -
Owen DeLong -
Paul Vixie -
Stephane Bortzmeyer