PROTOCOLO IPSEC

Este artículo presenta el funcionamiento del protocolo IPsec, que permite la creación de redes privadas virtuales de una manera que cumple con las especificaciones del IETF. Se detallan los servicios que ofrece el IPsec y sus limitaciones, así como las cuestiones de interoperabilidad, tanto con otros protocolos como entre diferentes aplicaciones. Por último, se presentan algunas implementaciones y se da una rápida visión general de su cumplimiento de las normas.

1 – Introducción al protocolo IPSec

El protocolo IPsec es uno de los métodos utilizados para crear VPNs (redes privadas virtuales), es decir, para unir sistemas informáticos de forma segura, apoyándose en una red existente, que a su vez se considera insegura. El término «seguro» tiene aquí un significado bastante vago, pero puede abarcar en particular las nociones de integridad y confidencialidad. El mayor interés de esta solución en comparación con otras técnicas (por ejemplo, los túneles SSH) es que se trata de un método estándar (opcional en el IPv4, pero obligatorio en el IPv6), desarrollado para este preciso propósito, descrito por diferentes RFC, y por lo tanto interoperable. Algunas ventajas adicionales son el ahorro de ancho de banda, en primer lugar porque la compresión de los encabezamientos de los datos transmitidos está prevista por esta norma, y en segundo lugar porque no utiliza técnicas de encapsulación excesivamente engorrosas, como los túneles PPP sobre enlaces SSH. También permite proteger protocolos de bajo nivel como ICMP e IGMP, RIP, etc…

El IPSec también tiene la ventaja de ser una solución escalable, ya que los verdaderos algoritmos de cifrado y autenticación se especifican por separado del propio protocolo. Sin embargo, esto tiene la desventaja inherente de ser flexible y su gran complejidad hace que sea difícil de aplicar. Los diversos servicios que ofrece el protocolo IPSec se detallan en este documento. Las formas en que estos diversos protocolos pueden combinarse entre sí, lo que se requiere para apoyar su aplicación y luego se presentan. Se estudian los medios de gestión de las claves de cifrado y firma y se discuten las cuestiones de interoperabilidad asociadas. Por último, se ofrece una rápida visión general de algunas implementaciones del IPSec, centrándose principalmente en su cumplimiento de las especificaciones.

2 – Servicios ofrecidos por IPsec

2.1 – Los dos modos de intercambio del IPsec

Una comunicación entre dos anfitriones, protegida por el IPsec, puede operar en dos modos diferentes: modo de transporte y modo de túnel. El primer modo ofrece esencialmente protección a los protocolos de nivel superior, mientras que el segundo modo permite encapsular los datagramas de IP dentro de otros datagramas de IP, cuyo contenido está protegido. El mayor interés de esta segunda modalidad es que hace factible la implantación de pasarelas de seguridad que manejen toda la parte IPsec de una comunicación y transmitan los datagramas purgados de su parte IPsec a su receptor real. También es posible encapsular una comunicación IPsec en modo túnel o transportarla en otra comunicación IPsec en modo túnel, procesada a su vez por una pasarela de seguridad, que transmite los datagramas tras la eliminación de su primera envoltura a un host que procesa a su vez las protecciones restantes o a una segunda pasarela de seguridad.

2.2 – Protocolos subyacentes al IPsec

2.2.1 – AH (encabezamiento de autenticación)

AH es el primero y más simple de los protocolos de protección de datos que forman parte de la especificación IPsec. Se detalla en el RFC 2402. Su propósito es garantizar..:

  • Autenticación: los datagramas IP recibidos han sido realmente enviados por el host cuya dirección IP se indica como la dirección de origen en los encabezados.
  • Unicidad (opcional, a discreción del receptor): un datagrama que haya sido transmitido y grabado legítimamente por un atacante no puede ser reutilizado por este último, por lo que se evitan los ataques de repetición.
  • Integridad: los siguientes campos del datagrama IP no han sido modificados desde que fueron transmitidos: datos (en el modo de túnel, esto incluye todos los campos, incluidos los encabezados, del datagrama IP encapsulado en el datagrama protegido por AH), versión (4 en IPv4, 6 en IPv6), longitud del encabezado (en IPv4), longitud total del datagrama (en IPv4), longitud de los datos (en IPv6), identificación, siguiente protocolo o encabezamiento (este campo es 51 para indicar que es el protocolo AH), dirección IP del remitente, dirección IP del receptor (sin enrutamiento de la fuente).

