[TAC] Fool Bot Honey Pot

[TAC] Fool Bot Honey Pot [Paid] 3.0.32

No permission to buy ($29.00)
Overview Updates (79) Reviews (28) History Discussion
tenants said:
I'm not sure if you know this, but one already exists. The stopbotters API response remains stored in the database for 5 minutes (to prevent repeat API requests)
- I could use a similar method to optionally ban the user too (and extend the time to an optional period - 1 day - X days)
Click to expand...

Thinking about this further, banning the IP might not even be required. Just disabling registration for that IP for X amount of time would be sufficient (if that functionality exists).

My reason for requesting something like this is I seem to get hit by bots in waves. The last one a few minutes ago had 34 attempted registrations in a 2 minute period. If there was a way to block the repeated attempted registrations it would be a nice addition.
 
I could add something local, but keep in mind, once they are detect as a bot (IP or email), the API won't let them though for at least 4 weeks anyway. Look at your logs, and you'll notice the repeat offend are always detected by stopbotters... In fact, there are rarely any bots that aren't detected by stopbotters, it's efficiency at detecting bots has overtaken StopForumSpam by a fair amount. So these repeat offenders aren't ever going to get anywhere, but by banning them locally too, it might save a little on resources
 
Last edited:
tenants said:
I could add something local, but keep in mind, once they are detect as a bot (IP or email), the API won't let them though for at least 4 weeks anyway. Look at your logs, and you'll notice the repeat offend are always detected by stopbotters... In fact, there are rarely any bots that aren't detected by stopbotters, it's efficiency at detecting bots has overtaken StopForumSpam but a fair amount. So these repeat offenders aren't ever going to get anywhere, but by banning them locally too, it might save a little on resources
Click to expand...

I see what you mean re large block lists - i checked my db and my API cache has 30,000+ entries for the last month.

I know it is blocking them - it does an awesome job at that. Saving resources was the thought by stopping them repeatedly submitting the registration form.
 
How does stop bot resources detect what is and isn't a bot? Could you update that to use stopbotters? That way once an IP is detected, stop bot resources takes over and displays the chosen page (eg 404)?
 
Hi. Most excellent plugin - but interesting thing. Recently I have checked the log and found no entries - as though the log has been deleted.

This isn't something that's happened on a regular basis - as though scheduled, but rather something which has happened three times in the last week.

I was wondering if there's a vulnerability that I'm unaware of? Thus far we're blocking 100 percent of bots trying to register, but we're getting a deleted log.

BTW - this is the full registered / paid for package.

Any help appreciated.
 
It clears up the logs, so you never have more than 1 months of bot logs in the system at any one time.

It's still working, I get a unique a bots roughly every 2-5 minutes on my spam trap site
They almost completely avoid some of my sites, since they know I automatically detect them

So the sites they know about, I'm blacked listed by bots :).
For Xrumer, this is done using xblack.txt. By black listing sites that report / detect them, it is hoped by the bot users, their IPs stay undetected for longer

.... It they know you're using FBHP and are autodetecing/repoting them, it might just be your site has been added to the genral black list and is avoided by many XRumer users, see:
https://www.google.co.uk/search?q=xrumer xblack.txt


Also, are you by any chance using stopbotresources?
The API that sbr uses is now very accurate (barely any bots get past now), it detects a higher Frequency of bots that StopForumSpam, so this could be another reason your bot troubles are over :)

Can you send me the URL via pm, and I'll test it, you are using the latest version (2.2.18) ?
 
Last edited:
Ah, not the latest version. The thing was the list cleared then a day or two later cleared again.

I am using FBHP, ANYAPI, and StopHumanForumSpam.

I am autodetecting and reporting but still they come by the dozens.

I'll upgrade and let you know.
 
It works great on registration, is there any possibility of it being extended to the "contact us" form as well to stop the bots posting spamming that?
 
Yes, I could use that. I was using question and answer "captcha" before, but the bothoneypot was working so well, I turned captcha off to make registration easier - which is working well. However this obviously opened up the contact form and I guess if the various TAC tools were applied to there, particularly the hidden fields etc, they would work just as well on that.
 
XF 1.3
Addon v2.2.19

@tenants, I've just had to disable the addon as I've found it's now blocking numerous valid registrations because it appears the Altered Hidden Field Count is not working correctly, and counting valid/shown fields as hidden fields - and then denying the registration. Example:

Code: 
Hidden Fields Modifed, FoolBotHoneyPot: Detected As A Bot - Registration Blocked
Today at 10:01
generated by username attempt: dctlcox
generated by email attempt: davidcox1@mac.com
IP Address: 180.148.120.187:41098
User Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B329 Safari/8536.25
Time Taken To Register: 273 (seconds)
Basic Proxy Detection: Possibly Forged IP Address, ipAddress (180.148.120.187) == ReverseDNS (180.148.120.187)
JavaScript Enabled: TRUE
Browser Plugins Detected: quicktime=
Altered Hidden Fields
username => dctlcox
email => davidcox1@<redacted>
timezone => Australia/Sydney
password => <redacted>
password_confirm => <redacted>

Registration Errors
fbhp => foolbothoneypot_sorry_youve_been_detected_as_an_automated_program
username => please_enter_name_that_is_at_least_x_characters_long
email => please_enter_valid_email
timezone => please_select_valid_time_zone
password => please_enter_valid_password
dob => please_enter_valid_date_of_birth

I'm also getting what appears to be invalid proxy detections ...

