Splunk® SOAR (On-premises)

Install and Upgrade Splunk SOAR (On-premises)

The classic playbook editor will be deprecated in early 2025. Convert your classic playbooks to modern mode.
After the future removal of the classic playbook editor, your existing classic playbooks will continue to run, However, you will no longer be able to visualize or modify existing classic playbooks.
For details, see:
This documentation does not apply to the most recent version of Splunk® SOAR (On-premises). For documentation on the most recent version, go to the latest release.

Set up an external PostgreSQL server

uses a PostgreSQL 11 database. In many installations, the database runs on the same server as . It is possible to put the database on its own server. For more information about configuring and operating a PostgreSQL database, consult the PostgreSQL website and their documentation.

These instructions are written using PostgreSQL version 11.16. You may use any PostgreSQL 11.x release with Splunk SOAR (On-premises) If you do use a different 11.x release, consult consult the documentation on the PostgreSQL website. If you choose to use a release other than PostgreSQL 11.16, you must to use matching parameters for your release where PostgreSQL 11.16 is specified in these instructions.

Limited Support for PostgreSQL 12

If your organization requires PostgreSQL 12, can provide limited support. Follow the directions in this topic, substituting PostgreSQL 12.X for PostgreSQL 11.X.

If you choose to use PostgreSQL 12.X instead of PostgreSQL 11.X, you must be aware of the following limitations:

  • PostgreSQL 12 is only supported for new deployments. Do not upgrade an existing external PostgreSQL 11.X database to PostgreSQL 12.X.
  • PostgreSQL 12 is only supported as an external service. Do not upgrade the embedded PostgreSQL 11 database to PostgreSQL 12.
  • You cannot use the following features of Splunk SOAR (On-Premises) if you use PostgreSQL 12:
    • Backup and restore. You must use another solution to backup or restore your PostgreSQL 12 database.
    • Warm standby

Install and configure PostgreSQL

If you run the PostgreSQL database on its own server, install and configure PostgreSQL before you install Splunk SOAR (On-premises).

These instructions are based on CentOS 7 or Red Hat Enterprise Linux 7. If you choose to to install PostgreSQL on another operating system, consult the documentation on the PostgreSQL website.

  1. Install one of the operating systems supported by PostgreSQL 11. PostgreSQL 11.16 is recommended, but you may use any release of PostgreSQL 11.x. Configure the operating system according to your organization's requirements. See Supported Platforms on PostgreSQL.org.
  2. Update the kernel semaphore parameters and refresh the system configuration.
    echo "kernel.sem=250 32000 32 5000" >> /etc/sysctl.conf 
    sysctl --system
    
  3. Configure your firewall to allow access. For a complete list of ports, see required ports.
  4. Add any additional yum repositories that you need. Use the tool on the Linux downloads (Red Hat family) page to identify the correct repository for your architecture and operating system combination.
    yum install <URL>
  5. Install the PostgreSQL server.
    yum install postgresql11-server-11.16
  6. Initialize the PostgreSQL database.
    /usr/pgsql-11/bin/postgresql-11-setup initdb
  7. Set PostgreSQL to start when the system starts.
    systemctl enable postgresql-11
  8. Start the PostgreSQL database.
    systemctl start postgresql-11
  9. Change to the postgres user.
    su - postgres
  10. Change to the PostgreSQL data directory.
    cd /var/lib/pgsql/11
  11. Generate the SSL certificate PostgreSQL uses.
    openssl req -new -x509 -days 3650 -nodes -text -out server.crt -keyout server.key -subj "/CN=postgres.cluster1"

    You can use an SSL certificate purchased from a Certificate Authority instead of generating a self-signed certificate.

  12. Set the permissions on the server.key file.
    chmod og-rwx server.key
  13. Run a PostgreSQL shell as the postgres user.

    You should already be the postgres user.

    psql
  14. Set the postgres user password, if it has not already been set.
    ALTER USER postgres PASSWORD '<postgrespassword>';
  15. Create the pgbouncer user.
    CREATE USER pgbouncer PASSWORD '<pgbouncerpassword>';
  16. Set PostgreSQL to use SSL. Provide the keys and cipher level.
    ALTER SYSTEM SET ssl = on; 
    ALTER SYSTEM SET ssl_cert_file = '/var/lib/pgsql/11/server.crt'; 
    ALTER SYSTEM SET ssl_key_file = '/var/lib/pgsql/11/server.key'; 
    ALTER SYSTEM SET ssl_ciphers = 'HIGH:+3DES:!aNULL';
    
  17. Exit the PostgreSQL shell by typing CTRL+D.
  18. Change back to the root user.
    exit
  19. Edit the pg_hba.conf file to enable access to the database. must be able to connect as both the postgres and pgbouncer users. In each entry, supply the IP range that will be used by your install or cluster.
    # TYPE  DATABASE    USER        ADDRESS         METHOD
    local   all	    all         peer		
    hostssl all         postgres    <IP Range>/<XX> md5
    hostssl phantom     pgbouncer   <IP Range>/<XX> md5
    
  20. Edit postgresql.conf. Set values for max_connections, work_mem, shared_buffers, and listen_address.
    max_connections=2500
    work_mem=2796kB
    shared_buffers=2GB
    listen_addresses = '*' # what IP address(es) to listen on;
    

    Several factors can influence the amount of memory dedicated to the work_mem setting. Larger, high event volume deployments will want significantly more, while smaller, lower volume deployments may use slightly less. The setting above assumes a medium sized deployment with a moderate event volume.

    For listen_address set a value that matches your security requirements. Valid settings are:

    • * for all addresses, 0.0.0. for all IPv4 addresses
    • :: for all IPv6 addresses
    • specific addresses you supply.
  21. Restart the PostgreSQL service.
    systemctl restart postgresql-11

