Subject: Re: [asrg] 6. proposal of solution: Using Relay Honeypots to Reduce Spam

From: "Jon Kyme" <[email-masked]>
Date: Tue, 15 Apr 2003 21:45:59 +0100

> At 05:57 PM 4/15/2003 +0100, you wrote:
> 
> 
> >What's the incentive to deploy (requirements 4.a ?) for an ISP?
> 
> I anticipate an ASRG plan which ASRG has analyzed and believes will end 
> spam (or reduce it by 99% - effectively end it.) It's time to get
> serious,
> to act against spam.  

Two questions:
1. How much spam reduction should we expect from the deployment of one more
honeypot?
2. How many honeypots do we need to deploy to reduce spam by 99%?

--
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Brad Spencer <[email-masked]>
Date: Tue, 15 Apr 2003 17:50:39 -0500

At 02:48 PM 4/15/2003 -0600, John Fenley wrote:
>>From: Brad Spencer <[email-masked]>
>>Subject: [asrg] 6. proposal of solution: Using Relay Honeypots to  Reduce 
>>Spam
>
>[I cut tons of stuff out of this whole thing]
>
>>ASRG can anticipate that some spammers, at least for a while, will resist 
>>the effort to end spam and will attempt to overcome the ASRG methods.
>>While the ASRG proposal should be comprehensive enough to anticipate such 
>>moves the details of such moves cannot be anticipated.
>
>There are current ways to defeat honeypots.
>
>1. using a test address to detect honeypots.(there are an infinite number 
>of addresses available, they will not run out.)

Doing something an infinite number of times does tend to tie up your days.

Get enough honeypots and you're glad every time a spammer finds one and 
decides to leave that IP alone.   That's /32 glad.  What you want is to be 
/24, /20, etc. glad, leading to /0 glad.

Forget honeypots.  Spammers send spam through abusable systems 
everywhere.  That means that anywhere (everywhere is the collection of all 
the anywhere's) can be a point at which spammers suffer hardship, if people 
anywhere would do it.  How one goes about messing with the spammers by 
messing with their ability to commit abuse is up to the ones taking the action.

>2. unless you can convince the whole world that these are good, using ip 
>to determine geographical locations where honeypots are scarce.

Yep.  Of course where the spammers are is where the best pickin's are.

>3. send even more spam through the real open relays.

Yes.  But we coast, they struggle.

>and As you mention:
>4. send spam directly

Which honeypots can't and don't touch.  Blocklists don't just touch, they 
wallop.

>>The first analysis of spam is easy: spam has two types, direct, and 
>>non-direct.  Direct spam should be completely controllable by use of 
>>block lists, at least direct spam from spam-only sources.
>
>Blocklists don't work. Again, there are an infinite number of email 
>addresses for spammers to use.

Yeah, but spammers send direct from IPs.  If they're their own IP's it's a 
small subset of all IPs.

>A spammer could buy a domain, and do a mailing using real begginning 
>addresses with their real domain endings. each unique address would only 
>be used once. everyone would have to block every address in that spammers 
>list, untill it is RBLed, and by that time the dammage is done. the 
>spammer can just buy another domain.

I can't stop that with honepots - that's someone else's baby.

>>The long-term ASRG plan may include a replacement or strengthening of the 
>>SMTP protocol.  What ASRG does need not be limited to a single action.
>>Protocol enhancement may be the key part of the ASRG plan but the current 
>>intense level of spam calls for immediate action to substantially reduce 
>>the amount of spam that reaches all users, as a whole.

>A revision to the SMTP protocall would eliminate the need for honeypots 
>altogether. The problem is adoption. a new protocall will not be adopted 
>if there is not an advantage to every user of the new protocall.

A topic for discussion.  I don't care if honeypots are used.  I care if 
spam is ended.

>Senders will not upgrade unless they see an advantage to doing it.
>Mail programs will not support it unless people are sending, using it. In 
>any case you will still have to recieve regular smtp mail untill the 
>change is complete.

True.  I mentioned the option because it seemed much of the discussion aims 
at such a solution.

>There is only one case I know of where change like this has happened. 
>Sweden changed from driving on the left to driving on the right, one 
>morning (September 3, 1967 I think), after a major advertising camaign 
>(obviously)backed by their government. They made the change in the middle 
>of the week to avoid people getting up to go to work on monday and having 
>a "Mannic Monday" because they forgot.

It could be gradual.  Have a third contact string - if both ends of the 
transaction recognize that string (the first uses it, the destination knows 
what it means) then both ends are using the new protocol.  Or it could be a 
new port.  It's not really my area of interest...

>Oh yeah, our (american) tv signals are changing to digital, in a plan 
>backed by our government. I think the deadline is 2008?
>
>Also the Euro.
>
>These plans were not spur of the moment plans. They took years of effort 
>to formulate and pass. This is what is needed if the system is not self 
>adopting, and backward compatable. (color tv was like this... a Black & 
>White tv could display color signals, just not the color.)

Whereas honeypots use existing protocols, existing MTA's.  You can do a 
sendmail honeypot.  I ran a mixed server/honeypot using command files.  It 
was a low-volume server and a Vaxstation, but it worked.  I don't recommend 
mixing a server and a honeypot now but it can be done.

>>Whether or not the abuse meets the federal standard for action the abuse 
>>[from spammers]is theft of service.
>
>If I set up a table on a hot day in a crowded place with no sign, put 
>glasses of liquid on it, and people drink the liquid, are they stealing 
>the liquid from me?
>likewise if the liquid turns out to be poison, am I responsible? I didn't 
>tell them to drink it...
>What do you think a court would say?

There is a federal threshold of $5000 worth of service stolen, if that's 
the sole abuse (theft of service.)  If that could be aggregated ($5000 
total for a single spammer) then federal investigators could go after 
high-volume spammers.  that means they could get search warrants.  At the 
moment I think this is exceedingly unlikely.

>>Honeypots, in this context, are systems set up to appear to the spammer 
>>to be vulnerable to abuse but not be vulnerable - some key part of the 
>>abuse is intercepted, usually delivery of spam.
>
>
>>The real power of honeypots comes when they exist in large numbers...
>
>The number of honeypots does not effect the validity of the workarounds 
>mentioned earlier.

The workaround (the effort the spammer has to put into finding real open 
relays) is the payoff of the honeypots.  He can no longer just send a test 
and find an open relay - he has to ascertain that the system that passed 
the test is an open relay.

>>RFC 2505 says that securing open relays is not an approach to ending spam.
>>The reason is that spammers will continue to discover open relays, so 
>>that even a 95% success in securing open relays won't stop spam.  The key 
>>word is discover: the problem is that spammers can discover open 
>>relays.  Anyone can: try to relay an email message through a million IPs 
>>and you'll find some that will.
>
>RFC 2505 also says:
>      "The Non-Relay rules are not in themselves enough to stop spam.
>       Even if 99% of the SMTP MTAs implemented them from Day 1,
>       spammers would still find the remaining 1% and use them. Or
>       spammers would just switch gear and connect directly to each and
>       every recipient host; that will be to a higher cost for the
>       spammer, but is still quite likely."

As it says "spammers would still find the remaining 1%."  I wish to destroy 
their ability to find the remaining 1%, or to make it so difficult they 
quit trying.

>Honeypots are not the solution. There are much more prommising Ideas out 
>there.

Go for them - I eagerly await the solution.

>>To really disrupt the spammers may take a number of honeypots equal to or 
>>greater than the number of open relays.  If the numbers were equal then 
>>the honeypots would be expected to be receiving roughly half the spam, a 
>>50% cut in spam volume.  At that level the spammers need only double 
>>their output to keep the same delivery level.  (Someday the headroom for 
>>increasing volume will run out - then nothing the spammers can do will 
>>keep up the volume.)
>
>Does Moore's Law apply to Bandwidth? mine sure has been going up.
>I've heard tell of "A fiber to every room". Maybe that will be part of my 
>2016 campaign if it hasn't already happened by then.
>I sure hope spam isn't still around in 2016.
>
>
>>The prime countermeasure a spammer can take is to stop sending spam to 
>>the honeypot, once he discovers it is a honeypot.
>
>The best possible course of action for the spammer is to hack through your 
>simple security, and turn your "honeypot" into a "zombie cash cow".
>
>
>>If the spammer sends spam to his own address then he probably will use 
>>that same address multiple times.
>
>Not if that is what you are depending on.
>random bot generated free addresses used only for 3 or so runs.

So the spammer finds an IP to not use more quickly.  I don't care.  The 
value of the idea is in the sheer overwhelming number of honeypots, not in 
an isolated few.

In what I'd consider the preferred implementation the ISP would be the one 
intercepting the abuse packets - at the ISP level.  So instead of crossing 
off a single IP as abusable the spammer would have to (when he figured it 
out) have to cross off an entire ISP.  As an example I'd suggest telesp.be, 
who sure need to do something.  This is exactly what they could do and the 
magnitude of the abuse coming their way suggests the magnitude of the 
effect if they'd act against the abuse.

After that the effect is that which comes from it being learned that an ISP 
has, very simply, taken action that forced all spammer abuse away.

>I am only half way through this thing.
>I'm sorry.
>I realy tried to see your logic, I feel dumber now.
>I have read every message on this list since I got here, but I will not 
>continue to read this one. You have not addressed the problems.
>You are "Beating a Dead Horse to Death".

You have read and looked for problems in a specific implementation of what 
I propose.  I propose acting against the abuse spammers commit when they 
send other than direct spam.  It is presented as an idea.

It is preposterous to imply that no effective action can be taken anywhere 
against the abuse spammers commit.  The dead horse, if any, is those who 
will not perceive.

>Please use some logic. Please try to solve the problems we are telling you 
>about before posting another behemoth like this one.
>I can never get that hour back.

So sorry.

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 16 Apr 2003 16:22:04 +0100

>>
>> It strikes me that this might be the most sensible sort of use
>> for honeypots.  So not exactly a "solution" then, but an assisting
>> technology?
>
That was for Brad.
I should have turned the sarcasm dial up further. I thought "mild" would do
it, should have been "pointed". Sorry.

>That reasoning is exactly why a standard configuration of DCC clients
[snip]
>It does not matter whether spammers are doing the obvious and including
>undetectable drop-boxes in their spews.  (It is obviously impossible
[snip]
>no better than Spamfords paid "Bandwidth Partners" and must be treated

Of course.

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 17 Apr 2003 12:20:55 +0100

> So if your proposed change in the measure of
> success is sensible, we might as well all pack up and go home 

This isn't a matter of "measure of success" as such. 
It's a question of "deployability".  

"Solutions" are proposed and evaluated and we have
a guide to requirements for "solutions". 

It's been asserted that this proposal can't meet the requirements 
regarding "incentives to deploy for those doing the deployment"
(or the point re. universal deployment). 
This follows discussion of the technical merits of the proposal,
and of political and commercial realities, here and in other places.

This assertion has not been disproved.  Perhaps a large-scale
experiment would change this. The results of such an experiment
would, I'm sure, be welcomed by the group.

The assertion can't be disproved by counter-assertion. Only
reviewed and reproducible experimental results (evidence)
can do this.

The chair invited Brad to make his proposal and the group has 
commented on it. 

Incidentally, is it my imagination, or has traffic on this list 
come down rather?  I wonder if the packing up and going home has
begun already?