"Microsoft closed the account immediately, without investigating."
They should look at aa105966 AT hotmail.com. While closing it would be appropriate that's too friendly. They should empty the mailbox, divert all future email away from it (it will be coming from newly-detected open relays - that's what the mailbox is for), and learn as much as they can about the IP address used to access the email.
At least it was so used on Tuesday.
The internet could be far more spammer unfriendly with very little more effort - and after all these years of spammer abuse wouldn't it be fun to make them hurt?
Love the way you think, but don't forget the incoming traffic. If it's a DHCP-controlled system (as far as its IP address is converned) change the IP address and assign the old address to a full honeypot - so all the incoming commands can be caught and analyzed. If the zombie works by receiving instructions and then following them simply changing the IP ends the abuse for now, but the system is, of course, still potentially abusable. To cure that your idea works.
It's not going to be necessary to do such things millions of times. The effect is to remove the availability of abusable systems to the spammers and such removal means they have to give up long before they try it millions of times - on that ISP. Get just one ISP doing the smarter things (and telling about it) and very quickly a change will occur - a change for the better.
Put "defeat the spammers" at the top of the list of objectives, not "secure the systems." That's how to win.
"It isn't an unreasonable expectation that a machine connecting to a public network shouldn't have gaping security gaps. In fact, IMO, it is a public duty that it should not."
Is it an unreasonable expectation that the operators of public networks, knowing how vulnerable "some" operating systems are, would block all incoming traffic that can be identified as being intended to exploit such vulnerabilities? What's the big urge to allow abuse traffic in to a network?
It is, it isn't (unreasonable) - I don't choose to argue. But all that traffic that is meant to enable or cause abuse or to discover vulnerable systems is not valid internet traffic, it's abuse traffic. Ignoring the abusive nature of the traffic hasn't worked with any sterling results - why not try not ignoring it for a while and see if that's better?
Here's a fact: the email address gazeta91 AT gazeta.pl is used to receive abuse traffic (specifically, test messages sent to see if systems are open relays.) The messages seem all to originate in Phoenix, from Level 3 dialups (Level 3 is an ISP.) This is information about abuse traffic and I can report it because somebody is taking the trouble to trap the abuse. As such messages have, for many months, come from Level 3 dialups in Phoenix it seems the perpetrator may just be somebody in Phoenix (he could be somebody who is skilled at finding abusable systems in the dialup space of Level 3 in Phoenix.) So, if the issue is open relays, another 5 years could be sent chanting "secure the open relays" or evidence such as this could be gathered and used to find and stop the abusers. Which looks better to you?
(fernandomori AT hanmail.net receives such test messages, too.)
(salesc00 AT sales-control.org? Yep, the same.) Look up sales-control.org and you see the name service is from hostwithsimon.com. Might even have a valid name, addresss, and telephone number - in Daytona Beach. I'm suspicious right away. You?
Technical means. Use technical means. USE technical means.
(Thanks to an anonymous person who doesn't even know I'm using some of his honeypot data in Slashdot.)
Go back to February, 1999 and read RFC 2505. See what it says about how securing open relays will work to end spam (it's the RFC that says to secure open relays.)
There are the open relays and there are the ones who abuse them. The ones who abuse them are the spammers, are the criminals. Doncha think maybe a teeny bit of attention might be paid to the criminals? Securing the open relays hasn't ended spam, not since 1999. It's not a means for ending spam. Whacking spammers, on the other hand, has strengths in the "ending spam" category. Bend the effort a little more toward whacking the spammers. In 1999, 2000, it was extremely easy to whack spammes right and left by operting a fake open relay - but few did.
If, someday, you really wish to see spam ended perhaps you'll think about how to hit the spammers and stop trying to blame other victims. Whatever else comes from blaming other victims, it's not productive, not doing much at all to end spam.
If you're already primed to respond with a "oooh, you're a spanked open relay operator" be aware that I have a rude, scornful reply in mind for you. No, I'm not. I'm a person who has bothered to think about spam and open relays and who understands better what to do (unlike, confound it, ASTA.) If ASTA would do MINIMAL research and READ RFC 2505 they might GET A CLUE about how and why securing systems is not a solution. If this is their technical approach to ending spam 5 years after RFC 2505 they are below pathetic - and that's being polite. If you are going to use technical means against spammers then USE TECHNICAL MEANS AGAINST SPAMMERS. Blocking ISPs who might have zombie systems isn't a solution to spam, isn't an action taken against spammers. Contact the ISP, tell them to find out where the abuse originates, and then themselves contact the ISP where it does originate (it could be coming from an open proxy, or even a zombie.) What in tarnation do people think "technical means" are? spam pervades the internet. Does it not seem barely possible that if ISPS would actually LOOK at the traffic they could SEE the abuse?
If Delgado has scared you off (and you're an ISP) ask your freaking lawyer. There are exemptions that allow monitoring traffic and spam traffic being sent by theft of your or your customers' services isn't "communication." It's THEFT.
"You can't get a linux box to respond in the same way as a windows box without seriously getting into the kernel though."
It's a blasted worm. Only if very sophisticated would a worm look for an authentic Windows environment. Why would they bother?
I'm far more familiar with honey pot definition 2 - and I know how incredibly stupid spammers have long been when it comes to open relay honeypots. They are doing bulk abuse, not pinpoint abuse. Whatever the details they are looking for a vulnerability - and then exploit that vulnerability when they find it. They look for hundreds or thousands of vulnerable systems. They do that "quick and dirty" - that's all they've had to do (almost no complex countermeasures are employed against them.) That has worked for them. Why should they make it more complicated?
It's not guaranteed that the woms are so primitive that they don't verify that a system is a Windows system - but it's not guaranteed the worms do. Wouldn't it be better to set up the Linux systems and see if they succeed or are discovered as fakes? That has some chance of success. Arm's-length philosophical discussions won't stop any abuse.
My experience with open relay honeypots suggests that all the spammers do to check for those is attempt to relay. I can see reason for the abusers to be more careful and more clever - but rather than assume they are the better idea is to force them into being more careful and more clever. Burn up more of their time, confuse them about the rest of the internet (the part they abuse, as opposed to their own part.) There are many goals in fighting abuse - don't fixate on just one. If the abusers can be made thoroughly confused about the rest of the internet (i.e., can't tell what is and what isn't vulnerable to abuse) then they pretty much have to give up. That will never happen if all that is done is engage in discussions.
OK, do fixate - it's you time - who am I to tell you what to do? But give some thought to how much better it is to make a broader attack, if you will, please.
P.S. Open relay honeypots still work today, April 23, 2004. Open proxy honeypots may be even more powerful.
Why would they? He keeps them in business. Anti-spam is big money. Without spammers, they're out of a job.
There's a large number of anti-spammers who do everything for free, as volunteers. Steve Linford is a prime example. "Giblet, USA resident" is another.
Here's another real question: is p2p inherently copyright violation?
My answer is: "no."
You are on the mark when it comes to the nature of copyright and the reasons for it. Surely this is an old debate. First there were audio tape recorders, then video recorders, now CDR and DVD-R writers - plus p2p. No doubt attempts were made to hobble each of those other technologies - but obviously the attempts weren't fully successful. The network started out p2p - and still retains many of the p2p features and programs (ftp, for one.) There are all sorts of technologies that can be misused - and are. Stomping on a technology because it is misused by some is not a good approach.
Still, what you say about copyright needs to be remembered. Even in this day of instant perfect digital duplication there are rights to original material and intellectual property and the proper course is to respect those rights. Making a copy of any copyrighted work and sending it to anyone else is illicit publishing of the work. The owner of the copyright, even if it is a big, nasty corporation (and such exist) has the right to stop that activity and to seek redress against those who do it. Whether they do or not, whether they win or not, if they started out as a big nasty corporation they remain one - but they also still have the right to restrict copies of the works they control. Nice guys with copyrights also have exactly the same rights, of course - and remain nice guys (I hope) if they take action against those who steal from them.
Kraewetz also wrote an article on anti-honeypot technology for IEEE Security & Privacy (pp 76-79, January-February 2004 issue.) He seems to asume (like too many) that the spamemrs are near God-like in their abilities. He also seems not to have ever run an anti-spam honeypot. If he had he might have, many times, seen spammers behaving in an incredibly stupid manner. The spammers aren't all that sharp and honeypots (at least now) don't have to be very sophisticated.
His survey article (the topic of this Slashdot thread) once again continues the misconception that anti-spam tools all must be at or after the destination server. Let's look at it this way: the spammers quickly figured out (4-5 years ago) that going direct from their server to the destination wasn't working for them, so they went to intermediate severs, starting with open relays. Anti-spammers are still stuck on their servers - if it isn't the final server it doesn't exist (to their closed minds.) The open relay layer is just as available to the anti-spammers as it is to the spammers, but the anti-spammers mostly refuse to go there. Actually the layer is more available to the anti-spammers: any system with no real email function could serve as an open relay honeypot. You don't need to filter or be smart at all with an open relay honeypot: the spammers do all the work for you. They find the honeypot, they think it's an open relay (the honeypot dutifully does deliver the spammers' test messages), they send the spam, you just sit and watch. For open proxies (another layer dominated by spammers) that's even more true: not that many systems need to run any real proxy software at all. If you don't like spammers (pretty likely) think how gleeful you'd be to see a spammer falsely assuming your trap will deliver his spam for him - and then think of the glee as you trap more and more of it. Think of finding the spammer's IP address (if you run a proxypot) and reporting it to the spammer's ISP. Many ISPs actually are ethical enough to rid themselves of a spamming customer, once they learn of him. Honeypots still work: the spammers don't all use spam-server zombies yet.
Retain your blocklists and filters in the meantime: until spam stops flowing you'll need them. If you've got an available IP and an available box you could probably be causing some spammer grief as early as tomorrow - if you'd run a honeypot.
That's a good idea (not a new one, but still a good one.) You still need to be able to use that data to whack their websites, though, or you'll be only a very minor inconvenience to them.
I know it's not new: I was saying it years ago. If someone said it before me I'm not in the least surprised: it's all simple and logical. The surprise is that it isn't being done (complex and illogical is the well-worn anti-spam path.)
Getting an entire spamming operation shut down (for a while) isn't a "minor" inconvenience, getting the feed pulled to the servers in the spammer's $750,000 house isn't a "minor" inconvenience. Getting spammer accounts nuked is just part of the goal: educating the ISPs to be able to find the spammers on their own, without honeypot help, is the greater goal. Then the ISPs will clean themselves and their neighbors and the problem will be gone. (If the neighbor doesn't clean himself rapidly enough, block the offending traffic at the ISP level.)
Don't paint this as simple "whack-a-mole" - it's much more.
However, I don't really care if anyone ever again uses a honeypot. ISPs, if they'd simply do some intelligent traffic analysis (and then take appropriate action), could accomplish far more than a thousand honeypots could. The traffic from a few billion spam messages per day isn't exactly invisible. The ISPs should find the suspect trafic and act on what they find (and quit screwing around - spam is a big nuisance.) Do they not have the right to reject offensive traffic (in the US, at least)? It's about time they took steps to find the offensive (spam) traffic and to reject that - and I do not mean wait until it comes to the destination server (an approach that works creakily at best.) A dumb old obsolete workstation running an MTA that is so old it doesn't recognize EHLO can trap and reject spam - it doesn't take proceesor power or sophisticated recognition techniques (I ran such a dumb old workstation: a Vaxstation 4000/90.) There are free honeypot packages available - those are smarter than that MTA that didn't recognize EHLO - but not particularly more sophisticated. Until the ISPs do the smart traffic analysis there's room for honeypots - lots of them. Even there the truth is that after the first several hundred to thousand of them (if that were ever to happen) the rest might trap almost nothing - the spam would be gone. That neglects spam zombies - there full honeypots and traffic analysis are the more powerful approaches. See much about either being proposed? No - the emphasis is still on floundering around at the receiving server. That stops spam to that server (when it works) but it doesn't work to stop spam period.
"But, as I said already, I'm not talking about sending spam."
I could have sworn you were. You said uu.net and above.net ignored complaints and asked for a solution to the problem. I gave a solution, based on actual experience that shows it works.
It's not illegal or abusive to have a website - even if the spammer generates leads for that website by committing abuse. How are you going to get the ISP to nuke the website?
As I've said, the ISPS (even uu.net, that perpetual bane of complaints) nuked spammer accounts when they were pointed out to uu.net as sources of abuse.
Ask for a solution, get a solution. Reject that solution and... I dunno. But you're not alone. For some strange reason based on the imponderable quirks of the human mind people want spam to be stopped only if it is done using the techniques that have so far failed to stop spam. They think being tough about open relays should end spam so they insist that the solution include being tough on open relays. That in spite of the clear wording in RFC 2505 that says (correctly) that securing open relays is not and will not be a successful strategy for ending spam. It's far more effective to open the relays a bit: let the spammers access them, deliver the spammers' test messages. Best is to set up a system for that purpose alone, one that doesn't handle any real SMTP traffic. Then the operator knows the SMTP traffic to it is suspect - and the operator can do whatever he wants to that traffic secure in the knowledge he is hitting spam and spam alone. That's about as simple as anything can be - but you'd have a very hard time getting even 10% of system operators to even think about it, let alone approve it. It's not what they think will work so they reject it, preferring to stay with what flat-out doesn't work. I don't say how to attack the spammers' web sites so you say "It's not what I want."
OK - next time make sure the question specifies that the solution must be taken from the body of things that have failed. Then you won't be bothered by any replies at all - there isn't any such solution. I'll keep trying to find people that actually want to end spam and will look at facts long enough to see how it can be done (but the evidence is getting strong that I'm pursuing yet another failed path - there are no such people.)
Firstly, all ISPs (and corperations, schools, unis and so on) should block port 25 by default.
An hour or so ago I mentioned Michael Tokarev's Moscow honeypot that was getting spam from uu.net customers. To save time I fudged a little. The spam wasn't coming from uu.net, it only looked like it was (because the spammer made it look that way.) Uu.net at first thought the spam complaints were bogus, had to be. That's because uu.net did block outgoing port 25. blocking port 25 wasn't enough to keep the spammers away.
The spammer (Ralsky) sent spam from a high-speed connection somewhere (in Dallas, but the actual source never was discovered - not by IP, not by street address.) The spam spoofed the uu.net IP addresses, so the ACK packets went to those uu.net IPs, which were uu.net dialup accounts. There were enough dialups in use at any time so that the high-speed link could send flat-out, spoofing different dial-up IPs, probably rotating through them . The ACKs got returned to the system with the high-speed link (the characteristics of the dialup IPs was that of a Cisco switch) so the TCP/IP dialog was carried out just like it was a normal setup.
Bottom line: there's more to it than first appears - even to professionals like uu.net employs.
It's going to take more than any single-step-and-then-it's-Miller-time approach. To stop the spammers the enemies of spam will have to keep whacking until there's nothing left to whack - and then a bit longer. Just like killing off a bacterial infection.
"UUnet isn't spam-friendly anymore than Rackspace is spam-friendly."
Did you choose a particularly bad example on purpose? There is only one ISP that ever telephoned me to tell me a lie ("The spammer is being disconnected" - pause - "right... NOW!") No, he wasn't.
"Perhaps the most useful thing that any ISP can do right now..."
I fervently disagree. The most useful thing ISPs could do right now is pay attention to their traffic: do traffic analysis. Billions of spam messages don't travel without a trace. If the ISP would look in the proper manner (just watching source and destination IP and port numbers) the ISP would find enough spam traffic to make life hard for the spammers - if the ISP was suffering any spam traffic. If the ISP is clean it can just sit back and smile - but remember that somewhere out there is a spammer who will be checking that ISPs cusomers for vulnerability very soon again.
No, not watch all traffic all the time: break it down into achievable chunks.
Individual users can run honeypots -even very rudimentatary ones. Llss than that but stilll useful is to look at the software firewall logs and find the events most likely to be spammer activity and then report those to the originating ISP (if it seems the ISP is not a full-fledged spammer enabler.) Port 25 activity and proxy port activity. If the user knows no good reason for the traffic then reporting it will probably be correct, even if the perpetrators aren't all spammers.
How do you identify the sender? The From: address is forged, the envelope MAIL FROM: is forged, the Reply-To: if forged, and in most cases, the originating IP address (the only one you can count on) is a virus infected zombie.
Correct. An open relay honeypot to which I have access trapped 1458 spam messages with 140658 recipients on Feb 16, all from 211.38.34.203, but that's probably just an open proxy or some other abused IP. Openrbl.org seems to agree.
It was diploma spam, with contact made by phoning 1-212-208-4551. Spam still being sent: it has recent hits in news.admin.net-abuse.sightings. If you didn't get yours maybe you were one of the 140658 (or one of the thousands others protected from the same spam that came to the honeypot through different IPs.) If you figure it up as 97 recipients per spam you'll find the count is off. The remaining messages were to the spammer's own dropbox alone - and he finally paid attention to the fact he wasn't getting his copies and stopped using the honeypot to relay spam. Which, of course, never happened (the relaying, that is.)
The trouble when you come to UUnet and Abovenet is that when you complain, they ignore you. Normally that means go to their upstream - well guess what, they have no upstream, for all intents and purposes they're it. If everybody else on the planet got together and blackholed them, it might work, but it would cause the rest of us almost as much pain as them. They're that big. They know it, and so unlike all the other ISPs they don't give a flying f$ck what their customers do, or what you think about it.
Got a solution to that problem? I'd love to hear it.
Years ago, when all were saying that same thing about uu.net, I got a spammer terminated. I had to send a second message (I'll admit that) but I never had to raise my voice, never had to make threats. I just laid out the facts that I could prove: their customer was attempting to relay spam through a university server. The customer disappeared. Later, he appeared again, on uu.net. Again, two messages were all it took.
Above.net I don't know - I never sent a complait to them that I can recall.
In 2003 Michael Tokarev notified uu.net that a spammer was attemtping to relay email through his server, in Moscow. Michael notified uu.net more cleverly: he sent the URL (http://www.corpit.ru/cgi-bin/h0n5yp0t) for a web page that reported the IP sources of recent spam. No surprise: after a while (and I think after a second remineder) uu.net started terminating spammer accounts. Then they'd refresh the page and see if a new throwaway account at uu.net was in use. If so, that account got terminated. and so on.
The spammer got thrown off three ISPS that way in one weekend and had to shut down for a while. Alan Ralsky is the spammer's name: the spam was coming from Ralsky's server farm in Dallas.
Sadly, Michael turned the honeypot off in July of 2003. but it was good while it lasted.
More recently Ron Guilmette had astounding results with his small network of open proxy honeypots. He, too, has shut down.
Make the right complaint and the ISP will listen. Or so it seems to me, from the evidence.
"The meta-point is, if we're going to progress in the war on spam we need to move past the solutions that have been proposed a million times with obvious holes in them."
Yeah, well. It isn't just solutions that have holes - it's also implementations. Blocklists would (or would have) worked very well, would have ended spam - if they had been used widely enough. But they are used just by some. Those that use them get a reasonable benefit, but the effect on the spammers isn't severe enough to make them decide to quit. Same for filters.
I've long advocated honeypots. That's out-of-the box thinking (the box being the use only of measures implemented at or after the destination email server.) They really work, the few there have been have had impressive results, but not enough people use them. Why not? Good question. I'd say precisely because it is out-of-the-box thinking behind them. Try to get any anti-spam person to agree to accepting relay email messages, for instance - he won't. He's so convinced that open relays (and not spammers) are the source of the problem he cannot hear. Move to open proxies and its the same: he has a nebulous fear that somehow accepting a spam message as a proxy carries a tremendous risk - like that maybe it will sneak by, get delivered.
The IEEE Security & Privacy Journal has an article on "Honeypot Hunter" in the January/February issue:
I can't quite figure it out but it may be the author is saying because one spammer has come up with one purported detection tool for open proxy honeypots the game is over for the honeypots. Watch me not be surprised that an effective tool will be rejected on such weak evidence after years of far more damning evidence being seen of effective spammer countermeasures against securing open relays, checksums, filters. Hash busters? Don't faze honeypots - honeypots don't care about content. Checksum busters? Same deal. Filter busters? If you don't care about content then nothing the spammers do with the content matters. So, OK, a spammer finds a honeypot - he'll stop trying to send spam through it. Next step, if things are done right, will be that he sees there's a bunch of honeypots in a particular net block and he'll stop trying to abuse any IP in that block - too risky. Note that word "stop" - that's an important word. Yes, he'll move on top other netblocks. That's not the problem - the problem is that the other netblocks have no honeypots to make him decide to stay away.
Or we can keep on flogging "solutions" at or after the destination server. What's the score, so far? Who is winning?
[I realize the rapid emergence of spam server zombies is changing the situation, making defeat of spam harder. For those a combinaiton of full honeypots (not the simple open relay/open proxy) variety will prove helpful, as will ISP attention to what's going on: traffic analysis. If there are billions of spam messages every day they will have a characteristic signature for the ISPs involved in the sending and delivery of the spam. If the ISPs would look they'd see. Seeing, they could act.
But it's that huge word "if" that's the problem - so far the ISPs won't, so far apparently most are unaware of the concept.]
You make some good points, but the counter point is that SMTP is what is implemented. To me that makes a solution that preserves SMTP (without creating an enormous burden) preferable to one that requires replacement of SMTP. There's an enormous investment in SMTP-based email. Preserving that wuld be less disruptive than wold be replacing it. It takes only a very low-level effort in detecting the spammers and their IPs to keep the spammers searching for new accounts - other than those spammers who are on ISPs who knowingly tolerate them. For the latter the solution is to expose the ISPs' willing participation in sending spam.
That said I agree with much of your analysis of Internet Mail 2000 - of which I was ignorant. I don't agree that ending spam requires replacement of SMTP. It's far too easy to act against spammers - even at the individual IP level - to blithely declare no solution that retains SMTP will work. Once spammers are knocked down to the "minor nuisance" level the amount of work involved in keeping them there is small - much smaller than the work involved in replacing SMTP everywhere (which might also entasil destroying the perr-to-peer nature of email, depending on the replacement. peer-to-peer is good: it prevents monopolistic practices.
The spam problem won't be solved untill teh vast majority of computers are completly un-hackable, or untill SMTP is improved.
Naw. Thee's no reason the spammers should be allowed to get their packets to the vulnerable systems for free - not when it's proxy port abuse. If it's abuse on other ports simple traffic analysis by an ISP will most often quickly reveal an external IP that is the source of attempts to find vulnerabilities. That requires ISPs be aware, be concerned, and be active. So far it looks like most ISPs are none of those.
You either are buying into or feeding the nonsensical notion that the only way to stop abuse is to secure everything. That's wrong. The problem is largely one of too much trusthaving been imbedded in the design of the internet - and that excess of trust is not solely a matter of protocols (it's screwy to act as though it is strictly a matter of protocols.) There's also too much trust in how ISPs run their services and in how they ignore the patterns of their traffic that indicate abuse in progress. Hard-core programming junkies may claimn that revising the internet and its protocols is the only way to end abuse but that's mostly extreme self-serving posturing on their part. They refuse to discuss the design, they refuse to engage in any analysis of the problem as it exists. No, they want to leap to an entire new design - so they can show off their skill. Sorry, the internet doesn't exist to prove how clever progrmamers are, it exists to provide services. Try to get a dialog going about the aspects of trust involved - they won't so it. They've already decided, without an analysis, that they want to revise the internet (or just SMTP.) They point at the weak and ad hoc attempts made to end spam, show they haven't succeeded (again, ), and claim a new design is the only way - a process that will take years. I have more faith in CAN-SPAM than I do in them - and that's a severe insult if ever there was one.
Re: analysis. If every mailbox were protected by a blocklist and if that blocklist accurately listed the sources of 98% of the spam then spam would die. Neither condition holds - the missing analysis is that of how much it would take to achieve the necessary levels of participation and lisitng accuracy to stop enough spam to make spamming unprofitable. For that matter the proponents of blocklists don't even do such an analysis.
Re:Spam is in the eye of the beholder (=recipient)
on
The Life of a Spammer
·
· Score: 2, Informative
So this is a fundamentally tough nut to crack.
Not much, not yet. Those at the intermediate stages (the ones who lose the most bandwidth) could very easily act. Even those who can't be abused (because they are secure against abuse already) could act: by looking like they are vulnerable to abuse and then reporting the attempts at abuse to the appropriate ISP.
I've stopped spam to millions of people without actually changing my SMTP software (I couldn't change it.) All I used were command files and system utilities. If people'd stop looking for the hard ways to stop spam and start looking for the easy ways:
(1) They'd find easy ways (2) They'd be very effective
On my VMS system all I had to do (once it no longer was a real email server) was:
(1) $ STOP/QUEUE UCX_SMTP (2) Every so often look to see what relay test messages I'd caught and then deliver one if I felt like it.
Receipt of a relay test message tells the spammer that the IP to which it was sent (through which it was sent) is an open relay. Well, mine is open if I chooose to let it be - and mostly I don't choose that. But you know that and I know that - Spammy didn't.
You can do much the same, using Jackpot:
http://jackpot.uk.net/
You have to decide ahead of time whether or not to deliver test messages and occasionally Jackpot mis-classifies but must of the time it's dead on.
Better yet (if you run Linux) try out the Bubblegum proxypot:
They're all equally insecure, the US as much as anyone else.
I'd not say equally - but US networks and systems are plenty insecure.
Of course that can be an advantage to anyone in the US who wants to fight spam: if the spammers look in the US for vulnerable systems then they can be deceived by an open relay or open proxy honeypot in the US.
Don't want to do that? Do you run a hardware or software firewall that logs blocked access attempts? If "yes" then please search the logs for attmepts on the proxy ports (1080, 3128, 8080) and report them.
I just got probed from 64.222.186.236 on all three ports. Will Bell Atlantic/Verizon do anything when I report this? I can't say - but I doubt it. But I'll still try. I doubt it because Verizon ignored reports of open relay scans for months (scans made by spammers Dave Patton.) Why, sure, Slashdot - I do have the evidence. Dave sent his relay tests to mets17@erols.com. Google "mets17 erols" and see what you find.
SMTP was designed to be a robust mail protocol in an environment in which trust was perfectly reasonable. The environment changed, the protocol was retained. Fine - but then you have to do something about the lost appropriateness of trust. Some things have been done - they've been inadequate. That's not the fault of SMTP or of the designers.
It isn't just SMTP that is abused: open proxy abuse is a big contributor to the spam problem. There, again, trust is inappropriate - but still exists. Spammers take advantage of other system and human vulnerabilities to set up spam zombie servers. Too much inappropriate trust yet again.
Some basic human behavior needs to change - and the ISPs should be in the lead. They aren't. The security experts might be in the lead. They aren't. Many security experts appear to believe that securing a small fraction of systems and bitching about all the rest is adeqaute. Well, take a look - is it? Few security experts do anything towards identifying and stopping the abusers who constantly search the internet for vulnerabilites. It's like a city is plagued by burglars and the security experts simply make sure the doors and windows of their buildings can't be forced. They could put in cameras to get pictures of the burglars when they try the window - but instead merely complain about those who don't secure their windows. Of course in this case it's spam, not burglary, and the abuse commited on the other guy's system can hit the security experts own system, in the form of spam. If the security expert would help rid the community of the abusers then the abuse would be reduced. The security expert would rather point fingers at others and hurl blame than do what he himself could do beyond excluding just one form of abuse. Some expert - he doesn't even look to see how allowing the abusers to continue hurts him.
Who is better placed than an ISP to watch for attempted proxy port abuse? What ISP do you know of that watches? Recent actual experience by someone who did watch showed that many spammers commit the abuse form their own IPs. Watch for the abuse and you find the spammers' IPs (so much for the much-vaunted "anonymity" of the spammers.) The spammers aren't that particularly clever: it's mostly that those who could act don't.
Your 1-5 description is wrong. SMTP is peer-to-peer. Step 1 and POP were added on when PCs with network connections became numerous.
If the recipient computer is off then SMTP systems typically queue the message and keep retrying it (to answer your question.) There's other practical problems for some end-user systems doing full SMTP but that doesn't change the peer-to-peer nature of SMTP. Back before the zealous blocking of DSL IPs it would have been (very often) possible to set the SMTP server address of your email client program (like Eudora) to the IP address of the server for the recipient of an email you wished to send and then to send it directly from your system to that server. It gets to be a PITA to keep changing the SMTP server so you wouldn't want to do that but it worked fine - better even than what you describe. If your client program says the message has been sent then you know it has reached the recipient's server. Absent blocking of your IP by the recipient's server this still works - if your ISP allows outgoing port 25.
For the traffic analysis consider this. The spammers still do a large amount of open proxy abuse. That means that large numbers of packets go from the spammers' IPs to the abused IPs. These packet streams are visible, if somebody watches for them, by both the spammers' ISPs and at by the victims ISPs.
In other words, if an ISP ran something like the ntop program to watch the outgoing traffic from a portion of it's network and looked only at port 1080 (as an example) the spammers' IPs would be at the top of the report, if the report is sorted by event count. If the ISPs of the victims watched a portion of the traffic coming in then if there are open proxies in its space being abused the traffic would show up - and the busiest spammers would top the list. (I say watch a portion because it may be a daunting task for an ISP to watch all its traffic. Spammers spam all the time, so just moving around a sampling point should find any spam activity in the segment being sampled. You don't have to find all the spam traffic, just enough to cause the spammers grief.) Account termination may not last forever (the spammers do get new accounts if thy are terminated) but it lasts long enough to hurt. Every time this works the ISPs get better skilled at it, too.
Technology can reduce the likelihood and impact of harmful human actions, but we cannot use it as a replacement for social responses.
I'll accept the premise. Technology can be the vehicle for social response - at the technical level, of course. Spam is a problem that involves trust. Several technological means are used to implement our distrust of spammers, with blocklists and filters coming to mind. But spammers also trust us - and that trust is well placed. Screw that: stop being trustworthy for the spammers. Right now, today, spammers can trust that if they test an IP for vulnerability as an open relay or open proxy, if it tests vulnerable - it is. For open relays, for example, all effort is directed to "secure your system." The spammer tests a secure system, it tests secure, he skips it. The spammer tests an insecure system, it tests insecure, he abuses it. If you don't see how the secure system has directly aided the spammer look again. There's no reason a secure system must test as secure - it's a mistake if they all do (so it's a mistake now.)
There's a direct and simple technical way to destroy the trust the spammers have in us. Destroying that trust doens't hurt the trust of non-spammer for non-spammer: it is almost exclusively the spammers who go around testing for insecurity.
Put another way, the non-spammer behavior patterns up to now haven't ended spam. It seems to follow that if the desire is to end the spam then the behavior needs to be changed - what's being done is a failure. That doesn't force my suggestion - but my suggeston does fit into that analysis. If you've got a better way to change the behavior, good for you. Tell us about it.
Slashdot Mirror
"Microsoft closed the account immediately, without investigating."
They should look at aa105966 AT hotmail.com. While closing it would be appropriate that's too friendly. They should empty the mailbox, divert all future email away from it (it will be coming from newly-detected open relays - that's what the mailbox is for), and learn as much as they can about the IP address used to access the email.
At least it was so used on Tuesday.
The internet could be far more spammer unfriendly with very little more effort - and after all these years of spammer abuse wouldn't it be fun to make them hurt?
Love the way you think, but don't forget the incoming traffic. If it's a DHCP-controlled system (as far as its IP address is converned) change the IP address and assign the old address to a full honeypot - so all the incoming commands can be caught and analyzed. If the zombie works by receiving instructions and then following them simply changing the IP ends the abuse for now, but the system is, of course, still potentially abusable. To cure that your idea works.
It's not going to be necessary to do such things millions of times. The effect is to remove the availability of abusable systems to the spammers and such removal means they have to give up long before they try it millions of times - on that ISP. Get just one ISP doing the smarter things (and telling about it) and very quickly a change will occur - a change for the better.
Put "defeat the spammers" at the top of the list of objectives, not "secure the systems." That's how to win.
"It isn't an unreasonable expectation that a machine connecting to a public network shouldn't have gaping security gaps. In fact, IMO, it is a public duty that it should not."
Is it an unreasonable expectation that the operators of public networks, knowing how vulnerable "some" operating systems are, would block all incoming traffic that can be identified as being intended to exploit such vulnerabilities? What's the big urge to allow abuse traffic in to a network?
It is, it isn't (unreasonable) - I don't choose to argue. But all that traffic that is meant to enable or cause abuse or to discover vulnerable systems is not valid internet traffic, it's abuse traffic. Ignoring the abusive nature of the traffic hasn't worked with any sterling results - why not try not ignoring it for a while and see if that's better?
Here's a fact: the email address gazeta91 AT gazeta.pl is used to receive abuse traffic (specifically, test messages sent to see if systems are open relays.) The messages seem all to originate in Phoenix, from Level 3 dialups (Level 3 is an ISP.) This is information about abuse traffic and I can report it because somebody is taking the trouble to trap the abuse. As such messages have, for many months, come from Level 3 dialups in Phoenix it seems the perpetrator may just be somebody in Phoenix (he could be somebody who is skilled at finding abusable systems in the dialup space of Level 3 in Phoenix.) So, if the issue is open relays, another 5 years could be sent chanting "secure the open relays" or evidence such as this could be gathered and used to find and stop the abusers. Which looks better to you?
(fernandomori AT hanmail.net receives such test messages, too.)
(salesc00 AT sales-control.org? Yep, the same.) Look up sales-control.org and you see the name service is from hostwithsimon.com. Might even have a valid name, addresss, and telephone number - in Daytona Beach. I'm suspicious right away. You?
Technical means. Use technical means. USE technical means.
(Thanks to an anonymous person who doesn't even know I'm using some of his honeypot data in Slashdot.)
Go back to February, 1999 and read RFC 2505. See what it says about how securing open relays will work to end spam (it's the RFC that says to secure open relays.)
There are the open relays and there are the ones who abuse them. The ones who abuse them are the spammers, are the criminals. Doncha think maybe a teeny bit of attention might be paid to the criminals? Securing the open relays hasn't ended spam, not since 1999. It's not a means for ending spam. Whacking spammers, on the other hand, has strengths in the "ending spam" category. Bend the effort a little more toward whacking the spammers. In 1999, 2000, it was extremely easy to whack spammes right and left by operting a fake open relay - but few did.
If, someday, you really wish to see spam ended perhaps you'll think about how to hit the spammers and stop trying to blame other victims. Whatever else comes from blaming other victims, it's not productive, not doing much at all to end spam.
If you're already primed to respond with a "oooh, you're a spanked open relay operator" be aware that I have a rude, scornful reply in mind for you. No, I'm not. I'm a person who has bothered to think about spam and open relays and who understands better what to do (unlike, confound it, ASTA.) If ASTA would do MINIMAL research and READ RFC 2505 they might GET A CLUE about how and why securing systems is not a solution. If this is their technical approach to ending spam 5 years after RFC 2505 they are below pathetic - and that's being polite. If you are going to use technical means against spammers then USE TECHNICAL MEANS AGAINST SPAMMERS. Blocking ISPs who might have zombie systems isn't a solution to spam, isn't an action taken against spammers. Contact the ISP, tell them to find out where the abuse originates, and then themselves contact the ISP where it does originate (it could be coming from an open proxy, or even a zombie.) What in tarnation do people think "technical means" are? spam pervades the internet. Does it not seem barely possible that if ISPS would actually LOOK at the traffic they could SEE the abuse?
If Delgado has scared you off (and you're an ISP) ask your freaking lawyer. There are exemptions that allow monitoring traffic and spam traffic being sent by theft of your or your customers' services isn't "communication." It's THEFT.
"You can't get a linux box to respond in the same way as a windows box without seriously getting into the kernel though."
It's a blasted worm. Only if very sophisticated would a worm look for an authentic Windows environment. Why would they bother?
I'm far more familiar with honey pot definition 2 - and I know how incredibly stupid spammers have long been when it comes to open relay honeypots. They are doing bulk abuse, not pinpoint abuse. Whatever the details they are looking for a vulnerability - and then exploit that vulnerability when they find it. They look for hundreds or thousands of vulnerable systems. They do that "quick and dirty" - that's all they've had to do (almost no complex countermeasures are employed against them.) That has worked for them. Why should they make it more complicated?
It's not guaranteed that the woms are so primitive that they don't verify that a system is a Windows system - but it's not guaranteed the worms do. Wouldn't it be better to set up the Linux systems and see if they succeed or are discovered as fakes? That has some chance of success. Arm's-length philosophical discussions won't stop any abuse.
My experience with open relay honeypots suggests that all the spammers do to check for those is attempt to relay. I can see reason for the abusers to be more careful and more clever - but rather than assume they are the better idea is to force them into being more careful and more clever. Burn up more of their time, confuse them about the rest of the internet (the part they abuse, as opposed to their own part.) There are many goals in fighting abuse - don't fixate on just one. If the abusers can be made thoroughly confused about the rest of the internet (i.e., can't tell what is and what isn't vulnerable to abuse) then they pretty much have to give up. That will never happen if all that is done is engage in discussions.
OK, do fixate - it's you time - who am I to tell you what to do? But give some thought to how much better it is to make a broader attack, if you will, please.
P.S. Open relay honeypots still work today, April 23, 2004. Open proxy honeypots may be even more powerful.
Why would they? He keeps them in business. Anti-spam is big money. Without spammers, they're out of a job.
There's a large number of anti-spammers who do everything for free, as volunteers. Steve Linford is a prime example. "Giblet, USA resident" is another.
Here's another real question: is p2p inherently copyright violation?
My answer is: "no."
You are on the mark when it comes to the nature of copyright and the reasons for it. Surely this is an old debate. First there were audio tape recorders, then video recorders, now CDR and DVD-R writers - plus p2p. No doubt attempts were made to hobble each of those other technologies - but obviously the attempts weren't fully successful. The network started out p2p - and still retains many of the p2p features and programs (ftp, for one.) There are all sorts of technologies that can be misused - and are. Stomping on a technology because it is misused by some is not a good approach.
Still, what you say about copyright needs to be remembered. Even in this day of instant perfect digital duplication there are rights to original material and intellectual property and the proper course is to respect those rights. Making a copy of any copyrighted work and sending it to anyone else is illicit publishing of the work. The owner of the copyright, even if it is a big, nasty corporation (and such exist) has the right to stop that activity and to seek redress against those who do it. Whether they do or not, whether they win or not, if they started out as a big nasty corporation they remain one - but they also still have the right to restrict copies of the works they control. Nice guys with copyrights also have exactly the same rights, of course - and remain nice guys (I hope) if they take action against those who steal from them.
Keep p2p, stop using it to steal.
Kraewetz also wrote an article on anti-honeypot technology for IEEE Security & Privacy (pp 76-79, January-February 2004 issue.) He seems to asume (like too many) that the spamemrs are near God-like in their abilities. He also seems not to have ever run an anti-spam honeypot. If he had he might have, many times, seen spammers behaving in an incredibly stupid manner. The spammers aren't all that sharp and honeypots (at least now) don't have to be very sophisticated.
His survey article (the topic of this Slashdot thread) once again continues the misconception that anti-spam tools all must be at or after the destination server. Let's look at it this way: the spammers quickly figured out (4-5 years ago) that going direct from their server to the destination wasn't working for them, so they went to intermediate severs, starting with open relays. Anti-spammers are still stuck on their servers - if it isn't the final server it doesn't exist (to their closed minds.) The open relay layer is just as available to the anti-spammers as it is to the spammers, but the anti-spammers mostly refuse to go there. Actually the layer is more available to the anti-spammers: any system with no real email function could serve as an open relay honeypot. You don't need to filter or be smart at all with an open relay honeypot: the spammers do all the work for you. They find the honeypot, they think it's an open relay (the honeypot dutifully does deliver the spammers' test messages), they send the spam, you just sit and watch. For open proxies (another layer dominated by spammers) that's even more true: not that many systems need to run any real proxy software at all. If you don't like spammers (pretty likely) think how gleeful you'd be to see a spammer falsely assuming your trap will deliver his spam for him - and then think of the glee as you trap more and more of it. Think of finding the spammer's IP address (if you run a proxypot) and reporting it to the spammer's ISP. Many ISPs actually are ethical enough to rid themselves of a spamming customer, once they learn of him. Honeypots still work: the spammers don't all use spam-server zombies yet.
Retain your blocklists and filters in the meantime: until spam stops flowing you'll need them. If you've got an available IP and an available box you could probably be causing some spammer grief as early as tomorrow - if you'd run a honeypot.
That's a good idea (not a new one, but still a good one.) You still need to be able to use that data to whack their websites, though, or you'll be only a very minor inconvenience to them.
I know it's not new: I was saying it years ago. If someone said it before me I'm not in the least surprised: it's all simple and logical. The surprise is that it isn't being done (complex and illogical is the well-worn anti-spam path.)
Getting an entire spamming operation shut down (for a while) isn't a "minor" inconvenience, getting the feed pulled to the servers in the spammer's $750,000 house isn't a "minor" inconvenience. Getting spammer accounts nuked is just part of the goal: educating the ISPs to be able to find the spammers on their own, without honeypot help, is the greater goal. Then the ISPs will clean themselves and their neighbors and the problem will be gone. (If the neighbor doesn't clean himself rapidly enough, block the offending traffic at the ISP level.)
Don't paint this as simple "whack-a-mole" - it's much more.
However, I don't really care if anyone ever again uses a honeypot. ISPs, if they'd simply do some intelligent traffic analysis (and then take appropriate action), could accomplish far more than a thousand honeypots could. The traffic from a few billion spam messages per day isn't exactly invisible. The ISPs should find the suspect trafic and act on what they find (and quit screwing around - spam is a big nuisance.) Do they not have the right to reject offensive traffic (in the US, at least)? It's about time they took steps to find the offensive (spam) traffic and to reject that - and I do not mean wait until it comes to the destination server (an approach that works creakily at best.) A dumb old obsolete workstation running an MTA that is so old it doesn't recognize EHLO can trap and reject spam - it doesn't take proceesor power or sophisticated recognition techniques (I ran such a dumb old workstation: a Vaxstation 4000/90.) There are free honeypot packages available - those are smarter than that MTA that didn't recognize EHLO - but not particularly more sophisticated. Until the ISPs do the smart traffic analysis there's room for honeypots - lots of them. Even there the truth is that after the first several hundred to thousand of them (if that were ever to happen) the rest might trap almost nothing - the spam would be gone. That neglects spam zombies - there full honeypots and traffic analysis are the more powerful approaches. See much about either being proposed? No - the emphasis is still on floundering around at the receiving server. That stops spam to that server (when it works) but it doesn't work to stop spam period.
"But, as I said already, I'm not talking about sending spam."
... I dunno. But you're not alone. For some strange reason based on the imponderable quirks of the human mind people want spam to be stopped only if it is done using the techniques that have so far failed to stop spam. They think being tough about open relays should end spam so they insist that the solution include being tough on open relays. That in spite of the clear wording in RFC 2505 that says (correctly) that securing open relays is not and will not be a successful strategy for ending spam. It's far more effective to open the relays a bit: let the spammers access them, deliver the spammers' test messages. Best is to set up a system for that purpose alone, one that doesn't handle any real SMTP traffic. Then the operator knows the SMTP traffic to it is suspect - and the operator can do whatever he wants to that traffic secure in the knowledge he is hitting spam and spam alone. That's about as simple as anything can be - but you'd have a very hard time getting even 10% of system operators to even think about it, let alone approve it. It's not what they think will work so they reject it, preferring to stay with what flat-out doesn't work. I don't say how to attack the spammers' web sites so you say "It's not what I want."
I could have sworn you were. You said uu.net and above.net ignored complaints and asked for a solution to the problem. I gave a solution, based on actual experience that shows it works.
It's not illegal or abusive to have a website - even if the spammer generates leads for that website by committing abuse. How are you going to get the ISP to nuke the website?
As I've said, the ISPS (even uu.net, that perpetual bane of complaints) nuked spammer accounts when they were pointed out to uu.net as sources of abuse.
Ask for a solution, get a solution. Reject that solution and
OK - next time make sure the question specifies that the solution must be taken from the body of things that have failed. Then you won't be bothered by any replies at all - there isn't any such solution. I'll keep trying to find people that actually want to end spam and will look at facts long enough to see how it can be done (but the evidence is getting strong that I'm pursuing yet another failed path - there are no such people.)
Firstly, all ISPs (and corperations, schools, unis and so on) should block port 25 by default.
An hour or so ago I mentioned Michael Tokarev's Moscow honeypot that was getting spam from uu.net customers. To save time I fudged a little. The spam wasn't coming from uu.net, it only looked like it was (because the spammer made it look that way.) Uu.net at first thought the spam complaints were bogus, had to be. That's because uu.net did block outgoing port 25. blocking port 25 wasn't enough to keep the spammers away.
The spammer (Ralsky) sent spam from a high-speed connection somewhere (in Dallas, but the actual source never was discovered - not by IP, not by street address.) The spam spoofed the uu.net IP addresses, so the ACK packets went to those uu.net IPs, which were uu.net dialup accounts. There were enough dialups in use at any time so that the high-speed link could send flat-out, spoofing different dial-up IPs, probably rotating through them . The ACKs got returned to the system with the high-speed link (the characteristics of the dialup IPs was that of a Cisco switch) so the TCP/IP dialog was carried out just like it was a normal setup.
Bottom line: there's more to it than first appears - even to professionals like uu.net employs.
It's going to take more than any single-step-and-then-it's-Miller-time approach. To stop the spammers the enemies of spam will have to keep whacking until there's nothing left to whack - and then a bit longer. Just like killing off a bacterial infection.
"UUnet isn't spam-friendly anymore than Rackspace is spam-friendly."
... NOW!") No, he wasn't.
Did you choose a particularly bad example on purpose? There is only one ISP that ever telephoned me to tell me a lie ("The spammer is being disconnected" - pause - "right
That call came from Rackspace.
"Perhaps the most useful thing that any ISP can do right now ..."
I fervently disagree. The most useful thing ISPs could do right now is pay attention to their traffic: do traffic analysis. Billions of spam messages don't travel without a trace. If the ISP would look in the proper manner (just watching source and destination IP and port numbers) the ISP would find enough spam traffic to make life hard for the spammers - if the ISP was suffering any spam traffic. If the ISP is clean it can just sit back and smile - but remember that somewhere out there is a spammer who will be checking that ISPs cusomers for vulnerability very soon again.
No, not watch all traffic all the time: break it down into achievable chunks.
Individual users can run honeypots -even very rudimentatary ones. Llss than that but stilll useful is to look at the software firewall logs and find the events most likely to be spammer activity and then report those to the originating ISP (if it seems the ISP is not a full-fledged spammer enabler.) Port 25 activity and proxy port activity. If the user knows no good reason for the traffic then reporting it will probably be correct, even if the perpetrators aren't all spammers.
How do you identify the sender? The From: address is forged, the envelope MAIL FROM: is forged, the Reply-To: if forged, and in most cases, the originating IP address (the only one you can count on) is a virus infected zombie.
Correct. An open relay honeypot to which I have access trapped 1458 spam messages with 140658 recipients on Feb 16, all from 211.38.34.203, but that's probably just an open proxy or some other abused IP. Openrbl.org seems to agree.
It was diploma spam, with contact made by phoning 1-212-208-4551. Spam still being sent: it has recent hits in news.admin.net-abuse.sightings. If you didn't get yours maybe you were one of the 140658 (or one of the thousands others protected from the same spam that came to the honeypot through different IPs.) If you figure it up as 97 recipients per spam you'll find the count is off. The remaining messages were to the spammer's own dropbox alone - and he finally paid attention to the fact he wasn't getting his copies and stopped using the honeypot to relay spam. Which, of course, never happened (the relaying, that is.)
The trouble when you come to UUnet and Abovenet is that when you complain, they ignore you. Normally that means go to their upstream - well guess what, they have no upstream, for all intents and purposes they're it. If everybody else on the planet got together and blackholed them, it might work, but it would cause the rest of us almost as much pain as them. They're that big. They know it, and so unlike all the other ISPs they don't give a flying f$ck what their customers do, or what you think about it.
Got a solution to that problem? I'd love to hear it.
Years ago, when all were saying that same thing about uu.net, I got a spammer terminated. I had to send a second message (I'll admit that) but I never had to raise my voice, never had to make threats. I just laid out the facts that I could prove: their customer was attempting to relay spam through a university server. The customer disappeared. Later, he appeared again, on uu.net. Again, two messages were all it took.
Above.net I don't know - I never sent a complait to them that I can recall.
In 2003 Michael Tokarev notified uu.net that a spammer was attemtping to relay email through his server, in Moscow. Michael notified uu.net more cleverly: he sent the URL (http://www.corpit.ru/cgi-bin/h0n5yp0t) for a web page that reported the IP sources of recent spam. No surprise: after a while (and I think after a second remineder) uu.net started terminating spammer accounts. Then they'd refresh the page and see if a new throwaway account at uu.net was in use. If so, that account got terminated. and so on.
The spammer got thrown off three ISPS that way in one weekend and had to shut down for a while. Alan Ralsky is the spammer's name: the spam was coming from Ralsky's server farm in Dallas.
Sadly, Michael turned the honeypot off in July of 2003. but it was good while it lasted.
More recently Ron Guilmette had astounding results with his small network of open proxy honeypots. He, too, has shut down.
Make the right complaint and the ISP will listen. Or so it seems to me, from the evidence.
"The meta-point is, if we're going to progress in the war on spam we need to move past the solutions that have been proposed a million times with obvious holes in them."
1 07 6abs.htm
Yeah, well. It isn't just solutions that have holes - it's also implementations. Blocklists would (or would have) worked very well, would have ended spam - if they had been used widely enough. But they are used just by some. Those that use them get a reasonable benefit, but the effect on the spammers isn't severe enough to make them decide to quit. Same for filters.
I've long advocated honeypots. That's out-of-the box thinking (the box being the use only of measures implemented at or after the destination email server.) They really work, the few there have been have had impressive results, but not enough people use them. Why not? Good question. I'd say precisely because it is out-of-the-box thinking behind them. Try to get any anti-spam person to agree to accepting relay email messages, for instance - he won't. He's so convinced that open relays (and not spammers) are the source of the problem he cannot hear. Move to open proxies and its the same: he has a nebulous fear that somehow accepting a spam message as a proxy carries a tremendous risk - like that maybe it will sneak by, get delivered.
The IEEE Security & Privacy Journal has an article on "Honeypot Hunter" in the January/February issue:
http://csdl..orcomputerg/comp/mags/sp/2004/01/j
(abstract)
I can't quite figure it out but it may be the author is saying because one spammer has come up with one purported detection tool for open proxy honeypots the game is over for the honeypots. Watch me not be surprised that an effective tool will be rejected on such weak evidence after years of far more damning evidence being seen of effective spammer countermeasures against securing open relays, checksums, filters. Hash busters? Don't faze honeypots - honeypots don't care about content. Checksum busters? Same deal. Filter busters? If you don't care about content then nothing the spammers do with the content matters. So, OK, a spammer finds a honeypot - he'll stop trying to send spam through it. Next step, if things are done right, will be that he sees there's a bunch of honeypots in a particular net block and he'll stop trying to abuse any IP in that block - too risky. Note that word "stop" - that's an important word. Yes, he'll move on top other netblocks. That's not the problem - the problem is that the other netblocks have no honeypots to make him decide to stay away.
Or we can keep on flogging "solutions" at or after the destination server. What's the score, so far? Who is winning?
[I realize the rapid emergence of spam server zombies is changing the situation, making defeat of spam harder. For those a combinaiton of full honeypots (not the simple open relay/open proxy) variety will prove helpful, as will ISP attention to what's going on: traffic analysis. If there are billions of spam messages every day they will have a characteristic signature for the ISPs involved in the sending and delivery of the spam. If the ISPs would look they'd see. Seeing, they could act.
But it's that huge word "if" that's the problem - so far the ISPs won't, so far apparently most are unaware of the concept.]
You make some good points, but the counter point is that SMTP is what is implemented. To me that makes a solution that preserves SMTP (without creating an enormous burden) preferable to one that requires replacement of SMTP. There's an enormous investment in SMTP-based email. Preserving that wuld be less disruptive than wold be replacing it. It takes only a very low-level effort in detecting the spammers and their IPs to keep the spammers searching for new accounts - other than those spammers who are on ISPs who knowingly tolerate them. For the latter the solution is to expose the ISPs' willing participation in sending spam. That said I agree with much of your analysis of Internet Mail 2000 - of which I was ignorant. I don't agree that ending spam requires replacement of SMTP. It's far too easy to act against spammers - even at the individual IP level - to blithely declare no solution that retains SMTP will work. Once spammers are knocked down to the "minor nuisance" level the amount of work involved in keeping them there is small - much smaller than the work involved in replacing SMTP everywhere (which might also entasil destroying the perr-to-peer nature of email, depending on the replacement. peer-to-peer is good: it prevents monopolistic practices.
The spam problem won't be solved untill teh vast majority of computers are completly un-hackable, or untill SMTP is improved.
Naw. Thee's no reason the spammers should be allowed to get their packets to the vulnerable systems for free - not when it's proxy port abuse. If it's abuse on other ports simple traffic analysis by an ISP will most often quickly reveal an external IP that is the source of attempts to find vulnerabilities. That requires ISPs be aware, be concerned, and be active. So far it looks like most ISPs are none of those.
You either are buying into or feeding the nonsensical notion that the only way to stop abuse is to secure everything. That's wrong. The problem is largely one of too much trusthaving been imbedded in the design of the internet - and that excess of trust is not solely a matter of protocols (it's screwy to act as though it is strictly a matter of protocols.) There's also too much trust in how ISPs run their services and in how they ignore the patterns of their traffic that indicate abuse in progress. Hard-core programming junkies may claimn that revising the internet and its protocols is the only way to end abuse but that's mostly extreme self-serving posturing on their part. They refuse to discuss the design, they refuse to engage in any analysis of the problem as it exists. No, they want to leap to an entire new design - so they can show off their skill. Sorry, the internet doesn't exist to prove how clever progrmamers are, it exists to provide services. Try to get a dialog going about the aspects of trust involved - they won't so it. They've already decided, without an analysis, that they want to revise the internet (or just SMTP.) They point at the weak and ad hoc attempts made to end spam, show they haven't succeeded (again, ), and claim a new design is the only way - a process that will take years. I have more faith in CAN-SPAM than I do in them - and that's a severe insult if ever there was one.
Re: analysis. If every mailbox were protected by a blocklist and if that blocklist accurately listed the sources of 98% of the spam then spam would die. Neither condition holds - the missing analysis is that of how much it would take to achieve the necessary levels of participation and lisitng accuracy to stop enough spam to make spamming unprofitable. For that matter the proponents of blocklists don't even do such an analysis.
So this is a fundamentally tough nut to crack.
Not much, not yet. Those at the intermediate stages (the ones who lose the most bandwidth) could very easily act. Even those who can't be abused (because they are secure against abuse already) could act: by looking like they are vulnerable to abuse and then reporting the attempts at abuse to the appropriate ISP.
I've stopped spam to millions of people without actually changing my SMTP software (I couldn't change it.) All I used were command files and system utilities. If people'd stop looking for the hard ways to stop spam and start looking for the easy ways:
(1) They'd find easy ways
(2) They'd be very effective
On my VMS system all I had to do (once it no longer was a real email server) was:
(1) $ STOP/QUEUE UCX_SMTP
(2) Every so often look to see what relay test messages I'd caught and then deliver one if I felt like it.
Receipt of a relay test message tells the spammer that the IP to which it was sent (through which it was sent) is an open relay. Well, mine is open if I chooose to let it be - and mostly I don't choose that. But you know that and I know that - Spammy didn't.
You can do much the same, using Jackpot:
http://jackpot.uk.net/
You have to decide ahead of time whether or not to deliver test messages and occasionally Jackpot mis-classifies but must of the time it's dead on.
Better yet (if you run Linux) try out the Bubblegum proxypot:
http://world.std.com/~pacman/proxypot.html
They're all equally insecure, the US as much as anyone else.
I'd not say equally - but US networks and systems are plenty insecure.
Of course that can be an advantage to anyone in the US who wants to fight spam: if the spammers look in the US for vulnerable systems then they can be deceived by an open relay or open proxy honeypot in the US.
Don't want to do that? Do you run a hardware or software firewall that logs blocked access attempts? If "yes" then please search the logs for attmepts on the proxy ports (1080, 3128, 8080) and report them.
I just got probed from 64.222.186.236 on all three ports. Will Bell Atlantic/Verizon do anything when I report this? I can't say - but I doubt it. But I'll still try. I doubt it because Verizon ignored reports of open relay scans for months (scans made by spammers Dave Patton.) Why, sure, Slashdot - I do have the evidence. Dave sent his relay tests to mets17@erols.com. Google "mets17 erols" and see what you find.
SMTP was designed to be a robust mail protocol in an environment in which trust was perfectly reasonable. The environment changed, the protocol was retained. Fine - but then you have to do something about the lost appropriateness of trust. Some things have been done - they've been inadequate. That's not the fault of SMTP or of the designers.
It isn't just SMTP that is abused: open proxy abuse is a big contributor to the spam problem. There, again, trust is inappropriate - but still exists. Spammers take advantage of other system and human vulnerabilities to set up spam zombie servers. Too much inappropriate trust yet again.
Some basic human behavior needs to change - and the ISPs should be in the lead. They aren't. The security experts might be in the lead. They aren't. Many security experts appear to believe that securing a small fraction of systems and bitching about all the rest is adeqaute. Well, take a look - is it? Few security experts do anything towards identifying and stopping the abusers who constantly search the internet for vulnerabilites. It's like a city is plagued by burglars and the security experts simply make sure the doors and windows of their buildings can't be forced. They could put in cameras to get pictures of the burglars when they try the window - but instead merely complain about those who don't secure their windows. Of course in this case it's spam, not burglary, and the abuse commited on the other guy's system can hit the security experts own system, in the form of spam. If the security expert would help rid the community of the abusers then the abuse would be reduced. The security expert would rather point fingers at others and hurl blame than do what he himself could do beyond excluding just one form of abuse. Some expert - he doesn't even look to see how allowing the abusers to continue hurts him.
Who is better placed than an ISP to watch for attempted proxy port abuse? What ISP do you know of that watches? Recent actual experience by someone who did watch showed that many spammers commit the abuse form their own IPs. Watch for the abuse and you find the spammers' IPs (so much for the much-vaunted "anonymity" of the spammers.) The spammers aren't that particularly clever: it's mostly that those who could act don't.
Your 1-5 description is wrong. SMTP is peer-to-peer. Step 1 and POP were added on when PCs with network connections became numerous.
If the recipient computer is off then SMTP systems typically queue the message and keep retrying it (to answer your question.) There's other practical problems for some end-user systems doing full SMTP but that doesn't change the peer-to-peer nature of SMTP. Back before the zealous blocking of DSL IPs it would have been (very often) possible to set the SMTP server address of your email client program (like Eudora) to the IP address of the server for the recipient of an email you wished to send and then to send it directly from your system to that server. It gets to be a PITA to keep changing the SMTP server so you wouldn't want to do that but it worked fine - better even than what you describe. If your client program says the message has been sent then you know it has reached the recipient's server. Absent blocking of your IP by the recipient's server this still works - if your ISP allows outgoing port 25.
Ok. This is bad idea. But what else we can do?
That is the right question - and it has answers.
Two of my answers are:
Honeypots (for individuals and ISPs.)
Traffic analysis (for ISPs.)
For the traffic analysis consider this. The spammers still do a large amount of open proxy abuse. That means that large numbers of packets go from the spammers' IPs to the abused IPs. These packet streams are visible, if somebody watches for them, by both the spammers' ISPs and at by the victims ISPs.
In other words, if an ISP ran something like the ntop program to watch the outgoing traffic from a portion of it's network and looked only at port 1080 (as an example) the spammers' IPs would be at the top of the report, if the report is sorted by event count. If the ISPs of the victims watched a portion of the traffic coming in then if there are open proxies in its space being abused the traffic would show up - and the busiest spammers would top the list. (I say watch a portion because it may be a daunting task for an ISP to watch all its traffic. Spammers spam all the time, so just moving around a sampling point should find any spam activity in the segment being sampled. You don't have to find all the spam traffic, just enough to cause the spammers grief.) Account termination may not last forever (the spammers do get new accounts if thy are terminated) but it lasts long enough to hurt. Every time this works the ISPs get better skilled at it, too.
Well said. It also brings the pure anti-abuse people into the battle against spam - or should. Also good.
Technology can reduce the likelihood and impact of harmful human actions, but we cannot use it as a replacement for social responses.
I'll accept the premise. Technology can be the vehicle for social response - at the technical level, of course. Spam is a problem that involves trust. Several technological means are used to implement our distrust of spammers, with blocklists and filters coming to mind. But spammers also trust us - and that trust is well placed. Screw that: stop being trustworthy for the spammers. Right now, today, spammers can trust that if they test an IP for vulnerability as an open relay or open proxy, if it tests vulnerable - it is. For open relays, for example, all effort is directed to "secure your system." The spammer tests a secure system, it tests secure, he skips it. The spammer tests an insecure system, it tests insecure, he abuses it. If you don't see how the secure system has directly aided the spammer look again. There's no reason a secure system must test as secure - it's a mistake if they all do (so it's a mistake now.)
There's a direct and simple technical way to destroy the trust the spammers have in us. Destroying that trust doens't hurt the trust of non-spammer for non-spammer: it is almost exclusively the spammers who go around testing for insecurity.
Put another way, the non-spammer behavior patterns up to now haven't ended spam. It seems to follow that if the desire is to end the spam then the behavior needs to be changed - what's being done is a failure. That doesn't force my suggestion - but my suggeston does fit into that analysis. If you've got a better way to change the behavior, good for you. Tell us about it.