As the next part of the series, the protection of the most common service SSH is described in this post. Almost every Linux based server will run a version of ssh daemon to be able to login from remote. In this post I will describe how to protect ssh using fail2ban.

Brute force login

Overview

The most common malicious behavior the server needs to protected against are brute force logins. The fraudsters are trying to guess a valid user name and password combination to get access to the system.  In the log file (typically /var/log/auth.log) this looks as follows:

sshd[1234]: Invalid user admin from xxx.xxx.xxx.xxx

Configuration

Add the following configuration to your jail.local configuration file

[sshd]
port    = ssh
logpath = %(sshd_log)s
enabled = true

This enables the ssh jail using the default values (e.g. 3 attempts in 10 minutes, see basic configuration). %sshd_log is variable defined in fail2ban which will lead to the correct config file for your distribution. See /etc/fail2ban/paths-common.conf and /etc/fail2ban/paths-<distro>.conf if you want to get more details.

Other options

Beside protecting the ssh service using fail2ban, security of ssh service can be improved by disallowing root logins to the system and to disable user name / password authentication and prefer public key authentication itself.  See this post for more details.

Buffer overflow scans

Overview

Some scans try to read the version of the SSH server and after they received it, try to push an exploit instead of sending the version of the SSH client itself. These scans are (at the moment) not too common to my servers but still occur. A typical log entry could look like

sshd[1234]: Did not receive identification string from xxx.xxx.xxx.xxx

Configuration

Add the following configuration to your jail.local configuration file

[sshd-ddos]
port    = ssh
logpath = %(sshd_log)s
enabled = true