Virtual Appliance Sizing Specifications

This article describes the resources required for the successful installation and operation of Stellar Cyber virtual appliances (sensors, aggregators, and DPs).

Sensor Specifications

You can install modular, security, network, container, and server (agent) sensors. Security and network sensors install as dedicated VMs; container sensors install as containers. Server sensors install as applications in an existing VM (Linux or Windows).

See the following sections for details:

• Modular Sensor Specifications

• Network Sensor Specifications

• Security Sensor Specifications

• Linux Server Sensor Specifications

• Windows Server Sensor Specifications

• Virtual Appliance Sizing Specifications

Provision Sufficient Resources for Virtual Sensors!

In order to guarantee the performance of your virtual sensors, you must provision them according to the system requirements for CPUs and memory in the sections that follow. For hypervisors that allow it, you must reserve resources using the procedure below.

In addition, pay attention to the clock speed for provisioned processors. Stellar Cyber validates sensor installations on processors @ 2.10 GHz.

Other hypervisors may provide their own tools for reserving resources. Refer to your hypervisor's documentation for details. In general, Stellar Cyber recommends reserving resources wherever possible to guarantee sensor performance.

Note that Stellar Cyber recommends using the Thick Provision option when creating the virtual machine to maximize disk I/O rates.

To reserve resources in a VMware environment:

1. Open the vSphere Client and navigate to the VMs and Templates view.

2. Make sure the VM whose provisioning you want to change is shut down. You can only change CPUs and memory for VMs that are shut down.

3. Right-click the VM for the Stellar Cyber sensor whose resources you want to reserve and choose Edit Settings from the menu that appears.

   

   The Edit Settings dialog box appears.

4. Cascade open the CPU entry and set the CPU value to the required amount for the features you are enabling.

5. Next, you'll reserve CPU resources. You do this differently depending on whether hyperthreading is enabled on the host server. The table below summarizes the calculations you make depending on whether or not hyperthreading is enabled on the ESXi host:

   Hyperthreading Enabled on ESXi Host?	CPU Reservation Calculation
   Hyperthreading Enabled (most common scenario)	(Number of CPUs Provisioned for VM) x (ESXi Host CPU Speed in Hz) / 2
   Hyperthreading Not Enabled	(Number of CPUs Provisioned for VM) x (ESXi Host CPU Speed in Hz)

   Examples:

   The following examples illustrate sample CPU reservation calculations for a sensor VM with 16 CPUs provisioned in different ESXi environments:

   • Hyperthreading Enabled, 96.8 GHz Capacity

     • CPU Capacity – 96.8 GHz (reported in Reservation dropdown in Edit Settings dialog box)

     • Logical Processors – 88

     • Processor type – Intel(R) Xeon(R) CPU ED-2696 v4 @ 2.20 GHz

     • Sockets – 2

     • Cores per socket – (blank)

     In this example, we use the following generic calculation for scenarios with hyperthreading enabled:

     (Number of CPUs Provisioned for VM) x (ESXi Host CPU Speed in Hz) / 2

     We will provision 16 CPUs and fill in the variables for our example as follows:

     (16 CPUs) x (2.20 GHz/CPU) / 2 = 17.6 GHz

   • Hyperthreading Disabled, 96.8 GHz Capacity

     • CPU Capacity – 96.8 GHz (reported in Reservation dropdown in Edit Settings dialog box)

     • Logical Processors – 44

     • Processor type – Intel(R) Xeon(R) CPU ED-2696 v4 @ 2.20 GHz

     • Sockets – 2

     • Cores per socket – (blank)

     In this example, we use the following generic calculation for scenarios with hyperthreading disabled:

     (Number of CPUs Provisioned for VM) x (ESXi Host CPU Speed in Hz)

     We will provision 16 CPUs and fill in the variables for our example as follows:

     (16 CPUs) x (2.20 GHz/CPU) = 35.2 GHz

   • Hyperthreading Enabled, 33.6 GHz Capacity

     • CPU Capacity – 33.6 GHz (reported in Reservation dropdown in Edit Settings dialog box). Two sockets multiplied by six cores/socket multiplied by 2.80 GHz per core.

     • Logical Processors – 24

     • Processor type – Intel(R) Xeon(R) CPU X5660 @2.80GHz

     • Sockets – 2

     • Cores per socket – 6

     In this example, we use the following generic calculation for scenarios with hyperthreading enabled:

     (Number of CPUs Provisioned for VM) x (ESXi Host CPU Speed in Hz) / 2

     We will provision 16 CPUs and fill in the variables for our example as follows:

     (16 CPUs) x (2.80 GHz/CPU) / 2 = 22.4 GHz

     Note that if you used the wrong calculation in this scenario and did not divide by two, the resulting value of 16 CPU x 2.80 GHz = 44.8 GHz would exceed the total CPU capacity of 33.6 GHz. Also, if you reserved the maximum available capacity of 33.6 GHz, you would commit all of the host's CPU resources to just this machine. This is why it's important to use the correct calculation for your host when reserving CPU resources.

