1. Présentation

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, qui peuvent provenir de différentes sources, 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. Gatewatcher propose un ensemble de règles qui peut être téléchargé depuis sa plateforme de mise à jour. Les paragraphes suivants détaillent les manipulations nécessaires pour fournir ces règles au module SIGFLOW du GCAP à travers le GCENTER.

Les étapes de base de configuration sont les suivantes :

2. GCAP Profiles

Menu : Operators > Sigflow > GCap Profiles

Depuis cette interface de configuration, les utilisateurs pourront appliquer une politique de règles spécifiques et personnaliser les paramètres depuis les catégories suivantes :

Afin que le moteur de détection puisse démarrer sur la sonde GCap, l'utilisateur doit d'abord y appliquer un ruleset. Voir la section Sigflow/Rulesets concernant la création d'un ruleset".

2.1. Detection Rulesets

Menu : Operators > Sigflow > GCAP Profiles

La section Detection Rulesets permet l'application des Rulesets SIGFLOW précédemment créés aux GCAP appairés sur le GCENTER. Il est également possible de configurer le module codebreaker pour le GCAP qui comprend l'activation ou la désactivation de la détection des shellcodes et des powershells de façon séparés.

Note

Il est nécessaire de générer les règles d'un ruleset avant de l'appliquer aux GCAPs. Dans le cas contraire, aucune règle ne sera appliquée.

Note

Codebreaker n'est pas configurable via le menu Detection Rulesets avec la licence CIE.

Le menu Detection Rulesets du GCAP permet 3 options de configuration:

  • Le single tenant:

    • Attribuer un ruleset pour toutes les interfaces de monitoring du GCAP,

    • Activer/désactiver codebreaker pour toutes les interfaces de monitoring du GCAP.

  • Le multi-tenant by interface:

    • Attribuer un ruleset par interface de monitoring du GCAP,

    • Activer/désactiver codebreaker par interface de monitoring du GCAP.

  • Le multi-tenant by vlan:

    • 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 codebreaker par vlan,

    • Activer/désactiver codebreaker pour le vlan par défaut (les vlans non créés via l'interface).

Note

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

2.1.1. Single-tenant

Note

Les modifications de cet onglet nécessitent la sauvegarde et l'application de la configuration du GCAP via le bouton save puis apply.

Configuration du single-tenant:

  1. Se rendre dans l'onglet Single-tenant,

  2. Sélectionner un ruleset à appliquer pour toutes les interfaces,

  3. Activer ou désactiver la détection des shellcodes pour toutes les interfaces,

  4. Activer ou désactiver la détection des powershells pour toutes les interfaces,

  5. Appliquer la configuration via le bouton "save".

2.1.2. Multi-tenant by interface

Le multi-tenant by interface permet d'appliquer une configuration single-tenant 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 SIGFLOW différent ainsi que de configurer codebreaker pour chacune des interfaces du GCAP.

Note

Une optimisation des règles SIGFLOW au préalable est conseillée avant de choisir cette option de configuration. Les règles doivent en effet être adaptées à l'environnement monitoré.

Note

Il est nécessaire de vérifier que plusieurs interfaces de monitoring sont activées sur le GCAP avant d'appliquer une configuration multi-tenant by interface.

Note

Les modifications de cet onglet nécessitent la sauvegarde et l'application de la configuration du GCAP via le bouton save puis apply.

Note

Seuls les interfaces de monitoring activées apparaissent dans l'interface du GCENTER.

Configuration du multi-tenant by interface:

  1. Se rendre dans l'onglet Multi-tenant by interface,

  2. Sélectionner un ruleset à appliquer pour chaque interface,

  3. Activer ou désactiver la détection des shellcodes pour chaque interface,

  4. Activer ou désactiver la détection des powershells pour chaque interface,

  5. Appliquer la configuration via le bouton "save".

Exemple de configurations:

  • interface mon0:

    • Ruletset nommé "Test-mon0",

    • Activation de la detection des shellcodes/powershells. Mon0

  • interface mon2:

    • Ruletset nommé "Test-mon2",

    • Désactivation de la détection des shellcodes/powershells. Mon2

2.1.3. Multi-tenant by vlan

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 SIGFLOW 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 SIGFLOW et de configurer codebreaker pour l'ensemble des vlans qui ne sont pas explicitement déclarés dans l'interface.

Note

Une optimisation des règles SIGFLOW au préalable est conseillée avant de choisir cette option de configuration. Les règles doivent en effet être adaptées à l'environnement monitoré.

Note

Les modifications de cet onglet nécessitent la sauvegarde et l'application de la configuration du GCAP via le bouton save puis apply.

Configuration du multi-tenant by vlan:

  1. Se rendre dans l'onglet Multi-tenant by vlan,

  2. Sélectionner un ruleset à appliquer pour le vlan "default",

  3. Activer ou désactiver la détection des shellcodes pour le vlan "default",

  4. Activer ou désactiver la détection des powershells pour le vlan "default",

  5. Créer autant de vlan que nécessaire via le bouton "Add",

  6. Le nom du vlan doit correspondre au numéro de vlan entre 0 et 4096,

  7. Sélectionner ensuite un ruleset à appliquer pour chaque vlan,

  8. Activer ou désactiver la détection des shellcodes pour chaque vlan,

  9. Activer ou désactiver la détection des powershells pour chaque vlan,

  10. Appliquer la configuration via le bouton "save".

Exemple de configurations:

  • vlan "default":

    • Ruletset nommé "Test-default",

    • Activation de la détection des shellcodes/powershells. default

  • vlan "110":

    • Ruletset nommé "Test-vlan110",

    • Désactivation de la detection des shellcodes/powershells. vlan110

2.2. Base variables

Menu : Operators > Sigflow > GCAP Profiles

La section Base variables va permettre à l'opérateur d'ajuster les paramètres de capture de la sonde grâce aux fonctions avancées de Suricata configurable depuis GCENTER. Les modifications de cette configuration entrainent 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).

Le menu se découpe en trois sections:

  • General

  • Stream

  • Parsing

2.2.1. Base Variables - General

L'onglet Base Variables - General permet la configuration des paramètres avancés de la sonde GCAP (Suricata).

Note

Les modifications de cet onglet nécessitent la sauvegarde et l'application de la configuration du GCAP via le bouton save puis apply.

Les valeurs par défaut des variables de l'onglet général:

