Cifrado punto a punto y punto multipunto utilizando IPSec Versión 1.2

Temas Introducción............................................................................... 1

Protocolos............................................................................... 1 Instalación................................................................................. 5

GNU/Linux .............................................................................. 5 Windows XP............................................................................. 6

Configuración ............................................................................. 7 Punto a Punto .......................................................................... 9 LAN a LAN.............................................................................. 34 Cliente Remoto (Road Warrior) .................................................... 35

Consideraciones de Seguridad y Compatibilidad ................................... 54 Alternativas .............................................................................. 55 Trabajo por hacer ....................................................................... 56 Bibliografía ............................................................................... 56

Introducción En este documento seguiremos paso a paso las configuraciones necesarias para cifrar el contenido de las comunicaciones entre dos equipos conectados a Internet. Tomaremos en cuenta tres escenarios, que se detallarán más adelante: el de dos equipos que quieren cifrar todo el tráfico que hay entre ellos, el cifrado del tráfico entre dos redes privadas, y el de un usuario remoto que debe conectarse a una red de nuestra organización. Se describirán las configuraciones para el sistema operativo GNU/Linux, para el primer y segundo esquema como uno de los extremos, y para el tercero como la “Puerta de entrada” a nuestra red. Todos los ejemplos estarán basados en la distribución Debian, versión Sarge (o Stable), con Kernel versíon 2.6. Para el restante extremo, utilizaremos Windows XP. De todas maneras, la mayoría de los pasos también podrán ser seguidos sin modificaciones en Windows 2000. Pero primero, veamos un poco de qué se trata IPSec.

Protocolos

IPsec El cifrado que abordaremos en este documento se basa en el protocolo IPSec, que consiste en la “reimplementación” para IPV4 de las medidas de seguridad originalmente diseñadas para IPV6. IPSec define los siguientes protocolos:

1

AH Authentication Header, consiste en incluir en los paquetes enviados una “firma” o hash que permitirá verificar su autenticidad, sin modificar el paquete original (salvo el agregado de la “firma”). De la misma manera que el protocolo TCP se designa con el número 6, y UDP con el 17, este protocolo utiliza el número de protocolo IP 51 para ser identificado. Existen dos modos de conformar un paquete AH: el modo transporte y el modo túnel. Estos modos serán explicados más adelante dentro del protocolo ESP.

Figura 1- Conformación de un paquete AH en modo transporte

...Proto=TCPIP origenIP destino

IP Header IP PayloadTCP Header TCP Payload

Datos...Port origenPort destino

Paquete IP/TCP original

...Proto=AHIP origenIP destino

Datos...Port origenPort destino

...Next=TCPFirma

Paquete AHTCP Header TCP Payload

IP Header IP PayloadAH

ESP Encapsutaled Security Payload, que servirá para cifrar todo el contenido de los paquetes IP (salvo su IP origen y destino, por razones que dejamos a la imaginación del lector), además de poder verificar su autenticidad. A su vez, este protocolo, posee dos modos principales de operación: El modo transporte, donde simplemente es cifrado el contenido de los paquetes que intercambian dos extremos, y el modo túnel, donde un paquete IP es encapsulado dentro de otro, creando lo que normalmente se conoce como un túnel (Por ejemplo, utilizando los protocolos IPIP o GRE). Usualmente el modo transporte es utilizado para el cifrado de paquetes entre dos equipos, y el modo túnel entre dos redes. El protocolo ESP utiliza el número de protocolo IP 50. Tanto AH como ESP son Estándares de Internet, publicados en las RFC 2402 y 2406 respectivamente.

2

Figura 2 - Conformación de un paquete ESP en modo transporte

...Proto=TCPIP origenIP destino

IP Header IP PayloadTCP Header TCP Payload

Datos...Port origenPort destino

Paquete IP/TCP original

Paquete ESP TransporteTCP Header TCP Payload

IP Header IP PayloadESP

ESP Data...

...Proto=ESPIP origenIP destino

Datos...Port origenPort destino Next=TCP

ESP Data...

:cifrado

Figura 3 - Conformación de un paquete ESP en modo túnel

...Proto=TCPIP origenIP destino

IP Header IP PayloadTCP Header TCP Payload

Datos...Port origenPort destino

Paquete IP/TCP original

Paquete ESP TúnelIP Header IP Payload

IP Header IP PayloadESP

ESP Data...

...Proto=ESPNuevo IP origenNuevo IP destino

Datos...Port origenPort destino Next=IP

ESP Data...

:cifrado

...Proto=TCPIP origenIP destino

