Akamai Guardicore Segmentation Admin User Guide

Guardicore
Centra Security Platform 5.0
Version 41
Administration Guide
Contents
CENTRA ADMINISTRATOR RESPONSIBILITIES............................................................................................................6
CENTRA ARCHITECTURE ....................................................................................................................................................7
OVERVIEW ........................................................................................................................................................................................................ 7
GUARDICORE MANAGEMENT SERVER.......................................................................................................................................................... 8
Management Layer Services .................................................................................................................................................................. 8
AGGREGATORS ................................................................................................................................................................................................. 9
How Aggregators Connect to Agents ...............................................................................................................................................11
COLLECTORS...................................................................................................................................................................................................12
TYPES OF COLLECTORS ................................................................................................................................................................................12
ESX Collector ..............................................................................................................................................................................................12
SPAN Collector ..........................................................................................................................................................................................13
VPC Flow Logs Collector .......................................................................................................................................................................14
IPFix Collector ............................................................................................................................................................................................ 16
IP Flows Collector ..................................................................................................................................................................................... 16
AGENTS ...........................................................................................................................................................................................................18
Agent Connections ....................................................................................................................................................................................18
DATA COLLECTION: AGGREGATORS AND COLLECTORS ........................................................................................ 19
WHEN TO USE AGGREGATORS ....................................................................................................................................................................19

WHEN TO USE COLLECTORS........................................................................................................................................................................19
POLICY DERIVATION TO AGENTS.................................................................................................................................. 20
POLICIES AS INPUT/OUTPUT CHAINS ........................................................................................................................................................20

WHAT TRIGGERS POLICIES?........................................................................................................................................................................20
HOW POLICIES ARE MATCHED TO AGENTS ..............................................................................................................................................21
EXAMPLE OF INPUT/OUTPUT CHAINS FOR IMPLICIT RULES .................................................................................................................23
EXAMPLE OF INPUT/OUTPUT CHAINS FOR PUBLISHED ALERT RULE .................................................................................................24
AGGREGATOR ADMINISTRATION ................................................................................................................................. 26
AGGREGATOR SCREEN ..................................................................................................................................................................................26

AGGREGATOR OPERATION AND CONFIGURATION ...................................................................................................................................27
Aggregator Override Configuration Option ..................................................................................................................................28
AGGREGATOR CLI .........................................................................................................................................................................................30
COLLECTOR ADMINISTRATION ..................................................................................................................................... 33
COLLECTORS SCREEN ...................................................................................................................................................................................33

COLLECTOR OPERATION AND CONFIGURATION .......................................................................................................................................34
Collector Override Configuration Option .......................................................................................................................................35
Administration Guide - Centra Security Platform 5.0 v41 1

AGENTS AND OS SUPPORT .............................................................................................................................................. 37
AGENTS IN A LINUX ENVIRONMENT ...........................................................................................................................................................37

Linux Agent OS Support .........................................................................................................................................................................37
Linux Agent Processes .............................................................................................................................................................................39
AGENTS IN A SOLARIS ENVIRONMENT .......................................................................................................................................................40
Solaris Agent OS Support.......................................................................................................................................................................40
Solaris Agent Processes ..........................................................................................................................................................................40
Storage, CPU and Memory Usage in a Solaris Environment..................................................................................................41
Agents Deployed on Solaris Zone Servers.......................................................................................................................................42
IPFilter Usage for Solaris Agent .........................................................................................................................................................42
AGENTS IN A HP-UX ENVIRONMENT ........................................................................................................................................................43
HP-UX Agent OS Support .......................................................................................................................................................................43
AGENTS IN AN AIX ENVIRONMENT ............................................................................................................................................................43
AIX Agent OS Support..............................................................................................................................................................................43
IPFilter Usage for AIX Agent ................................................................................................................................................................43
Storage, CPU and Memory Usage in AIX Environment ............................................................................................................44
AGENTS IN A WINDOWS ENVIRONMENT ...................................................................................................................................................44
Windows Agent OS Support..................................................................................................................................................................44
Agent Processes in a Windows Environment................................................................................................................................45
Storage, CPU, and Memory Usage in a Windows Environment ...........................................................................................46
INTEROPERABILITY OF CENTRA ENFORCEMENT WITH WINDOWS FIREWALL AND LINUX IPTABLES . 47
INTEROPERABILITY OF CENTRA ENFORCEMENT AND WINDOWS FIREWALL .....................................................................................47

INTEROPERABILITY OF CENTRA ENFORCEMENT AND LINUX IP TABLES ............................................................................................48
AGENT ADMINISTRATION ............................................................................................................................................... 48
AGENTS SCREEN ............................................................................................................................................................................................48

Agent Flags ..................................................................................................................................................................................................50
Filtering the Agents Screen Display ..................................................................................................................................................51
Generating Agents Diagnostics ...........................................................................................................................................................52
Deleting an Agent from the System ..................................................................................................................................................52
AGENT ADMINISTRATION LOCK..................................................................................................................................................................53
Windows Agent Administration Lock ..............................................................................................................................................53
Administration Lock on Other Operating Systems.....................................................................................................................53
Enabling the Agent Lock ........................................................................................................................................................................53
Unlocking the Agent.................................................................................................................................................................................55
Locking and Unlocking the Agent through the Centra Administration Agents Screen .............................................57
Locking and Unlocking the Windows Agent from the Command Prompt.......................................................................59
Local Control for Other OSs ..................................................................................................................................................................59
OLDER AGENTS AND RULE LIMITATIONS..................................................................................................................................................60
Rule Derivations ........................................................................................................................................................................................61

LOCAL ADMINISTRATION OF AGENTS ......................................................................................................................... 62
WINDOWS AGENT ADMINISTRATION UI...................................................................................................................................................62

Enforcement using the Windows Agent UI ....................................................................................................................................63
pausingSuspending the Agent .............................................................................................................................................................64
Reporting an Issue ....................................................................................................................................................................................65
AGENT CLI FOR LINUX .................................................................................................................................................................................66
AGENT LOG ROTATION PROFILES ................................................................................................................................ 69
AVAILABLE PROFILES ...................................................................................................................................................................................69

INSTALLATION CONFIGURATION FOR AGENT LOG ROTATION ..............................................................................................................70
Installation for Agent Log Rotation on Windows .......................................................................................................................70
Installation for Agent Log Rotation on Linux/Solaris/AIX ....................................................................................................70
RESOURCE USAGE MANAGEMENT FOR AGENTS ....................................................................................................... 70
SETTING HARD AND SOFT LIMITS ..............................................................................................................................................................70

WHY SET AGENT RESOURCE USAGE LIMITS? ..........................................................................................................................................71
PRE-CONFIGURED RESOURCE LIMITATION PACKAGES ..........................................................................................................................71
RESOURCE LIMITATION PACKAGES: TABLES OF VALUES PER MODULE ..............................................................................................71
Resource Limitation Packages for Linux ........................................................................................................................................71
Resource Limitation for Solaris / AIX ..............................................................................................................................................74
Resource Limitation for Windows: Supported Windows OS..................................................................................................74
Resource Limitation Packages for Windows ................................................................................................................................74
SETTING INITIAL RESOURCE LIMITS DURING AGENT DEPLOYMENT ...................................................................................................74
Setting Resource Usage Limits for Windows Agents .................................................................................................................75
Setting Resource Usage Limits for Linux Agents.........................................................................................................................75
CHANGING RESOURCE USAGE LIMITS LOCALLY USING THE CLI ..........................................................................................................77
Changing Limits Locally Using the CLI in Windows ..................................................................................................................77
Changing Limits Locally Using the CLI in Linux ..........................................................................................................................78
SETTING LIMITS AFTER DEPLOYMENT USING THE CENTRA UI ............................................................................................................78
For Advanced Users Only: Overriding Pre-Configured Values ..............................................................................................80
REVEAL DATA RETENTION ............................................................................................................................................. 82
OVERVIEW ......................................................................................................................................................................................................82
WHEN SHOULD THE RETENTION POLICY BE CHANGED? .......................................................................................................................82
CONFIGURING A RETENTION POLICY FOR CENTRA ES ...........................................................................................................................83
Listing Existing Indices and Storage ................................................................................................................................................83
Formulating a Retention Policy..........................................................................................................................................................83
Using the CLI to Configure Retention...............................................................................................................................................83
OTHER ES DATA TYPES AND HOW TO CONTROL THEM ........................................................................................................................87
TROUBLESHOOTING.......................................................................................................................................................... 88
LISTING AGGREGATORS AND COLLECTORS ...............................................................................................................................................88

CONTROLLING AGGREGATOR/COLLECTOR SERVICES .............................................................................................................................88
Starting a Component’s Subcomponent .........................................................................................................................................89
Restarting all of an Aggregator/Collector’s Services ...............................................................................................................90
UPGRADING .......................................................................................................................................................................... 90
GUARDICORE LINUX AGENT DEEP DIVE REVEAL + ENFORCEMENT .................................................................. 91
FUNCTIONALITY.............................................................................................................................................................................................91
HIGH LEVEL ARCHITECTURE OVERVIEW ..................................................................................................................................................91
COMPONENTS OVERVIEW ............................................................................................................................................................................92
BACKUP AND RESTORE .................................................................................................................................................... 94
WHAT IT DOES ...............................................................................................................................................................................................94

BACKUP PROCEDURE ....................................................................................................................................................................................94
OPTIONAL PARAMETERS ..............................................................................................................................................................................94
RESTORE PROCEDURE ..................................................................................................................................................................................94
NOTES .............................................................................................................................................................................................................95
LIMITATIONS ..................................................................................................................................................................................................95
WHAT IS BACKED UP? ...................................................................................................................................................................................96
STORAGE, CPU, AND MEMORY UTILIZATION ...........................................................................................................................................96
CPU ..................................................................................................................................................................................................................97
Memory ..........................................................................................................................................................................................................97
Storage...........................................................................................................................................................................................................98
COMMUNICATION WITH THE AGGREGATOR ..............................................................................................................................................99
COMMON SCENARIOS AND PROCEDURES ..................................................................................................................................................99
Initiation .......................................................................................................................................................................................................99
Upgrade ...................................................................................................................................................................................................... 100
Policy Setting/Update .......................................................................................................................................................................... 101
Policy Rules per Agent ......................................................................................................................................................................... 101
Read Connections Log .......................................................................................................................................................................... 101
Kernel Upgrade ....................................................................................................................................................................................... 101
LOCAL AGENT ADMINISTRATION ............................................................................................................................................................102
Agents Uninstall...................................................................................................................................................................................... 104
Agents Directory Structure ................................................................................................................................................................ 104
KO CLOUD .......................................................................................................................................................................... 105
WHAT IS KO CLOUD? ................................................................................................................................................................................105

HOW IS KO CLOUD POPULATED?............................................................................................................................................................105
WHAT HAPPENS WHEN NO SUPPORTED MODULES ARE FOUND? ...................................................................................................106
WHAT HAPPENS WHEN KO CLOUD IS NOT ACCESSIBLE?..................................................................................................................106
GUARDICORE’S DISASTER RECOVERY SOLUTION: HOW IT WORKS ...................................................................................................107
What's synced .......................................................................................................................................................................................... 107
What's not synced .................................................................................................................................................................................. 107

Instructions for Configuring the System for Disaster Recovery ........................................................................................ 108
Initiating Failover .................................................................................................................................................................................. 110
Instructions for Performing a Failback........................................................................................................................................ 111
CIRCUIT BREAKER .......................................................................................................................................................... 111
DISASTER RECOVERY ..................................................................................................................................................... 113
GUARDICORE’S DISASTER RECOVERY SOLUTION: HOW IT WORKS ...................................................................................................113

What's synced .......................................................................................................................................................................................... 113
What's not synced .................................................................................................................................................................................. 113
Instructions for Configuring the System for Disaster Recovery ........................................................................................ 114
Initiating Failover .................................................................................................................................................................................. 115
Instructions for Performing a Failback........................................................................................................................................ 116
FAILBACK TO NEW PRIMARY ...................................................................................................................................................................116
Preliminary steps ................................................................................................................................................................................... 117
Failback Steps .......................................................................................................................................................................................... 117
NETWORK LOG BACKUP AND RESTORE .................................................................................................................. 120
HOW IT WORKS ...........................................................................................................................................................................................120

Backup Script ........................................................................................................................................................................................... 120
Restore Script........................................................................................................................................................................................... 120
AGENT OS SUPPORT ....................................................................................................................................................... 121

Centra Administrator Responsibilities
As an administrator, you are responsible for making sure that Agents, Aggregators, and
Collectors are correctly functioning. This involves the following tasks:
• Configure Agents, Aggregators and Collectors for their environment.
• Ensure that components are correctly installed and deployed.
• Customize components to your environment.
• Ensure that all of the component files and folders exist.
• Monitor the operational status and health of components.
• Ensure that components are properly integrated with your environment. This includes
making sure that the required ports and connections are open.
• Manage the operation of components. This includes the following:
• Start, stop, or restart (reboot) components.
• Control the operation mode of components (on, off, monitor)
• Delete, upgrade, and reinstall components when required.
• Troubleshoot: There are many instances where the administrator can solve a problem.
Where this is not possible, the administrator should contact Guardicore support.

Centra Architecture
Overview
Guardicore Centra gathers data on flows in your system by deploying several types of software
components: Agents, Aggregators, and Collectors. All of the information is sent to the
Guardicore Management server which provides a single point of control for all data received by
the components. The Management server analyzes, enriches, and integrates the data so that it
can be used to provide a clear visualization of information flows in your system, as well as to
provide alerts and enforcement of security policies that regulate information flows.
Here is a brief overview of Centra’s components:
• Agents are deployed on each device in your network and are capable of sending
information that reveals the source and destination of flows, rerouting suspicious flows to
the Deception server (honeypot), and enforcing security policies.
• Virtual machines called Aggregators gather and process the data gathered from Agents,
and communicate with the Guardicore Management server.
• Virtual machines called Collectors gather information on information flows in

environments where Agents cannot be installed.
• A Management Server receives, analyzes, enriches, and manages the collected data.
• A Deception Server manages a farm of different-flavored honeypot instances (Windows

and Linux). Failed connections are redirected to a fully interactive honeypot, limiting the
attackers interactions to that instance. Following session recording and automatic
analysis of its content, complete incident information is reported to Management.

Guardicore Centra Architecture Diagram
The following sections provide more details on each component.
Guardicore Management Server

The Management layer provides the following functions:
• UI and REST API for system’s users
• Receiving, analyzing, enriching and managing storage of collected data
• Alerting and automated reporting
• Solution integration with SIEM and/or internal mail servers
• Monitoring and health control of all system components
• Managing the configuration of all system components
• Managing the patching/upgrade of all system components
For installations exceeding 500 Agents, the Management layer is deployed in a clustered manner
that supports high-availability and scalability.
Management Layer Services
The Management layer comprises the following main services:
Master service
The Master service is the orchestrator of all services running within the Management layer. In
addition, it exposes the system’s REST endpoint for UI and API usage, and is the communication
gateway for the system’s distributed components (Aggregators, Collectors and Deception
servers). Master instances are also Slaves, capable of fulfilling Slave duties as described below.
Slave
A slave instance executes the Management application workers such as data processing, policy
matching, alert triggering, healthcare control, etc. Multiple Slave instances provide the
application workers with HA. This component scales out linearly, according to the number of
Agents and Collectors.
RabbitMQ
The RabbitMQ service is a messaging mechanism for messages exchanged between the system’s
components, directing them to the right node and queue and storing them until consumed. For
automatic failover of this service, two RabbitMQ instances can be configured.

MongoDB
A MongoDB database is used to store the complete system configuration and detected security
incidents. For data redundancy and automatic failover of this service, a cluster of three
MongoDB instances can be deployed.
ElasticSearch
An ElasticSearch database is used to store the network flow data collected by the system’s
components (the Reveal map). This component is scaled out according to the number of Agents
and Collectors and the data retention policy requirement. Within an ElasticSearch cluster, HA of
both nodes and data redundancy can be configured.
InfluxDB
The InfluxDB database is used to store the recent healthcare data collected from the system’s
components. The availability of this service affects the healthcare control functionality only.
Aggregators
An Aggregator is a VM that aggregates and de-duplicates data it receives from its associated
Agents and then sends it to the Management Server. To support scaling, a single Aggregator can
be deployed per hundreds of Agents. In addition to gathering and sending the data to the
Management Server, the Aggregator manages the configuration of associated Agents.
Aggregators can be deployed in clusters. This provides the following:

Automatic load balancing capability between Aggregators within the cluster, resulting in a
uniform load distribution.
Agent to Aggregator High Availability as Agents round robin between the cluster’s Aggregators.
Configuring HA is typically done with a common FQDN for Aggregators, managed by a DNS or
GSLB solution. Direct IP-list configuration of a cluster’s Aggregators is also supported.
Both Aggregators and Collectors integrate with various orchestration layers such as VMWare,
AWS, Kubernetes, etc. This enables the automated pulling of asset information, labels and more
into the Centra™ platform.
Depending on allocated compute resources, a single Aggregator can support between an average
of 200 and 2000 agents with Micro-Segmentation feature-set (Reveal + Enforcement +

Detection modules active on agent, Deception module disabled), or an average of 100 Agents (all
modules, including Deception, are active on Agents).

