GCHQoogle: so much for "Don't be evil" So, unless you’ve been living under a rock for the past few months, you will be aware of the disclosure, by one Edward Snowden, of a massive multinational criminal conspiracy to subvert the security of internet communications and place us all under surveillance.

Even if you believe the security services won’t misuse this, what GCHQ can figure out, other criminal organisations can as well, so like many others, I’ve decided this’d be a good time to tighten the security of some of the sites I am responsible for.

Enabling HTTP Strict Transport Security

So, lets start off by making sure that once you end up on the secure version of a site, you always get sent there. For most sites I had already had a redirect in place, but this wouldn’t help with a number of threats. Thankfully, modern browsers support a header, that when received, will cause the browser to rewrite all connections to that site to the secure endpoint before they are sent.

A quick and easy win, so in my apache conf I placed:

Header add Strict-Transport-Security "max-age=15768000; includeSubDomains"

Auditing my SSL configuration, enabling forward secrecy

The next step was to examine the actual SSL/TLS configuration used by the various servers.

During the initialisation of a secure connection, there is handshake that takes place which establishes the protocol used (SSL / TLS), the version, and what algorithms are available to be used. The choices presented have an effect on exactly how secure the connection will be, and obviously, older and insecure protocols and weaker algorithms present security risks.

I have been, I admit, somewhat remiss in the past, and have largely used Apache’s defaults, which was ok for the most part, but as SSL Lab’s handy audit tool revealed left a number of weak algorithms available as well as not taking advantage of some newer security techniques.

I quickly disabled the weaker algorithms and SSL protocols, and also took the opportunity to specify that the server prefers algorithms which support Forward Secrecy.

Forward secrecy is a property of newer algorithms (supported, sadly, only by newer browsers), that means that even if the key for a given session has been compromised, that key could not be used to decrypt any future sessions. This means that even if the attacker compromised one connection, they would not be able to compromise any past or future connections.

Here is a handy guide for implementing this on your own server.

The downside of these changes of course is that older browsers (IE6, I’m looking at you) are left out in the cold, but these browsers (IE6, I’m still looking at you) are using such old implementations with weak algorithms, they would likely be in trouble anyway.

Security is a moving target, so it’s important to keep up to date!

Update: If you’re running Debian (as I am), you will have some issues with ECDHE suites until stable updates to Apache 2.4. Until then I’ve tacked on AES support at the end, to support IE with something reasonable, but giving forward secrecy to more modern browsers.

Update 27/6/14: Debian recently backported a few 2.4 cipher suites into the 2.2 branch in debian stable. This means that Perfect Forward Secrecy is now supported for Internet Explorer!

I do a lot of web development these days, on number of projects, which often require their own domain, so I thought I’d share a quick tip that I’ve found helpful.

In a nutshell, I use wildcard domains and used the Apache vhost alias module in order to be able to automatically create a domain per project.

Setting up bind

The first step is to set up wildcard DNS for your machine, in this case *.dev.mymachine. Assuming you’ve got bind set up, this is just a matter of configuring a local zone for your network (or adding this to your existing local zone).

It’s late, and I’m tired, Google “wildcard dns bind” and that’ll point you in the right direction.

Setting up the vhost

Next, you need to set up an Apache vhost for your wildcard domain, but crucially, instead of specifying DocumentRoot in the normal way define VirtualDocumentRoot.

First, enable the module:


a2enmod vhost_alias

Then, set up and enable a definition which uses variables supplied by the vhost_alias, which will use the structure of the url line to load the appropriate web page.


<VirtualHost *>

ServerAdmin webmaster@myhost.com
ServerName myhost.com
ServerAlias *.myhost.com

# Indexes + Directory Root.
DirectoryIndex index.html index.php
VirtualDocumentRoot /home/%2/mycode/%1/

<Directory "/home/*/mycode/">
AllowOverride All
Options +Indexes +Includes +FollowSymlinks +ExecCGI
</Directory>

</VirtualHost>

The above code will use the directory name plus the user’s username, for example, fizzbuzz.marcus.myhost.com.

What this means is that you don’t need to create a new virtual host for each one of your projects, which may save you a little time.

Yesterday, there was a thread on hacker news highlighting that many sites around the world were making available potentially sensitive information about their site via Apache’s server-status link (provided by mod-status).

The stated advice is to limit access to this and similar pages (such as the server info page provided by mod-info) by using Allow/Deny to limit access to requests from the local machine, thus:

<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1 ::1

</Location>

Many distributions have this as the default configuration, but beware!

If you run Squid in a reverse proxy configuration, which many sites including this one do to improve performance under high load, you can easily expose such pages.

A common reverse proxy configuration is to run Squid on the local machine “in front” of Apache by configuring Squid to listen to port 80 and relaying to a local Apache server (which is bound to a different port). Under this configuration all requests to Apache will appear to be local, originating from the local machine.

Without extra steps being taken (such as using Squid ACLs) you could quite easily expose sensitive information you thought was only available to your local admins.

Beware!