Quais opções existem para proteger a transferência de dados em uma rede semi-privada?

Question

Para ser mais específico, planejo configurar um site de comércio eletrônico com carga balanceada. Os dois balanceadores de carga aceitarão as conexões https dos tubos e, assim como a natureza do ssl, precisarão verificar a conexão, descriptografá-la e encaminhar a solicitação criptografada pela ONU para os servidores de aplicativos.

Em uma rede privada segura, tudo estaria bem, mas quero executar essa configuração com máquinas virtuais (slicehost). Teoricamente, as máquinas devem estar em uma rede privada, no entanto, é possível que outra máquina (fatia) de pessoas possa de alguma forma bisbilhotar o tráfego dentro da rede. Eu preciso assumir que a rede não é segura.

Eu pensei em usar o ssh e alguém sugeriu que eu usasse uma VPN (que eu não configurei antes e realmente não sei muito). Se eu usar o ssh, eu precisaria estar monitorando continuamente a conexão e certificando-se de que ela está ativa.

Eu acho que gostaria de saber o que as outras pessoas fazem?

Quanto menos complicado, melhor (isto é, menos coisas que podem dar errado e precisam ser monitoradas)

Esta é uma configuração do Linux. Estou pensando em usar o pound para o balanceador de carga. Ainda precisa fazer alguns testes nesse lado das coisas. Já começou a ler no nginx também.

    

Answer 1

Isso soa como um trabalho para o IPSEC para mim.

O IPSEC é "cozido" nas distribuições modernas do Linux. É completamente transparente para a camada de aplicação e "apenas funciona". Eu seguiria esse caminho para comunicação intra-máquina que precisa permanecer privada.

Uma configuração IPSEC "host para host" com chaves pré-compartilhadas é bastante simples. No CentOS, por exemplo, já existe um método para configurar essas conexões de host para host como parte da funcionalidade normal de "scripts de rede" (veja link ).

Dependendo da distribuição do Linux que você está usando, pode ser muito fácil de configurar, ou você pode ter que fazer um pouco de trabalho. Você não precisará de nenhum script de inicialização / desligamento de VPNs, scripts de monitoramento de túneis, etc. - tudo funcionará na camada 3. Isso, para mim, soa como uma solução vencedora.

Editar:

Eu uso o OpenVPN com frequência e muito, então eu não estou "desmotivando" o OpenVPN aqui, mas como uma solução para o seu problema em particular, eu acho que é sub-ótimo pelas seguintes razões (na ordem do meu grau de preocupação) :

• Cria uma infraestrutura de rede paralela. Você precisará ter certeza de que a comunicação entre hosts usa os endereços IP de destino corretos, de modo que as comunicações percorram a VPN, em vez da rede IP pública. Isso pode ser particularmente divertido se você planeja usar nomes DNS, já que precisará fazer algo com seu DNS (criando nomes de host hostA-secure, hostB-secure, etc.) ou criando uma "view" de DNS que sempre retorna o nome DNS. Endereços IP "seguros" quando as consultas vêm dos hosts "seguros") para ter certeza de que você resolve nomes para os IPs VPN "seguros".

• O OpenVPN é ponto a ponto. Você precisará configurar uma malha de túneis OpenVPN ou rotear o tráfego do OpenVPN "hub and spoke" por meio de um único host. O IPSEC é totalmente peer-to-peer, e você pode facilmente configurar uma topologia de malha com IPSEC e codificação dinâmica. Com a codificação pré-compartilhada, é um pouco mais trabalhoso, mas você também pode configurar uma topologia de malha dessa maneira.

• O OpenVPN é um programa de área de usuário que precisa ser iniciado. Isso não é um grande negócio, mas o IPSEC vive no espaço do kernel e "simplesmente funciona" sem iniciar nenhum programa de usuário quando estiver configurado.

Não entendo por que as pessoas acham que o IPSEC é tão odiosamente difícil de configurar. O IPSEC com chaves pré-compartilhadas é tão fácil de configurar em distros modernas quanto o OpenVPN com chaves estáticas (se não mais - normalmente sua distro trata de iniciar / parar automaticamente). O IPSEC com codificação dinâmica, usando uma PKI, requer quase os mesmos passos da configuração do OpenVPN com a autenticação baseada em certificados.

A complexidade do OpenVPN criando uma topologia de rede paralela com um segundo conjunto de endereços IP seria o assassino para mim. Eu gostaria que meus hosts pudessem conversar usando os mesmos endereços IP com os quais eles recebem comunicação não segura, "automagicamente" criptografando as conexões entre si de forma transparente.

Editar 2:

Para o que o pôster descreveu, acho que o IPSEC soa como a melhor solução (pelas razões que descrevi acima). Se o pôster estava falando sobre a interoperação com outros sistemas operacionais, e não apenas procurando proteger a comunicação entre alguns hosts, eu recomendaria o OpenVPN especificamente.

Eu concordaria que interoperar as várias implementações IPSEC do Linux com qualquer outra coisa é difícil (assim como interoperar praticamente qualquer IPSEC com praticamente qualquer outra implementação IPSEC, na verdade). Consegui fazer com que os túneis Cisco PIX para OpenSWAN funcionassem e obtive algum sucesso com túneis com chave estática vindos de máquinas Windows. Eu nunca toquei nenhum equipamento da Juniper, então não posso falar com ele.

Eu usei o OpenSWAN (quando era FreeSWAN, na verdade) e eu concordaria que os documentos são difíceis. Como o RedHat "escolheu" as ferramentas KAME para gerenciar a pilha IPSEC do kernel Linux 2.6, parei de seguir o OpenSWAN. Nas poucas vezes em que precisei de IPSEC host-to-host nos últimos anos (no RHEL ou no CentOS - tudo com o qual realmente trabalho no mundo do Linux), as ferramentas KAME se saíram bem. Eu tenho usado a documentação "oficial" do RHEL e a documentação do site do projeto KAME com sucesso.

    

Answer 2

OpenVPN é uma alternativa muito boa e muito mais simples ao IPSEC. O OpenVPN é uma solução SSL VPN de código aberto com recursos completos que vive no espaço do usuário. Multi plataforma (windows, linux, osx ..) incluiu todas as principais distribuições Linux.

Exemplo de configuração:

Primeiro, geramos a chave estática (não tão segura, mas simples):

$ openvpn --genkey --secret static.key

(copie esta chave via scp para seus clientes / servidores)

Servidor de configuração (/etc/openvpn/server.conf)

dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key
keepalive 10 60
ping-timer-rem
persist-tun
persist-key

Cliente de configuração (/etc/openvpn/client.conf)

remote myserver.address.com
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret static.key
keepalive 10 60
ping-timer-rem
persist-tun
persist-key

Certifique-se de que a porta UDP 1194 esteja aberta no servidor.

Executar no cliente / servidor:

# server
openvpn --config /etc/openvpn/server.conf
# client
openvpn --config /etc/openvpn/client.conf

Para verificar se a VPN está em execução, você deve conseguir efetuar ping de 10.8.0.2 do servidor e 10.8.0.1 do cliente.

    

Answer 3

Para um simples túnel ssh de auto-monitoramento, eu uso autossh . No entanto, lembre-se de que, com um alto throughput, você provavelmente precisará gastar o tempo configurando uma VPN completa, pois o ssh não funciona tão bem com grandes volumes de tráfego.