In this post, we looked at some ways to tighten up security and increase the speed of websites in modern times.

How to Implement Security HTTP Headers to Prevent Vulnerabilities? talks about some of the headers that should be modified from their defaults for increased security.

The list of headers they give are…

  • X-XSS-Protection
  • HTTP Strict Transport Security
  • X-Frame-Options
  • X-Content-Type-Options
  • HTTP Public Key Pinning
  • Content Security Policy
  • X-Permitted-Cross-Domain-Policies
  • Referrer Policy
  • Expect-CT

One of the things mentioned in my Best Practices for Websites in 2018 article was HTTP Strict Transport Security (HSTS). Using a CDN, like CloudFlare, HSTS can be included very easily in the free version. However, some of the other headers are only able to be added on the Enterprise version.

Other things it can be helpful to remove from the headers are the exact versions of Apache and PHP. Although, to be fair, there are only a finite number of web servers and programming languages so protection by obscurity is fairly limited.

Updating Headers in Apache and Ubuntu

First of all, a standard fresh install of Ubuntu might not have the headers module installed so add it by…

sudo a2enmod headers
sudo service apache2 restart

Then, most articles say that you should add the headers to the httpd.conf file. This file does not exist in a fresh install of Ubuntu so you have to make it in the location /etc/apache2/httpd.conf then include it in the apache2.conf like so…

Include httpd.conf

Once this is done you can start adding headers to it.

You should check whether you have a httpd.conf or not before you make one. Bitnami creates a httpd.conf that is already pre-populated with a lot of lines of code. This kind of pre-setup is the whole reason that Bitnami exists.

Removing the Version of Apache from the HTTP Headers

Web servers (Apache, Nginx, IIS) typically do not want you to remove them from the headers because it is a way of showing the world how popular they are. Like social media for web servers. So, the method of removing them can be relatively tricky.

One alternative is to use cloudFlare which gives the Server variable the value of “cloudflare”… Easy!

Alternatively, another easy fix is to remove the version number from Apache and just leave the word “Apache” visible.

With headers enabled and httpd.conf included in the apache2.conf you can add the lines…

ServerTokens Prod
ServerSignature Off

After restarting Apache the version of Apache should now be gone. You’re telling Apache that the website is in production so turn off the signatures.

Similarly, adding the following line will remove the ability to do a telnet trace of the website, although this still tells the person you’re using Apache.

TraceEnable off

Remove the Version of PHP from the HTTP Headers

The default for PHP is to not show the version of PHP in the headers, however, I found recently that in a Bitnami install it was actually shown by default.

You can turn this off in the php.ini…

expose_php = Off

As this is a PHP setting it will be the same in Nginx, IIS, etc.

After you have done this you’ll need to restart PHP, like this…

sudo service php5-fpm restart

Updating HTTP Response Headers in Apache

The rest of the headers listed above can be updated in the httpd.conf. Here are a few standard ones that do not need any modifications…

Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains;"
Header always set X-Frame-Options DENY
Header set Referrer-Policy "no-referrer"
Header set X-Permitted-Cross-Domain-Policies "none"
Header set X-XSS-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"
Header always set Expect-CT "enforce, max-age=300, report-uri='https://www.repoting-website.com/'"

The modifications to the httpd.conf will be very similar but different to the lines that would be added to the nginx.conf for Nginx.

Testing the Security of HTTP Headers

The first way to test your headers would be to inspect them in your browser. For Chrome, you would “inspect” then go to the “Network” tab. If the Network tab is empty, reload the page. Once the list of items is populated you can click on the main website which should be at the top, then on the right, there should be a “Headers” tab that lists all the headers.

SecurityHeaders is a great website for testing the security of your headers. The website completely ignores web server version and programming language version as you could argue that removing them does not offer much protection against an attack. Instead, it focuses on the instructions your website is giving browsers from its headers.

Another useful link for updating your HTTP headers that gives examples for different web servers is Hardening your HTTP response headers.

AWS Lightsail is the closest thing AWS has to shared hosting. It is their quick, easy and inexpensive off-the-shelf hosting that has SSH access and many of the benefits of using a more expensive EC2 instance.

It is an affordable entry in cloud computing, but is it any good?

I decided to try out Amazon’s cheapest hosting offering by moving a WordPress blog from some shared hosting to Lightsail. I have tried EC2 in the past so this was not my first experience with AWS, but I was curious to see what their new more consumer-based hosting was like.

Creating an Instance

When you create an instance of Lightsail you chose how big or small you want it. You also chose whether you want just the OS, or you can have an app pre-installed with Bitnami (“App+OS“). The options for the app include a pre-installed WordPress blog, LAMP, MEAN, LEMP or several other applications. Alternatively, you can choose “OS Only” where you currently have the choice of either Windows or Linux flavors: Amazon Linux, Ubuntu, Debian, FreeBSD, openSUSE and CentOS.

I went with the PHP 7 LAMP stack option in the smallest size ($3.50 per month). I chose this option because I wanted to make sure WordPress was exactly the way I wanted it. And I wanted to see what the LAMP option was like.

In the price you also get a dedicated IP which makes setting up a breeze before pointing the domain name at the new instance, definitely a nice touch.

The LAMP 7 option came with PHP 7.1. But it’s possible to upgrade. All the elements of LAMP come pre-installed (Linux, Apache, MySQL and PHP) but you’ll want to configure them to your needs.

The main thing you can say about the setup is that it was lightening fast. Within seconds I had a fully operational instance. In the past, when setting up some hosting you might have assumed it would take at least a couple of days. Because the dedicated IP is plainly visible on the AWS console, you can immediately see the default index page in your browser.

First Look at Lightsail App+OS

