Lab de réponse à incident et d’investigation : enquêter sur un serveur compromis

Ce lab donne à chaque élève sa propre VM Ubuntu contenant les journaux et les fichiers d’un serveur web piraté la nuit dernière : un journal SSH avec une rafale de mots de passe essayés, un journal du serveur web plein de scanners, le fichier des comptes, les crontabs et la liste des dates de modification des fichiers. L’élève est le répondant à l’incident et doit trouver qui est entré, sous quel compte, quand, et ce qu’il a laissé pour revenir.

Il n’y a ni logiciel malveillant ni code d’exploitation, et rien à exécuter : tout est du texte, à lire avec les outils de toute machine Linux.

Ce que les élèves apprennent

Lire des journaux comme des preuves : fouiller un journal SSH avec grep et awk, compter et trier avec sort et uniq, et distinguer une attaque du bruit de fond. L’affaire contient des leurres exprès, qu’une recherche paresseuse ne résout donc pas : l’adresse qui a le plus d’échecs n’entre jamais, un administrateur se trompe de mot de passe puis réussit, et un nouvel utilisateur légitime et une ancienne clé SSH côtoient ce que l’intrus a laissé. Ils construisent une chronologie et utilisent l’heure d’une modification pour distinguer le travail de l’intrus de celui de l’administrateur.

La tâche

L’élève trouve six éléments et les écrit dans answers.txt, une ligne étiquetée chacun : l’adresse d’où vient l’attaque, le compte attaqué, l’heure de la première connexion réussie, le type de persistance laissée, le fichier où elle se trouve et le programme qu’elle continue d’exécuter. Le README que le lab laisse dans le dossier personnel dit quoi trouver et ne donne aucune réponse.

Les preuves sont en lecture seule : les réponses viennent donc de leur lecture. Chaque élève a la même affaire.

Le lancer dans votre navigateur

Les labs VM se proposent comme tâche de lab dans un module, et l’exemple se trouve sur la page du lab.

  1. Ajouter le lab. Dans un module que vous enseignez, ajoutez une tâche et choisissez la carte « Lab VM Ubuntu ». La page affiche une courte description de la machine au lieu d’un fichier compose.
  2. Partir de l’exemple. La page propose des labs prêts à l’emploi pour commencer. Choisissez Incident response and forensics. Utiliser un exemple remplace le texte, et « Annuler » rétablit le vôtre.
  3. Publier et démarrer votre propre copie. Publiez, puis « Démarrer ». Le script d’installation du lab construit le dossier d’enquête au premier démarrage de la VM, en quelques secondes. Il n’installe rien depuis l’archive d’Ubuntu, sauf si l’image n’a pas Python.
  4. Ouvrir le terminal. Ouvrez son terminal et lisez README.md dans le dossier personnel : il nomme les éléments de preuve du dossier case et ce qu’il faut trouver, et ne donne aucune réponse. Les réponses vont dans answers.txt, une ligne étiquetée chacune.

Une leçon de base sur ce lab

Incident Response Basics est une petite leçon qui se fait dans ce lab, qui est une VM Ubuntu : chaque étape est expliquée et accompagnée d’un bouton Exécuter qui tape sa commande dans le terminal de la machine et montre ce qu’elle a affiché. L’élève liste les preuves, compte les lignes des deux journaux, lit les premières lignes du journal SSH et compte les mots de passe échoués.

Ils regardent autour d’eux et laissent à l’élève la tâche propre du lab, trouver l’attaquant : la leçon ne donne donc aucune réponse. Un compte personnel gratuit la reçoit sur le module Basics, qui est sur l’accueil, chaque établissement peut la copier depuis le dossier Basics de la Bibliothèque, et elle est volontairement petite : elle montre à un enseignant ce qu’est une leçon faite dans un lab, et le lab fait le reste. Copiez-la dans un module à vous pour la modifier.

Comment il est noté

Le lab a une vérification. Elle lit answers.txt, qui peut être écrit avec n’importe quelles majuscules et espaces, et compare chaque réponse à l’affaire. Quand une réponse est fausse, elle nomme le premier champ faux et ne dit jamais quelle est la réponse. Elle refuse aussi une affaire dont les preuves ont été modifiées pour coller à une réponse.

Un élève a sudo sur sa propre VM : celui qui lit les fichiers de root pourrait donc trouver la clé. C’est accepté : le lab est un entraînement, et ce qui est noté est la réponse écrite.

  1. Le distribuer. Attribuez le lab comme n’importe quelle tâche, avec une échéance si vous le souhaitez. Chaque élève reçoit sa propre VM, conservée d’une session à l’autre, avec le même dossier d’enquête.
  2. Lancer la vérification. Sur la ligne d’un élève dans la liste de la classe, appuyez sur « Lancer la vérification ». Elle démarre une copie de sa machine enregistrée, sans rien enregistrer en retour, exécute le script de vérification du lab en root et indique s’il a réussi, ce qu’il a affiché et quand. L’élève n’est pas informé du résultat.
  3. Noter. Lisez ce que la vérification a affiché : la première ligne nomme le premier champ faux, jamais la réponse. Renvoyez le travail avec un motif s’il demande un complément.

La définition sur GitHub

Le fichier est la définition complète du lab, le même texte que la plateforme exécute : taille, script d’installation qui construit l’affaire à partir d’une graine fixe, README et vérification. Copiez-le et modifiez le générateur dans le script d’installation pour faire votre propre affaire.

Questions fréquentes

Y a-t-il un logiciel malveillant dans le lab ?
Non. L’affaire est du texte : journaux, fichier des comptes, crontabs, clés et liste d’heures. Rien n’y est exécuté, et les adresses viennent de plages réservées à la documentation ou de plages privées.
De quelle taille de machine chaque élève a-t-il besoin ?
Un processeur, 1 Go de mémoire et 10 Go de disque. Le lab n’installe que Python, et seulement si l’image ne l’a pas.
Un élève peut-il trouver la réponse ailleurs ?
Un élève a sudo sur sa propre VM : un élève déterminé peut donc lire la clé de la vérification dans les fichiers de root. Le lab est un entraînement, et ce que votre enseignant note est la réponse écrite.