In part 1 I discussed basic options for securing your ssh server. In this part, I will discuss specific strategies for reducing the number of attacks the server faces.

Reducing the Number of Brute Force Attacks

The strategies discussed in part 1 work to secure the ssh server against attacks, but do nothing to reduce the number of attempts. The following will do just that. Remember that as the administrator, you must evaluate each of these in the context of your environment. For example, if many people connect to a server, running on a non-standard port may not be feasible.

Run sshd on a Non-Standard Port
sshd listens on port 22 by default, making it the main port attackers attempt to brute force. While having the daemon listen on a different port has no impact on the vulnerability of your ssh daemon, it will dramatically reduce the number of brute force attempts. To change the port, edit /etc/ssh/sshd_config:

Port 4321

where 4321 is some random unused port. This change will require a change in the configuration of all clients contacting the server and may necessitate a change in the server's firewall configuration.

Fail2Ban
Fail2Ban is a tool that parses log files and bans IP addresses with too many authentication failures. We will look at using it to defend against ssh brute force attacks although it has additional uses. It can block addresses with iptables or with TCP Wrappers (/etc/hosts.deny). I will detail configuration with the default, iptables, which must be up and running first.

Configuration is done via the /etc/fail2ban.conf file. You will need to set at least the following:

[DEFAULT]
maxfailures = 5     # Number of failures before an IP is banned.
bantime     = 600   # Seconds an IP will be banned.  A negative value will 
                    # permanently ban the IP.
ignoreip    =       # Whitespace delimited list of ip addresses to ignore.  
                    # You can use a mask to specify a range.
                    # e.g. 192.168.1.0/24

[SSH]
enabled     = true
logfile     = /var/log/auth.log
port        = 22

Check the [SSH] section and set the path to the logfile and port on which the daemon runs.

DenyHosts
DenyHosts is similar to Fail2Ban in that it scans log files and bans IP addresses with too many failed connection attempts. However, DenyHosts works only with ssh and blocks IP addresses by adding them to the /etc/hosts.deny file. This prevents that IP address from using any TCP Wrapper aware services on the server whereas Fail2Ban only prevents the attacker from using SSH. Additionally, DenyHosts has an optional synchronization mode that allows DenyHosts users to share attack data, proactively protecting against known attackers.

Configuration is done via the /etc/denyhosts/denyhosts.cfg file. Set the following to match your preferences and system:

SECURE_LOG =                # Path to the log file where sshd writes.
HOSTS_DENY =                # Path to the host access control file.
PURGE_DENY =                # Time denied addresses should remain in
                            # HOSTS_DENY. Leave blank to never purge.
BLOCK_SERVICE =             # Services to block for the offending host.
DENY_THRESHOLD_INVALID =    # Block host after number of failed, invalid
                            # user login attempts.
DENY_THRESHOLD_VALID =      # Block host after number of failed, valid
                            # user login attempts (except root).
DENY_THRESHOLD_ROOT =       # Block host after number of failed login
                            # attempts as root.

pam_abl
pam_abl is a pam module that automatically blacklists hosts and accounts that exceed a specified number of failed authentication attempts. The hosts / users are blacklisted for a configurable amount of time. Rules are written using the following syntax:

host_rule=<host>:<number of failures>/<time>,<number of failures>/<time>

For example, the following rule would ban all hosts (asterisk) with three or more authentication failures in one hour or 30 failed attempts in one day:

host_rule=*:3/1h,30/1d

Rules can be account based instead of host based by using the user_rule directive. The syntax is identical to that of the host_rule. Additional instructions and examples can be found at Linux.com.

iptables
The limit and recent iptables modules can be used to defend against ssh brute force attacks. See EnterpriseLinux and Diary of a Geek for more information and sample rulesets.

Conclusion

Brute force attacks on servers allowing remote ssh access are very common. In these two articles I have provided an overview of some of the steps and technologies available to system administrators for protecting their servers against these attacks. These steps range from restricting access to specific users / networks to programs that block computers that repeatedly fail to log in. Unfortunately, none of these solutions provides a magic bullet that will definitely protect your server. You must evaluate each one and use those that are most appropriate for your system and organization.