CARVIEW |
Securing Splunk Enterprise
- Install Splunk Enterprise securely
- Create secure administrator credentials
- About TLS encryption and cipher suites
- Securing Splunk Enterprise with FIPS
- About default certificate authentication
- Harden the Splunk Enterprise installation directory on Windows
- Secure Splunk Enterprise on your network
- Disable unnecessary Splunk Enterprise components
- Secure Splunk Enterprise service accounts
- Deploy secure passwords across multiple servers
- Harden the network port that App Key Value Store uses
- Some best practices for your servers and operating system
- Password best practices for administrators
- Configure Splunk password policies
- Configure a Splunk Enterprise password policy using the Authentication.conf configuration file
- Password best practices for users
- Unlock a user account
- Change a user password
- Manage out-of-sync passwords in a search head cluster
- Use access control to secure Splunk data
- About user authentication
- About configuring role-based user access
- Define roles on the Splunk platform with capabilities
- Add and edit users
- Create and manage roles with Splunk Web
- Add and edit roles with authorize.conf
- Configure access to manager consoles and apps in Splunk Enterprise
- Find existing users and roles
- Delete all user accounts on Splunk Enterprise
- Secure access for Splunk knowledge objects
- Use network access control lists to protect your deployment
- Set up user authentication with LDAP
- Manage Splunk user roles with LDAP
- LDAP prerequisites and considerations
- Secure LDAP authentication with transport layer security (TLS) certificates
- How the Splunk platform works with multiple LDAP servers for authentication
- Configure LDAP with Splunk Web
- Map LDAP groups to Splunk roles in Splunk Web
- Configure LDAP using configuration files
- Map LDAP groups and users to Splunk roles using configuration files
- Test your LDAP configuration on Splunk Enterprise
- Change authentication schemes from native to LDAP on Splunk Enterprise
- Remove an LDAP user safely on Splunk Enterprise
- About multifactor authentication with Duo Security
- Configure Splunk Enterprise to use Duo Security multifactor authentication
- Configure Duo multifactor authentication for Splunk Enterprise in the configuration file
- About multifactor authentication with RSA Authentication Manager
- Configure RSA authentication from Splunk Web
- Configure Splunk Enterprise to use RSA Authentication Manager multifactor authentication via the REST endpoint
- Configure Splunk Enterprise to use RSA Authentication Manager multifactor authentication in the configuration file
- User experience when logging into a Splunk instance configured with RSA multifactor authentication
- Configure single sign-on with SAML
- Configure SSO with PingIdentity as your SAML identity provider
- Configure SSO with Okta as your identity provider
- Configure SSO with Microsoft Azure AD or AD FS as your Identity Provider
- Configure SSO with OneLogin as your identity provider
- Configure SSO with Optimal as your identity provider
- Configure SSO in Computer Associates (CA) SiteMinder
- Secure SSO with TLS certificates
- Configuring SAML in a search head cluster
- Configure Ping Identity with leaf or intermediate SSL certificate chains
- Configure SAML SSO for other IdPs
- Configure authentication extensions for SAML tokens
- Configure advanced settings for SSO
- Map groups on a SAML identity provider to Splunk roles
- Modify or remove role mappings
- Configure SAML SSO in the configuration files
- Best practices for using SAML as an authentication scheme for single-sign on
- Troubleshoot SAML SSO
- About securing inter-Splunk communication
- Configure secure communications between Splunk instances with updated cipher suite and message authentication code
- Securing distributed search heads and peers
- Secure deployment servers and clients using certificate authentication
- Secure Splunk Enterprise services with pass4SymmKey
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.
|
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.1.7, 9.1.8, 9.1.9, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.2.5, 9.2.6, 9.3.0, 9.3.1, 9.3.2, 9.3.3, 9.3.4, 9.4.0, 9.4.1, 9.4.2
Comments
Use network access control lists to protect your Splunk Enterprise deployment
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.
Your Comment Has Been Posted Above
Feedback submitted, thanks!