Contexte : En tant que leader mondial de l'importation et de l'exportation, Vandalay Industries a été la cible de nombreux adversaires tentant de perturber leurs activités en ligne. Récemment, Vandaly a été victime d'attaques DDOS contre ses serveurs Web.
Non seulement les serveurs Web ont été mis hors ligne par une attaque DDOS, mais les vitesses de téléchargement ont également été considérablement affectées après la panne. Votre équipe réseau a fourni les résultats d’une vitesse de réseau au moment de la dernière attaque DDOS.
Fichier de test de vitesse
Capture d'écran du fichier « server_speedtest.csv » téléchargé dans Splunk :
eval , créez un champ appelé ratio qui affiche le rapport entre les vitesses de téléchargement et de téléchargement. Astuce : Le format pour créer un ratio est le suivant : | eval new_field_name = 'fieldA' / 'fieldB'
Requête utilisée dans Splunk pour générer un rapport entre les vitesses de téléchargement et de téléchargement - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS
Nous pouvons voir le ratio de téléchargements et d’uploads à partir de cette requête.
_timeIP_ADDRESSDOWNLOAD_MEGABITSUPLOAD_MEGABITSratioAstuce : utilisez le format suivant pour la commande table : | table champA champB champC
Requête utilisée dans Splunk pour générer un rapport entre les vitesses de téléchargement et de téléchargement - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS | table _time, IP_ADDRESS, DOWNLOAD_MEGABITS, UPLOAD_MEGABITS, ratio
À partir de la capture d'écran ci-dessus, nous pouvons voir la chronologie totale des événements, à savoir le moment où les téléchargements et les mises en ligne ont eu lieu.
À partir de la capture d'écran ci-dessus, nous pouvons voir l'heure à laquelle les téléchargements ont eu lieu ainsi que l'adresse IP source qui a effectué cette action.
À partir de la capture d'écran ci-dessus, nous pouvons voir une représentation visuelle de ces événements de téléchargement et de téléchargement sous forme de graphique à colonnes. L'heure est affichée en bas et cela rend nos données beaucoup plus lisibles.
Sur la base de nos résultats dans les requêtes ci-dessus, nous pouvons constater que la vitesse de téléchargement et de téléchargement a été considérablement réduite vers 14h30 le 23 février. Nous pouvons le voir dans la capture d'écran ci-dessous :
Nous pouvons voir les téléchargements tomber à 7,87 à 14h30. Il s’agit d’une baisse drastique par rapport aux 109,16 mégabits de l’événement précédent. Il est donc juste de supposer que c'était à peu près le moment où l'attaque a commencé.
Nous pouvons voir sur la capture d’écran ci-dessus que les mégabits téléchargés sont passés de 17,56 à 65,34, ce qui représente une augmentation drastique. Par conséquent, il est raisonnable de supposer que c'est à peu près au moment où le système a commencé à récupérer et à revenir au flux de trafic réseau normal.
Nous pouvons voir sur la capture d'écran ci-dessus que les mégabits téléchargés sont passés de 78,34 à 123,91 vers 23h30 le 23 février. On peut supposer que c'est à peu près le moment où le flux de trafic réseau s'est stabilisé et est revenu à la normale.
Soumettez une capture d'écran de votre rapport et la réponse aux questions ci-dessus.
Contexte : En raison de la fréquence des attaques, votre responsable doit s'assurer que les données sensibles des clients sur ses serveurs ne sont pas vulnérables. Puisque Vandalay utilise les scanners de vulnérabilités Nessus, vous avez extrait les dernières 24 heures d'analyses pour voir s'il existe des vulnérabilités critiques.
Pour plus d'informations sur Nessus, lisez le lien suivant : https://www.tenable.com/products/nessus
Résultats de l'analyse Nessus
Capture d'écran des résultats de l'analyse Nessus téléchargés dans Splunk :
10.11.36.23 . Utilisez dest_ip="10.11.36.23" dans la requête
Il convient de noter qu'il existe 5 types de niveaux de gravité recherchés par ces journaux, comme indiqué ci-dessous :
Nous souhaitons filtrer toutes les vulnérabilités dont le niveau de gravité est une valeur « critique ». Nous pouvons utiliser severity="crtiical" dans notre requête.
La requête entière est source="nessus_logs.csv" dest_ip="10.11.36.23" severity="critical"
Voir la capture d'écran ci-dessous pour l'intégralité de la requête qui affiche le nombre de vulnérabilités critiques du serveur de base de données client à partir de ce fichier journal :
Au total, 49 vulnérabilités critiques ont été découvertes lorsque l'adresse IP de destination était 10.11.36.23 (qui est le serveur de base de données).
[email protected] .Créez l'alerte en cliquant sur « Enregistrer sous », puis sur « Alerte » après avoir généré nos résultats à partir de la requête ci-dessus :
Entrez les détails pour générer des alertes chaque fois que Nessus détecte une vulnérabilité sur le serveur de base de données. Entrez le nom, la description et toute autre information relative :
Entrez les détails de l'e-mail pour envoyer l'alerte générée à - [email protected] et entrez les détails du message à envoyer avec l'e-mail :
Continuez à saisir les détails de l'alerte, puis cliquez sur « Enregistrer » :
Une fois enregistrée, nous devrions pouvoir voir l'alerte et la modifier si nous le souhaitons :
Soumettez une capture d'écran de votre rapport et une capture d'écran prouvant que l'alerte a été créée.
Contexte : Un serveur Vandalay subit également des attaques par force brute sur son compte administrateur. La direction souhaite que vous mettiez en place une surveillance pour informer l'équipe SOC si une attaque par force brute se reproduit.
Connexions administrateur
Capture d'écran du fichier « Administrator_logs.csv » téléchargé dans Splunk :
Conseils :
Recherchez le champ de nom pour trouver les connexions ayant échoué.
A noter que l'attaque a duré plusieurs heures.
Parce que nous souhaitons rechercher tout indicateur d'une attaque par force brute, nous souhaitons analyser les journaux dans lesquels les comptes n'ont pas réussi à se connecter. Si nous naviguons vers le champ « nom », nous pouvons voir les valeurs qu'il contient dans les journaux. Dans ce cas, nous pouvons voir un décompte de 1004 « Échec de la connexion d'un compte ». C’est un bon indicateur d’une attaque par force brute. Voir capture d'écran :
Maintenant, si nous ajoutons cela à notre recherche, nous pouvons voir le total des événements au moment où cela s'est produit. Nous pouvons alors voir quand la majorité de ces événements ont eu lieu, ce qui est un bon indicateur du moment où cela s'est produit. Voir capture d'écran :
Comme nous pouvons le constater, vers 9 heures du matin le 21 février, il y a un pic assez important d'événements où "Un compte n'a pas pu se connecter". Nous pouvons voir que sur un total de 1 004 événements survenus, à 9 heures du matin, il y avait 124 de ces événements et des nombres similaires apparaissant dans les heures qui ont suivi. Ainsi, je pense que l’attaque a commencé à cette heure-là – à 9 heures du matin le 21 février 2020.
Nous pouvons voir à partir de la chronologie de ces événements que 124 représente un pic considérable. Dans les heures qui ont précédé cet événement, le plus grand nombre de mauvaises connexions était d'environ 23. Nous pouvons considérer ce comportement normal. Voir capture d'écran :
En gardant cela à l'esprit et en tenant compte du fait qu'il y a eu environ 124 à 135 tentatives de connexion lorsque l'attaque par force brute s'est produite, je considérerais une base de référence d'environ 40 mauvaises connexions par heure. J'aurais les plages de mauvaises connexions par heure comme suit :
[email protected] si elle est déclenchée.Pour créer une alerte pour ce type d'événement, j'ai suivi les étapes suivantes :
Cliquez sur « enregistrer sous » puis sur « alerte » :
Remplissez les détails de l'alerte, y compris quand la déclencher (tout ce qui dépasse 25 tentatives par heure) :
Entrez les détails d'une action. Dans ce cas, nous enverrons un email à [email protected] :
Enregistrez l'alerte et nous pourrons ensuite la visualiser :
Nous avons maintenant créé avec succès une alerte qui se déclenchera lorsqu'il y aura plus de 25 événements d'échec de connexion d'un compte.
Soumettez les réponses aux questions sur le timing, la référence et le seuil de la force brute. De plus, fournissez une capture d’écran comme preuve que l’alerte a été créée.
