Ciò si riferisce a una domanda precedente che stava diventando troppo lunga e confusa a causa dei miei costanti aggiornamenti e modifiche e mi è stato detto di ri-chiederlo. Quindi lo sto ripulendo e sto facendo una domanda più diretta.

Prima di tutto, questa è una sperimentazione teorica che devo fare per imparare come funzionano i tunnel ssh avanti e indietro e in particolare per poter mantenere il controllo completo di dove mi trovo sulla rete in ogni momento e nascondere i miei passi durante il processo. Il mio allenatore mi ha affidato questo compito ma confida che lo capirò da solo senza l'aiuto di lui.

Devo trovare un modo per forzare RDP(Desktop remoto) a rispondere a una porta specifica anziché a un RHP (Random High Port). Non sto chiedendo come cambiare su quale porta RDP"Ascolta", ma piuttosto il contrario.

Sto tentando di impostare un SSHtunnel sperimentale avanti / indietro tra due sistemi. Sto usando un terzo sistema come punto Pivot per nascondere il mio IP sul tunnel forward. Ma voglio che il sistema in cui sto effettuando il Remoting attraverso il tunnel SSH Forward invii la risposta attraverso un SSHtunnel inverso separato a una porta "Specificata" anziché a un RHP. L'idea di base è che voglio essere in grado di controllare quali porte voglio ascoltare e / o ricevere e non voglio che nulla sia casuale.

Queste sono le mie tre macchine. Devilsmilkè il punto di snodo, il client è acceso kgravese sto scrivendo duclaw.

• KGRAVES - 10.0.10.113
• DEVILSMILK - 10.0.10.121
• DUCLAW - 10.0.10.120

Quindi voglio avere due pipe per la mia RDPsessione. Uno per l'avanti e l'altro per il contrario. Ma non voglio rispedirlo su un RHP. Non riesco a capire come dirlo per inviarlo a una porta specifica, :44444ad esempio.

Qualcuno sa come fare questo?

Ho bisogno che questo sia fatto in un modo specifico. Queste sono le porte che devo usare. Ho già impostato Duclawper l'ascolto RDPsu porta 1337anziché 3389. So che questo non è affatto il modo più semplice per farlo.

Ho bisogno che la connessione desktop remoto "appaia" come se provenisse da ciò devilsmilkche sta già avvenendo secondo WireShark. Ma voglio duclawinviare la risposta direttamente a kgravessenza passare devilsmilk. Quindi, per kgravesla RDPsessione viene inviato al localhostquale viene poi trasmesso attraverso sshtunnel attraverso devilsmilkdi duclaw, ma i RDPpacchetti che vengono ricevuti in risposta a questo proposito sono ricevuti direttamente da Duclaw. Attualmente la risposta sta tornando su un RHP attraversodevilsmilk

I miei comandi sono i seguenti e tutti vengono eseguiti dalla stessa identica CYGWIN sshconsole attiva ad kgraveseccezione della mstscconnessione che ho fatto da un altro CYGWINterminale acceso kgravesho aggiunto un'interruzione di linea per lo switch:

