About securing Splunk Enterprise with SSL
This section describes the types of Splunk configurations that you might want to secure with SSL.
About the default certificates
Splunk software ships with, and is configured to use, a set of default certificates. These certificates discourage casual snoopers but could still leave you vulnerable, because the root certificate is the same in every Splunk download and anyone with the same root certificate can authenticate.
The default certificates are generated and configured at startup and can be found in
$SPLUNK_HOME/etc/auth/. They are set to expire three years after they are generated and new certificates must be created and configured at that time.
- For information about the default certificate for Splunk Web, see "Turn on encryption (https) with Splunk Web." or "Turn on encryption (https) using web.conf."
- For information about SSL for forwarding with the default certificate, see "Configure Splunk forwarding to use the default certificate."
Ways you can secure Splunk Enterprise
You can apply encryption and/or authentication using your own certificates for:
- Communications between the browser and Splunk Web
- Communication from Splunk forwarders to indexers
- Other types of communication, such as communications between Splunk instances over the management port
The table below describes the most common scenarios and the default SSL settings:
|Type of exchange||Node A function||Node B function||Encryption||Certificate Authentication||Common Name checking||Type of data exchanged|
|Browser to Splunk Web||Browser||Splunk Web||NOT enabled by default||dictated by client (browser)||dictated by client (browser)||configuration and search data|
|Splunk Web to search head||Splunk Web||
||enabled by default||NOT enabled by default||NOT enabled by default||configuration and search data|
||NOT enabled by default||NOT enabled by default||NOT enabled by default||data to be indexed|
|Deployment server to deployment clients||
||enabled by default||NOT enabled by default||NOT enabled by default||configuration data|
||Enabled by default||NOT enabled by default||NOT enabled by default||search data|
|Search head clusters||
||Not enabled by default||NOT enabled by default||NOT enabled by default||cluster data|
|Search head cluster deployer||
||Enabled by default||NOT enabled by default||NOT enabled by default||configuration data|
|Indexer cluster peer nodes||
||NOT enabled by default. You must use the
||NOT enabled by default||NOT enabled by default||replication data|
|Indexer cluster master||
||Enabled by default||NOT enabled by default||NOT enabled by default||cluster data|
Communications between the browser and Splunk Web
Browser to Splunk Web data most commonly consists of search requests and returned data.
Data encryption (HTTPS) can be easily turned on using Splunk Web, or by editing the configuration files. Keep in mind that encryption with the default certificate protects against casual listening but is not fully secure.
For better security, replace the default certificates with certificates signed by a trusted CA. We strongly recommend using CA certs rather than signing your own in this case. Unless you have the ability to add your CA to the certificate stores in every browser that will access Splunk Web, a self-signed certificate is considered untrusted by users' browsers. For more information, see "About securing Splunk Web."
Splunk forwarders to indexers
Data sent from forwarders to indexers is the data that your indexers use for searches and reports. Depending upon your organization and the nature and format of the data being transmitted and Splunk configuration, this data may or may not be readable or sensitive.
Securing sensitive raw data helps to avoid snooping and man-in-the-middle attacks.
You can turn on SSL encryption using the default certificate to provide encryption and compression. However, communication using the default certificate does not provide secure authentication, as the certificate password is supplied with every installation of Splunk software. The default certificates are set to expire three years after initial startup, and forwarder to indexer communications will fail at this point.
For better security, require certificate authentication using a self- or CA-signed certificate. A certificate signed by a known and mutually trusted Certificate Authority is considered more secure by outside parties than a certificate you sign yourself. For more information about using certificates with Splunk forwarders and indexers, see "About securing data from forwarders."
Other SSL communications
Other Splunk communications happen between different instances of Splunk software over the management port, usually but not always in a distributed environment. An example of this is configuration data sent by a deployment server to clients. This type of SSL encryption is enabled by default. For most configurations this is adequate and is the recommended security method. However, if you do need to secure your communications with SSL authentication, we've provided some guidelines to help you in "About securing Splunk to Splunk communication" in this manual.
To learn about more ways to use TLS certificates, see the following topics:
Getting your certificates
If you are experienced with SSL certificates, you can create them as you normally would and go straight to configuring your Splunk instances to use them.
If you need help getting your certificates together, we've provided very simple examples using OpenSSL commands. (OpenSSL ships with Splunk software)
- How to self-sign certificates
- How to get third-party certificates
- How to self-sign certificates for Splunk Web
- How to get third-party certificates for Splunk Web
What to do when you have your certificates
The following topics provide more information about configuring Splunk software to use your certificates once you have them:
Use the getSearchFilter function to filter at search time
About using SSL tools on Windows and Linux
This documentation applies to the following versions of Splunk® Enterprise: 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, 8.0.0, 8.0.1, 8.0.2