MO Anti-pounding for Drupal

No More Hammering!

MO Anti-pounding helps you prevent heavy hammering of your websites from robots and individuals by catching and banning them before the Drupal database is accessed. Use this module to prevent a large amount of your resources from being eaten up by malicious users.

This module supports many features such as a whitelist allowing you to specify who can connect to your website with ban-free access (for example, administrators and well-behaved search engine robots.) It allows you to specify many timing intervals that are used to select how soon or late someone gets banned, and how long they stay banned.

In general, well behaved search engines and other robots observe proper protocol when they receive the 503 responses sent by this module. Non-compliant robots are simply banned.

"Brute Force" Drupal Log-In Protection

As a pleasant side effect, this module protects your website from "brute force" log-in attacks. Whenever a black-hat party employs a robot to attempt to hack a website user account, they generally want the robot to hit the site as fast as possible. How long would such an attempt take? Let's take a look at an example:

• Assume a user has an 8 letter and numerical digit password1
• The number of combination is (26 + 10)⁸ = 2,821,109,907,456 possibilities2
• Your website replies to log in attempts in one tenth of a second
• You get 10 log in attempts a second, 864,000 a day
• The robot may spend 8940 years before cracking your password

It's safe to say that this makes for a very secure password, so you may think that there is no need to worry about these "brute force" log-in attacks. However, consider how much bandwidth these black hat robots will consume executing these attacks on your site. Why lose it to such robots? With the MO Anti-pounding module, you can very quickly block those attempts for seconds, hours or even days.

However, if the user instead chooses a dictionary word (or otherwise well known word) for his/her password, the game is quite different. The number of English words is very large, but for passwords, it is often viewed as limited to less than 100,000. At the speed of ten attempts per second, any such password can be cracked in three days maximum. Assuming the user adds the number "1" at the end of the password, the attempt increases to six days. So for the average user, in less than one week their account may be hacked3.

With MO Anti-pounding active on your server, those black hat robots that try to crack user passwords will be blocked for at least a whole day after just 30 attempts. In other words, those robots attempting to hack passwords would need to either accept the minimum time allowed between accesses (say one whole second, i.e. the hacking will take at least 10× times more in our example), or be blocked for so long that it will take them years to find the password (unless they are lucky, of course.)

Technical Specifications:

• Current version: MO Anti-pounding version 1.6 for Drupal 6.x
• Supported platforms:
  • All platforms that support PHP 5+ with Drupal 6.x
    (Microsoft Windows, Linux, Mac OS/X, SunOS, HP UX, etc.)
  • CRON is strongly suggested for full and automatic support
• Whitelist
  • Maintains a list of IP addresses to always allow access
  • Provides an "agent string" for your browser (works with Mozilla Firefox and other modern browsers)
• Blacklist
  • Maintains a list of IP addresses to always refuse
  • May be used as a firewall when you do not have admin access to your actual server firewall
  • May be used as a per site firewall when you have a multi-site installation
• Maintains a list of files to protect by extension (i.e. .php)
• Maintains a list of files not protected when that extension appears at the end of your URI (in the query string)
• Offers many levels of control
  • Timing to trigger a ban
  • The number of hits to generate a ban
  • Duration of bans
  • Timing to reset the ban
• Logs banned user information
• Never accesses the database when testing incoming hits4
• Complete and detailed technical documentation provided
• Provides editable error messages
• Automatically ignored when running scripts on your site from your command line PHP (also called CLI)
• Sessions are saved in local files5

Compatibility Issues

By default, URLs that are used with AJAX (for features such as auto-complete) are put in the MO Anti-pounding URI white list. This list can be grown as required by the modules you use on your website. The following is a list of such modules that we use and had to authorize in the MO Anti-pounding module.

Chat Room

The Drupal chatroom module uses several AJAX features, two of which need to be listed in the MO Anti-pounding URL white list:

chatroomread.php
chatroom/chat/post/message

The chatroomread.php is the URL that handles the chat message synchronization capability. The other one is used to post new messages. The other AJAX URI used by this module are already accepted by the default URI defined in the MO Anti-pounding module.

• 1. At this point, we will further assume that the password is not a simple dictionary word with the digit 1 at the end (the vast majority of people still use such a password, like password1.)
• 2. 26 letters plus 10 numerical digits to the eighth power represents nearly 3 trillion possibilities (a 13 digits number). Writing a long sentence (say 64 characters), which is possible with Drupal and probably a lot easier to remember than a nonsense password, would represent 27⁶⁴ which is about 4x10⁹¹. In other words, a number with 92 digits! That's even better as long as you don't use a popular phrase or well known quote.
• 3. Remember that the maximum is a function of how long it takes to find the password and assumes that the password is the last word to be checked. In other words, since most people use the same few words, it is much more likely to be hacked in less than a day.
• 4. The system uses local files in your website folder (but not the files folder!) protected by an .htaccess to make sure that unwanted users cannot see their session. This can accelerate your system throughput enormously by preventing many otherwise slow database accesses.
• 5. The session cache requires CRON to be purged at regular intervals.