Utiliser l’Experience Center pour tester vos règles
Dans le dernier article de la série autour de la création d’un mini-SOC, nous avons vu comment créer des règles de détection pour pouvoir détecter les méchantes personnes qui veulent du mal à vos pauvres machines ou sites web.
Néanmoins dans l’article, je vous présentais directement une solution fonctionnelle sans plus de tests que cela. C’est parce que j’ai préféré réserver tout un article sur la face cachée derrière le développement d’une règle de détection, les tests, les ajustements, les échecs… parce que oui parfois, ce que l’on pense être correct s’avère ne pas l’être et il faut pouvoir analyser pourquoi ?
Pour répondre à cette question, il existe plusieurs moyens et je ne vais pas tous vous les décrire pour la simple et bonne raison que je ne les ai pas tous assez éprouvés pour être en mesure de les juger. De plus, le moyen que j’ai choisi est souvent, de mon expérience, négligé par les utilisateurs de la solution QRadar.
Ce moyen n’est autre que l’extension "Experience Center". Rentrons tout de suite dans le vif du sujet avec l’installation.
2. Installation de l’Experience Center
Et oui ! Ce n’est pas nativement inclus dans votre QRadar 😥 – les extensions sont ce qui permet à cette solution d’être très modulaire et adaptable, grâce notamment à la communauté mais cela implique qu’il faut souvent mettre les mains dans le code.
Heureusement pour vous, cette extension est plutôt facile à installer et il vous faudra 2 choses :
- Télécharger l’extension depuis l’Exchange App
- Créer un token avec les droits suffisants sur votre QRadar
Pour le premier point, il faut vous rendre à l’adresse suivante : IBM App Exchange avec un compte IBM puis cliquer sur télécharger.
Pour le deuxième point, il faut aller sur votre instance QRadar dans l’onglet "Admin" puis "Authorized Services" (https://<instance QRadar>/console/do/qradar/authorizedService?dispatch=authorizedServiceList) et créer un token avec les mêmes droits que ci-dessous (surligné en gris foncé) :
Pour l’installation, copier le token (caché derrière le trait vert dans l’image ci-dessus) dans un coffre-fort à mots de passe ou temporairement dans un éditeur de texte non enregistré.
Ensuite, il faut installer l’extension via "Admin>Extensions Management" ou directement avec le lien suivant : https://<instance QRadar>/console/do/qradar/extensionsManagementConsole. Sur cette page vous faites :
- "Add"
- "Browse" dans le popup qui apparaît
- Sélectionner le fichier "Experience_Center_<version>.zip" qui est sur votre ordinateur
- "Ouvrir"
- Cocher "Install immediatly" puis "Add"
- Valider l’installation des différents composants (custom properties, log source…)
Enfin, pour compléter l’installation un "Full Deploy" va être nécessaire, vous pouvez le faire en GUI en allant dans "Admin" puis "Advanced>Deploy Full Configuration" comme ci-dessous :
Après cela, l’extension est pleinement opérationnelle comme nous allons le voir dans la partie suivante en regardant ce qui la compose.
3. Présentation de l’extension
L’extension "Experience Center" est accessible sur la GUI de QRadar comme ceci :
Les différents menus sont les suivants :
- Overview of QRadar qui est une présentation de l’outil
- Threat Simulator qui permet de lancer des simulations d’attaques
- Upload logs to QRadar qui permet de téléverser des logs personnalisés depuis votre environnement vers QRadar
- Play logs in QRadar offre la possibilité de jouer les jeux de logs qui sont à votre disposition parmi lesquels vous retrouverez ceux téléversés dans le menu précédent
- Analyze your logs qui présente comment analyser les résultats par le biais de tutoriaux vidéos notamment
- Useful links regroupe quelques liens de documentation et d’aide
Dans la suite de cet article nous nous concentrerons sur 2 menus :
- Upload logs to QRadar puisqu’il va nous permettre d’ajouter nos échantillons de logs personnalisés
- Play logs in QRadar qui va être utile pour le lancement de nos tests
Avant de clôturer sur la partie présentation de l’extension, j’aimerais faire un rapide point sur le menu "Threat Simulator" qui contient des scénarii pré-faits (avec des log sources, règles de détections, custom properties etc) adaptés. Il permet, avec l’aide de la documentation associée pour chaque scénario, une meilleure compréhension de comment est faite la détection pour telle ou telle menace, ce que cela implique de mettre en place un tel scénario fonctionnel… Je trouve donc cela très pédagogique si vous souhaitez en apprendre plus sur le sujet pour pouvoir par la suite renforcer votre détection.
4. Test de fonctionnement de règle
a. Prérequis
Avant de pouvoir se lancer dans les tests, il va nous falloir quelques prérequis à avoir pour que tout se passe pour le mieux :
- Une règle à tester qui génère des événements (pour plus de détails sur la création de la règle et sur les actions faites je vous renvoie vers mon précédent article)
- Une log source vers laquelle les logs de test seront envoyés, ce n’est pas obligatoire puisque si vous ne faites pas ça les logs arriveront dans la log source "SIM Generic" mais c’est plus structuré d’avoir des log sources de test
- Un fichier de logs à tester
Pour le deuxième point, je vous conseille de faire des log sources comme ci-dessous :
Les points importants pour vos log sources sont :
- Protocol Type = Syslog
- Log Source Identifier = <une chaîne de caractères simple et n’entrant pas en conflit avec la production>
b. Génération de fichier de logs
Maintenant que nous avons nos log sources prêtes, il nous faut des événements à tester, pour cela il faut d’abord que je précise que nous allons mettre à l’épreuve les règles mentionnées dans mon précédent article, à savoir :
- Une règle pour identifier le bruteforce sur un htaccess
- Une règle pour détecter les connexions depuis des IPs identifiées comme malveillantes
Pour la première règle, nous avions identifié que les événements avec un QID de "4750002" nous permettaient de détecter les échecs de connexion à un htaccess. De plus, nous savons que les événements sont sous cette forme :
Avec :
- en rouge des informations relatives à la date de l’événement
- en vert le nom de la log source (hostname ici)
- en bleu l’IP du client tentant de se connecter
- en jaune des informations relatives à la connexion (nom d’utilisateur et fichier accédé)
En modifiant les parties sensibles avec des informations génériques et en retirant la partie ajoutée par le formatage syslog (tout ce qu’il y a du début du log jusqu’au log source identifier inclus) nous obtenons le log suivant :
apache2-error [Thu Nov 24 15:57:33.319995 2022] [auth_basic:error] [pid 25639] [client 10.10.10.10:41200] AH01617: user test: authentication failure for "/wp-admin/js/user-profile.min.js": Password Mismatch, referer: https://somewebsite.com/login.phpMaintenant que nous avons notre premier log, nous allons le dupliquer 6 fois pour que cela dépasse le seuil de 5 qui est défini dans la règle. Ainsi on obtient le fichier "htaccess_bruteforce.log" que vous retrouverez en annexe.
Pour la seconde règle, il nous faut tout simplement un log d’authentification réussie comme celui ci-dessous :
Avec :
- en rouge des informations relatives à la date de l’événement
- en vert le nom de la log source (hostname ici)
- en bleu l’IP du client tentant de se connecter
- en jaune des informations relatives à la connexion (nom d’utilisateur)
En modifiant les parties sensibles avec des informations génériques et en retirant la partie ajoutée par le formatage syslog (tout ce qu’il y a du début du log jusqu’au log source identifier inclus, ici le hostname) nous obtenons le log suivant :
sshd[3536]: Accepted password for toto from 10.10.10.10 port 54484 ssh2De par la conception de la règle, nous n’avons pas besoin de dupliquer le log plus d’une fois comme pour la première règle. Ainsi on obtient le fichier "malicious_authentication.log" que vous retrouverez en annexe.
c. Test de règle
Enfin, nous y voilà ! Dans cette dernière partie, nous allons pouvoir valider le bon fonctionnement des règles. Dans un premier temps, il faut téléverser les fichiers de log générés juste avant dans QRadar. Pour y arriver, aller dans le menu Upload logs to QRadar de l’application "Experience Center" puis sélectionner vos fichiers et cliquer sur "Next".
Une fois les fichiers téléversés, ils apparaîtront dans le menu Play logs in QRadar comme dans la capture ci-dessous :
Nous sommes quasiment prêt pour lancer l’échantillon de logs, il faut maintenant :
- vous placer dans le menu "Log Activity" de QRadar avec les bons filtres à savoir :
- Log Source is any of [LinuxServer @ simulation or Custom Rule Engine-<X>]
- vous mettre en vue "Real Time" pour avoir les logs en direct
- mettre le log source identifier de votre log source de simulation dans le panel de l’Experience Center comme ceci :
Vous pouvez désormais lancer la simulation en cliquant sur le bouton "Play" (fléché sur la capture ci-dessus). Après quelques secondes on obtient le résultat suivant :
Cette simulation montre bien qu’au bout de 5 tentatives, la règle apparaît (surlignée en rose dans la capture) comme il faut. Nous pouvons donc passer au deuxième test dont voici les résultats :
Dans la capture, j’ai volontairement laissé les précédents événements pour montrer la continuité de l’attaque évoquée dans le précédent article. On voit que le deuxième test génère le log surligné en bleu et que tout de suite après la règle sonne comme il se doit.
5. Conclusion
Et voilà ! Vous êtes en mesure d’utiliser les pleins potentiels de l’extension "Experience App", que cela soit pour tester vos règles comme nous avons pu le voir mais également pour challenger des scénarii d’attaques que l’on peut retrouver sur internet.
N’hésitez pas à me faire un retour sur cet article mais aussi à partager vos idées d’utilisation de cet outil ou encore vos logs de test avec les règles associées (on pense bien à obfusquer le tout bien évidemment 😋)
6. Bibliographie
- Documentation IBM sur l’extension : IBM Experience Center App.pdf
7. Annexes
htaccess_bruteforce.log :
apache2-error [Thu Nov 24 15:57:51.319995 2022] [auth_basic:error] [pid 25639] [client 10.10.10.10:41200] AH01617: user test: authentication failure for "/wp-admin/js/user-profile.min.js": Password Mismatch, referer: https://somewebsite.com/login.php
apache2-error [Thu Nov 24 15:57:41.319995 2022] [auth_basic:error] [pid 25639] [client 10.10.10.10:41200] AH01617: user test: authentication failure for "/wp-admin/js/user-profile.min.js": Password Mismatch, referer: https://somewebsite.com/login.php
apache2-error [Thu Nov 24 15:57:31.319995 2022] [auth_basic:error] [pid 25639] [client 10.10.10.10:41200] AH01617: user test: authentication failure for "/wp-admin/js/user-profile.min.js": Password Mismatch, referer: https://somewebsite.com/login.php
apache2-error [Thu Nov 24 15:57:21.319995 2022] [auth_basic:error] [pid 25639] [client 10.10.10.10:41200] AH01617: user test: authentication failure for "/wp-admin/js/user-profile.min.js": Password Mismatch, referer: https://somewebsite.com/login.php
apache2-error [Thu Nov 24 15:57:11.319995 2022] [auth_basic:error] [pid 25639] [client 10.10.10.10:41200] AH01617: user test: authentication failure for "/wp-admin/js/user-profile.min.js": Password Mismatch, referer: https://somewebsite.com/login.php
apache2-error [Thu Nov 24 15:57:01.319995 2022] [auth_basic:error] [pid 25639] [client 10.10.10.10:41200] AH01617: user test: authentication failure for "/wp-admin/js/user-profile.min.js": Password Mismatch, referer: https://somewebsite.com/login.phpmalicious_authentication.log :
sshd[3536]: Accepted password for toto from 10.10.10.10 port 54484 ssh2