VMware Carbon Black EDR Server Cluster Management Guide

VMware Carbon Black EDR Server Cluster Management Guide

Modified on 23 July, 2021

VMware Carbon Black EDR 7.5

You can find the most up-to-date technical documentation on the VMware website at:

https://docs.vmware.com/

VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com

Copyright ©

2021 VMware, Inc. All rights reserved. Copyright and trademark information.


VMware, Inc. 2

https://docs.vmware.com/

https://docs.vmware.com/copyright-trademark.html

Contents

Preface 5

1 Before You Begin 6What this Document Covers 6

Other Documentation 7

Community Resources 7

Contacting Support 8

Reporting Problems 8

2 Server Overview 9Server Overview 9

Server Configuration 11

Server Logs 12

Log Overview 12

Troubleshooting 13

Error in the Carbon Black EDR Console Interface 13

Sensors Are Not Checking in 13

Verify that Everything is Working 13

3 Installing the Server 14Overview 14

Firewall and Connectivity Requirements 15

Substituting a Server Communication Certificate 15

Installing and Initializing a Server 16

Installing Carbon Black EDR on an Air-Gapped Server 25

Create the OS and Carbon Black Yum Cache 25

Install Carbon Black EDR using a Yum Cache 27

Upgrading a Server 28

Using cbupgrade 29

Server Upgrades and New Sensor Versions 30

Upgrade Policy Settings 30

Supporting Multiple Volumes for Event Data 30

Naming Conventions 30

Using New Data Directories 31

Partitioning 31

Active and Read-Only Directories 32

Partition Purging 32

Extending Disk Space on the Fly 32

VMware, Inc. 3

Troubleshooting the Server 33

Uninstalling a Server 34

Removing the Server 35

4 Backup and Restore 37Overview 37

Restore Servers 38

Backup 38

Upgrade Server Operating System (Optional) 39

Restore 39

5 Ports and Protocols 41

6 Installing a Cluster 44Overview 44

Cluster Architecture 45

Cluster Operation 46

Configuring Clusters 48

Sensor Install and Verification 50

Best Practices 51

Adding Minions to Existing Clusters 51

Removing Minions from Existing Clusters 51

Best Practices 52

Read-Only Minions 52

Removing Minions 53

Upgrading Cluster Nodes 54

Manually Upgrading Cluster Nodes 54

7 CBCLUSTER 56Overview 56

Required User Privileges 57

Defining Users 59


VMware, Inc. 4

Preface

The VMware Carbon Black Server Cluster Management Guide explains how to install and manage VMware Carbon Black EDR servers and clusters.

This information describes how to install VMware Carbon Black EDR servers and clusters and how to backup and restore data to these systems.

Intended Audience

This information is intended for anyone who wants to install, upgrade, or use VMware Carbon Black EDR servers and clusters. The information is written for experienced system administrators.

VMware, Inc. 5

Before You Begin 1This preface provides a brief orientation to the VMware Carbon Black EDR Server Cluster Management Guide v7.5.

.

This chapter includes the following topics:

n What this Document Covers

n Other Documentation

n Community Resources

n Contacting Support

What this Document Covers

The following table summarizes the contents of the VMware Carbon Black EDR Server Cluster Management Guide.

Chapter Description

Chapter 2 Server Overview Provides an overview of the Carbon Black EDR server technology stack, daemons, configuration, and logs.

Chapter 3 Installing the Server Explains how to install and initialize a new Carbon Black EDR server, and how to upgrade, troubleshoot, and uninstall the server.

Chapter 4 Backup and Restore Explains how to perform backup and restore procedures.

Chapter 5 Ports and Protocols Provides a collection of tables that list port and protocol information for server communications.

Chapter 6 Installing a Cluster Introduces Carbon Black EDR clusters and explains how to configure clusters, add minions to existing clusters, remove minion nodes from clusters, and upgrade cluster nodes.

Chapter 7 CBCLUSTER Describes how to use the CBCLUSTER command as a non-root user.

VMware, Inc. 6

Other Documentation

To access documentation for tasks not covered in this guide, in addition to other documents maintained as a knowledge base for technical support solutions, see the following:

n VMware Carbon Black EDR Release Notes – Provides information about new and modified features, issues resolved and general improvements in this release, and known issues and limitations. It also includes required or suggested preparatory steps before installing the server.

n VMware Carbon Black EDR Operating Environment Requirements (OER) – Describes performance and scalability considerations in deploying a Carbon Black EDR server. This document was called the Server Sizing Guide in previous releases.

n VMware Carbon Black EDR Server Configuration (cb.conf) Guide – Describes the Carbon Black EDR server configuration file ( cb.conf ), including options, descriptions, and parameters.

n VMware Carbon Black EDR User Guide – Describes the Carbon Black EDR product and explains how to use all of its features and perform administration tasks. Beginning with Carbon Black EDR Server 6.5, this User Guide is also available online through the Help menu in the console.

n VMware Carbon Black EDR Unified View User Guide – Describes how to install and manage VMware Carbon Black EDR Unified View.

n VMware Carbon Black EDR Integration Guide – Provides information for administrators who are responsible for integrating Carbon Black EDR with various tools and applications, such as VMware Carbon Black App Control, EMET, VDI, SSO, and more.

n VMware Carbon Black EDR API – Documentation for the Carbon Black EDR REST API is located at https://developer.carbonblack.com/reference/enterprise-response . Documentation for the Python module that can be used for easy access to the REST API is hosted at https://cbapi.readthedocs.io.

n VMware Carbon Black EDR connectors – A connector enables communication between a third-party product and Carbon Black EDR server. Documentation describing how to install, configure and maintain VMware Carbon Black connectors is located at https://developer.carbonblack.com/guide/enterprise-response/#connectors .

Community Resources

The VMware Carbon Black User Exchange provides access to information shared by VMware Carbon Black customers, employees and partners. It includes information and community participation for users of all VMware Carbon Black products.

When you log into https://community.carbonblack.com, you can:

n Ask questions and provide answers to other users’ questions.

n Vote for product ideas.


VMware, Inc. 7

https://developer.carbonblack.com/reference/enterprise-response

https://cbapi.readthedocs.io

https://developer.carbonblack.com/guide/enterprise-response/#connectors

https://developer.carbonblack.com/guide/enterprise-response/#connectors

https://community.carbonblack.com

n Participate in the VMware Carbon Black developer community by posting ideas and solutions or discussing those posted by others.

n View the training resources available for VMware Carbon Black products.

You must have a login account to access the VMware Carbon Black User Exchange. Contact your VMware Carbon Black Technical Support representative to get an account.

Contacting Support

View our Customer Support Guide on the User Exchange for more information about Technical Support: https://community.carbonblack.com/t5/Support-Zone/Guide-to-Carbon-Black-Customer-Support/ta-p/34324

VMware Carbon Black Technical Support offers several channels for resolving support questions:

Technical Support Contact Options

Web: https://community.carbonblack.com

Email: [email protected]

Phone: 877.248.9098 or 617.393.7400

Fax: 617.393.7499

Reporting Problems

When you call or email technical support, provide the following information to the support representative:

Required Information Description

Contact Your name, company name, telephone number, and email address

Product version Product name and version number

Hardware configuration Hardware configuration of the server or computer the product is running on (processor, memory, and RAM)

Document version For documentation issues, specify the title and product version of the manual you are using.

Problem Action causing the problem, error message returned, and any other appropriate output

Problem severity Critical, serious, minor, or enhancement


VMware, Inc. 8

https://community.carbonblack.com/t5/Support-Zone/Guide-to-Carbon-Black-Customer-Support/ta-p/34324

https://community.carbonblack.com/t5/Support-Zone/Guide-to-Carbon-Black-Customer-Support/ta-p/34324

https://community.carbonblack.com

mailto:[email protected]

Server Overview 2This topic provides an overview of the Carbon Black EDR server technology stack, daemons, configuration, and logs.


n Server Overview

n Server Configuration

n Server Logs

Server Overview

This topic describes the technology stack on a Carbon Black EDR server.

Five major daemons exist in Carbon Black EDR server:

Daemon Description

cb-nginx Used as an HTTP reverse proxy to internal daemons.

cb-coreservices (Python, Gunicorn) All non-data application logic for HTTP transactions.

cb-datastore (Java/Jetty) All incoming data, including event logs and binary files.

cb-solr (Java/Jetty) Apache Solr, the primary data store.

cb-postgres Traditional relational database.

cb-sensorservices Handles all non-data sensor requests, such as sensor check-ins, registrations, and upgrades.

nginx is the only daemon with public sockets. The remaining daemons are bound to the Carbon Black EDR server using the default IP address, which is 127.0.0.1, and can only be accessed locally or by using the nginx reverse proxy.

nginx owns tcp/80 and tcp/443 and redirects to coreservices , cb-datastore or cb-sensorservices to the Carbon Black EDR web root:q based on the URL prefix:

VMware, Inc. 9

nginx Redirects to

/ /var/www/cb/

