Re: [Asrg] Whitelisting on Message-ID (Was Turing Test ...) honey

At 12:38 PM 4/9/2003 -0400, Kee Hinckley wrote:
> 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.
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.
> - 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.
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?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg