Prevent DNS Amplification attacks [$90 awarded]

[SGrondin]

The DNSChain code right now is not production ready as it can be used for DDOS attacks by the thousands of automated scripts on the internet hunting for badly configured DNS Servers.

DNS lookups need to be throttled on a IP+Domain basis.

--- The **[$90 bounty](https://www.bountysource.com/issues/3216552-prevent-dns-amplification-attacks?utm_campaign=plugin&utm_content=tracker%2F528702&utm_medium=issues&utm_source=github)** on this issue has been claimed at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F528702&utm_medium=issues&utm_source=github).

[SGrondin]

• Throttlers need to be purged after 10 minutes to not leak memory.
• The server needs a list of blacklisted domains (used for amplification). After implementing #34 it'll be possible to reload the list seamlessly.

[taoeffect]

Yeah, one thing that helps mitigate this (current) issue, is combining DNSChain with a resolver like PowerDNS (the most recent version). But certainly DNSChain isn't "production ready" as even signed HTTP responses hasn't been implemented yet. :P

DNS lookups need to be throttled on a IP+Domain basis.

What's the reason for an IP-basis? IPs are untrustworthy... Shouldn't a domain-basis be enough?

Throttlers need to be purged after 10 minutes to not leak memory.

Good suggestion. :)

The server needs a list of blacklisted domains (used for amplification). After implementing #34 it'll be possible to reload the list seamlessly.

I don't like blacklists. They are usually ineffective and just waste developer's time. Good code usually mitigates any need for them. Whitelists, on the other hand, are great, but they're not applicable to what we're doing here.

[SGrondin]

This comes from my experience running the unblock server, it gets a lot of attention from bots.

The point of DNS Amplification attacks is that the IP is the victim and it is reliable because that's the whole point of the attack.

After tweaking my unblock code for weeks, I found that IP-only doesn't work. It's very common for browsers to send "bursts" of requests for dozens of tabs. Especially right after reconnecting to the internet when all the background processes send several requests each.

Domain-only doesn't work. Case in point: google.com, akamaihd.com, etc. Those are requested orders of magnitude more than the others. IP+domain works like a charm.

The blacklist is important and implemented by all the public DNS servers out there for a reason. Attackers set up domains and configure them to make DNS Amplification attacks as powerful as possible. They are not used for anything other than those attacks. Google's 8.8.8.8 is okay at blacklisting them (so forwarding to 8.8.8.8 times out), but it sometimes takes days. I found scripts that will test the attack against themselves to find out exactly how slow they have to go to not be blocked/throttled too much and then use that information to attack as efficiently as possible. The blacklist comes in handy in those cases because simply blocking their domain takes them out for a couple days until they set up another one.

I've been tweaking my code and learning a lot in the last months.

[taoeffect]

OK, thanks for that explanation. It sounds like there might be value in IP+domain (you have me like 95% convinced on that). But for the blacklist, I'm still not convinced it's worth any time.

Here's the other issue: we've both already agreed that it makes more sense to pair DNSChain with a traditional resolver like PowerDNS et. al., and these already have these sorts of mitigations built-in, right? So why should we re-invent the wheel?

Are there DNSChain/unblock-specific DoS attacks that we should be concerned with? If so, let's discuss those.

[SGrondin]

Yes.

• There are requests that hit the Namecoin and Unblock parts of the code, they don't reach PDNS. They can be abused to DoS both any IP and even the DNSChain server itself.
• The throttling settings in PDNS are VERY lackluster.
• It's a lot more efficient to cut it at the DNSChain level instead of having to spend all those CPU cycles to let it go all the way through to PDNS and even to Google's 8.8.8.8 before something at some point maybe decides to block it. It's just not a clean design to me. There's a single clear entry point (port 53, DNSChain) and then data goes in all sorts of different directions. In my opinion, it's better to cut at the source for both design and performance reasons.

[taoeffect]

K, just want to jot some notes down before heading off to sleep:

There are requests that hit the Namecoin and Unblock parts of the code, they don't reach PDNS.

Re Namecoin: that system is non-heirarchical (except for the parts of the spec that tell you to talk to a traditional name server... sigh...), so it makes it less of an attractive target for DoS (there's no amplification aspect).

I'm not sure about the implications of the unblock parts... whether they allow for amplification. Thoughts on that?

The throttling settings in PDNS are very lackluster.

Yes. Tell me about it...

[SGrondin]

Those Namecoin/Unblock can still be used to DDOS some poor dude's server even if they don't amplify. By using a DNSChain server to do the attack, they make it extremely hard to track where the attack is really coming from.

That's not too bad, but it's a single line of code to throttle everything, I don't see any reason not to do it and see plenty of reasons in favor of doing it.

[taoeffect]

That's not too bad, but it's a single line of code to throttle everything, I don't see any reason not to do it and see plenty of reasons in favor of doing it.

If that single line of code doesn't break anything then go for it! :)

I'll check it of course to make sure I don't see any way that it could lead to unnecessary dropped queries.

[SGrondin]

Funny you mention that considering I just updated the README with this section: https://github.com/SGrondin/bottleneck#execution-guarantee

Or did you look at my commit and it made you think of that? :)

[taoeffect]

Or did you look at my commit and it made you think of that? :)

Just a coincidence. :)

[taoeffect]

I just want to wrap my head around the whole situation, how those variables you mention affect queries, what kinds of situations might happen, etc.

[SGrondin]

Let me know if you still have questions after reading the README and I'll here and update it. It's can be a bit difficult to explain how it works in words.

[SGrondin]

I'm working on this.

[SGrondin]

Any update on this?

[taoeffect]

@SGrondin Sorry, vacation took hold, then some fires needed to be put out.

I think this may be a good opportunity for me to add a bloody decent testing framework to DNSChain. There's no really good / proper way to see whether what you did works without one (other than writing some crappy ad-hock scripts, but why would you do that when that is essentially what a testing framework does already..?).

So, I'm currently looking into closing this issue by closing #12 (Add testing suite), and then testing this properly.

[taoeffect]

I've verified via the modular branch (see 0c808bd) that DNS throttling works. I didn't make any tests for HTTP(S) but I figure that probably works too (and if not, easy to fix since bottleneck stuff is working in principle). Closing and will give bounty to @SGrondin.

Fantastic work!