IKE Internet Key Exchange es el protocolo utilizado para negociar, en una primera fase, la autenticación de los extremos. Esta etapa soporta diversos mecanismos de autenticación; por ejemplo claves compartidas y certificados X.509, que son los que utilizaremos. A su vez, soporta dos diferentes modos de inicialización: el modo main, y el modo aggressive. Este último tiene la

3

ventaja de ser mucho más eficiente en velocidad y tráfico, pero tiene la desventaja de ser vulnerable a ataques del tipo “man in the middle” cuando se utiliza junto con claves compartidas. En una segunda etapa, se negocian los protocolos de cifrado y autenticación y las respectivas claves que se utilizarán durante la transmisión de datos. En estas dos etapas del protocolo IKE, ambos extremos utilizan el puerto 500/UDP para comunicarse entre sí.

Nat-T Originalmente IPSec no fue pensado para convivir con NAT. Es por ello que posteriormente se definió el protocolo Nat-T, o Nat-Trasversal. Este protocolo, que recientemente pasó de la etapa de “Proponed Standard” a “Internet Standard” (bajo las RFC 3947 y 3948), facilita la convivencia de IPSec con la traducción de direcciones.

L2TP “Layer 2 Tunnel Protocol” es un protocolo definido como Estándar de Internet en la RFC 2661. Su trabajo es encapsular frames de un protocolo de capa 2 (ISO/OSI), para ser transportados a través de una red de conmutación de paquetes (por ejemplo, TCP/IP). En particular, se encapsularán frames PPP (Point to Point Protocol, habitualmente utilizado en las conexiones seriales, por ejemplo en un dial-up), y se transportarán entre los extremos del túnel mediante el protocolo UDP. El extremo definido como servidor, o concentrador de túneles, utilizará el puerto 1701 para enviar y recibir paquetes UDP. En la Figura 4 puede verse una esquematización del encapsulamiento (los encapsulamientos en realidad) realizado.

Figura 4 - Encapsulamiento utilizando L2TP

IP Header IP Payload

...Proto=XXIP origenIP destino

Datos (UDP, TCP, ICMP, etc.)

Paquete IP/TCP original

Paquete IP encapsulado

...Proto=UDPIP origenIP destino (Túnel)

Paquete IP...Port origenPort destino

...L2TPData

...PPPData

UDP Head UDP PayloadIP Header IP Payload

Paquete IP original

4

Instalación GNU/Linux Como mencionamos previamente, la presente guía se basa en dos condiciones:

1. Kernel 2.6 de Linux. 2. Distribución Debian Sarge.

Comenzaremos con la instalación de los paquetes necesarios para controlar las funciones de IPSec del Kernel. En este caso utilizamos el software racoon, acompañado automáticamente por el paquete ipsec tools: vpnserver:~# apt-get install racoon De los dos modos de instalación disponibles, seleccionamos racoon-tool (Figura 6).

5

Figura 5 - Configuración de Racoon

Figura 6 – Selección del modo de configuración de Racoon

De esta manera, ya se encuentra instalado todo el software necesario para realizar nuestra configuración de túneles.

Windows XP Windows XP ya tiene instalado todo el software necesario para la configuración de túneles IPSec, por lo que nos limitaremos a verificar que el servicio que controla dicha funcionalidad se esté ejecutando. Para ello,

6

dentro de Panel de Control, Herramientas Administrativas, Servicios, nos aseguramos que el servico IPSec esté configurado para arrancar de manera automática (Figura 7).

Figura 7 – Servicio IPSec

Configuración Vamos a revisar los tres esquemas más comunes de realización de túneles. En el primero de ellos, utilizaremos cifrado IPSec entre todos los paquetes IP que intercambien dos equipos (Figura 8). Para ello utilizaremos el protocolo ESP de IPSec, en el modo transporte. Para este caso revisaremos la configuración de los extremos tanto utilizando GNU/Linux como Windows. Estas combinaciones son intercambiables, y servirán tanto para utilizarse combinadas, como con ambos extremos utilizando el mismo sistema operativo.

7

Figura 8 - Cifrado Punto a Punto

En el segundo esquema, interconectaremos dos redes, y todo el tráfico cruzado entre ellas será cifrado. En este caso también se utilizará ESP, pero esta vez en modo tunnel. Ambos extremos utilizarán GNU/Linux.

Figura 9 - Cifrado LAN a LAN

Por último, realizaremos una conexión remota a una red privada. En este caso utilizaremos un “Tunnel”, en donde un equipo corriendo Windows XP realizará una conexión remota a una red privada, accediendo a ésta mediante un “gateway” o “concentrador de túneles” con el uso de GNU/Linux (Figura 10).

8

Figura 10 - Usuario Remoto

Punto a Punto

GNU/Linux Comenzaremos por configurar un extremo de la comunicación cifrada utilizando GNU/Linux. El extremo a configurar será el Extremo A mencionado en la Figura 8. Comenzaremos con editar el archivo /etc/racoon/racoon-tool.conf: vpnserver:~# cd /etc/racoon vpnserver:/etc/racoon# vi racoon-tool.conf

peer(200.5.6.7): exchange_mode: main hash_algorithm[0]: sha1 encryption_algorithm[0]: 3des authentication_method[0]: pre_shared_key connection(linux-winxp): src_ip: 200.2.3.4 dst_ip: 200.5.6.7 admin_status: enabled authentication_algorithm: hmac_sha1 encryption_algorithm: 3des pfs_group: modp1024

De esta manera hemos definido las siguientes propiedades para el cifrado entre los extremos A y B: Modo de Inicio de Sesión IPSec: main. Este modo es preferible a la alternativa aggressive debido a la forma insegura en la que se eligen las claves de sesión en este último. Algoritmos triple DES y SHA-1 Método de autenticación: clave compartida Utilización de PFS1.

1 PFS: Perfect Forward Secrecy. Esta propiedad asegura que las claves IPSec utilizadas no son derivadas de ninguna otra clave. Esto asegurará que si alguien logra vulnerar una clave, no podrá utilizarla para descifrar el contenido de ninguna otra asociación IPSec.

9

Sólo resta configurar la clave que compartirán ambos extremos para reconocerse entre sí: vpnserver:/etc/racoon# vi psk.txt

200.5.6.7 La elección de esta clave debe ser especialmente cuidadosa. Una mala elección puede causar que la seguridad no sea efectiva.

La primera cadena de texto que aparezca en cada línea corresponderá al identificador del extremo en cuestión, en este caso el número IP del extremo B. El resto de la línea, incluyendo los espacios, corresponderá a la clave compartida entre ambos extremos. Como lo dice la misma clave, la elección de la misma debe ser extremadamente cuidadosa, y en lo posible con una importante cantidad de caracteres aleatorios para asegurar la eficiencia de la misma. Para asegurarnos el correcto funcionamiento de la nueva configuración, reiniciaremos el servicio IPSec: vpnserver:/etc/racoon# /etc/init.d/racoon restart

Windows XP Para Configurar Windows XP, el proceso es un poco más largo. Comenzaremos ejecutando el comando mmc desde Inicio / Ejecutar.

Luego, al aparecer la siguiente pantalla:

10

Utilizaremos la opción Add/Remove Snap-in… del menú desplegable File.

Presionamos Add…

11

Seleccionamos IP Security Policy Management y presionamos Add.

Seleccionamos Local Computer y presionamos Finish.

12

Presionamos Close y OK en las ventanas anteriores para regresar a la siguiente pantalla:

Seleccionamos IP Security Policies on Local Computer, y utilizamos la opción Create IP Security Policy… del menú desplegable Action.

13

Completamos el nombre y descripción de la política que estamos creando.

14

Es necesario desactivar el checkbox de activado de regla de respuesta por defecto.

Y finalizamos sin editar las propiedades de la política que acabamos de crear.

15

En este momento, aunque no es indispensable, podemos borrar las tres políticas por defecto, y sólo veremos en la siguiente pantalla la política recién creada por nosotros:

Mediante un doble click en la política recién creada, podremos editar sus propiedades:

16

Comenzaremos con algunos detalles generales, seleccionando la hoja correspondiente:

17

Avanzada…

Aquí marcaremos el cuadro PFS, y continuamos con los métodos:

18

De los cuatro métodos incluidos por defecto, sólo conservaremos el que utiliza los algoritmos triple DES y SHA-1, borrando los tres restantes:

Luego, presionaremos OK hasta volver a la hoja de Reglas.

19

Donde vamos a agregar una nueva regla.

20

Dentro de la nueva regla, tendremos que agregar una nueva lista de filtrado.

Completamos los datos descriptivos de la nueva regla, y agregamos un filtro mediante el botón Add.

21

Completamos los datos de la conexión, sin olvidarnos de marcar el cuadro Mirrored.., lo que hará que tanto el tráfico de ida como el de vuelta concuerde con esta regla. Al apretar OK, podremos ver el filtro que acabamos de crear,

Luego presionaremos Ok,

22

para luego seleccionar la regla que acabamos de crear.

23

A continuación, definiremos que acción se tomará con los paquetes que concuerden con esta regla:

24

