Chapitre III : Tests et évaluations
Pour détecter cette attaque nous allons nous servir de
Suricata qui détecte les scan Nmap et créer un log à
chaque 40 port scanner et le log crée contient le champs rule name : "ET
SCAN Possible Nmap User-Agent Observed"
Une fois qu'on lance un scan nmap il scan les 1000 ports les
plus fréquent et pour un scan nmap on aura au minimum 25 log venant de
suricata.
Pour créer cette nouvelle règle on fait Security
? Detections ? Manage detection rules ? Create new rules, on choisit Threshold
ce qui correspond au type de règle qu'on veut créer puis on met
index filebeat-* et on met la requête :
Rule.name : "ET SCAN Possible Nmap User-Agent Observed"
Cette requête va chercher dans l'index filebeat-*
tous les logs qui dans rule.name contient la phrase :
"ET SCAN Possible Nmap User-Agent Observed"
Et dans "Threshold" on met 25 qui correspond exactement à
un scan normal de port Nmap
Figure 74 : Création de la règle
pour la détection de scan Nmap section "Define rule "
70
Chapitre III : Tests et évaluations
On indique "Nmap scan Detected" comme nom de la règle, une
petite description, un tag pour notre alerte et 2 minutes comme temps de
vérification de l'alerte.
Figure 75 : Création de la règle
pour la détection de scan Nmap section "Schedule rule "
On enregistre notre règle de détection puis
à travers notre machine Kali Linux nous lançons le scan Nmap pour
tester notre règle.
On lance la commande "nmap -A 192.168.10.140" pour scanner les
ports et ainsi afficher les ports ouverts.
Figure 76 : Scan Nmap sur Kali Linux
71
72
Chapitre III : Tests et évaluations
Une fois notre scan nmap terminé et 2 minutes (selon le
temps défini) on voit une alerte qui apparait.
Figure 77 : Alerte "Nmap scan Detected"
3.5 Attaque de Brute force des répertoires d'un
serveur Web (Fuzzing Web)
Brute forcer les répertoires d'un serveur Web peut
être utile pour trouver des informations confidentielles, qui n'auraient
pas dû être disponibles à un utilisateur lambda. Cela permet
aussi de comprendre un peu mieux l'architecture du site Web (l'utilisation par
exemple d'applications ou de frameworks open source vulnérables), ce qui
permet à un attaquant d'arriver assez rapidement à une
exploitation possible pour prendre le contrôle, ou infecter le
système de programmes malveillants. Pour plus d'information voir [13]
L'attaque consiste à travers un fuzzer exécuter
des requêtes http contenant dans l'URL des noms de répertoire et
des noms de fichier et à travers le résultat il va
déterminer si ces répertoires et fichier existe ou pas. Pour
cette attaque un tas de log avec le code d'erreur 404 va se créer
puisque à chaque répertoire non trouver un 404 apparait. Donc on
va se servir de log de notre serveur web dans notre cas apache pour
détecter cette attaque.
Pour ce test un site web a été héberger sur
la machine Ubuntu.
Comme les autres règle d'alerte on crée une
règle pour cette attaque avec les caractéristiques suivantes :
Index patterns : filebeat-*
Custom query : log.file.path :
"/var/log/apache2/access.log" and http.response.status_code : "404"
Cette requête permet d'aller chercher dans le fichier
/var/log/apache2/access.log toute les requête http dont le code d'erreur
correspond au 404.
Threshold : 200
Field : user_agent.os.name
Name : Web Fuzzing Attack Detected
DescrIPtion : (Personnalisable)
Default Severity : Medium
Chapitre III : Tests et évaluations
Figure 78 : Création de la règle
pour la détection du fuzzing web "Define rule"
Figure 79 : Création de la règle
pour la détection du fuzzing web "About rule"
Une fois la règle crée on lance l'attaque
à travers l'outil "dirb" sur la machine Kali Linux qui va nous permettre
de faire le brute force des répertoires de notre serveur web
situé sur la machine Ubuntu.
Figure 80 : Attaque avec dirb sur notre
serveur web
73
74
| 
