Splunk® Enterprise

Securing Splunk Enterprise

Splunk Enterprise version 7.2 is no longer supported as of April 30, 2021. See the Splunk Software Support Policy for details. For information about upgrading to a supported version, see How to upgrade Splunk Enterprise.

Use network access control lists to protect your deployment

You can limit network access to your Splunk Enterprise deployment by using access control lists (ACLs) in configuration files to restrict incoming network traffic to deployment components such as indexers and search heads.

Splunk Cloud Platform has security safeguards in place that limit access to nearly all components except for Splunk Web from external networks. You can also configure which addresses on your network have access to components of Splunk Cloud Platorm using the Splunk Cloud Platform Admin Config Service (ACS) API.

Configure network ACLs in Splunk Cloud Platform

To learn about how to use the Splunk Cloud Platform ACS API to limit network access to your Splunk Cloud Platform instance, see Configure IP allow lists for Splunk Cloud Platform.

Configure network ACLs in Splunk Enterprise

To configure ACLs to protect a Splunk Enterprise deployment, use the server.conf and inputs.conf configuration files to specify the network IP addresses that the deployment can accept or reject for various communications. It's not possible to perform this configuration with Splunk Web.

When you configure an ACL, you supply one or more IP addresses to determine what the instance is to accept or reject. You separate multiple addresses with either commas or spaces. You can provide the addresses in the following formats:

Type of address Format example
A single IPv4 or IPv6 network address 10.1.2.3, fe80::4a3
A Classless Inter-Domain Routing (CIDR) block of network addresses 10/8 (which stands for "all addresses in the 10.0.0.0 block", fe80:1234/32
A DNS name, potentially using a * (asterisk) as a wildcard myhost.example.com, *.splunk.com
Anything *

To prevent inclusion of an address, place an ! (exclamation point) in front of that address, for example, !10.1/16.

The Splunk platform applies the rules in order, and uses the first rule that matches. For example, !10.1/16, * means to let connections in from any address except those that are in the 10.1.*.* network.

Where to configure network ACLs in Splunk Enterprise

You can secure IP addresses for the following connections by editing the accept_from setting in various configuration files. Where you edit the setting depends on the kind of network access that you want to control. See the following table for information on where you can establish ACLs with the accept_from setting.

Changes to access control lists happen when you reload the Splunk Enterprise configuration.

If you want to Edit this file Add to this stanza Notes
Instruct a node to only accept replicated data from other nodes with specific IP addresses server.conf httpServer If you configure this setting for indexer clusters, you must confirm that you include the IP addresses of all other peers in the cluster.

For more information about clusters, see About clusters and index replication

For more information about the server.conf file, see the server.conf specification file
Restrict TCP communications to specific IP addresses inputs.conf tcp Changes in this file overwrite the output values in the server.conf file if there are conflicts
Restrict TCP communications that use transport layer security (TLS) to specific IP addresses inputs.conf tcp-ssl
Configure your indexer to accept data only from forwarders with specific IP addresses inputs.conf splunktcp Edit the inputs.conf file on the indexer where you want to restrict inbound access.
Restrict User Datagram Protocol (UDP) communications to specific IP addresses inputs.conf UDP For more information about the inputs.conf, see the specification file for inputs.conf.
Last modified on 01 May, 2024
Secure access for Splunk knowledge objects   Set up native Splunk authentication

This documentation applies to the following versions of Splunk® Enterprise: 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.0, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.10, 8.1.11, 8.1.12, 8.1.13, 8.1.14, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.3.0, 9.3.1


Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters