[SOLVED] Modified /etc/pam.d/system-auth-local and get authentication failed

JockVSJock · 12-09-2015, 03:20 PM

I've locked myself out of RHELv5 after modifying pam files under /etc/pam.d. I was trying to setup a 4 second delay if someone fails at logging in.

I've setup a 4 second delay under /etc/login.defs

And then I've also dodified /etc/pam.d/system-auth-local with the following:

Code:

auth required pam_access.so
auth optional pam_faildelay.so delay=4000000
auth include system-auth-ac
account include system-auth-ac
password include system-auth-ac
session include system-auth-ac

I've then created a soft link from /etc/pam.d/system-auth to /etc/pam.d/system-auth-local

Once I've rebooted, I can type in the user name, however I don't get a chance to put in the password, I get authentication failed

This is what the log looks like from /var/log/secure

Code:

DEC 9 10:22:28 localhost ssd[3986]:  Server listening on 0.0.0.0 port 22. 
DEC 9 10:22:33 localhost gdm[4219]:  PAM (gdm) illegal module type: fail_delay 
DEC 9 10:22:33 localhost gdm[4219]:  PAM pam_parse:  exptecting return value: [...4]
DEC 9 10:22:33 localhost gdm[4219]:  PAM (gdm) no module name supplied 
DEC 9 10:22:33 localhost gdm[4219]:  gdm[4219]:  PAM unabled to dlopen(<*unknown module path*>)
DEC 9 10:22:33 localhost gdm[4219]:  PAM [error:  <*unknown module path*>:  cannot open shared object file:  No such file or directory 
DEC 9 10:22:33 localhost gdm[4210]:  PAM adding faulty module:  <*unknown module path*>

unSpawn · 12-12-2015, 08:13 AM

Quote:

Originally Posted by JockVSJock

(..) I've also dodified /etc/pam.d/system-auth-local

Instead of /etc/pam.d/sshd? Why?

Quote:

Originally Posted by JockVSJock

I've then created a soft link from /etc/pam.d/system-auth to /etc/pam.d/system-auth-local

Nowhere in RHEL / CentOS docs or /usr/share/doc/pam-*/txts/README.pam_faildelay does it say you should. Why?

*Also if you don't have remote console or any other Out of Band access next time set an 'at' task to undo changes after say 5 minutes? That way you can test with less risk and automagically revert back.

JockVSJock · 12-12-2015, 08:34 AM

I'm using the STIG requirements put out from DISA to implement these changes to /etc/pam.d. One of the STIGs is advising to modify those files Vs /etc/pam.d/sshd.

Typically, it sounds like its better to modify sshd then the system-auth and system-auth-ac files for pam.d?

JockVSJock · 12-12-2015, 09:55 AM

Luckily this is only a test server (a VM actually).

My end goal is to fully STIG a RHEL5/RHEL6 server, convert to template and then deploy servers from there as needed.

This is the text from the DISA STIG

Quote:

Rule Title: The delay between login prompts following a failed login attempt must be at least 4 seconds.
STIG ID: GEN000480 Rule ID: SV-37213r2_rule Vuln ID: V-768
Severity: CAT II Class: Unclass

Discussion:
Enforcing a delay between successive failed login attempts increases protection against automated password guessing attacks.

Documentable: No

Responsibility:
System Administrator

Check Content:
Check the value of the FAIL_DELAY variable and the ability to use it.

Procedure:
# grep FAIL_DELAY /etc/login.defs
If the value does not exist, or is less than 4, this is a finding.

Check for the use of pam_faildelay.
# grep pam_faildelay /etc/pam.d/system-auth*
If pam_faildelay.so module is not present, this is a finding.

If pam_faildelay is present only in /etc/pam.d/system-auth-ac:
ensure that /etc/pam.d/system-auth includes /etc/pam.d/system-auth-ac.
#grep system-auth-ac /etc/pam.d/system-auth

This should return:
auth include system-auth-ac
account include system-auth-ac
password include system-auth-ac
session include system-auth-ac

/etc/pam.d/system-auth-ac should only be included by /etc/pam.d/system-auth. All other pam files should include /etc/pam.d/system-auth.

If pam_faildelay is not defined in /etc/pam.d/system-auth either directly or through inclusion of system-auth-ac, this is a finding.

Fix Text:
Add the pam_faildelay module and set the FAIL_DELAY variable.

Procedure:

Edit /etc/login.defs and set the value of the FAIL_DELAY variable to 4 or more.

The default link /etc/pam.d/system-auth points to /etc/pam.d/system-auth-ac which is the file maintained by the authconfig utility. In order to add pam options other than those available via the utility create or modify /etc/pam.d/system-auth-local with the options and including system-auth-ac. For example:

auth required pam_access.so
auth optional pam_faildelay.so delay=4000000
auth include system-auth-ac
account include system-auth-ac
password include system-auth-ac
session include system-auth-ac

Once system-auth-local is written ensure the /etc/pam.d/system-auth points to system-auth-local. This is necessary because authconfig writes directly to system-auth-ac so any manual changes made will be lost if authconfig is run.

IA Controls:ECLO-1, ECLO-2
CCI: CCI-002238
NIST SP 800-53 Revision 4 :: AC-7 b

I'm not to terribly familiar with PAM, so I'm learning. I also know that the STIGS aren't perfect either and sometime they way they are written, they have unintended consequences.

unSpawn · 12-12-2015, 07:18 PM

Quote:

Originally Posted by JockVSJock

Typically, it sounds like its better to modify sshd then the system-auth and system-auth-ac files for pam.d?

/etc/pam.d/system-auth-ac is symlinked as /etc/pam.d/system-auth and I've never read PAM documentation that advices you to mess with those symlinks. If you 'grep system-auth -r /etc/pam.d/;' you'll find it is referenced by other services, so changing it will have consequences for all services. I don't think introducing fail_delay is a bad choice but only if you can reconcile /var/log/secure problems. Usually "unabled to dlopen(<*unknown module path*>)" and "[error: <*unknown module path*>: cannot open shared object file: No such file or directory" errors are due to using custom locations and those may be fixed by prefixing the whole path but since the "illegal module type: fail_delay" error precedes those (at least for GDM) I wonder what other services will b0rk...

Quote:

Originally Posted by JockVSJock

My end goal is to fully STIG a RHEL5/RHEL6 server, convert to template and then deploy servers from there as needed.

Laudable. Shame there's too few people interested in STIG compliance (last thread I remember was from a couple of years ago) so everybody is working separately on their own rule sets. So if you have stuff to share on LQ STIG-wise I'm interested.

Quote:

Originally Posted by JockVSJock

I'm not to terribly familiar with PAM, so I'm learning. I also know that the STIGS aren't perfect either and sometime they way they are written, they have unintended consequences.

PAM isn't that hard to configure, it's just that you have to be precise about doing things ;-p

JockVSJock · 12-12-2015, 07:33 PM

Right now I'm trying to STIG RHEL5 by hand. Once I get comfortable, then I will Bash script it out to automate it. The same with RHEL6.

Once I get something solid, I would love to share it with everyone here. Until then, I keep plugging away.

What kind of advise can you offer for troubelshooting/modifying PAM files in the future? Again it was only a test machine. However I want to get this fully STIGGED and into production. Something that I can use.

thanks

JockVSJock · 12-14-2015, 08:28 AM

So had a person on a gov-sec email list email me the following changes to make:

Confirm the following:

Code:

 
/etc/login.defs
FAIL_DELAY   4

Do the following:

Code:

cd /etc/pam.d
rm system-auth
cp -p system-auth-ac system-auth-local
ln -s system-auth-local system-auth

Add the following into both /etc/pam.d/system-auth-ac and /etc/pam.d/system-auth-local. Once doing that, run the following: /usr/sbin/authconfig --update

Code:

#%PAM-1.1
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_tally2.so file=/var/log/tallylog deny=3 unlock_time=604800
auth        optional      pam_faildelay.so delay=4000000 
auth        required      pam_env.so
auth        sufficient    pam_unix.so likeauth 
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so
account     required      pam_tally2.so

password    required      pam_cracklib.so try_first_pass retry=3 minlen=15 ocredit=-2 dcredit=-2 ucredit=-2 lcredit=-2 difok=4 maxrepeat=3 
password    sufficient    pam_unix.so sha512 shadow try_first_pass use_authtok remember=5
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Then do a final check on /etc/ssh/sshd_config

Code:

grep -V UsePam /etc/ssh/sshd_config

Confirm UsePam Yes

Confirm root permissions and 0644 on /etc/ssh/sshd_config and restart the sshd daemon.

I'm not sure what all of the entries under the /etc/pam.d/system-auth-ac and /etc/pam.d/system-auth-local do. If anyone can point me in a direction where I can learn more about pam, what do to and what not to do and what to backup before trying anything. I would be grateful.

thanks