Backup a Splunk SOAR (On-premises) database and restore to an external database

To backup a database and restore it on an external database, use the ibackup.pyc tool. See backup and restore overview in Administer .

Create an external PostgreSQL database in AWS RDS

Some deployments, especially those in Amazon Web Services, may want to put the PostgreSQL database on its own host using AWS's Relational Database Service (RDS). These steps can also be used to migrate a standalone instance to an instance using a PostgreSQL database hosted in AWS' RDS.

For more information on building a PostgreSQL database host in RDS, see the Amazon Relational Database Service documentation.

Set the statement_timeout parameter to "0" when creating an external PostgreSQL database in AWS RDS. See the Amazon Working with parameters on your RDS for PostgreSQL DB instance documentation for more information.

Checklist

Number Task Description
1 Create a PostgreSQL database in AWS. Create the external PostgreSQL database with the Relational Database System
2 Create the pgbouncer user account. Create the pgbouncer user for the RDS
3 Back up the instance's PostgreSQL database, then restore it to the AWS RDS instance. Backup a database and restore to an external database

Create the external PostgreSQL database with the Relational Database System (RDS)

uses a PostgreSQL 11.16 database. In many installations, the database runs on the same server as . If you opt to run the PostgreSQL database on its own Amazon Web Services RDS instance, follow the procedures here. These instructions assume you already have an AWS account and VPCs established for your organization's resources.

These instructions use PostgreSQL version 11.16. You may use any PostgreSQL 11.x release. If you do use a different release, you must to use matching parameters for your release where PostgreSQL 11.16 is specified in these instructions.

  1. From your EC2 dashboard, click Services in the menu bar, and under Database choose RDS.
  2. Click Create database.
  3. Select Standard Create.
  4. Under Engine options, select PostgreSQL.
  5. For Version, select 11.16 from the menu.
  6. For Templates, select either Production for production environments or Dev/Test for development/testing or Proof of Value environments.
  7. Under Settings, type a name for your DB instance identifier. Make sure that the name is unique across all DB instances owned by your AWS account.
  8. Under Credential Settings:
    1. Master username: postgres
    2. Make sure the Auto generate a password checkbox is not selected.
    3. Type and confirm the Master password in the fields provided. Record this password. You will need it later.
  9. Under DB instance size, select the radio button that matches your organization's needs.

    Warning: Instances below db.t2.large may deplete their available connections before installation of Splunk SOAR (On-premises) is complete.

  10. Under Storage, select a Storage type based on your organization's needs.
    1. For Allocated storage, set a number of GiB that matches your organization's needs.

      Databases with less than 500 gigabytes of storage are not supported for production use.

    2. Select the Enable storage autoscaling check box.
    3. Set Maximum storage threshold to 1000 (GiB).
  11. Under Availability & durability, select the Do not create a standby instance radio button.
  12. Under Connectivity, select the same VPC as you used for your instance.
  13. Under the Additional connectivity configuration section:
    1. Select the correct Subnet group. The available groups depend on your VPC selection.
    2. Under Publicly accessible, select the No radio button.
    3. Under VPC security group, select Choose existing.
    4. Select the appropriate security group from the menu.
    5. Click the X icon to remove any unwanted security groups that were added by default.
    6. Make sure the Database port is set to 5432.
  14. Under Additional configuration, Database options:
    1. Type phantom for Initial database name.
    2. Make sure the DB parameter group is set to default.postgres11.16.
  15. Under Additional configuration, Backup, leave everything at the defaults.
  16. Click Create Database.

