Thanks to the growing abundance of useful self-hosted apps such as WordPress and the affordable growth of cloud hosting providers, running your own server is becoming increasingly compelling to a broader audience. But securing these servers properly requires a fairly broad knowledge of Linux system administration; this task is not always suitable for newbies.
When you sign up for the typical cloud hosting account, you'll receive an email with a root account, password, and IP address, and instructions to sign in via SSH on port 22. But it's important to take several additional steps beyond the basic access configurations. That first root password below is actually just the starting point for security. There's much more to do.
This tutorial will provide an overview of common incremental approaches to secure your typical Linux server.
Approaches to Server Security
For purposes of this tutorial, I'm using a new Ubuntu 14.04 droplet from Digital Ocean with the LAMP configuration; if you wish to follow along with the same configuration, example configuration steps are explained here.
Once you map your chosen domain name, you're ready to begin. I'm using http://secure.lookahead.io for my example.
You can log in to your server with SSH: ssh root@secure.lookahead.io. The server should require you to change your password during the first login attempt:
Now, the rest is up to you. Here are a handful of common approaches to improving your server's login security:
1. Update Your System Components
Firstly, it's important to regularly update your Linux system components. Typically, when you log in, Ubuntu will tell you how many packages you have that need to be updated. The commands to update your packages are:
1 |
sudo apt-get update
|
2 |
sudo apt-get dist-upgrade
|
The recent Shellshock security vulnerability revealed in Bash is a perfect example of the need to regularly update your system files.
Each time you log in, Ubuntu will tell you if there are packages and security updates that can be updated.
If you wish, you can activate unattended upgrades:
1 |
sudo apt-get install unattended-upgrades |
2 |
sudo dpkg-reconfigure unattended-upgrades
|
2. Change Your SSH Port From the Default
Leaving SSH access on port 22 makes it faster and easier for hackers to target your servers. Let's change the default SSH port to something more obscure.
Edit the SSH configuration file:
1 |
sudo nano /etc/ssh/sshd_config
|
Change to a different port number, e.g.:
1 |
# What ports, IPs and protocols we listen for
|
2 |
Port 33322 |
Restart SSH:
1 |
sudo service ssh restart
|
Then, log out and try to log in again. You should see this error message:
1 |
ssh root@secure.lookahead.io |
2 |
ssh: connect to host secure.lookahead.io port 22: Connection refused |
This time, use the following SSH command, changing the port to 33322: ssh -p 33322 root@secure.lookahead.io. You should be able to log in successfully.
3. Activate a Firewall
Using a firewall can help block access to ports left unnecessarily open and close attack vectors; it can also help with logging attempted intrusions.
If you happen to be using Amazon AWS cloud services, there's a nice web user interface for its firewall called security groups. The console for AWS security groups makes it easy to turn off access to all ports except your new chosen SSH port and port 80 for web browsing; you can see a visual example of this here:
If you wish to implement Linux-based firewalls, you can study ufw and iptables. While it's beyond the scope of this tutorial, I will give a brief example of using ufw, the "uncomplicated firewall".
First, we'll enable ufw and then allow access for our SSH port 33322 as well as all http traffic, on port 80. Then, we'll deny access on the standard SSH port 22.
1 |
sudo ufw enable |
2 |
sudo ufw allow 33322 |
3 |
sudo ufw allow http |
4 |
sudo ufw deny 22 |
5 |
sudo ufw status |
Be careful configuring ufw, as you can lock yourself out of an existing console session and your entire server.
If you wish to go deeper, port knocking provides a way to more fully obscure your SSH access port. There is a detailed tutorial for advanced users by Justin Ellingwood: How to Use Port Knocking to Hide Your SSH Daemon from Attackers.
4. Change Your Root Login Name
Now, let's eliminate the root login user (or ubuntu on some systems) and customize the administrator's login.
We'll add a user named "hal". Replace "hal" with your preferred username in the examples below:
1 |
sudo adduser hal
|
Add your new user to the sudo group for administrators:
1 |
sudo adduser hal sudo |
Add your new user to the sudoers group. Edit the sudoers file:
1 |
sudo nano /etc/sudoers
|
Add this line to the sudoers file, in the user privileges section:
1 |
hal ALL=(ALL) NOPASSWD:ALL |
Edit the SSH configuration file again:
1 |
sudo nano /etc/ssh/sshd_config
|
Remove the root or ubuntu account from the AllowUsers field. You may also need to add this line if it's not in your configuration file:
1 |
AllowUsers hal |
Make sure PermitRootLogin is off:
1 |
PermitRootLogin no |
Restart the service:
1 |
sudo service ssh restart
|
Log out and try to sign in again as root. You shouldn't be able to. Then, try to log in as Hal: ssh -p 33322 hal@secure.lookahead.io. That should work just fine.
Note that some users may wish to restart SSH, log out, and verify that you can log in as Hal before turning off root login.
5. Activate Google Two-Factor Authentication
Now, we're going to add two-factor authentication to your server login; in other words, when we try to log in to the server, we will be required to provide a time-sensitive code from an app on our phone.
For this example, we'll use Google Authenticator. Be sure to download Google Authenticator from the iTunes app store or Play store.
Then, from your server console, install the Google Authenticator package:
1 |
sudo apt-get install libpam-google-authenticator |
Then we'll edit the Pluggable Authentication Module (PAM) for SSH to require two-factor authentication from Google:
1 |
nano /etc/pam.d/sshd |
Add the following line at the top:
1 |
auth required pam_google_authenticator.so |
Then, return to editing the SSH configuration file again:
1 |
sudo nano /etc/ssh/sshd_config
|
Change the ChallengeResponseAuthentication to yes:
1 |
# Change to yes to enable challenge-response passwords (beware issues with
|
2 |
# some PAM modules and threads)
|
3 |
ChallengeResponseAuthentication yes
|
Save the change and activate the authenticator:
1 |
google-authenticator |
In addition to seeing a large QR code (as shown at the top of this tutorial), you'll also see a set of secret login keys and be asked some questions to customize your configuration:
Using the Google Authenticator app on your phone, choose the edit pen icon in the upper right and add a new entry using the button at the bottom. You can either scan the QR code with your camera or enter the secret key. Once completed, Google Authenticator will be ready to provide codes to you for your next login.
Print a copy of these emergency scratch codes and save them in a secure location, in case you ever need to recover your login without two-factor authentication.
Restart the SSH service again and log out:
1 |
sudo service ssh restart |
2 |
logout |
Log in again, and this time you'll be asked for a verification code before your password. Type in the six-digit verification code from Google Authenticator on your phone:
The addition of two-factor authentication adds a strong layer of secondary security to your server. Still, there is more we can do.
6. Switch to Using SSH Keys for Login
It's wise to turn off your server's password-based login in favor of security keys; keys are far more resistant to attack. Passwords are short and subject to dictionary attacks; keys are longer and for the most part can only be compromised by government agency supercomputers.
To create your SSH key, follow these instructions. Change to the home directory for your new user:
1 |
cd /home/hal
|
Make an SSH directory and set permissions:
1 |
mkdir .ssh
|
2 |
chmod 700 .ssh
|
Generate a new key pair. When prompted, it's up to you whether to add a password to the key:
1 |
cd .ssh
|
2 |
ssh-keygen -b 1024 -f id_hal -t dsa |
Add the public key to the authorized_keys file:
1 |
cat ~/.ssh/id_hal.pub > ~/.ssh/authorized_keys |
Set the permissions for the key file:
1 |
chmod 600 ~/.ssh/* |
Move the private key to a temp folder for download to your local computer:
1 |
cp ~/.ssh/* /tmp |
2 |
chmod 644 /tmp/* |
Download the new private key to your computer using your Ubuntu account. On your computer, use Terminal:
1 |
scp -P 33322 -i ~/.ssh/id_hal hal@secure.lookahead.io:/tmp/* ~/.ssh |
Set permissions and test:
1 |
cd ~/.ssh |
2 |
chmod 400 id_hal |
3 |
ssh -p 33322 -i ~/.ssh/id_hal hal@secure.lookahead.io |
If you run into any errors, you can try looking at the log on the AWS server while you attempt to login:
1 |
tail -f /var/log/auth.log |
Remove the temporary key files from the server's tmp directory:
1 |
rm -rf /tmp/* |
Edit the SSH configuration file again:
1 |
sudo nano /etc/ssh/sshd_config
|
Turn off Password Authentication:
1 |
PasswordAuthentication no |
Restart the SSH service again:
1 |
sudo service ssh restart |
Now, nobody will be able to log in to your server without your private key. To log in to your server, use the following command:
1 |
ssh -p 33322 -i ~/.ssh/id_hal hal@secure.lookahead.io |
Make sure you secure the computer you're using with the private key on it; it's also wise to store a copy of your private key on a flash drive somewhere physically secure.
Note that Google Authenticator two-factor authentication is bypassed when using SSH key security.
Also, if you ever do get locked out of your server during these configurations, DigitalOcean provides a web console that acts as if a keyboard was plugged into your server. For other hosts, you may need to get help from their support team.
7. Manage Your Application Security
While the login portal of your server is a serious vulnerability, honestly, the applications you choose to install are likely to pose even bigger risks. For example, recently I read that using improperly secured regular expressions in your PHP app can open your server to ReDoS attacks.
But a more commonplace example is the recent WordPress plugin vulnerability with Slider Revolution. A theme I had installed actually bundled this plugin, so I had to update the theme to fix the bug.
Application vulnerabilities can be difficult to keep up on. It can make returning to managed hosting seem attractive again; don't give up! Be careful of apps you install, stay on mailing lists for your code providers and keep everything regularly up-to-date.
Be proactive, and do what you can to protect your apps. For example, look at how I describe adding Apache user security to the installation of popular web app, PHPMyAdmin, which is used for simplifying MySQL database access and administration. Because only administrators need access to PHPMyAdmin and the consequences of it being hacked are high, adding an additional layer of password security is quite appropriate for this particular app.
Security is a huge concern and a big area with which to grapple. I hope you've found this tutorial useful. Please feel free to post your own ideas, corrections, questions and comments below. I'd be especially interested in alternate and extended approaches. You can also reach me on Twitter @reifman or email me directly.
