Splunk Crash Course - Search Queries

Dans ce cas, nous avons importé l'ensemble de données BotsV1, fourni par Splunk eux-mêmes, sous forme d'index, qui est essentiellement une collection de données. Nous pouvons effectuer une recherche dans les données en accédant à l'application Search and Reporting depuis la Splunk page d'accueil et en saisissant la requête de recherche : index="botsv1" earliest=0 (comme il s'agit du seul index que nous avons créé, nous pouvons également utiliser index=*, qui est une recherche générique pour n'importe quel index. Nous pouvons constater que des centaines de milliers

d'événements ont été trouvés via cette requête de recherche. L'examen de ces données va prendre une éternité, et c'est là que les requêtes de recherche entrent en jeu.

Nous pouvons combiner des chaînes de texte, des noms de fichiers, des noms de processus, des adresses IP, des opérateurs et bien plus encore pour rechercher des données spécifiques dans notre index. Nous pensons que la meilleure façon de vous renseigner sur les requêtes de recherche est de simplement passer en revue quelques exemples ensemble. Nous allons couvrir :

• Recherche à l'aide de champs (champs sélectionnés, champs intéressants)
• Paires champ/valeur (opérateurs AND, OR, NOT)
• Wildcards
• Processus (champ Sysmon Image)

Recherche à l'aide de champs

Pour vous montrer le contenu des champs Splunk , nous allons accéder à l'application de recherche et de création de rapports et saisir la requête de recherche suivante dans la barre supérieure :

Que signifie réellement cette requête de recherche ?

• index= » botsv1″ — Nous voulons effectuer une recherche par rapport au jeu de données botsv1. Sinon, si nous avions plusieurs ensembles de données et que nous voulions effectuer une recherche parmi tous, nous utiliserions index=*
• earliest=0 — Si nous n'utilisions pas cet argument, qui indique de commencer Splunk à examiner le premier événement de l'ensemble de données, nous devrions modifier la plage de dates (à l'extrême gauche) sur Tout le temps, cette méthode est simplement plus simple

Maintenant, cet ensemble de données contient toujours des centaines de milliers d'événements, et il Splunk faudra un peu de temps pour les parcourir afin de trouver ceux qui répondent à nos critères de recherche, en l'occurrence tous. Pour vous faciliter la tâche, nous allons modifier la valeur d'échantillonnage (sous la barre de recherche sur la gauche) de Aucun échantillonnage d'événements

(tous les événements) à 1:100. Cela affichera 1 événement sur 100. Oui, nous allons manquer des événements, mais nous pouvons affiner notre requête de recherche puis désactiver l'échantillonnage des événements !

Bien, nous travaillons maintenant avec un échantillon de l'ensemble de données complet. Voyons donc ce que sont les champs. Sur le côté gauche de, vous Splunk pouvez voir « CHAMPS SÉLECTIONNÉS » et « CHAMPS INTÉRESSANTS ». Il s'agit d'informations qui ont été extraites des données brutes et triées par Splunk . Dans la capture d'écran ci-dessous, nous avons répertorié certains des champs intéressants. Cliquez sur celui du bas, « ComputerName ».

Dans la capture d'écran ci-dessous, vous pouvez voir que les informations de ce champ ont Splunk été extraites de tous les événements bruts de notre échantillon (1:100). Nous pouvons voir de nombreux

noms d'hôtes différents et le nombre d'événements dans lesquels ce nom figure. Par exemple, la valeur maximale we9748srv.waynecorpinc.local figure dans 1473 événements.

Revenons à la section « CHAMPS SÉLECTIONNÉS », où nous pouvons voir le nombre d'hôtes dans notre échantillon d'événements (plus de 100), le nombre de sources d'événements (18) et les différents types de sources d'origine des données (17).

En cliquant sur l'option hôte, nous verrons les 10 hôtes qui ont eu le plus de trafic. Nous pouvons voir que l'hôte le plus « bruyant » est 192.168.250.1, et celui ci-dessous est splunk-02, puis suricata IDS.

Examinons ensuite l'option « source » pour voir d'où proviennent les données que nous traitons. Dans la capture d'écran ci-dessous, nous pouvons voir que les journaux d'événements Windows constituent la principale source de journaux dans notre exemple d'événements, en particulier les journaux de sécurité, représentant 42 %. Vient ensuite udp:514, que vous devez reconnaître comme étant syslog ! Suivie par Suricata les journaux IDS en troisième position dans le top 10.

Sous « source », nous avons « sourcetype » qui nous indique le type de données dont nous disposons, ce qui donne des résultats normalement similaires à ceux du champ « source ».

Si nous voulons examiner l'un de ces types de journaux en particulier, tel que « wineventlog », nous pouvons simplement cliquer dessus et Splunk modifier notre requête de recherche, comme indiqué ci-dessous.

Cela peut être un excellent moyen de trouver rapidement des informations spécifiques. Par exemple, si nous voulions consulter les journaux du système de détection des intrusions, nous filtrerions Suricata en fonction du type de source. Supposons que nous voulions examiner le trafic réseau. Nous sélectionnons fgt_traffic dans le menu du champ « sourcetype » pour voir les journaux associés aux pare-feux Fortigate (fgt).

Veuillez noter que comme nous utilisons un exemple d'événement, il se peut que vous obteniez des résultats différents des nôtres, et c'est très bien ! Cela signifie simplement que vous êtes en train de regarder un autre groupe d'événements. Si vous ne voyez pas le type de source « fgt_traffic », essayez d'actualiser votre recherche pour index="botsv1" earliest=0 pour obtenir un nouvel échantillon 1:100.

Dans la capture d'écran ci-dessous, vous pouvez voir que notre requête de recherche a été modifiée pour inclure sourcetype=fgt_traffic à la fin, et le premier exemple montre un journal de pare-feu. Nous avons mis en évidence l'adresse IP source, le port source, l'interface source, l'adresse IP de destination, le port de destination et les valeurs de l'interface de destination. Comme il s'agit également de champs de journal, le champ « srcip » contient la valeur de l'adresse IP source. Souvenez-vous des leçons précédentes sur le domaine SIEM, où nous avons mentionné que les journaux ne sont pas universels et que, bien que ce journal de pare-feu utilise « srcip », un autre journal pourrait utiliser le nom de champ « source_ip » à la place.

Vous devez maintenant comprendre que les champs sont des paires de propriétés et de valeurs issues de journaux bruts et que nous pouvons les utiliser pour affiner rapidement nos recherches afin d'examiner des types de journaux spécifiques, des sources de journaux ou de recueillir rapidement des informations importantes telles que des noms d'hôtes et des adresses IP.

Paires champ/valeur

La recherche la plus simple que nous puissions effectuer consiste à rechercher un champ et une valeur. Par exemple, en recherchant dans nos données le champ IP source (src) et la valeur d'adresse IP 10.10.10.50.

recherche src="10.10.50"

Avec la requête ci-dessus, nous recherchons tous les journaux dont l'adresse IP source est répertoriée comme 10.10.10.50. Si nous voulions rechercher des journaux ou du trafic réseau associés à cette adresse IP, nous pourrions également rechercher des journaux dont l'adresse IP de destination est indiquée comme 10.10.10.50 :

recherchez src="10.10.50" OU dst="10.10.10.50"

Examinons ensemble un scénario simple. L'équipe du service client a reçu un certain nombre de plaintes indiquant que le site Web de l'entreprise est extrêmement lent et que certains clients ne peuvent pas y accéder. L'équipe de sécurité pense qu'il s'agit peut-être d'une attaque par déni de service distribué, dans laquelle plusieurs systèmes distants tentent de tomber en panne ou d'épuiser toutes les ressources du serveur afin que les clients légitimes ne puissent pas y accéder. À l'aide de la requête simple suivante, nous avons pu voir quel trafic est dirigé vers le serveur Web :

recherche dst="10.10.100.5"

Cela nous montrera tous les journaux dont l'adresse IP de destination est le serveur Web, mais cela affichera également tous les autres journaux ou le trafic allant vers ce serveur, ce qui pourrait entraîner de nombreux journaux qui ne nous intéressent pas. Nous pouvons appliquer des arguments supplémentaires dans notre requête de recherche pour effectuer des actions telles que le filtrage du trafic HTTP uniquement.

Wildcards

Qu'est-ce qu'un joker ? Un opérateur générique est un astérisque (*) qui peut être utilisé pour signifier n'importe quoi. Pour expliquer ce que nous voulons dire, prenons un autre exemple. Les analystes de sécurité déterminent que l'hôte 10.10.73 a été compromis par un acteur malveillant et que la prochaine étape probable de leur plan consiste à rechercher d'autres systèmes sur ce réseau (10.10.10.0/24). En utilisant Splunk , nous avons pu voir si l'hôte infecté a communiqué avec l'un des autres hôtes à l'aide de la requête :

search src="10.10.73" dst="10.10.10. * »

Dans l'exemple ci-dessus, le caractère générique dst= » 10.10.10.* » est utilisé pour représenter toute adresse IP commençant par « 10.10.10. ». Nous pouvons également l'utiliser pour rechercher des mots qui peuvent avoir différentes versions, tels que « pass » et « mot de passe ». Par exemple, nous pouvons rechercher des journaux contenant des informations sur les échecs de connexion à l'aide des éléments suivants :

passe de recherche* ET échec*

Ainsi, avec cette requête, elle renverra tous les journaux contenant les éléments suivants :

• « réussir » « échouer »
• « mot de passe » « échec »
• « réussite » « échec »
• « mot de passe » « échec »

Recherche de processus

index="botsv1" earliest=0 Image="* \ \ cmd.exe » | valeurs de statistiques (ligne de commande) par hôte

La requête de recherche ci-dessus utilise un nouveau paramètre, « Image= ». Ceci est dérivé des journaux Sysmon, tels que l'ID d'événement 1, « Nouveau processus créé ». Le champ Image des événements Sysmon montre l'exécutable qui a généré le processus, dans cet exemple, cmd.exe, qui doit se trouver dans C:\Windows\System32\cmd.exe (mais nous pouvons utiliser un caractère générique pour le chemin). Après avoir recherché le fichier cmd.exe, nous récupérons les événements à l'aide de valeurs (CommandLine) pour montrer quelles commandes ont été utilisées, puis nous les trions par hôte. Voyons à quoi ressemble cette recherche une fois qu'elle a été exécutée (sans échantillonnage d'événements) :

Ressources supplémentaires

Si vous souhaitez en savoir plus sur la recherche Splunk , nous vous recommandons vivement de lire la documentation relative à la recherche ici : Splunk /9.0.1/SearchTutorial/StartSearching « > https://docs.splunk.com/Documentation/ /9.0.1/SearchTutorial/StartSearching Splunk

Ou regardez cette superbe vidéo YouTube créée par l'équipe à l'adresse suivante Splunk : https://www.youtube.com/watch?v=xtyH_6iMxwA

Splunk Crash Course - Search Commands

1. Security Information and Event Monitoring

2. Using Splunk SIEM

3. Splunk Crash Course - Search Commands

Now that you know how we can find data within Splunk, we're going to cover Search Commands, and how they can help us better understand the data we've found in our search results. We'll cover the following commands:

• Sort
• Stats
• Table
• Uniq
• Dedup

Sort

Sort is a useful command that allows us to.. well.. sort the events returned to us by our search. For example, if we had a list of logs from a certain event, and we want to put them in chronological order, but not using Splunk's Time column, we could reference a specific field within the log, such as ‘time’ in Fortigate UTM events, and sort them based on this.

Look at the time field in the events below. They're not in order. Also look at the Time column on the left, notice how this doesn't match up with some of them?

So, we can add to the end of our search to sort on the value of the ‘time’ field, and make it ascending, so the oldest event is shown first.

| sort time asc

We can also add count=x after sort to limit the number of results returned. For example, | sort limit=2 time asc will show us the first two events from our search query, based on the time field. We can also use ‘desc’ if we want to see values ordered in descending value!

Stats

We can use the Stats command to provide statistics about the results from our search query. In the below example, we're looking at Fortigate UTM logs from a specific date, and have got a list of how many times (count) an IP value is present in the ‘srcip’ field.

If we wanted to see the most frequent IP at the top, what can we do? Combine it with a Sort command!

Table

We can use the Table command to create a custom table of the data we want to display, and hide everything else. Let's go through an example. Here's on raw log from our search query. We only care about the date, time, srcip, dstport, action, and msg fields.

We can add the following to the end of our search query:

| table date, time, srcip, dstport, action, msg

Now it's much easier to look at the information we care about, and we can use the column headings for filtering!

Uniq / dedup

The Uniq command can be used to retrieve unique values from our search results. If we wanted to see how many unique IP addresses there are in our logs, we can use Table to only display the srcip field, then perform uniq on the table:

| table srcip | uniq

In some cases uniq doesn't seem to work (maybe it's just us!), but we can alternatively use the dedup command to de-duplicate results. Combining this with a table, we can check what the various ‘action’ values are for Fortigate UTM logs:

| table action | dedup action