STEP 5:HOW TO SECURE YOUR VPS
Last updated
Last updated
It's very important to secure your VPS against malicious attacks. To do this, we will implement in this chapter tools that will increase the level of security.
First of all, it is very important to run these two commands as regularly as possible to keep your system up to date.
Secondly, it is very important that your SWT node is shutted down while you follow this safety steps. It's also recommanded to do this actions before setting the node or at least, to have a backup of json file and Nodepublic and Nodeprivate files.
This part will explain how to change the default SSH port in your Linux VPS. By default, the SSH is listening on port 22. This change of the SSH port will add an extra layer of security and will stop many attacks.
You have to choose a port between 49151 and 65535 (those are dynamic/private ports and can be used).
Let’s assume that we are going to use the port 49999. To check if that port is used, type the following command:
If the port is not used, you should not get any results:
That means that the port is free. But if you type the same command with the port 17812 for example, you could get this result (it might depend on your VPS configuration though):
You can see that the port 17812 is LISTENING.
Now, we can edit the SSHD configuration port in order to assign the new port selected.
Uncomment this line (by removing #) and change 22 by 49999.
It should looks like this:
Save changes by CTRL+X, type Y and then ENTER. By security, open again your SSHD_Config file to see if the changes are saved (very important, otherwise you take the risk to loose the connectivity to your VPS for good).
Restart the SSH service to switch over to the new port 49999:
That’s ok. The new ssh port is now set to 49999.
You can see the change by using the netstat commands. Port 22 is unused and 49999 is listening.
First of all, using a strong password to connect to your VPS is very important. Typically, Fail2Ban looks for repeated attempts to log unsuccessful log files, and proceeds to a ban by adding a rule to the IP tables firewall to ban the IP address of the source.
Fail2Ban is not really a security tool. The main goal is to avoid overloading the system logs with thousands of login attempts. A server with SSH access on the standard port, for example, will receive very quickly hundreds or even thousands of connection attempts from different machines. These are usually brute force attacks launched by bots.
Fail2Ban, by analysing the logs, makes it possible to ban the IP after a certain number of attempts which will limit the filling of the logs and the use of the bandwidth. But this does not improve the security of the service concerned. If the SSH access is not secure enough (weak password for example), Fail2Ban will not prevent an attacker from getting his way.
This file is empty, paste the following lines and save changes by CTRL+X, type Y and then ENTER. To be sure, open again your Jail.local file to see if the changes are saved by running the same command and by exiting with CTRL+X.
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1
findtime = 600
bantime = 3600
maxretry = 5
Ignoreip: Fail2Ban will ignore the IPV4 and IPV6 of the localhost.
Findtime: time interval within the retry are counted.
Bantime: these rules will ban IP address for one hour.
Maxretry: maximum number of wrong attempts
That means that an IP address who try to connect with a wrong password a maximum of 5 times (maxretry=5), within 10 minutes (findtime=600 sec) will be banned for one hour (bantime=3600).
Two-Factor Authentication (2FA) is an additional security measure that you can use on your VPS. Beyond from entering username and password, connecting to your server via SSH will require to enter a token from the Google Authenticator app.
You will need to install the Google Authenticator app on your mobile phone at first. Once done, follow these instructions:
Connect to your VPS using PuTTY (not with Tmux, as there are issues with GA options display). Then run the following commands:
Now, we need to generate a Time-Base On-Time Password. Type the following command and then put your window in full screen:
Take notice of your secret key and of your emergency scratch code.
Scan the QR code with your smartphone within the Google authenticator app.
Answer YES to the following questions:
- Do you want me to update your "/home/swt/.google_authenticator" file? (y/n)
- Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n)
- In order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. This allows for a time skew of up to 30 seconds between authentication server and client. If you experience problems with poor time synchronization, you can increase the window from its default size of 3 permitted codes (one previous code, the current code, the next code) to 17 permitted codes (the 8 previous codes, the current code, and the 8 next codes). This will permit for a time skew of up to 4 minutes between client and server. Do you want to do so? (y/n)
- If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting? (y/n)
We need to configure the /etc/pam.d/sshd file in order to allow user to connect using 2FA through SSH.
Add the line ‘auth required pam_google_authenticator.so’ at the end of the file:
Then press CTRL+X, Y and ENTER.
Now open the SSH config file to enable this way of authentication:
Then change the value of the line:
‘ChallengeResponseAuthentication’ from no to yes:
Save changes by CTRL+X, type Y and then ENTER.
Restart the SSH service:
Quit your SSH session and connect again. You will see that the password is asked at first and then a 2FA code is generated by your Google Authenticator on your smartphone.
And one last cool thing is that FileZilla will also ask you a 2FA code after entering your password to connect through SFTP!
VPS are constantly attacked by automated bots. In the case of Linux VPS, they try (in almost all cases) to penetrate as root users via SSH port 22 by means of brute force attacks.
We have changed the SSH port number in a previous security point. Most bots trying to penetrate SSH as root, we will now disable SSH access for the user ROOT.
Your VPS is now no longer accessible via SSH as a root user!