The main difference between the “App+OS” option and a normal VPS is Bitnami. You notice right away is that the default username is “bitnami” and after logging into the Linux console you get a large “Bitnami” logo at the top of the screen.

So, what is this Bitnami?

Bitnami

Amazon AWS has so many quirks that you might assume that Bitnami is an AWS thing, as is their own Amazon Linux, but it is quite widely used in cloud computing (including Oracle Cloud and Google Cloud Platform).

With the “App+OS” Bitnami a lot of the things you normally have to do to set up a LAMP stack are already done for you. For example, Apache is pre-installed with most/all modules and even MySQL is pre-installed. However, to find your root login for MySQL you’ll need to look for it, see below.

With Bitnami other slightly unusual thing you notice upon logging into SSH or SFTP is the directory structure, the apache.conf does not look the same as normal, and where are the virtual host files?

Bitnami uses httpd-app.conf, httpd-prefix.conf and httpd-vhosts.conf files, as described here.

This is unusual and I imagine many people who do not want to use Bitnami would want to use the “OS Only” option. While it may take a little longer to set up, once that’s done you have a “normal” Bitnami-free Linux instance.

Transferring a Website to Lightsail

Having gone with the LAMP (PHP 7) option I basically followed my guide from here to move a WordPress blog over to different hosting. With minimal setup to do it was mainly a case of setting up the database, installing WordPress then using WP-CLI to install the plugins and theme.

As the instance was just going to be hosting one website I didn’t have to worry at all about the virtualhosts as everything was set up to just work from the off.

My first question was how do I login to MySQL. The login info for MySQL did not appear to be anywhere in the AWS console. To find the password for the root user you need the Bitnami Application password. From the home directory (where you arrive after logging in) just type…

$ cat bitnami_application_password

Transferring everything across, most things just worked. While PDO worked fine in normal PHP pages, I had to tweak the php.ini to get PDO to work from a script run with cron. For me, I just had to uncomment the .so file for PDO which was almost the last line of the php.ini.

After changing something like the php.ini you’ll have to restart. The following command seems to stop everything (apache/HTTPd, PHP and MySQL, ), then restart everything; perfect for making sure everything gets restarted all at once but not very graceful (from here)…

$ sudo /opt/bitnami/ctlscript.sh restart

To just restart apache you’d just add “apache” to the end…

$ sudo /opt/bitnami/ctlscript.sh restart apache

Linux

While some things are very different in Bitnami, it’s basically just a Linux instance. The Linux version I got with the LAMP (PHP 7) option was actually Ubuntu 16.04, so if you want the latest version of Ubuntu (18.04 is currently the latest LTS), or a different flavor of Linux, chose the “OS Only” option. I am most comfortable with Ubuntu/Debian and a lot of the standard CLI functions are exactly the same as Ubuntu.

Nano comes pre-installed and was the default editor for the crontab.

$ crontab -e

BTW, cron needs the full path to php, i.e. something like…

* * * * * /opt/bitnami/php/bin/php -f /opt/bitnami/apache2/htdocs/scripts/index.php "name_of_method()"

Then…

$ sudo service cron reload

The timezone is quite important because it can also affect your keyboard layout when typing into the Linux terminal. Changing the timezone is based on Ubuntu 16.04, so something like this would work to list the timezones, select a timezone then check which timezone you’re using…

$ timedatectl list-timezones   
$ sudo timedatectl set-timezone America/Vancouver  
$ timedatectl

Now, that the Linux timezone is set, you may also need to update the timezone PHP uses by updating this line in the php.ini…

date.timezone="Europe/London"

For all the PHP timezone variables, click on your region from the PHP timezones page.

Something else that is the same as Ubuntu is updating and upgrading…

$ sudo apt-get update
$ sudo apt-get upgrade

Once you get used to the quirks and the different directory structure with Bitnami, most things seem the same as a typical Ubuntu instance.

Issue(s) with AWS Lightsail

The first “upgrade” was a large one which took a while. It took so long in fact that either putty went inactive, or my computer went to sleep, or both. After this, the website went down and I had no access to SSH. What I seemed to have to do was not “reboot” the instance, but “stop” and “start” the instance from the AWS console. After this, I had a different public IP address but I was able to fix whatever had happened with the upgrade.

If the restart is the opposite of graceful, stopping and starting was similarly very ungraceful, comparable to doing the same thing with any VPS instance.

Apart from some minor changes that will probably be easy to get used to, I did not have many issues at all.

AWS Lightsail App+OS: Conclusion

Bitnami saved some time during setup, but honestly, any time I saved was probably offset by time spent figuring out what was going on with Bitnami.
I’m not 100% sure that the speed of setup of Bitnami is worth the changes it makes to the Linux operating system. For something like this example, a WordPress blog, that isn’t going to need a lot of administration, the “App+OS” option was fine though.

If you are a purist and don’t mind setting up the Linux instance with everything you need there is always the “OS Only” option which I don’t believe uses Bitnami. This would be better for a website where you’re going to want to make more changes to the Virtualhost file and/or possibly upgrade to an EC2 instance in future. If you are already a full stack LAMP developer you’ll probably be wanting to use that option for any actual development. App+OS seems to be mainly for people who do not want to get too involved with the “L” or “A” parts of LAMP.

AWS Lightsail with the App+OS option is perfect for someone who just wants to have a cheap WordPress blog running on AWS, as I did here. For a brand new blog, choosing the “WordPress” option would simplify the whole process even more.

I’d say App+OS might also be a good way to play around with something new such as MEAN before starting an actual project with it. Everything would be pre-installed so you could get straight into the javascript and the NoSQL.

So far so good. The instance seems fast for a WordPress blog, it certainly is compared to the previous shared hosting. And, very affordable.