Splunk® Enterprise Security

Installation and Upgrade Manual

Download manual as PDF

Download topic as PDF

Install Splunk Enterprise Security in a search head cluster environment

Splunk Enterprise Security has specific requirements and processes for implementing search head clustering.

If you are installing Enterprise Security on an existing search head cluster environment which might have other apps deployed already, all of the steps in this section apply. Be careful to not delete or remove any existing content in the $SPLUNK_HOME/etc/shcluster/apps folder.

Prerequisites for installing Enterprise Security in a search head cluster environment

Splunk Enterprise Security supports installation on Linux-based search head clusters only. At this time, Windows search head clusters are not supported by Splunk Enterprise Security.

Before installing Enterprise Security in a search head cluster environment, verify that you have:

  • One deployer
  • The same version of Splunk Enterprise on the deployer and search head cluster nodes
  • The same app versions of any other apps on the deployer and search head cluster nodes (not yet including Enterprise Security)
  • The backup of etc/shcluster/apps on the deployer before installing Enterprise Security
  • The backup of etc/apps from one of search head cluster nodes
  • The backup of the KVstore from one of search head cluster nodes
  • Verify that your server.conf shclustering configuration is in $SPLUNK_HOME/etc/system/local/server.conf or is in an app that exports the server configuration globally via metadata:
    [server]
    export = system

Installing Enterprise Security in a search head cluster environment

The installer dynamically detects if you're installing in a single search head environment or search head cluster environment. The installer is also bigger than the default upload limit for Splunk Web. To install Enterprise Security on a search head cluster:

  1. Prepare the deployer per the prerequisites.
  2. Install Enterprise Security on the deployer.
    1. Increase the Splunk Web upload limit by creating a file called $SPLUNK_HOME/etc/system/local/web.conf with the following stanza.
      [settings]
      max_upload_size = 1000 // increases SplunkWeb upload limit to 1GB
    2. On the Splunk toolbar, select Apps > Manage Apps and click Install App from File.
    3. Click Choose File and select the Splunk Enterprise Security product file.
    4. Click Upload to begin the installation.
    5. Click Continue to app setup page

      Note the message that Enterprise Security is being installed on the deployer of a search head cluster environment and that technology add-ons will not be installed as part of the post-install configuration.

  3. Click Start Configuration Process.
  4. Wait for the process to complete.
  5. Use the deployer to deploy Enterprise Security to the cluster members. From the deployer, run this command:
    splunk apply shcluster-bundle


To verify that Enterprise Security is deployed to the cluster members:

  • From the GUI of a cluster member, you can check the Help > About menu to check the version number.
  • From the CLI of a cluster member, you can check the /etc/apps directory to verify the supporting add-ons and domain add-ons for Enterprise Security: DA-ESS-AccessProtection, DA-ESS-EndpointProtection, DA-ESS-IdentityManagement, DA-ESS-NetworkProtection, DA-ESS-ThreatIntelligence, SA-AccessProtection, SA-AuditAndDataProtection, SA-EndpointProtection, SA-IdentityManagement, SA-NetworkProtection, SA-ThreatIntelligence, SA-UEBA, SA-Utils, Splunk_DA-ESS_PCICompliance, SplunkEnterpriseSecuritySuite, Splunk_SA_CIM, Splunk_SA_ExtremeSearch
  • From the CLI of a cluster member, you can check the $SPLUNK_HOME/etc/apps/SplunkEnterpriseSecuritySuite/local/inputs.conf file to see that the data model accelerations settings are enabled.


Although technology add-ons are bundled in the installer, they are not deployed as part of the installation process. You must deploy them manually if you want to use them. See Deploy add-ons included with Splunk Enterprise Security.

Managing configuration changes in a search head cluster

Some system configuration changes must be deployed using the deployer.

  1. Instead of making the changes on a search head cluster member, make the changes on a deployer.
  2. Migrate the necessary files to the search head cluster deployer.
  3. Deploy the updated configuration to the search head cluster.