How Aggregators Connect to Agents
The following describes how Aggregators connect to Agents and manages them:
Each Agent connects to a Guardicore Aggregator server over SSL, with a certain SNI (Server
Name Indication). The connection is always initiated by the Agent. The Aggregator and the
Management server differentiate between Agents by a unique ID generated on the Agent.
The Aggregator handles new incoming connections with HaProxy, which determines the Agent
type by the SNI and forwards the connection to the relevant service, depending on the type of
Agent (see the section on Agents for a description of the types of Agents and their associated
services).
The Aggregator sends commands and requests to the Agents and gets responses. For example, in
the case of Reveal modules, the Aggregator sends a start-monitoring command that starts a
monitoring thread. Deception and Enforcement modules can push messages to the Aggregator
as well.
Aggregators can be configured either globally or individually.
Agents and Aggregators Connection Diagram

Collectors
Collectors are virtual machines that gather information on flows in environments where Agents
cannot be deployed. Such environments include legacy systems incompatible with Agent
software, as well as environments outside of your system that interface with your network.
Collectors integrate with the switching infrastructure to perform the following functionalities:
Reporting layer 4 network-flow information to Management. This data is used to gain wide
visibility across the network, visualizing and alerting on traffic with which Guardicore Agents are
not associated. It also allows IP Reputation analysis.
In installations that do not enable the Agent Deception module, Collectors detect failed flows,
forwarding those for Deception investigation.
Detecting network scanning activity.
Logging DNS traffic and allowing DNS Reputation analysis.
On physical infrastructure, Collectors connect to SPAN/TAP ports or integrate with 3rd party
NPB solutions. On VMware ESXi, Collectors use a promiscuous port group to receive a copy of
all traffic traversing the selected vSwitch(es).
Collectors relay data to the Guardicore Management server for further analysis and integration
into Guardicore’s Reveal charts. Collectors are also able to detect suspicious flows, redirect them
to a SPAN port for further analysis, and, where warranted, divert them to the Deception server
(honeypot).
You deploy Collectors during the installation of Guardicore Centra. During Installation you can
choose to deploy Collectors in two ways:
Use Guardicore’s deployment tool (GuarDeployer) to automatically deploy multiple Collectors.
–OR–
Manually deploy and configure each Collector separately.
During installation, Wizards guide you through the steps of deploying the various types of
Collectors. As of release 40, you can choose to deploy five types of Guardicore Collectors: ESX
Collector, SPAN Collector, AWS VPC Flow Logs Collector, IPFix Collector and IP Flows Collector:
The ESX Collector is a VM that integrates with ESX hosts and should be deployed as a VM on
each protected hypervisor and fixed to the host (make sure vMotion is disabled). The standard
ESX Collector analyzes communication flows sent to a SPAN port by a VSS (Virtual Standard

Switch) or VDS (vSphere Distributed Switch) switch. You can also configure an ESX Collector to
work with the less common N1KV switch.
Multiple vSwitches on the same host can be monitored with a single ESX Collector:
The ESX collector is responsible for the following:

Detection of suspicious traffic and redirecting it to the Deception Server for further
investigation.
Collection of network level information (L4) about all traffic flows. The ESX Collector also
enables reputation on IPs and DNS. An ESX Collector should be deployed as a VM on each
protected hypervisor and fixed to the host (make sure vMotion is disabled).
ESX Collector Configuration

The ESX Collector is installed on an ESX virtual machine and collects information between the
ESX and systems that interface with it. The datapath implementation uses the vSphere port
mirroring feature (new since 5.0) in order to allow Guardicore to analyze the traffic inside the
ESX Host and protect its virtual machines.
The SPAN Collector is deployed as a VM for physical networks and analyzes communication
flows sent by a switch to a SPAN port. More specifically, it receives traffic for inspection from
SPAN ports, network taps or Network Packet Brokers (NPBs). This Collector requires a return
port back to the network to be able to perform packet redirection.

Both the ESX and SPAN Collectors gather information from a SPAN port (virtual or physical) and
send that information to the Guardicore Management Server for analysis and appropriate action.
Span Collector Configuration

For the SPAN Collector, an important setting is to make sure that protected_cidr is configured. If
this option is not set, the Collector will not report any flows and the following message is
displayed:
Port mirroring without any protected CIDR's
To configure a SPAN port with protected_cidr, perform the following:
On the Administration panel, select Components, Collectors.
From the list of Collectors, select the Collector that you want to configure and click the More
button.
On the More button, select Configuration Overrides, then select the Show Advanced Options
checkbox.
Under Datapath, select Port Mirror Cloud Driver.
Select protected_cidr and supply a list of subnets in CIDR notation.
Guardicore’s AWS VPC Flow Logs Collector provides a way to inspect all the flows between the
different cloud assets within an Agentless cloud network such as AWS. The Collector gathers
logs from the AWS VPC Flow Logs feature (which publishes the information to Amazon
CloudWatch Logs and Amazon S3) and sends it to the Guardicore Management server. The
Management server then integrates the log information into Reveal, Guardicore’s Visibility
module, where it provides a clear view of the flows within the cloud environment.

The integration of the VPC flow logs information into Guardicore’s Reveal module can help you
with a number of tasks:
Troubleshoot why specific traffic is not reaching a destination, which in turn helps you diagnose
overly restrictive security group rules.
Use flow logs as a security tool to monitor the traffic that is reaching your environment.
Policy-wise, only alerts are supported without enforcement.
To allow VPC flow logs, install a dedicated Collector during installation and configure VPC flow
logs in AWS orchestration.
Additional Information About the AWS VPC Flow Logs Collector

No need for log persistence in the account.
One vpc flow log collector can cover multiple regions on multiple accounts. Currently there is no
way to control which collector takes care of which account.
Scale has been tested for a production multi region account with 500K flow per day.
Known AWS Flow Logs limitations

Flow logs do not capture real-time log streams for the network interfaces, there is an approx. 10-
15 minute delay.
The Flow Logs will not include any of the following traffic:
- Traffic to Amazon DNS servers, including queries for private hosted zones.
- Windows license activation traffic for licenses provided by Amazon.

- Requests for instance metadata.
- DHCP requests or responses.
IPFix Collector
Deployment of IPFIX collectors is required if you want to configure Big-IP F5 orchestration with
Centra. For networks that use F5 Big-IP Local Traffic Manager (LTM), Centra’S IPFix collector
provides visibility for flows passing through the Big-IP on monitored virtual servers.
After the Centra administrator configures F5 Orchestration, the virtual servers appear as assets
on the Assets screen and are labeled as Role:F5 Big-IP. Centra then consumes connection events
over IPFIX to display the flows to and from the virtual servers as continuous flows on the Reveal
map.
IP Flows Collector
Guardicore’s IP Flow Collector enables Centra to receive flow information and present it on the
Reveal map, as well as the Network log. This enables users to view and understand the flow of
traffic running on the network and specifically traffic from devices without deployed Agents
(either IoT, appliances, or laptops).
The information from the IP Flow collector enables administrators to better understand traffic
flows and develop better security policies for allowing or blocking. The IP Flow collector
provides valuable information that is unavailable from other types of collectors. For example, it
injects switch and port information as metadata on identified assets.
Centra’s IP Flow Collector can be deployed during Centra installation and supports 3 protocols:
Netflow 5 and 9, IPFi, and sFlow.

A single IP flow collector supports a maximum of 7.5 million flows per second and/or at least 35
switches. The specs are based on a VM collector with the following hardware configuration:
4 vCPUs
4GB RAM
30GB Hard disk
4 mitigation workers
The sampling ratio that was tested was 1:1.

Agents
Agents are a main source of data for Guardicore Centra, and, together with Aggregators, they
also enable policy enforcement. By deploying Agents on all the devices in your system,
Guardicore can analyze and control all flows within your network. Agents can be deployed on a
variety of platforms such as virtual machines, bare metal servers, cloud servers, etc. and are
supported for both Windows and Linux, and partially for Solaris.
An Agent can include up to four separate modules: Reveal, Deception, Detection, and
Enforcement:
Reveal Agents provide process-level visibility and file reputation. They collect process-
level information on all connections including protocols, ports, and corresponding
processes (path, user, command line, hash, etc.).
Detection Agents are responsible for File Integrity Monitoring (FIM).
Enforcement Agents block traffic based on network-level and/or process-level policy, and
process DNS requests and replies.
Deception Agents detect failed connection attempts and redirect them to a Deception Server for
further investigation. (The Deception Server manages a farm of multiple honeypots of different
flavors, Windows and Linux.)
Note: Deception Agents have several roles parallel to those of an ESX Collector, and must not be
installed on virtual servers that are hosted on ESXi hypervisors already protected by ESX
Collectors. When installing the system, Guardicore Solution Center decides which is the optimal
deployment for the client.
In addition, there is a Controller module, and two channels, Reveal and Enforcement, that
connect the Agent to the Aggregator as explained in the next section.
Agent Connections
Each Agent connects to a GuardiCore Aggregator server over SSL. The Aggregator and the
Management server differentiate between Agents by a unique ID generated on the Agent. The
Aggregator handles new incoming connections using HaProxy, which determines the Agent type
by the SNI and forwards the connection to the relevant service.
The interface to the Aggregator is implemented using two channels, gc-channel Reveal and gc-
channel Enforcement, which are responsible for communication with the Aggregator. The

Aggregator initiates all communication over the channels, polling Agents on new data and
updating them with configuration and policy changes. The Aggregator sends commands and
requests to the Agents and gets responses. Deception and Enforcement Agents are able to push
messages from the Agent to the Aggregator as well.
In case the Aggregator is disconnected from the Agents, the channels will try to reconnect, and,
if not successful, move to the next Aggregator in the list (if there is one).
Data Collection: Aggregators and Collectors

The preferred method for collecting information on flows in your network is to deploy Agents on
devices throughout your environment and to use Aggregators to collate the information
detected by the Agents and relay this to the Guardicore Management server for further analysis.
This provides the most detailed information, as well as enabling you to set and enforce flow
policies.
In cases where Agents cannot be deployed, you can deploy Collectors. Although Collectors
cannot enforce policies, Collectors and Aggregators perform essentially the same functions: they
gather data on information flows in the system (from Agents, in the case of Aggregators, or from
switches and logs, in the case of Collectors) and send the data to the Management server for
further analysis and integration.
When to Use Aggregators

Where Agents can be deployed, you must deploy Aggregators. Aggregators communicate with
Agents, collate the flow data detected by Agents, and relay this information to the Guardicore
Management server. In addition to gathering Agent data, an Aggregator issues commands to
Agents that enforce flow policies. A single Aggregator can serve up to 200 Agents.
When to Use Collectors

In cases where Agents cannot be deployed, Guardicore Centra deploys Collectors at the
infrastructure level to detect and redirect suspicious traffic, and to provide information about
traffic flows. Cases where Agents cannot be deployed include legacy systems inside your
organization whose systems are incompatible with Agent software, or outside networks and
environments that interface with your company’s network.
Policy-wise, Collectors support alerts, but without enforcement.

Policy Derivation to Agents
Policy rules to Agents control the flow of traffic to and from the assets on which the Agents are
deployed. Instructions and strategies for creating policies to segment and micro-segment the
network are dealt with in the Policy Guide.
This section explains the way Centra derives policy rules to Agents.
Policies as Input/Output Chains

Rules to Agents can be represented as Input and Output chains continuously derived from
Aggregators to Agents. Each Agent gets only the rules relevant to it. Rules for Agents are derived
to the Agent’s IP; Agents are unaware of labels or assets:
Input chain: the Agent is the destination of the incoming flow. If a specific Agent is included in
the destination of a rule, the rule will be derived to the Input chain.
Output chain: the Agent is the source of the outbound flow. If a specific Agent is included in the
source of a rule, the rule will be derived to the Output chain.
Note: A rule can be derived both to the Input and the Output chains: for example, Any → Label
that includes the Agent’s asset (in this case, the Agent is part of the source and also a part of the
destination).
What Triggers Policies?

Policies to Agents are triggered by the following:
Implicit rules: these are default rules that control traffic to Agents before any policies are
published. In general, the default rule is Allow.
Published policy: these are the rules that users publish to segment the network and include
Allow, Alert, and Block rules, as well as Overrides.
Inventory updates: rules affecting an asset may change if a label is associated or removed from
an asset, or if the asset’s IP has changed.

How Policies are Matched to Agents
Policies are matched to Agents in a specific order of priority as presented in the following table:
Matching Management Agent Policy - Input Agent Policy - Output

Order Policy
1 - IMPLICIT-INPUT IMPLICIT-OUTPUT
Allow traffic from: Allow traffic to:
Loopback Loopback
Multicast Multicast
Broadcast (by subnet mask) Broadcast (by subnet mask)
Local IP Local IP
Aggregator over TCP 443
2 Override Allow OVERRIDE-ALLOW (action: OVERRIDE-ALLOW (action:

Allow) Allow)
3 Override Alert
OVERRIDE-ALERT (action: Allow) OVERRIDE-ALERT (action: Allow)
4 Override Block OVERRIDE-BLOCK (action: OVERRIDE-BLOCK (action:

Block) Block)
5 Allow
ALLOW (action: Allow) ALLOW (action: Allow)
6 - IMPLICIT-PRE-DEFAULT
Allow traffic to:
DNS server over UDP 53
7 Alert
DEFAULT-ALERT (action: Allow) DEFAULT-ALERT (action: Allow)
8 Block DEFAULT-DENY (action: Block) DEFAULT-DENY (action: Block)
9 - DEFAULT-ALLOW any (action: DEFAULT-ALLOW any (action:

Allow) Allow)

Example of Input/Output Chains for Implicit Rules
The following is an example of the Input/Output chains for implicit rules for Agents before
specific policies are published:
INPUT
IMPLICIT-INPUT
implicit-local-rule: protocol: ALL, IPs: [127.0.0.0/255.0.0.0], subnets: [], ports: [],
applications: [] --> IPs: [127.0.0.0/255.0.0.0], subnets: [], ports: [], applications: [] = ALLOW
implicit-multicast-rule: protocol: ALL, IPs: [], subnets: [], ports: [], applications: [] --> IPs:
[224.0.0.0/240.0.0.0], subnets: [], ports: [], applications: [] = ALLOW
implicit-broadcast-rule: protocol: ALL, IPs: [], subnets: [], ports: [], applications: [] --> IPs:
[172.16.255.255], subnets: [], ports: [], applications: [] = ALLOW
implicit-local-ip-rule: protocol: ALL, IPs: [172.16.6.101], subnets: [], ports: [],
applications: [] --> IPs: [172.16.6.101], subnets: [], ports: [], applications: [] = ALLOW
DEFAULT-ALLOW
default: protocol: ALL, IPs: [], subnets: [], ports: [], applications: [] --> IPs: [], subnets: [],
ports: [], applications: [] = ALLOW
OUTPUT
IMPLICIT-OUTPUT
implicit-local-rule: protocol: ALL, IPs: [127.0.0.0/255.0.0.0], subnets: [], ports: [],
applications: [] --> IPs: [127.0.0.0/255.0.0.0], subnets: [], ports: [], applications: [] = ALLOW
implicit-multicast-rule: protocol: ALL, IPs: [], subnets: [], ports: [], applications: [] --> IPs:
[224.0.0.0/240.0.0.0], subnets: [], ports: [], applications: [] = ALLOW
implicit-broadcast-rule: protocol: ALL, IPs: [], subnets: [], ports: [], applications: [] --> IPs:
[172.16.255.255], subnets: [], ports: [], applications: [] = ALLOW
implicit-local-ip-rule: protocol: ALL, IPs: [172.16.6.101], subnets: [], ports: [],
applications: [] --> IPs: [172.16.6.101], subnets: [], ports: [], applications: [] = ALLOW
implicit-server-rule: protocol: ALL, IPs: [], subnets: [], ports: [], applications: [] --> IPs:
[172.16.8.1], subnets: [], ports: [443], applications: [] = ALLOW
IMPLICIT-PRE-DEFAULT
implicit-dns-rule: protocol: UDP, IPs: [], subnets: [], ports: [], applications: [] --> IPs:
[8.8.8.8], subnets: [], ports: [53], applications: [] = ALLOW
DEFAULT-ALLOW

default: protocol: ALL, IPs: [], subnets: [], ports: [], applications: [] --> IPs: [], subnets: [],
ports: [], applications: [] = ALLOW
Example of Input/Output Chains for Published Alert Rule

This example represents the Input/Output chains for a published Alert policy for Agents:
INPUT
IMPLICIT-INPUT
...Default policy…
ALLOW
490cfe09-6c2c-4895-992c-a242e7b92be2 (ALLOW / Production Accounting):
protocol: ALL, IPs: [172.16.1.101,172.16.1.111,172.16.1.112,172.16.1.121,172.16.1.122],
subnets: [], ports: [], applications: [] --> IPs: [], subnets: [], ports: [], applications: [] = ALLOW
e5d41481-4d3b-4f8e-9e3a-0b303d8204fe (ALLOW / Production Accounting):
protocol: TCP, IPs: [], subnets:
[33.22.33.22/32,138.201.72.66/32,138.201.72.76/32,138.201.72.77/32,172.16.0.100/32,172.
16.0.254/32,172.16.1.1/32,172.16.8.1/32,172.16.100.101/32,172.16.100.102/32,172.16.100.
103/32,172.16.100.104/32,172.16.100.105/32,172.16.100.106/32,172.16.100.107/32,172.16
.100.108/32,172.16.100.109/32,172.16.100.110/32,172.16.100.111/32,172.16.100.112/32,1
72.16.100.113/32,172.16.100.114/32,172.16.100.115/32,172.16.100.116/32,192.168.0.1/32,
192.168.0.3/32,192.168.0.4/32], ports: [], applications: [] --> IPs: [], subnets: [], ports: [80],
applications: [/usr/sbin/nginx] = ALLOW
e7321b7c-d6ef-4175-8ecc-a971f9b3de5c (ALLOW / Production Accounting):
protocol: TCP, IPs: [172.16.1.40,192.168.0.100], subnets: [], ports: [], applications: [] --> IPs: [],
subnets: [], ports: [22], applications: [] = ALLOW
DEFAULT-ALERT
2e217c8-538f-47ef-b1ee-0dc3062d351f (ALERT / Production Accounting):
protocol: ALL, IPs: [], subnets: [], ports: [], applications: [] --> IPs: [], subnets: [], ports: [],
applications: [] = ALLOW
DEFAULT-ALLOW
OUTPUT

