Linux.com

Feature: Security

Protect SSH from brute force attacks with pam_abl

By Anže Vidmar on March 26, 2007 (8:00:00 AM)

Share    Print    Comments   

Practically all Unix and Linux servers run an SSH service to let administrators connect securely from remote locations. Unfortunately for security administrators, attacks on SSH services are popular today. In this article I'll show you how can you protect machines running SSH services from brute force attacks using the pam_abl plugin for SSH pluggable authentication modules (PAM).

You can download and compile the pam_abl module yourself, or you can download and install a binary package from a repository. If you want to compile the module, download the source and look for information on how to compile it on the pam_abl homepage. If you want to implement pam_abl on your Ubuntu Dapper or Edgy server or desktop, add one of Roman Balitsky's custom repositories to your /etc/apt/sources.list file:

deb http://ubuntu.tolero.org/ dapper main (for Dapper)
deb http://ubuntu.tolero.org/ edgy main
(for Edgy)

After adding the installation source, update the source list, install pam_abl, and restart the SSH service:

sudo apt-get update
sudo apt-get install libpam-abl
sudo /etc/init.d/ssh restart

Next, you may want to tweak the pam_abl configuration file in /etc/security/pam_abl.conf:

#/etc/security/pam_abl.conf
host_db=/var/lib/abl/hosts.db
host_purge=2d
host_rule=*:3/1h,30/1d
user_db=/var/lib/abl/users.db
user_purge=2d
user_rule=!root:3/1h,30/1d

Lines 2 and 5 show where the list of banned users and hosts are saved. The third and sixth lines set the purge times for bans; here, both the host-ban and user-ban rules will be purged in two days. On the fourth and seventh lines are host and user rules. Let's look at them in more details.

The syntax of the config file is like this:

host/user_rule=<host/user>:<number of tries>/<ban time>,<number of tries>/<ban time>

Thus our line 4 rule means ban all hosts (the asterisk) that entered wrong credentials three or more times in the last hour, or if the tries number is greater than 30 in the last day.

The line 7 user rules says ban any user except the user root (the "!root" directive) if the user's password fails three times in a one-hour period or if the number of failed retries is greater than 30 in a one-day period.

You can also define only selected users that you need to protect. Let's say that you want to protect only the users anze, dasa, kimzet, and madison. The config syntax should look like this:

anze|dasa|kimzet|madison:20/1h

This means that all four users -- anze, dasa, kimzet, and madison -- will be banned if their login failures reach 20 in a one-hour period.

For full list of options and triggers, see the pam_abl manual page.

Test

To test your configuration, open a terminal on the target box and look at the /var/log/auth.log file. Try to log in to the server three times with the wrong password and see if the pam_abl plugin bans you. If it does, using the user madison as an example, the log file should look like this:

pam_abl[6248]: Blocking access from sataras.example.com to service ssh, user madison

Now madison is blocked on the target machine and will not be able to log in for two days.

You can check the banned users and hosts at any time with pam_abl command:

~$ sudo pam_abl
Failed users:
madison (3)
Blocking users [!root]
Failed hosts:
sataras.example.com (3)
Blocking users [*]

Conclusion

There are many ways you can protect your machine from hackers, including changing the SSH listening port and defining which hosts are allowed to connect to your SSH service using iptables and TCP wrappers. Implementing the pam_abl module eliminates brute force attacks against your SSH server; just be careful that you configure the module so that an attacker cannot lock you out of your own box.

Share    Print    Comments   

Comments

on Protect SSH from brute force attacks with pam_abl

Note: Comments are owned by the poster. We are not responsible for their content.

Just do a delay schtoopid

Posted by: Anonymous Coward on March 27, 2007 11:40 AM
Edit the file auth-passwd.c and add the single line 'sleep(10);' to it, immediately after the variable definitions.

One line of code is all it takes.

#

Re:Just do a delay schtoopid

Posted by: Joe Klemmer on March 28, 2007 10:06 AM
Ok, fine. Where is said file? Not on my boxes. You're talking about editing source and rebuilding. That's not going to happen on any systems that are in production use nor on the "Joe User" desktop.


Your glib, off-hand comments are nonproductive and of no value.

#

Alternatively...

Posted by: Anonymous Coward on March 27, 2007 02:10 AM
You could use the features already built into ssh. Disable password login, only allow public/private key access and list those user ids allowed to connect in<nobr> <wbr></nobr>/etc/sshd.conf. There are also a few scripts floating about that will block IPs after so many connections on port 22 within a specified time period.

#

Re:Alternatively...

Posted by: Anonymous Coward on March 27, 2007 03:31 AM
Disabling password access in sshd is a superior approach in terms of security, but may not be workable.

The scripts, by contrast, have a number of flaws, with misinterpretation of unusual login names, dns spoof redirect attack potential, and other issues. This is a clear improvement on the logo-watching scripts.

#

When Will They Learn

Posted by: Anonymous Coward on March 27, 2007 05:10 AM
Why is it that people feel that switching to key based access is the silver bullet of protection. While I agree that guessing the key would take much longer than a dictionary based userid and password, encryption key based access is not impervious to brute force attacks. Furthermore, while it may indeed take months/years/millennia to exhaust the keyspace, the odds are just as good for the first guess as they are for the last possible guess.

Key based access control systems do nothing to prevent a brute force attack at best they can only delay the inevitable. Programs such as this that identify and then deflect brute force attacks are a better solution than simply assuming that the vast keyspace will protect you. Also, key based access control systems are much less convenient for the user than userid and password. In some cases, key based access control is so inconvenient or impractical that it is unusable. But, userid and passwords on a system that defends itself against bruteforce attacks are perfectly acceptable.

#

Take a look at fail2ban

Posted by: Anonymous Coward on March 27, 2007 03:36 AM
Fail2Ban is a nice application that watches various log files. On certain conditions it will ban a given ip addresses for a period of time.

<a href="http://www.fail2ban.org/wiki/index.php/Main_Page" title="fail2ban.org">http://www.fail2ban.org/wiki/index.php/Main_Page</a fail2ban.org>

This can be used to watch any service log. Out of the box it will watch ssh. You can easily configure the ban period and the number of failed attempts before an IP is banned.

It's easy to install (I knwo there are apt packages for Ubuntu).

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya