Por que usar SSH e VPN em combinação?

Meu empregador exige que eu faça logon em uma VPN e só então posso fazer o SSH nos servidores. Mas, dada a segurança do SSH, há um excesso de VPN?

Qual é a utilidade de uma VPN em termos de segurança se eu já estiver usando SSH ?

O raciocínio por trás da sua configuração atual é provavelmente uma combinação dos três motivos a seguir.

A VPN é uma solução de segurança para fora da rede da sua empresa (veja o item 1 abaixo) . No entanto, o SSH pode ser uma segunda camada de segurança fora da rede da sua empresa ... mas seu principal objetivo é proteger o tráfego na rede da sua empresa (consulte o item 2 abaixo) . A VPN também é necessária se o dispositivo no qual você está tentando fazer o SSH estiver usando um endereço privado na rede da sua empresa (consulte o item 3 abaixo) .

1. A VPN cria o túnel para a rede da sua empresa pela qual você envia os dados. Portanto, ninguém vendo o tráfego entre você e a rede da sua empresa pode realmente ver o que você está enviando. Tudo o que eles vêem é o túnel. Isso evita que pessoas que estão fora da rede da empresa interceptem seu tráfego de uma maneira que seja útil.

2. O SSH é uma maneira criptografada de conexão com os dispositivos da sua rede (em oposição ao Telnet, que é um texto não criptografado). As empresas geralmente exigem conexões SSH, mesmo na rede da empresa, por questões de segurança. Se eu instalei um malware em um dispositivo de rede e você faz a telnet para esse dispositivo (mesmo se estiver passando por um túnel VPN - como o túnel VPN geralmente termina no perímetro da rede de uma empresa), posso ver seu nome de usuário e senha. Se é SSH que você está usando, não posso.

3. Se sua empresa estiver usando endereçamento privado para a rede interna, o dispositivo ao qual você está se conectando talvez não possa ser roteado pela Internet. A conexão por meio de um túnel VPN seria como se você estivesse conectado diretamente no escritório; portanto, você usaria o roteamento interno da rede da empresa que não seria acessível fora da rede da empresa.

O SSH é um alvo extremamente popular para tentativas de força bruta. Se você tiver um servidor SSH diretamente na Internet, em minutos, você verá tentativas de login com todos os tipos de nomes de usuário (e senhas) - geralmente milhares por dia, mesmo em pequenos servidores insignificantes.

Agora é possível proteger os servidores SSH (os três principais mecanismos estão exigindo uma chave SSH, negando acesso root ao SSH e, se possível, restringindo os endereços IP que podem se conectar). Ainda assim, a melhor maneira de proteger um servidor SSH é nem mesmo disponibilizá-lo na Internet.

Por que isso Importa? Afinal, o SSH é fundamentalmente seguro, certo? Bem, sim, mas é tão seguro quanto os usuários o fazem - e seu empregador pode estar preocupado com senhas fracas e roubo de chaves SSH.

A adição de uma VPN adiciona uma camada extra de defesa que é controlada no nível corporativo, em vez de no nível do servidor individual como o SSH.

Em suma, eu recomendaria seu empregador por implementar algumas boas práticas de segurança aqui. À custa da conveniência, é claro (a segurança geralmente vem à custa da conveniência).

A VPN permite que você se conecte à rede privada do seu empregador e adquira um endereço IP dessa rede privada. Uma vez conectado à VPN, é como se você estivesse usando um dos computadores dentro da empresa - mesmo se você estiver fisicamente localizado no outro lado do mundo.

Muito provavelmente, seu empregador exige que você se conecte via VPN primeiro porque os servidores não são acessíveis pela Internet (ou seja, eles não têm um endereço IP público), o que é uma boa idéia. A VPN adiciona outra camada de segurança, como se os servidores estivessem acessíveis ao público via SSH, eles estariam vulneráveis ​​a uma variedade de ataques.

SSH é um protocolo de criptografia usado para várias coisas. Criptografar o tráfego em um túnel VPN é um deles. Seu tráfego é criptografado usando SSH, mas precisa ser empacotado em pacotes IP válidos (túnel) para atravessar uma rede como a Internet. Este túnel é a VPN.

