Implementando un túnel IPsec

      Comentarios desactivados en Implementando un túnel IPsec

https://techlib.barracuda.com/attachments/image/6979952/ipsec_tunnel.jpg

Lo primero de todo, darle las gracias a I.G.B, porque sin saberlo me ha animado a escribir sobre este tema. ¡¡Gracias!! 🙂

La teoría de IPsec está bien definida en el conjunto de documentos RFC4301 y 4309, que vienen a actualizar y sustituir a los anteriores documentos RFC2401 y 2412, y que condicionan otro tanto de RFCs que definen el funcionamiento del intercambio de claves y el cifrado, como el RFC2406 al 2409 y los actualizados 4303 al 4308. Lo cierto es que la complejidad de lo que hoy es internet ha necesitado actualizar todas estas definiciones y dar soporte a algoritmos de cifrado más robustos así como mejorar mecanismos para evitar problemas de estabilidad y rupturas de cifrado.

Como las RFCs son bastante largas, podemos leer un buen resumen en la wiki acerca de IKE y de IPsec

De todas formas, IPsec es un protocolo criptográfico definido en un conjunto de RFCs que pretende otorgar los máximos niveles de seguridad posibles en la transmisión de datos y las comunicaciones IP, convirtiendose en una aplicación fundamental a la hora de realizar túneles VPN basados en la capa de red del modelo OSI. En definitiva, IPsec es un protocolo que cifra las comunicaciones IP de origen a fin.

IPsec puede ser utilizado en modo transporte mediante autenticación de cabeceras end-to-end (AH) o mediante un túnel que encapsula todo el tráfico Site-to-Site (ESP), siendo esta última la forma más segura (o robusta) de transmitir los datos durante todo el trayecto.

Para ello implementa una aplicación de tráfico cifrado a través del canal seguro que se ha establecido con el intercambio de claves IKE mediante sus fases (proposal 1, proposal 2). Hasta aquí, la teoría es muy bonita… pero es que la práctica lo es más.

En cualquier dispositivo que implemente IPsec, nos encontraremos con la definición de estas fases y según el soporte a la RFC que tengamos, podremos configurar unas cosas u otras. El problema es que cada fabricante monta un interfaz diferente a otro, y lo hace pensando en su público administrador, por lo que aunque en el fondo todos tengan que terminar entendiendose en cuanto a la RFC, cada uno lo muestra en pantalla diferente. Por tanto, voy a explicar qué cosas hemos de tener en cuenta a la hora de montar un túnel IPsec en cada una de sus fases, de forma que aunque no os hayais leido la RFC, con un poco de experiencia sepamos de qué hablamos.

Lo primero de todo, es que los dos dispositivos deben entender el mismo estándar (RFC). Esto es básico, e importante. Si no hablamos el mismo idioma nunca nos vamos a entender. Y para hablar este idioma necesitaremos comunicacion IP al puerto 500 UDP, y probablemente al 4500 UDP si hay NAT-T activo.

Proposal 1 o fase 1 (Fase de IKE o ISAKMP)

