2.1.3. Moteur Sigflow
2.1.3.1. Présentation
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 SigflowLes 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 RulesetsUne 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
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
2.1.3.4. Rulesets
2.1.3.4.1. Optimisation des rulesets
2.1.3.4.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.3.4.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 "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 variablesCes 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 :![]()
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.![]()
la partie "Direction" : indique le sens du flux.
![]()
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.
2.1.3.4.3.1. Règle secrète locale
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 :
2.1.3.5.1. Detection Rulesets
`Detection Rulesets`
permet l'application des Rulesets au Gcap appairé au GCenter.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
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
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)
2.1.3.5.2. Base variables
La partie variables de base est composée de :
2.1.3.5.2.1. Stream analysis and file extraction
2.1.3.5.2.2. 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
2.1.3.5.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.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
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.
2.1.3.5.3. Net variables
2.1.3.5.4. Flow timeouts
2.1.3.5.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 (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
2.1.3.5.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.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 UIPour 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,
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
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"
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.
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... |
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 (objet alert.metadata dans ES):
|
|
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.