Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

This relates to a previous question that was getting entirely too long and confusing due to my constant updates and edits and I was told to re ask it. So I am cleaning it up and asking a more direct question.

First off this is a theoretical experimentation I am having to do in order to learn how forward and reverse ssh tunnels work and specifically to be able to maintain complete control of where I am on the network at all times and hide my footsteps throughout the process. My trainer has given me this task but he is trusting that I figure it out on my own with no help from him.

I need to figure out a way to force RDP(Remote Desktop) to respond to a specific port Instead of a RHP(Random High Port). I am not asking how to change what port RDP "Listens" on, but rather the opposite.

I am attempting to set up an experimental Forward/Reverse SSH Tunnel between two systems. I am using a third system as a Pivot point to hide my IP on the forward tunnel. But I want the system I am Remoting into through the Forward SSH Tunnel to send the response through a separate reverse SSH tunnel to a "Specified" port instead of a RHP. The basic idea is I want to be able to control what ports I want listening and or receiving, and I don't want anything to be random.

These are my three machines. Devilsmilk is the pivot point, the client is on kgraves and I am Remoting into duclaw.

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

So I want to have two pipes for my RDP session. One for the forward, and the other for the reverse. But I don't want to send it back on a RHP. I can't figure out how to tell it to send it to a specific port, say :44444 for example.

Does anyone know how to do this?

I need this done a specific way. These are the ports I Have to use. I have already set up Duclaw to listen for RDP on port 1337 instead of 3389. I know that this isn't by any means the easiest way to do any of this.

I need the remote desktop connection to "appear" as if it is coming from devilsmilk which is already happening according to wireshark. But I want duclaw to send the response directly back to kgraves without going through devilsmilk. So to kgraves the RDP session is being sent to the localhost which is then forwarded via ssh tunnel through devilsmilk to duclaw, but the RDP packets that are being received in response to that connection are received directly from Duclaw. Currently the response is coming back on a RHP through devilsmilk

My commands are as follows and all of them are performed from the exact same CYGWIN ssh console on kgraves except for the mstsc connection which I did from another CYGWIN terminal on kgraves I have added a line break for the 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
$

Remote Desktop Connection to localhost:3333 was successfully Established. And as you can see it looks as if it is coming from devilsmilk on duclaw. But according to kgraves it is coming back from Devilsmilk.

This is a snapshot of wireshark running on duclaw during the RDP session:

enter image description here

This is a snapshot of wireshark running on kgraves during the RDP session:

enter image description here

So my problem still remains that I want Duclaw to send the RDP session back to Kgraves-pc through a entirely separate reverse tunnel. That is what I need to happen and can't figure out how to do.

Not only do I need duclaw to send it back in a separate tunnel straight to kgraves without going through devilsmilk, but I also need to control what Ephemeral port it sends it to. I want it to send it to port :44444 instead of a random ephemeral port. It is using :48809 randomly in the verbose debug ssh print out above.

In early stages it was brought up to me by the user John Siu that due to the nature of TCP communication this is not possible. Because kgraves is expecting a connection to be made from localhost since it was established with localhost. So there has to be a way for duclaw to send the session to kgraves but have it forwarded to appear as if it is coming from localhost maybe?

But I was told by my trainer that because the nature of the RFC for 127.0.0.1 (Localhost) the TCP three-way handshake never leaves layer 4 of the OSI model and it has some sort of "features" built into it that preclude the syn, syn-ack, ack requirement when connecting to 127.0.0.1. Therefore TCP doesn't quite follow the same rules when connected to localhost. He said if you could write a "wireshark" type program to sniff at layer 4 and watch the connection establish you would see what he's talking about.

I have been given the following possible answers thus far credit to user John Siu.

1.) To do what you are asking, the only method I can think of is to write a custom rdp proxy and run on both kgraves-pc and duclaw.

2.) I was also told that there may be some sort of Virus that I can use that basically mocks the rdp proxy that John Siu was talking about. Within my Virtual lab I can use whatever malware/virus that I want to use to exploit these systems. So anything is possible.

Any further help would be most appreciated! Thanks all for your contributions!

Hopefully this makes sense, if not...sorry for confusing you!

EDIT #1: I was able to recreate what I was seeing initially that had me believing that this reverse tunnel was happening initially. You can see from the wireshark traffic (Traffic on top is from Duclaw and traffic on bottom is from kgraves) that what John explained down below is exactly what is happening. Now that this mystery is solved I still need to figure out how to get RDP to callback to a specific port instead of a Random port.

