Fail2ban Frustrates Attackers

The attacker usually leaves password guessing to an automated attack program, which stubbornly processes one entry after the other from a dictionary. You can protect yourself against this kind of attack. Tools such as Fail2ban do not completely prevent dictionary attacks, but they ramp up the time required for the attack to the extent that the attacker usually gives up in frustration.

Fail2Ban consists of a server daemon and a client that interprets the central configuration files fail2ban.conf and jail.conf and sends commands to the server. The program reads one or more logfiles and checks each line with regular expressions. For example, if a defined number of login attempts is exceeded, Fail2Ban can use iptables to block the IP address of the attacker for a configurable time.

You can install Fail2ban with the apt install fail2ban command. Many distributions come with Fail2ban already preconfigured to let you start working with it and protect SSH (and often other services) right after installation without having to move a muscle. You can see whether Fail2ban is working on your system, after a certain wait, by checking the log, in this case /var/log/fail2ban.log (Figure 6).

Figure 6: Fail2ban registers repeated login attempts and blocks the attacker's IP addresses.

If you suspect that this protection is not yet enabled, check the configuration file /etc/fail2ban/jail.conf. You will find a section starting with [sshd]. If this section says enabled=false, change the false to true and restart the service by typing systemctl restart ssh. Fail2ban starts up immediately.

By default, the ban beam hits anyone who generates three login failures in 10 minutes or less. Fail2ban then blocks the incoming IP address for one hour. You can adapt these values to suit your own needs by changing the findtime, maxretry, and bantime parameters in the configuration file.

Mail Me on Login

Intrusion Detection Systems (IDS) are usually complex applications that try to detect and report unusual activities on the system. But you can also go one size smaller. A one-liner (Listing  4) is all you need to keep track of who is logging on to the system and when.

$ echo 'Login on' $(hostname) $(date) $(who) | mail -s "Login on $(hostname) $(who) | awk '{print $5}'" my_email

All you have to do is swap my_email for your actual email address. Then open the /etc/bash.bashrc file and append the one-liner to the file.

You will now receive an email every time a user logs on to the system. You can see the user name and the time of the login. For example, if our test user bob logs on to the influx system, you will receive a message like the one in the example (Figure 7).

Figure 7: Our simple intrusion detection system notifies by email as soon as a user logs in.

Disable Services

Sometimes you try something on a system, play around with it, and then forget it. Forgotten services pose a security risk on exposed systems. It is useful to check from time to time what exactly is running on the system, and specifically, which services can be accessed from outside.

An easy way to check which services are running is the netstat -tlpn command, which you need to call with administrative rights. netstat provides a tabular list of all services and the ports to which they are bound.

On the system shown in Figure 8, for example, InfluxDB is running along with a few other services. netstat shows that this service is open for arbitrary access from the network and listening for requests on port 8086 – showing 0.0.0.0:port_number for IPv4 and :::port_number for IPv6. On a conventional home network, port 8086 would still have to be forwarded from the WLAN router to the computer for the service to be accessible from the Internet.

Figure 8: Netstat can detect active services with ports open to the network.

Let's assume you don't have time to work on InfluxDB right now. You want to disable the service, but leave it installed so that you can continue using it later. To do this, stop InfluxDB with the systemctl stop influx command first. The command is executed, but it does not give you any output. To check that InfluxDB really isn't running anymore, take a look at /var/log/syslog or the Systemd log (Listing 5).

[...]
Jul 18 11:22:37 influx influxd[11322]: ts=2020-07-18T10:22:37.769190Z lvl=info
                msg="Closed service" log_id=0O4MSfDG000 service=subscriber
Jul 18 11:22:37 influx influxd[11322]: ts=2020-07-18T10:22:37.769493Z lvl=info
                msg="Server shutdown completed" log_id=0O4MSfDG000
Jul 18 11:22:37 influx systemd[1]: influxdb.service: Succeeded.
[...]

However, the fact that you have stopped the service now does not mean that it will remain permanently disabled. After a restart, it would start again automatically. You can prevent the service from starting automatically by typing systemctl disable influxdb. This command means that InfluxDB stays in place but no longer launches automatically. To enable the service again, type systemctl enable influxdb.