DNS Amplification Attacks

Mailman List Mirror (Read Only)
1

In this paper we address in detail how the recent DNS DDoS attacks work.
How they abuse name servers, EDNS, the recursive feature and UDP packet spoofing, as well as how the amplification effect works.

Our study is based on packet captures (we provide with samples) and logs from attacks on different networks reported to have a volume of 2.8Gbps. One of these networks indicated some attacks have reached as high as 10Gbps and used as many as 140,000 exploited name servers.

In the conclusions we also discuss some remediation suggestions.

Given recent events, we have been encouraged to make this text available at this time.

URL: http://www.isotf.org/news/DNS-Amplification-Attacks.pdf

Please note that this version of this paper is prior to submission for publication and that the final version may see significant revisions.

Thanks,

Randy Vaughn and Gadi Evron.

2

That ISPs still do not filter inbound traffic from their customers to prevent source spoofing is amazing.

Done closer to the ingress edge this filtering shouldnt be that expensive. Not everyone will do it, but atleast it will limit the places from where source address spoofing attacks originate.

The administrative burden arguments dont fly - a list of routes and IP address assignments per customer is already maintained both by ISPs and the customers -and route filters access lists are routinely automated.

So beyond laziness - are there any technical reasons why this causes problems for anyone ?

3

That ISPs still do not filter inbound traffic from their customers to
prevent source spoofing is amazing.

Heck, some people still can't get reverse DNS setup correctly for their
IP addresses. And in-addr.arpa has been around for decades.

host 66.201.54.61

Host 61.54.201.66.in-addr.arpa not found: 3(NXDOMAIN)

The problem with relying on address anti-spoofing is it doesn't matter how
many ISPs prevent spoofing because it only requires one opening (plus a
bad guy, plus bad computers, plus uncontrolled reflectors). While
its a good idea to make the spoofing openings as small as possible,
within your own network anti-spoofing is very useful, you also need
other management controls.

This goes beyond an individual protocol such as DNS. You can generate
blowback with many different protocols. Technology can take you only
so far, you also have to address the human element too.

1. Bad guys
2. Compromised computers (a few are really "owned" by the bad guys too)
3. Spoofable source addresses (the bad guys "own" their own ISPs too)
4. Open reflectors without rate limits

4

The fact that there are vendors out there that do not support RPF
filtering is even more amazing.

5

Sean Donelan wrote:

This goes beyond an individual protocol such as DNS. You can generate
blowback with many different protocols. Technology can take you only
so far, you also have to address the human element too.

1. Bad guys
2. Compromised computers (a few are really "owned" by the bad guys too)
3. Spoofable source addresses (the bad guys "own" their own ISPs too)
4. Open reflectors without rate limits

Each of these is a sound suggestion, some are in debate. The main point is though that although spoofing is to blame for this latest attack *vector* and indeed is an hazard on the Internet with many other possible vectors, it is *not* to blame for this attack. _Not_alone_.

Recursion the way it is set now with most DNS implementations, is the problem being exploited by spoofing. It is true spoofing is bad for our health, but that does not mean we should ignore what actually gets exploited, which is recursive name servers open to the world.

Fixing the one does not mean we shouldn't fix the other. Going after recursive servers is whack-a-mole all over again, going after how it all works and set may take a roll-back effect of a few years, but is worth it as a scalable solution.
One possible such solution is turning the default recursion "on" to "off".

As these things take time, starting is a good first step. :slight_smile:

Attacks such as this one have been happening for a long time now, non of us should be surprised. Two new things in the *recent* attacks are:

1. Wide exploitation in the wild, which draws attention.

  After all, until recently most active NANOGers saw no reason to
  even work on fixing spoofing.

2. Abusing EDNS for a larger amplification factor.

  Yes, smaller amplification factors work too and their rates can
  be increased, but if you can send a whole lot more for less,
  it's obviously more dangerous.

  How many pings would you rather get back from a broadcast
  address in a Smurf attack. 30 or 200?

The reason we released the text at this time (before we were ready, we were planning on making it academic-worthy) is that because of the lack of actual data out there and increasing FUD, we were encouraged to do so for the community.

