Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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!

share|improve this question

migrated from stackoverflow.com Mar 15 '13 at 0:40

This question came from our site for professional and enthusiast programmers.

up vote 1 down vote accepted

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.

share|improve this answer
    
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 '13 at 21:20

You must log in to answer this question.

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