openstack/openstack-ansible-security
Code Issues Proposed changes
9efb8153f1
openstack-ansible-security/doc/metadata/rhel6/V-38501.rst
Major Hayden 3c19f00a7f [Docs] Metadata cleanup 
This patch adds the right tags to each piece of metadata and corrects
small errors found in the deployer notes.

Closes-bug: 1595669
Change-Id: Ic04aaad85ebf111be5a0bdb01a350442fdea1433
2016-09-12 14:27:49 -05:00

1.8 KiB
Raw Blame History

---id: V-38501 status: opt-in tag: auth ---

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: 900

NOTE: 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.