
Deep Inside a DNS Amplification DDoS Attack - jasoncartwright
http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack
======
tptacek
While it's not the most compelling of the arguments against DNSSEC (which is
an ineffective and unnecessary complication of the Internet core protocols),
amplification has been the case Daniel J. Bernstein has been making against it
for years. Here's a good intro:

<http://dnscurve.org/amplification.html>

~~~
mike-cardwell
It's not a very compelling argument against DNSSEC no. The solution is for the
World to close down open DNS servers in the same way it did with open SMTP
servers. Granted, it was a lot easier to do with SMTP.

~~~
tptacek
Or, we could simply not do DNSSEC. DNSSEC + many tens of millions of dollars
of open redirector cleanup work is not an inherently better solution than
simply not doing DNSSEC.

~~~
peterwwillis
This seems like a stupid solution. Did they fix the FTP bounce attack by
disabling all PORT commands forever? No. They disabled PORT being used for any
host except the originator. Similarly, they could compromise here by only
enabling DNSSEC for authorized clients, and keep the rest of the DNS records
open for the world the way they work now.

This of course does nothing to fix the pink elephant of protocols that rely on
a source address in a UDP packet to shovel off data without any limits. DNSSEC
is just one single feature that can be abused; i'm sure there are many more
available in other protocols, and more yet to be invented.

~~~
tptacek
It would be a stupid solution if DNSSEC had some vital role to play in
Internet security. But it clearly doesn't, as evidenced by the fact that
virtually all high-volume commercial transactions conducted in the
industrialized world in 2012 hit the Internet, and none of it is protected by
DNSSEC.

If I had to draw a pie chart explaining the rationale behind deploying DNSSEC,
a 1/3 slice of that pie would be labeled "IETF's misguided effort to replace
the broken TLS CA PKI with yet another PKI controlled largely by the same
giant businesses", and the remaining 2/3 slice would be labeled "Self-
perpetuating fallacy that DNS must be SEC'd the way IP was (unsuccessfully)
SEC'd", or, less charitably, "Windmill tilting exercise on the part of
standards bodies".

~~~
peterwwillis
I don't care about DNSSEC. I just think it's ridiculous to ignore the real
flaw, which is that you can bounce DNS packets at anyone you want.

If you want to strip away part of the protocol to fix an attack vector, why
not just redact EDNS0? Or do what networks around the world already do and
block all port 53 udp packets bigger than 512 bytes. We'll continue to have a
size-limited and somewhat inflexible protocol, but at least DNS amplification
will have an upper bound.

~~~
tptacek
You can't just wave a magic wand and make it so attackers can't bounce DNS
packets, and so it actually does matter than one DNS feature makes those
bounced packets much much larger than any other DNS feature.

~~~
peterwwillis
You can keep DNSSEC and prevent amplification attacks by either limiting the
requests to authorized clients or requiring DNSSEC records use only TCP
connections. But you don't accept this solution because you hate DNSSEC and
you prefer to kill the feature and save the headache.

I get that. Hell, you're probably right that the cost of supporting DNSSEC
isn't worth its benefits in the long run. It's still a crappy argument and a
crappy way to deal with a long-standing security problem.

If you want to prevent all future UDP DNS amplification attacks you must
require all UDP DNS packets be no more than a specific number of bytes (for
example, 512, the pre-EDNS0 size). This would fix the root problem forever.
All feature extensions can simply require the use of TCP.

I get that there's a large cost involved with every solution _except_ for
forcing everyone to abandon DNSSEC. I don't think forcing everyone to abandon
DNSSEC is a realistic goal at this point. Instead, I recommend fixing the root
problem for all future cases. Everyone can continue to not use DNSSEC, and DNS
will never be able to be used in an amplification attack past what was already
possible before DNSSEC.

