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

From: "John Fenley" <[email-masked]>
Date: Tue, 15 Apr 2003 18:06:43 -0600

>From: Brad Spencer <[email-masked]>
>At 02:48 PM 4/15/2003 -0600, John Fenley wrote:
>>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.

No it doesnt...
It is all automated.

>Forget honeypots.  Spammers send spam through abusable systems everywhere.

Agreed.

>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.

Incorrect, that means that as long as other systems exist, there will be 
abuse.

Stopping one form just makes spammers adapt.

>>3. send even more spam through the real open relays.
>
>Yes.  But we coast, they struggle.

No, we struggle, they coast.
They have cheap automated systems to do all their work for them.

We, on the other hand, would have to set up potentially hundreds of 
thousands of honeypots to make any difference to the automated systems.
And even then all spammers have to do is wait a little longer for their 
system to find an open relay.

It is a supremely flawed idea with no forseeable fixes.

>>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.

Saying things to the effect of "all spammers ______", whatever that blank 
is, underestimates the human ability to adapt.

>>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.

Yes, I know. Everyone knows.

We must not give spammers an easy slope to climb.
If they realy become proficient in adapting to our solutions then we are 
hosed.

In order to win this we must hit them all of a sudden with something that 
will work perfectly, and stop them dead in their tracks. something that they 
won't be able to defeat easily using any sort of automated system.

If they are used to getting around things, it will just be that much easier 
for them to adapt in some other way. The chances that they will defeat the 
final(near term) solution go up if they have practice.

>>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.

It doesn't matter wether honeypots use existing protocols. They don't solve 
the problem.

>>>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.

Oh my...
Do you actually think that the spammer is actually sitting at a computer 
looking at a screen full of IPs trying to figure out which ones are real?

Automated systems do all that for them. all that happens is the conputer 
takes longer to find a real relay, they find it just the same.

Once they find enough real open relays they only need to search for more if 
one they are using goes down!

This takes NO EFFORT!!!
THEY DO NOTHING!!!

>
>>>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.

You won't be able to do that with honeypots.
There is a method I can think of that would solve the problem of open 
relays, but it would be unethical.

>>>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.

A zombie is a system under the control of a third party without the owners 
consent. I am suggesting that with many honeypots around on the internet 
with good connections, there is a chance that spammers would use them as a 
source of email. Without you knowing it they compromise the system, and use 
it to send the spam, while reporting to you that everything is normal.

With an overwhelming number of honeypots it would be easy for spammers to 
find systems with bad security to zombify.

I wish you the best of luck building a better honeypot.
John Fenley

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

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

---

From: Brad Spencer <[email-masked]>
Date: Tue, 15 Apr 2003 20:26:25 -0500

At 06:06 PM 4/15/2003 -0600, John Fenley wrote:
>>>1. using a test address to detect honeypots.(there are an infinite 
>>>number of addresses available, they will not run out.)
>>

Not yet.  Code doesn't write itself, code doesn't distribute itself.  They 
don't have it.

>Incorrect, that means that as long as other systems exist, there will be 

Look.  Believe what you will but I've seen damage to spammers from 
honeypots, I've caused damage to spammers.  They aren't all programming 
geniuses.  Many know that if they run the program that finds open relays 
that program tells them which tested systems are open relays - the systems 
that delivered the automated tests.  There is no intelligence or 
sophistication for most or all spammers: they test, their test is 
delivered, they conclude the IP is an open relay, they trust that.  Maybe 
way off in the future all spammers will be smarter but honeypots (which I 
will again emphasize are not the only way to combat spammer abuse) work today.

>Stopping one form just makes spammers adapt.

Fine.  Either they go somewhere else where they are potentially just as 
vulnerable or they stay on their own IPs where they are vulnerable to 
blocklists and any other method any other person creates to stop direct 
spam.  If they go somewhere else its still abuse and still can be combated 
by anti-abuse techniques.  If you postulate large areas where they are 
invulnerable then you postulate that ASRG hasn't done its outreach 
well.   Fine - but then the failure is ASRG outreach, not attack on abuse 
(including honeypots.)

