Dans ce tutoriel, nous allons voir comment réaliser un scan réseau avec Nmap en passant par un tunnel SSH. Autrement dit, nous allons utiliser une machine de rebond pour atteindre un réseau ou une machine.
Cette méthode est intéressante lorsque votre machine de scan ne peut pas joindre directement un réseau cible, mais qu’elle dispose d’un accès à une machine intermédiaire capable, elle, d’atteindre ce réseau. Cette machine intermédiaire joue alors le rôle de pivot, aussi appelée “machine de rebond”.
On retrouve ce cas de figure lors des situations suivantes :
Un test d’intrusion, avec un premier système compromis ;
Une vérification du cloisonnement réseau ;
Un diagnostic d’accessibilité ;
L’administration de systèmes sur un réseau isolé ;
Une validation de flux entre segments réseau.
Plutôt que de mettre en place un routage complet, un VPN temporaire ou des règles réseau spécifiques, il est possible d’utiliser un mécanisme léger et simple à mettre en œuvre. Dans ce tutoriel, nous allons utiliser un proxy SOCKS créé localement grâce à SSH, Proxychains pour forcer certains outils à utiliser ce proxy, puis Nmap pour exécuter les scans au travers de ce chemin indirect.
Dans ce contexte, votre trafic Nmap ne part pas directement vers la cible. Il passe d’abord dans un proxy SOCKS local, encapsulé dans un tunnel SSH, avant d’être relayé par la machine pivot vers le réseau cible. Et surtout, pas besoin d’outils sur la machine de rebond, ni de droits d’administration.
Note : cette technique s’utilise uniquement dans un cadre autorisé (audit, pentest mandaté, administration de vos propres systèmes). Scanner un réseau ou une machine sans autorisation est illégal.
Pourquoi utiliser un tunnel SSH SOCKS avec Proxychains ?
Dans ce scénario, la combinaison SSH + Proxychains présente plusieurs avantages :
Nous nous appuyons sur SSH, un protocole généralement déjà disponible ;
On évite de modifier la table de routage de la machine locale ;
Pas besoin de droits d’administration avancés sur tout l’environnement, ni de nouveaux outils à installer ;
C’est quoi un tunnel SSH ?
Nous allons utiliser la commande ssh -D pour créer un proxy SOCKS local sur notre machine de rebond. Il s’agit d’une option intégrée à SSH qui lui permet d’ouvrir un port local, par exemple 127.0.0.1:1080, et tout client compatible SOCKS peut envoyer son trafic sur ce port.
SSH se charge ensuite de transporter ce trafic jusqu’à la machine distante connectée via la session SSH. C’est cette machine distante qui établira les connexions finales vers les hôtes du réseau cible. Autrement dit :
Votre outil parle au proxy SOCKS local, il entre dans un “tunnel”.
Le proxy s’appuie sur la session SSH, donc il transit d’une machine à l’autre à l’intérieur du protocole SSH ;
La machine distante devient le point de sortie réseau (du “tunnel”) vers la cible.
Dès lors, nos outils “locaux” peuvent communiquer avec tous les systèmes et services situés derrière notre machine de rebond (sortie du tunnel).
Quel est le rôle de Proxychains ?
Tous les outils n’intègrent pas nativement la gestion des proxys SOCKS. C’est là que Proxychains nous sera utile. Il permet de forcer une application à utiliser un ou plusieurs proxys définis dans un fichier de configuration. Il intercepte les appels réseau effectués par le programme et les redirige vers le proxy configuré.
Dans notre cas, cela permet de faire passer Nmap au travers du proxy SOCKS créé par SSH.
Note : Proxychains ne transforme pas Nmap en outil “magique” capable de tout faire au travers d’un proxy. Certains types de scans restent inadaptés, car non compatibles avec l’utilisation d’un proxy, notamment ceux qui reposent sur des paquets bruts.
Lab et pré-requis
Pour illustrer cette manipulation, je me situe dans le lab suivant, qui schématise un cas classique d’utilisation d’un rebond :
Kali (192.168.57.3) : machine de scan sur laquelle sont lancés SSH, Proxychains et Nmap;
Debian1 (interface 1 : 192.168.57.101, interface 2 : 192.168.56.101) machine pivot, accessible depuis Kali et connectée au réseau cible ;
Debian2 (192.168.56.102) machine cible à scanner, non joignable directement par Kali, mais accessible depuis Debian1.
Dans ce contexte, Kali peut joindre Debian1 sur le réseau 192.168.57.0/24, mais n’a pas d’accès direct à Debian2 sur le réseau 192.168.56.0/24. En revanche, Debian1 est connectée aux deux réseaux. Elle peut donc servir de machine de rebond. Le chemin logique sera donc : Kali > proxy SOCKS local > tunnel SSH > Debian1 > Debian2
Sur votre système de scan (dans mon cas : Kali), vous devez disposer des éléments suivants :
sudo apt update
sudo apt install -y openssh-client proxychains4 nmap
Et sur la Debian1, il vous faudra bien sûr un service SSH en écoute sur l’interface connectée à votre système de scan. Pas de l’outil nmap sur Debian1, c’est là tout l’intérêt !
Scan Nmap au travers d’une machine de rebond
Créer le tunnel SSH dynamique
Depuis notre système de scan, on ouvre le tunnel SOCKS avec la commande suivante :
ssh -D 1080 -N -f [email protected]
Après avoir saisi le mot de passe, il ne se passe visiblement rien, grâce à l’option -f qui envoie SSH en arrière-plan après l’authentification. L’option -N permet de ne pas exécuter de commande distante (la session sert uniquement au tunnel). Enfin, c’est l’option -D 1080 qui crée le proxy SOCKS local sur le port indiqué.
Une fois cette commande exécutée, votre système écoute localement sur 127.0.0.1:1080. Pour le confirmer, regardons les ports en écoute :
$ ss -lntp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:* users:((“ssh”,pid=30152,fd=5))
LISTEN 0 128 [::1]:1080 [::]:* users:((“ssh”,pid=30152,fd=4))
Vous devez voir un processus SSH à l’écoute sur ce port. Si rien n’écoute sur le port 1080 :
Vérifiez que l’authentification SSH vers le système de rebond fonctionne ;
Relancez la commande sans -f pour voir les éventuels messages d’erreur ;
Assurez-vous que le port local 1080 n’est pas déjà utilisé.
Configurer Proxychains
Le fichier de configuration est généralement situé ici :
sudo nano /etc/proxychains4.conf
# ou
sudo nano /etc/proxychains.conf
Le plus important est de vérifier que la dernière ligne cible bien notre proxy, c’est-à-dire le port 127.0.0.1:1080 :
Extrait de configuration proxychains.
Très rapidement pour les autres options visibles sur cette capture d’écran :
strict_chain : force l’utilisation stricte des proxys déclarés
proxy_dns : permet de faire passer les résolutions DNS via le proxy, utile pour éviter les fuites DNS
tcp_read_time_out et tcp_connect_time_out : indique les délais au-delà desquels proxychains abandonne la connexion. Ils vous seront utiles pour rendre plus rapides vos scans nmap réalisés à travers ce proxy.
Dans notre lab, nous utiliserons des adresses IP, donc ce point est moins critique, mais il reste recommandé de le conserver.
Valider le pivot avant d’utiliser Nmap
Avant de lancer Nmap, il est fortement conseillé de vérifier que le trafic passe bien par le proxy SOCKS. Par exemple, en testant le port TCP/22 du système cible situé derrière notre système de rebond :
$ proxychains4 nc -vz 192.168.57.102 22
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] Strict chain … 127.0.0.1:1080 … 192.168.56.102:22 … OK
192.168.56.102 [192.168.56.102] 22 (ssh) open : Operation now in progress
Comme vous le voyez, il faut ici préfixer notre commande nc avec proxychains4 pour que tout le trafic réseau de notre commande passe par le tunnel SSH. Si le port 22 est ouvert sur Debian2, vous devriez obtenir une confirmation de connexion. La ligne importante ici, est celle finissant par “OK”, cela indique que proxychains a bien réussi à joindre le port de destination. Vous pouvez cacher cette ligne de journalisation générée par proxychains à l’aide de l’option -q :
proxychains4 -q nc -vz 192.168.57.102 22
Ce test est utile, car il permet de valider, dans l’ordre : le tunnel SSH, la configuration Proxychains, l’accessibilité réseau entre Debian1 et Debian2 et la présence d’un service sur le port ciblé.
Si le test échoue, vérifiez :
Que le tunnel SSH est toujours actif ;
Que Proxychains pointe bien sur 127.0.0.1:1080 ;
Que Debian1 peut joindre Debian2 ;
Que le service visé écoute bien sur la cible.
Réaliser le scan Nmap
Avant de lancer un scan, il faut savoir que Nmap, lorsqu’il passe par un proxy SOCKS, peut utiliser différentes techniques. Certaines s’appuient sur les fonctions réseau classiques du système, comme connect(), pour établir des connexions, tandis que d’autres envoient directement des paquets bruts. Proxychains agit principalement au niveau des connexions établies par ces fonctions classiques, ce qui le rend surtout adapté aux modes de scan qui utilisent ces appels standard pour communiquer.
C’est pourquoi, dans ce contexte, le mode de scan recommandé est -sT (TCP Connect Scan). Il permet d’établir une connexion TCP classique (Three way Handshake) vers les ports ciblés. Proxychains peut alors rediriger cette connexion vers le proxy SOCKS.
Par défaut, Nmap commence souvent par une phase de découverte d’hôte afin de déterminer si la cible est “up”. Cette phase peut s’appuyer sur des mécanismes qui se comportent mal via un proxy (notamment le ping). L’option -Pn indique à Nmap de considérer l’hôte comme actif et de passer directement au scan des ports. Lorsque l’on passe par proxychains, ces deux options de Nmap sont donc obligatoires, ce qui peut restreindre ses cas d’utilisation.
Lançons à présent notre scan à l’aide des options en question :
$ proxychains4 -q nmap -sT -Pn 192.168.56.102
Starting Nmap 7.99 ( https://nmap.org ) at 2026-06-30 20:24 +0200
Nmap scan report for 192.168.56.102
Host is up (0.00s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
8080/tcp open http-proxy
Nous venons ici d’effectuer un scan réseau via Nmap à travers notre machine de rebond, en ciblant une IP qui n’était à la base pas joignable par notre système de scan.
Note : si vous constatez que la communication via Proxychains fonctionne avec d’autres outils, mais que Nmap peine à détecter des ports ouverts, le problème peut venir des dépendances dynamiques de Nmap, qui l’amènent à contourner Proxychains. Une piste consiste alors à utiliser une version de Nmap compilée en statique. Les sources sont disponibles sur nmap.org/dist. Après compilation, exécutez le binaire ainsi produit via Proxychains (proxychains4 ./nmap …).
Pour aller plus loin : apprendre à maitriser Nmap
Utiliser Nmap via un tunnel SSH et Proxychains est une technique puissante, mais elle ne représente qu’une infime partie des cas d’usage de cet outil. Comme nous l’avons vu, une mauvaise configuration (choix du scan, gestion des proxys, interprétation des résultats) peut mener à des faux négatifs, des latences inutiles, ou pire, des perturbations réseau.
Ce tutoriel couvre un cas pratique spécifique, mais pour devenir opérationnel sur Nmap, que ce soit pour de la cartographie réseau, de la recherche de vulnérabilités ou des tests d’intrusion, une formation structurée est indispensable.
J’ai rédigé un livre de 160 pages dédié à la maîtrise avancée de Nmap, conçu pour :
Maitriser Nmap, comprendre son fonctionnement et ses limites
Rendre plus efficace vos scans (choix des options, interprétation des résultats).
Améliorer vos audits (éviter les faux positifs, limiter l’impact réseau).
Automatiser vos procédures (scripts NSE, intégration avec d’autres outils).
Couvrir tous les cas d’usage.
L’objectif ? Vous rendre opérationnel pour une utilisation efficace, sûre et optimisée de cet outil pour sécuriser votre système d’information, que vous soyez administrateur réseau, système, pentester ou RSSI.
Si vous débutez avec l’outil ou souhaitez éviter ces pièges, vous pouvez aussi lire le cours complet dédié à la cartographie réseau et au scan de vulnérabilités avec Nmap, ainsi que notre article sur les erreurs fréquentes à éviter lors d’un scan Nmap. Pour aller vers l’exploitation, l’article sur les scripts NSE incontournables prolonge cette lecture.
Conclusion
L’utilisation de Nmap via un tunnel SSH dynamique et Proxychains est une solution simple et efficace pour réaliser des scans dans un environnement segmenté à l’aide d’un hôte pivot. Cette méthode ne remplace pas un routage complet, mais elle répond très bien à différents besoins comme des tests ponctuels, du debug réseau, des tests de cloisonnement, etc.
Attention toutefois, les résultats obtenus doivent être consultés avec précaution. Le fait de scanner via un tunnel SSH SOCKS et Proxychains introduit une couche intermédiaire qui peut amener à plus de latence, davantage de dépendance à la stabilité de la session SSH, des limitations sur certains types de scans et de possibles différences de comportement entre un scan direct et un scan proxifié.
FAQ
Peut-on scanner un réseau isolé avec Nmap sans rien installer sur la machine pivot ?
Oui. La machine pivot a seulement besoin d’un service SSH en écoute. Le proxy SOCKS est créé côté machine de scan avec l’option ssh -D, et Nmap comme Proxychains restent installés uniquement sur cette machine de scan. Aucun outil ni droit d’administration n’est requis sur le pivot.
Pourquoi faut-il utiliser les options -sT et -Pn avec Nmap à travers Proxychains ?
Proxychains n’intercepte que les connexions établies via les appels réseau standard du système, comme connect(). L’option -sT (TCP Connect Scan) utilise ce mécanisme, contrairement aux scans à base de paquets bruts. L’option -Pn désactive la phase de découverte d’hôte (souvent basée sur le ping), qui se comporte mal à travers un proxy SOCKS.
Les scans UDP (-sU) fonctionnent-ils via un tunnel SSH SOCKS ?
Non. Proxychains ne prend en charge que le protocole TCP. Les scans UDP, tout comme les scans reposant sur des paquets bruts (SYN scan -sS, scan ICMP, etc.), ne transitent pas correctement par le proxy SOCKS. Pour ces besoins, il faut privilégier un routage ou un VPN vers le réseau cible.
Comment accélérer un scan Nmap réalisé à travers Proxychains ?
Un scan proxifié est plus lent qu’un scan direct. Pour limiter cette latence, ajustez les paramètres tcp_connect_time_out et tcp_read_time_out dans le fichier de configuration de Proxychains, et réduisez le périmètre du scan côté Nmap en ciblant des ports précis avec -p plutôt que l’ensemble des ports. L’option -q rend par ailleurs la sortie plus lisible.
Co-fondateur d’IT-Connect.fr.
Auditeur/Pentester chez Orange Cyberdéfense.