IPsec entre dos hosts: dónde empieza y dónde termina la protección
Un par de hosts puede proteger flujos seleccionados sin una puerta de enlace. Defina los extremos, la política que selecciona el tráfico y los permisos que siguen siendo independientes.
La protección en un par de hosts empieza donde termina la asociación de seguridad, y ese es el hecho que más a menudo pasa por alto la intuición forjada por las puertas de enlace. Un servidor de aplicaciones y su servidor de bases de datos pueden proteger su propia conversación directamente, sin ningún concentrador de acceso remoto en el camino, y el límite de protección queda entonces dentro de cada host en lugar de en un cortafuegos. Lo que eso le aporta es cobertura de extremo a extremo para flujos seleccionados. Lo que no le aporta es una decisión sobre quién puede leer qué fila.
El límite está donde termina la SA
La RFC 4301 describe las asociaciones de seguridad en modo transporte como la disposición que normalmente se usa entre un par de hosts para la protección de extremo a extremo. Esos dos hosts tienen las claves, y cada uno decide cuáles de sus propios paquetes entran en la asociación. Un túnel de puerta de enlace termina en un lugar completamente distinto y llega al host a través de un segmento interno adicional, que es un límite de confianza diferente incluso cuando el paquete va cifrado durante la mayor parte de su recorrido.
Host a host y modo transporte no son sinónimos, sin embargo. Dos hosts pueden construir con la misma corrección una asociación en modo túnel entre ellos, así que elija primero el modo y después describa los extremos. Escriba ambos en la nota de diseño junto a las direcciones de los pares, porque un revisor que solo conozca el modo supondrá el otro.
La SPD decide la protección, la ruta decide la dirección
Una tabla de enrutamiento responde adónde va un paquete. La base de datos de política de seguridad responde cómo cruza el tráfico seleccionado el límite de protección, y lo hace por dirección con sus propios selectores. Esa separación es la razón por la que una ruta que funciona hacia la base de datos no demuestra nada sobre si la petición estaba protegida, y por la que una negociación establecida no demuestra nada sobre si esta aplicación concreta coincidió con ella. Compare los selectores antes de comparar los contadores, ya que los contadores solo describen los flujos que llegaron tan lejos.
En Linux, ip xfrm policy imprime esas entradas con su dirección, prioridad, selector y acción de permitir, bloquear o atrapar, mientras que ip xfrm state muestra las asociaciones resultantes y sus contadores. Leer las dos juntas es la forma de encontrar el flujo que evitó el túnel en silencio porque una entrada de permitir más amplia coincidió primero.
El orden de prioridad forma parte de la política, no es un detalle de implementación. Una entrada estrecha que debería proteger el puerto de la base de datos pierde frente a una entrada más amplia con mayor prioridad, y el fallo parece indicar que la política nunca se consultó.
El modo transporte cubre la capa siguiente, no la cabecera IP
| Transport mode | Tunnel mode | |
|---|---|---|
| Original IP header | kept for routing the flow | replaced by an outer header |
| What ESP protects | the carried next-layer payload | the whole inner IP packet |
| Where it terminates | commonly the two hosts | gateway pair, or a host pair |
En modo transporte la cabecera ESP se sitúa entre la cabecera IP y la carga útil, y los campos de dirección de esa cabecera siguen visibles para todos los dispositivos del camino. Eso está bien cuando las direcciones no son el secreto y la carga útil sí. Es la elección equivocada si además necesita ocultar la topología interna, porque solo el modo túnel envuelve la cabecera original dentro de una nueva.
Ambos modos pueden transportar varios protocolos de la capa siguiente, y ESP protegerá lo que coincida con el selector en lugar de todo lo que envía el host.
La selección es más estrecha que la conexión
Una sola asociación puede transportar varios flujos, pero solo aquellos que la política selecciona. Registre las identidades de los pares, las direcciones de origen y destino, el protocolo y el alcance del servicio para la relación que pretende, y después decida por separado si el tráfico que no coincide puede ir en claro, debe protegerse o debe descartarse cuando la asociación no esté disponible. Esa última decisión es la que produce sorpresas, porque una regla que exige protección para el origen equivocado puede bloquear su propio acceso de gestión con la misma eficacia con la que bloquea a un intruso.
Mantenga una ruta fuera de banda aprobada mientras cambia la aplicación, y pruébela antes de necesitarla en lugar de después de que ambos hosts queden inalcanzables.
La identidad de la máquina no es el permiso de la aplicación
IPsec autentica un par configurado y protege los paquetes seleccionados. No decide qué registro de la base de datos puede editar una persona, y no convierte una identidad de servidor de confianza en una concesión de todos los privilegios de la aplicación. Las cuentas, los roles y la autorización de la aplicación se quedan exactamente donde estaban, y un requisito de TLS a nivel de aplicación conserva su propio propósito incluso cuando el camino de red ya está protegido.
Acepte el diseño con una operación desde el origen previsto y una que debe rechazarse, e incluya qué ocurre cuando la asociación requerida no puede establecerse. Una prueba de alcanzabilidad corriente le dice que los paquetes se mueven; no le dice que se movieron bajo la política que usted escribió.