Basic Practice for Server Security

On the Internet, thousands of Servers are vulnerable and misconfigured out there not well maintained and patched. As a server maintainer, SysAdmins needs to configure the system well to tackle the security breach which is happening on hundreds of servers on the internet.

Setting up a secure Base System

Before moving any other part we need to set up our system with some criteria for securing the server. Most of the attacks happen successfully because of the lame standard of servers’ passwords, using unpatched software, giving unwanted access, no logging system, and so on many more.

Password: The first layer of Security

You wouldn't think that a benign-sounding topic such as strong password criteria would be so controversial, also in your entire computer career you heard undoubtedly about the Password:

• Make passwords of a minimum of 8 length of character

• Make passwords that contain minimum of three classes of characters like uppercase letters, lowercase letters, numbers, and special characters

• Ensure that passwords don't contain any words that are found in the dictionary or that are based on the users' own personal data

• Force users to change their passwords on a regular-interval basis

To enforce strong password complexity criteria we can achieve this by pwquality. pwquality module is a newer technology that has replaced the old cracklib module.

sudo apt install libpam-pwquality

to set the complexity criteria you need to make changes in /etc/security/pwquality.conf file.

To set the Minimum acceptable size of password we need to set the parameter of minlen.

minlen = 19

The minimum length setting works on a credit number system.

If you need to require that a password has multiple character types (letters, numbers, and Symbols), it would be better to use the minclass parameter. Value 3 means it requires three different classes of character.

minclass = 3

Now if you gonna set a system password then it's required a minimum of 19 credit length and three class characters.

Enforcing Password Expiration

To Make a Password Expiration policy you need to change some parameters in /etc/login.defs file.

PASS_MAX_DAYS 90

PASS_MIN_DAYS 0

PASS_WARN_AGE 7

• PASS_MAX_DAYS 90 that point on to have a 90-day expiration date.

• PASS_MIN_DAYS 0 means you can change your password anytime

• PASS_WARN_AGE 7 means that it will send you the warning before 7 days of password expiration

Or, If you want to set the expiry date on a per user basis then you can do the same with chage command.

Protect from Bruteforcing

A simple and very powerful attack again the server is Bruteforce(If using Simple Password) on SSH or any other services. we can mitigate this issue by locking the user after many failed login attempts. by using pam_tally2 command.

pam_tally2 - The login counter (tallying) module

pam_tally2 module maintains a count of attempted accesses, it denies the login attempt if anyone tries to login with false credentials and locks the user of the server.

To implement pam_tally2 follow the steps:

you need to add some lines in /etc/pam.d/common-auth file by using your favorite text editor (nano, vim, vi).

auth     required       pam_tally2.so

auth     required       pam_tally2.so file=/var/log/tallylog deny=50 even_deny_root unlock_time=1800

• deny=50 means that the user account under attack will get locked out after only fifty failed login attempts.

• even_deny_root means that even the root user account will get locked if it's under attack.

• unlock_time=1800 means that The account will get automatically unlocked after 1800 seconds or 30 minutes

• file=/var/log/tallylog is a path of the default log file that is used to keep login counts

To verify or check the counter that the user attempts you need to type

sudo pam_tally2 --user=USERNAME

Where USERNAME is the name of the user

You can also use pam_tally2 to manually unlock the account before the time period.

sudo pam_tally2 --user=USERNAME --reset

pam_tally2 doesn't work with su

Securing Important Files/Data

You can set attributes in file permission by using chattr.

sudo chattr +a file.txt

where file.txt is the name of the file

where ‘a’ attribute now you are not able to overwrite the file. now you can’t append something in a file or delete it.

sudo chattr +i file.txt

by using ‘i’ attribute, You can't change, move, delete, rename, and create a hard link to the file.

If you want to revert the permission then run the same command with -a, -i respectively to files.

System Auditing and Vulnerability Scanning

As a System Admin, you need to Audit your system from time to time. and check if anything malicious and unwanted service is running. You can make use of Nmap, Nikto, Nessus, OpenVAS, and many more vulnerability scanners tools for that and patch vulnerable packages.

Securing SSH (the Secure Shell)

SSH is a secure way to access your server from another machine. It creates a secure encrypted tunnel over an unsecured network.

To connect to a server using SSH you need to type something like

ssh [email protected]

where the root is the user and 165.125.254.654 is the IP of the server you are accessing

Disabling SSH PasswordAuthentication login

as many SysAdmins argue regarding SSH Password login is unsecured. So, to disable SSH password login and instead, use SSH keys. To do so, you have to change the parameter of PasswordAuthentication to no in the /etc/ssh/sshd_config file.

# To disable the tunneled clear text passwords, change to no here!

PasswordAuthentication no

But wait is it true that passwords are really insecure? Using SSH Key for login makes your server super secure!!

The simple answer is NO. Both SSH Password Login and SSH Key Login have their issues and limitations. SSH Password Login is not un-secure but you need to set your password complex and long so it can't be Bruteforce easily.

