Это относится к предыдущему вопросу, который становился слишком длинным и запутанным из-за моих постоянных обновлений и правок, и мне сказали, чтобы я его задал. Поэтому я убираю это и задаю более прямой вопрос.

Прежде всего, это теоретический эксперимент, который я должен сделать, чтобы узнать, как работают прямые и обратные ssh-туннели, и, в частности, чтобы иметь возможность полностью контролировать свое местонахождение в сети и скрывать свои шаги на протяжении всего процесса. Мой тренер дал мне эту задачу, но он верит, что я справлюсь сам, без его помощи.

Мне нужно найти способ заставить RDP(Удаленный рабочий стол) для ответа на определенный порт вместо RHP(случайный высокий порт). Я не спрашиваю как поменять какой порт RDP "Слушает" дальше, а скорее наоборот.

Я пытаюсь настроить экспериментальный вперед / назад SSH Туннель между двумя системами. Я использую третью систему в качестве точки разворота, чтобы скрыть свой IP в прямом туннеле. Но я хочу, чтобы система, в которую я удаленно работал через прямой SSH-туннель, отправляла ответ через отдельный обратный канал. SSH туннель к "указанному" порту вместо RHP. Основная идея заключается в том, что я хочу иметь возможность контролировать, какие порты я хочу прослушивать или получать, и я не хочу, чтобы что-либо было случайным.

Это мои три машины. Devilsmilk это точка опоры, клиент находится на kgraves и я удаленный в duclaw,

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

Поэтому я хочу иметь две трубы для моего RDP сессия. Один для форварда, а другой для реверса. Но я не хочу отправлять его обратно на RHP. Я не могу понять, как сказать, чтобы отправить его на определенный порт, скажем, :44444 например.

Кто-нибудь знает как это сделать?

Мне нужно, чтобы это было сделано определенным образом. Это порты, которые я должен использовать. Я уже настроил Duclaw слушать RDP в порту 1337 вместо 3389, Я знаю, что это ни в коем случае не самый простой способ сделать это.

Мне нужно подключение к удаленному рабочему столу, чтобы "появиться", как будто оно исходит от devilsmilk что уже происходит в соответствии с Wireshark. Но я хочу duclaw отправить ответ обратно kgraves не пройдя devilsmilk, Так чтобы kgraves RDP сеанс отправляется localhost который затем пересылается через ssh туннель через devilsmilk в duclaw, но RDP пакеты, которые принимаются в ответ на это соединение, принимаются непосредственно от Duclaw, В настоящее время ответ возвращается на RHP через devilsmilk

Мои команды следующие, и все они выполняются с одного и того же CYGWINssh консоль на kgraves кроме mstsc соединение, которое я сделал из другого CYGWIN терминал на kgraves Я добавил разрыв строки для переключателя:

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
$

Подключение удаленного рабочего стола к локальному узлу:3333 успешно установлено. И, как вы можете видеть, это выглядит так, как будто это исходит от devilsmilk на duclaw, Но согласно kgraves это возвращается из Devilsmilk,

Это снимок wireshark работает на Duclaw во время RDP сессия:

Это снимок wireshark работает на kgraves в течение RDP сессия:

Таким образом, моя проблема по-прежнему заключается в том, что я хочу, чтобы Duclaw отправил сеанс RDP обратно в Kgraves-pc через совершенно отдельный обратный туннель. Это то, что мне нужно, и я не могу понять, как это сделать.

Не только мне нужно duclaw отправить его обратно в отдельный туннель прямо к kgraves не пройдя devilsmilk, но мне также нужно контролировать, какой эфемерный порт он отправляет. Я хочу отправить его в порт :44444 вместо случайного эфемерного порта. Он использует :48809 случайно в многословной отладке ssh распечатать выше.

На ранних этапах пользователь Джон Сиу напомнил мне, что из-за особенностей связи по протоколу TCP это невозможно. Так как kgraves ожидает, что соединение будет установлено с localhost, поскольку оно было установлено с localhost. Так что должен быть способ duclaw отправить сеанс kgraves но переадресовать его так, как будто оно исходит от localhost может быть?

Но мой тренер сказал мне, что из-за природы RFC для 127.0.0.1 (Localhost) трехстороннее рукопожатие TCP никогда не покидает уровень 4 модели OSI, и в него встроены какие-то "функции", которые препятствуют syn, syn-ack, ack требование при подключении к 127.0.0.1. Поэтому TCP не совсем следует тем же правилам при подключении к localhost. Он сказал, что если бы вы могли написать программу типа "wireshark", чтобы понюхать на уровне 4 и посмотреть, как установится соединение, вы увидите, о чем он говорит.

До сих пор мне были предоставлены следующие возможные ответы пользователю Джон Сиу.

1.) Чтобы сделать то, что вы просите, единственный способ, который я могу придумать, - это написать собственный прокси-сервер rdp и работать как на kgraves-pc, так и на duclaw.

2.) Мне также сказали, что может быть какой-то вирус, который я могу использовать, который в основном высмеивает прокси-сервер rdp, о котором говорил Джон Сиу. В моей виртуальной лаборатории я могу использовать любые вредоносные программы / вирусы, которые я хочу использовать для эксплуатации этих систем. Так что все возможно.

Любая дальнейшая помощь будет наиболее ценной! Спасибо всем за ваш вклад!

Надеюсь, это имеет смысл, если нет... извините, что сбил вас с толку!

РЕДАКТИРОВАТЬ #1: я был в состоянии воссоздать то, что я видел первоначально, что заставило меня поверить, что этот обратный туннель происходил изначально. Вы можете увидеть из wireshark трафик (трафик сверху от Duclaw и трафик на дне от kgraves) то, что Джон объяснил ниже, это именно то, что происходит. Теперь, когда эта загадка раскрыта, мне все еще нужно выяснить, как получить RDP для обратного вызова на определенный порт вместо случайного порта.