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

From: Brad Spencer <[email-masked]>
Date: Tue, 08 Apr 2003 17:58:24 -0500

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?  You configure something to accept relay email messages, 
you do something to recognize spammer relay tests, you deliver those.  I 
tell one way to recognize tests: one's IP is in the tests very often, 
plaintext or encoded.  I tell how they are encoded.  If you trap relay 
email the chances are nearly 100% that the first email you trap is a relay 
test.  What does it look like?  It might be different from any yet 
seen.  Does it or doesn't it have the tested IP in it someplace?

Different people are familiar with different MTA's.  Chances are most MTA's 
can be configured (on a separate system) to be honeypots.  The IDEA works 
for all MTAs - giving details of how I do it (ancient, free, unavailable 
PMDF) would be useless to anyone.  People can run Jackpot - I gave the URL 
for that.  Most Windows systems can be open relay honeypots.  Some can't - 
there's no particular need to enumerate those.

Honeypots are a single-system-level approach to dealing with the relay 
tests sent by spammers.  ISPs can do network-level actions against the 
abuse.  Yes, some legitimate traffic will be similar to spammer traffic - I 
don't recommend "sound shots." Once the ISP is convinced a source of 
activity is a spammer the ISP can then act.

I never thought of adding a web server to the honeypot - Michael Tokarev 
did.  If he had just done what I did he'd have had a far weaker tool than 
what he devised himself.  There's good reason to leave off implementation 
details - innovation comes form going beyond what has already been done.

I've also sent a draft to Paul Judge of my response to his suggestions for 
how to propose honeypots.  I don't think he'll like it - it isn't as 
detailed (I imagine) as he'd want it to be.  I am working in that direction 
but there's really no need to wait for that post.

I'm sorry if I'm brittle but you must understand I had two years of 
quibbles in NANAE and I'm not going to go that route any longer.

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 server - add to the idea.  That's what engineering is, is it not?

Actually, it's two ideas.  (1) Act at the relay level (including the proxy 
level.)  (2) Do it at a huge number of IPs, quickly.  You should see why 
the "quickly" part of (2) is a powerful idea against countermeasures.

I have not described all that might be possible using a 
honeypot.  Obviously you can end up with fresh spam and all you can do 
against received spam can be done against that.  It may contain variable 
data, such as reply-to addresses, that you can collect and report in one 
bunch to the provider of those reply-to addresses (almost surely a freemail 
provider.)  You can accomplish things against the spammers that will 
mystify them if they don't know about honeypots - they aren't used to that 
level of defense, don't understand their vulnerability.  That is part of 
the power.  Honeypots are two years overdue.  It's time to move on them.

Implied, I think, in your post is an assessment that says I am 
flawed.  Boy, am I.  Take the idea and run - leave me behind.  ASRG doesn't 
care, at any particular level, how flawed I am.  It's the idea that 
matters.  Go with the idea.

Thanks for your interest - I do appreciate your posts.

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

---

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

At 04:56 PM 4/8/2003 -0700, you wrote:

>Could you start from scratch in describing it?  I was not able to grasp it
>from the rather rambling description in your email.

Sorry.

Spammers abuse open relays - that's relay spam.

To do that they need to find open relays.  They look for them by attempting 
to send email messages to themselves through a list of candidate 
IPs.  Messages like this one:

Date: Mon, 07 Apr 2003 21:31:14 -1700
From: [email-masked]
Subject: hello
To: [email-masked]

05405304605504804605605704604905005305809710011510804505405304505504804505605704504905005304610011
5108046116117108115111107046115119098101108108046110101116058051053053058050058

The body of the message is in decimal ascii, and says:

65.70.89.125:adsl-65-70-89-125.dsl.tulsok.swbell.net:355:2:

The MUNGED in the message-ID replaces the IP that was tested, encoded 
exactly the same way.  for the spammer that's the payload of the relay 
test: it tells him which IP accepted and delivered the test message.  X.X.X 
obscures the name of the system.  Otherwise this is a real relay test 
message, just as trapped.  The spammer's dropbox address, where he receives 
his test messages that tell him where the open relays are, is 
[email-masked].

Most systems reject relay email.  Those that accept the relay email are 
mostly open relays that also deliver the test messages.  The spammer 
receives these and knows the IP that delivered it is an open relay.

So what a honeypot operator can do is accept relay messages and deliver 
those that are test messages.  That looks just like an open relay to the 
spammer.  Usually the spammer follows the delivery with spam.

I no longer deliver test messages, except when I choose to do so.  I do 
continue to trap test messages.  I could complain to both swbell.net and to 
connectfree.co.uk.  I usually tell the recipient ISP that the dropbox is 
used by the spammer to collect relay tests and that the ISP can choose what 
to do, if anything, with the information.  I'd like them to be aware that 
the sources of email to that address are very probably the open relays the 
spammer finds.  I'd like them to understand that if they'd divert email to 
that address but leave the account open they'd cause the spammer more 
trouble, but I just tell them and hope.

If spam follows it quite often comes from IPs sprinkled all over.  If it 
does then those are probably open proxies the spammer is abusing to send 
the spam and to hide his location form the recipient.  (That's all standard 
stuff you already know, probably.)

Spammers, as a group, seem to test about every portion of the internet for 
open relays.  Most email system operators can tell you their logs show 
rejections of such attempts.  What I advocate is setting up systems with no 
real email function to trap the tests (and perhaps deliver them to draw 
spam.)  That will at least produce more information on the sources and 
destinations of spammer relay tests, information I regard as important.

