2. Nouvelles fonctionnalités

2.1. Haute disponibilité

Afin d’augmenter la disponibilité opérationnelle de la solution, Gatewatcher a implémenté un mécanisme de haute disponibilité.

Il permet de ne pas perdre les flux capturés, par exemple, en cas de panne ou d’arrêt d’un GCap, grâce à la mise en place de deux GCap en redondance.

Ces deux GCap capturent le même flux et communiquent avec un unique GCenter.

En cas de problème sur le GCap « leader », le GCap « follower » prend le relais pour assurer une continuité du service pendant l’opération de maintenance.

Les commandes suivantes ont été ajoutées :

  • `show advanced-configuration high-availability` pour visualiser l’état de la redondance (HA),

  • `set advanced-configuration high-availability` pour configurer la redondance (HA).

Pour plus d’informations sur le fonctionnement de ce mécanisme, veuiller se référer à la documentation.

2.2. Authentification par clé SSH

Afin d’augmenter la sécurité d’accès au GCap, l’authentification par clé SSH a été mis en place.

Cette fonctionnalité permet de définir une clé pour un utilisateur donné en garantissant une traçabilité des connexions et une imputabilité des actions.

Le GCap supporte les clés de type RSA, ECDSA et ED25519.

Ce mode est à privilégier au couple login/mot de passe.

L’ajout d’une clé SSH pour un compte est défini via la commande `set ssh-keys`.

Note:

La politique de gestion des mots de passe n'est pas utilisée dans le cas de clés SSH.

2.3. Statistiques et des informations de santé

2.3.1. Affichage des statistiques et des informations de santé

Afin d’améliorer la supervision du GCap, des nouveaux compteurs sur les statistiques et des informations de santé ont été mis en place, avec les catégories suivantes :

  • les compteurs et statistiques liés au matériel (stockages de masse / processeurs / mémoire vive / l’espace d’échange),

  • les compteurs liés aux fonctionnalités (emergency mode / GCenter appairé / haute disponibilité (HA)/ disponibilité / initialisation du système),

  • les compteurs du moteur de détection Sigflow et de sa charge (Informations sur le moteur / interfaces réseaux / paquets reçus en fonction des cœurs de processeurs / nœud NUMA / charge moyenne du GCap).

Ces compteurs et statistiques sont consultables via la commande `show health`.

2.3.2. Nouvelles statistiques et informations de santé via Netdata

De nouvelles statistiques et informations de santé sont disponibles via Netdata.

2.4. Améliorations relatives au moteur de détection Sigflow

2.4.1. Nouvelle version du moteur

Le moteur Sigflow a été mis à jour pour prendre en compte de nouvelles fonctionnalités, nouveaux protocoles…

2.4.2. Nouveaux protocoles supportés pour l’analyse

Le tableau ci-après indique les nouveaux protocoles supportés.

La détection des prococoles comprends 2 parties :

  • le parsing :

  • il permet d’activer la détection des signatures SIGFLOW pour un protocole donné.

  • si le parsing est activé pour un protocole alors le flux identifié par une signature lève une alerte.

  • si le parsing est désactivé pour un protocole alors aucune alerte n’est levée.

  • le logging :

  • il permet d’activer la génération de métadonnées pour un protocole donné vers le Gcenter.

  • si le logging est activé pour un protocole alors le flux observée génére des métadonnées.

  • si le logging est désactivé pour un protocole alors aucune métadonnée n’est générée.

Protocole

Type

Versions du GCAP

V2.5.3.104

V2.5.3.105

DCERPC

parsing

supporté

supporté

logging

non supporté

supporté

ENIP

parsing

non supporté

supporté détection uniquement

logging

non supporté

non supporté

FTP

parsing

supporté

supporté

logging

non supporté

supporté

HTTP2

parsing

non supporté

supporté

logging

non supporté

supporté

IMAP

parsing

non supporté

supporté détection uniquement

logging

non supporté

non supporté

MQTT

parsing

non supporté

supporté

logging

non supporté

supporté

RDP

parsing

non supporté

supporté

logging

non supporté

supporté

RFB

parsing

non supporté

supporté

logging

non supporté

supporté

SIP

parsing

non supporté

supporté

logging

non supporté

supporté

SNMP

parsing

non supporté

supporté

logging

non supporté

supporté

2.4.3. Nouveaux protocoles supportés pour la reconstruction de fichiers

Le tableau ci-après indique les nouveaux protocoles supportés.

Versions du GCAP

Protocole

V2.5.3.104

V2.5.3.105

FTP

supporté via règles définies sur GCAP uniquement

supporté

HTTP2

non supporté

supporté

NFS

non supporté

supporté

SMB

supporté via règles définies sur GCAP uniquement

supporté

2.4.4. Ajout des adresses MAC observées sur le réseau

A partir de la V2.5.3.105, les adresses MAC observées sur le réseau sont enregistrées pour le bon fonctionnement du Network Detection & Response (NDR).

