IPsec entre dous equipos: onde comeza e onde remata a protección

A protección nun par de equipos comeza onde remata a asociación de seguridade, e ese é o feito que máis a miúdo pasa por alto a intuición forxada polas pasarelas. Un servidor de aplicacións e o seu servidor de bases de datos poden protexer a súa propia conversa directamente, sen ningún concentrador de acceso remoto no camiño, e o límite de protección queda entón dentro de cada equipo en lugar de nun cortafogos. O que iso lle achega é cobertura de extremo a extremo para fluxos seleccionados. O que non lle achega é unha decisión sobre quen pode ler que fila.

O límite está onde remata a SA

A RFC 4301 describe as asociacións de seguridade en modo transporte como a disposición que normalmente se usa entre un par de equipos para a protección de extremo a extremo. Eses dous equipos teñen as claves, e cada un decide cales dos seus propios paquetes entran na asociación. Un túnel de pasarela remata nun lugar completamente distinto e chega ao equipo a través dun segmento interno adicional, que é un límite de confianza diferente mesmo cando o paquete vai cifrado durante a maior parte da súa viaxe.

Equipo a equipo e modo transporte non son sinónimos, con todo. Dous equipos poden construír igual de correctamente unha asociación en modo túnel entre eles, así que escolla primeiro o modo e despois describa os extremos. Escriba ambos na nota de deseño xunto aos enderezos dos pares, porque un revisor que só coñeza o modo suporá o outro.

A SPD decide a protección, a ruta decide a dirección

Unha táboa de encamiñamento responde a onde vai un paquete. A base de datos de política de seguridade responde a como atravesa o tráfico seleccionado o límite de protección, e faino por dirección cos seus propios selectores. Esa separación é a razón pola que unha ruta que funciona cara á base de datos non demostra nada sobre se a petición estaba protexida, e pola que unha negociación establecida non demostra nada sobre se esta aplicación concreta coincidiu con ela. Compare os selectores antes de comparar os contadores, xa que os contadores só describen os fluxos que chegaron tan lonxe.

En Linux, ip xfrm policy imprime esas entradas coa súa dirección, prioridade, selector e acción de permitir, bloquear ou atrapar, mentres que ip xfrm state mostra as asociacións resultantes e os seus contadores. Ler as dúas xuntas é a forma de atopar o fluxo que evitou o túnel en silencio porque unha entrada de permitir máis ampla coincidiu primeiro.

A orde de prioridade forma parte da política, non é un detalle de implementación. Unha entrada estreita que debería protexer o porto da base de datos perde fronte a unha entrada máis ampla con maior prioridade, e o fallo parece indicar que a política nunca se consultou.

O modo transporte cobre a capa seguinte, non a cabeceira IP

En modo transporte a cabeceira ESP sitúase entre a cabeceira IP e a carga útil, e os campos de enderezo desa cabeceira seguen visibles para todos os dispositivos do camiño. Iso está ben cando os enderezos non son o segredo e a carga útil si. É a elección equivocada se ademais necesita ocultar a topoloxía interna, porque só o modo túnel envolve a cabeceira orixinal dentro dunha nova.

Ambos os modos poden transportar varios protocolos da capa seguinte, e ESP protexerá o que coincida co selector en lugar de todo o que envía o equipo.

A selección é máis estreita que a conexión

Unha soa asociación pode transportar varios fluxos, pero só aqueles que a política selecciona. Rexistre as identidades dos pares, os enderezos de orixe e destino, o protocolo e o alcance do servizo para a relación que pretende, e despois decida por separado se o tráfico que non coincide pode ir en claro, debe protexerse ou debe descartarse cando a asociación non estea dispoñible. Esa última decisión é a que produce sorpresas, porque unha regra que esixe protección para a orixe equivocada pode bloquear o seu propio acceso de xestión coa mesma eficacia coa que bloquea un intruso.

Manteña unha ruta fóra de banda aprobada mentres cambia a aplicación, e próbea antes de necesitala en lugar de despois de que ambos os equipos queden inalcanzables.

A identidade da máquina non é o permiso da aplicación

IPsec autentica un par configurado e protexe os paquetes seleccionados. Non decide que rexistro da base de datos pode editar unha persoa, e non converte unha identidade de servidor de confianza nunha concesión de todos os privilexios da aplicación. As contas, os roles e a autorización da aplicación quedan exactamente onde estaban, e un requisito de TLS a nivel de aplicación conserva o seu propio propósito mesmo cando o camiño de rede xa está protexido.

Acepte o deseño cunha operación desde a orixe prevista e unha que debe rexeitarse, e inclúa que ocorre cando a asociación requirida non se pode establecer. Unha proba de alcanzabilidade corrente dille que os paquetes se moven; non lle di que se moveron baixo a política que vostede escribiu.