Limitando o acesso a redes através do ssh jumpbox controlado centralmente

Question

Eu preciso restringir o acesso a muitas redes sobre as quais não tenho controle e planejo usar uma caixa de entrada para ser o único ponto de entrada em todos os ambientes. Um usuário faria login com suas credenciais de ldap, bem como sua chave ssh, e depois passaria daqui para um conjunto de hosts que eles têm permissão para acessar.

A questão central é a limitação em que um usuário pode acessar. Como esse é um recurso compartilhado no qual muitos membros de nossas equipes têm acesso, como limitar esse acesso. Eu pensei que poderia haver uma maneira com raio, mas eu não vi nenhum. Eu gostaria de tornar isso o mais fácil possível, ou seja,

ssh -t user@jumpbox ssh user@remote_host

Em que remote_host seria um sistema ao qual eles têm permissão de acesso.

Minhas ideias são as seguintes:

1. (com o uso intensivo de recursos), um jumpbox por usuário e gerenciar as rotas centralmente por meio do fantoche, a respeito do que elas podem acessar. Isso provavelmente seria o mais fácil de gerenciar, já que seria uma VM por usuário.

2. (mais doloroso para os usuários) Configure um script que é a única coisa que o usuário pode executar, o que lhes dá uma seleção. Isso seria uma dor, pois o usuário teria que selecionar uma lista potencialmente longa. Isso também poderia ser fácil de se locomover.

O que outras pessoas fizeram para resolver esse problema?

    

Answer 1

Eu faço isso com grupos e a regra iptables -m owner --gid-owner na corrente OUTPUT .

O tráfego que sai do jumpbox é controlado de acordo com vários grupos:

# timesheet people go to the timesheet rule
iptables -A OUTPUT -m owner --gid-owner 401 -j TIMESHEET
# debt mgmt people go to the debt rule
iptables -A OUTPUT -m owner --gid-owner 402 -j DEBT
# end to end testing people
iptables -A OUTPUT -m owner --gid-owner 403 -j E2E

Em seguida, cada uma dessas cadeias personalizadas implementará um conjunto (às vezes bastante complexo) de regras sobre quais sistemas as pessoas que correspondem a essa cadeia podem acessar. Um simples pode ser:

# people in the primary group timesheet can go to the timesheet app http://192.168.12.38:17001/
iptables -A TIMESHEET -p tcp --dport 17001 -d 192.168.12.38 -j ACCEPT
# but can't do anything else, with logging
iptables -A TIMESHEET -j LOG --log-prefix "TIMESHEET REJECT: "
iptables -A TIMESHEET -j REJECT

Uma vez que isso esteja configurado, permitir o acesso é apenas uma questão de colocar alguém no grupo principal 401 (para o quadro de horários), 402 (para o gerenciamento da dívida) e assim por diante. Se eu quisesse permitir alta complexidade, eu poderia usar --uid-owner e ter uma cadeia diferente para cada usuário, mas, em vez disso, mantenho minha vida um pouco mais simples com os grupos.

    

Answer 2

Se eu precisasse usar o SSH como minha camada de controle de acesso, eu determinaria o uso de chaves para acessar o host bastion, depois colocaria um force_command em cada chave para chamar um script com um identificador para o usuário por trás do chave. O script validaria as permissões de controle de acesso para o usuário identificado e acionaria uma sessão netcat para a máquina apropriada. O usuário usaria ProxyCommand localmente para fazer a proxy através do host de bastiões até a máquina de destino real e, portanto, o usuário poderia usar SSH através do túnel netcat para a máquina de interesse, de preferência novamente via chaves SSH.

    

Answer 3

Você pode configurar o sshd_config no destino para permitir a usuários específicos de hosts específicos com a seguinte diretiva.

AllowUsers username@foot

Portanto, em um servidor, você pode restringir o acesso a esse usuário a partir do servidor de salto. (Supondo que o endereço do seu servidor de salto seja 192.168.15.15.

AllowUsers [email protected] 

E restrinja o acesso a apenas outro usuário desse servidor de salto:

AllowUsers [email protected]

Você também pode usar a correspondência de padrões com esta diretiva (per man sshd_config). Observe que, dependendo do número de usuários que você possui na equipe, talvez seja necessário fazer uma administração significativa com o arquivo de configuração. Isso também afetará todos os scripts que você usa para efetuar login no servidor, pois os logins ficarão limitados ao que está nos AllowUsers após você adicioná-los.