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:
Received: from 65.70.89.125 X.X.X, 7 Apr 03 21:32 CDT
Message-Id: <MUNGED(_at_)afnicfr>
Date: Mon, 07 Apr 2003 21:31:14 -1700
From: ungratefull2003(_at_)acetech(_dot_)FR
Subject: hello
To: mikebsmith(_at_)connectfree(_dot_)co(_dot_)UK
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
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
mikebsmith(_at_)connectfree(_dot_)co(_dot_)UK(_dot_)
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg