Enable Kibana to Rate Limit Login Attempts

[elasticmachine]

Original comment by @epixa:

Taken from #11335

---

Feature Request and Motivation

Is it possible to rate limit the logins of users who've made a certain number of failed login attempts to Kibana (or Elasticsearch)? LDAP and ActiveDirectory login attempts can be rate limited externally, but I don't see any options for rate limiting the file or native realms.

The threat here is that a malicious user who has access to Kibana (or Elasticsearch) can attempt to brute-force the credentials of users in the file or native realms. This password guessing may be even more effective due to the fact that there are a number of known, built-in usernames, like elastic or kibana.

A malicious person gaining access to one of these users could be especially dangerous, as in practice they may be used for service-type accounts, which tend to be highly privileged.

My Search for Existing Support

I see that X-Pack can log a number of relevant auditing events, such as authentication_failed or realm_authentication_failed. It seems like X-Pack already has access to the type of information needed to rate limit failed login attempts.

However, I don't see any security settings that an administrator can configure for Elastic Stack to actively change how it responds to a large number of failed login attempts for a particular user account.

Desired Feature Usage

Ideally there'd be several additional security settings for Kibana and Elasticsearch that Elastic Stack administrators could configure. The exact details require more thought, but a first pass might look something like the following (overall structure borrowed from the LINK REDACTED docs):

xpack.security.authc:
  realms:

    file:
      type: file
      order: 0
      # More than this number of consecutive failed login attempts causes the account to 
      # be locked, requiring action by an admin user to unlock it.
      max_failed_login_attempts: 15

      # After this many failed consecutive logins, either make the user wait a finite 
      # amount of time, such as 1 minute or 5 minutes before they can login again, or, 
      # cause the server to respond increasingly slowly with each additional failed login 
      # (such as exponential backoff timing).
      rate_limit_after_n_failed_logins: 5

    native:
      # Same additional options as described above.

[elasticmachine]

Original comment by @MorrieAtElastic:

A user is also requesting logon-error limitation to Kibana. They additionally request a "human being verification" facility be installed on the Kibana login screen so that users must prove that they are no robots when logging into Kibana. Let me know if I need to provide a separate enhancement request for this facility.

[elasticmachine]

Original comment by @epixa:

A separate enhancement request would be good for that

[mfeldmanBT]

When upgrading the Native Realm, please add the ability to force the user to change the password at first login.

[jesuslinares]

Hey guys, any update on this?. This is a requirement for compliance regulation like PCI DSS.

Thanks.

[Jim1975]

Hey guys, any update this ?

[kunisen]

any update on this?

[legrego]

The requirements here seem a bit "squishy". There are asks for rate limiting in Kibana and/or Elasticsearch, but it would be good to understand exactly where we want this rate limiting to happen.

If we want Elasticsearch to perform the rate limiting, then we should transfer this issue to the Elasticsearch repo so that we can discuss and prioritize with the appropriate teams.

If we want Kibana to perform the rate limiting, then we can continue the discussion here. We haven't done much analysis on this recently, but I expect that we wouldn't be able to investigate this on the Kibana side until we implement #17870

It's important to note that if Kibana performs the rate limiting, that this won't prevent users from trying to brute-force passwords by authenticating against Elasticsearch directly. This might be fine for some users, but I imagine others would prefer a more holistic, stack-wide solution. In other words, if Elasticsearch performs the rate limiting, then Kibana will get this for "free", as well as any other stack component which authenticates to the stack.

[wolframhaussig]

@legrego Your last paragraph is the important one: I do not care on which application the login happens - we want to prevent brute force attacks. Therefore, ElasticSearch is the only place this can happen.
I guess this will be true for API keys too?

[legrego]

@legrego Your last paragraph is the important one: I do not care on which application the login happens - we want to prevent brute force attacks. Therefore, ElasticSearch is the only place this can happen.
I guess this will be true for API keys too?

API Keys are a bit different in that you don't provide a corresponding username when you attempt to authenticate with an API Key. The mechanism for detecting a brute-force attack would have to be different. Rate-limiting an invalid API Key is not very useful, because there's nothing you can do to make that key valid.

With user/pass combinations, you can try various passwords for the same user, so we at least have a username to track authentication attempts for in this scenario. This wouldn't prevent password spraying attacks, but multi-factor authentication is a good mitigation for that.

[gcrompton-novetta]

I will follow up periodically to check for updates.