Splunk® Enterprise

Admin Manual

Download manual as PDF

Splunk version 4.x reached its End of Life on October 1, 2013. Please see the migration information.
This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Download topic as PDF

Hardening standards

Splunk recommends using the following guidelines to harden your Splunk instances. Following these guidelines reduces the Splunk attack surface and mitigates the risk and impact of most vulnerabilities.

Service accounts

  • Practice the principle of least privilege by running Splunk as an unprivileged user rather than using a privileged account such as root or Administrator.
    • On Unix or Linux, use the "splunk" user created with the PKG or RPM packages, or create your own user that only has privilege and ownership over $SPLUNK_HOME.
    • On Windows, the local system context is often the best choice. However, if you require communication using a windows communication channel, such as WMI, use a restricted access account.

Splunk components

  • Disable all unnecessary Splunk components.
    • For single-server Splunk deployments:
      • Splunk forwarders should not run Splunkweb and should not be configured to receive data on TCP or UDP ports or from other Splunk instances.
    • For multi-server Splunk deployments:
      • Splunk search heads should not receive data on TCP or UDP ports or from other Splunk instances.
      • If users are not logging in to Splunkweb on Splunk indexers in a distributed environment, Splunkweb should be disabled on the indexers.
      • Splunk forwarders should not run Splunkweb and should not be configured to receive data on TCP or UDP ports or from other Splunk instances.

Network access

  • Do not place Splunk on an Internet-facing network segment.
    • This means that Splunk should not be accessible directly from the Internet.
    • Remote users can still access Splunk using a Virtual Private Network.
  • Use a host-based firewall to restrict access to Splunkweb, management, and data ports.
    • End users and administrators need to access Splunkweb (TCP port 8000 by default).
    • Search heads need to access search peers on the Splunk management port (TCP port 8089 by default).
    • Deployment clients need to access the deployment server on the Splunk management port (TCP port 8089 by default).
    • Forwarders need to access the Splunk index server data port (TCP port 9997 by default).
    • Remote CLI calls use the Splunk management port. Consider restricting this port to local calls only, using a host firewall.
    • In most cases, allowing access to Splunk forwarders on any port is not recommended.
  • Install Splunk on an isolated network segment that only trustworthy machines can access.
  • Do not permit Splunk access to the Internet unless access to Splunkbase or inline documentation is a requirement.

Operating System

  • Splunk strongly recommends hardening all Splunk server operating system.
    • If your organization does not have internal hardening standards, Splunk recommends the CIS hardening benchmarks.
    • As a minimum, limit shell/command line access to your Splunk servers.

Availability and reliability

  • Configure redundant Splunk instances, both indexing a copy of the same data.
  • Backup Splunk data and configurations, regularly.
  • Execute a periodic recovery test by attempting to restore Splunk from backup.

Physical security

  • Secure physical access to all Splunk servers.
  • Ensure that Splunk end users practice sound physical and endpoint security.
    • Set a short time-out for Splunkweb user sessions using Manager.

Confidentiality and integrity

  • Use SSL encryption on the Splunkweb, management, and data ports.


  • When installing Splunk, change the default "admin" password the first time you log in.
    • If you have configured Splunk to use LDAP authentication, all local accounts including "admin" are still present and active.
    • If the "admin" account password is subsequently changed back to the default value, you will not be prompted again to change it.
    • Always use a very strong password for any admin account.
  • Use SSL authentication between forwarders and indexers.
  • Use LDAP or other third-party systems to control authentication to Splunk.
    • If you have configured Splunk to use LDAP authentication, all local accounts including "admin" are still present and active by default.
      • To remove all the current local accounts when enabling LDAP authentication:
        • Move the $SPLUNK_HOME/etc/passwd file to passwd.bak.
        • Create a blank $SPLUNK_HOME/etc/passwd file.
        • Restart Splunk.
      • Remember, local Splunk accounts can still be created when Splunk is in LDAP authentication mode.
      • Any local Splunk accounts that must be retained for backup or disaster-recovery should use a very strong password.
    • When using LDAP, make sure your LDAP implementation enforces:
      • Strong password requirements for length and complexity.
      • A low incorrect attempt threshold for password lockout.
  • Do not use the default root certificate or server certificates that ship with Splunk.
    • Either:
      • Generate a unique root certificate and self-signed server certificates.
      • Use your enterprise root certificate authority
      • Use a third-party certificate authority.
    • Make sure you back up the private keys in a secure location.


  • Protect access to Splunk features and data using the Splunk role-based access control.
    • Practice the principle of least privilege by only granting access to features and data based on business justification.
    • Use an approval process to validate access requests to Splunk features and data.


  • Perform a periodic review of Splunk access and audit logs.
  • Perform a periodic review of Splunk server audit and security logs.
  • Perform a periodic review of all Splunk users and roles.

Configuration management

  • Use a configuration management tool, such as subversion, to provide version control for Splunk configurations.
  • Integrate Splunk configuration changes into your existing change management framework.
  • Configure Splunk to monitor its own configuration files and alert on changes.

Client browser

  • Use a current version of a supported browser, such as Firefox or Internet Explorer.
  • Use a client-side JavaScript blocker such as noscript on Firefox or Internet Explorer 8 Filters to help protect against XSS, XSRF, and similar exploits.
  • Ensure that users have the latest Flash version installed.
Configure event hashing
About jobs and job management

This documentation applies to the following versions of Splunk® Enterprise: 4.3, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.3.7


Rschutt, you can always configure Splunk to map roles to users by specifying the user as the group. Instructions on how to do this can be found here: http://docs.splunk.com/Documentation/Splunk/latest/Admin/SetupuserauthenticationwithLDAP#Map_users_directly

August 15, 2011

Rschutt, this is akin to saying that AD isn't secure because AD administrators can add administrators to the AD administrators group. if your LDAP isn't secure, then you have larger problems.

August 15, 2011

LDAP-implementation is NOT secure as Splunk-roles are assigned to LDAP-groups. So anyone who can assign groups to users can assign anyone to the Splunk-admin-role. An enhancement-request is pending under CASE [62163]. This should enable the Splunk-admin to map LDAP-users to Splunk-roles internally ONLY.

August 15, 2011

Was this documentation topic helpful?

Enter your email address, and someone from the documentation team will respond to you:

Please provide your comments here. Ask a question or make a suggestion.

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