What The Secure Shell (SSH) Protocol Architecture talks about both logins methods.

RFC 4251 - The Secure Shell (SSH) Protocol Architecture

Network Working Group T. Ylonen Request for Comments: 4251 SSH Communications Security Corp Category: Standards Track C. Lonvick, Ed. Cisco Systems, Inc. January 2006 The Secure Shell (SSH) Protocol Architecture Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements.

https://datatracker.ietf.org/doc/rfc4251/

Public Key Authentication

The use of the SSH Key Authentication Method assumes that the client host has not been compromised also assumes that the private key of the server has not been compromised

Password Authentication

The Password Authentication assumes that the server has not been compromised. If the server has been compromised, then using password authentication will reveal a valid username and password combination to the attacker, which may lead to further compromises

So, using passwords is not bad... but standard password recommendations still apply! In this case, you need to implement password policies, here they are:

• use complex passwords (letters, numbers, and symbols) so they can’t be easily Brute-forceable

• don’t use a single password everywhere(in case of multiple servers)

• Change your password frequently(60-90 Days Policy)

You can use password generator tools and password manager. a good password manager generates contain unique, random, and long passwords.

We recommend using SSH Key Authentication, not for security, but rather for convenience. also, it is helpful if you are using a lame password.

Changing the Default SSH Port

You can change the default port of SSH just by changing the Port parameter in the /etc/ssh/sshd_config file. it only might be useful is against the script kiddies and scanners(bots) that only check for default ports and weak SSH passwords. But if the hacking method is through brute-forcing the password, then having a really strong and unique password, or using SSH keys, is how you actually protect yourself!

Port 22

Hiding your insecure entry door might just delay the inevitable "hack"...

Disabling Root SSH login

Another tip we saw come up a lot is to disable the direct root login via ssh. Instead, we should use an unprivileged user without root permission.

Generally, it is always a good practice to use the least amount of privilege required to accomplish a task.

You can accomplish this by setting a parameter in the /etc/ssh/sshd_config file.

PermitRootLogin no

the default setting(in Ubuntu) looks a bit different:

PermitRootLogin prohibit-password

This means that the root user is allowed to log in, but only via an SSH Key Authentication.

But is it a good idea for us to do it on our servers? We use our server to install services and webserver! that all tasks needed root privilege on the server.

Another recommendation that goes hand-in-hand that disable the root users and add an unprivileged user with sudo group Permission so that the user can execute any command with root privilege. Surely user + sudo is different from the root so we're safe using this approach, right? This is not correct. From a security standpoint, these are (almost) the same.

By using sudo capabilities, you basically elevate that user to root. sure, it is not direct elevation to root. But when it comes to security, it’s the same.

If anyone wants to execute any malicious code or program with sudo then simply add some alias in the .bashrc file. when some user attempts to run any command then its triggers malicious code. BOOOM!!

But wait there are some advantages that sudo provides.

• By using sudo you don’t have to distribute the root passwords to everybody. Since all gonna use their own.

• Improve your Auditing capabilities because you’ll be able to see what user is doing with their admin privileges. All logs were saved on /var/log/auth.log file.

• You can limit user access with the sudoers file by just adding the policy.

Securing Server with Firewall

The way basically Firewall works is to block any port(Service). and unblock the one you need an example: ssh, Webservices(apache, Ngnix)

You can achieve this by using ufw(uncomplicated Firewall)

ufw allow ssh

ufw allow 443

You can also check what ports are in use by using the ss or netstat command.

netstat -plunt

now think about it for a second. your server listening up 22, 80, and 443. and you set up a firewall that allows communication on ports 22, 80, and 443, now what did you achieve? exactly Nothing.

They Both are the same But maybe you felt cool you did something with the firewall(inner Peace).

Of course, the Firewall is not useless but you need the right use case so that it can effectively block unwanted connections. For instance, consider a database SQL Server only accepts connections from its frontend server’s IP, then the firewall is effective in blocking out all the non-frontend traffic.

or also you can only accept connections for a service from specific source IPs so that no one unauthorized can connect with it.

Patching Services

You need to keep your packages up to date or the distro itself. If you want to enable an automatic unattended upgrade of the system you need to run the command

sudo dpkg-reconfigure unattended-upgrades

The unattended update is good for the Desktops but not suitable for servers case since it can break things and you’ll have to go in and manually apply fixes and that's terrible.

Also, All updates are not security updates so you need to manually check and update the necessary package that's not distributed to the critical services.

And there are two major cases where automatic updating won't help you.

1. If in software any serious vulnerability is found, OS packages that would be automatically updated might not have the patch ready since it takes time to release the security patch. so, as the SysAdmin person who is responsible for the server, you need to apply the patch yourself.

2. Or maybe you are using your own code which has vulnerabilities or the one you cloned from Git hub. These patches are not covered by system OS automatic updating, so you need to update those patches manually.