Get best of the week

Assassino de VPN. Acesso remoto adequado a servidores de batalha

A opinião expressa neste artigo é a opinião pessoal do autor. Ele enfatiza que isso pode não coincidir com a opinião de seu empregador, superiores e do departamento de segurança.

Uma das coisas mais legais da nossa empresa em termos de infraestrutura é como implementamos o acesso remoto. Isso é apenas mágica superprotegida. Conversei com muitos de meus colegas guardas de segurança e auditores, e parece que inventamos acidentalmente uma história totalmente nova misturando soluções comerciais e nosso software. E assim, pensei, seria interessante aprofundar os detalhes técnicos de como o setor trabalha com soluções de acesso remoto desatualizadas e como as implementamos.

VPN de boa pessoa não aconselha


Vou começar com uma declaração forte: todas as VPNs são lixo .

A VPN, como outras tecnologias digitais, pode ser configurada para que, se for invadida, o mundo não acabe. No entanto, ninguém faz isso ... mas teoricamente eles podem!

Em 99,95% dos casos, a VPN está configurada para:

  1. Criando uma ponte de rede entre o dispositivo (laptop ou outro servidor)
  2. ... e uma rede maior de servidores (por exemplo, na nuvem ou no local )
  3. ... e a Internet, protegida por uma camada adicional de criptografia



Isso não é uma boa ideia. Imagine se um vírus se instalou no seu laptop e você está se conectando via VPN a uma rede de servidores de batalha? Ta Dam! O vírus agora tem acesso LAN à sua produção. O que há no escapamento? Tristeza. Muita tristeza.

Ok, digamos que o caso do vírus seja exagerado. Mas e o fato de um hacker poder se infiltrar na própria VPN, por exemplo, usando uma vulnerabilidade dentro do dispositivo ou software no qual a VPN trabalha? Então, tendo entrado direto na rede de destino? Este é um assunto sério e longe de ser teorizado. Você pode ler mais no artigo sobre como o Heartbleed foi usado para capturar VPN usando o vetor de ataque, sobre o qual eu avisei diretamente no meu blog .

Há pouco tempo, uma onda de vulnerabilidades de VPN varreu o mundo, que foram imediatamente usadas por criminosos cibernéticos para obter acesso às redes de destino. Mas isso não é surpreendente, certo? Esses sistemas "olham" diretamente para a rede, sem nenhum outro mecanismo de proteção à sua frente. As correções e patches geralmente não são aplicados automaticamente e envolvem mecanismos proprietários controlados por software proprietário em execução no SO proprietário. Bem, boa sorte lá.

É difícil encontrar esses dispositivos VPN? Antes de escrever este artigo, eu nunca tentei, então não tinha certeza. Cerca de meia hora no Shodan.io e por favor - alguns dos principais resultados da saída:

  • A Thomson Reuters é uma empresa de US $ 41 bilhões, com 26.000 funcionários, metade dos quais proveniente de serviços financeiros.
  • O SAP Concur é um serviço de gerenciamento de viagens, quebrá-lo daria um monte de dados pessoais e de pagamento de todos os tipos.
  • Seguro Progressivo - dados pessoais e informações médicas pessoais, juntamente com alguns dados de pagamento.
  • Chevron Phillips Chemical - o nome fala por si.

Bem, isso provavelmente não é muito bom. Se é fácil encontrar essas coisas, não parece a solução perfeita para colocá-las online. Temos outra escolha?

Zero confiança


Zero Trust [literalmente: “zero trust”] - em essência, significa que você autoriza cada conexão e não assume que alguns deles são confiáveis ​​porque já estão dentro da sua rede. Se você deseja entender melhor esse termo e repensar sua abordagem para os negócios, leia este artigo no Network World (desculpe-me por outra vergonha de auto-relações públicas).

Compramos a solução Okta Advanced Server Access (OASA) para introduzir a autorização Zero-Trust em servidores de batalha.
A OASA é legal por três razões:

1. Este é apenas um invólucro em torno da configuração do OpenSSH em esteróides


Sob o capô, a plataforma da OASA é uma implantação bem gerenciada do OpenSSH (o mesmo comando ssh no seu console). E o OpenSSH é uma solução de administração remota extremamente bem testada e segura. A propósito, desde 2003, o OpenSSH não possui uma única vulnerabilidade que pode levar ao acesso remoto não autorizado na configuração padrão.
Os pontos de entrada nesse esquema são instâncias regulares do Amazon Linux 2. EC2, portanto, a área de ataque é extremamente pequena. Lembre-se: um dos principais problemas com o uso de uma VPN são as configurações proprietárias de software / SO que impedem correções automáticas. A capacidade de atualizar nossos pontos de entrada na rede junto com o restante da infraestrutura é uma grande vitória.

2. Não há pontes de rede


Como mencionei acima, a maioria das VPNs é configurada para criar uma ponte de rede entre um dispositivo de rede, como um laptop e uma rede de servidores na Internet. Um dos meus pontos mais dolorosos nas VPNs é que elas interceptam todo o tráfego da sua rede. É claro que você pode reconfigurar para um comportamento diferente, mas nossos clientes e os protocolos de segurança NIST 800-53 SC-7 (7) geralmente exigem exatamente isso.

Este é um bom exemplo de como algumas medidas de segurança estão muito atrasadas no desenvolvimento da indústria. No mundo da velha escola, a VPN poderia ser a única camada para criptografar o tráfego. Às vezes, os auditores acreditam que, sem a proteção da VPN, você enviará seus dados através de canais não criptografados.

