6cure

6cure
Threat
Protection®
Gestion des alertes
Modèle : 6cure TP – Version : 2.7
10/06/2015
Référence : 6C/TE/TP/14/0744
Version : 1.0.9
Campus Effiscience
2 rue Jean Perrin
14460 Colombelles
France
Tel. +33 250 011 509
Société par Actions Simplifiée au capital de 114900 €.

RCS : CAEN 520 799 487
contact@6cure.com
www.6cure.com
© 2014-2015 6cure SAS. Tous droits réservés. 6cure et le

logo 6cure sont des marques déposées par 6cure SAS.
[6cure Threat Protection®] • v1.0.9
Table des matières

Préambule . ....................................................................................................................................5
A propos.......................................................................................................................................................................... 5
Acronymes ...................................................................................................................................................................... 5
1. Présentation générale .....................................................................................................................6
1.1. Environnement ...................................................................................................................................................... 6
1.2. Principes de production et traitement d’alertes .............................................................................................. 7
2. Configuration ...................................................................................................................................9
2.1. Typologie d’alertes ................................................................................................................................................ 9
2.2. Configuration de production d’alertes ............................................................................................................... 9
2.3. Prise en compte des modifications .................................................................................................................. 16
3. Corrélation d’alertes ..................................................................................................................... 18
3.1. Principes d’agrégation ........................................................................................................................................ 18
3.2. Corrélation d’alertes ........................................................................................................................................... 20
4. Visualisation ................................................................................................................................. 22
4.1. Aperçu global ....................................................................................................................................................... 22
4.2. Détail d’un événement ....................................................................................................................................... 24
4.3. Filtrage d’événements ........................................................................................................................................ 24
4.4. Rapports ............................................................................................................................................................... 26
5. Intégration .................................................................................................................................... 27
5.1. Intégration SNMP ............................................................................................................................................... 27
5.2. Intégration syslog ............................................................................................................................................... 28
5.3. Intégration SMTP ................................................................................................................................................ 28
5.4. Intégration SIEM ................................................................................................................................................. 29
5.5. Transfert d’alertes............................................................................................................................................... 29
Annexe A – Nomenclature d’alertes ................................................................................................ 30
Alertes trafic ................................................................................................................................................................. 30
Alertes système........................................................................................................................................................... 32
Alertes filtrage ............................................................................................................................................................. 34
Annexe B – Exemple de fichier de configuration ............................................................................. 36
Annexe C – MIB ................................................................................................................................ 42
Annexe D – Nomenclature SNMP .................................................................................................... 58
Alertes système........................................................................................................................................................... 58
Alertes trafic ................................................................................................................................................................. 59
Contact . .................................................................................................................................. 60
6cure SAS | 3
6C/TE/TP/14/0744 [6cure Threat Protection®]
Table des tableaux & figures
Tableau 1 ■ Paramètres pour les alertes « trafic » .................................................................................................. 11

Tableau 2 ■ Paramètres pour les alertes « trafic rate » ......................................................................................... 12
Tableau 3 ■ Paramètres pour les alertes « système » ............................................................................................ 14
Tableau 4 ■ Paramètres génériques pour les alertes « filtrage » .......................................................................... 15
Tableau 5 ■ Paramètres spécifiques pour les alertes « filtrage » ......................................................................... 16
Tableau 6 ■ Paramètres spécifiques pour les alertes sémantiques de « filtrage »............................................ 16
Tableau 7 ■ Critères de similarité pour l’agrégation locale de messages............................................................. 19
Tableau 8 ■ Paramètres de configuration SMTP ...................................................................................................... 28
Figure 1 ■ Architecture de composants du produit 6cure Threat Protector.......................................................... 6

Figure 2 ■ Architecture de composants du produit 6cure Threat Manager. .......................................................... 7
Figure 3 ■ Principes génériques d’agrégation locale de messages. ...................................................................... 19
Figure 4 ■ Activation de l’analyseur « reassemble » depuis la console d’administration du 6cure TM. ......... 20
Figure 5 ■ Aperçu global des événements en console de visualisation du 6cure TM. ....................................... 22
Figure 6 ■ Exemple de focus sur les données d’événements en console de visualisation du 6cure TM. ....... 23
Figure 7 ■ Accès à la liste d’événements en console de visualisation du 6cure TM. ........................................ 23
Figure 8 ■ Liste des alertes corrélées en console de visualisation du 6cure TM. ............................................... 24
Figure 9 ■ Exemple de filtre de focalisation en console 6cure TM. ....................................................................... 25
Figure 10 ■ Exemple d’application de filtre de focalisation en console de visualisation 6cure TM. ................ 25
Figure 11 ■ Exemple d’application de filtre depuis la console de visualisation 6cure TM. ................................ 26
4 | 6cure SAS
Préambule .
A propos
La solution 6cure Threat Protection® (6cure TP) constitue un produit de sécurité permettant de protéger des
infrastructures de services informatiques et de réseaux de télécommunications. Les fonctions de sécurité
avancées embarquées par 6cure TP apportent une protection des actifs critiques tels que des serveurs
physiques ou virtuels, des applications informatiques installées sur ces serveurs, ou des composants réseau
tels que des routeurs, des liaisons de données, ou des services d’infrastructure (ex. : DNS), contre différentes
catégories d’attaques, et en particulier les menaces portant atteinte à la disponibilité de ces éléments, de
type « Distributed Denial of Service » (DDoS).
Ce document constitue un référentiel synthétique de gestion des alertes pour la solution 6cure Threat
Protection®.
Acronymes
Abréviation Signification
DoS Denial of Service
IDMEF Intrusion Detection Message Exchange Format
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
TM Threat Manager
TP Threat Protector
6cure SAS | Présentation générale 5

1. Présentation générale
1.1. Environnement
La solution 6cure Threat Protection est constituée de deux produits principaux :
• le produit 6cure Threat Protector (TP), en charge de l'analyse et du filtrage des flux sur chaque site ;
• le produit 6cure Threat Manager (TM), en charge de la supervision et du contrôle des modules de
filtrage ci-dessus.
De manière générique, le produit 6cure TP embarque sur un serveur dédié trois composants principaux :
• le composant d'analyse et filtrage (« tp-cc ») ;
• (optionnellement) le composant de gestion de ferme (« tp-controller » ou « controller ») ;
• le composant de génération d'alertes (« tp-correlator » ou « correlator »)
• le composant local de communication et pilotage (« em-collector » ou « collector »), qui constitue
l'interface de supervision et de contrôle utilisée par la console 6cure TM.
La relation interne entre ces composants est illustrée dans la Figure 1.
Figure 1 ■ Architecture de composants du produit 6cure Threat Protector.

Le composant « tp-cc » assure le traitement du trafic, opère ses analyses et ses filtrages, et envoie les logs
correspondants à son activité auprès du composant « tp-correlator ». Il notifie également sa présence auprès
du (ou des) « tp-controller(s) ».
Lorsqu’il est présent, le composant « tp-controller » est en charge de gérer le mode « ferme » (en particulier
pour des questions de redondance ou de regroupement de composants « tp-cc » sous son autorité, et les
transmet au composant « em-collector ». Il réceptionne d'autre part directement les mises à jour de
configuration en provenance du composant « em-collector » et les transmet aux composants « tp-cc » sous
son autorité. Il assure enfin la notification et la surveillance d'activité des composants « tp-cc », ainsi que des
autres « tp-controllers » éventuellement présents dans le cadre d'un déploiement en mode ferme.
Le composant « tp-correlator » est en charge du traitement des logs et de la génération d'alertes dans
différents formats (syslog, texte, IDMEF, SNMP) vers le composant « em-collector ».
6 Présentation générale | 6cure SAS

Le composant « em-collector » constitue l'interface entre la console (6cure TM) et le module de filtrage (6cure
TP). Il transmet les alertes auprès de la console, et en retour, réceptionne des demandes de modification de
configuration en provenance de cette dernière pour les traiter et les appliquer sur les différents composants
(via le « tp-controller » s'il existe).
Par ailleurs, le produit 6cure TM héberge différents services de supervision offerts par les composants
embarqués suivants :
• le composant de visualisation (« em-viewer ») qui propose l'IHM offerte à l'utilisateur ;
• le composant de supervision qui gère les communications entre composants (« em-core ») ;
• le composant d'analyse d'alertes (« em-analyzer ») ;
• le composant de stockage (« database »).
La relation interne entre ces composants est illustrée dans la Figure 2.
Figure 2 ■ Architecture de composants du produit 6cure Threat Manager.

Le composant « em-core » est en charge des opérations d'accès aux données (enrichissement et insertion
des événements, lecture des informations) et gère en ce sens les droits associés. Il reçoit les alertes envoyées
par les différents composants « em-collector » et les propage au composant d'analyse (« em-analyzer »). Il
administre également toutes les communications avec les composants tierces tels que les « collector(s) »
et/ou les « analyzer(s) ».
Le composant « em-analyzer » opère les analyses sur les événements transmis par le composant « em-core ».
Il héberge à ce titre une ou plusieurs instances de " corrélateurs " (e.g. « reassemble », « alerting »). Il peut
créer et initier l'insertion de nouveaux événements issus de ses corrélateurs.
Le composant « em-viewer » offre l'interface aux utilisateurs, dans leur accès aux données gérées par le
composant central « em-core », et dans l'administration des composants via ce dernier. Il peut opérer
exceptionnellement des requêtes directes vers la base de données pour certaines manipulations coûteuses
(ex. : production de rapports).
Le composant « database » (DB) assure la persistance des informations de l'application. Elle est requise par
l'ensemble des autres composants constitutifs du module 6cure TM.
1.2. Principes de production et traitement d’alertes

Chaque instance de module 6cure TP est donc en mesure de produire des alertes. Celles-ci sont construites
à partir de la surveillance de l’activité du composant de filtrage (« tp-cc ») localement analysées par le
6cure SAS | Présentation générale 7

composant dédié (« tp-correlator »). Elles sont ensuite transmises à la console 6cure TM via le composant
local de communication (« collector »). Le module 6cure TM assure la sauvegarde de ces alertes en base de
données (« database ») et procède à des analyses complémentaires au travers du composant de
corrélation/analyse (« em-analyzer »). Ces analyses complémentaires donnent lieu à la production d’alertes
de plus haut niveau, associant plusieurs alertes unitairement produites par les instances 6cure TP. Ces alertes
peuvent être visualisées en temps réel depuis le composant de visualisation (« em-viewer »).
Chaque composant ainsi « traversé » par le flux d’alertes dans une plate-forme 6cure Threat Protection® peut
donner lieu à un paramétrage spécifique modifiant le traitement opéré par ce composant sur le flux.
8 Présentation générale | 6cure SAS

