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.5. vpn-link speed option for the VPN tunnel¶
From V2.5.3.105 onwards, it will be possible to specify the link quality between the GCap and the GCenter in order to adapt to low speed links.
The following commands were added:
`show network-config vpn-link speed`
to view the current status,`set network-config vpn-link speed {fast|slow}`
to enable or disable 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.