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
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.
;>
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 
Dobbins, Roland 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
Stephane Bortzmeyer 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 DROPSo, 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
IPv6 should be a simple matter of putting the same line in your ip6tables file.
Owen
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?]
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.