Núcleo Linux 2.5/2.6 empleando herramientas KAME

Modo transporte

Esta sección tratará el establecimiento de una conexión en modo transporte con difusión manual de claves. Esta es, probablemente, la mejor manera de empezar, ya que es la conexión más simple que se puede establecer. Esta sección asume que dos máquinas con direcciones IP 192.168.1.100 y 192.168.2.100 se comunican empleando IPsec.

Todos los parámetros almacenados en las SAD y SPD pueden modificarse empleando el mandato setkey. Este mandato tiene una página de manual muy completa. Sólo indicaremos aquí las opciones necesarias para el establecimiento de una conexión en modo transporte. setkey lee órdenes de un fichero cuando se invoca con setkey -f /etc/ipsec.conf. A continuación se muestra un fichero /etc/ipsec.conf adecuado:

#!/usr/sbin/setkey -f

# Configuración for 192.168.1.100

# Vaciar las SAD y SPD
flush;
spdflush;

# Atención: Emplee estas claves sólo para pruebas
# ¡Debería generar sus propias claves!

# SAs para AH empleando claves largas de 128 bits
add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5 \
0xc0291ff014dccdd03874d9e8e4cdf3e6;
add 192.168.2.100 192.168.1.100 ah 0x300 -A hmac-md5 \
0x96358c90783bbfa3d7b196ceabe0536b;

# SAs para ESP empleando claves largas de 192 bits (168 + 24 paridad)
add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc \
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
add 192.168.2.100 192.168.1.100 esp 0x301 -E 3des-cbc \
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;

# Políticas de seguridad
spdadd 192.168.1.100 192.168.2.100 any -P out ipsec
           esp/transport//require
           ah/transport//require;

spdadd 192.168.2.100 192.168.1.100 any -P in ipsec
           esp/transport//require
           ah/transport//require;
	

Si desea emplear conexiones con difusión manual de claves fuera del entorno de pruebas, necesitará claves para reemplazar las proporcionadas en este script. Emplee las siguientes órdenes para generar sus claves:

$ # Claves largas de 128 bits
$ dd if=/dev/random count=16 bs=1| xxd -ps
16+0 Records ein
16+0 Records aus
cd0456eff95c5529ea9e918043e19cbe

$ # Claves largas de 192 bits
$ dd if=/dev/random count=24 bs=1| xxd -ps
24+0 Records ein
24+0 Records aus
9d6c4a8275ab12fbfdcaf01f0ba9dcfb5f424c878e97f888
	

Emplee el dispositivo /dev/random al generar las claves ya que asegura claves aleatorias.

El script primero limpia la base de datos de asociaciones de seguridad (SAD) y la base de datos de políticas de seguridad (SPD). Después crea las SAs AH y ESP. El mandato add añade una asociación de seguridad a la SAD y requiere las direcciones IP de origen y destino, el protocolo IPsec (ah), el SPI (0x200) y el algoritmo. El algoritmo de autenticación se especifica con -A (el de cifrado con -E, el de compresión con -C; la compresión IP aún no está soportada). Tras el algoritmo se especifica la clave. Puede estar formateada en ASCII encerrado entre comillas dobles, o en hexadecimal con el prefijo 0x.

Linux da soporte a los siguientes algortmos para AH y ESP: hmac-md5 y hmac-sha, des-cbc y 3des-cbc. En un plazo breve de tiempo, probablemente los siguientes algoritmos serán soportados: simple (sin cifrado), blowfish-cbc, aes-cbc, hmac-sha2-256 y hmac-sha2-512.

spdadd añade políticas de seguridad a la SPD. Estas políticas definen qué paquetes se protegerán con IPsec y qué protocolos y claves emplear. El mandato requiere las direcciones IP origen y destino de los paquetes a proteger, el protocolo (y puerto) a proteger (any) y la política a emplear (-P). La política especifica la dirección (in/out), la acción a aplicar (ipsec/discard/none), el protocolo (ah/esp/ipcomp), el modo (transport) y el nivel (use/require).

Este fichero de configuración debe crearse en los dos extremos que formarán parte de la comunicación IPsec. Mientras que el listado mostrado funciona sin ningún cambio en el sistema 192.168.1.100, deberá modificarse ligeramente en 192.168.2.100 para reflejar el cambio de dirección de los paquetes. La manera más sencilla de hacer esto es intercambiar las diercciones en las políticas de seguridad: reemplazar -P in por -P out y viceversa. El resultado se muestra a continuación:

