6.17 Set Retry Limit for Account Lockout

Information

The RETRIES parameter is the number of failed login attempts a user is allowed before being disconnected from the system and forced to reconnect. When LOCK_AFTER_RETRIES is set in /etc/security/policy.conf, then the user's account is locked after this many failed retries (the account can only be unlocked by the administrator using the command: passwd -u <username>. The account lockout threshold (RETRIES parameter) restricts the number of failed login attempts allowed before requiring the offending account be locked. The lockout requirement will help block malicious users from gaining access to the host via automated, repetitive brute-force login exploits--trying different passwords until one fits a user name.

Rationale:

Setting the failed login limit to an appropriate value locks the user account, which will severely limit the speed of such attacks, making it much more likely that the attacker's pattern will be noticed and the offending source address and/or port blocked, so this should be set according to the needs of the user.

Solution

Perform the following to implement the recommended state:

# cd /etc/default

# awk '/RETRIES=/ { $1 = 'RETRIES=3' } { print }' login >login.CIS

# mv login.CIS login

# cd /etc/security

# awk '/LOCK_AFTER_RETRIES=/ { $1 = 'LOCK_AFTER_RETRIES=YES' } { print }' policy.conf > policy.conf.CIS

# mv policy.conf.CIS policy.conf

# svcadm restart svc:/system/name-service/cache

Be careful when enabling these settings as they can create a denial-of-service situation for legitimate users and applications. Account lockout can be disabled for specific users via the usermod command. For example, the following command disables account lock specifically for the oracle account:

# usermod -K lock_after_retries=no oracle

Note: The root role is configured in this manner by default to prevent accidental lock out.

Additional Information:

The action specified here sets the lockout limit at 3, which complies with NSA/DISA recommendations, but may be too restrictive for some organizations.

See Also

https://workbench.cisecurity.org/benchmarks/4777