Variables Valeurs
file_resend_interval 86400s
files_hash ['md5']
flow_memcap 17179869184 Bytes
flow_prealloc 1048576
ftp_memcap 10485760 Bytes
http_body Désactivé
http_body_printable Désactivé
max_pending_packets 4096
packet Activé
payload Activé
payload_buffer_size 4096 Bytes
payload_printable Activé
smb_stream_depth 10485760 Bytes
xff_deployment reverse
xff_enable Activé
xff_header X-Forwarded-For
xff_mode extra-data

Liste des variables de l'onglet General:

  • File resend interval (seconds): intervalle de temps (en seconde) où, si un fichier identique est vu sur le réseau, il ne sera pas de nouveau envoyé vers le GCENTER par le GCAP. Seules les métadonnées le seront avec le champ Replica à True. Au-delà de ce délai, si le même fichier est vu sur le réseau, il sera de nouveau envoyé vers le GCENTER.

  • Max pending packets: Nombre de paquets simultanés que le moteur SURICATA peut gérer. Cela peut aller d'un paquet à des dizaines de milliers de paquets. Ce paramètre jouera sur les performances et sur l'utilisation de la mémoire (RAM). Un nombre élevé de paquets en cours de traitement permet d'obtenir de meilleures performances et d'utiliser plus de mémoire, et inversement. Choisir un faible nombre de paquets en cours de traitement tout en ayant plusieurs cœurs de CPU, peut avoir pour conséquence de ne pas utiliser la totalité de la capacité de la sonde (Exemple : utiliser un seul core tout en ayant 3 paquets en attente de traitement).

  • Enable XFF: Activation de la gestion de l'entête HTTP X-Forwarded-For en ajoutant un nouveau champ ou en écrasant l'adresse ip source ou destination (suivant le sens du flux) par l'ip renseignée dans cet entête. Le comportement (ajout de champ ou écrasement) est géré par la directive XFF mode. Cette directive est utile dans le cas de traitement de flux derrière un reverse proxy par exemple.

  • XFF mode: Comportement attendu lors de l'activation de XFF. Deux types de modes de fonctionnement sont disponibles extra-data ou overwrite. A noter qu'en mode 'overwrite', si l'adresse IP rapportée dans l'entête HTTP X-Forwarded-For est d'une version différente du paquet reçu, alors elle passera en mode 'extra-data'.

  • XFF deployment: Type de déploiement de XFF. Deux types de déploiement sont disponibles : reverse ou forward. Dans un déploiement reverse, l'adresse IP utilisée est la dernière, alors que dans un déploiement forward, l'adresse IP utilisée est alors la première.

  • Xff header: C'est le nom de l'entête HTTP où l'adresse IP réelle est présente. Si plus d'une adresse IP est présente, la dernière adresse IP sera celle prise en compte.

  • Payload: Ajoute un champ contenant la charge utile encodée en base 64 d'un flux déclenchant une alerte.

  • Payload buffer size: taille maximale de la mémoire tampon de la charge utile à ajouter dans l'alerte.

  • Payload printable: Ajoute un champ contenant la charge utile (Payload) au format ASCII (dit 'humain').

  • Packet: dump du paquet capturé encodé en base64.

  • HTTP body: Ajoute un champ contenant le body des requêtes HTTP encoder en base64. Pour fonctionner, ce paramètre nécessite des métadonnées.

  • HTTP body printable: Ajoute un champ contenant le body des requêtes HTTP au format ASCII (dit "humain"). Pour fonctionner, ce paramètre nécessite des métadonnées.

  • Flow memcap: allocation maximale pour les flux en octet.

  • Flow prealloc: allocation initiale du flux.

  • FTP memcap (B) : 'allocation maximale pour les flux.

  • SMB Stream Depth (B): La taille des fichiers qui peuvent être restaurés et stockés dépend de la valeur en mégaoctets. Au-delà de cette valeur, aucune reconstruction ne sera effectuée. Si cette valeur est atteinte, le fichier peut être tronqué et peut ne pas être stocké complètement. Cela signifie qu'après cette valeur, la session SMB ne sera plus suivie. De plus, les valeurs négatives désactivent l'option. Le réglage à 0 de cette valeur permet de stocker n'importe quelle taille de fichier.

  • Files hash: Permet de faire le choix de la fonction de hachage pour les fichiers reconstruit (md5, sha1 et sha256). Par défaut, md5 est sélectionné. Le hash sha256 sera dans tous les cas ajouté par le module Malcore.

2.2.2. Base Variables - Stream

 caution:: La modification des paramètres de cette section peut causer des dysfonctionnements de la solution TRACKWATCH. Cette partie est réservée au support et aux utilisateurs avancés.
Seule la variable "file_store_stream_depth_mb" peut être modifiée, sans jamais dépasser 100 MB.

L'onglet Base Variables - Stream permet la configuration des paramètres de reconstruction des fichiers ainsi que du module Stream-engine de la sonde GCAP (Suricata). Le module Stream-engine de la sonde permet le suivi des connexions TCP.

Note

Les modifications de cet onglet nécessitent la sauvegarde et l'application de la configuration du GCAP via le bouton save puis apply.

Le moteur est composé de deux parties:

  • Stream-tracking engine: Permet de suivre l'état des connexions TCP,

  • Reassembly-engine: Reconstruit le flux afin qu'il soit analysé par Suricata.

Les valeurs par défaut des variables de l'onglet stream:

Variables Valeurs
file_store_stream_depth_enable Activé
file_store_stream_depth_mb 10 MegaBytes
stream_memcap_b 32000000000 Bytes
stream_prealloc_sessions 1000000
stream_reassembly_depth_mb 10 MegaBytes
stream_reassembly_memcap_b 16000000000 Bytes
stream_reassembly_randomize_chunk_size Activé
stream_reassembly_toclient_chunk_size_b 2560 Bytes
stream_reassembly_toserver_chunk_size_b 2560 Bytes

