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
|
|