>They have cheap automated systems to do all their work for them.

And we have cheap automated systems to do all our work for us.  We 
outnumber them by what - 1000 to 1?  Who is coasting?  ("We" = people who 
want spam stopped and will act to help stop it if the action is worthwhile.)

>system to find an open relay.

No, they have one hell of a time characterizing each honeypot,even if 
honeypots are the sole technique used.

>It is a supremely flawed idea with no forseeable fixes.

Not proven, just claimed on the basis of shallow analysis.  Yes, you're 
convinced, but you started out wanting to be convinced.

I've not enumerated even the honeypot ideas I know.  You, I suspect, have 
enumerated none.  I keep saying this is put forward as an idea, not as a 
final solution: act against the abuse used by spammers.  That doesn't say 
"honeypots and only honeypots."  It doesn't say "only open relay abuse."

>>>addresses for spammers to use.

Tell MAPS, tell SPEWS, tell ORDB.

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

They can buy service elsewhere.  Guess what: when they send spam pretty 
quickly the IPs show up as spam sources.  Block those IPs.

>>>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.
>>

And yet many use RBLs and praise them.  Not my area, but they aren't proven 
totally useless.

>If they realy become proficient in adapting to our solutions then we are 

I have argued for two years that we have given them a downhill run when it 
comes to finding open relays.  Telling the spammer your server doesn't 
relay is ALL YOU NEED TO TELL HIM, TO HIS BENEFIT.  He knows, he keeps 
looking until he finds a system that delivers his test message (and doesn't 
say "550 we do not relay."  THAT is automated and that they use on a 
routine basis.  So yes, they do find new open relays.  It is easy, cheap, 
risk-free.  Nobody does anything about it.  It is behavior that is so 
cheerfully tolerated that some ISPs DO NOT KNOW WHAT I AM TALKING ABOUT 
when I report a spammer relay test:  (Shrug.)  "It's just somebody probing 
for a weakness."  And then they complain because spam gets through to them 
that is too hard to distinguish from real email so it gets delivered to the 
user.  They threw away a chance to stop spam when it was completely easy to 
detect and then fumble when the spam shows up again, harder to 
detect.  Stop the spam at the relay level and you don't need any filter to 
identify the spam.  You know it is spam because it came to you.  No valid 
email comes that way, not to the honeypot.

>will work perfectly, and stop them dead in their tracks. something that 
>they won't be able to defeat easily using any sort of automated system.

Prove all of that.  I say they can be greatly wounded by hitting them with 
a wave of absolutely simple and stupid honeypots, if it is done quickly 
enough.  Learn their evasion techniques from those and deploy the next wave 
of smarter ones.

>If they are used to getting around things, it will just be that much 
>easier for them to adapt in some other way. The chances that they will 
>defeat the final(near term) solution go up if they have practice.

I don't really understand that statement but I'll assume it's 
anti-honeypot.  I'll pretend I haven't seen all the ways spammers have 
gotten around earlier things and pretend that if they get around honeypots 
that will be their first time - they'll learn from that that they can do it.

>>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.
>
>It doesn't matter wether honeypots use existing protocols. They don't 
>solve the problem.

In the first place at this level of discussion whether or not the solve the 
problem is not germane.  The question is whether they contribute enough to 
be worthwhile - the ask is to find a solution, perhaps made up of several 
coordinated approaches.  What's in the hopper so far to compete with 
honeypots?  Honeypots require no RFC procedure, no modifications in 
protocol - they can go now.  What else is in the hopper that will 
contribute enough to be worthwhile?   (I can think of at least one 
contender, one existing technique that could be analyzed and proposed as a 
universal destination-level protection.)

>>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.
>
>Oh my...

No.

>Once they find enough real open relays they only need to search for more 
>if one they are using goes down!
>
>This takes NO EFFORT!!!
>THEY DO NOTHING!!!

Only in a hypothetical future in which the spammers have done the design 
and implementation to do the effortless defense you claim defeats 
honeypots.  SO FAR, after THREE YEARS, I still trap spam and my honeypot is 
simpler and dumber now than ever before.  In addition I post about it.  I 
don't readily reveal the IP but it's not that huge a secret.  So I stack my 
real experience up against your conjecture about a possible future that is 
reached by some amount of work by the spammers and in which their grand 
defense strategy is to not to try to relay through the honeypot.  Hello: 
isn't that what I wanted from day one?  To bad you can't ask Alan Brown how 
many times I told him that it looked like the spammers had me all figured 
out - the spam had stopped.  and then ...

>>>>RFC 2505 says that securing open relays is not an approach to ending spam.
>>>>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.
>>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.
>

At this stage of the process no decision has been made that honeypots are 
the best implementation of the idea of fighting spam by attacking the abuse 
the spammers use to send most spam.  I far prefer ISP-level 
action.  Individual honeypots are a weaker approach, if good numbers of 
ISPs are willing to do the little bit of work needed to detect massive 
abuse of the IPs in their space.

>relays, but it would be unethical.

Can it be made ethical by asking permission?

>>>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".

Why pick the honeypot over any other system?

>>>random bot generated free addresses used only for 3 or so runs.

Which, if there is an ASRG-designed plan for all interested entities, is 
something freemail providers will need to watch for: email creation 
bots.  If spammers always did it form the same IP then they'd be easily 
caught.  It's easy for the spammers to abuse open proxies to create 
freemail addresses but they should be running a risk if they use the same 
address more than twice (or even more than once.)  Freemail providers can 
get tighter about giving out addresses and could use the human-readable GIF 
Turing test to inconvenience the bots (or some equivalent test, including a 
.WAV Turing test for the visually impaired.)

>>value of the idea is in the sheer overwhelming number of honeypots, not 
>>in an isolated few.
>
>source of email. Without you knowing it they compromise the system, and 
>use it to send the spam, while reporting to you that everything is normal.

No greater risk than that of any other internet-connected system.  I say 
the risk is negligible and can be ignored, insofar as it is claimed to be 
honeypot-specific.  You can try to convince me otherwise but other than the 
revenge factor why would the spammer attempt that?  The honeypot is being 
run by someone that's at least a tiny bit clueful about spam: why should a 
spammer direct his efforts to such systems?

>find systems with bad security to zombify.

The way to realize an overwhelming number is mostly to run Jackpot, on 
Windows systems, until other similar honeypots are devised.  The systems 
are already there, and may be (as Windows systems) as vulnerable as you 
say.  If it's a danger and if ASRG chooses to back honeypots (I'm content 
with widespread ISP activity directed against abuse - ISP-level honeypotys, 
perhaps, but not really the single-IP ones we're discussing) then some 
effort would need to go into deciding how to protect against a zombie attack.

>I wish you the best of luck building a better honeypot.

Ain't gonna happen.  There may be far better ways of dealing with abuse; 
open proxy honeypots have barely begun and hold great promise, but I won't 
be doing them.  As I understand it this is an engineering task force, 
although loose-knit.  At some point a decision to act should occur and then 
I'd think the ideas would be examined.  My idea has a lot going for it: 
spammer abuse has barely been recognized, let alone targeted for action 
against the spammers.  No new protocol is required: action can be 
fast.  Since spammers have been allowed to commit their abuse almost 
unchecked they've gotten lazy and complacent.  I suspect no better idea 
will surface.  Even if there is a better idea if it will take a long time 
to implement then fighting spammer abuse is ready as a mode of attack today.

I've never built a better honeypot: others have (Michael Tokarev, Jack 
Cleaver, "The Mushroom Guy, " for example.) If one is built I won't be the 
builder.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 15 Apr 2003 20:52:58 -0600 (MDT)