IMPLICIT-OUTPUT
ALLOW
490cfe09-6c2c-4895-992c-a242e7b92be2 (ALLOW / Production Accounting):
protocol: ALL, IPs: [], subnets: [], ports: [], applications: [] --> IPs:
[172.16.1.101,172.16.1.111,172.16.1.112,172.16.1.121,172.16.1.122], subnets: [], ports: [],
IMPLICIT-PRE-DEFAULT
DEFAULT-ALERT
82e217c8-538f-47ef-b1ee-0dc3062d351f (ALERT / Production Accounting):
protocol: ALL, IPs: [], subnets: [], ports: [], applications: [] --> IPs:
[172.16.1.101,172.16.1.111,172.16.1.112,172.16.1.121,172.16.1.122], subnets: [], ports: [],
DEFAULT-ALLOW

Installation Requirements for Aggregators and Collectors
For step by step instructions on installing Guardicore Centra, refer to the Installation Guides:
For ESXi environments, refer to the Installation Guide for the Cloud.
For On-premises installation, refer to the Installation Guide for On-Premises Installation.
The installation guides also provide the required installation and configuration settings for
Aggregators and Collectors in ESXi and physical environments.
Aggregator Administration
Aggregator Screen
The user interface for Aggregators is accessible from the Administration panel (Components,
Aggregators). The screen displays all of the Aggregators deployed in the system:
The following information is displayed:
Column Description
Hostname The name of the host on which the Aggregator is located.
IP Address The IP address of the Aggregator.
Version The current version of the Aggregator.
Operation The current operation mode of the Aggregator: On, Off, or Monitor. The
operation modes refer to the functionality of the Aggregator.
On = the Aggregator’s functions are turned on.
Off = the Aggregator’s functions are turned off (i.e. it is not performing the
functions of communicating with Agents or relaying data to the
Management server).

Monitor = the Aggregator is gathering information, but is not rerouting
suspicious traffic to the Deception server and is not enforcing policies from
the Enforcement server.
Status This column displays information pertaining to the health of the Aggregator.
Guardicore periodically checks the status of Aggregators. The full list of the
status (health) of Aggregator services is displayed by hovering the mouse
cursor over the column. A plus sign next to an item in the list can be clicked
to display further items. The column also uses the following to indicate the
status of an Aggregator:
Up = All of the Aggregator’s services are functioning.
Partially Up = Some of the Aggregator’s services are functioning.
Down = The Aggregator is not functioning.
Error = Problem with some of the Aggregator’s services. Hovering over the
Error icon will display a list with the problematic services marked with an
Error icon.
Connecting = the Aggregator is trying to connect.
Initializing = the Aggregator services are initializing.
Stopped = the Aggregator was intentionally stopped. None of the services
are functioning.
Cluster The cluster to which the Aggregator belongs. Aggregators belong to a

cluster where they form a Zookeeper leader and quorum. Unless you have
more than one cluster, the value in this column is Default.
Last Seen The time and date when the Aggregator was last visible.
First Seen The time and date when the Aggregator was first visible.
Aggregator Operation and Configuration

The Aggregator screen’s More menu enables you to control the operation of Aggregators, such
as starting and stopping their services. It also enables you to change configuration settings. The
most common configuration options are discussed later in this section. For many of the advanced
configuration options, it is advisable to confer with Guardicore Support before proceeding.
To change an Aggregator’s operation mode or to configure it:

In the list of Aggregators, select the checkbox next to the Aggregator whose operation mode you
want to change, or that you want to configure.
Click the More button.
Select one of the displayed options:
Option Explanation
Change Operation Mode This refers to the operation of the Aggregator’s services:
On, Off, Monitor: See the previous section on the Aggregator
screen for an explanation of these options.
Start/Stop Start: Start the services for the Aggregator.

Stop: Stop the services for the Aggregator. The component is no
longer functioning and is not communicating with the
Management server. You can start the component again by
selecting Start.
Restart Reboot the Aggregator. This is an actual reboot which means

that the component begins functioning anew.
Override Configuration This displays a screen with numerous configuration options. To

display all of the options, select the Show Advanced Options
checkbox. See below for an explanation of the options.
Get debug logs This downloads a compressed tar.gz file that contains detailed
debug information in several files.
Aggregator Override Configuration Option

The Override Configuration option appears in the More menu for selected Aggregators:

The option enables you to specify important settings for Aggregators. Make sure to check Show
Advanced Options for a full list. Some of the most important options are listed here:
Configuration Setting Explanation
Machine Details | Include Guardicore uses unique hardware IDs to identify the
hardware UUID machine on which an Aggregator is deployed. The Include
hardware UUID option can solve the following problem:
When servers are cloned in the environment they carry the

same UUID. Turning this option off will ensure that the
machine ID remains unique.
(Alternatively, if the UUID file is removed before cloning a
machine, there is no need to disable this option.)
Aggregator | Aggregator Explicitly assign this Aggregator/Collector to be part of the

Features | Cluster Zookeeper cluster quorum as a “publisher” (with the other members of
the quorum).
Aggregator | Aggregator Explicitly assign this Aggregator/Collector as the exporter of

Features | Cluster Exporter Syslog data in accordance with the setting of the Syslog
Integration configuration (the Export through Aggegators
option in Integrations | Syslog must first be checked).
If more than one Aggregator/Collector is marked as a
“cluster exporter”, then there will be an election in the
quorum to determine which Aggregator/Collector will take
the role of cluster exporter.
Aggregator | Aggregator Explicitly assign this Aggregator/Collector as the interface to

Features | Cluster pull data from the orchestrator (for example, vSphere, AWS
Orchestration

orchestration, etc.) and to publish it for other
Aggregators/Collectors in the cluster to consume.
If more than one Aggregator/Collector is marked as a

“cluster orchestrator”, then there will be an election in the
quorum to determine which Aggregator/Collector will take
the role of cluster orchestrator.
Aggregator | Zookeeper | hosts On occasion, it may be required to explicitly define the IP

addresses of the quorum members of any given
Aggregator/Collector.
Aggregator | Cluster | cluster-id Occasionally there is a need to change the ID of the cluster
of which the Aggregator/Collector is a part. This usually
accompanies some network reorganization or segmentation.
Datapath | General | TCP Typically, these ports are left untouched. However, if there
Service Ports is a special need to define a port for redirection to the
Deception Server, it’s done here.
Aggregator | Aggregator Check If you want this Aggregator to serve Agents in a load
Features | Agents Load balanced arrangement together with other Aggregators in
Balancer the cluster.
Aggregator | Aggregator Check the modules that you want this Aggregator to serve.
Features | [Enforcement,
Reveal, Detection, Deception]
Agents Server
Aggregator | Aggregator Check to support Layer 4 visibility in the absence of Agents.

Features | Reveal Datapath
Visibility
Aggregator CLI
Administrators can use CLI commands to access detailed information on Aggregators.
To do this Run on Type this

Find out to which Management gc-mgmtctl locate_agent --agent_filter <hostname
Aggregator an asset’s CLI or IP address>
Agent modules are
reporting.
List all Management gc-mgmtctl list_aggregators

Aggregators/Collectors in CLI
the environment, their
status, hostname, and IP.
List the Reveal Agents Aggregator CLI map-workers [hostname]

served by an Aggregator
(and on which worker
thread). including Agent
version, up time, and other
information.
List the status of the Aggregator/ monicore-ctrl status [-v]

Aggregator/Collector Collector CLI
subservices.
Restart an Aggregator/ monicore-ctrl restart <all | subservice name>

Aggregator/Collector Collector CLI
subservice.
Full Cluster Diagnostic Aggregator/ gc-cluster-diagnostic

Collector CLI
Confirm message brokering Aggregator/ gc-list-roles

is working and confirm the Collector CLI
cluster roles that are
assigned.
Display content of the Aggregator/ gc-network-db-dump -m

servers in the network Collector CLI
database - also confirm
that the network
information is shared with

other
Aggregators/Collectors.
Display SSL Proxy Aggregator/ gc-lower-hatop

Configuration and Traffic Collector CLI (for communication pathways downward in the
Statistics. direction of Agents)
gc-upper-hatop
(for communication pathways upward in the
direction of the Management server)

Collector Administration
Collectors Screen
The user interface for Collectors is accessible from the Administration panel (Components,
Collectors). The screen displays all of the Collectors deployed in the system:
The following information is displayed:
Column Description
Hostname The name of the host on which the Collector is located.
IP Address The IP address of the Collector.
Version The current version of the Collector.
Operation The current operation mode of the Collector: On, Off, or Monitor. The
operation modes refer to the functionality of the Collector.
On = the Collector is relaying data to the Management server.
Off = the Collector is not relaying data to the Management server.
Monitor = the Collector is gathering information, but is not rerouting
suspicious traffic to the Deception server.
Status This column displays information pertaining to the health of the Collector.
Guardicore periodically checks the status of Collectors. The full list of the
status (health) of Collector services is displayed by hovering the mouse over
the column. A plus sign next to an item in the list can be clicked to display
further items. The column also uses the following to indicate the status of
an Collector:

Up = All of the Collector’s services are functioning
Partially Up = Some of the Collector’s services are functioning.
Down = The Collector is not functioning.
Error = Problem with some of the Collector’s services. Hovering over the
Error icon will display a list with the problematic services marked with an
Error icon.
Connecting = the Collector is trying to connect.
Initializing = the Collector services are initializing.
Stopped = the Collector was intentionally stopped. None of the services are
functioning.
Cluster The cluster to which the Collector belongs. Collectors belong to a cluster
where they form a Zookeeper leader and quorum.
Last Seen The time and date when the Collector was last visible.
First Seen The time and date when the Collector was first visible.
Collector Operation and Configuration

The Collectors screen’s More menu enables you to control the operation of Collectors, such as
starting and stopping their services. It also enables you to change configuration settings.
To change the operation of, or configure, a Collector:

In the list of Collectors, select the Collector that you want to configure.
Click the More button.
Select one of the displayed options:
Option Explanation

Change Operation This refers to the operation of the Collector’s services:
Mode On, Off, Monitor: See the previous section on the Collectors screen
for an explanation of these options.
Start/Stop Start: Start the services for the Collector.

Stop: Stop Collector services. The Collector no longer functions and
does not communicate with the Management server. To start the
component again, select Start.
Restart Reboot the Collector. This is an actual reboot which means that the
component begins functioning anew.
Override This displays a screen with numerous configuration options. To

Configuration display all options, select the Show Advanced Options checkbox.
Get debug logs This downloads a compressed tar.gz file that contains detailed debug
information in several files.
Collector Override Configuration Option

The Override Configuration option appears in the More menu for selected Collectors:
The Override Configuration option enables you to specify important settings for Collectors.
Make sure to check Show Advanced Options for a full list. Some of the most important options
are listed in the following table.
Note: Because Aggegators and Collectors share the same OVA, the options use the term
Aggregator, even though the option is being applied to the Collector that you selected.
Configuration Setting Explanation

Machine Details | Include hardware UUID Guardicore uses unique hardware IDs to identify
the machine on which a Collector is deployed.
The Include hardware UUID option can solve
the following problem:
When servers are cloned in the environment

they carry the same UUID. Turning this option
off will ensure that the machine ID remains
unique.
(Alternatively, if the UUID file is removed before

cloning a machine, there is no need to disable
this option.)
Aggregator | Orchestration | Aggregator Explicitly assign this Collector to be part of the

Features | Cluster Zookeeper cluster quorum as a “publisher” (with the other
members of the quorum).
Aggregator | Orchestration | Aggregator Explicitly assign this Collector as the exporter of

Features | Cluster Exporter Syslog data in accordance with the setting of the
Syslog Integration configuration (the Export
through Aggegators option in Integrations |
Syslog must first be checked).
If more than one Aggregator/Collector is

marked as a “cluster exporter”, then there will be
an election in the quorum to determine which
Aggregator/Collector will take the role of cluster
exporter.
Aggregator | Orchestration | Aggregator Explicitly assign this Collector as the interface to

Features | Cluster Orchestration pull data from the orchestrator (for example,
vSphere, AWS orchestration, etc.) and to publish
it for other Aggregators/Collectors in the cluster
to consume.
If more than one Collector is marked as a
“cluster orchestrator”, then there will be an

election in the quorum to determine which
Aggregator/Collector will take the role of cluster
orchestrator.
Aggregator | Zookeeper | hosts On occasion, it may be required to explicitly

define the IP addresses of the quorum members
of any given Collector.
Aggregator | Cluster | cluster-id Occasionally there is a need to change the ID of

the cluster of which the Collector is a part. This
usually accompanies some network
reorganization or segmentation.
Datapath | General | TCP Service Ports Typically, these ports are left untouched.
However, if there is a special need to define a
port for redirection to the Deception Server, it’s
done here.
Agents and OS Support

Agents are supported for Linux, Windows, and Unix (Solaris, HP-UX, AIX). Support for the Agent
modules differs from version to version as detailed in the following:
Agents in a Linux Environment

Linux Agent OS Support
Unless otherwise noted, all of the OS versions are for 64 bit:
OS Version Agent Module
Reveal Enforcement Deceptio Detectio

n n
Red Hat 4.* ✔ ✘ ✘ ✘

Polling mode
Red Hat 5.2-5.11 ✔ ✔ ✘ ✔

Polling mode Network level (L4
only)

Red Hat 6.2-6.10 ✔ ✔ ✔ ✔
7.0-7.6
Red Hat 6.0, 6.1 ✔ ✔ ✘ ✔
CentOS 5.2-5.11 ✔ ✔ ✘ ✔
only)
CentOS 6.2-6.10 ✔ ✔ ✔ ✔
7.0-7.6
CentOS 6.0-6.1 ✔ ✔ ✘ ✔
Amazon 2012+ ✔ ✘ ✔ ✔
Oracle Linux 5.2-5.11 ✔ ✔ ✘ ✔

only)
Oracle Linux 6.2-6.10, 7.0-7.6 ✔ ✔ ✔ ✔

(not in
Azure)
Oracle Linux 6.0, 6.1 ✔ ✔ ✘ ✔

(not in
Azure)
Ubuntu 12.04-18.04 LTS ✔ ✔ ✔ ✔
Debian 7.8.9 ✔ ✔ ✔ ✔
SUSE 11 SP0, SP1 ✔ ✘ ✘ ✔

Polling mode
SUSE 11 SP2-SP4 ✔ ✔ ✔ ✔
SUSE 12.15 ✔ ✔ ✔ ✔

Linux Agent Processes
In a Linux environment, depending on the OS support, the following processes may be run by the
four Agent modules:
Process Purpose
gc-agents-service The main service of the Agent. Provides the local administration of the
Agent. Creates, monitors and restarts the other subcomponents of the
Agent.
gc-channel The communication channel for the Enforcement and Reveal modules.
An instance of the process is run for each module simultaneously:
gc-channel (Reveal) Communication channel to the Aggregator for reporting of visibility

data as well as reporting for the enforcement log. The Aggregator polls
the Agent through the channel for new data. The connection is
encrypted and authenticated on TCP/443, using TLS1.2.
gc-channel Communication channel for applying policy updates. The connection

(Enforcement) is encrypted and authenticated on TCP/443, using TLS1.2.
gc-controller Remote control channel for Agent administration. Maintains a

communication channel between the Agent and the Aggregator for
monitoring the Agent, and controlling its configuration. The
connection is encrypted and authenticated on TCP/443, using TLS1.2.
gc-enforcement-agent The Enforcement module of the Agent. Gets the policy from the
Aggregator and loads it into the driver. Persistent storage is used to
store the latest received policy and configuration that is used after
machine restart until a new policy is received.
gc-fastpath The Deception module of the Agent.
gc-guest-agent The Reveal (visibility) module of the Agent.

Responsible for reporting the visibility data collected by the Agents
and also the enforcement log (blocked and allowed connections).
Loads gc-digger which enables alternative visibility data collection
based on netstat polling.

gc-guardig Standalone utility for continuous network flows reporting.
gc-digger Designed for legacy systems:

In Linux, this is a standalone utility for network flows reporting in
polling mode.
gc-detection The Detection module of the Agent. Used for File Integrity Monitoring
capabilities.
gc-cert-client Standalone utility for automatic certificate enrollment and renewal

using the SCEP interface.
Agents in a Solaris Environment

