Réseau interne isolé et snapshots — Fondamentaux techniques : réseaux, Linux et systèmes

Vous avez une machine de travail. Mais un laboratoire n'a de sens que s'il est étanche : ce que vous y faites ne doit jamais toucher votre réseau domestique, votre entreprise, ni Internet. C'est la règle numéro un de tout laboratoire de sécurité. Cette leçon vous apprend à construire cette étanchéité avec un réseau interne isolé, et à vous donner un filet de sécurité grâce aux snapshots.

Dans la leçon précédente, votre Kali était branchée en NAT pour pouvoir se mettre à jour. C'est pratique, mais ce n'est pas un environnement de test. Voyons comment créer un vrai réseau privé de laboratoire, et pourquoi c'est la protection la plus importante de toute votre pratique.

Pourquoi isoler ? Un exemple concret

Dans les prochains cours, vous allez faire tourner des machines volontairement vulnérables : des applications web truffées de failles pour s'entraîner, des systèmes anciens non corrigés. Si l'une d'elles était branchée en pont sur votre réseau domestique, n'importe quel appareil de la maison, ou n'importe quel visiteur sur votre Wi-Fi, pourrait l'atteindre, et un véritable attaquant pourrait s'en servir comme d'un point d'entrée. L'inverse est vrai aussi : un outil de test mal manipulé pourrait atteindre vos voisins du réseau. D'où l'isolement.

Choisir le bon mode réseau

Voici un tableau récapitulatif des modes proposés par les hyperviseurs et de leur usage dans un laboratoire :

Mode	La VM peut joindre…	Usage dans le labo
NAT	Internet (via l'hôte) ; non joignable de l'extérieur	Temporaire, pour installer et mettre à jour
Pont (bridged)	Tout votre réseau réel	À éviter pour toute machine de labo
Hôte uniquement	L'hôte et les autres VM du même réseau	Utile pour administrer les VM depuis l'hôte
Réseau interne	Uniquement les autres VM du même réseau interne	Réseau d'entraînement par défaut

La règle est simple : les machines vulnérables ne doivent avoir qu'une carte réseau, branchée à un réseau interne. La machine d'attaque (Kali) peut avoir deux cartes : une en NAT, uniquement pendant les mises à jour, et une sur le réseau interne pour travailler. Quand vous faites des exercices, débranchez la carte NAT (« câble débranché » dans les options de la carte) : vous ne gardez alors que le réseau interne.

Le schéma du laboratoire

Voici l'architecture minimale que nous allons viser, à reporter dans votre carnet :

        +---------------------- Hôte (votre ordinateur) ----------------------+
        |                                                                      |
        |   +-------------+        réseau interne "labo-interne"   +--------+  |
        |   |  kali-labo  |---------------------------------------| cible  |  |
        |   | 10.10.10.10 |            10.10.10.0/24               |10.10.10.20|
        |   +-------------+                                        +--------+  |
        |        |  (carte 1 : NAT, uniquement pour les mises à jour)          |
        +--------|-------------------------------------------------------------+
                 v
              Internet

La plage 10.10.10.0/24 est une plage privée de notre choix. Le nom « labo-interne » est celui du réseau interne : toutes les cartes qui portent ce nom sont reliées entre elles.

Configurer le réseau interne avec VirtualBox

Dans l'interface, ouvrez les réglages de la VM, onglet « Réseau », choisissez la carte 2, cochez « Activer », mode « Réseau interne », nom labo-interne. En ligne de commande, la même opération (VM éteinte) s'écrit :

VBoxManage list vms
VBoxManage modifyvm "kali-labo" --nic2 intnet --intnet2 "labo-interne"

Dans VMware, l'équivalent est un réseau personnalisé ou « segment de réseau local ». Un réseau interne VirtualBox n'a pas de serveur DHCP par défaut : il faut donner une adresse fixe à chaque machine. Dans la VM Kali, trouvez le nom de la deuxième interface (ip addr, souvent eth1) puis :

sudo ip addr add 10.10.10.10/24 dev eth1
sudo ip link set eth1 up

Cette configuration est temporaire (elle disparaît au redémarrage), ce qui suffit pour un exercice. Une configuration permanente passe par le gestionnaire de réseau de la machine. Sur la seconde VM (cible), donnez de la même façon l'adresse 10.10.10.20/24. Testez avec ping -c 3 10.10.10.20 depuis Kali.

La seconde machine : une cible légale

La machine « cible » est un système sur lequel vous avez tous les droits, installé uniquement pour vos exercices. Dans ce cours, un simple serveur Linux léger suffit. Dans le cours de pentest web, vous y installerez des applications d'entraînement conçues pour être attaquées légalement, comme DVWA ou OWASP Juice Shop. Ces projets sont des environnements d'entraînement pensés pour cela : ne les exposez jamais sur Internet.

Vérifier que l'isolement est réel

Ne vous contentez pas de croire que le labo est étanche : vérifiez-le. Sur la machine cible, une fois la carte NAT absente :

ip route
ping -c 2 example.com

ip route ne doit montrer aucune route par défaut vers l'extérieur, et le ping doit échouer (« Temporary failure in name resolution » ou « Network is unreachable »). Si le ping réussit, la machine a un accès Internet : revoyez la configuration des cartes. Autre contrôle : depuis votre ordinateur hôte, vous ne devez pas pouvoir joindre 10.10.10.20 (le réseau interne ne passe pas par l'hôte).