2. Configuration
2.1. Typologie d’alertes
La solution 6cure Threat Protection® met à disposition trois grandes familles d’alertes :
• les alertes de « trafic » caractérisant les attaques détectées par les différentes couches de filtrage
du 6cure TP ;
• les alertes spécifiques à l’activité de « filtrage » de trafic par le 6cure TP ;
• les alertes liées au « système », à savoir le fonctionnement même du 6cure TP.
Une nomenclature complète des alertes produites par le 6cure TP est fournie en annexe A.
Les deux premiers types d’alertes sont donc intrinsèquement liés à l’activation des fonctions de filtrage sur
les différents services protégés par le 6cure TP. A titre d’exemple, des alertes de type « flood » (ex. : « SYN
flood ») et filtrage de ces phénomènes par le TP (ex. : « RR Default Redundancies filtered ») ne pourront être
produites que si la fonction de filtrage en charge de la protection contre les « floods » sur le TP est active
(ex. : couche « Redundancy Remover » - RR). Il est bien évidemment possible de tirer parti du mode
« simulation » disponible pour la protection des services pour bénéficier des alertes dans un mode
« détection » sans qu’elles soient associées à un filtrage effectif par le 6cure TP (pour plus de détails, prière
de se reporter à la documentation technique de la solution 6cure Threat Protection®).
2.2. Configuration de production d’alertes

La configuration principale pour la production d’alertes par le 6cure TP est gérée localement sur chaque
instance par le module « tp-correlator » par l’intermédiaire du fichier ‘/etc/6cure/tp-correlator/tp-
correlator.conf’, dont un exemple est fourni en annexe B.
Ce fichier est structuré selon quatre sections :
1. Spécification des formats de sortie (balise <OutputFormat>)

2. Paramétrage des alertes « trafic » (balise <TrafficAlerts>)
3. Paramétrage des alertes « système » (balise <SystemAlerts>)
4. Paramétrage des alertes « filtrage » (balise <FilterAlerts>)
2.2.1. Spécification des formats de sortie

Exemple :
<OutputFormat brake="disabled">
<Output type="idmef"
status="enabled">/var/log/cleaning_center/cleaning_center_events.log</Output>
<Output type="text"
status="disabled">/var/log/cleaning_center/cleaning_center_alerts.log</Output>
<Output type="snmp"
status="disabled">/var/log/cleaning_center/cleaning_center_traps.log</Output>
<Output type="syslog" status="enabled" server="127.0.0.1"
port="514">/var/log/cleaning_center/cleaning_center_event_syslog.log</Output>
<Output type="smtp" status="disabled" from="youraddress@domain"
to="destination@domain">/var/log/6cure/tp-cc/cleaning_center_error.log</Output>
</OutputFormat>
Plusieurs formats de production d’alertes sont disponibles sur le 6cure TP :
6cure SAS | Configuration 9

• format IDMEF (type="idmef") : nécessaire à la prise en compte des alertes par le composant
« collector », et donc à leur visualisation dans l’interface 6cure TM ;
• format SNMP (type="snmp") : production de « traps » SNMP à destination des collecteurs spécifiés
en configuration générale du 6cure TP (‘/etc/6cure/tp-cc/cleaning_center.conf’) ;
• format syslog (type="syslog") : production de messages syslog à destination d’un collecteur spécifié
dans la configuration (attribut server) ;
• format mail (type="smtp") : production de mails à destination de serveur(s) SMTP spécifié(s) en
configuration spécifique du module (‘/etc/6cure/tp-correlator/.smtp.conf’) ;
• format texte (type="text") : utilisé pour l’intégration dans des systèmes externes de type SIEM.
Pour chaque format, il est possible de spécifier :
• le statut (status) : peut être actif : ‘enabled’ ou inactif : ‘disabled‘ ;

• le fichier de sortie, i.e. le fichier local d’écriture des alertes produites et/ou des erreurs rencontrées.
Pour ce dernier, la modification du fichier IDMEF nécessite une reconfiguration du « collector » de manière à
assurer que celui-ci est en mesure de lire les alertes produites afin d’assurer leur transfert vers la console
6cure. De plus, le fichier SNMP et le fichier syslog sont uniquement présents pour garder une trace locale des
messages produits par le 6cure TP, et simultanément envoyés vers le(s) collecteur(s). A ce titre, pour le format
syslog, il est nécessaire de préciser l’adresse du collecteur (server) ainsi que le port de réception sur ce
collecteur (port).
Plus globalement, il est possible d’interrompre la production d’alertes en activant le paramètre ‘brake’ sur la
section complète.
2.2.2. Gestion des alertes « trafic »

Les alertes « trafic » représentent les messages associés à une anomalie constatée sur le trafic traité par le
TP, cette anomalie pouvant relever d’une attaque caractérisée, ou d’un comportement abusif. Les différentes
catégories d’alertes de ce type sont :
• Alertes « DoS » : alertes levées pour un service lorsque la part de trafic filtré (ou filtrable dans le cas
d’un mode simulation) par le TP sur ce service dépasse un seuil spécifié en interface 6cure TM – elles
sont caractéristiques d’un taux anormal de paquets malicieux à destination du service concerné,
représentant alors une possibilité d’indisponibilité de ce dernier ;
• Alertes « Flood » : alertes relatives à des attaques par inondation de requêtes similaires (ex. : SYN
flood) sur un service protégé par le TP – elles sont produites par le TP si la couche de filtrage RR est
activée pour le service concernée, et qu’elle détecte ce type de phénomène ;
• Alertes « Trend » : alertes déclenchées par l’analyse comportementale de trafic pour un service
donné, si cette analyse a été activée depuis l’interface 6cure TM – elles interviennent lorsque l’afflux
de trafic déborde de l’enveloppe modèle du comportement normal du service, construite par
apprentissage par le TP, représentant alors un excès ou un défaut de trafic sur le service ;
• Alertes « Packet » : alertes liées à des anomalies protocolaires constatées par le TP (ex. : taille d’en-
tête TCP invalide) ;
• Alertes « Rate » : alertes de dépassement de seuils statiques de trafic pour un service ou un
ensemble de services protégés par le 6cure TP – elles diffèrent de l’analyse comportementale (alertes
« Trend ») par le fait que les seuils spécifiés par l’utilisateur sont statiques ;
• Alertes « Scan » : alertes dénonçant un phénomène de scans de cibles hôtes (IP scan) ou de ports
applicatifs (Port scan) pour une cible donnée – produites par le TP si le module RR et les sous-modules
de filtrage de scans sont actifs ;
• Alertes « Report » : alertes spécifiques pour la production de rapports périodiques rendus ainsi
disponibles en interface 6cure TM ;
10 Configuration | 6cure SAS

• Alertes « Applicatives » : alertes spécifiques de différents types d’attaques de niveau 7 (ex. : « DNS
Cache poisoning ») - ces alertes ne donnent pas lieu à un paramétrage spécifique.
Le Tableau 1 recense l’ensemble des paramètres pour les alertes « trafic » ainsi définies.
Tableau 1 ■ Paramètres pour les alertes « trafic »
Paramètre Description Valeur par défaut

all
status état (actif/inactif) disabled
window1 taille de la fenêtre (en secondes) 60
au maximum une alerte de ce type est produite par fenêtre temporelle,
pour chaque service
DoS
threshold seuil (en nombre de messages) 10
nombre minimal de messages (traces TP) requis sur une période pour
générer une alerte
period période (en secondes) 60
taille de la période de référence pour la génération d’alertes (cf. threshold)
rate-limit period période de rate-limiting (en secondes) 300
durée du silence nécessaire à la production d’une nouvelle alerte « non
corrélée » aux précédentes
ratio ratio (%) 70%
seuil de trafic « filtré » déclenchant un accroissement de sévérité de l’alerte
min packet nombre minimal de paquets 5000
seuil minimum de paquets reçus pour déclencher une alerte
Flood
Trend
1
hors alertes « Report »


min throughput débit minimal (en bits/s) 20000000
débit minimum de trafic pour déclencher une alerte
tolerance seuil de tolérance 4
facteur de déviation minimal pour déclencher une alerte
Packet
Rate
service list liste des services N/A
spécification des seuils d’alerte pour chaque service
Scan
Report
size taille du « top » 5
nombre d’entrées pour chaque « top N » produit dans le rapport
périodique
average moyenne (en pps) 10
seuil minimal de trafic moyen pour une entrée dans un « top N »
instant valeur instantanée (en pps) 50
seuil minimal de trafic instantané pour une entrée dans un « top N »
Les alertes « Rate » permettent donc de définir des seuils statiques de débit (en pps et en bps) pour le
déclenchement d’alertes, et ce pour une liste de services (service list). Chaque service ainsi déclaré possède ainsi
un ensemble de valeurs détaillées dans le Tableau 2.
Tableau 2 ■ Paramètres pour les alertes « trafic rate »

Service
id identifiant du service N/A
identifiant unique du service tel que défini dans la configuration du TP


PacketsCount
min rate débit minimal (en pps) 500
débit en-dessous duquel un message « Traffic overly low » est déclenchée
high rate débit soutenu (en pps) 500000
débit au-dessus duquel un message « Traffic overly high » de sévérité
« medium » est déclenchée
max rate débit maximal (en pps) 750000
« high » est déclenchée
Volum
min rate débit minimal (en bps) 0
débit en-dessous duquel un message « Traffic overly low » est déclenchée
high rate débit soutenu (en bps) 500000000
« medium » est déclenchée
max rate débit maximal (en bps) 1000000000
« high » est déclenchée
Il est possible de définir ce type de seuils d’alerte pour le trafic global (tous services confondus d’une opération
de réaction d’identifiant X), à l’aide de l’identifiant ‘operationX_service0’.
Les principes d’agrégation et corrélation de messages du 6cure TP pour la production d’alertes sont détaillés
dans la section 3.
2.2.3. Gestion des alertes « système »