Solaris Agent OS Support
Solaris Version
Reveal Enforcement Deception Detection
10 (exc. U8,U9) ✔ ✔ ✘ ✘
(SPARC, Polling mode Network level
X86_64) only
11 .0-11.4 ✔ ✔ ✘ ✘
(SPARC, Polling mode Network level
X86_64) only
Solaris Agent Processes
Process Purpose
gc-agents-service The main service of the Agent. Provides the local administration of the
Agent. Creates, monitors and restarts the other subcomponents of the
Agent.
gc-channel The communication channel for the Enforcement and Reveal modules.
An instance of the process is run for each module simultaneously:

gc-channel (Reveal) Communication channel to the Aggregator for reporting of visibility
data as well as reporting for the enforcement log. The Aggregator polls
the Agent through the channel for new data. The connection is
gc-channel Communication channel for applying policy updates. The connection

(Enforcement) is encrypted and authenticated on TCP/443, using TLS1.2.
gc-controller Remote control channel for Agent administration. Maintains a

communication channel between the Agent and the Aggregator for
monitoring the Agent, and controlling its configuration. The
connection is encrypted and authenticated on TCP/443, using TLS1.2.
gc-enforcement-agent The Enforcement module of the Agent. Gets the policy from the
Aggregator and loads it into the driver. In versions v29 and up,
persistent storage is used to store the latest received policy and
configuration that is used after machine restart until a new policy is
received.
gc-guest-agent The Reveal module of the Agent. Responsible for reporting visibility
data collected by Agents and also the enforcement log (blocked and
allowed connections).
gc-digger Collects visibility (Reveal) data based on Netstat polling.
gc-cert-client Standalone utility for automatic certificate enrollment and renewal

using the SCEP interface.
Storage, CPU and Memory Usage in a Solaris Environment

The expected utilization of the Agent is up to 5% CPU and up to 400MB memory (RSS). The
Agent binaries require 50MB of system's disk space. By default, additional 220MB of disk space
are required for log files storage.
The log rotation and retention configuration can be changed during installation, by changing the
log rotation profiles, or after the Agent installation, by changing the Agent configuration. See
Agent Log Rotation Profiles for details.
The Agent uses internal OS mechanisms to limit the resource usage. See Resource Limitations
for Solaris section for details.

Agents Deployed on Solaris Zone Servers
Agents for Solaris are optimized for bare metal or VM servers. Agents running on servers
operating with a Solaris Zone configuration have some restrictions which are discussed here.
Solaris Zones can be configured in different ways:

Shared-IP Global Zone
Shared-IP Non-Global Zone
Exclusive-IP Non-Global Zone
The functioning of Agents in each of these Zone types is discussed below.
Global Zone
An Agent can run on a global zone with shared IP to provide L4 visibility and enforcement. In this
case, the global zone and all its non-global zones will be treated as a single entity ("Asset") in the
system. This is not true for an exclusive-ip global zone.
Shared-IP Non-Global Zone

A shared-IP zone is a non-global zone that shares the IP layer configuration and state with the
global zone. In this configuration, the zone cannot run the native Solaris IP Filtering (IPF) module,
which belongs to the global zone only. Therefore, enforcement cannot be supported within a
shared-IP non-global zone.
Exclusive-IP Non-Global Zone

An exclusive-IP zone has its own IP-related state. This configuration enables installing an Agent
on each zone of this type and treating it as a unique entity ("Asset"). Visibility and Enforcement
will be supported for this type of non-global zone by installing an Agent in each non-global zone.
The Agent cannot be installed in a global zone in this configuration.
IPFilter Usage for Solaris Agent
The Enforcement module that was built for Solaris servers uses IP Filtering (IPF), which is the OS
native enforcement utility up until Solaris 11.3. By default, the server uses the persistent IPF
configuration, which is typically described in "/etc/ipf/ipf.conf". As the Agent loads, and fetches
the latest policy from the system, the Agent converts it to IPF rules and overrides the existing
IPF rules in memory. The persistent IPF configuration, which is typically saved in
"/etc/ipf/ipf.conf", will not be affected.
NOTE: Solaris 11.4 no longer uses IPF as its enforcement utility. Instead, it uses the PF firewall
which also deals with NAT. However, because Agents override all PF rules, this may cause

NAT rules to flush. Therefore, the PF firewall must be disabled before installing Solaris Agents
for Solaris 11.4. If the firewall is not disabled, the installation will stop and the following
message is displayed:
Solaris Firewall is enabled, disable firewall to install enforcement agent
To disable the firewall, use the command pfctl -d or provide
export GC_SOLARIS_OVERWRITE_PF=yes before installation.
Agents in a HP-UX Environment

HP-UX Agent OS Support
HP-UX Version
11.23, 11.31 ✔ ✘ ✘ ✘
(Itanium) Polling mode
Network Level only
Agents in an AIX Environment

AIX Agent OS Support
AIX Version
6.1, 7.1, 7.2 ✔ ✔ ✘ ✘

Polling mode Network level
only
IPFilter Usage for AIX Agent

The Enforcement module that was built for AIX servers uses IP Filtering (IPF), which is a native
OS enforcement utility.
By default, the server uses the persistent IPF configuration, which is typically described in
"/etc/ipf/ipf.conf". As the Agent loads, and fetches the latest policy from the system, the Agent

converts it to IPF rules and overrides the existing IPF rules in memory. The persistent IPF
configuration, which is typically saved in "/etc/ipf/ipf.conf", will not be affected.
Storage, CPU and Memory Usage in AIX Environment

The expected utilization of the Agent is up to 5% CPU and up to 400MB memory (RSS). The
Agent binaries require 50MB of system's disk space. By default, additional 220MB of disk space
are required for log files storage.
The log rotation and retention configuration can be changed during installation, by changing the
log rotation profiles, or changed after the Agent installation, by changing the Agent
configuration. See Agent Log Rotation Profiles for details.
Agents in a Windows Environment

Windows Agent OS Support
Version Agent Module
2000 (32 bit) ✔ ✘ ✘ ✘

Polling mode
2003 (32bit, 64bit) ✔ ✔ ✘ ✔

XP SP3 (32bit, 64bit) Polling mode Network level
2008 (32bit) ✔ ✔ ✘ ✔
Polling mode Network level
2008 (64bit) ✔ ✔ ✘ ✔
Polling mode
2008R2 (64bit) ✔ ✔ ✔ ✔
2012, 2012R2 ✔ ✔ ✔ ✔
(64bit)
2016, 2016 Core ✔ ✔ ✔ ✔

(64bit)
2019 (64bit) ✔ ✔ ✔ ✔

Version Agent Module
7 (64bit) ✔ ✔ ✔ ✔
8 (64bit) ✔ ✔ ✔ ✔
10 (64bit) ✔ ✔ ✔ ✔
Agent Processes in a Windows Environment
Process Purpose
gc-agents-service.exe The main service of the Agent. Provides the local administration of the Agent.
Creates, monitors and restarts the other subcomponents of the Agent.
gc-channel.exe The communication channel for the Enforcement and Reveal modules. An
instance of the process is run for each module simultaneously:
gc-channel (Reveal) Communication channel to the Aggregator for reporting of visibility data as
well as reporting for the enforcement log. The Aggregator polls the Agent
through the channel for new data. The connection is encrypted and
authenticated on TCP/443, using TLS1.2.
gc-channel (Enforcement) Communication channel for applying policy updates. The connection is
gc-agent-ui.exe The Agent user interface. Supported from Windows 2008R2.
gc-controller.exe Remote control channel for Agent administration. Maintains a communication

channel between the Agent and the Aggregator for monitoring the Agent, and
controlling its configuration. The connection is encrypted and authenticated on
TCP/443, using TLS1.2.
gc-enforcement-agent.exe The Enforcement module of the Agent. Gets the policy from the Aggregator
and loads it into the driver. In versions v29 and up, persistent storage is used
to store the latest received policy and configuration that is used after machine
restart until a new policy is received.
gc-fastpath.exe The Deception module of the Agent.
gc-guest-agent.exe The Reveal (visibility) module of the Agent.

Process Purpose
Responsible for reporting the visibility data collected by the Agents and also
the enforcement log (blocked and allowed connections).
Loads either:
gc-windig which implements process-level visibility connection reporting by
registering to ETW providers (Windows).
–OR–
gc-digger which enables alternative visibility data collection based on netstat
polling.
gc-windig.exe The utility that integrates into the Windows ETW provider to collect network
flows information.
gc-digger.exe Designed for legacy systems:

In Windows this is an alternative network flows collection utility for systems
without ETW support.
gc-detection.exe The Detection module of the Agent. Used for File Integrity Monitoring
capabilities.
gc-cert-client Standalone utility for automatic certificate enrollment and renewal using the
SCEP interface.
Storage, CPU, and Memory Usage in a Windows Environment

While Agent performance varies from environment to environment, in most Windows
environments it is found to utilize less than 0.1% of CPU, on average. The Agent is protected by
Windows Job Objects - system built-in memory and CPU limitation mechanisms. Memory usage
limitations apply to all Windows operating systems starting from Windows 2003. CPU limitations
apply to all Windows operating systems starting from Windows 2012. See Resource Limitation
Packages for Windows.
After installation, the Agent binaries require 50MB of system's disk space. By default,
Additional 220MB of disk space are required for log files storage.
The log rotation and retention configuration can be changed either:
During installation, by changing the log rotation profiles,
- OR -
After the Agent installation, by changing the Agent configuration.

See Agent Log Rotation Profiles for details.

Interoperability of Centra Enforcement with Windows
Firewall and Linux iptables
Policies created in Centra create input and output chains consisting of Allow, Alert, or Block rules
that control the flow of traffic between assets (see Policy Derivation to Agents). These policies
provide a complete solution for protecting an organization's assets. Nevertheless, Centra runs on
Windows and Linux OS which have their own implicit firewall systems. These may be running
with a default policy or running with a purposefully configured flow policy.
This section provides an explanation of how Centra works with Windows Firewall and Linux
iptables.
Interoperability of Centra Enforcement and Windows Firewall

in Windows 2008 and above, the Windows Filtering Platform (WFP) is used as the basis of both
Windows Firewall and Centra's enforcement module. Centra’s verdicts are translated into WFP
verdicts as follows:
Centra Enforcement Verdict WFP verdict Effect
Allow Permit Permit the data to be transmitted or received.

Veto any higher-weight WFP filter (including
Windows Firewall) with Centra decision.
Block Block Block the data from being transmitted or

received.
Veto any higher-weight WFP filter (including
Windows Firewall) with Centra decision.
Conflicts between WFP verdicts and Centra policy are resolved as follows:
Allow verdict: When making an Allow verdict, Guardicore Centra vetoes any conflicting verdict
from WFP. Therefore, an Allow verdict from Centra will not be inspected by Windows Firewall
and any Windows Firewall block rules will not apply. This includes the following cases:
Some Allow rule in the policy is matched.
No rule in the policy is matched (because we have an implicit default-allow rule).

Block verdict: When making a Block verdict, Guardicore Centra vetoes any conflicting verdict
from WFP. Therefore, a Block verdict from Centra will not be inspected by Windows Firewall
and the flow will be blocked regardless of any alternative rules from WFP.
Alert verdict: In terms of its effect on communication flow, this is an Allow verdict and is treated
the same way as Allow as explained above. Its function as an Alert within Centra is not affected
by the Windows Firewall.
Interoperability of Centra Enforcement and Linux IP Tables

On systems running under Linux, Netfilter (NF) is the basis for both iptables and Centra's
enforcement module. Centra’s policies use Netfilter (NF) hooks that translate Centra’s verdicts as
follows:
Centra Enforcement Verdict NF verdict Effect
Allow Accept Continue traversal as normal.
Block Drop Drop the packet; discontinue traversal.
Linux uses iptables together with Netfilter (NF) to enforce a policy. When there is a conflict
between the Centra verdict and the iptables verdict, Block takes precedence, regardless of
whether the Block verdict is from Centra or iptables.
Agent Administration
Agents Screen
As an administrator you use the Agents screen to monitor the health and functioning of Agents
and to perform any necessary operations. The Agents screen looks like this:

The Agents columns are as follows:
Column Description
Name The name of the device on which the Agent is deployed.
Asset Status Whether the device on which the Agent is deployed is on or off line.
IP The IP of the device on which the Agent is deployed.
Agent Version The software version of the deployed Agent.
Modules Four icons appear that represent the following modules:

Reveal, Deception, Enforcement, Detection.
As explained above, each of these modules is actually a separate Agent that
executes separate processes that connect to the appropriate server.
Hovering over an icon displays the name of the Aggregator to which the Agent is
attached (the name is a link that displays the Aggregator details on the Aggregators
screen). The icons also indicate the status of the module:
blue (active), red (active with errors), and gray (not deployed).
Labels The label assigned to the asset on which the Agent is deployed.
Flags Flags indicate problems of which the administrator should be aware. Hovering over
the notice in this column provides more details. The complete list of flags is listed in
the table below.

Column Description
Kernel The version of the kernel on which the Agent is deployed. This affects particular
Agent modules that work from the kernel.
Last Seen The most recent time that the Agent was detected by the Management server.
First Seen The first time that the Agent was detected by the Management server.
Agent Flags
The following table lists the various flags that can be displayed in the Flags column on the Agents
screen:
Flag Description
Agent Missing Agent was not seen in the last X minutes.
No Reveal Reported Agent didn’t report reveal data in the last hour.
Polling Mode Agent is in polling mode.
Outdated Policy Agent’s policy isn’t updated to the latest policy.
Limited Policy Agent’s policy was modified to meet Agent limited functionality. See Older
Agents Rule Limitations for more details.
Outdated Configuration Agent’s configuration isn’t updated to the latest configuration. See Agent
Configuration for more details.
Partial Configuration Some configuration attributes are not supported by the Agent.
High Drop Rate High ratio of dropped connections.
Enforcement Module Error Agent’s Enforcement module is missing.
Reveal Module Error Agent’s Reveal module is missing.
Deception Module Error Agent’s Deception module is missing.
Detection Module Error Agent’s Detection module is missing.
Controller Module Error Agent’s Controller module is missing.

Flag Description
No Reveal Received The Aggregator didn’t report reveal data to the Management in the last
hour.
Reveal Offline The Reveal module is running, but there is no connectivity between the
module and the Aggregator.
Enforcement Offline The Enforcement module is running, but there is no connectivity between
the module and the Aggregator.
Memory Limit Reached The Agent/Module memory consumption reached the predefined
threshold. See Resource Usage Management for more details.
Filtering the Agents Screen Display

The Agents screen provides filter criteria enabling you to quickly find Agents in the list:
For example, to view only Windows Agents, select Windows in the OS filter option to display the
following screen:
To save a filter for future use, use the Save filter button. To remove the filter, click the Discard
button.

Note: The Module Status filter enables you to filter according to the status (online, offline, etc.)
of one of the four Agent modules: Enforcement, Deception, Detection, or Reveal. You can only
select one status.
Generating Agents Diagnostics
Deleting an Agent from the System

The Agents screen enables you to delete Agents from the database:
On the Agents screen, select the Agent(s) that you want to delete.
Click the Remove from database button. The Agent is removed from the database but as long as
its certificate is not revoked, it can still function and it will attempt to reconnect to the system
and re-register. After a successful connection, the Agent will appear in the system with a default
Agent configuration.
To fully remove an Agent and prevent it from reconnecting to the system, the administrator must
install it and optionally revoke its certificate. When an external Public Key Infrastructure (PKI) is
being used, the Agent certificate will be marked as “pending for revocation”. The system
administrator can revoke the Agent’s certificate which ensures that the Agent is fully removed
and cannot reconnect.

Agent Administration Lock
Centra now includes an Agent lock that prevents Agent tampering by an unprivileged server
administrator which may cause the Agent to be suspended or disabled. This may happen because
Agents on servers that are managed by application owners or OS owners, may be disabled by
these owners, thus clashing with security concerns. For example, an application owner may
decide to disable an Agent in order to disregard a policy that prevents exporting data from the
server.
Windows Agent Administration Lock

To prevent disabling the Agent, the following is prevented by the Agent lock:
Uninstalling the Agent through Add/Remove programs
Stopping / Restarting / Disabling the Agent Service through Windows Services
Stopping / Restarting / Disabling Agent modules through the Windows Agent CLI
Killing the Agent process in the Windows Task Manager. An attempt to do so will bring up the
Agent again. This feature exists in previous versions as well.
Administration Lock on Other Operating Systems

The Administration Lock protects only the gc-agent binary, which controls the Agent status. The
Administration Lock does not protect the Agent from being uninstalled or stopped by using
standard Operating System methods.
Enabling the Agent Lock

By default, the Agent Tamper Prevention lock is disabled for existing Agents or newly installed
Agents.
There are several ways to enable the lock:
In Windows only: The Centra Administrator installs the Agent with the Lock enabled.
The Centra Administrator uses the Override Configuration option on the Agents screen in Centra
Administration to change an Agent’s state to Locked, as explained below.
Windows only: Installing the Agent with the Lock Enabled

When installing an Agent using the Agent Installation Instructions on Centra’s Administration
screen under Agents, the following flag is found in Advanced options and can be added to the
Installation script:

/enable-admin-lock
Alternatively, if the Guardicore Agent Setup screen is used to install the Agent, under Specific
Module Configuration, select the Enable Administration Lock option:
The installed Agent will run in Locked mode.
Verifying the Agent’s Lock State on Windows Servers

The Agent’s Locked state can be verified by one of the following ways:
Checking the Agent’s Admin button on the local Agent UI
If the Admin button is disabled (grey), the Agent is locked and the local user cannot perform
Admin activities with the Agent such as Stopping, Restarting, etc.:

