Qué es y cómo funciona IPsec

En este artículo, responderé la pregunta » ¿Qué es IPsec ?». Aprenderá todo lo que necesita saber sobre IPsec.

¿Qué es IPsec y en qué consiste?

IPsec no es un protocolo, sino tres o cuatro, dependiendo de cómo lo cuente. En OpenVPN y otras soluciones basadas en TLS, todo es simple: se establece una conexión TCP o UDP, se negocian los parámetros y luego se transmiten los datos.

En IPsec, diferentes protocolos son responsables de negociar parámetros y de transmitir datos. En Linux, BSD y muchos sistemas operativos de enrutadores especializados, el túnel se puede configurar manualmente sin la necesidad de un protocolo de control.

AH y ESP

Los tres componentes principales de la seguridad son accesibilidad, autenticidad y confidencialidad. IPsec puede proporcionar autenticidad sin hacer nada por la privacidad.

Protocolo AH (Encabezado de autenticación) agrega un encabezado especial con una suma de comprobación al paquete. En la práctica, rara vez se usa, porque no contribuye a la confidencialidad.

Sin embargo, se puede encontrar en aplicaciones donde solo la autenticidad es importante. Por ejemplo, el protocolo de enrutamiento OSPFv2 usaba contraseñas y sumas MD5 para protegerse contra anuncios falsos, y su sucesor OSPFv3 no incluye ninguna funcionalidad de protección; en cambio, se propone usar IPsec en modo de transporte (transparente) y con una firma AH sin cifrado.

ESP (Carga útil de seguridad encapsulada) cifra el contenido del paquete y agrega hashes. Se puede utilizar en dos modos: transporte y túnel. Ahora, en las redes IPv4, cualquier VPN es impensable sin enrutar direcciones privadas (grises) a través del túnel, porque los hosts se comunican con el mundo exterior a través de NAT. Pero IPsec es anterior a NAT e inicialmente solo cifró la carga útil del paquete sin tocar los encabezados; este es el modo de transporte.

En el modo túnel, ESP encripta todo el paquete y lo transfiere como una carga útil, por otro lado, se extrae, descifra y enruta.

Curiosamente, ambos no funcionan sobre TCP o UDP, sino que usan números de protocolo IP separados. En cualquier caso, de forma predeterminada, ESP se puede encapsular en UDP para que funcione a través de NAT, pero más adelante eso.

Marco del protocolo de gestión – ISAKMP

ISAKMP (Asociación de seguridad de Internet y protocolo de administración de claves) describe los principios generales para negociar configuraciones de seguridad. Se describe enRFC 2408.

ISAKMP no es un protocolo de red completo. Este es un marco que describe los requisitos para el funcionamiento seguro de los protocolos para el intercambio de configuraciones de conexión segura, la terminología y el formato general de los paquetes, pero no dice nada sobre protocolos específicos para el intercambio de claves, el cifrado, etc. Esto sigue siendo la conciencia de las implementaciones.

Es de ISAKMP de donde provienen los términos Fase 1 y Fase 2, que a menudo se pueden encontrar en la interfaz de configuración del enrutador y en las descripciones de configuración para la conexión. Fase 1: coordinación de parámetros para el intercambio seguro de datos sobre la configuración. Fase 2: coordinación de los parámetros de protección del tráfico transmitido de hosts o aplicaciones.

La implementación más popular y casi única de ISAKMP es IKE.

Protocolo de control – IKE

IKE (Internet Key Exchange) es el protocolo de administración real para IPsec basado en ISAKMP. En la práctica, podemos decir que la Fase 1 es la coordinación de la configuración de IKE, y la Fase 2 es la coordinación de la configuración de ESP.

En sistemas similares a UNIX, IKE es la única parte de la pila IPsec que funciona como un proceso normal. El cifrado en sí se implementa en el núcleo, y el demonio IKE le pasa parámetros después de negociar con la segunda parte. En Linux, esto sucede a través de netlink o comandos ip xfrm.

El subsistema Linux XFRM generalmente está asociado con IPsec, pero puede realizar otras transformaciones, como la compresión de la carga útil.

Los paquetes populares de IPsec como StrongSWAN y LibreSWAN implementan IKE.