Felizmente, existe uma maneira melhor. No modelo da OASA, uma conexão é estabelecida individualmente entre você e o servidor. Por exemplo, em resposta à solicitação "Desejo efetuar logon na instância do EC2 i-028d62efa6f0b36b5", seu sistema se conecta ao ponto de entrada da rede e depois ao servidor de destino. A OASA também protege essas conexões emitindo certificados de cliente de dez minutos após a primeira verificação de seus dados através do SSO e, em seguida, verificando se você está no dispositivo confiável pretendido (e confirmado).

Há pouca liberdade para percorrer a rede. Um administrador pode inserir um ponto de entrada na rede e encaminhar portas para outro destino, mas esse recurso é desativado por padrão e deve ser explicitamente solicitado ao estabelecer uma conexão. E a melhor parte é que ninguém exige que eu carregue todo o tráfego através da nuvem privada virtual, porque isso não é chamado de "VPN".

3. Acesso à rede dedicado e IP aleatório


Esses pontos de entrada de rede são implantados separadamente para cada nuvem privada virtual (por exemplo, um para prod, um para teste, um para dev, etc.). Além disso, cada um deles é monitorado de perto por nossa solução de segurança, que registra todas as atividades e filtra o tráfego. Se o cracker estiver dentro de um dos pontos de entrada, algo também não funcionará. Em qualquer situação, nosso esquema de segurança não permite o acesso a recursos protegidos simplesmente porque você já está dentro da Virtual Private Cloud.

Um dos meus mecanismos de defesa favoritos apareceu por acidente. Quando começamos a configurar os pontos de entrada, cada um deles foi configurado para um endereço IP estático da AWS. Muito rapidamente, descobrimos que esses endereços IP às vezes não estavam vinculados às instâncias do EC2 no momento certo, o que poderia levar à autoconfiguração incorreta da OASA. Tendo experimentado as delícias de uma dúzia de correções diferentes na produção, eu não aguentava e simplesmente excluí toda a história sobre IPs estáticos - e funcionou.



A OEA precisa apenas de um IP voltado para a Internet e não precisa ser conhecido com antecedência. Quando o cliente está pronto para estabelecer uma conexão, é solicitado um GUID exclusivo, com a ajuda da qual o IP é determinado:

  • Usuário: Quero fazer login para conectar-me ao vpc-99f2acff
  • Aplicativo cliente OASA: defini vpc-99f2acff como um servidor conhecido com GUID 25af5d4f-e657-4583-b0bd-beb1ca4f0c1f
  • Servidor OASA: K 25af5d4f-e657-4583-b0bd-beb1ca4f0c1f pode ser acessado em 3.22.198.24, eis os certificados
  • Aplicativo cliente da OASA: Certificados instalados, conectando a 3.22.198.24 via SSH ...

Isso significa que cada instância de nossa infra-estrutura de ponto de entrada (uma publicação separada sobre isso à sua atenção) vem com um conjunto completamente novo de endereços IP. Assim, hackers aleatórios terão que procurar um IP entre dezenas de milhões, e seu número está crescendo todos os dias. Infelizmente para eles, esta pesquisa é completamente em vão, graças a ...

Porta corporativa batendo


Bater à porta [literalmente: bater nas portas] é algo que, em princípio, ninguém usa no mundo real, mas que é muito divertido de configurar. Em resumo, a batida na porta é uma sequência de "bumps" para várias portas de rede fechadas e, se a sequência for repetida corretamente, a porta "real" será aberta no seu IP. Elegante, mas impraticável em grandes projetos reais.
Fui inspirado pela ideia e pensei em como melhorá-la. Assim, nasceu a solução que chamo de Enterprise Port Knocking .

Eu queria criar um mecanismo que garantisse a proximidade de nossos pontos de entrada com a Internet, até que alguém pudesse acessá-los. Esse mecanismo deveria ser fácil de usar, confiável e autenticado de uma maneira existente.
Esbocei a arquitetura do mecanismo e fui com ela para a nossa incrivelmente talentosa equipe de engenheiros. Algumas semanas depois, começamos.

O serviço é bastante simples e é implantado como uma função do AWS Lambda, com acesso a ele através do AWS API Gateway (a alegria da arquitetura sem servidor!) Para uso fácil e confiável. O mecanismo funciona assim:

  1. O usuário é autenticado com sucesso através do SSO.
  2. O aplicativo ignora as contas configuradas da AWS em busca de um grupo de segurança especialmente marcado (conceito da AWS para regras de firewall)
  3. O aplicativo atualiza o grupo de segurança, permitindo o acesso ao endereço IP do solicitante. Uma regra no grupo de segurança também armazena o carimbo de data / hora de adição.
  4. A tarefa cron limpa a lista de IPs permitidos a cada período especificado.

Graças a essa situação, agora estamos apresentando uma solução de acesso remoto completamente fechada à Internet e requer autenticação de dois fatores por meio do banco de dados do usuário antes de abrir a porta no firewall .

E é fácil!


Ainda não toquei em como esses mecanismos são simples. Eu sei que existem muitos componentes, mas juntos eles criam uma autorização muito simples:

  1. Efetue login através do SSO.
  2. Clique no lançamento do Enterprise Port Knocking no portal SSO.
  3. No terminal, usando o comando SSH, especifique o destino como o ID da instância do EC2 de destino. O sistema da OASA é inteligente o suficiente para descobrir qual ponto de entrada usar e tudo o mais acontece automaticamente!



Todo esse sistema é uma grande vitória para nossa infraestrutura, para nosso cumprimento de todos os acordos de segurança e para a segurança de nossos clientes. Os usuários realmente gostam de como é fácil se conectar aos nossos servidores, porque você não precisa passar por autenticação adicional ou lembrar qual VPN usar. E eu realmente gosto do meu sono calmo. Todos ganharam com o novo modelo!

Bem, exceto os hackers, é claro.

More articles:


All Articles