Configuration changes that must be deployed using the deployer:

Configuration change File modified
Enable or disable indexed real-time searches on the General Settings page. inputs.conf
Modify the indexed real-time disk sync delay on the General Settings page. inputs.conf
Send notable events to Splunk UBA on the UBA Setup page. outputs.conf

Most configuration changes that you make in a search head cluster replicate automatically to other search head cluster members. For example:

  • Add, modify, and disable threat intelligence sources
  • Add, modify, and disable asset and identity source lists
  • Changes to the user interface
  • Changes to searches

See How configuration changes propagate across the search head cluster in the Distributed Search Manual.

Migrate an existing search head to a search head cluster

An Enterprise Security standalone search head or search head pool member cannot be added to a search head cluster. To migrate ES configurations to a search head cluster:

  1. Identify any custom configurations and modifications in the prior ES installation. Check to make sure there is no local copy of ess_setup.conf that could conflict with the default one when you deploy Enterprise Security to the cluster.
  2. Implement a new search head cluster.
  3. Deploy the latest version of Enterprise Security on the search head cluster.
  4. Review and migrate the customized configurations to the search head cluster deployer for replication to the cluster members.
  5. Shut down the old ES search head.

For more information, see the topic Migrate from a standalone search head to a search head cluster in the Splunk Enterprise Distributed Search Manual.

For assistance in planning a Splunk Enterprise Security deployment migration, contact Splunk Professional Services.

Back up and restore Splunk Enterprise Security in a search head cluster environment

Back up and restore a Splunk Enterprise Security search head cluster (SHC) environment with at least three SHC nodes. All of the nodes in the SHC must be running the same version of Splunk Enterprise Security. Restoring an SHC environment might be necessary in the event of a disaster.

Take regular backups from the SHC, so that you have a backup from a time when the environment is healthy. For example, you could automate taking backups every hour. Choose a frequency of backups based on recovery point objectives.

To check if your environment is healthy, you can use one of the following methods:

  • CLI command: ./splunk show shcluster-status –verbose
  • API: /services/shcluster/status?advanced=1

In the output, look for the following fields:

Field Description
dynamic_captain Whether the cluster has a dynamically elected captain.
stable_captain Whether the cluster captain is in a stable state.
service_ready_flag Whether the cluster has enough members to support replication factor.
splunk_version Whether all members, including the cluster master, are running Splunk version 7.1.0.
out_of_sync Whether all nodes are currently in-sync.

Back up a search head cluster environment

Back up an SHC environment by backing up the KV store, the deployer, and the SHC nodes. The backup procedure does not require shutting down the SHC cluster or any node in the cluster.

Back up the KV store

To back up the KV store, run the following command from the CLI from the SHC node with the most recent data:

splunk backup kvstore -auth "admin:<password>"

This command creates an archive file in the $SPLUNK_HOME/var/lib/splunk/kvstorebackup directory. For example, the file might be named kvdump_example.tar.gz.

Back up the deployer and search head cluster nodes

  1. On the deployer, back up the files in the $SPLUNK_HOME/etc/shcluster directory.
  2. On the SHC node with the most recent data, note the GUID from the shclustering stanza from the $SPLUNK_HOME/etc/system/local/server.conf file. This information is necessary during the restore process.
  3. On the SHC node with the most recent data, back up the files in the $SPLUNK_HOME/var/run/splunk/snapshot/$LATEST_TIME-$CHECKSUM.bundle bundle.
  4. Create a tar.gz file from these backups.

Restore from a backup of a search head cluster environment

You need the following information to restore from a backup:

  • The GUID from the server.conf file from one of the SHC members from before you begin restoring.

    After your restore the cluster, the restored cluster will have the same GUID as the cluster that was backed up.

  • A backup of the deployer.
  • A backup of the SHC node with the most recent data.
  • A backup of the KV store from the SHC node with the most recent data.