Create the pgbouncer user for the RDS

interacts with the PostgreSQL database using the pgbouncer user account. This account needs to be created for the database you built in RDS.

  1. SSH to the operating system of your instance and use the user was installed with. For privileged installs, this will be the root user.
  2. Create the pgbouncer user.
    psql --host <DNS name for RDS instance> --port 5432 --username postgres --echo-all --dbname phantom --command "CREATE ROLE pgbouncer WITH PASSWORD '<pgbouncer password>' login;"
  3. Make the pgbouncer user a superuser.
    psql --host <DNS name for RDS instance> --port 5432 --username postgres --echo-all --dbname phantom --command "GRANT rds_superuser TO pgbouncer;"

Backup the external PostgreSQL database with the Relational Database System (RDS)

To backup an external PostgreSQL database with the RDS, you can perform the following steps as the unprivileged user.

You must use identical versions of Splunk SOAR (On-premises) for this procedure. For example, if your PostgreSQL backup is from Splunk SOAR (On-premises) 5.0.1, you must restore it to use with an instance of Splunk SOAR (On-premises) 5.0.1.

  1. Backup the database.
    cd <PHANTOM_HOME>/bin
    phenv python backup.pyc --all
    
  2. Copy the file path that shows the backup file that was created to use in a future step.
    All data backed up to <PHANTOM_HOME>/data/phantom_backups/phantom_backup_2017-07-15-20-47-04.126913.tgz
    
  3. Edit the <PHANTOM_HOME>/etc/pgbouncer/pgbouncer.database.ini file as shown in the following code. host is the IP address or DNS name of the database server.
    [databases]
    phantom = user=pgbouncer password=<pgbouncerpassword> host=<pg server>
    postgres = user=postgres password=<postgrespassword> host=<pg server>
    [pgbouncer]
    server_tls_sslmode = require
    

    Amazon Web Services RDS PostgreSQL databases do not need the server_tls_sslmode = require entry.

  4. Stop all services.
    <PHANTOM_HOME>/bin/stop_phantom.sh
    
  5. Reload pgbouncer. For all deployments, use the following command:
    <PHANTOM_HOME>/bin/phsvc restart pgbouncer
    
  6. Test the connection to the database server.
    <PHANTOM_HOME>/bin/phenv psql  -h /tmp -p 6432 -d postgres
    

    If connectivity is successful, you will see the following message:

    psql (11.16)
    Type "help" for help.
    postgres=#
    
    To exit from psql, use \q.
  7. Initialize the database to use with .
    cd <PHANTOM_HOME>/bin
    phenv prepare_db --db-exist-ok
    
  8. Start all services.
    <PHANTOM_HOME>/bin/start_phantom.sh
    
  9. Restore the backup using the file name you copied in step 2.
    cd <PHANTOM_HOME>/bin
    phenv python restore.pyc --file <PHANTOM_HOME>/data/phantom_backups/phantom_backup_2017-07-15-20-47-04.126913.tgz
    
  10. Connect to the server's web user interface.
Last modified on 06 December, 2023
Run make_cluster_node.pyc   Set up external file shares using GlusterFS

This documentation applies to the following versions of Splunk® SOAR (On-premises): 5.4.0


Was this topic useful?







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