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

At 06:06 PM 4/15/2003 -0600, John Fenley wrote:
> > From: Brad Spencer <brad(_dot_)madison(_at_)mail(_dot_)tds(_dot_)net>
> > 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.
Not yet.  Code doesn't write itself, code doesn't distribute itself.  They 
don't have it.



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




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

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

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



> > > 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.
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.
> Saying things to the effect of "all spammers ______", whatever that blank 
> is, underestimates the human ability to adapt.
They can buy service elsewhere.  Guess what: when they send spam pretty 
quickly the IPs show up as spam sources.  Block those 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.
> Yes, I know. Everyone knows.
And yet many use RBLs and praise them.  Not my area, but they aren't proven 
totally useless.


> We must not give spammers an easy slope to climb.
> If they realy become proficient in adapting to our solutions then we are 
> hosed.
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.


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


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

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

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


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

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

> There is a method I can think of that would solve the problem of open 
> relays, but it would be unethical.
Can it be made ethical by asking permission?




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

Why pick the honeypot over any other system?



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

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



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

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?

> With an overwhelming number of honeypots it would be easy for spammers to 
> 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.
> John Fenley

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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg