FoolBotHoneyPot Bot Killer: Spam Combat 2.4.05

Stop bots from registering with elegant methods that do not bother humans (these mechanims are described in more detail below):

• Hidden honey pot traps
• Registration form customisation (un-detectable when looking at the form)...
• Registration timer (that can not be manipulated)
• StopBotters API request to detect known Bots (optional and logged)
• JavaScript Detection (optional and logged)
• Dynamically ordered registration fields
• Registration Field names which are different for every session
• Basic Proxy Detection (logged)
• User Agent (logged)
• Browser Plugin Detection(logged)
• Spam Bot Server Resource Reduction (new) - (reduce spam bots: querying, downloading data, using cpu)
• Works with the Free Plugin AnyApi (designed for this add-on, but can be used as a stand alone), so any api you want can be added to prevent registration:

i) Project Honey Pot Http:BL
ii) Stop Forum Spam
iii) FSpamlist
iv) Bot Scout
v) Spam Busted
vi) up to 10 APIs defined by you
Note: even without AnyApi, this plugin currently blocks 100% of bots

Works brilliantly on its own, but can also be used in combination with :

• AnyApi (Use any API you want, to prevent spam bots / spam humans from registering)
• StopHumanSpam (Stops human creating links / sigs / banned content, it also check for "sneaky broken links")
• StopCountrySpam (to reduce spam from particular countries bot/human),
• CustomImgCaptcha (as a second wave fallback mechanism),
• StopBotResources (to reduce the amount or resources spam bots use)

[CustomImgCaptcha is free and recomended with this plug-in, since FoolBotHoneyPot will also unlock some of CustomImgCaptchas features]

Many Forum Spam Bots such as Xrumer, are incredibly "intelligent", and solve almost all common CAPTCHA mechanisms. Not only can they solve many CAPTCHA images, but they can also solve common question / answers and logical problems

Often, regardless of how good the anti-bot mechanism of a particular forum software is, if it's too common then it becomes a target to break.
Customisations and variations of plug-ins can often help stop the vast majority of Forum Bots from registering

These mechanisms are particularly nice anti-bot mechanisms, since they have no negative impact on users (compared to some very complicated CAPTCHA)

1) 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

2) 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

3) 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

4) The Dynamic Registration URL (Param & Val Randomisation)

• Although this is fairly rare, some bots that target forum software do not always post data where the form tells them to, but POST data to where they expect the core to be located. For instance, the core data will always usually be posted to yoursite.com/register/register
• By Adding a URL param and value and only accepting the data posted to yoursite.com/register/register&xxx=yyy, we can stop these type of bot attempts (this acts like an extra hidden field).
• Both the Param and Values are UUIDs that change with every session attempt, making the URL effectively dynamic

5) Dynamic Form Spacers

• Although bots that this effects are also fairly rare, some bots that attempt to sign up using forms will record the exact location of the field (so that they can register multiple times)
• With Dynamic spacers, every time the spam bot attempts to register, the form fields changes position. This is not very noticeable to humans, but can mean the difference between selecting a field or not for these types of bots, making it far harder for them to attempt to create multiple accounts

6) Multi Step Registration

• There are now options to have a 2 steps registration process, making the registraton form even more customised and harder to automate against.

7) 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 given 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

8) StopBotters (Optional) Detection Mechanism

• Stops A high percentage of known bots using an API request.
• Known bots are detected via IP address / Email Address / Username.
• The underlying StopBotters mechanism is confidential

9) 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)

10) 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)

11) 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

12) 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

13) AnyApi
More and more APIs are becoming avialiable, this allows you to choose the approriate ones.

The AnyApi plugin is a free plugin designed to work hand in hand with FoolBotHoneyPot (AnyApi can work as a free stand alone). By Default, it is set up with the following APIs:

• Project Honey Pot Http:BL
• Stop Forum Spam
• FSpamlist
• Bot Scout
• Spam Busted

But the way it is designed makes it possible for you to add Any API of your choice (even future APIs).

14) Server Resource Reduction

Now there is an option so that spam bots that attempt to hit your forum multiple times, and do it so many times it causes server limit issues, these bots hit a low query and low byte page. The entire core forum can benefit from a reduced server usage from spam bots that attempt to hit your site many times (these spam bots ips are cached locally for x minutes, they are only cached if they have attempted to register, altered many hidden fields and done this within seconds and also have no JavaScript! so there is no doubt these are spam bots)