7.1. Introducción al intercambio manual de claves

IPSEC es un tema complicado. Hay mucha información en la red, pero este COMO se concentrará en enseñarle a ponerlo a funcionar y explicar los principios básicos. Todos los ejemplos están basados en Racoon, que encontrará en el enlace anterior.

IPSEC ofrece una versión segura del Internet Protocol. La seguridad en este contexto significa dos cosas diferentes: cifrado y autentificación. Una visión inocente de la seguridad ofrece sólo cifrado, pero es sencillo demostrar que esto es insuficiente: puedes estar comunicándote de forma cifrada, pero no hay garantías de que en el otro extremo esté quien tú esperas.

IPSEC admite "Encapsulated Security Payload" (ESP) para el cifrado y "Authentication Header" (AH) para autentificar al otro extremo. Puede configurarlos ambos, o decidir usar sólo uno.

Tanto ESP como AH dependen de asociaciones de seguridad (security associations). Una asociación de seguridad (SA) consiste en origen, destino y una instrucción. Un ejemplo de autentificación por SA podría ser así:

	  add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
	

Esto significa «el tráfico que va de 10.0.0.11 a 10.0.0.216 que necesita AH puede ser firmado usando HMAC-MD5 usando la clave 1234567890123456». Esta instrucción va etiquetada con el identificador SPI ("Security Parameter Index") "15700", hablaremos de ello más adelante. La parte interesante sobre los SA es que son simétricos. Ambos extremos de una conversación comparten exactamente el mismo SA; en el otro extremo no encontraremos una copia especular. Tenga en cuenta sin embargo que no hay una regla "autoreverse": esta SA sólo describe una autentificación posible desde 10.0.0.11 a 10.0.0.216. Para tener tráfico en las dos direcciones, hacen falta dos SA.

Un ejemplo de SA ESP:

add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
	

Aquí dice que «el tráfico que va de 10.0.0.11 a 10.0.0.216 que necesita cifrado puede serlo usando 3des-cbc con la clave 123456789012123456789012». El identificador SPI es "15701".

Hasta ahora, hemos visto que las SA describen instrucciones posibles, pero en realidad no describen normas sobre cuándo se deben usar. En realidad, podría haber un número arbitrario de SA idénticas que sólo difiriesen en sus id SPI. Casualmente, SPI significa Security Parameter Index. Para hacer cifrado realmente, necesitamos describir una norma (policy). Esta norma puede incluir cosas como «usa ipsec si está disponible» o «corta el tráfico a menos que haya ipsec».

Una Security Policy (SP) típica podría parecerse a esto:

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
   esp/transport//require
   ah/transport//require;
	

Si se introduce en el sistema 10.0.0.216, esto quiere decir que todo el tráfico que vaya hacia 10.0.0.11 debe ir cifrado y encapsulado en una cabecera de autentificación AH. Fíjese que no se indica qué SA ha de usarse; determinar esto se deja como ejercicio para el núcleo.

En otras palabras, una Security Policy (norma de seguridad) especifica QUE queremos; mientras que una Security Association describe COMO lo queremos.

Los paquetes salientes son etiquetados con el SA SPI ("el cómo") que el núcleo use para cifrado y autentificación, de manera que el otro extremo pueda buscar la instrucción de verificación y decodificación correspondiente.

Lo que sigue es una configuración muy simple para hablar desde la máquina 10.0.0.216 con la 10.0.0.11 usando cifrado y autentificación. Fíjese que el camino inverso (reverse path) es texto plano en esta primera versión, de manera que no debería usar esta configuración en producción.

En la máquina 10.0.0.216:

#!/sbin/setkey -f
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
   esp/transport//require
   ah/transport//require;
	

En la máquina 10.0.0.11, las mismas Security Association, sin Security Policy:

#!/sbin/setkey -f
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";
	

Con esta configuración (puede ejecutar los ficheros si tiene "setkey" en /sbin), "ping 10.0.0.11" desde 10.0.0.216 debería dar resultados similares a este usando tcpdump:

22:37:52 10.0.0.216 > 10.0.0.11: AH(spi=0x00005fb4,seq=0xa): ESP(spi=0x00005fb5,seq=0xa) (DF)
22:37:52 10.0.0.11 > 10.0.0.216: icmp: echo reply
	

Fíjese en cómo el ping que vuelve de 10.0.0.11 es de hecho visible claramente. El ping inicial no lo puede leer tcpdump por supuesto, pero muestra el Security Parameter Index de AH y ESP, que le dice a 10.0.0.11 cómo verificar la autenticidad de nuestro paquete y cómo descrifrarlo.

De todas maneras, hay que mencionar algunas cosas. La configuración anterior aparece en muchos ejemplos de IPSEC y es muy peligrosa. El problema es que lo anterior contiene normas sobre cómo debería tratar 10.0.0.216 los paquetes que van a 10.0.0.11, y explica cómo debería tratar 10.0.0.11 estos paquetes, ¡pero NO indica a 10.0.0.11 que descarte tráfico sin autentificar o cifrar!

Cualquiera puede ahora insertar datos falsos y completamente sin cifrar y 10.0.0.11 los aceptará. Para remediarlo, necesitamos una norma de tráfico entrante para 10.0.0.11, como sigue:

#!/sbin/setkey -f
spdadd 10.0.0.216 10.0.0.11 any -P IN ipsec
   esp/transport//require
   ah/transport//require;
	

Esto le dice a 10.0.0.11 que cualquier tráfico que venga de 10.0.0.216 debe tener ESP y AH válidos.

Ahora, para completar esta configuración, necesitamos que el tráfico devuelto sea también cifrado y autentificado, por supuesto. La configuración completa en 10.0.0.216:

#!/sbin/setkey -f
flush;
spdflush;

# AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";

# ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
           esp/transport//require
           ah/transport//require;

spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
           esp/transport//require
           ah/transport//require;

	

Y en 10.0.0.11:

#!/sbin/setkey -f
flush;
spdflush;

# AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";

# ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";


spdadd 10.0.0.11 10.0.0.216 any -P out ipsec
           esp/transport//require
           ah/transport//require;

spdadd 10.0.0.216 10.0.0.11 any -P in ipsec
           esp/transport//require
           ah/transport//require;

	

Fíjese que en este ejemplo hemos usado claves idénticas para ambas direcciones de tráfico. Sin embargo, esto no es necesario.

Para comprobar la configuración que hemos creado, ejecute setkey -D, que muestra las asociaciones de seguridad, o setkey -DP que muestra las normas configuradas.