How to secure a fresh Linux virtual private server install

Introduction

A Linux virtual private server (VPS) is an essential tool for any cyber security analyst, but left unsecured it can quickly be taken over by those with more nefarious intentions. Lets make sure that does not happen. This blog and accompanying video covers a few basic “must do” tasks to configure a secure Linux virtual private server at first boot. Why do we need to secure a new system? Within seconds of it coming online it will be found and attacked. If you want to test this you can leave this system as installed for 24 hours and then check the logs, there will be brute force attempts on ssh at a minimum. You may want to re-deploy the VPS before going any further if you performed this test.

YouTube video on how to secure a Linux VPS.

Getting Started – How-To Configure a Secure Linux Virtual Private Server

Setting up a Linode VPS

Lots of companies offer VPS solutions but we rely on Linode and have never had any problems at all, their customer support is top notch and deploying a VPS is quick and easy. If you are just starting out I suggest you get their Nanode package for $5 per month, it is cheap and gives you more than enough horsepower to start. Later you can increase the size as needed and it is really easy to do with no rebuild, they just increase the ram, cpu, bandwidth and disk size. Once you signup just add a Nanode (or lager if you like) and deploy it with a Centos 7 image. Several minutes later you will be ready to start it up, just click the boot button and it will boot up. Access the VPS with putty from a Windows host or SSH from Linux.

Configuring SSHD and restricting access

By default Linodes will have only the root account setup so login using the root username and password you setup when you configured the host. Now we want to edit the hosts.allow file to explicitly allow our system to ssh into the VPS. If you do not know your IP address open a browser, go to Google and type in “whats my ip address” and it will show you. If you have a dynamic IP you will need to include your ISP’s net block in cidr notation. Use VIM to edit /etc/hosts.allow to allow the IP where you will ssh from as in the example below, just replace the example addresses with your IP or net block (just use one of the examples, try to limit the scope to as small as possible):

SSHD: 11.222.0.0/16
SSHD: 11.222.1.0/24
SSHD: 1.2.3.4

Now lets edit the hosts.deny file and add a default deny all policy to restrict everyone else from entry via ALL means. Use VIM to edit /etc/hosts.deny to explicitly deny everything else:

ALL: ALL

Since the root user is the only one on the system now, and logging in with root is a terrible idea, we need to create a new user and configure SSHD to not allow root to login via SSH. First we will create a new user and set a password, remember a good password will have upper and lower case letters, numbers, symbols and be at least 12 characters with no dictionary words. DO NOT use a password you use somewhere else!

useradd yourusername
passwd yourusername

Since it is such a bad idea for root to login remotely over SSH, lets configure SSHD to disallow it. Use VIM to edit /etc/ssh/sshd_config (find the line that says “PermitRootLogin yes” and change it:

PermitRootLogin no

Now we will have to restart SSHD for the changes to take effect. This is easily accomplished by executing the following command as root:

systemctl restart sshd

Now its time to test our work, use Putty or the Linux SSH client and try to login to your VPS with root. This should fail. Now try to login with your newly created username. This should work. If the testing goes as expected we can conclude we have correctly configured SSHD and restricted access by hosts.allow and hosts.deny; however we are not done yet. We need to add another layer of protection to our VPS in case something goes wrong.

Configuring the firewall

Now we can configure the firewall to add another layer of security to what we have already done. Firewalld is a great front end to iptables and makes configuration much easier.

First we should make sure it is up and running. This can be done with systemctl:

systemctl status firewalld

Check to see what the default zone is and which zone is active by typing the following command:

firewall-cmd --get-default-zone
firewall-cmd --get-active-zones

If the default zone is not set to drop we can set it by executing the following:

firewall-cmd --set-default-zone=drop

Now lets see what services, if any, the drop zone is allowing:

firewall-cmd --zone=drop --list-services

We see it is not allowing anything, good. This is good but we need to allow ssh from our hosts so we can use the system. The limit we established above with hosts.allow is all we want the firewall to allow. To do this we will have to create rich rules for the firewall based on what you did above. If you added a single IP exception to hosts.allow the rich rule would look like this:

firewall-cmd --permanent --zone=drop --add-rich-rule 'rule family=ipv4 source address=1.2.3.4 port port=22 protocol=tcp accept'

If you added an entire class c (/24 in cidr notation) your rich rule would look like this:

firewall-cmd --permanent --zone=drop --add-rich-rule 'rule family=ipv4 source address=11.222.1.0/24 port port=22 protocol=tcp accept'

The rule is not deployed in a permanent manner after we add it but is instead added to the runtime rules. We will need to add it to the permanent rules and reload the firewall. To do this we need to just execute the following:

firewall-cmd --reload
firewall-cmd --list-rich-rules

That is all we need to do to get a basic firewall setup that only allows inbound ssh from our IP or net block. To finish up our VPS deployment we should set the hostname and update the system:

hostnamectl set-hostname yourchosenhostname
yum -y update

When yum completes it’s updates you will have an up to date and secure Linux virtual private server. If you have questions feel free to ask them in the comments below. I hope you enjoyed this blog post and the accompanying video, if you did please take a moment and give it a like also consider subscribing to my YouTube channel. I enjoy doing tutorials and how-to’s on cyber security topics and as long as they are popular I’ll keep doing them.

See Ya

References

Some of the links we provide on the site are affiliate links and your use of that link provides this site with needed funding to provide this free content; and we greatly appreciate it! Without your support we could not sustain the site.