Alinear la configuración de cifrado

IKE tiene la oportunidad de ofrecer al segundo lado varias opciones para elegir, y la conexión se establecerá si ambos lados tienen al menos una opción de coincidencia. Este es el principio general de los protocolos de intercambio de claves, TLS funciona igual, pero TLS elimina periódicamente la compatibilidad con algoritmos heredados. En IKE, la seguridad de la selección de algoritmos permanece en la conciencia del usuario. Obviamente, DES y MD5 vulnerables no están oficialmente excluidos del protocolo y aún son compatibles con muchas implementaciones.

Cada túnel tiene una o más «propuestas» asociadas. Las propuestas se procesan hasta el primer partido. De ahí la consecuencia: es muy posible que un servidor malicioso (o irresponsablemente configurado) ofrezca al cliente algoritmos obsoletos, y un cliente descuidado estará de acuerdo. Es posible que algunos clientes ni siquiera puedan seleccionar los algoritmos manualmente, y especialmente a los administradores perezosos les gusta hacer una gran propuesta para todos los clientes con todos los algoritmos concebibles. El estándar no obliga a ordenar los algoritmos por confiabilidad, y las partes pueden acordar un cifrado hace medio siglo.

Además, el cifrado nulo es oficialmente compatible: la opción de no cifrar el tráfico en absoluto.

Para asegurarse de que la configuración sea segura, lo ideal es comprender un poco los principios de la criptografía y seguir las noticias. Sin embargo, se pueden citar varias recetas.

1. En ningún caso debe aceptar algo que termine ecb. El ECB (Electronic Code Book) es un modo de operación extremadamente inseguro para los cifrados de bloque. La esencia del problema queda claramente demostrada por los famososPingüino del BCE. Un buen cifrado en el modo incorrecto es un cifrado incorrecto. AES-128-CBC es bueno, AES-128-ECB es malo.
2. 3DES y Blowfish hasta hace poco se consideraban confiables, pero vulnerabilidad SWEET32demostró que esto no es así. AES-128, AES-256, Twofish y otros cifrados con bloques de 128 bits siguen siendo una opción inteligente.
3. Los grupos para el algoritmo Diffie-Hellman DH1024 (grupo 2) y DH1536 (grupo 5) también se reconocen como vulnerables. Debe usar DH2048 (grupo 14) o grupos en curvas elípticas.

En IKE, es bastante posible utilizar diferentes conjuntos de algoritmos para la Fase 1 y la Fase 2. Esto no tiene mucho sentido, pero existe la posibilidad.

Diffie – Hellman y PFS

PFS (Perfecto secreto hacia adelante) Es la opción recomendada, que muchos dejan desactivada, pero en vano, especialmente si se utiliza una clave previamente compartida.

En este modo, se genera una clave de sesión actualizada periódicamente a partir de las claves de ambos lados y se combina con el algoritmo Diffie-Hellman (DH). En una formulación extremadamente simplificada, se basa en el hecho de que elevar un número a una potencia es simple, y calcular el logaritmo es mucho más difícil. Al usar PFS, si alguien obtiene acceso a la clave compartida, no podrá descifrar el tráfico interceptado por él, esta es la esencia del secreto directo. La clave seleccionada de una sesión tampoco ayudará a descifrar las siguientes, siempre que los números sean lo suficientemente grandes, por lo que DH1024 y DH1536 se han vuelto inseguros: el hardware moderno ya es lo suficientemente rápido como para descifrarlos.

El parámetro Phase2 de por vida (vida útil de ESP) especifica con qué frecuencia debe cambiar la clave. La vida útil de la clave es un parámetro puramente local que no es consistente a través de IKE y puede resultar diferente en diferentes lados. Si sus túneles IPsec primero transmiten tráfico y luego dejan de funcionar repentinamente, verifique si la clave tiene la misma vida útil en ambos lados.

Asociaciones de seguridad

A diferencia de OpenVPN o Wireguard, IPsec por sí solo no crea ninguna interfaz virtual. En el momento de su creación, cada host en Internet tenía una dirección pública y simplemente no había necesidad de redes virtuales con direcciones separadas. Protocolos separados, como L2TP o GRE, manejan interfaces virtuales, e IPsec solo cifra su tráfico. Muchas plataformas admiten VTI, la interfaz virtual asociada con una conexión IPsec, pero en realidad es solo una configuración IPIP automatizada sobre IPsec.

