
IT Pro confession: I contributed to the DDOS attack against Spamhaus - esalazar
http://www.theregister.co.uk/2013/03/28/i_accidentally_the_internet/
======
sciurus
"""Let's say that you leave your recursive server open to the internet. Now
not only can you ask your DNS server for information about other DNS servers
on the internet, so can anyone else. If someone asks your server "where is
www.google.com" a whole bunch of times then your server starts flooding
google.com's DNS servers. For every 1 byte of data sent to your DNS server 50
bytes of traffic end up directed at the target."""

This explanation is skipping a key component of a DNS reflection attack. When
the attacker makes a DNS request, they spoof their source address so it is the
address of the host they want to attack. Thus they send a small request to
your DNS server, and your DNS server returns a large response not to them, but
to the host they're attacking.

~~~
bradleyjg
Why does it need to be recursive then?

Couldn't you perform the same attack by querying a whole bunch of
authoritative name servers for zones they serve with forged source addresses?

~~~
entropy_
The attack as specified by the article would be pretty ineffective as
recursive DNS servers tend to have a cache. So only the first request would
hit the target DNS server.

Also, you can definitely do this with authoritative servers only, which is why
only egress filtering by ISPs is a permanent solution to the problem. However,
there are way fewer authoritative DNS servers out there than there are open
recursors and they are better managed. So an attack would never grow to the
scale this one has grown to using only authoritative servers.

~~~
ricardobeat
You got me confused for a minute. So I assume in an actual attack you'll
rotate the domains being requested?

~~~
entropy_
No, the attack does not work by overloading target DNS servers. There is no
benefit in asking a recursive DNS server to make a DNS request for you to
overload another DNS server, you could just make that request yourself(or with
whatever botnet you're using).

The attack works by sending a recursive DNS server a request with a spoofed
source IP. Namely, you make the recursive DNS server think your target is
making the request. While a typical DNS query consists of a 64byte UDP packet,
a reply can be much much lengthier(it can go well over 1KB).

So say you have a botnet with a total bandwidth of 1Gb/s. Each request you
make(64bytes) will result in, say, 1KB being sent by the DNS server to your
target although the server thinks it is sending it to you. That results in a
16x amplification of the amount of data you are sending the target's way. So
instead of flooding your target with 1Gb/s of data, you are flooding it with
16Gb/s of DNS replies.

The only permanent solution to this problem(though it is discussed elsewhere
in this thread why this is impractical) is for all(or almost all) ISPs to have
egress filtering. That is, that they would drop all packets sent from their
networks with a source IP that is not on their networks. This would make it
impossible to fool a recursive DNS server into sending the reply to the wrong
IP.

Since this is very hard to do(ISPs have zero incentive to do egress filtering,
and we can't even locate the ones from whose networks these attacks are
originating to shame them into doing it) the pursued solution is the easier
one of locating and closing publicly open DNS recursors. This would still
allow DNS amplification attacks using authoritative servers, but they would be
much more limited in scope.

~~~
bradleyjg
Thanks for the great explanation.

So if I understand correctly, the problems with the DNS amplification attack
using only authoritative nameservers are:

a) You have to keep track of which name to request from which server

b) You can't optimize for a particularly large response

c) Operators of authoritative name servers are likely to be more sophisticated
and therefore have egress filtering.

d) There aren't as many authoritative nameservers as open recursive servers
(?)

~~~
entropy_
All points correct except c). Egress filtering happens on the ISP side,
there's nothing the DNS server can do once it gets a request with a spoofed
source IP.

But since operators of authoritative name servers are more likely to be
sophisticated they could notice an ongoing attack and throttle down the
replies without negatively affect anything else. In fact, that protection
could be built into the server code. Simply throttle consecutive replies to
the same requester to a sane amount. There is no legitimate use-case where the
same person would make a humongous amount of consecutive requests from an
authoritative server as responses are usually cached. If that's done, an
attacker wouldn't be able to coerce authoritative servers into flooding a
target, they would just send replies at a slow rate(after an initial speedy
response) and no significant amplification would occur.

As you state in d) there are a lot of open recursive servers out there that
are unlikely to be updated or managed by someone sophisticated enough to
respond to attacks like this. Whereas this is less likely with authoritative
servers.