Liste des variables de l'onglet Stream:

  • Enable File-Store stream depth: Permet d'activer le contrôle de la taille des fichiers stockés.

  • File-store stream depth (Mb): Fixe la taille maximum des fichiers qui peuvent être restaurés et stockés en mégaoctets. Si cette valeur est atteinte, le fichier peut être tronqué et peut ne pas être stocké complètement. Cela signifie qu'après cette valeur, la session HTTP ne sera plus suivie. Une valeur négative désactive l'option et la valeur 0 permet de stocker n'importe quelle taille de fichier. Si cette option n'est pas activée, alors la valeur de 'Stream reassembly depth (Mb)' sera prise en compte.

  • Stream memcap (B): Cette valeur est la valeur maximale en octets allouée au suivi des sessions TCP. Afin d'éviter un manque de ressources, un memcap peut être utilisé pour limiter la mémoire utilisée.

  • Stream Prealloc sessions: C'est la quantité de sessions que le moteur SURICATA doit garder disponible en mémoire. Ce moteur fonctionne indépendamment du traitement des paquets et possède un 'thread' de gestion assurant le paramétrage de cette valeur à l'intérieur du memcap afin d'allouer de la mémoire. L'option permet d'éviter à SURICATA d'être surchargé par la création rapide de sessions et lui demande de garder un certain nombre de sessions prêtes en mémoire. Il spécifie le nombre d'éléments à pré-allouer au démarrage du logiciel. Ceci diminue le coût des allocations en cours de fonctionnement aux dépens de l'utilisation mémoire initiale du logiciel.

  • Stream reassembly memcap (B) Le moteur de reconstitution de flux doit conserver des segments de données en mémoire afin de pouvoir le reconstruire. Pour éviter le manque de ressources, un memcap est utilisé pour limiter la mémoire utilisée. Cette option est la quantité maximale d'octets que le moteur de flux peut utiliser pour restaurer un fichier.

  • Enable the randomizable of chunks size: Le but de ce paramètre est d'éviter de rendre la reconstitution de morceaux trop prévisible. Pour cela, leur taille sera modifiée par un facteur aléatoire qui sera ajouté.

  • Stream reassembly depth (Mb) C'est la taille du flux réseau en mégaoctets. Le fait de reconstruire un flux de données est une opération très importante qui pourra se contrôler avec la notion de 'depth'. La valeur par défaut est un paramètre qui peut être remplacé par les analyseurs de protocoles qui effectuent l'extraction des fichiers. L'inspection sera ignorée si cette valeur est atteinte pour un débit en particulier. Le réglage à 0 de cette valeur permet de stocker n'importe quelle taille de flux.

  • Stream reassembly to server chunk size (B) La reconstruction d'un flux de données se fait par morceaux. La taille de ces morceaux est à définir au niveau de ce champ pour que le flux soit inspecté et reconstruit à partir de cette valeur.

  • Stream reassembly to client chunk size (B) La reconstruction d'un flux de données se fait par morceaux. La taille de ces morceaux est à définir au niveau de ce champ pour que le flux soit inspecté et reconstruit en fonction de celle-ci.

2.2.3. Base Variables - Parsing

L'onglet Base Variables - Parsing permet la configuration du parsing et du logging des protocoles utilisés par la sonde GCAP. Les protocoles pouvant être analysés et journalisés sont présent dans l'interface GCenter. Dans le cas où une sonde GCAP a une version d'avance sur le GCenter, il est possible que certains protocoles aient été ajoutés.

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 parsing et logging:

  • La parsing 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 SIGFLOW dans le dashboard Kibana.

  • La 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 lèvera une alerte pour ce protocole dans le dashboard Kibana.

Note

La configuration par défaut des protocoles varie en fonction du profil du GCAP utilisé.

Note

Les modifications de cet onglet nécessitent la sauvegarde et l'application de la configuration du GCAP via le bouton save puis apply.

Voici la liste des protocoles configurables avec l'option parsing:

  • dcerpc

  • dnp3

  • dns_udp

  • dns_tcp

  • ftp

  • http

  • modbus

  • smb

  • smtp

  • ssh

  • tls

  • dhcp

  • ikev2

  • krb5

  • nfs

  • ntp

  • tftp

Voici la liste des protocoles configurables avec l'option logging:

  • http

  • dns_udp

  • dns_tcp

  • tls

  • smtp

  • smb

  • ssh

  • netflow

  • dnp3

  • ftp

  • dhcp

  • ikev2

  • krb5

  • nfs

  • tftp

Voici la configuration par défaut de l'option parsing pour chaque protocole en fonction du profil utilisé:

Protocoles Minimal Balanced LPM Paranoid Intuitio
dcerpc Disabled Disabled Disabled Enabled Disabled
dnp3 Disabled Disabled Disabled Enabled Disabled
dns_udp Disabled Enabled Enabled Enabled Enabled
dns_tcp Disabled Enabled Enabled Enabled Enabled
ftp Disabled Enabled Enabled Enabled Enabled
http Enabled Enabled Enabled Enabled Enabled
modbus Disabled Disabled Disabled Enabled Disabled
smb Disabled Enabled Disabled Enabled Enabled
smtp Enabled Enabled Enabled Enabled Enabled
ssh Disabled Enabled Disabled Enabled Enabled
tls Disabled Enabled Enabled Enabled Enabled
dhcp Disabled Enabled Disabled Enabled Enabled
ikev2 Disabled Disabled Disabled Enabled Disabled
krb5 Disabled Enabled Disabled Enabled Enabled
nfs Disabled Enabled Disabled Enabled Enabled
ntp Disabled Enabled Disabled Enabled Disabled
tftp Disabled Enabled Disabled Enabled Enabled

Voici la configuration par défaut de l'option logging pour chaque protocole en fonction du profil utilisé:

Protocoles Minimal Balanced LPM Paranoid Intuitio
http Disabled Enabled Enabled Enabled Enabled
dns_udp Disabled Enabled Enabled Enabled Enabled
dns_tcp Disabled Enabled Enabled Enabled Enabled
tls Disabled Enabled Enabled Enabled Enabled
smtp Disabled Enabled Enabled Enabled Enabled
smb Disabled Enabled Disabled Enabled Enabled
ssh Disabled Enabled Disabled Enabled Enabled
netflow Disabled Disabled Disabled Enabled Disabled
dnp3 Disabled Disabled Disabled Enabled Disabled
ftp Disabled Enabled Enabled Enabled Enabled
dhcp Disabled Enabled Disabled Enabled Enabled
ikev2 Disabled Disabled Disabled Enabled Disabled
krb5 Disabled Enabled Disabled Enabled Enabled
nfs Disabled Enabled Disabled Enabled Enabled
tftp Disabled Enabled Disabled Enabled Enabled

En plus de ces protocoles, il est également possible de générer des données NetFlow.

Avertissement

L'activation de la génération de données NetFlow va créer beaucoup de meta-données

