3. Other features and improvements

3.1. Change of operating system

A complete overhaul of the GCap operating system has taken place at V2.5.3.105.


3.2. Change of the programming language

The main programming language changed to V2.5.3.105.


3.3. Update of the kernel

The operating system kernel was updated to the latest Long-Term Support (LTS) version.


3.4. Performance improvement

3.4.1. Codebreaker performance improvements

From V2.5.3.105 onwards, in order to improve Codebreaker’s performance, a new programming language was used and the code was optimised.


3.4.2. Optimising the network communication between the GCap and the GCenter

Up until V2.5.3.104, there was a systematic exchange of files between the GCap and the GCenter.

From V2.5.3.105 onwards:

  • only the updated files are compressed and downloaded in several parallel sessions and no longer file by file,

  • to manage the sending of eve-logs between GCap and GCenter, a new exchange mechanism was implemented,

  • to download configurations and files between the GCenter and the GCap:

    • for the GCenter in V2.5.3.104, rsync was used,

    • for GCenter in V2.5.3.105, there was a new exchange mechanism only compatible with GCenter version 102. For GCenters in version 101, rsync will remain the method used.


3.4.3. Improved load management of monx capture interfaces

Up until V2.5.3.104, load balancing from the monx capture interfaces to the GCap CPUs was implemented on an experimental basis.

As of V2.5.3.105, this feature has matured although the functionality is only compatible with certain GCap models.

For more information on this enhancement, please contact the Gatewatcher technical support.


3.5. Global security improvements

3.5.1. Network security

3.5.1.1. Stricter isolation of the SSH service using VRF

From V2.5.3.105 onwards, in order to further secure the SSH service, VRFs are used for better partitioning.


3.5.1.2. Redesign of internal firewall rules

As of V2.5.3.105, iptables were replaced by nftables for filtering internal GCap flows and dynamically managed rules were abandoned in favour of static rules predefined according to the GCap status.


3.5.1.3. Redesign of the IPsec management between the GCap and the GCenter

From V2.5.3.105 onwards, in-depth changes to the IPSec service were made in order to improve the stability and security of exchanges between the GCap and the GCenter.


3.5.2. Security system

3.5.2.1. Improved quality of the cryptographic keys

As of V2.5.3.105, an entropy injection mechanism was introduced to improve the quality of the cryptographic keys generated, particularly during the first start-up.


3.5.2.2. Strengthening the SSH service configuration

In V2.5.3.105, the SSH service was tightened up to follow the ANSSI recommendations.


3.5.2.3. Improving process isolation

From V2.5.3.105 onwards, better process isolation is provided by Systemd with a limitation of the memory space allocated to processes, read-only access, and more.


3.5.2.4. PAM policy and account lock management

As of V2.5.3.105, a complete overhaul of the PAM policy and account lock management was carried out.


3.5.2.5. Protection of read-only disk partitions

Starting with V2.5.3.105, partitions containing GCap code are now set to read-only when the server is started and not when the detection engine is started.


3.5.2.6. Changing the root password policy

Starting with V2.5.3.105, the root password is randomly generated. It is no longer available to users of the system.

For more information on this subject, please contact the GATEWATCHER technical support.



3.5.2.8. Risk reduction on SUID rights

As of V2.5.3.105, all programs having the SUID property, which are not used, are either removed or disabled.


3.5.2.9. Improved XDP filter support daemon

As of V2.5.3.105, the following improvements were applied to the XDP filter daemon:

  • reduction of the attack surface with more dynamic code compilation, hardening of the daemon, and more.

  • increased performance.


3.5.2.10. Improved Netdata security

As of V2.5.3.105, the native Netdata measurement modules are replaced by a secure daemon developed by Gatewatcher.


3.5.2.11. Creation of a specific initrd image

From V2.5.3.105 onwards, a secure initrd image, generated by Gatewatcher, is now being used.


3.5.2.12. Replacement of the start-up system

As of V2.5.3.105, the OpenRC initialisation system is replaced by systemd.


3.6. Changes to the CLI


3.6.2. Selecting the protocols to be analysed by the detection engine

Until V2.5.3.104, the selection of protocols to be analysed by the detection engine was done via the GUI or the `Protocols-selector` command.

From V2.5.3.105 onwards, this function is handled via the detection engine rules, so it is managed by the GCenter.

The `Protocols-selector` command was therefore removed from the CLI.


3.6.3. The configuration GUI is marked obsolete

As of V2.5.3.105, the GUI is considered deprecated or obsolete.

The new features will therefore only be fully usable through the CLI.

3.7. Features available for extracting diagnostic data to Gatewatcher technical support

In order to easily collect the data necessary for diagnosis by Gatewatcher technical support, an automated extraction of the GCap operating data was developed.

This extraction is performed by using the `tech-support` command of the `show` subgroup.


3.8. Changing the driver reload strategy

Up to V2.5.3.104, a reboot was performed with a driver shutdown and then a service reboot + file load: `system restart-drivers` command.

From V2.5.3.105 onwards, a reload of the configuration files is performed: `system reload-drivers` command.


3.9. Modification of the crisis management strategy (emergency mode)

From V2.5.3.105 onwards, disk space management was added with the implementation of quotas to avoid the saturation of these spaces that would render the GCap inoperative.

If these quotas are exceeded, emergency mode is triggered, which dynamically changes the GCap’s data retention time to 2 minutes.

Thus all files older than this retention time will be deleted, starting with the oldest until the emergency mode is exited.

For further information on this feature, please consult the documentation.