SSH is pretty secure, especially if you take reasonable precautions like requiring key pair based authentication. However, there are still many bots in the wild that try to find vulnerable hosts by trying to log in with common compromised usernames and passwords such as root / root or admin / admin. While they are unlikely to be successful, they will still use your bandwidth and generate massive amounts of logs.
One way to minimize brute force login attempts is to change the default port that SSH listens on. However, this is not considered good practice - first, remember that every time they connect to the server, they should set the correct port, other than the default. Moreover, it can create another security vulnerability if the selected port is greater than 1024. Usually, only root can bind to port numbers below 1024. However, if a higher port number is used for SSH, under certain circumstances users without root access can replace the SSH daemon with another possibly a malicious service.
The best way to solve this problem is to use a tool that will block an attacker from accessing the SSH server. One such widely used tool is fail2ban ( www.fail2ban.org ). By analyzing the logs, fail2ban detects repeated failed authentication attempts and automatically sets firewall rules to discard traffic originating from the attacker's IP address.
Install fail2ban on Ubuntu
Manual Installation
Installing fail2ban on Ubuntu (and other Debian based distributions) is very simple:
$ sudo apt install fail2ban
Checking how it works
You can check if the service is running with the following command:
$ sudo systemctl status fail2ban
The output should look like the following - the service status should be active:
● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2021-05-18 12:36:36 ***; ** min ago
Docs: man:fail2ban(1)
Process: 723*** ExecStartPre=/bin/mkdir -p /run/fail2ban (code=exited, status=0/SUCCESS)
Main PID: 723*** (f2b/server)
Tasks: 5 (limit: 38293)
Memory: 18.0M
CGroup: /system.slice/fail2ban.service
└─723488 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
Let's see how fail2ban changed the iptables rules:
$ sudo iptables -L -n -v
You should also see that there is a new f2b-sshd chain in the iptables configuration that is referenced by the INPUT chain rule:
Chain INPUT (policy ACCEPT 73411 packets, 6622K bytes)
pkts bytes target prot opt in out source destination
1019 65297 f2b-sshd tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22
Chain f2b-sshd (1 references)
pkts bytes target prot opt in out source destination
8 480 REJECT all -- * * 94.191.93.46 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 77.50.75.162 0.0.0.0/0 reject-with icmp-port-unreachable
10 600 REJECT all -- * * 51.254.143.190 0.0.0.0/0 reject-with icmp-port-unreachable
10 600 REJECT all -- * * 46.101.97.5 0.0.0.0/0 reject-with icmp-port-unreachable
9 540 REJECT all -- * * 43.129.28.88 0.0.0.0/0 reject-with icmp-port-unreachable
9 540 REJECT all -- * * 41.221.168.167 0.0.0.0/0 reject-with icmp-port-unreachable
9 540 REJECT all -- * * 35.247.219.12 0.0.0.0/0 reject-with icmp-port-unreachable
12 720 REJECT all -- * * 220.180.119.192 0.0.0.0/0 reject-with icmp-port-unreachable
10 600 REJECT all -- * * 218.75.121.75 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 213.87.101.176 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- * * 192.139.15.34 0.0.0.0/0 reject-with icmp-port-unreachable
21 1260 REJECT all -- * * 187.104.145.210 0.0.0.0/0 reject-with icmp-port-unreachable
8 480 REJECT all -- * * 177.191.189.13 0.0.0.0/0 reject-with icmp-port-unreachable
10 600 REJECT all -- * * 159.89.82.134 0.0.0.0/0 reject-with icmp-port-unreachable
10 600 REJECT all -- * * 159.75.140.97 0.0.0.0/0 reject-with icmp-port-unreachable
8 480 REJECT all -- * * 157.92.13.105 0.0.0.0/0 reject-with icmp-port-unreachable
11 660 REJECT all -- * * 117.80.225.245 0.0.0.0/0 reject-with icmp-port-unreachable
9 540 REJECT all -- * * 106.53.121.179 0.0.0.0/0 reject-with icmp-port-unreachable
865 56057 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
The fail2ban package contains a tool called fail2ban-client. It allows you to check the status of a service and interact with it (for example, it allows you to manually block and unblock IP addresses, enable and disable jails, etc.)
Let's see which jails are active:
$ sudo fail2ban-client status
Status |- Number of jail: 1 `- Jail list: sshd
There is only one jail - sshd - which sq is responsible for monitoring the SSH server logs for failed login and configuring firewall rules to block further attempts.
Now we can check the statistics for the sshd jail:
$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 8
| |- Total failed: 26
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 22
|- Total banned: 25
`- Banned IP list: 106.53.121.179 117.80.225.245 157.92.13.105 159.75.140.97 159.89.82.134 177.191.189.13 187.104.145.210 213.87.101.176 218.75.121.75 220.180.119.192 35.247.219.12 41.221.168.167 43.129.28.88 46.101.97.5 51.254.143.190 77.50.75.162 94.191.93.46 1.55.165.141 120.53.245.68 104.131.178.145 106.56.102.83 152.32.146.21
Configuring fail2ban
In most cases, the default configuration should be sufficient. However, it is helpful to understand what these defaults are and how they can be changed to suit your needs.
In a standard configuration, fail2ban will protect the SSH server and block the attacker for 10 minutes after 5 failed login attempts within 10 minutes. The default config file can be found at /etc/fail2ban/jail.conf. The file is well documented and mostly self-explanatory. Please note that you should not make any changes to this file as it may be overwritten during fail2ban update.
After changing the configuration, don't forget to restart the service:
$ sudo systemctl restart fail2ban
I should note that in this case, I changed the configuration parameters, understanding the attack strategy and received a daily list of attacking hosts and blocked it.
But I'll talk about this later in a separate note, if this one is useful and interesting to someone.