Además, en el caso de que esté presente el enrutamiento de la fuente, el campo de la dirección IP del receptor tiene el valor que el emisor predijo que tendría cuando fue recibido por el receptor. Sin embargo, como el valor que tomarán en la recepción los campos de tipo de servicio (IPv4), indicadores (IPv4), índice de fragmentos (IPv4), TTL (IPv4), suma de comprobación del encabezamiento (IPv4), clase (IPv6), etiqueta de flujo (IPv6) y límite de salto (IPv6) no es predecible en el momento de la transmisión, su integridad no está garantizada por AH.

La integridad de las opciones de propiedad intelectual que no pueden modificarse durante el transporte está garantizada, mientras que la integridad de las demás opciones no lo está.
Tenga en cuenta que AH no garantiza la confidencialidad: los datos están firmados pero no encriptados.

Por último, la AH no especifica ningún algoritmo de firma en particular, estos se describen por separado, sin embargo, se requiere una implementación que cumpla con la RFC 2402 para soportar los algoritmos MD5 y SHA-1.

2.2.2 – ESP (encapsulando la carga útil de seguridad)

ESP es el segundo protocolo de protección de datos que forma parte de la especificación IPsec. Está detallado en el RFC 2406. A diferencia de AH, el ESP no protege las cabeceras de los datagramas IP utilizados para transmitir la comunicación. Sólo los datos están protegidos. En el modo de transporte, proporciona..:

  • Confidencialidad de los datos (opcional): la parte de los datos de los datagramas IP transmitidos está encriptada.
  • Autenticación (opcional, pero obligatoria en ausencia de confidencialidad): la parte de datos de los datagramas IP recibidos sólo puede ser transmitida por el host con el que se realiza el intercambio IPsec, que sólo puede autenticarse con éxito si conoce la clave asociada a la comunicación ESP. También es importante tener presente que la falta de autenticación es perjudicial para la privacidad, lo que la hace más vulnerable a ciertos ataques activos.
  • Único (opcional, a discreción del receptor).
  • Integridad: los datos no han sido alterados desde que fueron transmitidos.

En el modo de túnel, estas garantías se aplican a los datos del datagrama en el que se encapsula el tráfico útil, es decir, al conjunto (incluidos los encabezamientos y las opciones) del datagrama encapsulado. En este modo, aparecen dos ventajas adicionales:

  • Confidencialidad limitada de los flujos de datos (sólo en modo túnel, cuando se garantiza la confidencialidad): un atacante capaz de observar los datos que pasan por un enlace no puede determinar la cantidad de datos que se transfieren entre dos anfitriones concretos. Por ejemplo, si la comunicación entre dos subredes está cifrada mediante un túnel ESP, el atacante puede calcular el volumen total de datos intercambiados entre esas dos subredes, pero no la distribución de ese volumen entre los diferentes sistemas de esas subredes.
  • La confidencialidad de los datos, si se solicita, se extiende a todos los campos, incluidos los encabezamientos, del datagrama IP encapsulado en el datagrama protegido por el PES).

Por último, el ESP no especifica una firma o algoritmo de cifrado en particular, éstos se describen por separado; sin embargo, se requiere una implementación conforme a la RFC 2406 para soportar el algoritmo de cifrado DES en el modo CBC, y firmas que utilicen las funciones hash MD5 y SHA-1.

2.2.3 – Implementación del IPSec en el Datagrama IP

La figura 1 muestra cómo los datos necesarios para el correcto funcionamiento de los formatos AH y ESP se colocan en el datagrama IPv4. Se trata de una adición al datagrama IP, no de un nuevo datagrama, que permite un número teóricamente ilimitado o casi ilimitado de encapsulados IPsec: un datagrama determinado puede, por ejemplo, estar protegido por tres aplicaciones sucesivas de AH y dos encapsulados ESP.

