Website Padlocks

In my last blog entry, Read this Blog and Get a Virus (Statistically Speaking), I described the disturbing trend of web logs being routinely hacked and used to infect the computers of their visitors. I thought it might be good to review some steps you can take to make your website less susceptible to exploit. As I go through the principles, I'll give the steps you can take in securing a Drupal 7 site. There are likely ways to accomplish these steps on other content management systems but due to both my experience and bias with Drupal, I'll limit my instructions to that platform. If you'd like to contribute steps on a different CMS, reach out to me and I'll ammend this entry with your contributions.

The Basics

The most simple of changes can prevent most issues.

Complex Password

Most of the available evidence indicates that weak login passwords is the primary way hackers are taking control of websites. I'll make this very simple rule: use a password generator to make a password that even you can't remember. I know this is a painful paradigm shift but will make your site a lot harder to get into. For more on how I handle my passwords, read my log entry: Password Day. If your system has more than one privileged user, enforce password complexity. In Drupal, this is done with the password policy module. If you have a hosting account, make sure you use a different, but equally complex password to access web management, SFTP and SSH. 

Flood Control

Regardless of how secure your password is, if you give a hacker enough tries he will eventually crack it. Drupal 7, out of the box, limits the number of failed attempts that can be tried from a given IP address or against a user account. Those default settings can be tweaked using the flood control module. If you have access to the server you are hosting on you should also use fail2ban or another tool to prevent bruteforce password cracking against other services like FTP and SSH.

Update Your System

Apply patches quickly. CMS can give notifications when new patches are available. In Drupal this is the "update module" included in core. It can send you an email when updates are available. It is imperative for you to know that the latest that a hacker will know that there is a vulnerability is when you receive the email. This is because he will also be waiting for an announcement of the vulnerability so he can begin crafting an exploit against it. Often the hacker knows about the vulnerability much earlier, giving you even less time to respond. Unless you know how to handle patch management, I highly recommend you host with a managed hosting company that knows how to keep your system patched. Along with patching your CMS, you (or your provider) need to make sure your server software stays updated.

Reduce Your Code

Disable all the features, plug-ins and modules you are not currently using. You can always turn it on later but the less code your site is running the less code that can be exploited. When you enable code make sure it is actively supported and production quality. Fight the temptation to use the cool new bleeding edge code. When installing Drupal, I prefer to use a "minimal" install then enable the modules I actually need.

Minimal Users

When you allow anonymous users to gain user accounts on your systems you give great avenue for hackers. There are many great use cases where this makes sense but be very sure that you have one of those. I prefer (as I've done on f15hb0wn.com) to use social media commenting module for a couple of reasons. First, I don't have to give access to strangers to my site. Secondly, using Facebook credentials decreases spam and trolling on the site. If you decide to invite users into your system, be sure to pay extremely close attention to the permissions you grant them. Also perform email verifications and use a CAPTCHA when they register. The CAPTCHA will prevent malicious programs from creating accounts. CAPTCHA is when you see letters inside of an image. It is possible for a human to read the letters but not computers (hopefully anyway.)  

Secure Login

HTTP does not send information encrypted. When you login to your site you should use a mechanism that will encrypt your password as it moves from your computer to the web server. You will need to install a security certificate on your system then don't log in without seeing the trusty padlock in your browser. If it is not possible to use secure login, then refrain from logging in from networks that are public. You may also want to use a stop gap encryption solution like jCryption. In Drupal, the encrypt submissions module implements jCryption.

Advanced Topics

Spambots can be used to drop advertisements on your website that may used for more nefarious purposes. In addition to restricting anonymous user registration here are a couple of things I highly recommend.

Join Project Honeypot 

Project Honeypot is a distributed system that identifies spammers and spambots by feeding suspected bad guys traceable email accounts. When spam is sent to those suspected addresses, Project Honeypot logs the scanner's IP address as "known bad." This information is made available to all members of the project instantly. This information can then be used to block the bad hosts before they can load your web pages. In Drupal, the http:BL module connects the site to the project. I have found spam and scanner traffic on hosts using this service has been reduced as much as 92% after joining Project Honeypot.

Scan Content

If you are allowing users to post information to your site make sure it is being run through a content scanner. I prefer Mollom and have had great success with it. Mollom can provide CAPTCHA's when appropriate as well as checking submitted content for "spammy" links and words as well as checking for profanity. Drupal provides a Mollom module to connect to the service.

Virus Scanning

If you allow users to upload files (like PDF) you should provide virus scanning on those files. I recommend against allowing uploads unless completely necessary. If you must allow it, use an antivirus scanner and limit the file types that can be uploaded. Drupal has alpha integration with ClamAV for Drupal 7.

File Permissions

If possible, update the file permissions on the server so that the user account running the web service can read the files but not write (except in upload directories.)

Obsufcation

As soon as an attacker can determine what CMS you are using (should take < 1 minute) they can attempt to manipulate the administrative and user pages. To make it more difficult for them, you can move those directories to a new location that only you know. In Drupal 7 this can be accomplished using the rename admin paths module.

Read Your Logs

Make a time each day where you review your log files for suspicious entries. It will improve the experience for your visitors and give you visibility to problems before they become crises. If that is outside of your skill set, use a managed hosting service that will handle that.

Wrap Up

To provide a web site that will inform and help your visitors take some simple steps to keep them safe. If the necessary steps are outside of your wheel house spend the money on a service that can take care of making your site one of the harder sites on the internet to break into. These steps won't make your sites "hack-proof" but by increasing the difficulty to break in, hackers will likely move to easier targets than your site.