Basicamente, seu empregador bloqueia o tráfego fora da rede, por segurança, a menos que esse tráfego seja fornecido por uma VPN que o empregador controla. Uma VPN pode ou não criptografar o conteúdo do túnel. O uso do SSH criptografará o tráfego transportado no túnel da VPN.

Você precisa da VPN para entrar na rede local.

Você não precisa proteger sua conexão com servidores individuais, pois ela já será criptografada pelo link da VPN.

No entanto, de que outra forma você se conectaria a eles? SSH é o protocolo de acesso ao console de fato para servidores remotos; instalar e configurar um não seguro seria uma sobrecarga de gerenciamento adicional e diminuiria a segurança na rede local (o que pode ou não ser um problema).

Não se esqueça, nem todos, mesmo dentro da empresa, terão acesso total a todos os servidores, e a capacidade de usar criptografia baseada em chave, mesmo dentro da rede local, permite que o administrador da rede garanta com facilidade e segurança que apenas as pessoas que sabem ostensivamente o que desejam. estão fazendo, mesmo dentro da empresa, podem tocar no servidor.

Você também pode direcionar camadas de segurança adicionais através da VPN. Como verificações de critérios de dispositivo, autenticação de dois fatores, etc.

O raciocínio típico é que você deseja reduzir a exposição e os possíveis vetores de ataque o máximo possível.

Se você começar com a premissa de que o SSH e a VPN são necessários (para seus próprios propósitos), então os dois enfrentam externamente significa que os invasores têm duas rotas em potencial no seu ambiente. Se você criar SSH somente local, ele adicionará uma camada adicional à segurança do servidor. Considere os seguintes cenários:

1. SSH + VPN externamente. O atacante precisa apenas comprometer o SSH para comprometer o servidor.

2. SSH externo. Funcionalmente igual ao cenário anterior.

3. VPN externo (SSH interno). Dobra em segurança. O invasor deve romper os dois antes que eles possam fazer qualquer coisa com o servidor.

Considere isso juntamente com o fato de que a VPN não seria necessária para outras funções, e pode estar melhor configurada para acesso externo e é fácil.

Eu arriscaria que a resposta seja simplesmente que o NAT esteja envolvido e (como muitos outros declararam) expor o servidor de destino final ao mundo, convidando outro ponto de ataque. A menos que você esteja realizando transferências pesadas de dados em massa com chaves grandes, o SSH geralmente não atrapalha. O gargalo quase sempre será a rede. (Quase! = Sempre).

Se você tiver 'sorte' o suficiente de ter IPv6, isso provavelmente não será um problema, mas com o IPv4 e o espaço de endereço limitado disponível, o NAT é (IMO), em última análise, o que eu acho que está por trás dessa 'política' mais do que qualquer outro segurança 'acidental' ou 'proposital'.

Do meu entendimento atual, o SSH - porque ele simplesmente usa uma troca de chaves tcp para verificar se um usuário cliente tem as credenciais corretas para acessar o ID do usuário no servidor, é suscetível a ataques intermediários onde um ISP ou roteador comprometido poderia intercepte a solicitação de handshake e aja como a única que envia autenticação, na verdade sequestrando a conexão. Isso permite que os comandos sejam injetados no fluxo e a saída filtrada antes de atingir o cliente autêntico inicial, ocultando o homem na injeção intermediária de comandos arbitrários no shell ssh do servidor.

No entanto, por um túnel VPN, algo que o ssh não permite. Uma chave de criptografia simétrica pré-acordada adicional. Isso significa que o tráfego entre as duas máquinas não é suscetível a um homem no ataque intermediário, porque o tráfego, se interceptado e encaminhado em nome do cliente autêntico, a fim de controlar a camada de criptografia SSL, não seria capaz de passar a chave de criptografia VPN. requisitos porque o terceiro não teria a capacidade de falsificar as chaves vpn da mesma maneira que seria capaz de controlar um encaminhamento intermediário da conexão ssh tcp ssl.

Portanto, o ssh não é bom o suficiente para parar o homem no meio de um ISP ou roteador comprometido pelo qual um cliente precisa passar para se conectar ao servidor.