Le module 6cure TP procède à une surveillance de ses propres indicateurs de bon fonctionnement. A ce titre,
il est susceptible d’émettre des alertes en cas d’anomalies constatées sur celui-ci. Les différents types
d’alertes ainsi émises sont :
• Alertes « Storage » : alertes émises lorsque le stockage de trafic (captures) sont suspendues –
intervient lors d’une autoprotection du TP en cas de charge importante ;
• Alertes « Overload » : alertes levées en cas de surcharge des interfaces réseau du TP, conduisant à
la non prise en compte de certains paquets ;
• Alertes « FarmLife » : alertes produites lors de l’entrée (respectivement la sortie) d’une instance TP
au sein d’une ferme ;
• Alertes « StatusInfo » : alertes relatives à l’état de fonctionnement (up/down) d’un TP ;
• Alertes « Heartbeats / Statistics » : alertes déclenchées lorsque le TP ne produit plus de statistiques
périodiques de fonctionnement (« heartbeats ») – ce phénomène peut intervenir lorsque le TP ne
reçoit plus aucun trafic sur ses interfaces, ou lorsque le TP entre en autoprotection en cas de charge
critique ;
• Alertes « Logs » : alertes liées à la production de logs par le TP, significatives d’une saturation de
buffer de logs pouvant entraîner des « trous » de remontées statistiques ;
• Alertes « IllegalFrames » : alertes indiquant que des trames « non reconnues » sont reçues sur les
interfaces de TP, en particulier sur des protocoles de couche 2 non pris en compte par ce dernier ;
• Alertes « RingBuffer » : alertes de surveillance du taux d’occupation du buffer cyclique lié à l’écriture
des captures de trafic sur le disque du TP – un buffer plein indique que l’intensité du trafic est telle
que le TP n’est pas en mesure d’écrire l’intégralité des captures requises sur le disque ;

• Alertes « LoadMonitor » : alertes générées lorsque le TP n’est plus en mesure d’assurer la

surveillance de la charge système ;
• Alertes « Watchdog » : alertes émises lors de l’activation du processus de surveillance automatique
du TP en cas de défaillance majeure de ce dernier.
Le Tableau 3 recense l’ensemble des paramètres pour les alertes « système » ainsi définies.
Tableau 3 ■ Paramètres pour les alertes « système »

all
Storage
period délai de tolérance (en secondes) 60
durée maximale d’interruption avant génération d’alerte
Overload
StatusInfo
load balancer coordonnées du load balancer N/A
spécification (optionnelle) des coordonnées de mécanismes de partage de
charge en amont du TP
load balancer id identifiant du load balancer N/A
load balancer vrid index de priorité du load balancer N/A
load balancer address adresse IP du load balancer N/A
Heartbeats
Statistics
Logs

IllegalFrames
RingBuffer
LoadMonitor
Watchdog
removal period délai de levée d’alertes (en secondes) 10
durée du silence nécessaire à la production d’une alerte informative de
retour à une situation stable
dans la section 3.
2.2.4. Gestion des alertes « filtrage »

Les alertes de filtrage rendent compte de l’activité effective du TP lorsqu’une couche de filtrage rejette des
paquets pour un service. Elles permettent à l’utilisateur de la plate-forme 6cure Threat Protection® d’être
informé des décisions du TP, et d’obtenir la liste des sources filtrées. Il est possible d’activer ces alertes par
couche de filtrage et par service défini en configuration de réaction. Les différents types d’alertes produites
par ce mécanisme correspondent donc à chaque couche de filtrage proposée par le TP (ex. « APD Bogon
filtered on service »).
Le Tableau 4 recense l’ensemble des paramètres pour les alertes « filtrage » ainsi définies.
Tableau 4 ■ Paramètres génériques pour les alertes « filtrage »

all
hitter count nombre de hits 10
nombre minimal de paquets filtrés par une couche requis sur une source
donnée pour générer une alerte
sampled count nombre de paquets filtrés 100

nombre minimal de paquets filtrés par une couche requis sur l’ensemble
des sources pour générer une alerte
Il est donc possible de définir, par couche (module) de filtrage proposée par le TP, des paramètres spécifiques
présentés dans le Tableau 5.
Tableau 5 ■ Paramètres spécifiques pour les alertes « filtrage »

Module
name nom du module N/A
acronyme spécifique désignant la couche principale de filtrage (doit être une
valeur parmi ‘APD, BPF, SAF, NSTT, SCC, APF, RR, HHB’)
exclusion list liste d’exclusion N/A
liste des identifiants de services pour lesquels les alertes ne sont pas
requises
Il est conseillé de paramétrer ce type d’alertes avec soin, afin de ne pas conduire à une génération excessive
d’alertes.
Les alertes de « filtrage » déclenchent également la génération d’alertes spécifiques lorsqu’un module filtre
une part importante du trafic. Ces alertes de filtrage dites « sémantiques » sont également configurables
selon les paramètres du Tableau 6
Tableau 6 ■ Paramètres spécifiques pour les alertes sémantiques de « filtrage »

all
ratio ratio (%) 70%
seuil de trafic « filtré » déclenchant la génération du message (trace TP)
dans la section 3.
2.3. Prise en compte des modifications

Toute modification de configuration du composant « tp-correlator » au travers du fichier de configuration local
nécessite le rechargement du composant via la commande suivante, exécutée en tant qu’utilisateur ‘sixcure’
sur le TP :

$ 6curectl tp-correlator {restart|reload}
Toutefois, la modification des listes de services pour les alertes « trafic » ou « filtrage » est immédiatement
prise en compte dès que le fichier modifié est sauvegardé.

3. Corrélation d’alertes
Afin d’assurer une production d’alertes exploitable, la plate-forme 6cure Threat Protection® embarque des
mécanismes d’agrégation et de corrélation.
Le mécanisme d’agrégation opère localement au niveau du TP afin de regrouper les messages unitaires
générés par ce dernier au sein d’alertes sémantiquement enrichies et caractérisant un phénomène confirmé.
Il permet également de préparer l’association d’alertes successives par le composant de corrélation embarqué
par le 6cure TM.
Le mécanisme de corrélation opère donc au niveau de la console 6cure TM au travers du composant « em-
analyzer ». Plusieurs mécanismes peuvent être mis à disposition. L’analyseur principal est en charge du
réassemblage d’alertes qui se succèdent dans le temps afin de les associer au sein d’un événement unique
caractéristique d’une période couvrant un phénomène complet.
3.1. Principes d’agrégation

L’agrégation locale de messages opérée au niveau du TP suit un schéma de principe générique pour une
grande partie des alertes présentées dans la section 2.1.
Une instance 6cure TP produit en permanence un ensemble de messages de logs (au format syslog)
représentatifs de son activité. Le composant « tp-correlator » décide au travers de sa lecture continue et en
temps réel de ces messages de la production d’alertes. Pour cela, des paramètres permettant de confirmer
une alerte sont généralement introduits :
• une période (glissante) de référence (ex. : 60 secondes)

• un nombre (seuil) de messages similaires requis sur cette période (ex. : 10 messages)
Ainsi, si le nombre de messages similaires requis est atteint dans le cadre d’une période de référence, alors
le composant « tp-correlator » génère une alerte. Celle-ci porte un identifiant unique.
Si le phénomène ayant donné lieu à la génération de cette première alerte se poursuit, alors le composant
« tp-correlator » continue à produire des alertes. Cependant, sur les alertes « successives », il indique
l’identifiant unique de la première alerte relative à ce phénomène afin de permettre au module de corrélation
du 6cure TM de réassembler les alertes ainsi produites et transmises. Si le phénomène s’interrompt pendant
un laps de temps trop important (appelé « période de rate limiting »), puis vient à se reproduire, alors le
composant « tp-correlator » génèrera une nouvelle alerte de « première génération » destinée à être associée
à d’éventuelles alertes qui la suivront.
Ainsi, pour un phénomène donné, trois périodes se succèdent :
• une période de montée en charge (« ramping ») durant laquelle des messages unitaires sont générés
par le TP, mais pas encore en nombre suffisant pour déclencher une alerte ;
• une période d’activité (« active ») durant laquelle les messages unitaires donnent lieu à des mises à
jour de l’alerte initialement levée à la fin de la période de montée en charge ;
• une période d’inactivité (« inactive ») durant laquelle aucun message unitaire similaire au précédent
n’est généré par le TP, conduisant à l’annulation des mises à jour.
Ces principes sont illustrés dans la Figure 3 où :
• t0 représente la date initiale de début du phénomène (instant de production du premier message

unitaire) ;
• T représente la durée de la période de référence ;
• t3 représente la date d’arrivée du dernier message unitaire se rapportant au phénomène ;
18 Corrélation d’alertes | 6cure SAS

• ∆ représente la durée du silence nécessaire pour confirmer la fin du phénomène ;

• t'0 représente la date hypothétique de nouvelle survenue du phénomène.
Figure 3 ■ Principes génériques d’agrégation locale de messages.
La notion de similarité permettant d’agréger localement des messages diffère selon les types d’alertes. Le
Tableau 7 fournit l’ensemble des caractéristiques retenues pour définir la similarité entre deux messages.
Tableau 7 ■ Critères de similarité pour l’agrégation locale de messages
Type d’alertes Critères de similarité

Trafic
DoS Service
Flood Type de requête
Service
Source
Destination
Packet Protocole
Source
Destination
Rate Nature (low/high)
Unité (pps/bps)
Service
Scan Type de scan
Service
Source
Trend Nature (low/high)
Service
Filtrage
Filter Module
Sous-module
Service
6cure SAS | Corrélation d’alertes 19

Semantic Module
Service
Ainsi, par exemple, les messages « SYN Flood », pour un service donné protégé par le 6cure TP, seront
considérés comme similaires (et donc pourront être agrégés) s’ils concernent la même adresse IP source et la
même adresse IP destination.
La modification de ces critères peut être opérée à la demande auprès du support 6cure.
3.2. Corrélation d’alertes

Les alertes produites par le composant « tp-correlator » sont transmises à la console 6cure TM par le
composant « collector ». Toutes les alertes ainsi émises sont sauvegardées en base de données centrale, et
transmises simultanément aux fonctions de corrélations proposées par le 6cure TM.
3.2.1. Réassemblage d’alertes

Le mécanisme premier de corrélation a pour objectif de réassembler les alertes relatives à un phénomène qui
se poursuit dans le temps. C’est le rôle du module de corrélation « reassemble ».
Ce dernier analyse les données portées par les alertes issues des instances 6cure TP et associe les alertes
portant référence à la même alerte originelle (cf. §3.1), et ce dans une fenêtre de temps définie (taille de
buffer). Ce mécanisme permet d’obtenir l’intégralité d’un phénomène sous un événement unique en console
TM, événement « vivant » au fur et à mesure des mises à jour.
Ce corrélateur doit être activé et paramétré depuis la console 6cure TM (menu « Administration ») pour être
effectif.
Figure 4 ■ Activation de l’analyseur « reassemble » depuis la console d’administration du 6cure TM.
La fenêtre temporelle de réassemblage peut être obtenue en cliquant sur l’icône de configuration du moteur
de corrélation (« engine »).
La visualisation des alertes ainsi produite est présentée en section 4.
20 Corrélation d’alertes | 6cure SAS

