5 Steps to Secure Your Linux Server

Linux Server Security: 5 Linux Hardening & Security Best Practices

Linux is the most commonly used operating system for web-facing computers, running on nearly 75% of servers. We’ll cover how to make your Linux servers more secure.

Server security describes the software, tools, and processes used to protect a business’ server from unauthorized access and other cyberthreats. It is a key requirement for most system administrators and cybersecurity teams.

Linux security is considered good, based on the operating system’s strong default permissions structure. However, you must still adopt best practices to keep your servers running safely and effectively.

The main thing to take away from this is that you will have to decide for yourself what security protections will be necessary. Before you do this, you should be aware of the risks and the trade offs, and decide on the balance between usability and security that makes sense for you.

Whether your Linux server is running Ubuntu, Debian, or some other distribution, follow these steps to strengthen your Linux server’s default configuration.

STEP 1 – Enable Automatic Updates

You should not hold old, unpatched packages, as these introduce critical vulnerabilities to the system that could be exploited by cybercriminals. To avoid this problem, ensure that your server, or server pool, is updated regularly.

Manual Updates:

				
					sudo apt update
sudo apt dist-upgrade
				
			

Many Linux distributions, notably Ubuntu, are also updated in a rolling distribution cycle with both long-term (LTS) and short-term release versions. Your security teams should consider from the start whether they want to run bleeding edge or stable software on their machines, and configure the appropriate update policies.

The unattended-upgrades package available for Ubuntu, for instance, will poll for updates at a fixed interval and apply them automatically in the background.

Automatic Updates:

				
					apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades
				
			

Now your server will automatically update whenever a new update releases, which now makes your linux server one level more secure from the patches.

STEP 2 – Create a Limited User Account

Linux distributions include a superuser called ‘root’ that contains elevated administrative permissions. Keeping root login enabled can present a security risk and diminish the safety of small business cloud resources hosted on the server, as hackers can exploit this credential to access the server. To strengthen your server security, you must disable this login.

The process of disabling the root account varies depending upon which distribution of Linux you are using – you must first create a new user account and assign elevated (sudo) permissions, so that you will still have a way of installing packages and performing other admin actions on the server. Alternatively, you can assign these permissions to an existing user in order to ensure a secure server login.

Create a User:

				
					adduser {username}

				
			

Add User to the sudo group:

				
					usermod -aG sudo {username}
				
			

Finally, logout of root and login to your new account, since you will be a member of the group sudo you will have permission to run commands that can be run by root only so don’t forget to add sudo before every privileged command you are trying to run, Also don’t forget to disable the ROOT account here’s how to disable it.

Disable root User:

				
					sudo vim /etc/passwd
#change the following line from
root:x:0:0:root:/root:/bin/bash
#to
root:x:0:0:root:/root:/sbin/nologin
				
			

STEP 3 – Enable Security Keys

Passwords are dangerous and secure both at the same time, secure in the sense that it helps protect your server from unauthorized access but it is easy for hackers to gain access to your password so to prevent hackers to get into your server we usually disable password and use security keys for identification.

Public Key authentication is a way of logging into your server using SSH/SFTP account using a cryptographic key rather than a password. If you use very strong SSH/SFTP passwords, your accounts are already safe from brute force attacks. However, using public key authentication provides many benefits when working with multiple developers. For example, with SSH keys you can:

  1. allow multiple developers to log in as the same system user without having to share a single password between them;
  2. revoke a single developer’s access without revoking access by other developers; and
  3. make it easier for a single developer to log in to many accounts without needing to manage many different passwords.

How Public Key Authentication Works ?

Keys come in pairs of a public key and a private key. Each key pair is unique, and the two keys work together.These two keys have a very special and beautiful mathematical property: if you have the private key, you can prove you have it without showing what it is. It’s like proving you know a password without having to show someone the password.
Public key authentication works like this:

  1. Generate a key pair.
  2. Give someone (or a server) the public key.
  3. Later, anytime you want to authenticate, the person (or the server) asks you to prove you have the private key that corresponds to the public key.
  4. You prove you have the private key.

You don’t have to do the math or implement the key exchange yourself. The SSH server and client programs take care of this for you. This is how you can setup security keys for identification and get one step ahead of hackers.

