Defina rigorosamente o seu problema

Question

Se me permitem, tomarei a liberdade de decompor sua pergunta, dando um passo atrás e ajudando a percorrer todo o processo de design da solução para que possamos determinar uma solução viável para você. Há uma série de imprecisões em sua pergunta sobre o protocolo SSH, VPNs e, em geral, como projetamos sistemas seguros. Vamos trabalhar com eles aqui.

Atualmente, sua pergunta pede orientação para a implementação de tecnologias específicas. No entanto, a declaração do seu problema não avalia a ameaça específica que você está enfrentando, por isso é prematuro projetar uma solução; nesse aspecto você temXY com problemanós.

Qualquer implementação que você fizer não resolverá o problema (porque na verdade o problema está em outro lugar) ou adicionará complexidade onde uma solução mais simples for adequada. Além disso, a complexidade desnecessária é indesejável, pois pode ser uma fonte de vulnerabilidades de segurança adicionais.

Defina rigorosamente o seu problema

Nos deveríamos serobjetivo focado,não focado na solução. Devemos definir os objetos do nosso domínio de problema, verificar quaisquer fatores contribuintes a serem considerados, compreender as ameaças que enfrentamos e só então poderemos começar a determinar quais escolhas tecnológicas e de processos podem ser feitas para resolver o problema em questão. Um processo que podemos seguir:

Identifique o problema– qual é a dificuldade específica que procuramos resolver? A dificuldade deve ser um problema objectivo e mensurável, apoiado por provas concretas da sua existência a partir de observações feitas no terreno.
Determinar suposições e restrições– existem itens específicos que podemos assumir como estando num determinado estado, e existem outras condições impostas à solução proposta? Uma restrição significativa deve incluir custos diretos de implementação da solução (compra de hardware, software ou tempo de consultoria) e custos indiretos (realização de mudanças no processo, treinamento de pessoal, acomodação da perda de produtividade).
Identifique os atores da ameaça(para problemas de segurança) –nenhum sistema ou processo é 100% seguro. Precisamos determinar cuidadosamente a natureza de todos os adversários que provavelmente lançarão um ataque, a fim de determinar se a nossa solução evita adequadamente tais ataques. Isto se aplica tanto ao projeto de sistemas de segurança física do mundo real quanto ao projeto para resultados técnicos.

Por exemplo, na sua avaliação, você pode considerar fatores como:
- Capacidades do seu adversário– qual o seu nível de conhecimento, se têm acesso a recursos específicos para ajudar num ataque, etc.
- A posição deles– há uma diferença substancial entre um script kiddie na última milha de um serviço residencial de Internet e um ator estatal com acesso a posições na rede a partir das quais ataques man-in-the-middle são viáveis
- Seutermostato de risco e risco– o que motiva o ator a atacar você ou sua organização especificamente? Por exemplo, o seu sistema armazena ou processa dados sensíveis e/ou privilegiados que normalmente são de natureza restrita e podem ser valiosos para terceiros (dados pessoais, segredos empresariais, etc.)? Tem uma posição privilegiada numa rede a partir da qual podem ser lançados mais análises ou ataques (por exemplo, um router central num ISP, um gateway fronteiriço no perímetro de uma rede sensível numa grande empresa)?
  
  Isso ajuda a identificar se estamos lidando com um ator de Ameaça Persistente Avançada (APT) que busca atingirvocêespecificamente, ou se estamos defendendo oportunistas. É muito mais fácil defender-se contra um oportunista passageiro tendo proteções modestas que fazem você parecer seguro em relação à concorrência.
  
  Além disso, identificar o seu apetite pelo risco (o seutermostato de risco) contribui para otimizar o resultado para cobrir adequadamente os riscos identificados sem ser exagerado.
Decisão de implementação– utilizando a informação recolhida neste processo, tendo em conta os constrangimentos descritos e a nossa posição sobre o risco, identificar a tecnologia adequadae processomudanças para solucionar o problema,ou revisar as restrições ou o perfil de risco se nenhuma solução puder ser identificada.

Durante todo o processo, lembramossegurança é um processo, não um destino. Não podemos “comprar” títulos como uma mercadoria pronta para uso, e qualquer pessoa que sugira isso está mentindo ou tem segundas intenções (provavelmente enriquecimento pecuniário).

Seu problema específico

Sua pergunta é incrivelmente abrangente, então podemos seguir nosso processo delineado com seus problemas específicos:

O problema

Eu experimentei um comprometimento do servidor com base na análise do rkhunter e quero mitigar a possibilidade de isso acontecer novamente.

