Hardening standards

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.

Authentication

• 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.

Authorization

• 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.

Auditing

• 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.

• Was this topic useful?
• Post a comment