#!/usr/sbin/setkey -f

# Configuración para 192.168.2.100

# Vaciar las SAD y SPD
flush;
spdflush;

# Atención: Emplee estas claves sólo para pruebas
# ¡Debería generar sus propias claves!

# SAs para AH empleando claves largas de 128 bits
add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5 \
0xc0291ff014dccdd03874d9e8e4cdf3e6;
add 192.168.2.100 192.168.1.100 ah 0x300 -A hmac-md5 \
0x96358c90783bbfa3d7b196ceabe0536b;

# SAs para ESP empleando claves largas de 192 bits (168 + 24 paridad)
add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc \
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
add 192.168.2.100 192.168.1.100 esp 0x301 -E 3des-cbc \
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;

# Políticas de seguridad
spdadd 192.168.1.100 192.168.2.100 any -P in ipsec
           esp/transport//require
           ah/transport//require;

spdadd 192.168.2.100 192.168.1.100 any -P out ipsec
           esp/transport//require
           ah/transport//require;
	

Una vez que el fichero de configuración esté preparado en cada uno de los extremos de la comunicación, puede cargarse empleando setkey -f /etc/ipsec.conf. Para comprobar el funcionamiento, puede mostrar la SAD y la SPD:

# setkey -D
# setkey -DP
	  

La configuración ahora será similar a la de Figure 4.

Si hace ping de una máquina a la otra el tráfico se cifrará y tcpdump mostrará los siguientes paquetes:

12:45:39.373005 192.168.1.100 > 192.168.2.100: AH(spi=0x00000200,seq=0x1): 
ESP(spi=0x00000201,seq=0x1) (DF)
12:45:39.448636 192.168.2.100 > 192.168.1.100: AH(spi=0x00000300,seq=0x1): 
ESP(spi=0x00000301,seq=0x1)
12:45:40.542430 192.168.1.100 > 192.168.2.100: AH(spi=0x00000200,seq=0x2): 
ESP(spi=0x00000201,seq=0x2) (DF)
12:45:40.569414 192.168.2.100 > 192.168.1.100: AH(spi=0x00000300,seq=0x2): 
ESP(spi=0x00000301,seq=0x2)
	

Modo túnel

El modo túnel se emplea cuando los dos pares que utilizan IPsec funcionan como un gateway y protegen el tráfico entre dos redes (Figure 5). Los paquetes IP originales se cifran y encapsulan en un gateway y se transmiten al otro extremo del tunel. Allí se desencapsulan y se tratan los paquetes originales sin protección.

La configuración de las asociaciones de seguridad y políticas para el modo túnel es similar a la del modo transporte y se muestra en el siguiente listado.

#!/usr/sbin/setkey -f

# Vaciar las SAD y SPD
flush;
spdflush;

# SAs para ESP realizando cifrado con claves largas de 192 bit (168 + 24 paridad)
# y autenticación empleando claves largas de 128 bits
add 192.168.1.100 192.168.2.100 esp 0x201 -m tunnel -E 3des-cbc \
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831 \
-A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;

add 192.168.2.100 192.168.1.100 esp 0x301 -m tunnel -E 3des-cbc \
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df \
-A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b;

# Políticas de seguridad
spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec
           esp/tunnel/192.168.1.100-192.168.2.100/require;

spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec
           esp/tunnel/192.168.2.100-192.168.1.100/require;
	

Este ejemplo sólo emplea el protocolo ESP. El protocolo ESP asegura integridad y confidencialidad. En este caso el orden de los algoritmos ESP es importante. Primero se necesita definir el algoritmo de cifrado y su clave, y después el algoritmo de autenticación y su clave.

Al contrario que en la implementación de IPsec de BSD, una asociación de seguridad en Linux sólo puede usarse para modo transporte o túnel. El modo transporte es el modo predeterminado, por lo que cuando se desee modo túnel, la asociación de seguridad deberá definirse mediante -m tunnel.

Las políticas de seguridad ahora especifican las direcciones IP de las redes protegidas. Los paquetes que empleen estas direcciones IP de origen y destino se cifrarán mediante IPsec. Cuando el modo túnel se usa, la política de seguridad debe especificar tunnel y las direcciones IP de los pares que implementan la protección. Esta información es necesaria para localizar las IPsec SA adecuadas.

Claves compartidas con anterioridad

La manera más sencilla para realizar la autenticación mediante racoon es emplear claves precompartidas. Estas claves deben definirse en un fichero /etc/psk.txt. Este fichero no debería ser leído por usuarios sin privilegios (chmod 400 /etc/psk.txt) y tiene la siguiente sintaxis:

