- Совместимость с XenForo
- Видимая ссылка
- 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)
- 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:
ii) Stop Forum Spam
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)
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
- 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
- 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
- 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
- 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
- There are now options to have a 2 steps registration process, making the registraton form even more customised and harder to automate against.
- 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
- 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
- This registration prevention method is optional (defined in the ACP)
- 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)
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
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
- Bot Scout
- Spam Busted
14) Server Resource Reduction