Re: Re: DNS load research
2005-03-23 14:27:23
Radu Hociung wrote:
Scott Kitterman wrote:
Scott Kitterman wrote:
:) Oh, it will survive and get stronger. but in the meanwhile I
think it
will experience 'the plague'. I don't wish to imply that SPF is a
plague, far from it, it's very useful, but it does have some serious
problem that most people are happy to overlook, in the hopes that when
we have to deal with them. Hope is not a method! ;)
Or perhaps not overlook, but came to a different conclusion
than you. DNS
load, DDoS, and security have been regular topics of discussion
for the year
I've been on this list. I think it's something we need to
watch, but not
the potential disaster that you forsee.
I'm sure the problem is my twisted sense of logic ;)
Why don't you Scott, explain to us the worst possible scenario that
_you_ can imagine for a virus that wants to do the most damage to the
Internet by using SPF.
I said "damage to the Internet" on purpose, because the DNS is the
mission-critical Internet protocol without which the 'Net' would just be
a bunch of computers tied together with a wire. But perhaps I'm wrong
about this too.
Thanks.
Is DNS potentially subject to DDoS? Yes.
If someone wanted to write a virus that queried DNS for a large number
queries and they wanted to make it look like it was SPF that was doing
it,
they could. No mail need be involved, just lots of queries from various
compromised machines.
Simple enough...
Get a spammer list of e-mail addresses and then have your virus start
querying DNS for TXT, MX, A, and PTR records from the domains on the
list.
Come up with the virus writer's trick of the day to get it to spread and
things could get ugly.
That's really all it would take if deployed on enough machines.
Now, except for TXT being on the list, what does this have to do with
SPF?
Not much.
One virus infected (say it is in Russia) machine connects to ohmi.org.
It sends the the following 60-byte packet to port 25 at ohmi.org, and
goes on to the next target, without waiting for a response, or closing
the connection.
The packet reads:
"ehlo u
mail from: <a(_at_)kitterman(_dot_)com>
rcpt to: <radu(_at_)ohmi(_dot_)org>"
Your record cost 18 queries till yesterday when megapath saw a flicker
of light and made their record better). Let's work with that.
So since kitterman.com may be on my whitelist, as a host I have seen
before, ohmi.org will proceed to check it's SPF record. Out go 18 UDP
packets, maybe 100 bytes each. The hosts named in your record each
respond to the 18 queries with 18 packets, say also 100 bytes each.
So with an effort of only 60 bytes, the virus sucked 1800 bytes of my
bandwidth, and 1800 bytes of various hosts that you name in your record.
Bandwidth amplification factor: 60X
If the SPF checker is serializing DNS queries (which is more bandwidth
efficient than parallel querying), and each round trip takes 200ms
because the the net is pretty congested by now, that is works out to 3.6
seconds that my mailer will not be available to deal with real mail.
Perhaps it took the virus 50ms to establish a connection with ohmi.org
and send the 60 bytes.
Time amplification factor: 72X
And I will spell this out for you: if the company that employs our
click-happy employee has half decent connectivity, that virus can do
this to 72 domains in the time it takes ohmi.org to cope with one.
So, during the 3.6 seconds, 1 copy of the virus will generate 72x60x(the
bandwith it uses) in traffic to DNS servers around the world.
A virus with a 1-mbit/s link will thus cause 4.320-Gbit/s aggregate DNS
traffic around the world.
And SPF is what made it all possible, because it made it possible for my
server, ohmi.org, programmatically execute a pattern of traffic that you
specified with your SPF record (call it a script if you wish, because
that's what it is).
The beauty of it is that the 4Gb link is distributed around the world,
it is bandwith needed between ohmi.org and the virus.
Let me go a little futher:
Since megapathdsl will answer 11 of the 18 queries your record
prescribes, they will see 11/18 of this 4.320 Gbit/s traffic. Do they by
any chance dedicate 2.64Gbits/s for every running instance of this virus ?
And this is just the attack mechanism, the spreading mechanism (actually
getting the mail spread) is going to take more bandwith yet. But the
virus will use the company's MTA for that. As that MTA tries to deliver
the virus, it will cause even more DNS damage.
Radu.
I forgot one thing:
After a few minutes of thinking how to fix this, admins figure out that
by setting their servers to not respond to TXT queries makes the problem
go away in seconds. UDP queries are not long lived, so if all TXT
records disapeared at the same time, it would take only a few seconds
for the storm to go away.
In other words, take SPF away, and the internet is back on its feet.
So how do you explain that SPF is not do blame?
Radu.
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: Re: DNS load research, (continued)
- Re: Re: DNS load research, Radu Hociung
- RE: Re: DNS load research, Scott Kitterman
- Re: Re: DNS load research, Radu Hociung
- Re: Re: DNS load research,
Radu Hociung <=
- Re: Re: DNS load research, Andy Bakun
- Re: Re: DNS load research, Radu Hociung
- RE: Re: DNS load research, Guy
- Re: Re: DNS load research, Radu Hociung
- Re: Re: DNS load research, Andy Bakun
- Re: Re: DNS load research, Radu Hociung
- Re: Re: DNS load research, David MacQuigg
- DNS Query Format, David MacQuigg
- query format, load, and stunt servers, oh my, Andy Bakun
- New draft (was: query format, load, and stunt servers, oh my), Frank Ellermann
|
|
|