Let's say it again: Lycos Europe's position is that the cooperative screensaver system monitors the response times of the webservers, endeavouring to throttle the hits sent so as not to shut them down. Not to mention shutting down other, legitimate sites hosted on the same servers.
Here's another example of people fundamentally misunderstanding this attempt: Mr. Kulawiec, like others, doesn't seem to understand what Lycos is trying to do...
From: Rich Kulawiec rsk@...orgThe point is to eat up the bandwidth allowance of spamvertised webservers. This will either quickly shut them down, or cost the spammers a lot of money in additional bandwidth charges. Spammers' websites do not have "an infinite amount of bandwidth". Perhaps you're confusing e-commerce webservers with MTAs?
Date: November 29, 2004 9:56:33 AM EST
Subject: Lycos gets into the denial-of-service attack business
It's hard to know where to even begin trying to explain how terribly misguided this is, so I'll just confine myself to noting that trying to win a bandwidth contest with spammers -- who have an unlimited supply of it at zero cost -- reflects a stunning ignorance of reality.
3 comments:
No, I'm not confused, and yes, they do have (for all practical purposes) an infinite amount of bandwidth.
Let me explain how they've done that.
First, you need to know that over the past two and a half years, spammers have used viruses (SoBig, for example) to hijacked a VERY large number of Windows systems. Estimates vary from 10M to 100M, with something in the middle as a rough consensus.
Second, you need to understand that these systems (called "zombies" in anti-spam parlance) are completely under the control
of their remote attackers, who can download anything they wish into them and run it.
Third, these zombies are prolific spam sources. After all, even a middling PC on a consumer broadband connection can pump out a million messages a day, even without optimization. Do the math.
Fourth, sending spam is NOT all that they do. Some are used to control other zombies; some to probe for open proxies and other security holes; and some -- and here is where we get around to the point -- to host spammer websites.
What they do, you see, is put hundreds or thousands of copies of their websites on the zombies
and then use redirectors to shunt traffic there. They then spam and include in the spam the URL of the redirector. The redirector itself thus handles very little traffic: it's all spun off to the zombies. And yes, some of them will be up, some will be down, some will be busy,
and so on, but that's of little consequence: keep in mind the scale that we're talking about here. (Oh: they'll also use multiple redirectors in case they lose one of those.)
Fifth, and finally: this isn't the end of their tricks. There are others as well that have been discussed in considerable depth on the Spam-L mailing list.
But the bottom line is that spammers have as much free bandwidth as they can steal: trying to go after them by consuming it is like trying to drown the ocean.
---Rsk
Ummm, thanks for the botnet-101 ;-) Yes, I agree with almost all that you say...
While it's very clear that at least half of the SMTP traffic is coming from botnets, it's not anywhere clear to me that botnets are responsible for this much web traffic. Do you have studies that show this?
As far as I can see, the economics of mainstream spam is still that the spammer isn't the same person as the spamvertiser. It's effectively an affiliate or commission relationship. It's always dangerous to generalize, of course ;-)
That's one reason why spamvertisers don't like to use botnets for web serving. Another is (as you rightly say) some will be down or busy. While spam deliverability is a numbers game, any marketer will tell you that it's really important to give a prospective purchaser a good experience if s/he gets as far as clicking through to your site! A Chinese BPH makes much better business sense than a flaky botnet for this.
Anyway, back to MakeLoveNotSpam: of course it's moot now, but the point was to soak up the bandwidth allocation of the spamvertised servers. As you so correctly point out, if the spamvertiser is using a botnet to serve up web pages, the spamvertised URL will belong to a redirector.
If the redirector's bandwidth runs out, it can't redirect traffic to the botnet.
Let me try to answer your points (although not necessarily in order).
- on trying to DoS the redirectors: that's difficult, because the
redirection itself doesn't involve a lot of traffic (compared to, say,
an ordinary web page with its accompanying graphics and so forth).
It's also not a good idea if it's a publicly-available redirection
service being used by lots of other (non-spamming) people. And then
there are further spammer tricks such as rapidly-updating DNS,
Javscript redirection, secondary redirection, and so, all of which
serve both to obfuscate and distribute incoming HTTP requests to their
(co-opted and otherwise) web servers. Some of the methods used are
ingenious and arcane; unraveling them often requires in-depth knowledge
of routing, HTTP, HTML, scripting, DNS, and a few other odd and ends.
This is not at all something that can be reliably done by a program.
- on the less-than-optimal-shopping experience: sure. But keep in
mind: the visitors are people who are trying to patronize spammers.
They may not balk at seeing a HTTP 404 error; they may just hit
"reload" until (thanks to all the tricks above) they get what they
think they want. Oh, it's sad, I know, but it's happens all the time.
See http://news.bbc.co.uk/2/hi/technology/4375601.stm for an indication
of just how many people are willing to purchase spamvertized items.
- on the extent of the use of zombies as web servers: hard to say. We
know it's "big" but really can't be much more precise than that because
of the difficulty of actually measuring it. The only real way to tell
is to look at one's own network and locate incoming HTTP traffic (on
any port: doesn't have to be headed to port 80) that's going to hosts
that aren't supposed to have web servers on them. But any ISP diligent
enough to actually perform this investigation would probably also be
diligent enough to have detected the zombies earlier and "sandboxed"
them until their former owners reclaimed them and locked them down.
However, we do at least know something about the extent of the zombies,
because every time they deliver (or attempt to deliver) spam, they make
themselves known. That's where the 10M-100M range comes from. And
given that some detectors, such as the CBL, have noted 200K-300K new
ones in a single day, I tend to favor the high end of that estimate.
And nothing stops any of those from being turned into a web server
whenever their controllers find it expedient to do so.
- in general: please don't take my opposition to this particular idea
as indicative of support for spam. Quite the contrary: I believe if
you peruse the archives of Spam-L, you'll find that my posture on spam
in general is...well, shall we say, belligerent. It's just that this
simply won't work: it relies very heavily on the naive presumption
that spammers will do nothing by way of countermeasures, and they're
far too clever for that. The most likely outcome is a DoS attack
that ends up hitting an innocent third parties.
This is why one of the mantras of the
anti-spam movement has always been "don't
fight abuse with abuse": even if folks don't agree that it's wrong, it's VERY likely to hit the wrong target -- doubly so because spammers will be aware of it and
take active countermeasures. (And this in
turn is why challenge/response, callback, and other poorly-thought-out schemes are
very bad ideas...but this is long enough.)
---Rsk
Post a Comment