3.2.2. Autres fonctions de corrélation

D’autres fonctions de corrélation peuvent être activées sur le 6cure TM pour opérer des analyses plus
complexes : corrélation statistique (surveillance de la volumétrie du flux d’événements) ou corrélation
sémantique (agrégation contextuelle d’événements, filtrage et modification).
Ces modules complémentaires sont disponibles sous forme d’options complémentaires de la solution 6cure
Threat Protection®.
6cure SAS | Corrélation d’alertes 21

4. Visualisation
Les alertes produites par les instances 6cure TP présentes au sein d’une plate-forme 6cure Threat Protection®
sont directement consultables depuis l’onglet « Visualisation » de l’interface 6cure TM. Le lecteur est prié de
se reporter au manuel d’utilisation de la console pour plus de détails.
4.1. Aperçu global

Le menu « Visualisation » disponible sur l’onglet du manager central en console offre une vue synthétique
directe des événements sur la période récente, comme le montre la Figure 5.
Figure 5 ■ Aperçu global des événements en console de visualisation du 6cure TM.
Depuis cet aperçu global, il est notamment possible :
• de définir la période de visualisation ;

• d’appliquer des filtres spécifiques sur les données d’événements ;
• d’accéder aux informations détaillées (événements, classifications, sources, cibles …).
Les informations détaillées appliquent automatiquement un « filtre » contextuel pour l’accès à la base de
données d’événements (ex. : cliquer sur le graphe de sévérité pour une valeur de sévérité donnée donne accès
aux événements de cette sévérité uniquement). Elles apparaissent dès lors sous un nouvel onglet de
visualisation. La Figure 6 fournit un exemple de données obtenues pour les classifications.
22 Visualisation | 6cure SAS

Figure 6 ■ Exemple de focus sur les données d’événements en console de visualisation du 6cure TM.
L’accès à la liste d’événements peut s’opérer de différentes manières : soit directement depuis l’aperçu
général, soit depuis un focus intermédiaire (en cliquant sur le nombre d’événements).
Figure 7 ■ Accès à la liste d’événements en console de visualisation du 6cure TM.
6cure SAS | Visualisation 23

La Figure 7 montre que les filtres contextuels créés dynamiquement au fil de la navigation sont
systématiquement rappelés sous forme de « critères » qui peuvent également être effacés. La colonne
« Sub » de la liste d’événements indique le nombre d’alertes unitaires corrélées par l’événement visible en
console TM. On parle également d’événements « fils » ou « subsumes ».
4.2. Détail d’un événement

L’accès au détail d’un événement s’opère en cliquant sur son index (numéro d’événement). Ce détail est
composé de plusieurs sections :
• informations générales : sévérité, statut, dates, producteur de l’événement, classification ;

• sources et cibles ;
• données additionnelles : comporte notamment le log brut unitaire de l’alerte « première » ;
• événements « fils » ou « corrélés » : liste des alertes associées par l’événement de corrélation (le cas
échéant)
En particulier, cette dernière section permet d’accéder à chaque alerte unitaire (zoom) produites par le 6cure
TP et réassemblée au sein du même événement.
Figure 8 ■ Liste des alertes corrélées en console de visualisation du 6cure TM.
4.3. Filtrage d’événements

La console 6cure TM offre la possibilité de définir des filtres de visualisation depuis le menu « Filtering ». Il
est alors possible de construire des filtres pour focaliser la navigation dans la base de données d’événements
sur des critères simples ou composites (i.e. combinés selon des règles logiques de type ‘AND’ et ‘OR’).
Un exemple de filtre simple permettant de focaliser la vue sur les événements ciblant un service particulier
(ex. : ‘6cure DNS’) est fourni dans la Figure 9. Les filtres peuvent avoir une portée « privée » (i.e. réservée à
l’utilisateur) ou « publique » (accessible à tous les utilisateurs).

Figure 9 ■ Exemple de filtre de focalisation en console 6cure TM.
Dès lors, les filtres ainsi construits peuvent être invoqués dans le menu « Visualisation » de la console 6cure
TM, depuis l’aperçu général, dans le cartouche « Filter(s) ».
Figure 10 ■ Exemple d’application de filtre de focalisation en console de visualisation 6cure TM.
La Figure 10 illustre ainsi l’application d’un filtre, qui – dès lors – est reporté sur les focus invoqués à partir de
l’aperçu général (ex. : classifications en Figure 11). Le filtre peut être « levé » en cliquant sur l’icône présent
sur la ligne de rappel des critères de focalisation.
6cure SAS | Visualisation 25

Figure 11 ■ Exemple d’application de filtre depuis la console de visualisation 6cure TM.
4.4. Rapports
Chaque instance du 6cure TP produit des rapports périodiques bruts sous la forme d’alertes de type « Periodic
report ») qui peuvent être consultés depuis l’interface 6cure TM.
D’autres types de rapports sur les événements peuvent être construits à partir du menu spécifique issu du
plugin de « reporting » du composant 6cure TM.

5. Intégration
La plate-forme 6cure Threat Protection® propose différents mécanismes permettant de diriger et traiter les
alertes vers d’autres systèmes de supervision externes (ex. : SIEM, outils de ticketing, hyperviseurs).
5.1. Intégration SNMP

Le module 6cure TP peut générer des alertes sous forme de « traps » SNMP. La MIB associée aux alertes
ainsi générée est fournie en annexe C.
La configuration de ces alertes obéit au même fichier principal (‘/etc/6cure/tp-correlator/tp-

correlator.conf’). Il convient toutefois de paramétrer deux aspects de l’intégration SNMP :
• Activer la production de « traps » dans la section concernant les formats de sortie du fichier de
configuration du « tp-correlator »
<Output type="snmp"
status="enabled">/var/log/cleaning_center/cleaning_center_traps.log</Output>
• Déclarer le(s) collecteur(s) SNMP dans la section SNMP du fichier de configuration principal du « tp-
cc » (‘/etc/6cure/tp-cc/cleaning_center.conf’) sous la balise <Agent>
o fournir l’adresse IP du collecteur ;
o renseigner la communauté SNMP utilisée pour l’envoi et la réception des notifications.
<SNMP>
<MIB name="SIXCURE-TP-MIB" rwcommunity="private" ip="127.0.0.1" enable="false"/>
<Agents>
<Agent ip_address="10.10.10.1" community="example"/>
</Agents>
</SNMP>
Dans les deux cas, il est nécessaire d’opérer un rechargement de la configuration. Il est nécessaire de s’assurer
de la présence de l’outil ‘snmptrap’ (au besoin l’installer depuis un dépôt depuis le package ‘snmp’).
Un exemple de « trap » SNMP est fourni ci-après (trace produite dans le fichier de log SNMP).
Sep 18 13:05:49 cc05 snmptrapd[4587]: localhost [UDP: [127.0.0.1]:43638->[127.0.0.1]]: Trap ,

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (0) 0:00:00.00, SNMPv2-MIB::snmpTrapOID.0 = OID:
SIXCURE-TP-MIB::ccTrafficScan, SIXCURE-TP-MIB::ccAnalyzerName = STRING: "cc05", SIXCURE-TP-
MIB::ccAlertClassification = STRING: Port scan on service DNS(A), SIXCURE-TP-
MIB::ccAlertSourceAddress = STRING: 92.141.151.156, SIXCURE-TP-MIB::ccTrafficServiceName = STRING:
DNS(A)
Le produit 6cure Threat Protection® dispose donc de sa propre MIB. Dans sa version actuelle, cette MIB est
exclusivement utilisée à des fins d'interprétation. 6cure possède un numéro privé d'entreprise enregistré
auprès de l'IANA :
• Private Enterprise Number: 39530

• Organization Name: 6cure SAS
6cure SAS | Intégration 27

La nomenclature des notifications SNMP est fournie en annexe D. Il convient d’indiquer que les alertes
« filtrage » ne donnent pas lieu à des notifications SNMP.
5.2. Intégration syslog

Le module 6cure TP peut générer des messages syslog à destination d’un collecteur.
La configuration de ces messages obéit au même fichier principal (‘/etc/6cure/tp-correlator/tp-

correlator.conf’). Il convient toutefois de paramétrer deux aspects de l’intégration syslog :
• Configurer l’adresse du collecteur dans la section concernant les formats de sortie du fichier de
configuration du « tp-correlator »

• Configurer le port destination du collecteur, toujours dans la section concernant les formats de sortie
du fichier de configuration du « tp-correlator »

Il est également possible d’envisager une intégration en paramétrant le démon syslog local à l’instance 6cure
TP.
5.3. Intégration SMTP

Le module 6cure TP peut émettre des mails au travers de serveurs SMTP externes. Pour ce faire, les
paramètres de connexion et d’émission de messages via ces serveurs doivent être spécifiés au sein du fichier
de configuration spécifique (‘/etc/6cure/tp-corrrelator/.smtp.conf’).
Le Tableau 8 recense l’ensemble de ces paramètres.
Tableau 8 ■ Paramètres de configuration SMTP
Paramètre Description
authentication
Auth protocole d’authentification SMTP
(NONE, LOGIN, PLAIN, CRAM-MD5 ou NTLM)
AuthId nom d’utilisateur utilisé pour l’authentification
AuthPwd mot de passe utilisé pour l’authentification
server
Smtp adresse IP ou nom du serveur SMTP
(une liste peut être spécifiée, en séparant les noms par une virgule ‘,’)
Port port TCP utilisé pour la connexion au serveur
(ex. : 587)
encode
CType type de contenu du message
(ex. : text/plain, text/html, application/octet-stream, application/x-zip-
encoded, image/gif…)
CharSet jeu de caractères utilisé pour le message
28 Intégration | 6cure SAS

(ex. : us-ascii, iso-8859-1, …)

Encoding encodage du contenu
(ex. : none, base64, quoted-printable, uuencode, 7bit…)
Par ailleurs, il est possible de préciser, dans le fichier de configuration principal du module (‘/etc/6cure/tp-
correlator/tp-correlator.conf’), aussi bien l’adresse source utilisée (champ ‘from’) que les destinataires
(champ ‘to’). Une liste de destinataires peut être spécifiée en séparant les différentes adresses par une virgule
‘,’.
<Output type="smtp" status="disabled" from="youraddress@domain.net"

