IPsec entre dois hosts: onde a proteção começa e termina

A proteção num par de hosts começa onde termina a associação de segurança, e esse é o facto que a intuição moldada por gateways mais frequentemente deixa passar. Um servidor de aplicações e o seu servidor de base de dados podem proteger a própria conversa diretamente, sem qualquer concentrador de acesso remoto no caminho, e o limite de proteção fica então dentro de cada host em vez de numa firewall. O que isto lhe dá é cobertura de ponta a ponta para fluxos selecionados. O que não lhe dá é uma decisão sobre quem pode ler que linha.

O limite é onde termina a SA

A RFC 4301 descreve as associações de segurança em modo de transporte como a disposição usualmente utilizada entre um par de hosts para proteção de ponta a ponta. Esses dois hosts detêm as chaves, e cada um decide quais dos seus próprios pacotes entram na associação. Um túnel de gateway termina num local completamente diferente e chega ao host através de um segmento interno adicional, o que é um limite de confiança diferente mesmo quando o pacote vai cifrado durante a maior parte do percurso.

Host a host e modo de transporte não são, no entanto, sinónimos. Dois hosts podem construir com igual correção uma associação em modo de túnel entre si, por isso escolha primeiro o modo e descreva depois os extremos. Escreva ambos na nota de conceção junto aos endereços dos pares, porque um revisor que conheça apenas o modo assumirá o outro.

A SPD decide a proteção, a rota decide a direção

Uma tabela de encaminhamento responde a onde vai um pacote. A base de dados de política de segurança responde a como o tráfego selecionado atravessa o limite de proteção, e fá-lo por direção com os seus próprios seletores. Essa separação é a razão pela qual uma rota funcional até à base de dados nada prova sobre se o pedido estava protegido, e pela qual uma negociação estabelecida nada prova sobre se esta aplicação concreta correspondeu a ela. Compare os seletores antes de comparar os contadores, pois os contadores descrevem apenas os fluxos que chegaram tão longe.

No Linux, o ip xfrm policy imprime essas entradas com a sua direção, prioridade, seletor e ação de permitir, bloquear ou capturar, enquanto o ip xfrm state mostra as associações resultantes e os seus contadores. Ler os dois em conjunto é a forma de encontrar o fluxo que contornou o túnel em silêncio porque uma entrada de permitir mais ampla correspondeu primeiro.

A ordenação por prioridade faz parte da política, não é um detalhe de implementação. Uma entrada estreita que deveria proteger a porta da base de dados perde para uma entrada mais ampla com prioridade superior, e a falha parece indicar que a política nunca foi consultada.

O modo de transporte cobre a camada seguinte, não o cabeçalho IP

No modo de transporte o cabeçalho ESP fica entre o cabeçalho IP e a carga útil, e os campos de endereço desse cabeçalho permanecem visíveis para todos os dispositivos no caminho. Isso está bem quando os endereços não são o segredo e a carga útil é. É a escolha errada se também precisar de ocultar a topologia interna, porque só o modo de túnel envolve o cabeçalho original num novo.

Ambos os modos podem transportar vários protocolos da camada seguinte, e o ESP protegerá o que o seletor corresponder em vez de tudo o que o host envia.

A seleção é mais estreita do que a ligação

Uma única associação pode transportar vários fluxos, mas apenas aqueles que a política seleciona. Registe as identidades dos pares, os endereços de origem e destino, o protocolo e o âmbito do serviço para a relação que pretende, e depois decida em separado se o tráfego que não corresponde pode passar em claro, tem de ser protegido ou tem de ser descartado quando a associação não está disponível. É essa última decisão que produz surpresas, porque uma regra que exige proteção para a origem errada pode bloquear o seu próprio acesso de gestão com a mesma eficácia com que bloqueia um intruso.

Mantenha um caminho fora de banda aprovado enquanto altera a aplicação, e teste-o antes de precisar dele em vez de depois de ambos os hosts ficarem inacessíveis.

A identidade da máquina não é uma permissão da aplicação

O IPsec autentica um par configurado e protege os pacotes selecionados. Não decide que registo da base de dados uma pessoa pode editar, e não transforma uma identidade de servidor de confiança numa concessão de todos os privilégios da aplicação. As contas, as funções e a autorização da aplicação ficam exatamente onde estavam, e um requisito de TLS ao nível da aplicação mantém o seu próprio propósito mesmo quando o caminho de rede já está protegido.

Aceite o desenho com uma operação a partir da origem prevista e uma que tem de ser recusada, e inclua o que acontece quando a associação exigida não pode ser estabelecida. Um teste de alcançabilidade comum diz-lhe que os pacotes se movem; não lhe diz que se moveram sob a política que escreveu.