Prevent searches using certain patterns

1

Hi
Our users do not want to understand and often ask general queries like: *:* or *logs*.
Such requests touch all of our logs and cause our cluster to crash.
Is there a chance to block the creation or search of such index templates. But at the same time, searching for narrower patterns should work, for example *logs-aaa*

{“customer_id”: “6c4a385b-2ae8-4f02-a9cd-ef24addfb5b3”, “subscription_id”: “32d4073f-dc2f-4056-a868-842727c637cd”}

2

Interesting problem @driveirk.

You might have a hope with the new variable functions (i.e. using a regex to intercept a pattern and replace it what you don’t want with some really long garbage which is guaranteed to match no index)

What are the minimum criteria for allowing a double-wildcard in your business case?

  • *:* :x:
  • *logs* :x:
  • *logs-aaa* :white_check_mark: what is aaa?

We can give you a pre-build with this feature to test if you want.

3

Sorry @sscarduzio , I was on vacation and missed your reply.
Thanks for the link with regexps, I’ll read it, maybe this will be enough for us at first.

In general the conditions are:

  1. minimum 12 characters.
  2. according to the template *:*logs-(any 3 characters)*

If you can achieve any of these criteria, that will be great. But if you can do 2 at once it will be great.

ps:
aaa - any 3 characters

4

you can use replace_all to neutralise the attempt to access to indices that you don’t permit.

indices: [ '*#{replace_all( "^.{0,11}$" , "group")}#{replace_all( "<any other pattern>" , ".dev-null")} ' ]

Then we need to find a way to match that pattern, negate it and replace it.

Or we implement a indices_re with capability to match regular expressions? @coutoPL I need your input here

5

@sscarduzio the replace_all is the dynamic variable function. It’s allowed only to be used with ROR’s dynamic variables.

It looks like we could implement the indices_re or introduce regex pattern into the existing rule. But keep in mind that the indices rule for RO request doesn’t block, but filter the indices only. Here we want to block some requests according to some rules on indices names.

Maybe we should focus on search requests only.

6

You are correct, if the block type is “allow” (default type) the indices rule is:

  • if the requested indices are all allowed → allow request
  • if the requested indices contain some allowed indices → filter allowed indices and allow the request
  • if the requested indices do not contain any allowed indices → return empty search result

But what happens if you put an indices rule in a type: forbid block?

About the introduction of the regex in indices rule. Do you see it can introduce particular complications?

7

Thanks for the advice @coutoPL . I’ll test with a redirect.

In general, it’s enough for me to prohibit the creation of patterns in kibana. Because dashboards that use this pattern cause problems.
Initially, I thought that this would be a list of patterns that cannot be created.
Can this be done with a kibana-only setting?
PS
Sorry for not writing this earlier.

8

But what happens if you put an indices rule in a type: forbid block?

ACL is evaluated block by block. When a block is matched, the evaluation of further blocks is stopped (this is not obviously true for the login request, where all blocks are evaluated in parallel and results are collected from the matched blocks … but let’s not bother with this now).

Then when we have a result of ACL evaluation, which is a matched block or mismatch result (no block matched) we take into consideration the type:

  1. if type: allow and there is a matched block, then allow processing; otherwise - forbid
  2. if type: forbid and there is a matched block, then forbid processing; otherwise - allow

As you can see, the indices rule semantics doesn’t matter much (I recall - the semantics is “filtering”, not “blocking” … so it’s almost always matched (for RO requests)).

About the introduction of the regex in indices rule. Do you see it can introduce particular complications?

I think it would be a problem with it. But it requires deeper analysis. Will back to you with it.

1 Like