Message Board

Installing Honey Pots

Too complex, too cumbersome?

Author: O.M2 (18 Jan 05 5:26am)

The project looks interesting, but by looking the address-generation script (at least the PHP one), I'm affraid that its designers forgot one basic engineering rule: keep it simple stupid!
Copy-paste heaven, massive amount of defines... but no comment besides legal & CYA. Thanks.

Next, the script computes an MD5 hash of itself everytime it's run. Put politely, what for? Trying to detect tampering is doomed to failure, one can easily compute the hash once then modify the script at will, hardcoding the correct value. Trying to detect accidental corruption is not much more likely to work: if the script is hosed, it won't be able to check itself anyway.
On the other hand, this checking not only adds an unnecessary burden on the server, it also makes fixing the script limitations (short PHP tags vs normal ones) a pain.

Part of the script complexity comes from its attempt at making the HTML it generates somewhat variable, presumably to make it harder to detect. I think that this is not necessary against dumb harvesters, and not enough against smarter ones, as the general page structure is still fixed and therefore recognizable.
Adding tracker addresses to normal "home-made" pages would I think be much more effective.

Moreover, a script is supposedly tied to a single domain, worse yet, to a single URL it seems, and vice versa. Maybe I miss something here, but this artificial limitation looks completely pointless to me.
A little like B.Coogan a post or 2 back, I host a bunch of parked domains, all of which display a similar script-generated "coming soon" page. I would gladly modify it to sprinkle a few ProjectHoneyPot addresses here and there, making them especially hard to distinguish from legitimate ones.
The arbitrary restrictions enforced by ProjectHoneyPot make this really cumbersome, probably too much for me to bother at least for now.

All in all, this plus a very wordy licence and unclear ROI (what does the community gets in return for its participation?) make the project unfortunately quite unattractive to me as a sysadmin.

Any thoughts?

Re: Too complex, too cumbersome?

Author: M.Prince (18 Jan 05 5:35am)

Thanks for your input. Clearly the Project isn't for everyone and for every website. In designing the Project we took steps to limit the potential for abuse. That introduces complexity, but it hasn't be overwhelming for the thousands of other webmasters who have already installed it.

Over time we will continue to adjust the scripts to adapt to both our users' needs, as well as adjustments by harvesters, in order to keep the Project as effective as possible. But, as I'm sure you can understand, we need to be careful in order to both keep our statistics as clean and accurate as possible, and also reduce the risk of abuse by rogue users.

We've worked with users who have particular needs and are more than willing to accomodate web admins with a large number of sites, or a bunch of domains they'd like to donate (as MX records) toward the cause. If there's any way we can make the installation more convenient for you, please don't hesitate to contact us directly and we'll see if we can help.

Re: Too complex, too cumbersome?

Author: O.M2 (18 Jan 05 6:55am)

Thank you for your quick reply, however you don't address my questions. More directly:

First, how does checking an untrusted MD5 hash, which you have no way of checking whether it is the one of the script executing, help with security?
Second, what does enforcing a given URL, domain and script names (again provided only by the possibly tampered-with script) bring you?

I understand your concerns, but I think that those checks don't offer you ANY guarantee, they are merely an annoyance for legitimate users. And actually quite a few, by judging from this message board.

I'm sorry if I hurt anyone's feeling by possibly pointing at design errors, I think the project's idea is cool nonetheless.

