2.1.3. Moteur Sigflow

2.1.3.1. Présentation

Le moteur Sigflow analyse l'ensemble du trafic réseau et peut, suivant des règles, générer des alertes, des métadonnées ou des contenus.
Ces règles doivent décrire les caractéristiques des attaques qui devront être détectées mais doivent également être optimisées pour réduire les faux positifs.
Le GCenter permet de compiler plusieurs sources et donc plusieurs ensembles de règles pour créer un fichier spécifique appelé Ruleset qui sera ensuite transféré au moteur Sigflow dans le GCap.

2.1.3.2. Organisation des règles

Les règles envoyées au moteur Sigflow sont organisées de la manière suivante :

  • une liste de sources mettant à disposition des fichiers d'ensembles de signatures regroupées en catégories

  • une liste de signatures pouvant être adaptées au besoin de l'environnement à surveiller

  • une liste de ruleset permettant de faire le lien entre les signatures et un GCap

Note

La gestion des sources, catégories, règles et rulesets est faite dans le gestionnaire de règles intégré au GCenter.

Les paragraphes suivants détaillent les étapes nécessaires pour fournir ces règles sous forme de Ruleset au module Sigflow du GCap à travers le GCenter :

  • la gestion des sources de règles disponibles : voir les Sources des signatures du moteur Sigflow
    Les sources permettent de déclarer des dépôts où sont mises à disposition les signatures.
    Une fois téléchargées puis décompressées, les règles devront être ajoutées dans l'interface du GCenter.
    Ces sources se mettent à jour automatiquement dans le cas de source publique / HTTP si le GCenter est connecté à internet, sinon, une mise à jour manuelle peut être faite au niveau de cette interface afin d'avoir les dernières signatures de disponibles.
  • la création des rulesets à partir des sources : voir les Rulesets
    Une fois les règles ajoutées, il est possible d'affecter directement cette source à différents rulesets
  • la génération des rulesets : voir la procédure de Génération des rulesets

  • l'application de ruleset sur le GCap : voir la procédure de Detection Rulesets

  • la configuration avancée des paramètres du GCap : voir les Profils GCap


2.1.3.3. Sources des signatures du moteur Sigflow

Les sources comportent des signatures de détection de type Suricata.
Il existe des sources natives : CTI, ETPRO
Il est aussi possible d'ajouter des sources publiques dans le gestionnaire de règles (public source).
Chaque source délivre un fichier d'ensembles de règles, groupées en catégories.
Il est possible de gérer des catégories et les règles.
Le gestionnaire de règles permet de :
  • définir et gérer les sources des signatures pour le moteur de détection

  • gérer les fichiers de l'ensemble de règles mis à disposition par les sources

  • gérer les catégories et les règles de ces fichiers

  • visualiser les règles présentes dans les sources disponibles

La mise à jour des signatures se fait grâce à l'outil de gestion des mises à GUM (Gatewatcher Update Manager).
L'utilisateur (operator) peut directement affecter une ou plusieurs sources à un ruleset.
Le gestionnaire de gestion des sources est décrit dans l'Ecran `Config - sigflow/sources` de la legacy web UI.
Pour la mise en œuvre, voir les Sources de règles du moteur SIGFLOW.

2.1.3.4. Rulesets

Le ruleset est la politique de sécurité et de détection qui doit être appliquée au GCap.
Comme vu ci-dessus, un ruleset se compose donc de sources comprenant les différentes signatures de détection.
La création du ruleset est obligatoire pour que la sonde GCap puisse analyser le trafic réseau et remonter des alertes.
Des modifications peuvent être effectuées sur les signatures (ou catégories) afin d'adapter une règle à des spécificités du système d'information ou à un besoin spécifique.
Le gestionnaire de gestion des sources est décrit dans l'Ecran `Config - sigflow/rulesets` de la legacy web UI.
Pour la mise en œuvre, voir la procédure de Gestion d'un ruleset du moteur SIGFLOW.

2.1.3.4.1. Optimisation des rulesets

L'optimisation d'un ruleset consiste à adapter au mieux ce dernier au type de trafic analysé (différents points de collecte).
Le ruleset peut être édité à n'importe quel moment (ajout, modification ou suppression de règles, de catégories ou de sources).
Un ruleset modifié doit être appliqué au GCap afin que les modifications soient prises en compte.
Pour la mise en œuvre, voir la procédure de Gestion d'un ruleset du moteur SIGFLOW.

2.1.3.4.2. Modification de signatures

Les signatures et les catégories peuvent être activées, désactivées ou modifiées pour un ruleset donné.
Il est possible :
  • d'activer des signatures et des catégories

  • de désactiver des signatures et des catégories

  • de modifier le fonctionnement d'une signature afin de l'adapter au système d'information supervisé (mise en place de seuil ou suppression d'alerte pour un réseau spécifique)

Il est possible de modifier une signature de la façon suivante :
  • créer une Suppress Rule sur une règle : supprime la levée d'alerte en fonction d'une IP source ou de destination

  • créer une Threshold Rule : limite le nombre d'alertes à afficher en fonction d'une IP source ou de destination

Note

Il n'est pas possible d’interagir directement sur le contenu de la règle depuis le gestionnaire de règles.
Pour la mise en œuvre, voir la procédure de Modification de règles du moteur SIGFLOW.

2.1.3.4.2.1. Définition des signatures

Les signatures présentes dans les sources CTI et ETPRO peuvent comporter des références menant à des blogs, CVE, sites internet,etc accessibles depuis le gestionnaire de règles.
Pour comprendre un peu mieux comment fonctionne une signature, voici un exemple de signature :
../../_images/SR8.png

Une signature est toujours composée :

  • d'une action

  • d'un protocole

  • de paramètres réseaux (IP et port source et destination)

  • d'un message

Exemple d'une signature :

../../_images/SR9.png

Les protocoles suivants peuvent faire l'objet d'une règle :

../../_images/SR10.png

