Dean Wilson@UnixDaemon: Whatever affects one directly, affects all indirectly.

Thu, 08 Jan 2009

Limiting Failed SSH Logins using PAM
Ever wanted to limit the number of ssh login attempts a user can make before their account gets locked? Well, not really, but when brute force tools are so common and easy to use it's another useful trick in the sysadmins arsenal.

In this example I'll show you how to install, configure and audit failed ssh loging attempts on Linux. While the PAM mod_tally module is available for a number of different distros and Unix variants we'll set it up on Debian. First of all grab the package if you don't already have it -

apt-get install libpam-modules

Now we've installed mod_tally you have to add a couple of lines to the /etc/pam.d/ssh PAM config file for ssh.


$ vi /etc/pam.d/ssh

# add before @include common-auth
# lock the buggers after 3 attempts
auth required pam_tally.so onerr=fail deny=3

# add before @include common-account
# resets count if login successful
account required pam_tally.so reset

The ordering of the lines is important. In some configurations previous PAM checks can shortcut the full process. While this post isn't the place to learn all about PAM the first line of the example sets what to do if something strange happens, such as the log file being unavailable (onerr=fail) and how many times a login can fail before being locked (deny=3). The second line tells PAM to reset the counter once a successful login has occurred for a specific user. If you leave this one out every failure is remembered for ever and eventually all will be locked out.

Now you're up and running how do you find out what's happening? If you want to look at the current status then you can run the pam_tally command and you'll see output like this -


root@pam:/etc/pam.d# /usr/sbin/pam_tally
User ajones     (1000)   has 2
User lockme     (10010)  has 4

pam_tally also logs wherever your authentication events go (/var/log/auth.log on Debian by default ) so you can keep historical information or feed the attempts in to your normal log monitoring systems


# sample log line
Jan  8 19:16:24 pam pam_tally[30086]: user lockme (10010) tally 4, deny 3

To close the loop let's cover resetting the locked accounts. If you have a user complaining then you can run pam_tally --reset --user lockme to clear their tally. Another option (worth considering) is a scheduled reset. This gives you the benefit of slowing down brute force attacks while not requiring you to unlock all accidentally locked accounts. The simplest way to do this is to add a cronjob that runs a reset. Newer versions have an unlock_time=n option you can supply in the ssh PAM config file but that didn't work for me under Etch.

Like this post? - Digg Me! | Add to del.icio.us! | reddit this!

Posted: 2009/01/08 23:31 | /security | Permanent link to this entry | This entry + same date

July 2009	2
June 2009	1
April 2009	3
March 2009	7
February 2009	4
January 2009	17
December 2008	1
November 2008	4
October 2008	5
September 2008	4
August 2008	12
July 2008	9
April 2008	4
March 2008	1
February 2008	1
January 2008	15
August 2007	2
June 2007	9
May 2007	6
April 2007	8
March 2007	31
February 2007	3
January 2007	21
December 2006	1
November 2006	4
October 2006	6
September 2006	32
August 2006	17
July 2006	14
June 2006	9
May 2006	13
March 2006	11
February 2006	16
January 2006	11
December 2005	1
November 2005	6
October 2005	19
September 2005	25
August 2005	16
July 2005	16
June 2005	13
May 2005	2
April 2005	19
March 2005	31
February 2005	20
January 2005	31
December 2004	21
November 2004	30
October 2004	32
September 2004	18
August 2004	7
July 2004	14
June 2004	5