/api/* coreservices on tcp/5000

/sensor/* sensorservices on tcp/6500 and 6501

/data/* cb-datastore on tcp/9000

Note coreservices handles /api/*

All /api/ URLs are used by the Carbon Black EDR console interface and by REST clients.

sensorservices handles /sensor/*

All /sensor/ URLs are used by the sensors that are pushing data. These URLs are isolated to allow binding a separate nginx server instance to tcp/443 on a public or DMZ interface for sensors that are outside of the internal network (for example, sensors on laptops used by traveling or remote employees) without exposing the /api/ interfaces externally. You can isolate these URLs by using a simple nginx configuration change, as shown in the example in the file:

/etc/cb/nginx/conf.d/cb-multihome.conf.example

Note Listening ports are configured differently in a clustered setup. See cluster-specific documentation for more details.

In general, sensors first register and check into sensorservices by using nginx . If sensors have data, after they check in, they post event logs to cb-datastore by using nginx .

cb-datastore caches data for a few minutes before sending a collection of related data to cb-solr .

The following diagram shows the Carbon Black EDR server architecture at a high level:


VMware, Inc. 10

Server Configuration

Most major server configuration is done after the Carbon Black EDR server is installed, when the cbinit script is run. cbinit configures a combination of initial settings in both static configuration files and PostgreSQL.

For more information about installing and configuring the Carbon Black EDR server, see Chapter 3 Installing the Server

Daemon configuration data is generally static, and is stored in flat files that follow typical Linux conventions. Dynamic run-time configuration data is stored in PostgreSQL and configured by using the Carbon Black EDR console.

The following table describes the major static configuration files.


VMware, Inc. 11

Static Configuration File Description

/etc/cb/cb.conf Major Carbon Black EDR enterprise-wide settings.

/etc/cb/solr6/core_conf This directory stores Apache Solr settings. Each subdirectory has individual solr core configurations.

/var/cb/data/pgsql/postgresql.conf PostgreSQL settings.

/etc/cb/coreservices-logger.conf Configuration of log settings for the Python coreservices daemon.

/etc/cb/sensorservices-logger.conf Configuration of log settings for the Python sensorservices daemon.

/etc/cb/cb-datastore/* Configuration of log settings for the Java cb-datastore daemon.

/etc/cb/nginx/conf.d/cb.conf nginx server settings for defining IP addresses and ports to bind to listeners.

/etc/sysconfig/iptables Standard iptables configuration for the server firewall (for CentOS 6).

The following table describes the secondary static configuration files:

Static Configuration File Description

/etc/cb/allianceclient-logger.conf Configuration of log settings for the Carbon Black EDR Alliance client daemon.

/etc/cb/nginx/cb-nginx.conf Standard nginx server configurations that are specific to Carbon Black EDR.

/etc/cb/solr6/solr.in.sh Jetty servlet settings for Solr

Server Logs

The Carbon Black EDR server uses log files extensively. These files provide reassurance of system health and a record of activity under error conditions.

Log Overview

The following table describes critical logs that reside on the Carbon Black EDR server:

Log Description

/var/log/cb/nginx/access.log (and error.log ) nginx HTTP access and error logs for all sensor and API traffic.

/var/log/cb/coreservices/debug.log Application logic for API traffic.

/var/log/cb/sensorservices/debug.log Application logic for sensor traffic.

/var/log/cb/datastore/debug.log Incoming sensor data cache.

/var/log/cb/solr/debug.log Sensor data storage, indexing, and queries.


VMware, Inc. 12

http://wiki.apache.org/solr/SolrConfigXml

http://www.postgresql.org/docs/9.2/static/runtime-config.html

http://wiki.nginx.org/Configuration

http://www.centos.org/docs/5/html/5.2/Deployment_Guide/s2-sysconfig-iptables.html

http://wiki.nginx.org/Configuration

Troubleshooting

This topic describes several issues and troubleshooting recommendations.

Error in the Carbon Black EDR Console Interface

Review the log file: /var/log/cb/coreservices/debug.log for a Python stack trace with details.

Contact your VMware Carbon Black Technical Support representative.

Sensors Are Not Checking in

If a sensor is not checking in, look in the log file: /var/log/cb/nginx/access.log for a request from the host.

For example:

164.230.214.13 - - [20/Apr/2021:20:04:52 +0000(3.811)] "POST /sensor/checkin/35998 HTTP/1.1" 502 166

"-" "sensors.vibrant-pies.my.carbonblack.io" ">170.16.20.21:6501" "-" "-"

In the output example, several fields are useful for diagnosing the issue:

n Sensor Id is reported after the checkin field. It is 35998 in the above case.

n The actual error code is reported in the field following HTTP/1.1 text. In the example above, 502 is the error code.

n In a clustered environment, some requests proxy calls to a different minion in the cluster. This minion's address is reported after the ‘>’ character (170.16.20.21 in the above case).

If you find a checkin error or an error to any other call with the "/sensor/" prefix, check the following log: /var/log/cb/sensorservices/debug.log.

If you see an error related to requests prefixed with "/data/", check the following log: /var/log/cb/datastore/debug.log.

In a clustered environment, review the log files on the node that is referenced in the nginx error log entry.

Alternatives

If sensors are not checking in but there are no entries in access.log , check error.log .

If the sensor SSL client certificates are not signed by the Certificate Authority (CA) in /etc/cb/certs and configured in /etc/cb/nginx/conf.d/cb.conf , nginx will refuse the request.

If there are no entries in error.log, check the status of sensor communications as described in the “Troubleshooting Sensors” section in the VMware Carbon Black EDR User Guide .

Verify that Everything is Working

Check the nginx access.log for ‘ 200 ’ HTTP response codes. 200 codes indicate that communications are working properly.


VMware, Inc. 13

Installing the Server 3This topic explains how to install and intialize a new Carbon Black EDR server. It includes instructions for upgrading, troubleshooting, and uninstalling a server.


n Overview

n Installing and Initializing a Server

n Installing Carbon Black EDR on an Air-Gapped Server

n Upgrading a Server

n Supporting Multiple Volumes for Event Data

n Troubleshooting the Server

n Uninstalling a Server

Overview

This topic describes the steps for installing the Carbon Black EDR server. It covers new installations and server upgrades. You can complete the entire process in about ten minutes, assuming reasonable download speed.

The VMware Carbon Black EDR Operating Environment Requirements (OER) Guide provides guidelines for hardware and software required for the Carbon Black EDR server. Your environment must meet these requirements before you begin installation.

A Carbon Black EDR server installation consists of the following main steps:

1 Obtain and install an RPM from VMware Carbon Black. This RPM does not install the Carbon Black EDR server. It sets up a Yum repository and installs an SSL client certificate that allows the full Carbon Black EDR server to be downloaded and installed.

2 Install the Carbon Black EDR server. This is a two-step process that involves running the yum install command and the cbinit configuration script. The Carbon Black EDR server software is downloaded when you run the yum install command.

For information about automating cbinit, see Cb Response 6.2 Automating Installation Using cbinit.

VMware, Inc. 14

https://community.carbonblack.com/t5/Documentation-Downloads/Cb-Response-6-2-Automating-Installation-Using-cbinit/ta-p/41938

https://community.carbonblack.com/t5/Documentation-Downloads/Cb-Response-6-2-Automating-Installation-Using-cbinit/ta-p/41938

After you have installed the server, you can install sensors on the endpoints. Instructions for installing and upgrading sensors are provided in the “Installing, Upgrading, and Uninstalling Sensors” chapter in the VMware Carbon Black EDR User Guide.

Firewall and Connectivity Requirements

Internet connectivity through outbound TCP ports is required on the Carbon Black EDR Server system for the scenarios that the following table describes.

Scenario Description Address

Carbon Black EDR Yum Repository

The RPM installer sets up a Yum repository. yum.carbonblack.com:443

yum.distro.carbonblack.io:443

Carbon Black EDR Alliance Server and Carbon Black Threat Intel

The Alliance Server and Carbon Black Threat Intel provide threat intelligence and can enable further analysis of files on endpoints through Carbon Black Threat Intel partners.

To view all threat intelligence data, you need both addresses.

api.alliance.carbonblack.com:443

threatintel.bit9.com:443

CentOS Yum Repository The standard CentOS Yum repository server used during Carbon Black EDR server installation to download standard packages.

mirror.centos.org:80

Substituting a Server Communication Certificate

Carbon Black EDR uses HTTPS and TLS to secure communications between endpoints and the server, and to ensure that the endpoint communications only with the Carbon Black EDR server that it trusts, and the server communications with trusted endpoints only.

When you install a new Carbon Black EDR Server, the cbinit configuration program you run after installation installs a legacy certificate suitable for use with the standard “pinning” validation method.

By default, the certificate installed during cbinit is produced by the server itself. As an alternative to the default legacy certificate, you can substitute your own certificate during the server post-installation initialization process. In either case, the certificate is named “Legacy” where certificates appear in the console, and it is protected from deletion.

A server certificate for sensor communications must meet the following requirements:

n The files must be recognized as a valid certificate and key pair by the OpenSSL library.

n Both the certificate file and the key file must be in unencrypted ASCII PEM format.

n The certificate must have valid dates when uploaded – that is, its "not valid before" date should be in the past and its "not valid after" date should be in the future.


VMware, Inc. 15

n The certificate must have two distinct SAN DNS entries to address the Carbon Black EDR cluster scenario where sensors must resolve primary and minion virtual addresses to different IP addresses or FQDNs. This is required for every server certificate, even in standalone configurations, so that the certificate remains valid if a standalone instance is upgraded to a cluster. The second SAN field is a single virtual address used for all minions, but it is mapped to a different IP address or FQDN hostname as needed by the sensor itself.

n SAN DNS entries must meet the standards for hostname formatting. Allowed characters include the hyphen and alphanumeric characters (a to z and 0 to 9). Invalid SAN DNS entries can silently fail.

n The CN field is not used for validation of a new certificate because it has been deprecated. Sensors perform their own local resolution of virtual names to real server addresses, so no additional DNS entries are required.

The example below shows how you can set up the SAN portion of the certificate. The first SAN.DNS entry is used for the primary node and the second for the minions.

Certificate A

CN=<something>

SAN.DNS.1=virtual-a.master

SAN.DNS.2=virtual-a.minion

When you substitute your own certificate using cbinit , Carbon Black EDR runs tests to confirm that the certificate is valid for this use. If the certificate passes the test, it is used for this server. Otherwise, the default, server-provided legacy certificate is used instead, an error message appears, and the certificate import failure is logged to /var/log/cb/cli. The cbinit process continues if the substitution fails.

The server certificate and key are copied into the server as /etc/cb/certs/cb-server.crt and /etc/cb/certs/cb-server.key , and are also stored in the Carbon Black EDR database.

Important Additional certificate management features are available in Carbon Black EDR, including support for adding multiple certificates after server initialization. See “Managing Certificates” in the VMware Carbon Black EDR User Guide.

Installing and Initializing a Server

This section describes the steps for installing and initializing a new Carbon Black EDR server. Root-level permissions are required throughout the entire installation/configuration process. Use su or sudo to enter the installation/initialize commands.

Caution The steps in this section are for a new installation only. If you already have the Carbon Black EDR server installed, do not perform these steps. Instead, see Server Upgrades and New Sensor Versions.

Using the new installation procedure on an existing server can result in loss of all data, including the configuration and event data collected from sensors.


VMware, Inc. 16

To install and initialize a new server:

1 Verify that the host machine on which to install Carbon Black EDR server meets the hardware and software requirements specified in the VMware Carbon Black EDR Operating Environment Requirements (OER) Guide.

2 Verify that the server has Internet connectivity as specified in Firewall and Connectivity Requirements.

3 Contact VMware Carbon Black Technical Support to procure an installation RPM for the Carbon Black EDR server.

4 Install the RPM:

a Run the following command using the customer-specific RPM you received:

sudo rpm -ivh carbon-black-release-1.0.3-1- <customername> .x86_64.rpm

b (Optional) Verify that the Carbon Black EDR [cb] Yum repository was configured correctly. You can run this command to see the contents of the new Yum repository entry for Carbon Black EDR:

cat /etc/yum.repos.d/CarbonBlack.repo

[root@cb-enterprise-testing ~]# cat /etc/yum.repos.d/CarbonBlack.repo

[CarbonBlack]

name=CarbonBlack

baseurl=https://yum.distro.carbonblack.io/enterprise/stable/

$releasever/$basearch/

gpgcheck=1

enabled=1

metadata_expire=60

sslverify=1

sslclientcert=/etc/cb/certs/carbonblack-alliance-client.crt

sslclientkey=/etc/cb/certs/carbonblack-alliance-client.key

c (Optional) You should see the Carbon Black EDR SSL certificates and keys in the following directory:

/etc/cb/certs/

5 Install the Carbon Black EDR server:

a Verify that the computer’s date and time settings are accurate. Incorrect date/time settings can cause failures in SSL negotiation.

b For EL6 and EL7 servers, run the following command:

$ sudo yum install cb-enterprise

[jdoe@localhost yum.repos.d]$ sudo yum install cb-enterprise

For EL8 servers, run the following commands:


VMware, Inc. 17

$ sudo yum module disable postgresql redis python39

$ sudo yum install cb-enterprise

[jdoe@localhost yum.repos.d]$ sudo yum module disable postgresql redis python39

[jdoe@localhost yum.repos.d]$ sudo yum install cb-enterprise

c Install the CentOS GPG key if you are prompted to do so.

d If your environment requires that outbound firewall exceptions be made, ensure that the exceptions documented in Firewall and Connectivity Requirements are followed. You must also update /etc/yum.repos.d/CentOS-Base.repo to enable the baseurl of http://mirror.centos.org.

Note Yum supports the use of web proxies. However, VMware Carbon Black cannot use Yum with NTLM-authenticated web proxies.

6 When the installation completes, initialize and configure the server.

a Run the following command. If you plan to use the server-provided certificate to secure communications with sensors, no arguments are necessary:

sudo /usr/share/cb/cbinit

To substitute your own certificate, add the following arguments to the cbinit command, substituting the full path to a certificate file and a key file where shown:

--server-cert-file= <certpath> --server-cert-key= <keypath>

Important See Substituting a Server Communication Certificate for certificate requirements.

b Press [Return] to open the EULA. When you are done reviewing it, if you agree to the terms, type q and then type yes to continue.

c Select a storage location for your data and press [Return] .

Note By default, the primary datastore is mapped to /var/cb/data. If you configured your storage differently, review your current file system mapping (df -h) with VMware Carbon Black Support or Professional Services. Incorrect or insufficient disk configurations prevent Carbon Black EDR from operating correctly.


VMware, Inc. 18

d Enter an initial Adminstrator account to log in and configure Carbon Black EDR. Enter values for Username , First Name , Last Name , E-Mail , Password , and Confirm password :

e Press [Enter] and then validate the account information by typing y.

f In the Sensor Communications section, define the address that the sensors will use to communicate to the Carbon Black EDR server:

Would you like to keep the default [Y/n]: n

Use SSL [Y/n]: Y

Hostname [192.168.117.141]: cbr.company.com

Port [443]: return

If the Verify Account Information looks correct, Y

Note The IP address of the server is accessed via the default SSL port 433. A best practice is to use a DNS record that points to this IP address.

Work with VMware Carbon Black Support or Professional Services to make sure that you understand the external connectivity options supported by the Carbon Black EDR server.


VMware, Inc. 19

g Review all prompts and configure sharing settings in accordance with your company’s security policies. The recommended settings are provided here. You can change these settings at any time by accessing the Carbon Black EDR console and clicking Username> Sharing Settings.

n Do you want to enable communication with the Carbon Black Alliance? – Y

This enables the program to be supplemented with updated threat intelligence from VMware Carbon Black Threat Intel and the extended network of VMware Carbon Black Threat Intel partners.

n Do you want your server to submit statistics and feedback information to Carbon

Black? – Y

This enables the server to submit health statistics back to Carbon Black EDR. These are used by VMware Carbon Black Support and Professional Services to determine how the allocated server is performing.

n Do you want the default sensor group to submit hashes to Carbon Black Alliance? –

N

See the “Threat Intelligence Feeds” chapter in the VMware Carbon Black EDR User Guide for more information on sharing hashes with Carbon Black EDR.

n Continue with current sharing settings? – Y


VMware, Inc. 20

h The SSL Certificates section is automated and requires no user input. If you used arguments pointing to valid certificate and key files when you ran cbinit , the certificate from your organization is substituted for the default certificate created by the server. See Substituting a Server Communication Certificate and the VMware Carbon Black EDR User Guide for more information.

Run the following script to create an encrypted backup of your certificates. The exact certificates are critical to disaster recovery efforts.

/usr/share/cb/cbssl backup --out <backup_file_name>


VMware, Inc. 21

i In the IP Tables section, answer Y. This opens port 433 in the server’s IP tables.

j The POSTGRESQL Database Setup section is automated and requires no user input.


VMware, Inc. 22

k In the Setup Complete section, enter Y to start the services.


VMware, Inc. 23

Note To confirm that sensor-to-server communications are functioning properly:

1 Open Google Chrome and launch the server:

https://<your_cber_server_url>

2 Download a sensor and install it on an endpoint.

For more information on installing and managing sensors, see the “Manage Sensors” chapter in the VMware Carbon Black EDR User Guide.

7 Configure the firewall if you have not already done so. There are many ways to configure a firewall. The following is an example for CentOS 6.

a Open port 443 if you did not allow the cbinit script to manage iptables for you.

[jdoe@localhost yum.repos.d]$ sudo vim /etc/sysconfig/iptables

# Firewall configuration written by system-config-firewall

# Manual customization of this file is not recommended.

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -p icmp -j ACCEPT

-A INPUT -i lo -j ACCEPT

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-host-prohibited


VMware, Inc. 24

-A FORWARD -j REJECT --reject-with icmp-host-prohibited

# New additions to the IPTABLES for carbon black

-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT

COMMIT

b (Optional) Open port 80 to allow use of web interface and sensor communications through an unsecured channel. This is not required and only recommended for exploration or troubleshooting. Connections to the web interface through port 80 are redirected to port 443.

8 Log into the Carbon Black EDR server web console at https://<your server address>/ and use the username and password that you set up in the cbinit script.

Note Google Chrome is the only supported browser for this release.

After you have installed, configured, and initialized the Carbon Black EDR, it should be accessible through the web interface on port 443 with a self-signed certificate. If you attempt to access the web interface through HTTP on port 80, the connection is redirected to port 443.

The next step is to download and install one or more sensors to begin collecting data. Sensor installation is described in the “Manage Sensors” chapter in the VMware Carbon Black EDR User Guide .

Installing Carbon Black EDR on an Air-Gapped Server

This section describes how to install Carbon Black EDR on a server that does not have access to the CentOS/RedHat or Carbon Black Yum repositories.

Installing Carbon Black EDR using a Yum cache is very similar to a standard server installation. The only difference is that you instruct Yum to use the local cache for all operations.

Caution The steps here are for a new installation only. If you already have the Carbon Black EDR server installed, do not perform these steps.

Using the new installation procedure on an existing server can result in loss of all data, including the configuration and event data collected from sensors.

Create the OS and Carbon Black Yum Cache

Use this procedure to install the operating system and create the Yum cache.


VMware, Inc. 25

Prerequisites

To create a Yum cache, you must provide a system that can communicate with the operating system (OS) and Carbon Black Yum repositories. This system is used to download, install, and store (cache) packages and dependencies. This system is referred to as a caching server, and does not need to meet any Server Sizing Guide or Operating Environment Requirements. The caching server is not initialized or used as a functioning Carbon Black EDR server.

Important You must install the same OS on the caching server as you install on the Carbon Black EDR production server. RHEL and CentOS Yum require unique packages for each OS type and version. Any difference in the caching server OS build and the production OS build can result in a high probability of failure.

Configure the Caching Server:

Procedure

1 Install the appropriate OS on the caching server by following OS vendor or internal procedures.

2 Install the Carbon Black EDR License RPM.

a Copy the Carbon Black-provided RPM file to the caching server.

carbon-black-release-<customer dependent>.x86_64.rpm

b Log into the caching server console.

c Change directory to the location of the RPM.

d Install the RPM package:

#rpm -ivh carbon-black-release-<customer dependent>.x86_64.rpm

3 Configure Yum to cache all package installations.

a Modify the yum.conf file:

#vi /etc/yum.conf

b Configure cachedir and keepcache:

[main]

cachedir=/var/cache/yum/$basearch/$releasever

keepcache=1

4 Download and install Carbon Black EDR packages and dependencies. Install cbenterprise:

#yum install cb-enterprise -y


VMware, Inc. 26

5 Compress and archive the Yum cache directory:

#tar -selinux -cvzf yumcache.tar.gz -C

/var/cache/yum/<basearch>/<releasever>/

Example:

#tar -selinux -cvzf yumcache.tar.gz -C

/var/cache/yum/x86_64/6/

6 Copy the cache archive file (yumcache.tar.gz) to media or to a location that is accessible by the production Carbon Black EDR server.

What to do next

Install Carbon Black EDR using a Yum Cache

Install Carbon Black EDR using a Yum Cache

Use this procedure to install Carbon Black EDR on the production server by using the Yum cache.

Prerequisites

Important You must install the same OS on the production server as you installed on the caching server. RHEL and CentOS Yum require unique packages for each OS type and version. Any difference in the caching server OS build and the production OS build can result in a high probability of failure.

Procedure

1 Install the appropriate OS on the production server by following OS vendor or internal procedures.

2 Install the Carbon Black EDR License RPM.

a Copy the Carbon Black-provided RPM file to the production server.

carbon-black-release-<customer dependent>.x86_64.rpm

b Log into the production server console.

c Change directory to the location of the RPM.


VMware, Inc. 27

d Install the RPM package:

#rpm -ivh carbon-black-release-<customer dependent>.x86_64.rpm

e Create a Yum cache directory structure and add the base architecture and release version directories to /var/cache/yum:

#mkdir -p /var/cache/yum/<basearch>/<releasever>/

Example:

#mkdir -p /var/cache/yum/x86_64/7/

3 To populate the production server’s Yum cache, extract the Yum cache archive file (yumcache.tar.gz) to the appropriate directory:

#tar -xvzf yumcache.tar.gz -C

/var/cache/yum/<basearch>/<releasever>/

Example:

#tar -xvzf yumcache.tar.gz -C /var/cache/yum/x86_64/6/

4 Update /etc/yum.conf by adding cachedir=/var/cache/yum/$basearch/$releasever in the [main] section of the file.

5 If you are using RHEL8/CENTOS8, use the cache command line option to disable some prerequisite modules:

yum -C -y module disable postgresql redis python38

6 Install cb-enterprise using the cache switch:

#yum install -C cb-enterprise

7 Follow the remaining Carbon Black EDR server installation procedures beginning at step 6 in Installing and Initializing a Server.

Upgrading a Server

If you are upgrading the Carbon Black EDR server, the procedure varies depending on whether you are upgrading a standalone server or a clustered server.

The database schema or VMware CB Threat Intel feed data must be migrated after the new server version is installed.

These steps require SSH or console access to the server and minions with root privileges.

To upgrade a standalone server:

1 On the server, stop the Carbon Black EDR services:

sudo service cb-enterprise stop


VMware, Inc. 28

2 (Optional) Clean the yum cache of metadata and packages:

yum clean all

3 Update the Carbon Black EDR services:

sudo yum upgrade cb-enterprise

4 Restart the Carbon Black EDR services:

sudo service cb-enterprise start

To upgrade a clustered server:

1 On the primary server, navigate to the cb install directory (defaults to /usr/share/cb ) and stop the Carbon Black EDR services: sudo cbcluster stop

2 (Optional) Clean the yum cache of metadata and packages:

yum clean all

3 Update the Carbon Black EDR services on each primary and minion server node:

sudo yum update cb-enterprise

4 Run the cbupgrade utility (see the following section for more information.):

/usr/share/cb/cbupgrade

5 On the primary server, restart the Carbon Black EDR services:

sudo cbcluster start

Caution On pre-6.1 versions of Carbon Black EDR, you could change the home directory of the cb service account, which is /var/cb by default. This is the account under whose auspices server installations occur. This is no longer supported, and will cause upgraded servers to fail with an nginx error.

The home directory of the cb service account must be /var/cb. This is where upgrades place runtime configuration files for nginx, so if you changed the cb service home directory, these files will not be found. If you edited the home directory in /etc/password, restore it to /var/cb before upgrading.

Using cbupgrade

Upgrades to the Carbon Black EDR server occasionally require you to use a utility called cbupgrade after executing yum update cb-enterprise to migrate the database schema or Threat Intel feed data.

You are notified of this requirement when attempting to start the cb-enterprise services. In a clustered-server configuration, you must run the cbupgrade tool on all nodes before restarting the cluster. When running this utility in a clustered environment, be sure to answer No when asked to start the Carbon Black EDR services. You must use cbcluster to start the clustered server.

See Upgrading Cluster Nodes for cbupgrade options.


VMware, Inc. 29

Server Upgrades and New Sensor Versions

Carbon Black EDR server releases generally include updated sensor versions for one or more operating systems. Servers and sensors can be upgraded independently, and sensors can be upgraded by sensor groups rather than all at once.

Decide if you want the new sensor to be deployed immediately to existing sensor installations, or if you want to install only the server updates. VMware Carbon Black recommends a gradual upgrade of sensors to avoid impact on network and server performance, and strongly recommends that you review your Sensor group Upgrade Policies before upgrading your server to avoid inadvertently upgrading all sensors at once. See the “Sensor Group” section of the VMware Carbon Black EDR User Guide.

Upgrade Policy Settings

On the Sensors page, the Upgrade Policy section of the Create or Edit Group panel contains options to set the policy for upgrading installed sensors within a group.

Upgrade policy options are as follows:

n No automatic updates – Manually decide when to upgrade sensors.

n Automatically install the latest version – Automatically upgrades the sensors to the latest version.

n Automatically install a specific version – Install a specific version for all sensors in a group. This keeps all sensors at the selected version. Select a version number using the drop-down list. Selecting the upgrade policy of a specific version is useful when sensor versions must be tested or vetted.

Supporting Multiple Volumes for Event Data

This topic describes how to add more storage to an existing Carbon Black EDR deployment after upgrading to the latest release.

This activity involves adding multiple Solr data directories for cbevents cores. These directories can be added as mount points into new storage arrays, so that you can easily add more disk space. This can be easily configured. If you need more disk space, you attach a new volume, mount it into the Solr data directory, and the server automatically starts using it.

Naming Conventions

Solr uses new cbevents directories (mount points) if their name is prefixed with cbevents* or _cbevents*.

Note The cbevents directory (without the suffix) is the default directory but does not need to remain on the original data partition. You can remove it if needed.

The following is an example of a valid multi-volume configuration:


VMware, Inc. 30

In this example, the default data drive is mounted to /dev/xvdb, and /data is configured as the data root inside of cb.conf. In addition, two more volumes are added and mounted to /data/solr6/cbevents2 and /data/solr6/cbevents3.

Caution The system assigns the correct user:group upon cb-enterprise restart. If you created the mount points on a live server, ensure that the user assigned to the Carbon Black EDR server has write permissions on the mounted directory. Failure to do so causes the system to ignore the new mount points.

Another option to expand cbevents storage is to use symlink.

To use a symlinked location for event storage:

1 Create a mount point in another location in the file system, such as /data2.

2 Create a symlink to the cbevents* directory inside the solr6 directory that points to the mounted directory. For example:

ln -s /data2 /var/cb/data/solr6/cbevents2

3 Ensure that the Carbon Black EDR user has write permissions in the mounted directory (/data2).

Using New Data Directories

This section discusses partitioning and purging related to new data directories.

Partitioning

New data directories are used when the next partition occurs (every 3 days by default), or sooner if the current data disk is at risk of becoming full.

The server uses simple heuristics in calculating when to partition and where to place the new event partition:

1 A new partition is created in the cbevents* directory that has the most free space at the time of partitioning.

2 If the current data volume is more than 95% full and additional partitions exist that have more than 5% free space available, the server immediately partitions.


VMware, Inc. 31

You can control this threshold using the following configuration parameter:

SolrTimePartitioningFreeSpaceThresholdPerc

n Rule 1 ensures that new volumes are used in a balanced fashion. As old data is aging out (being purged), some partitions free up. This ensures optimal use of free space.

n Rule 2 ensures that the system uses fragmented disk space efficiently in case many cbevents* directories exist. For example, assume you have five volumes, and each has 20% free space. This could result in none of the volumes fitting into the three-day partition. The system continues to try to use one of the partitions (up to its maximum available space) before moving to the next one. As a result, the server might end up with smaller partitions. However, this scenario should be rare.

Active and Read-Only Directories

Any cbevents directories prefixed with cbevents* are used to create new cbevent partitions. Any cbevents directories prefixed with _cbevents* are used as read-only.

A read-only partition can load existing partitions, but new partitions are not created on it. You can use this approach when retiring old volumes. Old partitions will eventually be purged based on time. A second use for _cbevents prefix is for directories that are used only for "cold" partitions (old partitions that are only loaded on demand).

Partition Purging

The system purges partitions based on disk space, time, or the maximum number of allowed partitions.

When purging based on disk space, a purging algorithm considers the overall amount of free disk space. For example, three 100 GB volumes exist, each with 30 GB of free space, giving you a total of 90 GB of free space and a total disk space of 300 GB. The total event data size is the sum of index sizes on all three volumes. (This could be less than 210 GB since the main data volume can also contain store files and other data.)

The following shows how the current purging thresholds (in cb.conf ) are interpreted when multiple volumes exist:

n MaxEventStoreSizeInPercent - Purge the oldest partition when the total sum of all event core sizes exceeds the given percentage of a total disk space (on all volumes).

n MaxEventStoreSizeInMB - Purge the oldest partition when the total event store size (on all volumes) exceeds the given threshold.

n MinAvailableSizeInMB - Purge the oldest partition when the total free disk space (on all volumes) falls below the given threshold.

Extending Disk Space on the Fly

You can add disk space on the fly without having to restart the Carbon Black EDR server.


VMware, Inc. 32

New directories are automatically used when a new partition occurs, avoiding any server downtime. Make sure that the directory is given correct read+write permissions to the user.

Troubleshooting the Server

The following table shows the Carbon Black EDR server logs in /var/log/cb that are organized into subdirectories by component.

Component Description

allianceclient The Alliance client communicates with the Carbon Black EDR Alliance server.

audit Contains log files for the following activities: banning, sensor isolation, and live response. If EnableExtendedApiAuditLogging is enabled in cb.conf , this directory also includes a user activity log file based on user-generated API calls in the console.

cbfs Was the location of the datastore engine in earlier versions of Carbon Black EDR but is no longer used in versions 5.0.0 and later.

cbfs-http Contains log files of the second generation Java datastore engine.

cli Contains events pertaining to the Carbon Black EDR service commands used at the server console level.

coreservices Provides access to functionality via web APIs to both the web interface and sensors. Nearly all interface issues should result in log entries for coreservices.

sensorservices Provides entry-point for sensor registrations and checkins. Look for issues here if there are problems with sensor connectivity

datastore Used for core event data processing and managing incoming sensor data.

enterprise Used for event logging of the Carbon Black EDR service.

job-runner The Carbon Black EDR server uses cron jobs to provide various scheduled maintenance, data trimming, and similar tasks.

liveresponse Used to hold Live Response session-related events.

nginx The reverse proxy and SSL termination point for the Carbon Black EDR server.

notifications The location of the syslog output for feeds and watchlists.

pgsql The Carbon Black EDR server uses Postgres SQL to store administrative data. Event data gathered from the sensors is not stored in Posgres.

rabbitmq The logging location for the rabbitmq component of the Carbon Black EDR server.

redis The logging location for the redis component of the Carbon Black EDR server.

services The logging location for the start/stop services of the Carbon Black EDR server.

solr Used for indexes and stores data.

supervisord The supervisord process utility is used to manage Carbon Black EDR server processes, handling startup and shutdown dependencies between the various server components and services.

The following table shows the diagnostic scripts found in/usr/share/cb.


VMware, Inc. 33

Component Description

cbbanning Assists in managing the Carbon Black EDR server banning features. To get a list of available commands, run this command:

cbbanning commands

cbstats This utility provides access to the statistics collected by the Carbon Black EDR server.

cbsyslog Provides an interface for testing Carbon Black EDR’s notifications syslog output.

cbpost This utility is used to send file(s) to the Alliance server; typically used during interaction with VMware Carbon Black Technical Support.

py_runtime_info Generates a runtime report that shows the stack trace, process memory map, and open file descriptors for the running Carbon Black EDR processes.

cbfeed_scrubber Helps clean up feed tags on existing Solr documents.

cbinit Used to configure a combination of initial settings during a Carbon Black EDR server installation.

cbdiag Dumps verbose troubleshooting information, including logs and configuration, to a gzip archive. This file can be analyzed offline or provided to VMware Carbon Black with support requests.

sql_stats Contains outputs of various SQL database statistics; typically used during troubleshooting.

cbsolr Used for indexes and stores data.

cbget This utility is used to download or list files from Alliance server; typically used during interaction with VMware Carbon Black Technical Support.

sensor_report Generates a report that shows the status of every sensor communicating with Carbon Black EDR server. Optionally, it can be used to identify specific sensors that might require the attention of IT support personnel.

cbcheck Assists in troubleshooting Carbon Black EDR server installation. To get a list of available commands, run this command:

cbcheck commands

to learn more about a specific command, run this command:

cbcheck <command> -h

cbcluster Used to manage clusters (not a diagnostic tool).

cb_rabbitmq-server.sh This is a system utility and should never be run manually.

cbrabbitmqctl A command-line interface that provides access to the Carbon Black EDR rabbitmq service.

pgsql_diag.sh Prints diagnostic info about the CBER Postgres database

cbpasswd Resets user’s password. Can only be run as root.

Uninstalling a Server

This topic describes the procedure for uninstalling a Carbon Black EDR server from RHEL/CentOS.


VMware, Inc. 34

You must remove the following Carbon Black EDR packages:

n carbon-black-release

n cb-datagrid

n cb-datastore

n cb-enterprise

n cb-solr

n cb-swagger

n cbui

n libselinux-cb-python

n python-cb-coreservices

n python-cb-response-venv

Removing the Server

Using the Yum utility, you can uninstall a Carbon Black EDR server in one of two ways.

You can remove or erase the packages that constitute the Carbon Black EDR server, or remove Carbon Black EDR packages plus all other third-party packages upon which it depends. Instructions for both methods are provided here.

To uninstall a server (Carbon Black EDR RPMs only):

1 Stop the Carbon Black EDR services by using one of the following commands:

sudo /usr/share/cb/cbcluster stop

or


2 Use the following Yum utility command to remove Carbon Black EDR packages listed above.

sudo yum remove <package1> <package2> <packageN>

3 Manually remove the following cb directories:

n /var/www/cb/

n /var/run/cb/

n /var/log/cb/

n /var/lib/cb/

n /var/cb/

n /usr/share/cb/


VMware, Inc. 35

n /etc/cb/

You can also use the Yum utility to remove Carbon Black EDR packages and all other third-party packages upon which it relies.

Caution This procedure might remove packages that are also required by other software applications. Use caution when performing this procedure.

To uninstall a server (Carbon Black EDR and related RPMs):

1 Stop the Carbon Black EDR services by using one of the following commands:

sudo /usr/share/cb/cbcluster stop

or


2 Access the yum.conf file with the following command:

vi /etc/yum.conf

3 Add this line to yum.conf:

clean_requirements_on_remove=1

4 Enter the following:

yum erase cb-enterprise

5 Enter the following:

yum remove carbon-black-release

6 Manually remove the following cb directories:

n /var/www/cb/

n /var/run/cb/

n /var/log/cb/

n /var/lib/cb/

n /var/cb/

n /usr/share/cb/

n /etc/cb/


VMware, Inc. 36

Backup and Restore 4This topic explains how to backup and restore your Carbon Black EDR server.


n Overview

n Backup

n Upgrade Server Operating System (Optional)

n Restore

Overview

This topic provides procedures for backing up and restoring a Carbon Black EDR server. The procedures are designed to ensure minimal data loss in the event of a catastrophic failure.

This topic also includes optional instructions for upgrading your server operating system between backup and restore procedures.

Backup files and data should be stored on a different server than the one that is used for daily operations.

The backed up data must be restored on the same version of the server(s) from which the backups were taken (for example, v7.5.0).

All procedures are performed at the command prompt and require root-level access.

Note n /var/cb is assumed to be the default installation data path. If you have your datastore root

configured in a different location, use that in place of what is provided here.

n Network integrations are not fully backed up. Any network integration needing a bridge or connector installed must be installed on the new restore server before restoring the configurations.

VMware, Inc. 37

Restore Servers

For all restore options, it is assumed that a new server install has been performed with the same number of primary and minion systems, each with the same number of Solr data shards in place on each system, and configured to use the same hostname and IP addresses.

All installation steps involve running cbinit (and cbcluster add-node for clustered systems). These must be completed before performing a system restore.

Backup

To backup, you must run all commands on the primary and minion systems unless otherwise noted. Perform all steps on all standalone servers.

To backup the Carbon Black EDR server:

1 Stop Carbon Black EDR services.

a Copy and save all entries in the Carbon Black server section from /etc/hosts that are marked by {{BEGIN - CB Server}} and {{END - CB Server}} comments to a remote location. There might not be a Carbon Black server section, or the section might be empty.

b Issue the following commands to back up files. (Not all files exist on some systems or installations.)

tar -P --selinux -cvf cbssh.tar /etc/ssh/

tar -P --selinux -cvf cbconfig.tar /etc/cb/

tar -P --selinux -cvf cbrootauthkeys.tar /root/.ssh/authorized_keys

tar -P --selinux -cvf cbinstallers.tar /usr/share/cb/coreservices/installers/

tar -P --selinux -cvf cbcrons.tar /etc/cron.d/cb

c You can perform a full backup, or you can skip event core backups if migration space is limited. Issue one of the following commands.

Full backup:

tar -P --selinux -cvf cbdata.tar /var/cb/

Backup without event core:

tar --exclude=/var/cb/data/solr?/cbevents/* -P --selinux -cvf cbdata.tar /var/cb

d Back up custom changes from the following locations:

/etc/rsyslog.conf

/etc/rsyslog.d/

/usr/share/cb/syslog_templates (on primary machine only)


VMware, Inc. 38

e Custom syslog changes might be specified in the /etc/cb/cb.conf file. Search the file for any SyslogTemplate= entries. For example:

WatchlistSyslogTemplateBinary=/var/custom/syslog/ watchlist_binary_custom.template

2 Save tar data to a remote location.

Upgrade Server Operating System (Optional)

You can upgrade the server operating system between backup and restore procedures.

To upgrade the server operating system on a fresh machine:

1 Install the new operating system and install the license rpm.

2 Configure the machine — the following values must match the original installation:

n IP address

n Hostname

n DNS resolution

3 Install Carbon Black EDR (or Carbon Black Unified View) and run cbinit . If this is a cluster, run add-nodes for each minion.

Restore

To restore a system, the following prerequisites must be met:

n A fresh Carbon Black EDR server (or an old snapshot) installation must be available on which to restore the backup files. All restoration activities require that Carbon Black EDR be placed in a stopped state.

n In a clustered environment, the server must have the same configuration for the primary node and minions as the system that was backed up.

n The new server(s) must be installed on the same version of the server(s) from which the backups were taken (for example, 7.5.0).

To restore:

1 Restore entries to /etc/hosts.

2 Put tar files on the server(s).

3 Remove data from the fresh install:

rm -rf /etc/cb

rm -rf /var/cb

4 Restore items from the tar files:

for f in *.tar; do tar -P -xvf "$f"; done


VMware, Inc. 39

5 Set SE Linux permissions by issuing the following commands. Depending on which package is installed, some commands might fail, but it is safe to proceed.

chcon -R system_u:object_r:rabbitmq_var_lib_t:s0 /var/cb/data/rabbitmq/

chcon -R system_u:object_r:var_log_t:s0 /var/log/cb/redis

chcon -R system_u:object_r:redis_log_t:s0 /var/log/cb/redis/*.log && chcon -R

system_u:object_r:redis_log_t:s0

/var/log/cb/redis/*.log-*

chcon -R system_u:object_r:var_log_t:s0 /var/log/cb/redis/*

6 If Carbon Black EDR version is 7.3.0 or later, set CbJavaHome=/usr/lib/jvm/jre-11/ in /etc/cb/cb.conf for all nodes.

7 Repeat the preceding steps for all cluster minions.

8 Start Carbon Black EDR.


VMware, Inc. 40

Ports and Protocols 5This topic provides port and protocol information for server communications.

Note Underlying IP addresses of identified servers can change. Avoid listing any specific IP addresses; instead, configure your firewalls to use DNS names.

Communication Port Protocol Comment

Management Station to Carbon Black EDR Server

TCP 22 SSH A management station is a machine from which system administrators can SSH into the Carbon Black EDR Server and address any required administrative tasks or troubleshooting.

Management Station to Carbon Black EDR Server

TCP 443

HTTPS (configurable)

Sensor to Carbon Black EDR Server

TCP 443


NA

Primary Carbon Black EDR Server to Minion Carbon Black EDR Server

TCP 22 SSH MinionApiPort in the cb.conf file allows configuration of the HTTPS port configuration.

TCP 443


TCP 4369

RabbitMQ

TCP 5701

datagrid

TCP 6379

REDIS

TCP 6500

sensorservices

TCP 6501

sensorservices

TCP 8080

SOLR

TCP 9000

CB data store

TCP 25004

RabbitMQ

VMware, Inc. 41


Minion Carbon Black EDR Server to Primary Carbon Black EDR Server

TCP 4369

RabbitMQ NA

TCP 5002

POSTGRES

TCP 5600

liveresponse

TCP 5701

datagrid

TCP 6379

REDIS

TCP 6500

sensorservices

TCP 6501

sensorservices

TCP 8080

SOLR

TCP 25004

RabbitMQ

Minion Carbon Black EDR Server to Minion Carbon Black EDR Server

TCP 4369

RabbitMQ NA

TCP 5701

datagrid

TCP 6500

sensorservices

TCP 6501

sensorservices

TCP 8080

SOLR

TCP 25004

RabbitMQ

Carbon Black EDR Server to a VMware Carbon Black Alliance Server

TCP 443

HTTPS For URLs that can accept VMware Carbon Black Alliance Server communications, see one of the following:

n api.alliance.carbonblack.com

Points to the VMware Carbon Black Alliance Server and has a single IP behind it that can change for various reasons over time.

n api2.alliance.carbonblack.com

Points to the VMware Carbon Black Alliance Server. The single IP behind it can be different or the same as api.alliance.carbonblack.com. It can change for various reasons over time.

Note that the IPs behind these servers are subject to change.


VMware, Inc. 42


Carbon Black EDR Server to VMware Carbon Black Threat Intel

TCP 443

HTTPS For a URL that accepts VMware Carbon Black Threat Intel communications, see threatintel.bit9.com. This URL has multiple elastic IPs behind it, and it points to the "next-gen" VMware Carbon Black Threat Intel infrastructure. The IPs behind this URL are subject to change.

Carbon Black EDR Server to YUM Repositories

TCP 443

HTTPS For an API on this type of communication, see yum.distro.carbonblack.io.

TCP 80 HTTP For an API on this type of communication, see mirror.centos.org or any other kind of enabled repository.

Note that Carbon Black EDR uses the default CentOS configuration when installing base CentOS packages.

Any communication supporting the installation or update of YUM repositories utilizes mirror.centos.org first, but that host is used only to identify the current mirror server list. After that, any of the available mirror servers might be chosen to download the actual packages.

If this default CentOS behavior is a problem, ask your system administrator to change the CentOS configuration.


VMware, Inc. 43

Installing a Cluster 6This topic introduces Carbon Black EDR clusters and explains how to configure clusters, add minions to existing clusters, remove minion nodes from clusters, and upgrade cluster nodes.


n Overview

n Configuring Clusters

n Adding Minions to Existing Clusters

n Removing Minions from Existing Clusters

n Upgrading Cluster Nodes

Overview

A Carbon Black EDR cluster is a group of servers that fulfill certain roles and operate as a single Carbon Black EDR instance. Clusters support a larger number of sensors and data than a single standalone server can support.

Carbon Black EDR collects a large volume of data at varying degrees of velocity. As volume and velocity increase, the server begins to reach the limit of what a single server can support. To support increasing volume and velocity, the infrastructure must grow horizontally. This means adding additional servers to the infrastructure. A cluster of Carbon Black EDR servers must be configured when the desired number of sensors, activity level, or amount of retention exceeds a certain threshold, which negatively impacts the performance of a single Carbon Black EDR server instance.

Horizontal scaling is used by Solr, which is the core component that Carbon Black EDR uses to store data. Solr is a big data solution that uses distributed indexes and distributes queries to those indexes. This increases query performance for high volume and velocity indexing. The Carbon Black EDR infrastructure is modeled around this concept to support optimal scaling performance.

See the VMware Carbon Black EDR Operating Environment Requirements (OER) Guide for more information on server performance and hardware requirements.

VMware, Inc. 44

Cluster Architecture

Carbon Black EDR cluster servers have one of two roles:

n Primary – Also known as a head-node and formerly known as Master

n Minion – Also known as an index(ing) node

Each cluster membership role fulfills specific functions for a single Carbon Black EDR instance. Together, the nodes in a cluster form a functioning Carbon Black EDR server that have specific functionalities and internal components configured to perform their membership roles.

The following table provides a matrix for Carbon Black EDR services and certain components compared to each role:

Service/Component Standalone Primary Minion

cb-nginx Yes Yes Yes

cb-datastore Yes Yes Yes

cb-coreservices Yes Yes Yes

cb-sensorservices Yes Yes Yes

cb-liveresponse Yes Yes No

cb-allianceclient Yes Yes Yes

cb-datagrid Yes Yes Yes

cb-enterprise Yes Yes Yes

- ThreatIntel Yes Yes No

- Statistics Yes Yes Yes

cb-redis Yes Yes Yes

cb-pgsql Yes Yes No

cb-solr Yes Yes Yes

- Process data

(cbevents core shards)

Yes No Yes

- Binary Info data

(cbmodules core)

Yes Yes Yes*

- Feed data

(cbfeeds core)

Yes Yes No

cb-rabbitmq Yes Yes Yes

Binary (modulestore) Yes No Yes

* replicated by Primary


VMware, Inc. 45

Solr clustering is performed by breaking up a single Solr core into multiple cores called shards. Shards, which are identified by a numerical integer starting at 0, are then evenly distributed to the indexing nodes (minions) for individual management and distributed querying.

For smaller cluster implementations, the primary can also perform the role of an indexing server and fulfill all roles similar to a standalone server. However, for larger organizations that have more than 60,000 sensors or four minions, the cluster must have a dedicated primary node that is not performing minion duties.

When Carbon Black EDR is clustered, internal nodal communication must occur so that the application behaves as a single instance. Most internal components can operate in this distributed capacity by making standard calls to the other components and/or nodes.

The following diagram illustrates inter-nodal cluster communications:

For RabbitMQ to function properly as a single system, it must be clustered. RabbitMQ is an application message bus that exchanges data (or messages) between the processes, application, and servers. Creating a RabbitMQ cluster allows Carbon Black EDR to exchange and queue internal (server process and application) and inter-nodal (node-to-node) messaging for proper operation as a single Carbon Black EDR instance.

Cluster Operation

A Carbon Black EDR cluster must operate with multiple servers in the same way as a standalone instance. As a result, each role must be responsible for certain aspects of a Carbon Black EDR instance.


VMware, Inc. 46

The primary node contains the user interface and is the primary front end for the API and most integrations. As users navigate the web console, standard API endpoint calls are made to the primary, which in turn queries the appropriate back-end storage location. When process data is queried, the primary distributes the query to the minions and renders the aggregated results. However, if a binary, threat intel, or alert search is performed, it only queries its local Solr cores.

The primary also contains the only instance of the PostgreSQL database that houses most of the application-specific configuration and certain state information that is used for sensor management. The primary is in charge of managing the sensor configuration and communications, which include the Live Response capabilities. Managing sensors not only requires sensor state information, but requires minion state metrics to independently distribute minion bandwidth. This allows its assigned sensors to submit data.

The minions serve as the main ingestion point for sensor data. When the primary instructs a sensor to send data to the minion, the minion receives the data and begins to ingest the data for storage. A minion will store all process-related data in its cbevents Solr core(s), where it manages its indexes separately from the rest of the cluster. This data is retrieved when the primary initiates a distributed query. Binary data is forwarded to the primary node for storage and management. This is done only one time per unique binary per sensor. Unlike the binary metadata, copies of the binaries are stored locally on the minion. The copies are submitted and stored only one time per Carbon Black EDR cluster or instance. The distribution of the binary storage depends on the sensor to which that binary was submitted. This data flow is illustrated in the following figure:


VMware, Inc. 47

Configuring Clusters

This topic describes how to configure a Carbon Black EDR cluster that contains a primary node and minion nodes.

This process involves two generic Carbon Black EDR server installs, which initially have no client software configured on them. The goal is to create a Carbon Black EDR cluster with cb-master as the primary node and cb-minion as the minion node.

You must execute the initial cbinit , which runs on the primary node.

If the node is a primary and the cluster has more than three nodes, add the following parameter to instruct the primary node not to store events:

--no-solr-events

Note The following instructions assume that you have installed the Carbon Black EDR RPM and have run the yum install cb-enterprise command on the primary node. The minion is simply a generic install of CentOS. For more information, see Installing and Initializing a Server.


VMware, Inc. 48

To set up the cluster configuration:

1 On the primary node, issue the cbinit command with the correct --no-solr-events flag defined, based on your installation. In this example, we instruct the primary node to not store events.

/usr/share/cb/cbinit --no-solr-events

Use the following Carbon Black EDR cluster management command-line tool options to initiate the cluster configuration:

[root@cb-‐master~]# /usr/share/cb/cbcluster

Usage: cbcluster COMMAND [CMD OPTIONS]

Available commands are:

help – Display this help screen

start – Start the cluster

stop – Stop the cluster

status – Get the running status of the cluster

add-node – Add a minion node to the cluster

change-node – Change parameters of the existing cluster node

remove-node – Remove a minion node from the cluster

2 From cb-master , run the following command to initiate the cluster configuration (see Best Practices):

[root@cb-master~]# /usr/share/cb/cbcluster add-node

3 Enter the following information when prompted:

n For the hostname or IP address of the remote node, enter the IP address of the server to become a minion node. For example: 172.xx.xxx.xxx .

n For the password of the server that will become a minion node, enter the root password for the server; do not enter the Carbon Black EDR password.

The Carbon Black EDR software is now installed on each minion. The yum repo configuration used on the primary is used on each node added.

4 When all minion nodes have been configured, start the cluster services:

[root@cb-master~]# /usr/share/cb/cbcluster start

5 Review the results in the config file:

[root@cb-master~]# cd /etc/cb/

[root@cb-master~]# less cluster.conf

############################################################################

#

# /etc/cb/cluster.conf:

# This file contains Carbon Black EDR server cluster configuration,

# which includes the list of participating nodes and Solr

# shards present on every one of those nodes.


VMware, Inc. 49

#

# NOTE: The contents of this file are being managed by

# /usr/share/cb/cbcluster command line tool and any changes

# made here may be overwritten next time that tool is used.

#

###########################################################################

[Cluster]

NodeCount=2

NextSlaveAutoInc=2

[Master]

Host=172.16.100.110

HasEvents=False

User=root

[Slave1] Host=172.16.100.111

HasEvents=True

User=root

6 Log into Carbon Black EDR.

7 Click Username>Settings :

8 Click Server Nodes to view the cluster nodes.

Sensor Install and Verification

This procedure adds sensors to the cluster node(s) and verifies that the installed sensors appear in the Carbon Black EDR console on the primary node.

All sensors report to the primary node and have an assigned node for reporting process events and binary data.

To install and verify sensors:

1 Log into Carbon Black EDR.

2 On the navigation bar, click Sensors.

3 In the Groups list, click the name of the group to which the new sensor will belong. If you have not created any groups, click Default Group.

4 Click Download Sensor Installer and select the sensor installer that matches your OS platform and (for Windows) installation method.


VMware, Inc. 50

5 Install the sensors on the cluster node(s). See the “Installing Sensors” chapter in the VMware Carbon Black EDR User Guide for additional help.

6 After you have installed all sensors on the cluster node(s), click Sensors on the navigation bar to verify that they appear in the primary node.

Best Practices

When configuring a Carbon Black EDR cluster, Carbon Black recommends that you refer to the VMware Carbon Black EDR Operating Environment Requirements (OER) Guide, which describes performance and scalability considerations in deploying Carbon Black EDR.

Adding Minions to Existing Clusters

This topic describes how to add minions to existing clusters.

Verify that the primary node and minion are using the same version of Carbon Black EDR.

1 Login to the primary server and stop the cluster services:

/usr/share/cb/cbcluster stop

2 Check the status to ensure the cluster services have stopped:

/usr/share/cb/cbcluster status

3 Run the cluster add node command:

/usr/share/cb/cbcluster add-node

4 On the primary server, start the cluster:

/usr/share/cb/cbcluster start

Removing Minions from Existing Clusters

Removing unneeded minions from a cluster reduces the overall cluster size and simplifies the cluster deployment. This improves cluster performance by reducing network overhead.


VMware, Inc. 51

Best Practices

Adhere to these best practices before attempting to remove minions from an existing cluster.

Consult the VMware Carbon Black Operating Environment Requirements (OER) Guide to make sure that the reduced cluster has the capacity to support the total number of endpoints.

n The remaining minions must have enough disk space to contain the full data.

n Calculate the daily usage of the disk per sensor and re-calculate the required disk space to new minions for full retention. For example:

Assume you want to collapse the six-minion cluster that has 40K endpoints down to three minions with 30-day retention. Carbon Black EDR v6.0+ supports this because each minion still has less than the maximum of 18,750 endpoints.

You calculate the current daily disk usage per sensor to be 20MB (dividing total cluster data volume storage by current daily retention and number of endpoints).

The new total storage requires a minimum of 20MB * 40K (endpoints) * 30 (days) = 24 TB (or 8 TB per node).

Add 20-30% to the available disk space on top of the calculated amount to allow for increased sensor activity in the future.

n Additional extra disk space must be provided for desired cold storage in days.

n The primary cluster node must have enough disk space to contain binary files for all removed minions. Binary files typically take less space than events, but should still be taken into account. You can calculate the required extra space on the primary node by logging into Carbon Black EDR, navigating to Server Dashboard in the left navigation bar, and viewing Storage Statistics for the minions. To obtain the maximum additional space required on the primary node, add up the total binary size on the minions that are to be removed.

n To support the sensor load, the remaining minions must have sufficient CPU and memory.

Read-Only Minions

Before removing minions from an existing cluster, you must convert them to a read-only state.

Read-only minions are searchable throughout the API and user interface but are not used for sensor checkins or event/datastore pushes. While minions are in the read-only state, the system copies the binary files to the primary node.

The event data is not added to the minions and existing data is purged periodically as in normal operations. Therefore, the read-only minions become completely inactive after the retention period. After the desired data retention period expires, you can safely remove the read-only minions.

You can revert read-only minions to active minions at any time.


VMware, Inc. 52

Removing Minions

Perform these steps to mark/unmark minions as read-only and to remove a cluster minion.

If the node_id parameter is required, it can be found inside /etc/cb/cluster.conf.

To mark minions as read-only:

1 Stop the cluster.


2 For each minion to remove, run the following command:

/usr/share/cb/cbcluster change-node -N {node_id} -R True

3 (Optional) If you have an eventless primary node and want it to contain events, run the following command:

/usr/share/cb/cbcluster change-node -E True

4 Start the cluster.

To unmark minions as read-only:

1 Stop the cluster.


/usr/share/cb/cbcluster change-node -N {node_id} -R False

3 (Optional) If you want to convert the primary node back to eventless, run the following command:

/usr/share/cb/cbcluster change-node -E False


To remove a cluster minion:

1 Stop the cluster.


/usr/share/cb/cbcluster remove-node -N {node_id}



VMware, Inc. 53

Removed minions are no longer part of the cluster and can be shut down and de-provisioned.

Note n Only read-only minions can be removed.

n The system can remove a minion only if all storefiles have been copied to the primary node. If this is not the case, an error message states how many more files must be moved.

Upgrading Cluster Nodes

There are two routes for upgrading cluster nodes:

n Run /usr/share/cb/cbcluster start on the primary node after it has been upgraded. If there are no RPMNEW files on any cluster nodes (indicating modified configuration files), this action upgrades all cluster nodes. If there are new RPMNEW files, cbcluster start will stop and prompt you to manually upgrade the nodes.

n Upgrading each cluster node manually with cbupgrade . You must do this in any case when there are new RPMNEW files.

Important If an RPMNEW file is encountered on a node during upgrade, you must reconcile the current configuration files on the node with the new configuration information, and you must remove the RPMNEW file from that node, before cbcluster start can complete successfully.

To upgrade cluster nodes:

1 Login to the primary node and stop the cluster:


2 After the cluster is completely stopped, restart it:


If there are no RPMNEW files, the cluster nodes are upgraded without further steps. If there are RPMNEW files, you must upgrade each node manually.

Manually Upgrading Cluster Nodes

The procedure for manually upgrading cluster nodes is similar to upgrading a standalone Carbon Black EDR server.

See Upgrading a Server. Additional steps are required to ensure that the cluster nodes are communicating with each other.


VMware, Inc. 54

To manually upgrade minion servers in a cluster:

1 After the primary node has been upgraded, login to each of the other machines in the cluster and upgrade cb-enterprise:

yum upgrade cb-enterprise

2 Login to each of the cluster nodes and upgrade their data schema to the latest version:

/usr/share/cb/cbupgrade [--proceed-on-rpmnew] [--non-interactive]

With no argument, this command stops running if Carbon Black EDR RPMNEW files are detected, indicating a modified configuration file. The command reports the names of those files. You must manually resolve differences between the RPMNEW and the existing configuration file of the same name, and delete the RPMNEW file before cbupgrade completes.

With the proceed-on-rpmnew argument, cbupgrade runs to completion but also reports the RPMNEW files that it discovered so that you can address them after the upgrade. This can be helpful for a seamless upgrade and are comfortable editing the configuration files later.

When the --proceed-on-rpmnew option is used with --non-interactive option, you are not prompted for the upgrade to proceed, but the cb-enterprise services do not start automatically as if you ran the command without the non-interactive option.

Caution At the end of the cbupgrade process, if you are prompted to start services, do not start the services.

3 With a new software version, communications port requirements can change. You must check whether the firewall settings require an update.

a If you are manually updating the settings, run the following command to identify which rules need to be added:

/usr/share/cb/cbcheck firewall -l

b To adjust the firewall settings automatically, run this command to have the utility apply those settings:

usr/share/cb/cbcheck firewall --apply

4 After all nodes have been upgraded (but not started), start the entire cluster by logging into the primary node and issuing the following command:


This is an important step to perform after an upgrade. When the cluster is started using the cbcluster tool, it redistributes configuration files that must be synchronized across all nodes in the cluster. If a new software version introduces configuration changes, this step ensures that each minion node has the updates.


VMware, Inc. 55

CBCLUSTER 7This topic describes how to use the CBCLUSTER command as a non-root user.


n Overview

n Required User Privileges

n Defining Users

Overview

cbcluster is a command line utility that you can use to manage and configure Carbon Black EDR clusters on the primary node.

It supports the following options:

n cbcluster start

n cbcluster stop

n cbcluster status

n cbcluster add-node

These commands run in root context and require users to have sudo privileges to invoke /usr/share/cb/cbcluster on the primary node. Additionally, the cbclusteradd-node command, which is used to add a new minion node to a cluster, connects and remotely executes on the minion a series of commands for cluster configuration.

Note n Make sure that the primary and minion nodes are running the same version of Carbon Black

EDR prior to running the cbcluster add-node command. If the versions are not the same, an error message displays.

n The cbcluster reshard command is deprecated.

As of Carbon Black EDR version 5.1.1, you can define a non-root user as the remote user for minion communication and execution. Previously, when adding a minion node to a cluster, the cbcluster utility required availability of root user on the minion node. In this and later releases, this requirement is relaxed, and minion nodes can be configured as a non-root user.

VMware, Inc. 56

This topic describes the required privileges for the non-root user and its use during cluster setup.

Required User Privileges

Before invoking cbcluster to connect to a minion as a non-root user, the remote user on the minion must have certain assigned privileges:

n SSH access to the minion node.

n Sudo privileges for the commands listed below. The user must be configured to run with NOPASSWD.

For Carbon Black EDR versions 6.2-7.3, add the following entries to your sudoers file to use the cbcluster commands with a non-root user:

## Required sudo privileges on minion to run cbcluster add-node

Cmnd_Alias HOSTNAME = /bin/hostname

Cmnd_Alias CB_INIT = /usr/share/cb/cbinit

Cmnd_Alias YUM_INSTALL_CB = /usr/bin/yum install cb-enterprise -y

Cmnd_Alias YUM_INSTALL_RSYNC = /usr/bin/yum install rsync -y

Cmnd_Alias MKDIR_ETC_CB = /bin/mkdir /etc/cb --mode=755

Cmnd_Alias MKDIR_ETC_CB_CERTS = /bin/mkdir /etc/cb/certs --mode=755

Cmnd_Alias COPY_ALLIANCE_CRT = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/

carbonblack-alliance-client.crt /etc/cb/certs/carbonblack-alliance-client.crt

Cmnd_Alias COPY_SERVER_CRT = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/cb-

server.crt /etc/cb/certs/cb-server.crt

Cmnd_Alias COPY_CLIENT_CA_CRT = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/cb-client-

ca.crt /etc/cb/certs/cb-client-ca.crt

Cmnd_Alias COPY_ALLIANCE_KEY = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/

carbonblack-alliance-client.key /etc/cb/certs/carbonblack-alliance-client.key

Cmnd_Alias COPY_SERVER_KEY = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/cb-

server.key /etc/cb/certs/cb-server.key

Cmnd_Alias COPY_CLIENT_CA_KEY = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/cb-client-

ca.key /etc/cb/certs/cb-client-ca.key

Cmnd_Alias COPY_CB_REPO = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/

CarbonBlack.repo /etc/yum.repos.d/CarbonBlack.repo

Cmnd_Alias COPY_CLUSTER_CONF = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/

cluster.conf /etc/cb/cluster.conf

Cmnd_Alias COPY_ERLANG_COOKIE = /usr/bin/rsync --remove-source-files --verbose /

tmp/.cb_tmp/.erlang.cookie /var/cb/.erlang.cookie

Cmnd_Alias COPY_SERVER_LIC = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/

server.lic /etc/cb/server.lic

Cmnd_Alias COPY_SERVER_TOKEN = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/

server.token /etc/cb/server.token

Cmnd_Alias CBCHECK_FIREWALL = /usr/share/cb/cbcheck firewall --apply

Cmnd_Alias CB_ENTERPRISE = /etc/init.d/cb-enterprise

Cmnd_Alias CAT_VERSION = /bin/cat /usr/share/cb/VERSION

Cmnd_Alias CBUPGRADE = /usr/share/cb/cbupgrade --non-interactive

Cmnd_Alias CBUPGRADE_CHECK = /usr/share/cb/cbupgrade --check

my_user ALL=(ALL) NOPASSWD: HOSTNAME, CB_INIT, YUM_INSTALL_CB, YUM_INSTALL_RSYNC,


VMware, Inc. 57

MKDIR_ETC_CB, MKDIR_ETC_CB_CERTS, COPY_ALLIANCE_CRT, COPY_SERVER_CRT, COPY_CLIENT_CA_CRT,

COPY_ALLIANCE_KEY, COPY_SERVER_KEY, COPY_CLIENT_CA_KEY, COPY_CB_REPO, COPY_CLUSTER_CONF,

COPY_ERLANG_COOKIE, COPY_SERVER_LIC, COPY_SERVER_TOKEN, CBCHECK_FIREWALL, CB_ENTERPRISE, CAT_VERSION,

CBUPGRADE, CBUPGRADE_CHECK

For Carbon Black EDR versions 7.4+, add the following entries to your sudoers file to use the cbcluster commands with a non-root user:

## Sudoers adjustments for restricted EDR cluster environments.

##

Cmnd_Alias HOSTNAME = /bin/hostname

Cmnd_Alias CB_INIT = /usr/share/cb/cbinit

Cmnd_Alias CB_CLUSTER = /usr/share/cb/cbcluster

Cmnd_Alias CB_UPGRADE = /usr/share/cb/cbupgrade

Cmnd_Alias CB_SERVICE = /usr/share/cb/cbservice

Cmnd_Alias YUM_INSTALL_CB = /usr/bin/yum install cb-enterprise -y

Cmnd_Alias YUM_INSTALL_RSYNC = /usr/bin/yum install rsync -y

Cmnd_Alias MKDIR_ETC_CB = /bin/mkdir /etc/cb --mode=755

Cmnd_Alias MKDIR_ETC_CB_CERTS = /bin/mkdir /etc/cb/certs --mode=755

Cmnd_Alias COPY_ALLIANCE_CRT = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/

carbonblack-alliance-client.crt /etc/cb/certs/carbonblack-alliance-client.crt

Cmnd_Alias COPY_SERVER_CRT = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/cb-

server.crt /etc/cb/certs/cb-server.crt

Cmnd_Alias COPY_CLIENT_CA_CRT = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/cb-client-

ca.crt /etc/cb/certs/cb-client-ca.crt

Cmnd_Alias COPY_ALLIANCE_KEY = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/

carbonblack-alliance-client.key /etc/cb/certs/carbonblack-alliance-client.key

Cmnd_Alias COPY_SERVER_KEY = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/cb-

server.key /etc/cb/certs/cb-server.key

Cmnd_Alias COPY_CLIENT_CA_KEY = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/cb-client-

ca.key /etc/cb/certs/cb-client-ca.key

Cmnd_Alias COPY_CB_REPO = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/

CarbonBlack.repo /etc/yum.repos.d/CarbonBlack.repo

Cmnd_Alias COPY_CLUSTER_CONF = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/

cluster.conf /etc/cb/cluster.conf

Cmnd_Alias COPY_ERLANG_COOKIE = /usr/bin/rsync --remove-source-files --verbose /

tmp/.cb_tmp/.erlang.cookie /var/cb/.erlang.cookie

Cmnd_Alias COPY_SERVER_LIC = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/

server.lic /etc/cb/server.lic

Cmnd_Alias COPY_SERVER_TOKEN = /usr/bin/rsync --remove-source-files --verbose /tmp/.cb_tmp/

server.token /etc/cb/server.token

Cmnd_Alias CBCHECK_IP_TABLES = /usr/share/cb/cbcheck iptables --apply

Cmnd_Alias CB_ENTERPRISE = /etc/init.d/cb-enterprise

Cmnd_Alias CAT_VERSION = /bin/cat /usr/share/cb/VERSION

Cmnd_Alias CLUSTER_OPERATIONS = HOSTNAME, CB_INIT, YUM_INSTALL_CB, YUM_INSTALL_RSYNC, MKDIR_ETC_CB,

MKDIR_ETC_CB_CERTS, COPY_ALLIANCE_CRT, COPY_SERVER_CRT, COPY_CLIENT_CA_CRT, COPY_ALLIANCE_KEY,

COPY_SERVER_KEY, COPY_CLIENT_CA_KEY, COPY_CB_REPO, COPY_CLUSTER_CONF, COPY_ERLANG_COOKIE,

COPY_SERVER_LIC, COPY_SERVER_TOKEN, CBCHECK_IP_TABLES, CB_ENTERPRISE, CAT_VERSION, CB_CLUSTER,

CB_UPGRADE, CB_SERVICE

my_user ALL=(ALL) NOPASSWD: CLUSTER_OPERATIONS


VMware, Inc. 58

See https://community.carbonblack.com/docs/DOC-5692 for a formatted version of these entries that you can copy and paste into your environment.

If any of the required permissions are not configured, the cbcluster command prompts for the missing permissions during initial validation.

Defining Users

There are two ways to invoke cbcluster and configure minion nodes as a user other than root:

n If this is a new minion that is not added to the cluster, you can configure the new user when running add-node, by including the new add-node option:

--user=<arg>

For example:

$ /usr/share/cb/cbcluster add-node --hostname <my_host> --user <my_user>

This command configures cbcluster to perform all remote actions for <my_host> as <my_user> . The / etc/cb/cluster.conf file is updated to reflect the new configuration with the key-value pair " User=<my_user> ".

n If this is an existing minion, the /etc/cb/cluster.conf file can be modified directly. Open the file in an editor, and for each minion node, add the key-value pair " User=<my_user> " where <my_user> is the actual username you want cbcluster to use when connecting to that minion.

Note To avoid potential conflicts, do not select “cb” for a username.


VMware, Inc. 59

https://community.carbonblack.com/docs/DOC-5692

Documents

VMware Carbon Black EDR Server Cluster Management Guide