If the Admin button is purple it indicates that local Administration is enabled, and thus the Agent
is not locked and the local user can perform some Admin activities with the Agent:
Using the Server’s Services Screen

The local user can display the Server’s Services screen and right-click the Guardicore Agent
Service in the list of services; stopping the Agent server will be restricted from the user.
Unlocking the Agent

The Agent can be unlocked by the following ways:
The Centra Administrator uses the Override Configuration option on the Agent screen in Centra
Administration to change the Agent’s state to Unlocked. This is the preferable option, allowing
the Centra Administrator to centrally control all the Agents locking states. See explanation for
this method below.

The Server owner uses a custom password issued by the Administrator to change the Agent’s
state to Unlocked in the Administration screen on the Agent’s local UI, or through the Windows
CLI.
Unlocking the Windows Agent Through the Agent UI

The password can be issued to the local Server owner who can then use the password to unlock
the Windows Agent using the local Agent UI Admin button:

NOTE: For extreme situations in which there is no communication with the local server, it is also
possible to use the Agent Installation password. But as this is the Administrator’s master
password, it should not be shared with the local Server owner.
Locking and Unlocking the Agent through the Centra Administration

Agents Screen
The Centra Administrator can unlock an Agent from Centra Administration by the following:
Display the Agents screen and select the Agent to be locked/unlocked:
Click the More button and select Override Configuration:
In the left pane of the Agents Configuration dialog box, select Agent Controller and in the right
pane scroll down to Set admin lock state and select Locked/Unlocked:

Click Save Changes; the Agent state will be changed.
NOTE: Set admin lock displays three states: Unlocked, Locked, and Unset. When Unlocked or
Locked is set, it takes precedence over any installation configuration of the Agent. On the other
hand, when the Agent is in Unset mode, the locked or unlocked state can be determined by the
configured Installation settings.
Defining a Custom Password for Agent Lock

The Administrator can create a custom password in the Set admin lock password box (found on
the Agent’s Controller dialog box underneath the Set admin lock state):

Locking and Unlocking the Windows Agent from the Command Prompt
It is also possible for the Administrator to lock or unlock the Agent through the command
prompt, whether in Windows or Linux systems:
Run the following command with administrative privileges to lock the Agent:
c:\Program Files\Guardicore>gc-agents-service.exe --ctrl set-adminlock-state --args LOCKED
Use the following command with administrative privileges to unlock the Agent:
c:\Program Files\Guardicore>gc-agents-service.exe --ctrl set-adminlock-state --args
UNLOCKED:<enter_your_password>
Local Control for Other OSs

Local Administration lock control for other OSs is not supported in this release. Use the remote
control of the Administration lock to lock and unlock the Agent.

Older Agents and Rule Limitations
The following table summarizes the behavior of Centra V.31 with various types of rules, policy
limitations, and older Agents:
Rule Type Agent Version
V27 V28 V29 V30 V31
DNS rule reject policy reject policy reject policy reject policy works
Full-path allow rule ignore path works works works works
Full-path block rule ignore path works works works works
works (only
Rule with a label group that has Linux &
excluded labels ("NOT rules") reject policy reject policy reject policy Windows) works
Rule with AD group on Windows

Agent. reject policy reject policy reject policy reject policy works
Rule with AD group with "wrong"

domain (Linux agents, or Windows
Agents with another domain) reject policy reject policy reject policy reject policy ignore rule
Policy with over 1,024 rules derived to

a specific Agent. reject policy reject policy reject policy reject policy reject policy
Rule sources or destinations with over

12,228 items each (subnets, IPs, ports,
processes).* See Note below. reject policy reject policy reject policy reject policy reject policy
Rule with wrong Fullpath type (Win

path on Linux, or Linux path on
Windows) N/A ignore rule ignore rule ignore rule ignore rule
Process level allow or alert rule on ignore ignore ignore

Agent with L4-only enforcement.** process process process ignore process ignore process
Process level block rule on L4-only

Agent ignore rule ignore rule ignore rule ignore rule ignore rule
* Note: labels and assets expand to IPs which may cause limits to be exceeded (e.g. a label
containing 5,000 assets can cross the limit if each asset has three IPs).

** OS that support Agent with L4-only enforcement:
• Windows 2003 (32bit and 64bit), 2008 (32bit)
• Unix Solaris 10 (exc U8 and U9) (SPARC x86_64), 11.0 and 11.3 (SPARC
x86_64), AIX 6.1, 7.1, 7.2
Behavior Consequences
Reject policy Agent will not get the latest policy; an "outdated policy" flag will be raised.
Ignore rule Policy will be derived to the agent, without the specific rule.
Ignore path Rule will be derived, ignoring the full path and using process name only.
Ignore process Rule will be derived as if the user did not write any process on the affected source/destination.
Rule Derivations
In addition to the rule derivations noted in the previous section, Centra V.31 performs the
following derivations for policy rules for Agents:
Internet Rules
Internet rules are converted to the complement of IANA's private networks list and exclude what
is configured as private under IP classification.
Example:
"match_multiple_subnets": [
"0.0.0.0/0",
"!10.0.0.0/8",
"!169.254.0.0/16",
"!172.16.0.0/12",
"!192.0.0.0/29",
"!192.0.0.170/31",
"!192.0.2.0/24",
"!192.168.0.0/16",
"!198.18.0.0/15",
"!198.51.100.0/24",
"!203.0.113.0/24",
"!240.0.0.0/4"
]
The private networks list can be updated through the UI.

Subnet Labels
The derived rule will contain the subnet itself plus all the assets with an interface in the subnet
and their IPs
In case a rule contains both Subnets and IPs, all IPs will be converted to /32 subnets.
In general, subnets and IPs that overlap may be merged. For example, if a rule contains the
following elements: 192.168.0.0/16, 192.168.0.8/24, 192.168.1.1, then all three will be merged
to the single subnet: 192.168.0.0/16.
Intersecting an Asset or Label with a Subnet

It is possible to intersect an asset or a label with a subnet, as depicted below:
Source Field in the Segmentation Rules screen Showing Intersection with a

Subnet
In this case, only the IPs of the interface (asset or label) in the specified subnet will be derived.
When deriving to a specific agent, if the result of this derivation includes all agent’s IP, the
specific rule will show “ANY” on the source (if the agent belongs to the rule’s source) or
destination (if the agent belongs to the rule’s destination).
Local Administration of Agents

In addition to the Agents screen, Guardicore Centra enables the administrator to manage Agents
locally using either a Windows UI or a Linux CLI. These are described in the following sections.
Windows Agent Administration UI

In a Windows environment, Guardicore Centra provides an expanded Administration UI for
controlling an Agent’s modules.
To access the UI for a particular Agent:

1. Select the Agent in the Agents screen and click the Guardicore Tray icon:

2. The Windows Agent Administration Main screen appears, showing the current status of
each of the installed modules.
During the initialization of the modules, after the installation or after system reboot, a
“Validating” state is expected. This is an initial state that monitors the startup of the module and
validates its functionality. Validation should not take more than 60 seconds.
The modules should be in the “Running” state. In case there is an issue preventing the module
from running as it should, the status will be changed to “Running with Errors”.
Enforcement using the Windows Agent UI

Policy Table
The Enforcement Module screen displays a table containing the current policy applied to the
specific machine on which the Agent is deployed. The table displays the source, destination, port,
and protocol for each flow and whether the flow is allowed by the enforcement policy.
Filter buttons:
Selecting “All”, “Incoming” or “Outgoing” filters between inbound and outbound rules.
Selecting Show Implicit Rules displays administrative rules that ensure the Agent doesn’t lose the
ability to communicate with the management system. See the section below for details.
Refresh button: this pulls the most recent policy from the kernel module.
Export to CSV button: this generates a CSV file with all the applied rules.
NOTE: the policy table will not appear if the Agent is not connected to an Aggregator.
Implicit rules
Implicit rules are administrative rules that make sure the Agent doesn’t lose the ability to
communicate with the management system. These rules cannot be modified and do not appear
as part of the Segmentation Policy in Centra UI.
The default implicit rules are the following:
Allow local host communication (127.0.0.1 and local interface IP addresses)
Allow multicast communication
Allow broadcast communication
Allow TCP port 443 communication to the Aggregator server
Allow outbound DNS
pausingSuspending the Agent
If needed, you can temporarily suspend Agent operation. There are two options:
Stop for a specified time or until system restart: the Agent will resume its operation after the
specified time period or after system restart, whichever is earlier.
–OR–
Stop until system restart: The Agent will resume its operation after system restart.
To suspend the Agent:
Do either of the following:
On the Windows Agent Administration Main screen, click the Menu button and then select
Suspend Agent.
–OR–
Right-click the Guardicore Tray icon and select Suspend Agent.

The following dialog box appears:
Select an option and click Pause.

Reporting an Issue
Clicking Report an Issue at the bottom right of the Policy table, displays the following:
The System Information box on the right of the screen displays information about the selected
Agent such as Operating System, Aggregator IP, etc.
To report an issue, on the left side of the screen, select one of the following delivery methods:
Send agent diagnostics to Guardicore - Centra automatically creates the package and attaches it
to a new support ticket in the Guardicore Support Portal.
Save agent diagnostics package locally - The package is saved locally as a file on the system. The
following information is collected:

SSL connectivity check to the Aggregator Internet connectivity check
Guardicore Agent log files (files in Proxy configurations

C:\ProgramData\Guardicore\logs)
Guardicore Agent installation log files Windows Firewall configuration

(%temp%\Guardicore_installer\gc_install.log)
Guardicore Agent version Validation of necessary privileges for Guardicore

Agent related directories and files
Connectivity certificate validation Task Scheduler log file
Operating system configuration information The version of installed .NET package

using “systeminfo” command
List of running processes List of local machine users
List of installed services and their status List of logged in users
Local Active Directory attachment Messages from Windows Event Log

information
List of installed software Disk space usage, and available storage

(HKLM\SOFTWARE\Microsoft\Windows\Cu
rrentVersion\Uininstall)
List of ETW consumers Full Guardicore registry key

(HKLM\Software\Guardicore)
Opening the Guardicore Agent Logs directory

The Guardicore Agent default log directory is usually: C:\ProgramData\Guardicore\logs. To open
it, in the Report an issue dialog box, click on the “Open logs directory” link underneath the
System Information box.
Agent CLI for Linux

The administration of Agents in a Linux environment includes commands that can be executed in
a CLI. These include commands for starting and stopping Agent services, changing configuration
settings, and rebooting Agents.

The following commands are supported to control the Agent in a Linux environment:
Command Description
gc-agent start Start the Agent service with all the installed modules.
gc-agent stop Stop the Agent service with all the installed modules.
gc-agent status Get the status of all the installed modules.
gc-agent restart Restart the Agent.
gc-agent system-status Get general info about the Agent deployment including the IP of the
Aggregator, uptime, and more useful info for debugging.
gc-agent uninstall Uninstall the Agent from the machine.
gc-agent start-all Start all the Agent modules, assuming the Agent service is up.
gc-agent stop-all Stop all the Agent modules, without shutting down the Agent service
gc-agent restart-all Restart all the Agent modules.
gc-agent module-start Start a specific module, assuming the Agent service is up.
<module name>
gc-agent module-stop Stop a specific module, assuming the Agent service is up.
<module name>
gc-agent module-restart Restart a specific module, assuming the Agent service is up.
<module name>
gc-agent module-status Get the status of the module, assuming the Agent service is up.
<module name>
gc-agent collect- Collect local diagnostics on the machine and create a report to be sent to
diagnostics the Guardicore support center.
gc-agent version Show Agent version details.

Command Description
gc-agent get-limitations Get the current resource limitations configuration.
The following modules are supported for <module name>:

controller | reveal | reveal-channel | enforcement | enforcement-channel | deception | detection
The following additional commands are supported to control the Linux Agent’s Enforcement
module:
Control option Description
gc-agent dump-policy Print the current enforcement policies and revision set for the
module.
gc-agent get-enforcement-mode Get the current state of the Enforcement module.

Agent Log Rotation Profiles
For each Agent module, Centra creates and stores log files that record information about the
Agent collected during a session. The information is useful for debugging and includes details
such as failed connection incidents, Agent flags, etc. Depending on the profile that was selected
during installation (see the following section), for each Agent module, a limited amount of
storage space is allocated to each log, and a limited number of logs are stored. When the
allocated storage capacity is reached, the logs are compressed. After compression, if the
storage capacity is reached, the oldest log is deleted.
Available Profiles
During Agent installation, you can choose one of the following three Log Rotation profiles: “min”,
“medium”, “max” for allocating storage space for Agent logs. The “medium” profile is considered
to be the default profile.
The type of profile determines the amount of debugging information that is collected and the
time span over which it is collected. The Min profile collects the least amount of information,
while the Max collects the most. Thus, the choice of profile may affect troubleshooting.
The following table describes the different log sizes configurations for each profile:
Profile Min Medium (default) Max
Expected Expected Expected

Threshold Storage Threshold Storage Threshold Storage
Module (MB) Count (MB) (MB) Count (MB) (MB) Count (MB)
Agents service 10 3 13 10 5 15 50 8 90
Cert client 1 3 1.3 6 5 9 15 8 27
Channel 1 3 1.3 6 5 9 15 8 27
Controller 1 3 1.3 10 5 15 50 8 90
Deception 2 3 2.6 10 8 18 50 8 90
Detection 2 3 2.6 6 5 9 15 8 27
Enforcement 30 5 45 50 8 90 80 10 160

Dig 10 3 13 10 8 18 50 8 90
Reveal 5 3 6.5 20 3 26 50 8 90
The estimated storage required for each Log Rotation Profile:

Min Medium (default) Max
90 MB 220 MB 700 MB
Installation Configuration for Agent Log Rotation

To set the Agent Log Rotation profile during Agent installation use the following instructions.
Installation for Agent Log Rotation on Windows

Use the /logging-profile installation parameter with the desired profile.
Example: windows_installer.exe /q /a 172.16.100.50 /p <password> /logging-profile min
Installation for Agent Log Rotation on Linux/Solaris/AIX

Use the following environment variable during installation:
export GC_LOGGING_PROFILE=min
Resource Usage Management for Agents

Agents use a certain percentage of CPU, Memory, and IO resources. For example, Agent
modules typically use less than 1% of a server’s CPU processing which means that 2% is a
recommended default soft limit. Using that amount of CPU would not normally interfere with
running other applications on the server. Similarly, there are typical default usage limitations for
memory and IO resources. In addition to these soft limits, there are higher, absolute, hard limits
that can be configured that restrict the amount of usage that Agents are permitted under any
circumstances.
Setting Hard and Soft Limits

Guardicore Centra enables you to set both Hard and Soft usage limitations for Agents directly
from the Admin UI, or locally from the command line:
Hard limits restrict resource usage to an absolute ceiling that cannot be exceeded.

Soft limits, on the other hand, restrict usage for the current process, but may be exceeded in
certain situations.
Why Set Agent Resource Usage Limits?

There are various reasons why you may want to change resource usage limits for Agents. These
include system expansion or downsizing, different servers exhibiting different resource usage
percentages due to varying hardware and software configuration, critical applications on the
server that require more extensive resources to run effectively (prioritization within the server),
etc. Another reason might be an increase or decrease on the server load due to changes in flow
policy.
Pre-Configured Resource Limitation Packages

Guardicore provides three pre-configured resource usage limitation packages: low, medium, and
high. The packages have pre-configured soft and hard limits for CPU, Memory, and IO. Low
Agent resource usage is for servers that run applications that are resource intensive and need to
severely restrict Agent usage. The Medium package is less restrictive and allocates more of a
server’s resources for Agent usage. This is the default package. The High package is the least
restrictive and provides Agents with the greatest share of resources.
The following sections provide tables for Windows and Linux with hard and soft limits for CPU,
memory, and IO usage for the three pre-configured resource limitation packages. The packages
set resource usage limits for each of the Agent modules: Deception, Reveal, Reveal Channel,
Enforcement, Enforcement Channel, Detection, Controller, and Agent Service.
Resource Limitation Packages: Tables of Values per Module

Resource Limitation Packages for Linux
The following tables contain the values for Resource Limitation Packages for Linux.
Note: Auto-detection logic for Linux

When installing Agents for Linux without any explicit configuration settings, Guardicore
employs an auto-detection logic for determining the optimal package as follows:
Low: less than 2G RAM Medium: 2G <= RAM <= 32G High: RAM > 32G

(for an explanation of Soft and Hard limits in the tables below, see Setting Hard and Soft Limits)
Key: (L=Low, M=Medium, H=High) Values for CPU are %, Values for Memory are MB.
Deception Reveal * Reveal-channel
L M H L M H L M H
CPU
Soft 2 2 2 2 2 2 2 2 2
Hard 20 20 20 20 20 20 20 20 20
Memor
y
Soft 10 80 160 10+cores*20 (10+cores*20)*2 (10+cores*20)*4 10 20 400

0
Hard 120 800 160 250+cores*32 (250+cores*32)* (250+cores*32)* 15 30 600

0 2 4 0
* Note: Alternative Memory Limitation Values for Reveal Module

In case the Agent cannot detect the number of cores in the machine, the values for the Reveal
module are as follows:
Low Medium High
Soft 250 500 1000
Hard 540 1024 2048
Enforcement Enforcement Detection Controller

Channel
L M H L M H L M H L M H
CPU