2.3. Net variables

Menu : Operators > Sigflow > GCAP Profiles

La section Net variables va permettre à l'opérateur de définir les variables réseaux utilisées dans les règles sigflow.

Note

Les modifications de cette section nécessitent la sauvegarde et l'application de la configuration du GCAP via le bouton save puis apply.

Au niveau de la structure d'une règle SIGFLOW, juste après 'alert' et le mot clé indiquant le protocole, il est possible d'utiliser des variables qui vont permettre de définir des groupes d'adresses IP.

Dans l'exemple suivant :

 
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:”GPL SCAN NULL”; flow:stateless; ack:0; \
flags:0; seq:0; reference:arachnids,4; classtype:attempted-recon; sid:2100623; rev:7;)

Ces flux doivent aller de \(HOME_NET vers \)EXTERNAL_NET.

La première partie \(HOME_NET est la source, la seconde \)EXTERNAL_NET est la destination. Avec la source et la destination, vous spécifiez la source du trafic et la destination du trafic, respectivement. Vous pouvez attribuer des adresses IP (IPv4 et IPv6 sont pris en charge) et des plages IP. Ces paramètres seront utilisés à la place des variables dans les règles de détection.

Cette section permet de définir le contenu de ces variables.

Pour appliquer ces modifications, il sera nécessaire de cliquer sur le bouton Save and Apply.

La règle s'adapte aux besoins et peut changer en fonction du paramètre sélectionné au niveau du menu déroulant de chaque environnement. 'list', 'default (equals to HOME_NET)' et 'exclude (opposite of HOME_NET)' permettent respectivement de définir l'action de la règle par rapport à un groupe d'adresse, par rapport aux adresses renseignées dans l'environnement HOME_NET ou par rapport à toutes les adresses ne faisant pas partie de l'environnement HOME_NET.

Il n'est pas nécessaire de définir une adresse pour chacune des variables existantes. Par défaut, quand rien n'est renseigné, cela équivaut à appliquer la règle sur tout le trafic.

La configuration utilisée par défaut:

Variables Valeurs
home_net []
external_net []
http_servers default
smtp_servers default
sql_servers default
dns_servers default
telnet_servers default
aim_servers default
dnp3_servers default
dnp3_clients default
modbus_servers default
modbus_clients default
enip_servers default
enip_clients default
dnp3_server default
dnp3_client default
modbus_server default
modbus_client default
enip_server default
enip_client default

2.4. Flow timeouts

Menu : Operators > Sigflow > GCAP Profiles

 caution:: La modification des paramètres de cette section peut causer des dysfonctionnements de la solution TRACKWATCH. Cette partie est réservée au support et aux utilisateurs avancés.

La section Flow timeouts va permettre de configurer le temps (en secondes) pendant lequel Suricata garde un flux en mémoire en fonction de son état. Les protocoles udp, tcp, icmp sont configurables.

Note

Les modifications de cette section nécessitent la sauvegarde et l'application de la configuration du GCAP via le bouton save puis apply.

La configuration utilisée par défaut en fonction du protocole (toutes les valeurs sont en secondes):

protocol new established closed emergency_new emergency_established emergency_closed
udp 30 300 - 10 100 -
tcp 30 300 0 10 100 0
icmp 30 300 - 10 100 -
default 30 300 - 10 100 -

Pour chaque protocole, il existe différents états dans lesquels un flux peut se trouver:

  • Protocole TCP:

    • New: La période pendant laquelle l'établissement de la connexion se fait. Ce champ est le temps écoulé en secondes après la dernière activité de ce flux dans ce type d'état.

    • Established: La période pendant lequel le transfert des données se fait. Ce champ est le temps écoulé en secondes après la dernière activité de ce flux dans ce type d'état.

    • Closed: La période pendant laquelle la fin de la connexion se fait. Ce champ est le temps écoulé en secondes après la dernière activité de ce flux dans ce type d'état.

  • Protocoles UDP et ICMP:

    • New: L'état pendant lequel les paquets sont envoyés depuis une seule direction. Ce champ est le temps écoulé en secondes après la dernière activité de ce flux dans ce type d'état.

    • Established: L'état pendant lequel les paquets sont envoyés dans les deux sens. Ce champ est le temps écoulé en secondes après la dernière activité de ce flux dans ce type d'état.

Les modes 'Emergency_new', 'Emergency_established' et 'Emergency_closed' sont les modes d'urgence des 3 états des protocoles TCP, UDP et ICMP.

2.5. Files rules management

Menu : Operators > Sigflow > GCAP Profiles

La section Files rules management va permettre de configurer les types de fichier que la sonde va extraire pour un protocole donné. Les protocoles compatibles sont: HTTP, SMTP, SMB, NFS, FTP. Les fichiers sont extraits 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... L'extraction de fichiers fonctionne en parallèle des signatures SIGFLOW définies pour ces mêmes protocoles. Chaque ligne de la section Files rules management correspond à une règle d'extraction d'un type de fichier.

Note

Un trop grand nombre de règles d'extraction de fichiers peut avoir un impact significatif sur les performances de la sonde.

Note

Les modifications de cette section nécessitent la sauvegarde et l'application de la configuration du GCAP via le bouton save puis apply.

Voici la liste des champs configurables pour une entrée de la section Files rules management:

  • Protocole: Permet de sélectionner le protocole pour lequel le fichier sera extrait parmi: HTTP, SMTP, SMB, NFS, FTP.

  • Type: Permet de définir la façon dont suricata va reconnaitre le fichier:

    • extension: Correspond à l'extension du fichier.

    • filemagic: Correspond au type du fichier extrait. La commande file sous linux permet d'obtenir cette information:

shell
xxx@debian:~$ file ~/Téléchargements/xxx.exe 
/home/xxx/Téléchargements/xxx.exe: PE32 executable (console) Intel 80386, for MS Windows
  • Value: L'identifiant du fichier qui sera reconstruit en fonction du type configuré précédemment:

    • Type extension:

      • Fichier javascript: js,

      • Fichier executable windows: exe.

    • Type filemagic:

      • Fichier javascript: Javascript,

      • Fichier executable windows: PE32 executable.

  • Enable et Delete sont respectivement les cases à cocher pour activer et supprimer la règle d'extraction des fichiers.

Les règles utilisés en fonction du profil GCAP utilisé:

