Protect VPS with FAIL2BAN and IPTABLES
11:05, 03.12.2021
When a server connects to the network, it will inevitably be attacked by bots written by hackers with the sole purpose of finding vulnerabilities in the VPS protection. Scanning by bots - it's like a test for the young soldier, and if your server passes this test successfully, then in the future you can sleep well. If you find a vulnerability - wait for trouble, because the bots will immediately report it to the hackers, and then everything will depend on human error. In this article we will describe how you can protect VPS or VDS with two simple but very effective tools:
- A local Fail2ban service that tracks the logs of all running processes on the server.
- IPTABLES utility. To be more precise, with a netfilter firewall, but we need this utility only for its configuration and control. It is built into the kernel of all UNIX like systems using the Linux kernel 2.4 or later. In general, no installation is required.
But first, it is worth taking some preparatory steps.
Moving the SSH server to another port
And our first step is to move the SSH server to a more secure port. The default is the standard 22 port, and it is considered insecure. Therefore, log in as a root user, find the configuration file and make a backup so that in case the modification fails, you can rollback the changes:
# sudo cp /etc/ssh/sshd_config
/etc/ssh/sshd_config.factory-defaults
Now open the configuration file for editing:
# sudo vi /etc/ssh/sshd_config
Here, the default port must be replaced with a more complex port, preferably using a 5-digit number. For example, 57481 - in this case, we have a fairly complex port, which includes 5 digits of different denominations. Do not use a port with five identical digits, as bots scan them first.
Our next step in the same file is to disable authentication for superusers and add SSH key logon capability. To do this, find and change the parameters:
- PermitRootLogin – replace with NO;
- PubkeyAuthentication – replace with YES.
Then we reboot the server and reconnect but through a new port. In this example, the command would look something like this:
ssh user@host -p 57481
Now let's explain why this is done. Many administrators are convinced that in order to protect VPS it is enough to switch to authorization by keys and install Fail2ban, and after that the server allegedly will be impenetrable. Switching to a non-standard port is an important procedure that allows you to use standard ports as bait for bots, and thanks to them, your server will be able to detect attempts to scan and block IP-addresses, where the scanning is done. Of course, experts recommend that you specify white addresses so that you don't accidentally get blocked. It turns out that changing the port to a non-standard one makes it much more difficult to hack your system and increases the cost of information collection. If set up properly, it may take an attacker months of uninterrupted scanning, and if the hacker does not know your SSH port in advance, he will not be able to exploit it even if vulnerabilities are detected. Therefore, this recommendation should not be ignored.
Closing all ports except SSH, HTTP, HTTPS
If your server is used only for web hosting, you must close all but three third-party ports:
- 80 (HTTP) and 443 (HTTPS) – they are used by the browsers of live people, visitors to your site.
- SSH – in your case, the port number will be the one you choose when you migrate SSH, a matter we covered in detail above. The port itself will be used exclusively by the server administrator.
So, the algorithm is as follows: first, we create a file with the iptables rules:
sudo touch /etc/iptables.firewall-rules
The contents of the file must be placed inside for the firewall to work properly:
#!/bin/bash
IPTABLES=/sbin/iptables
#start and flush
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -X
$IPTABLES -P FORWARD DROP
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT ACCEPT
#SSH traffic
$IPTABLES -A INPUT -p tcp --dport 57481 -j ACCEPT
#HTTP traffic
$IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT
#HTTPS traffic
$IPTABLES -A INPUT -p tcp --dport 443 -j ACCEPT
#loopback
iptables -A INPUT -i lo -p all -j ACCEPT
This is just a possible way to write a script, and if you yourself have the necessary knowledge of programming, then you can easily write your own rules, individually adapting the firewall to the needs of a VPS or VDS.
Dynamic protection with Fail2ban
The Fail2ban service is not always part of the base set of system utilities, so it needs to be installed first. You can download it from any official repository. If you have a server running Debian or Ubuntu, the command to install is
# apt-get install fail2ban
If CentOS, Fedora or RHEL, the command looks a little different:
# yum install fail2ban
It is recommended that you create a backup of the configuration file so that you can roll back the state of the utility to its original state if necessary.
Once you install the utility, your SSH server will already have basic protection against trivial key sniffing, but experienced admins know that this is not enough. The program contains two basic configuration files:
- /etc/fail2ban/fail2ban.conf - contains the parameters for starting the process.
- /etc/fail2ban/jail.conf - contains security parameters for specific services, including SSHD.
The second file is divided into several sections, called isolators. Each of these sections is responsible for specific services and types of attacks.
Parameters written to section [DEFAULT] are automatically applied to all sections unless you override them manually. Section [SSH] contains parameters for SSH protection against repeated failed attempts - this is the element that guarantees protection against password brute-forcing. In this simple way, we weed out the most primitive, but very annoying pests.
Now let’s talk in detail about the parameters of the jail.conf configuration file:
- ignoreip — these are the IP addresses that do not need to be blocked. Here you can enter as many addresses as you like, separated by a space, and specify the subnet mask and DNS name.
- bantime — the duration of the ban, specified in seconds and assigned to the IP addresses that attempted unsuccessful authorization. After this time has elapsed, the IP address is removed from the banlist.
- maxretry — this parameter defines the number of allowed suspicious actions, after which the rule will be applied. In our case, suspicious actions are unsuccessful authentication attempts.
- enabled — If true, it means that the section is active. If false, the isolator is disabled.
- port — here we write the port on which the target service is running. As we noted earlier, the standard SSH port is 22. If you have changed it to a non-standard, then write it here. Also here you can write his alphabetical designation - ssh.
- filter — is the name of the filter with regular expressions used to detect "suspicious matches". The file /etc/fail2ban/filter.d/sshd.conf is for the sshd filter.
- logpath — is the address of the log file used by Fail2ban to filter based on the parameters specified earlier. This will contain the log of all successful and unsuccessful authentication attempts. The file itself is located at /var/log/auth.log.
And now give some recommendations on how to set it all up properly and prepare for work and defense:
- Do not leave the default address 127.0.0.1/8 on the ignoreip list, as it will become a security vulnerability - if a hacker manages to access any shell account, he can run some bruteforce to attack root or other users from the same server in no time;
- Do not change the main jail.conf file, better to use a file with the extension .local - these are automatically connected and have higher priority;
- maxtry parameter is best set to 5.
After configuring, you should restart the utility and everything will work. If you want more information on Fail2ban documentation and setup, we recommend visiting the official Wiki dedicated to the tool.
As a conclusion
After all these manipulations, your server will become much less "trusting" to malicious programs and bots. It will stop reacting to packets coming on any ports other than HTTP, HTTPS, and SSH port, which we configured with iptables. Now your server can distinguish the bad from the good and the bad will definitely get banned. You can consider that Linux-host protection is of the highest quality now and it will be very difficult to break into such a VPS. And if you still have questions - call or leave a request on the site, our experts will advise you and help to solve any problem.