BMCWeb: rate-limit authentication failures

BMCWeb: rate-limit authentication failures

[Joseph Reynolds]

I would like to enhance BMCWeb to rate-limit password-based 
authentication attempts (footnote1) to address [CWE-307][].  [Broken 
Authentication][] is an OWASP top 10 item.  The goal is to protect 
against CWE-307 without causing denial of service.  Specifically, when 
excessive authentication attempts are happening, legitimate users should 
be able to access the BMC (specifically an admin can login), and 
degraded BMC performance is acceptable.

The main idea for the design is to allow authentication at full speed, 
and rate-limit only when needed.   This is consistent with the approach 
OWASP outlines.

Perhaps the design can be as simple as recording the 10 most recent 
authentication failures (steady_clock time only, having them time out 
after a minute) to define "excessive", and using the timestamp of the 
most recent failure to determine when the next attempt will be allowed.  
When authentication is requested but not allowed, return HTTP status 
code 429 (Too Many Requests) with HTTP response header "Retry-After: 
3".  ==> This will slow down attackers (for example, to 30 tries per 
minute, even when multiple connections are used) and allow legitimate 
users to compete for authentication attempts.

However, I think even this apparently simple design might be tricky to 
get right.  Is there an open source solution we can use?  What do you 
think?  Let me know if this is important to you.  I would like to hear 
ideas how to proceed.

- Joseph

<snip/>TL;DR (too long; don't read):

A counterpart to this design is to delay any failed authentication 
attempt for a few seconds.  This is intended to slow down malfunctioning 
network agents that repeatedly fail to authenticate to the BMC.  This 
won't slow down attackers who can use multiple connections to the BMC.

I looked at using Linux-PAM.  For example, [OpenBMC uses pam_tally2][] 
but does not configure account lockouts.  I don't want to pursue using 
the pam_tally2 lockout mechanism because that can lead to denial of 
service.  I believe rate-limiting is a better approach.

I only want to protect access via BMCWeb.  The protection techniques may 
also apply to network IPMI and SSH, but the direction is to disable 
these accesses, so I am less interested.  Access via the BMC's serial 
console would not be protected.  Access via the BMC's host should have 
similar protections, but I am not investigating that now.

CWE-307 is a problem only because OpenBMC offers password-based 
authentication without requiring multi-factor authentication (MFA). 
Disabling password-based auth remains a popular use case, and OpenBMC 
has no MFA capabilities.  So I need CWE-307 protection as a stop-gap 
solution.

References and footnotes:
[CWE-307]: https://cwe.mitre.org/data/definitions/307.html
[OpenBMC uses pam_tally2]: 
https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-extended/pam/libpam/pam.d/common-auth
(footnote1): BMCWeb's password-based authentication includes Basic Auth, 
login via /login, and creating a Redfish session.  It does not include 
authentication via mTLS or using an X-Auth-Token or a cookie from an 
established session.
[Broken Authentication]: 
https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A2-Broken_Authentication

Re: BMCWeb: rate-limit authentication failures

[James Feist]

On 2/4/2020 2:41 PM, Joseph Reynolds wrote:
> I would like to enhance BMCWeb to rate-limit password-based 
> authentication attempts (footnote1) to address [CWE-307][].  [Broken 
> Authentication][] is an OWASP top 10 item.  The goal is to protect 
> against CWE-307 without causing denial of service.  Specifically, when 
> excessive authentication attempts are happening, legitimate users should 
> be able to access the BMC (specifically an admin can login), and 
> degraded BMC performance is acceptable.
> 
> The main idea for the design is to allow authentication at full speed, 
> and rate-limit only when needed.   This is consistent with the approach 
> OWASP outlines.
> 
> Perhaps the design can be as simple as recording the 10 most recent 
> authentication failures (steady_clock time only, having them time out 
> after a minute) to define "excessive", and using the timestamp of the 
> most recent failure to determine when the next attempt will be allowed. 
> When authentication is requested but not allowed, return HTTP status 
> code 429 (Too Many Requests) with HTTP response header "Retry-After: 
> 3".  ==> This will slow down attackers (for example, to 30 tries per 
> minute, even when multiple connections are used) and allow legitimate 
> users to compete for authentication attempts.
> 
> However, I think even this apparently simple design might be tricky to 
> get right.  Is there an open source solution we can use?  What do you 
> think?  Let me know if this is important to you.  I would like to hear 
> ideas how to proceed.

I know we plan to look into this in the near future.

> 
> - Joseph
> 
> <snip/>TL;DR (too long; don't read):
> 
> A counterpart to this design is to delay any failed authentication 
> attempt for a few seconds.  This is intended to slow down malfunctioning 
> network agents that repeatedly fail to authenticate to the BMC.  This 
> won't slow down attackers who can use multiple connections to the BMC.
> 
> I looked at using Linux-PAM.  For example, [OpenBMC uses pam_tally2][] 

Did you look into Pam_abl? Haven't looked much into it, but reading a 
couple articles it looks promising. Using lockouts based on host instead 
of account seems like it would be a good approach.

> but does not configure account lockouts.  I don't want to pursue using 
> the pam_tally2 lockout mechanism because that can lead to denial of 
> service.  I believe rate-limiting is a better approach.
> 
> I only want to protect access via BMCWeb.  The protection techniques may 
> also apply to network IPMI and SSH, but the direction is to disable 
> these accesses, so I am less interested.  Access via the BMC's serial 
> console would not be protected.  Access via the BMC's host should have 
> similar protections, but I am not investigating that now.
> 
> CWE-307 is a problem only because OpenBMC offers password-based 
> authentication without requiring multi-factor authentication (MFA). 
> Disabling password-based auth remains a popular use case, and OpenBMC 
> has no MFA capabilities.  So I need CWE-307 protection as a stop-gap 
> solution.
> 
> References and footnotes:
> [CWE-307]: https://cwe.mitre.org/data/definitions/307.html
> [OpenBMC uses pam_tally2]: 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-extended/pam/libpam/pam.d/common-auth 
> 
> (footnote1): BMCWeb's password-based authentication includes Basic Auth, 
> login via /login, and creating a Redfish session.  It does not include 
> authentication via mTLS or using an X-Auth-Token or a cookie from an 
> established session.
> [Broken Authentication]: 
> https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A2-Broken_Authentication 
>