Member
I dunno if you're like me, but it seems the more visitors I get to my site, the more often I have to delete comment spam and email spam from the contact page.
As I released more and more work the number seemed to grow, from a minor inconvenience to a major annoyance. I began looking at some of the options out there to combat spam for other CMS systems and came across a common backbone.
After creating a plug-in to combat the malicious posters, spammers, & harvesters, I have seen bad events fall off almost completely. And so I figured I'd turn it into a plug-in for use among the community.
And zenHttpbl was born.
*What does zenHttpbl do?
zenHttpbl utilizes Project Honey Pot's HTTP:BL service to stop spammers, harvesters, and comment spammers in their tracks. By utilizing the HTTP:BL API and making a DNS query to the PHP servers you are given information categorizing an IP from tracking records, identifying if that IP has been part of any suspicious or malicious activity.
This implementation does all this before serving any web pages, and then (if the visitor passes the thresholds you set via options) either redirects to a honey pot, or serves a blank page. Saving you traffic, and dramatically reducing annoying comment/content spammers.
For more information and download, please visit here.
Edit: Link correction and spacing correction.
As I released more and more work the number seemed to grow, from a minor inconvenience to a major annoyance. I began looking at some of the options out there to combat spam for other CMS systems and came across a common backbone.
After creating a plug-in to combat the malicious posters, spammers, & harvesters, I have seen bad events fall off almost completely. And so I figured I'd turn it into a plug-in for use among the community.
And zenHttpbl was born.
*What does zenHttpbl do?
zenHttpbl utilizes Project Honey Pot's HTTP:BL service to stop spammers, harvesters, and comment spammers in their tracks. By utilizing the HTTP:BL API and making a DNS query to the PHP servers you are given information categorizing an IP from tracking records, identifying if that IP has been part of any suspicious or malicious activity.
This implementation does all this before serving any web pages, and then (if the visitor passes the thresholds you set via options) either redirects to a honey pot, or serves a blank page. Saving you traffic, and dramatically reducing annoying comment/content spammers.
For more information and download, please visit here.
Edit: Link correction and spacing correction.
Administrator
Member
Correct, basically Project Honey Pot has two main features.
The first are the actual honey pots that people can setup, or QuickLinks that people link to. The links are generated in invisible divs and via comments etc. There are multiple ways to display the links, I just chose a div of 0x0 to be hidden. But the bots look at the code backend so when they follow the link they are given a bunch of fake email addresses etc (among other things) that they happily spam away at and get marked as being suspicious/spammer/harvester etc.
The second major part of the interface is the actual HTTP Blacklist they maintain. It's done via a DNS query, and then it sends a response based on the information PHP has stored in their databases. It stores the # of days since last "bad event", a threat rating based on # of spam messages, and the type of threat. All of this stored in a 4 octet IP result based on the initial DNS query. Quite ingenious and in use already among many email servers now. So Project Honey Pot decided to create a HTTP version that functions similarly.
And through use of their API I was able to create a simple plug-in for the zenphoto community. What the plugin does is the DNS query, and based on A) the response and B) the options the users sets up, it will either direct the spam bot to a honeypot, or will just kill connection saving bandwidth and time.
And more than happy to contribute when the time and inspiration strike me
The first are the actual honey pots that people can setup, or QuickLinks that people link to. The links are generated in invisible divs and via comments etc. There are multiple ways to display the links, I just chose a div of 0x0 to be hidden. But the bots look at the code backend so when they follow the link they are given a bunch of fake email addresses etc (among other things) that they happily spam away at and get marked as being suspicious/spammer/harvester etc.
The second major part of the interface is the actual HTTP Blacklist they maintain. It's done via a DNS query, and then it sends a response based on the information PHP has stored in their databases. It stores the # of days since last "bad event", a threat rating based on # of spam messages, and the type of threat. All of this stored in a 4 octet IP result based on the initial DNS query. Quite ingenious and in use already among many email servers now. So Project Honey Pot decided to create a HTTP version that functions similarly.
And through use of their API I was able to create a simple plug-in for the zenphoto community. What the plugin does is the DNS query, and based on A) the response and B) the options the users sets up, it will either direct the spam bot to a honeypot, or will just kill connection saving bandwidth and time.
And more than happy to contribute when the time and inspiration strike me
Administrator
Member
So, I got to thinking. "Hey Mike, how do they know the plug-in is working?" and my answer was "Well they have to trust me that it is." Realizing this wasn't the best way to handle things I've made a couple changes to the zenHttpbl plug-in.
[i]v1.4.0.3-7031
*Housekeeping change to file archive names.
*Added the ability to test zenHttpbl with manually set IP via options.
*Added rudimentary incremental counter to track the number of bad events blocked by zenHttpbl.[/i]
So the first thing is just a minor housekeeping change. I'm going to keep copies of the current archive/version as well as one named zenHttpbl-current.zip to avoid updating links constantly.
The second change was one that I thought would be a good addition. So when you've installed zenHttpbl you should notice not difference. You're not a bad IP (hopefully) so shouldn't see any change. So how do you know it works? First you browse over to the Project Honey Pot home page and select an IP off the naughty list. Then you enter it into the option for manual IP test, and enable the testing feature.
You'll then see how the plug-in functions, be either serving blank front-end pages or redirects to your honeypot. To disable, simply turn off the test, or delete the IP from the option setting.
The other change is pretty crude at the moment. I'm still working out a better way to enable/manage it, but I've added a minor tracking system. I've decided that I'm not going to try to incorporate the Project Honey Pot feeds for your sites because honestly, they're best served there. However, I do want to be able to display a quick reference for users to view in the backend (and possibly reset).
[b]Info, demo, and download: Here[/b]
[i]v1.4.0.3-7031
*Housekeeping change to file archive names.
*Added the ability to test zenHttpbl with manually set IP via options.
*Added rudimentary incremental counter to track the number of bad events blocked by zenHttpbl.[/i]
So the first thing is just a minor housekeeping change. I'm going to keep copies of the current archive/version as well as one named zenHttpbl-current.zip to avoid updating links constantly.
The second change was one that I thought would be a good addition. So when you've installed zenHttpbl you should notice not difference. You're not a bad IP (hopefully) so shouldn't see any change. So how do you know it works? First you browse over to the Project Honey Pot home page and select an IP off the naughty list. Then you enter it into the option for manual IP test, and enable the testing feature.
You'll then see how the plug-in functions, be either serving blank front-end pages or redirects to your honeypot. To disable, simply turn off the test, or delete the IP from the option setting.
The other change is pretty crude at the moment. I'm still working out a better way to enable/manage it, but I've added a minor tracking system. I've decided that I'm not going to try to incorporate the Project Honey Pot feeds for your sites because honestly, they're best served there. However, I do want to be able to display a quick reference for users to view in the backend (and possibly reset).
[b]Info, demo, and download: Here[/b]
Member
Couple of minor changes to the code today. First I verified that it's working with the latest official release (1.4.1.1) and changed the version to match.
Secondly I added a quick basic template function to display the current number of blocked events. So now you can display via the template call on your web pages somewhere if you want to show off how many bad events you've blocked.
Just a note, when you check your stats on Project Honey Pot, that only displays the # of actual traps set, what it doesn't count is the repeat visits. For instance, my Project Honey Pot dashboard shows 1,942 spam traps issued, however the counter has blocked access to bad IP's (according to my counter) 4,482 times.
For changelog, info, & download: Visit here.
As a note, I expect some additional enhancements to the counter display (image generation maybe), and a quick way to reset the counter without having to reset the database for it.
Secondly I added a quick basic template function to display the current number of blocked events. So now you can display via the template call on your web pages somewhere if you want to show off how many bad events you've blocked.
Just a note, when you check your stats on Project Honey Pot, that only displays the # of actual traps set, what it doesn't count is the repeat visits. For instance, my Project Honey Pot dashboard shows 1,942 spam traps issued, however the counter has blocked access to bad IP's (according to my counter) 4,482 times.
For changelog, info, & download: Visit here.
As a note, I expect some additional enhancements to the counter display (image generation maybe), and a quick way to reset the counter without having to reset the database for it.