Elegimos crear una nueva acción mediante el botón Add…

25

Elegimos Negociar la seguridad, y otra vez mediante el botón Add…

26

y seleccionamos Cifrado e Integridad.

27

Por último, seleccionamos la utilización de PFS.

28

Será también conveniente incluir un nombre descriptivo por el cual podamos identificar esta acción.

29

En este caso también debemos asegurarnos de seleccionar la acción recién creada. Para concluir con esta etapa de configuración, seleccionaremos un método de autenticación en la hoja correspondiente:

30

Kerberos no está entre nuestros planes, por lo que utilizaremos el botón Add…

31

Y seleccionamos el método de clave compartida. Es muy importante que la clave ingresada sea exactamente igual a la ingresada en el archivo psk.txt en Linux para evitar problemas engorrosos de descubrir.

32

Ya que no utilizaremos el método Kerberos, ya lo podemos borrar. Ya estamos en condiciones de presionar OK y Close según corresponda hasta volver a la ventana de políticas IPSec.

33

El último paso restante para finalizar esta configuración consiste en Aplicar la política que acabamos de crear mediante el menú Action / Assign.

Comprobación La mejor manera de comprobar el correcto funcionamiento es realizando un ping desde el equipo windows. En un principio, el ping fallará con el mensaje Negociando Seguridad IP, pero seguidamente comenzará a funcionar. Si realizamos el ping desde el host linux, debemos tener la precaución de permitir el tipo de paquetes correspondientes en el Firewall de Windows XP para que funcione correctamente. También podrá utilizarse un sniffer (por ejemplo tcpdump) mientras se realiza el ping, y en este caso, en lugar de observar los paquetes ICMP correspondientes, deberemos ver los paquetes UDP correspondientes a la etapa de IKE, y paquetes ESP correspondientes al tráfico.

LAN a LAN En este caso ambos extremos utilizarán GNU/Linux. Comenzamos por configurar el Extremo A mencionado en la Figura 9. Como en el ejemplo anterior, editamos el archivo /etc/racoon/racoon-tool.conf: vpnserver:~# cd /etc/racoon vpnserver:/etc/racoon# vi racoon-tool.conf

peer(200.5.6.7): exchange_mode: main hash_algorithm[0]: sha1 encryption_algorithm[0]: 3des authentication_method[0]: pre_shared_key connection(linux-winxp): src_ip: 200.2.3.4 dst_ip: 200.5.6.7 src_range: 10.1.1.0/24 dst_range: 10.2.2.0/24 admin_status: enabled authentication_algorithm: hmac_sha1 encryption_algorithm: 3des pfs_group: modp1024

Como podrán notar, la configuración es prácticamente igual que para el ejemplo anterior, salvo que en este caso especificamos los rangos de las redes internas. Automáticamente se seleccionará el modo tunnel con la inclusión de estas nuevas directivas. Nota: se deberá tener muy en cuenta que esta configuración no implica el cifrado del tráfico entre los extremos A y B, o entre la Lan A y el extremo B y vice-versa.

34

Por último, si queremos que los paquetes del cliente lleguen a nuestra red interna, deberá estar habilitado el ruteo en el concentrador de túneles. Para activarlo inmediatamente utilizaremos el siguiente comando: vpnserver:~# echo 1 > /proc/sys/net/ipv4/ip_forward y para que el ruteo siga activado después de un rebooteo, deberemos editar la siguiente línea en el archivo /etc/network/options:

ip_forward=y

Cliente Remoto (Road Warrior) Para la conexión de un cliente remoto, también conocido como Road Warrior, como si fuese parte de nuestra red, utilizaremos la configuración que se muestra en la Figura 11. En este caso sólo analizaremos el caso donde un equipo corriendo GNU/Linux actúe como concentrador de túneles, y él o los clientes remotos utilicen Windows XP. Para maximizar la compatibilidad con el cliente Windows, y para facilitar la utilización de IPs dinámicos en los clientes, utilizaremos el protocolo L2TP además del cifrado IPSec.

Figura 11 - Cliente Remoto

En este ejemplo, un cliente remoto con IP dinámico se conectará al concentrador de túneles (IP 200.1.0.1) utilizando IPSec. Una vez cifrado el tráfico, se establecerá un túnel L2TP, a través del cual se iniciará una sesión PPP. El extremo de este túnel correspondiente al Road Warrior utilizará un IP de la red privada asignado por el concentrador de túneles, y el extremo del lado del concentrador tomará el IP 200.1.0.2. De esta manera, una vez establecida la sesión, el cliente remoto aparecerá como un equipo más dentro de la red privada, y todo el tráfico desde y hacia el cliente remoto será redirigido a través del túnel. Nota: Se deberán tener en especial consideración las implicancias de permitir el acceso remoto a la red interna. Se recomienda tomar las medidas de diseño de red y filtrado de paquetes necesarias para asegurar este esquema.