6. Cascade open the Memory entry and set it to the required amount for the features you are enabling.

7. Check the Reserve all guest memory (All locked) option to reserve the full amount of memory for the sensor VM's usage.

   

8. Click OK to apply your changes to the VM.

9. Power on the VM.

Refer to the VMware documentation for a general discussion of resource reservation as well as a set of suggested best practices for reserving resources.

Modular Sensor Specifications

A modular sensor lets you easily add the features you like to your sensor. This helps simplify your deployment and lets you manage the VM requirements for the sensors based on the modular features they use. A modular sensor is also recommended by Stellar Cyber when you want to deploy an aggregator – simply enable the Aggregator feature in its Modular Sensor Profile.

The modular sensor VM must meet the minimum specifications in the table below:

Modular Features	Virtual Cores	RAM (GB)	SSD (GB)	Workers
Log forwarder (500 events/s)	1	3	64	1
Log forwarder and aggregator (500 events/s; 100 Mbps traffic)	1	3	64	1

The OVA/VHD files distributed for Modular Sensor installation in VMware/Hyper-V environments provision the VM with 1 virtual core, 3 GB of RAM, and a 64 GB disk. You must provision sufficient resources to support the features you anticipate enabling for the Modular Sensor in its Modular Sensor Profile. Use the table below to determine the total resources required for different combinations of the features available in a Modular Sensor Profile.

As a rule of thumb, Stellar Cyber recommends that you provision at least 1.5 times as much memory as the number of CPU cores to ensure stable performance. So, for example, if you provision 8 CPUs, you should provision at least 8 x 1.5 = 12 GB of memory.

CPU	RAM (GB)	Disk (GB)	Log Collector Log Forwarder	Network Traffic	IDS	Sandbox	Tenable
1	3	23	ü	–	–	–	–
2	3	28	ü	ü	–	–	–
4	6	50	ü	ü	ü	–	–
4	6	50	ü	ü	–	ü	–
4	6	50	ü	ü	ü	ü	–
2	4	33	ü	–	–	–	ü
3	5	38	ü	ü	–	–	ü
4	8	60	ü	ü	ü	–	ü
4	8	60	ü	ü	–	ü	ü
4	8	60	ü	ü	ü	ü	ü

Keep in mind the following:

• Log Collector and Log Forwarder are always enabled in Modular Sensor Profiles.

(missing or bad snippet)

• The Sandbox and IDS features can only be enabled if Network Traffic is enabled.

• Modular Sensor throughput is the same as stated for Security Sensors when provisioned similarly.

Linux Server Sensor Specifications

The Linux Server Sensor uses 5% of the host server's resources, including each CPU core, so the VM must have at least:

Component	Specification
Host CPU	Xeon Core 2 virtual cores (2.0 GHz or more)
Host RAM (GB)	12
Host SSD (GB)	128

Windows Server Sensor Specifications

The Windows host into which the Windows Server Sensor is installed must have at least:

Component	Specification
Host CPU	Xeon Core 2 virtual cores (2.0 GHz or more)
Host RAM (GB)	8
Host SSD (GB)	128
OS	Windows Server 2008 R2 (or later)

Enabling SSSE3

Sensors installed on Linux hosts with KVM hypervisors must have SSSE3 enabled for their vCPUs in order to collect network packets (including packets received from a mirror port) and generate Interflow data from them. This is true for both device sensors and server sensors.
SSSE3 is typically supported/enabled for most vCPUs, but may not be for certain legacy AMD vCPUs. See below for instructions on enabling SSSE3.

Similarly, sensors deployed in Hyper-V must have processor compatibility mode disabled to ensure that SSSE3 works correctly. Refer to Installing a Modular, Network, or Security Sensor in Hyper-V for instructions.

To enable SSSE3 for a virtual machine:

1. Start the virtual shell (virsh)

2. Type the following command to edit the virtual machine's settings:

   edit <virtual_machine_name>

3. Locate the <cpu> section. It should appear similar to the following:

   Copy

   <cpu mode='custom' match='exact' check='partial'>
   
                                   <model fallback='allow'>SandyBridge</model>
   
                                   ......
   
                               </cpu>

4. Add the following line to the <cpu> section:

   <feature policy='require' name='ssse3'/>

   When you are done, the <cpu> section should appear similar to the following:

   Copy

   <cpu mode='custom' match='exact' check='partial'>
   
                                   <model fallback='allow'>SandyBridge</model>
   
                                   <feature policy='require' name='ssse3'/>
   
                                   ...........
   
                               </cpu>

5. Save changes to the virtual machine and exist virsh.

6. Run the following command:

   virsh define /etc/libvirt/qemu/<virtual_machine_name>.xml

   Each virtual machine has a configuration .xml file. Typically, these files are stored under /etc/libvirt/qemu, but the location may be different for your system.

7. Stop and start the virtual machine in virsh.