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 passerrelle 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 healtcheck 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 healtcheck 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étadata 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éfinis à 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_protovaudra HTTP, alors qu’il aurait du 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
pagen’est pas défini ou égal 1le paramètre
pagedétermine le nombre de résultats renvoyés au lieu de renvoyer la page spécifiéele paramètre
page_sizen’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 /nonexistant: 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 Suricata dans des conditions extrêmement précises peut aboutir à l’apparition de fichiers dits unknown c’est-à-dire dont les métadata n’ont pas pu être récupérées par Suricata.
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 evènements de type métadata 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 dashboard Tactical à la place du dashboard 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.