[TAC] Fool Bot Honey Pot [Paid] 3.0.32

[Case]

Working fine again now. Thanks for the quick response.

 

[D.O.A.]

I'm liking the new log layout and information provided... this mod made our lives easy again

 

[tenants]

I'm liking the new log layout and information provided... this mod made our lives easy again

View attachment 37566

It gives admins a lot more confidence that this is only preventing bots

You'll notice that almost every bot fake their user agent to look like a browse, this was mentioned here:
http://xenforo.com/community/threads/xrumer-discussion.41538/page-2#post-447724
user_agent hasn't been a good method for distinguishing bots for a long time (so we don't use it)

The timing method works a lot of the time, but it's not 100% ... some bots do actually take a while, this can be due to slow proxy connection or slow server connection. I don't think they are intentionally pausing yet, but they will eventually, although I have seen some bots take as long as 27 seconds

The honey pots and hidden fields are currently 100% effective

(I have a couple of other methods that I believe are also 100%, I'm currently logging the information and checking this, I will add it to the next update)

All of these methods will only affect bots, users will not be affected by these methods.

 

[tenants]

tenants updated FoolBotHoneyPot Bot Killer: Spam Combat with a new update entry:

FoolBotHoneyPot Bot Killer - update: proxy , JS , plug-in detection, field names created on the fly

• Now detects basic proxies (more than 80% bots seem to use easily detected proxies)
• UUIDs of form field names are now generated on the fly (for each session), meaning the registration form is different each and every time for bots
• JavaScript detection is now possible (XRumer is not a JavaScript Enabled Browser)
• Plug-ins of the Browser are now detected (bots do not have any of the standard plugins installed)

Read the rest of this update entry...

 

[tenants]

Since not everyone really understood how this plugin works, and users may have had to take it at face value that some how this plugin prevents 100% of bots without affecting users... I've now added full descriptions of each of the mechanisms that this plugin uses to the front page (and below):



The Honey Pot Mechanism

• XRumer and many other bots will often try to register by sending a request directly to the registration form (carrying over the session cookie). In order to populate the form, the bots will use fields names, text is then injected into the field values containing that name (this process is written into a script / used by a standard script against XenForo registration), these field names will often be standard field names such as name = "name", name = email, name=password.. etc
• With the Honey Pot Mechanism, these fields still exist but are hidden (from humans). A bot will automatically fill these fields, but by doing so the bot has been fooled by the "honey pot" and is subsequently prevented from registering
• Additionally, XRumer bot users will sometimes write the script so that all form fields are populated, this will of course be caught by the standard honey pots, additionally there are multiple other hidden trick fields that will catch these bots, and these fields are named with uuids that are created on the fly for each session

The Form Customisation Mechanism

• As mentioned above, XRumer and many other bots will try to inject information into forms by using fields names that it knows (name=email, name=password)
• With the customisation mechanism, each of the valid field names (the fields that a user can see) are now uniquely named, and new names are created for each session.
• Since the bot will not know which fields names are which (for instance which is the email and which is the password_confirm) it makes it incredibly difficult for the bot to know how to populate the form correctly, once again preventing the bot from registering

The Form Field Randomisation Mechanism

• For those bots that do not use fields names, but simply populate the form according to form index order, this is an addition mechanism to trip them up
• By randomising the field order , it makes it incredibly hard to populate a form according to index number.
• The fields are randomised every time the registration page is loaded/refreshed

The Registration Timer Mechanism

• This registration timer mechanism can not be manipulated or altered by injection/inbetween applications.
• The time from the point of that the registration page is first loaded for any give user session is recorded directly into the database (not sent by requests). This prevents bots from manipulating the mechanism
• This mechanism also allows users that make a registration mistake to then be able to complete a partially populated form very quickly without being blocked (since the time is recorded from the point that the registration is first loaded for that given session)
• Registration time mechanisms are not a 100% effective against bots, since many proxies are slow (and often hosts will experience laggy periods)... this is why you will notice that some bots will take 20 seconds or more to register

The (Optional) JavaScript Detection Mechanism

• This registration prevention method is optional (defined in the ACP)
• As you probably know, many bots are simply applications running scripts, they do not have their own JavaScript version, they simply fake what they can.
• This method detects the availability of JavaScript by sending an Ajax request at the time of registration.
• If no Ajax request is made, then the browser does not have JavaScript enabled (and has a high potential of being a bot).
• This information is logged for bots, but there is also the option (in the ACP) to not allow users that do not have JavaScript Enabled to register.
• If a genuine user attempts to register without JavaScript enabled, they are presented with an error asking them to enable JavaScript.
• At the time of writing this, approximately 98% of users have JavaScript enabled by default (and it's even higher in certain countries)

Basic Proxy Detection

• This has not been used as a preventative mechanism for this plug-in, but for each bot that fails registration, this information is logged. There are many ways of detecting proxies, but none of them are full proof. One mechanism is to detect open ports (some times know as scanning back). However, this is time consuming (can take between 1-3 seconds or longer for each port), since bots can use any port ranging from 0 to 65535, and will often use rare / non standard ports, this type of detection has not been used.
• Instead the headers have been checked for known proxy variables (this catches mainly transparent proxies)
• Additionally, proxies are detected with a ReverseDNS Look up (catches some anon/high_anon proxies)
• Additionally, proxies are detected by comparing the ReverseDNS IP address to the hostname for that IP address. (catches some anon/high_anon proxies)
• After testing this, approximately 70% of bots were found to be using proxies that were easy to detect using these proxy detection mechanisms (so this may be added as an optional preventative mechanism)

User Agent Detection
This has not been used as a preventative mechanism for this plug-in, but for each bot that fails registration, this information is logged. Patterns of user_agent can give you more confidence that the bot detection is valid, but for a long time now, many bots fake the user_agent header to appear as if they are browsers

Browser Plugin Detection
This has not been used as a preventative mechanism for this plug-in, but for each bot that fails registration, this information is logged. Users will often have JavaScript enabled (bots will often not). By having JavaScipt enabled, it is then possible to detect which plug-ins the browser supports

 

[erich37]

maybe tenants you have an idea to this ?
http://xenforo.com/community/threads/spam-bots-targeting-xf-websites.41861/

 

[tenants]

tenants updated FoolBotHoneyPot Bot Killer: Spam Combat with a new update entry:

FoolBotHoneyPot Bot Killer - minor fixes

• Corrected the versioning (2.0.x not 1.0.x)
• Turned logging of altered hidden fields back on

Read the rest of this update entry...

 

[tenants]

tenants updated FoolBotHoneyPot Bot Killer: Spam Combat with a new update entry:

FoolPotHoneyPot - javasctript logging bug fix

• For Logging purpopsues only, you may have noticed that some real users were getting logged as not having javascipt enabled (but javascript detected), these users would have been able to register without issue, but would have been logged as not having javascript enabled.. (but yet detected???). This was a silly school boy error, "$nonJSBot = true" shoud have been "$nonJSBot == true" in the logging section.

Read the rest of this update entry...

 

[HannahP]

Let me just say, kudos to you and yours on this.

In the past few days I've been getting hammered, but within five minutes of installing FoolBot, it had blocked three attempts (and in the time I spent typing the above, it blocked two more).

I would kiss you, but I don't know where you've been.

 

[tenants]

I know where I've been, and I definitely wouldn't want to kiss me

 

[Wulfspider]

I've been having a little issue while testing this... all user registrations are coming up with the same obfuscated username and email address (with UUID in it I assume). It reported them as bots to a couple API places (which I contacted regarding the issue), but the are not bots. I'm working with one user right now to resolve the issue, just trying to figure out why it's doing that, as users can't register in the mean time.

Shouldn't those fields be unique as well, not the same for every user? I thought that was one of the features. I've tested this myself numerous times as well, and it keeps trying to create a user with those obfuscated field names/values.

Currently testing with 2.0.06.

 

[tenants]

What plugin are you using this in combination with?

The visible (valid) email address and username fields are dynamically named (and this changes every session).

If another plugin tries to use these fields, they won't know what these fields have been renamed to (In a similar way, a bot also does not know).
What the other plugin will do, is use the values for the hidden "username" and "email" ... and then try to "do stuff" with the values of those fields names. In this case, these are hidden and not supposed to be used.

I've spoken to Sonnb, and provided him a solution for Stop Spam Here, in theory the current version should work with his plugin... (I don't know that this is the case though)

However, I strongly suspect that this plugin wont work with XenUtiles
There is a way around this, but it would require detecting of presence of this plugin and then to grab the name of dynamic fields on the fly (I've shown how to do this 4 posts down)

That email value that you've mentioned that keeps on coming up is the hidden email value
The fields names (the hooks that the bot uses to inject their values into) are always unique for every session, but there are constant (hidden) fields which are honey pot traps (This is correct and as designed). These traps have the following field names:

password, email, username ...etc.

I've set values to these fields so that they are never auto-populated (some browsers try to force auto-populate even though you explicitly set auto-complete to off... pre-setting a value avoids this issue.)

One of these values is the email value (which is the value you mention above)


Usually I would go out of my way to make things compatible with everything, but with this plugin, the actual nature of this plugin will make it fairly incompatible with plugins that use the actionRegister (CAPTCHAs will still be compatible)

... so Sonnb Stop Spam Here should be compatible (since we've spoke), but XenUtiles might not.
I strongly suspect what you are seeing is a compatibly issue with XenUtiles? (I suspect that Jaxel might not be willing to make the changes required. So I can refund, or you could try to switch XenUtiles off )

 

[Wulfspider]

I've tried it with XenUtiles enabled and disabled, either way registrations fail and end up being the random uselessness, so unsure what else would be interfering, as I have no other spam related things and no other other addons doing anything to registrations that I know of. The user and email is the same every time as shown in the screenshot above.

 

[tenants]

It really does imply a plug-in compatibility issue
(I've just retested with email confirmation on, and it works without issue .. it shows and sends the email to the correct location)

Can you send me the list of your plugins

 

[Wulfspider]

It really does imply a plug-in compatibility issue
(I've just retested with email confirmation on, and it works without issue .. it shows and sends the email to the correct location)

Can you send me the list of you plugins

Send you a PM with the list. I'm going to see if I can do a bit more testing too.

Edit: Just tested on a clean version of XenForo (1.1.3), and it did it. It had a couple shared addons, so testing now.

Edit 2: It looks like Minecraft Avatar is the culprit.

 

[tenants]

This issue was a clash with another plugin that used the actionRegister (Minecraft Avatar)

The fix was to add small amount of code within that plugin (the same fix will probably work with any other plugins that also use the actionRegister (which should be rare)):

Within the actionRegister, just below this:

$passwords = $this->_input->filter(array(
'password' => XenForo_Input::STRING,
'password_confirm' => XenForo_Input::STRING,
));

Add the following:

// For FoolBotHoneyPot
$addOnModel = $this->getModelFromCache('XenForo_Model_AddOn');
if (($addon = $addOnModel->getAddOnById('FoolBotHoneyPot')) && !empty($addon['active']) )
{
 
$uuids = $this->getModelFromCache('FoolBotHoneyPot_Model_HoneyPot')->getFeildUUIDs();
 
$uuidData = $this->_input->filter(array(
$uuids['1']  => XenForo_Input::STRING, // 'username'
$uuids['2']      => XenForo_Input::STRING, // 'email'
$uuids['3']  => XenForo_Input::STRING, // 'password'
$uuids['4']      => XenForo_Input::STRING, // 'password_confirm'
$uuids['5']  => XenForo_Input::STRING, // 'timezone'
$uuids['6']    => XenForo_Input::STRING, // 'gender'
));
 
$data['username'] = $uuidData[$uuids['1']]; // 'non hidden username'
$data['email'] = $uuidData[$uuids['2']]; // 'non hidden email'
$passwords['password'] = $uuidData[$uuids['3']];  // 'non hidden password'
$passwords['password_confirm'] = $uuidData[$uuids['4']]; // 'non hidden password_confirm'
$data['timezone'] = $uuidData[$uuids['5']];  // 'non hidden timezone'
$data['gender'] = $uuidData[$uuids['6']]; // 'non hidden gender'
 
}
// End FoolBotHoneyPot

 

[CTXMedia]

Just keeps getting better.

Thanks for all the work you've done on this and the prompt updates/fixes.

 

[HWS]

We use it with XenUtiles without problems.

 

[tenants]

We use it with XenUtiles without problems.

That's good to know, I've only breifly tried testing it with XenUtiles (and suspected they wouldnt work together)... do you use any of the 3rd party spam management tools :

STOPFORUMSPAM / BOTSCOUT / FSPAMLIST ​

 

[Wulfspider]

Tested without a captcha, and so far only 1 bot has made it by out of the ~4k attempts that were blocked.

That's good to know, I've only breifly tried testing it with XenUtiles (and suspected they wouldnt work together)... do you use any of the 3rd party spam management tools :
STOPFORUMSPAM / BOTSCOUT / FSPAMLIST

We use it with XenUtiles without problems.

I use it as well with no issues; I only suspected it when I had the previous issue. I normally use BS and FSL with it and have no issues.