glFusion Wiki

Site Tools


Bad Behavior2 Plugin

Bad Behavior was written by and is maintained by Michael Hampton at

Bad Behavior has been integrated into glFusion by the glFusion development team to take advantage of the great features that Bad Behavior brings, specifically:

Bad Behavior complements other link spam solutions by acting as a gatekeeper, preventing spammers from ever delivering their junk, and in many cases, from ever reading your site in the first place. This keeps your site’s load down, makes your site logs cleaner, and can help prevent denial of service conditions caused by spammers. (quoted from

Bad Behavior can use of the Project Honey Pot - HTTP Black List service, which will block known malicious sites. You will need to create an account and obtain a set of keys to configure below. It is highly recommended that you enable this feature in Bad Behavior.

Configuration Options

The Bad Behavior configuration options are located under Command & Control → Spam / Bot Protect.

BB2 Enabled
Set this to true to enable Bad Behavior 2 plugin protection.
Enable Automatic Banning
If set to true, IPs will be automatically banned if they fail the CAPTCHA entry 5 times, or if a post fails the Cross Site Forgery Check. IPs will be banned for 24 hours.
Log Automatic Bans
If set to true, Bad Behavior2 will log (in error.log) each time it performs an automatic ban. It will log the date, time, IP address and reason for banning.
Strict Checking
Bad Behavior operates in two blocking modes: normal and strict. When strict mode is enabled, some additional checks for buggy software which have been spam sources are enabled, but occasional legitimate users using the same software (usually corporate or government users using very old software) may be blocked as well. It is up to you whether you want to have the government reading your blog, or keep away more spammers.
Verbose Logging
Turning on verbose mode causes all HTTP requests to be logged. When verbose mode is off, only blocked requests and a few suspicious (but permitted) requests are logged. Verbose mode is off by default. Using verbose mode is not recommended as it can significantly slow down your site; it exists to capture data from live spammers which are not being blocked.
Logging Enabled
You can disable logging entirely, but this is not recommended since it may cause additional spam to get through.
HTTP BlackList Key
Bad Behavior is capable of using data from the http:BL service provided by Project Honey Pot to screen requests. This is purely optional; however if you wish to use it, you must sign up for the service and obtain an API key. To disable http:BL use, remove the API key from your settings.
http:BL Threat Level
This number provides a measure of how suspicious an IP address is, based on activity observed at Project Honey Pot. Bad Behavior will block requests with a threat level equal or higher to this setting. Project Honey Pot has more information on this parameter.
http:BL Maximum Age
This is the number of days since suspicious activity was last observed from an IP address by Project Honey Pot. Bad Behavior will block requests with a maximum age equal to or less than this setting. Project Honey Pot ( has more information on this parameter.
Allow Offsite Forms
Bad Behavior normally prevents your site from receiving data posted from forms on other web sites. This prevents spammers from, e.g., using a Google cached version of your web site to send you spam. However, some web applications such as OpenID require that your site be able to receive form data in this way.
EU Cookie
Enable this option to alter Bad Behavior's cookie handling to conform to 2012 EU cookie regulations.
Reverse Proxy Support (i.e.; CloudFlare)
Enable this option if your website is behind a reverse proxy or load balancer. For example, if you use CloudFlare service or another proxy server, set this to True.
Proxy Header
The proxy header to add when Reverse Proxy is enabled. Generally the default of 'X-Forwarded-For' is fine.
Reverse Proxy Addresses
If you know the IP addresses of your proxy server(s) or the load balancers, enter them here. For services such as CloudFlare, you can leave this blank.


Whitelists allow you to configure IP addresses, or a range of IP addresses, URLs (on your site) and User Agents that should always be allowed to access your site. A whitelist prevents glFusion's Bad Behavior plugin from blocking a user that matches the whitelist setting.

From the Bad Behavior documentation:

Inappropriate whitelisting WILL expose you to spam, or cause Bad Behavior to stop functioning entirely! DO NOT WHITELIST unless you are 100% CERTAIN that you should.

IP Addresses

You can specify a specific IP address or CIDR format address ranges.

CIDR (Classless Inter Domain Routing) is a simple method to specify a block of IPv4 addresses, for example: This represents all IP addresses in the range of through

For more information on CIDR see Classless Inter-Domain Routing (


URL fragments beginning with the / after your web site hostname. For example, if you always wanted to allow access to a specific Static Page on your site (we'll use dashboard in this example), we could specify:


This would allow anyone to access this page, even if they failed other Bad Behavior tests (such as being on a blacklist).

User Agent

You can specify full user agent strings to whitelist. For example, if you use to monitor your site's availability, you might want to Whitelist the User Agent of the Uptime BOT:

Mozilla/5.0 (compatible; Uptimebot/1.0; +

This is an actual real world example. The Uptime BOT will normally be blocked by Bad Behavior because the BOT does not include the required Accept header in its request. By whitelisting the User Agent, we can ensure that the Uptime BOT will be able to access your site.


There may be times where you want to block some users (generally BOTS and scripts) from using resources on your site. Trying to block specific IP addresses is usually a difficult task. There are probably hundreds of thousands of IP addresses used by BOTs and malicious scripts. Fortunately, we have several ways we can block malicious activity.

IP Addresses / CIDR Ranges

As we mentioned earlier, blocking IP addresses isn't always the best approach to blocking malicious traffic, there are times when it is appropriate. For example, at, we receive thousands of requests per day from a specific hosting provider, all calling users.php (to login) with invalid data. As these are identified, we block the range of IPs from the specific host.

For example, the range of IPs - is represented as a CIDR address as - this one CIDR notation covers 254 individual IP addresses. Many times it is helpful to use one of the online CIDR calculators, such as to understand how to represent a range of IP addresses correctly.

User Agent - Beginning of String

This allows you to block requests by checking the User Agent used by the client. This specific search will look at the start (beginning) of the User Agent string for a match. For example, you may notice a lot of malicious traffic from a specific bot. If you know the User Agent is always the same (User Agents are generally shown in the GUS list or in your web server's access log), you can specify the beginning part of the User Agent to block.

User Agent - Match anywhere in the string

This allows you to block requests by checking the User Agent string and matching the text anywhere in the User Agent. For example, I see a lot of scans from the Site Lock service and since I do not subscribe to their service, I would prefer they not scan my sites, I can block them by matching SiteLock in their user agent (which is: SiteLockSpider [en] (WinNT; I ;Nav)).

User Agent - Regex

This allows you to specify a search regular expression (regex) to match user agents. Regular Expressions can be very complicated, if you want a quick primer on how to understand and use regular expressions, I recommend checking out You Don't know anything about regular expressions.

URL Strings

With URL strings, you can block specific requests to your site. For example, we see several BOTs try to exploit know WordPress vulnerabilities by scanning /wp-admin/somefile…By setting up a URL String block of /wp- we will block all requests that have /wp- in the URL. This has proven to be very effective in blocking these bots.


Many bots try to crawl sites using a special 'Referer' in their request header - the point is to embed links to their sites in your logs to drive more traffic.

2016/07/16 19:39
glfusion/siteadministration/bb2.txt · Last modified: 2017/01/18 06:40 (external edit)

Page Tools