Переадресация обратного порта ssh на мобильное устройство

У нас есть требование иметь доступ к ресурсам на мобильном устройстве. мобильное устройство должно действовать как сервер. он должен быть доступен независимо от того, как подключен телефон (wi-fi, 3g, за брандмауэром и т. д.). я понимаю, что это можно сделать, инициировав переадресацию обратного порта ssh с телефона на сервер, доступный в облаке. клиенты, желающие получить доступ к ресурсам на телефоне, теперь могут подключаться к облачному серверу через произвольный порт и туннелировать соединение с мобильным устройством. отлично.

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

вот некоторые из моих опасений,

  1. выделение портов. для каждого туннеля требуется уникальный порт на облачном сервере. Я считаю, что для этого потребуется, чтобы устройство и облачный сервер согласовали IP-адрес перед запуском туннеля. это, конечно, возможно, но это означает, что где-то есть довольно сложная служба, которая постоянно проверяет порты, чтобы определить их доступность.

  2. портовые ресурсы. на сервере конечное количество портов. может быть, это не проблема, когда все масштабируется на нескольких серверах.

  3. управление туннелем. туннели могут не всегда работать нормально, поэтому возникает проблема очистки туннелей, которые неожиданно выходят из строя (см. № 1).

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

Кроме того, простое открытие всех уникальных портов сервера является еще одним вектором атаки.

  1. масштабируемость. насколько дорого (с точки зрения ресурсов) иметь, возможно, тысячи открытых туннелей SSH? это реалистично?

  2. брандмауэр. порты облачного сервера будут не 80 или 8080, а какое-то случайное число. это проблема для некоторых брандмауэров, которые могут ограничивать исходящие подключения к стандартным портам?

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


person Jeffrey Blattman    schedule 15.02.2011    source источник


Ответы (1)


Здесь был бы уместен некоторый пользовательский код или сеанс туннелирования по протоколу, предназначенному для этой концепции. IPSEC через UDP может быть хорошей номинацией. Если это вообще возможно, если мобильное устройство слушает как обычный сервер и отправляет эхо-запросы всякий раз, когда оно меняет адреса, это может избавить вас от многих проблем. Это будет зависеть от поведения телефона и от того, делает ли оператор раздражающие вещи, такие как фильтрация входящих TCP-соединений. Во всяком случае, для решения конкретных вопросов:

1) Нет, для каждого соединения потребуется уникальный сокет. Это комбинация номера порта и IP-адреса. Даже если два телефона находятся за одним и тем же NAT, устройство NAT назначит соединениям разные порты. Вы можете запустить одну службу на одном порту вашего сервера.

2) См. выше

3) Это будет скорее правилом, чем исключением. Они истекают по тайм-ауту и ​​закрываются. На самом деле это может быть менее сложной задачей, чем вы ожидаете.

4) Способ решения этой проблемы будет зависеть от ваших потребностей в безопасности. Вы можете попытаться идентифицировать базовые идентификаторы на телефоне, чтобы усложнить задачу, потребовать ввода пароля пользователя, чтобы сделать его двухфакторным, и т. д. Это, конечно, конкурирует с простотой использования, поэтому компромисс остается за вами. .


1a) Понятия не имею... но это не должно быть невозможно.

2а) Вы столкнетесь с этим в некоторых местах, а где трудно предугадать. Тем не менее, вы также выполняете эти функции через HTTPS.

person Jeff Ferland    schedule 15.02.2011