A la découverte de l’utilitaire netcat sur Linux

I. Presentation

Depuis le temps vous aurez sans doute remarqué que GNU/Linux fournit à peu près tous les outils nécessaires à la communication entre machines. D'ailleurs pour ce billet je vous propose de découvrir l’un de ces utilitaires que l’on a tendance à oublier et qui, pourtant rend de fiers services de transmission. Je veux vous parler de netcat, abrégé en nc.

Son installation est des plus simple. On doit installer le package nmap-ncat qui se trouve dans le dépôt de base de la distribution GNU/Linux CentOS. Le binaire se trouve placé dans /usr/bin. Pour s’en convaincre, il suffit depuis une machine Linux CentOS7 d’exécuter :

# rpm -qf /usr/bin/nc
nmap-ncat-6.40-19.el7.x86_64

REMARQUE: cela signifie que normalement le package faisant partie du dépôt de base, il n’est pas nécessaire de l’installer. Mais, si ce n’était pas le cas, alors vous pouvez effectuer son installation via la commande :

# yum install nmap-ncat

En version CentOS 8, le package est toujours nmap-ncat (dans sa version 7.70), mais le dépôt d’appartenance est @System, comme l’atteste la capture suivante :

Cet outil est disponible de façon générale sur les systèmes Unix, Windows, et MacOS X. Sa fonctionnalité principale consiste à ouvrir les connexions réseau localement sur la machine tout en envoyant les paquets de façon synchrone (paquets TCP) ou asynchrone (paquets UDP).

En fait, il gère les sockets (ou connexions réseau), en établissant n’importe quelle communication vers un serveur distant, en choisissant l’adresse IP et le port et en ouvrant ce dernier en écoute de paquets entrants et/ou sortants. On peut véritablement parler de couteau suisse car, comme nous allons le voir, sa façon d’établir des connexions permet de nombreuses autres applications.

II. Mise en communication

La façon la plus simple d’utiliser nc est d’ouvrir une communication en mode serveur grâce à la commande suivante :

$ nc -l -p <n°Port TCP>

Du côté du client, on peut alors ouvrir une autre session et exécuter la commande suivante :

$ nc @IPServeur <n° Port>

REMARQUE : si l’on doit communiquer via un port UDP, il suffit d’ajouter l’option -u aux commandes côté serveur :

$ nc -l -u -p <n°Port TCP>

Et côté client :

$ nc -u @IPServeur <n° Port>

Ainsi, par exemple, pour ouvrir une communication via le port TCP/8000, sur un serveur dont l’adresse principale est 192.168.1.3, on devra exécuter la commande en mode serveur suivante :

$ nc -l -p 8000

Ensuite, il faudra ouvrir une autre session qui servira de client afin d’exécuter l’instruction suivante :

$ nc 192.168.1.3 8000

Du coup, cela ouvre de nombreuses perspectives d’applications. En effet, grâce à ce mécanisme, on peut facilement transférer de l’information quelle qu’elle soit, au travers du réseau d’entreprise.

III. Transfert d'information

Le plus évident consiste à transférer le contenu d’un fichier qu’il s’agisse d’un fichier de données ou de configuration. Prenons l’exemple du fichier /etc/passwd.

REMARQUE : par précaution, on prendra une copie de ce fichier que l’on déposera dans son propre répertoire d’accueil :

$ sudo cp /etc/passwd ~/mypasswd.orig

Supposons qu’un de nos collègues souhaite nous envoyer le fichier de ses utilisateurs afin que nous disposions des mêmes comptes (uid, gid…) que sur son serveur. Pour se faire, on va lui ouvrir une communication via netcat sur notre terminal, dans un sous-répertoire Recup (pour pouvoir prouver que le protocole fonctionne correctement), en exécutant :

$ cd Recup
$ nc -l -p 8000 > mypasswd.copie

Depuis son terminal, le collègue peut alors exécuter l’instruction suivante :

$ nc <notre @IP> < $HOME/mypasswd.orig

Au niveau de notre terminal, cela va déclencher le transfert d’information, avec l’affichage suivant :

ATTENTION : l’ordre dans lequel doivent être effectuées les commandes est très important. C’est le demandeur qui ouvre sa session netcat en premier et seulement alors, l’émetteur peut alors déclencher le transfert. Dans le cas contraire on obtient un message d’erreur “Ncat : connection refused“.

Du côté de l’émetteur, si l’on a utilisé l’option de verbosité -vv, l’affichage est le suivant :

De notre côté, si l’on regarde le contenu de notre répertoire Recup, on listera alors le fichier passwd.copie que l’on vient de récupérer :

Maintenant, ce mécanisme de transfert n’étant pas sans risque, puisque l’on ignore par quel(s) relai(s) le fichier est passé, il faut être prudent et à la réception du fichier souhaité, on doit vérifier son intégrité via la commande md5sum :

$ md5sum passwd.copie
d41d8dc98f00b204e9800998ecf8427e

REMARQUE: le code d’intégrité du fichier original peut également être envoyé de la même façon via netcat et on devrait alors récupérer le code suivant : d41d8dc98f00b204e9800998ecf8427e

On peut également interroger le système via un navigateur de façon à être encore plus efficace, grâce à l’url suivante : http://localhost:8000. On peut aussi récupérer le fichier au travers de requêtes wget ou curl.

Voici un bref récapitulatif des différentes options disponibles pour la commande nc :

IV. Scan de ports

