SSH и PWNAT для SSH-соединения между двумя отдельными NAT

SSH и PWNAT для SSH-соединения между двумя отдельными NAT

Можно ли использоватьpwnatи SSH для установления «однорангового» SSH-соединения между двумя машинами, находящимися за двумя отдельными брандмауэрами/NAT?

Если это возможно, какие шаги необходимо предпринять для настройки этой функции на машине Linux внутри NAT, на которой запущен сервер OpenSSH, и как клиент, находящийся за отдельным NAT, сможет подключиться?

Также, если это возможно, представляет ли эта настройка серьезный риск безопасности? Может ли любой произвольный SSH-клиент подключиться к серверу, на котором запущен pwnat?

решение1

Да.Предположим, ваша сеть выглядит так:

Диаграмма сети

Вы хотите подключиться по SSH из A в B. У вас запущен sshd на B; он прослушивает tcp://127.0.0.1:22.

B$ pwnat -s 0.0.0.0 2022 127.0.0.1:22

pwnat на B теперь слушает udp://0.0.0.0:2022 и настроен на разрешение подключений к tcp://127.0.0.1:22. Он также отправляет периодические запросы ICMP echo на 3.3.3.3 (жестко закодированный IP).

A$ pwnat -c 127.0.0.1 3022 104.16.111.208 2022 127.0.0.1 22

pwnat на A теперь прослушивает tcp://127.0.0.1:3022.

pwnat на A отправляет пакет ICMP о превышении времени на 104.16.111.208, полезная нагрузка которого соответствует исходящим запросам ICMP echo, поступающим от NAT B. NAT B видит, что полезная нагрузка соответствует исходящим запросам ICMP echo, и пересылает пакет ICMP о превышении времени на B. Обратите внимание, что заголовок IP для пакета ICMP о превышении времени содержит IP-адрес NAT A, 151.101.193.69, в качестве адреса источника.

pwnat на B отправляет пакет UDP на udp://151.101.193.69:2022 с исходным портом 2022. NAT B добавляет запись в свою таблицу, чтобы в будущем он пересылал все пакеты UDP, которые он получает с udp://151.101.193.69:2022 по адресу udp://104.16.111.208:2022, на udp://192.168.2.10:2022.Обратите внимание, что многие NAT назначают другой порт на внешнем интерфейсе. Если это так,pwnat не работает.

pwnat на A отправляет UDP-пакет на udp://104.16.111.208:2022 с исходным портом 2022. NAT A добавляет запись в свою таблицу, чтобы в будущем он пересылал все UDP-пакеты, получаемые им с udp://104.16.111.208:2022 по адресу udp://151.101.193.69:2022, на udp://192.168.1.10:2022.

NAT A получает UDP-пакет, отправленный B, сопоставляет его в своей таблице и пересылает его A. NAT B получает UDP-пакет, отправленный A, сопоставляет его в своей таблице и пересылает его B. Теперь A и B могут свободно общаться по UDP.

A$ ssh -p 3022 127.0.0.1

pwnat на A, который прослушивает tcp://127.0.0.1:3022, принимает соединение от ssh. pwnat на A отправляет запрос pwnat на B (через UDP) на открытие туннеля к tcp://127.0.0.1:22. Поскольку это было указано как разрешенная пара хост/порт при запуске pwnat на B, он устанавливает соединение. Теперь туннель готов:

ssh on A --[tcp]--> pwnat on A --[udp]--> pwnat on B --[tcp]--> sshd on B

Если pwnat не имеет ошибок, то это ничем не отличается с точки зрения безопасности от раскрытия sshd миру на сервере, который не находится за NAT. Однако, если взглянуть на исходный код, pwnat кажется чем-то вроде хака, и я бы не стал полагаться на его безопасность. Худшим сценарием было бы выполнение произвольного кода на A и B как пользователя, который запускает pwnat.

решение2

Pwnat, похоже, не аутентифицирован, что я бы счел серьезным риском безопасности. Если вы контролируете хотя бы один из двух NAT/брандмауэров, просто настройте переадресацию/трансляцию портов для гораздо более безопасной настройки.

Связанный контент