> ...
> Not yet.  Code doesn't write itself, code doesn't distribute itself. ...

> ...

> ...

See http://groups.google.com/groups?q=brad+honeypot+group%3A*abuse
for a couple thousand statements along those lines since early 2001.

There are a several distinct and independent anti-spam mechanisms in
current use that each prevents the delivery of 10 to several 100 times
more spam every day day than all intentional honeypots have captured
in their combined histories.  I doubt it is a coincidence that none
of those mechanisms have the deployment, potential for abuse, narrow
application, and other problems of honeypots.

Spam honeypots are like teregrubing and security honeypots.  They
should be in any comprehensive list of tools, but they are not
solutions.  They can be useful research and detection tools, but
except for research and support, they are not part of the fix.

Note that for years I've been running systems that appear to spammers
like one of the kinds of honeypots that Brad Spencer has advocated
(the kind that does not deliver any spam including possible relay
tests and so does not abuse anyone or the network).

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

---

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

>tests and so does not abuse anyone or the network).

Vernon is largely responsible for the DCC.  Expansion of the DCC to cover 
additional mailboxes not now covered seems to me to be a viable option for 
ASRG to consider as a major part of a full solution to the spam 
problem.  Similarly, expanded use of Razor seems justified, as does use of 
both systems to identify spam (or bulkish mail, in the case of DCC) and to 
then use the information as a means of flagging the sources of identified 
abuse email for listing in blocklists.  My ISP uses Brightmail: I get spam 
every day.  It is my impression that Brightmail depends on manual 
identification of spam - manual identification appears to have a 
significant time lag.  If automated identification is used then spam 
versions and the corresponding spam sources are identified rapidly.