3 – Arquitecturas de seguridad

3.1 – Asociaciones de seguridad

RFC 2401 (Arquitectura de Seguridad para el Protocolo de Internet) describe el protocolo IPsec al más alto nivel. En particular, indica lo que se supone que debe configurar una aplicación en términos de política de seguridad (es decir, qué intercambios de IP deben ser protegidos por el IPsec y, si procede, qué protocolo(s) utilizar). Cada sistema capaz de utilizar IPsec debe tener un SPD (base de datos de política de seguridad), cuya forma precisa se deja a la elección de la aplicación, y que permite especificar la política de seguridad que se aplicará al sistema. Cada entrada de esta base de datos se identifica con un SPI (índice de parámetros de seguridad) único (32 bits) elegido arbitrariamente.

Una comunicación protegida con IPsec se llama SA (asociación de seguridad). Una SA se basa en una sola aplicación TSA o una sola aplicación ESP. Esto no excluye el uso simultáneo de la TSA y la PES entre dos sistemas, o por ejemplo el encapsulamiento de los datagramas de la TSA en otros datagramas de la TSA, pero entonces se tendrán que activar varias SAs entre los dos sistemas. Además, un AS es unidireccional. Por lo tanto, la protección de la comunicación bidireccional requerirá la activación de dos AS. Cada SA se identifica de forma exclusiva mediante un SPI, una dirección IP de destino (posiblemente una dirección de difusión o multidifusión) y un protocolo (AH o ESP). Los AS activos están agrupados en una SAD (asociación de seguridad

El SPD es consultado durante el procesamiento de cualquier datagrama IP, entrante o saliente, incluyendo los datagramas no IPsec. Para cada datagrama, tres comportamientos son posibles: rechazarlo, aceptarlo sin procesamiento IPsec, o aplicar IPsec. En el tercer caso, el SPD también especifica qué tratamientos IPsec deben aplicarse (ESP, AH, modo de túnel o de transporte, qué algoritmo de firma y/o de cifrado debe utilizarse).

Los más importantes de estos términos se resumen en el siguiente cuadro:

  • Base de datos de políticas de seguridad del SPD
  • SA una entrada del SPD
  • Lista DAS de CI en uso

Si el administrador del sistema lo desea, las reglas del SPD deberían poder depender de los siguientes parámetros:

  • dirección IP de destino o grupo de direcciones IP
  • dirección IP o grupo de direcciones de la fuente
  • nombre del sistema (DNS completo, nombre X.500 distinguido o general)
  • protocolo de transporte utilizado (típicamente TCP o UDP)
  • nombre completo de usuario, como foo@bar.net (sin embargo, este parámetro no es necesario en algunos tipos de implementación)
  • Importancia de los datos (este parámetro, sin embargo, no es obligatorio en ciertos tipos de implementaciones)
  • puertos de origen y destino (sólo UDP y TCP, el soporte de este parámetro es opcional)

Algunos parámetros pueden ser ilegibles debido a la posible codificación de la ESP en el momento de ser procesados, en cuyo caso el valor de la SPD para ellos puede especificarlo, es decir..:

  • identidad de usuario
  • el protocolo de transporte
  • puertos de origen y destino

Por lo tanto, es posible especificar una política de seguridad relativamente fina y detallada. Sin embargo, una política común para el tráfico a un conjunto de sistemas proporciona una mejor protección contra el análisis del tráfico que una política extremadamente detallada, que incluya muchos parámetros específicos de cada sistema individual. Por último, si la implementación permite que las aplicaciones se especifiquen a sí mismas a qué parte del tráfico aplicar el IPsec y cómo, el administrador debe ser capaz de evitar que eludan la política por defecto.

3.2 – Arquitecturas soportadas

El protocolo IPsec permite teóricamente cualquier combinación, en un número virtualmente ilimitado de niveles de encapsulación, es decir, acumulaciones SA. Sin embargo, no es necesario que las implementaciones ofrezcan esa flexibilidad. Las arquitecturas que debe soportar una aplicación que cumpla con la RFC 2401, cuatro en número, se describen a continuación.

3.2.1 – Diálogo entre dos anfitriones que protegen el tráfico ellos mismos

Dos hosts se dedican a la comunicación IPsec, encapsulando el protocolo de alto nivel en :
en el modo de transporte:

  • Los datagramas de AH
  • Datagramas ESP
  • o datagramas ESP encapsulados en datagramas AH.

en modo túnel:

  • Los datagramas de AH
  • o datagramas ESP

3.2.2 – Diálogo entre dos redes locales utilizando pasarelas de seguridad

Aquí, dos puertas de enlace de seguridad gestionan las conversaciones entre los hosts de dos redes locales diferentes, con el IPsec aplicándose de forma transparente a los hosts. Las dos pasarelas de seguridad intercambian datagramas en modo túnel, utilizando AH o ESP (después del enrutamiento, esto corresponde simplemente a la segunda parte del caso anterior), y luego transmiten los datagramas obtenidos después del procesamiento IPsec a los hosts receptores. Así, los datagramas IP enviados por un sistema en una de las dos redes LAN son encapsulados en otros datagramas IP+IPsec por la pasarela de la «red local de envío», cuyo encapsulamiento es eliminado por la pasarela de la «red local de recepción» para obtener de nuevo los datagramas IP originales.

3.2.3 – Diálogo entre dos anfitriones que cruzan dos puertas de seguridad

El tercer caso no añade realmente ningún requisito previo a las implementaciones del IPsec. Así pues, una pasarela de seguridad debe tener la capacidad de transmitir el tráfico ya asegurado por el IPsec a través de un túnel IPsec. Esto permite diálogos IPsec entre dos hosts que a su vez se encuentran en redes LAN conectadas por puertas de enlace de seguridad.

3.2.4 – Diálogo entre un anfitrión y una puerta de seguridad

El último caso es el de un host externo que se conecta a una LAN protegida por una puerta de seguridad. La documentación técnica a menudo se refiere a tal anfitrión como un guerrero de carretera. Inicia una conversación IPsec con un sistema en la LAN en modo de transporte, encapsulado en un túnel IPsec establecido entre el propio guerrero de la carretera y la puerta de seguridad. En este caso, los datagramas del túnel son del tipo AH o ESP y los datagramas utilizados en el modo de transporte deben ser del tipo AH, ESP o ESP encapsulados en AH.

4 – Gestión de claves

Los servicios de protección que ofrece el IPsec se basan en algoritmos criptográficos y, por lo tanto, se basan en claves. Si bien estas teclas son manejables manualmente en caso de que se necesiten pocos anfitriones para iniciar conversaciones IPsec, esto se convierte en una pesadilla cuando el sistema comienza a expandirse (el número de pares de teclas aumenta cuadráticamente con el número de sistemas). Por ello, la especificación del IPsec también propone procesos de intercambio automático de claves, cuyos aspectos más importantes se examinan aquí. Sin embargo, una presentación completa de este procedimiento está fuera del alcance de este artículo. El RFC 2401 especifica que una implementación IPsec debe soportar la gestión manual de claves y el método IKE de intercambio automático de claves, aunque existen otros algoritmos. Un punto importante es que la gestión automática de las claves se considera más segura que la gestión manual de las claves.

El protocolo de intercambio de claves de Internet (IKE) se describe en el RFC 2409. Permite el intercambio de claves entre dos hosts con direcciones IP previamente conocidas o desconocidas dependiendo del modo de intercambio de claves seleccionado. Entre sus ventajas está el modo agresivo (esta característica no es obligatoria), que acelera el proceso de negociación a costa de la protección de la identidad. Sin embargo, la identidad está protegida en el caso de una negociación de IKE autenticada con firmas de clave pública.

Se utilizan ampliamente dos formas de intercambio de claves: las claves precompartidas y los certificados X.509 (en este último caso, dos sistemas de direcciones inicialmente desconocidas pueden proteger su intercambio).

La segunda forma tiene la ventaja de permitir a los clientes de direcciones IP dinámicas y posiblemente cambiantes crear SAs, pero no está necesariamente soportada por las implementaciones que cumplen con el RFC 2409.

Por último, una definición que puede ser útil al leer la documentación técnica sobre IPsec: PFS (perfect forward secrecy) se define en el RFC 2409 como la noción de que el compromiso de una clave sólo permitirá el acceso a los datos protegidos por esa clave, pero no será suficiente para descifrar todo el intercambio IPsec, sólo se descifrará la parte de la comunicación protegida por la clave corrupta.

5 – Compresión de la cabeza

El RFC 3095 describe un protocolo de compresión de cabecera que puede aplicarse a RTP, UDP y ESP sobre IP. Desafortunadamente, la compresión de los datos en sí no está cubierta por esta especificación, por lo que no hay planes para comprimir los datos en sí en este momento. En cambio, está diseñado para acomodar las altas tasas de error de transmisión de las comunicaciones por aire. Por último, la compresión descrita se basa en una capa de enlaces que garantiza la transmisión de los datos en el orden en que se transmiten y sin duplicaciones, lo que puede hacer peligroso su uso en determinadas redes. Por último, la capa de enlace debe permitir la negociación de los parámetros ROHC (compresión robusta de cabecera), aunque esta negociación puede llevarse a cabo a priori o mediante el uso de otros protocolos.

6 – Problemas varios

El uso simultáneo de IPsec y otros protocolos o equipos de red plantea algunos problemas en algunos casos. Además, el manejo manual de las claves introduce algunas restricciones en los posibles usos del protocolo.

6.1 – Limitaciones debidas al manejo manual de las llaves

Los servicios de singularidad que ofrecen AH y ESP se basan en números de secuencia inicializados a 0 cuando se crea un AS y aumentados cuando se envía cada datagrama. Estos números de secuencia se almacenan en un entero de 32 bits, que nunca debe ser disminuido. El número máximo de datagramas que un AS puede intercambiar es por lo tanto del orden de cuatro mil millones. Más allá de este límite, es necesario crear un nuevo AS y por lo tanto una nueva clave. Esto dificulta la aplicación simultánea de la gestión manual de claves y la protección contra la duplicación de los datagramas. Siendo esto último opcional, es posible desactivarlo, en cuyo caso el número de secuencia puede ser cancelado cuando haya alcanzado su valor máximo.

6.2 – Emisión y multidifusión

El uso del IPsec para el envío y la recepción de datagramas de multidifusión y de radiodifusión plantea algunos problemas, algunos de los cuales aún no se han resuelto. Hay problemas de rendimiento por un lado, y dificultades que un simple aumento de la potencia de cálculo no resolvería, como la verificación de los números de secuencia. Por lo tanto, el servicio de protección contra la duplicación de datos no es utilizable en un entorno de multidifusión y radiodifusión en la actualidad.

6.3 – Cortafuegos

El filtrado de datagramas IPsec es complicado por dos razones:

  • Las RFC no especifican si, en un sistema que realiza simultáneamente las funciones de una pasarela de seguridad y un cortafuegos, la decodificación IPsec debe tener lugar antes o después de que se apliquen las reglas del cortafuegos.
  • El código de cortafuegos no puede leer ciertos datos, por ejemplo, los números de puerto, a partir de datos codificados o de datos transmitidos en un formato que no conoce.


Por lo tanto, es importante leer la documentación de la aplicación del IPsec utilizada en los sistemas diseñados para gestionar el IPsec y el cortafuegos simultáneamente. También es útil señalar que los sistemas que aplican reglas de cortafuegos antes de la decodificación IPsec suelen, no obstante, ser capaces de filtrar los datagramas decodificados utilizando herramientas de tunelización como ipip y gif, o filtrando en la interfaz de salida de datos. Por último, AH utiliza el protocolo número 51 y ESP utiliza el protocolo número 50, mientras que IKE utiliza el puerto UDP número 500. Esta información es esencial cuando se configura un cortafuegos para permitir o bloquear los intercambios IPsec.

6.4 – NATs

En teoría, debería evitarse cualquier traducción de direcciones en un datagrama del IPsec, ya que este tipo de operación modifica el contenido de los datagramas, lo que es incompatible con los mecanismos de protección de la integridad de los datos del IPsec. Hay una solución a este problema, propuesta por SSH Communications Security: el IPsec NAT-Traversal. Es un borrador, por lo tanto aún incompleto, pero suficiente para prever lo que nos depara el futuro. De hecho, algunos equipos ya permiten cruzar los NAT, utilizando protocolos más o menos estandarizados y con diversos grados de éxito. Como sólo es un borrador, se describe en documentos cuyo nombre y dirección cambian a menudo, pero una forma sencilla de encontrarlo es introducir la cadena draft-stenberg-ipsec-nat-traversal en su motor de búsqueda favorito. Finalmente, este protocolo sólo puede ser implementado si el protocolo IKE es usado simultáneamente.

6.5 – Protocolos distintos del IP

Una desventaja del IPsec es que este protocolo sólo permite el transporte seguro de los datagramas IP. Esto no es suficiente, ya que en un gran número de redes se utilizan otras normas como IPX y NetBIOS. Sin embargo, existe una solución a este problema: encapsular los datos a proteger en PPP, que a su vez es transportado por IPsec. El papel de la PPP es, en efecto, permitir la transmisión de diferentes protocolos a través de un enlace existente. Esto implica poder encapsular la PPP en datagramas IPsec, esta operación se describe en los siguientes párrafos.

6.5.1 – PPTP

La primera solución que permite este encapsulamiento es el protocolo PPTP, descrito por el RFC 2637. El PPTP ofrece así a un cliente, conocido como PAC (concentrador de acceso PPTP), la posibilidad de establecer un enlace PPP con un servidor conocido como PNS (servidor de red PPTP), encapsulado en datagramas IP. Si el cliente ha establecido previamente una SA con una pasarela de seguridad (posiblemente separada del PNS), que le permite proteger estos datagramas IP, los datos PPP también estarán seguros, al igual que los protocolos de nivel superior basados en el enlace PPP. Hay dos puntos importantes al configurar un firewall entre un CAP y un SNP:

  • El PPTP se basa en el Protocolo de Encapsulado General GRE, al que la IANA le ha asignado el número 47.
  • un enlace PPTP es controlado por una conexión TCP al puerto 1723 del SNP

Por último, el PPTP por sí solo, es decir, sin IPsec, puede y ha sido utilizado para crear VPNs, asegurando intercambios autenticados, protegiendo las contraseñas utilizadas de un posible atacante, pero sin encriptar el resto de la comunicación. Sin embargo, este sistema ofrece una autenticación mucho menos fiable que la que es posible con el IPsec. Además, se ha comprobado que muchas de las aplicaciones de este protocolo, incluidas las de Microsoft, tienen vulnerabilidades y no pueden proteger eficazmente las contraseñas de los usuarios. Por lo tanto, el uso de este sistema es arriesgado.

6.5.2 – L2TP

Una segunda solución para encapsular PPP en IP es el protocolo L2TP, descrito por el RFC 2661. Permite la transmisión de PPP usando protocolos de nivel 2 como el ethernet. También proporciona un mecanismo para encapsular la PPP en UDP. Por lo tanto, es posible proteger la PPP utilizando UDP encapsulado en IPsec. El L2TP también ofrece una arquitectura más modular que el PPTP: asume que el cliente es capaz de intercambiar tramas a través de un protocolo de nivel 2 o datagramas UDP con un LAC (concentrador de acceso L2TP), que transmite los datos a un LNS (servidor de red L2TP). Si el LAC y el LNS están físicamente ubicados en el mismo sistema, entonces el LAC y el LNS juegan exactamente el mismo papel que el PPTP LNS.

Un detalle importante al configurar un firewall: el L2TP encapsulado en UDP utiliza el puerto 1701.

6.5.3 – ¿PPTP o L2TP?

El uso de PPTP o L2TP no cambia mucho desde el punto de vista de la seguridad, la seguridad es proporcionada por la capa inferior de IPsec. Por lo tanto, la cuestión que se plantea es la del consumo de ancho de banda, porque todas estas encapsulaciones están empezando a representar un volumen importante de datos. En el caso de que un cliente se conecte a un ISP y luego haga un túnel hacia una red de destino, el PPTP debe guardar las cabeceras UDP. Por otra parte, en el caso de que un cliente se conecte, por ejemplo, por módem o línea RDSI, directamente a la red privada y, por lo tanto, tenga un enlace de nivel 2 a esa red, el L2TP parece ser más económico. Un último punto a tener en cuenta es que el sistema operativo que se ejecuta en el servidor a veces impone limitaciones:

  • para Windows 2000 y posteriores, Microsoft parece estar muy a favor de L2TP.
  • Las versiones anteriores de Windows no soportan L2TP.
  • Los Unix libres parecen estar ligeramente atrasados en el soporte de L2TP.

7 – Algunas implementaciones actuales

Esta sección ofrece una visión general de las capacidades de algunos sistemas operativos populares en cuanto a la compatibilidad con IPsec. La información proporcionada es una visión general de los sitios del sistema operativo, los proveedores y las preguntas frecuentes del software en cuestión, por lo que en estos sitios se pueden encontrar más detalles.

7.1 – Windows

Windows XP y 2000 incluyen soporte para el modo de transporte IPsec y el intercambio de claves utilizando certificados nativos. Hay una amplia gama de software disponible para crear VPNs en Windows, incluyendo un servidor VPN opcional en Windows 2000 y XP, capaz de configurar túneles IPsec/L2TP. Por otro lado, Windows 95, 98 y NT 4 tienen un gran número de implementaciones comerciales de IPsec y casi todas las versiones de Windows desde la 95 son capaces de crear túneles PPTP. Una solución interesante es la que ofrece la Seguridad de Comunicaciones SSH. Su implementación es actualmente una de las pocas implementaciones que apoyan el IPsec NAT-Traversal. El cliente está disponible para las versiones de Windows 95, 98, Me, NT 4, 2000 y XP.

7.2 – Linux

La implementación de IPsec más utilizada bajo Linux está licenciada bajo la GPL, es FreeS/WAN. La parte del núcleo de esta implementación se llama KLIPS. Se apoyan en particular:

  • intercambio dinámico de claves IKE usando el software de Plutón, que permite el uso de claves pre-compartidas así como certificados.
  • la protección de las conexiones de un guerrero de la carretera a una LAN, incluso si su dirección IP es asignada dinámicamente y está sujeta a cambios
  • la creación de túneles PPTP (lado del servidor), utilizando el software PoPToP
  • creación de túneles PPTP (lado del cliente), usando el software PPTP-linux
  • la creación de túneles L2TP, gracias al software l2tpd
  • la encriptación oportunista, que permite la protección de los datos intercambiados entre dos sistemas que antes eran totalmente ajenos (las claves públicas se intercambian entonces utilizando el DNS)

Los principales problemas conocidos al escribir este documento fueron:

  • KLIPS tiene una muy ligera pérdida de memoria…
  • Si se establecen varias conexiones entre dos puertas de seguridad, la compresión de cabecera debe activarse para todas o ninguna de estas conexiones.
  • El KLIPS no soporta los datagramas en los que están presentes las opciones de IP.

Finalmente, FreeS/WAN decodifica los paquetes IPsec antes de pasarlos al código del cortafuegos. Las reglas de firewalling pueden probar si los datagramas fueron enviados en texto claro o no.

7.3 – NetBSD

NetBSD utiliza KAME, una implementación IPsec (y más generalmente IPv6) bajo una licencia BSD. Preguntas frecuentes sobre IPsec para NetBSD. Apoyado son :

  • el uso simultáneo de IPsec en modo de túnel o transporte con IPv6, al menos para la versión actual de NetBSD
  • Configuración de cada uno de los enchufes (usando la llamada de sistema setsockopt(2))
  • creación de túneles IPsec utilizando los puertos pptp y pptp-server
  • un número casi ilimitado de CI anidados
  • intercambio dinámico de claves IKE, usando ya sea racoon, que puede trabajar con claves o certificados pre-compartidos, o isakmpd, que aún está en su etapa alfa, y también soporta ambos métodos

Los principales problemas conocidos al escribir este documento fueron:

  • Las claves asociadas con un AS establecido usando la llamada setsockopt(2) no pueden ser negociadas por mapache
  • el protocolo AH en modo túnel no funciona correctamente

Finalmente, cuando se usan KAME y el filtro IP juntos bajo NetBSD, los datagramas son procesados por el cortafuegos antes de ser decodificados por KAME.

7.4 – FreeBSD

FreeBSD también soporta KAME. El uso de IPsec en FreeBSD está documentado. Entre otras cosas, se apoyan las siguientes:

  • el uso simultáneo de IPsec en modo túnel o transporte con IPv6, al menos para la versión actual de FreeBSD
  • Creación de túneles PPTP (lado del cliente)
  • la creación de túneles PPTP (lado del servidor), utilizando el software PoPToP
  • la creación de túneles L2TP, gracias al software l2tpd (cuyo portado a FreeBSD está todavía en la fase alfa)
  • intercambio dinámico de claves IKE, usando racoon

7.5 – OpenBSD

Al igual que FreeBSD y NetBSD, OpenBSD usa KAME. La documentación para usar IPsec en OpenBSD. Apoyado son :

  • intercambio dinámico de claves ISAKMP utilizando el software isakmpd, que soporta el modo agresivo y el uso de certificados como claves precompartidas, y la creación de SAs con clientes de direcciones IP asignadas dinámicamente y variables, también se pueden utilizar foturis, pero todavía está en la fase alfa y poco documentado.
  • creación de túneles PPTP (lado del cliente), gracias al puerto pptp
  • la creación de túneles PPTP (lado del servidor), utilizando el software PoPToP
  • intercambio dinámico de claves según el estándar de Photuris, basado en el software de Photurisd

7.6 – Soluciones de hardware

Si es necesario mantener muchos SAs, debido a la alta carga de CPU asociada con la encriptación, puede ser necesario utilizar una de las muchas soluciones duras disponibles comercialmente (Redcreek, Timestep).

8 – Dificultades

Concluiremos este artículo con una advertencia: cuando se instalen VPNs usando IPsec, es fundamental comprender plenamente a qué se aplicará la protección. En efecto, es muy fácil cometer errores con consecuencias extremadamente graves. Por ejemplo, colocar una puerta de seguridad detrás de un cortafuegos y configurar el cortafuegos para que permita el paso de todo el tráfico IPsec implica una configuración cuidadosa de la puerta de seguridad para evitar que un atacante la utilice para eludir el cortafuegos. En particular, si esta puerta de enlace implementa la encriptación oportunista de la implementación de FreeS/WAN, el cortafuegos puede dejar de ser de utilidad. Por lo general se recomienda aplicar las reglas de cortafuegos tanto después como antes de los tratamientos IPsec (para dejar las cosas claras, una forma sencilla pero exorbitante de aplicar este consejo es colocar un primer cortafuegos antes de la pasarela de seguridad y un segundo después de ella).

Además, la codificación de los datos no debe crear la ilusión de seguridad, como lo ha hecho con demasiada frecuencia el SSL: la codificación no es una autenticación (un atacante puede muy bien entablar una conversación cifrada con una puerta de seguridad), y la autenticación del sistema que emite un datagrama utilizando el protocolo AH no es necesariamente suficiente para garantizar la seguridad: Si un administrador utiliza un protocolo que permite la autenticación en texto plano, como telnet, encapsulando los datos en datagramas protegidos por la TSA, un atacante podrá leer su contraseña, y si entonces es posible establecer conexiones no autenticadas utilizando IPsec con el sistema, entonces el sistema puede considerarse comprometido.

Estos dos ejemplos ilustran la complejidad de la aplicación de la IPsec. Esta complejidad difícilmente puede dar cabida a las llamadas soluciones mágicas, «llave en mano», que se pueden configurar con sólo unos pocos clics de ratón. IPsec es excesivamente complejo, y esconder esta complejidad detrás de interfaces gráficas que no llaman a las cosas por su nombre es tan peligroso como irresponsable (¿ya es hora de poner fin a la anarquía en el vocabulario de la ?-D?).

Categorías Red

Deja un comentario