Фон:
На моем сервере запущена служба, которая прослушивает сокет домена на /srv/socketпредмет входящих подключений, а затем взаимодействует с подключившимся пользователем. Обратите внимание, что эта служба написана мной (на C++), поэтому я могу довольно легко изменить ее поведение. Сейчас эта служба не выполняет проверку подлинности или разрешений (как вы увидите через секунду, это придется изменить). Нескольким разработчикам (кажется, от пяти до десяти), с которыми я работаю, нужен доступ к этой службе (и только к этой службе) с компьютеров где-то в Интернете. Поскольку эта служба дает им довольно много привилегий, я хочу, чтобы аутентификация была максимально надежной, а соединение было зашифровано. Основной вопрос, который у меня есть (чтобы избежать любой проблемы XY): как мне это настроить?
Идея и вопросы по ней:
Моя первоначальная идея состояла в том, чтобы предоставить собственную аутентификацию, а затем использовать TLS для шифрования (конечно, выставляя службу на внешний порт). Однако написание собственной аутентификации, скорее всего, приведет к уязвимостям безопасности, а настройка соединения для работы через TLS будет мучением.
Моя вторая идея была тогда просто использовать SSH. SSH уже имеет очень сильную аутентификацию и шифрование, и в основном делает то, что мне нужно. К сожалению, я не совсем уверен, как это настроить. Во-первых, я, конечно, не хочу давать разработчикам полный доступ к оболочке, поэтому я изменю их оболочку по умолчанию на /bin/false(согласно нескольким другим ответам на этом и связанных сайтах). Но тогда мне все равно нужно, чтобы они могли подключаться к соответствующему сокету. Я изучал туннелирование ssh, но, похоже, это не то, что мне нужно, и другие поиски по вещам, похожим на «ssh как прокси», все выявляют связанные, но не идентичные проблемы. Что здесь правильно сделать? Конечно, я мог бы написать собственный исполняемый файл, который будет действовать как «оболочка» и просто подключать этих пользователей к моей службе, но опять же, этот код будет чувствителен к безопасности, и по возможности я хотел бы избежать написания своего собственного.
Лучший сценарий:
В идеале я бы хотел, чтобы произошло следующее:
- Пользователь запускает некоторую команду на своем клиенте.
- Создается зашифрованное соединение с прокси-сервисом на моем сервере, и пользователь проходит аутентификацию на этом сервисе (в идеале это должен быть хорошо зарекомендовавший себя сервис, который известен своей достаточной безопасностью).
- Прокси-сервис открывает соединение с моим сервисом, пересылает имя пользователя (или какой-либо идентификатор пользователя) и подключает клиента.
Как лучше всего это сделать?
решение1
Я знаю, что прошло уже много времени с момента вашего вопроса, но если вам все еще интересно, взгляните на мойпочтана Server Fault. Хотя проблема там не связана с вашими требованиями, мое предложенное решение может быть напрямую связано. Я надеялся получить некоторые ответы на этот пост от экспертов, которые понимают последствия безопасности лучше меня, но этого не произошло.
Этот пост немного длинный, чтобы его здесь воспроизвести, но вкратце его концепция такова:
- настройте SSH так, чтобы он требовал столько механизмов аутентификации, сколько вам нужно/можно допустить, например, пароль + ключи + OTP и т. д.
- установить оболочку пользователя на
/sbin/nologin(/sbin/nologinпредпочтительнее, чем/bin/false) - используйте sshrc на сервере для вызова скрипта, когда пользователь подключается (аутентифицируется) через ssh, скрипт может делать все, что вам нужно, например, запускать вашу службу
В приведенной выше настройке ваши пользователи проходят аутентификацию через SSH, и после аутентификации /etc/ssh/sshrcвыполняет необходимые действия в отношении вашего сервиса, а затем /sbin/nologinкорректно отключает сеанс SSH после аутентификации, поскольку он больше не требуется.
Вы можете сойти с ума со скриптом в sshrc. Например, рассмотрите возможность начать без открытых портов для вашей службы. После аутентификации пользователя скрипт sshrc может открыть порт для IP пользователя в вашем брандмауэре на лету.
Пожалуйста, обрати внимание:вышеизложенное предполагает, что вы действительно, действительно знаете, что делаете в отношении конфигурации ssh. Хотя существует несколько хорошо протестированных реализаций SSH, многие из них могут быть легко неправильно настроены, что повлияет на безопасность. Кроме того, для аутентификации SSH я настоятельно рекомендую всегда использовать ключи + (по крайней мере, что-то одно, что знает пользователь, например, пароль или otp, в идеале и то, и другое).