Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Julien DUMUR
Infrastructure in a Nutshell

An SSH access is a privileged entry point for hackers. Today I am offering you a guide that will allow you to strengthen the security of your SSH accesses, to reduce the attack surface, in order to make them much more difficult to attack.

Don't try this at home

The technical indications given in this article are intended to restrict access to your server. Make sure you have temporary secondary access to check that the configurations you have put in place have not cut off all your access! I recommend that you experiment on a test server before doing it in production.

To start modifying the file (to be adapted to your editor) :

vi /etc/ssh/sshd_config


Reminder: to activate each of these configurations, a restart of the SSH service is necessary.

Modify the SSH default port

Modifying the default port makes it possible to get rid of all the scripts that test the default ports to discover breaches to open on our system. It is therefore relevant to modify it with a randomly chosen port.

Port 8645

Disable Passwordless Authentication

This is one of the essential rules in computer security: an account without a password must not be able to identify itself remotely on the system!

PermitEmptyPasswords no

Disable authentication as root

Like disabling passwordless authentication, the root account should not be able to log in remotely.

PermitRootLogin no

Restrict access to defined users or groups

Based on the principle of least privilege, the restriction by user or by user group makes it possible to perfectly control the accounts authorized to connect to the server without having to systematically edit the configuration file (less manipulation, less risk of errors ).

AllowUsers user1 user2 ...
AllowGroups group1 group2 ...

Set the lifetime of an inactive session

Cutting inactive connections or connections whose client has not responded for some time is also a parameter to be modified downwards in order to disconnect inactive users. In general, I put a disconnection after 1200s (20min) of inactivity. Here are the settings to apply:

ClientAliveInterval 1200
ClientAliveCountMax 0

Every 1200s, the server will send a test message to the client to know if it is still active. If the client is idle, it increments the ClientAliveCount by 1. When the value of ClientAliveCountMax is reached, the client is considered idle and the session disconnected.

Set authentication timeout

The almost systematic use of remote connection tools reduces the time required to establish the SSH connection to a few seconds. This parameter is not necessarily essential but personally I reduce the delay to 20 seconds.

LoginGraceTime 20

Disable use of SSHv1 and force use of SSHv2

Imperative to force a greater level of security.

Protocol 2

Disable X11 forwarding

Potential vector of attacks if the server is corrupted, it is necessary to deactivate it.

X11Forwarding no

Disable SFTP subsystem

Frequent attack vector, if you do not use the FTP layer of SSH I invite you to deactivate it. Just comment out the line.

#Subsystem sftp /usr/lib/openssh/sftp-server

Protection against brute force hacking attempts

Considering the fact that we almost always use login software with saved parameters, it is possible to reduce the number of failed attempts before blocking enormously.

MaxStartups 5:30:20

5: Number of connection attempts from which the server begins to refuse connections.

30: Percentage of chance that the server automatically refuses the connection once the 5 attempts have been reached (increments by 10 in 10).

20: Maximum number of failed attempts from which the server blocks everything.

The final word

Here is already a good series of modifications to be made to properly secure your SSH server.

Another approach is also to secure all open ports on your server via third-party tools such as PortSentry, FailtoBan, log auditing, etc.

There is also a great way to protect SSH to deal with: authentication using a private key. This configuration, which is a bit long and tedious, will be the subject of a future article.

0 comments

Leave a Reply