Chapitre III : Tests et évaluations
Figure 55 : Manage detection rules
Puis on se rend dans "Create new rule"
Une fenêtre de configuration de la règle
s'affiche nous demandant de choisir le type de règle, Les types de
règle disponible dans Kibana sont les suivantes :
y' Custom query : règle basée
sur une requête, qui recherche les index définis et crée
une alerte lorsqu'un document correspond à la requête de la
règle.
y' Machine learning : règle de machine
learning, qui crée une alerte lorsqu'un travail de machine learning
découvre une anomalie au-dessus du seuil défini.
y' Threshold rules : recherche les index
définis et crée une alerte de détection lorsque le nombre
de fois où la valeur du champ spécifié atteint le seuil au
cours d'une seule exécution.
y' Event correlation : recherche les index
définis et crée une alerte lorsque les résultats
correspondent à une requête EQL (Event Query Language).
y' Indicator match : crée une alerte
lorsque les valeurs de champ d'index Elastic Security correspondent aux valeurs
de champ définies dans les modèles d'index d'indicateur
spécifiés.
Dans notre cas c'est le "Threshold rules" qui nous
intéresse et nous le choisissons puis dans index patterns on indique
l'index qui nous intéresse on peut choisir tous les index mais pour
réduire le temps de recherche on indique de préférence
l'index concerné qui est l'index filebeat-*.
61
Chapitre III : Tests et évaluations
Figure 56 : Configuration de la règle
section "Define rule"
Dans Custom query on met notre requête KQL :
log.file.path : "/var/log/secure" and message : "sshd " and
message : " Failed password "
Cette requête permet d'aller chercher dans le fichier
"/var/log/secure" qui est le fichier dans lequel se situe les logs SSH dans
CentOS puis récupérer tous les logs contenant les mot "sshd" et
"Failed password".
Dans Field on met host.hostname.keyword pour que l'alerte soit
générée pour chaque machine qui apparaît (on peut y
mettre aussi adresse IP) et dans "Threshold" nous indiquons le nombre de fois
d'apparition d'une réponse de la requête. Ici on a choisi 10
puisqu'on trouve qu'une personne légitime connaissant bien son mot de
passe ne va pas faire plus de 10 tentatives de connexion échouée
chaque minute. Ceci dépend de l'analyse qu'on a faite mais on peut y
indiquer le nombre de fois qu'on veut.
Figure 57 : Configuration de la règle
section "Define rule" 2
62
Chapitre III : Tests et évaluations
Dans "About rule" on met le nom de notre règle par ex :
"Potential SSH Brute force detected", puis on met une description et un tag qui
classera l'attaque.
L'option default severity contient ces différentes options
:
? Low : alertes qui présentent un
intérêt mais qui ne sont généralement pas
considérées comme des incidents de sécurité.
Parfois, une combinaison d'événements de faible gravité
peut indiquer une activité suspecte.
? Medium : alertes qui nécessitent une
enquête.
? High : alertes qui nécessitent une
enquête immédiate.
? Critical : alertes indiquant qu'il est
très probable qu'un incident de sécurité s'est produit.
Pour cette attaque nous allons définir le niveau de
sévérité à Medium puisque ça
nécessite une enquête.
Figure 58 : Configuration de la règle
brute force SSH `About rule'
Et enfin nous mettons le temps dans lequel nous voulons que
notre règle soit vérifiée soit 1 minutes (ce temps est
flexible selon notre règle).
Ce qui fait en conclusions qu'on aura une alerte à
chaque fois que notre requête est répéter plus de 10 fois
en 1 minutes.
63
| 