~~~
tptacek
So I mostly agree with this comment (note the thing I said at the top of this
thread: not the best argument against DNSSEC). The only thing I disagree with
is that "forcing everyone to abandon DNSSEC" is unrealistic. Actually, DNSSEC
hasn't been adopted yet. It has seen virtually no uptake in the ~decade since
its current incarnation was put forward, and it has not seen a sharp uptake in
interest after the "sign the TLDs" hurdle was crossed either. The reality is
that lots of security standards put forth by the IETF don't go on to take over
the Internet; for instance, your Google Mail connection is protected by
SSL/TLS, not IPSEC.

------
donavanm
A bit disappointed that the truncate bit wasn't mentioned. So, for the open
resolver owners playing along at home: Instead of dropping suspect requests
send the truncate bit back. There's no byte amplification in the response,
which defeats the attacks raison d'etre.

By dropping the incoming packets you're punishing well behaved resolvers.
They're going to take a 2-500ms latency hit before retrying another resolver
or over tcp. A well behaved resolver will respond to a truncate by sending the
same query over tcp. That's only a latency hit of the rtt.

The tcp connection also effectively authenticates control of that source ip
address. Now add that src ip to your whitelist of known good resolvers.

Attacker mitigated, other customers not impacted.

~~~
gridspy
Bear in mind that none of these DNS queries are ever sent out of CloudFlare's
network - as mentioned in the previous blog entry, none of these incoming
responses are valid.

See <http://blog.cloudflare.com/65gbps-ddos-no-problem>

" What's great is that we can safely respond and ask them to block all DNS
requests originating from our network since our IPs should never originate a
DNS request to a resolver. "

~~~
donavanm
Please to be rereading my comment. It's addressed to anyone running a
resolver/authoritative name server, not the attack target. I promise I'm well
acquainted with spoofed DNS attacks.

------
agwa
I was curious how operators of public DNS resolvers, such as Google, prevent
themselves from becoming unwitting aids to DNS Amplification attacks. I found
this info about Google's resolver:

<https://developers.google.com/speed/public-dns/docs/security>

The tl;dr is rate limiting, plus some other techniques like adaptively
restricting the ratio of request size to response size.

------
otterley
In addition, it's network engineers' responsibility to prevent source address
spoofing by dropping all outgoing packets having a source address that's not
on a connected subnet.

~~~
aidenn0
I have wondered about this; does anyone who knows more about networks than me
know why source-address spoofing is still alive and well when it was a known
issue at least as far back as the late '90s (when I first learned about smurf
attacks).

In particular since most DDoS attacks originate from botnets, simply egress
filtering at the ISP level should be sufficient.

~~~
grandinj
Laziness on the part of the network operators.

Seriously, they're just too lazy to auto-generate firewall rules from their
list of assigned addresses.

~~~
UnoriginalGuy
I would argue Hanlon's razor applies here.

I think vendors also have some responsibility. The defaults are bad and the
vendors make their devices hard to manage on purpose (for lock-in reasons).
I'm looking at Cisco in particular.

------
latchkey
Why doesn't BIND disable/block open recursion by default? It should be a
configuration option that you have to turn on and should spit out warning
messages in the logs.

------
follower
I encountered a DNS Amplification attack recently and was confused how the VM
I was using could be involved given it wasn't running BIND.

It turned out that a VPN was implemented using `dnsmasq` which was responding
to the DNS queries.

I ended up using firewall rules to drop the queries because it seems like in
certain situations it's not enough to just configure `dnsmasq` to not respond
to the requests: [http://people.canonical.com/~ubuntu-
security/cve/2012/CVE-20...](http://people.canonical.com/~ubuntu-
security/cve/2012/CVE-2012-3411.html)

Just incase the information is useful to anyone else. :)

(I Am Not A Network Engineer.)

------
joe_bleau
My little personal VPS (non-recursive!) DNS server has been asked to
participate in one of these DDoS attacks before; the incoming requests for
isc.org tipped me off. I guess they didn't notice that my server wasn't
sending replies.

