Home Wiki > SDB:SSH systematic attack protection
Sign up | Login

SDB:SSH systematic attack protection

tagline: From openSUSE

Icon-update.png Update to version: 13.2
This article needs to be tested for a newer version. If you are using this guide on the newer version and you find the guide up-to-date to this version, please add the version number to the Knowledge bar. Please refer to version related jobs: SDB pages for more information.
Icon-obsolete.png This article or section refers to the version '11.2' and it is now obsolete!
Please refer to this article's discussion page for more information.
This article describes SSH systematic attack protection. Although SSH is a very safe protocol, this article can help you to understand and protect you against the risks of opening access to your computer using SSH or openSSH
Tested on openSUSE Recommended articles Related articles
Icon-checked.png

Icon-manual.png Icon-help.png

General

OpenSUSE comes with openSSH, containing both the server and client software to make use the SSH protocol.

SSH, or secure shell, is a very popular method to provide secure access to remote systems across a computer network. In some cases, the networks will be insecure, or worse, connected to public networks such as the Internet, which allows global access to the system. A popular attack is to find systems which are running SSH services that are available on the Internet and systematically attempt to guess the account names and passwords by trying thousands, hundreds of thousands, or even millions of authentication attempts until a correct one is found. This is known as a brute-force, systematic, or exhaustive attack.

The cost of resources to accomplish this task for "black hat" attackers is low due to inexpensive access to large numbers of compromised "zombie" computers.

A competent systems administrator will ensure the security of any SSH systems through methods such as changing the SSH service port from the default TCP port 22, greatly restricting the number of accounts which can authenticate, and/or requiring the use of key authentication instead of using passwords. (See openSSH public key authentication) However, these methods may not always be possible, such as in the case of a group-accessed SSH resource.


Solutions

In openSUSE and many other Linux distributions there are methods to restrict access to SSH client systems which repeatedly fail to authenticate. One of the most successful, other than making it hard to find the SSH service or using key authentication instead of passwords, is to use a host-based firewall to block access to the SSH service after a number of failures occur.

DenyHosts

DenyHosts is a python program that automatically blocks ssh attacks by adding entries to /etc/hosts.deny. Denyhosts will also inform Linux administrators about offending hosts, attacked users and suspicious logins. DenyHosts is available from the openSUSE repositories.

sshguard

sshguard works independently of the SSHD daemon and scripts. It monitors multiple system logs out of the box. When a multiple invalid log-in attempts occur, there will be an entry made for your firewall, to block the attacker in the future. Although created to secure SSH servers, it now supports many more protocol servers.

Sshguard is being actively maintained. It supports IPv6, whitelists and log authentication, interfaces with all the major firewall systems. Sshguard is not available in the openSUSE repositories. You can install and configure sshguard by following instructions on Install and configure sshguard

sshdfilter

sshdfilter is not being actively maintained, but appears to have more options when restricting access such as different times for restricting access for root account attempts, unknown user account attempts, and how often password failures occur. It is also more challenging to install.

From the official website: sshdfilter blocks the frequent brute force attacks on ssh daemons, it does this by directly reading the sshd logging output (or syslog output) and generating iptables (or ipfw) rules, the process can be quick enough to block an attack before they get a chance to enter any password at all. The blocking policy is defined by a list of blockrules largely by user name or by the type of user name. There are two install routes, the original style sshdfilter starts sshd itself, having started sshd with the -e and -D options. The newer style uses a syslog configuration line that writes sshd messages to a dedicated named pipe, normally /var/run/sshd.fifo. Regardless, this means sshdfilter can see events as they happen and act on them as they happen.

Sshdfilter is not available in the openSUSE repositories. You can install and configure sshdfilter by following instructions on Install and configure sshdfilter

Fail2Ban

Fail2Ban is yet another tool that monitors the system logs against multiple failed authentications, automatically adding offending hosts to iptables rules (temporary ban). It's largely customizable as it supports monitoring a wide number of known servers (including Apache and Postfix). It can also send notifications of blocked addresses, however enabling notification for SSH is strongly unrecommended as it would be easy to get your mailbox filled or your server being marked as a spammer due to large traffic generated by the SSH systematic attack.

Fail2Ban is available in the OpenSUSE repository.


Drawbacks

Any time a service is blocked to a particular source address when too many failures occur, there is the potential for someone to manipulate these attacks to appear to be coming from somewhere they are not to create a denial-of-service attack. In the case of SSH, this is difficult to do because of the workings of the protocol, but not impossible.

The potential for this to occur should be weighed carefully before implementing one of the earlier solutions.


See also


External links