If you deliver the tests and attract the spam then you may succeed in 
stopping spam to some number of recipients.  One person who has done this 
for over a year (using sendmail -bd, with some additional configuration 
stuff: see http://fightrelayspam.homestead.com/files/antispam06132002.htm 
and look for the sendmail stuff.)  He trapped spam to over 281 million 
people in his first year of operation, using a 120 MHz Pentium with 64 MB, 
Linux, and sendmail.

Windows users can run a honeypot if they install a Java Virtual Machine: 
http://jackpot.uk.net/

All this is well and good.  It's useful and fun to trap spam, same for 
detecting spammer test sources and destinations.  Ho hum, in a way, 
though.  Millions trapped is feeble when there are billions/day.  Do 
remember that the millions are for a single IP: it is very impressive 
performance for one IP - there just aren't enough like it.

RFC 2505 (if I may change direction a bit) says that securing open relays 
won't work to stop relay spam because spammers will find the remaining open 
relays and exploit them.  The test message above is an example of how they 
find open relays.  The villain is the ability to find open relays.  I 
advocate having so many honeypots that the spammers don't know which IPs 
are open relays and which are a fakes.  Obviously if they come up with a 
second test to distinguish honeypots from open relays then they still win - 
part of the challenge is to continue deceiving the spammers once they start 
taking countermeasures.  One countermeasure might be to include a spammer 
dropbox every so often in the spammed addresses.  If the spam through relay 
A doesn't hit the dropbox then relay A gets flagged as a honeypot and the 
spammer stops using it. Fred Woods is developing a central database server 
for the email addresses spammed.  If the spammers re-use their dropbox 
addresses frequently they will appear as frequently used addresses in the 
database.   Once you know which addressees the spammers use you deliver the 
spam to those, just like the spammer wants.

Honeypots are quite easy.  Almost anyone can run Jackpot, even if they need 
help downloading it and installing it.  If run in the as-installed 
configuration all it will do is accept relay email - no more.  Use it's web 
interface or edit its configuration file and you can have it try to 
identify relay tests and to deliver those (keeping a copy.)  That draws 
spam.  Jackpot will also make all the trapped relay email, test messages 
and spam, available on the web (there is a numeric cutoff so if more than 
that number of messages come from a single IP the excess aren't 
stored.)   Jackpot is a way to get large numbers of honeypots in use 
quickly.  (That probably won't happen soon but it's still a true 
statement.)  If the pool of open relays gets diluted with large numbers of 
honeypots then the spammers are closer to not being able to find open 
relays to abuse.  When they can't find them they will eventually stop 
abusing them, as the lists they have wear out. The need is to so saturate 
the internet with false open relays that the true ones can't be 
found.  (Note that doing this doesn't weaken DNSBL lists of open 
relays.  Whether the fakes are listed in the DNSBL or not doesn't affect 
their utility in blocking relay spam.  Honeypots can be used in conjunction 
with all current techniques - they are an addition to the arsenal.)

Similar reasoning exists for open proxies.  I have almost no experience 
with running a proxy honeypot - others have.  An example is GypsyProxy, 
from http://www.angelfire.com/space/netcensus/ .  Gypsy Proxy runs on 
Windows systems and runs some real proxy services (the list of proxy ports 
appears to be editable.)  It is wickedly clever: if a proxy user tries to 
connect to the SMTP port of some remote system GypsyProxy diverts that 
connection to its own SMTP simulator-honeypot.   Then the same thing 
happens: the spammer sends his spam, Gypsy Proxy saves it.  I actually 
don't know the details of how or whether it delivers relay tests - I don't 
think it does.  There's room here for improved software.

I've had reports of blockages in the millions for other honeypots; a major 
honeypot installation in Germany had blocked spam to 220 million recipients 
so far this year when I asked, which was a month or so ago.)   I'm 
perfectly content for most honeypots to just trap and perhaps complain 
about relay tests.  The countermeasure then for the spammers would be to 
stop testing IPs that accept but don't deliver the relay tests.  One 
response to that would be to change the IP (if possible) and continue 
running - the goal would be to have the spammer give up on the entire block 
of IP addresses.  That, too, is a win - it reduces the IP space the spammer 
can check for open relays.

If this isn't adequate please say so.  I can dig up version one of a Perl 
honeypot - the author spoke f a version 2 but it never appeared in public 
that I know of.  Michael Tokarev, in Moscow, did his honeypot based on the 
Postfix mailer.  I've heard from one user that Michael helped him with his 
Postfix honeypot.   Michael added a web server to the honeypot.  The 
honeypot is now inactive but the server is still running so it can be seen 
how it looked in action: http://www.corpit.ru/cgi-bin/h0n5yp0t

That URL was sent to three different ISPs one weekend when Alan Ralsky was 
"using" the Moscow honeypot to relay spam.  None of the spam got delivered; 
Ralsky apparently burned through all his throwaway accounts on 3 different 
ISPs that weekend - the accounts got cancelled rather more quickly than 
he'd been accustomed to.  Ralsky used the Moscow honeypot from February to 
July last year.

---

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

At 12:25 AM 4/9/2003 -0700, you wrote:

>Sounds nice but why won't they alter the tests to not be so detectable?

I suppose they would if they could.

The tests currently are undectED.  I don't know how you would make them 
undetectABLE, but as long as they are undetectED the spammers have no 
problem.  Relay spam is courtesy of those who don't bother to do what they 
could to make it stop.  I won't name any names...