Security Tips

Security Tips afrank30
Drupal Version
Tags

The pages in this section provide helpful tips and tricks for improving the security of your Drupal website.  In addition to the information here, be sure to look at our Best Practices for Configuring and Managing Drupal page, and browse through the User Authentication section for more security tips, including how to require user login before viewing specific pages.


Security Resources

Setting Up SSL For Drupal Sites on OIT Web Hosting

Setting Up SSL For Drupal Sites on OIT Web Hosting esembrat3
Drupal Version
Tags

Editor's Note: Information on Obtaining and SSL Certificate and Setting Up SSL on OIT Web Hosting with an External Domain Name has been moved to the Georgia Tech Resources for Webmasters website.

Additional details about enabling SSL for Drupal can be found in Jimmy Kriigel's posting in GitHub about SSL and Drupal sites.

Part I: SSL Certificate

See if you need an SSL Certificate, and if so, obtain your SSL Certificate. In short, if your site is a top-level site on OIT Web Hosting, you can use the existing SSL certificate available on your hosting server - no special configuration on the Plesk control panel side is needed - just follow the steps in Part II below.  If your site's hostname is a subdomain of a department domain (e.g. something.yourdepartment.gatech.edu), then you will have to see if the Plesk certificate includes your "yourdepartment.gateh.edu" domain name - if so, then you should be good to go - if not, then you'll need to obtain a certificate (see "obtain your SSL Certificate" above).

Part II: Configure Your Drupal Instance

Edit Your Site's .htaccess File

Add the following directly after "RewriteEngine On" in your site's .htaccess file:

RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

What this will do is catch any requests that have "www." before your site's hostname and redirect the user to the non-"www." version of the URL.  Then, if the user is not using HTTPS, it will redirect the user to the HTTPS version of the URL to ensure that HTTPS / SSL security is always used.

Edit Your Site's settings.php File (Drupal 7 only)

Find the line for "$base_url" (or add one if this setting is not defined), and set it to the the fully qualified domain name of your site, like so:

$base_url = "https://foobar.gatech.edu/";

Important Note:  The settings.php file is usually protected from editing, so you may have to modify its access permissions before you can modify it.  Try editing it from the File Manager in your hosting account's Plesk Control Panel, as this may make it easier to override those protections.

Restricting a Website to On-Campus Access Only

Restricting a Website to On-Campus Access Only afrank30
Drupal Version
Tags

You can restrict your site so that only people who are on-campus (or using the VPN) can access it. This is a great idea for internal-use-only sites and also for all of your development/test websites if you are not using a local stack.

Using .htaccess Configuration

Here's the code to put into the .htaccess file in the root directory of your site (on OIT Web Hosting, this goes under httpdocs or httpsdocs usually):

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^130.207.
RewriteCond %{REMOTE_ADDR} !^128.61.
RewriteCond %{REMOTE_ADDR} !^143.215.
RewriteCond %{REMOTE_ADDR} !^192.93.8.
RewriteCond %{REMOTE_ADDR} !^10.
RewriteCond expr "! -R '172.16.0.0/12'"
RewriteCond expr "! -R '100.64.0.0/10'"
RewriteCond %{REQUEST_URI} !/vpn-message.html
RewriteRule ^.* /vpn-message.html [R=303,L]

The first three lines cover the main Atlanta campus, while the fourth line (192.93.8.) covers GT Lorraine in France, and the last 3 private campus IP space.  The last RewriteCond line is needed to whitelist your message to off-campus users - otherwise they'll end up in an infinite redirect loop.  Also note the 303 redirect status on the last line: this tells the browser to check back with the server and not cache the redirect.  If you use 301 instead, then a user who connects from off-campus and gets your message file will continue to get it even if they then connect to the VPN.  Using 303 ensures that they'll actually get to your site once they've logged into the VPN.

The method above will direct all outside users to /message.html on your site, where you can post a message about the site being for on-campus use only. An alternate method (shown below) will just give users a 403 Forbidden error, which might be good enough in many cases.

Alternate Method with Basic Apache HTTPD Configuration

The following may be a little easier to maintain than the as the campus network expands and evolves than the version above, but this version will simply give the off-campus user a standard 403 Access Denied error message without any further explanation.

For Apache 2.4 .htaccess

Require all denied
## All Atlanta Campus & VPNs
Require ip 130.207.0.0/16
Require ip 128.61.0.0/16
Require ip 143.215.0.0/16
Require ip 10.0.0.0/8
Require ip 172.16.0.0/12
Require ip 100.64.0.0/10
## GT Lorraine
Require ip 192.93.8.0/24

Using a Firewall

If your website is not on OIT Web Hosting, then you can also limit access through firewalls:

Software Firewall

This kind of firewall you have to set up and maintain yourself, so you need to have some basic networking knowledge to get it configured correctly.  On the other hand, you can reconfigure it yourself whenever necessary.  On UNIX style systems (Linux, Mac OS X, etc.), you can use either  ipfilters or ipfw.  On Windows servers, Microsoft provides its own firewalling tools - check your Windows server documentation for more information.

Hardware Firewall

This kind of configuration has to be done via the GT Networking Firewall web application by someone authorized to make changes to the subnet that your server lives on.  The upside to this option is that you don't have to know anything about networking, and you don't have to worry about your firewall breaking when you run upgrades on your server's operating system.  The downside is that if you don't have access to mange the firewall for your subnet then you'll have to send your requests for changes up to whomever manages your subnet.