Hosting WordPress Yourself Part 1 – Setting Up a Secure Virtual Server
Welcome to the first post in the series on Hosting WordPress Yourself, in which I will guide you through the process of building a complete server to house your WordPress sites. I’m going to start at the very beginning and detail the complete approach I personally take to build a new server that’s easy to configure, secure, tuned for optimal WordPress performance and scalable for small to medium sized sites. (Wondering why you’d want to host WordPress yourself in the first place? Check out our 7 reasons.)
The server is going to be designed for single user access. Therefore this setup isn’t going to be suitable for a shared hosting environment, but is ideal for personal and fully managed client sites. Depending on the virtual server package you choose, this setup should comfortably handle multiple sites on a single server.
In this tutorial series I’m going to use a Digital Ocean 512MB droplet ($5/month), but you could also choose Linode, Amazon EC2, or one of the many other virtual server providers. Regardless of which you choose, the steps following the initial server creation should be very similar. The steps detailed in this series are written for Mac users, but Windows users shouldn’t find too many differences once you get past part 1. I’m also assuming you are comfortable using the command line. Finally, although designed for WordPress, this setup should work equally well for other PHP open source systems.
So, without further ado, let’s begin building your new server!
Selecting a Linux Distribution
I’m not going to go into detail on the initial droplet (server) creation as Digital Ocean has their own tutorial, but I do want to list the reasons I choose Ubuntu as my Linux distribution and how I pick a release version. Ubuntu is one of the most popular distributions for servers and here’s a few reasons why:
- Heavily focussed on usability
- A large selection of packages
- Frequent software updates
- A large community leading to more helpful resources
One drawback to choosing a distribution with frequent software updates is that it’s possible to introduce new bugs and conflicts. Luckily, Ubuntu has a LTS (Long Term Support) release, which uses packages that are considered more stable. LTS releases occur every 2 years and are supported for 5 years – making them suitable for production servers. At the time of writing, the latest LTS release is 18.04 (Bionic Beaver), which is the version I’m going to choose.
With the distribution and release version selected, go ahead and create a new droplet. Remember to select a region that is closest to the majority of your base audience. I would also recommend that you enable the ‘Monitoring’ option.
Once the server has finished provisioning you should receive an email containing the droplet IP address, username and password. Begin by connecting to your new droplet and changing the root password, which is required on first login:
Although you are going to disable root login a bit later, you should set a strong password (using a tool like 1Password), as you will still be able to switch to the root user once logged in.
Setting the Hostname
Now that you’re logged into the server, let’s set the hostname and fully qualified domain name (FQDN). The hostname should be unique but doesn’t require any relationship to the sites that will be hosted, for example, people often name their servers after astronomical objects. Correctly setting the hostname and FQDN will make connecting to your server much easier in the future as you won’t have to remember the IP address each time. To set the hostname, issue the following commands (altered for your chosen domain name):
echo "pluto.ashleyrich.com" > /etc/hostname hostname -F /etc/hostname
In order to connect to the server using your hostname you need to update your domain name’s DNS settings. Log into your DNS control panel and create a new A record:
Now if you exit out of the current SSH session you should be able to connect to the server using the new hostname. However, you may need to wait a while for the DNS settings to propagate:
Setting the Timezone
So that the server is running on your local timezone you must configure the tzdata package, which will ensure that the system log files show the correct date and time. The following command will allow you to configure the tzdata package:
A simple GUI will be displayed, allowing you to select your geographic area and time zone:
Once completed, the newly selected timezone will be displayed along with the current time and date:
Installing Software Updates
Although you have only just provisioned your new server, it is likely that some software packages are out of date. Let’s ensure you are using the latest software by pulling in updated package lists:
Once completed, let’s update all of the currently installed packages. You will be prompted with how much space the updates will take – hitting Y and Enter will begin the process:
When the upgrades have completed you will be shown which packages have installed, and also which packages are no longer required by the system.
Feel free to remove the outdated packages by issuing the following command:
Creating a New User
It’s time to add a new user to your server. There are two reasons for this:
- Later in this tutorial you are going to disable root login, which means you need another user account in order to access your server.
- The root user contains very broad privileges which will allow you to execute potentially destructive commands. Therefore it’s advised to create a new user account with more limited permissions for day-to-day use. This new user will be added to the sudo group so that you can execute commands which require heightened permissions, but only when required.
First, create the new user:
You’ll be prompted to enter some basic user information and to select a password. As mentioned previously, this password should be complex:
Next you need to add the new user to the sudo group:
usermod -a -G sudo ashley
Now ensure your new account is working by logging out of your current SSH session and initiating a new one:
Then login with the new account:
Generating a Key Pair
At this point your new user is ready to use, however for enhanced security you are going to add public key authentication. I’m not going to go into detail on how to create an SSH key pair (Digital Ocean have an informative article on the process), but if you don’t already have one, enter the following command on your local machine:
You should receive a message like I have below, just hit return to accept the default location. You’ll then be prompted to enter a passphrase (optional), which will require you to enter a password every time you login with this key pair:
Copying the Public Key
Now that you have your SSH key pair, you need to copy the public key to your server. Assuming you saved the key in the default location, the following command will print the key to your console window:
Select the outputted string and copy it to your clipboard. Go back to your SSH session, ensuring you are logged in with the newly created user. Now create the .ssh directory and set the correct permissions:
mkdir ~/.ssh chmod 700 ~/.ssh
Within the .ssh directory create a new file called authorized_keys which contains the public key you copied from your local machine:
Save the file using CTRL-X and then Y. Finally, set the correct permissions on the file:
chmod 600 ~/.ssh/authorized_keys
Now if you logout of the current SSH session and try reconnecting, you should no longer have to enter your user password. Remember, if you set a passphrase when creating the SSH key, you will need to enter it when prompted.
With your new user created, it’s time to further secure the server by configuring SSH. The first thing you are going to do is disable root login, which as the name suggests will no longer let you log into the server via SSH using the default root user. Open the SSH configuration file using nano (notice the use of sudo to heighten privileges for this command):
sudo nano /etc/ssh/sshd_config
Find the line that reads
PermitRootLogin yes and change it to
PermitRootLogin no. Hit CTL-X then Y to save the changes. In order for the changes to take affect you must restart the SSH service:
sudo service ssh restart
Now if you exit out of the current SSH session and try connecting with the root user you should receive a permission denied error message.
The final step to securing SSH is to disable user login using a password. This ensures that attackers need your private SSH key to login to the server. Remember, if you lose your private key you will be locked out of the server, so keep it safe! Most virtual server providers do have other means of logging in, but it’s best not to rely on those methods:
sudo nano /etc/ssh/sshd_config
Find the line that reads
#PasswordAuthentication yes and change it to
PasswordAuthentication no. Hit CTL-X then Y to save the changes. Once again, you must restart the SSH service for the changes to take effect.
sudo service ssh restart
Now, before you log out of your server, you should test your new configuration. To do this open a new terminal window, without closing the current SSH session and attempt to connect:
You should login to the server successfully. To further test that password authentication is disabled I like to temporarily rename the SSH key located in my .ssh directory. When attempting to log into the server this time you should receive a Permission denied (publickey) error.
The firewall provides an additional layer of security to your server by blocking inbound network traffic. In this article I’m going to demonstrate the iptables firewall, which is the most commonly used across Linux and is installed by default. In order to simplify the process of adding rules to the firewall I like to use a package called ufw, which stands for Uncomplicated Firewall. The ufw package is usually installed by default, but if it isn’t go ahead and install it using the following command:
sudo apt-get install ufw
Now that you have access to ufw you can begin adding to the default rules, which deny all incoming traffic and allow all outgoing traffic. For now, add the ports for SSH (22) and HTTP (80):
sudo ufw allow ssh sudo ufw allow http
If you plan on running a site using HTTPS you will also need to add port 443:
sudo ufw allow https
To review which rules will be added to the firewall, enter the following command:
sudo ufw show added
Before enabling the firewall rules, ensure that the port for SSH is in the list of added rules – otherwise you won’t be able to connect to your server! The default port is 22. If everything looks correct, go ahead and enable the configuration:
sudo ufw enable
To confirm that the new rules are active, enter the following command:
sudo ufw status verbose
You will see that all inbound traffic is denied by default except on ports 22, 80 and 443 for both IPv4 and IPv6, which is good starting point for most servers.
Fail2ban is a tool which works alongside your firewall. It functions by monitoring intrusion attempts to your server and blocks the offending host for a set period of time. It does this by adding any IP addresses that show malicious activity to your firewall rules.
The Fail2ban program isn’t installed by default, so let’s install it now:
sudo apt-get install fail2ban
The default configuration should suffice, which will ban a host for 10 minutes after 6 unsuccessful login attempts via SSH. To ensure the fail2ban service is running enter the following command:
sudo service fail2ban start
Job done! You now have a good platform to begin building your WordPress web server and have taken the necessary steps to prevent unauthorised access. However, it’s important to remember that security is an ongoing process and you should keep in mind the following points:
- Install only required software from trusted sources
- Regularly install software updates and security fixes
- Enforce strong passwords using a tool such as 1Password
- Use common sense and think about how you would gain access to the server if you were locked out
That’s all for part 1, in the next post I will guide you through installing Nginx, PHP-FPM and MariaDB. Until next time!