Como estruturar o “gráfico de autenticação” de um grupo de servidores frontend / backend?

Question

Estou assumindo um monte de servidores como um novato sysadmin, que inclui um servidor web frontend e vários servidores back-end que contêm bancos de dados que incluem informações privadas dos usuários do serviço da web.

Para uma partida, desativei a autenticação de senha SSH. Eu estou querendo saber o que mais eu deveria cuidar, em termos de autenticação de login, para proteger os servidores com força razoável (primeira prioridade), e também para facilitar a tarefa de futuros problemas de administração (segunda prioridade).

Pergunta 1 : Recomenda-se configurar um servidor "passo a passo", como no diagrama (2) abaixo, que será o único servidor com a porta 22 aberta? Isso tornará os servidores backend mais seguros?

(1) em forma plana - sem degraus (configuração atual)

[dev machine] - pub key auth - [Frontend]*
 private key A                  public key A

[dev machine] - pub key auth - [Backend]*
 private key A                  public key A

(2) em forma de estrela - com trampolim

[dev machine] - pub key auth - [S- stone] -    ?    - [Frontend/Backend]*
 private key A                  public key A

Question 2: In case of this setup, which authentication method is recommended for internal login?
                         (a)   use another key pair: priv key B - pub key B
                         (b)   use ssh-agent
                         (c)   reuse key pair A: put priv key A to the s- stone
                         (c)   use password auth

Nota: "gráfico de autenticação" no título da pergunta é uma palavra inventada. Eu ficaria feliz em saber se há um termo para esse tipo de problema - qual servidor permitir login de para qual servidor.

    

Answer 1

Eu não acho que um host de bastiões seja um benefício líquido. Se você fizer o login da mesma maneira que você entra nos backends, não há nenhum benefício (se um invasor aparecer no bastião, ele está em todas as direções), e se você precisar fazer login no bastião de forma diferente, é um enorme comando administrativo. frustração e mais cedo ou mais tarde você vai trabalhar em torno dele para ser mais produtivo, e sua segurança acabou de sair pela janela.

Por outro lado, ter tudo pendurado na Internet para que alguém possa cutucar é um risco desnecessário. As soluções que implantei no passado incluem:

• Limitando os IPs de origem : Puro na teoria, até que seu ISP renumere sua conexão inicial ou precise urgentemente entrar em um servidor quando estiver em trânsito.
• Port knocking : Fofo em teoria, mas é mais útil para manter seus logs de autenticação limpos do que fornecer qualquer segurança real . Também é muito embaraçoso quando você esquece a seqüência de batidas de porta.
• VPN : Boa segurança, especialmente se você precisar usar protocolos não criptografados para os servidores backend de vez em quando (maldito você, IPMI), e pode fornecer uma autenticação boa e strong se você usar PKI (yay openvpn! ). O problema é que a configuração do seu cliente fica mais complicada.

Não há uma solução "melhor". Eu gosto de VPNs, mas YMMV.

    

Answer 2

Uma caixa de gateway ("passo a passo", "bastião host", etc.) é uma boa idéia, pois limita o perfil de ataque: Em vez de ter daemons SSH de muitos computadores expostos, você só tem um.

Dito isto, como womble apontou se você está usando as mesmas credenciais para entrar no "trampolim" e todos os servidores por trás dele você não está recebendo um ganho líquido em segurança - Uma chave / senha / etc . fica comprometida e eles podem chegar aonde quiserem.
Você deve implementar credenciais de autenticação discretas (chave separada para a caixa "passo a passo" versus as coisas por trás) no mínimo, e deve considerar as outras técnicas mencionadas (especificamente fonte IP limitando e / ou port-knocking) como camadas adicionais de segurança.

Observe que, se você adotar a abordagem VPN, você geralmente depende da VPN como provedor de segurança (substituindo o host "passo a passo").