Это относится к предыдущему вопросу, который становился слишком длинным и запутанным из-за моих постоянных обновлений и правок, и мне сказали, чтобы я его задал. Поэтому я убираю это и задаю более прямой вопрос.
Прежде всего, это теоретический эксперимент, который я должен сделать, чтобы узнать, как работают прямые и обратные 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
Мои команды следующие, и все они выполняются с той же самой консоли CYGWIN ssh на 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 и наблюдать за установлением соединения, вы бы поняли, о чем он говорит.
До сих пор мне были предоставлены следующие возможные ответы пользователю John Siu.
1.) Чтобы сделать то, что вы просите, единственный метод, который я могу придумать, - это написать собственный прокси-сервер rdp и работать как на kgraves-pc, так и на duclaw.
2.) Мне также сказали, что может быть какой-то вирус, который я могу использовать, который в основном высмеивает прокси-сервер rdp, о котором говорил Джон Сиу. В моей виртуальной лаборатории я могу использовать любое вредоносное ПО / вирус, которое я хочу использовать для эксплуатации этих систем. Так что все возможно.
Любая дальнейшая помощь будет наиболее ценной! Спасибо всем за ваш вклад!
Надеюсь, это имеет смысл, если нет ... извините, что сбил вас с толку!
РЕДАКТИРОВАТЬ # 1: я был в состоянии воссоздать то, что я видел первоначально, что заставило меня поверить, что этот обратный туннель происходил изначально. Вы можете видеть из wireshark трафика (Traffic на вершине от Duclaw и трафика на дне от kgraves что Джон объяснил вниз именно то , что происходит. Теперь, когда эта загадка раскрыта, мне все еще нужно выяснить, как получить RDP для обратного вызова к определенному порту вместо случайного порта.