That is why in the paper we cover events that happened to ISP's rather than just theoretical case studies.

  Gadi.

6

Recursion the way it is set now with most DNS implementations, is the
problem being exploited by spoofing. It is true spoofing is bad for our
health, but that does not mean we should ignore what actually gets
exploited, which is recursive name servers open to the world.

Fixing the one does not mean we shouldn't fix the other.

But fixing recursion also fixes the internet (fixes as in how you fix a dog)
in that he who controls the DNS controls the net. Fixing DNS is going to
hand over strict control to governments because now they can prevent you
from resolving anything they don't want you to resolve.

It also severely cuts into redundancy functions on the net.

I realize even if we eliminate spoofing completely, dns can still be used to
flood, but so can any other shared function on the net. We closed relay but
I can still flood you with emails by doing a joe-job is a good example.

At some point we really need to look at this and ask ourselves is it worth
what we must give up in order to eliminate some attack vector and isn't
there a better way that doesn't involve us giving up so much. I think in
this case the answer is maybe there is a better way, eliminate spoofing or
eliminate udp use in recursive dns queries are valid options.

So in answer to the last part of the above quote, maybe we shouldn't fix the
other. (just something to consider)

George Roettger
Netlink Services

7

Geo. wrote:

Recursion the way it is set now with most DNS implementations, is the
problem being exploited by spoofing. It is true spoofing is bad for our
health, but that does not mean we should ignore what actually gets
exploited, which is recursive name servers open to the world.

Fixing the one does not mean we shouldn't fix the other.

But fixing recursion also fixes the internet (fixes as in how you fix a dog)
in that he who controls the DNS controls the net. Fixing DNS is going to
hand over strict control to governments because now they can prevent you
from resolving anything they don't want you to resolve.

Where did that come from? I respect you but please, let's have a technical discussion. This is important enough for us all to avoid the flame-wars for now. Don't move this thread to politics or lunacies.

8

...

Where did that come from? I respect you but please, let's have a
technical discussion. This is important enough for us all to avoid the
flame-wars for now. Don't move this thread to politics or lunacies.

...

Then leave governments out of it, and re-phrase the question in this
way. If one can not run one's own DNS server on the public Internet,
but must rely on a DNS service supplier for your DNS, and at some point
you start to wonder about the technical competence or correct configura-
tion of the DNS service supplier whose DNS you are configured to use,
and all other DNS servers out there are configured to refuse recursive
service except perhaps to their own population, than against what can
you compare the DNS service that you are getting, to see whether it is
giving you what "the world" should be seeing?

9

Attacks such as this one have been happening for a long time now, non of
us should be surprised. Two new things in the *recent* attacks are:

1. Wide exploitation in the wild, which draws attention.

that the press has been told about it this time, is new. the scope of the
attack, either in breadth or intensity, is not new in these recent attacks.

2. Abusing EDNS for a larger amplification factor.

the use of EDNS is not new in these recent attacks, either.

The reason we released the text at this time (before we were ready, we
were planning on making it academic-worthy) is that because of the lack
of actual data out there and increasing FUD, we were encouraged to do so
for the community.

any blame-putting on DNS or EDNS that fails to also mention amplification
that's possible via NTP or the fact that refector attacks based on ICMP are
still common and practical even without smurf amplification, is itself FUD.

That is why in the paper we cover events that happened to ISP's rather
than just theoretical case studies.

in the paper i reviewed, the practical case studies were useful.

10

Joseph S D Yao wrote:

...

Where did that come from? I respect you but please, let's have a technical discussion. This is important enough for us all to avoid the flame-wars for now. Don't move this thread to politics or lunacies.

...

Then leave governments out of it, and re-phrase the question in this
way. If one can not run one's own DNS server on the public Internet,
but must rely on a DNS service supplier for your DNS, and at some point
you start to wonder about the technical competence or correct configura-
tion of the DNS service supplier whose DNS you are configured to use,
and all other DNS servers out there are configured to refuse recursive
service except perhaps to their own population, than against what can
you compare the DNS service that you are getting, to see whether it is
giving you what "the world" should be seeing?

