Securing a Linux server

Is your Linux server safe from hackers? Can they get hacked? Freak out about getting your server compromised and getting your data leaked? Take a look at some of the tips you can take to secure and protect your Linux server.
 

1. SSH security

SSH is like a path to connect you to your Linux server. Of course, you will have to secure the passage. Hackers can access your server the same way you access your server.
 

SSH Port

Everyone knows that SSH uses the default port 22 to connect to your server. To avoid letting people know that your SSH is open to connection, change the port so hackers that scan port 22 will not know that your server's SSH is active. The best practice is to change your SSH ports to a different port between 10000 and 32767.
 

To change your SSH ports, edit SSH config

vi /etc/ssh/sshd_config

Find this line

#Port 22

change port value

Port <Random Ports>

Don't forget to restart your ssh server to apply the settings.

systemctl restart sshd

2. SSH Keys

Password can easily get bruteforced, trying keying in your Password in How Secure Is My Password? | Password Strength Checker | Security.org and find out how long does it take for a hacker to crack your password. Scary isn't it?

Now, how about cracking a 4096 bits SSH key? Good luck with that, Mr. Hackers.
 

To set up an SSH key, use the code to generate a rsa 4096 bit key pair

ssh-keygen -t rsa -b 4096

On Windows machine (cmd), this will be

C:\Users\evoxt>ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\evoxt/.ssh/id_rsa):
Created directory 'C:\Users\evoxt/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\evoxt/.ssh/id_rsa.
Your public key has been saved in C:\Users\evoxt/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:RSM1LY13KzUzgSziCz1gLKfTSLs3YtgKBtHdQGdX2SQ evoxt@DESKTOP-DU15VE5
The key's randomart image is:
+---[RSA 4096]----+
| . oo+o ooEO.... |
|. . +o*..o=+B * |
| . . O + ..+ o = |
|. = o +. . . |
|. o o .So . |
|... = o . |
|.. o o . |
| . |
| |
+----[SHA256]-----+
C:\Users\evoxt>

Then, you will have to manually copy the ssh public key to your server ( ~/.ssh/authorized_keys )
 

The formatting will be

ssh-rsa <generated_public_key>

Example:

[root@evoxt .ssh]# cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDPsDZ5LPRriU4wDjZVzSVdqVzWNlaon2WdOm9v1AsAp+9R0u+dyy0YiXcxhF9rjK4bnLc840pw2AiCiQIEwfXS03jVA3b1q1yqCqyiO3WVf+SGuL9m+GXq9hNsRCHznGhhsoi9VbbED5ECMFYoU6SeVucXntEtfR32C8Hnb1eBCICU5GXrZpIqEgqZrnDEVKzMUS/T4HjGGnT4puQDEg++e33HE3z0vr7PXbDW2RR1kIsRdNS0/BfdlPCXf1lA8aAkKWq49rGO5T5PT4+bCDh7aVCS5ouTfL0qJNpyijBudRvHy4DUuzdqNJLEcR4DYZRSXEQsYc+oK+5mjvcGFNQXbx8bQNYyGtERBfAVuWSTsk8oVwRwbo9YIzkMYKyf1GwJvoggKHCsx+s0gHcAo0LSU7BFXVJMS5NY6Zvw6Cv+z/UUokVkTZ/CkTiTJHhVJjzLkeqmFPWbxEWSWED5RUuCnWTmHcV6Fkc3sbUAwp+qRdQgVcGPYigpa8/dsyLWFTbdK1fe5UUeY5C3UbBqr6bItn42tJCNPcu6YpxtfdxDtq/IDWGRsZltM15FEFCrvBGX8JD1z1H3S+j3GjFJtA1iW1cODOV5l+s0sUS64OnY+o0hpsqs2Mie4Xy/zzKg5C071wHIORML1tZq40ZETmwCUXlwmv4shay5cJJm/Ss3qQ==

[root@evoxt ~]#

On a Linux machine, this will be

