2.1.5. Moteur Sigflow
2.1.5.1. Introduction
2.1.5.1.1. Pour quels types de menaces ce moteur est-il conçu ?
la détection de comportements inhabituels ou d’actions non recommandées sur le réseau d’entreprise
la détection d’actions suspectes/malveillantes sur le réseau de l’entreprise, telles que le téléchargement malveillant, le balisage ou l’extraction de fichiers
les détections basées sur des règles générées automatiquement à partir d’indices de compromission (ICO) proviennent de CTI.
2.1.5.1.2. Comment ce moteur particulier détecte-t-il les menaces ?
2.1.5.1.3. Comment ce moteur fonctionne dans le GCenter ?
Sigflow doit être configuré et cette configuration est effectuée par le GCap profil. Le GCap profil contient :
la configuration avancée des paramètres du GCap ( entre autres le choix des protocoles à surveiller...)
un liste structurée de règles
Note
Si le protocole surveillé par des règles n'est pas sélectionné alors Sigflow signalera ces règles comme incorrectes et les ignorera.
2.1.5.1.3.1. Pour plus d'information
2.1.5.2. Fonctionnement détaillé des règles
2.1.5.2.1. 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 le paragraphe 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 le paragraphe Génération des rulesets
l'application de ruleset sur le GCap : voir le paragraphe Detection Ruleset
la configuration avancée des paramètres du GCap : voir le paragraphe Profils GCap
2.1.5.2.2. Sources des signatures du moteur Sigflow
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
`Threat-DB update`.2.1.5.2.3. Rulesets
2.1.5.2.3.1. Optimisation des rulesets
2.1.5.2.3.2. Modification de signatures
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)
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
2.1.5.2.3.2.1. Définition des signatures
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 :
Les protocoles suivants peuvent faire l'objet d'une règle :
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 "Direction" : indique le sens du flux.
Pour la mise en œuvre, voir la procédure de Modification de règles du moteur Sigflow.
2.1.5.2.3.3. Suppression ou limitation du nombre d'alertes
Le nombre d'alertes remontées peut être limité de façon automatique ou manuelle :
2.1.5.2.3.3.1. Création manuelle de la suppression ou limitation du nombre d'alertes
Syntaxe :
threshold: type <threshold|limit|both>, track <by_src|by_dst|by_rule|by_both>, count <N>, seconds <T>
Les différents champs sont :
Champ
`type`: définit le type de limitation. Il y a trois possibilités :
`limit`: limite les alertes à au plus «N» fois
`threshold`: seuil minimum pour une règle avant qu’elle ne génère une alerte
`both deux`: la limitation et le seuillage sont appliqués
Champ
`track`: définit le champ d'application. Il y a plusieurs possibilités :
`by_src`: la limitation est appliquée aux alarmes ayant la même adresse IP source
`by_dst`: la limitation est appliquée aux alarmes ayant la même adresse IP destination
`by_rule`: la limitation est appliquée à toutes les alarmes déclenchées par la règle
`by_both`: la limitation est appliquée aux alarmes ayant la même couple IP adresse source + destination
Champ
`count`: définit la quantité (limite ou seuil) suivant le typeChamp
`seconds`: définit la durée de référence
Exemple :
`threshold: type threshold, track by_src, count 10, seconds 60;
Cette règle ne génère une alerte qu'après 10 alertes levées ayant une même adresse IP source dans une période de temps d’une minute.
2.1.5.2.3.3.2. Création automatique de limites du nombre d'alertes
Principe :
Le nombre d’alertes d'un ou des GCaps peut être contrôlé par limitation.
Le GCenter compte les alertes durant une période d'observation et les compare à un seuil de déclenchement programmable.
Le GCenter détermine les règles qui ont généré ce dépassement du seuil et en fonction du critère sélectionné (type de filtration), le GCenter crée automatiquement des limites d'alarmes.
Ces limites groupées par GCap sont communiquées au moteur Sigflow présent dans chaque GCap pour mettre en oeuvre ces limitations.
Il y a plusieurs types de filtration :
`by_src`: la limitation est appliquée aux alarmes ayant la même adresse IP source
`by_dst`: la limitation est appliquée aux alarmes ayant la même adresse IP destination
`by_rule`: la limitation est appliquée à toutes les alarmes déclenchées par la règle
`by_both`: la limitation est appliquée aux alarmes ayant la même couple IP adresse source + destination
2.1.5.2.3.4. Génération des rulesets
2.1.5.2.4. Profils GCap
Il est possible d'appliquer une politique de règles spécifiques et personnaliser les paramètres depuis les catégories suivantes :
2.1.5.2.4.1. Detection Ruleset
`Detection Rulesets`` permet l'application des Rulesets au GCap appairé au GCenter.Note
Le menu `Detection Rulesets` du GCap permet trois options de configuration :
Note
2.1.5.2.4.1.1. Single-tenant
2.1.5.2.4.1.2. Multi-tenant par interface
2.1.5.2.4.1.3. Multi-tenant par VLAN
Le mode Multi-tenant par VLAN permet:
L’attribution d’un ruleset par VLAN
L’attribution d’un ruleset pour le VLAN par défaut pour les VLAN non créés via l’interface
2.1.5.2.4.2. Variables de base
La partie variables de base est composée de :
2.1.5.2.4.2.1. Analyse de flux et d'extraction de fichiers
2.1.5.2.4.2.2. Proxy HTTP
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.5.2.4.2.3. Charge utile
2.1.5.2.4.2.4. Community ID
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.5.2.4.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 > 3. Sélectionner les protocoles analysés.
Terminologie des termes alerting 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 (Essential, Balanced, Deep, Paranoid, Performance) : dans l'ordre du plus au moins permissif
par la modification du contenu du profil téléchargé dans le GCap.
2.1.5.2.4.3. Net variables
2.1.5.2.4.4. Flow timeouts
2.1.5.2.4.5. File rule management
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 (Essential, Balanced, Deep, Paranoid, Performance) : dans l'ordre du plus au moins complet
par la modification du contenu du profil téléchargé dans le GCap
2.1.5.2.4.6. Packet filtering
`Packet filters` permet d'ignorer un ou plusieurs trafics spécifiques directement au niveau de la carte réseau du GCap.2.1.5.3. Événements générés
Les événements générés par Sigflow sont:
- Événements de type "alerte" lorsque le moteur a trouvé une correspondance avec la signature définie dans les règles d’alerte.Les événements sont affichés dans l’interface principale GCenter ainsi que dans Kibana.
- Événements de type "fileinfo" lorsque le moteur Sigflow a reconstruit les fichiers de flux réseau.Ces événements fileinfo ne sont visibles que dans l’interface Kibana.
- Événements de type "meta-data" lorsque le moteur Sigflow a reconnu le flux réseau.Ces événements de métadonnées ne sont visibles que dans l’interface Kibana.
Ces événements (ou logs) sont structurés de la même façon et cette structure est présentée dans le paragraphe Structure des données des événements de type "alert".
2.1.5.3.1. Événements de type "alerte"
- 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 le Présentation de la WebUI.Il est possible de visualiser la signature trouvée et sa définition.- Pour visualiser les alertes, sélectionner le filtre moteur
`Sigflow`.Voir la présentation de l'Ecran `Alerts` de la WebUI.
- Cliquer sur l'alerte sélectionnée.La fenêtre
`Alert details`est affichée.Les informations détaillées de cette alerte sont affichées dans l'Exemple d’alerte Sigflow dans la WebUI.Les compteurs affichés sont indiqués dans l'annexe Structure des données du journal de bord du moteur.
- Dans l'interface nommée Kibana UI
- Dans l'interface principale WebUI, pour visualiser les alertes, sélectionner le filtre moteur
`Sigflow`.L'écran affiche uniquement la liste des alertes Sigflow.
- Après avoir sélectionné l'alerte, cliquer sur la commande
`Open flow details`du menu`Actions`.Voir la présentation de l'Ecran `Alerts` de la WebUI.Kibana est ouvert dans la catégorie`Sigflow`de la section`Alerts `.L'interface affichée est l'interface nommée Kibana UI (décrite dans l'Interface graphique Kibana).
- Cliquer sur l'onglet
`Messages`(1).
La base de données Kibana est filtrée avec les filtres :network.flow_id: ID unique du flux sélectionné
event.module: sigflow_alert
Cette page affiche toutes les alertes détectées par Sigflow dans ce flux réseau (quelles que soient les adresses IP ou la direction). - Cliquer sur l'icône (2) à gauche de l'alerte.La fenêtre
`Expanded document`(3) est affichée.
Les informations détaillées de cette alerte peuvent être consultées sous forme de tableau ou au format json (voir le paragraphe Événements de type "alerte").Les compteurs affichés sont donnés dans l'annexe Structure des données du journal de bord du moteur.Note
L'interface KibanaUI est également accessible sans filtre via l'icône
`Hunting`sur la barre de menu de gauche dans la WebUI.
2.1.5.3.1.1. Exemple d’alerte Sigflow dans la WebUI
`Alert details` est donnée dans la Fenêtre `Alert details`.2.1.5.3.1.2. Liste des protocoles dans les événements de type "alerte"
app_proto_tc (au client)
app_proto_ts (vers le serveur)
app_proto_orig
Note
Le protocole effectivement reconnu par Sigflow est défini dans le profil GCap sous l’onglet `Alerting and logging` de la colonne `Alerting`.
2.1.5.3.1.3. Structure des données des événements de type "alert"
Les logs sont composées de différentes parties:
La partie en-tête
La partie source définie par "_source"
La partie champ définie par "_fields"
Cette information est affichée dans l’écran `Expanded document` de Kibana.
2.1.5.3.1.3.1. La partie en-tête des événements de type "alert"
La section d’en-tête contient:
"_index": "engines_alerts-2024.11.26-000022",
"_id": "yZzDZ5MBe7GX5B2fDKfY",
"_version": 1,
"_score": 0,
Les informations détaillées sont données dans le tableau (Compteurs de la partie en-tête des journaux).
2.1.5.3.1.3.2. La partie source des événements de type "alert"
La partie source définie par "_source" contient:
Note
`Extended document` sur l’interface Kibana.L’exemple donné ici est un exemple de Kibana.
"http": {
"response": {
"status": 200,
"bytes": 1197,
"mime_type": "application/octet-stream"
},
"http_response_body": "TVqQAAMAAAAA//8AALgAAAOAADwELAQYAAAAAAAAAA",
"http_response_body_printable": "MZ.....!..L.!This program cannot be run in DOS mode.\r\r\n$.............."
"hostname": "",
"version": "HTTP/1.1",
"request": {
"method": "GET"
}
},
"source": {
"ip": "",
"port": 41710,
"mac": ""
},
"flow": {
"pkts_toserver": 4,
"bytes_toserver": 338,
"pkts_toclient": 12,
"bytes_toclient": 15280,
"start": "2024-11-26T09:16:56.277148+0000"
},
"observer": {
"gcap": {
"ingress": {
"interface": {
"name": "monvirt"
}
},
"hostname": "gcap.gatewatcher.com",
"version": "2.5.x"
},
"product": "gcenter",
"hostname": "gcenter.domain.local",
"version": "2.5.3.103",
"log_format_version": "1.0.0",
"uuid": "fc1e66e3-a397-5eb4-9277-754be778f317",
"vendor": "gatewatcher"
},
"network": {
"tx_id": 0,
"protocol": "http",
"timestamp": "2024-11-26T09:16:56.278736+0000",
"transport": "tcp",
"flow_id": 95140270586524
},
"ecs": {
"version": "8.6.0"
},
"metadata": {
"flowbits": [
"min.gethttp",
"exe.no.referer"
]
},
"destination": {
"ip": "x.y.z.a",
"port": 16122,
"mac": "10:e2:ba:a6:a4:70"
},
"sigflow": {
"action": "allowed",
"payload_printable": "GET /emd.exe HTTP/1.1\r\nHost: opred.net\r\nConnection: Keep-Alive\r\n\r\n",
"stream": 1,
"packet": "kOK6pqSQkOK6pqSRmgk2FpoJNha",
"packet_info": {
"linktype": 1
},
"signature_id": 2019714,
"metadata": {
"updated_at": [
"2024_04_22"
],
"performance_impact": [
"Significant"
],
"created_at": [
"2014_11_15"
]
},
"gid": 1,
"signature": "ET CURRENT_EVENTS Terse alphanumeric executable downloader high likelihood of being hostile",
"payload": "R0VUIC9lbWQuZXhlIEhUVFAvMS4mUNCg0K",
"category": "Potentially Bad Traffic",
"rev": 11
},
"url": {
"domain": "opred.net",
"path": "/emd.exe"
},
"@timestamp": "2024-11-26T09:16:56.278Z",
"event": {
"created": "2024-11-26T09:16:56.278736+0000",
"dataset": "alert",
"module": "sigflow_alert",
"kind": "alert",
"category": [
"network",
"intrusion_detection"
],
"severity": 2,
"id": "ce95f31d-6bb1-45f9-9f06-1661f5431329"
},
"@version": "1"
}
2.1.5.3.1.3.3. Liste des compteurs d’événements de type "alert"
Note
Les compteurs d’alerte sont visibles :
Dans l’écran
`Alert details`du WebUIDans l’écran
`Expanded document`de KibanaDans l’exportation vers le SIEM
Les informations détaillées sont données dans le tableau (Compteurs de la partie source des journaux).
2.1.5.3.2. Événements de type "fileinfo"
- Cliquer sur l'icône
`Hunting`de la`WebUI`.
Cliquer sur la section
`Network Metadata`(2) puis sur la catégorie`File Transactions`(1).- Cliquer sur l'onglet
`Messages`(3).
Cette page affiche tous les événements de type fileinfo correspondant aux fichiers reconstruits dans ce flux de réseau.- Cliquer sur l'icône (1) à gauche de l'alerte.
Les informations détaillées (2) de cet événement peuvent être consultées sous forme de tableau ou au format json.Note
L'interface KibanaUI est également accessible sans filtre via l'icône
`Hunting`sur la barre de menu de gauche dans la WebUI.
2.1.5.3.2.1. Exemple des événements de type "fileinfo"
2.1.5.3.2.2. Structure des données des événements de type "fileinfo"
Les logs sont composées de différentes parties:
La partie en-tête
La partie source définie par "_source"
La partie champ définie par "_fields"
Cette information est affichée dans l’écran `Expanded document` de Kibana.
2.1.5.3.2.2.1. La partie en-tête des événements de type "fileinfo"
La section d’en-tête contient:
"_index": "engines_alerts-2024.11.26-000022",
"_id": "yZzDZ5MBe7GX5B2fDKfY",
"_version": 1,
"_score": 0,
Les informations détaillées sont données dans le tableau (Compteurs de la partie en-tête des journaux).
2.1.5.3.2.2.2. La partie source des événements de type "fileinfo"
La partie source définie par "_source" contient:
Note
L’exemple donné ici est un exemple de Kibana.
"user_agent": {
"original": "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)"
},
"destination": {
"port": 19609,
"ip": "x.y.z.a"
},
"source": {
"port": 8080,
"ip": "a.b.c.d"
},
"event": {
"dataset": "network_metadata",
"module": "sigflow_file",
"category": [
"network",
"file"
],
"created": "2025-02-03T16:39:29.577001+0000",
"id": "cbfb9498-72f5-43ab-a53a-aad5bb7b4ad2",
"kind": "event"
},
"@version": "1",
"file": {
"tx_id": 1,
"magic": "Macromedia Flash data (compressed), version 14",
"name": "/6SuCHKKkf8Sf1aFXJPqD0R6r3oEDCrbwHFm23EU-Af2zwWdHgpn6mEGu5XlxFust",
"sid": [
1100020
],
"state": "CLOSED",
"file_id": 1153,
"hash": {
"sha256": "350836364013549b6a76aab79d57d109df6acc143759e24a952d3ff5d6a76ec4",
"md5": "67ca9a31f220bc7b68f203c07ad668b9"
},
"size": 77068,
"gaps": false,
"stored": true
},
"http": {
"http_refer": "http://tsevid-synonymi.justdanceatsea.com:8080/ndf4xx22ci.php",
"response": {
"mime_type": "application/x-shockwave-flash",
"status": 200,
"bytes": 77068
},
"hostname": "tsevid-synonymi.justdanceatsea.com",
"http_port": 8080,
"version": "HTTP/1.1",
"request": {
"method": "GET"
}
},
"url": {
"domain": "tsevid-synonymi.justdanceatsea.com",
"path": "/6SuCHKKkf8Sf1aFXJPqD0R6r3oEDCrbwHFm23EU-Af2zwWdHgpn6mEGu5XlxFust"
},
"observer": {
"product": "gcenter",
"uuid": "78f4fed1-c9ad-52b9-b509-6b87767f501f",
"hostname": "gcenter.domain.local",
"gcap": {
"ingress": {
"interface": {
"name": "monvirt"
}
},
"hostname": "gcap.gatewatcher.fr",
"version": "2.5.x"
},
"version": "2.5.x",
"vendor": "gatewatcher",
"log_format_version": "1.0.0"
},
"@timestamp": "2025-02-03T16:39:29.577Z",
"ecs": {
"version": "8.6.0"
},
"network": {
"protocol": "http",
"transport": "tcp",
"timestamp": "2025-02-03T16:39:29.577001+0000",
"flow_id": 1156097574154966
}
2.1.5.3.2.2.3. Liste des compteurs d’événements de type "fileinfo"
Note
Les compteurs d’alerte sont visibles :
Dans l’écran
`Expanded document`de KibanaDans l’exportation vers le SIEM
Les informations détaillées sont données dans le tableau (Compteurs de la partie source des journaux).
2.1.5.3.2.3. Événements de type "meta-data"
- Cliquer sur l'icône
`Hunting`de la`WebUI`.
Cliquer sur la section
`Network Metadata`puis sur la catégorie de protocole (HTTP par exemple).- Cliquer sur l'onglet
`Messages`.Cette page affiche tous les événements de type métadonnées (metadata) correspondant au protocole détecté dans ce flux de réseau. - Sélectionner la flèche à gauche de l'événement.
Les informations détaillées de cet événement peuvent être consultées sous forme de tableau ou au format json.
2.1.5.3.2.4. Exemple d'évènement de type "meta-data"
2.1.5.3.2.5. Structure des données des événements de type "meta-data"
Les logs sont composées de différentes parties:
La partie en-tête
La partie source définie par "_source"
La partie champ définie par "_fields"
Cette information est affichée dans l’écran `Expanded document` de Kibana.
2.1.5.3.2.5.1. La partie en-tête des événements de type "meta-data"
La section d’en-tête contient:
"_index": "engines_alerts-2024.11.26-000022",
"_id": "yZzDZ5MBe7GX5B2fDKfY",
"_version": 1,
"_score": 0,
Les informations détaillées sont données dans le tableau (Compteurs de la partie en-tête des journaux).
2.1.5.3.2.5.2. La partie source des événements de type "meta-data"
La partie source définie par "_source" contient:
Note
L’exemple donné ici est un exemple de Kibana.
"user_agent": {
"original": "\"Mozilla/5.2 (Windows NT 6.2; rv:50.2) Gecko/20200103 Firefox/50.2\""
},
"destination": {
"port": 16122,
"ip": "x.y.z.a"
},
"source": {
"port": 62219,
"ip": "a.b.c.d"
},
"event": {
"dataset": "network_metadata",
"module": "sigflow_http",
"category": [
"network"
],
"created": "2025-02-03T16:45:17.241433+0000",
"id": "609a229b-d352-4b70-a0db-7915ac2aaeec",
"kind": "event"
},
"@version": "1",
"ether": {},
"http": {
"connection": "Keep-Alive",
"response": {
"mime_type": "text/plain",
"status": 200,
"bytes": 186503
},
"server": "Microsoft-IIS/5.0",
"date": "Thu, 01 Jun 2017 20:55:46 GMT",
"version": "HTTP/1.1",
"request": {
"mime_type": "text/plain",
"bytes": 251904,
"method": "GET"
},
"last_modified": "Thu, 01 Jun 2017 20:25:44 GMT",
"hostname": "fabrique.com",
"accept": "*/*",
"accept_encoding": "gzip, deflate",
"accept_language": "en-US"
},
"url": {
"domain": "fabrique.com",
"path": "/7rvmnb"
},
"observer": {
"product": "gcenter",
"uuid": "78f4fed1-c9ad-52b9-b509-6b87767f501f",
"hostname": "gcenter.domain.local",
"gcap": {
"ingress": {
"interface": {
"name": "monvirt"
}
},
"hostname": "gcap.gatewatcher.fr",
"version": "2.5.x"
},
"version": "2.5.x",
"vendor": "gatewatcher",
"log_format_version": "1.0.0"
},
"@timestamp": "2025-02-03T16:45:17.241Z",
"ecs": {
"version": "8.6.0"
},
"network": {
"tx_id": 0,
"protocol": "http",
"transport": "tcp",
"community_id": "1:cxHEBTJgZCFfWpryH1AkluiYEGk=",
"timestamp": "2025-02-03T16:45:17.241433+0000",
"flow_id": 575568319996003
}
2.1.5.3.2.5.3. Liste des compteurs d’événements de type "meta-data"
Note
Les compteurs d’alerte sont visibles :
Dans l’écran
`Expanded document`de KibanaDans l’exportation vers le SIEM
Les informations détaillées sont données dans le tableau (Compteurs de la partie source des journaux).
2.1.5.4. Gestion du moteur
2.1.5.4.1. Visualisation de l'état du moteur
La visualisation de l'état courant du moteur est donnée dans l'Ecran `Health checks`.