That is exactly what worries me.

In germany censoring is commonplace. You have to use foraign resolvers
to escape it. There is a lot collateral dammage too - governement has
provided the tools. Corrupt people use it to play tricks on their
"friends".

How about alternative roots? ICANN does censor "XN--55QX5D.", "XN--FIQS8S."
and "XN--IO0A7I." already. You must use alternative roots to exchange emails
with people living in those domains.

Banning open resolvers means censoring for a lot of people, at least
if they cannot run their own servers.

Regards
Peter and Karin Dambier

11

Stop with the bull$**+ (self-censored), trying to recast the "censorship"
light on the issue of alternate roots. ICANN is censoring nothing; it's
"alternative" roots that are taking it upon themselves not to go through a
standardization process by creating nonstandard naming trees.

I encourage you to look up the English definition of "censor" sometime.

12

Joseph S D Yao wrote:
[...]

service except perhaps to their own population, than against what can
you compare the DNS service that you are getting, to see whether it is
giving you what "the world" should be seeing?

DNS looking glasses, in much the same way that we use web-form based BGP or traceroute looking glasses today.

13

Yes, I think I wrote one of those. :wink: It would have to become a
common service to allow folks to trust the service [by comparing
outputs].

14

Much of the enterprise market seems wedded to Visio as their network graphics tool, which locks them into Windows. Personally, I hate both little pictures of equipment and Cisco hockey-puck icons; I much prefer things like rectangles saying "7507 STL-1" or "M160 NYC-3".

Assuming you use *NIX platforms (including BSD under Mac OS X), what are your preferred tools for network drawings, both for internal and external use? I'd hate to be driven to Windows only because I need Visio.

15

Much of the enterprise market seems wedded to Visio as their network
graphics tool, which locks them into Windows. Personally, I hate both
little pictures of equipment and Cisco hockey-puck icons; I much
prefer things like rectangles saying "7507 STL-1" or "M160 NYC-3".

Not sure how preferring things like rectangles stops you from using Visio,
but *shrug*

Assuming you use *NIX platforms (including BSD under Mac OS X), what
are your preferred tools for network drawings, both for internal and
external use? I'd hate to be driven to Windows only because I need
Visio.

If you're doing diagrams for internal use and know the chances of them
being used with external parties is slim-to-none, go ahead, play with
toys like dia. Omnigraffle looks hopeful, but haven't personally used.

On the other hand, if you are doing professional business communications
I'd seriously condsider getting vmware and Visio. I might be a little
backward to many here, as I work for a consulting company and 95% of what
we do is client-facing. Maybe, more accurately, if you never expect
anybody other than you to edit your work, Visio's not a necessity.
PDFs are almost 100% acceptable, with a few losers left who won't
install a reader.

Not trying to start a Visio religious war, just saying there's a reason
enterprises use it.

Random thought - think Visio's capabilities are about as underused as
Excel's...

John

16

xfig

emacs artist-mode

randy

17

I use OmniGraffle Pro for OS/X:

http://www.omnigroup.com/applications/omnigraffle/pro/

It can import and export Visio XML format, as well.

18

KDE has a "Visio-like" tool called kivio

It was pretty much useless last I looked, but looks like it has some potential. Think I heard that you would be able to use the visio format at some point too, probably not yet though.
http://www.koffice.org/kivio/

I've used dia a bit, seems reasonable.
http://www.gnome.org/projects/dia/

-Wil

Howard C. Berkowitz wrote:

19

And something I learned only recently -- xfig comes with a large
library of clip art. Here are the categories on my system:

$ ls /usr/pkg/lib/X11/xfig/Libraries/
Arrows Electronic Labels Optics
Audiovisual Examples Logic Origami
Buildings Flags Maps ProcessFlowsheet Charts Flowchart Mechanical_DIN Structural_Analysis
Computers Furniture Miscellaneous UML
DSP GUI Music Welding
ERD Hospital Networks Electrical Knitting OfficeEquip

And if you must, Networks/router3.fig is a hockey puck....

    --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

20

Omnigraffle!

http://www.omnigroup.com/applications/omnigraffle/

                                -Bill