12 Things to do After Installing a Linux Server

Cloud computing has changed the server scenario drastically. Many platforms are providing free Linux cloud servers and you can deploy your Linux servers in minutes though these cloud platforms.

When you spin up a new server, especially if it is visible on the Internet, it will be immediately available to bad guys scouring exposed servers for misconfigurations and vulnerabilities through their automated bot scripts.

There are a few things you must do after installing Linux server to ensure your server isn't compromised.

Here's a screenshot of what Fail2ban has seen recently on one of my servers.

212 bad login attempts and 6 blocked IP Addresses. All traffic from unauthorized people or scripts trying to log into my server.

A few crucial first steps will help you protect your new server builds from compromise.

Recommended things to do after installing a Linux server to beef up the security

I have considered two of the most popular Linux server distributions here: Ubuntu and CentOS/Red Hat. Please check which Linux you are running.

Most of the advices are generic here and should be applicable to other Linux unless specifically mentioned.

Here are the things I recommend you should check to ensure your Linux server's security. I have provided individual steps but if you want to do it quickly, I have also created a script that you can run quickly on any new server you deploy.

1. Ensure a non-root user is set up

Root is almighty and you don't need the root permissions all the time.

root is also a valid username on almost every Linux system. Meaning if it is enabled for remote authentication, half the attacker's job, obtaining a valid username is done.

Also, if an attacker can get on as root, no further permissions are required to do anything on the system.

For these reasons, it is best to log in as a non-root user and to disable root login for remote access using SSH (explained later).

How to do it?

I am assuming that you are logged in as root on your system.

Add a new user with the useradd command. Replace <username> with a username of your choice.

useradd <username>

Set up a password with passwd command for the newly added user:

passwd <username>

2. Ensure the non-root user has sudo permission

Since you'll be logging into this account remotely using Secure Shell (SSH), you'll want to be able to do privileged activities requiring root access. This means the account must have sudo permissions.

How to do it?

The process for creating sudo user on Ubuntu and CentOS is similar, but the group you'll be adding the user to is different.

You should be logged in as root to preform this step.

On CentOS and Red Hat, the wheel group is the standard group used to give users sudo permissions. Add the user to this group with usermod command:

usermod -aG wheel <username>

Ubuntu uses the sudo group to manage sudo users.

usermod -aG sudo <username>

3. Enabling key based SSH authentication

It is important to have key based authentication for SSH enabled so that it's working when we disable password based authentication.

Cracked, brute forced, or compromised passwords are a very common way for bad actors to gain access to systems. Spear phishing, extremely targeted spam email that coaxes an unsuspecting user into providing credentials, is but one common method of obtaining credentials.

If someone gets your username and password on a system where key-based authentication is enabled and password based authentication is disabled for remote access over SSH, that stolen password will no longer get them access to that server.

By enabling key based authentication and in a later step disabling password based authentication you have greatly reduced your chances of SSH being used against you. This is one of the elementary ways to secure SSH server.

How to do it?