Cette signature est composée de :

  • la 1ère partie "action" : correspond à l'action à effectuer en cas de détection. Par exemple : "alert, pass, drop...""

  • la 2ème partie "l'en-tête" : C'est cette partie qui permet de définir le sens de l'alerte ainsi que les réseaux et protocoles. Par exemple : "tcp any any -> any any "
    Cette partie est composée de :
  • la partie "Protocole" : indique le protocole surveillé. Par exemple : "tcp, udp, icmp"

  • la partie "Source et destination" : spécifie respectivement la source du trafic et la destination du trafic. Il est possible d'assigner des adresses IP (IPv4 et IPv6 sont supportés) et des plages IP avec des opérateurs si besoin.
    Il est possible aussi d'utiliser également des variables, comme $HOME_NET et $EXTERNAL_NET qui sont gérées dans la Partie `Net variables` du menu `Config Gcaps profiles` et Net variables
    Ces variables sont utilisées pour augmenter la précision des alertes que remontent les signatures.
    La syntaxe suivante peut être utilisée pour spécifier les adresses :
    ../../_images/SR11.png
  • la partie "Ports (source et destination)" : indique les ports : le premier est le port source, le second est le port destination (voir la direction de la flèche directionnelle).
    Le trafic entre et sort par les ports. Différents protocoles ont des numéros de port différents.
    Par exemple, le port par défaut pour HTTP est 80 tandis que 443 est généralement le port pour HTTPS.
    A noter cependant que le port ne dicte pas quel protocole est utilisé dans la communication. Il détermine plutôt quelle application reçoit les données.
    La liste ci dessous donne des exemples de spécification des ports.
    ../../_images/SR12.png
  • la partie "Direction" : indique le sens du flux.

    ../../_images/SR13.png
  • la dernière partie correspond aux options appliquées à la règle.
    Celles-ci sont entourées de parenthèses et séparées par des points-virgules.
    Certaines options ont des paramètres (tels que msg), qui sont spécifiés par le mot-clé de l’option, suivie par un deux-points, suivie par les paramètres.
    D’autres n’ont pas de paramètres, ils sont simplement le mot-clé (comme nocase).

Pour la mise en œuvre, voir la procédure de Modification de règles du moteur SIGFLOW.


2.1.3.4.3. Génération des rulesets

Important

Tant que les rulesets n'ont pas été générés après modifications, aucune configuration ne sera déployée sur le GCap.

Une fois le ruleset créé, il est nécessaire de le générer pour valider la création. Il sera ensuite possible de transférer au GCap.
Pour la mise en œuvre, voir la Génération des rulesets du moteur SIGFLOW.

2.1.3.4.3.1. Règle secrète locale

