ietf-asrg
[Top] [All Lists]

Re: Relay honeypots (RE: [Asrg] define spam)

2003-04-06 19:20:23
At 09:04 PM 4/6/2003 -0400, you wrote:
At 5:45 PM -0500 4/6/03, Brad Spencer wrote:
Show me a risk-free, automatic process to do it, and then you'll have some takers. Please do not assume that everyone fighting spam is sitting around with spare IP addresses and lots of free time.

OK. Run your MTA with delivery stopped and write software that recognizes relay tests of your IP and delivers those. To make it even safer write software that does that just once per day, maximum.

Yes. If you recall, the very first thing I asked you when you talked about this technique was whether you had software I could use to try it. You said no. I'm the one complaining about lack of time, remember?

This is ASRG. It is perfectly reasonable to suggest approaches that have not been implemented.

Years ago I described using sendmail -bd (sendmail is no longer that simple but the concept remains) as a honeypot. As described it will trap relay tests - that is fully automated. Something additional would need to be added to recognize relay tests and deliver them. I separated spam from legitimate email on a server/honeypot automatically, I recognized relay tests and forced their delivery (saving a copy) fully automatically. Jackpot (http://jackpot.uk.net/) is fully automated and runs on any system with a Java Virtual Machine. I've seen it deliver small quantities of single-recipient spam, therefore I didn't recommend it to you. There's also been a honeypot written in Perl published. Michael Tokarev's honeypot in Moscow was automated to the point that it sent an email message to Michael whenever a probable relay test message was received along with instructions (I imagine just a string to cut and paste into a window connected to the honeypot system) that would deliver that one test message. That's not fully automated so I didn't report it. If you want to just trap relay tests (which is fully reasonable, helps, and is what I usually do) just disable delivery in some way. Smarthost to a coffee pot or something like that - anything that prevents delivery. I stop the queue on a VMSsystem, I run Jackpot with delivery off at home.


Even easier, do what I do: run an MTA with delivery stopped and report relay tests to the appropriate ISP. If you claim you are going to get blacklisted because spammer relay tests go in to your system and disappear you'll need to explain how that happens.

I thought what you said was that to get this started, you had to let through the initial relay tests. Telling those from BL relay tests is my concern. Plus the fact that it has to be done manually.

You can choose the level of operation you desire. I've cut back, mostly, to just trapping relay tests. I consider that to be a useful activity. It also works to deliver spammer relay tests and then trap spam that follows. That isn't essential. IT can be very satisfying, you can sometimes do additional damage if you trap the spam. For a while a spammer was sending me spam in which he used dropbox addresses for his replies and had a lot of those so he wouldn't be badly wounded if a few got reported and the accounts got closed. I reported hundreds at a time - that hurt him a bit more. These were swirve.com and snowboarding.com dropboxes. Also some excite.com addresses - the main difference is that I heard back from outblaze but not from excite.com.


I'm describing actual factual occurrences, not things I imagine.  If you have

No. You are imagining a world in which thousands of people do this and it stops spam. I'm telling you that if you want that happen you a) need to show that the software can be written to do it automatically and b) need to show the numbers. Instead you keep coming back and telling me how well your honeypot works. I've never denied that it works. Show me how it's going to get deployed! Show me facts.

I'm imagining thousands, up to millions. Yes. Even one honeypot has an effect. One honeypot surely is not going to stop spam (but does have an effect) and my goal is not to deal with spam but to end it. The number needed may be less than millions. As a system as simple as Jackpot already exists I have no doubt that in time millions of systems could be deployed. In the default configuration Jackpot accepts only, doesn't deliver anything. That's a huge step forward compared to doing nothing at all. I'd be tickled right now with a few hundred Jackpots that only trapped relay tests. If there were a few hundred I'd pretty soon see if exponential growth started - that's what I want and expect.


This is what so many proposals on this list have done. They imagine a perfect world in which a whole bunch of people decide to put up with a bunch of grief in order to make the world a better place. Yes, those people exist. No, you're not going to solve things that way. The number of people who don't make the effort is way larger.

Understood, and thank you. Yes. I don't see grief, though. If it seems too much effort to anyone, if someone doesn't want o do it because he's allergic to bee stings and the name "honeypot" disturbs him, no problem. There still has to be thousands willing to do it if they know about it and if they aren't scared away by false concerns.


Take the honeypot idea. Propose a way of automating it. Describe how you are going to deal with countermeasures.


I'm lazy. It is automated so that's done. Dealing with countermeasures rather depends on the countermeasures and I don't intend to tell spammers the best way to combat honeypots. I'm confident the anti-spammers can keep the upper hand. The ultimate spammer defense is to stop sending realy tests and to stop sending spam. I'll let them win that way. If all you do is trap relay tests and if trapping relay tests and reporting them becomes (through ISP education) a significant way of stopping spammers then there are no countermeasures - do a test and get busted. There is obviously the possibility that spammers will switch to doing all their tests through open proxies: then the effective weapons are open proxy honeypots. As a general defense against countermeasures i advocate distributing honeypots in source form and letting the talented users modify and improve them. If you don't see how this will rapidly result in a plethora of versions you haven't been watching software very long. I want a plethora of versions, an impossible snarl. I'd never be able to figure such a situation out. More to the point, a spammer would never be able to figure it out. There would be no simple, reliable procedure for figuring out an IP isn't a real open relay. Right now there is, of course, since IPs are so perfectly divided into just two classes: open relays and non-open relays.

To take any countermeasure the spammer has to start with a test. Capture the test and you have him. If the honeypot is a standard MTA run as a honeypot then I see little chance the spammer can discover it is a honeypot without running a test. If he's going through an open proxy then he has slimmer chances of avoiding detection at the open proxy.

Describe how you are going to deal with spammers reporting you as an open relay to black list operators.

So long as it isn't an idiotic blocklist that expands open relay listings there's no problem. I ran a server/honeypot that was listed: I invited ORBS to test and list me. I did rely on the apparent low usage of ORBS by .edu email managers at the time but that was a server. I don't care if the IP of the honeypot is listed - I may want it listed may self-nominate for listing. It isn't a permanent black mark on a person's character, it's just a listing. You can take pride in running a listed honeypot: you are helping screw any spammer who lazily relies on listings to find open relays/open proxies.

One spammer/relay tester did routinely include a blocklist in the destination of his tests. Why, I don't know. ORDB, I think it was. I didn't and don't care. I'm not anti-blocklist. I am against accurate blocklists. The inaccuracy I desire is, of course, that some listed IPs not be open relays but instead be honeypots. That has no impact on anti-spam use - the honeypot IP never comes up for anti-spammers. If it is, as I recommend, a system with no valid email function.


And how you are going to let spammer mail through, but not tests or real spam. Make a proposal!

You mean, I think, spammer tests through, anti-spammer tests and spam not through. I use sting searches to find relay tests in my mail queue. My IP in plaintext, my IP encoded in decimal ascii, and the string MAILINF0 (where I could use my IP as encoded in that type of test - I just don't.) I do this manually, when there's also spam in the queue. When I ran fully automated I just used strings (there were more strings - more than needed. I know more now.) If you fail then you don't deliver a spammer test because it isn't encoded in a way you recognize- it's fail-safe. Currently - a spammer could start putting the relay IP in the body of real spam - then you'd have to test slightly harder. When I ran automated I simply did the string matches, saved copies of the tests, and delivered them. I'm not really a unix shell programmer but I could, if I were doing this on a Unix/Linux system, come up with a cron task that would automate the entire thing. Some have gone so far as to automate sending complaints to the ISP of the source (Jackpot shows the abuse address, if known, of the ISP for each spam-source IP.) I've done cron commands that recognized spam and rm'd it - that was a different problem.


So far all you've done is what everyone else has done. You've said, "Hey, there's the great thing, and it works great for me, everyone should do it."


Yep. But I also give numbers. Elsewhere I've done the analysis that shows the effect would be predicted to grow as the number of honeypots grow. I was a royal PITA in NANAE (past tense may be self-fllattery) about the idiocy of simply securing open relays. For those the effect of securing a relay on the delivered spam volume is 0.00000000% until almost every open relay is secured, until the existing open relays are inadequate for the spam volume. RFC 2505 says securing open relays is not a viable approach to stopping spam. Nonetheless that approach was taken. RFC 2505 says that is because spammers can find and abuse new (to them, or truly new) open relays. That's what I wish to attack: the ability to find open relays. You can't do anything more about the true open relays so the attack has to use non-open relays. The attack is simple: make them look to the spammer (who is constantly searching for open relays) like open relays. Get my thousands or millions of people doing that and the spammer will no longer be able to find open relays. To be effective my ideas depends on thousands or millions of participants. The first hundred or so are the hard ones to get - their results will make getting the rest progressively easier.

A data point on the scale of the problem. Whether it's relay specific or not, I don't know. I know an ISP which has been blacklisting single IP addresses when they attempt to connect with bogus HELO strings. They noticed that these came preliminary to an actual spam flood attempt, so they started blocking them as soon as they saw them. So far he's blocked close to 100,000 distinct IP addresses.


Sure. For a while, believe it or not, my honeypot was used by a spammer to test systems for open proxy. He'd HELO me and then QUIT. He'd do it always through different open proxies. For a longer while I constantly got connections form a spammer whose spamware depended on EHLO being recognized. My original honeypot, using an MTA, was based on software so old it doesn't recognize EHLO (not any Unix software. If it's vulnerable to being OWNed the hacker is going to have to figure it out all on his own - there's not even source that can be associated with the software.) The guy you mention is almost certainly blocking open proxies - no surprise at the number of them.

Like these:

### Begin SMTP from 199.183.67.8; Tue, 7 Jan 03 01:44 CST
<-- HELO mail.jondoninc.com

### Begin SMTP from dsl-216-222-118-170.az.rmci.net; Tue, 7 Jan 03 02:06 CST
<-- HELO smtp.msn.com

### Begin SMTP from dhcp065-029-068-003.indy.rr.com; Tue, 7 Jan 03 05:40 CST
<-- HELO 164.100.80.127:8080  (probably telling me something right there)

### Begin SMTP from 206.67.58.234; Tue, 7 Jan 03 09:17 CST
<-- HELO lkpug.yahoo.com

They lie.

I keep getting these:

### Begin SMTP from dynamic-62-99-161-123.804.inode.at; Sun, 6 Apr 03 20:42 CDT
### Begin SMTP from dynamic-62-99-161-123.804.inode.at; Sun, 6 Apr 03 20:32 CDT
### Begin SMTP from dynamic-62-99-161-123.804.inode.at; Sun, 6 Apr 03 20:30 CDT
### Begin SMTP from dynamic-62-99-161-123.804.inode.at; Sun, 6 Apr 03 20:28 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 20:22 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 20:12 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 20:02 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 19:52 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 19:42 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 19:32 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 19:21 CDT

always EHLO's something like a hotmail IP. I can't do EHLO, he quits. If I did EHLO I think I might get spam.

The honeypot approach has worked in Italy, Denmark, Germany, Moscow, Wisconsin (me, yay!), New Orleans, Atlanta, and surely many other places. It isn't centralized (although Fred Woods is working on a central database of recipient addresses, to help detect spammer dropboxes if they start spamming those to detect honeypots.) Anyone with cable or DSL potentially could do this- it helps to not be running a real MTA.





_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg