3. Patches

3.1. Status of the latest updates

When restoring a GCenter, information related to the signature update status on GCaps is not restored.
The status will update when the GCap retrieves a new rule file.
This problem is fixed in V2.5.3.102.

3.2. Pairing to a GCAP is not possible if there is no gateway set for the VPN interface

Pairing between the GCenter and the GCap will fail if there is no default gateway set when configuring the network interface mgmt0 of the GCenter.
The error message sent back by the GCap when pairing is `Can't connect to \<Gcenter IP\>`.
This happens even though the GCap and GCenter are in the same subnet and a default gateway should not be required.
This problem is fixed in V2.5.3.102.

3.3. Pairing to a GCAP is not possible after the GCenter network configuration has been changed

After reconfiguring the network settings of the GCenter's VPN interface (e.g. IP, subnet, FQDN), it is possible that re-pairing with a previously paired GCap will no longer work.
Upon pairing, the GCap will display the following error message: `pairing not established`.
This problem is fixed in V2.5.3.102.

3.4. LastInfoSec rules

Inconsistency between the LIS rules and the generated file, as the rules with the hashes are missing.
This problem is fixed in V2.5.3.102.

3.5. Machine Learning engine and CIE editing

The GATEWATCHER tables of the Machine Learning engine do not take into account the license restriction if the GCenter is a CIE edition.
This problem is fixed in V2.5.3.102.

3.6. Netdata Export - Netdata versions higher than 1.19 are not compatible

Exporting GCAP/GCENTER monitoring statistics to an external Netdata is only compatible with a Netdata server whose version is equal or lower than 1.19.
In higher versions, the data is exported and can be queried within the external Netdata. However, an error in the graphic interface occurs and it is impossible to view the data.
This does not affect GCenter, only the external Netdata server.
This problem is fixed in V2.5.3.102.

3.7. GScan - Edition Critical Infrastructure Edition (CIE)

The GScan functionality does not take into account the license restriction if the GCenter is a CIE edition.
This problem is fixed in V2.5.3.102.

3.8. DGA - Field not present

The absence of the `dga_probability` field in the events will be done if the following conditions are met:

  • The activation of logging on DNS event types

  • Activation of the DGA Detection Machine Learning module

  • A heavy DNS network load

This problem is no longer apparent because in V2.5.3.102 dedicated events exist for the DGA.

3.9. Third Party - Intelligence

Interconnection configuration with intelligence raises a 500 error if the token is incorrect.
This problem is fixed in V2.5.3.102.

3.10. Kibana - Inaccessible tables

KIBANA tables may not be displayed after a restart on GCenter and/or the WEB interface.
The error message displayed is `Elastic did not load properly. Check the server output for more information`.
This problem is fixed in V2.5.3.102.

3.11. Kibana - "Not ready yet"

In a few special cases, a failure of the log rotation system can lead to the /var/log/ partition being saturated.
This results in a `not ready yet` error message in Kibana.
This problem is fixed in V2.5.3.102.

3.12. Malcore Management - GScan Profile

The `Number of files` option in Malcore Management's GScan profile enables an alert to be issued based on the number of files in the archive.
This feature is not operational.
This problem is fixed in V2.5.3.102.

3.13. Malcore - Incorrect healthcheck status in Critical Infrastructure Edition (CIE) licence

The health status of the Malcore engine may be incorrectly displayed on the home page in global status/healthcheck.
This can happen when the GCenter is running with the CIE licence: the healthcheck may display `Malware Analysis engine has one or more issues`, even if the engine is running.
This problem is fixed in V2.5.3.102.

3.14. Malcore - No flow_id

In rare cases, the `flow_id` field of a Malcore alert may not appear.
Correlation with the metadata for this Malcore event can be made using the SHA256 and `timestamp_detected` of the Malcore alert.
From version 2.5.3.101-HF2 onwards, if the `flow_id` is missing, it is set to 0, enabling the export of alerts.
This problem is fixed in V2.5.3.102.

3.15. Malcore - Duplicate Analysis

Malcore analysis duplicates can occur during elasticsearch database shrinking operations.
These operations take place every day at 02:00 UTC. They aim at optimizing the memory consumption of elasticsearch by reducing the number of shards per index.
This problem is fixed in V2.5.3.102.

3.16. Malcore - Engine crash due to an overload

The Malcore engine can become unstable if it is under extreme load and hundreds of thousands of files are waiting to be processed.
This results in a total blockage of the engine (no more analysis) or a very significant reduction in the number of analyses being performed.
This problem is fixed in V2.5.3.102.

3.17. Malcore - analysis engine saturation

If the speed of rebuilding files on the GCap is faster than the speed of Malcore analysis, a queue is formed at the GCenter. This causes engine saturation and loss of real time in Malcore alerts.
This problem is fixed in V2.5.3.102.

3.18. Malcore - Service discontinued due to saturation

In exceptional cases, if the Malcore analysis queue holds several thousand large files, a slowdown or stoppage of the service may result.
This problem is fixed in V2.5.3.102.

3.19. Malcore - Disabling an antivirus engine

The Malcore solution is made up of 16 detection engines.
One of the engines is causing malfunctions. It was disabled in version 2.5.3.101-HF2.
This can be seen in the `total_found` field of the Malcore logs which is XX/15.
This engine was re-enabled in V2.5.3.102 and this can be seen in the ``total_found`` field of the Malcore logs which is XX/16.

3.20. Malcore - Export logs with flow_id=0

In rare cases, the `flow_id` field of Malcore logs is not set, preventing them from being exported.
This problem is fixed in V2.5.3.102.

