AC.L2-3.1.8 (NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2) requires limiting the number of unsuccessful login attempts to systems that process, store, or transmit CUI — a straightforward control in principle but one that needs careful, auditable implementation on Linux and SSH to avoid blocking legitimate users or leaving gaps that attackers can exploit.
Why this control matters and the compliance context
For Compliance Framework readers: AC.L2-3.1.8 is a protective measure to reduce the likelihood of brute-force, credential-stuffing, and password-guessing attacks. NIST/CMMC expects organizations to implement technical controls and to document policies, settings, and monitoring that demonstrate enforcement. Evidence typically includes configuration files, change-control tickets, test results, and logs showing lockouts and alerts.
Recommended technical approaches
There are two complementary approaches you should implement on Linux systems: account-based lockouts via PAM (pam_faillock or pam_tally2 depending on your distro) and network/IP-based bans via Fail2Ban (or equivalent) for SSH. PAM enforces per-account mitigation; Fail2Ban mitigates repeated attempts from hostile IPs. Combine both for defense-in-depth.
1) Account lockouts using pam_faillock (modern RHEL/CentOS/Fedora, some modern Debian/Ubuntu)
Example configuration for RHEL/CentOS 7+ (edit /etc/pam.d/password-auth and /etc/pam.d/system-auth). Back up files before editing and test on a non-production host:
Insert near top of the auth stack (preauth):
auth required pam_faillock.so preauth silent deny=5 unlock_time=900 fail_interval=900
Replace the standard auth line with the following ordering snippet (simplified):
auth [success=1 default=bad] pam_unix.so nullok try_first_pass
Insert post-failure handler:
auth sufficient pam_faillock.so authfail deny=5 unlock_time=900 fail_interval=900
And ensure account module is present to reset counters on successful login:
account required pam_faillock.so
Meaningful parameter choices: deny=5 (lock after 5 failed attempts), unlock_time=900 (15 minutes) and fail_interval=900 (failures counted within 15 minutes). For higher assurance, set unlock_time=0 to require administrator reset; document exceptions and break-glass procedures.
2) Legacy systems and pam_tally2
On older Debian/Ubuntu or legacy systems that do not have pam_faillock, pam_tally2 can be used. Typical pam.d lines (example in /etc/pam.d/common-auth):
auth required pam_tally2.so deny=5 even_deny_root unlock_time=900 onerr=fail
Note: pam_tally2 and pam_faillock behave differently; test and pick one consistent solution across your estate to simplify evidence collection.
3) SSH-specific hardening and Fail2Ban for IP banning
In /etc/ssh/sshd_config set conservative SSH parameters: MaxAuthTries 3, PermitRootLogin no (or prohibit-password), PasswordAuthentication no if using keys, and UsePAM yes. Example:
MaxAuthTries 3
PermitRootLogin no
UsePAM yes
Then install and configure Fail2Ban to ban offending IPs. Example jail.local (Debian/Ubuntu or CentOS w/ EPEL):
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log # or /var/log/secure on RHEL
maxretry = 5
bantime = 86400
findtime = 600
This bans an IP for 24 hours after 5 failures in a 10-minute window. Fail2Ban complements account lockouts by protecting against distributed attacks from the same IP range.
Logging, monitoring, and evidence collection for audits
To meet Compliance Framework expectations, configure centralized logging (syslog/rsyslog -> SIEM, Splunk, or cloud logging) to capture /var/log/auth.log or /var/log/secure, and pam_faillock records. Create alerts for repeated lockouts and for admin unlock events. Documentation and evidence should include: change tickets approving config changes, the actual config files (timestamped), test results showing account lockouts, and log extracts demonstrating lockout events.
Small-business real-world scenario
Consider a small defense contractor with 12 Linux servers and ~30 users. Implementation steps: (1) Inventory which servers host CUI and apply stricter policies there, (2) standardize on pam_faillock where available; for older servers, use pam_tally2, (3) deploy Fail2Ban on all externally reachable hosts, (4) set MaxAuthTries=3 and PermitRootLogin=no in sshd_config, (5) configure centralized logging to a small SIEM or cloud log collector and create an alert for >3 lockouts in 15 minutes. Result: attackers face both account lockout and IP banning, reducing brute-force likelihood while the organization keeps records for auditors.
Compliance tips and best practices
- Test changes on a staging host and maintain an emergency “break-glass” admin process to unlock accounts or permit temporary access with strong auditing. - Avoid overly aggressive lockouts for administrative accounts; instead, require multi-factor authentication (MFA) for privileged logins. - Standardize settings across similar systems and document exceptions. - Keep timing and thresholds in your System Security Plan (SSP) and in Standard Operating Procedures (SOPs). - Monitor false positives (e.g., automated services using SSH keys) and whitelist those service accounts or use key-based auth with restricted commands.
Risk of not implementing AC.L2-3.1.8
Not enforcing failed-login thresholds leaves systems vulnerable to automated brute-force and credential-stuffing attacks. An attacker who obtains valid credentials or successfully guesses passwords can access systems containing CUI, leading to data theft, mission impact, and compliance violations. Additionally, lacking logs and documented enforcement increases the chance of failing audits and can result in contractual penalties for small businesses handling DoD-related information.
In summary, implementing failed-login thresholds for Linux and SSH to satisfy AC.L2-3.1.8 requires combining PAM-based account lockouts, SSH hardening, IP-level bans (Fail2Ban), centralized logging, and thorough documentation. For small businesses, prioritize systems that handle CUI, test configurations carefully, document policies and exceptions, and ensure monitoring and evidence collection are in place to demonstrate compliance during assessment.