O problema específico é um comprometimento passado da máquina, do qual você deseja minimizar quaisquer recorrências.

O objetivo principal que posso identificar na sua pergunta é proteger a máquina contra eventos de comprometimento remoto que podem ocorrer em uma rede pública (como a Internet). Um objetivo secundário é garantir a confidencialidade e a integridade das sessões remotas do shell na máquina remota.

Pressupostos e Restrições

Vamos documentar estes pontos para orientar nossa solução:

Os serviços de sites públicos expostos pela máquina são seguros
As estações de trabalho a partir das quais você inicia conexões remotas não são proxies para atacar a máquina servidora em questão. Por exemplo, eles próprios não são infiltrados (portanto, não são um vetor para vazamento ou modificação de chaves, ou para que os binários usados para fazer conexões sejam adulterados). Você pode explorar os pontos fracos de segurança de qualquer máquina cliente separadamente ou agrupá-los em uma única avaliação.
A máquina servidora é fisicamente segura e a adulteração da configuração de hardware ou software por uma pessoa que atende fisicamente a máquina é improvável ou descartada. (É improvável que uma máquina à qual um invasor tenha acesso físico seja mais a sua máquina.)
A rede é considerada comprometida. Pode haver atores que tenham a capacidade de interceptar ou desviar nossos pacotes.
Queremos usar software disponível gratuitamente para atingir os aspectos técnicos de nossa solução.
Assumimos que os usuários são adequadamente treinados para que os ataques ao wetware (operadores humanos) possam ser descontados (por exemplo, ameaças de engenharia social). Novamente, em princípio, estes raramente são mitigados de forma adequada e são um ponto fraco para a maioria das organizações, mas isso é uma falha do servidor, portanto, além de uma menção passageira, desconsiderarei os aspectos não técnicos do modelo de ataque.
É aceitável se a solução exigir distribuição offline ou verificação de chaves antes da primeira conexão.
Supõe-se que primitivas criptográficas conhecidas sejam imunes a ataques backdoor ou não divulgados publicamente.

Modelo de ameaça

Não consigo determinar adequadamente o seu modelo de ameaça, pois não tenho visibilidade sobre a sua organização e infraestrutura, nem possuo uma visão geral do portfólio de dados que você processa ou das redes privadas às quais você pode estar conectado internamente. Pelas informações públicas em seu perfil, vejo que você pode trabalhar em um local que processa propriedade intelectual confidencial em nome de terceiros, o que constituiria uma coleta de dados de médio a alto risco para ameaças de ataque específicas. (Essa ameaça pode se estender aos sistemas pessoais que você opera.)

Implementação

Vamos projetar uma solução que atenda aos nossos objetivos. Para fortalecer a máquina, precisamos considerar rotas de ataque públicas. Ele expõe dois serviços e presumimos que o serviço web não é vulnerável. Portanto, devemos considerar a conexão shell remota.

Para este propósito,SSH é mais do que capazde atender aos seus requisitos sem o invólucro adicional de uma sessão VPN. Quase qualquer máquina Unix é capaz de executar um daemon SSH, e um número significativo é exposto direta ou indiretamente a redes hostis sem infiltração.

Como o SSH se adapta aos nossos objetivos?

Secure Shell (SSH) foi projetado para fornecer confidencialidade e integridade de sessões remotas de shell. Isso é feito usando abordagens criptográficas; em particular, os hosts recebem uma ou mais chaves de host que podem ser usadas para identificar positivamente o host para conectar máquinas clientes.

Ataques man-in-the-middle em SSH

Como você identificou corretamente, o SSH é suscetível a um ataque man-in-the-middle em um cenário específico: a maioria dos usuários não inspeciona as chaves do host apresentadas pela máquina na conexão inicial; eles implantam umconfiança no primeiro usopolítica. Se um MitM puder fornecer chaves de host alternativas neste ponto, a interceptação da sessão SSH agora e em conexões futuras sem detecção adicional será viável. A detecção sem inspecionar a chave do host em cache exigiria a neutralização da ameaça MitM ou a conexão de uma rede não comprometida para que a verdadeira chave do host remoto pudesse ser apresentada.

Como estamos preocupados com o MitM, devemos conceber uma solução para mitigar esta situação. As opções disponíveis para você incluem (não exaustivas):