The restore procedure requires the SHC to be shut down, but not the KV store.

Restore the deployer

  1. On the deployer, extract the deployer backup file to the $SPLUNK_HOME/etc/shcluster directory.
  2. Apply the bundle with the following command:
    splunk apply shcluster-bundle

Restore the search head cluster nodes

Complete the following steps on each SHC node that you want to restore:

  1. Run the following command to stop Splunk Enterprise Security:
    stop splunk
  2. Create a temporary folder and name it temp.
  3. Extract the SHC node backup file to the temp directory.
  4. Move the config.bundle file from the temp directory to the $SPLUNK_HOME/etc directory.
  5. Extract the config.bundle file to the $SPLUNK_HOME/etc directory.

Restore the KV store

  1. On an SHC node, check the $SPLUNK_HOME/var/lib/splunk/kvstorebackup directory to make sure that the kvdump_example.tar.gz backup file that you want to use to restore is there. If it is not in that directory, manually copy your tar.gz file to that location. Note that the KV store backup file is not automatically replicated across each SHC member.
  2. Ensure that Splunk Enterprise Security is installed. The collections.conf file is necessary to complete the restore.
  3. Run the following command to restore the KV store:
    splunk restore kvstore -archiveName kvdump_example.tar.gz
  4. Restore the snapshot bundle by extracting the backup tar file from the $SPLUNK_HOME/var/run/splunk/snapshot directory to the $SPLUNK_HOME/etc directory.
  5. Repeat these steps on each SHC node that you want to restore. Restoring the KV store on one SHC node does not cause the KV store to automatically replicate across each SHC member.

Entries that are present in both the current KV store and in the backup are updated and replaced by the entry in the backup. Entries that are in the current KV store but not in the backup are not deleted or affected in any way.

Complete restoring the search head cluster environment

Finish restoring Splunk Enterprise Security from backup in an SHC environment.

  1. In the $SPLUNK_HOME/etc/system/local/server.conf file, locate the shclustering stanza.
  2. Update the field ID in this stanza with the GUID copied from the server.conf file during backup.
  3. Run the following command to restart Splunk:
    splunk restart

Restore incident review history from internal audit logs

In the event that the backup process was not established prior to a data loss event with the KVStore, some of the information pertaining to incident review history can still be recovered using internal logs, as dictated by index _audit retention settings.

earliest=-30d index=_audit sourcetype=incident_review | rex "@@\w+,(?<rule_name>[^,]+),(?<status>[^,]*),(?<owner>[^,]*),(?<urgency>[^,]*),(?<comment>.*),(?<user>[^,]+), (?<something>[^,]+)" | eval time=_time | table comment owner rule_id rule_name status time urgency user | outputlookup append=t incident_review_lookup_REMOVE_FOR_SAFETY

PREVIOUS
Install Splunk Enterprise Security
  NEXT
Deploy add-ons included with Splunk Enterprise Security

This documentation applies to the following versions of Splunk® Enterprise Security: 5.3.0, 5.3.1


Comments

Thanks @Vskoryk! I followed up with an email & am making updates shortly.

Lkutch splunk, Splunker
June 4, 2019

In the event backup process was not established prior to data loss event with KVStore, some of the information pertaining to incident review history can still be recovered using internal logs. as dictated by index _audit retention settings.

<code>earliest=-30d index=_audit sourcetype=incident_review
| rex "@@\w+,(?<rule_name>[^,]+),(?<status>[^,]*),(?<owner>[^,]*),(?<urgency>[^,]*),(?<comment>.*),(?<user>[^,]+),(?<something>[^,]+)"
| eval time=_time
| table comment owner rule_id rule_name status time urgency user

| outputlookup append=t incident_review_lookup_REMOVE_FOR_SAFETY</code>

Vskoryk splunk, Splunker
June 2, 2019

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