/ dev / tcp listen au lieu de nc listen


39

Avec un auditeur netcat comme:

nc -l <port> < ~/.bashrc

Je peux récupérer mon fichier .bashrc sur une nouvelle machine (n’a pas ncou LDAP) avec:

cat < /dev/tcp/<ip>/<port> > ~/.bashrc

Ma question est la suivante: y at-il un moyen de mimer les capacités de nc -l <port>ma première ligne avec / dev / tcp au lieu de nc?

Les machines sur lesquelles je travaille sont dans un environnement de laboratoire / sandbox extrêmement dur RHEL (pas de ssh, pas de nc, pas de LDAP, pas de miam, je ne peux pas installer de nouveau logiciel et ils ne sont pas connectés à Internet)


À part écrire un script python pour garder le socket ouvert, existe-t-il un moyen simple de réaliser cela?
h3rrmiller

Réponses:


23

Si Perl est installé (comme sur une machine RHEL):

perl -MIO::Socket::INET -ne 'BEGIN{$l=IO::Socket::INET->new(
  LocalPort=>1234,Proto=>"tcp",Listen=>5,ReuseAddr=>1);
  $l=$l->accept}print $l $_' < ~/.bashrc

fonctionnerait, à moins qu'un pare-feu local n'autorise pas les connexions entrantes vers 1234.

Si socat est installé:

socat -u - tcp-listen:1234,reuseaddr < ~/.bashrc

Si zsh est installé:

zmodload zsh/net/tcp
ztcp -ld3 1234 && # start listening socket on fd 3
  ztcp -ad4 3 && # accept connection on fd 4
  ztcp -c 3 && # close the listening socket that is no longer needed
  cat < ~/.bashrc >&4 && # send the data
  ztcp -c 4 # close the communication socket to tell the other end we're finished

La dernière ztcp -c 4commande ne devrait-elle pas lire 3? Sinon, bonne information, bon conseil.
dezza

@dezza, voir edit. Le socket sur le disque 3 n'était pas vraiment fermé (bien que cela se soit passé à la fin du script). Nous devons fermer le socket sur le disque 4 afin que l’autre extrémité reçoive un EOF.
Stéphane Chazelas

42

Malheureusement, c'est impossible avec juste bash. /dev/tcp/<ip>/<port>Les fichiers virtuels sont implémentés de la manière que bash tente de se connecter à la fonction spécifiée à l' <ip>:<port>aide de connect(2). Pour créer un socket d’écoute, il faudrait appeler une bind(2)fonction.

Vous pouvez vérifier cela en téléchargeant des bashsources et en le regardant. Il est implémenté dans le lib/sh/netopen.cfichier dans la _netopen4fonction (ou _netopen6, qui prend également en charge IPv6). Cette fonction est utilisée par la fonction wrapper netopendu même fichier, qui à son tour est directement utilisée dans le fichier redir.c( redir_special_openfonction) pour implémenter cette redirection virtuelle.

Vous devez trouver une autre application pouvant créer un socket d’écoute sur votre machine.


+1 le bash permet de créer le socket client mais le socket serveur vous pouvez utiliser nc ou peut être implémenté avec perl ou c, en fait le processus serveur lançera en boucle des connexions et des processus de spawn ou créer des threads
Nahuel Fouilleul

2
@NahuelFouilleul: Ce n'est pas tout à fait correct. Vous pouvez traiter beaucoup de clients avec un seul thread / processus en utilisant une programmation réseau "asynchrone" ou "pilotée par événement" (essayez de rechercher Google pour la fonction select () et son utilisation dans la programmation réseau). Dans de nombreux cas, il s'agit d'un moyen bien meilleur (plus rapide) d'accepter de nombreux clients.
Krzysztof Adamski

Merci, je n'ai pas pensé à cette solution
Nahuel Fouilleul

4
C'est à cela que sert xinetd. Il écoute et génère votre processus / script arbitraire pour toutes les connexions entrantes. Avec lui, tout peut devenir un serveur TCP / IP.
Evi1M4chine

0

Il n'y a pas moyen d'écouter parce que l'écoute n'est pas au rendez-vous comme l'a souligné Adamski.

Mais vous n'avez pas besoin d'écouter sur le client, vous n'avez donc pas besoin de netcat sur le client pour transférer des fichiers, par exemple:

## To send a file to the locked down computer: 
 ## Local server where you do have netcat 
cat ~/.bashrc | nc -l -q 1 -p 8998

 ## Remote locked down computer without netcat
cat < /dev/tcp/local.server.ip.addr/8998 > latest.bashrc 

## To grab a file from the locked down computer: 
 ## First - on the local server run 
nc -l -p 8998 -q 1 > remote.bashrc < /dev/null 

 ## Then on the locked down computer run: 
cat ~/.bashrc > /dev/tcp/local.server.ip.addr/8998 0<&1 2>&1

-3

vous pouvez le faire comme vous l'avez dit en demandant / dev / tcp avec bash:

</dev/tcp/host/port

s'il fonctionne immédiatement, il écoute, de toute façon il expire


4
Non, vous n'avez certainement pas testé cela et si vous l'avez fait, vous ne devez pas comprendre les résultats. Votre suggestion ouvrirait le socket (pas écouter) et redirigerait vers la commande que vous avez exécutée. Une réponse correcte a déjà été trouvée (il y a presque 6 ans ...) donc je ne suis pas sûr de savoir pourquoi vous avez choisi de nécro cette question.
h3rrmiller
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.