2013-05-26 1 views
1

Я встроенный инженер (а не сетевой гуру), строя часть оборудования на базе Linux (портативный измерительный прибор), который обычно не подключен к Интернету, но нам нужно, чтобы оборудование «вызывало домой "для поддержки, включая обновления и устранение неполадок, таким образом, чтобы это не ущемляло ни безопасность продукта, ни сетевую безопасность клиента, ни нашу собственную корпоративную сеть.Как создать безопасную функцию «вызова домой» для инструмента?

Функция «звонок домой» будет полностью контролироваться пользователем, возможно, нажав физическую кнопку для ее активации после того, как оборудование будет подключено к любой сети, которую клиент хочет использовать. Для прототипов и демонстрационных систем эта сеть может находиться в чьем-либо доме или офисе или даже через телефонное соединение (оборудование будет содержать только проводной порт Ethernet, и клиенту необходимо будет предоставить проводную точку доступа, если требуется WiFi-доступ).

Выполнение подключения не требует настройки для каждого вызова в конце пользователя и в нашем ящике, поэтому я думаю, что мы можем потребовать от клиента предоставления DHCP, а не больше. Мы также можем потребовать от клиента сначала связаться с нами, прежде чем нажимать кнопку «позвонить домой», чтобы мы могли поддерживать наш интерфейс только тогда, когда это необходимо.

Когда блок «звонит домой», он просто подключается к системе компании, ничего не делая до тех пор, пока инженер (ну, я) напрямую не подключится к нему. Помимо существования соединения, мы не должны получать (или минимальную) информацию о сети, которую использует клиент. Поэтому я думаю о каком-то SSH-соединении, но это насколько я понял.

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

Но я понятия не имею, как сделать SSH-соединение (если это подходящий инструмент для этого) в качестве двух отдельных половин: удаленный блок «называет» где-то, предположительно, в одной из наших систем компании, тогда система уведомляет инженера (меня) о том, что инициирован «звонок домой», а затем ждет, когда инженер подключится, образуя вторую половину соединения.

Подключение не обязательно должно идентифицировать удалённую систему (марка, модель, серийный номер, версия и т. Д.): Я сделал бы это вручную после безопасного входа в систему.

При необходимости я могу создать новую систему на нашем конце (Linux, BSD, Windows, любой, физический или виртуальный), который может быть предназначен только для этой функции. В случае необходимости я могу получить хотя бы один статический порт, который был бы привязан к нашей корпоративной глобальной сети (но я бы предпочел избежать, если это возможно).

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

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

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

EDIT: Если бы это было уже не очевидно, предположите, что я идиот по сети, которому можно доверять только, чтобы следовать явному рецепту, и не намного больше. KISS применяется!

ответ

1

Отказ от ответственности: до тех пор, пока нет «реального» ответа, я просто предоставляю свои более или менее теоретические мысли с надеждой, что это помогает.

Не прочтя подробно, я нашел http://www.vdomck.org/2005/11/reversing-ssh-connection.html, чтобы изменить ssh-соединение. Если это легко сделать (это должно быть просто, просто ssh -R в основном, см. Также http://www.brandonhutchinson.com/ssh_tunnelling.html), это означает, что ваше удаленное устройство может подключиться к вашей сети (а «Пит» - ваш партнер у клиента). Проблема в том, что для запуска ssh-соединения без пользователя/пароля требуется секретный ключ аутентификации на этом устройстве (так что в дружественных руках).

Вы можете разместить немой ssh-сервер без личных данных и не иметь специального доступа и даже пароль, который вы могли бы установить только для этого единственного соединения (и сообщить своему партнеру «Пит» по телефону), пусть ваша фантазия немного поиграет чтобы получить статическую половину «ImGenious $%» и динамическую половину «1243», чтобы вы могли дать короткую легкую динамическую половину по телефону.

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

+0

Похоже, что устройство обратило бы SSH на порт на машине компании, тогда я бы SSH к тому же порту, чтобы установить соединение на моем конце. Никакой другой вид прокси не нужен? – BobC

+0

По этой причине я бы предложил использовать порт 80 (http) или 443 (https-port), потому что для его открытия используются IT-отделы. ;-) Вы просто ssh на localhost в этом порту, чтобы войти в уже установленное соединение. И создание пары ключей для каждого устройства немного скучно, но действительно хорошее решение. Вы включаете этот ssh-ключ сразу после телефонного звонка, вы можете даже автоматизировать его на машине с очень простым perl или bash-scripting, таким как «phone_accept m3311», чтобы активировать ssh-ключ для m3311. – flaschenpost

+0

Что-нибудь вроде «Key Generation and Management для чайников»? В идеале я бы хотел, чтобы на каждом блоке были ключи и ключи для каждого разработчика, чтобы любой разработчик мог подключиться к любому устройству, но не нужно создавать все возможные комбинации ключей для всех разработчиков и всех устройств. Это возможно? – BobC

1

Я бы предложил, чтобы функция домашнего вызова использовала SSH для подключения к вашему офису. Это требует, чтобы сеть вашего клиента предоставляла DHCP, доступ в Интернет и возможности DNS. Он также требует, чтобы они разрешали исходящие соединения на порту 22. Последнее, возможно, является проблемой для некоторых клиентов, ориентированных на безопасность, которые хотят предотвратить неизвестный выход данных.

Вам понадобится сертификат для вашего SSH-сервера, чтобы сертификат был действителен для выбранного вами имени домена. Вам также необходимо убедиться, что клиент SSH на сервере настроен на прием подписи вашего сервера.

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

Если устройство скомпрометировано или украдено, вы можете удалить соответствующий ключ с вашего сервера. Устройство не сможет снова войти в систему. Частный ключ на устройстве имеет значение только потому, что вы решили принять связанный открытый ключ при входе в систему. Удалите это, и оно не имеет значения. Дополнительным преимуществом является то, что вы можете идентифицировать устройство по ключу, который он использовал для входа (например, вы можете связать каждый ключ с другим пользователем). Затем вы можете связать логин с информацией об устройстве/клиенте, который вы храните в своих системах.

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

+0

Да, я искал создание ключей для каждой единицы на основе соли с серийным номером, но не зашел слишком далеко. Спасибо за указатель на обратный SSH! – BobC