Protocoles Valeurs Minimal Balanced LPM Paranoid Intuitio
http Microsoft Excel Désactivé Activé Activé Activé Activé
http Microsoft Word Désactivé Activé Activé Activé Activé
http Microsoft PowerPoint Désactivé Activé Activé Activé Activé
http Composite Document File V2 Désactivé Activé Activé Activé Activé
http Microsoft Office Document Désactivé Activé Activé Activé Activé
http Microsoft OOXML Désactivé Activé Activé Activé Activé
http 7-zip archive data Désactivé Activé Activé Activé Activé
http PDF document Désactivé Activé Activé Activé Activé
http ELF Désactivé Activé Activé Activé Activé
http Microsoft Cabinet archive data Désactivé Activé Activé Activé Activé
http PE32 executable (DLL) Désactivé Activé Activé Activé Activé
http PE32 executable Désactivé Activé Activé Activé Activé
http gzip compressed data Désactivé Activé Activé Activé Activé
http RAR archive data Désactivé Activé Activé Activé Activé
http Zip archive data Désactivé Activé Activé Activé Activé
http POSIX tar archive Désactivé Activé Activé Activé Activé
http DOS batch Désactivé Activé Activé Activé Activé
http MS-DOS executable Désactivé Activé Activé Activé Activé
http Java archive data Désactivé Activé Activé Activé Activé
http Macromedia Flash Désactivé Activé Activé Activé Activé
http OS/2 REXX batch file Désactivé Activé Activé Activé Activé
http COM executable Désactivé Activé Activé Activé Activé
http Node.js script text Désactivé Activé Activé Activé Activé
http MS Windows shortcut Désactivé Activé Activé Activé Activé
http PE32+ executable Désactivé Activé Activé Activé Activé
http OpenDocument Désactivé Activé Activé Activé Activé
http Mach-O Désactivé Activé Activé Activé Activé
http Javascript Désactivé Activé Désactivé Activé Activé
smtp Microsoft Excel Désactivé Activé Activé Activé Activé
smtp Microsoft Word Désactivé Activé Activé Activé Activé
smtp Microsoft PowerPoint Désactivé Activé Activé Activé Activé
smtp Composite Document File V2 Désactivé Activé Activé Activé Activé
smtp Microsoft Office Document Désactivé Activé Activé Activé Activé
smtp Microsoft OOXML Désactivé Activé Activé Activé Activé
smtp 7-zip archive data Désactivé Activé Activé Activé Activé
smtp PDF document Désactivé Activé Activé Activé Activé
smtp ELF Désactivé Activé Activé Activé Activé
smtp Microsoft Cabinet archive data Désactivé Activé Activé Activé Activé
smtp PE32 executable (DLL) Désactivé Activé Activé Activé Activé
smtp PE32 executable Désactivé Activé Activé Activé Activé
smtp gzip compressed data Désactivé Activé Activé Activé Activé
smtp RAR archive data Désactivé Activé Activé Activé Activé
smtp Zip archive data Désactivé Activé Activé Activé Activé
smtp POSIX tar archive Désactivé Activé Activé Activé Activé
smtp DOS batch Désactivé Activé Activé Activé Activé
smtp MS-DOS executable Désactivé Activé Activé Activé Activé
smtp Java archive data Désactivé Activé Activé Activé Activé
smtp Macromedia Flash Désactivé Activé Activé Activé Activé
smtp OS/2 REXX batch file Désactivé Activé Activé Activé Activé
smtp COM executable Désactivé Activé Activé Activé Activé
smtp Node.js script text Désactivé Activé Activé Activé Activé
smtp MS Windows shortcut Désactivé Activé Activé Activé Activé
smtp PE32+ executable Désactivé Activé Activé Activé Activé
smtp OpenDocument Désactivé Activé Activé Activé Activé
smtp Mach-O Désactivé Activé Activé Activé Activé
smtp Javascript Désactivé Activé Désactivé Activé Activé
ftp Microsoft Excel Désactivé Activé Activé Activé Activé
ftp Microsoft Word Désactivé Activé Activé Activé Activé
ftp Microsoft PowerPoint Désactivé Activé Activé Activé Activé
ftp Composite Document File V2 Désactivé Activé Activé Activé Activé
ftp Microsoft Office Document Désactivé Activé Activé Activé Activé
ftp Microsoft OOXML Désactivé Activé Activé Activé Activé
ftp 7-zip archive data Désactivé Activé Activé Activé Activé
ftp PDF document Désactivé Activé Activé Activé Activé
ftp ELF Désactivé Activé Activé Activé Activé
ftp Microsoft Cabinet archive data Désactivé Activé Activé Activé Activé
ftp PE32 executable (DLL) Désactivé Activé Activé Activé Activé
ftp PE32 executable Désactivé Activé Activé Activé Activé
ftp gzip compressed data Désactivé Activé Activé Activé Activé
ftp RAR archive data Désactivé Activé Activé Activé Activé
ftp Zip archive data Désactivé Activé Activé Activé Activé
ftp POSIX tar archive Désactivé Activé Activé Activé Activé
ftp DOS batch Désactivé Activé Activé Activé Activé
ftp MS-DOS executable Désactivé Activé Activé Activé Activé
ftp Java archive data Désactivé Activé Activé Activé Activé
ftp Macromedia Flash Désactivé Activé Activé Activé Activé
ftp OS/2 REXX batch file Désactivé Activé Activé Activé Activé
ftp COM executable Désactivé Activé Activé Activé Activé
ftp Node.js script text Désactivé Activé Activé Activé Activé
ftp MS Windows shortcut Désactivé Activé Activé Activé Activé
ftp PE32+ executable Désactivé Activé Activé Activé Activé
ftp OpenDocument Désactivé Activé Activé Activé Activé
ftp Mach-O Désactivé Activé Activé Activé Activé
ftp Javascript Désactivé Activé Désactivé Activé Activé
nfs Microsoft Excel Désactivé Désactivé Désactivé Activé Activé
nfs Microsoft Word Désactivé Désactivé Désactivé Activé Activé
nfs Microsoft PowerPoint Désactivé Désactivé Désactivé Activé Activé
nfs Composite Document File V2 Désactivé Désactivé Désactivé Activé Activé
nfs Microsoft Office Document Désactivé Désactivé Désactivé Activé Activé
nfs Microsoft OOXML Désactivé Désactivé Désactivé Activé Activé
nfs 7-zip archive data Désactivé Désactivé Désactivé Activé Activé
nfs PDF document Désactivé Désactivé Désactivé Activé Activé
nfs ELF Désactivé Désactivé Désactivé Activé Activé
nfs Microsoft Cabinet archive data Désactivé Désactivé Désactivé Activé Activé
nfs PE32 executable (DLL) Désactivé Désactivé Désactivé Activé Activé
nfs PE32 executable Désactivé Désactivé Désactivé Activé Activé
nfs gzip compressed data Désactivé Désactivé Désactivé Activé Activé
nfs RAR archive data Désactivé Désactivé Désactivé Activé Activé
nfs Zip archive data Désactivé Désactivé Désactivé Activé Activé
nfs POSIX tar archive Désactivé Désactivé Désactivé Activé Activé
nfs DOS batch Désactivé Désactivé Désactivé Activé Activé
nfs MS-DOS executable Désactivé Désactivé Désactivé Activé Activé
nfs Java archive data Désactivé Désactivé Désactivé Activé Activé
nfs Macromedia Flash Désactivé Désactivé Désactivé Activé Activé
nfs OS/2 REXX batch file Désactivé Désactivé Désactivé Activé Activé
nfs COM executable Désactivé Désactivé Désactivé Activé Activé
nfs Node.js script text Désactivé Désactivé Désactivé Activé Activé
nfs MS Windows shortcut Désactivé Désactivé Désactivé Activé Activé
nfs PE32+ executable Désactivé Désactivé Désactivé Activé Activé
nfs OpenDocument Désactivé Désactivé Désactivé Activé Activé
nfs Mach-O Désactivé Désactivé Désactivé Activé Activé
nfs Javascript Désactivé Désactivé Désactivé Activé Activé
smb Microsoft Excel Désactivé Désactivé Désactivé Activé Activé
smb Microsoft Word Désactivé Désactivé Désactivé Activé Activé
smb Microsoft PowerPoint Désactivé Désactivé Désactivé Activé Activé
smb Composite Document File V2 Désactivé Désactivé Désactivé Activé Activé
smb Microsoft Office Document Désactivé Désactivé Désactivé Activé Activé
smb Microsoft OOXML Désactivé Désactivé Désactivé Activé Activé
smb 7-zip archive data Désactivé Désactivé Désactivé Activé Activé
smb PDF document Désactivé Désactivé Désactivé Activé Activé
smb ELF Désactivé Désactivé Désactivé Activé Activé
smb Microsoft Cabinet archive data Désactivé Désactivé Désactivé Activé Activé
smb PE32 executable (DLL) Désactivé Désactivé Désactivé Activé Activé
smb PE32 executable Désactivé Désactivé Désactivé Activé Activé
smb gzip compressed data Désactivé Désactivé Désactivé Activé Activé
smb RAR archive data Désactivé Désactivé Désactivé Activé Activé
smb Zip archive data Désactivé Désactivé Désactivé Activé Activé
smb POSIX tar archive Désactivé Désactivé Désactivé Activé Activé
smb DOS batch Désactivé Désactivé Désactivé Activé Activé
smb MS-DOS executable Désactivé Désactivé Désactivé Activé Activé
smb Java archive data Désactivé Désactivé Désactivé Activé Activé
smb Macromedia Flash Désactivé Désactivé Désactivé Activé Activé
smb OS/2 REXX batch file Désactivé Désactivé Désactivé Activé Activé
smb COM executable Désactivé Désactivé Désactivé Activé Activé
smb Node.js script text Désactivé Désactivé Désactivé Activé Activé
smb MS Windows shortcut Désactivé Désactivé Désactivé Activé Activé
smb PE32+ executable Désactivé Désactivé Désactivé Activé Activé
smb OpenDocument Désactivé Désactivé Désactivé Activé Activé
smb Mach-O Désactivé Désactivé Désactivé Activé Activé
smb Javascript Désactivé Désactivé Désactivé Activé Activé

