Security

How to prevent users from writing to indexes?

alekksi
Communicator

Hi all,

Currently any user (user,power,admin,whatever) is able to write to an index -- even indexes that they don't have permission to see (!!). We do not want users to be able to have this ability, or we want to grant it only to a specific role -- is there a way to do this?

As far as I can see from documentation and searching online, it is impossible to disallow users from running the 'collect' command. Nor am I able to see a capability to disable writing a scheduled search to a summary index.

That a generic user is able to write data to any index of their choosing we consider to be a security issue and we need to rectify it as soon as possible.

Any help would be greatly appreciated!

Kind regards,
Alex

the_wolverine
Champion

Verified fixed in 6.4, according to the latest answer.

0 Karma

alekksi
Communicator

If there are no capabilities to restrict individual users from writing to any index, then the issue is definitely not fixed.

0 Karma

jbrodsky_splunk
Splunk Employee
Splunk Employee

In Splunk 6.4.0, we added a security check so that if users do not have "read" capability to the summary index they should not be able to write to that summary index via collect. If this is not working for you (after upgrading to 6.4.x) then log a support case and have them reference internal SPL-50063.

the_wolverine
Champion

Was the ability to modify access to the collect command also addressed?

https://answers.splunk.com/answers/128764/restrict-a-users-ability-to-write-to-indexes.html

ddrillic
Ultra Champion

Interesting design question, as writing to the indexes is open, where the user which runs as a forwarder can write to any index, while reading (via roles) is well specified.

0 Karma

mcronkrite
Splunk Employee
Splunk Employee

Limit the access to the indexes that the user can access via their role, and then take away the capability from that role to do any writes. You can also prevent the index from being written to from the Search Head by updating the local search head indexes.conf to have:

isReadOnly = true|false
* Set to true to make an index read-only.
* If true, no new events can be added to the index, but the index is still
  searchable.
* Must restart splunkd after changing this parameter; index reload will not
  suffice.
* Defaults to false

Depending on what you are trying to prevent, either Users being malicious, or users making mistakes.
Using a deployment server to manage forwarders really cuts down on end users being able to change the configs.
To help prevent routing errors with, then also edit the inputs.conf on the indexers and explicitly prevent the search heads from being able to write data to your indexes. (don't block them from writing to _internal though!):

> acceptFrom = <network_acl> ...
* Lists a set of networks or addresses to accept connections from.  These rules
  are separated by commas or spaces
* Each rule can be in the following forms:
    1. A single IPv4 or IPv6 address (examples: "10.1.2.3", "fe80::4a3")
    2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32")
    3. A DNS name, possibly with a '*' used as a wildcard (examples:
       "myhost.example.com", "*.splunk.com")
    4. A single '*' which matches anything
* Entries can also be prefixed with '!' to cause the rule to reject the
  connection.  Rules are applied in order, and the first one to match is
  used.  For example, "!10.1/16, *" will allow connections from everywhere
  except the 10.1.*.* network.
* Defaults to "*" (accept from anywhere)

alekksi
Communicator

Thanks for your response!

Limit the access to the indexes that the user can access via their role, and then take away the capability from that role to do any writes.

So this sentence is rather promising to me. Our current setup is as follows:

User role is mostly default. As per the roles section under authorisation, it has the following capabilities (none are inherited):
accelerate_search
change_own_password
get_metadata
get_typeahead
input_file
list_inputs
output_file
pattern_detection
request_remote_tok
rest_apps_view
rest_properties_get
rest_properties_set
search

The user role also has a number of indexes (upwards of 30) configured in both srchIndexesAllowed and srchIndexesDefault (both the same), but there are easily another 20-30 indexes which are not configured for the default user role. The user role can write to those indexes that have been disallowed -- we have tested with a given user who wrote a log entry from an index they could see into an index they were unable to see, using the collect command.

So my questions would be, with regard to the first sentence, are: Is there another way of limiting role access to a given index? Which capability grants write access to indexes? What capability can be used to disallow access to the 'collect' command?

You can also prevent the index from being written to from the Search Head by updating the local search head indexes.conf to have:

This is a potential idea that we can use, but we'd have to adjust it in a way that kind of moots the point of having a search head cluster. If we were to prevent the search head cluster from writing to indexes, then we would have to set up search heads outside of the cluster to run scheduled searches which then write to summary indexes, as we heavily use the summary indexes. This would mean creating a standalone search head which would be able to do the summary index writing -- however this is something we are trying to avoid, as we are trying to make our Splunk setup as resilient as possible in terms of site failure and failovers: every search head on one site should have a counterpart on the other site, ready to take over automagically.

Depending on what you are trying to prevent, either Users being malicious, or users making mistakes. Using a deployment server to manage forwarders really cuts down on end users being able to change the configs.

We have two deployment servers (active & passive / hot-warm), but most users (apart from on Windows) do not have the user permissions to modify Splunk forwarders or their configs without prior approval and action from the appropriate administrative team.

The network ACL is worth another look from our side, as there are some clear subnet divides that we could enforce, but this is too general a solution, unfortunately.

0 Karma

dwaddle
SplunkTrust
SplunkTrust

What capability can be used to disallow access to the 'collect' command?

This is I think the most central question to this. If there is a capability that enables / disables collect + all of the other si* commands, then that would be ideal. If not, then there is no level to twist here to take the capability away. All of the compensating controls around getting data into splunk are great, but the collect command is kind-of an end run around all that.

dwaddle
SplunkTrust
SplunkTrust

This... this is a really really good question. It also sounds like something that would definitely be worth a support case to get an official answer, a bug filed, and etc.

Get Updates on the Splunk Community!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...