Conectando-se apenas em redes confiáveis. Isto não é viável, pois não atende aos nossos objetivos ou suposições sobre conexões em redes públicas.
Distribuição da impressão digital da chave do host (ou de toda a sua chave pública) antes da conexão inicial. Use o ssh-keygencomando no servidor para obter a impressão digital, distribua-a aos usuários e faça-os comparar a impressão digital apresentada na primeira conexão com a versão no servidor. Eles só devem fazer login se a impressão digital corresponder.
Publique as chaves do host no DNS e assine a zona usando DNSSEC. Certifique-se de que todos os clientes conectados usem um resolvedor de validação de DNSSEC e verifiquem as chaves de host baseadas em DNS.Mais informações aqui. Esta abordagem evita o fardo de distribuição e verificação manual da chave do host, mas requer a presença de componentes técnicos específicos que ainda não estão difundidos em muitas redes.

Ataques de senha de força bruta

Outra vulnerabilidade de um daemon SSH em execução são os ataques de força bruta de senha. É comum que os invasores investiguem sua caixa em busca de serviços SSH e tentem a autenticação usando uma lista comum de nomes de usuário e senhas. Caixas com nomes de usuário na lista pública e senhas fracas provavelmente serão comprometidas. Os métodos para mitigar isso incluem:

Alternar o daemon SSH para usar autenticação baseada em chave e desabilitar a autenticação por senha da Internet pública. Gere um par de chaves RSA para sua conta de usuário usando ssh-keygenum grande número de bits (por exemplo, >2048) ou um número apropriado de bits para um par de chaves assinado com outro sistema criptográfico.
Usar software como fail2banmonitorar seus registros e adicionar regras de firewall para bloquear novas tentativas de conexão do mesmo endereço após um limite de login com falha ser atingido.

Uma VPN ajudaria?

As soluções VPN podem resolver o mesmo problema que você procura resolver com o túnel SSH. Eles podem usar uma abordagem técnica diferente ou sistemas criptográficos diferentes, mas ambos são adequados para cumprir suas obrigações de segurança. Ambos também incorrem em despesas semelhantes (por exemplo, a obrigação de pré-distribuir ou verificar as chaves com cada parte antecipadamente é idêntica).

A funcionalidade adicional fornecida por uma VPN parece desnecessária neste caso específico, se tudo o que você deseja operar é um servidor shell remoto. A execução de uma VPN provavelmente acarreta riscos adicionais por seroutrodaemon rodando em sua máquina e um vetor de ataque maior.

Answer 1

Se me permitem, tomarei a liberdade de decompor sua pergunta, dando um passo atrás e ajudando a percorrer todo o processo de design da solução para que possamos determinar uma solução viável para você. Há uma série de imprecisões em sua pergunta sobre o protocolo SSH, VPNs e, em geral, como projetamos sistemas seguros. Vamos trabalhar com eles aqui.

Atualmente, sua pergunta pede orientação para a implementação de tecnologias específicas. No entanto, a declaração do seu problema não avalia a ameaça específica que você está enfrentando, por isso é prematuro projetar uma solução; nesse aspecto você temXY com problemanós.

Qualquer implementação que você fizer não resolverá o problema (porque na verdade o problema está em outro lugar) ou adicionará complexidade onde uma solução mais simples for adequada. Além disso, a complexidade desnecessária é indesejável, pois pode ser uma fonte de vulnerabilidades de segurança adicionais.

Defina rigorosamente o seu problema

Nos deveríamos serobjetivo focado,não focado na solução. Devemos definir os objetos do nosso domínio de problema, verificar quaisquer fatores contribuintes a serem considerados, compreender as ameaças que enfrentamos e só então poderemos começar a determinar quais escolhas tecnológicas e de processos podem ser feitas para resolver o problema em questão. Um processo que podemos seguir:

Identifique o problema– qual é a dificuldade específica que procuramos resolver? A dificuldade deve ser um problema objectivo e mensurável, apoiado por provas concretas da sua existência a partir de observações feitas no terreno.
Determinar suposições e restrições– existem itens específicos que podemos assumir como estando num determinado estado, e existem outras condições impostas à solução proposta? Uma restrição significativa deve incluir custos diretos de implementação da solução (compra de hardware, software ou tempo de consultoria) e custos indiretos (realização de mudanças no processo, treinamento de pessoal, acomodação da perda de produtividade).
Identifique os atores da ameaça(para problemas de segurança) –nenhum sistema ou processo é 100% seguro. Precisamos determinar cuidadosamente a natureza de todos os adversários que provavelmente lançarão um ataque, a fim de determinar se a nossa solução evita adequadamente tais ataques. Isto se aplica tanto ao projeto de sistemas de segurança física do mundo real quanto ao projeto para resultados técnicos.

