[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
I just got my account suspended from this plugin "Extremely high server resource utilization,
This account is having a MySQL resource usage issue; one of your XenForo plugins appears to have "gone rogue," as
it's attempting to read millions of rows from sf_foolbothoneypot_uuids and sf_foolbothoneypot_log "

How can this be fixed? Thanks

P.S. Other than this issue, this plugin killed 100% of my spam problems, and I used to get spammed 1,000 posts per day!! Amazing plugin
.
 
peppes said:
I just got my account suspended from this plugin "Extremely high server resource utilization,
This account is having a MySQL resource usage issue; one of your XenForo plugins appears to have "gone rogue," as
it's attempting to read millions of rows from sf_foolbothoneypot_uuids and sf_foolbothoneypot_log "

How can this be fixed? Thanks

P.S. Other than this issue, this plugin killed 100% of my spam problems, and I used to get spammed 1,000 posts per day!! Amazing plugin
.
Click to expand...

Are you using the latest version? It is suppose to prune old entries.
 
A note to anyone using this and occasionally having the odd user go in to moderation

FoolBotHoneyPot does not put users in moderation, it is the core xenforo APIs that does this
FoolBotHoneyPot does stop 100% of bots and does not suffer with false positives
However, the core APIs may pick up false positives every now and then

FoolBotHoneyPot pretty much wipes out the chances of bots getting picked up by the core APIs, since they are already stopped.
So, if you have users in moderation, it is very possible they are real users picked up as false positives by the xenforo core API usage (or other APIs)

So, if you have users in your moderation queue, they are very unlikely to be bots (they could still be human spammers)... so email them
Out of 3 user I've had in my moderation queue across 3 forums, 3 out of 3 have been genuine users (no spam)
- APIs (from the core or other) and especially layers of APIs may pick up false positves
 
We have users go into moderation almost daily. I'm guessing that most of the time they will be people whose IP or email address is on stopforumspam. But there is no indication as to why they are in the moderation queue, and this is quite an important omission requiring work by the moderators to figure out why the account is in the queue and what to do with it.
How do you think we could resolve this please?
 
This add-on, to my knowledge, completely prevents registration and there are very few (if any) false positives. Everything is logged in its logs.

It does not, as far as I can remember, put users into the approval queue.

That sounds like XenForo has detected something. There are some XenForo default anti-spam things that can do this, but the reason is not logged anywhere. Improved reporting for that has been suggested.
 
Stuart Wright said:
We have users go into moderation almost daily. I'm guessing that most of the time they will be people whose IP or email address is on stopforumspam. But there is no indication as to why they are in the moderation queue, and this is quite an important omission requiring work by the moderators to figure out why the account is in the queue and what to do with it.
How do you think we could resolve this please?
Click to expand...

I can only suggest to contact them, and simply query them (put their IP or email address into search engines) or search each of the APIs. It would be nice to have more data when users a put into moderation (so if we are picking up false positives from particular APIs, the core can be tweaked).
As Chris mentioned, putting users into moderation is core behaviour, and since they have got passed FBHP they are unlikely to be bots. From my own experience, they've also not been spammers (but that is across a only a few forums, none have daily user moderations).

However, StopForumSpam (and other APIs) will stop human spammers, FBHP will not. So, it is possible some of these will be human spammers or false positives. If you have that many, google a few, it might just be that StopForumSpam is picking out the human spammers in your case.

In my experience, APIs are definitely a useful broad catch (one that is very hard to bypass), and may outlive many mechanism (it may one day be our only resort... although there are ideas to bypass even APIs)
But, the more APIs are used in combination, and the more weight they are given, the more false positives are picked up (they can be noisy when relying on human reports)

It would be a good idea to see why/when the core has found false positives (by putting users who are not spammers into moderation) and to be able to tweak the APIs in accordance. Although defining "users who are not spammers" accurately might be harder than 1st thought. Spammers tend not to reply to emails, and re-join the community with a positive outcome (this is not a hard an fast rule for previous human spammers, we are very assorted)
 
I think what is needed is an addition to the user moderation queue stating why they are there. If it's been triggered by SFS then it needs to be something like 'match to suspect IP on SFS' with a link to interrogate that IP on SFS.
And the same kind of functionality if it's triggered by matching email address or username.
Email address is a much bigger deal, as that more likely to be a genuine catch.
Generally I look at what functionality is needed and then do my utmost to make that happen.
So what do I need to do to make that happen in this case?
 
Last edited:
As stated above, the action of putting users in the moderation queue is carried out by XenForo. A suggestion has already been made with regards to better reporting why each user has been rejected.
 
I have a question about proxy headers.

My web server is behind a nginx reverse proxy with IP forwarding enabled. FoolBotHoneypot detects all registrations as having proxy headers and gives them a negative point for it.

Is there a special way I can configure my proxy headers in nginx to play nice with FoolBotHoneyPot or just disable proxy headers as a bot detection method?
 
FoolBotHoneyPot wont do anything about proxies, it just informs you... this is basically extra information so you can tell FoolBotHoneyPot is blocking bots and never humans
.. it also does this for browser plugins, bots will never have browser plugins, but often humans will (flash, pdf readers, java etc), there is also an indicator for JavaScript. However, for JavaSctipt, you can optionally block users / bots that do not have js swicthed on

For proxies and plugins, FoolBotHoneyPot is just logging the information to give you (the admin) reassurance that it's blocking bots and never blocking humans

To prevent proxies, use StopCoutrnySpam. However, since you don't wont to stop proxies, it's only logging the information, there is no need to do anything

There are no negative points

You can read here to see how FBHP works:
http://xenforo.com/community/resources/foolbothoneypot-bot-killer-spam-combat.1085/
 
I have a problem.

I've been testing the FoolBotHoneyPot that is included with the free antispam collection.

I've installed it as instructed by the instructions, and everything looks good.

The problem is that when a human user tries to sign up, he's informed that the Username and E-mail address is not unique.
At the same time if a bot tries to sign up it gets accepted and everything is working fine for them and they are free to spam my forum as they like.

This made me guess that somehow the functionality is reversed. But nothing shows up in the logs of either FoolBotHoneyPot or AnyAPI.
If I disable FoolBotHoneyPot everything gets back to normal and human users can sign up again.

I checked the html source of the registration page with FBHP enabled and it show's all the extra name and email fields hidden in various ways. So it's using the right template.
I have made no changes to the template at all.

XenForo v 1.2.4

Any idea what is wrong and how I can fix it?

Edit:
After disabling FBHP it now allows AnyAPI to work.. before FBHP would somehow bypass it and let the spammers through.
 
Last edited:
That's very strange behaviour.

Do you use any other add-ons that might manipulate the registration page, and can you send me the url of your site

"Username and E-mail address is not unique." is not a foolbothoneypot error

I wonder if it is an issue with 1.2.4
It's also not a 1.2.4 issue, since I use it myself with 1.2.4

Not having any logs for FoolBotHoneyPot is strange, I think there is something else at play in your set up, but will need to look at your site to see
 
Last edited:
The site is: www.choicecraft.net

And we have these add-ons installed:

  • ******* - Change Threads/Posts Owner (Prenium) 1.2.2
  • MicroSupport 1.1.0
  • Minecraft Avatar 1.1.0
  • Nodes As Tabs 1.2.2
  • Post Ratings 1.6.0
  • Server Address 1.0.0
  • TAC AnyApi 1.0.3
  • TAC FoolBotHoneyPot - Stop bots from registering with honey pots 2.2.13 (Disabled for now)
  • Tapatalk 1.9.0
  • [8wayRun.Com] XenPorta (Portal) 1.6.0
  • [8wayRun.Com] XenUtiles (Spam) 1.0.1
  • [Herocraft Development] Minecraft Status 2.2.0-b1 2.2.0-b1

Both FBHP and AnyAPI logs was empty until I disabled FBHP then AnyAPI started to work and block spammers during registering.
 
As a test, try turning off XenUtiles and turning back on TAC FoolBotHoneyPot
I'm not really sure what XenUtiles does any more, I don't think it's used on the registration form (but I've never had need for it, since no spam gets through)