Par ailleurs, l’utilitaire nc permet également, comme on peut le constater dans le tableau des options ci-dessus, de scanner les ports de services grâce à l’option -z :

$ nc -z <Host> <n° Port>

Par exemple, pour scanner les ports standards : 80 (http), 22 (ssh), 21 (ftp) ou 443 (https), on doit exécuter les commandes suivantes :

V. Rebond de connexion SSH

La procédure de connexion d’une machine à une autre est grandement simplifiée grâce à l’utilisation des clés de chiffrement SSH. Cependant, les normes de sécurité devenant de plus en plus restrictives, les administrateurs réseau choisissent le plus souvent de contrôler les flux entrants et sortants de leur réseau, en bloquant les connexions directes depuis un serveur ou un poste client vers un serveur externe et réciproquement. Cela implique alors de faire passer les flux par un serveur mandataire (aussi appelé proxy), filtrant à la fois les connexions entrantes et sortantes :

Contrairement à d’autres utilitaires, les connexions ssh et les transferts d’information au travers du protocole SSH, entre machines clientes et serveurs ne possèdent aucun dérivatif pour mentionner l’utilisation d’un proxy, comme on peut le faire au travers des variables http_proxy pour yum, wget et curl.

Du coup, pour effectuer des connexions avec rebond cela peut vite devenir fastidieux. En effet, dans le cas de la copie d’un fichier depuis le client d’un réseau local vers un poste ou un serveur distant, il faudrait effectuer les tâches suivantes :

• Copie du ou des fichiers sur le proxy
• Connexion au proxy
• Copie du ou des fichiers sur le serveur distant, depuis le proxy

Alors me direz-vous qu’est-ce cela a à voir avec nc ? Et bien en fait ce petit outil va nous permettre d’établir une connexion transparente au travers du proxy afin d’atteindre le serveur distant. La première étape nécessaire pour mettre en place un rebond ssh, consiste à générer les clés de chiffrement sur chacune des machines concernées : à savoir, sur le client, sur le proxy et aussi sur le serveur distant. Bien sûr, l’opération reste possible en utilisant des mots de passe. Mais, cela demeure malgré tout aussi laborieux.

Il faut ensuite créer un fichier ~/.ssh/authorized_keys sur chacune des machines concernées (le client, le proxy et le serveur distant), et il faut aussi copier dans ce fichier, le contenu des parties publiques des différentes clés de chiffrement utilisées sur les deux autres machines.

REMARQUE : cela va permettre notamment d’activer la connexion par clé dans les deux sens : Client => Proxy => Serveur (noté sens 1) et aussi dans le sens Serveur => Proxy => Client (noté sens 2).

En ce qui concerne le sens 1, on doit établir une connexion uniquement en copiant la clé publique du client dans le fichier ~/.ssh/authorized_keys du proxy, ainsi que les deux clés publiques du proxy et du client, dans ce même fichier, sur le serveur distant. Une fois cette étape réalisée, on peut alors créer un fichier appel é config que l’on place dans le répertoire ~/.ssh de la machine client dans lequel on déclare les instructions suivantes :

Host=<Proxy>
Hostname=<Proxy FQDN>
User=<User Proxy>

Host=<Server>
User=<Login Server>
ProxyCommand=ssh <Proxy> nc <Server FQDN> 22

Les trois premières lignes indiquent les instructions relatives à la connexion sur le proxy et les trois dernières concernent la connexion au serveur distant, depuis la machine ou le poste client. C’est grâce au contenu du champ ProxyCommand que l’on autorise l’ouverture d’une session de communication au travers de sockets d’un point à un autre, en utilisant la commande nc via le protocole SSH.

la commande nc peut varier d’une distribution à une autre et/ou d’un système d’exploitation à un autre. Il faut donc bien lire le manuel en ligne afin de disposer des bonnes options.

ATTENTION : les options et arguments de la commande nc ne dépendent pas de l’implémentation de la commande présente sur le poste client, mais de celle présente sur le proxy.

Ensuite, le fichier config que l’on vient de créer ne doit être accessible que par l’utilisateur qui en est le véritable propriétaire et uniquement en lecture-écriture. On doit donc exécuter sur ce fichier la commande suivante :

$ chmod 600 ~/.ssh/config

Dès lors après la création de ce même fichier, une simple commande ssh permet de vérifier la bonne configuration pour la connexion directe :

$ ssh <Server>

Ainsi, la connexion via le proxy passe inaperçue. Le grand avantage de ce mécanisme n’est pas seulement de permettre une connexion plus simple, mais aussi de rediriger de façon sécurisée et maitrisée toute opération ssh, depuis un client vers un ou plusieurs serveurs distants. Le principe reste également vérifiable pour des transferts de fichiers :

$ scp <File> <Server>

Pour établir un lien dans le sens 2 de la communication, il faut également créer un fichier config sur le serveur distant, contenant les lignes suivantes :

Host=<Proxy>
Hostname=<Proxy FQDN>
User=<User Proxy>

Host=<Client>
User=<Login>
ProxyCommand=ssh <Proxy> nc <Client FQDN> 22

VI. Conclusion

Ainsi, à l’avenir lorsque vous aurez besoin d’établir une communication entre deux serveurs quels qu’ils soient, il vous suffira d’utiliser nc (alias netcat). Par ailleurs, comme l’a prouvé le paragraphe précédent, savoir configurer ses communications ssh peut être très utile car cela permet d’établir des connexions avec rebonds de façon transparente. Là encore nc rend de fiers services.

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

See Full Bio