CNO\kgraves@KGRAVES ~
$ ssh -vg -L 3333:localhost:6666 misfitred@devilsmilk
OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to devilsmilk [10.0.10.121] port 22.
debug1: Connection established.
debug1: identity file /home/kgraves/.ssh/id_rsa type 1
debug1: identity file /home/kgraves/.ssh/id_rsa-cert type -1
debug1: identity file /home/kgraves/.ssh/id_dsa type -1
debug1: identity file /home/kgraves/.ssh/id_dsa-cert type -1
debug1: identity file /home/kgraves/.ssh/id_ecdsa type -1
debug1: identity file /home/kgraves/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
key_read: uudecode devilsmilk ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwVZRlnAgPRPxTx           cbTPALg5XPpOnAMhJabQ3Dv/7a95eqe5l7XnKRciYQZ41B61DRgXCzC/M9ObknMR79zG0mkSl+jQTGJ7           klol7nw0+U1dNFknv4fOn+YGAsqECclWEow3OK5xRcla5eBekRGWjrZ7Wbs4F3FeKGQNqU/OuGvdSaQb           3nqgLPGTZfRhNtykQvpNzXw5cjO7XvM0BBv9di4JblLx9Fk3iq2KwdgWmK9uFDPYjU1gkHR8hk+bns1t           16KFcyDKnzhR1CblU6JT/wlBtnFa11no1UJBEHC2UQy8trwkMU6NqUt0X+D/XqW5F6+uWNc/dY97CCky           9HdfWNGQ==
 failed
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA b5:d6:eb:64:50:2f:40:04:32:10:bb:4f:a8:d3:f5:37
key_read: uudecode devilsmilk ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwVZRlnAgPRPxTx           cbTPALg5XPpOnAMhJabQ3Dv/7a95eqe5l7XnKRciYQZ41B61DRgXCzC/M9ObknMR79zG0mkSl+jQTGJ7           klol7nw0+U1dNFknv4fOn+YGAsqECclWEow3OK5xRcla5eBekRGWjrZ7Wbs4F3FeKGQNqU/OuGvdSaQb           3nqgLPGTZfRhNtykQvpNzXw5cjO7XvM0BBv9di4JblLx9Fk3iq2KwdgWmK9uFDPYjU1gkHR8hk+bns1t           16KFcyDKnzhR1CblU6JT/wlBtnFa11no1UJBEHC2UQy8trwkMU6NqUt0X+D/XqW5F6+uWNc/dY97CCky           9HdfWNGQ==
 failed
The authenticity of host 'devilsmilk (10.0.10.121)' can't be established.
RSA key fingerprint is b5:d6:eb:64:50:2f:40:04:32:10:bb:4f:a8:d3:f5:37.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'devilsmilk' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/kgraves/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Trying private key: /home/kgraves/.ssh/id_dsa
debug1: Trying private key: /home/kgraves/.ssh/id_ecdsa
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to devilsmilk ([10.0.10.121]:22).
debug1: Local connections to *:3333 forwarded to remote address localhost:6666
debug1: Local forwarding listening on :: port 3333.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 0.0.0.0 port 3333.
debug1: channel 1: new [port listener]
debug1: channel 2: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Last login: Wed Jan 30 16:13:02 2013 from kgraves.cno.local
[misfitred@devilsmilk ~]$ ssh -vg -L 6666:localhost:1337 kgraves@duclaw
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to duclaw [10.0.10.120] port 22.
debug1: Connection established.
debug1: identity file /home/misfitred/.ssh/id_rsa type 1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'duclaw' is known and matches the RSA host key.
debug1: Found key in /home/misfitred/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: publickey
debug1: Offering public key: /home/misfitred/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: password
kgraves@duclaw's password:
debug1: Authentication succeeded (password).
debug1: Local connections to *:6666 forwarded to remote address localhost:1337
debug1: Local forwarding listening on 0.0.0.0 port 6666.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on :: port 6666.
debug1: channel 1: new [port listener]
debug1: channel 2: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Wed Jan 30 15:55:29 2013 from devilsmilk.cno.local
"tty" option detected in CYGWIN environment variable.
CYGWIN=tty is no longer supported.  Please remove it from your
CYGWIN environment variable and use a terminal emulator like mintty,
xterm, or rxvt.