Does Minecraft Avatar pick your avatar up from some where on registration?

What is "Server Address 1.0.0", do you have a link to that addon
 
Last edited:
Error when registering on XF 1.3

Code: 
Fatal error: Call to undefined method XenForo_Model_Login::convertIpToLong() in /home/nginx/domains/dev.z22se.org.uk/public/library/Tac/FoolBotHoneyPot/ControllerPublic/Register.php on line 572
 
Hmm, they've removed this function? Wouldn't it have been better for plugin compatability if the core had updated this method to support ipv6, rather than remove it and add new methods... Oh well, guess I will need to look at this

Thanks for letting me know
 
You're free to mention things like that in suggestions. We don't promise 100% backwards compatibility in second point releases but if it's a simple change, then we may do our best to restore it.
 
The suggestion may or may not get implemented. By the time the decision is made, the release product may be on it's way.

As an add-on developer, by the time a release product is made, I would like to make sure the add-on works (so often use the XenForo beta to make sure that this is so). So I often feel making the suggestion is counter productive (I might be waiting in vain that it get's implemented, but then doesn't just before release). So, it's often easier and quicker to make a change to the add-on

I do feel that changing core methods names isn't a great idea for plugin-support (maybe it had to be done for what ever reason, I'll need to look)

... In saying this, I could have probably made the necessary changes and released it in the time I made this comment :cautious:
 
Last edited:
Conversely in the time it took you to write that, you could have suggested it, Mike could have read it and implemented that change for Beta 2 :LOL:
 
You must log in or register to reply here.
Top Bottom