You already have SSH enabled on your server, I presume. What you need to do is to generate SSH keys on your personal computer (from where you'll login to the server).

Once you have the SSH keys, you should add the public key to the authorized_keys on our server for the non-root user.

Attention! Do not lose the ssh keys from your personal computer. Make a backup of these keys. If you disable password-based authentication later and lose the SSH keys, you'll be locked out of your own server.

4. Ensure SSH is allowed through the ufw firewall

Before you enable the firewall on your system, you should make sure that SSH is allowed. Otherwise, you might be locked out of your system if you are accessing it remotely.

How to do it?

Ubuntu uses Uncomplicated Firewall (ufw), and CentOS/Red Hat uses firewalld.

On CentOS/Red Hat, use the firewall-cmd command:

sudo firewall-cmd --zone=public --add-service=ssh --permanent

On Ubuntu, use the ufw command like this:

sudo ufw allow ssh

5. Enable firewall (only after allowing SSH)

A firewall ensures only traffic you specifically permit can flow into your server. If a bad actor gets malware on your server and tries to have it communicate over a port that isn't allowed, or if a service is accidentally enabled, it can't be used to compromise your server or compromise it further.

How to do it?

On CentOS/Red Hat systems, enable the firewalld systemd service:

sudo systemctl start firewalld
sudo systemctl enable firewalld

On Ubuntu, use this command:

sudo ufw enable

6. Set SSH not to display banner

One of the ways an attacker may compromise your server is through bugs in the software running your services. A banner can display information about what version of OpenSSH or operating system you're running. No sense in giving information to the bad guys. Make them work for it!

How to do it?

It is default behavior in CentOS/ Red Hat not to display a banner so no action is needed.

On Ubuntu, you can use:

sudo echo "DebianBanner no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

7. Disable all SSH forwarding

While it is not uncommon for administrators to use SSH forwarding to encrypt traffic that may otherwise pass clear text, if you don't use it, you should turn it off. Forwarding could be used by a bad actor to encrypt traffic so it's harder for you to view, or to get traffic that would otherwise be blocked to pass using an authorized port and service.

How to do it?

On CentOS/Red Hat, add the following to /etc/ssh/sshd_config:

DisableForwarding yes

On Ubuntu, add DisableForwarding yes to the 10-my-sshd-settings.conf file:

sudo echo "DisableForwarding yes" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

8. Disable root login over SSH

There's a root user on almost every Linux system. The risks of allowing that account to use SSH are twofold.

1. The username is known and frequently tried by bad guys.
2. If an attacker gets in as root, she has full system access.

Disabling the use of the root account for SSH connections negates both risks.

How to do it?

On CentOS/Red Hat, find the line PermitRootLogin yes in /etc/ssh/sshd_config and change it to:

PermitRootLogin no

On Ubuntu, add PermitRootLogin no to the 10-my-sshd-settings.conf file:

sudo echo "PermitRootLogin no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

9. Disable password-based SSH authentication

Before disabling password authentication in SSH, make sure that you have key-based authentication configured and tested as mentioned in step 3.

Disabling password-based authentication blocks malicious actors who try to guess your password or who have socially engineered you into entering your credentials or stolen them by any means from getting onto your server using SSH.

An attacker has to have your public and private keys to get to your server.

How to do it?

On CentOS/Red Hat, find the line PasswordAuthentication yes in /etc/ssh/sshd_config and change it to:

PasswordAuthentication no

On Ubuntu, add PasswordAuthentication no to the 10-my-sshd-settings.conf file:

sudo echo "PasswordAuthentication no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

10. Ignore rhosts

rhosts is associated with rsh, a legacy protocol superseded by secure shell. If a user attempts to create a malicious rhosts file, this setting explicitly ignores it.

How to do it?

On CentOS/Red Hat, find the line #IgnoreRhosts yes in /etc/ssh/sshd_config and change it to:

IgnoreRhosts yes

On Ubuntu, add IgnoreRhosts yes to the 10-my-sshd-settings.conf file:

sudo echo "IgnoreRhosts yes" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

11. Install fail2ban and configured it to protect SSH

Fail2ban keeps an eye on the log files for configured services like SSH and blocks malicious user's IP Addresses from connecting to your server after a set number of attempts for a set amount of time.

If an attacker makes more than 5 failed attempts in a three-hour period, her IP Address will be blocked for 12 hours, for example.

Fail2ban can be configured to protect other services too such as websites powered by nginx web server or Apache web server.

How to do it?

You can follow our detailed guide on using Fail2Ban.

12. Configure automatic security updates (for Red Hat and CentOS)

As mentioned previously, an outdated service with an exploit can let an attacker get on your server without even having to log in if the vulnerability is serious enough! It is crucial to have security updates applied quickly to reduce this risk.

How to do it?

For a default Ubuntu server installation, automatic security updates are enabled so no action is necessary regarding updates.

To configure automatic updates on CentOS / Red Hat, you'll install an application called dnf-automatic and enable a timer for it using the commands below:

sudo dnf upgrade
sudo dnf install dnf-automatic -y
sudo systemctl enable --now dnf-automatic.timer

You can check timer by running:

sudo systemctl status dnf-automatic.timer

Look for "loaded" under the Loaded: line and "active" under the Active: line.

There may be more or fewer steps depending on your personal taste and what you typically set your servers up to do.

Bonus Script: First 10 Seconds on a Linux Server

As promised, here's the script I wrote that does all the above steps I mentioned after you have a non-root user set up and configured for key-based authentication.

The script can be run on both Ubuntu 20.04 and CentOS/Red Hat 8.

Please note that you should not run random shell scripts downloaded from the internet blindly, no matter how much you trust the source of the script. You must read the script and try to understand what it does.

The entire script is open source and available to everyone and can be viewed here. You may download, read and then run the bash script.

Here's a screenshot after a run on Ubuntu 20.04 server.

See, how easily you can complete some basic steps to secure your new server builds in CentOS, Red Hat, or Ubuntu by running just one script!

You're also welcome to provide feedback on the script or request features.

Conclusion

These are just some of the very basic security checks but something that you must do after installing your Linux server.

Manually doing these things on a number of servers can be painful and unnecessarily time-consuming. This is where you can take advantage of scripting and use my 'First 10 seconds on a Linux server' script or create your own.

These are some of my recommendations. How about you? Do you have something to add to this list? Do provide your suggestion in the comment section.