[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:
You might be right despair, I'll need to check

I'm going to upload the previous version again until I can look into this

Back to 2.2.04c (and I'll leave it up as a previous stable release)


I've not seen any issues with CustomImgCaptcha + FBHP2.2.05 (used on surrey forum / and a few others), but I'll need to test reCaptcha / QA captcha

For now, 2.2.04c works perfectly (I was just trying to prepare for the update)
Click to expand...
Actually Mike, apologies for this, it's actually Waterfox and IE that aren't displaying KeyCaptcha. It's only working in Chrome. I'm going to remove that and just use your FBHP add-on.
 
Yes, 2.2.05 should work fine with other Captcha (it was just QA/ReCaptcha) due to the reason Despair mentioned.

2.2.04c will work with all Captcha (so that's the version up at the moment)

I have thought of a way of getting the best both worlds... If the user is detected as a bot (by FBHP / Other mechanism), then check the captcha (since they would be blocked from registration anyway), but don't call the captcha otherwise

So, I can still call the parent, and also confirm that the bot failed the captcha in the logs.

I'll wait for 1.1.4 and release it once I've tested it
 
tenants said:
but I'll need to test reCaptcha / QA captcha
Click to expand...
Yea, especially recaptcha. I thought of a way to fix the Q&A, but it wouldn't work for an external system like recaptcha. I think I remember one out of five times that I tested, the registration still managed to pass through somehow. That was past 3am though so I'm not sure if I was thinking straight...

tenants said:
I have thought of a way of getting the best both worlds... If the user is detected as a bot (by FBHP / Other mechanism), then check the captcha (since they would be blocked from registration anyway), but don't call the captcha otherwise

So, I can still call the parent, and also confirm that the bot failed the captcha in the logs.
Click to expand...
I think the only issue with that is if a user passes all bot checks, but then fails the captcha and you have the option "log passed events" on, it'll say the registration was allowed. A minor issue though, if there isn't a better solution I guess a compromise is necessary.

I was also wondering, does everyone more or less get 14 altered fields from bots on average? The majority of bots I get tend to often alter this many fields. The weird thing is I have disabled fields that can be tabbed to option on, and the count was the same previously. This would seem to indicate that the bots didn't fall for that set of honey pot anyways. Relating to this, I tried turning off captcha globally. As soon as I did it looked like a lot of bots suddenly only altered 2 or 3 fields, instead of 14. I wouldn't think disabling captcha (globally) would cause any difference, could it be a coincidence? Did anyone else notice their altered field count of recent bots drop down to only 2? The weirdest thing is before I disabled captcha, but only on the registration page and never noticed any difference. I guess I could try enabling captcha again and see if it goes back to 14. :confused:

That reminds me that if anyone sees their altered field counts suddenly dropping really low, they should make a post. If others see the same behaviour that could mean you could change all the FBHP fields to new ones and stop bots before they try to eventually crack all the fields? :p
 
Despair said:
I think the only issue with that is if a user passes all bot checks, but then fails the captcha and you have the option "log passed events" on, it'll say the registration was allowed. A minor issue though, if there isn't a better solution I guess a compromise is necessary.
Click to expand...

Yes, it's the only down side I can see. Sometimes in the logs, you might notice a user is a human and allowed to register through FBHP... but they seemed have been logged twice. On further investigation, you notice that the first attempted failed something in the registration. This is usually date of birth, non matching passwords, and sometimes the CAPTCHA. But, now if a human does fails the CAPTCHA, you won't be able to tell that from the logs. I don't think that's a big loss, what it more important is that you can tell that bots have passed/failed the CAPTCHA

Despair said:
I was also wondering, does everyone more or less get 14 altered fields from bots on average? The majority of bots I get tend to often alter this many fields. The weird thing is I have disabled fields that can be tabbed to option on, and the count was the same previously. This would seem to indicate that the bots didn't fall for that set of honey pot anyways.
Click to expand...

Bots will look for the standard fields (the honey pots) "username, email, timezone, password, password_confirm" and try to populate them. After that, most bots will populate the next x fields in index order (formname[5], formname[6], etc.) with defined text. Most bots will be caught by 14 fields (the 5 standard honey pots, + 9 others). If your form contain custom fields near the beginning of the form, then it will be caught by less. For instance, if you add another 4 custom fields after the usename, most bots will then only be caught by 10 honeypots.

On average, >90% of the bots I've seen get caught by 14 honey pots, a handful 15 and some around 11-13.

These number aren't because they're getting around the honey pots, but because XRumer is often set to auto populate 20 fields

Of the standard honey pots: "username, email, timezone, password, password_confirm" Sometimes the bot wont get tripped up by email/username, since they don't populate it on the registration form, but let it pass through from the login page.. when they pick up the session cookie. So, the bot sometimes gets the username/email correct

If you disable the tabbed fields, one of the reasons you aren't seeing a difference, is not because the bot was bypassing them already, but because it's getting picked up by the next fields. There are currently a total of 24 hidden fields, most bots only bother to populate the 1st ~20 fields (6 real, 14 hidden + possibly 1 captcha), there are still another 10 hidden fields that they haven't even gotten to yet. If you had 1000 hidden fields, most botters would still only bother to populate the first 20 or so (it's not very common that a form would have more than 20 fields)

.. additionally, when you select the option "Disable Hidden Fields That Can Be Tabbed Into" you are actually converting one type of hidden field to another (so you don't actually lose any hidden fields, so the bots would still be caught by them)

Despair said:
Relating to this, I tried turning off captcha globally. As soon as I did it looked like a lot of bots suddenly only altered 2 or 3 fields
Click to expand...

This I can't explain, other than every now and then you will get bots that target the standard fields only, so they will only get caught by 4-6 of the honey pots. 2 or 3 fields seems strange, what fields were they?

Dont forget, the javascipt mechanism is also a honey pot.. if they attempt to pass the wrong uuid through.. they get caught. If they don't attempt anything related to the js, they still get caught (but detecting bots via this mechanism is an ACP option that isn't even needed yet, since the hidden fields currently catch 100% of the bots)

And there is also the timer (which I expect to be beaten 2-3 months after it being introduced into the core, depending how large a target XenForo is). However, it was the weakest of all the mechanisms used in this plugin
 
Thanks for the explanation, makes sense.

tenants said:
This I can't explain, other than every now and then you will get bots that target the standard fields only, so they will only get caught by 4-6 of the honey pots. 2 or 3 fields seems strange, what fields were they?
Click to expand...
Yea, this is definitely weird. The ones that only alter 2-3 fields are altering either the username, email, or gender and skipping any of the UUID fields. Another thing worth mentioning is since I turned off captcha, the number of bots has increased by around 3 times... When looking more closely at the logs, it's not as if all bots suddenly dropped down to only altering 2-3 fields. Rather it seems like a new set of bots is hitting the site that only alter 2-3 fields.

For example, let's say I get an average of 20 bots per day, and most of them altered 14 fields. Now, I'll get 60 bots per day total. I'm still getting around 20 bots that alter 14 fields, but 40 new bots that only alter 2-3 fields. Which is weird, why are the ones that are smart enough to avoid the UUID fields only showing up as soon as I disable captcha. I'm probably going to turn it back on now and see if I find any difference...

Edit:
After at least 12 hours I can already see that indeed enabling the captcha again, the number of bots that were altering only 2-3 fields are almost all gone... Heh, it's as if the bots scouring the web thought, "Omg, this form has a captcha, I'm too tired and lazy, I'm not going to bother." Meanwhile when it's turned off, "Sweet, this form doesn't have a captcha, piece of cake, let's go raid it." Maybe you can try testing turning off captcha and see if the same thing happens, that is, if you think this is worth looking into.
 
Hi

Someone just contacted me saying they can't register on our site. Just tested myself and every time it says the captcha was failed. Not using any captcha though, only this add-on.

Any idea what could be going on? Thanks
 
Case said:
Hi

Someone just contacted me saying they can't register on our site. Just tested myself and every time it says the captcha was failed. Not using any captcha though, only this add-on.

Any idea what could be going on? Thanks
Click to expand...


Can you PM me your forum URL (and let me know what CAPTCHA addons and version of FBHP you are using)

If you are using FBHP 2.2.05, then use 2.2.04c (it's the one that it currently displayed for download)
 
Yes, the reason was due to using 2.2.05 with reCapthca / QA (This version was removed and the previous working version 2.2.04c was uploaded a few days ago)... This was mentioned above by Despair

Foolishly, I hadn't tested the reCaptcha/QA scenario for this version

2.2.05 is a bad version if you use reCaptcha / QA ... FoolBotHoneyPot 2.2.04c works without issues.
 
I have some false positive, with the registration timer failure.

Code: 
Registration Too Fast, FoolBotHoneyPot: Detected As A Bot - Registration Blocked
10 minuti fa
generated_by_username_attempt: Xxxxx
generated_by_email_attempt: xxxxxx@live.it
IP Address: xxx.52.132.9:65250
User Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22
Basic Proxy Detection: Possibly Forged IP Address, ipAddress (xxx.52.132.9) == ReverseDNS (xxx.52.132.9)
JavaScript Enabled: FALSE
Browser Plugins Detected: None
 
0 => fbhp_you_completed_the_registration_faster_than_the_min_registration_time
custom_field_piattaforma => please_enter_value_for_all_required_fields
 
 
USER => nginx
HOME => /var/lib/nginx
FCGI_ROLE => RESPONDER
SCRIPT_FILENAME => /store1/www/it.xfitalia.www/doc_root/community/index.php
QUERY_STRING => /community/register/register&
REQUEST_METHOD => POST
CONTENT_TYPE => application/x-www-form-urlencoded
CONTENT_LENGTH => 930
SCRIPT_NAME => /community/index.php
REQUEST_URI => /community/register/register
DOCUMENT_URI => /community/index.php
DOCUMENT_ROOT => /store1/www/it.xfitalia.www/doc_root
SERVER_PROTOCOL => HTTP/1.1
GATEWAY_INTERFACE => CGI/1.1
SERVER_SOFTWARE => nginx/1.2.6
REMOTE_ADDR => xxxx.52.132.9
REMOTE_PORT => 65250
SERVER_ADDR => xxx.xxx.44.78
SERVER_PORT => 80
SERVER_NAME => www.xfitalia.it
HTTP_HOST => www.xfitalia.it
HTTP_CONNECTION => keep-alive
HTTP_CONTENT_LENGTH => 930
HTTP_CACHE_CONTROL => max-age=0
HTTP_ACCEPT => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
HTTP_ORIGIN => http://www.xfitalia.it
HTTP_USER_AGENT => Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22
HTTP_CONTENT_TYPE => application/x-www-form-urlencoded
HTTP_REFERER => http://www.xfitalia.it/community/register/register
HTTP_ACCEPT_ENCODING => gzip,deflate,sdch
HTTP_ACCEPT_LANGUAGE => it-IT,it;q=0.8,en-US;q=0.6,en;q=0.4
HTTP_ACCEPT_CHARSET => ISO-8859-1,utf-8;q=0.7,*;q=0.3
HTTP_COOKIE => tapatalk_redirect=false; __gads=ID=8e8fd04fe09dd30f:T=1363630881:S=ALNI_Mam1j9RVis5k46JapjYoZ5LAvOrZw; xf_sonnbLimitGuestViewing=4; xf_session=3772894163f33afad9e352a02078a7bf; __utma=210929244.2013316177.1363630876.1363630876.1363630876.1; __utmb=210929244.31.10.1363630876; __utmc=210929244; __utmz=210929244.1363630876.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
PHP_SELF => /community/index.php
REQUEST_TIME_FLOAT => 1363632011.116
REQUEST_TIME => 1363632011
 
Giorgino, that person that attempted to register is already registered (look at their cookie)

HTTP_COOKIE => tapatalk_redirect=false; __gads=ID=--------------------------------0f:T=1363630881:S=--------------------------------; xf_sonnbLimitGuestViewing=4; xf_session=--------------------------------; __utma=--------------------------------; __utmb=--------------------------------; __utmc=--------------------------------; __utmz=--------------------------------.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
Click to expand...

They are also not completing all of the fields

custom_field_piattaforma => please_enter_value_for_all_required_fields
Click to expand...

The time is settable in the ACP, by default this is 7 seconds...

I've registered on your site (without issue), I've also PMed you to try to reproduce this, but I've never seen false positives.
 
I've looked into Giorginos issue above.

The issue seems to have stemmed from database disconnections (database reaching a limit), and occurred infrequently (not with all user registrations).
Database limits should be definable by the host (they have either used an unreasonable limit, or the forum is under stress / needs an upgraded server package)

In Giorginos case, every now and then a database limit / disconnection occurred. Since the time start/end for the registration timer is inserted directly to the database, every now and then it looked like a human didn't even have a value for the timer (not even 0 seconds).

This wont happen under most circumstances, and if it does, the host really needs to be contacted (look at your server logs, if you have lots of timeouts / database disconnections, then you might want to consider contacting your host)

Zend_Db_Statement_Mysqli_Exception: Mysqli statement execute error : Lock wait timeout exceeded; try restarting transaction - library/Zend/Db/Statement/Mysqli.php:214​
Click to expand...
Error #110: Connection timed out - library/Zend/Http/Client/Adapter/Socket.php:235​
Click to expand...

With Giorgino issue, we've set the timer to 0 seconds until the database issues are resolved (1.1.4 will have a timer anyway ;) )

The timer works as designed, database disconnections / limits are server issues (unrelated to this plugin)
 
tenants updated FoolBotHoneyPot Bot Killer: Spam Combat with a new update entry:

FoolBotHoneyPot_v2_2_07 For XF 1.1.4

FoolBotHoneyPot_v2_2_07.zip

Release 26/03/2013
Change Log:


  • Compatible with XF 1.1.4.
  • Now calls parent actionRegister (and lets parent call the CAPTCHA unless known as bot) => Makes the PHP compatible with other plugins that use the actionRegister and should't need updating for upgraded
  • Template edit fot the Registration Form now displays the count down timer, and includes the registration Key
There is now no need to have a timer in FBHP (since XF correctly uses a session timer, this is saved directly to the database and can't be manipulated... this is the same method that FBHP already used)... This timer will be removed next version.

Next version I'll use hooks for the registration page (so it will be a custom registration page based on hooks, making the registration template more compatible)
Click to expand...

Read the rest of this update entry...
 
I released this version pretty quick after the release of 1.1.4, so let me know if you see anything

I'm testing it myself now

The order of events:

1) FBHP will still catch the bots 1st using hidden field honey-pots / JavaScript detection honey-pots / timer / customisation of the form / other mechanisms
1) (Yes this can happen at the same time) AnyAPI can still be used to detect spammers using Any API you want (StopForumSpam, etc.)
2) The XF core registration timer displays correctly on the registration form, a bot can then be caught by this (if is hasn't already been caught by the above)
3) The XF core API calls to DNSBL can then be used (which by the way, you should have been able to set up with AnyApi if you wanted to) ;)
 
I don't honestly know

Since it's calling the actionRegister from the parent, it shouldn't matter. I belive it should work with older versions too (but it wont display the count down on the registration form, since that option can't be pullled from the ACP). The key will just be an empty string on the registration form... but, since the parent doesn't look for a key, the actionRegister won't be looking for it, so it should't matter

I'm going to say it should work with 1.1.3 too, but I've only tested it with 1.1.4 so far
 
You must log in or register to reply here.
Top Bottom