to="destination@domain.net">/var/log/6cure/tp-cc/cleaning_center_error.log</Output>
Les erreurs éventuellement rencontrées lors de l’émission des messages sont donc placées, par défaut, dans
le fichier : ‘/var/log/6cure/tp-cc/cleaning_center_error.log’.
5.4. Intégration SIEM

La solution 6cure Threat Protection® autorise l’intégration directe de ses alertes (et des statistiques de trafic)
au sein de solutions tierces. Plusieurs méthodes d’intégration sont possibles. En particulier, en matière de
gestion d’alertes, une solution de type SIEM pourra tirer parti de l’accès sécurisé aux alertes, soit directement
au format IDMEF (localisation par défaut : ‘/var/log/6cure/tp-cc/cleaning_center_events.log’), soit dans un
format « texte ».
Dans ce dernier cas, il est nécessaire d’activer la production d’alertes dans le format de sortie « texte » depuis
le fichier de configuration principal du « tp-correlator » (‘/etc/6cure/tp-correlator/tp-correlator.conf’).
<Output type="text"
status="enabled">/var/log/cleaning_center/cleaning_center_alerts.log</Output>
Cette modification éventuelle de configuration nécessite le rechargement du composant.
Le format par défaut des lignes de sortie d’alertes en « texte » suit le canevas :
%syslog_time [%alert_id|%referral] %service_name: %signature
Ce format est modifiable sur demande au support 6cure (support@6cure.com).
5.5. Transfert d’alertes

L’export d’événements sur des critères spécifiques (notion de filtres, cf. §4.3) vers des systèmes externes
peut également être opéré depuis la console 6cure TM au travers du module de corrélation spécifique
« alerting ».
D’autres moyens d’intégration, tel que l’envoi de messages via des sockets TCP sont également
envisageables. Sur ces points, le lecteur est prié de se rapprocher du support 6cure (support@6cure.com).
6cure SAS | Intégration 29

Annexe A – Nomenclature d’alertes

Alertes trafic
Classification Type Impact Paramètres Données additionnelles

DoS attack on service dos Filtered traffic ratio Service Log received from
exceeds threshold Original log
Generated by
Rule ID
Service ID
Service name
Impacted services
Start time
End time
<request> flood on service dos Flood of <request> Request Log received from
Service Original log
Source Generated by
Destination Rule ID
Service ID
Service name
Impacted services
Start time
End time
Abnormal packets with invalid other <count> repeated Protocol Log received from
<protocol> header abnormal requests from Source Original log
source Destination Generated by
Rule ID
Start time
End time
<protocol> header length
IP payload
Traffic rate overly {low|high} on service dos Traffic rate out of strict Type Log received from
limits Unit Original log
Service Generated by
Rule ID
Service ID
Service name
Impacted services
Start time
End time
<type> scan on service recon <type> scan Type Log received from
Source Generated by
Rule ID
Service ID
Service name
Impacted services
Start time
End time
Unexpected {low|high} traffic rate dos Traffic rate gets out of Type Log received from
expected values Service Original log
Generated by
30 Annexe A – Nomenclature d’alertes | 6cure SAS

Rule ID
Service ID
Service name
Impacted services
Start time
End time
Cache poisoning file Transaction ID collision Log received from
Original log
Generated by
Rule ID
Start time
End time
DNS transaction ID
DNS payload (hex)
DNS payload (string)
Periodic report other Periodic report Log received from
Original log
Generated by
Rule ID
Start time
End time
Top N size
Average hit threshold
Instantaneous hit threshold
Fast flux report2 other Fast flux report Log received from
Original log
Generated by
Rule ID
Start time
End time
Domain
Distinct IP count
Distinct A classes count
Botnet report3 other Source activity similarity Log received from
Original log
Generated by
Rule ID
Start time
End time
Top source IPs
Top source ports
2
3 Disponible pour les modules additionnels (ex. : 6cure Source Analyzer®)
6cure SAS | Annexe A – Nomenclature d’alertes 31

Alertes système

Traffic storage {suspended|resumed} other Traffic storage Log received from
{suspended|resumed} Original log
Generated by
Rule ID
Start time
End time
Queue size
Safety threshold
System overload other Frames are dropped Log received from
Original log
Generated by
Rule ID
Start time
End time
Dropped frame ratio
Total number of frames
Farm mode : Only one Cleaning Center other Log received from
in group Original log
Generated by
Rule ID
Start time
End time
Farm mode : Cleaning Center group other Log received from
empty Original log
Generated by
Rule ID
Start time
End time
Cleaning Center {up|down} other Cleaning Center status Log received from
change Original log
Generated by
Rule ID
Start time
End time
Statistics computation other Statistics computation Log received from
{suspended|resumed} {suspended|resumed} Original log
Generated by
Rule ID
Start time
End time
Log {discard|overwrite} other Log {discard|overwrite} Log received from
Original log
Generated by
Rule ID
Start time
End time
Illegal frames other Illegal frames Log received from
Original log
Generated by

Rule ID
Start time
End time
Capture dumping : full ring-buffer other Capture dumping : full Log received from
ring-buffer Original log
Generated by
Rule ID
Start time
End time
System load monitoring other System load monitoring Log received from
{suspended|resumed} {suspended|resumed} Original log
Generated by
Rule ID
Start time
End time
Cleaning center failure other Watchdog {about to Log received from
{detected|resumed} restart|restarted} Original log
cleaning center Generated by
Rule ID
End time

Alertes filtrage

<module> filtered on service other <module> activation Module Log received from
Submodule Original log
Service Generated by
Rule ID
Service ID
Service name
Impacted services
Start time
End time
Misuse attack on service dos high APD filtering level Module Log received from
Generated by
Rule ID
Service ID
Service name
Impacted services
Start time
End time
Module
Filtering level
Malicious IP attack on service dos high SAF filtering level Module Log received from
Generated by
Rule ID
Service ID
Service name
Impacted services
Start time
End time
Module
Filtering level
Spoofed IP attack on service dos high NSTT filtering level Module Log received from
Generated by
Rule ID
Service ID
Service name
Impacted services
Start time
End time
Module
Filtering level
Exhaustion attack on service dos high SCC filtering level Module Log received from
Generated by
Rule ID
Service ID
Service name
Impacted services

Start time
End time
Module
Filtering level
Application misuse attack on service dos high APF filtering level Module Log received from
Generated by
Rule ID
Service ID
Service name
Impacted services
Start time
End time
Module
Filtering level
Flood attack on service dos high RR filtering level Module Log received from
Generated by
Rule ID
Service ID
Service name
Impacted services
Start time
End time
Module
Filtering level
Volumetric attack on service dos high HHB filtering level Module Log received from
Generated by
Rule ID
Service ID
Service name
Impacted services
Start time
End time
Module
Filtering level

Annexe B – Exemple de fichier de configuration
<AlertParameters timestamp="1328118434" id="600666" ruleset="common">


<OutputFormat brake="disabled">
<Output type="idmef"
status="enabled">/var/log/cleaning_center/cleaning_center_events.log</Output>
<Output type="text"
status="disabled">/var/log/cleaning_center/cleaning_center_alerts.log</Output>
<Output type="snmp"
status="disabled">/var/log/cleaning_center/cleaning_center_traps.log</Output>
<Output type="smtp" status="disabled" from="youraddress@domain.net"
to="destination@domain.net">/var/log/6cure/tp-cc/cleaning_center_error.log</Output>
</OutputFormat>




<TrafficAlerts>

<DosAlerts status="disabled" window="60">

<Threshold>10</Threshold>
<Period>60</Period>

<RateLimitPeriod>300</RateLimitPeriod>

<Ratio>70%</Ratio>

<MinPacket>5000</MinPacket>
</DosAlerts>
<FloodAlerts status="disabled" window="60">
<Period>60</Period>
</FloodAlerts>
<TrendAlerts status="disabled" window="60">
<Period>60</Period>

<MinThroughput>20000000</MinThroughput>
36 Annexe B – Exemple de fichier de configuration | 6cure SAS

<Tolerance>4</Tolerance>
</TrendAlerts>
<PacketAlerts status="disabled" window="60">
<Period>60</Period>
</PacketAlerts>
<RateAlerts status="disabled" window="60">
<Period>300</Period>
<ServiceList>

<Service id="operation1_service0" status="disabled">

<PacketsCount>
<MinRate>500</MinRate>
<HighRate>500000</HighRate>
<MaxRate>750000</MaxRate>
</PacketsCount>
<Volum>
<MinRate>0</MinRate>
<HighRate>500000000</HighRate>
<MaxRate>1000000000</MaxRate>
</Volum>
</Service>
</ServiceList>
</RateAlerts>
<ScanAlerts status="disabled" window="60">
</ScanAlerts>
<ReportAlerts status="disabled">

<Size>5</Size>

<Average>10</Average>
<Instant>50</Instant>
</ReportAlerts>
</TrafficAlerts>
<SystemAlerts>

<Storage status="disabled">

<Period>60</Period>
</Storage>
<Overload status="disabled" window="60">
6cure SAS | Annexe B – Exemple de fichier de configuration 37

<Period>60</Period>

<MinRatio>10</MinRatio>
</Overload>
<FarmLife status="disabled"/>
<StatusInfo status="disabled">
<LoadBalancer/>
</StatusInfo>
<Heartbeats status="disabled">

<Period>30</Period>
</Heartbeats>
<Logs status="disabled">

<Period>60</Period>
</Logs>
<IllegalFrames status="disabled">

<Period>60</Period>
</IllegalFrames>
<Statistics status="disabled">

<Period>20</Period>
</Statistics>
<RingBuffer status="disabled">

</RingBuffer>
<LoadMonitor status="disabled">

<Period>60</Period>
</LoadMonitor>
<Watchdog status="enabled">

<RemovalPeriod>10</RemovalPeriod>
</Watchdog>
</SystemAlerts>
<FilterAlerts>

<Period>60</Period>

<HitterCount>10</HitterCount>
<SampledCount>100</SampledCount>

<FilteringModules>
<Module name="APD" status="disabled">
<SemanticAlerts status="enabled" window="60">
<Period>60</Period>