Il est également possible de définir certaines règles localement sur une sonde GCap qui n’apparaîtront volontairement pas dans le gestionnaire de règles du GCenter.
Cela peut se présenter dans les cas suivants :
  • rendre des signatures confidentielles pour que les opérateurs du GCenter ne puissent les voir (notion de 'besoin d'en connaître')

  • dans des cas complexes, faire une modification local sur les signatures de la sonde

  • lorsque le GCenter est confié à un tiers et que ce dernier ne peut manier des marqueurs ou des signatures d'un certain niveau

Cette procédure est détaillée dans la documentation-GCAP à la section Ajouter des règles secrètes localement.


2.1.3.5. Profils GCap

Il est possible d'appliquer une politique de règles spécifiques et personnaliser les paramètres depuis les catégories suivantes :

Afin que le GCap puisse lever des alertes, l'utilisateur doit d'abord appliquer un ruleset à ce dernier.
Le gestionnaire des profils GCap et leurs configurations est décrit dans l'Ecran `Config - Gcaps profiles` de la web UI.
Pour la mise en œuvre, voir la procédure de Configuration des GCaps.

2.1.3.5.1. Detection Rulesets

La section `Detection Rulesets` permet l'application des Rulesets au Gcap appairé au GCenter.
Il est également possible de configurer le module Codebreaker en activant ou désactivant la détection des shellcodes et des powershells.

Note

Il est nécessaire de générer les règles d'un ruleset avant de l'appliquer au GCap. Dans le cas contraire, aucune règle ne sera présente sur la sonde.

Note

Codebreaker est configurable via le menu `Detection Rulesets` mais uniquement pour les licences disposants de ce module.

Le menu `Detection Rulesets` du GCap permet 3 options de configuration :

Note

Ces options de configuration sont exclusives. Cela signifie qu'il ne sera pas possible d'appliquer une configuration single tenant et multi-tenant en même temps.


2.1.3.5.1.1. Single-tenant

Le mode Single-tenant permet :

  • d'attribuer un ruleset pour toutes les interfaces de monitoring du GCap

  • d'activer/désactiver le module Codebreaker pour toutes les interfaces de monitoring du GCap

Le gestionnaire des rulesets de détection est décrit dans la Partie `Detection Rulesets` du menu `Config Gcaps profiles`.
Pour la mise en œuvre, voir la procédure de Configurer Codebreaker puis appliquer les Rulesets Sigflow aux GCaps.

2.1.3.5.1.2. Multi-tenant by interface

Le mode Multi-tenant by interface permet :

  • d'attribuer un ruleset par interface de monitoring du GCap

  • d'activer/désactiver le module Codebreaker par interface de monitoring du GCap

Le multi-tenant by interface permet d'appliquer un ruleset pour chacune des interfaces du GCap et donc d'avoir une supervision différente par interface.
En effet il est possible d'appliquer un ruleset différent ainsi que de configurer Codebreaker pour chacune des interfaces du GCap.
Le gestionnaire des rulesets de détection est décrit dans la Partie `Detection Rulesets` du menu `Config Gcaps profiles`.
Pour la mise en œuvre, voir la procédure pour Configurer Codebreaker puis appliquer les Rulesets Sigflow aux GCaps.

2.1.3.5.1.3. Multi-tenant by vlan

Le mode Multi-tenant by vlan permet :

  • attribuer un ruleset par vlan

  • attribuer un ruleset pour le vlan par défaut (les vlans non créés via l'interface)

  • activer/désactiver le module Codebreaker par vlan

  • activer/désactiver le module Codebreaker pour le vlan par défaut (les vlans non créés via l'interface)

Le multi-tenant by vlan permet d'appliquer une configuration pour chaque vlan précédemment créé dans l'interface et d'avoir une supervision différente sur des réseaux différents.
Il est donc possible d'appliquer un ruleset ainsi que de configurer Codebreaker de manière indépendante pour chaque vlan.
Un vlan nommé "default" est créé par défaut dans l'interface. Il permet d'appliquer un ruleset et de configurer Codebreaker pour l'ensemble des vlans qui ne sont pas explicitement déclarés dans l'interface.
Le gestionnaire des rulesets de détection est décrit dans la Partie `Detection Rulesets` du menu `Config Gcaps profiles`.
Pour la mise en œuvre, voir la procédure pour Configurer Codebreaker puis appliquer les Rulesets Sigflow aux GCaps.

2.1.3.5.2. Base variables

La partie Base variables permet d'ajuster les paramètres de capture de la sonde grâce aux fonctions avancées de Sigflow configurable depuis GCenter.
Les modifications de cette configuration entraînent des répercussions sur les remontées d'alertes depuis la sonde GCap vers le GCenter.
L'activation de certaines options va permettre l'émission d'alertes, d'anomalies, de métadonnées, d'informations sur les fichiers et des enregistrements spécifiques aux protocoles.
Les alertes sont des enregistrements d'événements provoqués par la correspondance d'une règle avec le trafic réseau.
Une alerte sera générée avec des métadonnées associées, comme l'enregistrement de la couche applicative (HTTP, DNS, etc).
L'interface graphique de ce gestionnaire des variables de base est décrite dans la Partie `Base variables` du menu `Config Gcaps profiles`.

La partie variables de base est composée de :


2.1.3.5.2.1. Stream analysis and file extraction

La zone d'analyse de flux et d'extraction de fichiers permet de contrôler la façon dont le moteur Sigflow gère les tailles maximum des flux et de l’extraction de fichiers.
L'interface graphique et le détail des paramètres sont décrits dans la partie Zone `Stream analysis and file extraction`.

2.1.3.5.2.2. HTTP Proxy

La zone Proxy HTTP permet d'améliorer les métadonnées et les alertes des flux mandatés avec l’en-tête http X-Forwarded-For (XFF).
L'interface graphique et le détail des paramètres sont décrits dans la partie Zone `HTTP Proxy`.

Note

XFF est une en-tête standard permettant d'identifier l'adresse IP d'origine d'un client se connectant à un serveur web par le biais d'un proxy HTTP ou d'un équilibreur de charge.


2.1.3.5.2.3. Payload

La section Payload permet l'activation ou désactivation de différents champs présents (Http body, Payload printable, Http body printable...) dans les évènements.
L'interface graphique et le détail des paramètres sont décrits dans la partie Zone `Payload`.

2.1.3.5.2.4. Community ID

La section Community ID permet l'activation ou désactivation de ce champ dans les événements.
Ce dernier permet d'identifier les flux réseaux analysés.

Note

Ce champ est présent dans d'autres solutions que celle de Gatewatcher. Il peut donc permettre de faire de la corrélation entre les différents outils d'un même système d'information.

L'interface graphique et le détail des paramètres sont décrits dans la partie Zone `Community ID`.


2.1.3.5.2.5. Alerting et logging

La section Alerting and logging permet la configuration de l'alerting et du logging des protocoles utilisés par le Gcap.

Note

Dans le cas où un GCap a une version d'avance sur le GCenter, il est possible que certains protocoles ne soient pas encore implémentés dans ce dernier.

Ce point est abordé plus en détail dans la documentation-GCAP dans la section Moteur de détection Sigflow > Reconstruction de fichiers.

Terminologie des termes parsing et logging :

  • l'alerting consiste à activer la détection des signatures Sigflow pour un protocole donné. En effet si ce dernier est activé pour un protocole alors le flux qui est identifié par une signature lèvera une alerte côté GCenter.

  • le logging consiste à activer la génération de métadonnées pour un protocole donné. En effet, si ce dernier est activé pour un protocole alors chaque session observée générera des métadonnées pour ce protocole côté GCenter.

La gestion de la configuration des protocoles est faite :

  • par l'utilisation de profils proposés par défaut (Minimal, Balanced, LPM, Paranoid, Intuitio) : dans l'ordre du plus au moins permissif

  • par la modification du contenu du profil téléchargé dans le GCap.

Le choix du profil par défaut et le chargement sur le GCap est fait dans l'interface graphique détaillé dans l'Ecran `Admin-GCaps pairing and status` de la legacy web UI.
La modification de la configuration du profil chargé dans le GCap est fait dans l'interface graphique détaillée dans la Zone `Alerting and logging`.
La configuration par défaut des protocoles varie en fonction du profil du GCap utilisé : la liste est indiquée dans le paragraphe Paramètres par défaut pour les profils existants disponibles.
La liste des protocoles configurables avec l'option alerting et avec l'option logging est indiquée dans les Paramètres par défaut pour les profils existants disponibles.

2.1.3.5.3. Net variables

La zone Net variables de l'interface graphique permet de définir les variables réseaux utilisées dans les règles Sigflow.
La liste des variables et leurs valeurs par défaut sont données dans la Partie `Net variables` du menu `Config Gcaps profiles`.
Cette interface graphique est décrite dans la Partie `Net variables` du menu `Config Gcaps profiles`.

2.1.3.5.4. Flow timeouts

La Partie Flow timeouts permet de configurer le temps (en secondes) pendant lequel Sigflow garde un flux en mémoire en fonction de son état.
La liste des paramètres et leurs valeurs par défaut sont données dans la Partie `Flow timeouts` du menu `Config Gcaps profiles`.
Cette interface graphique est décrite dans la Partie `Flow timeouts` du menu `Config Gcaps profiles`.

2.1.3.5.5. File rule management

La partie File rule management permet de sélectionner les types de fichiers à extraire pour un protocole donné.
L'extraction de fichiers fonctionne en parallèle des signatures Sigflow définies pour ces mêmes protocoles.
Les fichiers sont reconstruits puis enregistrés sur le disque avec des métadonnées qui incluent des informations comme :
  • l'horodatage

  • l'adresse IP source/destination

  • le protocole

  • le port source/destination

  • la taille

  • le md5sum, etc

La gestion de la configuration de la gestion des règles d'extraction de fichiers est faite :

  • par l'utilisation de profils proposés par défaut (Minimal, Balanced, LPM, Paranoid, Intuitio) : dans l'ordre du plus au moins complet

  • par la modification du contenu du profil téléchargé dans le GCap

Le choix du profil par défaut et le chargement sur le GCap sont détaillés dans l'Ecran `Admin-GCaps pairing and status` de la legacy web UI.
La modification de la configuration du profil chargé dans le GCap est détaillé dans la Partie `File rule management` du menu `Config Gcaps profiles`.
La liste des protocoles ainsi que la liste des types de fichiers sont données dans l'Ecran `Config - Gcaps profiles` de la web UI.

2.1.3.5.6. Packet filtering

La partie `Packet filters` permet d'ignorer un ou plusieurs trafics spécifiques directement au niveau de la carte réseau du GCap.
Cette fonctionnalité permet de ne pas surcharger le GCap avec du trafic "inutile" (flux chiffrés, flux de backup, etc) ou pouvant faire monter les cpus en charge (Elephant Flow, Miles Flow, etc).
Le choix du trafic que l'on souhaite ignorer se fait sur la base de vlan, de prefix réseau, de protocoles ou encore de ports réseaux.
L'interface graphique est détaillé dans la Partie `Packet filters` du menu `Config Gcaps profiles`.

2.1.3.6. Événements générés

Les événements générés par Sigflow sont :

  • des Événements de type "alert" quand le moteur a trouvé une correspondance avec la signature définie dans les règles d'alertes.
    Les événements sont affichés dans l'interface principale du GCenter ainsi que dans Kibana.
    Dans l'interface principale, il est possible de visualiser la signature trouvée et sa définition.
    Dans l'interface principale nommée WEB UI du GCenter dans l'écran `Alerts` (l'interface principale nommée WEB UI est décrite dans la Présentation de l'interface graphique WEB UI).
    Pour visualiser les alertes, il faut sélectionner le filtre IDS et ainsi visualiser la liste des alertes : voir la présentation de l'écran `Alerts` de la web UI.
    En cliquant sur une alerte, les informations détaillées de cette alerte sont affichées : voir Compteurs de la partie source des logs Sigflow de type alerte.
    Dans l'interface Kibana UI
    Pour visualiser les alertes; il faut sélectionner le filtre Sigflow et ainsi visualiser la liste des alertes : voir la présentation de l'écran Alerts de la web UI.
    En cliquant sur une alerte, il faut sélectionner sur la commande `Flow details` puis sélectionner la flèche à gauche de l'alerte.
    L'interface affiché est l'interface nommée Kibana UI (décrite dans la Présentation de l'interface graphique Kibana).
    Les informations détaillées de cette alerte sont visualisables en format tableau ou jason.
    Les informations détaillées de cette alerte sont affichées : voir Compteurs de la partie source des logs Sigflow de type alerte.
  • des Événements de type "fileinfo" quand le moteur Sigflow a reconstruit les fichiers du flux réseau.
    Ces événement du type fileinfo sont visibles dans l'interface Kibana.
    Pour cela, il faut sélectionner sur la commande Hunting puis l'onglet `Sigflow` et la catégorie `Messages` puis sélectionner la flèche à gauche de l'événement.
    Les informations détaillées de cette événement sont visualisables en format tableau ou jason.
    Les informations détaillées de cette événement sont affichées (voir Événements de type "fileinfo").
  • des Événements de type "méta-données" quand le moteur Sigflow a reconnu le flux réseau.
    Ces événement du type métadonnées sont visibles dans l'interface Kibana.
    Pour cela, il faut sélectionner sur la commande Hunting puis l'onglet `Metadata` et la catégorie `Messages` puis sélectionner la flèche à gauche de l'événement.
    Les informations détaillées de cette événement sont visualisables en format tableau ou jason.
    Les informations détaillées de cette événement sont affichées (voir Compteurs des metadonnées).

Ces évènements (ou logs) sont structurés de la même manière et cette structure est présentée dans le paragraphe Exemple et structure des logs (Événements) Sigflow.


2.1.3.6.1. Exemple et structure des logs (Événements) Sigflow

2.1.3.6.1.1. Exemple d'un log Sigflow

Ci dessous un exemple de log sigflow (log de type alert) est affiché :

{
"_index": "suricata-2023.10.09-000162",
"_type": "_doc",
"_id": "lb-iE4sBeBoubSygsnlA",
"_version": 1,
"_score": 1,
"_source": {
  "proto": "TCP",
  "@timestamp": "2023-10-09T08:51:50.124Z",
  "uuid": "1b6e03fa-d325-4f3d-ac54-e2dd6152c8fd",
  "timestamp_analyzed": "2023-10-09T08:51:50.124Z",
  "gcap": "gcap-xxxxxxxxx.domain.local",
  "host": "gcap-xxxxxxxxx.domain.local",
  "flow": {
    "pkts_toclient": 4,
    "pkts_toserver": 4,
    "bytes_toserver": 421,
    "bytes_toclient": 647,
    "start": "2023-10-09T08:51:17.974120+0000"
  },
  "dest_port": 48740,
  "alert": {
    "signature_id": 2034636,
    "rev": 2,
    "action": "allowed",
    "severity": 3,
    "metadata": {
      "updated_at": [
        "2021_12_08"
      ],
      "attack_target": [
        "Client_Endpoint"
      ],
      "former_category": [
        "INFO"
      ],
      "signature_severity": [
        "Minor"
      ],
      "deployment": [
        "Perimeter"
      ],
      "affected_product": [
        "Windows_XP_Vista_7_8_10_Server_32_64_Bit"
      ],
      "created_at": [
        "2021_12_08"
      ]
    },
    "signature": "ET INFO Python SimpleHTTP ServerBanner",
    "gid": 1,
    "category": "Misc activity"
  },
  "type": "suricata",
  "packet": "ivOZFqBXfu+N6xq...AqAABwKgAAwBQvmQfXmk2N+fYu4AYAfzRowAAAQEIClfrLQ32MlIpUEsDBAoAAAAAAOCYuCg8z1FoRAAAAEQAAAAJAAAAZWljYXIuY29tWDVPIVAlQEFQWzRcUFpYNTQoUF4pN0NDKTd9JEVJQ0FSLVNUQU5EQVJELUFOVElWSVJVUy1URVNULUZJTEUhJEgrSCpQSwECFAAKAAAAAADgmLgoPM9RaEQAAABEAAAACQAAAAAAAAABACAA/4EAAAAAZWljYXIuY29tUEsFBgAAAAABAAEANwAAAGsAAAAAAA==",
  "timestamp_detected": "2023-10-09T08:51:17.976Z",
  "dest_ip": "X.X.X.X",
  "src_port": 80,
  "ether": {
    "dest_mac": "7e:ef:8d:eb:1a:81",
    "src_mac": "8a:f3:99:16:a0:57"
  },
  "community_id": "1:r6LvcE7ltny4a6Y9xt1VroBgcKs=",
  "event_type": "alert",
  "@version": "1",
  "severity": 3,
  "stream": 1,
  "flow_id": 1666858537573672,
  "gcenter": "gcenter-xxx.domain.local",
  "payload_printable": "HTTP/1.0 200 OK\r\nServer: SimpleHTTP/0.6 Python/3.7.3\r\nDate: Thu, 20 Aug 2020 08:27:52 GMT\r\nContent-type: application/zip\r\nContent-Length: 184\r\nLast-Modified: Thu, 20 Aug 2020 08:26:32 GMT\r\n\r\n",
  "src_ip": "X.X.X.X",
  "in_iface": "monvirt",
  "http": {
    "hostname": "eicar.com",
    "status": 200,
    "http_user_agent": "Wget/1.20.1 (linux-gnu)",
    "url": "/eicar_com.zip",
    "http_content_type": "application/zip",
    "length": 0,
    "http_method": "GET",
    "protocol": "HTTP/1.1"
  },
  "payload": "SFRUUC8xLjAgMjAwIE9LDQpTZXJ2ZXI6IFNpbXBsZUhUVFAvMC42IFB5dGhvbi8zLjcuMw0KRGF0ZTogVGh1LCAyMCBBdWcgMjAyMCAwODoyNzo1MiBHTVQNCkNvbnRlbnQtdHlwZTogYXBwbGljYXRpb24vemlwDQpDb250ZW50LUxlbmd0aDogMTg0DQpMYXN0LU1vZGlmaWVkOiBUaHUsIDIwIEF1ZyAyMDIwIDA4OjI2OjMyIEdNVA0KDQo=",
  "tx_id": 0,
  "app_proto": "http",
  "packet_info": {
    "linktype": 1
  }
},
"fields": {
  "alert.category": [
    "Misc activity"
  ],
  "alert.metadata.signature_severity": [
    "Minor"
  ],
  "http.url": [
    "/eicar_com.zip"
  ],
  "type": [
    "suricata"
  ],
  "uuid": [
    "1b6e03fa-d325-4f3d-ac54-e2dd6152c8fd"
  ],
  "alert.metadata.created_at": [
    "2021_12_08"
  ],
  "event_type": [
    "alert"
  ],
  "payload": [
    "SFRUUC8xLjAgMjAwIE9LDQpTZXJ2ZXI6IFNpbXBsZUhUVFAvMC42IFB5dGhvbi8zLjcuMw0KRGF0ZTogVGh1LCAyMCBBdWcgMjAyMCAwODoyNzo1MiBHTVQNCkNvbnRlbnQtdHlwZTogYXBwbGljYXRpb24vemlwDQpDb250ZW50LUxlbmd0aDogMTg0DQpMYXN0LU1vZGlmaWVkOiBUaHUsIDIwIEF1ZyAyMDIwIDA4OjI2OjMyIEdNVA0KDQo="
  ],
  "flow_id": [
    1666858537573672
  ],
  "host": [
    "gcap-xxxxxxxxx.domain.local"
  ],
  "ether.src_mac": [
    "8a:f3:99:16:a0:57"
  ],
  "alert.metadata.former_category": [
    "INFO"
  ],
  "dest_port": [
    48740
  ],
  "alert.severity": [
    3
  ],
  "gcenter": [
    "gcenter-xxx.domain.local"
  ],
  "flow.bytes_toclient": [
    647
  ],
  "packet": [
    "ivOZFqBXfu+N6xq...AqAABwKgAAwBQvmQfXmk2N+fYu4AYAfzRowAAAQEIClfrLQ32MlIpUEsDBAoAAAAAAOCYuCg8z1FoRAAAAEQAAAAJAAAAZWljYXIuY29tWDVPIVAlQEFQWzRcUFpYNTQoUF4pN0NDKTd9JEVJQ0FSLVNUQU5EQVJELUFOVElWSVJVUy1URVNULUZJTEUhJEgrSCpQSwECFAAKAAAAAADgmLgoPM9RaEQAAABEAAAACQAAAAAAAAABACAA/4EAAAAAZWljYXIuY29tUEsFBgAAAAABAAEANwAAAGsAAAAAAA=="
  ],
  "tx_id": [
    0
  ],
  "http.length": [
    0
  ],
  "timestamp_detected": [
    "2023-10-09T08:51:17.976Z"
  ],
  "http.hostname": [
    "eicar.com"
  ],
  "flow.bytes_toserver": [
    421
  ],
  "dest_ip": [
    ""X.X.X.X""
  ],
  "proto": [
    "TCP"
  ],
  "gcap": [
    "gcap-xxxxxxxxx.domain.local"
  ],
  "timestamp_analyzed": [
    "2023-10-09T08:51:50.124Z"
  ],
  "alert.metadata.deployment": [
    "Perimeter"
  ],
  "http.http_user_agent": [
    "Wget/1.20.1 (linux-gnu)"
  ],
  "http.http_method": [
    "GET"
  ],
  "alert.metadata.attack_target": [
    "Client_Endpoint"
  ],
  "ether.dest_mac": [
    "7e:ef:8d:eb:1a:81"
  ],
  "alert.metadata.affected_product": [
    "Windows_XP_Vista_7_8_10_Server_32_64_Bit"
  ],
  "flow.pkts_toclient": [
    4
  ],
  "http.http_content_type": [
    "application/zip"
  ],
  "src_ip": [
    "X.X.X.X"
  ],
  "community_id": [
    "1:r6LvcE7ltny4a6Y9xt1VroBgcKs="
  ],
  "stream": [
    "1"
  ],
  "alert.rev": [
    2
  ],
  "@version": [
    "1"
  ],
  "alert.signature_id": [
    "2034636"
  ],
  "alert.action": [
    "allowed"
  ],
  "packet_info.linktype": [
    1
  ],
  "severity": [
    3
  ],
  "payload_printable": [
    "HTTP/1.0 200 OK\r\nServer: SimpleHTTP/0.6 Python/3.7.3\r\nDate: Thu, 20 Aug 2020 08:27:52 GMT\r\nContent-type: application/zip\r\nContent-Length: 184\r\nLast-Modified: Thu, 20 Aug 2020 08:26:32 GMT\r\n\r\n"
  ],
  "http.protocol": [
    "HTTP/1.1"
  ],
  "app_proto": [
    "http"
  ],
  "in_iface": [
    "monvirt"
  ],
  "src_port": [
    80
  ],
  "flow.start": [
    "2023-10-09T08:51:17.974Z"
  ],
  "alert.gid": [
    1
  ],
  "@timestamp": [
    "2023-10-09T08:51:50.124Z"
  ],
  "alert.signature": [
    "ET INFO Python SimpleHTTP ServerBanner"
  ],
  "flow.pkts_toserver": [
    4
  ],
  "http.status": [
    "200"
  ],
  "alert.metadata.updated_at": [
    "2021_12_08"
  ]
}
}

2.1.3.6.1.2. Structure des logs sigflow

Les logs sont composés de différentes parties :

  • la partie entête

  • la partie source définie par "_source"

  • la partie champs définie par "_fields"


La partie entête des logs sigflow

La partie entête contient :

{
 "_index": "suricata-2023.10.09-000162",
 "_type": "_doc",
 "_id": "lb-iE4sBeBoubSygsnlA",
 "_version": 1,
 "_score": 1,
Tableau partie entête des logs sigflow

Champ

Requis

Description

Valeurs ou exemple

_index

Oui

Index interne

suricata-2023.10.09-000162

_type

Oui

type par défault

_doc

_id

Oui

identifiant interne

lb-iE4sBeBoubSygsnlA

_version

Oui

version interne

1

_score

Oui

pertinence de la réponse par rapport à la requête

1


La partie source des logs sigflow

La partie source définie par "_source" contient :

{
 "_index": "suricata-2023.10.09-000162",
 "_type": "_doc",
 "_id": "lb-iE4sBeBoubSygsnlA",
 "_version": 1,
 "_score": 1,
 "_source": {
   "proto": "TCP",
   "@timestamp": "2023-10-09T08:51:50.124Z",
   "uuid": "1b6e03fa-d325-4f3d-ac54-e2dd6152c8fd",
   "timestamp_analyzed": "2023-10-09T08:51:50.124Z",
   "gcap": "gcap-xxxxxxxxx.domain.local",
   "host": "gcap-xxxxxxxxx.domain.local",
   "flow": {
     "pkts_toclient": 4,
     "pkts_toserver": 4,
     "bytes_toserver": 421,
     "bytes_toclient": 647,
     "start": "2023-10-09T08:51:17.974120+0000"
   },
   "dest_port": 48740,
   "alert": {
     "signature_id": 2034636,
     "rev": 2,
     "action": "allowed",
     "severity": 3,
     "metadata": {
       "updated_at": [
         "2021_12_08"
       ],
       "attack_target": [
         "Client_Endpoint"
       ],
       "former_category": [
         "INFO"
       ],
       "signature_severity": [
         "Minor"
       ],
       "deployment": [
         "Perimeter"
       ],
       "affected_product": [
         "Windows_XP_Vista_7_8_10_Server_32_64_Bit"
       ],
       "created_at": [
         "2021_12_08"
       ]
     },
     "signature": "ET INFO Python SimpleHTTP ServerBanner",
     "gid": 1,
     "category": "Misc activity"
   },
   "type": "suricata",
   "packet": "ivOZFqBXfu+N6xq...AqAABwKgAAwBQvmQfXmk2N+fYu4AYAfzRowAAAQEIClfrLQ32MlIpUEsDBAoAAAAAAOCYuCg8z1FoRAAAAEQAAAAJAAAAZWljYXIuY29tWDVPIVAlQEFQWzRcUFpYNTQoUF4pN0NDKTd9JEVJQ0FSLVNUQU5EQVJELUFOVElWSVJVUy1URVNULUZJTEUhJEgrSCpQSwECFAAKAAAAAADgmLgoPM9RaEQAAABEAAAACQAAAAAAAAABACAA/4EAAAAAZWljYXIuY29tUEsFBgAAAAABAAEANwAAAGsAAAAAAA==",
   "timestamp_detected": "2023-10-09T08:51:17.976Z",
   "dest_ip": "X.X.X.X",
   "src_port": 80,
   "ether": {
     "dest_mac": "7e:ef:8d:eb:1a:81",
     "src_mac": "8a:f3:99:16:a0:57"
   },
   "community_id": "1:r6LvcE7ltny4a6Y9xt1VroBgcKs=",
   "event_type": "alert",
   "@version": "1",
   "severity": 3,
   "stream": 1,
   "flow_id": 1666858537573672,
   "gcenter": "gcenter-xxx.domain.local",
   "payload_printable": "HTTP/1.0 200 OK\r\nServer: SimpleHTTP/0.6 Python/3.7.3\r\nDate: Thu, 20 Aug 2020 08:27:52 GMT\r\nContent-type: application/zip\r\nContent-Length: 184\r\nLast-Modified: Thu, 20 Aug 2020 08:26:32 GMT\r\n\r\n",
   "src_ip": "X.X.X.X",
   "in_iface": "monvirt",
   "http": {
     "hostname": "eicar.com",
     "status": 200,
     "http_user_agent": "Wget/1.20.1 (linux-gnu)",
     "url": "/eicar_com.zip",
     "http_content_type": "application/zip",
     "length": 0,
     "http_method": "GET",
     "protocol": "HTTP/1.1"
   },
   "payload": "SFRUUC8xLjAgMjAwIE9LDQpTZXJ2ZXI6IFNpbXBsZUhUVFAvMC42IFB5dGhvbi8zLjcuMw0KRGF0ZTogVGh1LCAyMCBBdWcgMjAyMCAwODoyNzo1MiBHTVQNCkNvbnRlbnQtdHlwZTogYXBwbGljYXRpb24vemlwDQpDb250ZW50LUxlbmd0aDogMTg0DQpMYXN0LU1vZGlmaWVkOiBUaHUsIDIwIEF1ZyAyMDIwIDA4OjI2OjMyIEdNVA0KDQo=",
   "tx_id": 0,
   "app_proto": "http",
   "packet_info": {
     "linktype": 1
   }
 },

La partie champs des logs sigflow

La partie champs définie par "fields" contient les même compteurs que dans la partie source: se référer à la section partie source


2.1.3.6.2. Événements de type "alert"

2.1.3.6.2.1. Exemple d'événements de type "alert" Sigflow dans la webui

../../_images/ALERTE-07.PNG

Les compteurs sont détaillées dans la Structure des logs sigflow.


2.1.3.6.2.2. Données des logs de type "alert"

La lise des protocoles pouvant généré des alertes est indiqué par le paramètre Paramètres par défaut pour les profils existants disponibles [champ app_proto).
Si un protocole change en cours de route (par exemple si SMTP est upgradé en TLS via STARTTLS) ou si les protocoles utilisés ne sont pas les mêmes dans les deux sens du flux, les champs suivants peuvent apparaître :
  • app_proto_tc (to client)

  • app_proto_ts (to server)

  • app_proto_orig

Note

Le protocole effectivement reconnu par Sigflow est défini dans le profil GCap dans l'onglet `Alerting and logging` dans la colonne `Alerting`.


2.1.3.6.2.3. Compteurs de la partie source des logs Sigflow de type alerte

Note

Ce tableau récapitulatif indique les compteurs qui ne dépendent pas des protocoles.

Tableau partie source des logs Sigflow de type alerte

Champ

Requis

Description

Valeurs ou exemple

@timestamp

Oui

Timestamp du traitement de l'alerte par le GCenter (correspond au passage dans logstash)

2023-10-09T08:51:50.124Z

@version

oui

version du document

1

app_proto

Non

Protocole applicatif du flux de provenance du fichier

http

community_Id

Oui

Id unique pour correler l'élèment entre les différents équipements de sécurité

1:r6LvcE7ltny4a6Y9xt1Vr...

dest_ip

Oui

Adresse IP de destination

"X.X.X.X"

dest_mac

Oui

Adresse MAC de destination

"7e:ef:8d:eb:1a:81"

dest_port

Non

Port de destination. Présent seulement quand proto vaut udp ou tcp

48740

event_type

Oui

Type d’évènement : alert

Par défaut alert

flow_id

Oui

Identifiant du flux

1666858537573672

flow.bytes_toclient

Oui

Taille du flux vers le client

647

flow.bytes_toserver

Oui

Taille du flux vers le serveur

421

flow.pkts_toclient

Oui

Nombre de paquets vers le client

4

flow.pkts_toserver

Oui

Nombre de paquets vers le serveur

4

flow.reason

Non

Mécanisme qui a provoqué l’arrêt de traitement du flux entre (“timeout”, “forced”, “shutdown”)

flow.start

Oui

Date et heure du premier paquet vu par suricata

2023-10-09T08:51:17.974120+0000

gcap

Oui

Nom du gcap associé à l’alerte

gcap-xxxxxxxxx.domain.local

gcenter

Oui

Nom du GCenter associé à l’alerte

gcenter-xxx.domain.local

host

Oui

Nom du gcap associé à l’alerte

gcap-xxxxxxxxx.domain.local

in_iface

Non

Interface de capture sur le gcap

monvirt

packet

Oui

paquet ayant déclenché l’alerte enregistré en base64 (uniquement pour UDP)

ivOZFqBXfu+N6xq......

packet_info.linktype

Oui

Type d’entête de la link-layer

1

payload

Non

Payload du paquet au format base64
Présent seulement si l’option payload du menu « bases variables » du gcap est activée

"SFRUUC8xLjAgMjAwIE9...

payload_printable

Non

Payload du paquet dans un format lisible.
Présent seulement si l’option payload printable du menu « bases variables » du gcap est activée.

"HTTP/1.0 200 OKrnServer: SimpleHTTP/0.6 Python/3.7.3r..."

proto

Oui

Protocole de couche 4 utilisé

TCP

severity

Oui

Niveau de sévérité de l’alerte

3

src_ip

Oui

Adresse IP source

"X.X.X.X"

src_mac

Oui

Adresse MAC source

"8a:f3:99:16:a0:57"

src_port

Non

Port de la source. Présent seulement quand proto vaut udp ou tcp

80

stream

Oui

1

Timestamp du traitement de l'alerte par le GCenter (correspond au passage dans logstash)

Oui

Date et heure de l’analyse de l’alerte par logstash

2023-10-09T08:51:50.124Z

timestamp detected

Oui

Date et heure de la génération de l’alerte par suricata

2023-10-09T08:51:17.976Z

tx_id

oui

identification de transaction (paire requête/réponse)

0

type

Oui

Type d’évènement: par défaut suricata

suricata

uuid

Oui

Identifiant unique de l’alerte

1b6e03fa-d325-4f3d...

Tableau récapitulatif des compteurs de la catégorie "Alert"

Champ

Requis

Description

Valeurs ou exemple

alert.action

oui

Allowed si l’action alert ou pass est utilisé et blocked si l’action drop ou reject est utilisé.

alert, drop, reject, pass "action": "allowed",

alert.category

Oui

Description de la classification de l’alerte

classtype. exemple Misc activity

alert.gid

Oui

Identifiant d’un groupe d’alerte

gid

alert.metadata

Non

Métadonnées de l’alerte. La spécification des champs est libre.

metadata: key value

alert.rev

Oui

Numéro de révision de l’alerte

2

alert.severity

Oui

Niveau de sévérité de l’alerte

3

alert.signature

Oui

Description de l’alerte

ET INFO Python SimpleHTTP ServerBanner

alert.signature_id

Oui

Identifiant de l’alerte. Il doit être unique.

sid. exemple 2034636

Liste des métadonnées utilisées dans les alertes des sources ETPRO et CTI (objet alert.metadata dans ES):

  • alert.metadata.affected_product

  • alert.metadata.attack_target

  • alert.metadata.created_at

  • alert.metadata.deployment

  • alert.metadata.former_category

  • alert.metadata.impact_flag

  • alert.metadata.malware_family

  • alert.metadata.performance_impact

  • alert.metadata.ruleset

  • alert.metadata.service

  • alert.metadata.signature_severity

  • alert.metadata.tag

  • alert.metadata.updated_at

Voici un exemple d'alerte qui utilise les métadonnées affected_product, attack_target, created_at, deployment, signature_severity, tag et updated_at:

alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 1433 (
msg:"ET EXPLOIT MS-SQL SQL Injection closing string plus line comment";
flow: to_server,established;
content:"'|00|";
content:"-|00|-|00|";
reference:url,doc.emergingthreats.net/bin/view/Main/2000488;
classtype:attempted-user;
sid:2000488;
rev:7;
metadata:affected_product Web_Server_Applications, attack_target Web_Server, created_at 2010_07_30, deployment Datacenter, signature_severity Major, tag SQL_Injection, updated_at 2016_07_01;
)

2.1.3.6.3. Événements de type "fileinfo"

Note

Ce tableau récapitulatif indique les compteurs qui ne dépendent pas des protocoles.

Champ

Requis

Description

app_proto

Oui

Protocole applicatif du flux de provenance du fichier . exemple http

dest_ip

Oui

Adresse IP de destination

dest_port

Oui

Port de destination. Présent seulement quand proto vaut udp ou tcp

event_type

Oui

Type d’évènement

fileinfo.file_id

Non

Identifiant du fichier

fileinfo.filename

Oui

Nom du fichier

fileinfo.gaps

Oui

fileinfo.magic

Non

Identifiant du type de fichier

fileinfo.md5

Non

Hash MD5 du fichier

fileinfo.sha1

Non

Hash SHA1 du fichier

fileinfo.sha256

Non

Hash SHA256 du fichier

fileinfo.size

Oui

Taille du fichier

fileinfo.state

Oui

Complétude du fichier analysé (CLOSED) sinon TRUNCATED.
La variable file-store.stream-depth de suricata définit la taille des fichiers reconstruits.
Le fichier est TRUNCATED si sa taille est > File-store stream depth (10 MO) par défaut.

fileinfo.stored

Oui

True si le fichier est reconstruit et False sinon.

fileinfo.tx_id

Oui

identification de transaction (paire requête/réponse)

flow_id

Oui

Identifiant du flux

gcap

Oui

Nom du gcap associé à l’alerte

gcenter

Oui

Nom du GCenter associé à l’alerte

host

Oui

Nom du gcap associé à l’alerte

in_iface

Non

Interface de capture sur le gcap

proto

Oui

Protocole de couche 4 utilisé

src_ip

Oui

Adresse IP de destination

src_port

Non

Port de destination. Présent seulement quand proto vaut udp ou tcp

timestamp analyzed

Oui

Date et heure de l’analyse de l’alerte par logstash

timestamp detected

Oui

Date et heure de la génération de l’alerte par suricata

type

Oui

Type d’événement. Par défaut suricata

uuid

Oui

Identifiant unique de l’alerte

vlan

Non

Identifiant du vlan du flux


2.1.3.6.4. Événements de type "méta-données"

2.1.3.6.4.1. Liste des champs présents dans toutes les alertes avec event_type != ["alert", "fileinfo", "stats"]

  • @timestamp

  • @version

  • dest_ip

  • event_type

  • flow_id

  • gcap

  • GCenter

  • host

  • proto

  • src_ip

  • timestamp_analyzed

  • timestamp_detected

  • type

  • uuid


2.1.3.6.4.2. Liste des protocoles compatibles avec le logging (champ event_type)

  • dhcp:

    • dhcp.assigned_ip

    • dhcp.client_ip

    • dhcp.client_mac

    • dhcp.dhcp_type

    • dhcp.dns_servers

    • dhcp.hostname

    • dhcp.id

    • dhcp.lease_time

    • dhcp.next_server_ip

    • dhcp.params

    • dhcp.rebinding_time

    • dhcp.relay_ip

    • dhcp.renewal_time

    • dhcp.requested_ip

    • dhcp.routers

    • dhcp.subnet_mask

    • dhcp.type

  • dnp3

  • dns:

  • body.proba_dga

  • body.severity

  • dga_probability

  • dns.aa

  • dns.answers.rdata

  • dns.answers.rrname

  • dns.answers.rrtype

  • dns.answers.ttl

  • dns.authorities.rrname

  • dns.authorities.rrtype

  • dns.authorities.ttl

  • dns.flags

  • dns.grouped.A

  • dns.grouped.AAAA

  • dns.grouped.CNAME

  • dns.id

  • dns.qr

  • dns.ra

  • dns.rcode

  • dns.rd

  • dns.rrname

  • dns.rrtype

  • dns.tx_id

  • dns.type

  • dns.version

  • headers.content-length

  • headers.content-type

  • tags

  • ftp

  • http:

  • http.accept

  • http.accept-charset

  • http.accept-datetime

  • http.accept_encoding

  • http.accept_language

  • http.accept-range

  • http.age

  • http.allow

  • http.authorization

  • http.cache_control

  • http.connection

  • http.content_encoding

  • http.content-language

  • http.content-length

  • http.content-location

  • http.content-md5

  • http.content-range

  • http.content_type

  • http.content-type

  • http.cookie

  • http.date

  • http.dnt

  • http.etags

  • http.from

  • http.hostname

  • http.http_content_type

  • http.http_method

  • http.http_port

  • http.http_refer

  • http.http_user_agent

  • http.last-modified

  • http.length

  • http.link

  • http.location

  • http.max-forwards

  • http.origin

  • http.pragma

  • http.proxy-authenticate

  • http.proxy-authorization

  • http.range

  • http.redirect

  • http.referrer

  • http.refresh

  • http.retry-after

  • http.server

  • http.set-cookie

  • http.status

  • http.te

  • http.trailer

  • http.transfer-encoding

  • http.upgrade

  • http.url

  • http.vary

  • http.via

  • http.warning

  • http.www-authenticate

  • http.x-authenticated-user

  • http.x-flash-version

  • http.x-forwarded-proto

  • http.x-requested-with

  • ikev2:

  • ikev2.alg_auth

  • ikev2.alg_dh

  • ikev2.alg_enc

  • ikev2.alg_esn

  • ikev2.alg_prf

  • ikev2.errors

  • ikev2.exchange_type

  • ikev2.init_spi

  • ikev2.message_id

  • ikev2.notify

  • ikev2.payload

  • ikev2.resp_spi

  • ikev2.role

  • ikev2.version_major

  • ikev2.version_minor

  • krb5:

  • krb5.cname

  • krb5.encryption

  • krb5.error_code

  • krb5.failed_request

  • krb5.msg_type

  • krb5.realm

  • krb5.sname

  • krb5.weak_encryption

  • netflow:

  • icmp_code

  • icmp_type

  • metadata.flowbits

  • netflow.age

  • netflow.bytes

  • netflow.end

  • netflow.max_ttl

  • netflow.min_ttl

  • netflow.pkts

  • netflow.start

  • parent_id

  • tcp.ack

  • tcp.cwr

  • tcp.ecn

  • tcp.fin

  • tcp.psh

  • tcp.rst

  • tcp.syn

  • tcp.tcp_flags

  • nfs:

  • nfs.file_tx

  • nfs.filename

  • nfs.hhashl

  • rpc.auth_type

  • rpc.creds.gid

  • rpc.creds.machine_name

  • rpc.creds.uid

  • rpc.status

  • rpc.xid

  • smb:

  • smb.access

  • smb.accessed

  • smb.changed

  • smb.client_dialects

  • smb.client_guid

  • smb.command

  • smb.created

  • smb.dcerpc.call_id

  • smb.dcerpc.interfaces.ack_reason

  • smb.dcerpc.interfaces.ack_result

  • smb.dcerpc.interfaces.uuid

  • smb.dcerpc.interfaces.version

  • smb.dcerpc.opnum

  • smb.dcerpc.req.frag_cnt

  • smb.dcerpc.req.stub_data_size

  • smb.dcerpc.request

  • smb.dcerpc.res.frag_cnt

  • smb.dcerpc.res.stub_data_size

  • smb.dcerpc.response

  • smb.dialect

  • smb.directory

  • smb.disposition

  • smb.filename

  • smb.fuid

  • smb.function

  • smb.id

  • smb.modified

  • smb.named_pipe

  • smb.ntlmssp.domain

  • smb.ntlmssp.host

  • smb.ntlmssp.user

  • smb.request.native_lm

  • smb.request.native_os

  • smb.response.native_lm

  • smb.response.native_os

  • smb.server_guid

  • smb.service.request

  • smb.service.response

  • smb.session_id

  • smb.share

  • smb.share_type

  • smb.size

  • smb.status

  • smb.status_code

  • smb.tree_id

  • smtp:

  • email.attachment

  • email.body_md5

  • email.from

  • email.status

  • email.subject

  • email.subject_md5

  • email.to

  • smtp.helo

  • smtp.mail_from

  • smtp.rcpt_to

  • ssh:

    • ssh.client.proto_version

    • ssh.client.software_version

    • ssh.server.proto_version

    • ssh.server.software_version

  • tftp:

    • tftp.file

    • tftp.mode

    • tftp.packet

  • tls:

    • tls.chain

    • tls.fingerprint

    • tls.issuerdn

    • tls.notafter

    • tls.notbefore

    • tls.sni

    • tls.subject

    • tls.version


2.1.3.6.4.3. Compteurs des metadonnées

Tableau récapitulatif des compteurs qui ne dépendent pas des protocoles:

Champ

Requis

Description

app_proto

Non

Protocole applicatif du flux de provenance du fichier

dest_ip

Oui

Adresse IP de destination

dest_port

Non

Port de destination. Présent seulement quand proto vaut udp ou tcp

event_type

Oui

Type d’évènement. Par défaut alert

flow_id

Oui

Identifiant du flux

gcap

Oui

Nom du gcap associé à l’alerte

gcenter

Oui

Nom du GCenter associé à l’alerte

host

Oui

Nom du gcap associé à l’alerte

in_iface

Non

Interface de capture sur le gcap

proto

Oui

Protocole de couche 4 utilisé

src_ip

Oui

Adresse IP de destination

src_port

Non

Port de destination. Présent seulement quand proto vaut udp ou tcp

timestamp analyzed

Oui

Date et heure de l’analyse de l’alerte par suricata

timestamp detected

Oui

Date et heure de la génération de l’alerte par suricata

type

Oui

Type d’événement. Par défaut suricata

uuid

Oui

Identifiant unique de l’alerte

vlan

Non

Identifiant du vlan du flux


2.1.3.7. Visualisation de l'état de Sigflow

La visualisation de l'état courant du moteur est donnée dans l'Ecran `Health checks` de la web UI.


2.1.3.8. Mise à jour de Sigflow

Il y a des mises à jour (Updates) pour le moteur Sigflow.
Ces mises à jour peuvent se faire de façon manuelle ou planifiée via GUM.

2.1.3.9. Configuration de Sigflow

Le moteur se configure par des profils.
Pour plus d'information, voir le paragraphe Profils GCap.
Pour la mise en œuvre, voir la procédure de Configuration des GCaps.