Por exemplo, na sua avaliação, você pode considerar fatores como:
- Capacidades do seu adversário– qual o seu nível de conhecimento, se têm acesso a recursos específicos para ajudar num ataque, etc.
- A posição deles– há uma diferença substancial entre um script kiddie na última milha de um serviço residencial de Internet e um ator estatal com acesso a posições na rede a partir das quais ataques man-in-the-middle são viáveis
- Seutermostato de risco e risco– o que motiva o ator a atacar você ou sua organização especificamente? Por exemplo, o seu sistema armazena ou processa dados sensíveis e/ou privilegiados que normalmente são de natureza restrita e podem ser valiosos para terceiros (dados pessoais, segredos empresariais, etc.)? Tem uma posição privilegiada numa rede a partir da qual podem ser lançados mais análises ou ataques (por exemplo, um router central num ISP, um gateway fronteiriço no perímetro de uma rede sensível numa grande empresa)?
  
  Isso ajuda a identificar se estamos lidando com um ator de Ameaça Persistente Avançada (APT) que busca atingirvocêespecificamente, ou se estamos defendendo oportunistas. É muito mais fácil defender-se contra um oportunista passageiro tendo proteções modestas que fazem você parecer seguro em relação à concorrência.
  
  Além disso, identificar o seu apetite pelo risco (o seutermostato de risco) contribui para otimizar o resultado para cobrir adequadamente os riscos identificados sem ser exagerado.
Decisão de implementação– utilizando a informação recolhida neste processo, tendo em conta os constrangimentos descritos e a nossa posição sobre o risco, identificar a tecnologia adequadae processomudanças para solucionar o problema,ou revisar as restrições ou o perfil de risco se nenhuma solução puder ser identificada.

Durante todo o processo, lembramossegurança é um processo, não um destino. Não podemos “comprar” títulos como uma mercadoria pronta para uso, e qualquer pessoa que sugira isso está mentindo ou tem segundas intenções (provavelmente enriquecimento pecuniário).

Seu problema específico

Sua pergunta é incrivelmente abrangente, então podemos seguir nosso processo delineado com seus problemas específicos:

O problema

Eu experimentei um comprometimento do servidor com base na análise do rkhunter e quero mitigar a possibilidade de isso acontecer novamente.

O problema específico é um comprometimento passado da máquina, do qual você deseja minimizar quaisquer recorrências.

O objetivo principal que posso identificar na sua pergunta é proteger a máquina contra eventos de comprometimento remoto que podem ocorrer em uma rede pública (como a Internet). Um objetivo secundário é garantir a confidencialidade e a integridade das sessões remotas do shell na máquina remota.

Pressupostos e Restrições

Vamos documentar estes pontos para orientar nossa solução:

Os serviços de sites públicos expostos pela máquina são seguros
As estações de trabalho a partir das quais você inicia conexões remotas não são proxies para atacar a máquina servidora em questão. Por exemplo, eles próprios não são infiltrados (portanto, não são um vetor para vazamento ou modificação de chaves, ou para que os binários usados para fazer conexões sejam adulterados). Você pode explorar os pontos fracos de segurança de qualquer máquina cliente separadamente ou agrupá-los em uma única avaliação.
A máquina servidora é fisicamente segura e a adulteração da configuração de hardware ou software por uma pessoa que atende fisicamente a máquina é improvável ou descartada. (É improvável que uma máquina à qual um invasor tenha acesso físico seja mais a sua máquina.)
A rede é considerada comprometida. Pode haver atores que tenham a capacidade de interceptar ou desviar nossos pacotes.
Queremos usar software disponível gratuitamente para atingir os aspectos técnicos de nossa solução.
Assumimos que os usuários são adequadamente treinados para que os ataques ao wetware (operadores humanos) possam ser descontados (por exemplo, ameaças de engenharia social). Novamente, em princípio, estes raramente são mitigados de forma adequada e são um ponto fraco para a maioria das organizações, mas isso é uma falha do servidor, portanto, além de uma menção passageira, desconsiderarei os aspectos não técnicos do modelo de ataque.
É aceitável se a solução exigir distribuição offline ou verificação de chaves antes da primeira conexão.
Supõe-se que primitivas criptográficas conhecidas sejam imunes a ataques backdoor ou não divulgados publicamente.

Modelo de ameaça

Não consigo determinar adequadamente o seu modelo de ameaça, pois não tenho visibilidade sobre a sua organização e infraestrutura, nem possuo uma visão geral do portfólio de dados que você processa ou das redes privadas às quais você pode estar conectado internamente. Pelas informações públicas em seu perfil, vejo que você pode trabalhar em um local que processa propriedade intelectual confidencial em nome de terceiros, o que constituiria uma coleta de dados de médio a alto risco para ameaças de ataque específicas. (Essa ameaça pode se estender aos sistemas pessoais que você opera.)