kgraves@DUCLAW ~
$ ssh -vg -R 3333:devilsmilk:6666 kgraves@kgraves
OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to kgraves [10.0.10.113] port 22.
debug1: Connection established.
debug1: identity file /home/kgraves/.ssh/id_rsa type 1
debug1: identity file /home/kgraves/.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA de:1c:37:d7:84:0b:f8:f9:5e:da:11:49:57:4f:b8:f1
debug1: Host 'kgraves' is known and matches the ECDSA host key.
debug1: Found key in /home/kgraves/.ssh/known_hosts:3
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/kgraves/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: password
kgraves@kgraves's password:
debug1: Authentication succeeded (password).
Authenticated to kgraves ([10.0.10.113]:22).
debug1: Remote connections from LOCALHOST:3333 forwarded to local address devils           milk:6666
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: remote forward failure for: listen 3333, connect devilsmilk:6666
Warning: remote port forwarding failed for listen port 3333
debug1: All remote forwarding requests processed
Last login: Wed Jan 30 16:21:12 2013 from duclaw.cno.local
"tty" option detected in CYGWIN environment variable.
CYGWIN=tty is no longer supported.  Please remove it from your
CYGWIN environment variable and use a terminal emulator like mintty,
xterm, or rxvt.
_____________________________________________________________________________
##From separate CYGWIN Terminal##
CNO\kgraves@KGRAVES ~
$ mstsc /v:localhost:3333 /f

CNO\kgraves@KGRAVES ~
$
_____________________________________________________________________________

kgraves@KGRAVES ~
$ debug1: Connection to port 3333 forwarding to localhost port 6666 requested.
debug1: channel 4: new [direct-tcpip]
debug1: Connection to port 6666 forwarding to localhost port 1337 requested.
debug1: channel 4: new [direct-tcpip]
debug1: channel 4: free: direct-tcpip: listening port 3333 for localhost port 66                          66, connect from ::1 port 49496, nchannels 5
debug1: channel 4: free: direct-tcpip: listening port 6666 for localhost port 13                          37, connect from 127.0.0.1 port 48808, nchannels 5
debug1: Connection to port 3333 forwarding to localhost port 6666 requested.
debug1: channel 4: new [direct-tcpip]
debug1: Connection to port 6666 forwarding to localhost port 1337 requested.
debug1: channel 4: new [direct-tcpip]
$ debug1: channel 3: free: direct-tcpip: listening port 3333 for localhost port 6666, conne               ct from ::1 port 49495, nchannels 5
debug1: channel 3: free: direct-tcpip: listening port 6666 for localhost port 1337, connect                from 127.0.0.1 port 48807, nchannels 5
$

Connessione desktop remoto a localhost: 3333 è stata stabilita correttamente. E come puoi vedere sembra provenire da devilsmilksopra duclaw. Ma secondo kgravesesso sta tornando da Devilsmilk.

Questa è un'istantanea wiresharkdell'esecuzione su duclaw durante la RDPsessione:

Questa è un'istantanea wiresharkdell'esecuzione kgravesdurante la RDPsessione:

Quindi il mio problema rimane che voglio che Duclaw rispedisca la sessione RDP a Kgraves-pc attraverso un tunnel inverso completamente separato. Questo è ciò di cui ho bisogno per accadere e non riesco a capire come fare.

Non solo devo duclawrispedirlo in un tunnel separato direttamente kgravessenza passare devilsmilk, ma devo anche controllare a quale porta effimera a cui lo invia. Voglio che lo invii alla porta :44444anziché a una porta effimera casuale. Si sta usando in :48809modo casuale nella sshstampa dettagliata del debug sopra.

Nelle prime fasi, l'utente John Siu mi ha spiegato che ciò non è possibile a causa della natura della comunicazione TCP. Perché kgravessi aspetta una connessione da localhost da quando è stata stabilita con localhost. Quindi ci deve essere un modo per duclawinviare la sessione, kgravesma deve essere inoltrata per apparire come se forse venisse localhost?

Ma il mio trainer mi ha detto che a causa della natura della RFC per 127.0.0.1 (Localhost) l'handshake a tre vie TCP non lascia mai il layer 4 del modello OSI e ha una sorta di "caratteristiche" incorporate che precludono il requisito syn, syn-ack, ack quando ci si collega a 127.0.0.1. Pertanto TCP non segue le stesse regole quando è collegato a localhost. Ha detto che se potessi scrivere un programma di tipo "WireShark" per annusare il layer 4 e guardare la connessione stabilirti vedresti di cosa sta parlando.

