0

I have RHEL 6.3 systems that have PAM's access.conf correctly configured and running. However, it seems in a less than ideal state, after analysis of a root-hack attempt, and I'm wondering if there's anything that can be done about it.

I used authconfig to add access.conf and then added my rules. However, it looks like PAM runs a password check BEFORE running access.conf rules. I want to reverse that, and not even allow someone to check password unless they pass access.conf rules FIRST.

The current behavior represents a security risk, imho, because although access.conf might subsequently deny a successful password guess, there are characteristics that will tell the hacker that they got the guess right. That is:

Unsuccessful password attempts:

[ivo@pioneer:~]$ ssh root@mysecuresystem
root@mysecuresystem's password:
Permission denied, please try again.
root@mysecuresystem's password:
Permission denied, please try again.
root@mysecuresystem's password:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Successful password attempts:

[ivo@pioneer:~]$ ssh root@mysecuresystem
root@mysecuresystem's password:
Connection closed by 10.10.10.65

Behavior doesn't conclusively tell them they got password, but it IS different from a failed guess, and therefore noteable. (Also, logs still show unix_chkpw, which results in a false positive in Security's IDS/log analyzer).

While changing this behavior would result in PAM source changes, and thus be complicated, changing the order of checks in PAM might be easy?

So how do I get PAM to use access.conf BEFORE a password check?

(Note: We need to use access.conf because we need to stop only root from most machines, but allow users from anywhere. So sshd config is not a solution, nor are wrappers for what we need to accomplish)

Thanks!

Improve this question

1 Answer 1

Reset to default
1

This isn't a solution but it seems to be a reasonable workaround, modify /etc/pam.d/sshd moving the "pam_access.so" line so that it's in the "auth" section, for example:

auth required pam_access.so

Rather than

account required pam_access.so

This causes log in attempts to produce the "Access denied" message even when a valid password has been used thus avoiding informing the hacker of a correct guess.

Improve this answer
1
  • Thanks Bill - I think this is a partial answer, and if after a few more days no one else answers will mark it as such. This solves the part where the cracker will get same prompting whether they guess correctly or not. I would love to see the logs still not show unix_chkpw so our security group would quit coming down to "make sure this is a false positive..." But this solves a big part!
    – zenfridge
    Mar 18, 2013 at 21:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .