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 that 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, In your entire computer career you heard about Passwords:
Make passwords of a minimum of 8 characters in length
Make passwords that contain a 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 the/etc/security/pwquality.conf file.
To set the Minimum acceptable size of the 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 are going to set a system password then it requires 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 points 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 against 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 the 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 the ‘a’ attribute now you are not able to overwrite the file. now you can’t append something to a file or delete it.
sudo chattr +i file.txt
by using the ‘i’ attribute, You can't change, move, delete, rename, or create a hard link to the file.
If you want to revert the permission then run the same command with -a, and -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 scanner 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 root@165.125.254.654
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 an 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 login methods.
RFC 4251 - The Secure Shell (SSH) Protocol Architecture
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 server)
Change your password frequently(60-90 Days Policy)
You can use password generator tools and password manager. a good password manager contains 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 against the script kiddies and scanners(bots) that only check for default ports and weak SSH passwords. But if the hacking method is 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 a webserver! all tasks need 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 it 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 are going to 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 when 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.
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 server cases 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.
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.
Or maybe you are using your own code which has vulnerabilities or the one you cloned from GitHub. These patches are not covered by system OS automatic updating, so you need to update those patches manually.