The way I think you could make the HoneyPot installation simpler: assign one HPOT_TAG per user, don't attempt to lock things down by personalizing scripts etc, or at least don't expect the information coming from such scripts to be more reliable (actually, in my case it will be LESS accurate, I'll be forced to fake that the script is running at one place only whereas it may end up providing tracking addresses to other domains, too numerous to be configured individually).
Face it, the email address you sent the confirmation to is the only user-provided information you can trust anyway.

For MX donations: have a bulk-submit mechanism, and assign the same MX to all (sub-)domains submitted by the same user, possibly "username/unique-id.mxmailer.com".

Re: Too complex, too cumbersome?

Author: M.Prince (18 Jan 05 9:02pm)

O.M2 --
No hurt feelings at all. We've thought about this system a lot and, while intelligent people can disagree, we're pretty happy with the decisions we've made.

As you correctly point out, we have initially made a choice to begin with a relatively strict set of rules in terms of honey pot installation. We are, over time as we learn about the needs of our users, loosing some of these rules (and, incidentally, tightening others). For example, in part due to the feedback we've received through the boards, we just today loosened the restrictions on the domain on which honey pots are installed.

Our initial spec actually called for individuals to be able to install email addresses anywhere they wanted on their own web pages. (In fact, there are a few places in the FAQ where it's still written as if that's possible.) After much thought and debate internally, consulting with website administrators we trust, and talk with our attorneys, we decided that was a bad idea. If web admins need to place honey pots more places on their sites, there are mechanisms where you can create your own honey pot system. It looks like you're already using a custom-rolled system on your own website.

While you are correct to say that abuse is still possible, our lockdown measures have made it more difficult and easier to spot. If the current honey pot implementation doesn't make sense for your setup, we completely understand. Check back over time and we'll be adding additional ways (some of which may be less restrictive) for websites to participate.

In terms of MX donations, we are happy to accept bulk donations. We're toying internally with a public mechanism to do this. In the meantime, if you have 10+ MXs that you'd like to donate, feel free to contact us via the feedback form and we'll give you a way to donate them in bulk.

Thanks again for the feedback!

Re: Too complex, too cumbersome?

Author: K.Kirkpatrick (10 Feb 05 7:38am)

After becoming totally disappointed with MS OS's, and still having to use XP on my home system due to the requirements of software with which I make my living, I determined to make the effort to use Linux for my website.

I'm a complete neophyte to Linux, and it is a struggle at times, but as Netchze pointed out "that which does no kill us makes us stronger."
I have many tripidations about putting up a honeypot, many illdefined questions, and the spectere of doubt as to my ability to do this cleanly and correctly.
Having just finished making several inaffectual phonecalls to... among others Inflow.com and Omnis.com regarding their harvesting scripts running rampant through my site, I have sinched up my belt, drawn on the guantlets, and girded myself for warfare.

I don't care if it isn't simple, a lot of worthwhile things aren't.

The only thing that concerns me is that I will not submit, roll over, and become part of the problem rather than harden my resolve to contribute to a solution.

I do understand the sentiment though and know from first hand that it is a burden to try to make a living and do something complex and for which the rewards are not immediate, nor cost justifiable in traditional "bottom line" terms.

I have a multitude of questions and hope that I will be able to frame them appropriately that they not become an annoyance. I have an abiding faith that this community, as with others of its kind will accept my open ignorance at face value, and that I will aquite myself reasonably as a student of anti-spam kung-fu.

...I wil not go gently into that good night.

Re: Too complex, too cumbersome?

Author: D.Gorelik (16 Sep 08 11:05pm)

You wrote:
======
Our initial spec actually called for individuals to be able to install email addresses anywhere they wanted on their own web pages.
...
After much thought and debate internally, consulting with website administrators we trust, and talk with our attorneys, we decided that was a bad idea.
======

Could you share your reasons why you consider custom honey pots implementations a bad idea?
What potential bad cases are you thinking about?

I agree with O.M2 -- you didn't really address his questions.

Re: Too complex, too cumbersome?

Author: M.Prince (16 Sep 08 11:29pm)

D.Gorelik:
In short: the downside risk doesn't outweigh the upside. Specifically, our law enforcement partners have said that the cannot trust the data or submit it in court if it is collected in a non-standardized way. That makes the implementation of custom honey pot scripts a non-starter for us, but I'm happy to provide more technical reasons for the decision as well....

In the Project's history, having standardized honey pots has paid significant dividends. For example, several users asked if there was a way for us to being tracking blog spam. Because we had designed the software that distributed spam trap email addresses we were able to use hooks we'd built in to that software in order to deliver trap forms to the existing honey pots. Had we gone down the path suggested by O.M2 above, that update wouldn't be possible.

That said, if there are particular languages or platforms we do not currently support, we are happy to work with developers to develop a standardized script for dispensing spamtrap email addresses for those languages. As you can see from our Tech Specs page, several of our script languages were developed by users, approved by the administrators of the Project, and then made available to all its users. And, as has been the case for the last year, if you want to contribute data to the network and do not want to install our script then you can include a QuickLink on your page. This requires you to install zero software and takes advantage of the flexibility we could count on to be built in to our standardized scripts.

I'm not clear what the opportunity the Project is losing out on by not allowing custom scripts to dispense spamtrap addresses. Maybe you could make that more clear to me?

Note that while we do not have an API for dispensing spamtraps, we do have an API for taking advantage of the data the spamtraps collect: http:BL. We encourage developers to develop http:BL software to protect their web servers from malicious robots. There is no approval process to create software that takes advantage of the http:BL API and already more than 100 software packages have been created in order to do so.

Going forward, we are primarily concerned with ways to make the data we're gathering from our extensive network of traps more useful to more people. That is our development priority. After we've made more progress on that end we'll revisit the issue of spamtrap distribution.

Matthew.