Implementação

Vamos projetar uma solução que atenda aos nossos objetivos. Para fortalecer a máquina, precisamos considerar rotas de ataque públicas. Ele expõe dois serviços e presumimos que o serviço web não é vulnerável. Portanto, devemos considerar a conexão shell remota.

Para este propósito,SSH é mais do que capazde atender aos seus requisitos sem o invólucro adicional de uma sessão VPN. Quase qualquer máquina Unix é capaz de executar um daemon SSH, e um número significativo é exposto direta ou indiretamente a redes hostis sem infiltração.

Como o SSH se adapta aos nossos objetivos?

Secure Shell (SSH) foi projetado para fornecer confidencialidade e integridade de sessões remotas de shell. Isso é feito usando abordagens criptográficas; em particular, os hosts recebem uma ou mais chaves de host que podem ser usadas para identificar positivamente o host para conectar máquinas clientes.

Ataques man-in-the-middle em SSH

Como você identificou corretamente, o SSH é suscetível a um ataque man-in-the-middle em um cenário específico: a maioria dos usuários não inspeciona as chaves do host apresentadas pela máquina na conexão inicial; eles implantam umconfiança no primeiro usopolítica. Se um MitM puder fornecer chaves de host alternativas neste ponto, a interceptação da sessão SSH agora e em conexões futuras sem detecção adicional será viável. A detecção sem inspecionar a chave do host em cache exigiria a neutralização da ameaça MitM ou a conexão de uma rede não comprometida para que a verdadeira chave do host remoto pudesse ser apresentada.

Como estamos preocupados com o MitM, devemos conceber uma solução para mitigar esta situação. As opções disponíveis para você incluem (não exaustivas):

Conectando-se apenas em redes confiáveis. Isto não é viável, pois não atende aos nossos objetivos ou suposições sobre conexões em redes públicas.
Distribuição da impressão digital da chave do host (ou de toda a sua chave pública) antes da conexão inicial. Use o ssh-keygencomando no servidor para obter a impressão digital, distribua-a aos usuários e faça-os comparar a impressão digital apresentada na primeira conexão com a versão no servidor. Eles só devem fazer login se a impressão digital corresponder.
Publique as chaves do host no DNS e assine a zona usando DNSSEC. Certifique-se de que todos os clientes conectados usem um resolvedor de validação de DNSSEC e verifiquem as chaves de host baseadas em DNS.Mais informações aqui. Esta abordagem evita o fardo de distribuição e verificação manual da chave do host, mas requer a presença de componentes técnicos específicos que ainda não estão difundidos em muitas redes.

Ataques de senha de força bruta

Outra vulnerabilidade de um daemon SSH em execução são os ataques de força bruta de senha. É comum que os invasores investiguem sua caixa em busca de serviços SSH e tentem a autenticação usando uma lista comum de nomes de usuário e senhas. Caixas com nomes de usuário na lista pública e senhas fracas provavelmente serão comprometidas. Os métodos para mitigar isso incluem:

Alternar o daemon SSH para usar autenticação baseada em chave e desabilitar a autenticação por senha da Internet pública. Gere um par de chaves RSA para sua conta de usuário usando ssh-keygenum grande número de bits (por exemplo, >2048) ou um número apropriado de bits para um par de chaves assinado com outro sistema criptográfico.
Usar software como fail2banmonitorar seus registros e adicionar regras de firewall para bloquear novas tentativas de conexão do mesmo endereço após um limite de login com falha ser atingido.

Uma VPN ajudaria?

As soluções VPN podem resolver o mesmo problema que você procura resolver com o túnel SSH. Eles podem usar uma abordagem técnica diferente ou sistemas criptográficos diferentes, mas ambos são adequados para cumprir suas obrigações de segurança. Ambos também incorrem em despesas semelhantes (por exemplo, a obrigação de pré-distribuir ou verificar as chaves com cada parte antecipadamente é idêntica).

A funcionalidade adicional fornecida por uma VPN parece desnecessária neste caso específico, se tudo o que você deseja operar é um servidor shell remoto. A execução de uma VPN provavelmente acarreta riscos adicionais por seroutrodaemon rodando em sua máquina e um vetor de ataque maior.

Defina rigorosamente o seu problema

Responder1

Defina rigorosamente o seu problema

Seu problema específico

O problema

Pressupostos e Restrições

Modelo de ameaça

Implementação

Como o SSH se adapta aos nossos objetivos?

Ataques man-in-the-middle em SSH

Ataques de senha de força bruta

Uma VPN ajudaria?

informação relacionada