Many services nowadays run on servers with different Linux distributions. Compared to server versions of Microsoft operating systems, they are free. They are also generally considered to be more secure, but require deeper knowledge on the part of the system administrator to ensure they are configured correctly. It doesn't matter whether the system runs on your own infrastructure or on cloud solutions from Amazon, Microsoft or others. In this article, I'll give you tips for making your Linux instances more secure. The article also includes practical examples of improving the security of Debian-based operating system distributions.
Automatic installation of updates
Many servers become targets and victims of hacker attacks due to a security gap in the operating system used. Administrators are usually reluctant to update systems, as this can cause more harm than good, as deployed applications may stop working after a system update. However, it is extremely important for keeping the operating system secure and therefore automatic installations should always be enabled, especially on critical systems. If it is necessary to use older versions of operating systems, we recommend that these computers be completely isolated from the network. A few commands are all that is needed to enable automatic updates on a Linux system.
$ apt update && apt dist-upgrade
$ apt install unattended-upgrades
$ dpkg-reconfigure –priority=low unattended-upgrades
By successfully running the above commands, you can turn on automatic system updates and take the first step to improve system security.
Remote access security
The secure SSH communication protocol is commonly used to remotely access and manage Linux servers. It was created as a successor to the older Telnet, which, unlike SSH, transmitted data in unencrypted form. It is considered secure, but is often abused to infiltrate systems. This is due to its improper use, so here I will outline a few ways to increase security when using remote access through this protocol.
It is forbidden to log in remotely with a privileged account (root user)! Login to the remote server should always be done by a user with restricted access. However, this user can be a member of the sudo group, which allows you to perform actions under a privileged user after a successful login. The following commands demonstrate how to create a restricted user for remote login.
$ adduser USERNAME
$ usermod -aG sudo USERNAME
SSH access using cryptographic keys
A username and password are commonly used for remote access. You can use a 30-character complex password and feel relatively secure. However, there is still the possibility that your password is part of the files for dictionary attacks, or it could be that someone simply guesses your password by brute force cracking. So what is the right way to secure remote login? The answer is to use asymmetric cryptography - public and private keys. I do not want to overwhelm you with information about the details of cryptography principles, but to demonstrate its practical use.
In short, it is a mathematically bound pair of a public and private key represented by a string of characters. Imagine that you own a public and a private key. Only you know the private one and everyone else knows the public one. If someone encrypts a message with your public key, that message can only be decrypted with your private key and no other. This ensures the principle of confidentiality, which says that anyone can send you an encrypted message knowing that you are the only one in the world who can read it again. Cryptography has other broad uses, but I'll save those for future articles.
The first step is to create your own key pair and then upload your public key to the ~ / .ssh directory on the remote server that manages the public keys of legitimate users. I demonstrate how to perform this action again on the commands below.
$ ssh-keygen -b 4096
$ scp ~/.ssh/id_rsa.pub USERNAME@SERVER: ~/.ssh/authorizer_keys
At this point, the server will never ask you for a login password again, because it will instead authenticate with a 4096 bit long cryptographic key! This gives you a much higher level of security and eliminates the need to remember passwords.
However, other users can still log in with a username password, so disable this option in the next step. Privileged users are still allowed to log in and the SSH service runs on the default port, which is well known to all hackers. To fix these flaws, just edit the following in the /etc/ssh/sshd_config file:
After saving the changes and restarting the SSH service, the server is almost ready for real use. You can test the changes by trying to log in. The remote server should not require an input password and you should be able to access its environment securely.
$ ssh USER@SERVER -p PORT
The last step is to properly set up firewall rules to secure the entire outer perimeter and allow only the desired incoming and outgoing communications. First, look at what open ports of the operating system you have in use.
$ ss –tupln
Install the uncomplicated firewall (ufw) and enable communications on the port you have chosen for the SSH service. Enable the firewall to start when the operating system boots and finally look at the list of rules used.
$ apt install ufw
$ ufw allow PORT
$ ufw enable
$ ufw reload
$ ufw status
It is also good practice to suppress ICMP so that the server will not respond to attempts to determine its availability (ping). This hides the existence of the server from eyes that would want to detect it quickly and easily. To do this, add the following line to /etc/ufw/before.rules before the block of rules governing ICMP communication behaviour and then restart the firewall.
-A ufw-before-input -p icmp –icmp-type echo-request -j DROP
$ sudo ufw reload
If you have successfully completed the steps described in this article, you have done what is needed to secure your Linux server instances. Note that the syntax of the commands demonstrated may vary depending on the Linux distribution used, but the principles of these security mechanisms remain the same. Therefore, you have achieved a secure method of remote login and have gained control over the data traffic flowing through the secure server.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.