Often times users issue * search over a time range. With huge data on the indexes this becomes a problem taking unnecessary resources on splunk indexers. We do control the searches with memory limits. But is there an efficient way stopping the search from issuing/starting at all ?
Can you define what you are trying to do a touch more clearly? Do you not want them doing index=* Or sourcetype=*, or are you trying to not allow wild cards at all? As far as I know you can't restrict wildcard usage by role, but you can restrict search terms by role in user access control, so when a user does wildcard a field their search is limited to what you you say they can be looking for.
We do limit the indexes a user can search depending on his role. When you have terabytes of data, it doesn't make sense when a user just puts a * and nothing else and issue a search. The search will return millions of events before it is auto finalized with several limits we have in place.
I'm trying to stop this search without even getting processed. It just doesn't make sense to issue a search like that in first place.
you can limit the possibilities of user search by defining specific roles with specific limitations for your users (see http://docs.splunk.com/Documentation/Splunk/6.5.2/Security/Aboutusersandroles):
About the first one, the Search filter field can include any of the following search terms:
You cannot block the use of "*"!
Thanks @cusello We do have most if not all of the above measures in place. Nothing stops a user from simply putting a * in the search bar and issue a search. We haven't come across a valid use case in the past several years why anyone wants to just put a * (and nothing else) and search on all the indexes he is allowed to.
So, if you've setup the attribute srchIndexesDefault (Indexes searched by default) to nothing, then users won't be able to search without specifying an index. (you can still maintain access to indexes using srchIndexesAllowed (Indexed allowed to search). If you're looking for a way to enforce they to add sourcetype /host/source or use any other filters in the search, it's purely based on the user's knowledge on how to use Splunk efficiently.
One workaround you may try is to add a srchFilter (default search term that will get added to all searches) as some dummy sourcetype/host/source match (e.g. sourcetype="PleaseSpecifyASourcetype" ), so that if user doesn't specify the sourcetype explicitly search would not return anything. Drawback of this is that many a time people don't know about sourcetype and they just search on index to know about the available sourcetype. For that, they need to run like
index=foo sourcetype=* to see them.
Thanks @somesoni2 We can't enforce the index to be part of search via srchIndexesDefault because the ability to do transacation commands over multiple applications scattered across multiple indexes will be lost. Hence we restrict the list of indexes using srchIndexesAllowed
There are many valid uses cases where an user may/may not want to include index/source/sourcetype in their search. I'm trying to attack only the * search which has been one of our pain points.
My suggestion was to set srchIndexesDefault to blank so that user have to specify the index name for every search. (and it's Searching best practice as well to specify as much metadata fields in the base search as possible). If your users want to search over multiple indexes without specifying the explicit index names, they can still use
index=* to search across all the indexes they have access to (set by
As far as restricting searches with just
*, as @muebel pointed out, there is no native way in Splunk and best option is user awareness. You can setup the alert and disable the user access if they continue to do the same continuously (that threat always works 🙂 ), along with proper training.
Hi gpradeepkumarreddy, I don't believe there is a way of preventing such a search from being issued, so perhaps the most efficient method would be to setup reporting or alerting for users who perform such searches. My guess is that certain users would get into the habit of running these kinds of searches more often than others, and you could remediate it by training.
Please let me know if this helps!
Thanks @muebel. We do this by sending an email automatically to the user when we catch this. With more than 5000 users and constantly adding new users every day, this is a battle. We would like to stop it at root proactively than a reactive measure.