3. Correctifs
3.1. Statut des dernières mises à jour
Lors de la restauration d’un GCenter, l’information liée à l’état des mises à jour (update) des signatures sur les GCaps n’est pas restaurée.
Le statut se mettra à jour lorsque le GCap récupérera un nouveau fichier de règles.
Ce problème est corrigé en V2.5.3.102.
3.2. Appairage à un GCap impossible si aucune passerelle n'est renseignée pour l'interface VPN
L’appairage entre le GCenter et le GCap échouera si aucune passerelle par défaut n'est renseignée lors de la configuration réseau de l'interface mgmt0 du GCenter.
Le message d'erreur renvoyé par le GCap lors du pairing est
`Can't connect to \<Gcenter IP\>`.Cela se produit même si le GCap et le GCenter sont dans le même sous-réseau et qu'aucune passerelle par défaut ne devrait être nécessaire.
Ce problème est corrigé en V2.5.3.102.
3.3. Appairage à un GCap impossible après changement de la configuration réseau du GCenter
Suite à une reconfiguration des paramètres réseau de l'interface VPN du GCenter (ex : IP, subnet, FQDN), il est possible que le ré-appairage avec un GCap précédemment appairé ne fonctionne plus.
Lors de l’appairage, le GCap indique le message d'erreur suivant :
`pairing not established`.Ce problème est corrigé en V2.5.3.102.
3.4. Règles LastInfoSec
Incohérence entre les règles LIS et le fichier généré, il manque les règles avec les hashs.
Ce problème est corrigé en V2.5.3.102.
3.5. Moteur Machine Learning et édition CIE
Les tableaux GATEWATCHER du moteur de Machine Learning ne prennent pas en compte la restriction de licence lorsque le GCenter est une édition CIE.
Ce problème est corrigé en V2.5.3.102.
3.6. Export Netdata - Incompatibilité avec des versions Netdata supérieures à 1.19
L'export des statistiques de monitoring GCap/GCenter vers un Netdata externe n'est compatible qu'avec un serveur Netdata dont la version est égale ou inférieure à 1.19.
Dans les versions supérieures, les données sont bien exportées et requêtables au sein du Netdata externe mais une erreur au niveau de l'interface graphique se produit et il est impossible de visualiser les données.
Cela n'impacte pas le GCenter, seulement le serveur Netdata externe.
Ce problème est corrigé en V2.5.3.102.
3.7. GScan - Edition Critical Infrastructure Edition (CIE)
La fonctionnalité GScan ne prend pas en compte la restriction de licence lorsque le GCenter est une édition CIE.
Ce problème est corrigé en V2.5.3.102.
3.8. DGA - Champ non présent
L'absence du champ
`dga_probability` dans les events se fera si les conditions suivantes sont réunies :
l'activation du logging sur les event-type DNS
l'activation du module de Machine Learning DGA Detection
une charge réseau DNS importante
Ce problème n'est plus visible car en V2.5.3.102 il existe des évènements dédiés pour le DGA.
3.9. Third Party - Intelligence
La configuration d'interconnexion avec intelligence lève une erreur 500 si le token est erroné.
Ce problème est corrigé en V2.5.3.102.
3.10. Kibana - Tableaux inaccessibles
Les tableaux KIBANA peuvent ne pas s'afficher suite à un redémarrage sur GCenter et/ou de l'interface WEB.
Le message d'erreur affiché est
`Elastic dit not load properly. Check the server output for more information`.Ce problème est corrigé en V2.5.3.102.
3.11. Kibana - "Not ready yet"
Dans certains cas particuliers, une défaillance du système de rotation des logs peut entraîner la saturation de la partition /var/log/.
Cela se traduit au niveau de Kibana par un message d'erreur de type
`not ready yet`.Ce problème est corrigé en V2.5.3.102.
3.12. Malcore Management - GScan Profile
L'option
`Number of files` du profil GScan de Malcore Management permet de retourner une alerte en fonction du nombre de fichier présent dans l'archive.Cette fonctionnalité n'est pas opérationnelle.
Ce problème est corrigé en V2.5.3.102.
3.13. Malcore - Status healthcheck erroné en licence Critical Infrastructure Edition (CIE)
L'état de santé du moteur Malcore peut être affiché de manière erronée au niveau de la page d'accueil, dans global status/healthcheck.
Cela peut se produire lorsque le GCenter fonctionne avec la licence CIE : le healthcheck peut alors afficher
`Malware Analysis engine has one or more issue`, même si le moteur est fonctionnel.Ce problème est corrigé en V2.5.3.102.
3.14. Malcore - Absence de flow_id
Dans de rares cas, le champ
`flow_id` d'une alerte Malcore peut ne pas apparaître.La corrélation avec les métadonnées relatives à cet événement Malcore peut être faite à l'aide des SHA256 et
`timestamp_detected` de l'alerte Malcore.A partir de la version 2.5.3.101-HF2 si le
`flow_id` est absent, celui-ci est défini à 0, permettant l'export des alertes.Ce problème est corrigé en V2.5.3.102.
3.15. Malcore - Doublon d'analyse
Des doublons d'analyse Malcore peuvent apparaître lors des opérations de shrinking de la base de données elasticsearch.
Ces opérations ont lieu tous les jours à 02:00 UTC et visent à optimiser la consommation mémoire d'elasticsearch en réduisant le nombre de shards par index.
Ce problème est corrigé en V2.5.3.102.
3.16. Malcore - Crash du moteur suite à une surcharge
Le moteur Malcore peut devenir instable s'il est soumis à une charge extrême et que des centaines de milliers de fichiers sont en attente de traitement.
Cela se traduit par un blocage total du moteur (plus d'analyse) ou une réduction très importante du nombre d'analyses produites.
Ce problème est corrigé en V2.5.3.102.
3.17. Malcore - Saturation des moteurs d'analyse
Si la vitesse de reconstruction des fichiers sur le GCap est supérieure à la vitesse d'analyse de Malcore, une file d'attente se créée au niveau du GCenter, provoquant un phénomène de saturation des moteurs et de perte du temps réel dans les alertes Malcore.
Ce problème est corrigé en V2.5.3.102.
3.18. Malcore - Arrêt du service pour cause de saturation
Dans de rares cas, lorsque la file d'attente des analyses Malcore comporte plusieurs milliers de fichiers de taille importante, un ralentissement ou un arrêt du service peut être observé.
Ce problème est corrigé en V2.5.3.102.
3.19. Malcore - Désactivation d'un moteur antivirus
La solution Malcore est composée de 16 moteurs de détection.
L'un des moteurs provoque des dysfonctionnements. Il a été désactivé en version 2.5.3.101-HF2.
Cela est visible au niveau du champ
`total_found` des logs Malcore qui est de XX/15.Ce moteur a été réactivé en V2.5.3.102 et cela est visible au niveau du champ total_found des logs Malcore qui est de XX/16.
3.20. Malcore - Export des logs avec flow_id=0
Dans de rares cas, le champ
`flow_id` des logs Malcore n'est pas défini, ce qui empêche l'export de ceux-ci.Ce problème est corrigé en V2.5.3.102.
3.21. Malcore - Incohérence healthcheck WebUI et statut des updates
Sur la page d'accueil du GCenter pour les administrateurs, il existe une incohérence graphique entre le
`Updates Status` du panneau `Global Status` et le panneau `Malcore Update Status`.Ces deux panneaux alertent l'utilisateur lorsque les mises à jour sont plus vieilles de 7 jours ;
le premier le fait au bout d'une durée strictement supérieure à 7 jours
tandis que le second le fait pour une durée supérieure ou égale à 7 jours
Ce problème est corrigé en V2.5.3.102 avec la refonte complète de la page de healthcheck.
3.22. Erreur d'enrichissement de Malcore sur le champ `app_proto`
Dans les logs Malcore, le champ
`app_proto` indique le protocole par lequel un fichier analysé a été transporté.Si un même fichier est transporté par deux protocoles différents (par exemple HTTP puis SMTP) pendant la durée du file_resend_interval (configurable dans
`Operator > GCap profiles > Base variables > File resend interval)` :un premier log replica=false avec app_proto=HTTP sera produit
puis un deuxième log avec replica=true sera produit. Le champ
`app_proto`vaudra HTTP, alors qu'il aurait dû valoir SMTP
Ce problème est corrigé en V2.5.3.102.
3.23. Incohérence dans les alertes Malcore sur le champ `total_found`
Dans les alertes Malcore, dans certains cas, le champ
`total_found` et le nombre d'`engine_id` ne sont pas identiques.Ce problème est corrigé en V2.5.3.102.
3.24. API - Paramètre authentification
Les requêtes destinées à l'API du GCenter utilisent le mot-clé
`API-KEY` pour fournir le token d'authentification en paramètre.Dans swagger (https://HOSTNAME-GCENTER/docs/swagger/) les exemples de requêtes générées utilisent le mot-clé
`apikey`.Ce problème est corrigé en V2.5.3.102.
3.25. API - endpoint /api/alerts non-fonctionnel
Le endpoint /api/alerts de l'API du GCenter n'est pas fonctionnel :
lors de l'utilisation du classement par date de manière décroissante, on obtient une erreur 500 si le paramètre
`page`n'est pas défini ou égal 1le paramètre
`page`détermine le nombre de résultats renvoyés au lieu de renvoyer la page spécifiéele paramètre
`page_size`n'est pas pris en compte
Ce problème est corrigé en V2.5.3.102.
3.26. Proxy - Error 500 en cas de résolution de nom impossible
Si le proxy renseigné dans
`Configuration/Proxy Configuration` ne peut pas être résolu par le serveur DNS configuré pour le GCenter, cela produit deux erreurs :
une erreur 500 au niveau de la page de configuration du proxy (/configuration/proxy_settings/)
une erreur dans le menu de configuration de GUM (/gum/configuration)
Ce problème est corrigé en V2.5.3.102.
3.27. GCenter-setup - message d'erreur
Lors du lancement de gcenter-setup, le message d'erreur suivant peut être visible :
`Could not chdir to home directory/nonexistent: No such file or directory`.
Cela n'affecte en rien le fonctionnement du GCenter.
Ce problème est corrigé en V2.5.3.102.
3.28. LDAP Configuration - TLS
La gestion des utilisateurs peut être assurée via la connexion du GCenter à un Active Directory ou tout autre solution utilisant LDAP via le menu
`Accounts/LDAP configuration`.Lorsqu'un serveur LDAP est utilisé avec des paramètres TLS, le statut visible dans le panneau de configuration
`LDAP interconnection status` peut indiquer une erreur bien que la configuration soit fonctionnelle.L'erreur affichée est alors la suivante :
`Cannot connect to LDAP with current settings: {'desc': "Can't contact LDAP server",'errno': 115, 'info': '(unknown error code)'}`.
Ce problème est corrigé en V2.5.3.102.
3.29. LDAP avec SSL ou STARTTLS
Si LDAP est configuré avec SSL ou STARTTLS et utilise un certificat pour valider le serveur, il peut disparaître lors d’un changement de configuration via la WebUI du GCenter.
Il est cependant bien conservé et utilisé.
Ce problème est corrigé en V2.5.3.102.
3.30. Export syslog : absence des analyses Malcore des fichiers "unknown"
Un bug affectant le moteur Sigflow dans des conditions extrêmement précises peut aboutir à l'apparition de fichiers dits unknown c'est-à-dire dont les métadonnées n'ont pas pu être récupérées par Sigflow.
Voir la description détaillée des conditions ici.
Les analyses Malcore relatives à ces fichiers sont consultables dans Kibana mais ne sont pas exportées via Syslog.
Ce problème est corrigé en V2.5.3.102.
3.31. Export syslog : comportement lors des saturations
Si le débit des logs à exporter est tel qu'il sature l'export syslog, le GCenter commencera par traiter les évènements de type métadonnées en best-effort (pertes possibles) afin de préserver l'export des alertes Sigflow, Malcore et Codebreaker.
Ce problème est corrigé en V2.5.3.102.
3.32. Export syslog - Exceptions dans les formats de logs
Des incohérences mineures peuvent exister dans les logs de type Malcore (index malware) lors de leur export.
Les champs suivants peuvent être de type entier (sans guillemet autour de la valeur du champ) ou de type chaîne de caractères (avec guillemets) :
src_port
dest_port
detail_scan_time
Par exemple :
"src_port" : "25"
ou "src_port" : "25".
Ce problème est corrigé en V2.5.3.102.
3.33. Export syslog - alertes Sigflow en double
Dans l'export syslog, les logs de type "alerte Sigflow" (type=suricata AND event_type=alert) sont envoyés en double.
Ce problème est corrigé en V2.5.3.102.
3.34. Redirection Trackwatch Logs vers le dashboard Syslog
Lorsque l'on clique sur
`Administrator > Gcenter > Trackwatch logs`, l'utilisateur est redirigé vers le tableau de bord `Tactical` à la place du tableau de bord `Syslog`.Ce problème est corrigé en V2.5.3.102.
3.35. Réactivation des comptes par défaut
Lors de la configuration d'un GCenter, les comptes par défaut administrator et operator doivent être désactivés/ou le mot de passe changé.
Lorsque l'on procède à un upgrade, les valeurs de ces comptes sont réinitialisées à celles par défaut et ces derniers sont réactivés.
Ce problème est corrigé en V2.5.3.102.
3.36. Activation par défaut du protocole CIP/ENIP
Le parsing du protocole CIP/ENIP est activé par défaut et ne peut pas être désactivé dans l'interface du GCenter.
Ce problème est corrigé en V2.5.3.102.
3.37. Bug d'affichage pour ajouter des IP dans la partie external_net
Dans
`Operator > GCap profiles > Netvariables`, si l'on essaye d'ajouter un EXTERNAL_NET de type list avec un masque différent de /24, un bug d'affichage empêche d'ajouter le réseau.Ce problème est corrigé en V2.5.3.102.