3. Correctifs¶
3.1. Double Authentification¶
L’activation de la double authentification par certificat rendait la WebUI inaccessible et nécessitait une réinitialisation de sa configuration.
Cette fonctionnalité est désormais corrigée et permet d’ajouter une autorité de certification (CA) et une liste de révocation (optionnelle) afin de valider les certificats clients.
Il est possible de l’activer/désactiver via l’interface de la WebUI du GCenter.
3.2. Certificat Personnalisé du GCenter¶
La fonctionnalité d’ajout de certificat pour la WebUI du GCenter est corrigé. Il est désormais possible de l’activer ou de la désactiver.
3.3. SWAP¶
Lors du démarrage du GCenter, l’initialisation de la partition de SWAP chiffrée s’effectue désormais correctement.
3.4. Partition chiffrée de sauvegarde¶
Dans certains cas, au moment du démarrage des services, les disques de sauvegarde ne montaient pas correctement.
Désormais, lorsque leur déchiffrement est effectué, le service vérifie que le disque est accessible et sa partition bien présente.
3.5. Activation de la configuration spécifique à la Loi de Programmation Militaire (LPM)¶
L’application du renforcement LPM du GCenter lorsque celui-ci est sélectionné est fonctionnelle. L’API interne du GCenter résout ce problème.
3.6. Affichage page d’accueil¶
Les informations affichées sur la page d’accueil de l’interface WEB du GCenter étaient erronées et manquaient de cohérence.
Les statuts sont maintenant cohérents avec les alertes en cours.
Les indicateurs de fichiers en attente affichent désormais des valeurs justes pour chacun des moteurs.
Les informations liées aux partitions ElasticSearch sont cohérentes.
3.7. Configuration avancée de Malcore¶
Dans certains cas d’utilisation ou lors de fortes charges, les profils de Malcore se désynchronisaient. Cela avait pour conséquence une surcharge des CPU et de la RAM, ce qui entrainait une accumulation de fichier à analyser.
3.8. Profils d’analyse¶
La synchronisation des profils d’analyse est opérationnelle entre l’interface WEB du GCenter et Malcore à la suite d’un redémarrage inopiné.
3.9. Expiration session web¶
La configuration du backend de la WebUI du GCenter était incohérente et entrainait des déconnexions inopinées des utilisateurs.
3.10. Champs ElasticSearch¶
Dans les versions précédentes de la 2.5.3.100, les incohérences des champs ElasticSearch empêchaient d’utiliser de manière optimale les meta données envoyés à un SIEM.
L’unification et la ré-organisation de ceux-ci (‘src_ip’,’dest_ip’) ont permis de résoudre ce problème.
3.11. Gestion des cookies¶
La configuration des cookies de sessions sur le GCenter était basée sur une gestion côté client. Cela permettait de les réutiliser.
La gestion des cookies est désormais faite côté serveur ce qui empêche toute réutilisation non désirée.
3.12. Edition des tableaux KIBANA¶
La version précédente de KIBANA ne permettait pas la création, l’édition ou la duplication des tableaux. Ce problème est corrigé suite à la mise à jour de KIBANA.
3.13. Historique des authentifications¶
La pagination de l’historique des authentifications sur l’interface Web du GCenter n’était pas correct. Elle est désormais fonctionnelle.
3.14. Historique des adresses IP de connexion¶
L’utilisation de docker entraînait l’affichage d’une adresse IP unique et interne au GCenter.
Désormais l’adresse IP réelle de l’utilisateur qui s’est connecté à la WebUI du GCenter est correctement affichée.
3.15. Création/Edition d’un utilisateur¶
Il était possible de créer un utilisateur avec un nom contenant plus de 256 caractères ce qui entrainait une erreur d’affichage et retournait un code d’erreur HTTP 500. La taille maximale des champs est désormais de 256 caractères.
3.16. Règles Sigflow¶
Dans les versions précédentes, les règles Sigflows générées pour les différents GCaps étaient accessibles de manière globale.
Désormais ces règles son cloisonnées et accessibles par le GCap concerné.
3.17. Rapport PDF¶
La mise en forme des rapports PDF générés par le GCenter était incorrecte. Elle est désormais corrigée.
3.18. BlackList/WhiteList Malcore¶
L’utilisation du système de ‘Black/White list’ pour l’analyse n’avait aucun effet. Elle est désormais corrigée.
3.19. Sigflow Manager¶
L’utilisation de Sigflow Manager était indépendante de la WebUI du GCenter. Désormais Sigflow Manager fait partie intégrante de l’interface Web du GCenter.
3.20. Nombre d’alertes dans les tableaux GATEWATCHER¶
La configuration du nombre d’alertes dans les tableaux Gatewatcher utilise JavaScript.
La sélection d’un trop grand nombre d’alertes entrainait une surcharge du navigateur et rendait l’exploitation des données impossible.
La limitation à 5000 alertes autorisées et 500 par défaut corrige ce problème.
3.21. Export des diagnostiques¶
Le nom du fichier lors de l’export des diagnostiques était erroné, cela empêchait l’opération.
La nouvelle nomenclature du fichier est sous la forme <DATE_UTC>_GCap_diagnostics.csv. Cela corrige le problème.
3.22. Champ mot de passe des archives¶
La configuration du mot de passe pour l’extraction ou la génération d’archives par le GCenter était affichée en clair.
Il est désormais masqué par défaut avec une possibilité de le visualiser.
3.23. Healtcheck¶
Il n’y avait pas de gestion de services des conteneurs.
Grâce à la mise en place d’un Healtcheck, les services des conteneurs sont contrôlés et redémarrés si besoin.
3.24. Utilisateurs non-authentifiés¶
Dans les versions précédentes, un utilisateur non authentifié pouvait accéder librement aux pages d’erreurs correspondant aux différents code http (4XX,5XX). Cela n’est désormais plus possible. Tant que l’utilisateur n’est pas authentifié il est redirigé automatiquement vers la page d’authentification.
3.25. Utilisateurs authentifiés¶
Après authentification, l’utilisateur est redirigé vers la page demandée et non plus vers la page d’accueil.
Dans les versions précédentes, la redirection après authentification n’était pas fonctionnelle.
Désormais, l’utilisateur authentifié sera redirigé vers la page demandée. Si elle n’existe pas, l’utilisateur sera redirigé vers une page de code erreur.
Si la requête est sous forme POST et qu’une authentification est requise, elle sera modifiée sous forme GET.
3.26. Authentification LDAP¶
L’authentification LDAP n’était pas fonctionnelle. La correction de celle-ci est consultable dans les nouvelles fonctionnalités (1.26).