Create the Public Key Directory on your Linux Server:

				
					mkdir ~/.ssh && chmod 700 ~/.ssh
				
			

Create Public/Private keys on your computer

				
					ssh-keygen -b 4096
				
			

Upload your Public key to the your Linux Server (Using Windows)

				
					scp $env:USERPROFILE/.ssh/id_rsa.pub {username}@{server ip}:~/.ssh/authorized_keys

				
			

Upload your Public key to the your Linux Server (Using mac)

				
					scp ~/.ssh/id_rsa.pub {username}@{server ip}:~/.ssh/authorized_keys
				
			

Upload your Public key to the your Linux Server (Using Linux)

				
					ssh-copy-id {username}@{server ip}

				
			

STEP 4 – Passwords aren’t for us

Once you have your SSH keys configured, you can add some extra security to your server by disabling password authentication for SSH. This will make sure that your server cannot be accessed via password but only via your private key which was created in Step 3. For disabling the password for SSH you need to edit the SSH config file like mentioned below.

Edit the SSH config file:

				
					sudo nano /etc/ssh/sshd_config
				
			

Change the following:

  1. Change Port 22 to Port (any uncommon random port that is not being used)
  2. Change AddressFamily to inet (which only enables server to be accessed via ipv4)
  3. Change PermitRootLogin from Yes to No (cause we aren’t gonna root login now)
  4. Now chnage PasswordAuthentication to No (cause password is for suckers, which makes authorized users to login using security keys only)
  5. save the file and restart SSH service and you’re done, now no one can login to your server without the security key you generated

STEP 5 – Fence It Up !!

So, everything is hackable, but some things are more secure and we want to be on that side right? Definitely a Yes!!!

So one more thing let’s firewall it up or as the title says fence it up so no one’s getting in. So first we want to see what ports are open or what are the holes in my system that could be used by a hacker to get into the server. For this use the following command:

				
					sudo ss -tupln
				
			

So when you run the command do you see a ton of things listed, there might be some ports you don’t want open or maybe things you’re not sure of so google the port number to see what it is for, it maybe for a service you are hosting or require for your server to function, but if you google it and it’s something weird, just uninstall it.

Now we’re gonna get our Fence (the firewall) ready, so to set up our firewall we’re gonna install something called UFW (uncomplicated Firewall) it’s basically a nice frontend to mess with your firewall, cause firewalls can get complex and this is not so complex, so let’s build the Fence.

Install UFW:

				
					sudo apt install ufw
				
			

Before I put my fence up I want to create gates for us to pass through so we have to open some necessary ports and enable the firewall

				
					sudo ufw allow {port number}
sudo ufw enable

				
			

Before I complete this blog there is one last thing I would like to do that is to hide my server from hackers or in simple terms disable ping so my server cannot be found out, so let’s go do that right now.

So all we have to do is add the following line in /etc/ufw/before.rules file and reboot our server and we’re done.

				
					-A ufw-before-input -p icmp --icmp-type echo-request -j DROP

				
			

Alright now you have made your VPS more secure so that hackers can’t get into your server very easily, Thank you for following through my whole blog and hope you have implemented all these steps on your server and will help keep you safe but it’s not full proof, honestly nothing is but you just need to make it more secure and harder.

Written By:

Vedant Agrawal

Founder,LD CLoud

1 Comment

  1. WhitEHat9018 Reply September 6, 2021 - 10:03 am

    For browser privacy I strongly disagree with the recommendations above… Alone they are great but together they interfere with each other and leave gaps in your security. This is noticeable in cookies. I encourage noscript with ad block edge, which is adblock plus before they started selling immunity to advertisers. Privacy badger is decent but not necessary with a strict no script policy. Using Firefox you should go to preferences>privacy>”use custom settings for history” uncheck accept cookies from site and start your own whitelist of what you want to accept and from who. This is a headache at first as you have to fix most website functionality but after established will make for a more secure `privacy` browsing experience.

    if you already have cookies ie the persistent google tracking cookie remove $HOME/.mozilla/’WHATEVERYOURUIDIS’/cookies.sqlite with firefox closed
    doing this will force firefox to recreate the empty cookies.sqlite location with an empty file the next time firefox launces.

    short version:
    1. strict noscript
    2. ad block edge
    3. whitelist cookies ONLY



Leave a Reply