Quão seguro é o SSH ForceCommand em um host de salto?

Eu tenho a seguinte configuração na minha rede:

Internet <--> Bastion <--> Local Network

Eu tenho vários usuários e cada usuário é atribuído a uma máquina específica. Ou, em outras palavras: cada usuário deve ter apenas acesso a um desses servidores. Por exemplo: Usuário1 -> Máquina1, Usuário2 -> Máquina2 e assim por diante.

Esses usuários se conectam de fora da minha rede e eu considerei muitas opções de como encaminhar suas conexões através do meu host bastião para a minha rede.

Por fim, optei por Match Blocks e forcecommand.

Portanto, meu / etc / ssh / sshd_config no bastion fica assim:

Match User User1
        ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND

O Usuário1 se conecta ao host bastião, que estabelece automaticamente uma conexão com a Máquina1.

Tanto quanto eu entendi o ForceCommand, o Usuário1 não terá acesso real ao host do bastião, porque todas as suas operações serão tratadas primeiro pelo bloco de correspondências e, portanto, redirecionadas para a Máquina1. No entanto, isso é realmente verdade? Isso já é suficiente para ser uma configuração segura? O usuário está preso na Machine1 de qualquer maneira, então ele não terá muitas possibilidades lá.

A maneira como eu uso um host bastião está usando ProxyCommande o -Wsinalizador como neste exemplo:

ssh -o ProxyCommand='ssh -W %h:%p user@bastion' user@machine

Eu uso essa abordagem por razões de segurança. A comunicação entre o cliente e a máquina de destino é criptografada e autenticada de ponta a ponta, o que significa que permanece segura mesmo se o bastião estiver comprometido. Um host bastião comprometido não forneceria menos segurança do que o uso ssh de ponta a ponta sem um bastião.

Também elimina a necessidade de usar qualquer encaminhamento de agente. O cliente pode usar a autenticação baseada em chave primeiro para acessar o bastião e, em seguida, novamente para acessar o host de destino, sem que nenhum deles seja fornecido com uma conexão de agente que possa ser usada para abusar da chave privada presente no cliente.

Também limita o código do qual sou dependente do host bastião. Não preciso executar nenhum comando no bastião. -Wimplica o sinalizador no command, bem como um encaminhamento de porta única, esse encaminhamento de porta é tudo o que o host bastião precisa permitir.

Com essa abordagem em mente, minha recomendação seria bloquear o host do bastião o máximo possível, permitindo apenas o uso de comandos da estrutura acima.

O ~/.ssh/authorized_keysarquivo no bastião pode pertencer à raiz (como todos os diretórios no caminho da raiz do sistema de arquivos para ele), isso reduz o risco de modificação, mesmo que alguém consiga entrar como usuário não privilegiado no diretório host bastião.

Em authorized_keysprivilégios do cliente pode ser limitada usando as opções command, no-agent-forwarding, no-pty, no-user-rc, no-X11-forwarding, bem como a utilização permitopende redirecionamento de portas limite para permitir apenas o acesso à porta 22 no anfitrião que este usuário é permitido o acesso a.

Em princípio, essa abordagem seria segura, mesmo que vários usuários compartilhem o mesmo nome de usuário no bastião. Mas você obtém um pouco mais de separação usando nomes de usuário separados no bastião.

Você pode contornar facilmente o ForceCommand, pois ele entra em ação quando o shell é iniciado. Isso significa essencialmente que o arquivo shell rc é processado primeiro e depois o ForceCommand, se você permitir que ele chegue lá. Simples exec shno seu arquivo shell rc gerará outro shell e manterá o ForceCommand esperando até você sair desse shell.

Então linha de fundo; se o usuário puder, de alguma forma, editar seu shell rc (por exemplo, .bashrc) via ftp, sftp, scp ou de outra forma, o ForceCommand não é realmente algo em que confiar.

Eu imagino que isso seja bom na maior parte do tempo, mas o problema com a segurança é o que ninguém pensou nisso ainda. Não há garantias.

Por exemplo, por um longo tempo, ninguém pensou muito sobre como as funções poderiam ser criadas a partir de variáveis ​​de ambiente no bash, mas recentemente as pessoas perceberam que isso poderia ser subvertido, e um dos efeitos disso foi que o ForceCommand poderia ser contornado (em menos implementado no arquivo allowed_keys) se o shell dos usuários foi feito em uma festa. O Bash foi corrigido e, esperançosamente, sua versão está atualizada, mas coisas assim acontecem.

Não tenho certeza se definir o ForceCommand é efetivamente o mesmo que definir esses comandos nos arquivos allowed_keys. Eu não olhei tão de perto.

Torne a .bashrcpropriedade de, root:usergrpmas ainda assim, legível pelo sshd em execução enquanto o usuário efetua login. Defina perms / owner em $ HOME, impedindo a criação de novos arquivos pelo usuário. Dessa maneira, a raiz controla o conteúdo .bashrc, deixando que ele faça o que precisa, mas o próprio usuário não pode alterar essas configurações ou permissões em arquivos / diretórios que indiretamente lhes permitiriam alterar o conteúdo .bashrc.

Eu tenho outra ideia. Para cada usuário no servidor bastião, você pode definir seu shell no / etc / passwd como um script bash que simplesmente executa ssh user1 @ machine1, user2 @ machine2, etc. Dessa forma, você garantirá que eles não tenham nenhum valor válido. shell no próprio servidor e que eles simplesmente se conectem à máquina à qual deveriam estar se conectando.