<Ratio>0.7</Ratio>
</SemanticAlerts>
<ExclusionList>
<Service id="operation1_service1"/>
</ExclusionList>
</Module>
<Module name="BPF" status="disabled">
<ExclusionList/>
</Module>
<Module name="SAF" status="disabled">
<Period>60</Period>
<Ratio>0.7</Ratio>
</SemanticAlerts>
<ExclusionList/>
</Module>
<Module name="NSTT" status="disabled">
<Period>60</Period>
<Ratio>0.7</Ratio>
</SemanticAlerts>
<ExclusionList/>
</Module>
<Module name="SCC" status="disabled">

<Period>60</Period>
<Ratio>0.7</Ratio>
</SemanticAlerts>
<ExclusionList/>
</Module>
<Module name="APF" status="disabled">
<Period>60</Period>
<Ratio>0.7</Ratio>
</SemanticAlerts>
<ExclusionList/>
</Module>
<Module name="RR" status="disabled">
<Period>60</Period>
<Ratio>0.7</Ratio>
</SemanticAlerts>
<ExclusionList/>
</Module>
<Module name="HHB" status="disabled">
<Period>60</Period>
<Ratio>0.7</Ratio>
</SemanticAlerts>

<ExclusionList/>
</Module>
</FilteringModules>
</FilterAlerts>
</AlertParameters>

Annexe C – MIB
SIXCURE-TP-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
NOTIFICATION-TYPE, enterprises, Integer32,
Gauge32, TimeTicks FROM SNMPv2-SMI
DisplayString, RowStatus, DateAndTime FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP FROM SNMPv2-CONF
CounterBasedGauge64 FROM HCNUM-TC
InetAddress, InetAddressType FROM INET-ADDRESS-MIB
;
cleaning-center MODULE-IDENTITY
LAST-UPDATED "201507120018Z"
ORGANIZATION "6cure http://www.6cure.com/"
CONTACT-INFO
"email: support@6cure.com
postal: 6cure
Campus Effiscience
2 rue Jean Perrin
14460 Colombelles"
DESCRIPTION
"6CURE THREAT PROTECTOR MIB"
REVISION "201507120018Z"
DESCRIPTION
"Including service identifier in alerts."
REVISION "201401311122Z"
DESCRIPTION
"Updating notifications with alert severity info."
REVISION "201303080041Z"
DESCRIPTION
"Additional notification-types for BEM."
REVISION "201211210953Z"
DESCRIPTION
"Minimal implementation of notifications.
Conformance and compliance information."
-- .1.3.6.1.4.1.39530 -- ::= { enterprises 39530 }
ccIdmef OBJECT-IDENTITY
STATUS current
DESCRIPTION "Definition point for IDMEF definitions."
-- .1.3.6.1.4.1.39530.1 -- ::= { cleaning-center 1 }
-- analyzer Group
ccAnalyzer OBJECT-IDENTITY
42 Annexe C – MIB | 6cure SAS

STATUS current
DESCRIPTION "Definition point for analyzer properties."
-- .1.3.6.1.4.1.39530.1.1 -- ::= { ccIdmef 1 }
ccAnalyzerId OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..128))
MAX-ACCESS read-write
STATUS current
DESCRIPTION "Unique IDMEF ID"
-- .1.3.6.1.4.1.39530.1.1.1 -- ::= { ccAnalyzer 1 }
ccAnalyzerName OBJECT-TYPE
STATUS current
DESCRIPTION "Analyzer name"
-- .1.3.6.1.4.1.39530.1.1.2 -- ::= { ccAnalyzer 2 }
ccAnalyzerManufacturer OBJECT-TYPE
STATUS current
DESCRIPTION "Analyzer manufacturer"
DEFVAL { "6cure" }
-- .1.3.6.1.4.1.39530.1.1.3 -- ::= { ccAnalyzer 3 }
ccAnalyzerModel OBJECT-TYPE
STATUS current
DESCRIPTION "Analyzer model"
DEFVAL { "Threat Protector" }
-- .1.3.6.1.4.1.39530.1.1.4 -- ::= { ccAnalyzer 4 }
ccAnalyzerVersion OBJECT-TYPE
STATUS current
DESCRIPTION "Analyzer version"
DEFVAL { "2.0.0" }
-- .1.3.6.1.4.1.39530.1.1.5 -- ::= { ccAnalyzer 5 }
-- alert Group
ccAlert OBJECT-IDENTITY
STATUS current
DESCRIPTION "The definition point for CC alerts."
-- .1.3.6.1.4.1.39530.1.2 -- ::= { ccIdmef 2 }
ccAlertId OBJECT-TYPE
STATUS current
6cure SAS | Annexe C – MIB 43

DESCRIPTION "The unique identifier for an alert generated by the CC."

-- .1.3.6.1.4.1.39530.1.2.1 -- ::= { ccAlert 1 }
ccAlertClassification OBJECT-TYPE
SYNTAX DisplayString
STATUS current
DESCRIPTION "The description of the alert."
-- .1.3.6.1.4.1.39530.1.2.2 -- ::= { ccAlert 2 }
ccAlertSeverity OBJECT-TYPE
SYNTAX Integer32 (0..5)
STATUS current
DESCRIPTION "The severity of the alert, frequently linked with
classification. The convention is the following:
0 - critical
1 - high
2 - medium
3 - low
4 - info
5 - unknown."
-- .1.3.6.1.4.1.39530.1.2.3 -- ::= { ccAlert 3 }
ccAlertCreateTime OBJECT-TYPE
SYNTAX DateAndTime
STATUS current
DESCRIPTION "The time the alert was created. Of the three times
that may be provided with an Alert, this is the only one that is
required."
-- .1.3.6.1.4.1.39530.1.2.4 -- ::= { ccAlert 4 }
ccAlertDetectTime OBJECT-TYPE
SYNTAX DateAndTime
STATUS current
DESCRIPTION "The time the event(s) leading up to the alert was detected. In the
case of more than one event, the time the first event was detected. In some
circumstances, this may not be the same value as CreateT ime."
-- .1.3.6.1.4.1.39530.1.2.5 -- ::= { ccAlert 5 }
ccAlertAnalyzerTime OBJECT-TYPE
SYNTAX DateAndTime
STATUS current
DESCRIPTION "The current time on the analyzer."
-- .1.3.6.1.4.1.39530.1.2.6 -- ::= { ccAlert 6 }
ccAlertSourceTable OBJECT-TYPE
SYNTAX SEQUENCE OF CcAlertSourceEntry
MAX-ACCESS not-accessible

STATUS current
DESCRIPTION "A list of source entries."
-- .1.3.6.1.4.1.39530.1.2.7 -- ::= { ccAlert 7 }
ccAlertSourceEntry OBJECT-TYPE
SYNTAX CcAlertSourceEntry
STATUS current
DESCRIPTION "An entry containing information applicable to a particular alert
source."
INDEX { ccAlertSourceId }
-- .1.3.6.1.4.1.39530.1.2.7.1 -- ::= { ccAlertSourceTable 1 }
CcAlertSourceEntry ::= SEQUENCE {

ccAlertSourceId Integer32,
ccAlertSourceAddressType InetAddressType,
ccAlertSourceAddress InetAddress,
ccAlertSourceName DisplayString
}
ccAlertSourceId OBJECT-TYPE
STATUS current
DESCRIPTION "A unique value for each source."
-- .1.3.6.1.4.1.39530.1.2.7.1.1 -- ::= { ccAlertSourceEntry 1 }
ccAlertSourceAddressType OBJECT-TYPE
SYNTAX InetAddressType
STATUS current
DESCRIPTION "The type of address of the source equipment."
ccAlertSourceAddress OBJECT-TYPE
SYNTAX InetAddress
STATUS current
DESCRIPTION "The network or hardware address of the source equipment."
ccAlertSourceName OBJECT-TYPE
STATUS current
DESCRIPTION "The name of the source equipment. May be strictly equal to the
network address."
ccAlertTargetTable OBJECT-TYPE
SYNTAX SEQUENCE OF CcAlertTargetEntry

STATUS current
DESCRIPTION "A list of target entries."
-- .1.3.6.1.4.1.39530.1.2.8 -- ::= { ccAlert 8 }
ccAlertTargetEntry OBJECT-TYPE
SYNTAX CcAlertTargetEntry
STATUS current
DESCRIPTION "An entry containing information applicable to a particular alert
target."
INDEX { ccAlertTargetId }
-- .1.3.6.1.4.1.39530.1.2.8.1 -- ::= { ccAlertTargetTable 1 }
CcAlertTargetEntry ::= SEQUENCE {

ccAlertTargetId Integer32,
ccAlertTargetAddressType InetAddressType,
ccAlertTargetAddress InetAddress,
ccAlertTargetName DisplayString
}
ccAlertTargetId OBJECT-TYPE
STATUS current
DESCRIPTION "A unique value for each Target."
-- .1.3.6.1.4.1.39530.1.2.8.1.1 -- ::= { ccAlertTargetEntry 1 }
ccAlertTargetAddressType OBJECT-TYPE
SYNTAX InetAddressType
STATUS current
DESCRIPTION "The type of address of the target equipment."
ccAlertTargetAddress OBJECT-TYPE
SYNTAX InetAddress
STATUS current
DESCRIPTION "The network or hardware address of the target equipment."
ccAlertTargetName OBJECT-TYPE
STATUS current
DESCRIPTION "The name of the target equipment. May be strictly equal to the
network address."
ccAlertAdditionalTable OBJECT-TYPE

SYNTAX SEQUENCE OF CcAlertAdditionalEntry

STATUS current
DESCRIPTION "A list of additional data information."
-- .1.3.6.1.4.1.39530.1.2.9 -- ::= { ccAlert 9 }
ccAlertAdditionalEntry OBJECT-TYPE
SYNTAX CcAlertAdditionalEntry
STATUS current
DESCRIPTION "An entry containing information applicable to a particular additional
data."
INDEX { ccAlertAdditionalId }
-- .1.3.6.1.4.1.39530.1.2.9.1 -- ::= { ccAlertAdditionalTable 1 }
CcAlertAdditionalEntry ::= SEQUENCE {

ccAlertAdditionalId Integer32,
ccAlertAdditionalMeaning DisplayString,
ccAlertAdditionalValue DisplayString
}
ccAlertAdditionalId OBJECT-TYPE
STATUS current
DESCRIPTION "A unique value for each additional data."
-- .1.3.6.1.4.1.39530.1.2.9.1.1 -- ::= { ccAlertAdditionalEntry 1 }
ccAlertAdditionalMeaning OBJECT-TYPE
STATUS current
DESCRIPTION "A string describing the meaning of the element content.
These meanings will be vendor/implementation dependent; the method
for ensuring that managers understand the strings sent by analyzers is outside the
scope of this specification."
ccAlertAdditionalValue OBJECT-TYPE
STATUS current
DESCRIPTION "A string describing the value of the element content.
These values will be vendor/implementation dependent; the
method for ensuring that managers understand the strings sent by analyzers
is outside the scope of this specification."
ccSystem OBJECT-IDENTITY
STATUS current
DESCRIPTION "Definition point for system properties."

