Arkendia Classrooms
Leçon 12 sur 28 · 15 min

Bonnes pratiques et éthique du laboratoire personnel

Vous possédez désormais un laboratoire, des outils puissants et une certaine curiosité. C'est le bon moment pour poser les règles du jeu. La différence entre un professionnel de la sécurité et un délinquant ne tient pas aux outils, qui sont les mêmes, mais à l'autorisation, au périmètre et à l'éthique. Cette leçon établit la « charte » de votre laboratoire, et rappelle le cadre légal que nous détaillerons au chapitre 7.

Dans ce chapitre, vous avez installé un hyperviseur, une machine Kali et un réseau interne isolé. Avant de poursuivre, prenez le temps d'ancrer les bons réflexes : ils vous accompagneront pendant tout le parcours et dans votre éventuelle carrière.

La règle d'or : seulement ce qui vous appartient

Un test de sécurité n'est légitime que s'il porte sur un système dont vous êtes le propriétaire, ou dont le propriétaire vous a donné une autorisation écrite précise. Dans le cadre de ce parcours :

  • Vos machines virtuelles et votre réseau interne sont votre terrain de jeu.
  • Les plateformes d'entraînement conçues pour cela sont autorisées, dans le respect de leurs règles : TryHackMe, HackTheBox, PortSwigger Web Security Academy, ainsi que les applications DVWA et OWASP Juice Shop que vous installerez vous-même dans votre laboratoire.
  • Tout le reste est interdit : le réseau de votre école ou de votre entreprise, le Wi-Fi de vos voisins, le site de votre commune, un serveur trouvé « par curiosité ». Même sans mauvaise intention, même « juste pour voir ».

Rappel légal (France). Les articles 323-1 à 323-3-1 du Code pénal sanctionnent notamment l'accès ou le maintien frauduleux dans un système de traitement automatisé de données, l'entrave à son fonctionnement, ainsi que l'introduction, l'extraction ou la modification frauduleuse de données. Une simple intrusion sans dommage peut déjà être punie, et la tentative l'est aussi. Le texte précis, les peines et leurs aggravations sont consultables sur Légifrance. D'autres pays ont des dispositions comparables : l'ignorance de la loi n'est jamais une défense. Nous détaillerons ce cadre au chapitre 7.

Comprendre la notion de « périmètre »

Dans un vrai test d'intrusion, on parle de périmètre (scope) : la liste exacte des systèmes, adresses et dates sur lesquels le test est autorisé. Tout ce qui est hors périmètre est interdit, même s'il paraît lié. Prenez dès maintenant cette habitude pour votre laboratoire : écrivez dans votre carnet ce qui en fait partie.

Périmètre du laboratoire (exemple)
- Réseau virtuel : labo-interne (10.10.10.0/24)
- Machines : kali-labo (10.10.10.10), cible (10.10.10.20)
- Hors périmètre : tout autre appareil, mon réseau domestique,
  tout service sur Internet

Ce petit document est la version « jouet » du périmètre contractuel d'un vrai test. Le jour où vous réaliserez un test pour un client, ce périmètre sera au cœur du contrat.

Les bonnes pratiques de laboratoire

  1. Isoler. Réseau interne pour les cibles, NAT uniquement pour les mises à jour, aucune machine vulnérable en pont. Vérifiez l'isolement après chaque changement.
  2. Documenter. Tenez un journal daté : ce que vous avez fait, la commande utilisée, le résultat, ce que vous en retenez. Dans le métier, ce journal est la matière première du rapport final.
  3. Snapshotter. Un état propre avant chaque expérience, pour pouvoir revenir en arrière.
  4. Mettre à jour l'hyperviseur, les outils d'intégration et les VM de travail. Les VM volontairement vulnérables, elles, restent dans leur état : c'est leur raison d'être, d'où leur isolement.
  5. Séparer les rôles. Ne faites pas vos tâches personnelles (banque, messagerie) dans les machines de laboratoire, et n'y stockez aucun mot de passe réel, aucune donnée personnelle réelle.
  6. Ne pas mélanger les contextes. Une machine d'attaque ne doit pas être connectée à vos comptes personnels ni à un réseau d'entreprise.
  7. Nettoyer. Supprimez les machines et les captures dont vous n'avez plus l'usage, en particulier celles qui contiennent des données personnelles.
  8. Prendre soin des échantillons. Si un jour vous étudiez des programmes malveillants, faites-le uniquement sur des machines dédiées, sans réseau et sans dossiers partagés, et à partir de sources reconnues.

Les plateformes d'entraînement légales