Honeypots add to the solution and do not interfere.  Honeypot-trapped spam 
can also be used to feed into the DCC and Razor databases.  No matter how 
cleverly the spammers disguise the spammish nature of what they send it is 
known to be spam the instant a honeypot traps it.

---

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

> known to be spam the instant a honeypot traps it.

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?

--

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 16 Apr 2003 08:29:17 -0600 (MDT)

> From: "Jon Kyme" <[email-masked]>

> for honeypots.  So not exactly a "solution" then, but an assisting

That reasoning is exactly why a standard configuration of DCC clients
is to report unauthorized relay attempts with counts of "many."  After
a couple years, that reasoning is clearly wrong.  Only a very few of
the stupiest spammers pump more than a few 100 messages through a
system that answers relay attempts with "250 OK" but does not deliver.

It does not matter whether spammers are doing the obvious and including
undetectable drop-boxes in their spews.  (It is obviously impossible
for a honeypot operator to distinguish or detect one address that gets
a copy of every spam sent by a relay spammer and is monitored by the
spammer from every other address that gets a copy of every spam sent.)
What matters is that honeypots that don't deliver spam to victims
don't get used by spammers, while honeypots that do deliver spam are
no better than Spamfords paid "Bandwidth Partners" and must be treated
like the spammers they are.

---

From: Brad Spencer <[email-masked]>
Date: Wed, 16 Apr 2003 10:45:20 -0500

>spammer from every other address that gets a copy of every spam sent.)