-- .1.3.6.1.4.1.39530.2 -- ::= { cleaning-center 2 }
-- system group
ccUpTime OBJECT-TYPE
SYNTAX TimeTicks
STATUS current
DESCRIPTION "Up-Time (Ticks)"
-- .1.3.6.1.4.1.39530.2.1 -- ::= { ccSystem 1 }
ccLastHeartbeat OBJECT-TYPE
SYNTAX DateAndTime
STATUS current
DESCRIPTION "timestamp last heartbeat"
-- .1.3.6.1.4.1.39530.2.2 -- ::= { ccSystem 2 }
ccLastConfiguration OBJECT-TYPE
SYNTAX DateAndTime
STATUS current
DESCRIPTION "timestamp last configuration"
-- .1.3.6.1.4.1.39530.2.3 -- ::= { ccSystem 3 }
ccAverageCpuLoad OBJECT-TYPE
SYNTAX Gauge32
STATUS current
DESCRIPTION "average cpu load in percent"
-- .1.3.6.1.4.1.39530.2.4 -- ::= { ccSystem 4 }
ccFifoSize OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION "fifo size in bytes"
-- .1.3.6.1.4.1.39530.2.5 -- ::= { ccSystem 5 }
ccNumberOfServices OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION "number of services"
-- .1.3.6.1.4.1.39530.2.6 -- ::= { ccSystem 6 }
ccTraffic OBJECT-IDENTITY
STATUS current
DESCRIPTION "Definition point for traffic information."
-- .1.3.6.1.4.1.39530.3 -- ::= { cleaning-center 3 }

-- the traffic table
ccTrafficTable OBJECT-TYPE
SYNTAX SEQUENCE OF CcTrafficEntry
STATUS current
DESCRIPTION "A list of traffic entries. The number of services is given by the value of
ccServicesNumber."
-- .1.3.6.1.4.1.39530.3.1 -- ::= { ccTraffic 1 }
ccTrafficEntryOBJECT-TYPE
SYNTAX CcTrafficEntry
STATUS current
DESCRIPTION "An entry containing management information applicable to a
particular service."
INDEX { ccTrafficId }
-- .1.3.6.1.4.1.39530.3.1.1 -- ::= { ccTrafficTable 1 }
CcTrafficEntry ::= SEQUENCE {

ccTrafficId Integer32,
ccTrafficRowStatus RowStatus,
ccTrafficServiceName DisplayString,
ccTrafficModuleName DisplayString,
ccTrafficIncomingPacketsCount CounterBasedGauge64,
ccTrafficIncomingVolume CounterBasedGauge64,
ccTrafficOutgoingPacketsCount CounterBasedGauge64,
ccTrafficOutgoingVolume CounterBasedGauge64,
ccTrafficGeneratedPacketsCount CounterBasedGauge64,
ccTrafficGeneratedVolume CounterBasedGauge64,
ccTrafficRejectedPacketsCount CounterBasedGauge64,
ccTrafficRejectedVolume CounterBasedGauge64
}
ccTrafficId OBJECT-TYPE
STATUS current
DESCRIPTION "A unique value for each services."
-- .1.3.6.1.4.1.39530.3.1.1.1 -- ::= { ccTrafficEntry 1 }
ccTrafficRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row"
-- .1.3.6.1.4.1.39530.3.1.1.2 -- ::= { ccTrafficEntry 2 }
ccTrafficServiceName OBJECT-TYPE

STATUS current
DESCRIPTION "service name"
-- .1.3.6.1.4.1.39530.3.1.1.3 -- ::= { ccTrafficEntry 3 }
ccTrafficModuleName OBJECT-TYPE
STATUS current
DESCRIPTION "module name"
-- .1.3.6.1.4.1.39530.3.1.1.4 -- ::= { ccTrafficEntry 4 }
ccTrafficIncomingPacketsCount OBJECT-TYPE
STATUS current
DESCRIPTION "number of incoming packets"
-- .1.3.6.1.4.1.39530.3.1.1.5 -- ::= { ccTrafficEntry 5 }
ccTrafficIncomingVolume OBJECT-TYPE
STATUS current
DESCRIPTION "volume of the number of incoming packets"
-- .1.3.6.1.4.1.39530.3.1.1.6 -- ::= { ccTrafficEntry 6 }
ccTrafficOutgoingPacketsCount OBJECT-TYPE
STATUS current
DESCRIPTION "number of outgoing packets"
-- .1.3.6.1.4.1.39530.3.1.1.7 -- ::= { ccTrafficEntry 7 }
ccTrafficOutgoingVolume OBJECT-TYPE
STATUS current
DESCRIPTION "volume of the number of outgoing packets"
-- .1.3.6.1.4.1.39530.3.1.1.8 -- ::= { ccTrafficEntry 8 }
ccTrafficGeneratedPacketsCount OBJECT-TYPE
STATUS current
DESCRIPTION "number of generated packets"
-- .1.3.6.1.4.1.39530.3.1.1.9 -- ::= { ccTrafficEntry 9 }
ccTrafficGeneratedVolume OBJECT-TYPE
STATUS current
DESCRIPTION "volume of the number of generated packets"
-- .1.3.6.1.4.1.39530.3.1.1.10 -- ::= { ccTrafficEntry 10 }

ccTrafficRejectedPacketsCount OBJECT-TYPE
STATUS current
DESCRIPTION "number of rejected packets"
-- .1.3.6.1.4.1.39530.3.1.1.11 -- ::= { ccTrafficEntry 11 }
ccTrafficRejectedVolume OBJECT-TYPE
STATUS current
DESCRIPTION "volume of the number of rejected packets"
-- .1.3.6.1.4.1.39530.3.1.1.12 -- ::= { ccTrafficEntry 12 }
ccTraps OBJECT-IDENTITY
STATUS current
DESCRIPTION "Definition point for CC notifications."
-- .1.3.6.1.4.1.39530.0 -- ::= { cleaning-center 0 }
-- Traps
ccSystemAlert OBJECT-IDENTITY
STATUS current
DESCRIPTION "Definition point for various system alerts."
-- .1.3.6.1.4.1.39530.0.1 -- ::= { ccTraps 1 }
ccSystemStorageSuspendedAlert NOTIFICATION-TYPE
OBJECTS { ccAnalyzerName,
ccAlertSeverity
}
STATUS current
DESCRIPTION "Traffic storage onto disk suspended"
-- .1.3.6.1.4.1.39530.0.1.1 -- ::= { ccSystemAlert 1 }
ccSystemStorageResumedAlert NOTIFICATION-TYPE
ccAlertSeverity
}
STATUS current
DESCRIPTION "Traffic storage onto disk resumed"
-- .1.3.6.1.4.1.39530.0.1.2 -- ::= { ccSystemAlert 2 }
ccSystemOverloadAlert NOTIFICATION-TYPE
ccAlertSeverity
}
STATUS current
DESCRIPTION "System overload: frames dropped"
-- .1.3.6.1.4.1.39530.0.1.3 -- ::= { ccSystemAlert 3 }

ccSystemFarmCcDownAlert NOTIFICATION-TYPE
ccAlertSeverity
}
STATUS current
DESCRIPTION "Cleaning Center down in Group"
-- .1.3.6.1.4.1.39530.0.1.4 -- ::= { ccSystemAlert 4 }
ccSystemFarmCcUpAlert NOTIFICATION-TYPE
ccAlertSeverity
}
STATUS current
DESCRIPTION "Cleaning Center has joined Group"
-- .1.3.6.1.4.1.39530.0.1.5 -- ::= { ccSystemAlert 5 }
ccSystemFarmGroupEmptyAlert NOTIFICATION-TYPE
ccAlertSeverity
}
STATUS current
DESCRIPTION "No Cleaning Center up in Group"
-- .1.3.6.1.4.1.39530.0.1.6 -- ::= { ccSystemAlert 6 }
ccSystemFarmCcAloneAlert NOTIFICATION-TYPE
ccAlertSeverity
}
STATUS current
DESCRIPTION "Only one Cleaning Center in Group"
-- .1.3.6.1.4.1.39530.0.1.7 -- ::= { ccSystemAlert 7 }
ccSystemStatisticsSuspendedAlert NOTIFICATION-TYPE
ccAlertSeverity
}
STATUS current
DESCRIPTION "Statistics computation suspended"
-- .1.3.6.1.4.1.39530.0.1.8 -- ::= { ccSystemAlert 8 }
ccSystemStatisticsResumedAlert NOTIFICATION-TYPE
ccAlertSeverity
}
STATUS current
DESCRIPTION "Statistics computation resumed"
-- .1.3.6.1.4.1.39530.0.1.9 -- ::= { ccSystemAlert 9 }
ccSystemLogFailureAlert NOTIFICATION-TYPE
ccAlertSeverity
}
STATUS current

DESCRIPTION "Log discarded or overwritten"

-- .1.3.6.1.4.1.39530.0.1.10 -- ::= { ccSystemAlert 10 }
ccSystemRingBufferAlert NOTIFICATION-TYPE
ccAlertSeverity
}
STATUS current
DESCRIPTION "Capture dumping: full ring-buffer"
-- .1.3.6.1.4.1.39530.0.1.11 -- ::= { ccSystemAlert 11 }
ccSystemIllegalFrameAlert NOTIFICATION-TYPE
ccAlertSeverity
}
STATUS current
DESCRIPTION "Illegal frames received"
-- .1.3.6.1.4.1.39530.0.1.12 -- ::= { ccSystemAlert 12 }
ccTrafficAlert OBJECT-IDENTITY
STATUS current
DESCRIPTION "Definition point for various traffic alerts."
-- .1.3.6.1.4.1.39530.0.2 -- ::= { ccTraps 2 }
ccTrafficDosAlert NOTIFICATION-TYPE
ccAlertClassification,
ccAlertSeverity,
ccTrafficServiceName,
ccTrafficId
}
STATUS current
DESCRIPTION "Filtered traffic over threshold: suspected DoS attack on
service"
-- .1.3.6.1.4.1.39530.0.2.1 -- ::= { ccTrafficAlert 1 }
ccTrafficRateAlert NOTIFICATION-TYPE
ccAlertSeverity,
ccTrafficId
}
STATUS current
DESCRIPTION "Unexpected traffic rate on service"
-- .1.3.6.1.4.1.39530.0.2.2 -- ::= { ccTrafficAlert 2 }
ccTrafficScanAlert NOTIFICATION-TYPE
ccAlertSeverity,

