01 / Scénario & problème
La segmentation fonctionne tant que les systèmes qui relient les zones réseau restent dignes de confiance.
Le laboratoire académique utilise trois machines virtuelles. Kali peut joindre le serveur web Ubuntu mais pas le serveur Debian de base de données. Ubuntu possède une interface dans chaque zone et peut communiquer avec les deux côtés.
Démontrer, dans un environnement isolé et volontairement vulnérable, comment une exécution de commandes sur le serveur exposé peut être transformée en accès indirect au réseau interne.
Il s’agit d’un exercice académique de pentest autorisé. La page explique l’architecture, le raisonnement et les preuves sans reproduire les charges d’injection de commandes utilisées pendant le lab.
02 / Architecture initiale
Kali et Debian n’ont aucun chemin direct ; Ubuntu est la seule machine connectée aux deux côtés.
192.168.56.103
192.168.56.102 / 10.10.10.20
10.10.10.30
Kali peut communiquer avec le serveur web Ubuntu.
Ubuntu et Debian communiquent dans le réseau privé.
Le serveur web devient critique puisqu’il touche les deux zones.
03 / Stratégie & exécution du lab
Le pivot est une chaîne de petites étapes, pas une action unique de l’outil.
Vérifier l’état initial : Kali atteint Ubuntu mais pas Debian.
Utiliser le formulaire PHP volontairement vulnérable du lab pour exécuter des commandes sur Ubuntu.
Lancer l’agent Ligolo-ng sur Ubuntu et le connecter au proxy sur Kali.
Créer l’interface virtuelle et router 10.10.10.0/24 à travers le pivot.
Utiliser des outils réseau standards pour confirmer que Debian est désormais joignable.
machine externe
hôte pivot
hôte interne
04 / Résultat & preuves
L’hôte interne passe d’inaccessible à joignable à travers la machine intermédiaire compromise.
Une fois le tunnel actif, Kali peut atteindre 10.10.10.30. Le laboratoire utilise ensuite la reconnaissance réseau pour confirmer l’exposition de SSH (22) et MySQL (3306), puis une connexion SSH autorisée valide le chemin de bout en bout.
Kali ne peut pas joindre Debian directement.
Le trafic est routé à travers Ubuntu.
SSH et MySQL sur l’hôte interne.
05 / Signification réelle & défense
La leçon importante n’est pas le tunnel lui-même, mais l’endroit où le modèle de confiance se casse.
Un serveur interne segmenté peut redevenir joignable lorsqu’un système exposé est compromis et autorisé à communiquer entre plusieurs zones. Le laboratoire relie donc compréhension offensive et conception défensive.
Couche applicative
Valider les entrées et supprimer les chemins d’injection de commandes afin qu’un serveur exposé ne puisse pas devenir un shell distant.
Couche réseau
Appliquer le moindre privilège entre segments et limiter les connexions sortantes depuis les serveurs exposés.
Supervision hôte
Surveiller les processus inattendus, agents de tunnel, nouvelles interfaces virtuelles et changements de routes inhabituels.
Détection & réponse
Corréler connexions sortantes inhabituelles, reconnaissance interne et authentifications entre zones réseau.
Il rend concrets la segmentation, le routage Linux, le tunneling et la reconnaissance interne, tout en montrant pourquoi une défense multicouche reste nécessaire lorsqu’un hôte intermédiaire est compromis.
Constat principal : le serveur Ubuntu ne crée pas une nouvelle vulnérabilité réseau à lui seul ; sa compromission transforme une relation de confiance existante entre deux zones en chemin de pivot.
06 / Limites & apprentissages
Le laboratoire démontre un mécanisme de pivot, pas toute la complexité d’un réseau d’entreprise.
- Trois machines virtuelles dans un environnement isolé.
- Application PHP volontairement vulnérable pour l’exercice.
- Aucun système de production, utilisateur réel ou réseau non contrôlé.
- Le lab valide la connectivité et l’accès, pas la persistance, la furtivité ou un mouvement latéral à l’échelle d’un SI.
Ce que j’ai appris
Le plus utile a été de voir la segmentation sous les deux angles : d’abord comme une barrière, puis comme une protection qui peut échouer lorsqu’un hôte à deux interfaces devient un relais. Le résultat relie directement le mécanisme offensif aux contrôles défensifs à renforcer : moindre privilège réseau, limitation des sorties et surveillance des routes, interfaces et tunnels inattendus.