[Dshield] Spam trap code/ virtual machine
Tomas L. Byrnes
tomb at byrneit.net
Sat May 26 00:42:40 GMT 2007
Gentleman, I'm not planning on using a real domain that gets mail.
I'm going to use one of the many domains for defunct companies that I still own, and make it's MX the spam trap. Now all I need is the spamtrap code.
I can't find jackpot, proxypot, SMTPot.py, Spamhole, Back officer friendly, or any of a wealth of others referenced in the O'Reilly books and wikipedia.
Guess I'll build one of my own using honeyperl/honeyd, and make it available as part of the ThreatSTOP project.
If anyone has a quicker way, I'd be happy to hear about it!
> -----Original Message-----
> From: list-bounces at lists.dshield.org
> [mailto:list-bounces at lists.dshield.org] On Behalf Of Håkon Alstadheim
> Sent: Friday, May 25, 2007 2:04 PM
> To: list at lists.dshield.org
> Subject: Re: [Dshield] Spam trap code/ virtual machine
> Darren Spruell wrote:
> > On 5/24/07, Tomas L. Byrnes <tomb at byrneit.net> wrote:
> >> Is there any pre-built spam trap stuff out there that
> would let you
> >> easily set up a machine that accepts mail from anywhere to anyone,
> >> routes it to /dev/null, and logs the IP address of the
> connecting host?
> > A fairly easy way to harvest violators would be to add another MX
> > record to your zone at a higher value (lower preference) and log
> > connection attempts to that. As a rule, no valid email
> should be sent
> > to that MX
> What do you mean by "should" here? Certainly not the same
> thing the RFCs mean by should.
> > and any deliveries can be considered violations.
> "Violations" is very wrong. Even "suspect" would be
> stretching it. A possible way of setting up spamtrap-adresses
> would be to take this list from the bogus MX and vetting it
> by hand. I believe it would be less work to just make list of
> delivery attempts to non-existent mailboxes, remove honest
> spelling-mistakes and discontinued accounts and using that as
> a starting-point for a list of spamtraps. As an example, my
> system has no digits in any of the account-names, and I
> automatically register any delivery-attempt to all numeric
> localparts as spam and block all email from those boxes.
> Those same boxes are usually also on a dozen rbl-lists and
> say "ehlo localhost" at the start of the conversation with my
> server. Not much gained there.
> I'm fairly rabid about anybody hitting my spamtraps, but I
> have 5 users and I read every REJECT line in /var/log/mail
> every day, and I reject with 451 so bona-fide mail will stay
> in the senders queue for me to let it in manually. A real
> site will by necessity be more permissive.
> > Many SPAM
> > shops intentionally hit lower preference MXs to bypass the
> > that tends to be on the higher preference hosts.
> True. Now what would the "set and forget" solution to this be
> ? Not the scheme outlined by Darren, that's for sure.
> > This of course
> > assuming that you don't have failures in your legitimate MX
> > that would cause deliveries to fail to your "trap" MX; but if they
> > failed anyway, you'd have no deliveries of legitimate mail in the
> > first place.
> In the event that your MXes go offline, deliveries will stop
> until the MX come on the air again. Most of the servers
> trying to send to you will keep trying for 5 days, holding
> your mail for the duration.
> If you implement Darrens* scheme ANY glitch in your real
> servers might mean that you automatically polluted your list
> of spammers, perhaps even without knowing it until some time later.
> This scheme is VERY quick and dirty. Be careful with the
> ip-adresses you harvest this way, don't use them with any
> more prejudice than
> just-another-factor-in-spamassasin-scoring. If you want to
> enable REJECT at delivery, you need to be a LOT more careful
> about how you make your list of convicted spammers.
> * "Darrens scheme" is just shorthand for "The scheme outlined
> by Darren", it has been suggested before by others.
> Håkon Alstadheim
> spamtrap: finnesikke at alstadheim.priv.no -- 1 hit & you are out.
> If you hit my spamtrap you can still get through to the
> rfc-mandated adresses, but nothing else.
> SANS 2007 March 29 - April 6 in San Diego, CA offers 52
> Courses taught by our top rated instructors plus a huge
> vendor tools expo.
> Register Today! http://www.sans.org/info/2501 (BROCHURECODE: ISC)
More information about the list