4. Known problems¶
4.1. Export SYSLOG¶
The Syslog UDP export truncates alerts if they are over 65635 bytes.
Workaround: give preference to the use of TCP.
4.2. Status of last 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.
Workaround : Regenerate the rule file in Sigflow Manager.
4.3. LastInfoSec rules¶
Inconsistency between the LIS rules and the generated file, as the rules with the hashes are missing.
Workaround: No solution.
4.4. GUM error management in Local or Online mode¶
For GUM updates (local or online) no information related to the error is available via the GCenter WebUI.
Workaround: Error message available in the GCenter logs.
4.5. 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.
Workaround: No solution.
4.6. Double booting¶
As of version 2.5.3.100, dual booting is no longer supported.
Workaround: No solution.
4.7. 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.
Workaround: No solution.
4.8. Self-signed certificate¶
An error may appear from the GCenter WebUI when applying self-signed certificates. This does not affect the proper operation of encrypted authentication.
Workaround: No solution.
4.9. Malcore Alert¶
In some cases, an inconsistency may occur between the ‘total_found’ and ‘engine_id’ fields.
Workaround: No solution.
4.10. Proxy server configuration¶
After upgrading from GCenter version 2.5.3.10 to 2.5.3.100, the proxy configuration is no longer effective.
Workaround: It is necessary to re-edit the configuration of this one. Corrected to version 2.5.3.100-hf5.
4.11. SUP0 interface configuration¶
After upgrading from GCenter version 2.5.3.10 to 2.5.3.100, the configuration of the SUP0 interface is no longer effective. This leads to problems with exporting to the SYSLOG server using the MGMT0 interface by default.
Workaround: It is necessary to re-edit the configuration of this one. Corrected to version 2.5.3.100-hf5.
4.12. Ruleset¶
If a rule is deactivated in several rulesets, reactivating it in a single ruleset does not work.
Workaround: The rule must be enabled for all rulesets.
4.13. Threshold rule¶
If we edit a rule to enable a Threshold rule, the generate rules file does not update this new configuration.
Workaround: A generate rules file must be executed twice. Corrected as of HF5.
4.14. Export syslog¶
Exporting logs to the syslog server is not done on a 2.5.3.100-hf4 version.
Workaround: A restart of logstash is required. This fix is included in package 5.
4.15. Sigflow Manager - Transform Category¶
Applying a Transform category raises a 500 error if no ruleset is available on GCenter.
Workaround: Creating a ruleset.
4.16. Sigflow Manager - Error 500 when adding a rule to a custom source¶
Adding a rule raises a 500 error if the following conditions are present: * The rule is added by editing a custom source * The rule already exists in another custom source (same SID)
Workaround: Change the rule’s SID that is to be added in order to avoid the SID conflict.
4.17. Sigflow Manager - Inconsistency in the display of the number of categories and rules of a category¶
The Sigflow homepage > Sources shows the number of categories and rules contained in each source. It is possible that the information displayed is inconsistent with the sources’ actual content. This situation may occur after editing a custom source or an update.
Workaround: No workaround.
4.18. LDAP Configuration - TLS¶
User management can be achieved by connecting the GCenter to an Active Directory or other solution running LDAP via the Accounts/LDAP configuration menu. If an LDAP server is used with TLS settings, the status visible in the LDAP interconnection status control panel may indicate an error although 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)’}.
Workaround: No solution.
4.19. Backup Restore¶
In the context of reinstalling the GCenter version that followed a particular upgrade path, restoring the backup will not work.
Workaround: it is necessary to proceed with the upgrade of the versions respecting the path initially made so that the backup can be applied.
*Example: GCenter was installed in version XXX. The X, Y, and Z hotfixes were applied.
To perform a restore:
Install gcenter with version XX,
Then apply the X, Y, and Z hotfixes respectively before restoring.
4.20. GCap FQDN (Pairing/Status)¶
Upper case letters in the GCap FQDN will cause association errors when initiating the IPsec tunnel with GCenter.
Workaround: GCap’s FQDN in the Pairing/Status field must be lower case only.
4.21. Kernel - IPSEC module instability¶
The linux kernel had a module related to ipsec that could cause kernel errors (kernel oops).
Workaround: Fixed in version 2.5.3.100-hf6.
4.22. Malcore - Incorrect file association in the case of replicas¶
In malcore type logs, the “filename” field could be inaccurate if several files had the same hash but different names.
Workaround: Fixed in version 2.5.3.100-hf6.
4.23. Malcore - Accumulation of files in /tmp¶
In some instances, malcore could miss scans, and pending files would remain indefinitely in a directory reserved for temporary files.
Workaround: Fixed in version 2.5.3.100-hf6.
4.24. Malcore - No flow_id¶
The flow_id field was not systematically present in malcore alerts.
Workaround: Fixed in version 2.5.3.100-hf6.
4.25. Malcore - Profiles not saved post upgrade¶
When applying HF6, the profile configuration via Malcore Management is not kept.
In particular, the parameter concerning the maximum size of files analysed by malcore, if it was at its default value before the upgrade, it will be reduced to 2Mb.
Potentially, files rebuilt by GCap would no longer be scanned. This would result in the value File size exceeded in the total_found field of the malcore logs.
Workaround: Reapply the Malcore Management profile configuration and apply the recommended value of 100 for the parameter. Maximum size of scanned files (in MB) in the Default profile accessible from the Administrator/Malcore Management/Profile/Default menu.
4.26. Malcore - Disabling an antivirus engine¶
With malcore v4 (as of the HF6 application), one of the antivirus engines is experiencing instabilities that are dangerous for the overall consistency of Malcore. This was disabled. Consequently, malcore runs with 15 antivirus engines, and the total_found field in the malcore logs is XX/15 and not XX/16.
Workaround: No workaround.
4.27. 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.
Workaround: No workaround.
4.28. Malcore - File analysis¶
When malcore scans a file the first time, it generates a log with a replica=false field.
If that file is viewed again before the end of the file_resend_interval period, malcore does not rescan the file. It creates a log with a replica=true field. These scans of previously observed files are called replicas. (The file_resend_interval is configurable in the Sigflow/GCap Profiles settings of the GCap in Base variables and defaults to 24 hours).
After applying HF6, malcore ensures that each file is analysed at least once. In rare cases, and when a large number of replicas are observed, it is possible that some replica=true scan logs are not generated. Or on the contrary, they are observed in several copies. In the latter case, the try_count field - which is internal to the GCenter operation - is incremented between each copy.
Workaround: If a file with a large number of replica=true occurrences is to be found with certainty:
Find the SHA256 of the file in question in the data produced by malcore (field SHA256);
Filter the file reconstruction metadata of sigflow with this SHA (field fileinfo.sha256).
4.29. 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.
Workaround: No solution.
4.30. Malcore - Black/White list configuration and application¶
It is possible to add White/Black lists of files that malcore should not scan.
The configuration of this feature can be found in Gcenter/Malcore Management/Whitelist(Blacklist).
The white/blacklisting of a file is not immediately effective. It becomes active after a period of time less than or equal to the file_resend_interval configured on the GCap observing the file. (The file_resend_interval is configurable in the Sigflow/GCap Profiles settings of the GCap in Base variables and defaults to 24 hours).
Workaround: No solution.
4.31. 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.
Workaround: No solution.
4.32. 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.
Workaround: In Gcenter-setup: Gapps Management > Reset a GApp > Reset Malcore Engine.