Security Best Practices


Patch, Patch, Patch

The most important security practice for web application software is to keep up with your software patches.  The more commonly used the application, the greater a chance that someone out there is looking for insecure installations to hack.

Systems like Drupal and WordPress are so popular that you need to be prepared to deploy security patches for them just as soon as they come out.  If your hosting server is running Installatron, you can configure it to automatically install many of these updates.  If you don't have Installatron, you can still configure WordPress to automatically install new updates on its own.  Drupal, unfortunately, requires manual intervention if you don't have an outside tool like Installatron, but modules can usually be updated from within the application.  Drupal core updates have to be installed from the command line or from a web hosting file manager control panel.

Non-security patches can be important, too, but should be tested more thoroughly before deployment since they could break things.  (Security patches could break things, too, but sometimes it may be better to break a small feature of your site temporarily than to leave it susceptible to a known vulnerability.)

Lock Down Site Access

Securing the back doors to your site is pointless if you leave the front door wide open.  Make sure you have configured your web application properly so that only the proper authorized people can access it.  

  • Consider user roles carefully and don't give out more access privileges than are necessary.
  • Audit user access lists and remove users who no longer need access (employees who no longer work for your unit, students who have graduated, anyone who has moved to a different role that doesn't need to use the application.)
  • Besides auditing access lists within web applications, also audit the access lists for their server hosting accounts as well.  Make sure that the people with access to administer those accounts still have reason to be doing so.  Take old developers off of these accounts if they aren't actively working for you, even if you think you'll bring them back in later, and remove anyone who has left Georgia Tech, as they could potentially still be able to get to your hosting account even after many of their standard IT privileges have expired.
  • If you implement a configuration where anyone with a GT Account can log into your application, be very careful about what you make available to these 'regular' users.  Keep in mind that when you include all GT Accounts, you include all guest users, outside vendors and developers who are doing work for Georgia Tech units, retirees, alumni, etc.  That's a pretty big pool of people.  If you really don't need to include all of those people, look into options for validating that someone logging in is a current faculty/staff member or student.
  • If you add custom security modules to content systems like Drupal and WordPress, don't just assume they work as you have configured them:  open a different browser and test to make sure a non-logged in user really can't get to the content you are trying to protect.  A security configuration that doesn't actually work is worthless.

Run a Tight Ship

Module and plugin based applications like Drupal and WordPress have one distinct downside:  not all modules and plugins are created equal, and poorly written and managed ones can put your application at risk.

Before installing a module or plugin, review it carefully.  Avoid ones that do not have active support, ones that haven't been updated in several years, and ones that have never left alpha/beta status.  It's usually better to tell a stakeholder that there's nothing available to provide a certain functionality than to offer up a module or plugin that isn't stable and risks introducing security holes.  It's also far better to say no up front than to try something that stakeholders get used to, only to later discover a serious uncorrectable problem that necessitates removing the plugin/module.

Avoid Frankensites

What's a Frankensite?  It's a module/plugin based web application where so many extra components have been added to it that it's impossible to properly audit the functionality of the site.  Upgrading these sites can either become impossible, or strokes of pure luck if a major update doesn't break several things at once.

When any kind of complex functionality is required, look at abstracting that functionality out to a separate application that can run in parallel with the main application.  For example, if you are running a Drupal site and your stakeholders want a nice photo album, don't load up the Drupal site with the half-dozen extra modules needed to make a barely functional internal photo album system.  Instead, set up a copy of ZenPhoto, which is designed from the ground up to handle photo albums.  Or, suggest the usage of an hosted in-the-cloud system.  Any of these options will keep your main website application from turning into an unmanageable Frankensite.

(Setting up multiple applications may seem like more work at first glance, but it's far less work in the long run, as you'll be able to streamline the installation of updates, not to mention that you can update the secondary applications one at a time without having to bring down any others or the main application/site.)

Enable and Monitor Security Logs

Many applications and all hosting account systems will log different kinds of activity related to your web application.  While a lot of these logs may seem unreadable to the untrained person, they could still be invaluable should a problem arise - especially a security incident.  It's a good idea to keep these logs around for at least six months, and even longer if your application handles any sensitive data.  Check the Georgia Tech data security policy to find institute requirements and recommendations for log retention.

When possible, sending logs to a remote server is a really good idea, as that prevents those remote copies from being modified by a hacker who gets too far into your web server.

Make Regular Site Backups

Nothing is worse than having a site crash without a recent backup available.  Whether the crash was due to a patch gone bad or a hacker getting into the site, being able to restore the site to a previously known good state is critical.  Here are some recommended guidelines for handling backups:

  • For all sites, run a full backup once a week, and for important sites, also run an incremental backup daily.
  • Store backups in a safe location, ideally on a remote server.  If possible, configure your infrastructure so that the web server can't modify a backup once it's been written to the remote server, so that a hacker who breaks into the web server can't delete your backups.
  • TEST your backups!  Far too many a systems administrator has been bitten hard by backup files that were corrupted, missing important components, or even just plain missing because the backup process didn't write out the files as expected.  After running your first backup, download the files and try to recreate the website in a test environment to make sure you have a complete backup of the site.  And, don't forget to check the backup archives periodically to make sure they're still functioning as you expect.
  • Be sure to cycle out old backup files periodically, so that your backup system doesn't run out of disk space.  This is yet another way to discover that you have no recent backups when you need them the most.

Install and Utilize Security Tools

Some applications may have third-party tools to help you monitor for security problems.  A good, reliable security tool can block many types of known attacks, stop brute-force login attempts, log more details about accesses to the site, and/or point out configuration settings that you ought to change to make the site more secure.

Since every application is unique, you'll have to research the available security tools that work with a specific applications.  Be sure to look at how well respected the tool is within the user community, as that will give you an idea of how safe and reliable it will be.

There are also server level security tools that you can utilize, such as Web Application Firewalls (WAFs).  These have to be installed by a server administrator, but can add an extra layer of protection beyond the tools available for the specific application(s) you are running.  The OIT Web Hosting servers all run a WAF that protects their hosting accounts by filtering any requests coming from off-campus.

Write Safe Code

If you are coding applications for the web or even just coding modules / plugins / themes for existing applications, take the time to write safe code:

  • Sanitize any user input that you utilize to deter hackers from running malicious commands by submitting carefully crafted values into a form field.
  • Use proper security wrapping methods to make sure that authorization is being checked properly before the execution of any higher level command.
  • Avoid putting in a backdoor "just for testing", as it can be all too easy to forget to remove it later.  If you must use one, document it boldly and clearly so that it's easy to detect when you review the code later.
  • Do carefully review your code before putting it into production, and even better, have someone else review it as well, since they might catch bugs that aren't obvious to you.
  • Always keep a copy of your code on a separate server, so that if your development or production servers get hacked, you can run a code comparison to your protected code to see if anything was changed by the hackers.

Clean Up After Yourself

Leaving junk behind in your public web hosting account directories can cause multiple problems, so keep your public directories clean:

  • When installing code updates, keep the installers out of your public directories, or at least move them out once you are finished with the update.  If your hosting account doesn't already have a private directory, create one and use it for installers, backups, etc.
  • If you edit live code, don't leave any backup copies in the live directories.  If you need to make a backup of a file before editing it, put the copy in a private directory.  There are many ways in which an improperly named backup file could accidentally expose the program code to a hacker, and depending on the file, this could expose internal user account credentials, shared secrets, or internal server names, all of which could be quite valuable to a hacker.
  • If you run a major update and want to move your current installation to a different folder, once again move it somewhere inside a private (non-public) directory, especially if there is no need to be able to access the old installation over the web.  If you do need to leave the old installation up temporarily, plan a date at which it will be shut down, and if at all possible, firewall that directory for the interim to just on-campus IP addresses (or if possible, just IP addresses for your local unit).  Old installations usually never get patched, and thus can become huge forgotten security holes if left publicly accessible over the web.
  • Security precautions aside, keeping your public web directories neatly cleaned up will help you in many other ways, including making it easier to debug problems and in some cases even speeding up application performance.