IPSec para tráfego de LAN: considerações básicas?

Question

Esta é uma continuação do meu Criptografando absolutamente tudo ... pergunta.

Importante : não se trata da configuração mais usual do IPSec, na qual você deseja criptografar o tráfego entre duas LANs.

Meu objetivo básico é criptografar todo o tráfego dentro da LAN de uma pequena empresa. Uma solução pode ser o IPSec. Acabei de começar a aprender sobre o IPSec, e antes de decidir usá-lo e mergulhar mais profundamente, gostaria de obter uma visão geral de como isso poderia ser.

• Existe um bom suporte multiplataforma? Ele deve funcionar em clientes Linux, MacOS X e Windows, servidores Linux e não deve exigir hardware de rede caro.

• Posso ativar o IPSec para uma máquina inteira (para que não haja outro tráfego de entrada / saída), ou para uma interface de rede, ou isso é determinado pelas configurações de firewall para portas individuais /...?

• Posso banir facilmente pacotes IP não-IPSec? E também o tráfego IPSec "malvado de Mallory" que é assinado pela chave alguns , mas não a nossa? Minha concepção ideal é tornar impossível ter qualquer tráfego IP na LAN.

• Para tráfego interno da LAN: eu escolheria "ESP com autenticação (sem AH)", AES-256, em "Modo de transporte". Esta é uma decisão razoável?

• Para o tráfego de LAN-Internet: como funcionaria com o gateway da Internet? Eu usaria

  • "Modo de túnel" para criar um túnel IPSec de cada máquina para o gateway? Ou eu também posso usar
  • "Modo de transporte" para o gateway? A razão pela qual eu pergunto é que o gateway teria que ser capaz de descriptografar os pacotes vindos da LAN, então será necessário que as chaves façam isso. Isso é possível, se o endereço de destino não for o endereço do gateway? Ou eu teria que usar um proxy neste caso?

• Há mais alguma coisa que eu deva considerar?

Eu realmente só preciso de uma rápida visão geral dessas coisas, e não de instruções muito detalhadas.

    

Answer 1

• Is there good cross-platform support? It must work on Linux, MacOS X and Windows clients, Linux servers, and it shouldn't require expensive network hardware.

Eu realmente não tenho muita experiência com isso, já que eu principalmente tenho sistemas Linux, mas eu consegui principalmente trabalhando em uma máquina Windows 2000 (isso foi há algum tempo atrás). Ele tinha um problema que o IPsec não conseguiu renegociar uma nova chave de sessão depois que algum número de bytes foi transferido (isso deveria acontecer automaticamente), então a conexão caiu depois de um tempo, e eu nunca pude me incomodar em cavar nela. mais distante. Provavelmente funciona muito melhor hoje em dia.

• Can I enable IPSec for an entire machine (so there can be no other traffic incoming/outgoing), or for a network interface, or is it determined by firewall settings for individual ports/...?

Como funciona (ou, melhor dizendo, como eu consegui fazê-lo funcionar), você define que uma máquina foo deve ser usada somente IPsec para máquinas bar , baz e yow . Qualquer tráfego de e para essas máquinas é agora seguro e tão confiável quanto essas máquinas. Qualquer outro tráfego não é IPsec e funciona normalmente.

• Can I easily ban non-IPSec IP packets? And also "Mallory's evil" IPSec traffic that is signed by some key, but not ours? My ideal conception is to make it impossible to have any such IP traffic on the LAN.

O tráfego IPsec só é permitido para as IPsec " políticas " que você define, portanto, qualquer máquina aleatória não pode enviar pacotes IPsec - deve existir uma política IPsec que corresponda a esses pacotes.

• For LAN-internal traffic: I would choose "ESP with authentication (no AH)", AES-256, in "Transport mode". Is this a reasonable decision?

Sim. Fala-se sobre abandonar o AH completamente porque é redundante - você pode usar ESP com criptografia NULL com o mesmo efeito.

• For LAN-Internet traffic: How would it work with the internet gateway? Would I use
  • "Tunnel mode" to create an IPSec tunnel from each machine to the gateway? Or could I also use

Eu escolheria essa opção. Como é, eu mesmo não controlo o gateway, e o tráfego será descriptografado fora da minha rede, portanto, não vejo uma necessidade urgente.

O tráfego da Internet para hosts que não usam IPsec deve ser visto como possivelmente interceptado - não há sentido em criptografar na LAN local quando o seu ISP ou o ISP do seu ISP pode ouvir os mesmos pacotes não criptografados.

• "Transport mode" to the gateway? The reason I ask is, that the gateway would have to be able to decrypt packages coming from the LAN, so it will need the keys to do that. Is that possible, if the destination address isn't the gateway's address? Or would I have to use a proxy in this case?

Pelo que entendi, isso não funciona - você precisaria de um proxy.

• Is there anything else I should consider?

Veja se você pode usar algo sensato, como chaves OpenPGP, em vez de certificados X.509. Eu uso o X.509, já que era a única coisa suportada pelo daemon de IPsec que eu usei pela primeira vez, e não tive a energia necessária para refazer tudo isso. Mas eu devo, e eu vou, algum dia.

P.S. Eu e um associado realizamos uma palestra sobre IPsec em 2007, pode ser útil esclarecer alguns conceitos .

    

Answer 2

Isso parece um pouco exagerado. Eu não posso dizer que eu já ouvi falar de alguém criptografando todo o tráfego em sua LAN. Qual é a sua motivação para fazer isso?

    

Answer 3

O IPSec é ótimo para se conectar a redes não confiáveis (por exemplo, Web DMZs, etc) e dentro de redes que são separadas por firewalls. Os aplicativos que usam protocolos RPC (ou seja, Microsoft AD, etc) gostam de usar intervalos de porta efêmeros altos, que não funcionam com os firewalls. Dentro da LAN, seus benefícios dependem de vários fatores.

Não é uma bala de prata, e não necessariamente simplificará a segurança da rede. Ele ajudará você a operar serviços na Internet ou em outras redes não confiáveis sem fazer grandes investimentos em equipamentos de rede.

Se você está fazendo isso como um exercício ou experiência de aprendizado, tudo bem, mas nada do que você postou até este ponto faz um argumento convincente para fazer o que você está falando.