35

GNU/Linux Como mencionamos en la sección anterior, utilizaremos L2TP, por lo que tendremos que instalar el paquete correspondiente a este servicio. El nombre del paquete para GNU/Linux Debian es l2tpd, y es recomendable utilizar una versión 0.70 o superior. En caso de no estar disponible la misma para la versión de Debian que estemos utilizando, el paquete correspondiente podrá bajarse de http://packages.debian.org. Para instalarlo, bastará con ejecutar vpnserver:~# apt-get install l2tpd y en caso de haberlo bajado de http://packages.debian.org, vpnserver:~# dpkg –i l2tpd_0.70-pre20031121-2_i386.deb Ahora revisaremos la configuración del cifrado IPSec en el concentrador de túneles: vpnserver:/etc/racoon# vi racoon-tool.conf

peer(%anonymous): exchange_mode: main hash_algorithm[0]: sha1 encryption_algorithm[0]: 3des authentication_method[0]: rsasig dh_group[0]: modp1024 my_identifier: fqdn vpnserver.arcert.gov.ar certificate_type: x509 vpnpub.pem vpnpriv.pem verify_identifier: on verify_cert: on connection(%anonymous): src_ip: 200.1.0.1 admin_status: on authentication_algorithm: hmac_md5 encryption_algorithm: 3des pfs_group: none

Notaremos algunas diferencias con la configuración del esquema punto a punto. En primer lugar, como el IP del cliente remoto es desconocido, utilizaremos el comodín %anonymous para nombrarlo. Además, si quisiésemos utilizar claves compartidas para la autenticación del cliente, todos los clientes deberían compartir la misma clave (ya que no los podemos identificar de antemano mediante el número IP). Por esta razón utilizaremos certificados en lugar de claves compartidas para este esquema. Por último, y a raíz de una restricción impuesta en la configuración del túnel en Windows XP, deberemos desactivar PFS.

36

Si bien está afuera de los objetivos de este documento, mencionaremos brevemente la manera de crear certificados para utilizar en esta configuración. Si no disponemos de una CA, podremos crearla aprovechando la utilidad provista con el paquete openssl: vpnserver:~# /usr/lib/ssl/misc/CA.pl -newca CA certificate filename (or enter to create) Making CA certificate ... Generating a 1024 bit RSA private key ...++++++ ...........................++++++ writing new private key to './demoCA/private/cakey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:AR State or Province Name (full name) [Some-State]:BA Locality Name (eg, city) []:BA Organization Name (eg, company) [Internet Widgits Pty Ltd]:ArCERT Organizational Unit Name (eg, section) []:VPN CA Common Name (eg, YOUR name) []:VPNCA Email Address []: vpnserver:~# A continuación, creamos la clave privada (vpnpriv.pem) y la firmamos con la CA, obteniendo así un certificado para el servidor (vpnpub.pem). Es recomendable que el Common Name utilizado coincida con el nombre de dominio del concentrador de túneles, ya que algunos clientes de VPN podrían revisar que el mismo coincida. vpnserver:~# openssl req -new -nodes -newkey rsa:2048 -sha1 -keyform PEM -keyout vpnpriv.pem -outform PEM -out vpnreq.pem Generating a 2048 bit RSA private key ...+++ .................................................................+++ writing new private key to 'vpnpriv.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:AR

37

State or Province Name (full name) [Some-State]:BA Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]:ArCERT Organizational Unit Name (eg, section) []:Centro de Computos Common Name (eg, YOUR name) []:vpnserver.arcert.gov.ar Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: vpnserver:~# vpnserver:~# openssl ca -policy policy_anything -in vpnreq.pem -out vpnpub.pem Using configuration from /usr/lib/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 1 (0x1) Validity Not Before: Apr 8 10:26:26 2005 GMT Not After : Apr 8 10:26:26 2006 GMT Subject: countryName = AR stateOrProvinceName = BA organizationName = ArCERT organizationalUnitName = Centro de Computos commonName = vpnserver.arcert.gov.ar X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: A1:C0:DB:37:3B:38:A3:6E:CA:63:8E:EF:F9:AA:85:E4:23:E8:7C:CF X509v3 Authority Key Identifier: keyid:A6:81:4B:3F:6B:40:AC:EB:DE:37:2B:8C:0A:6A:0E:10:72:85:D6:94 DirName:/C=AR/ST=BA/L=BA/O=ArCERT/OU=VPN CA/CN=VPNCA serial:00 Certificate is to be certified until Apr 8 10:26:26 2006 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated vpnserver:~#

