Fail2ban

Several security measures do not protect your systems from compromise, including security by obscurity (i.e., changing ports), intrusion detection (after the fact monitoring and reporting), and poor password policies (allowing non-complex passwords). The better method for protecting your systems is to implement intrusion prevention measures. Fail2ban [1] is one such solution. It scans logs to check for attacks before they occur and blocks the offending host's access prior to any compromises or break-ins.

Malicious attackers know that passwords are the weakest link in the security chain. They also know that with enough time they can break even the best passwords. Rather than allowing attackers to make attempt after attempt, Fail2ban stops them on their first round of attempts. Any password-protected service such as SSH, FTP, IMAP, POP3, Sendmail, and others are susceptible to brute force and dictionary attacks, because username/password combinations are inherently weak protections.

Fail2ban allows you to set up intrusion prevention monitoring on any service port that uses username/password combinations for authentication. And while Fail2ban runs as a daemon, it does not expose any new listening network ports to which an outside attacker can attach. To disable it, an attacker would have to compromise the system before Fail2ban bans the offending host, which is unlikely in the case of a dictionary or brute force attack on an exposed port.

Installing Fail2ban

Fail2ban is available as a package for most distributions, so try that installation method before searching for source code and compile options. For example, on Red Hat-based systems, use:

$ sudo yum --y install fail2ban

For Debian-based ones, use:

$ sudo apt install fail2ban

Using a package installer also guarantees that you'll install the correct dependencies, which include Python and other Fail2ban packages, such as fail2ban-firewalld , fail2ban-sendmail , and fail2ban-server .

Once installed, you'll want to start Fail2ban and set it up to automatically start on boot, as follows:

$ sudo systemctl enable fail2ban
$ sudo systemctl start fail2ban

The Fail2ban service is started and is set to start on system boot, but currently has no protective configuration. The first step is to copy the jail.conf file, which you shouldn't edit, to jail.local, which you should edit:

$ sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Open jail.local in your favorite editor and add IP addresses that should never be banned. You must do this in case your standard modes of entry get banned. It is essentially giving yourself a backdoor into the system.

Look for this entry

ignoreip = 127.0.0.1/8

and add any IP addresses after the localhost entry that should never be banned. Separate entries by a single space. I suggest that you enter a limited number of single IP addresses rather than entering an entire subnet. It kind of defeats the purpose of having this protection if you're going to immunize every system from being banned. The point is that if a system is compromised and an attempt is made on the protected system, it will be banned. As shown in the following example, having fewer systems with immunity decreases the likelihood of a successful attack:

ignoreip = 127.0.0.1/8 192.168.1.55 192.168.1.89

Save the jail.local file.

You'll want to protect any exposed service port on your system. For this article, I'm going to protect SSHD.

For each service to be protected, you have to create a corresponding local "jail" file that contains some basic information about the service you want to protect.

Create the entry with your favorite editor:

$ sudo vi /etc/fail2ban/jail.d/sshd.local

Enter information into the sshd.local file as shown in Listing 1.

[sshd]
enabled = true
port = ssh
action = iptables-multiport
logpath = /var/log/secure
maxretry = 5
bantime = 600

Be sure that your logpath is correct and that you set maxretry to a reasonable number and bantime to your own tolerance level. The bantime parameter is in seconds. Some system administrators ban for one week (604800). It becomes inefficient for an attacker to wait a week or more between attempts, and they will likely give up. You can ban for longer if you wish. A -1 entry is a permanent ban.

Save the file and restart Fail2ban:

$ sudo systemctl restart fail2ban

Note: Remember to always restart Fail2ban after making any configuration changes or the changes will not take effect.

If systems have attempted and failed login via any protected service, you'll see them by displaying a list of iptable rules and the numeric values associated with those rules, as in Listing 2.

$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target      prot opt source       destination
f2b-default tcp  --  0.0.0.0/0    0.0.0.0/0    multiport dports 22
Chain FORWARD (policy ACCEPT)
target      prot opt source       destination
Chain OUTPUT (policy ACCEPT)
target      prot opt source       destination
Chain f2b-default (1 references)target      prot opt source      destination
REJECT    all  --  192.168.1.96 0.0.0.0/0  reject-with icmp-port-unreachable
RETURN    all  --  0.0.0.0/0    0.0.0.0/0

You can see that the IP address, 192.168.1.96, is banned. This system cannot use the host's SSH service. Chances are that a user attempted to log in to the host and failed the configured number of times, which according to the above configuration settings is five times.

To unban an IP address, use the unban command:

$ sudo fail2ban-client set sshd unbanip 192.168.1.96

unban immediately removes the banned IP address from iptables, and the formerly banned system now has access to the protected system. Unbanning an IP address does not require you to restart any services.

You can now check currently banned systems, with the results shown in Listing 3.

$ sudo iptables --L --n
Chain INPUT (policy ACCEPT)
target      prot opt source       destination
f2b-default tcp  --  0.0.0.0/0    0.0.0.0/0    multiport dports 22
Chain FORWARD (policy ACCEPT)
target    prot opt source         destination
Chain OUTPUT (policy ACCEPT)
target    prot opt source         destination
Chain f2b-default (1 references)
target    prot opt source         destination
RETURN    all  --  0.0.0.0/0      0.0.0.0/0

If a system's IP address has been banned, no user on the banned system may use the banned service. Additionally, in the case of SSH, all related services are also banned, such as SFTP, SCP, and any service that uses the SSH port (22). However, the banned system is only banned for that one particular service. For example, the banned system can still reach services on port 80 and on port 443. Each service on a system is independent and protected independently with its own set of rules.

For those of you who use it, Webmin  [2] has a Fail2ban module that lists dozens of services that you can protect, including Webmin itself.

Administrators will have to watch the iptables list output to ensure that legitimate attempts get unbanned in a timely manner and that malicious ones are permanently banned. External attempts are most likely malicious, and internal ones, while worth checking for legitimacy, are less likely to be hostile. If an internal system is banned by Fail2ban, you should check the security logs and question any individual who has failed to successfully log in to a protected system. Such internal auditing is an investigative check on bans originating from inside the network to verify if those attempts are harmless or malicious.

This brief introduction to Fail2ban allows you to quickly protect your systems from brute force attacks, dictionary attacks, and other methods of guessing passwords. Any service that requires authentication can be protected with Fail2ban, but that is its limitation. You can't protect services that don't require authentication. Fail2ban provides system administrators with a cost-free method for protecting servers and services. Even the most junior system administrator can set up and manage Fail2ban. Be aware, however, that like any security solution, it is only one defense and should not be used as the only protection against intruders.