SSH systematic attack protection

From openSUSE

Contents

Overview

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 Securing SUSE Linux: SSH Security) However, these methods may not always be possible, such as in the case of a group-accessed SSH resource.

Solution

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. Fortunately for us, openSUSE and most Linux distributions contains nearly all the pieces we need to do this.

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 this solution.

Implemenation methods

These sections detail how to accomplish this using one of two open source tools.


sshguard

sshguard is being actively maintained. It supports IPv6, whitelists and log authentication, interfaces with all the major firewalling systems. It works independently of the SSHD daemon and scripts.

Installation Process

The installation process overview is as follows. This was tested on openSUSE 11.1. See the following sections for more detail.

1. Obtain a copy of the sshguard software from SourceForge, or another reliable source. Preferably, get the RPM version for easy installation.
2. Install the RPM package on the SSH server you wish to protect. Most easily, this can be done by using:
   rpm -Uvh sshguard-package-name.rpm
3. Configure the firewall to accept IP addresses to block from the SSH service. See this section for more details.
4. Configure syslog-ng to launch sshguard and pass the necessary logs to it. See this section for more details.
5. Configure AppArmor to allow sshguard to run and syslog-ng to pass logs to it. See this section for more details.
6. Restart and test the system. NOTE: Existing open SSH sessions will not be blocked if an IP address is blacklisted, however all new session attempts will fail.

Firewall configuration

The SuSEfirewall2 firewalling system is very powerful, but unfortunately, may not be obvious where to place additional rules so that they are permanent and interoperate with the built-in openSUSE firewall configuration tools.

1. Edit the /etc/sysconfig/scripts/SuSEfirewall2-custom file. Add these lines to the fw_custom_before_port_handling section before the "true" statement:
   ## For SSHguard, regular IPv4 support:
   iptables -N sshguard
2. To the same file, add these lines to the fw_custom_before_denyall section before the "true" statement:
   ## For SSHguard
   iptables -A INPUT -j sshguard
3. Activate the firewall rule customizations by adding this line to the /etc/sysconfig/SuSEfirewall2 file.
   FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"
4. Restart the firewall by using the following commands, or wait until the system is reset later.
   SuSEfirewall2 stop
   SuSEfirewall2 start

syslog-ng configuration

The default logging system, syslog-ng can be configured to both automatically collect the information needed for sshguard to operate, as well as actually launch sshguard when syslog-ng launches.

1. Add the following lines to the /etc/syslog-ng/syslog-ng.conf file:
   ## SSHguard
   # pass only entries with auth+authpriv facilities that contain sshd
   filter sshlogs { facility(auth, authpriv) and match("sshd"); };
   
   ## SSHguard
   # pass to this process with this template (avoids <ID> prefixes)
   destination sshguardproc {
          program("/usr/sbin/sshguard"
          template("$DATE $FULLHOST $MESSAGE\n"));
   };
   log { source(src); filter(sshlogs); destination(sshguardproc); };
2. Wait until the AppArmor configuration is complete to restart both services, or restart the computer after you complete that step.

AppArmor configuration

AppArmor is the next-generation chroot that keeps a service process or daemon from doing more than it should if it comes under attack. Rather than risk disabling this valuable service, it is relatively easy to reconfigure it to allow sshguard to perform its work.

1. Add the following lines to the /etc/apparmor.d/sbin.syslog-ng file:
   # allow syslog-ng to launch and pipe information to sshguard
   /usr/sbin/sshguard pxr,
   /bin/bash ix,
2. Create the following file and save it as /etc/apparmor.d/usr.sbin.sshguard:
   #include <tunables/global>
   
   /usr/sbin/sshguard {
     #include <abstractions/base>
     /usr/sbin/iptables Ux,
   }
3. Restart the computer system, or restart both the AppArmor and syslog-ng services.

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.

These steps were tested with SUSE Linux Enterprise Server 10 which is roughly equivalent to openSUSE 10.

1. Obtain a copy of sshdfilter from a trusted source, such as the official package site.
2. Edit /etc/issue to remove the leading blank line before the SUSE identifier line, to get the installation script to recognize the version of Linux.
3. Install sshdfilter using the install as wrapper script.
4. Edit /etc/sysconfig/scripts/SuSEfirewall2-custom file.
5. Add these lines before the "true" statement in the fw_custom_before_port_handling section.
   #Rules for sshdfilter
   iptables -N SSHD
   iptables -I INPUT -p tcp -m tcp --dport 22 -j SSHD
6. Update /etc/sysconfig/SuSEfirewall2 to set:
   FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"
7. Restart the firewall with the commands:
   SuSEfirewall2 stop
   SuSEfirewall2 start
8. Restart sshd:
   /etc/init.d/sshd restart

See Also

References