Ssh – Firewalls (ufw vs apf) on Ubuntu

iptables -A INPUT -p tcp -m state --state NEW --dport 21 -m recent --name ftpattack --set
iptables -A INPUT -p tcp --dport 21 -m state --state NEW -m recent --name ftpattack --rcheck --seconds 60 --hitcount 4 -j LOG --log-prefix 'FTP REJECT: '
iptables -A INPUT -p tcp --dport 21 -m state --state NEW -m recent --name ftpattack --rcheck --seconds 60 --hitcount 4 -j REJECT --reject-with tcp-reset

these rules near or at the top of your ruleset will allow only three connections to port 21, from any given IP address, in a rolling 60-second window. To allow n, use --hitcount n+1; to use a bigger window than 60 seconds, increase --seconds 60.

What I recommend is to stagger your security solutions. Security is best implemented in Layers, and having one solutions means you will have a Single Point of Failure.

Fail2Ban, as stated above by Jeff Ferland, is a good first step solution. It will monitor your log files for signs of a brute force attack, and can be configured to listen generally against PAM.

But what happens if this log file is lost? permissions change? if the log file destination changes? if fail2ban crashed? if an update changes the way you intend things to work? the regex pattern must be updated? what happens if the log file destination drive or partition becomes full? fail2ban becomes useless.

• Introducing libpam_shield

There is a PAM Module called pam_shield. this is not only more efficient (operating directly within the Login layer), it uses a fast access database, which can persist across reboots.

it uses less memory, and does not require a running service which can fail. pam_shield can also be configured to work with your routing table, as well as IPTables.

Much like Fail2Ban, you give it a period of time to consider the host for a ban. you supply the maximum attempts the remote host can make, and the period of time which to ban them for.

To make it work nicely with Fail2Ban, set these to 1.5 times that of what is configured in Fail2Ban. you might also make the Ban period much longer. this way, fail2ban will ban the user the first time around... and if their ban expires, and they are caught again, it will ban them for much longer the second time around.

Here is a link to the configuration files manual page: shield.conf

• Introducing pam_tally2

You might also consider pam_tally2 for locking a specific users account.

if a user account is being specifically targeted, you would need to lock out this user account, and prevent login all-together, or until the attack is dealt with.

this is useful especially on a shared server, when the attack is originating from "the inside". when you can’t block the local host (i.e. 127.0.0.1).

Hopefully this helps! I realize the original post is a bit old now, but It's very important to implement security in layers... and to cover all your bases! there is NO package you can "just install" to make your system secure. not even Fail2Ban.