3.21. Malcore - Inconsistent healthcheck WebUI and update status

On the GCenter administrator home page, there is a graphical inconsistency between the `Updates Status` panel and the `Malcore Update Status` panel.
These two panels alert the user if updates are older than 7 days:

  • The first does so after a period of time strictly longer than 7 days

  • While the second one does so for a duration greater than or equal to 7 days

This problem is corrected in V2.5.3.102 with the complete redesign of the healthcheck page.

3.22. Malcore enrichment error on the `app_proto` field

In the Malcore logs, the `app_proto` field specifies the protocol by which an analyzed file was transported.
If the same file is transported by two different protocols, for example HTTP and then SMTP, for the duration of the file_resend_interval (configurable in `Operator > GCap profiles > Base variables > File resend interval`):

  • An initial log replica=false with app_proto=HTTP will be generated

  • Then a second log with replica=true will be issued. The `app_proto` field will be set to HTTP, when it should have been set to SMTP.

This problem is fixed in V2.5.3.102.

3.23. Inconsistency in the Malcore alerts on the `total_found` field

In Malcore alerts, in some instances, the `total_found` field and the `engine_id` number are not identical.
This problem is fixed in V2.5.3.102.

3.24. API - Authentication parameter

Requests to the GCenter API use the `API-KEY` keyword to provide the authentication token as a parameter.
In swagger (https://HOSTNAME-GCENTER/docs/swagger/) the example of generated requests use the keyword apikey.
This problem is fixed in V2.5.3.102.

3.25. API - endpoint /api/alerts not working

The /api/alerts endpoint of the GCenter API is not working:

  • When using descending date sorting, a 500 error is returned if the `page` parameter is not set or equals 1

  • The `page` parameter determines the number of results returned instead of the specified

  • The `page_size` parameter is not taken into account

This problem is fixed in V2.5.3.102.

3.26. Proxy - Error 500 if unable to resolve name

If the proxy specified in `Configuration/Proxy Configuration` cannot be resolved by the DNS server configured for the GCenter, then this produces two errors:

  • A 500 error in the proxy configuration page (/configuration/proxy_settings/);

  • An error in the GUM configuration menu (/gum/configuration

This problem is fixed in V2.5.3.102.

3.27. GCenter-setup - error message

When running gcenter-setup, the following error message may appear:
`Could not connect to home directory /nonexistent: No such file or directory`.
This does not interfere with GCenter's operation in any way.
This problem is fixed in V2.5.3.102.

3.28. LDAP Configuration - TLS

User management can be achieved by connecting the GCenter to an Active Directory or other solution running LDAP via `Accounts/LDAP.configuration` menu.
If an LDAP server is used with TLS settings, the status visible in the `LDAP interconnection status` configuration panel may indicate an error even though the configuration is operational.
The error displayed is as follows:
`Cannot connect to LDAP with current settings: {'desc': "Can't contact LDAP server",'errno': 115, 'info': '(unknown error code)'}`.
This problem is fixed in V2.5.3.102.

3.29. LDAP with SSL or STARTTLS

If LDAP is configured with SSL or STARTTLS and uses a certificate to validate the server, it may disappear when changing the configuration via the GCenter WebUI.
However, it is well preserved and used.
This problem is fixed in V2.5.3.102.

3.30. Syslog export: no Malcore analysis of "unknown" files

A bug affecting the Sigflow engine under very specific conditions can result in the appearance of so-called unknown files. This means that the metadata could not be recovered by Sigflow.
See detailed description of conditions here.
The Malcore analysis for these files are viewable in Kibana, but are not exported via Syslog.
This problem is fixed in V2.5.3.102.

3.31. Syslog export: behavior during saturations

If the throughput of the logs to be exported is such that it saturates the syslog export, the GCenter will first process the metadata events in a best-effort manner (possible losses) in order to preserve the export of Sigflow, Malcore, and Codebreaker alerts.
This problem is fixed in V2.5.3.102.

3.32. Syslog export - Exceptions in log formats

Minor inconsistencies may exist in Malcore (malware index) logs when exported.
The following fields can be of integer type, without quotes around the field value, or of string type with quotes:

  • src_port

  • dest_port

  • detail_scan_time

For example:

  • "src_port": "25"

  • or "src_port": "25".

This problem is fixed in V2.5.3.102.

3.33. Syslog export - duplicate Sigflow alerts

In the syslog export, logs of type "Sigflow alert" (type=suricata AND event_type=alert) are sent twice.
This problem is fixed in V2.5.3.102.

3.34. Redirect Trackwatch Logs to the Syslog dashboard

If one clicks on `Administrator > Gcenter > Trackwatch logs`, the user is redirected to the `Tactical` dashboard instead of the `Syslog` dashboard.
This problem is fixed in V2.5.3.102.

3.35. Default accounts reactivated

When configuring a GCenter, the default accounts administrator and operator must be disabled or the password changed.
If an upgrade is performed, these accounts are reset to their default values and reactivated.
This problem is fixed in V2.5.3.102.

3.36. Default activation of the CIP/ENIP protocol

The CIP/ENIP protocol parsing is enabled by default. It cannot be disabled in the GCenter interface.
This problem is fixed in V2.5.3.102.

3.37. Display bug for adding IPs in the external_net section

In `Operator > GCap profiles > Netvariables`, if one tries to add an EXTERNAL_NET of the list type with a mask other than /24, a display bug prevents the network from being added.
This problem is fixed in V2.5.3.102.