2.6. Packet filtering

Menu : Operators > Sigflow > GCAP Profiles

Packet filtering va permettre à l'opérateur d'ajuster les paramètres de capture de la sonde de détection grâce aux fonctions avancées de Sigflow.

Le but de cette fonctionnalité est d'agir directement sur le périphérique de capture de la solution TRACKWATCH en modifiant la méthode d'acquisition des paquets grâce à BPF (Barkeley Packet Filter). Le trafic sera donc ignoré pour un identifiant de VLAN donné dans le champ 'Dropped VLAN Id'.

Le numéro de VLAN par défaut est à renseigner sur l'interface Web du GCENTER dans 'Default VLAN'. Par défaut, la valeur est à 1. Une fois le VLAN renseigné, une fenêtre apparait pour que l'opérateur puisse rajouter les informations réseaux sur le trafic qu'il souhaite vouloir faire disparaitre de ses notifications.

L'opérateur peut supprimer une règle de filtrage via la case Delete. Les modifications sont sauvegardées lors de la validation du formulaire en cliquant sur le bouton Save. Cependant afin de les appliquer il sera nécessaire de cliquer sur le bouton Save and Apply sur la page de configuration.

3. Gestion des règles

Les signatures du moteur Sigflow sont organisées de la manière suivantes :

  • Une liste de source mettant à disposition des signatures

  • 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 leur sources et un GCAP

3.1. Sources

Menu : Operators > Sigflow > Sources

Les sources permettent de déclarer des endroits 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.

Une fois les règles ajoutées, l'opérateur peut directement affecter cette source à différents Rulesets

La visualisation d'une règle custom se fait depuis l'onglet 'View' dans Add custom source:

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 mise à jour des signatures et la vérification de l'historique des changements sont possibles :

3.2. Rulesets

Menu : Operators > Sigflow > Rulesets

Dans un second temps il va falloir attribuer un 'Ruleset' associé à la source ajoutée précédemment. La création du Ruleset est obligatoire pour que la sonde GCAP puisse analyser le flux réseau et remonter des alertes si les signatures correspondent.

Des modifications peuvent être effectuées sur les règles afin d'adapter une règle publique à des spécificités de système d'information, ou à un besoin spécifique.

Les modifications suivantes seront appliquées à toutes les catégories du Ruleset

ACTION :

Détermine l'action à appliquer sur le Ruleset créé.

Filestore : Si une règle correspond et contient une signature, le paquet sera traité et stocké comme tout autre paquet.

