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 :

Gestion des sources de règles disponibles
Création des ruleset à partir des sources
Générer les rulesets (important)
Application de ruleset sur le gcap
Configuration avancée des paramètres du gcap

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 :

Detection Ruleset
Base variables
Net variables
Flow timeouts
Files rules management
BPF filter

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:

Se rendre dans l'onglet Single-tenant,
Sélectionner un ruleset à appliquer pour toutes les interfaces,
Activer ou désactiver la détection des shellcodes pour toutes les interfaces,
Activer ou désactiver la détection des powershells pour toutes les interfaces,
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:

Se rendre dans l'onglet Multi-tenant by interface,
Sélectionner un ruleset à appliquer pour chaque interface,
Activer ou désactiver la détection des shellcodes pour chaque interface,
Activer ou désactiver la détection des powershells pour chaque interface,
Appliquer la configuration via le bouton "save".

Exemple de configurations:

interface mon0:
- Ruletset nommé "Test-mon0",
- Activation de la detection des shellcodes/powershells.
interface mon2:
- Ruletset nommé "Test-mon2",
- Désactivation de la détection des shellcodes/powershells.

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:

Se rendre dans l'onglet Multi-tenant by vlan,
Sélectionner un ruleset à appliquer pour le vlan "default",
Activer ou désactiver la détection des shellcodes pour le vlan "default",
Activer ou désactiver la détection des powershells pour le vlan "default",
Créer autant de vlan que nécessaire via le bouton "Add",
Le nom du vlan doit correspondre au numéro de vlan entre 0 et 4096,
Sélectionner ensuite un ruleset à appliquer pour chaque vlan,
Activer ou désactiver la détection des shellcodes pour chaque vlan,
Activer ou désactiver la détection des powershells pour chaque vlan,
Appliquer la configuration via le bouton "save".

Exemple de configurations:

vlan "default":
- Ruletset nommé "Test-default",
- Activation de la détection des shellcodes/powershells.
vlan "110":
- Ruletset nommé "Test-vlan110",
- Désactivation de la detection des shellcodes/powershells.

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 fonctionnement 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 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 (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.