Нужно выяснить способ для RDP перезванивать локальному слушателю через указанный эфемерный порт через обратный туннель SSH

1895
Kentgrav

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

Прежде всего, это теоретический эксперимент, который я должен сделать, чтобы узнать, как работают прямые и обратные 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сеанса:

enter image description here

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

enter image description here

Таким образом, моя проблема все еще остается в том, что я хочу, чтобы 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трафику (трафик сверху вверху, Duclawа снизу трафик снизу kgraves) видно, что Джон объяснил ниже именно то, что происходит. Теперь, когда эта загадка раскрыта, мне все еще нужно выяснить, как получить RDP для обратного вызова к определенному порту вместо случайного порта.

enter image description here

2
Я намереваюсь разгадать следующую загадку: `... НО На Kgraves-PC у меня был SSH-трафик, исходящий прямо из Duclaw в 10.0.10.130. Как бы я тогда увидел трафик от Duclaw на Kgraves-PC? ... `Но это не отображается в вашем Wireshark, вы все еще видите это или IP-адрес изменился? John Siu 11 лет назад 0
Я больше не вижу этого. На `kgraves` я вижу трафик SSH, идущий от` devilsmilk`. Я мог бы поклясться, когда я изначально настроил это, что я вижу, что это происходит из `duclaw`, но я больше не вижу этого прямо сейчас. Не уверен, что я сделал по-другому. Или, может быть, я воображал вещи. Kentgrav 11 лет назад 0
На самом деле был шанс, может быть, из-за заказа вашего SSH. Но это все еще внутри туннеля SSH. Я отправлю ответ на это. Нужно положить его на рисунке, так что, возможно, 30 минут. John Siu 11 лет назад 1
То, что вы хотите сделать, не сможет быть выполнено без какого-либо специального программного обеспечения, соответствующего вашим конкретным потребностям. И то, что ваш тренер сказал вам о TCP на localhost, НЕПРАВИЛЬНО. Подумайте об этом: TCP ничего не знает об IP-адресах, что происходит на уровне 3, так как он может сделать что-то особенное на основе IP? Да, и Wireshark делает именно то, что вы упоминаете в описании программы типа «Wireshark», чтобы понюхать на уровне 4. heavyd 11 лет назад 1
Круто, я посмотрю на это тяжело. Я также рассмотрю весь TCP на недопонимании localhost. Уверяю вас, этот парень знает, о чем говорит. Так что, вероятно, произошло то, что я неправильно понял, что он пытался сказать мне, и мисс сообщила об этом. Я получу разъяснения. Спасибо за ваш вклад. Kentgrav 11 лет назад 0
Опубликовать ответ за «загадку». John Siu 11 лет назад 0

2 ответа на вопрос

1
John Siu

Это ответить на «загадку» из предыдущего комментария

... НО на Kgraves-PC у меня был SSH трафик, идущий прямо из Duclaw в 10.0.10.120. Как бы я тогда увидел трафик от Duclaw на Kgraves-PC? ...

Рассказы о трех туннелях

  1. Красный Kgraves-PC: 3333 до дьявольского молока: 6666

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

  2. Зеленое дьявольское молоко: с 6666 по Дукло: 1337

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

  3. Синие кгрейвс-пк: 3333 до (герцог) в дьявольское молоко: 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

Красная история линия

Если используется красный туннель, пакет SSH (RDP) будет следовать туда-сюда следующим образом

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

Это то, что показано на снимке экрана OP Wireshark.

Blue Story Line

Если используется синий туннель, пакет SSH (RDP) будет следовать туда-сюда следующим образом

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

В этом случае, похоже, что kgraves-pc и duclaw имеют прямое соединение SSH-RDP в wireshark, но нет.

Кстати, спасибо за этот ответ, я проверяю несколько вещей с ним сейчас. Занят весь день. Kentgrav 11 лет назад 0
Это имеет большой смысл, и я смог воссоздать его! Спасибо за разгадку этой тайны! Так что в этот момент я вернулся туда, где я начал в понедельник, но я многому научился на этом пути, лол. Теперь мне все еще нужно выяснить, как получить RDP для обратного вызова на указанный порт. Kentgrav 11 лет назад 0
Я не уверен, что SSH туннель является правильным подходом для ваших реальных потребностей. Туннельная функция ssh работает как обычно tcp / ip. Позже вечером (через несколько часов) я добавлю дополнительный ответ с концептуальным рисунком того, что вы правильно искали. Но вам нужно будет найти реальную «программу», способную сделать это. John Siu 11 лет назад 1
Мой тренер в основном сказал мне, что он ведет меня по кроличьей норе, и хотя то, что я пытаюсь здесь сделать, возможно. Это выходит за рамки того, чему он пытается научить меня в данный момент: отправлять данные через один туннель, но получать их через другой туннель или иметь принимающую сторону целиком и полностью другим хостом. Поэтому он сказал мне, чтобы я делал то же самое, используя FTP или Telnet вместо RDP, так что я хочу дать вам шанс и пометить ваш ответ как правильный ответ, так как вы помогли прояснить множество вопросов, касающихся всего этого процесса. Я ценю его. Kentgrav 11 лет назад 0
Как я и обещал, дополнительный ответ с рисунком концепции: D John Siu 11 лет назад 0
1
John Siu

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.

Большое спасибо, человек! Я проверю это на следующей неделе. Ценю всю вашу помощь. Kentgrav 11 лет назад 0
FTP .. твой тренер очень любит кроличьи норы ... John Siu 11 лет назад 0

Похожие вопросы