e57593dfd4
With the upcoming changes to rebase onto the RHEL 7 STIG controls, there needs to be a new solution for documentation that is easier to manage and filter. This patch automates the generation of the STIG control documentation in the following way: * A Sphinx extension runs early in the doc build process that writes all of the individual STIG control docs as well as ToC pages. * ToC pages are now sorted by severity, tag, and implementation status. * A giant listing of controls is easier to navigate now. * Docs are generated from metadata in the /doc/metadata directory. New documentation only needs to be added there. (Will explain this in the developer notes in a subsequent patch.) Implements: blueprint security-rhel7-stig Change-Id: I455af1121049f52193e98e2c9cb1ba5d4c292386
1.8 KiB
---id: V-38501 status: exception tag: misc ---
Exception and opt-in alternative
Adjusting PAM configurations is very risky since it affects how all
users authenticate. In addition, pam_faillock.so isn't
available in Ubuntu.
Another option is to utilize pam_tally to deny logins
after failed attempts. Adjusting PAM configurations automatically can
disrupt the operation of production systems, so this is left up to the
deployer to configure. For more details on how to configure
pam_tally, refer to this
AskUbuntu article about pam_tally.
Another alternative is fail2ban. Read the notes below for more tails on this option.
The Ansible tasks will install fail2ban and configure it to ban IP addresses using the following logic
- The IP has attempted three logins in the last 10 minutes and all have failed
- That IP will be banned for 15 minutes (via iptables rules)
Deployers must opt-in for fail2ban to be installed and configured. To
opt-in, set the security_install_fail2ban Ansible variable
to yes. The time period for bans can also be configured (in
seconds) via tha security_fail2ban_bantime variable:
security_install_fail2ban: yes
security_fail2ban_bantime: 900NOTE: Fail2ban can only review authentication attempts for services that listen on the network, such as ssh. It has no control over physical consoles. Deployers are strongly urged to use stong physical security policies to prevent unauthorized users from accessing server consoles. In addition, deployers must secure out-of-band access methods, like IPMI, as they can be vectors for physical console access as well.