spf-discuss
[Top] [All Lists]

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>