account attempt lockout and pam_tally

Hi, I work for the DOD and one of the checks in our security scan fails because pam_tally is not configured in pam.d to lock an account after three failed login attempts.

There are a lot of other checks that fail because to script only knows one way of doing things, ie all checks against /etc/syslog because syslog-ng is being used.

I have not found out if openSUSE is using a different method of locking accounts aftet failed login attempts.

If I need to use pam tally, which file does it go in?

I think it would be auth or password.

I found this doc, but it only shows changing the sshd in pam.d

SDB:Lock user account after login fails - openSUSE



The idea of PAM is to allow a configurable control of authentication, usable by many applictions of authentication. The method shown for sshd, should work for other methods of gaining access to system.

It looks to me like common-auth is the place for a central authentication policy. common-password is about changing passwords, and looks to be defining a policy for a new password.

On syslog v syslog-ng, you might find Syslog-ng - Wikipedia, the free encyclopedia the link to Recommendation and analysis of syslog-ng in secure environments 360 Information Security : The Magnificent Seven, #2 Syslog NG reassuring.

The configuration syntax probably has a yacc based parser in the source, which might help in developing a module to check the configuration.

Those four common files you mention represent the four places where a PAM service is called. A particular module will implement one or more of those aspects. In the case of pam-tally this would be auth, at least. It may also go into one of the other aspects.

You might not want to put it in common-auth because this affects all places where login is used, including something like a POP3 service using PAM. If the POP3 user, which is probably a mail program, is given the wrong password by the user, then it will rapidly fail three times in a row and get struck out. You might want to put it only in the login service, and perhaps the ssh service.

Why would the POP3 program retry if the username/password fails the authentication?

The user might retry. In any case perhaps you don’t want to put a lockout on a POP3 account when it’s the login retries that you want to control. Just saying have a look where common-* is used instead of blindly inserting pam-tally there, you might end up locking out apps you didn’t really mean to.

Thanks for all the replys.

For robopensuse, I am not having any problems with syslog-ng I was just showing how the scanner we have to use fails because it only knows one way of doing checks.

So I figured that pam_tally would go in auth or password, auth makes sense. But before I try messing with pam I was trying to verify if openSUSE already had a method of locking accounts. I guess that since no one has menchened one, pam_tally is the way to go.


The problem with this thinking ken, is that an attacker can then use your POP3 service to do their password cracking. Then do the login service once, now you’ve helped them out.

So I think a central authentication policy makes more sense, if you care about security.

The POP3 was an example. Whether you want to control all your applications that use common-* is up to you. I was just pointing out that there is a reason why there is a common-* in the name, it is used for all services that include this fragment. So don’t blindly insert checks here without understanding how the PAM config files are setup. That was the main point.