Les snapshots : votre bouton « annuler »

Un snapshot (instantané) enregistre l'état complet d'une VM à un instant donné : disque, et éventuellement mémoire. Vous pouvez y revenir en quelques secondes. C'est ce qui rend le laboratoire joyeux plutôt qu'anxiogène : vous pouvez casser, configurer de travers, installer n'importe quoi, puis tout annuler.

Prenez l'habitude suivante : un snapshot « propre » juste après l'installation et les mises à jour (c'est votre point de retour sûr), puis un snapshot avant toute expérience importante.

VBoxManage snapshot "kali-labo" take "installation-propre" --description "Après mises à jour"
VBoxManage snapshot "kali-labo" list
VBoxManage snapshot "kali-labo" restore "installation-propre"

Ces mêmes actions existent dans l'interface graphique (onglet « Instantanés »). Les clones sont un autre outil utile : un clone « lié » partage le disque de la machine d'origine (économique) ; un clone « complet » est une copie indépendante.

Un snapshot n'est pas une sauvegarde. Il dépend du disque virtuel d'origine : si le disque est perdu ou corrompu, les snapshots aussi. Sauvegardez régulièrement vos VM importantes (export en fichier d'appareil virtuel) vers un autre support, comme vous l'avez appris avec la règle 3-2-1. Et ne laissez pas s'accumuler une chaîne de dizaines de snapshots : ils ralentissent la machine et consomment du disque.

Autres réglages d'isolation à ne pas oublier

Désactiver le presse-papiers partagé et le glisser-déposer entre l'hôte et les machines à risque.
Ne pas monter de dossiers partagés de l'hôte dans une VM vulnérable ou dans une VM qui manipule des échantillons suspects.
Désactiver les périphériques USB et audio inutiles pour réduire les ponts avec l'hôte.
Garder l'hyperviseur et les outils d'intégration à jour.

À vous de jouer

Créez une seconde VM cible (un serveur Linux léger suffit), avec une seule carte, de type réseau interne labo-interne.
Ajoutez à kali-labo une deuxième carte sur le même réseau interne, et donnez des adresses fixes aux deux machines comme ci-dessus.
Vérifiez la communication (ping) et l'isolement (aucun accès à Internet depuis la cible).
Prenez un snapshot « labo-propre » de chaque machine.
Cassez volontairement quelque chose (supprimez un fichier de configuration non critique dans la cible), puis restaurez le snapshot et vérifiez que tout est revenu.

Voir une solution

Isolement. Depuis la cible : ip route n'affiche que le réseau 10.10.10.0/24 ; ping -c 2 example.com échoue. Depuis Kali, ping -c 3 10.10.10.20 répond. Dans Wireshark sur Kali (interface interne), vous voyez d'abord des requêtes ARP, puis les paquets ICMP.

Snapshot. Après restauration, le fichier supprimé réapparaît : c'est la démonstration que vous pouvez expérimenter sans crainte. Notez dans le carnet la date et le nom de chaque snapshot.

Si le ping ne passe pas : vérifiez que les deux cartes portent exactement le même nom de réseau interne, que les interfaces sont « up », et que les adresses sont dans le même sous-réseau.

À retenir

Les machines vulnérables ne se placent jamais en pont sur votre réseau réel : un réseau interne isolé est la configuration de référence.
Le NAT est réservé aux mises à jour ; débranchez-le pendant les exercices.
Vérifiez l'isolement par des tests (route par défaut absente, ping vers l'extérieur qui échoue).
Un snapshot « propre » puis un snapshot avant chaque expérience permettent d'annuler toute erreur ; ce n'est toutefois pas une sauvegarde.
Désactivez presse-papiers partagé, dossiers partagés et périphériques inutiles sur les machines à risque.

Votre laboratoire est techniquement prêt. Il reste à fixer la règle du jeu : ce qui est permis, ce qui ne l'est pas, et comment garder une pratique saine et légale. C'est la dernière leçon de ce chapitre.