Securing Sal

What is Sal?

Never heard of Sal? Then you need to take a trip over to YouTube and watch Multi-Tenated Munki with Puppet and Sal. Sal was written by Graham Gilbert and is a multi-tenated reporting solution that collects information about your Macs and puts them in a very nice looking dashboard. This is especially great for me since I’m trying to manage many machines, all over the country. There is even a nice plugin called Sal-WHDImport that allows WebHelpDesk to pull information about the client Macs and update its own asset database.

Let’s get down to business now. If you’re following along, please note that I won’t be covering installation of Sal. Graham has already covered this on the GitHub page for Sal: https://github.com/grahamgilbert/sal/blob/master/docs/Installation.md I’ve installed Sal in a Hyper-V virtual machine and it’s running on Ubuntu 14.04.1 LTS with Apache2.

The Cert

The first thing I had to do was get a certificate from my SSL certificate vendor, DigiCert. But that means I need what is called a CSR (certificate signing request). Basically, it’s a file that contains a unique server encryption key that was then signed by your server. Once given to DigiCert, they will then sign the CSR and give it back to you. This will enable your browser to trust the website you’re trying to access and make a secure connection. I had never generated a CSR on my own before (WebHelpDesk includes an app called Portecle that handles the CSR for you). Luckily, DigiCert has a great OpenSSL CSR Tool to help you generate a line of code you then use on your server to generate a CSR. After I did that, I followed DigiCert’s guide: Ubuntu Server with Apache2 SSL Certificate Installation

Enabling SSL

I modified the /etc/apache/sites-enabled/sal.conf file for SSL. Here’s a copy of what it looks like at this point:

 ServerName sal.example.com
 SSLEngine on
 SSLCertificateFile /usr/local/certs/star_example_com.crt
 SSLCertificateKeyFile /usr/local/certs/ssl_csr/sal_example_com.key
 SSLCertificateChainFile /usr/local/certs/DigiCertCA.crt
 WSGIScriptAlias / /usr/local/sal_env/sal/sal.wsgi
 WSGIDaemonProcess sal user=saluser group=salgroup
 Alias /static/ /usr/local/sal_env/sal/static/
 
 WSGIProcessGroup sal
 WSGIApplicationGroup %{GLOBAL}
 Order deny,allow
 Allow from all
 Require all granted


 

I noticed that this file didn’t call for any SSL protocol or cipher suite declarations. I found those /etc/apache2/mods-enabled/ssl.conf. I did a web search for “Apache2 SSL Hardening” and found a great article by SSLLabs: Configuring Apache, Nginx, and OpenSSL for Forward Secrecy The ssl.conf file contains many settings but the ones we’re after are below. I changed the ciphers line to use colon-delimited since Apache2 on Ubuntu didn’t like spaces between them.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
 

At this point a quick test on SSL Labs gets us an “A” rating. We can do better though.

Enabling HSTS

Since I’m working with Apache2, enabling the HTTP Strict Transport Protocol is very straight forward. I did a couple more web searches and pieced together a method I liked. At this point /etc/apache/sites-enabled/sal.conf looks like this:

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



 ServerName sal.example.com
 SSLEngine on
 SSLCertificateFile /usr/local/certs/star_example_com.crt
 SSLCertificateKeyFile /usr/local/certs/ssl_csr/sal_example_com.key
 SSLCertificateChainFile /usr/local/certs/DigiCertCA.crt
 WSGIScriptAlias / /usr/local/sal_env/sal/sal.wsgi
 WSGIDaemonProcess sal user=saluser group=salgroup
 Alias /static/ /usr/local/sal_env/sal/static/
 
 WSGIProcessGroup sal
 WSGIApplicationGroup %{GLOBAL}
 Order deny,allow
 Allow from all
 Require all granted


 

However, I kept getting an error that the mod_header.so mod wasn’t found. This is easy to fix with one command:

sudo a2enmod headers

I restarted Apache2 and found that HSTS was enabled! We now get an “A+” grade, which is fantastic. There is one more thing to do.

Enable a Redirect

You may notice, at this point, that you have two sites. A default Ubuntu page at port 80 (http://sal.example.com) and Sal at port 443 (https://sal.example.com). What we would like is to have users redirected to Sal on port 443 even if the visit the site over port 80. We just need to make another small change to /etc/apache/sites-enabled/sal.conf. It will look like this when we’re done:

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

 ServerName sal.example.com
 Redirect / https://sal.example.com



 ServerName sal.example.com
 SSLEngine on
 SSLCertificateFile /usr/local/certs/star_example_com.crt
 SSLCertificateKeyFile /usr/local/certs/ssl_csr/sal_example_com.key
 SSLCertificateChainFile /usr/local/certs/DigiCertCA.crt
 WSGIScriptAlias / /usr/local/sal_env/sal/sal.wsgi
 WSGIDaemonProcess sal user=saluser group=salgroup
 Alias /static/ /usr/local/sal_env/sal/static/
 
 WSGIProcessGroup sal
 WSGIApplicationGroup %{GLOBAL}
 Order deny,allow
 Allow from all
 Require all granted

There! Now it’s perfect.

Conclusion

Is there anything revolutionary about what I just covered? Nah. In fact, this should probably be called “Securing Apache.” Nevertheless, citing a real use case is always helpful. I’m very excited to have Sal as another member of my solution-stack. With SSL hardened and getting a great grade from SSLLabs, we’re ready to start improving our client’s experience.