Introduction
Les outils de sécurité peuvent produire de longues sorties contenant des notes, des observations répétées et des diagnostics. Un résultat utile est un petit ensemble d'observations pertinentes dont vous comprenez l'origine.
Dans ce lab, vous vous exercerez avec un fichier texte fourni avant d'exécuter un outil d'analyse. Vous lirez son contenu, filtrerez et dédupliquerez les enregistrements de services ouverts, les compterez et séparerez les erreurs de la sortie utile.
Lire un fichier de sortie préparé
Dans cette étape, vous examinerez un fichier texte préparé de plusieurs façons avant d'en extraire des observations. Il s'agit de données d'exemple, pas de la sortie d'une analyse que vous devez exécuter.
Ouvrez le shell Kali préparé :
kali
Utilisez un chemin absolu pour choisir le répertoire de travail partagé :
cd /home/labex/project
Le fichier observations.txt contient de courtes lignes commençant par NOTE, OPEN ou CLOSED. Ici, OPEN signifie que l'observation d'exemple indique un service ouvert ; cela ne prouve pas une vulnérabilité. Affichez ce petit fichier entier :
cat observations.txt
Vous verrez des lignes de services ouverts répétées, ainsi que des notes et des lignes de services fermés. Lire d'abord la source vous aide à choisir un filtre qui préserve les informations voulues.
Pour un fichier long, less affiche une page à la fois sans modifier le fichier :
less observations.txt
Utilisez les touches fléchées pour vous déplacer si nécessaire, puis appuyez sur q pour quitter et revenir au shell. L'exemple tient sur un seul écran ; le même outil de consultation fonctionne pour des sorties d'outils plus volumineuses.
head lit le début d'un fichier ; tail lit sa fin. L'option -n définit le nombre de lignes à afficher. Examinez les trois premières lignes :
head -n 3 observations.txt
Résultat attendu :
NOTE supplied training observations
OPEN training-web:8080 http
CLOSED training-db:5432 postgresql
Examinez maintenant les deux dernières lignes :
tail -n 2 observations.txt
La dernière ligne est NOTE end of sample. Enregistrez l'aperçu de trois lignes avec l'opérateur > présenté dans le premier lab :
head -n 3 observations.txt > preview.txt
cat preview.txt
L'aperçu doit contenir les trois mêmes lignes que ci-dessus. Vous avez conservé la source intacte et enregistré une vue utile de son contenu.
Filtrer, trier et supprimer les observations répétées
Dans cette étape, vous construirez un pipeline qui conserve les enregistrements de services ouverts et supprime les doublons.
Restez dans Kali et revenez à l'espace de travail partagé :
cd /home/labex/project
grep affiche les lignes correspondantes. Le motif ci-dessous est entre apostrophes afin que le shell le transmette littéralement. L'ancre ^ désigne le début d'une ligne et l'espace après OPEN sépare le type d'enregistrement de ses données :
grep '^OPEN ' observations.txt
La sortie contient toutes les observations de services ouverts, y compris les lignes répétées. Les notes et les lignes CLOSED sont absentes.
Le symbole de tube | relie la sortie standard d'une commande à l'entrée standard de la suivante. sort ordonne les lignes afin que les lignes identiques deviennent adjacentes :
grep '^OPEN ' observations.txt | sort
Les lignes répétées sont maintenant regroupées. uniq supprime les lignes identiques adjacentes : il doit donc venir après le tri lorsque des doublons peuvent être séparés :
grep '^OPEN ' observations.txt | sort | uniq
Résultat attendu :
OPEN training-dns:5353 dns
OPEN training-ssh:2222 ssh
OPEN training-web:8080 http
Chaque commande a un rôle : sélectionner les enregistrements, les ordonner, puis réduire les répétitions. Enregistrez le flux obtenu dans un fichier de sortie distinct :
grep '^OPEN ' observations.txt | sort | uniq > open-services.txt
cat open-services.txt
Vous devriez voir les trois mêmes enregistrements uniques. La redirection s'applique à la sortie finale du pipeline ; les observations d'origine ne sont pas modifiées.
Compter les résultats et séparer la sortie d'erreur
Dans cette étape, vous compterez les observations sélectionnées et distinguerez une sortie normale d'un message d'erreur.
Partez de l'espace de travail partagé :
cd /home/labex/project
wc compte les éléments d'un texte. Son option -l compte les lignes terminées par un saut de ligne. Comme le fichier enregistré contient une observation par ligne, ce nombre correspond au nombre d'enregistrements distincts de services ouverts :
wc -l open-services.txt
La sortie indique 3 et le nom du fichier ; l'espacement peut varier. Un pipeline fournit du texte sans argument de nom de fichier, ce qui facilite l'enregistrement du nombre seul :
cat open-services.txt | wc -l > finding-count.txt
cat finding-count.txt
La valeur est 3, éventuellement précédée d'espaces.
Les programmes envoient normalement les données utiles vers la sortie standard et les diagnostics vers l'erreur standard. Le > du shell redirige la sortie standard ; 2> redirige à la place l'erreur standard. Pour observer la différence, essayez de lire un fichier volontairement absent et enregistrez son diagnostic. L'échec de la prochaine commande est attendu, car missing-observations.txt n'existe pas ; c'est une démonstration intentionnelle, continuez donc ensuite :
cat missing-observations.txt 2> read-error.txt
Rien ne devrait apparaître à l'écran, car le message d'erreur a été envoyé dans read-error.txt. Examinez ce diagnostic distinct :
cat read-error.txt
Le message nomme missing-observations.txt et indique qu'il ne peut pas être lu parce qu'il n'existe pas. Vos observations réelles sont toujours séparées :
cat open-services.txt
Les trois enregistrements valides restent inchangés. Séparer les diagnostics évite de prendre un message d'erreur pour une observation d'outil.
Résumé
Vous avez lu du texte avec cat, less, head et tail, sélectionné des lignes avec grep, composé un pipeline avec sort et uniq, compté des enregistrements avec wc et utilisé les redirections de sortie et d'erreur. Ces compétences aident à transformer les sorties volumineuses des outils en résultats courts et faciles à examiner.