En lugar de túneles, IPsec opera con entidades aún más abstractas: asociaciones de seguridad. No son conexiones de red, son solo conjuntos de parámetros que indican qué tráfico y cómo cifrar. Por ejemplo, «el tráfico de 192.168.1.0/24 a 10.1.0.0/24 debe cifrarse con AES-128 y agregar la cantidad SHA-1».

Las asociaciones de seguridad existen en ambos lados de forma independiente y no pueden terminar por sí mismas, a diferencia de las conexiones de red. Si ve una SA en vivo a su lado, esto no significa que el tráfico irá normalmente al segundo lado del túnel. Recuerde verificar que todo realmente funcione. Para que el segundo lado pueda descubrir lo que está sucediendo, debe configurar la detección de pares muertos (para IKEv1) o usar IKEv2, donde hay una comprobación de vida.

En el caso de detección de pares muertos, no olvide comprobar que los parámetros en ambos lados son los mismos, de lo contrario, puede permanecer con el túnel durante mucho tiempo, que solo parece estar vivo.

Transversal NAT

IPsec apareció antes de NAT y en su forma más pura no puede funcionar para NAT. Esta oportunidad le fue jodida más tarde. ESP en sí es un protocolo IP separado con el número 50. Para trabajar detrás de NAT, está encapsulado en UDP. En este caso, IKE y el ESP encapsulado usan el mismo puerto: UDP / 4500.

Inicialmente, NAT afectó a los usuarios de conexiones de clientes como L2TP e IPsec. La popularidad de las plataformas en la nube, donde en lugar de asignar direcciones públicas a los hosts, estas direcciones se distribuyen a través de NAT 1: 1 ha hecho que este problema sea relevante para las conexiones entre enrutadores.

Puede surgir un problema inesperado: si en el otro lado el túnel está configurado para una dirección fija, incluso si se admite el recorrido NAT, la conexión no funcionará.

El hecho es que los identificadores de host están presentes en los paquetes IKE. Por defecto, la mayoría de las implementaciones usan la dirección de interfaz desde la cual se envían los paquetes como un identificador, y en el caso de NAT, ya no coincide con la dirección de origen cuando los paquetes llegan al segundo lado.

La solución es simple: nadie se compromete a usar el identificador predeterminado. Puede escribir cualquier cadena en él, a veces incluso es necesario, por ejemplo, si el segundo lado no tiene una dirección fija o se usa x.509.

Por ejemplo, en StrongSWAN:

IKEv1 vs IKEv2

IKE tiene dos versiones: IKEv1 e IKEv2. IKEv2 obtuvo un uso generalizado solo en los últimos años, y no en todas partes, pero tiene una serie de ventajas tangibles.

• La estandarización final del trabajo a través de NAT: en la mayoría de los casos, ahora simplemente funciona.
• Verificación de la vida útil: el controlador de dos vías se mantiene vivo para verificar si las SA están vivas.
• La capacidad de combinar múltiples criterios de cifrado de tráfico en una SA.

En IKEv1, se necesitaba una SA separada para cada par de direcciones locales y remotas. Por ejemplo, si los hosts 192.168.1.1 y 192.168.1.2 necesitan acceso de túnel a 10.1.0.1 y 10.1.0.2, el demonio IKE creará cuatro SA independientes. IKEv2 en este sentido es más flexible.

IKEv2 también se elimina permanentemente aggressive mode, en el que los parámetros de Fase 1 y Fase 2 se pasan simultáneamente. Sin embargo, una parte importante de las implementaciones ha dejado de admitirlo en IKEv1 debido a obvios problemas de seguridad con este enfoque.

Si ambas partes admiten IKEv2, es mejor usarlo. Si está interesado en leer el estándar, se describe enRFC 5996.

Conclusión

Espero que si IPsec fuera misterioso para usted, ahora los principios de su funcionamiento se han vuelto más claros. No olvide que la seguridad de la configuración de cifrado está en su conciencia y que no todos los conflictos de configuración se detectarán automáticamente.