Назад | Перейти на главную страницу

обратный туннель ssh через stunnel (или просто откат назад вниз stunnel-соединение)

Я создаю "Dropbox" безопасности, который можно развернуть за nat или любым брандмауэром, вызывать контролируемый общедоступный сервер и затем инициировать управление с сервера.

Я знаю, что это легко сделать с помощью команды ssh -R, однако я ищу что-то, что эффективно обходит IDS / IPS через правильный SSL / TLS и порт 443.

В настоящее время моя работающая установка (только SSL) имеет мой dropbox (назовем его клиентом), вызывающий и инициирующий stunnel-соединение с сервером. Затем я могу вручную передать ssh с клиента на сервер.

Это хорошо и здорово, однако мне нужно иметь возможность передавать ssh с сервера на клиент через установленный stunnel.

Вопросы:

  1. Могу ли я просто использовать ssh напрямую с сервера через существующее соединение stunnel (stunnel, инициированный клиентом). Это может потребовать изменения конфигурации stunnel, я просто немного не понимаю, что мне следует изменить.
  2. Могу ли я обратить SSH-туннель от клиента через stunnel к серверу, чтобы у сервера был локальный порт для ssh обратно к клиенту? Если это так, мне не удалось заставить команду ssh -R работать должным образом, так как я думаю, что в конечном итоге создаю цикл.

Ниже приведены мои конфиги stunnel:

Сервер:

cert=/path/to/cert.pem
pid=/tmp/stunnel.pid
[ssh]
accept = 443
connect = 127.0.0.1:22

Клиент: 

cert=/path/to/cert.pem
pid=/tmp/stunnel.pid
client=yes
[ssh]
accept=2200
connect=<serverpubip>:443

Пример команды SSH для попытки и обратного перехода от клиента к серверу через соединение stunnel:

ssh -i /path/to/cert -R 2200:localhost:2200 -p 2200 admin@localhost -f -N

Помните, что требования состоят в том, что только клиент может вызывать сервер для инициации начального соединения (stunnel), а трафик должен проходить через правильно сформированное шифрование SSL / TLS. Мне также нужно получить доступ к оболочке от сервера к клиенту. Заранее спасибо!

Обновить:

В итоге получилась плохая команда ssh. У меня сработала команда ssh:

ssh -i /path/to/cert -R 2201:localhost:22 -p 2200 admin@localhost -f -N

Почему бы не установить постоянный измеритель reverse_http (s) в "Dropbox"? Я думаю, что это самый простой способ получить обратную оболочку через http (s).

Ваша цель с помощью ваших реальных инструментов не может быть достигнута, потому что

  1. stunnel не может выполнить эту функцию обратного подключения,
  2. ssh не будет работать как демон, и протокол немного отличается от https. Достаточное количество умных IDS сможет это обнаружить.

Что вам нужно было сделать:

  1. Как предложил @NilsToedtmann, вам следует использовать какие-нибудь хитрые штуки, по крайней мере, OpenVPN. Клиентская сторона openvpn должна работать внутри. Следите за настройками тайм-аута / поддержки активности! Вы должны были сделать как можно меньше накладных расходов.
  2. Трафик OpenVPN опасно отличается от обычного https, но есть инструмент под названием obfsproxy с этим вы можете встроить трафик OpenVPN в более удобный поток данных. Этот инструмент является частью проекта tor, но может использоваться и независимо (изначально он был разработан против большого китайского межсетевого экрана).
  3. Если на картинке изображен корпоративный брандмауэр, вы можете использовать cntlm чтобы это выглядело как ie8, и сделать его совместимым с корпоративными прокси-серверами с аутентификацией Kerberos.
  4. На стороне сервера есть инструмент, который может быть очень полезен, и его имя sslh. Это позволяет вам мультиплекс ваш openvpn / ssh через трафик https с обычным сервисом https.

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

Я думаю, что все, что нужно, это изменить -R 2200:localhost:2200 к -R 2200:localhost:22 в вашей команде ssh.

В его нынешнем виде вы подключаете порт 2200 на сервере обратно к порту 2200 на клиенте. И да, это создает цикл пересылки, поскольку client: 2200 туннелируется обратно на сервер.

Предполагая, что ssh на клиенте работает на порту 22, тогда -R 2200:localhost:22 подключит порт 2200 на сервере к ssh на клиенте.

Чтобы сделать это немного понятнее, я предлагаю выбрать другой номер порта для обратного туннеля с сервера: скажем, -R 2201:localhost:22. Таким образом, вы не используете порт 2200 на обоих хостах, что поможет избежать путаницы между двумя портами.