Subject: RE: [Asrg] Whitelisting on Message-ID (Was Turing Test ...) honey pot plug

From: Brad Spencer <[email-masked]>
Date: Mon, 07 Apr 2003 10:53:43 -0500

At 08:32 AM 4/7/2003 -0700, you wrote:

>The second is the important one for me. Some people talk as if all we have
>to do to end spam is close the open relays. I am not so sure this is the
>case.

That (all we have to do to end spam is close the open relays) was the 
belief (apparently) a few years ago.  I doubt few believe it now.

I do believe that if all the abuse paths for sending spam were blocked the 
spam volume would go way down and that (by definition the spammers would 
have to switch to sending their spam directly.  That's easy spam to block 
using blocklists.  (since I say it so glibly it's an automatic candidate 
for disproof.)  Open relays and open proxies are (I think) the current 
most-abused pathways - I'd like to see that abuse ended.  I don't call for 
closing all the open relays (that so far hasn't happened) but for the 
entire open relay pathway to be made so useless to the spammers that they 
abandon it.  As it is increasingly difficult to secure the open relays 
subject to abuse I don't emphasize that approach, although securing an open 
relay is always worth doing.  Instead I advocate creating so many false 
open relays that the spammers can't tell which are truly open and which 
aren't.  right now a honeypot that delivers relay tests (once, or only) 
suffices to deceive the spammers.  As spammers get more sophisticated the 
deceit will have to improve.  Instead of trying to predict in advance all 
the possible ways of overcoming increased spammer sophistication and 
creating a perfect honeypot that combats those I favor quickly creating a 
bunch of really dumb honeypots - those will have an immediate effect.  As 
spammers develop new evasion techniques it will be necessary to deploy some 
honeypots that overcome those techniques.

What should be noted is that in this scenario it is the spammers who are 
trying to keep up, not the anti-spammers.  Every time the anti-spammers 
increase the sophistication of their honeypots they make real open relays 
more threatening to the spammers - the real open relay must be suspected as 
a sophisticated honeypot.  Do the spammers have that fear today?  No - the 
open relays they find are almost certainly real open relays - there is no 
challenge at all to finding and abusing open relays.  It is made perfectly 
easy for them.

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

---

From: Chuq Von Rospach <[email-masked]>
Date: Mon, 7 Apr 2003 09:24:36 -0700

> belief (apparently) a few years ago.  I doubt few believe it now.

I was curious, so I took a quick look. My home system runs no RBLs, no 
filters, I do my spam filtering in mail.app on OS X right now. So I get 
a full feed without anything in the way. About 50% of my inbox is 
flagged as spam, and mail.app now has about a .01 false positive 
(usually e-newsletters from places like Orbitz and Burpee seeds), and 
about a 97% hit rate. Not bad.

But it also allows me to go wander through the spam and look at things. 
I went and looked at 25 random messages that I've gotten since 
midnight. By evaluating headers, I saw 18 came in direct from the 
spammer, or were inserted into the delivery box via an open proxy, 1 
definitely came in through an open proxy, and six came in through open 
relays.

So only about 1/4 of the spam came from open relays.

I looked up the various sites in spamcop, just to see what was in 
there. the one open proxy was also in spamcopy. Of the 18 direct/open 
relay sites, 10 were blocked in spamcop. Of the 6 open relays, 3 were 
blocked in spamcop.

and just for your amusement:

http://spamcop.net/w3m?action=checkblock&ip=212.216.22.67

---

From: Brad Spencer <[email-masked]>
Date: Tue, 08 Apr 2003 07:45:29 -0500

At 09:19 PM 4/7/2003 -0600, you wrote:

>Be careful what you wish for. A spammer who can't tell an open relay from a
>fake one might become a script kiddie. There by compromising Cable/DSL modem
>residential users to send the spam. Then there are department stores with
>Internet connections which you can:
>
>-Insert spammer CDROM.
>-Turn off computer.
>-Turn on computer.
>-Leave department store.

I'm sorry, I don't see the problem as being fatal.  I don't doubt that 
spammers may do all number of things that are wrong but I can't see how 
that leads to the conclusion that you should just let them do what they are 
now doing.  If you believe the spammer response to losing the open relay 
pathway to send spam might lead them to start hacking computers instead I 
can't say you are wrong - I tend to think the same thing.  That, though, is 
real offense - for that existing laws would, I think, put the spammers at 
risk.  There's no fiction anymore that the spammers aren't breaking any 
laws, aren't committing abuse (I imagine the spammers tell themselves that 
if someone runs an open relay he implicitly authorizes its use by anyone.)

Once there is evidence that an IP is the source of abuse of the type you 
suggest I'd think the possibility exists that a search warrant could be 
issued to monitor all packets from that IP.  If the spammer escapes that by 
doing the department store trick he's going to have one or two free shots 
and then the department store security is going to get much tougher and the 
spammer will risk having videotape made of his next attempt to steal 
service at the department store.  If a spammer needs 190 servers I don't 
think he's going to hit 190 department stores.

Before he begins to rely on the department store trick I think the spammer 
is more likely to try a Trojan horse approach or try rooting home systems 
through a long proxy pathway (so he's hard to trace.)  The Trojan horse, 
once analyzed and understood, gives a beautiful way to combat the spammer - 
instead of waiting to be tested (as you must for a regular honeypot)  you 
simply "phone home" to the spammer's system and tell him your system has 
been Trojaned.  He sends you the spam, you throw it away.

Speculation can go on forever.  Spammers do send relay tests and do make 
themselves vulnerable thereby.  Same for open proxy tests.  There's no 
subtlety - they just send the tests - all over, every day.  Do some 
spammers specialize in testing one part of the IP space, others specialize 
in testing other parts?  I can guess but I don't know - the data is 
incredibly sparse even though it is tremendously easy to collect.

---

From: Brad Spencer <[email-masked]>
Date: Tue, 08 Apr 2003 09:36:52 -0500

At 08:43 AM 4/8/2003 -0600, you wrote:

>I agree it's not fatal, just pushing the problem somewhere else. I believe
>technical solutions are better than legislative ones. The ISP eventually has
>to do something after more of their CIDR blocks find there way into an RBL.

Honeypots are a technical solution.  They work in conjunction with 
blocklists.  They are a "something more" done by an ISP or by individuals 
who wish to eliminate spam.  They're an action taken by the clueful to make 
harder exploitation of the clueless.  They work.

If action against some form of abuse can't be taken because the spammers 
will just go to a different form of abuse then isn't it time to give 
up?  Maybe it's time to add one or more additional requirements to the 
existing list:

o  Must stop spam so effectively that the spammers don't try anything else.
o  Must be technical, must not rely on any law enforcement activity, must ...

I see:  have so many restrictions that ending spam is indeed 
impossible.  Is that the ASRG task: to so restrict solutions that no 
solution is possible?  Interesting.  I object.

I've got an anti-spam method that works without needing any change to 
existing protocols, is 100% efficient - no false positives, no false 
negatives, is economical of compute resources, is widely applicable, has a 
multitude of possible utilizations, has three year's history of 
effectiveness and the response is that it's not usable because if it is 
used the spammers will do something else.  If that's the way it is it is 
past time for me to say goodbye but for a while I'll try to convince people 
that it is possible to take action where none is taken and that that action 
will provide great benefits, if the goal is to help end spam.

Sorry if I'm brittle but if ASRG is just NANAE all over again there's no 
point  in my continuing.

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 8 Apr 2003 15:40:06 -0400

At 9:36 AM -0500 4/8/03, Brad Spencer wrote:
>I've got an anti-spam method that works without needing any change 
>to existing protocols, is 100% efficient - no false positives, no 
>false negatives, is

You have an idea.  When asked to document it, provide the numbers, 
and indicate how it would be deployed, you never answered.  There's 
some software here, there's another example there.  It's still 
manual.  But anyone can run it if they have spare time and a spare 
machine and some spare IP addresses.  That's not a proposal.  Until 
there's a concrete proposal you aren't going to get any support.

I'll say again what I said before.  If the system is safely 
deployable and automatic, then I'd very much like to try running it 
(if only as a way of sampling spam).  That's more support than you've 
gotten from anyone else on this list.  But to date you haven't 
provided a convincing argument that such a goal is feasible (or that 
you consider such a goal desirable).  I'm not asking for 
software--but respond to some of the issues with an organized plan 
for how it would work.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 8 Apr 2003 20:54:28 -0400

At 5:41 PM -0500 4/8/03, Brad Spencer wrote:
>At 03:40 PM 4/8/2003 -0400, you wrote:
>
>>You have an idea.
>
>That's what I am presenting.  In engineering the idea precedes 
>implementation.  I deliberately don't describe implementation - why 
>is that such a problem?

Read what I wrote.  I didn't ask you to describe an implementation.

>Here's an IDEA.  Examine it.  It has great power to stop a huge 
>portion of today's spam.  Assume I've overlooked something even more 
>powerful than a web

You keep saying that.  But you've made no attempt to respond to any 
of the people who have pointed out problems with the idea.  You just 
keep repeating the idea.

---

From: Brad Spencer <[email-masked]>
Date: Tue, 08 Apr 2003 20:31:40 -0500

At 08:54 PM 4/8/2003 -0400, you wrote:

>You keep saying that.  But you've made no attempt to respond to any of the 
>people who have pointed out problems with the idea.  You just keep 
>repeating the idea.

I think I have responded.  I apologize for my brittle attitude but I have 
been through this process once already.  Every idea has problems but many 
ideas are accepted and implemented with far less information supplied than 
what I give.  Please see the reply I just posted - I go over it again.

If I give implementation details then people probably can find 
quibbles.  I've done this for three years - the quibbles don't impress me 
in face of my success.  Others have done it for a year, still others for a 
shorter time.  Michael Tokarev in Moscow knocked hell out of Alan Ralsky 
for a while.  That didn't get much publicity at the time: why risk tipping 
off Ralsky by bragging about trapping Ralsky's spam while it was still 
happening?  Only some of his spam was trapped, of course - Ralsky has 190 
servers, the one honeypot in Moscow wasn't collecting it all.  But it may 
be that that one honeypot did bring all of Ralsky's Dallas servers to a 
halt because the one honeypot got all the throwaway dialup accounts Ralsky 
had terminated.  I can't call Ralsky and ask - I have to guess.  People did 
say in NANAE that they weren't getting Ralsky spam at the same time.

The quibble I can remember right now is that if you do this and it works 
(note WORKS) then the spammers will move to a different form of abuse.  In 
other words, it's hopeless.  How am I supposed to handle that?  In fact I 
can*, but when do people start looking at the idea and thinking about what 
it means and how they'd use it instead of submitting me to a 3rd degree 
interrogation?  It's simple: set up a system with no email function that 
accepts relay email.  That's the entire basis of the idea.  You don't want 
to be an open relay, so don't be - don't relay anything, just capture what 
comes.  You can act against spammers just on the basis of their relay tests 
- you should capture relay tests because almost certainly spammers are 
attempting them for that IP.

If you go one step further and deliver a relay test, in a timely fashion, I 
hope keeping a copy, then you should receive spam as a result.  That is 
spam that otherwise would have gone to a real open relay and would have 
been delivered.  Don't deliver it.

If a spammer figures out it's a honeypot then wait for the next spammer to 
find you.  If he doesn't continue to deliver relay tests for him (at least) 
and continue to not deliver spam.  Send appropriate complaints based on the 
spam you receive.  If you want and can, change the IP of the honeypot if it 
is discovered - that forces the spammer to do it all over again, if he 
continues to test in your range.  You coast, he works.  That's a small win 
but it is a win.

Better yet, create and run an open proxy honeypot.  There's a much greater 
chance (these days) that the spammer will connect to the honeypot directly 
from his own IP, which you will learn.  Then you have evidence of abuse to 
show his ISP.

In the other posted reply I have a link for GypsyProxy.  I've only run it 
once, I can't vouch for it.  It seems to be a  good idea.  I don't doubt a 
better idea is possible - I thought that was the focus of ASRG - better ideas.

When spammers develop countermeasures the challenge will be to defeat 
them.  Why is it required to anticipate everything they might do (and 
haven't yet done, based on successful evidence) in order to get the ideas 
considered?

Thanks again for your reply -  I continue to appreciate your interest.
--

*If honeypots work so well that spammers must move to a different form of 
abuse the entire picture will be different.  For honeypots to do that there 
have to be a lot of them.  If there's a lot of them then many people will 
be working to defeat relay spam.  If they defeat relay spam they'll know 
it, and thereby know they can, working together, end a form of abuse.  The 
expectation should be that, if there's a new form of abuse, a large number 
of people, working together, can make that end as well.  (This discussion 
is probably 95% accurate.  someone surely can find a quibble.  It is not 
productive to devote all energy to finding quibbles, is it?)

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 9 Apr 2003 10:06:22 +0100

On Wednesday, Apr 9, 2003, at 02:31 Europe/London, Brad Spencer wrote:

> Better yet, create and run an open proxy honeypot.

I don't see how an open proxy honeypot would work. With an open relay 
honeypot you can deliver the test message at any later time. An open 
proxy probe is realtime.

Matt.

---

From: Brad Spencer <[email-masked]>
Date: Wed, 09 Apr 2003 05:49:22 -0500

At 10:06 AM 4/9/2003 +0100, Matt Sergeant wrote:

>honeypot you can deliver the test message at any later time. An open proxy 
>probe is realtime.

  The open proxy may get two types of use: the spammer may try to test 
other IPs through it to see if they are open relays or he might try to send 
spam through it to known open relays.  The second is easy: simulate 
acceptance by the other IP of the email - the spammer is happy, the spam 
becomes trapped on the open proxy honeypot.  The same almost works for the 
first case but the spammer never receives the test message - it's a 
NOP.  For open relays the spammer sends a message to himself - there's two 
data points that tell him the IP is an open relay: the IP accepts the test 
message and the IP delivers the test message.  For a proxy the spammer just 
checks to see that it looks like he reaches something else though it - I've 
logged empty SMTP transactions (HELO, QUIT) from large numbers of IPs that 
are probably the SMTP end of proxy tests.  If the proxy connects to a SMTP 
honeypot it will look open to the spammer, it will look successful to the 
spammer when he sends spam (if he doesn't check delivery in any way.)

If the spammer is trying to send direct to the destination through the open 
proxy that's still SMTP and the SMTP honeypot connected to the open proxy 
honeypot still deceives.

As a bonus you may learn the spammer's own IP, if he connected to you 
direct instead of through another open proxy (some spamware provides for a 
chain of proxies.)  To be complete (third type) it looks like the open 
proxy honeypot might need to simulate proxy operation at a target IP as 
well as simulate SMTP operation there.  The main point is that if you have 
the spammer's IP that plus what you trapped is solid evidence he is 
committing abuse - his ISP should nuke him. Note that if there are open 
proxy honeypots the spammer increases the chance he'll hit one if he uses a 
chain of proxies. His chance of hitting a proxy honeypot first, from his 
own IP, stays the same but he has a higher probability of failed spamming 
through a chain of proxies, about in proportion to the length of the 
chain.  I'd guess for US spammers that use a chain of proxies the first 
proxy would typically be offshore, Brazil being a good guess as to where.

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 9 Apr 2003 12:17:41 +0100

On Wednesday, Apr 9, 2003, at 11:49 Europe/London, Brad Spencer wrote:

> other IPs through it to see if they are open relays or he might try to 
> send spam through it to known open relays.

This is a bogus assumption. It's much easier to test an open proxy by 
testing it can connect somewhere you own, not check that you can relay 
mail through it. I have no idea why a spammer would try the latter 
since it's much *much* slower. Or you'd even test it can access a known 
web site, like google.

Can you explain why a spammer might try an email first rather than just 
check the proxy is functioning?

Matt.

---

From: Brad Spencer <[email-masked]>
Date: Wed, 09 Apr 2003 06:32:16 -0500

At 12:17 PM 4/9/2003 +0100, Matt Sergeant wrote:

>mail through it. I have no idea why a spammer would try the latter since 
>it's much *much* slower. Or you'd even test it can access a known web 
>site, like google.
>

Sorry, I didn't read the whole thing.

I can't explain, but all he did was HELO and QUIT, no message.  It makes 
some small amount of sense to verify you can get through the proxy to port 
25 someplace, I suppose, but for the real answer you'd need to ask Mr. Spammer.

It was a doubly dumb thing for the spammer to do.  First dumb is that of 
all the IPs he could have picked he picked mine, where I pay attention to 
the logs.  The second dumb is that my MTA is old and stupid - it can only 
listen to one source at a time.  At the time of these tests the MTA was 
also busy accepting relay spam so the testing spammer would have to wait 
until that long, long transaction finished to make his connection.  That 
was delayed.  As he surely did it using an automated procedure the effect 
was just one of inefficiency - he didn't lose personal time.

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 9 Apr 2003 13:02:26 +0100

On Wednesday, Apr 9, 2003, at 12:32 Europe/London, Brad Spencer wrote:

> I can't explain, but all he did was HELO and QUIT, no message.  It 
> makes some small amount of sense to verify you can get through the 
> proxy to port 25 someplace, I suppose, but for the real answer you'd 
> need to ask Mr. Spammer.
>
> It was a doubly dumb thing for the spammer to do.  First dumb is that 
> of all the IPs he could have picked he picked mine, where I pay 
> attention to the logs.  The second dumb is that my MTA is old and 
> stupid - it can only listen to one source at a time.  At the time of 
> these tests the MTA was also busy accepting relay spam so the testing 
> spammer would have to wait until that long, long transaction finished 
> to make his connection.  That was delayed.  As he surely did it using 
> an automated procedure the effect was just one of inefficiency - he 
> didn't lose personal time.

That still doesn't explain how you can build an open proxy honeypot. 
This is still about an open relay honeypot. Please explain in terms of 
*just* an open proxy honeypot.

Matt.

---

From: Brad Spencer <[email-masked]>
Date: Wed, 09 Apr 2003 07:42:06 -0500

At 01:02 PM 4/9/2003 +0100, Matt Sergeant wrote:

>That still doesn't explain how you can build an open proxy honeypot. This 
>is still about an open relay honeypot. Please explain in terms of *just* 
>an open proxy honeypot.

It's a proxy server that doesn't do as it's told.  All connection attempts 
through it to port 25 anywhere are diverted to an SMTP honeypot.  I suppose 
the SMTP honeypot code could be internal to the open proxy honeypot - 
that's a detail.

The spammer connects to port 4080 of the honeypot, says connect to port 25 
of some server.  The honeypot changes that to be a connection to a 
honeypot's port 25 and let's it through.  Everything works but the spammer 
never gets beyond the honeypot space.  If the spammer tries something else 
either it is allowed or it isn't.  If allowing the other connection is 
unsafe then don't do it.  If the connection attempt is to a proxy port 
elsewhere intercept it, handle it locally.  Make what the spammer sees look 
like he is succeeding in what he is trying to do but make it not 
succeed.  In all probability it's an automated tool that makes no checks on 
the reasonableness of the results.  Why would it?  The spammers for years 
have been free to abuse.

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 9 Apr 2003 12:38:56 -0400

At 7:42 AM -0500 4/9/03, Brad Spencer wrote:
>what he is trying to do but make it not succeed.  In all probability 
>it's an automated tool that makes no checks on the reasonableness of 
>the results.  Why would it?  The spammers for years have been free 
>to abuse.

At the MIT Spam Conference, Praed said that he felt the best way to 
evaluate the effectiveness of an anti-spam solution was to see how 
well it dealt with evasion.  I agree.

That's the major flaw with the honeypot solution.  It deals very 
poorly with evasion.  As soon as honeypots become a problem, spammers 
will begin to write more sophisticated tests that try and detect 
honeypots.  Mind you, they don't have to be terribly sophisticated. 
Here's the simplest one.

- test by sending several thousand of spam messages

Sure, it takes a little more time--a few minutes probably.  But 
that's not a big deal.  Then you check your trap accounts that were 
hidden in the recipient list.  No spam--it's a honeypot.

And the honeypot operator is screwed.  Either he delivers several 
thousand spam messages (and probably gets nailed by his ISP), or he 
gets blacklisted by the spammers.  End of story either way.

I don't see any way you can deal with this.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 9 Apr 2003 10:59:09 -0700

On Wednesday, April 9, 2003, at 09:38  AM, Kee Hinckley wrote:

> honeypots.

I posted an easy way to get around honeypots the other day -- regular 
tests. Easy to do using a small array of captive accounts, hard to 
catch.

Any solution that's so easy *I* can pull a way to isolate it off the 
top of my head is something not worth spending energy implementing, 
because it's a solution that works only because spammers haven't had 
enough hassle from it to work around it. That's not even an arms race, 
that's throwing snowballs at a tank. It'd take us a lot more time and 
energy to build up a honeypot system annoying enough to amek them 
notice than it'll take for them to build a system to make that honeypot 
system useful only against stupid spammers.

So IMHO, it's a bad place to spend our energy, but it won't even slow 
down the smart spammers, and we don't need sophisticated tools to catch 
stupid ones.

---

From: Brad Spencer <[email-masked]>
Date: Wed, 09 Apr 2003 13:05:23 -0500

At 12:38 PM 4/9/2003 -0400, Kee Hinckley wrote:
>>what he is trying to do but make it not succeed.  In all probability it's 
>>an automated tool that makes no checks on the reasonableness of the 
>>results.  Why would it?  The spammers for years have been free to abuse.
>
>evaluate the effectiveness of an anti-spam solution was to see how well it 
>dealt with evasion.  I agree.

I'm not sure of "best," but that doesn't matter.  It's a very good concept.

>That's the major flaw with the honeypot solution.  It deals very poorly 
>with evasion.  As soon as honeypots become a problem, spammers will begin 
>to write more sophisticated tests that try and detect honeypots.  Mind 
>you, they don't have to be terribly sophisticated. Here's the simplest one.
>
>Sure, it takes a little more time--a few minutes probably.  But that's not 
>a big deal.  Then you check your trap accounts that were hidden in the 
>recipient list.  No spam--it's a honeypot.

Right.  Early on I looked for duplicate recipient addresses, thinking 
they'd know to do just what you say but would re-use the same address.  I 
never found a duplicate.  "The Mushroom Guy" has captured spam for over a 
year - they don't (as a whole) do the smart thing.  Michael Tokarev trapped 
Ralsky spam from February to July last year.  Ralsky didn't do the smart 
thing - he went dumber, and sent himself spam delivery reports via the 
honeypot, which Michael delivered.  Michael had an advantage: he manually 
checked every putative test message his software identified and only 
delivered those he thought should be delivered.  If it came down to the 
honeypot operator sometimes having to manually intervene then I'd still say 
it was an acceptable solution.  I didn't change the recognition part of my 
crude prototype server/honeypot much at all during the last year I ran that 
way.  I see people all concerned about dealing with encrypted spam, 
changing checksums, etc.  Doesn't matter to me: if they relay it through 
the honeypot I know what it is.  My point: even if some work is necessary 
that isn't unique to honeypots.  Dealing with evasions is impacted most by 
the fact that so few honeypots are in use that the evasions don't show.  To 
me the bottom line fact that favors the honeypot operator is that the 
spammer cannot send a stealth relay test message.  To find open relays the 
spammer must look for them and he must look by sending a message that can 
be traced back to that spammer.

In addition relay spam email traveling through of, oh, heck, 
Rackspace-assigned IP space should stick out at least as bulk email just 
from it's pattern.  If the packets were analyzed enough to see the 
destinations of the email these would show as not being related to the IP 
addresses the email was going to, for relay spam.  Presto: it's seen to be 
spam.  similarly, if the spam is targeted first on proxy ports.  If 
telesp.br watched incoming packets to proxy ports they'd see packets to a 
lot of their IPs coming from one or a few other IPs.  They could then act - 
it isn't necessary for their customers to secure the open proxies for the 
abuse to be stopped.  None of this paragraph is honeypot, it's just the 
same idea: go after the abuse.

>And the honeypot operator is screwed.  Either he delivers several thousand 
>spam messages (and probably gets nailed by his ISP), or he gets 
>blacklisted by the spammers.  End of story either way.

That's the honeypot operator.  Recall that I am selling an idea, and part 
of that idea is for ISPs to watch for the patterns characteristic of open 
proxy and open relay abuse and act when abuse is found.

Jackpot won't deliver several thousand test messages - it has strict timing 
limits to avoid the abuse you describe.  The spammer that tries that will 
discover the honeypot and blacklist it.

My first thought, way back when I started this, was that the spammer would 
discover the honeypot and would blacklist it.  Several times I thought that 
had happened, that at last no more spam would come.  Inevitably some other 
spammer sent spam - I had spam last February.  I delivered a test today - 
more than an hour after it came - I'll see if that draws spam.

Returning to the blacklisting I thought would happen, I planned the next 
step to be a change of the honeypot IP (I had a /22 at my disposal.)  The 
hope would be that the spammer would eventually blocklist the /22.  Then 
I'd persuade the campus to run honeypots and get the entire campus 
blacklisted by the spammers.  Then all of .edu, then all of 
everything.  Being blacklisted by the spammers doesn't scare me - it's 
still a win.  Stopping the spam on the honeypot is just one aspect of the 
idea and isn't the essential part of it.  For me it never got to the point 
where I felt I was spammer-blacklisted.  Spammers being as they are you can 
bet that, if they in any way supplied relay IPs to other spammers, they'd 
supply the blacklisted IPs as part of the list - a little joke.

>I don't see any way you can deal with this.

See above.  So far there are no reports from anyone doing honeypots that 
they are idle.  I don't deliver relay tests on my home system (DSL), it 
gets few test hits.  As I post about honeypots in NANAE with my 
NNTP-posting-host visible it isn't hard to imagine that at least my 
honeypot is blacklisted.  I think that you are correct, that when honeypots 
become numerous the spammers will try to defeat them.  Recall again I am 
proposing an idea, not just one technique based on the idea.  Also recall 
that I want action taken against spammers who send relay tests by the ISPs 
selling service to those spammers.  Actually, I advocate any legal action 
taken by anyone against those who send such tests.  That can't be done in a 
stealth mode.  As I replied to Chuq, if he's really paranoid he could do as 
little as  run a secure sendmail on an otherwise-mail-idle system and 
detect relay tests in the sendmail logs.  One guy doing that is, um, OK, 
useful, something.  A good thing, not significant.  Ten thousand guys doing 
it is more of a real effort, is something that can have a substantial 
effect.  The honeypots may lose sometimes to some spammers.  The idea as a 
whole should not lose.  You can catch and report people doing open relay 
tests and open proxy tests.  At the ISP level you should be able to detect 
such abuse originating in your own space, you should be able to detect such 
abuse coming in to your own space.

I can say that the current prevalent practice, do nothing at all, is a 
failure.  It doesn't even push the spammers into doing evasion.

ASRG could make recommendations to ISPs of best practices for keeping clean 
and keeping spam abuse packets out (or quickly whacking those that send 
spam abuse packets.)  That's far beyond honeypots.  An ISP could run 
something as simple as ntop and send the URL to the ISP from which abuse 
was coming.  If the ISP of origin nuked the account and the spammer 
switched to a new IP that new IP would quickly percolate to the top of the 
ntop display and could again lead to a nuke.

ntop probably can't handle the full traffic of an ISP.  It should be able 
to handle portions of that traffic at a time.  Besides, ntop is the 
low-level application I know of - I'm no expert.  What would the experts 
recommend for watching traffic on a subnet in order to find the suspicious 
traffic?

---

From: Brad Spencer <[email-masked]>
Date: Wed, 09 Apr 2003 13:34:08 -0500

At 10:59 AM 4/9/2003 -0700, Chuq Von Rospach wrote:

>>to write more sophisticated tests that try and detect honeypots.
>
>tests. Easy to do using a small array of captive accounts, hard to catch.
>
>Any solution that's so easy *I* can pull a way to isolate it off the top 
>of my head is something not worth spending energy implementing, because 
>it's a solution that works only because spammers haven't had enough hassle 
>from it to work around it. That's not even an arms race, that's throwing 
>snowballs at a tank. It'd take us a lot more time and energy to build up a 
>honeypot system annoying enough to make them notice than it'll take for 
>them to build a system to make that honeypot system useful only against 
>stupid spammers.
>
>So IMHO, it's a bad place to spend our energy, but it won't even slow down 
>the smart spammers, and we don't need sophisticated tools to catch stupid ones.

Obviously you are smarter than the spammers, Ralsky in particular.  See my 
recent reply for more.   I suspect I know things about some spammers that 
no one else here knows.  That's because I trap relay tests.  Whether the 
spammers sending the tests are smart or dumb I can't say.  I didn't have to 
be at all smart to catch their tests - nobody does.  They aren't smart 
enough to be able to find open relays without sending open relay 
tests.  (Creative use of DNSBLs excepted, but that doesn't discover new 
open relays.)

I  responded to your earlier post, I think, by saying that just watching 
the spammer relay tests is an important function, currently not done, and 
(IMHO) worth the time of those here.  I do it by trapping the tests: 
spammers could learn what that means and no longer test IPs that accept 
tests but don't deliver them.  I specifically said in my reply that one 
could run a secure sendmail on a dedicated system and pull much of the 
information about the spammer tests from the logs (source IP and dropbox 
address.)  Spammers could stop testing those, too.  Pretty soon the 
spammers run out of IPs to test, and if they are looking for NEW open 
relays they have to test IPs that they don't know about or give 
up.  Honeypots can be waiting at some of those new IPs.   And, be honest, 
if spammer A finds a honeypot will he tell spammer B that it is (a) a 
honeypot or (b) an open relay?

What you propose has been anticipated, is the first thing I looked for when 
I first collected spam.  I've discussed that topic with someone else in 
this list long ago and we agreed on how sneakily the spammer could do the 
tests.  So far no test I've received has shown the sneakiness.   Fred Woods 
has worked on a database for spammed addresses, so that if your test idea 
worked for the spammer he'd have to create a new throwaway for each 
test.  It wouldn't  do for him to send the tests to random names in his own 
captive domain - that would be detected very quickly.  First, though, the 
spammers have to get smart enough to do these things for there to be 
reports of success in defeating the evasion.

Energy has already been spent implementing honeypots and everyone who 
reports results reports positive results.  I think I have the worst results 
of anyone in terms of captured spam.  Not too surprising when you recognize 
that I don't deliver most relay tests.  I propose no change in any 
protocol, nothing that requires any email operator to do anything 
different, nothing that requires MTAs to be changed in any way.  That in 
itself makes this a very good solution, if its benefits are adequate.  That 
means it can be implemented quickly, that means there is no lag in its 
effectiveness due to reticence or neglect on the par of email 
operators.  It works from day one.  The more honeypots there are the 
greater the effect of its working.  When the effect is great enough to 
cause significant spammer grief then yes, I also anticipate evasion.  None 
of that evasion will be secret - they have to show exactly what they are doing.

It is also possible that they'll go with dedicated Trojan Horse relays, as 
some are already using.  That's a different kind of abuse, that will take a 
different effort.  Must I also solve that problem for honeypots to be 
considered?  If the honeypots aren't done it doesn't matter - the spammers 
will have open relays and open proxies to abuse - who need the Trojan 
Horses?  If it's a technical solution that is wanted then the effort better 
be quick or the DMA will get a law through Congress that makes the 
technical solutions irrelevant.  (Maybe I'm wrong, but maybe I'm right.)

My larger objection is that you say to reject the entire idea based on 
postulated defeat of one aspect of one implementation of the idea.  It is a 
very good idea, one it is (and has been) foolish to ignore.  Starkly 
stated, the choice is to allow the spammers to commit abuse with nothing 
done to stop them or to act to stop the abuse.  The current choice, for 
most, is to allow the spammers to commit the abuse.  No matter how it is 
rationalized that is a bad choice, that is the wrong choice.  Where's the 
good idea in ASRG to make mine unnecessary?  Nowhere - you are spinning 
your wheels.

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 9 Apr 2003 16:34:48 -0400

At 1:34 PM -0500 4/9/03, Brad Spencer wrote:
>>So IMHO, it's a bad place to spend our energy, but it won't even 
>>slow down the smart spammers, and we don't need sophisticated tools 
>>to catch stupid ones.
>

Don't assume spammers are dumb because they don't avoid blocks.  A 
*far* better assumption is that the blocks haven't become a 
significant problem.  So far they have quite easily adapted to 
existing block techniques as they've been developed.  Open relays, 
open proxies, randomized wording, hidden html to screw up word order, 
encoded text using javascript, headers that mimic existing email 
clients, domains that resolve the the relay... we've seen no 
shortages of evasive techniques.  Any anti-spam solution needs to 
look *both* at how things are now, and how they will be if the system 
is deployed.  Most of the systems I've criticized on this forum 
looked only at the end-game and not the transition period.  I think 
this proposal swings too far in the other direction :-).

>My larger objection is that you say to reject the entire idea based 
>on postulated defeat of one aspect of one implementation of the 
>idea.  It is a

No.  What we ask is that someone who proposes an idea thinks about 
how it will react to the spammers when they react to it.  Ideas that 
assume spammers are dumb need more work.  I happen to believe that 
there isn't an easy solution to spammers attempting to detect open 
relays and proxies.  But I'm quite willing to hear proposals.  What 
worries me is when someone makes a proposal that assumes that the 
spammer won't react.  If we're going to propose that lots of people 
implement a particular solution, we want to be sure that that 
solution provides more than just a temporary respite.  You don't get 
that many chances to ask everyone to install new software (even if 
you're Microsoft :-).
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society