27.1.5 – Travaux pratiques – Convertir les données dans un format universel
27.1.5 – Travaux pratiques – Convertir les données dans un format universel
Remarque à l’intention de l’instructeur : la couleur de police rouge ou les surlignages gris indiquent que le texte n’apparaît que dans la copie de l’instructeur.
Objectifs
Partie 1 : Normalisation des horodatages dans un fichier journal
Partie 2 : Normalisation des horodatages dans un fichier journal Apache
Partie 3: Préparation du fichier journal dans la machine virtuelle Security Onion
Contexte/scénario
Ce TP vous permet de découvrir comment localiser, manipuler et afficher les fichiers journaux. Les entrées du journal sont générées par des appareils réseau, des systèmes d’exploitation, des applications et divers types d’appareils programmables. Un fichier contenant un flux temporel d’entrées de journal s’appelle un fichier journal.
Par nature, les fichiers journaux enregistrent les événements qui se rapportent à la source. La syntaxe et le format des données dans les messages du journal sont souvent définis par le développeur de l’application.
C’est pourquoi la terminologie utilisée dans les entrées de journal varie souvent d’une source à l’autre. Par exemple, selon la source, les termes « login », « logon », « authentication event » et « user connection » peuvent tous être utilisés pour décrire l’authentification sur un serveur.
Il est préférable d’avoir une terminologie uniforme dans les journaux générés par différentes sources, notamment lorsque tous les fichiers journaux sont collectés de manière centralisée.
Le terme normalisation désigne le processus de conversion des parties d’un message, en l’occurrence une entrée de journal, dans un format courant.
Au cours de ces travaux pratiques, vous utiliserez les outils de ligne de commande pour normaliser manuellement les entrées de journal. Dans la partie 2, le champ timestamp sera normalisé. Dans la partie 3, le champ IPv6 sera normalisé.
Remarque : bien qu’il existe de nombreux plug-ins pour procéder à la normalisation des entrées de journal, il est important de comprendre les concepts de base du processus de normalisation.
Ressources requises
- Poste de travail CyberOps VM
- La machine virtuelle Security Onion,
Instructions
Partie 1 : Normalisation des horodatages dans un fichier journal
Les horodatages sont utilisés dans les entrées de journal pour spécifier le moment où l’événement enregistré a eu lieu. Même s’il est conseillé d’utiliser le fuseau horaire UTC pour les horodatages, le format de l’horodatage varie d’une source à une autre. Il existe deux formats courants d’horodatage : Unix Epoch et un format intelligible.
Les horodatages Unix Epoch enregistrent la date et l’heure en mesurant le nombre de secondes écoulées depuis le 1er janvier, 1970.
Les horodatages au format intelligible enregistrent la date et l’heure en représentant des valeurs distinctes pour l’année, le mois, le jour, les heures, les minutes et les secondes.
L’horodatage au format intelligible Wed, 28 Jun 2017 13:27:19 GMT est le même que 1498656439 au format Unix Epoch.
Du point de vue de la programmabilité, il est beaucoup plus facile de travailler avec Epoch, car il simplifie les additions et les soustractions. Toutefois, du point de vue de l’analyse, les horodatages au format intelligible sont beaucoup plus faciles à interpréter.
Conversion des horodatages Epoch au format intelligible avec AWK
AWK est un langage de programmation conçu pour manipuler les fichiers texte. Il est très puissant et particulièrement utile pour manipuler des fichiers texte, où les lignes contiennent plusieurs champs, séparés par un caractère délimiteur. Les fichiers journaux contiennent une entrée par ligne et sous la forme de champs séparés par des délimiteurs. AWK est donc un outil de normalisation très performant.
Examinez le fichier applicationX_in_epoch.log ci-dessous. La source du fichier journal n’est pas pertinente.
2|Z|1219071600|AF|03|N|1219158000|AF|89 4|N|1220799600|AS|12 1|Z|1220886000|AS|67 5|N|1220972400|EU|23 6|R|1221058800|OC|89
Le fichier journal ci-dessus a été généré par l’application X. Le fichier présente les caractéristiques suivantes:
- Les colonnes sont séparées, ou délimitées, par le caractère | . Par conséquent, les données ont cinq colonnes.
- La troisième colonne contient des horodatages Unix Epoch.
- Le fichier contient une ligne supplémentaire à la fin. Cette information sera importante pour la suite du cours.
Supposons qu’un analyste de journal doive convertir les horodatages au format intelligible. Suivez les étapes ci-dessous pour utiliser AWK afin d’effectuer facilement la conversion manuelle :
a. Lancez le poste de travail virtuel CyberOps, puis ouvrez une fenêtre du terminal.
b. Utilisez la commande cd commande pour passer au répertoire /home/analyst/lab.support.files/. Une copie du fichier ci-dessus y sera stockée.
[analyst@secOps ~]$ cd /home/analyst/lab.support.files/
[analyst@secOps lab.support.files]$ ls -l
total 580
-rw-r--r-- 1 analyst analyst 649 Jun 28 18:34 apache_in_epoch.log
-rw-r--r-- 1 analyst analyst 126 Jun 28 11:13 applicationX_in_epoch.log
drwxr-xr-x 4 analyst analyst 4096 Aug 7 15:29 attack_scripts
-rw-r--r-- 1 analyst analyst 102 Jul 20 09:37 confidential.txt
<output omitted>
[analyst@secOps lab.support.files]$c. Exécutez la commande AWK suivante pour convertir et imprimer le résultat sur le terminal :
Remarque: La flèche vers le haut peut être utilisée pour modifier les erreurs de frappe dans l’entrée de commande précédente.
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS="|"}
{$3=strftime("%c",$3)} {print}' applicationX_in_epoch.log
2|Z|Mon 18 Aug 2008 11:00:00 AM EDT|AF|0
3|N|Tue 19 Aug 2008 11:00:00 AM EDT|AF|89
4|N|Sun 07 Sep 2008 11:00:00 AM EDT|AS|12
1|Z|Mon 08 Sep 2008 11:00:00 AM EDT|AS|67
5|N|Tue 09 Sep 2008 11:00:00 AM EDT|EU|23
6|R|Wed 10 Sep 2008 11:00:00 AM EDT|OC|89
||Wed 31 Dec 1969 07:00:00 PM EST
[analyst@secOps lab.support.files]$La commande ci-dessus est un script AWK. Il peut sembler compliqué. La structure principale du script AWK ci-dessus est la suivante :
- awk : appelle l’interprète AWK.
- ‘BEGIN : définit le début du script.
- {} : définit les actions à effectuer dans chaque ligne du fichier texte d’entrée. Un script AWK peut avoir plusieurs actions.
- FS = OFS = “|” : définit le séparateur de champ (c’est-à-dire, le délimiteur) sous forme de barre (|). Les caractères de séparation pour délimiter les champs peuvent différer d’un fichier texte à un autre. Cet opérateur permet à l’utilisateur de définir quel caractère est utilisé comme séparateur de champ dans le fichier texte actuel.
- $3 : désigne la valeur dans la troisième colonne de la ligne actuelle. Dans le fichier applicationX_in_epoch.log, la troisième colonne contient l’horodatage Epoch à convertir.
- strftime : désigne une fonction AWK interne conçue pour fonctionner avec les données temporelles. Les valeurs %c et $3 entre parenthèses sont les paramètres transmis à strftime.
- applicationX_in_epoch.log : désigne le fichier texte d’entrée à charger et à utiliser. Comme vous êtes déjà dans le répertoire lab.support.files, vous n’avez pas besoin d’ajouter les informations de chemin d’accès, /home/analyst/lab.support.files/applicationX_in_epoch.log.
La première action de script, spécifiée dans le premier jeu d’accolades, définit le symbole «|» comme caractère de séparation. Dans le deuxième jeu d’accolades, l’action de script réécrit la troisième colonne de chaque ligne avec le résultat de l’exécution de la fonction strftime(). strftime() est une fonction AWK interne créée pour gérer les conversions d’heure. Notez que, selon le script, la fonction doit utiliser le contenu de la troisième colonne de chaque ligne avant le changement ($3) et mettre en forme le résultat (%c).
Les horodatages Unix Epoch ont-ils été convertis au format intelligible ? Les autres champs ont-ils été modifiés ? Expliquez votre réponse.
Oui, le script est passé d’Epoch à Human Readable. Le script a modifié uniquement le champ d’horodatage, en préservant le reste du fichier.
Comparez le contenu du fichier et la sortie imprimée. Pourquoi la ligne ||Wed 31 Dec 1969 07:00:00 PM EST apparaît-elle ?
La raison de la ligne supplémentaire est que le fichier a une ligne vide à la fin, ce qui a conduit le script à l’interpréter par erreur comme 0 et à le convertir en un horodatage lisible par l’homme.
En interprétant la ligne vide comme 0, le script a converti 0 Unix Epoch en Human Readable. 0 Unix Epoch se traduit par 0 seconde après minuit le 1er janvier 1970. Le script affiche “Mer 31 décembre 1969 07:00:00 PM EST” car il s’ajuste automatiquement au fuseau horaire. Étant donné que la station de travail CyberOps est configurée pour EST (UTC -5), le script affiche minuit, le 1er janvier 1970 moins 5 heures.
d. Utilisez nano (ou l’éditeur de texte de votre choix) pour supprimer la ligne vide superflue à la fin du fichier, puis réexécutez le script AWK en utilisant la flèche vers le haut pour le trouver dans la mémoire tampon de l’historique des commandes.
[analyst@secOps lab.support.files]$ nano applicationX_in_epoch.log
La sortie est-elle correcte à présent ? Expliquez votre réponse.
Oui. Étant donné que la ligne vide a été supprimée, aucune donnée supplémentaire n’a été créée et ajoutée au fichier journal par le script.
e. Bien que l’impression du résultat à l’écran soit utile pour résoudre les problèmes liés au script, les analystes doivent souvent enregistrer la sortie dans un fichier texte. Redirigez la sortie du script ci-dessus vers un fichier nommé applicationX_in_human.log pour l’enregistrer dans un fichier :
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS="|"}
{$3=strftime("%c",$3)} {print}' applicationX_in_epoch.log >
applicationX_in_human.log
[analyst@secOps lab.support.files]$Qu’est-ce qui a été imprimé par la commande ci-dessus ? Est-ce prévu ?
Rien n’a été imprimé sur l’écran. Oui, c’est normal, car la sortie de la commande a été redirigée vers un fichier texte nommé applicationX_in_human.log.
f. Utilisez cat pour afficher le fichier applicationX_in_human.log. Notez que la ligne superflue a été supprimée et que les horodatages pour les entrées de journal ont été convertis au format intelligible.
[analyst@secOps lab.support.files]$ cat applicationX_in_human.log 2|Z|Mon 18 Aug 2008 11:00:00 AM EDT|AF|0 3|N|Tue 19 Aug 2008 11:00:00 AM EDT|AF|89 4|N|Sun 07 Sep 2008 11:00:00 AM EDT|AS|12 1|Z|Mon 08 Sep 2008 11:00:00 AM EDT|AS|67 5|N|Tue 09 Sep 2008 11:00:00 AM EDT|EU|23 6|R|Wed 10 Sep 2008 11:00:00 AM EDT|OC|89 [analyst@secOps lab.support.files]$
Partie 2 : Normalisation des horodatages dans un fichier journal Apache
Tout comme le fichier journal applicationX_in_epoch.log , les fichiers journaux Apache peuvent également être normalisés. Suivez les étapes ci-dessous pour convertir les horodatages Unix Epoch dans un format intelligible. Examinez le fichier journal Apache suivant, apache_in_epoch.log :
[analyst@secOps lab.support.files]$ cat apache_in_epoch.log 198.51.100.213 - - [1219071600] "GET /twiki/bin/edit/Main/Double_bounce_sender?topicparent=Main.ConfigurationVariables HTTP/1.1" 401 12846 198.51.100.213 - - [1219158000] "GET /twiki/bin/rdiff/TWiki/NewUserTemplate?rev1=1.3&rev2=1.2 HTTP/1.1" 200 4523 198.51.100.213 - - [1220799600] "GET /mailman/listinfo/hsdivision HTTP/1.1" 200 6291 198.51.100.213 - - [1220886000] "GET /twiki/bin/view/TWiki/WikiSyntax HTTP/1.1" 200 7352 198.51.100.213 - - [1220972400] "GET /twiki/bin/view/Main/DCCAndPostFix HTTP/1.1" 200 5253 198.51.100.213 - - [1221058800] "GET /twiki/bin/oops/TWiki/AppendixFileSystem?template=oopsmore&m1=1.12&m2=1.12 HTTP/1.1" 200 11382
Le fichier journal Apache ci-dessus contient six entrées qui enregistrent les événements liés au serveur web Apache. Chaque entrée comporte sept champs. Les champs sont délimités par un espace :
- La première colonne contient l’adresse IPv4, 198.51.100.213, du client web qui a effectué la demande.
- Les deuxième et troisième colonnes ne sont pas utilisées. Le caractère – représente l’absence de valeur.
- La quatrième colonne contient l’horodatage au format Unix Epoch, par exemple [1219071600].
- La cinquième colonne contient des informations sur l’événement au format texte, y compris les URL et des paramètres de requête web. Les six entrées sont toutes des messages HTTP GET. Comme ces messages contiennent des espaces, le champ complet est entre guillemets.
- La sixième colonne contient le code d’état HTTP, par exemple 401.
- La septième colonne contient la taille de la réponse au client (en octets), par exemple 12 846.
Comme dans la première partie, un script est créé pour convertir l’horodatage Epoch au format intelligible.
a. Pour commencer, répondez aux questions suivantes. Elles sont essentielles pour la construction du script.
Dans le cadre de la conversion de l’horodatage, quel caractère peut être utilisé comme caractère délimiteur pour le fichier journal Apache ci-dessus ?
Le personnage de l’espace
Combien de colonnes le fichier journal Apache ci-dessus contient-il ?
7
Dans le fichier journal Apache ci-dessus, quelle colonne contient l’horodatage Unix Epoch ?
Colonne 4
b. Sur le terminal du poste de travail virtuel CyberOps, une copie du fichier journal Apache, apache_in_epoch.log, est stockée sous /home/analyst/lab.support.files.
c. Utilisez un script awk pour convertir le champ d’horodatage dans un format intelligible. Notez que la commande contient le même script que celui utilisé précédemment, mais avec quelques ajustements pour le délimiteur, le champ d’horodatage et le nom du fichier.
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS=" "}
{$4=strftime("%c",$4)} {print}' apache_in_epoch.logLe script a-t-il converti correctement les horodatages ? Décrivez la sortie.
Non. Tous les horodatages sont désormais le mercredi 31 décembre 1969 à 19 h 00 HNE.
d. Avant d’aller plus loin, réfléchissez à la sortie du script.
Selon vous, pourquoi la sortie est-elle incorrecte ? Le script est-il incorrect ? Quelles sont les différences notoires entre les fichiers applicationX_in_epoch.log et apache_in_epoch.log ?
Le problème est les crochets dans le fichier du cours. Le script s’attend à ce que l’horodatage soit au format Unix Epoch qui n’inclut pas les crochets. Étant donné que le script ne sait pas quel nombre représente le caractère “[“, il suppose zéro et renvoie le début des temps Unix en UTC -5.
e. Pour résoudre le problème, les crochets doivent être supprimés du champ d’horodatage avant la conversion. Corrigez le script en ajoutant deux actions avant la conversion, comme indiqué ci-dessous :
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS=" "}
{gsub(/\[|\]/,"",$4)}{print}{$4=strftime("%c",$4)}{print}'
apache_in_epoch.logNotez qu’après avoir spécifié que les données sont séparées par un espace avec {FS=OFS=” “}, une action d’expression régulière permet de trouver les crochets correspondants et de les remplacer par une chaîne vide, afin de supprimer les crochets qui s’affichent dans le champ d’horodatage. La deuxième action imprime la ligne mise à jour pour que l’action de conversion puisse être exécutée.
gsub(): désigne une fonction AWK interne permettant de localiser et de remplacer les chaînes. Dans le script ci-dessus, gsub() a reçu trois paramètres séparés par des virgules, lesquels sont décrits ci-dessous.
/\[|\]/ – Il s’agit d’une expression régulière transmise à gsub() comme premier paramètre. L’expression régulière signifie find “[” OR “]”. Voici la répartition de l’expression :
- Les premier et dernier caractères « / » marquent le début et la fin du bloc de recherche. Tout élément inclus entre le premier « / » et le second « / » est lié à la recherche. Le caractère « \ » est utilisé comme caractère d’échappement de ce qui suit, « [ ».
L’échappement est nécessaire, car « [ » peut également être utilisé par un opérateur dans une expression régulière. En utilisant le caractère d’échappement « \ » avec « [ », l’interprète comprend que le symbole «[ » fait partie du contenu et que ce n’est pas un opérateur. Le caractère « | » correspond à l’opérateur OR. Notez qu’aucun caractère d’échappement n’est utilisé avec le symbole « | » et qu’il sera, par conséquent, considéré comme opérateur. Enfin, l’expression régulière utilise le caractère d’échappement pour le crochet de fin, « \] », comme précédemment.
“” : représente l’absence de caractère ou une chaîne vide. Ce paramètre indique à gsub() ce par quoi les symboles « [ » et «] » doivent être remplacés, quand ils sont reconnus. En remplaçant les symboles « [ » et «] » par “”, gsub() supprime les caractères « [ » et «] ».
$4 : indique à gsub() de ne traiter que la quatrième colonne de la ligne actuelle, la colonne d’horodatage.
Remarque : l’interprétation des expressions régulières est un sujet d’examen SECOP. Les expressions régulières sont abordées en détail dans un autre TP de ce chapitre. Toutefois, vous pouvez rechercher des tutoriels sur Internet.
f. Sur le terminal d’un poste de travail virtuel CyberOps, exécutez le script corrigé, comme suit :
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS=" "}
{gsub(/\[|\]/,"",$4)}{print}{$4=strftime("%c",$4)}{print}'
apache_in_epoch.logLe script a-t-il converti correctement les horodatages cette fois-ci ? Décrivez la sortie.
Oui. La sortie affiche maintenant deux lignes pour chaque entrée de journal. La première ligne affiche l’horodatage au format Unix Epoch et la deuxième ligne est la même entrée de journal avec l’horodatage affiché au format lisible par l’homme.
g. Arrêtez la machine virtuelle CyberOps Workstation si vous le souhaitez.
Partie 3 : Préparation du fichier journal dans la machine virtuelle Security Onion
Comme la normalisation des fichiers journaux est importante, les outils d’analyse des journaux comprennent souvent des fonctionnalités de normalisation. Les outils qui n’intègrent pas ces fonctionnalités doivent souvent utiliser des plug-ins pour la normalisation et la préparation des journaux. L’objectif de ces plug-ins est de permettre aux outils d’analyse des journaux de normaliser et de préparer les fichiers journaux reçus avant leur utilisation.
L’appliance Security Onion s’appuie sur un certain nombre d’outils pour fournir des services d’analyse de journaux. ELK, Zeek, Snort et SGUIL sont sans doute les outils les plus utilisés.
ELK (Elasticsearch, Logstash et Kibana) est une solution pour atteindre les objectifs suivants:
- Normaliser, stocker et indexer les journaux sans limites de volume et de fréquence
- Fournir une API et une interface de recherche simple et épurée
- Fournir une infrastructure permettant d’alerter, de signaler et de partager les journaux
- Ajouter des plug-ins au système pour lui permettre d’effectuer certaines actions avec les journaux
- Existe en tant que projet complètement gratuit et open source
Zeek (anciennement appelé Bro) est un cadre conçu pour analyser passivement le trafic réseau et générer des journaux d’événements sur cette base. Lors de l’analyse du trafic réseau, Bro crée des journaux relatant des événements tels que les suivants:
- Connexions réseau TCP/UDP/ICMP
- Activité DNS
- Activité FTP
- Requêtes et réponses HTTPS
- Établissement d’une liaison SSL/TLS
Snort et SGUIL
Snort est un appareil de détection des intrusions qui repose sur des règles prédéfinies pour signaler le trafic potentiellement dangereux. Snort examine toutes les parties des paquets réseau (en-têtes et charges utiles), à la recherche de modèles définis dans ses règles. Une fois qu’il les trouve, Snort effectue les actions définies dans la même règle.
SGUIL fournit une interface graphique pour les journaux et les alertes Snort, ce qui permet aux analystes en sécurité de passer de SGUIL à d’autres outils pour obtenir plus d’informations. Par exemple, si un paquet potentiellement malveillant est envoyé au serveur web de votre entreprise et que Snort déclenche une alerte à ce sujet, SGUIL répertorie cette alerte. L’analyste peut ensuite effectuer un clic droit sur cette alerte pour faire des recherches dans les bases de données ELSA ou Bro afin de mieux comprendre l’événement.
Remarque : le répertoire peut être différent de l’exemple de sortie ci-dessous.
Étape 1: Démarrez la machine virtuelle Security Onion
Lancez la machine virtuelle Security Onion à partir du tableau de bord de VirtualBox (nom d’utilisateur : analyst/mot de passe : cyberops).
Étape 2: Journaux Zeek dans Security Onion
a. Ouvrez une fenêtre de terminal sur la machine virtuelle Security Onion. Cliquez avec le bouton droit sur le bureau. Dans le menu contextuel, sélectionnez Ouvrir Terminal.
b. Les journaux Zeek sont stockés sous /nsm/bro/logs/. Avec les systèmes Linux, une rotation des fichiers journaux a lieu en fonction de la date. Ils sont également renommés et stockés sur le disque. Les fichiers journaux actuels se trouvent sous le répertoire current. Dans la fenêtre du terminal, changez de répertoire à l’aide de la commande suivante.
analyst@SecOnion:~$ cd /nsm/bro/logs/current analyst@SecOnion:/nsm/logs/current$
c. Utilisez la commande ls -l pour voir tous les fichiers journaux générés par Zeek:
Remarque: Dépend de l’état de la machine virtuelle, il se peut qu’il n’y ait pas encore de fichiers journaux.
Étape 3: Journaux Snort
a. Les journaux Snort se trouvent sous /nsm/sensor_data/. Modifiez le répertoire comme suit.
analyst@SecOnion:/nsm/bro/logs/current$ cd /nsm/sensor_data analyst@SecOnion:/nsm/sensor_data$
b. Utilisez la commande ls-l pour voir tous les fichiers journaux générés par Snort.
analyst@SecOnion:/nsm/sensor_data$ ls -l total 12 drwxrwxr-x 7 sguil sguil 4096 Jun 19 18:09 seconion-eth0 drwxrwxr-x 5 sguil sguil 4096 Jun 19 18:09 seconion-eth1 drwxrwxr-x 7 sguil sguil 4096 Jun 19 18:32 seconion-import
c. Notez que Security Onion sépare les fichiers en fonction de l’interface. Étant donné que l’image Security Onion VM a deux interfaces configurées en tant que capteurs et un dossier spécial pour les données importées, trois répertoires sont conservés. Utilisez la commande ls –l seconion-eth0 pour voir les fichiers générés par l’interface ethernet 0.
analyst@SecOnion:/nsm/sensor_data$ ls -l seconion-eth0 total 28 drwxrwxr-x 2 sguil sguil 4096 Jun 19 18:09 argus drwxrwxr-x 3 sguil sguil 4096 Jun 19 18:09 dailylogs drwxrwxr-x 2 sguil sguil 4096 Jun 19 18:09 portscans drwxrwxr-x 2 sguil sguil 4096 Jun 19 18:09 sancp drwxr-xr-x 2 sguil sguil 4096 Jun 19 18:24 snort-1 -rw-r--r-- 1 sguil sguil 5594 Jun 19 18:31 snort-1.stats -rw-r--r-- 1 root root 0 Jun 19 18:09 snort.stats
Étape 4: Journaux divers
a. Bien que le répertoire /nsm/ stocke des fichiers journaux, des fichiers journaux plus spécifiques peuvent être consultés sous /var/log/nsm/. Changez de répertoire et utilisez la commande ls pour voir tous les fichiers journaux dans le répertoire.
analyst@SecOnion:/nsm/sensor_data$ cd /var/log/nsm/ analyst@SecOnion:/var/log/nsm$ ls eth0-packets.log sid_changes.log netsniff-sync.log so-elastic-configure-kibana-dashboards.log ossec_agent.log so-elasticsearch-pipelines.log pulledpork.log so-sensor-backup-config.log seconion-eth0 so-server-backup-config.log seconion-import sosetup.log securityonion so-zeek-cron.log sensor-clean.log squert-ip2c-5min.log sensor-clean.log.1.gz squert-ip2c.log sensor-clean.log.2.gz squert_update.log sensor-newday-argus.log watchdog.log sensor-newday-http-agent.log watchdog.log.1.gz sensor-newday-pcap.log watchdog.log.2.gz sguil-db-purge.log
Notez que le répertoire ci-dessus contient également des journaux utilisés par des outils secondaires tels qu’ OSSEC et Squert.
b. Les journaux ELK se trouvent dans le répertoire /var/log. Changez de répertoire et utilisez la commande ls pour voir tous les fichiers journaux dans le répertoire.
analyst@SecOnion:/var/log/nsm$ cd .. analyst@SecOnion:/var/log$ ls alternatives.log debug kern.log.1 samba alternatives.log.1 debug.1 kern.log.2.gz sguild apache2 debug.2.gz kibana so-boot.log apt dmesg lastlog syslog auth.log domain_stats lightdm syslog.1 auth.log.1 dpkg.log logstash syslog.2.gz auth.log.2.gz dpkg.log.1 lpr.log syslog.3.gz boot elastalert mail.err syslog.4.gz boot.log elasticsearch mail.info unattended-upgrades bootstrap.log error mail.log user.log btmp error.1 mail.warn user.log.1 btmp.1 error.2.gz messages user.log.2.gz cron.log faillog messages.1 wtmp cron.log.1 freq_server messages.2.gz wtmp.1 cron.log.2.gz freq_server_dns mysql Xorg.0.log curator fsck nsm Xorg.0.log.old daemon.log gpu-manager.log ntpstats daemon.log.1 installer redis daemon.log.2.gz kern.log salt
c. Effectuez une recherche Google sur ces outils secondaires et répondez aux questions suivantes :
Pour chacun des outils énumérés ci-dessus, décrivez sa fonction, son importance et sa position dans le workflow des analystes en sécurité.
Pulledpork est un système de gestion de règles Snort. Il facilite la mise à jour des règles Snort. Les règles obsolètes de Snort rendent l’ensemble du système inutile.
OSSEC est un système utilisé pour normaliser et concentrer les journaux système locaux. Lorsqu’il est déployé dans toute l’organisation, OSSEC permet à un analyste d’avoir une image claire de ce qui se passe dans les systèmes.
Squert est un outil visuel qui tente de fournir un contexte supplémentaire aux événements grâce à l’utilisation de métadonnées, de représentations de séries chronologiques et d’ensembles de résultats pondérés et regroupés logiquement.
Elasticsearch est un moteur de recherche et d’analyse distribué. Les données sont stockées de manière centralisée pour fournir des recherches rapides et permettre un réglage fin.
Logstash rassemble les données de différentes sources et alimente les données dans ElasticSearch.
Kibana est la visualisation de données pour la pile ELK afin de fournir un aperçu rapide des données.
Remarques générales
La normalisation des journaux est importante et dépend de l’environnement déployé.
Les outils fréquemment utilisés intègrent leurs propres fonctions de normalisation, mais la normalisation des journaux peut également être effectuée manuellement.
Lorsque vous normalisez et préparez manuellement les fichiers journaux, vérifiez bien les scripts pour vous assurer d’obtenir le résultat souhaité. Si le script de normalisation est mal écrit, les données risquent d’être modifiées, ce qui a une incidence directe sur le travail de l’analyste.