ccAlertSourceAddress,
ccTrafficId
}
STATUS current
DESCRIPTION "Scan on service"
-- .1.3.6.1.4.1.39530.0.2.3 -- ::= { ccTrafficAlert 3 }
ccTrafficFloodAlert NOTIFICATION-TYPE
ccAlertSeverity,
ccAlertTargetAddress,
ccTrafficId
}
STATUS current
DESCRIPTION "Flood on service"
-- .1.3.6.1.4.1.39530.0.2.4 -- ::= { ccTrafficAlert 4 }
ccTrafficDnsFloodAlert NOTIFICATION-TYPE
ccAlertSeverity,
ccTrafficId
}
STATUS current
DESCRIPTION "DNS subdomain request flood on service"
-- .1.3.6.1.4.1.39530.0.2.5 -- ::= { ccTrafficAlert 5 }
ccTrafficPacketAlert NOTIFICATION-TYPE
ccAlertSeverity,
ccAlertTargetAddress
}
STATUS current
DESCRIPTION "Repeated abnormal requests with invalid header length"
-- .1.3.6.1.4.1.39530.0.2.6 -- ::= { ccTrafficAlert 6 }
ccTrafficCachePoisonAlert NOTIFICATION-TYPE
ccAlertSeverity,
ccAlertTargetAddress
}

STATUS current
DESCRIPTION "Cache poisoning: Transaction ID collision"
-- .1.3.6.1.4.1.39530.0.2.7 -- ::= { ccTrafficAlert 7 }
-- Conformance
ccMibConformance OBJECT IDENTIFIER

-- .1.3.6.1.4.1.39530.4 -- ::= { cleaning-center 4 }
ccMibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "Compliance declaration for cleaning center MIB."
MODULE -- This module
MANDATORY-GROUPS { ccIdmefGroup,
ccSystemGroup,
ccTrafficGroup,
ccNotificationGroup
}
-- .1.3.6.1.4.1.39530.4.1 -- ::= { ccMibConformance 1 }
ccIdmefGroup OBJECT-GROUP
OBJECTS {
ccAnalyzerId,
ccAnalyzerName,
ccAnalyzerManufacturer,
ccAnalyzerModel,
ccAnalyzerVersion,
ccAlertId,
ccAlertSeverity,
ccAlertCreateTime,
ccAlertDetectTime,
ccAlertAnalyzerTime,
ccAlertSourceAddressType,
ccAlertSourceName,
ccAlertTargetAddressType,
ccAlertTargetName,
ccAlertAdditionalMeaning,
ccAlertAdditionalValue
}
STATUS current
DESCRIPTION "Collection of IDMEF MIB objects."
ccSystemGroup OBJECT-GROUP
OBJECTS {
ccUpTime,
ccLastHeartbeat,
ccLastConfiguration,

ccAverageCpuLoad,
ccFifoSize,
ccNumberOfServices
}
STATUS current
DESCRIPTION "Collection of System MIB objects."
ccTrafficGroup OBJECT-GROUP
OBJECTS {
ccTrafficRowStatus,
ccTrafficModuleName,
ccTrafficIncomingPacketsCount,
ccTrafficIncomingVolume,
ccTrafficOutgoingPacketsCount,
ccTrafficOutgoingVolume,
ccTrafficGeneratedPacketsCount,
ccTrafficGeneratedVolume,
ccTrafficRejectedPacketsCount,
ccTrafficRejectedVolume
}
STATUS current
DESCRIPTION "Collection of Traffic MIB objects."
ccNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
ccSystemStorageSuspendedAlert,
ccSystemStorageResumedAlert,
ccSystemOverloadAlert,
ccSystemFarmCcDownAlert,
ccSystemFarmCcUpAlert,
ccSystemFarmGroupEmptyAlert,
ccSystemFarmCcAloneAlert,
ccSystemStatisticsSuspendedAlert,
ccSystemStatisticsResumedAlert,
ccSystemLogFailureAlert,
ccSystemRingBufferAlert,
ccSystemIllegalFrameAlert,
ccTrafficDosAlert,
ccTrafficRateAlert,
ccTrafficScanAlert,
ccTrafficFloodAlert,
ccTrafficDnsFloodAlert,
ccTrafficPacketAlert,
ccTrafficCachePoisonAlert
}
STATUS current
DESCRIPTION "Collection of notifications."

END

Annexe D – Nomenclature SNMP

Alertes système
Classification OID Paramètres Description

Storage suspended .0.1.1 Analyzer name Traffic storage onto disk suspended
Alert severity
Storage resumed .0.1.2 Analyzer name Traffic storage onto disk resumed
Alert severity
System overload .0.1.3 Analyzer name System overload: frames dropped
Alert severity
Farm CC down .0.1.4 Analyzer name Cleaning Center down in Group
Alert severity
Farm CC up .0.1.5 Analyzer name Cleaning Center has joined Group
Alert severity
Farm group empty .0.1.6 Analyzer name No Cleaning Center up in Group
Alert severity
Farm CC alone .0.1.7 Analyzer name Only one Cleaning Center in Group
Alert severity
Statistics suspended .0.1.8 Analyzer name Statistics computation suspended
Alert severity
Statistics resumed .0.1.9 Analyzer name Statistics computation resumed
Alert severity
Log failure .0.1.10 Analyzer name Log discarded or overwritten
Alert severity
Ring buffer .0.1.11 Analyzer name Capture dumping : full ring-buffer
Alert severity
Illegal frames .0.1.12 Analyzer name Illegal frames received
Alert severity
58 Annexe D – Nomenclature SNMP | 6cure SAS

Alertes trafic
Classification OID Paramètres Description

DoS .0.2.1 Analyzer name Filtered traffic over threshold: suspected
Alert classification DoS attack on service
Alert severity
Service name
Rate .0.2.2 Analyzer name Unexpected traffic rate on service
Alert classification
Alert severity
Service name
Scan .0.2.3 Analyzer name Scan on service
Alert severity
Source address
Service name
Flood .0.2.4 Analyzer name Flood on service
Alert severity
Source address
Target address
Service name
DNS flood .0.2.5 Analyzer name DNS subdomain request flood on service
Alert severity
Source address
Target address
Service name
Packet .0.2.6 Analyzer name Repeated abnormal requests with invalid
Alert classification header length
Alert severity
Source address
Target address
Cache Poison .0.2.7 Analyzer name Cache poisoning: Transaction ID collision
Alert severity
Source address
Target address
6cure SAS | Annexe D – Nomenclature SNMP 59

Contact
Pour tout renseignement concernant ce document, prière de contacter :
Nom Prénom (6cure SAS) Téléphone Messagerie

6cure Support +33 02 50 01 15 39 support@6cure.com
60 Contact | 6cure SAS

6cure - TP Correlator - v1 0 9

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

6cure - TP Correlator - v1 0 9

Transféré par

Droits d'auteur :

Formats disponibles

Tel. +33 250 011 509

Société par Actions Simplifiée au capital de 114900 €.

© 2014-2015 6cure SAS. Tous droits réservés. 6cure et le

Table des matières

Table des tableaux & figures

Tableau 1 ■ Paramètres pour les alertes « trafic » .................................................................................................. 11

Figure 1 ■ Architecture de composants du produit 6cure Threat Protector.......................................................... 6

6cure SAS | Présentation générale 5

La relation interne entre ces composants est illustrée dans la Figure 1.

Figure 1 ■ Architecture de composants du produit 6cure Threat Protector.

6 Présentation générale | 6cure SAS

La relation interne entre ces composants est illustrée dans la Figure 2.

Figure 2 ■ Architecture de composants du produit 6cure Threat Manager.

1.2. Principes de production et traitement d’alertes

6cure SAS | Présentation générale 7

8 Présentation générale | 6cure SAS

2.2. Configuration de production d’alertes

Ce fichier est structuré selon quatre sections :

1. Spécification des formats de sortie (balise <OutputFormat>)

2.2.1. Spécification des formats de sortie

Plusieurs formats de production d’alertes sont disponibles sur le 6cure TP :

6cure SAS | Configuration 9

Pour chaque format, il est possible de spécifier :

• le statut (status) : peut être actif : ‘enabled’ ou inactif : ‘disabled‘ ;

2.2.2. Gestion des alertes « trafic »

10 Configuration | 6cure SAS

Tableau 1 ■ Paramètres pour les alertes « trafic »

Paramètre Description Valeur par défaut

6cure SAS | Configuration 11

durée du silence nécessaire à la production d’une nouvelle alerte « non

Tableau 2 ■ Paramètres pour les alertes « trafic rate »

Paramètre Description Valeur par défaut

12 Configuration | 6cure SAS

status état (actif/inactif) disabled

2.2.3. Gestion des alertes « système »

6cure SAS | Configuration 13

• Alertes « LoadMonitor » : alertes générées lorsque le TP n’est plus en mesure d’assurer la

Tableau 3 ■ Paramètres pour les alertes « système »

Paramètre Description Valeur par défaut

14 Configuration | 6cure SAS

2.2.4. Gestion des alertes « filtrage »

Tableau 4 ■ Paramètres génériques pour les alertes « filtrage »

Paramètre Description Valeur par défaut

6cure SAS | Configuration 15

Tableau 5 ■ Paramètres spécifiques pour les alertes « filtrage »

Paramètre Description Valeur par défaut

Tableau 6 ■ Paramètres spécifiques pour les alertes sémantiques de « filtrage »

Paramètre Description Valeur par défaut

2.3. Prise en compte des modifications

16 Configuration | 6cure SAS

$ 6curectl tp-correlator {restart|reload}

6cure SAS | Configuration 17

3.1. Principes d’agrégation

• une période (glissante) de référence (ex. : 60 secondes)

Ainsi, pour un phénomène donné, trois périodes se succèdent :

Ces principes sont illustrés dans la Figure 3 où :

• t0 représente la date initiale de début du phénomène (instant de production du premier message

18 Corrélation d’alertes | 6cure SAS

• ∆ représente la durée du silence nécessaire pour confirmer la fin du phénomène ;

Figure 3 ■ Principes génériques d’agrégation locale de messages.

Tableau 7 ■ Critères de similarité pour l’agrégation locale de messages

Type d’alertes Critères de similarité