Posteriormente, deberemos seguir el mismo procedimiento para crear los certificados de los clientes Windows: userpriv.pem y userpub.pem. Para facilitar la importación de dicho certificado en el equipo Windows, empaquetaremos la clave privada, el certificado, y el certificado de la CA en formato PKCS12, obteniendo el archivo user.pfx.

38

vpnserver:~# cat userpriv.pem userpub.pem demoCA/cacert.pem | openssl pkcs12 -export -clcerts -out user.pfx Enter Export Password: Verifying - Enter Export Password: vpnserver:~#

Por último, copiamos la clave y certificado del servidor junto con el certificado de la CA (para que el servidor de túneles reconozca los certificados de los usuarios) al directorio /etc/racoon/certs/. vpnserver:~# cp vpnpub.pem vpnpriv.pem demoCA/cacert.pem /etc/racoon/certs/

Para que los programas reconozcan el certificado de la CA, deberemos crear los links correspondientes según el formato dictado por OpenSSL. Para ello, utilizamos el programa c_rehash, que se incluye en el paquete openssl. Además, nos aseguramos que sólo root pueda acceder a la clave privada utilizada. vpnserver:~# ls -l /etc/racoon/certs/ total 8 -rw-r--r-- 1 root root 1054 2005-04-08 07:29 cacert.pem -rw-r--r-- 1 root root 1675 2005-04-08 07:29 vpnpriv.pem -rw-r--r-- 1 root root 4072 2005-04-08 07:29 vpnpub.pem vpnserver:~# c_rehash /etc/racoon/certs/ Doing /etc/racoon/certs/ vpnpub.pem => 34e7346a.0 WARNING: vpnpriv.pem does not contain a certificate or CRL: skipping cacert.pem => f79292af.0 vpnserver:~# ls -l /etc/racoon/certs/ total 8 lrwxrwxrwx 1 root root 10 2005-04-08 07:29 34e7346a.0 -> vpnpub.pem -rw-r--r-- 1 root root 1054 2005-04-08 07:29 cacert.pem lrwxrwxrwx 1 root root 10 2005-04-08 07:29 f79292af.0 -> cacert.pem -rw-r--r-- 1 root root 1675 2005-04-08 07:29 vpnpriv.pem -rw-r--r-- 1 root root 4072 2005-04-08 07:29 vpnpub.pem vpnserver:~# chmod go-r /etc/racoon/certs/vpnpriv.pem vpnserver:~# ls -l /etc/racoon/certs/ total 8 lrwxrwxrwx 1 root root 10 2005-04-08 07:29 34e7346a.0 -> vpnpub.pem -rw-r--r-- 1 root root 1054 2005-04-08 07:29 cacert.pem lrwxrwxrwx 1 root root 10 2005-04-08 07:29 f79292af.0 -> cacert.pem -rw------- 1 root root 1675 2005-04-08 07:29 vpnpriv.pem -rw-r--r-- 1 root root 4072 2005-04-08 07:29 vpnpub.pem vpnserver:~#

Una vez finalizada la instalación de los certificados, continuamos con la configuración del l2tpd: vpnserver:~# vi /etc/l2tpd/l2tpd.conf

39

[global] listen-addr = 200.1.0.1 [lns default] ip range = 10.1.0.128 - 10.1.0.191 local ip = 10.1.0.2 require chap = yes refuse pap = yes require authentication = yes name = VPNServer ppp debug = yes pppoptfile = /etc/ppp/options.l2tpd length bit = yes

Aquí definimos, como vemos en la Figura 11, el IP donde escuchará el servidor L2TP (el IP externo de nuestro concentrador de túneles), el rango de IPs que serán asignados a los clientes remotos, y el IP correspondiente al extremo del túnel residente en el concentrador. Como veremos en la configuración del cliente Windows XP, el certificado asignado al cliente se corresponderá con el equipo, seguramente una notebook, y no con el usuario en sí, por lo tanto utilizaremos un nombre de usuario y contraseña para autenticarlo. Si bien el tráfico ya está cifrado y no es necesario, utilizaremos el protocolo MS-Chap V2 para el intercambio de la clave. vpnserver:~# vi /etc/ppp/options.l2tpd

+mschap-v2 mtu 1400 mru 1400