[root@evoxt ~]# ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:eIS1I1I0YXgvjR9igqAipDp0j3D+CYpyqjuJQ02ugZ8 root@evoxt
The key's randomart image is:
+---[RSA 4096]----+
| o*.. |
|.. .o.+ . |
|+. ...o++ |
|=o.+..=++. |
|* O oo.+S. |
|+o * . .. |
|+++.o . |
|BoE o |
|** |
+----[SHA256]-----+
[root@evoxt ~]#

Then, you can use ssh-copy-id command to install the ssh public key.

ssh-copy-id user@your_server_ip

[root@evoxt ~]# ssh-copy-id [e-mail]
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
The authenticity of host 'xx.xx.xx.xx (xx.xx.xx.xx)' can't be established.
ECDSA key fingerprint is SHA256:umf+E/a0OQe8eRmPdYyCM5kE+ZG/FCC2MEEn2G81dGA.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[e-mail]'s password:
 

Number of key(s) added: 1
 

Now try logging into the machine, with "ssh '[e-mail]'"
and check to make sure that only the key(s) you wanted were added.
 

[root@evoxt ~]#

 

SSH from Specific IP

To allow specific IP to access your server through SSH, configure the firewall only to allow a single IP address to go through the firewall to your SSH port.
 

Make sure you have a static IP before doing this. Else you can get locked out of your server.
 

Disable Password Authentication

Once SSH key authentication has been set up, disable password authentication.

sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config

Then restart SSH service

systemctl restart sshd

3. Automatic updates

Zero-day exploits are attacks that you can't react to. The best thing next is to protect yourself from N-day attacks once the zero-day exploit has been discovered. To protect yourself from N-day attacks, enable automatic updates. Keep in mind that automatic updates can potentially mess things up. To reduce the chances, enable automatic security only.
 

To enable automatic security updates, use this guide.
 

4. Default password

Change your server's default password. Most default passwords are stored in databases and your email inbox. Change them!
 

To change your server's password,

passwd <user>

[root@TEST ~]# passwd root
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[root@TEST ~]#

5. Private Networks and VPNs

Set up a server and connect to your servers through a private network. Private network uses private IP to communicate with each other isolating your servers from the public without any exposure to the public.
 

To set up a private network or a VPN. Take a look at Pritunl. They offer many advanced features such as organization management to separate between Private networks, and it also comes with GUI to easily configure the server.
 

6. Firewall

Set up a firewall to block unnecessary open ports.
 

Most Linux distributions includes Iptables by default.
 

To control your Iptables:

• CentOS/ Fedora uses FirewallD
• Ubuntu/ Debian uses UFW.

To take a look for running programs that are currently using specific ports, use netstat

netstat -tulpn

Also, block ICMP Ping if not required.

With ICMP blocked, hackers have a harder time knowing your server is currently up and running.
 

7. Users

Root access is scary! With root access, the hacker can do almost anything to your servers.
 

Because root access is so powerful, hackers tend to try to crack and brute force root accounts. Hackers will usually stay away from other user accounts if you disable root user access due to the lack of permissions.
 

The most common practice is to block root access through SSH.
 

To disable root access through SSH

vi /etc/ssh/sshd_config

Change PermitRootLogin from yes to no and remove the # comment if there is any
 

#PermitRootLogin yes

to

PermitRootLogin no

Or use this simple command to disable root login.

sed -i 's/#PermitRootLogin yes/PermitRootLogin no/g' /etc/ssh/sshd_config

Don't forget to restart your ssh service to apply the settings.

systemctl restart sshd

Note: Please make sure you have other users account created with sufficient permission to avoid getting locked out of your server.
 

8. Backup

This is not quite related to server security. However, I believe this is super important to be included.
 

It is crucial to have a server backup just in case something goes wrong.
 

When a server is hacked, backup files will be your savior.
 

Store your backup offsite, so the hacker cannot modify or alter your backup files.
 

Luckily for you, all servers under Evoxt will be backup weekly on an offsite server. If you are not using Evoxt yet, consider upgrading!