Lets Encrypt!

Lets Encrypt! Free Certificate!

Lets Encrypt

I thought I would run through the process of obtaining a certificate for a web server from Lets Encrypt the open certificate authority by the Internet Security Research Group (ISRG) , for free!

The Lets Encrypt initiative has been setup to simplify the process of obtaining a certificate and make it more accessible for people to use encryption on their websites you can read more about it here: https://letsencrypt.org/. Certificates are free and valid for 90 days and need to be renewed for continuation of the service. (which can be automated). Those who have been through the process of provisioning certificates will understand the involved process to get it working, this is a breath of fresh air in comparison.

Sounds great so what do we need to do? Well the below example runs through the process for an already created standard HTTP apache debian based system.

OK So Lets Encrypt!

First we need to obtain the Lets Encrypt files. We will pull the files across from the Official GitHub repository. We’ll do this through git. This ensures that we have the latest version of the Lets Encrypt files. We will drop it under the /opt folder.

If you don’t have git installed… install it with:

apt-get install git

Then pull across the Lets Encrypt folder with:

git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

(If you want to update in the future run ‘git pull’ in the same folder.)

Move into the lets encrypt folder:

cd /opt/letsencrypt

We then need to install the Lets Encrypt client through the ‘letsencrypt-auto’ command, when this is run it will essentially pull down all the related dependencies from your OS repositories and update the client through either apt-get or yum for example. From there on you can run either ‘letsencrypt’ or ‘letsencrypt-auto’ command for new certs of renewals.

Next we will obtain our certificate and bundle for our test domain testdomain.co.uk and subdomain www.testdomain.co.uk with the letsencrypt-auto command. This is the recommended method from the Lets Encrypt website.

There are a number of plugins that can be used with letsencrypt run command, and a number of command line parameters you can pass, these are all designed to help ease the process along. We are going to be running the Apache plugin and so will pass it the ‘–apache’ command. This plugin is designed to be used with Apache (funnily enough!) which automates the process of obtaining and installing the certificate with Apache2.4 on Debian based systems. This effectively sorts all the certificate configuration within Apache and then restarts the service.

./letsencrypt-auto --apache -d testdomain.co.uk -d www.testdomain.co.uk

After this is executed you should see the updates scroll through pulling content from your repositories, after a while you will presented with the following screen asking you to confirm your email. This is used as a reminder for renewal:

You can automate this process passing the –email parameter at the command line if you wish. So ‘–email admin@testdomain.co.uk’

You will next be asked to agree to the terms of service:

Again you can automate this by passing the –agree-tos in the command line.

Next you will be asked where you want to access your site through http and https or just through https.

You will then be presented with the ‘Congratulations!’ screen saying you have successfully configured your certificate and enabled https:

Renewal

To renew your certificate run:

letsencrypt-auto renew

This will renew all your certificates with all previously used parameters for certificates that are due to expire within 30 days. passing the -d parameter will renew per domain.

--force-renewal

Allows you to renew before 30 days.

You can also run:

letsencrypt-auto renew --rsa-key-size 4096

This will renew your certificate with a key size of 4096 bit.

You can also rerun the existing command you ran earlier in which case you will be prompted that you have already run the command and to either re-run the install or renew your certificates.

All that is left to do is to automate the renewal with a cron job, one for another post.

Amazing that’s it! This makes obtaining a certificate for a website very accessible to people due to the way the scripts/plugins automate the apache configuration.

**Thumbs up Lets Encrypt this is great project!**

7th February 20162nd January 2017

Server Hardening: HTTP TRACE TRACK Methods Allowed – Part1 Apache

Many vulnerability scanners will often bring back HTTP TRACE TRACK Methods Allowed against Apache and Microsoft web servers of the older generation. TRACE is usually associated with Apache and TRACK for Microsoft. This has a CVSS score of 4.3 and is a relatively easy fix. Clearly the older generation operating systems should be migrated to a supported platform, both the later distributions of Ubuntu and Microsoft 2012 R2 do not allow these methods to be used. However a simple way to validate this finding is to use telnet to connect to the web server on port 80, once connected you can type something similar to the following for each method. The ‘Host’, ‘TestA’ and ‘TestB’ aren’t needed however if you use some custom text you will be sure to see it echoed back by the web server if trace is enabled.

TRACE / HTTP/1.1
Host: 192.168.0.29
TestA: Is this correct?
TestB: Are we sure?

Tap return twice to send.