Enforcement Enforcement Detection Controller
Channel
L M H L M H L M H L M H
Soft 2 2 2 2 2 2 2 2 2 2 2 2
Hard 20 20 20 20 20 20 20 20 20 20 20 20
Memory
Soft 40 200 400 10 100 200 10 60 120 10 60 120
Hard 10 600 120 15 300 600 15 300 600 30 200 400

0 0
Agent Service
L M H
CPU
Soft 2 2 2
Hard 20 20 20
Memory
Soft 10 150 300
Hard 15 500 1000
I/O Read Speed from Disk for Detection module

The I/O read speed from disk is only applicable to the Detection module.
Bits/second:
L M H
10,485,760 20,971,520 41,943,040

Resource Limitation for Solaris / AIX
Customizable resource limitations mechanism is not supported for Solaris / AIX / HPUX
operating systems in this version.
Resource Limitation for Windows: Supported Windows OS

The following are the Windows OS that support Centra’s Memory and/or CPU limitations
feature:
• Memory Limitations Support: Windows Server 2008, Windows XP and newer (only 64 bit
architecture)
• CPU Limitations Support: Windows Server 2012, Windows 8 and newer (only 64 bit
architecture)
Resource Limitation Packages for Windows

When installing Agents for Windows, the Medium package is the default.
Values for CPU are %, Values for Memory are MB.
All modules share the same limitations Virtual memory Virtual memory CPU Rate %
Job (hard mem) Process (soft mem)
Low 400 250 5
Medium 800 500 5
High 1600 1000 5
Instructions for using these packages are provided in the following section. There is also an
option for changing individual settings within a configuration package.
Setting Initial Resource Limits During Agent Deployment

You set the initial resource limitations for Agents during Agent installation. The sections below
provide instructions for setting initial resource limits for Agents when deploying Agents in
Windows, or in Linux.
Important Note: Limits configuration made remotely using the UI will override any installation or
local configuration on the Agent itself.

Setting Resource Usage Limits for Windows Agents
Use the following installation attributes to change the default resource limitation configuration.
You can define a configuration for each Agent module.
/res_limit_<module name>_conf <config>
Module name can be one of the following:

enforcement, enforcement_channel, reveal, reveal_channel, deception, detection, controller
Config can be one of the following: Low, Medium, High
Example: windows_installer.exe /a aggregator.domain.com /p "<installation password>"

/res_limit_enforcement_conf “Medium” /res_limit_deception_conf “Medium”
For advanced users only: To override specific resource limitation values, you can use the
following installation attributes:
/res_limit_<module name>_<attr> <value>

Attr can be one of the following:

cpu, memory-soft, memory-hard
The value is related to the specific attribute

Memory usage is measured in MB, CPU in %
Setting Resource Usage Limits for Linux Agents

Use the following environment variables to change the default resource limitation configuration
during Agent installation. You can define a configuration for each Agent module.
export RES_LIMIT_<module name>_CONF=<config>

ENFORCEMENT, ENFORCEMENT_CHANNEL, REVEAL, REVEAL_CHANNEL, DECEPTION,
DETECTION, CONTROLLER
Config can be one of the following:

LOW, MEDIUM, HIGH

Example: export RES_LIMIT_DECEPTION_CONF=”MEDIUM”
export RES_LIMIT_<module name>_<attr>=<value>

ENFORCEMENT, ENFORCEMENT_CHANNEL, REVEAL, REVEAL_CHANNEL, DECEPTION,
DETECTION, CONTROLLER

CPU_SOFT, CPU_HARD, MEMORY_SOFT, MEMORY_HARD, IO

Memory usage is measured in MB, IO usage in IOPs, CPU in %

Changing Resource Usage Limits Locally Using the CLI
After Agents are deployed, you can use commands to change their usage resource limits. The
following sections provide instructions on how to use the change limits locally using the CLI in
Windows, or in Linux.
Important Note: Limits configuration made remotely using the UI will override any installation or
local configuration on the Agent itself.
Changing Limits Locally Using the CLI in Windows
Use the following commands to change the resource limitation configuration in Windows. You
can define a configuration for each Agent module.
C:\Program Files\Guardicore\gc-agents-service.exe --ctrl set-limitations -S <config> -M <module>


LOW, MEDIUM, HIGH
To apply the new configuration, run the following command:

C:\Program Files\Guardicore\gc-agents-service.exe --ctrl reload-configuration
Example: C:\Program Files\Guardicore\gc-agents-service.exe --ctrl set-limitations -S MEDIUM -

M enforcement
C:\Program Files\Guardicore\gc-agents-service.exe --ctrl set-limitations -R <attr> -M <module> -L

<value>




C:\Program Files\Guardicore\gc-agents-service.exe --ctrl reload-configuration
Changing Limits Locally Using the CLI in Linux

Use the following commands to change the resource limitation configuration for Linux Agents.
You can define a configuration for each Agent module.
gc-agent set-limitations -M <module_name> -S <config>


LOW, MEDIUM, HIGH

gc-agent reload-configuration
Example: gc-agent set-limitations -M enforcement -S HIGH

following commands:
gc-agent set-limitations -M <module_name> -R <attr> -L <value>




gc-agent reload-configuration
Setting Limits After Deployment Using the Centra UI

Once Agents are installed, you can easily change the pre-configured resource usage limit
package for individual modules from the Centra Administration screen. To do this, follow these
steps:

In Centra, select the Administration button to display the Administration menu.
From the Administration menu, select Components, Agents to display the Agents screen.
In the Agents screen, select the Agents whose resource usage limits you want to change, and
click the More button to display the following options:
Select Override configuration, then select Agent Controller to display the Agents Configuration
dialog box:
Scroll down to the Resource limitations values box for the module whose limits you want to
change, select the desired resource limitation package, and choose Save changes. For example:

For Advanced Users Only: Overriding Pre-Configured Values
You can override the pre-configured package limitations for a module. However, you should only
do this in consultation with Guardicore Support.
To change a pre-configured value:

1. In the Agents configuration dialog box, scroll down to the last option, Override resource
limitations value:

2. Click the + Add button and use the drop down buttons to select the module and resource
attribute (for example CPUHard) whose values you want to change:
3. In the Value box, type a value and choose Save changes.

Reveal Data Retention
Centra’s Management layer uses Elasticsearch to store network flow data (which appears as a
Reveal map) collected by Centra’s Agents and Collectors. The Elasticsearch database is
distributed across multiple containers and can be scaled out depending on the number of Agents
and Collectors, and the required data retention policy. Guardicore provides a comprehensive and
easy to use group of CLI commands to configure and control the data retention policy. These are
explained in the following sections.
Overview
All data saved by Management to Elasticsearch comes with a default retention policy. In this
case, retention actually means deletion – once the stored data reaches the retention point, it is
deleted without backup or recovery options.
Centra’s data deletion logic is executed using a celery task called archive_and_delete_old_data.
The task runs once an hour as part of the celery-long-run worker, and its logs can be found
under /var/log/guardicore/celery-long-run.log. For every data type stored in Elasticsearch, the
task lists all the existing indices. An index whose index timestamp is older than “today minus
retention_policy (in days)” is deleted.
When Should the Retention Policy be Changed?

When Elasticsearch reaches its maximum Hard Disk usage (usually set at 85%), it will stop
accepting data write or edit calls. The immediate effect on the system will be many errors,
services crashing, and general havoc. This effect may not always be clear from the system log,
since system events themselves are written to Elasticsearch (ES), so that, in this case,
Management might not even be able to write system events. For this reason, it’s better to be
proactive and monitor ES HD usage using Grafana or other monitoring tools.
Almost all of the HD usage on ES nodes is taken up by its indices storage. Thus, if the HD fills up,
it means too much data is being stored. One way to deal with this is to simply delete old data
using the ES DELETE API:
curl -XDELETE elastic_ip:9200/<index_name_or_regex>
For details refer to Elasticsearch documentation:
https://www.elastic.co/guide/en/elasticsearch/reference/5.6/indices-delete-index.html
However, using the Delete API will not prevent new data from piling up. So, to control retention
of new data, the Administrator should configure the retention policy. Instructions to accomplish
this are provided in the following section.

Configuring a Retention Policy for Centra ES
Configuring a retention policy involves just a few steps:
Listing the existing indices and the storage that they take up.
Formulating a retention policy.
Using CLI commands to change the retention default values and configure the new retention
policy.
Listing Existing Indices and Storage
To list the existing indices and the storage taken by each of them, use the elastic cat indices API:
curl elastic_ip:9200/_cat/indices?s=i
The indices are displayed with prefixes that indicate their data type. The list shows how many
shards make up an index, the number of docs, deleted docs, primary store size, and total store
size (all shards including replicas). For details, refer to Elasticsearch documentation:
https://www.elastic.co/guide/en/elasticsearch/reference/5.6/cat-indices.html
Formulating a Retention Policy
Using the elastic cat API command provided above, you can see how much storage each index
takes. Grouping the indices by their prefixes (which indicate their data type), you can measure
which data types are taking up all the storage. You then need to prioritize the importance of each
type of data to your organization’s security requirements and decide on a retention policy that
provides for these requirements. Finally, use the table in the next section to understand the
different data types, how to configure their retention policy, and the effect of doing so.
Note: Multi-Node Elastic Clusters

On multi-node elastic clusters, every index is automatically assigned a replica shard. This means
that the storage taken by every index is, in fact, double the storage it would take on a single-
node elastic cluster. This is easily demonstrated in the cat indices API.
Using the CLI to Configure Retention

To configure retention for the various indices, use mgmtctl, and run the following command:
gc-mgmtctl set_conf --group elastic_archive --option <configuration_name> --value
<new_value_in_days>
Where:
Elastic_archive is the name of the group under which all configuration names are stored.
<configuration_name> is a name listed in the table below and specifies the indices and type of
data whose retention is being configured.

<new_value_in_days> is the new value that specifies how many days will elapse before the data
indices are deleted.
Table of Configuration Names

The following table specifies configuration names, the Elastic indices that they affect, their data
types, and the Centra screens and logic that are affected by the data.
Configuration name Default Elastic Indices and their Data type Affected Screens and
value Logic
agent_status_events_delete_after_days 7 agent_event__* Agents log screen

Agent log events
closed_connections_delete_after_days 2 closed_connections__* Currently only the

Closed connections, used for dashboard uses this data,
traffic volume calculation. which is why its
retention policy is short
(2 days).
connections_delete_after_days 30 barebones_connections__* Network Log

Barebones connections (aks just Saved maps creation
“connections” or “network (uses these indices as
connections”) input)
connections_process_info_delete_after_ 90 processes__* Contains process info for

days Connections process info all sorts of network
connections. Used for:
Network log & other
screen filters
Saved maps creation
This configuration
should always be set to
the maximum between
barebones/hourly/daily
connections retention
intervals.

value Logic
daily_connections_delete_after_days 90 daily_barebones_connections__ Grouped indices

* containing all the
Daily connections indices connections
happening in a single
day, without time
resolution.
These indices are used
for efficient creation
of large maps. When
they do not exist, the
system will use the
barebones_connection
s indices instead
which will cause a
slower creation of
saved maps.
This is the only long-
term storage for
Reveal data (stores 90
days).
On large envs these
can grow huge. If they
pass the 10-15GB bar,
our recommendation
is to reduce their
retention to 1-2 days.
dns_cache_delete_after_days 7 dns_cache__* DNS log screen (under

DNS Log events labs)
Retention policy for DNS log DNS requests log per
(shown in the DNS log screen asset (under asset
under labs, and in the DNS screen)
requests log per asset under
the asset screen)

value Logic
fim_log_delete_after_days 60 fim_report_log__* File integrity log

Fim log screen
hourly_connections_delete_after_da 2 hourly_barebones_connections Grouped indices

ys __* containing all the
Hourly connections indices. connections
happening in a single
hour (out of the last
48 hours), without
time resolution.
These indices are used
for efficient creation
of large maps.
label_changes_log_delete_after_days 30 label_changes_log__* Labels log screen

Labels log events
machines_matching_log_delete_after 30 machines_matching_log__* Currently not exposed

_days Machine matching log event through UI
network_events_delete_after_days 30 network_events__* Redirections Log

Redirection events screen
queue_statistics_delete_after_days 7 - Unused, ignore me.
system_events_delete_after_days 90 system_events__* System Log

System events

Other ES Data Types and How to Control Them
Retention for the data types below cannot be configured with the set_conf command provided
above. The following table provides instructions on how to delete these indices.
Elastic Indices Data Type How to Delete
incidents__* and Incidents and This data is stored both to Mongo and to Elastic. There is
incident_groups__* incident currently no automatic retention handling for incidents and
groups incident groups. To remove them from Elastic you can use
the Elastic DELETE API (this might leave dead pointers here
and there). Deleting from Mongo is not dealt with here.
saved_connection__* Saved maps Delete the saved maps through the saved maps screen or
and storage API. The index names match the map ID, which you can use
saved_processes__* (connections to understand which maps you need to delete to clear the
and space.
processes)
q_requests_log__* Q requests Shown in the reputation log.

This data is stored both to Mongo and to Elastic (similar to
Incidents).
By default it is stored for 30 days.
To configure this value, modify
cfg.CONF.q.log_records_expiry_days and restart the
Management cluster.

Troubleshooting
As an administrator, you should be able to check the health of Aggregators, Collectors, and
Agents and solve certain problems that interfere with their proper functioning. Although the GUI
enables you to do this, it may not display the actual state of the component in real time. If you
want to check components against the GUI display, you can use the following CLI commands:
Listing Aggregators and Collectors

In some cases, it is useful to list all of the Aggregators and Collectors in the environment. Use the
following command:
gc-mgmtctrl list_aggregators
This command lists all of the Aggregators and Collectors (recall that Aggregators and Collectors
are essentially the same) in the environment. Here is an example of the listing as compared with
the listing in the GUI:
Controlling Aggregator/Collector services

After listing Aggregators and Collectors, you may want to check on their status (health) or the
status of one of their subcomponents (such as mitigation, kafka, etc.). You can display the status,
as well as restart, stop, or start a component or one of its subcomponents, using the following
command:

monicore-ctrl <status | restart | stop | start> <all | subcomponent_name>
Using the monicore-ctrl command can help you return a component to health, as in the following
case:
Suppose you wanted to check why the status of the ESX Collector listed in the previous example
was PARTIALLY UP. To do this, connect to the Collector via SSH, and issue the following
command:
monicore-ctrl status
Here is an example of the command and its output:
The status of all of the Collector’s subcomponents are listed and we now see the problem – gc-
mitigation has been forced down.
Starting a Component’s Subcomponent

To solve the above problem, you can start the Collector’s gc-mitigation subcomponent by issuing
the following command:
monicore-ctrl start gc-mitigation
as in the following command and output:
displaying in the GUI like this:

Restarting all of an Aggregator/Collector’s Services
In some cases, you may want to restart all of the services for a particular Aggregator or Collector.
Although this may take more time for the component to recover, it may be the best solution
when there are multiple problems with a component’s services.
For example, you could restart all of the ESX Collector’s services by issuing the following
command:
monicore-ctrl restart all
You can use the monicore-ctrl status command again to check the status of all of the Collector’s
services.
Alternatively, you can use the Reboot option in the component’s GUI to restart all of a
component’s services:
Upgrading
Scheduled upgrades of Guardicore Centra and/or any of its components are performed regularly
by Guardicore Support. Contact Guardicore Support for details.

Guardicore Linux Agent Deep Dive
Reveal + Enforcement
Applies to V39 and above
Functionality
The Guardicore Agent is designed to track all network connections of a protected server,
coupled with information on the processes involved in the connection. The Agent validates each
connection against a segmentation policy to allow / alert / block the connection. The connection
metadata and the applied action are reported to Guardicore Centra.
Guardicore Agents enable:

Gaining process-level visibility of all communications of a protected server.
Enforcing a segmentation policy by blocking and/or alerting violating traffic.
Automatically analyzing traffic flows for malicious processes, malicious DNS names or IP
addresses, using the Guardicore Reputation Service.
High Level Architecture Overview

Components Overview
Agent service - creates, monitors, and restarts the other subcomponents of the Agent.
Controller - maintains a communication channel between the Agent and the Aggregator for
monitoring and control of the Agent’s configuration. The TCP connection is always initiated from
the Agent to the Aggregator, and is encrypted and authenticated on TCP/443, using TLS1.2.
Reveal bundle - user space part of the Reveal component. Responsible for reporting the visibility
data collected by the Agents and also the enforcement log (blocked and allowed connections)
Enforcement Agent - user space part of the enforcement Agent - gets the policy from the
Aggregator and loads it into the gc_enforcement kernel module. The fetched policy is also stored
in a local persistent storage, and is applied after machine restart until a new policy is received, or
whenever policy updates cannot be fetched from the Aggregator (for instance, in a disconnected
Agent scenario).
GC-Enforcement.ko - kernel module that integrates into the Netfilter framework and enforces
the policy.
Deception bundle - user space part of the Deception service. Detects connections blocked by
the enforcement policy and redirects them to a Deception Server for further investigation.
Detection bundle - user space part of the Detection service. Responsible for File Integrity
Monitoring (FIM) and OSQuery capabilities.
Cert Client - standalone utility for automatic certificate enrollment and renewal using the SCEP
interface. In addition, in case the Kernel was updated, it downloads from the Aggregator a new
set of Kernel Object (KO) for Enforcement and Reveal. The KO is downloaded by Aggregators
from Management. Management might be integrated with the Guardicore KO Cloud to
periodically auto-fetch KOs matching newly released kernel versions, or alternatively have a
locally managed KOs storage.