Reject : S'il s'agit d'un rejet du paquet, Sigflow génère une alerte pour des paquets de réinitialisation (TCP) et des paquets d'erreurs ICMP.

Drop : Si trouve une règle qui correspond contenant la signature, il s'arrête immédiatement. Le paquet ne sera plus envoyé et une alerte sera générée.

Bypass : Si une règle correspond et contient un 'bypass', Sigflow arrête de scanner le paquet et passe à la fin de toutes les règles (uniquement pour le paquet actuel).

LATERAL :

Les signatures sont souvent écrites avec les variables \(EXTERNAL\_NET et \)HOME_NET, ce qui signifie qu'elles ne correspondront pas si les deux côtés d'un flux se trouvent dans le \(HOME\_NET. Ainsi, les mouvements latéraux ne sont pas détectés. Cette transformation change \)EXTERNAL_NET en n'importe quelle variable pour pouvoir détecter les mouvements latéraux.

L'option peut avoir trois valeurs :

Non : le remplacement n'est pas effectué

Oui : $EXTERNAL_NET est remplacé par n'importe quel IP (any)

Auto : la substitution est effectuée si la signature vérifie certaines propriétés

TARGET :

Le mot-clé 'target' peut être utilisé pour dire quel côté d'un flux déclenchant une signature est la cible. Si cette clé est présente, les événements connexes sont améliorés pour contenir la source et la cible de l'attaque.

L'option peut avoir quatre valeurs :

Auto : un algorithme est utilisé pour déterminer la cible s'il y en a une

Destination : la cible est l'IP de destination

Source : la cible est la source IP

Aucune : aucune transformation n'est effectuée

'Add' pour valider l'ajout du ruleset.

3.2.1. Optimisation des rulesets

Comme pour les sources, le Ruleset peut se mettre à jour à n'importe quel moment. Il met de ce fait toutes ses signatures à jour tout en proposant un différentiel des changements opérés :

Un Ruleset peut être édité afin que l'opérateur puisse faire des modifications sur les sources, catégories ou règles présentes dans le Ruleset.

ACTION EDIT SOURCES :

Cette option sert à activer ou désactiver manuellement l'action d'une source sur un Ruleset.

Une fois décochées, les signatures ne seront plus matchées par des flux en particulier et ne remonteront plus d'alerte sur l'interface.

ACTION EDIT CATEGORIES :

Cette option sert à activer ou désactiver manuellement l'action d'une catégorie sur un Ruleset.

Une fois décochées, les signatures ne seront plus matchées par des flux en particulier et ne remonteront plus d'alerte sur l'interface.

Il est possible de désactiver une signature associée à un Ruleset directement depuis l'interface SIGFLOW. La désactivation d'une règle ne provoque pas sa suppression définitive.

L'administrateur peut décider de faire un duplicata du Ruleset afin de l'attribuer à une autre sonde GCAP par exemple en fonction des flux réseau qui transitent. Le Ruleset est spécifique et doit être optimisé en fonction de la sonde à laquelle il sera attribué.

ACTION COPY RULESET :

Cette option sert à dupliquer le Ruleset, la copie prendra en compte les sources associées au Ruleset.

ACTION DELETE RULESET :

La suppression du Ruleset est irréversible mais ne provoquera pas la suppression des sources et signatures qui étaient liées au Ruleset.

D'autres options de visionnage sont disponibles avec l'interface SIGFLOW. La rubrique DISPLAY permet d'avoir la vision des catégories (via Show structure) et celle des règles (via Show rules). De plus grâce à cette rubrique, un export de toute la configuration SIGFLOW est possible en prenant en compte les Ruleset, les sources, les thresholds et les suppress créés.

3.3. Modification de signatures

Les signatures (et leurs catégories) sont le point commun entre une source et un rulesets. Il est possible d'agir directement sur le fonctionnment d'une signature depuis l'interface du GCenter.

On peut accéder aux signatures et à leurs catégories depuis un Ruleset en cliquant sur le bouton View du Ruleset puis la catégorie.

Suivant les alertes qui arrivent au niveau de l'interface, il est possible d'être très précis sur le type ou même le nombre de notifications. La règle peut être activée ou désactivée au sein du Ruleset.

En cliquant sur le lien "Edit Rule" il est possible de générer des règles afin de limiter ou supprimer certaines alertes. Il y a les Suppress Rules, qui suppriment une alerte en fonction d'une IP source ou de destination, ou alors une Threshold Rules qui limite le nombre d'alertes à afficher.

THRESHOLD :

Cette option sert à programmer une limitation des alertes au-delà d'un seuil paramétré.

Pour un threshold, il y a 3 types de règles :

Threshold : Ce type peut être utilisé pour définir un seuil minimum pour une règle avant de générer des alertes. Un réglage de seuil de N signifie qu'à la nième fois que la règle correspond, une alerte est générée.

Limit : Ce type peut être utilisé pour s'assurer que vous ne soyez pas inondé d'alertes. S'il est défini sur N, il alertera au maximum N fois.

Both : Ce type est une combinaison des types "threshold" et "limit". Il applique à la fois le seuillage et la limitation. Cette alerte ne générera N alerte que si, dans les X minutes.

Il est nécessaire ensuite de :

  • Définir si l'alerte se fera en se basant via l'IP source ou de destination

  • Préciser le nombre d'alertes maximums générées pour la période donnée

  • Définir la période en seconde définie pour générer l'alerte

Les règles créées se retrouvent disponibles dans la page du Ruleset avec le format de la nouvelle règle.

SUPPRESS :

Cette option sert à supprimer une alerte par rapport à une adresse IP ou un réseau donné.

Plusieurs IP peuvent être ajoutées en étant séparées par des ' ,'

Après avoir sélectionné Suppress Rules :

  • Choisir le Ruleset qui sera affecté

  • Choisir si la suppression de l'alerte se fera en fonction de la source ou de la destination.

  • Définir l'IP concernée par cette règle. (au format CIDR)

La règle est disponible dans la page du Ruleset en question :

En cliquant sur l'ID de la suppress rule il est possible de l'éditer ou de la supprimer.

3.3.1. Définition des signatures

Toutes les signatures présentes dans les sources CTI ou ETPRO ont des références menant à des blogs, CVE, sites internet… accessibles depuis l'interface. Pour comprendre un peu mieux comment fonctionne une signature, voici un exemple d'une règle :

Dans la plupart des cas, une règle, une signature est composée : d'une action, de l'entête et des options de règle. Par exemple :

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

