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 informationThis 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) license¶
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 license: the healtcheck 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 optimising the memory consumption of elasticsearch by reducing the number of shards per index.
his 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 analysed 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_protofield 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
pageparameter is not set or equals 1The
pageparameter determines the number of results returned instead of the specifiedThe
page_sizeparameter 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 suricata 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 suricata.
See detailed description of conditions here.
The Malcore analyses 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: behaviour during saturations¶
If the throughput of the logs to be exported is such that it saturates the syslog export, 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.