ietf-asrg
[Top] [All Lists]

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

2003-04-08 18:08:30
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



<Prev in Thread] Current Thread [Next in Thread>