bmcweb 30 second lockout

Neil Bradley Neil_Bradley at phoenix.com
Thu Sep 10 09:26:44 AEST 2020


Thanks Joseph! I'll look at this in more detail in a bit but I noticed your comments here:

" This issue is to add capability for "authentication rate limiting" for BMCWeb (login and Basic Auth), SSH login, and ideally for IPMI authentication. This capability is to be independent from account lockouts, specifically so someone could use the auth rate limiting as an effective defense and not need to lock accounts."

This is precisely what I was getting at. I'm not a fan of lockouts generally because they can be abused (depending upon implementation of course), and adding in auth rate limiting (just delaying a few seconds when credentials are wrong) winds up making brute force attacks ineffective.

-->Neil


-----Original Message-----
From: Joseph Reynolds <jrey at linux.ibm.com> 
Sent: Wednesday, September 9, 2020 4:21 PM
To: Neil Bradley <Neil_Bradley at phoenix.com>; OpenBMC Maillist <openbmc at lists.ozlabs.org>
Subject: Re: bmcweb 30 second lockout

On 9/9/20 5:13 PM, Neil Bradley wrote:
>
> I had recently read somewhere on the OpenBMC mailing list (forgive me, 
> as I can't find it anywhere now) recently indicating that there'd be a
> 30 second lockout for a given user if there were 3 consecutive failed 
> login attempts. My question is firstly, is this the case, and 
> secondly, is it tied to the user globally regardless of connection or 
> is it per user and connection? The reason I ask is that the former 
> would still allow for a denial of service attack and want to make sure 
> that's not actually the case.
>

I can think of two items:

1. I had pushed an experimental gerrit code review to do what you described.
Here: https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/31841
My idea has not gained much traction and is recorded here: 
https://github.com/ibm-openbmc/dev/issues/2434
and here: https://github.com/linux-pam/linux-pam/issues/216
and here: https://github.com/deksai/pam_abl/issues/4
and other places.
If this ever gets merged, it would NOT the be default behavior.

2. The user lockouts for failed authentication attempts is handled by 
pam_tally2 and controlled by Redfish APIs.
See 
https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-extended/pam/libpam/pam.d/common-auth
In pam.d/common-auth, the default pam_tally2 deny=0 means "accounts are 
never locked because of failed authentication attempts".

The Redfish APIs are implemented here: 
https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/account_service.hpp
Specifically, PATCHing /redfish/v1/AccountService/ property 
AccountLockoutDurationor AccountLockoutThreshold invokes a D-Bus method 
which ultimately modifies the pam.d/common-auth config file above.

Note that downstream projects may typically want to modify these default 
settings.

3. I don't think you mean this: There is a current code review for a 
BMCWeb enhancement to allow the BMC admin to control the idle session 
SessionTimeout property.  The minimum is 30 seconds. See 
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/36016

- Joseph

> Thanks!
>
> àNeil
>



More information about the openbmc mailing list