Backup and Restore
Starting with Centra Version 36, on-prem customers are able to easily keep a backup of the
system so that, in case of a disaster, they can restore the entire system without having to create
a new policy, labels, rules, Agent config, etc.
What it does
Guardicore’s Backup and Restore feature backs up Management into a tar.gz file that includes
the configuration for Agents, policies, etc. The full list of items that are backed up is included in
the section What is Backed Up below.
Backup Procedure
To create a new backup file:
● On the Management server, from root, run the following command:
gc-backup-cli backup
Optional parameters
--backup-file Enables specifying a filename. Otherwise the filename defaults to

Centra_backup_YYYYMMDDhhmmss.tar.gz
--force This will override an existing backup file if such exists
The backup may take a few minutes. The backup file will be saved to
/storage/disaster_recovery/backup
Logs for the backup and restore process are located in the following:
/var/log/guardicore/backup_control.log
Restore Procedure
Note: The control node must be able to access all infra nodes via SSH prior to running the
restore procedure. All infra nodes must be up and running.

To restore a backup file:
1. Change directory as follows:
cd /storage/disaster_recovery/restore
2. Make sure that the backup tar.gz file to be restored is in the folder:
/storage/disaster_recovery/restore
3. Run the following command:
gc-backup-cli restore --backup-file <file>
Optional parameters
--force Restores the data without asking the user
It may take up to 2 hours for the process to be completed.
Note: After restore, the status of agents/assets/orchestrations will be incorrect until the reports
are received from the aggregators. Restore is similar to the DR process, i.e., the for agents will
not be re-sent and the policy will not be updated. The policy will be the same as it was when the
system was backed up. To update the policy, a restart of the enforcement modules on the
Aggregators is required. See the next step.
4. After the restore, on the Aggregator, restart the enforcement modules via this command:
monicore-ctrl restart gc-enforcement (Each aggr)
This causes the Agent to correct the Policy.
Notes
● The Backup file is a file on Management and can stay forever -- it can be exported and
saved wherever the user desires.
Limitations
● There is no cross-version restore.

● You cannot create a partial restore.

What is backed up?
The following table specifies the items that are backed up by the Backup command.
The following table specifies the items that are backed up by the Backup command.
What is backed up Comments
agent data Data about the agents. Includes status, error flags, installation profile, and
current expected configuration
assets Data regarding assets in the system. Can be agents/ agentless assets.
labels all label data including dynamic criteria, label groups, label suggestions, etc.
system configuration Configuration settings
user data all of the users in the system, user groups, user directories, user permission
schemes, etc.
policy policy rules, rulesets, workflow templates
dashboard
orchestrations Orchestration configurations
Storage, CPU, and Memory Utilization

Guardicore provides three pre-configured resource usage limitation packages: low, medium
(default) and high. The packages set resource usage limits for each of the Agent modules.
A package can be selected during installation, or modified from local or central configuration.
There is also an option for changing individual settings within a configuration package.
The limits set resource usage limits for each of the Agent modules. All modules share the same
limitation values:
Hard limits restrict resource usage to an absolute ceiling that cannot be exceeded.
Soft limits, on the other hand, restrict usage for the current process, but may be exceeded in
situations when the resource is not requested by concurrent processes.

CPU
CPU limitations are applied using cgroups and/or ulimit mechanisms, depending on the Linux
flavor. While Agent performance varies from environment to environment, in most Linux
environments it is found to utilize less than 1% of CPU.
The CPU Rate limit in all the 3 pre-configured resource usage limitation packages is similar:
Profile CPU Rate - soft limit CPU Rate - hard limit
Low 2% for any Agent module 5% for Reveal, Enforcement modules

20% for Controller, Agent service modules
Medium 2% for any Agent module 5% for Reveal, Enforcement modules

High 2% for any Agent module 5% for Reveal, Enforcement modules

Memory
When installing Agents for Linux without any explicit configuration settings, Guardicore employs
an auto-detection logic for determining the optimal package as follows:
Low profile: less than 2GB RAM is detected
Medium profile : between 2GB to 32GB RAM is detected
High profile: more than 32GB RAM is detected
The Memory limits in the pre-configured resource usage limitation packages are as follows:
Profile Soft Hard
Module Low Medium High Low Medium High
Agents service 10 150 300 15 500 1000
Controller 10 60 120 30 200 400
Deception 10 80 160 120 800 1600
Detection 10 60 120 15 300 600
Enforcement 40 200 400 100 600 1200

Profile Soft Hard
(10+cores
Reveal 10+cores*20 (10+cores*20)*2 *20)*4 250+cores*32 (250+cores*32)*2 (250+cores*32)*4
* Note: Alternative Memory Limitation Values for Reveal Module

In case the Agent cannot detect the number of cores in the machine, the values for the Reveal
module are as follows:
Low Medium High
Soft 250 500 1000
Hard 540 1024 2048
Storage
Required Disk Space

The following table lists the required disk space for the Agent’s installation, binaries and
configuration files, and log files:
Description Required disk space
Installation package 10MB
Binaries and configuration files 30MB
Log files 210MB with default configuration (“medium” profile).
Log Size Configurations

The following table describes the different log size configurations for each profile.
Threshold value refers to the max size of a single non-compressed log file, Count value refers to
the total number of log files stored, Expected Storage refers to the max storage of all log files of
a module:
Expected Expected Expected

Threshold Storage Threshold Storage Threshold Storage
Module (MB) Count (MB) (MB) Count (MB) (MB) Count (MB)

Agents service 10 3 13 10 5 15 50 8 27
Cert client 1 3 1.3 6 5 9 15 8 27
Controller 1 3 1.3 10 5 15 50 8 90
Deception 2 3 2.6 10 8 18 50 8 27
Detection 2 3 2.6 6 5 9 15 10 160
Enforcement 30 5 45 50 8 90 80 8 90
Reveal 5 3 6.5 20 5 26 50 8 90
TOTAL 75 MB 210 MB 580 MB
Communication with the Aggregator

The interface with the Aggregator is implemented using the channels components which are
responsible for communication channels with the Aggregator. The TCP connection is always
initiated from the Agent to the Aggregator.
On top of the connection, the Aggregator triggers the Agents - polling the Agents on new data
and updating them with configuration and policy changes.
In case of an Aggregator disconnect, the channels will try to reconnect and, if not successful,
move to the next Aggregator in the provided list (if there is one).
Common Scenarios and Procedures

Initiation
All Agent subcomponents initiation is done using Agent service. This process executes all the
Agent processes according to the configuration and monitors their state. In case of failure, the
process is restarted (after a 20 second wait time). The kernel modules are loaded through
wrapper bash scripts (reveal_agent_wrapper.sh and enforcement_agent_wrapper.sh). The
wrappers are also in charge of detecting that the right version of Kernel is missing and
communicating with the Aggregator (and from it to the Management which is updated by the KO
Cloud / manually) to fetch the missing objects.
The kernel modules create the following device: /dev/endr in order to communicate with the
user mode part of the Agent modules.

Upgrade
The usual upgrade procedure is to reinstall the Agent and then the new processes are started
through the initiation scheme described above. An Agent can also be upgraded from the Centra
Agents screen by selecting it and clicking the Remote Agent Upgrade button on the Agents
toolbar. A dialog box appears enabling the Administrator to type a name (description) for the
upgrade and start the upgrade process.

Policy Setting/Update
Policy setting and updating is initiated by the Aggregator in response to an explicit policy change
in Management or an implicit change due to Label contents change or IP changes in the
environment. The Agent’s relevant policy is derived and loaded to each Agent. The policy is
applied through the kernel module and, in case of an error, an indication is propagated back to
the central Management interface. The policy is stored in a persistent storage in the file system
and used in case of an Agent restart to gain the latest known configuration, until a policy update
from an Aggregator is fetched.
Policy Rules per Agent

When rules are all IP based, Centra supports up to 2K rules per Agent.
Read Connections Log

The Reveal logs are parsed, aggregated, and stored in memory until being collected by the
Aggregator. The Enforcement logs are sent through the Reveal Agent and use the same
mechanism and channel as the Aggregator.
Kernel Upgrade
When the kernel is upgraded there are two scenarios:
Scenario 1: System requires a reboot for the changes to take effect
In this case, when the system wakes up from the reboot as part of the initiation procedure
described above, the wrappers will validate if the kernel modules that are present on the host
match the kernel. In case the kernel modules don’t match, the wrappers will access the
Aggregators to fetch new kernel modules (a request that will be forwarded to Management and,
if needed, configured to the KO Cloud service). Once the new modules are available they are
installed and the system continues its execution1.
In case the kernel module is missing, the Agent will default to “polling mode” where the events
collection is done in user-space, and enforcement is not supported. An appropriate flag is raised
in Management so the user can identify the problem and solve it with Guardicore support.
Scenario 2: System reboot is not required

In this case, the kernel module should not be updated.
1
The frequency of checking for new KOs is ~1 hour

Local Agent Administration
Other than Central administration from the Management console, Guardicore Centra provides
CLI tools for local administration of Agent’s modules.
The following commands are supported to control the Agent in a Linux environment:
Command Description
gc-agent bundles-status Get the status of all the installed bundles.
gc-agent system-status Get general info about the Agent deployment including the IP of
the Aggregator, uptime, and more useful info for debugging.
gc-agent start-all Start all the Agent modules, assuming the Agent service is up.
gc-agent stop-all Stop all the Agent modules, without shutting down the Agent
service.
gc-agent restart-all Restart all the Agent modules.
gc-agent module-start Start a specific module, assuming the Agent service is up.
<module name>
gc-agent module-stop Stop a specific module, assuming the Agent service is up.
<module name>

Command Description
gc-agent bundles-status Get the status of all the installed bundles.
gc-agent module-restart Restart a specific module, assuming the Agent service is up.
<module name>
gc-agent module-status Get the status of the module, assuming the Agent service is up.
<module name>
gc-agent collect- Collect local diagnostics on the machine and create a report to be
diagnostics sent to Guardicore support center.
gc-agent version Show Agent version details.
gc-agent get-limitations Get the current resource limitations configuration.
The following modules are supported for <module name>:

controller | reveal | reveal-channel | enforcement | enforcement-channel | deception |
detection
In addition, the following commands are supported to control the Enforcement module:
gc-agent dump-policy Print the current enforcement policies and revision set for
the module.

gc-agent get-enforcement- Get the current state of the Enforcement module.

mode
Agents Uninstall
The following command needs to be run as root:
gc-agent uninstall
Agents Directory Structure
Directory Description
/var/lib/guardicore/storage/tls Agent certificats files
/var/lib/guardicore/storage/persistent- Agent configuration files

