Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

1 Answer 1

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.