Votre laboratoire personnel n'est pas la seule option. Plusieurs plateformes offrent des environnements d'entraînement faits pour être attaqués, avec leurs propres règles d'utilisation :

  • TryHackMe : parcours guidés, adaptés aux débutants, avec des machines accessibles depuis le navigateur ou par connexion sécurisée.
  • HackTheBox : machines et défis de difficulté croissante, plus autonomes.
  • PortSwigger Web Security Academy : cours et exercices gratuits sur les vulnérabilités web.
  • DVWA et OWASP Juice Shop : applications volontairement vulnérables à installer dans votre propre laboratoire.

Ces plateformes sont présentées ici comme de simples ressources de formation, sans lien d'affiliation. Lisez toujours leurs conditions d'utilisation : elles précisent ce que vous pouvez faire et contre quelles machines, et vous engagent à ne rien tenter en dehors de leur périmètre.

Que faire si vous découvrez une faille chez un tiers ?

Cela arrive, même à des débutants : un formulaire qui laisse voir des données, un fichier exposé, un message d'erreur trop bavard. Les bons réflexes :

  • Ne continuez pas à explorer et ne téléchargez ni ne copiez de données.
  • Ne tentez pas de prouver la faille en l'exploitant davantage.
  • Notez ce que vous avez vu par hasard (lien, date, nature de l'anomalie) sans rien conserver de sensible.
  • Signalez-la de façon responsable à l'organisation concernée (une adresse de contact sécurité existe parfois) ou, en France, via les dispositifs officiels de signalement des vulnérabilités. Nous détaillerons ce chemin au chapitre 7. Les ressources officielles de l'ANSSI (cyber.gouv.fr) et de cybermalveillance.gouv.fr sont un bon point de départ.

L'éthique du « white hat »

Le terme « white hat » désigne un expert qui utilise ses compétences pour protéger, avec autorisation. Il se distingue du « black hat » (malveillant) et du « grey hat » (qui agit sans autorisation, même avec de bonnes intentions : et qui reste, légalement, dans l'illégalité). Les valeurs qui fondent le métier sont assez simples :

  • L'autorisation d'abord : pas de test sans accord écrit.
  • La proportionnalité : on prouve l'existence d'une faille avec le minimum d'impact, sans dégrader le service ni lire des données inutilement.
  • La confidentialité : ce qu'on découvre chez un client reste chez lui.
  • L'honnêteté : on rapporte ce qu'on a trouvé et fait, y compris ses propres erreurs.
  • Le partage des connaissances : on contribue à la communauté, sans mettre en danger des tiers.

À vous de jouer

Exercice : rédiger la charte de votre laboratoire. Dans votre carnet, écrivez une page qui comprend :

  1. Le périmètre exact de votre laboratoire (réseau, machines, adresses).
  2. Cinq règles de fonctionnement (isolement, snapshots, mises à jour, pas de données réelles, nettoyage).
  3. La liste des plateformes d'entraînement que vous vous autorisez à utiliser.
  4. Ce que vous ferez si vous trouvez par hasard une faille sur un système qui n'est pas le vôtre.
  5. Une phrase d'engagement personnel, datée et signée de votre main.
Voir une solution

Voici un exemple de charte condensée : « Mon laboratoire se limite au réseau virtuel labo-interne (10.10.10.0/24) et aux machines kali-labo et cible. Je ne teste que ces machines et les plateformes d'entraînement légales dont j'ai lu les règles. Je prends un snapshot avant chaque expérience, je tiens un journal daté et je supprime captures et machines inutiles. Je ne stocke aucune donnée réelle. Si je découvre une faille sur un système qui n'est pas le mien, je m'arrête, je ne l'exploite pas, et je la signale par un canal officiel. Je m'engage à ne jamais utiliser mes compétences sans autorisation écrite. Fait le … , signature. »

Peu importe la forme exacte : l'essentiel est que ces engagements soient écrits, relus, et réellement appliqués.

À retenir

  • On ne teste que ce qui nous appartient ou ce pour quoi on dispose d'une autorisation écrite précise.
  • Le Code pénal (articles 323-1 à 323-3-1) sanctionne l'accès frauduleux, l'entrave et la manipulation de données, même sans intention de nuire.
  • Le périmètre est la liste exacte de ce qui peut être testé ; hors périmètre = interdit.
  • Bonnes pratiques : isoler, documenter, snapshotter, mettre à jour, ne stocker aucune donnée réelle, nettoyer.
  • En cas de découverte fortuite d'une faille : s'arrêter, ne pas exploiter, signaler de façon responsable.

Votre laboratoire est monté, isolé, et encadré par une charte. Il est temps de plonger dans l'intérieur des systèmes qui y tournent. Chapitre suivant : Linux au quotidien.

Publicité
Connectez-vous pour enregistrer votre progression. Se connecter