-1

Я настраиваю свой сервер, который работает с NAT и брандмауэром. Чтобы получить доступ к SSH, я настроил reverse ssh tunneling к другому серверу с публичным IP.

Я немного боюсь, что это недостаточно безопасно, что это туннелирование активно 100% времени.

Есть ли способ заблокировать туннелирование на общедоступном сервере? Я хотел бы иметь возможность:

  1. Подключиться к общедоступному серверу SSH
  2. Включить туннельный порт
  3. Подключиться к туннельному порту (к моему серверу за NAT)
  4. Делай мою работу
  5. Отключить туннельный порт

Это возможно?

1 ответ1

0

Если ваш туннель прослушивает общедоступный интерфейс общедоступного сервера, вы можете заблокировать / разблокировать порт на общедоступном брандмауэре общедоступного сервера. Когда туннель не заблокирован, дополнительная безопасность от SSH отсутствует.


Если ваш туннель прослушивает общедоступный петлевой интерфейс сервера, вам не нужно выключать и снова включать; просто обезопасить публичный роутер. Если речь идет о безопасности, я бы порекомендовал это решение (почти, я объясню это ниже). Вы получите доступ к своему туннельному сервису либо

  • подключившись с самого публичного сервера

или же

  • через другой туннель SSH.

Команда (Linux) для установки такого туннеля от третьего хоста (например, вашего частного ноутбука):

ssh <user>@<public-server-IP> -L <portA>:127.0.0.1:<portB>

где <portB> - это порт, который прослушивает исходный туннель, <portA> - это порт по вашему выбору (сделайте его как минимум 1024 потому что нижние могут быть ограничены).

Затем подключитесь к 127.0.0.1:<portA> . Это соединение локально для вашего компьютера. На вашем общедоступном сервере также будет локальное соединение с 127.0.0.1:<portB> поэтому вся безопасность - это безопасность SSH, которая достаточно надежна, если вы правильно ее используете (хороший пароль / ключ и т.д.).

Единственный недостаток, о котором я могу подумать: другой пользователь, имеющий доступ (например, доступ по SSH) к вашему общедоступному серверу, может подключиться к 127.0.0.1<portB> на нем. Если это тоже проблема, вам следует изменить решение для туннелирования, как описано ниже.


Вместо создания туннеля, ведущего к вашей (потенциально небезопасной) службе, сначала создайте туннель к SSH-серверу NAT-ed.

На сервере NAT-ed вы пойдете так:

ssh <user>@<public-server-IP> -R <public-server-IP>:<portB>:127.0.0.1:<portSSH>

где <portSSH> - это порт, который прослушивает SSH-сервер на маршрутизаторе NAT-ed (обычно 22). (Конфигурация сервера SSH на общедоступном маршрутизаторе может помешать вам связываться с <public-server-IP> ; в Linux sshd это опция GatewayPorts , перенастройте при необходимости.) Таким образом, SSH-сервер NAT-ed будет доступен по <public-server-IP>:<portB> .

Затем создайте туннель от локального компьютера до сервера NAT-ed:

ssh <user1>@<public-server-IP> -p <portB> -L <portA>:127.0.0.1:<portS>

где <portS> - сервисный порт на сервере NAT-ed, и снова вы можете выбрать <portA> (снова не менее 1024). Обратите внимание, что теперь вы должны использовать свои учетные данные NAT-ed сервера.

Затем подключитесь к 127.0.0.1:<portA> чтобы получить доступ к услуге с локального компьютера.

Улучшение заключается в том, что на общедоступном маршрутизаторе нет открытого порта, ведущего непосредственно к вашему сервису на маршрутизаторе NAT-ed. Если вы заставите службу слушать только через интерфейс обратной связи маршрутизатора NAT-ed, она также будет недоступна из его локальной сети. Это делает решение очень безопасным (опять же: с хорошим паролем / ключом SSH и т.д.) И безопасным для использования даже с полностью открытой службой, которая не заботится о учетных данных.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .