Blocking Users by IP Address and Non-Account Logins

By Michael Ross

This article was published as a cover story in the print magazine Drupal Watchdog, Volume 7 Issue 1, 2017-03-25, on pages 56-59, by Linux New Media. The magazine was distributed at DrupalCon Baltimore, 2017-04-24.

Among all the major content management systems, Drupal is noted for having an especially robust native capability for determining which categories of site users can view and potentially modify the nodes (instances of particular content types), blocks, pages, and other components of that site. It does so by requiring user authentication through a login mechanism, the assignment of users to roles, and the assignment of permissions to those roles.

This strategy works well for most requirements, but in some cases you need to restrict access to a site as a whole without relying on standard user authentication. For instance, imagine that you have crafted a new Drupal site that was uploaded to a remote server so that it could be examined by the project stakeholders, but the site has yet to be launched. You and the stakeholders want to be able to test all of the site's pages as an anonymous Internet visitor, but you do not want anyone else to stumble upon the site (inadvertently or as the result of someone leaking the site URL or name) and thus see the site before it goes live.

Fortunately, it is possible to restrict visitor access based on the person's IP address or authentication credentials that are completely separate from the normal Drupal user accounts. In this article, I will explore how this can be accomplished using several Drupal contributed modules.

Blocking the Knowns

Before getting into the details of how to block all unknown visitors except those team members who need to view the site in progress, I will first review the basics of how Drupal can block a set of IP addresses, either in the case where one or more of them are known or in the case where their behavior makes them dynamically "known" as bad actors. Drupal has a built-in mechanism for storing and utilizing IP addresses that should be disallowed from accessing the site, using the database table blocked_ips. For instance, if you add a new entry in the ip column of that table with the value 127.0.0.1 (which in most development environments is the address of your own local web server), then when you try to visit any of your locally-hosted sites, you should receive the error message "Sorry, 127.0.0.1 has been banned." Such IP addresses can be added or removed manually using any appropriate database editing tool or within the website itself at admin/config/people/ip-blocking.

Figure 1. IP address blocking in Drupal

Typically that table is used by Drupal only to record and subsequently block IP addresses that attempt to login too many times too rapidly (by default, 50 failed attempts within one hour), as that invariably indicates that someone is trying to brute force their way into the system by using all permutations of usernames and passwords until one such pair works.

Most administrators who want to browse and possibly modify the parameters that control this process can utilize the Flood Control module, which allows you to change the default values for failed login attempts by IP address and username, as well as contact form submissions.

Figure 2. Flood Control parameters

That module handles the core contact form, but not custom forms. To handle those, consider using the Form Block IP (FBIp) module.

Blocking the Unknowns

Generally you have two strategies, each with advantages and disadvantages, for limiting site visitors to a vetted individual or group: by IP address or by login authentication. The latter approach allows the stakeholder to easily make the site available to more people, simply by sharing the login credentials with them, with no need to find out and report their IP addresses to the developer. However, that also has the downside that anyone who learns those credentials, either accidentally or intentionally, now has that access until the credentials are changed. Furthermore, how would you discover that an attacker had learned of those credentials and is using them, short of the site being defaced (at which point it may be too late)? The IP address approach obviates that weakness as long as no hacker can spoof an address on the list. But any time one of the team members tries to access the site from a previously-unknown computer or unintentionally changes her address, then she will lose access to the site. Non-technical project managers might become unhappy if this occurs frequently enough, and you may become equally unhappy having to update the list every time it happens.

To implement the IP address technique, probably the most commonly chosen module is Restrict IP, possibly because it offers more options than the alternative modules. The configuration page (at admin/config/people/restrict_ip) allows you to add the addresses manually, disable restriction based on the roles of the user logged in, and disable it for certain pages; it has a couple of other nice features, as well.

Figure 3. Restrict IP config

By default, any visitor whose IP address is not in the white list will not be able to see the website; instead he will see only an "Access Denied" message.

Figure 4. Restrict IP message

Also by default, the module is not active until you enable the appropriate checkbox, to give you an opportunity to add at least your own IP address to the white list. Should you inadvertently activate the module without first entering your own address, you can regain access to your website by disabling the module from the command line, e.g., using Drush.

A few other contributed modules have similar functionality. Maintenance Exempt has a more limited scope than Restrict IP, in that you specify a list of IP addresses that do not see the message that the website is in maintenance mode and instead can access it normally.

Figure 5. Maintenance Exempt config

Quite similar in functionality is the Skip-Maintenance-Mode-By-IP module, which has a nice additional feature that lets you add a description to each IP address. That would be the obvious place to put the name and email address of the team member who is currently using that address.

Figure 6. Skip-Maintenance-Mode-By-IP config

The second strategy for the administrators of a site to limit those Internet visitors who can see the actual site, is to set up some form of authentication that is completely separate from the native Drupal user authentication system. Apparently the only module that implements such functionality is the Cookie Lock module, whose configuration page (at admin/config/development/cookielock) allows you to specify the username and password that all of the team members will need to access the site, assuming that their IP addresses have not been added to the textarea also found on that configuration page.

Figure 7. Cookie Lock configuration

These modules and any others quite similar to them will arguably not be used on a long-term basis with any conceivable website, but when it comes time for a business or other type of organization to perform limited testing of their new website on a live server, these techniques should prove quite valuable.

Copyright © 2017 Michael J. Ross. All rights reserved.