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

Question

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 acesso apenas a um desses servidores. Por exemplo: User1 - > Machine1, User2 - > Machine2 e assim por diante.

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

Por fim, optei por blocos de correspondência e por favor.

Então, meu / etc / ssh / sshd_config no bastião se parece com isso:

Match User User1
        ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND

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

Tanto quanto eu entendi ForceCommand, User1 não terá qualquer acesso real ao host bastion, porque todas as suas operações serão tratadas pelo bloco de correspondência primeiro, portanto, reencaminhadas para Machine1. No entanto isso é realmente verdade? Isso já é suficiente para ser uma configuração segura? O usuário é preso em Machine1 de qualquer maneira, então ele não terá muitas possibilidades lá.

    

Answer 1

A maneira como eu uso um host de bastiões está usando ProxyCommand e o sinal -W como neste exemplo:

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

Eu uso essa abordagem por motivos 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 protegida mesmo se o bastião estiver comprometido. Um host de bastiões comprometido não forneceria menos segurança do que usar o ssh de ponta a ponta sem um bastião.

Ele 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 tenha 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 eu dependo no host bastion. Eu não preciso executar nenhum comando no bastião. -W implica o sinalizador sem comando, bem como um único encaminhamento de porta, este encaminhamento de porta é tudo que o host de bastiões precisa permitir.

Com essa abordagem em mente, minha recomendação seria bloquear o host de bastiões o máximo possível, permitindo que apenas os comandos da estrutura acima fossem usados.

O arquivo ~/.ssh/authorized_keys no bastião pode ser de propriedade de root (assim como todos os diretórios no caminho da raiz do sistema de arquivos para ele), isso reduz o risco de ser modificado mesmo se alguém conseguir quebrar como usuário sem privilégios no host bastion.

Em authorized_keys , os privilégios do cliente podem ser limitados usando as opções command , no-agent-forwarding , no-pty , no-user-rc , no-X11-forwarding , além de usar permitopen para limitar os reenvios de porta apenas permitir acesso à porta 22 no host ao qual esse usuário tem permissão de acesso.

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.

    

Answer 2

Você pode contornar o ForceCommand facilmente desde que ele entra em ação quando o shell é iniciado. Isso significa essencialmente que o seu arquivo shell rc é processado primeiro e depois o ForceCommand se você permitir que ele chegue lá. O simples exec sh no seu arquivo shell rc gerará outro shell e manterá o ForceCommand aguardando até você sair desse shell.

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

    

Answer 3

Eu imagino que está tudo bem na maior parte do tempo, mas o problema com a segurança são as coisas que ninguém imaginou ainda. Não há garantias.

Como 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 poderiam ser subvertidas, e um dos efeitos disso foi que o ForceCommand poderia ser obtido em torno de (pelo menos como implementado no arquivo authorized_keys) se o shell dos usuários era bash. Bash foi corrigido, e esperamos que sua versão esteja atualizada, mas coisas assim acontecem.

Não tenho certeza se a definição do ForceCommand é efetivamente o mesmo que definir esses comandos nos arquivos authorized_keys. Eu não olhei tão de perto.

    

Answer 4

Torne o .bashrc possuído por root:usergrp , mas ainda legível pelo sshd executado como o usuário efetuando login. Defina perms / owner em $ HOME, impedindo a criação de novos arquivos pelo usuário. Desta forma, root controla o conteúdo de .bashrc , permitindo 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 permitiriam que eles alterassem o conteúdo de .bashrc .

    

Answer 5

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