Code: 
FoolBotHoneyPot Logs
[LIST=1]
[*]Delete...
Hidden Fields Modifed,
FoolBotHoneyPot: Detected As A Bot - Registration Blocked
Today at 10:01 : 180.148.120.187:41098
Username: dctlcox
Email: davidcox1@<redacted>
User Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B329 Safari/8536.25
Time taken to register: 273 (seconds)
JavaScript Enabled Browser: TRUE
Altered Hidden Field Count: 5
Basic Proxy Detection: Possibly Forged IP Address, ipAddress (180.148.120.187) == ReverseDNS (180.148.120.187)
Browser Plugins Detected: quicktime=
Bot Detected On StopBotters: FALSE
Detected on Stop Forum Spam FALSE
[/LIST]
 
The basic proxy detection is correct, it does not block based on proxies and many ISPs do not have ipAddress == ReverseDNS (This I find strange for an ISP, but it is not that uncommon)
... this is just logged for information (It's a possible forged IP address, not an actual forged IP address), user are never blocked due to proxy detection.
Some ISPs will even manipulate transparent proxies (which I find very strange, but can happen). This is why FBHP only logs this information, and does not block users based on proxy detection

The altered hidden fields however will block users (this really only happens with bots, or when another plugin manipulates the registration page / the registration template has been altered)
That very much looks like a real user (from looking at JS/Plugin detection, it's unlikely a bot would fill those)
Have you used another add-on that might alter the registration page?

I'm using this on XF 1.3 and find it impossible to get blocked without altering the hidden fields...
I register successfully, and 100% bots get detected (users register without issue)

(But then I am not using add-ons that might alter the registration page)

It works well with 1.3 and blocks bots without humans noticing, they way it is written should now also better allow other add-ons to manipulate the registration page (that might be the issue), what could the other add-on be?
 
Last edited:
@Mouth, yes there is something quite different about your registration page, since the page has classes such as:
class = "fa fa-envelope fa-lg fa-fw"

Can you go to your template modification page and see which ones have been applied:

upload_2014-3-14_14-14-49.webp


Instead of editing the template, you could manipulate the page with the EXTRA.css (unless this was done with another plugin)

It's not possible to look for a string of template code and replace it (as to work with other add-ons) if the string of template code is not there to begin with. One possibility is to have an ACP option to work in "legacy mode" where we use the old registration template (this template is still there since FBHP still works pre 1.2, without template modifications)

Another further improvement could be made with the template modifications, instead of looking for entire string chunks, I could make better use of regex and just look for ids/classes

@Mouth You have two date of births on your registration page (and things look misaligned), so I'm suspecting you have manually edited your registration_form template (try rolling your template changes back)
 
Last edited:
Okay, I've made some changes

You no longer need to leave the registration_form template as "is", even if changes are made to the core template, it shouldn't cause an issue with FBHP
You can probably make the changes you want, as long as you leave the original ids in (and don't duplicate these ids):
id="ctrl_username"
id="ctrl_email"
id="ctrl_password"
id="ctrl_confirm_password"
id ="ctrl_gender_male"
id ="ctrl_gender_female"

Since I now use regex for the template modifications:
#<dl[^>]+>[^<]+<dt><label for="ctrl_email.+ctrl_email(.*?)</dl>#siu

I've also added an option in the FBPH Options:

upload_2014-3-14_15-49-10.webp

With the regex changes made, I really doubt this option will be needed,
Unless xenforo decide to change the registration form template vastly, or another add-on does something very strange, then dont tick this (this is a fall back "last option" / if all else fails)
You will possibly only need to tick this option if you (the admin) / a plugin has done something very bad.. such as adding multiple "unique" IDs to the registration_form(tut tut)

It also means I can get rid of the redundant hidden time-zone modification

So this is incredibly robust.. this allows for other plugins to do ILLEGAL things (duplicate ids), allows for admins to change the core registration_form template (as long as ids that should always be present remain present), and if all else fails, there is a legacy mode which should avoid any add-ons causing issues with the registration_from template (which shouldn't happen with the template modification anyway)

I will release this shortly...
 
Last edited:
tenants said:
Okay, I've made some changes

You no longer need to leave the registration_form template as "is", even if changes are made to the core template, it shouldn't cause an issue with FBHP
You can probably make the changes you want, as long as you leave the original ids in (and don't duplicate these ids):

[...]

I will release this shortly...
Click to expand...

Terrific, thanks! That will very helpful and resolve the issue I have.
 
tenants updated FoolBotHoneyPot Bot Killer: Spam Combat with a new update entry:

legacy and regex-template modifications

FoolBotHoneyPot_v2_2_20.zip
Release 14/03/2014
Change Log:
  • Added a legacy option, to use an independent registration_form template instead of template modification (this should not be needed in most cases, if any!)
  • Template modifications now rely on regex, meaning the registration_form in most cases can be manipulated without issues (as long as the expected ids remain in the template)
Click to expand...

If you make changes to your registration form, it's still recommended, any changes to the registration_form template should be done via the EXTRA.css where possible. The regex will be able to find and replace a lot of cases, but adding new nodes to the registration_form template might cause the regex to not find a match

Always check that the regex is working for this add-on when installing by checking your template modifications area (if you have made registration_form template changes):
yoursite.com/admin.php?template-modifications/

If you have not made registration_form template changes, there is no need to worry, this plugins works out of the box.

Read the rest of this update entry...
 
Last edited:
You must log in or register to reply here.
Top Bottom