3.3. Using Extra Security Modules
Drupal is guided by the idea that core should be small but extensible and include only the most common features and APIs necessary to build a site. All other features should be implemented as an extension module that provides the additional functionality. So Drupal's core provides protection against common security vulnerabilities but does not provide some features that may be useful if you feel that your site needs more security than what is provided in core.
Skeptical readers may note that adding these modules increases the attack surface and may increase the likelihood that your site is vulnerable to attack. There is also the fact that some of these modules may introduce bugs and may not be maintained properly for future versions of Drupal (for example, the PHPIDS module was recently abandoned and then picked up by a new maintainer). So while these are recommended as modules that provide potential methods to improve the security of the site, you should still review the code yourself for weaknesses prior to installing one of these modules. Also, new modules are created frequently, so you are encouraged to review new modules in the Security category on drupal.org (http://drupal.org/project/Modules/category/69).
3.3.1. Login and Session-Related Modules
Chapter 1 discussed the importance of the authentication, authorization, and sessions as a focal point of attacks. The next modules provide additional security related to this area and should be seriously considered for any site that contains sensitive information.
Login Security: http://drupal.org/project/login_security
This module provides several useful login-related security features. First, it inserts a delay after a failed login attempt to slow down brute force password-cracking attempts. It can also automatically block an account or IP based on a number of failed login attempts. Finally, it also can alert users about the last login and last usage of their accounts, which can help a user to identify if her account has been compromised.
Persistent Login: http://drupal.org/project/persistent_login
The overall goal of this module is to reduce the likelihood of an attacker using a session that was top active on a shared computer. First, this module gives a user the Remember Me feature on the login form, which she is probably used to from other systems. When she is on a public computer she can log in without checking the box and know that her session will not be stored after she closes the browser. Second, it exposes administrator control over the session lifetime—this can also be controlled via PHP settings in a php.ini file, the .htaccess file, or in your Drupal settings.php file—but the module provides an easier interface to the setting. It also controls which sections of a site a user can access if she is using a session from a cookie rather than a session based on submitting the login form.
Single Login: http://drupal.org/project/single_login
This module limits each account so that it can log in to the site only once, which is useful to make sure that people are not sharing accounts. When an account logs in for the second time, the first session is removed. If the user at the original session then logs in, the process is repeated in reverse, and after an administrator-specified number of times, an account that has bounced back and forth can be automatically blocked.
3.3.2. Password-Related Modules
User passwords are a common source of vulnerabilities on a site. Attackers can use dictionary attacks or brute force attacks to guess the passwords on a site if the passwords are simple enough. On the other hand, forcing users to use complex passwords or change them on a regular basis can lead the end user to start writing down the passwords. Ideally a balance must be met between password strength and usability. One potential solution is to use OpenID, discussed shortly.
Password Strength: http://drupal.org/project/password_strength
This module takes a feature from Drupal 6.x, which uses JavaScript to test the strength of the password, and provides it for Drupal 5.x. Weak user passwords are one of the biggest problems with all systems, and providing motivation to users to improve password strength is a great way to reduce this problem.
The next two figures (Figure 3-3 and 3-4) show the Password Checker in Drupal 6.x core providing feedback about how to improve a password with "low" strength and another with "medium" strength.
Password Policy: http://drupal.org/project/password_policy
This module requires passwords to meet certain criteria defined by an administrator. This is a more forceful system than the suggestion that is provided in Drupal 6 core and by the Password Strength module.
Figure 3.3. Feedback for a user about to set a weak password
This module "salts" Drupal's passwords so it is harder to determine the password from the MD5 hash. A salt is an additional string that is added to the password string before it is hashed. Common attacks on hashed passwords use hashes of known words that are built without a salt, so those comparisons will fail to find a match to the same word when that word is salted. If the hashes are compromised but not the salt, then it is very difficult to crack a hashed password.
Figure 3.4. Feedback for a user about to set a medium-strength password
Secure Password Hashes (phpass): http://drupal.org/project/phpass
This module uses the more robust password hash algorithm provided by the phpass library, which uses a variety of hashing algorithms depending on what is available in your version of PHP and on your operating system. This feature is included in Drupal 7.x core.
OpenID Support
OpenID is a specification for systems to use domain names as logins to sites. Individuals use a domain—such as http://my_username.myopenid.com—to identify themselves to a website. The website then goes through a process of communicating with the OpenID providing party—myopenid.com in this case—to verify that the user really is who he says he is. OpenID allows individuals to use one username and password with their centralized ID provider, which reduces the number of passwords they have to memorize, allowing them to use one good password. Many large companies like AOL and Yahoo! support OpenID. The OpenID icon (on the top of the text box in Figure 3-5) is quickly becoming a common feature on high-traffic websites.
Figure 3.5. The default OpenID login form in Drupal 6.x
3.3.3. Visitor Analysis
By just visiting your site users give you a lot of information you can use to make decisions about them. Further, whenever they submit information to your site you gain more information, which you can use to evaluate their intentions. These next two modules evaluate visitors to try to identify attackers and potential attackers.
PHPIDS: http://drupal.org/project/phpids
This module compares content submission to rules of the PHP-Intrusion Detection System and tries to identify attacks on a site. In theory this is a great idea to figure out when a site is being attacked. In practice this results in a lot of false positives and is therefore of limited use.
NOTE
For more information about PHPIDS see the website at http://php-ids.org/. Because it is used in many systems, there is a great interest in making it work well in general.
http:BL: http://drupal.org/project/httpbl
This checks a site visitor's IP address against a list of known malicious (often bot) machines and can block or limit access by that visitor. One interesting side effect of this module is that many visitors in the http:BL list can be demanding on server resources, and installation of this module sometimes results in improved performance. The major drawback of this module is that it can block legitimate users of your site and present them with a confusing message, as shown in Figure 3-6.
Figure 3.6. The http:BL warning message
3.3.3.1. Extra Security Module Summary
Some of the modules presented are transparent to users or may provide features that increase the usability of the site (for example, the password-hashing modules and Persistent Login Remember Me function), while others may be an annoyance to users (for example, http:BL blocks legitimate users and Persistent Login requires users to log in on a more frequent basis). Therefore, it is up to you as the site administrator to determine which of these modules should be installed and which would present too great of an annoyance for the benefit gained.