enter image description here

share|improve this question
    
I intend to solve the following mystery: ... BUT On Kgraves-PC I had SSH traffic coming straight from Duclaw at 10.0.10.130. How would I be seeing traffic from Duclaw on Kgraves-PC then? ... But it is not showing in your wireshark, are you still seeing that or the IP changed? –  John Siu Jan 31 '13 at 15:05
    
I am no longer seeing that. On kgraves I am seeing SSH traffic coming from devilsmilk. I could have sworn when I initially set it up that I was seeing it coming from duclaw but I am no longer seeing that right now. Not sure what I did differently. Or maybe I was imagining things. –  Kentgrav Jan 31 '13 at 15:08
1  
Actually there was a chance, maybe due to the order your ssh is issued. But it is still all within ssh tunnel. I will post an answer to that. Have to put it in drawing, so maybe 30min. –  John Siu Jan 31 '13 at 15:18
1  
What you're wanting to do is not going to be able to be done without some custom software to fit your specific need. And what your trainer told you about TCP on localhost is WRONG. Think about it: TCP has no knowledge whatsoever about IP addresses, that happens at layer 3, so how could it do something special based on an IP? Oh, and wireshark does exactly what you mention in the description of a "wireshark" type program to sniff at layer 4. –  heavyd Jan 31 '13 at 15:28
    
Awesome, I'll look into that heavyd. I'll also look into the whole TCP on localhost misunderstanding. I assure you this guy knows what he is talking about. So what probably happened is I misunderstood what he was trying to tell me and miss communicated it. I will get clarification. Thanks for your input. –  Kentgrav Jan 31 '13 at 16:16

2 Answers 2

up vote 1 down vote accepted

To do what you are asking, I can only think of the following way

enter image description here

  • C = Client (Client software of rdp, telnet, etc)
  • S = Server (Server software of rdp, telnet, etc)
  • Red and Green are separate TCP/IP connection.

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 on Telnet, RDP, which only use one tcp connection. FTP is much more difficult as it use additional tcp connection with a random port for data(file) transfer.

share|improve this answer
    
Thanks a lot man! I will test this out next week. Appreciate all your help. –  Kentgrav Feb 2 '13 at 1:03
    
FTP .. your trainer really like rabbit holes ... –  John Siu Feb 2 '13 at 4:38

This is to answer a "mystery" from a previous comment

... BUT On Kgraves-PC I had SSH traffic coming straight from Duclaw at 10.0.10.120. How would I be seeing traffic from Duclaw on Kgraves-PC then? ...

Tales of Three Tunnels

  1. Red kgraves-pc:3333 to 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:3333 to (duclaw) to devilsmilk:6666

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

Map Of 3 Tunnels

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

Red Story Line

If red tunnel is used, SSH(RDP) packet will follow back and forth in the following way

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

This is what being shown in OP wireshark screen shot.

Blue Story Line

If blue tunnel is used, SSH(RDP) packet will follow back and forth in the following way

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

In this case, it look like kgraves-pc and duclaw is having a direct SSH-RDP connection in wireshark, but not.

share|improve this answer
    
By the way thanks for this answer, I am verifying a few things with it now. Got busy all day. –  Kentgrav Jan 31 '13 at 21:45
    
That makes a lot of sense, and I was able to re-create it! Thanks for solving this mystery! So at this point I am back where I started on Monday, but I have learned a lot along the way lol. Now I still need to figure out how to get RDP to callback to a specified port. –  Kentgrav Jan 31 '13 at 21:56
1  
I am not sure ssh tunnel is a correct approach for your real needs. ssh tunnel function works as normal tcp/ip. I will throw in a additional answer later(a few hours) tonight with a concept drawing of what you properly looking for. But you will need to find the actual "program" capable of doing it. –  John Siu Jan 31 '13 at 22:06
    
My trainer basically told me he is leading me down a rabbit hole and although what I am trying to accomplish here IS possible. It's out of the scope of what he is trying to teach me at the moment which is sending data through one tunnel but receiving it through another tunnel or having the receiving end be another host entirely. So he has told me to do the same thing using FTP or Telnet instead of RDP so I'm gonna give that a shot and mark your answer as the correct answer for now as you did help clarify a lot of questions concerning this entire process. I appreciate it. –  Kentgrav Feb 1 '13 at 13:47
    
As I promised, additional answer with concept drawing :D –  John Siu Feb 1 '13 at 20:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.