En esta fase se establece el canal seguro bidireccional SA (Security Association) mediante el intercambio de claves, que relacionamos con la fase IKE o ISAKMP (dependiendo de la versión de IKE… ojo) y donde hemos de definir para ella el siguiente conjunto de parámetros:

  • Modo: “Aggressive” o “Main”. La diferencia está en que el primero no cifra las identidades y el proceso es mucho más rápido, pero a su vez algo menos seguro. A veces es conveniente usar uno u otro en función de otros factores como NAT-T, por precisamente identidades, por lo que podría ser necesario especificar qué ID se acepta, o se envía (entiendase ID como la identidad IP). En algunos casos esto puede traer de cabeza a quien esté montando el túnel. Debe ser el mismo en ambos… o no nos entenderemos -salvo bug en contrario!.
  • Peer: el sitio remoto contra el que queremos comenzar la negociación y establecer el tunel. Se puede definir con un dns, pero en defintiva apuntará a una IP.
  • Hash: para la integridad del paquete, puede ser MD5 o SHA en sus diferentes evoluciones. Hemos de configurar el mismo en ambos extremos, y se pueden configurar varios, que se eligirá con el otro extremo en funcion de la prioridad del mismo.
  • Algoritmo de cifrado de la SA: Definiremos un algoritmo del tipo DES, 3DES o AES en sus diferentes evoluciones. Hemos de configurar el mismo en ambos extremos, y se pueden configurar varios, que se eligirá con el otro extremo en funcion de la prioridad del mismo.
  • Diffie-Hellman Group: Grupo de logaritmos con el que conseguiremos intercambiar la clave entre los dos “peers”, con la teórica convicción de que un intruso en medio no es capaz de enterarse de la clave. Sin este proceso, la clave podría ser descubierta puesto que para cifrar necesitamos que ambos extremos conozcan la clave. Tambien debe ser el mismo en ambos extremos
  • Preshared Key: La clave de secreto compartido que introduciremos en ambos extremos para iniciar el intercambio descrito en toda esta proposal
  • NAT-T: especificaremos si el canal de comunicacion atraviesa NAT en algún punto intermedio.
  • Lifetime: el tiempo en segundos o cantidad de bits para que la SA muera y deba volver a negociarse

Si todo está correcto, es decir, que en ambos extremos vamos a hablar lo mismo y hemos configurado lo que vamos a hablar, se establecerá la SA y dará paso a la segunda fase.

Proposal 2 o fase 2 (Fase IPSec)

Esta fase forma parte de IKE en sí mismo, pero para ofrecer todas las SA de cara al cifrado de los datos, y que conocemos como IPsec en sí mismo. En esta fase se va a producir una SA por cada canal seguro que deba cifrarse por lo que cumpliendo con un estándar básico de transmisión y recepción, en un caso bidireccional tendríamos al menos dos SA.

Cabe decir, que dentro de este canal seguro de la fase 1 podemos introducir tantas SA de la fase 2 como queramos y que generalmente nos limitará nuestro hardware (o software…).

Los parámetros a tener en cuenta:

  • Hash: Definiremos como en la fase 1 un hash para la integridad del paquete, puede ser MD5 o SHA en sus diferentes evoluciones. No tiene por qué ser el mismo que la fase 1, se trata de otra SA. Pero si debe ser el mismo en ambos extremos, y se pueden configurar varios que se elegiran en base a la prioridad de los mismos
  • Algoritmo de cifrado de la SA: Al igual que con el Hash, definiremos un algoritmo del tipo DES, 3DES o AES en sus diferentes evoluciones, para cifrar los datos que forman parte de nuestra comunicación. Su configuración sigue los mismos patrones que el hash, no tiene por qué ser el mismo que en fase 1 pero sí el mismo en ambos extremos.
  • (Opcional) PFS – Diffie-Hellman Group: Si elegimos esta opción, se producirá un nuevo intercambio de claves que esta vez no hemos definido, con el fin de ofrecer una comunicación más segura si por un casual, un hacker consiguiera la PSK y capturase tráfico, y pudiera romper los algoritmos con la clave simétrica. Debe ser el mismo en ambos extremos
  • Redes cifradas: En base a que la SA es unidireccional, se debe elegir el origen y el extremo y estas coincidir de forma inversa en ambos extremos. En algunos casos los identificaremos como “proxy id”
  • Lifetime: Al igual que en la fase 1, estas SA necesitan tener un tiempo en el que se renegociarán los canales.

Por tanto, los parámetros a configurar son bastantes y en algunos casos parecen los mismos, pero cada fase tiene sus requisitos. Recordad que la PSK, y los peers, forman parte de la fase 1, mientras que PFS y las redes a cifrar forman parte de la fase 2.

¿Y si no se monta el túnel después de esto?… pues hagamos debug a ver donde está fallando. Lo vemos en el proximo post.