Thwarting Attack Web Bots

By Michael Ross

This article was published in the print magazine Drupal Watchdog, Volume 6 Issue 3, Winter 2016, on pages 22-24, by Linux New Media.

Drupal websites, like those based upon other CMSs, are frequently hammered by web bots that use various automated techniques for trying to break into those sites. One of the most common methods is for the bot to go to the default page where users login, which varies depending on the CMS chosen by the site builders. A bot has ways to try to determine the particular CMS of any given target, often by examining the HTML of the target site's home page or searching for certain CMS-specific files or directories on the server. However, because there is a limited set of CMSs used to build the majority of such websites, a bot can simply try their various user login paths until landing on the right one.

The problem of misbehaving web bots goes beyond security concerns, because they are consuming your web account's allocated bandwidth, program executions, and allowed time, which might be quite limited depending on your budget and the chosen hosting plan. Simply put, this web traffic is doing your site absolutely no good.

In the case of a Drupal website, the login page is by default found at /user/login (e.g., http://www.example.com/user/login). Unfortunately, having a known login page is like presenting hackers with a fixed target. Thus, it is wise to remove that target from automated attacks, specifically by changing the path of the login page, so that when any of these hacker bots eventually reach your Drupal site, it will appear to the bot that your site doesn't even have a login page, even though it does and is easily accessible by human users through a clearly labeled navigation link. Such a tactic can be an effective measure in making your site more secure.

You can easily confirm that such bots are constantly on the prowl, looking for login pages on Drupal sites: Simply create and publish a new site — or modify an existing and indexed site — so that within the user account settings (/admin/config/people/accounts), visitors can approve accounts without administrative approval. It won't take long before those tireless bots are signing up for new accounts, with junk e-mail addresses, and attempting to login to your site using those new bogus accounts.

HTTP Trickery Possible?

Before diving into solutions that are known to work, we should briefly consider whether it is possible to achieve this functionality simply by making one or more changes to the website's HTTP access file (.htaccess), because any Drupal developer who feels comfortable making changes to that file (or any others in the root directory of the site) will likely wonder if such a solution is possible.

At least one Drupal developer has asserted that this simple method works: Assuming your website is at http://www.example.com/, add the following lines of code to that HTTP access file:

Redirect 301 /user http://www.example.com/404Redirect 301 /user/login http://www.example.com/404

These instructions to the web server tell it to send any visitor — whether human or robotic — to your 404 error ("Page not found") page for any attempt to go to the user or user login page. How, then, do you send legitimate visitors, including yourself, to the correct pages? The claim is that one merely adds one or more dummy directory names to the URLs in your site's navigation menu(s). For instance, a URL such as http://www.example.com/user/legit supposedly bypasses the redirect. However, testing indicates this is not true. Specifically, the server redirects that URL to http://www.example.com/404/legit.

Research has not turned up any other strategies that rely on the web server itself and not Drupal's handling of paths, but that does not imply that they do not exist and would not be appropriate for your situation if they are feasible.

Module Magic

If you would prefer not to make changes to critical files in your root directory or if your web hosting plan doesn't even allow it, then you could instead utilize a module. The simplest such solution is to use the Path core module. After enabling it, create a "Page not found" page (e.g., at /content/page-not-found). Then create a path alias with the "Existing system path" set to "user" and its corresponding "Path alias" set to "member" (or whatever value you want to use as the substitute path). This addition defines the path for the user login link in your navigation. Then create two more path aliases with the "Existing system path" set to "content/page-not-found" and the "Path alias" field set to "user" for the first one and "user/login" for the second. These additions will send the bad bots off in the wrong direction.

If you elect to customize both paths and stay with the default values suggested by the module (/backend and /member, respectively), then you will find, using a clean install of Drupal 7 as an example, that going to the conventional login path produces the expected "Page not found" message, whereas going to http://drupal_7_test/member produces the usual login page.

Figure 1. Login page with module

Unfortunately, this strategy does not work when the website is put into maintenance mode (/admin/config/development/maintenance). Under that scenario, a bot that tries /user/login is sent to the (attack-proof) "Site under maintenance" message page, but if the bot tries /user, it is sent to the actual login page (/member), at which point the bot can perform whatever nastiness was planned.

The second solution works nicely when a site is put into maintenance mode and, thus, would be a much better choice for any site that may receive extensive maintenance in the future. It makes use of the Rename Admin Paths module, which allows you to change the admin path (which is typically at /admin, the user login path, or both — all in a simple settings page, at /admin/config/user-interface/rename-admin-paths.

Figure 2. Rename Admin Paths settings

The two customized paths work even when the site is put into maintenance mode.

The module has stable versions for both Drupal 7 and 8. Note that some Drupal developers recommend against renaming the admin path because doing so can apparently cause problems with other contrib modules, such as Display Suite.

Regardless of which approach you choose, modifying the user login path can help harden your website against such automated attacks. After all, if you know that your castle is going to be attacked by a multitude of fearsome and soulless dragons, it is best not to leave your most vulnerable opening at the exact same location as that of every other castle. Move your gate and drawbridge, and while you're at it, top up the moat with wildfire. Winter is coming.

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