Which would look something like the below as you can see the user input was returned, the web server accepting the method:

Remediation:

As I said the HTTP TRACK / TRACE issue is this is relatively straight forward to fix, simple add ‘TraceEnable off’ somewhere in your main Apache config file outside of the vhost configuration.

Once implemented retesting should reveal that the method is not allowed:

after adding 'TraceEnable off' HTTP Trace disabled on Apache — After adding ‘TraceEnable off’

10th October 201523rd November 2016

Web Server Hardening: Removing Server and Software version information

All too often web servers are setup with fairly standard configuration. The HTTP Headers display various information from time stamps, cookie info and also server version.

Server version information especially should be removed from the HTTP headers as it allows an attacker to identify what the underlying server and web server version is. If vulnerabilities lie in the stated version, an attacker can concentrate there efforts towards that version identified on your system more easily.

The below configurations should be set for minimal server version info.

Linux/Apache/PHP:

In the /etc/php5/apache2/php.ini file find the line ‘expose_php = On’ and set the parameter from ‘On’ to ‘Off’ as below:

; Decides whether PHP may expose the fact that it is installed on the server
; (e.g. by adding its signature to the Web server header).  It is no security
; threat in any way, but it makes it possible to determine whether you use PHP
; on your server or not.
; http://php.net/expose-php
expose_php = Off

This will remove the ‘X-Powered-by’ option from the HTTP header thus removing your PHP version and OS version information.

In the /etc/apache2/conf-available/security.conf locate the ‘Server Tokens Full’ line and change the parameter from ‘Full’ to ‘Prod’ this will give the least amount of information. Unfortunately without changing this hard-coded parameter and recompiling apache yourself there is no way to reduce this information any further.

# ServerTokens
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
# Set to one of:  Full | OS | Minimal | Minor | Major | Prod
# where Full conveys the most information, and Prod the least.
#ServerTokens Minimal
#ServerTokens OS
#ServerTokens Full
ServerTokens Prod

In the same file locate the ‘ServerSignature On’ line and change the parameter from ‘On’ to ‘Off’, or comment out the existing line and add a new one in with the ‘Off’ option as below.

The ServerSignature isn’t actually information from or displayed in the HTTP headers, it is however information that is displayed at the bottom of for example a 404, 403 default page, which again will give away information about your system. Better still use a custom 404 or 403 page however if you don’t have custom pages this is the next best thing.

# Optionally add a line containing the server version and virtual host
# name to server-generated pages (internal error documents, FTP directory
# listings, mod_status and mod_info output etc., but not CGI generated
# documents or custom error documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of:  On | Off | EMail
ServerSignature Off
#ServerSignature On

And as usual you should test these configurations out in a test environment first before your main production web servers.

10th September 201523rd November 2016

Changing SSL TLS Cipher Suites in Windows and Linux

I have added a basic guide for changing SSL TLS cipher suites that Windows Server IIS and Linux Ubuntu Apache2 use. Allowing only secure ciphers to be negotiated between your web server and client is essential. This guide will go through how to change and select the different ciphers for both Windows server 2012 R2 and Ubuntu 14.04 in order to help mitigate some of the vulnerabilities in the SSL/TLS protocols.

Read further on the Resource page for changing SSL TLS Cipher Suites here.

29th August 20152nd January 2017

Quick SSL Scan

OK so with a my new website up my first thought was ‘right lets secure it!’. Now if only more people thought this way surely we wouldn’t see half the info sec issues we see today. So I’m probably slightly biased on the subject being a Pentester. Not sure if biased or paranoid is better word.

I’m supposed to be on holiday in wales for the bank holiday however 8 hours into the site build and can’t help but think, security. A few tasks later and I navigate to Qualys, lets see where we currently stand, 10 minuets later and I’m building a Kali 2.0 virtual machine in Virtual Box on my laptop in the hopes of pentesting it over 3G!

So a Grade B on ssllabs.com . A little work needed I think.

Qualys.com is a great resource for scanning URL’s to see what SSL/TLS cipher suites are in use. Check it out!

Disabling SSL v2, v3 and also RC4 in Apache2.

By the time I had finished typing this post I was up to a A- having disabled RC4 in the SSL.conf file in mods-enabled folder be appending the ‘SSLCipherSuite’ with :!RC4. Disabling SSL v2 and v3 is also a simple step by appending the ‘SSLProtocol’ line with ‘-SSLv3 -SSLv2’ in the same file.

This is very much only a small step towards securing a site, although a good start!