2. New features

2.1. High availability

In order to increase the operational readiness of the application, Gatewatcher implemented a high availability mechanism.

It enables maintaining the captured flows. For example, in the event of a GCap failure or shutdown, this is achieved by setting up two redundant GCaps.

These two GCaps capture the same flow while communicating with a single GCenter.

In the event of any problems with the « leader » GCap, the « follower » GCap takes over thus ensuring continuity of service during the maintenance operation.

The following commands were added:

  • `show advanced-configuration high-availability` to view the status of redundancy (HA),

  • `set advanced-configuration high-availability` to configure the redundancy (HA).

For further information on how this mechanism works, please refer to the documentation.


2.2. SSH key authentication

In order to increase the access security to the GCap, SSH key authentication was implemented.

This feature enables defining a key for a given user, guaranteeing traceability of connections and accountability of actions.

GCap supports RSA, ECDSA, and ED25519 keys.

This mode is to be preferred to the user name/password pair.

Adding an SSH key for an account is set via the `set ssh-keys` command.

Note:

The password management policy is not used in connection with SSH keys.

2.3. Statistics and health information

2.3.1. Displaying statistics and health information

In order to improve GCap monitoring, new counters on statistics and health information were introduced, covering the following categories:

  • counters and statistics related to mass storage material, processors, RAM, and exchange space,

  • counters related to emergency mode, pairing of GCenter, high availability (HA), availability, and system initialisation features,

  • counters of the Sigflow detection engine and its load such as engine information, network interfaces, received packets by processor core, NUMA node, and average GCap load.

These counters and statistics can be viewed via the `show health` command.


2.3.2. New statistics and health information via Netdata

New statistics and health information are available via Netdata.


2.4. Improvements to the Sigflow detection engine

2.4.1. New version of the engine

The Sigflow engine was updated to take into account new features, new protocols, and so forth.


2.4.2. New protocols supporting the analysis

The table below displays the new protocols that are supported.

The protocol detection is divided in 2 parts:

  • parsing:

  • this enables SIGFLOW signature detection for a given protocol.

  • if parsing is enabled for a protocol then the flow identified by a signature raises an alert.

  • if parsing is disabled for a protocol then no alert is raised.

  • logging:

  • this enables generating metadata for a given protocol to the GCenter.

  • if logging is enabled for a protocol then the observed flow generates metadata.

  • if logging is disabled for a protocol then no metadata is generated.

Protocol

Type

GCAP Versions

V2.5.3.104

V2.5.3.105

DCERPC

parsing

supported

supported

logging

not supported

supported

ENIP

parsing

not supported

supported detection only

logging

not supported

supported

FTP

parsing

supported

supported

logging

not supported

supported

HTTP2

parsing

not supported

supported

logging

not supported

supported

IMAP

parsing

not supported

supported detection only

logging

not supported

supported

MQTT

parsing

not supported

supported

logging

not supported

supported

RDP

parsing

not supported

supported

logging

not supported

supported

RFB

parsing

not supported

supported

logging

not supported

supported

SIP

parsing

not supported

supported

logging

not supported

supported

SNMP

parsing

not supported

supported

logging

not supported

supported


2.4.3. New protocols supported for rebuilding files

The table below displays the new protocols that are supported.

GCAP Versions

Protocol

V2.5.3.104

V2.5.3.105

FTP

supported via defined rules on GCAP only

supported

HTTP2

not supported

supported

NFS

not supported

supported

SMB

supported via defined rules on GCAP only

supported


2.4.4. Adding MAC addresses from the network

As of V2.5.3.105, MAC addresses observed on the network are recorded for the proper functioning of Network Detection & Response (NDR).


2.4.5. Optimisation of TLS encrypted flow analysis

Up until V2.5.3.104, the entire TLS flow is analysed by the detection engine (both the plaintext and encrypted parts).

From V2.5.3.105 onwards:

  • the plaintext part of TLS flows is analysed,

  • the encrypted part of TLS flows is no longer analysed thanks to the addition of a dynamic bypass rule (XDP filter).


2.4.6. Dynamic change of CPU assignments

Up until V2.5.3.104, assigning CPUs to the detection engine could cause instabilities, requiring a restart of the GCap after modification.

As of V2.5.3.105, it is no longer necessary to restart the GCap after a new assignment.


2.4.7. MTU configuration for interfaces monvirt, gcp0 and gcp1

As of V2.5.3.105, it is possible to configure the MTU of the monvirt virtual interface and the gcp0 and gcp1 physical interfaces via the `set advanced-configuration mtu` command.


2.4.8. Enabling TLS connection fingerprinting

As of V2.5.3.105, a new option enabling JA3 is available.

JA3 will enable retrieving information exchanged during TLS negotiation to detect malicious connections.

This option is only available in v102 compatibility mode.


2.4.9. Adding the community-id for the hash of flows

The addition of the community-id, a hash based on a 7-tuple algorithm, will simplify the analysis of a flow between several detection engines.


2.4.10. Adding the « activehunt » classetype

Adding the classetype « activehunt » to the classification file of the detection engine was made in order to take into account the category related to the rules generated from the CTI LIS.


2.4.11. Grace period granted to the capture interface start-up

As of V2.5.3.105, the grace period for starting up the capture interfaces is configurable.

The following commands were added:

  • `show interfaces delay` to view the current value,

  • `set interfaces delay` to set this value.


2.4.12. Manual assignment of all GCap interfaces

Up until V2.5.3.104, it is possible to:

  • view the interfaces using the `show monitoring-interfaces` command,

  • automatically detect interfaces using the `set advanced-configuration rescan-interfaces` command.

As of V2.5.3.105, the following command is completed for detecting and assigning interfaces: `set advanced-configuration interface-names`.

It enables the following actions:

  • assigning the physical interfaces of the GCap:
    • the management interfaces (gcp0 et gcp1)

    • the mon0 to monx or virtual monvirt capture and detection interfaces.

  • resetting the current assignment and returning to an automatic assignment. This assignment is done with the `set advanced-configuration interface-names reset` command.


2.4.13. Detection engine grace period option

Up until V2.5.3.104, the grace period for starting the detection engine is only configurable with root rights.

It is related to the loading times of the rules by the detection engine.

From V2.5.3.105 onwards, this grace period can be modified.

The following commands were added:

  • `show monitoring-engine start-timeout` to display the current value,

  • `set monitoring-engine start-timeout` to configure this value.


2.4.14. Sanity-checks option for the detection engine

As of V2.5.3.105, the check for prerequisites to start the detection engine can be enabled or disabled.

This check consists of verifying whether the monx capture interfaces that are enabled are properly connected in order to allow the engine to start.

The following commands were added:

  • `show monitoring-engine start-checks` to display the current value,

  • `set monitoring-engine {disable-sanity-checks|enable-sanity-checks}` to activate or deactivate the check.



2.6. Addition of an automatic restart mechanism for crashed services

Up until V2.5.3.104, some services were not restarted when they were inoperative.

As of V2.5.3.105, a mechanism was added to automatically restart crashed services.


2.7. Addition of the possibility of placing a command from the CLI with the SSH connection

From V2.5.3.105 onwards, in order to simplify the automation of interactions with the GCap, it is now possible to issue a single command:

  • to connect remotely via SSH,

  • to execute a command,

  • to display the result of the command,

  • to close the remote connection.