Any service that is exposed to the internet is susceptible to attacks from malicious parties. If your service requires authentication, illegitimate users and bots will attempt to break into your system by repeatedly trying to authenticate using different credentials.
A common example of this is with SSH, which will be the subject of bot attacks that attempt to brute force common account names. Luckily, services like fail2ban were created to help us mitigate these attacks.
Fail2ban works by dynamically altering the firewall rules to ban addresses that have unsuccessfully attempted to log in a certain number of times.
If you are interested in the mechanics of how this all works, read on. Otherwise, please just be happy in the knowledge that every VPS we roll out has fail2ban already configured and running, keeping you safe and secure on the big bad internet!
So, the basic idea behind fail2ban is to monitor the logs of common services to spot patterns in authentication failures. When fail2ban is configured to monitor the logs of a service, it looks at a filter that has been configured specific to that service. The filter is designed to identify authentication failures for that specific service through the use of complex regular expressions. It defines these regular expression patterns into a variable called
Luckily, fail2ban includes filter files for common services. When a line in the service’s log file matches the
failregex in its filter, the defined action is executed for that service. The
action is a variable that can be configured to do many different things, depending on the preferences of the administrator.
The default action is to ban the offending host/IP address by modifying the
iptables firewall rules. You can expand this action to also send an email to the administrator with the
whois report of the attacker or the log lines that triggered the action.
You can also modify the action target to be something other than the usual
iptables. This can be as complex or as simple as you make it and many different firewall configuration file and notification options are available.
By default, action will be taken when three authentication failures have been detected in 10 minutes, and the default ban time is for 10 minutes. The default for number of authentication failures necessary to trigger a ban is overridden in the SSH portion of the default configuration file to allow for 6 failures before the ban takes place. This is entirely configurable by the administrator.
When using the default
iptables target for SSH traffic (for example),
fail2ban creates a new chain when the service is started. It adds a new rule to the INPUT chain that sends all TCP traffic directed at port 22 to the new chain. In the new chain, it inserts a single rule that returns to the INPUT chain.
This just makes the traffic jump to the new chain and then jump right back. This has no affect on traffic at the start. However, when an IP hits the threshold for authentication failures, a rule is added to the top of the new chain to drop the traffic from the offending IP. This takes care of the actual ban. When the ban period has expired, the iptables rule is removed. The chain and associated rules are removed when the fail2ban service exits.