У меня есть следующие настройки в моей сети:
Internet <--> Bastion <--> Local Network
У меня есть несколько пользователей, и каждый пользователь назначен на определенную машину. Или другими словами: каждый пользователь должен иметь доступ только к одному из этих серверов. Например: User1 -> Machine1, User2 -> Machine2 и так далее.
Эти пользователи будут подключаться из-за пределов моей сети, и я рассмотрел множество вариантов переадресации их подключений через мой бастионный хост в мою сеть.
В конце концов я выбрал Match Blocks и forcecommand.
Итак, мой / etc / ssh / sshd_config на бастионе выглядит так:
Match User User1
ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND
Пользователь1 подключается к бастионному хосту, который автоматически устанавливает соединение с Machine1.
Насколько я понял ForceCommand, User1 не будет иметь реального доступа к хосту бастиона, потому что все его операции будут сначала обрабатываться блоком соответствия, следовательно, перенаправляются на Machine1. Однако так ли это на самом деле? Этого уже достаточно, чтобы быть безопасной установкой? В любом случае пользователь находится в тюрьме на Machine1, поэтому у него там не будет много возможностей.
Ответы:
То, как я использую хост-бастион, использует
ProxyCommandи-Wфлаг, как в этом примере:Я использую этот подход по соображениям безопасности. Связь между клиентом и целевой машиной зашифрована и полностью аутентифицирована, что означает, что она остается защищенной, даже если бастион скомпрометирован. Скомпрометированный хост-бастион обеспечит не меньшую безопасность, чем использование сквозного ssh без бастиона.
Это также устраняет необходимость использования любого агента переадресации. Клиент может использовать аутентификацию на основе ключей сначала для доступа к бастиону, а затем снова для доступа к целевому хосту, при этом ни одному из них не предоставляется соединение агента, которое можно использовать для злоупотребления закрытым ключом, присутствующим на клиенте.
Это также ограничивает код, от которого я зависим на хосте бастиона. Мне вообще не нужно выполнять никаких команд на бастионе.
-Wподразумевает флаг no command, а также переадресацию одного порта, эта переадресация портов - это все, что должен разрешить хост-бастион.Учитывая этот подход, я рекомендую максимально блокировать хост-бастион, позволяя использовать только команды вышеуказанной структуры.
~/.ssh/authorized_keysФайл на бастионе может принадлежать корню (как мог все каталоги на пути от корня файловой системы к ней), это снижает риск он может быть изменен , даже если кто - то удалось вырваться в качестве непривилегированного пользователя на выполнении бастионный хозяин.В
authorized_keysпривилегии клиента может быть ограничена с помощью опцийcommand,no-agent-forwarding,no-pty,no-user-rc,no-X11-forwarding, а также использованияpermitopenдля ограничения портов экспедирования , чтобы разрешить доступ к порту 22 на хосте , что этот пользователь имеет доступ только.В принципе, этот подход будет безопасным, даже если несколько пользователей используют одно имя пользователя на бастионе. Но вы получаете немного больше разделения, используя отдельные имена пользователей на бастионе.
источник
sshкоманды выполняются на клиенте. И это именно то, что я делаю так, как я предлагаю. Подход, упомянутый в этом вопросе, будет работатьsshна бастионе, который открывает широкий спектр возможных векторов атаки.Вы можете легко обойти ForceCommand, поскольку он запускается при запуске оболочки. По сути это означает, что сначала обрабатывается rc-файл вашей оболочки, а затем ForceCommand, если вы позволите ему туда попасть. Простой
exec shв вашей оболочке rc-файл создаст другую оболочку и заставит ForceCommand ждать, пока вы не выйдете из этой оболочки.Итак, суть; если пользователь может каким-либо образом редактировать свою оболочку rc (скажем, .bashrc) через ftp, sftp, scp или каким-либо другим способом, то ForceCommand на самом деле не является чем-то, на что можно положиться.
источник
Я думаю, что в большинстве случаев это нормально, но проблема с безопасностью заключается в том, о чем еще никто не задумывался. Там нет никаких гарантий.
Как, например, долгое время никто не задумывался о том, как можно создавать функции из переменных окружения в bash, но недавно люди поняли, что это можно подорвать, и одним из последствий этого было то, что ForceCommand можно было обойти (в как минимум, реализовано в файле авторизованных ключах), если оболочка пользователя была bash. Bash исправлен, и, надеюсь, ваша версия обновлена, но такие вещи случаются.
Я не совсем уверен, является ли определение ForceCommand по сути тем же, что и определение этих команд в файлах Authorized_keys. Я не посмотрел так внимательно.
источник
Сделайте
.bashrcпринадлежащим,root:usergrpно все еще читаемым sshd, работающим при входе пользователя в систему. Установите perms / owner на $ HOME, чтобы запретить создание новых файлов пользователем. Таким образом, root управляет содержимым.bashrc, позволяя ему делать то, что ему нужно, но сам пользователь не может изменять эти настройки или разрешения для файлов / каталогов, которые косвенно позволяют им изменять содержимое.bashrc.источник
.bashrcкоманды, которые хотите запустить?У меня есть другая идея. Для каждого пользователя на бастионном сервере вы можете определить его оболочку в / etc / passwd как bash-скрипт, который просто запускает ssh user1 @ machine1, user2 @ machine2 и т. Д. Таким образом, вы убедитесь, что у них нет действительных оболочки на самом сервере и что они просто подключаются к машине, к которой они должны подключаться.
источник