Protection against DoS

SSH has two jails: the one just mentioned and sshd-ddos. This jail is not designed to prevent attempts to guess passwords, but to counter denial-of-service (DoS) attacks that open connections to the SSH daemon without entering a password.The logfile contains messages like this in case of a DoS attack:

sshd: Did not receive identification string from 10.0.0.150

Although you could configure multiple regular expressions per jail, many admins will prefer to assign different ban times for distributed DoS (DDoS) attacks as opposed to failed login attempts. That is, splitting this into the SSH and sshd-ddos categories makes a lot of sense.

The SSH jail is the only one set to enabled = true by default; all other jails – including sshd-ddos – have to be enabled manually.

Protection Scheme

If a user enters the wrong password multiple times, the results are similar to the Sshutout results: An iptables rule is triggered and locks out all connections from the offending computer for the next five minutes (Figure 2).

Protection for other services follows the same pattern (Figure 3). If you have a number of login-protected web pages on your Apache web server, Fail2ban will give you a jail to match,

[apache]
  enabled = false
  port = http,https
  filter = apache-auth
  logpath = /var/log/apache*/*access.log
  maxretry = 3

which you need to modify slightly. The Apache version that I run writes error messages to a separate error.log file, and not to access.log. After setting enabled = true, you can enable the jail.

Tip: A more elegant approach than simply restarting the Fail2ban daemon, which could mean disabling active iptables rules, is to send the following command from the Fail2ban client to the server:

fail2ban-client start apache

This command tells the server to add the [apache] entry to the list of active jails. To try this out, I entered a number of invalid passwords, and a new iptables rule was activated.