Además, y para evitar inconvenientes en la transmisión de paquetes debido a los múltiples encapsulamientos, disminuimos el tamaño máximos de transmisión y recepción de frames. En el archivo /etc/ppp/chap-secrets configuramos los usuarios que se conectarán, con sus respectivos passwords, y el rango de IPs desde el cual pueden utilizarlos (el rango asignado a los clientes en la configuración de l2tpd). vpnserver:~# cat /etc/ppp/chap-secrets

# Secrets for authentication using CHAP # client server secret IP addresses tomas * "ll&%$ñs#-.32Ç" 10.1.0.128/26

40

Al igual que en el esquema anterior, deberemos habilitar el reenvío de paquetes. Para activarlo inmediatamente utilizaremos el siguiente comando: vpnserver:~# echo 1 > /proc/sys/net/ipv4/ip_forward y para que el ruteo siga activado después de un rebooteo, deberemos editar la siguiente línea en el archivo /etc/network/options:

ip_forward=y

Windows De la misma manera que lo hicimos para las políticas IP, agregamos el módulo de Certificados utilizando Start / Run… / mmc:

Deberemos utilizar la Opción Equipo Local, ya que el cliente que utilizaremos asocia una VPN con el equipo, y no con un usuario:

41

42

Una vez abierto el módulo de certificados, Mediante el menú Action, o utilizando el botón derecho del mouse, realizamos una importación de certificado en la carpeta Personal/Certificates.

43

Seleccionamos el archivo que contiene los certificados.

Si utilizamos un password al generar el archivo PKCS12, deberemos ingresarlo aquí. Además, si queremos poder exportar la clave en un futuro, deberemos marcar la casilla correspondiente.

44

Es importante marcar la opción de selección automática del store.

45