Finora mi sono state date le seguenti possibili risposte all'utente John Siu.

1.) Per fare quello che mi stai chiedendo, l'unico metodo a cui riesco a pensare è scrivere un proxy rdp personalizzato ed eseguire sia su kgraves-pc che su duclaw.

2.) Mi è stato anche detto che potrebbe esserci una sorta di virus che posso usare che sostanzialmente prende in giro il proxy rdp di cui parlava John Siu. Nel mio laboratorio virtuale posso usare qualsiasi malware / virus che voglio usare per sfruttare questi sistemi. Quindi tutto è possibile.

Qualsiasi ulteriore aiuto sarebbe molto apprezzato! Grazie a tutti per i vostri contributi!

Spero che abbia senso, se non ... scusami per averti confuso!

EDIT # 1: Sono stato in grado di ricreare ciò che stavo vedendo inizialmente che mi ha fatto credere che questo tunnel inverso stava accadendo inizialmente. Dal wiresharktraffico (il traffico in alto proviene da Duclawe il traffico in basso proviene da kgraves) si può vedere che ciò che John ha spiegato in basso è esattamente ciò che sta accadendo. Ora che questo mistero è stato risolto, devo ancora capire come far richiamare RDP su una porta specifica anziché su una porta casuale.

Per fare quello che mi stai chiedendo, posso solo pensare al modo seguente

• C = Client (software client di rdp, telnet, ecc.)
• S = Server (software server di rdp, telnet, ecc.)
• Rosso e verde sono connessioni TCP / IP separate.

Custome Proxy 1

(Blue)  Listen to a local port to wait for client software connection
(Red)   Forward incoming packet from C to Custom Proxy 2 public port
(Green) Listen to a public port, forward incoming packet from Custom Proxy 2 to C (via Blue)

Custome Proxy 2

(Red)   Listen to public port for incoming packet from Custom Proxy 1
(Blue)  Establish connection with S, forward incoming packet from Custom Proxy 1 to S
(Green) Forward incoming packet from S to Custom Proxy 1 public port

PS: Focus su Telnet, RDP, che usa solo una connessione tcp. FTP è molto più difficile in quanto utilizza una connessione tcp aggiuntiva con una porta casuale per il trasferimento di dati (file).

Questo per rispondere a un "mistero" di un commento precedente

... MA su Kgraves-PC ho avuto traffico SSH proveniente direttamente da Duclaw il 10.0.10.120. Come vedrei il traffico da Duclaw su Kgraves-PC allora? ...

Racconti di tre tunnel

1. Red kgraves-pc: 3333 a devilsmilk: 6666

   kgraves-pc $ ssh -vg -L 3333:localhost:6666 misfitred@devilsmilk(10.0.10.121)
   

2. Green devilsmilk: 6666 to duclaw: 1337

   devilsmilk $ ssh -vg -L 6666:localhost:1337 kgraves@duclaw(10.0.10.120)
   

3. Blue kgraves-pc: da 3333 a (duclaw) per il diavolo: 6666

   duclaw     $ ssh -vg -R 3333:devilsmilk:6666 kgraves@kgraves(10.0.10.113)
   

kgraves-pc$ $ mstsc /v:localhost:3333 /f

Red Story Line

Se viene utilizzato il tunnel rosso, il pacchetto SSH (RDP) seguirà avanti e indietro nel modo seguente

kgraves-pc <--(Red)--> devilsmilk <--(Green)--> duclaw(RDP server end point)

Questo è ciò che viene mostrato nella schermata OP di WireShark.

Blue Story Line

Se viene utilizzato il tunnel blu, il pacchetto SSH (RDP) seguirà avanti e indietro nel modo seguente

kgraves-pc <--(Blue-ssh)--> duclaw(en-route) <--(Blue-non-ssh)--> devilsmilk <--(Green)--> duclaw(RDP server end point)

In questo caso, sembra che kgraves-pc e duclaw abbiano una connessione SSH-RDP diretta in WireShark, ma non.