config
/var/lib/guardicore/storage/config Agent configuration files
/var/lib/guardicore/sbin Agent binaries
/var/log/gc-*.log Agent logs
/var/lib/guardicore/bash_completion.d Agent commands bash completion configuration
/var/lib/guardicore/bin Agent binaries
/var/lib/guardicore/labels.d Agent scripts
/var/lib/guardicore/services.d Agent scripts
/var/lib/guardicore/run Agent IPC sockets
/var/lib/guardicore/modules Agent kernel modules
/etc/default/guardicore Agent configuration file
/sys/fs/cgroup/*/guardicore Agent cgroups resource limitation configurations
/etc/bash_completion.d/guardicore* Agent commands bash completion configuration

/etc/rc.d/init.d/gc-agent Agent startup script
/usr/bin/gc-config Agent configurations control script
/usr/bin/gc-agent Agent control script
It is possible to modify the binaries and configuration paths - see customization options.
KO Cloud
What is KO Cloud?
KO Cloud is a hosted environment that contains the .ko object of gc_enforcement kernel
module for all supported Linux distributions for all existing and supported kernel versions.
How Is KO Cloud Populated?
KO Cloud is populated following a daily crawl-build-test service that is executed by Guardicore.

The crawler runs nightly and monitors the repositories of various distributions looking for new
supported kernel versions for them. When a new kernel version is detected, the kernel module is
compiled for this new version and a predefined set of tests is executed to validate the
functionality. Once tests have passed, the .ko objects are added to the KO Cloud.
Management polls the KO Cloud for new .ko modules, and updates its internal cache.
Although the KO Cloud feature was designed to facilitate the functioning of Agents in their
specific OS environment, some customers may require more control over the downloading of
Kernel Objects. To enable this, Centra now allows manually enabling or disabling the automatic
downloading of Kernel Objects from the KO Cloud per Agent.
Users who choose to disable the automatic KO download for an Agent can then manually
determine whether to download a KO for the Agent. Since an Agent requests a KO every 45
seconds, the user can simply select the Agent, then click the More button and under Control
select Enable automatic download of kernel module when available
To enable or disable automatic download of KO for an Agent perform the following steps:
1. On the Agents screen, select the Agent that you want to configure.
2. Click the More button and select Override Configuration.
3. Select Agent Controller and scroll to the bottom of the screen:

4. Select or deselect the Automatic Download option:
• Enable automatic download of kernel module when available
What Happens When No Supported Modules Are Found?
In case the matching ko file is not found on the management or on the KO Cloud - a rare
situation typically associated with custom-built kernels which are not available on public
repositories - the Agent will move to “polling mode” and will provide limited Reveal service. A
flag will be raised in Management so the issue can be detected by the administrator and handled
with Guardicore support. When the supported KOs are added locally to Management and/or to
the KO Cloud and through it to Management and Aggregators, the wrapper automatically
detects the added .KOs and installs them and the Agent returns to its normal operation without
any need for operator involvement.
What Happens When KO Cloud is Not Accessible?
In case the KO Cloud is inaccessible, for instance due to internal customer policy:
• Each system patch done as part of routine maintenance also refreshes the KO repository
stored on Management, replacing it with the complete repository supported by
Guardicore at that time.
• A new KO repository can be acquired from Guardicore support and a short, simple
manual procedure is executed to upload it into Management. This is commonly used by
customers to resolve specific events of missing KOs.

Guardicore’s Disaster Recovery Solution: How it Works
Guardicore’s solution comprises two different management clusters:
● Primary cluster that is designed to be the active management

● Standby cluster that acts as backup in case the primary cluster fails.
Both clusters can be active or backup, but only one can be active or backup at any given time.
If the primary cluster fails, you can initiate a failover on the standby cluster to continue system
operations on the standby cluster. When the primary cluster becomes available, it returns to
active and the standby cluster goes back to being the backup cluster.
Centra ensures there is an ongoing sync between the two clusters. For example, all segmentation
rules and labels written to the primary cluster are replicated to the backup cluster, and the other
way around.
What's synced
● Configuration (information)
● Inventory (list of assets, aggregators etc’)
● Segmentation policy
What's not synced
● Reveal data
● Incidents data

Aggregator &
C fi
Configuration
DB is auto-replicated
into the Standby
Management
Centra DR Scheme
Instructions for Configuring the System for Disaster Recovery
Before you can initiate a failover, you must first configure the system so that it is capable of
switching between a primary management cluster and a secondary management cluster.
Install two different management clusters. These are referred to as Primary Management
Master/Cluster and Standby Management Master/Cluster.
Allow SSH communication between the management master within each cluster (i.e. by doing
ssh-copy-id <standby-IP>).
Sync the certificates between the primary management master and the standby management
master:
Add the following in /etc/guardicore/hosts at the end of the file on the primary:
1 …
2 [peer_master]
3 [standby_master_ip]

To synchronize the certificates, run the following on the primary management cluster:
1 gc-dr-cli sync-standby-certs
This copies all certificates from the primary management master to the standby one.
Configure the primary management cluster:
Run the following:
1 gc-dr-cli configure --current-role primary --primary-ip <my-ip> --standby-ip <standby-ip> -

-components-standby-ip <component-facing-standby-ip> --components-primary-ip
<component-facing-primary-ip> --sleep-interval-seconds 360
Notes:
components-standby-ip and components-primary-ip should be different then standby-ip and
primary-ip in case the component facing subnet differs from the inter-management subnet.
sleep-interval-seconds determines the interval between the collection of configuration to be
fetched by the standby in order to keep them synchronized.
Enable the primary management cluster by running the following:
1 gc-dr-cli enable
Configure the Standby management cluster:
1 gc-dr-cli configure --current-role standby --primary-ip <primary-ip> --standby-ip <my-ip> -

-components-standby-ip <component-facing-standby-ip> --components-primary-ip
Notes:
sleep-interval-seconds determines the interval between each time the standby management
cluster attempts to fetch the new backup configuration.
Enable the standby management cluster by running the following:

1 gc-dr-cli enable
Verify the configurations:
To verify the Standby configuration:

• On the designated standby management master, run gc-dr-cli status; something like the
following should appear:
Management ID State Role
ae4a51b3bd5a511a82de080255e6b07b Backup Standby
To verify the Primary configuration:

• On the designated primary management master, run gc-dr-cli status;
something like the following should appear:
ae4a51b3bd5a511a82de080255e6b07b Active Primary
Initiating Failover
In case the primary cluster fails for any reason, the administrator can initiate the failover. This
will cause the standby management cluster to take over as the primary management cluster. All
management operations will then be available on the new active cluster.
To initiate the failover, perform the following:
1. Run the following on the standby management master: gc-dr-cli failover
The following prompt appears:

Warning: You are about the initiate DR sequence
Are you sure you want to continue? [y/N]
2. Type y to initiate the failover.
The process takes around 10 minutes, including the shifting of the components to the
standby management master which now acts as the primary management master.

Instructions for Performing a Failback
Once the disaster has been resolved and the designated primary cluster regains availability, the
administrator can initiate the failback process. All configuration and policy changes made to the
standby cluster during the disaster period will be synced back to the primary cluster.
To initiate the failback and return the system to the primary cluster:
1. Run the following: gc-dr-cli generate-config
This triggers unscheduled configuration collection and archiving to speed up the failback
process.
2. Initiate fetch and load configuration from the designated standby (current "active"
management). Run the following on the primary management master:
gc-dr-cli pull-and-load-config
The designated primary management master will now pull the file created on the standby
management master and load it. The designated primary management master is now
ready for use.
3. Return the standby management master to its original standby role by running the
following on the standby management master:
gc-dr-cli standby
The designated standby is stopped, and the primary management cluster becomes the
active one. This returns us to the original state: the designated master cluster is the
"active" cluster, while the designated standby cluster is the "backup" one.
Circuit Breaker
It may happen that a Rule will cause Centra to be flooded with multiple incidents. This can cause
too much load on the DBs and the system in general. To avoid this situation, Centra implements
a Circuit breaker that stops creating new incidents that exceed the threshold. The circuit breaker
causes the system to drop all new incidents beyond the limit which is defined as follows:
Max number of incidents = 60 * number of enrichment-workers * unique connections triggering

the incidents

The System log generates a warning for every incident that is above the threshold. New
incidents above the threshold won't be created and won't start any of the "enrichment" process
that takes lots of resources. The System logs are grouped by the rule id that triggered that
incident, which helps identify which rule is probably causing the flood of incidents.
Note: the circuit breaker is only relevant for new incidents, not rules. The System log may issue a
warning about a rule, but this is meant to indicate to the administrator which rule might be
causing the incident "flood".

Disaster Recovery
Unplanned incidents can happen at any time. Your network could suffer connectivity problems,
the hypervisor that hosts your system components can crash, or your entire site might
fail. When things don’t go as planned, it’s important to have a well-planned disaster recovery
solution that ensures continuous system operation at all times. Guardicore’s disaster recovery
approach allows for continuous system operation in times of complete site failure, connectivity
problems, hypervisor crash, etc.
Note: The described solution is relevant for on-premises deployments only, as availability of
SaaS deployments is guaranteed by Guardicore.
Guardicore’s Disaster Recovery Solution: How it Works

Guardicore’s solution comprises two different management clusters:
• the primary cluster that is designed to be the active management
• the standby cluster that acts as backup in case the primary cluster fails.
Both clusters can be active or backup, but only one can be active or backup at any given time. If
the primary cluster fails, you can initiate a failover on the standby cluster to continue system
operations on the standby cluster. When the primary cluster becomes available, it returns to
active and the standby cluster goes back to being the backup cluster.
Centra ensures there is an ongoing sync between the two clusters. For example, all segmentation
rules and labels written to the primary cluster are replicated to the backup cluster, and the other
way around.
What's synced
• Configuration (information)
• Inventory (list of assets, aggregators etc’)
• Segmentation policy
What's not synced

• Reveal data
• Incidents data

Instructions for Configuring the System for Disaster Recovery
Before you can initiate a failover, you must first configure the system so that it is capable of
switching between a primary management cluster and a secondary management cluster.
1. Install two different management clusters. These are referred to as Primary
Management Master/Cluster and Standby Management Master/Cluster.
2. Allow SSH communication between the management master within each cluster (i.e. by
doing ssh-copy-id <standby-IP>).
3. Sync the certificates between the primary management master and the standby
management master:
Add the following in /etc/guardicore/hosts at the end of the file on the primary:
1 ...
2 [peer_master]
3] [standby_master_ip]
4. To synchronize the certificates, run the following on the primary management cluster:
1 gc-dr-cli sync-standby-certs
This copies all certificates from the primary management master to the standby one.
5. Configure the primary management cluster:
Run the following on the primary:

1 gc-dr-cli configure --current-role primary --primary-ip <my-ip> --standby-ip <standby-
ip> --components-standby-ip <component-facing-standby-ip> --components-primary-ip
Notes:
components-standby-ip and components-primary-ip should be different then standby-ip and
primary-ip in case the component facing subnet differs from the inter-management subnet.
sleep-interval-seconds determines the interval between the collection of configuration to be
fetched by the standby in order to keep them synchronized.
6. Enable the primary management cluster by running the following on the primary:
1 gc-dr-cli enable
7. Configure the Standby management cluster on the standby:

1 gc-dr-cli configure --current-role standby --primary-ip <primary-ip> --standby-ip <my-
ip> --components-standby-ip <component-facing-standby-ip> --components-primary-ip
Note:
sleep-interval-seconds determines the interval between each time the standby management
cluster attempts to fetch the new backup configuration.
8. Enable the standby management cluster by running the following on the standby:
1 gc-dr-cli enable
9. Verify the configurations:
To verify the Standby configuration:

• On the designated standby management master, run gc-dr-cli status; something like
the following should appear:
ae4a51b3bd5a511a82de080255e6b07b Backup Standby
To verify the Primary configuration:

• On the designated primary management master, run gc-dr-cli status;
something like the following should appear:
ae4a51b3bd5a511a82de080255e6b07b Active Primary
Initiating Failover
In case the primary cluster fails for any reason, the administrator can initiate the failover. This
will cause the standby management cluster to take over as the primary management cluster. All
management operations will then be available on the new active cluster.
To initiate the failover, perform the following:

1. Run the following on the standby management master: gc-dr-cli failover
The following prompt appears:
Warning: You are about the initiate DR sequence

Are you sure you want to continue? [y/N]
2. Type y to initiate the failover.
The process takes around 10 minutes, including the shifting of the components to the standby
management master which now acts as the primary management master.
Instructions for Performing a Failback

Once the disaster has been resolved and the designated primary cluster regains availability, the
administrator can initiate the failback process. All configuration and policy changes made to the
standby cluster during the disaster period will be synced back to the primary cluster.
1. To initiate the failback and return the system to the primary cluster, run the following on
the standby:
gc-dr-cli generate-config
This triggers unscheduled configuration collection and archiving to speed up the failback
process.
2. Initiate fetch and load configuration from the designated standby (current "active"
management). Run the following on the primary management master:
The designated primary management master will now pull the file created on the standby
management master and load it. The designated primary management master is now ready for
use.
Return the standby management master to its original standby role by running the following on
the standby management master:
gc-dr-cli standby
The designated standby is stopped, and the primary management cluster becomes the active
one. This returns us to the original state: the designated master cluster is the "active" cluster,
while the designated standby cluster is the "backup" one.
Failback to New Primary

Use this procedure if the old primary management cluster is gone or non-recoverable.

Preliminary steps
Deploy a new primary management cluster with the same control node IP address as the
previous primary control node.
Failback Steps
Step 1: Shut Down the Primary Cluster
• On the new primary control node run:
gc-cluster-cli cluster-stop --group all
Step 2: Allow SSH Between the Two Clusters
1. Copy SSH keys from management primary to standby node by running
ssh-copy-id <standby-IP>
2. Copy SSH keys from management standby to primary node by running
ssh-copy-id <primary-IP>
Step 3: Sync Certificates

You must now sync the certificates between the primary management control node and the
standby management control node. To this perform the following steps:
1. On the primary, in the file /etc/guardicore/hosts, at the bottom of the file, add the
following:
...
[peer_master]
<standby_control_node_ip>
Note: You do not need to do this on the standby as it should already be present.
2. Backup /var/lib/guardicore/storage/certs/tls on the new primary control node.
3. Copy all of the subdirs from the standby under /var/lib/guardicore/storage/certs/tls to the
new primary control node (this must be done manually as there is currently no script for
this)::
- "aggregator"
- "disaster_recovery"

- "disaster_recovery_server"
- "gcca"
- "mesos_master"
- "mitigation_ca"
- "mongodbclient"
- "mongodbserver"
- "mitigation_cas_chain.pem"
- "rabbitmq"
- "rabbitmqserver"
- "remote_ssl_proxy"
- "remote_ssl_proxy_server"
4. Run the following on the new primary control node
gc-dr-cli propograte-certificates
5. Restart dr-ssl-proxy
6. On the new primary run the following to load the new certificates
gc-cluster-cli infra-service-start --infra_name dr_ssl_proxy
Step 4: Configure the New Primary

Configure the new primary as instructed in the Instructions for Configuring the System for
Disaster Recovery section. No need to re-configure the standby.
Step 5: Enable Disaster Recovery

Now that the primary disaster recovery settings have been configured, enable it by running the
following on the standby:
gc-dr-cli enable

Step 6: Pull and Load the Configuration from the Standby
To initiate fetch and load configuration from the designated standby (current "active"
management), run the following on the new primary management control node:
Step 7: Turn the Standby to Standby Mode

On the standby control node run:
gc-dr-cli standby

Network Log Backup and Restore
Centra's Backup and Restore capabilities have been further enhanced and now enable preserving
all network data in the event of a disaster that affects the Management cluster. In addition to the
existing Backup and Restore procedure that backs up and restores policies and Agent
configuration, Centra administrators will now be able to backup and restore Network log data
and the associated reveal maps. The new data backup and restore ensures that network data can
be backed up and restored to a new deployment of Centra, providing another layer of security, in
case of a disaster.
The following items can be backed up and restored:
• Network logs
• Reveal Explore map
• Saved maps
• Audit/system logs
• Labels log
How it works
Backup and Restore is accomplished by running the following scripts from the command line:
• Backup Script
• Restore Script
The Administrator can edit the script to determine the repository for the backup.
Backup Script
Contact Guardicore Support to download the script.
Restore Script
Contact Guardicore Support to download the script.

Agent OS Support
OS Type OS Name Versions Visibility Enforcement Deception FIM Insight
✔
4.* , 5.0-5.1 (64bit) Polling ✘ ✘ ✘ ✘
mode
Red Hat ✔
✔
5.2-5.11 (64bit) Network level (L4 ✘ ✔ ✘
only)
6-8 (64bit) ✔ ✔ ✔ ✔ ✔
✔ ✔
5.2 (32bit) Polling Network level (L4 ✘ ✘ ✘
mode only)
CentOS ✔
✔
5.2-5.11 (64bit) Network level (L4 ✘ ✘ ✘
only)
6-8 (64bit) ✔ ✔ ✔ ✔ ✔
Linux ✔
✔
5.2-5.11 (64bit) Network level (L4 ✘ ✔ ✘
Oracle Linux[1]
only)
6-8 (64bit) ✔ ✔ ✔ ✔ ✔
Amazon 2012+ (64bit) ✔ ✔ ✔ ✔ ✔
Amazon 2 2018+ (64bit) ✔ ✔ ✔ ✔ ✔
12.04-20.04 LTS
Ubuntu ✔ ✔ ✔ ✔ ✔
(64bit)
Debian 7.5-10 (64bit) ✔ ✔ ✔ ✔ ✔
✔
11 SP0- SP1 (64bit) Polling ✘ ✘ ✔ ✘
mode
SUSE
11 SP2-SP4 (64bit) ✔ ✔ ✔ ✔ ✔
12, 15 (64bit) ✔ ✔ ✔ ✔ ✔
✔
2000 SP4 (32bit) Polling ✘ ✘ ✘ ✘
mode
Microsoft Windows Server
✔
✔
2003 SP2(32bit, 64bit) Network level (L4 ✘ ✔ ✘
only)

2008 (32bit) ✔ ✔ ✘ ✔ ✘
2008 SP2 (64bit) ✔ ✔ ✘ ✔ ✘
2008R2 ✔ ✔ ✔ ✔ ✘
2012, 2012R2 SP1 ✔ ✔ ✔ ✔ ✔
2016, 2016 Core ✔ ✔ ✔ ✔ ✔
2019 ✔ ✔ ✔ ✔ ✔
✔
✔
XP SP3 (32bit, 64bit) Network level (L4 ✘ ✔ ✘
only)
Vista SP1 (32bit) ✔ ✔ ✘ ✔ ✘

Windows
Desktop Vista SP2 (64bit) ✔ ✔ ✘ ✔ ✘
7, 8, 8.1, 10 (32bit) ✔ ✔ ✔ ✔ ✘
7 SP1(64bit) ✔ ✔ ✔ ✔ ✘
8, 8.1, 10 (64bit) ✔ ✔ ✔ ✔ ✔
✔
11.23 Polling ✘ ✘ ✘ ✘
mode
HP-UX[2]
✔ ✔
11.31 Polling Network level (L4 ✘ ✘ ✘
mode only)
✔ ✔
10 U8-U9(x86_64) Polling Network level (L4 ✘ ✘ ✘
mode only)
✔ ✔
UNIX 10 U10+
Polling Network level (L4 ✘ ✘ ✘
Solaris[3] ( x86_64, SPARC)
mode only)
✔
✔
11.0-11.4 Polling
Network level (L4 ✘ ✘ ✘
(SPARC, x86_64) mode
only)
✔ ✔
AIX 6.1, 7.1, 7.2 Polling Network level (L4 ✘ ✘ ✘
mode only)
FreeBSD 11.3, 12.1 ✔ ✔ ✘ ✘ ✘

Polling Network level (L4

mode only)
[1] Not in Azure

[2] Itanium
[3] Solaris Zones are supported for selected configurations

Akamai Guardicore Segmentation Admin User Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Akamai Guardicore Segmentation Admin User Guide

Uploaded by

Copyright:

Available Formats

Guardicore

Centra Security Platform 5.0

CENTRA ARCHITECTURE ....................................................................................................................................................7

DATA COLLECTION: AGGREGATORS AND COLLECTORS ........................................................................................ 19

WHEN TO USE AGGREGATORS ....................................................................................................................................................................19

POLICY DERIVATION TO AGENTS.................................................................................................................................. 20

POLICIES AS INPUT/OUTPUT CHAINS ........................................................................................................................................................20

AGGREGATOR ADMINISTRATION ................................................................................................................................. 26

AGGREGATOR SCREEN ..................................................................................................................................................................................26

COLLECTOR ADMINISTRATION ..................................................................................................................................... 33

COLLECTORS SCREEN ...................................................................................................................................................................................33

Administration Guide - Centra Security Platform 5.0 v41 1

AGENTS IN A LINUX ENVIRONMENT ...........................................................................................................................................................37

INTEROPERABILITY OF CENTRA ENFORCEMENT WITH WINDOWS FIREWALL AND LINUX IPTABLES . 47

INTEROPERABILITY OF CENTRA ENFORCEMENT AND WINDOWS FIREWALL .....................................................................................47

AGENT ADMINISTRATION ............................................................................................................................................... 48

AGENTS SCREEN ............................................................................................................................................................................................48

Administration Guide - Centra Security Platform 5.0 v41 2

WINDOWS AGENT ADMINISTRATION UI...................................................................................................................................................62

AGENT LOG ROTATION PROFILES ................................................................................................................................ 69

AVAILABLE PROFILES ...................................................................................................................................................................................69

RESOURCE USAGE MANAGEMENT FOR AGENTS ....................................................................................................... 70

SETTING HARD AND SOFT LIMITS ..............................................................................................................................................................70

REVEAL DATA RETENTION ............................................................................................................................................. 82

LISTING AGGREGATORS AND COLLECTORS ...............................................................................................................................................88

Administration Guide - Centra Security Platform 5.0 v41 3

GUARDICORE LINUX AGENT DEEP DIVE REVEAL + ENFORCEMENT .................................................................. 91

BACKUP AND RESTORE .................................................................................................................................................... 94

WHAT IT DOES ...............................................................................................................................................................................................94

KO CLOUD .......................................................................................................................................................................... 105

WHAT IS KO CLOUD? ................................................................................................................................................................................105

Administration Guide - Centra Security Platform 5.0 v41 4

CIRCUIT BREAKER .......................................................................................................................................................... 111

DISASTER RECOVERY ..................................................................................................................................................... 113

GUARDICORE’S DISASTER RECOVERY SOLUTION: HOW IT WORKS ...................................................................................................113

NETWORK LOG BACKUP AND RESTORE .................................................................................................................. 120

HOW IT WORKS ...........................................................................................................................................................................................120

AGENT OS SUPPORT ....................................................................................................................................................... 121

Administration Guide - Centra Security Platform 5.0 v41 5

• Ensure that components are correctly installed and deployed.

• Customize components to your environment.

• Ensure that all of the component files and folders exist.

• Monitor the operational status and health of components.

• Manage the operation of components. This includes the following:

• Start, stop, or restart (reboot) components.

• Control the operation mode of components (on, off, monitor)

• Delete, upgrade, and reinstall components when required.

Administration Guide - Centra Security Platform 5.0 v41 6

Here is a brief overview of Centra’s components:

• Virtual machines called Collectors gather information on information flows in

• A Deception Server manages a farm of different-flavored honeypot instances (Windows

Administration Guide - Centra Security Platform 5.0 v41 7

The following sections provide more details on each component.

Guardicore Management Server

• Receiving, analyzing, enriching and managing storage of collected data

• Alerting and automated reporting

• Solution integration with SIEM and/or internal mail servers

• Monitoring and health control of all system components

• Managing the configuration of all system components

• Managing the patching/upgrade of all system components

Administration Guide - Centra Security Platform 5.0 v41 8

Aggregators can be deployed in clusters. This provides the following:

Administration Guide - Centra Security Platform 5.0 v41 9

Administration Guide - Centra Security Platform 5.0 v41 10