3. Patches¶

3.1. Double Authentication¶

Enabling dual certificate authentication caused the WebUI to become inaccessible and required a configuration reset.

This feature is now rectified, enabling the addition of a certificate authority (CA) and an optional revocation list to validate client certificates.

It can be enabled/disabled via the GCenter WebUI.

3.2. GCenter Custom Certificate¶

The certificate addition feature for the GCenter WebUI is fixed. It is now possible to enable or disable it.

3.3. SWAP¶

When starting GCenter, the encrypted SWAP partition is now initialised correctly.

3.4. Encrypted Backup Partition¶

In some cases, when starting the services, the backup disks were not mounting properly.

From now on, when decrypting them, the service will check whether the disk is accessible and its partition is present.

3.5. Activating the Military Programming Law (MPL) specific configuration¶

Applying the MPL enhancement of the GCenter, if selected, is functional. The GCenter internal API solves this problem.

3.6. Display the home page¶

The information displayed on the GCenter WEB interface home page was incorrect and incoherent.

The statuses are now consistent with the current alerts.

Pending file indicators now display correct values for each engine.

ElasticSearch partition information is consistent.

3.7. Advanced Malcore configuration¶

In some use cases or under heavy loads, the Malcore profiles were falling out of sync. This resulted in an overload of the CPU and RAM, resulting in a backlog of files to be scanned.

3.8. Analysis profiles¶

Synchronising the analysis profiles is operational between the GCenter WEB interface and Malcore following an unexpected reboot.

3.9. Expiration of web session¶

The GCenter WebUI backend configuration was incoherent, resulting in unexpected user disconnections.

3.10. ElasticSearch fields¶

In previous versions of 2.5.3.100, inconsistencies in ElasticSearch fields prevented optimal use of metadata sent to a SIEM.

Unifying and reorganising these (‘src_ip’, ‘dest_ip’) solved this problem.

3.12. Editing KIBANA tables¶

The previous version of KIBANA did not enable creating, editing, or duplicating tables. This problem was corrected with the Kibana update.

3.13. Authentication history¶

The paging of the authentication history on the GCenter web interface was incorrect. It is now functional.

3.15. Creating/Editing a user¶

It was possible to create a user name longer than 256 characters, resulting in a display error and returning an HTTP 500 error code. The maximum field size is now 256 characters.

3.16. Sigflow rules¶

In previous versions, the Sigflow rules generated for the different GCaps were accessible globally.

From now on, these rules are partitioned and accessible by the GCap concerned.

3.17. PDF report¶

The formatting of the PDF reports generated by the GCenter was incorrect. This has now been corrected.

3.18. BlackList/WhiteList Malcore¶

Using the ‘Black/White list’ system for analysis had no effect. This has now been corrected.

3.19. Sigflow Manager¶

Using Sigflow Manager was independent of the GCenter WebUI. Henceforth, Sigflow Manager is an integral part of the GCenter WebUI.

3.20. Number of alerts in the GATEWATCHER tables¶

The configuration of the number of alerts in the Gatewatcher tables uses JavaScript.

Selecting too many alerts would overload the browser, making it impossible to use the data.

Limiting the number of alerts to 5000 and 500 by default corrects this problem.

3.21. Export of diagnostics¶

The file name when exporting the diagnostics was wrong, preventing the operation.

The new file naming is in the form <DATE_UTC>_GCap_diagnostics.csv. This corrects the problem.

3.22. Archive password field¶

The password setting for archive extraction or generation by the GCenter was displayed in plain text unencrypted.

It is now hidden by default with the option to view it.

3.23. Healthcheck¶

There was no management of container services.

With the implementation of a Healthcheck, container services are checked and restarted if necessary.

3.24. Unauthenticated users¶

In previous versions, an unauthenticated user could freely access the error pages corresponding to the various http codes (4XX,5XX). This is no longer possible. Unless the user is authenticated, they are automatically redirected to the authentication page.

3.25. Authenticated users¶

After authentication, the user is redirected to the requested page instead of the home page.

In previous versions, redirection after authentication was not available.

From now on, the authenticated user will be redirected to the requested page. If it does not exist, the user will be redirected to an error code page.

If the request is in POST form and authentication is required, it will be changed to GET form.

3.26. LDAP authentication¶

LDAP authentication was not working. The fix for this can be found in the new features (1.26).