------
brokentone
The post slug is the best part of this article by far:
"i_accidentally_the_internet" Full current URL in case it gets updated:
[http://www.theregister.co.uk/2013/03/28/i_accidentally_the_i...](http://www.theregister.co.uk/2013/03/28/i_accidentally_the_internet/)

~~~
alxndr
You'll like the opening image in this, then; #10 on HN home page right now:
[http://blog.tinfoilsecurity.com/building-a-browser-
extension...](http://blog.tinfoilsecurity.com/building-a-browser-extension-be-
careful-not-t-17787)

~~~
brokentone
I'm familiar with the meme. The humor isn't in the meme, but in the usage by a
professional journalism establishment that is unrelated to the title of the
piece.

~~~
alxndr
Right.

------
laumars
I have a couple of name servers I've inherited since starting my job. How
would I go about testing these servers to see if they're set up correctly
(obviously I'm not interested in the forged UDP packets side of things, only
testing to make sure that recursive look ups are disabled).

~~~
jethro_tell
you could do an nslookup google.com <your.name.server.ip> from off network, or
check your blocks on <http://openresolverproject.org/>

------
mindstab
Whats a simple way to confirm by test your DNS server isn't doing recursion?

~~~
rhizome
A little Googling can often help:

[http://dnsknowledge.com/bind/howto-test-bind-open-
recursive-...](http://dnsknowledge.com/bind/howto-test-bind-open-recursive-
dns-queries/)

~~~
mindstab
fantastic, thanks!

------
metalruler
I don't understand why it's _necessary_ for the server to be open, and have
recursion enabled. I run a couple of authoritative name servers and have seen
them used for amplification attacks. Sure, it's not as easy as querying every
open recursive DNS server you can find for
<single_domain_with_huge_sized_reply>.com, but there's still (literally)
billions of unique hostnames on the internet which can be resolved
"legitimately" via their authoritative name servers. There is no magical
config option to prevent this; the only way to block this type of activity is
to analyze traffic to find IPs that are repeatedly sending the same [spoofed]
request.

------
unethical_ban
Some have suggested that DNS move to TCP, but I don't think that's proper. The
nature of DNS lends itself to connectionless, lightweight communication. That
said, could the next iteration of DNS implement application-level handshaking?

The reason not to do this at layer 4 is because I, in the several minutes of
pondering it, think it could break lots of security devices that track
connection state across lots of computers in a network. Make some kind of

    
    
      C -> S request  
      C <- S ack 
      C -> S yes  
      C <- S lots of data  
      done
    
      C -> S request  
      C <- S ack
      C -> S no  
      done

~~~
drdaeman
Unfortunately, round-trip time is still important, too. I suspect, almost
doubling the DNS request time may cause problems in some cases.

------
ajross
This really is a real issue. My home machine was an open recursor for a while
too. I set up a dnsmasq installation and forgot to set an "except-interface"
to restrict it to the internal network.

I even like to think I know this stuff well, but still got burned. I'm sure at
the time my security analysis (if I even thought of the externally-facing
issue) was "who cares if I expose a caching nameserver with no sensitive
content to the rest of the internet?".

------
SageRaven
How disappointing. I thought it was going to be the story of a fed-up email
admin breaking down and DoS'ing one of the scourges of the internet.

Blacklists are pure evil, and nothing will ever change my opinion of that.
They cause far more problems than they solve. Granted, it's usually by idiot,
over-zealous mail admins who block on merely being listed anywhere, rather
than by weighted score.

~~~
dne
Blacklists are the only reason e-mail is still usable.

~~~
SageRaven
I thought it was statistical filtering and crowd-sourced spam tagging (like
Google's spam filter). I maintain a mail server for a client and Spam Assassin
(edit: and greylisting) works well enough without blacklists enabled. Throw in
a couple of extra Bayesian filters via procmail, and you're doing about as
well as Google does.

~~~
danielweber
Greylists are murder on businesses that depend on receiving mail from new
people.

I see SpamHaus as akin to a the Microsoft monopoly in the 90's. If your
interests are aligned with them, great. And for most people they do a great
job. But there a lots of small businesses who get caught up and nearly
crushed. Because a listing on a blacklist can be murder for a business that
depends on communicating with people over email.

~~~
ios84dev
Why are graylists that horrible? All it does is require the sending server to
retry 5 minutes later; I don't see how that would have any impact on a
business unless they are in the habit of being on the phone with new customers
and asking them to send an email at the same time.

~~~
danielweber
Assuming the sending server does that. Maybe it takes a few hours. Maybe it
doesn't. Small businesses can be a mess, and you can't say "well, your
customers suck" when the client complains about how greylisting is working for
him.

------
sunyc
one of my server got exposed too, it was being queried for ripe.net