2.4.5. Optimisation de l’analyse des flux chiffrés TLS

Jusqu’à la V2.5.3.104, l’ensemble d’un flux TLS est analysé par le moteur de détection (partie en clair et partie chiffrée).

A partir de la V2.5.3.105 :

  • la partie en clair des flux TLS est analysée,

  • la partie chiffrée des flux TLS n’est plus analysée grâce à l’ajout d’une règle de bypass dynamique (filtre XDP).

2.4.6. Changement dynamique des assignations des CPU

Jusqu’à la V2.5.3.104, l’assignation des CPU au moteur de détection pouvait provoquer des instabilités et nécessitait donc un redémarrage du GCap après modification.

A partir de la V2.5.3.105, il n’est plus nécessaire d’effectuer ce redémarrage après une nouvelle assignation.

2.4.7. Configuration MTU pour les interfaces monvirt, gcp0 et gcp1

A partir de la V2.5.3.105, il est possible de configurer la MTU de l’interface virtuelle monvirt et des interfaces physiques gcp0`et `gcp1 via la commande `set advanced-configuration mtu`.

2.4.8. Activation de l’empreinte des connexions TLS

A partir de la V2.5.3.105, une nouvelle option permettant l’activation de JA3 est disponible.

JA3 va permettre de récupérer des informations échangées lors de la négociation TLS afin de détecter des connexions malveillantes.

Cette option est uniquement disponible en mode de compatibilité v102.

2.4.9. Ajout du community-id pour le hash des flux

L’ajout du community-id, hash basé sur un algorithme 7 tuple, va faciliter l’analyse d’un flux entre plusieurs moteurs de détection.

2.4.10. Ajout du classetype « activehunt »

L’ajout du classetype « activehunt » dans le fichier de classification du moteur de détection a été réalisée afin de prendre en compte la catégorie relative aux règles générées à partir de la CTI LIS.

2.4.11. Période de grâce accordée au démarrage des interfaces de capture

A partir de la V2.5.3.105, la période de grâce accordée au démarrage des interfaces de capture est configurable.

Les commandes suivantes ont été ajoutées :

  • `show interfaces delay` pour visualiser la valeur courante,

  • `set interfaces delay` pour configurer cette valeur.

2.4.12. Assignation manuelle de toutes les interfaces du GCap

Jusqu’à la V2.5.3.104, il est possible de :

  • visualiser les interfaces avec la commande `show monitoring-interfaces`,

  • détecter automatiquement les interfaces avec la commande `set advanced-configuration rescan-interfaces`.

A partir de la V2.5.3.105, la commande suivante vient compléter les actions possibles au niveau de la détection et l’assignation des interfaces :`set advanced-configuration interface-names`.

Elle permet d’effectuer :

  • l’assignation des interfaces physiques du GCap :

    • les interfaces de management (gcp0 et gcp1)

    • les interfaces de capture et de détection mon0 à monx ou virtuelle monvirt.

  • la réinitialisation de l’assignation courante et revenir à une assignation automatique. Cette assignation se fait grâce à la commande `set advanced-configuration interface-names reset`

2.4.13. Option période de grâce du moteur de détection

Jusqu’à la V2.5.3.104, le délai accordé au démarrage du moteur de détection n’est configurable qu’avec les droits root.

Il est lié aux temps de chargement des règles par le moteur de détection.

A partir de la V2.5.3.105, ce délai (période de grâce) est modifiable.

Les commandes suivantes ont été ajoutées :

  • `show monitoring-engine start-timeout` pour visualiser la valeur courante,

  • `set monitoring-engine start-timeout` pour configurer cette valeur.

2.4.14. Option sanity-checks du moteur de détection

A partir de la V2.5.3.105, le contrôle des prérequis nécessaires au démarrage du moteur de détection peut être activé ou désactivé.

Ce contrôle consiste à vérifier que les interfaces de capture monx qui sont activées sont correctement connectées afin d’autoriser le démarrage du moteur.

Les commandes suivantes ont été ajoutées :

  • `show monitoring-engine sanity-checks` pour visualiser l’état courant,

  • `set monitoring-engine {disable-sanity-checks|enable-sanity-checks}` pour activer ou désactiver le contrôle.

2.6. Ajout d’un mécanisme de redémarrage automatique des services crashés

Jusqu’à la V2.5.3.104, certains services n’étaient pas redémarrés lors qu’ils étaient inopérants.

A partir de la V2.5.3.105, il a été ajouté un mécanisme de redémarrage automatique des services crashés.

2.7. Ajout de la possibilité de passer une commande de la CLI avec la connexion SSH

A partir de la V2.5.3.105, afin de facilité l’automatisation des interactions avec le GCap, il est dorénavant possible en une seule commande :

  • de se connecter à distance en SSH,

  • d’exécuter une commande,

  • d’afficher le résultat de la commande,

  • de fermer la connexion à distante.