Una vez que se complete el proceso, aparecerá el cartel precedente indicando que la importación se realizó con éxito Volviendo a la consola de administración de certificados, podremos ver el certificado recién instalado recién después de refrescar la pantalla (Mediante la utilización de la tecla F5, o del menú Ver.

A continuación, utilizaremos el asistente para la creación de una nueva conexión de red. El mismo puede accederse a partir del panel de control,

46

al seleccionar el módulo de conexiones de red, en el menú de la izquierda de la ventana:

47

Seleccionaremos Conectarse a mi ligar de trabajo,

48

mediante una VPN,

le asignamos un nombre a la nueva conexión,

49

e indicamos el nombre o número IP del concentrador de túneles (200.1.0.1).

Así habremos creado una nueva conexión de red:

50

A la cual le deberemos realizar ciertos ajustes mediante el menú de propiedades, accesible mediante el botón derecho del mouse.

51

En la hoja de Seguridad de las Propiedades de la conexión, deshabilitaremos el cuadro de Requerir cifrado de datos, ya que éste se refiere a la conexión PPP, y en realidad utilizaremos IPSec para el cifrado.

En la hoja de Red, debemos seleccionar el tipo de VPN: L2TP IPSec VPN. También será conveniente deshabilitar los protocolos que no vayan a ser utilizados, por ejemplo el Cliente para redes Microsoft.

52

Y Luego de presionar Ok, estamos listos para establecer la conexión, utilizando alguno de los nombres de usuario configurados en el concentrador de túneles.

53

Si todo sale como lo esperado, habremos establecido una conexión con el concentrador de túneles.

Consideraciones de Seguridad y Compatibilidad A continuación, destacaremos algunos detalles importantes a tener en cuenta.

Aggressive Mode Este modo de IKE, que no utilizamos en este caso, no debe ser utilizado en conjunción con claves compartidas (PSK), ya que permitirá ataques que podrán ver y modificar de manera inadvertida el tráfico cifrado.

PFS Esta propiedad puede ser utilizada tanto en la etapa de IKE, como en la de transmisión de datos, y nos asegurará que cualquier clave que se pueda haber filtrado por error, u obtenido por algún otro método (por ejemplo fuerza bruta), no sirva para descifrar el resto del contenido de una conexión. En el ayudante de configuración de conexiones de red de Windows XP utilizado para el tercer esquema de esta guía, no existe la posibilidad de habilitarlo (por razones desconocidas).

PSK Las claves compartidas son un método válido de autenticación cuando sólo dos extremos la conocen, y además se utilizan claves suficientemente “fuertes”. Las principales desventajas que posee son: que no son seguras, por un problema de diseño, cuando se utilizan junto al “aggressive mode”, y que en el caso de ser compartidas por más de un extremo (por ejemplo, si las queremos utilizar para “usuarios remotos”), no podemos identificar cual de los “usuarios” es el que se conecta, y peor aún, si no se utiliza PFS, se corre el riesgo de que un usuario malicioso utilice la clave para ver o modificar conexiones ajenas.

NAT Ninguno de los esquemas presentados funciona correctamente con NAT. Para que el primer esquema funcione con Nat-t, debería modificarse la configuración para utilizar el modo tunnel en lugar del modo transporte, y aplicar Nat-t. Sin embargo, la configuración de un host Windows sería bastante más compleja, y consideramos que el uso de NAT no es el caso más común para este esquema. Al igual que en el caso anterior, el segundo esquema presenta varios problemas de configuración y compatibilidad entre diferentes implementaciones de IPSec, y consideramos que los “extremos” que realizan el cifrado usualmente no utilizan NAT. En el tercer esquema, el cliente de Windows utiliza el modo transporte, por lo que no podrá utilizarse racoon, ya que hasta el día de hoy sólo implementa (correctamente) nat-t en modo tunnel. Por este motivo, en el caso de

54

necesitar utilizar NAT, se deberá recurrir a otra implementación de IPSec, por ejemplo, Openswan.

Firewalls En la mayoría de los casos, un firewall instalado entre dos extremos que intenten comunicarse por los medios descriptos en esta guía no permitirá la conexión. Para que ésta pueda realizarse, habrá que configurarlo para que permita el paso del protocolo 50(ESP), y del puerto 500/UDP (IKE).

Alternativas En esta sección, presentamos otras implementaciones que podrían utilizarse para éste u otro tipo de túneles cifrados.

OpenVPN OpenVPN es una implementación multiplataforma que utiliza el protocolo SSL/TLS para encapsular paquetes IP dentro de conexiones TCP o paquetes UDP. Es un protocolo robusto y con implementaciones en varios sistemas operativos. Tiene un cliente que puede bajarse en modo binario para ser utilizado en Windows 2000/XP.

SSH El protocolo SSH, usualmente utilizado como reemplazo seguro del telnet, también tiene la capacidad de encapsular otras conexiones. Si bien no puede considerarse exactamente un túnel, servirá para encapsular conexiones individuales.

Openswan OpenSwan es una alternativa a la implementación nativa de IPSec del kernel 2.6. Soporta Nat-t tanto en modo transport como en modo tunnel. A continuación, se incluye la configuración necesaria para utilizar OpenSwan en el esquema número 3 en lugar de racoon:

Colocar el certificado de la CA (cacert.pem) en el directorio /etc/ipsec.d/cacerts.

Colocar la clave pública del servidor (vpnpub.pem) en el directorio /etc/ipsec.d/certs

Colocar la clave privada del servidor (vpnpriv.pem) en el directorio /etc/ipsec.d/private.

Colocar la siguiente entrada en el archivo /etc/ipsec.secrets:

: RSA vpnpriv.pem

Utilizar la siguiente configuración en el archivo /etc/ipsec.conf:

config setup nat_traversal=yes conn roadwarrior

55

authby=rsasig pfs=no left=%defaultroute leftcert=vpnpub.pem leftprotoport=17/1701 right=%any rightrsasigkey=%cert rightid="C=AR, ST=BA, O=ArCERT, CN=*, E=*" rightprotoport=17/1701 auto=add

reemplazando el parámetro rightid por las propiedades de los certificados que queremos permitir, o simplemente eliminándolo para aceptar todos los certificados emitidos por la CA.

Y por último, y muy importante, no usen debug en la versión 2.3.0 de Openswan porque perderán preciadas horas intentando dilucidar por qué razón la conexión no se realiza con éxito, hasta descubrir que es el mismo debug quien la impide ☺.

Trabajo por hacer Para continuar con la evolución de este documento, consideramos realizar en un futuro las siguientes tareas:

• Incluir Nat-T en los tres esquemas propuestos. Esto implica la realización de pruebas exhaustivas de compatibilidad, ya que se han detectado comportamientos diferentes entre las distintas implementaciones.

• Recambio de las capturas de Windows XP por la versión en castellano. • Revisión de la herramienta utilizada para configurar IPSec en Linux. • Migración a rp-l2tp, l2tpns u openl2tp. • Incluir Protocolos y puertos utilizados en los esquemas presentados y la

incidencia de firewalls en el camino de las conexiones. Si tiene alguna sugerencia sobre este documento, por favor envíela a info@arcert.gov.ar.

Bibliografía Para obtener más información sobre IPSec y su configuración, pueden consultarse los siguientes sitios:

• An Illustrated Guide to IPSec, por Steve Friedl • Debian Administration :: Debian IPsec Micro-Howto • Using a Linux L2TP/IPsec VPN server, por Jacco de Leeuw • IPSec Technical Reference, por Microsoft

56