Dans la signature, vous pouvez attribuer des adresses IP, de type IPv4 et IPv6 combinés ainsi que séparés. Les sources et les destinations de la signature sont impactées.

De plus, il est possible de définir des variables telles que \(HOME\_NET ou \)EXTERNAL_NET auxquelles des IP seront à définir. 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 :

De la même manière, la syntaxe suivante peut être utilisée pour spécifier les ports :

Deux directions peuvent être définies pour indiquer le sens du flux :

3.4. 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.

Une fois la configuration des sources, rulesets et modifications éventuelles réalisées il est nécessaire de générer la configuration pour les sondes et de la déployer. Cette action se fait grâce à l'action « Generate Ruleset » qui figera l'état du Ruleset et prendra en compte toutes les modifications.

3.5. Règle secrète locale

Il est également possible de définir certaines règles localement sur une sonde GCAP qui n'apparaitront volontairement pas dans l'interface GCENTER.

Cela peut se présenter dans les cas suivants :

  • Rendre des signatures confidentielles sans que les opérateurs du GCENTER puissent les voir (notion de 'besoin d'en connaitre')

  • Faire une modification des signatures locales des sondes dans des cas complexes

  • 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 "Moteur de détection > 7. Ajouter des règles secrètes localement".

4. Détection

4.1. SmartMap

Menu : Operators > SmartMap

La SmartMap permet de visualiser en temps réel les attaques et le trafic. Cela permet de manière intuitive et visuelle de détecter le trafic inhabituel ou particulièrement soutenu.

Afin de pouvoir afficher les informations sur la carte, la SmartMap nécessite d'avoir les informations de géolocalisation sur les alertes. Ces dernières devront donc être activées depuis la section configuration par un administrateur.

4.2. Dashboard Kibana

Menu : Operators > Dashboards

Toutes les informations analysées par le module Sigflow sont stockées afin de permettre aux opérateurs d'effectuer une analyse de la manière la plus efficace possible.

Ainsi différents tableaux de bord (ou dashboards) sont mis à disposition par défaut.

Les informations du module Sigflow se retrouvent dans le dashboard Tactical, qui offre une vision globale des menaces, dont celles levées par Sigflow

Des données plus spécifiques à ce module peuvent également être trouvées dans le dashboard Sigflow.

Comme toujours, il possible d'avoir le détail complet des alertes en basculant sur la vue Messages

Les champs présents sont ceux détaillés ci-après dans la section Évènements générés

Enfin, ce module enrichit également le trafic observé avec les meta-données qui ont pu être analysées (suivant la configuration effectuée sur le profil du GCAP)

5. Évènements générés

Pour suricata, et donc Sigflow, les champs produits dépendent du flux observé.

5.1. Document de type "alert"

Liste des champs présents dans toutes les alertes avec event_type == alert:

  • @timestamp

  • @version

  • alert.action

  • alert.category

  • alert.gid

  • alert.rev

  • alert.severity

  • alert.signature

  • alert.signature_id

  • dest_ip

  • event_type

  • flow.bytes_toclient

  • flow.bytes_toserver

  • flow.pkts_toclient

  • flow.pkts_toserver

  • flow.start

  • flow_id

  • gcap

  • GCenter

  • host

  • packet

  • packet_info.linktype

  • payload_printable

  • proto

  • severity

  • src_ip

  • stream

  • timestamp_analyzed

  • timestamp_detected

  • type

  • uuid

Liste des protocoles compatibles avec le parsing (champ app_proto):

  • dcerpc

  • dhcp

  • dnp3

  • dns

  • ftp

  • http

  • ikev2

  • krb5

  • modbus

  • nfs

  • ntp

  • smb,

  • smtp

  • ssh

  • tftp

  • tls

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

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

Champs Requis Mot clé suricata Description
alert.action Oui alert, drop, reject, pass Allowed si l’action alert ou pass est utilisé et blocked si l’action drop ou reject est utilisé.
alert.category Oui classtype Description de la classification de l’alerte.
alert.gid Oui gid Identifiant d’un groupe d’alerte.
alert.metadata Non metadata: key value; Métadonnées de l’alerte. La spécification des champs est libre.
alert.rev Oui rev Numéro de révision de l’alerte.
alert.severity Oui - Niveau de sévérité de l’alerte.
alert.signature Oui msg Description de l’alerte.
alert.signature_id Oui sid Identifiant de l’alerte. Il doit être unique.
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.age Non - Durée du flux.
flow.bytes_toclient Oui - Taille du flux vers le client.
flow.bytes_toserver Oui - Taille du flux vers le serveur.
flow.end Non - Date et heure du dernier paquet vu par suricata.
flow.pkts_toclient Oui - Nombre de paquets vers le client.
flow.pkts_toserver Oui - Nombre de paquets vers le serveur.
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.
flow.state Non - L’état du flux entre (“new”, “established”, “closed”, “bypassed”)
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.
packet Non - Paquet au format base64. Présent seulement si l’option packet du menu « bases variables » du gcap est activée.
payload Non - Payload du paquet au format base64. Présent seulement si l’option payload du menu « bases variables » du gcap est activée.
packet_info.linktype Oui - -
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.
proto Oui - Protocole de couche 4 utilisé.
severity Oui - Niveau de sévérité de l’alerte.
src_ip Oui - Adresse IP de destination.
src_port Non - Port de destination. Présent seulement quand proto vaut udp ou tcp.
stream Oui - -
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.

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;
)

5.2. Document de type "fileinfo"

Liste des champs présents dans toutes les alertes avec event_type == fileinfo:

  • @timestamp

  • @version

  • app_proto

  • dest_ip

  • dest_port

  • event_type

  • fileinfo.filename

  • fileinfo.gaps

  • fileinfo.size

  • fileinfo.state

  • fileinfo.stored

  • fileinfo.tx_id

  • flow_id

  • gcap

  • GCenter

  • host

  • proto

  • src_ip

  • src_port

  • timestamp_analyzed

  • timestamp_detected

  • type

  • uuid

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

Champs Requis Description
app_proto Oui Protocole applicatif du flux de provenance du fichier.
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 reconstruit. 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 -
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.

5.3. Document de méta-données

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

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.hhash

    • nfs.id

    • nfs.procedure

    • nfs.rename.from

    • nfs.rename.to

    • nfs.status

    • nfs.type

    • nfs.version

    • 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

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

Champs 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 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.