# Direcciones IPv4
192.168.2.100          clave precompartida simple
5.0.0.1                0xe10bd52b0529b54aac97db63462850f3
# USER_FQDN
ralf@spenneberg.net    Esta es una clave precompartida para una dirección de correo
# FQDN
www.spenneberg.net     Esta es una clave precompartida
	

El fichero se organiza en columnas. La primera columna almacena la identidad del contrario autenticado por la clave precompartida. Cualquier cosa que comience en la segunda columna es la clave precompartida.

La configuración de racoon es muy sencilla. El siguiente listado muestra un fichero de configuración /etc/racoon.conf típico:

path pre_shared_key "/etc/psk.txt";

remote 192.168.2.100 {
        exchange_mode main;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                dh_group modp1024;
        }
}

sainfo address 172.16.1.0/24 any address 172.16.2.0/24 any {
        pfs_group modp768;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}
	

Este fichero de configuración define primero el lugar donde racoon puede encontrar las claves precompartidas. Después define un miembro de la comunicación 192.168.2.100 y los parámetros a usar en la fase uno de la negociación IKE. El segundo párrafo especifica los parámetros que pueden emplearse para el establecimiento de asociaciones de seguridad. Esta definición puede ser específica para ciertas direcciones IP, o puede ser general si se emplea anonymous en lugar de las direcciones IP. En este punto se definen los algoritmos de cifrado, autenticación y compresión para la SA. Se deben definir los tres para evitar un error durante el lanzamiento de racoon.

El servidor IKE racoon no inicia la negociación del túnel de manera inmediata al iniciarse. racoon espera a que se necesite emplear el túnel. Para que esta notificación se lleve a cabo, el núcleo necesita saber cuándo debe realizarse. Para ello, el administrador necesita definir políticas de seguridad sin las asociaciones de seguridad apropiadas. En el momento en que el núcleo Linux necesite proteger un paquete según las políticas de seguridad definidas, y no exista ninguna asociación de seguridad disponible, el núcleo Linux llamará a racoon y solicitará las asociaciones de seguridad adecuadas. Raccon iniciará en ese momento las negociaciones IKE que concluirán con la creación de las SAs. Tras esto, el núcleo Linux podrá enviar los paquetes.

Así, para la configuración indicada se necesitarán definir las siguientes políticas en 192.168.1.100:

#!/usr/sbin/setkey -f
#
# Vaciar SAD y SPD
flush;
spdflush;

# Crear políticas para racoon
spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec
           esp/tunnel/192.168.1.100-192.168.2.100/require;

spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec
           esp/tunnel/192.168.2.100-192.168.1.100/require;
	

Una vez que las políticas se carguen empleando la orden setkey-f /etc/ipsec.conf, se podrá lanzar racoon. Mientras se realicen pruebas, racoon debería lanzarse mediante racoon -F -c /etc/racoon.conf. La configuración del otro extremo de la comunicación deberá modificarse para reflejar el sentido inverso. Las direcciones IP de los ficheros /etc/psk.txt, /etc/ipsec.conf y /etc/racoon.conf deberán intercambiarse.

Se puede seguir el proceso de inicialización del tunel a través de los ficheros de registro (logs) del sistema:

2003-02-21 18:11:17: INFO: main.c:170:main(): @(#)racoon 20001216 20001216
 sakane@kame.net
2003-02-21 18:11:17: INFO: main.c:171:main(): @(#)This product linked Open
SSL 0.9.6b [engine] 9 Jul 2001 (http://www.openssl.org/)
2003-02-21 18:11:17: INFO: isakmp.c:1365:isakmp_open(): 127.0.0.1[500] use
d as isakmp port (fd=7)
2003-02-21 18:11:17: INFO: isakmp.c:1365:isakmp_open(): 192.168.1.100[500]
 used as isakmp port (fd=9)
2003-02-21 18:11:37: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA r
equest for 192.168.2.100 queued due to no phase1 found.
2003-02-21 18:11:37: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new 
phase 1 negotiation: 192.168.1.100[500]<=>192.168.2.100[500]
2003-02-21 18:11:37: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Identit
y Protection mode.
2003-02-21 18:11:37: INFO: vendorid.c:128:check_vendorid(): received Vendor
 ID: KAME/racoon
2003-02-21 18:11:37: INFO: vendorid.c:128:check_vendorid(): received Vendor
 ID: KAME/racoon
2003-02-21 18:11:38: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA es
tablished 192.168.1.100[500]-192.168.2.100[500] spi:6a01ea039be7bac2:bd288f
f60eed54d0
2003-02-21 18:11:39: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new p
hase 2 negotiation: 192.168.1.100[0]<=>192.168.2.100[0]
2003-02-21 18:11:39: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA establish
ed: ESP/Tunnel 192.168.2.100->192.168.1.100 spi=68291959(0x4120d77)
2003-02-21 18:11:39: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established:
 ESP/Tunnel 192.168.1.100->192.168.2.100 spi=223693870(0xd554c2e)
	

Certificados X.509

Racoon permite emplear certificados X.509 en el proceso de autenticación. Estos certificados pueden comprobarse contra una autoridad de certificación. La configuración es similar a la empleada con claves precompartidas y se diferencia sólo en la parte de autenticación:

path certificate "/etc/certs";

remote 192.168.2.100 {
        exchange_mode main;
        certificate_type x509 "mi_certificado.pem" "mi_clave_privada.pem";
	verify_cert on
        my_identifier asn1dn;
	peers_identifier asn1dn;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method rsasig;
                dh_group modp1024;
        }
}

sainfo address 172.16.1.0/24 any address 172.16.2.0/24 any {
        pfs_group modp768;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}
	

El certificado y la clave privada se almacenan en la ruta de ciertificados /etc/certs. Esta ruta se establece mediante la opción path certificate dentro del fichero de configuración. Los certificados y listas de revocación de certificados se almacenan en formato PEM tal y como se generan con openssl. Para la generación de certificados lea el capítulo acerca de certificados X.509. Si el certificado del otro extremo va a comprobarse contra una autoridad de certificación (verify_cert on es la opción predeterminada), el certificado de la autoridad de certificación también deberá almacenarse en este directorio. Para que OpenSSL encuentre el certificado, éste deberá ser renombrado o enlazado empleando un nombre específico calculado a partir del propio certificado:

ln -s CAfile.pem `openssl x509 -noout -hash < CAfile.pem`.0
	

Si el certificado debe ser comprobado frente a una fichero de revocación de certificados (CRL), éste deberá almacenarse en el mismo directorio empleando un nombre calculado de manera similar:

ln -s CRLfile.pem `openssl crl -noout -hash < CAfile.pem`.r0
	

Al almacenar los certificados y la clave privada, es importante darse cuenta de que racoon no puede descifrar una clave privada. Por lo tanto, la clave privada deberá almacenarse en texto claro sin cifrar. Si creó una clave privada cifrada, deberá descrifrarla:

# openssl rsa -in my_private_key.pem -out my_private_key.pem
read RSA key
Enter PEM pass phrase: password
writing RSA key
	

Roadwarrior

Los roadwarriors son clientes que emplean direcciones IP dinámicas desconocidas para conectarse con la pasarela de la VPN. Estos clientes suponen dos problemas para racoon:

• La dirección IP no se conoce, y por lo tanto no puede especificarse en el fichero de configuración de racoon ni en el fichero /etc/psk.txt. Por este motivo se deberá emplear una manera distinta de determinar la identidad del cliente. ¡Emplear claves precompartidas requiere el uso del modo agresivo! La mejor solución es emplear certificados X.509.

• No puede crearse ninguna política de seguridad sobre la que actúe racoon, ya que la dirección IP de destino no se conoce. racoon debe crear la política de seguridad y la asociación de seguridad mientras se inicia la conexión.

Para alcanzar estos objetivos, el fichero de configuración /etc/racoon.conf necesita ser objeto de varias modificaciones:

path certificate "/etc/certs";

remote anonymous {
        exchange_mode main;
        generate_policy on;
        passive on;
        certificate_type x509 "mi_certificado.pem" "mi_clave_privada.pem";
        my_identifier asn1dn;
        peers_identifier asn1dn;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method rsasig;
                dh_group modp1024;
        }
}


sainfo anonymous {
        pfs_group modp1024;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}
	

La opción generate_policy on ordena a racoon crear la política apropiada cuando se inicie una nueva conexión. La opción passive on indica a racoon que debe permanecer pasivo y esperar a que una nueva conexión se inicie desde fuera. racoon no puede iniciar una conexión.

El cambio más importante, sin embargo, es la definición de anonymous en las líneas remote y sainfo. Esto indica a racoon que acepte conexiones desde cualquier lugar.