The honeypot operator isn't the only person who can act usefully.  The 
operator of the system to which the test spam is sent can, by implementing 
anti-spam filters, greatly destroy the power of this spammer ploy.  If the 
spammer response is to send the spam to his own domain (as some do for 
their test messages) it's trivial to make sure that domain gets all the 
spam the spammer sends to himself (once you know the spammers' domains.)

>like the spammers they are.

My original honeypot did sometimes leak spam.  Mea Culpa.  I now run it 
with all delivery disabled and sometimes deliver a relay test 
manually.   It now does not and cannot leak spam.  I run Jackpot at home 
with relay disabled.  It does not and cannot leak spam, not even one.  It 
does trap relay tests every once in a while.  The "work" honeypot was up to 
333 tests this year last time I checked.  Many of those are repeat 
tests.  With only one trap I can't say anything about the testing pattern 
that the tests represent (and I think the testing patterns are tremendously 
important to know.).  I do know some spammers differently from how most 
do.  I know a [email-masked] spammer - he's the one that sent three 
intermingled types of relay spam, through open proxies, and sometimes 
screwed up (put the "Meet Russian Women" subjects with a different 
spam.)  That's another way I know spammers differently from most: I see 
more of a complete spam run than is usual.  If there were larger numbers of 
honeypots and if the operators were doing what I started to do with the 
"work" honeypot - let test messages be delivered only to one drop box - 
then there'd be a good body of formation possible that would link a test 
dropbox address with a particular flavor of spam.  If the dropboxes were 
not done under fictitious names (and some have very long histories, so the 
spammers may not realize the vulnerability) then a subpoena could be issued 
to link the spam back through the dropbox that received a test message and 
triggered that spam to  the name of the spammer.  The AOL suit could have a 
lot of the "John Doe's" filled in with real names.

However, since the topic has come up, there are honeypot schemes in which 
some spam is delivered.  I will point out the inconsistency of opposition 
to those, using securing of open relays as the starting point.  When an 
open relay is secured then that particular IP is no longer a source of 
spam.  As generally done the securing results in the IP responding "550 we 
do not relay" to any relay attempts.  That is all the information the 
spammer needs and it is given to him for free.  That preserves the strict 
dichotomy on the internet: systems that don't relay spammer test messages 
and aren't open relays and systems that do deliver spammer test messages 
and are open relays.  The act of securing the system makes no noticeable 
effect on the volume of delivered spam.  As long as the spammer can find 
enough true open relays he continues to send as much relay spam as he needs 
or desires.

If I created a honeypot that used some random number function to determine 
which spam recipients were to get spam, and programmed it to deliver 50% of 
the spam, then it would also stop 50% of the spam.  That is far worse form 
a single-system viewpoint but is infinitely more effective than the secured 
system in actually stopping spam TODAY.  Only when almost all systems are 
secured does simply securing result in a lowered spam volume - that day 
hasn't yet arrived.  You can rail all you want about a system that delivers 
half the spam it is given to deliver but it is doing more to stop spam than 
a secured open relay.

That's not the only scenario.   If there were a million honeypots they 
could deliver 100% today, 98% tomorrow, and so on, ramping down to 0% 
delivery in 50 days.  This isn't likely to ever be done but, depending on 
how thoroughly the spammers had switched over to these fake open relays, 
the spam volume would be greatly reduced after 50 days (if the spammers 
didn't scramble away from the honeypots.)  I don't advocate this but I do 
advocate thinking about it - the simple gut-reaction approach, appropriate 
for the first day it is discovered that your system is being used to relay 
spam, is no longer adequate (and thus never was.)

There was no benefit I can see to my honeypot leaking spam and I never 
wanted it to leak.  But it did function to end huge amounts of spam while 
people with simply-secured systems did nothing comparable.  It did get 
listed as an open relay but that was OK: I invited ORBS to test my zone 
whenever they wished. Later on it was much tighter.  It also functioned by 
delivering all single-recipient messages (for convenience in 
implementation, not for any necessity.)  After it was shut down 
single-recipient relay spam got far more prevalent.  It would have been 
trivial to change it so that it checked all messages.  Even for 
single-recipient spam it checked for relay tests, so I could save 
copies.  MAPS listed it because I described it in NANAE.  Again, no problem.

If you remember nothing else from this message remember the folly of giving 
the spammer for free the piece of information he most needs about a secured 
system to enable him to keep sending relay spam: the fact that it is secured.

I've not really thought through all the implications of open proxy 
honeypots - there may be some great ideas there that haven't yet been 
touched.  That's where the action is now - open proxies.