Habib M’henni / Wikimedia Commons, CC BY-SA
Nowadays, raising a server on a hosting is a matter of a couple of minutes and a few mouse clicks. But right after launch, he finds himself in a hostile environment, because he is open to the entire Internet like an innocent girl in a rocker disco. It will be quickly groped by scanners and will detect thousands of automatically scripted bots that scour the network for vulnerabilities and misconfigurations. There are a few things to do right after launch to provide basic protection.
- Non-root user
- Keys instead of SSH passwords
- Automatic security updates
- Changing the default ports
The first step is to get yourself a non-rooted user. The point is that the user has
root absolute privileges in the system, and if you allow him remote administration, then you will do half the work for the hacker, leaving a valid username for him.
Therefore, you need to create another user, and for root, disable remote administration via SSH.
A new user is created by the command
useradd [options] <username>
Then a password is added for it with the command
Finally, this user needs to be added to a group that has the right to execute commands with elevated privileges
sudo… Depending on the Linux distribution, these can be different groups. For example, in CentOS and Red Hat, the user is added to the group
usermod -aG wheel <username>
On Ubuntu, it is added to the group
usermod -aG sudo <username>
Keys instead of SSH passwords
Brute force or password leakage is a standard attack vector, so it is better to disable SSH (Secure Shell) password authentication and use key authentication instead.
sudo apt install openssh-client
Installation on the server:
sudo apt install openssh-server
Running the SSH daemon (sshd) on a server running Ubuntu:
sudo systemctl start sshd
Starting the daemon automatically on every boot:
sudo systemctl enable sshd
It should be noted that the server side of OpenSSH includes the client side. That is through
openssh-server you can connect to other servers. Moreover, from your client machine, you can launch an SSH tunnel from a remote server to a third-party host, and then the third-party host will consider the remote server as the source of requests. A very handy feature for disguising your system. For more details see the article “Practical Tips, Examples, and SSH Tunnels”…
On the client machine, it usually makes no sense to install a full-fledged server in order to prevent the possibility of remote connection to the computer (for security purposes).
So, for your new user, you first need to generate SSH keys on the computer from which you will log into the server:
ssh-keygen -t rsa
The public key is stored in a file
.pub and looks like a string of random characters that start with
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ3GIJzTX7J6zsCrywcjAM/7Kq3O9ZIvDw2OFOSXAFVqilSFNkHlefm1iMtPeqsIBp2t9cbGUf55xNDULz/bD/4BCV43yZ5lh0cUYuXALg9NI29ui7PEGReXjSpNwUD6ceN/78YOK41KAcecq+SS0bJ4b4amKZIJG3JWm49NWvoo0hdM71sblF956IXY3cRLcTjPlQ84mChKL1X7+D645c7O4Z1N3KtL7l5nVKSG81ejkeZsGFzJFNqvr5DuHdDL5FAudW23me3BDmrM9ifUmt1a00mWci/1qUlaVFft085yvVq7KZbF2OP2NQACUkwfwh+iSTP username@hostname
Then, from under the root, create an SSH directory on the server in the user’s home directory and add the public SSH key to the file
authorized_keysusing a text editor like Vim:
mkdir -p /home/user_name/.ssh && touch /home/user_name/.ssh/authorized_keys
Finally, set the correct file permissions:
chmod 700 /home/user_name/.ssh && chmod 600 /home/user_name/.ssh/authorized_keys
and change ownership to this user:
chown -R username:username /home/username/.ssh
On the client side, you need to specify the location of the secret key for authentication:
Now you can log into the server under the username using this key:
After authorization, you can use the scp command to copy files, the utility sshfs to remotely mount a file system or directories.
It is advisable to make several backups of the private key, because if you disable password authentication and lose it, then you will not have any way to log into your own server at all.
As mentioned above, you need to disable authentication for root in SSH (for this reason, we started a new user).
On CentOS / Red Hat we find the line
PermitRootLogin yes in the config file
/etc/ssh/sshd_config and change it:
On Ubuntu add the line
PermitRootLogin no to config file
sudo echo "PermitRootLogin no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf
After verifying that the new user is authenticated using their key, you can disable password authentication to eliminate the risk of password leakage or brute-force. Now, to access the server, an attacker will need to get a private key.
On CentOS / Red Hat we find the line
PasswordAuthentication yes in the config file
/etc/ssh/sshd_config and change it as follows:
On Ubuntu add the line
PasswordAuthentication no to file
sudo echo "PasswordAuthentication no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf
For instructions on connecting two-factor authentication over SSH, see here…
The firewall ensures that only the traffic on the ports that you directly allow will go to the server. This protects against exploitation of ports that accidentally join with other services, that is, greatly reduces the attack surface.
Before installing the firewall, you need to make sure that SSH is included in the list of exceptions and will not be blocked. Otherwise, after starting the firewall, we will not be able to connect to the server.
Allow SSH in firewall on Ubuntu:
sudo ufw allow ssh
On CentOS / Red Hat use the command
sudo firewall-cmd --zone=public --add-service=ssh --permanent
After this procedure, you can start the firewall.
On CentOS / Red Hat, start the systemd service for firewalld:
sudo systemctl start firewalld sudo systemctl enable firewalld
On Ubuntu, use the following command:
sudo ufw enable
Service Fail2Ban analyzes the logs on the server and counts the number of access attempts from each IP address. The settings specify the rules for how many access attempts are allowed within a certain interval – after which the given IP address is blocked for a specified period of time. For example, we allow 5 unsuccessful SSH authentication attempts within 2 hours, after which we block this IP address for 12 hours.
Installing Fail2Ban on CentOS and Red Hat:
sudo yum install fail2ban
Installation on Ubuntu and Debian:
sudo apt install fail2ban
systemctl start fail2ban systemctl enable fail2ban
The program has two configuration files:
/etc/fail2ban/jail.conf… The ban limits are specified in the second file.
Jail for SSH is enabled by default with default settings (5 attempts, interval 10 minutes, ban for 10 minutes).
[DEFAULT] ignorecommand = bantime = 10m findtime = 10m maxretry = 5
In addition to SSH, Fail2Ban can protect other services on the nginx or Apache web server.
Automatic security updates
As you know, new vulnerabilities are constantly found in all programs. After the information is published, exploits are added to popular exploit packs, which are massively used by hackers and teenagers when scanning all servers in a row. Therefore, it is very important to install security updates as soon as they appear.
The Ubuntu server has automatic security updates enabled by default, so no further action is required.
On CentOS / Red Hat you need to install the application dnf-automatic and turn on the timer:
sudo dnf upgrade sudo dnf install dnf-automatic -y sudo systemctl enable --now dnf-automatic.timer
sudo systemctl status dnf-automatic.timer
Changing the default ports
SSH was developed in 1995 to replace telnet (port 23) and ftp (port 21), so the author of the program Tatu Iltonen chose port 22 by defaultand it was approved by the IANA.
Naturally, all attackers are aware of which port SSH is running on – and scan it along with the rest of the standard ports to find out the software version, to check the standard root passwords, and so on.
Changing standard ports – obfuscation – several times reduces the volume of junk traffic, the size of logs and the load on the server, and also reduces the attack surface. While some criticize this method of “protection through obscurity” (security through obscurity). The reason is that this technique is opposed to a fundamental architectural protection… Therefore, for example, the US National Institute of Standards and Technology in Server Security Guide indicates the need for an open server architecture: “The security of the system should not rely on the secrecy of the implementation of its components,” – said in the document.
In theory, changing the default ports is against open architecture practice. But in practice, the volume of malicious traffic does decrease, so this is a simple and effective measure.
The port number can be configured by changing the directive
Port 22 in the config file / etc / ssh / sshd_config… It is also indicated by the parameter
-p <port> at sshd… SSH client and programs sftp also support the parameter
-p <port> can be used to specify the port number when connecting using the command
ssh on Linux. AT sftp and
scp parameter is used
-P <port> (capital P). Specifying from the command line overrides any value in the configuration files.
If there are many servers, almost all of these actions for securing a Linux server can be automated in a script. But if there is only one server, then it is better to manually control the process.
Order and work immediately! VDS creation any configuration and with any operating system within a minute. The maximum configuration will allow you to come off to the full – 128 CPU cores, 512 GB RAM, 4000 GB NVMe. Epic 🙂