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!
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.
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)
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):
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.
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.
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.
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.