Message Board

Installing Honey Pots

Installing spampots at an ISP

Author: B.Coogan (17 Jan 05 8:28am)

Hi,

I run a webhosting company and would like to install spampots on our "holding" page for newly created domains. The holding page is the page that displays on a website prior to our users uploading any webpage content, and of course, many never do as they just use the domain for their email. This means that you'll effectively get hundreds of domains for free.

Obviously, I don't want to have to define every new website with you guys, so my question is ...

How do I go about this? Do I just add your code to the holding page shared template as I would if it was a normal webpage? Or do I need to make some sort of special arrangement?

On a second topic, having done this, I wouldn't mind the ability to auto-update the part of your code (PHP in my case) that lives on my server regularly, perhaps via wget or rsync or some other mechanism. I'd really like something that's as much set-and-forget as possible, that way I can run this on all my servers without any extra time cost to myself.

Great work guys, stellar contribution to the spam fight. This is going to mean the end of harvesting if enough people join.

Cheers,

Brian

Re: Installing spampots at an ISP

Author: M.Prince (17 Jan 05 8:41am)

Brian --
First, thank you for an extremely generous offer. It will be interesting to see how many of these "holding" domains end up getting hit by harvesters.

In terms of the technical details, the easiest thing you could do is create one central honey pot and place that script in a central place on your server. Then you can add HTML links to it from all the holding pages. That way you wouldn't need to install and update a honey pot for each new domain, but instead just install a honey pot once and link to it from the holding pages. The only downside to this is that you won't be able to track the statistics on a domain-by-domain basis. However, that's probably more trouble than it's worth for both you and us. If you wanted to get fancy, you could randomize some of the different link formats we suggest, but even that may be overkill.

We don't anticipate a lot of updates of the core script once it's installed. The script communicates with our server automatically to get more addresses and we can change elements of the content automatically if we find harvesters filtering on something in particular in our content. However, let me think about whether there's some way for us to do an auto-update system. That, of course, would create a number of additional possibility security risks so we wouldn't want to add it by default. But, before we release the first script update, I'll think if there's any way that we can make updates for our existing installations as easy, and maybe even automatic, as possible.

Finally, while it wasn't something you offered, if you're willing to suggest to your members that they consider donating an MX record as a portion of their newly created domain, that'd be really helpful as well. I don't know what the easiest way to incorporate that into your systems and ours is, but we'd be happy to work with you to make it happen if you're interested.

Thanks for your help, and welcome to the Project!

Re: Installing spampots at an ISP

Author: B.Coogan (17 Jan 05 9:06am)

My current plan, hatched just after posting, was to create an Apache mod_rewrite rule that invisibly redirected requests to a certain directory or link (or group of links, to make it harder) to the project honeypot script.

This way, the capture pages would all appear to have domain-dependent, different, URLs as far as the harvesters were concerned. Only the subdirectory would be constant. We might have to work to randomize them more as time goes on, but I think it'd get us going for now.

Am I right in supposing that I could use an existing downloaded script for this purpose withour any further modifications?

The MX record is harder because of the need for subdomains. While I could create a subdomain with a constant name that would be an obvious giveaway. Of course, I could still donate MX records from some domains, but I'd need to do it manually. (Or I could register some domains, after all they only cost us$6.75 each :) ).

Cheers and thanks!

BTW I thought spambots didn't follow PHP links? One of my early harvester stopping scripts replaced mailto: links with a PHP script that did a redirect to a mailto (ie: "location: mailto:user@domain.com") - are you saying that would no longer work?

Cheers,

Brian

ps: feel free to contact me off list to discuss, spampt11 at bcfilt dot com ...

Re: Installing spampots at an ISP

Author: M.Prince (17 Jan 05 9:58pm)

That seems like a good plan. As long as the honey pots is activated initially, and our verification system knows where to find it, then it doesn't matter where it's linked from or how the spiders get to it.

In terms of the PHP anti-harvester technology, most harvesters will follow links these days, even those that are generated by, or point to, dynamic content. Your trick works because it doesn't put the email address in the content of the page, but instead hides it in the header (not to be confused with the <head></head>) of the HTTP transaction. For 95% of robots, I'd imagine, that will still work. However, there are a few that take EVERYTHING your server sends to them when a link is requested and parse it for an email address. For those, the trick using the link to a dynamic page with the "location" header element redirecting to an email address won't work.

That's a pretty good trick still, and we thought about including it in our How to Avoid Spambots tutorial. Unfortunately, it's fairly technically sophisticated and certainly not for the faint of heart.

Let me know if you run into any trouble with the install. I'll be curious to see if harvesters hit the parking pages. Would mean they must be farming DNS records for new sites, or pulling domains from email addresses they've somehow gotten their hands on, right? I guess, theoretically, they could be guessing domain names at random -- but that hardly seems efficient or likely to prove fruitful. Regardless, I think your installation is likely to generate some fascinating results.