Universidad de Buenos Aires Facultad De Ingeniería 2 do Cuatrimestre 2011 TP2: IPSEC Parte 1 (RSA) INTEGRANTES Carracedo, Leandro - 83.291 leandrocarracedo@gmail.com De Roovers, Raúl - 84.248 nari77@gmail.com Pereira, María Florencia - 88.816 mflorenciapereira@gmail.com 66.69 - Criptografía y Seguridad Informática
Índice 1. Introducción 2 1.1. Objetivo.................................................. 2 1.2. IPSec................................................... 2 2. Esquema inicial 4 3. Experiencia 5 3.1. Modificación de scripts.......................................... 5 3.2. Preparación de las estaciones y routers................................. 5 3.2.1. H1-preparar.sh.......................................... 5 3.2.2. H2-preparar.sh.......................................... 5 3.2.3. R1-1-preparar.sh......................................... 6 3.2.4. R2-1-preparar.sh......................................... 6 3.3. Verificación de la configuración..................................... 6 3.3.1. Ping H1 a R1........................................... 7 3.3.2. Ping H2 a R2........................................... 7 3.3.3. Ping R1 a R2........................................... 8 3.4. Generación de claves........................................... 8 3.4.1. R1-generarclaves.sh....................................... 8 3.4.2. R2-generarclaves.sh....................................... 8 3.4.3. ipsec.secrets............................................ 8 3.5. Configuración y establecimiento del tunel............................... 9 3.5.1. R1-4-configurar.sh........................................ 9 3.5.2. R2-4-configurar.sh........................................ 10 3.5.3. iniciarenlace.sh (en R2)..................................... 10 3.5.4. Verificación del enlace...................................... 10 3.5.5. Captura de paquetes....................................... 11 3.6. Captura del protocolo.......................................... 13 3.7. Desencriptación de tráfico........................................ 20 4. Conclusión 25
1. Introducción 1.1. Objetivo Investigar el funcionamiento de IPSec mediante la configuración de un túnel entre dos PCs, usando la distribución de Linux provista por la cátedra, el analizador de protocolos Wireshark y un software de virtualización (VMWare). 1.2. IPSec La especificación de IPSEc se encuentra en varias RFCs. Algunas de ellas son: RFC 2401, RFC 2402, RFC 2406, RFC 2408. Provee servicios tales como control de acceso, confidencialidad, autenticación, protección contra replay a nivel de IP, permitiendo la configuración de claves y algoritmos a utilizar. IPSec tiene dos modos de funcionamiento: transporte y túnel. En el modo transporte ESP se usa para encriptar los datos a transmitir. El header se inserta antes del header de la capa de transporte. En el modo túnel, todo el paquete IP es cifrado o autenticado. Para lograrlo, tanto los campos correspondientes al header AH o ESP como el paquete original se trata como payload. Ningún router intermedio puede observar el header interno. Suele usarse este modo cuando uno de los dispositivos es un security gateway como un firewall o router que implementa IPSec. Detrás de este dispositivo, puede haber otras estaciones comunicadas sin que estas implementen IPSec. Los paquetes transmitidos por las estaciones se transmiten mediante SAs en modo túnel mediante el software instalado en el firewall al traspasar la red local. A continuación se muestran las diferencias de headers en los dos modos: Figura 1: Headers en modo túnel y modo transporte. Un concepto importante en IPSec es el de Security Association (SA). Una SA es una asociación unidireccional 2
entre un transmisor y receptor que usa servicios de seguridad. Los parámetros de las SA se guardan en una Security Association Database (SAD). Una SA contiene los siguientes parámetros: Security Parameters Index (SPI): un número que identifica al SA localmente que permite al receptor determinar el SA mediante el cual se procesarán los paquetes recibidos. IP destino IPSec Protocol Identifier: si la SA es ESP o AH. Sequence Number Counter: genera un número de secuencia para los headers ESP o AH. Sequence Counter Overflow: un flag que indica si hubo Overflow en el número de secuencia para que dejen de transmitirse paquetes en esta SA. Anti-Replay Window: permite detectar replays. AH Information: algoritmo, claves, etc. de AH ESP Information: algoritmos, claves de ESP. Lifetime: intervalo en que será válido el SA. Luego es reeplazado por otro o terminado. IPSec Protocol Mode: Tunnel, transport, or wildcard Path MTU: MTU observado. Consta básicamente de dos protocolos, cuyos headers son: Authentication Header (AH) y Encapsulating Security Payload (ESP). AH se usa para lograr autenticación e integridad en paquetes IP y tiene el siguiente formato: Figura 2: Header AH ESP permite lograr confidencialidad en el contenido del mensaje y también en relación a las propiedades del flujo de tráfico. El formato del header es el siguiente. 3
Figura 3: Header ESP 2. Esquema inicial Para la realización del trabajo práctico se armó el siguiente esquema de red: Figura 4: Esquema de red Se montaron cuatro máquinas virtuales, usando VMware Workstation. Se crearon 3 VLANS. La VLAN 1 comprende H1 y R1, la VLAN 2 comprende R2 y H2 y finalmente, la VLAN 3 incluye a R1 y R2. Se eligió como número de grupo 212. Para esta primera parte del Trabajo Práctico se utilizó el tipo de tunel: ESP-RSA. 4
3. Experiencia 3.1. Modificación de scripts Para lograr la configuración especificada en la sección anterior se utilizaron los scripts proporcionados por la cátedra. Inicialmente, fue necesario modificar las siguientes variables de entorno en el archivo /crypto/conf/config.sh: #Variables del grupo GRUPO = 212 TIPO TUNEL = ESP-RSA A partir de la definición de estas variables se generarán las direcciones IP y se indica que se utilizará el protocolo ESP y el modo de autenticación con RSA. 3.2. Preparación de las estaciones y routers Luego, se ejecutó el script de preparación en modo root para cada una de las máquinas virtuales. 3.2.1. H1-preparar.sh 3.2.2. H2-preparar.sh Figura 5: Ejecución del script H1-preparar.sh Figura 6: Ejecución del script H2-preparar.sh 5
3.2.3. R1-1-preparar.sh Figura 7: Ejecución del script R1-1-preparar.sh 3.2.4. R2-1-preparar.sh 3.3. Verificación de la configuración Figura 8: Ejecución del script R2-1-preparar.sh Para corroborar que la configuración del entorno es correcta, se utiliza la herramienta ping. Vemos a continuación que todos los paquetes de prueba enviados llegan correctamente a destino, confirmando que la red está correctamente configurada. 6
3.3.1. Ping H1 a R1 Figura 9: Ping de H1 a R1. 3.3.2. Ping H2 a R2 Figura 10: Ping de H2 a R2. 7
3.3.3. Ping R1 a R2 3.4. Generación de claves Figura 11: Ping de R1 a R2. En esta parte del trabajo práctico se generaron las claves públicas y privadas del algoritmo RSA que van a ser utilizadas para la encriptación por los routers R1 y R2. El resultado del script se guarda en un archivo ubicado en /etc/ipsec.secrets que solo podrá ser modificado o leído en modo root. 3.4.1. R1-generarclaves.sh 3.4.2. R2-generarclaves.sh Figura 12: Ejecución del script R1-generarclaves.sh 3.4.3. ipsec.secrets Figura 13: Ejecución del script R2-generarclaves.sh A continuación se incluye el contenido del archivo ipsec.secrets. Observamos que en en un sección del archivo se especifican los parámetros correspondientes a la clave pública. Asimismo, existe una sección donde se definen los parámetros utilizados en la clave privada tales como el par de números primos que se eligen. 8
Figura 14: Contenido de ipsec.secrets 3.5. Configuración y establecimiento del tunel En esta parte se configuran los routers para iniciar el servicio IPSec y posteriormente en alguno de estos se ejecuta el script que establece el túnel. Finalmente verificamos que el túnel se estableció correctamente revisando las rutas que quedaron configuradas y utilizando nuevamente la herramienta ping. 3.5.1. R1-4-configurar.sh Figura 15: Ejecución del script R1-4-configurar.sh 9
3.5.2. R2-4-configurar.sh 3.5.3. iniciarenlace.sh (en R2) Figura 16: Ejecución del script R2-4-configurar.sh 3.5.4. Verificación del enlace Figura 17: Ejecución del script iniciarenlace.sh desde R2 Inicialmente verificamos que las rutas hayan quedado correctamente configuradas ejecutando route en cada router. 10
Figura 18: Ejecución de route en R1 Encontramos configurada en R1 la ruta 10.212.2.0 especificada en el enunciado. Figura 19: Ejecución de route en R2 Encontramos configurada en R2 la ruta 10.212.1.0 especificada en el enunciado. Figura 20: Ping de H1 a H2. Finalmente, volvemos a hacer ping entre H1 y H2, para verificar la comunicación entre los hosts. 3.5.5. Captura de paquetes Como parte de la verificación del túnel, se capturan paquetes usando wireshark en la interfaz eth0 del router R1. Esta interfaz permite comunicar R1 y R2. También se inicia la captura en H1 y se hace un ping desde H2 a H1. La captura en el router R1 arroja el siguiente resultado: 11
Figura 21: Captura en R1 Observamos que entre los routers (direcciones 192.168.212.41 y 192.168.212.42) solo se intercambian parquetes del tipo ESP (Encapsulating Security Payload), garantizando que la información intercambiada se encuentra encriptada. Esto sucede en todos los casos. Por otro lado, también podemos ver que hay paquetes del tipo ICMP intercambiados entre los dos hosts, que utilizan la misma interfaz (por esta razón aparecen en la captura). La captura en H1 genera el siguiente resultado: 12
Figura 22: Captura en H1 Observamos que al igual que el caso anterior se intercambian paquetes ICMP y ARP entre H1 y H2. Podemos conlcuir que la red planteada permite intercambiar paquetes ICMP o ARP de los hosts hacia los routers y que entre los routers la información viaja encriptada mediante paquetes ESP. 3.6. Captura del protocolo Inicialmente damos de baja la conexión, abrimos wireshark y levantamos el tunel otra vez. De esta forma se espera capturar todos los paquetes involucrados en el establecimiento de la conexión. El resultado de la captura es el siguiente: 13
Figura 23: Captura en R1 Observamos que inicialmente se intercambian paquetes bajo el protocolo ISAKMP (Internet Security Associations and Key Managment Protocol). Este protocolo, definido en la RFC 2408 permite la negociación y el establecimiento de procedimientos utilizados por los Security Associations (SA) y claves criptográficas. El framework solo proporciona autenticación e intercambio de claves. Se utiliza en este caso junto con IKE (Internet Key Exchange) para implementarlo para internet, pero también podría usarse con Kerberized Internet Negotiation of Keys. La negociación IKE está compuesta por dos fases. El objetivo de la primera fase IKE es establecer un canal de comunicación seguro usando el algoritmo de intercambio de claves Diffie-Hellman para generar una clave de secreto compartido y así cifrar la comunicación IKE. Esta negociación establece una única SA ISAKMP Security Association (SA) bidireccional. La autenticación puede ser realizada usando tanto una clave compartida (preshared key) (secreto compartido), firmas digitales o cifrado de clave pública. La fase 1 opera tanto en modo principal como agresivo. El modo principal protege la identidad de los extremos, mientras que el modo agresivo no lo hace. En la segunda fase IKE, los extremos usan el canal seguro establecido en la primera fase para negociar una Asociación de Seguridad (SA), esto es los algoritmos de encriptación y autenticación a usar en el túnel. La negociación consiste en un mínimo de dos SAs unidireccionales. El único modo en este caso es QuickMode. En nuestro caso, como vemos en la figura, para la primera fase se usa Modo Principal (Main mode). En esta fase R1 comunica a R2 qué algoritmos de encriptación y de hash soporta. Esta comunicación se realiza mediante Transform Payloads que contienen principalmente los siguientes campos: Encryption Algorithm: constantes que representan los algoritmos de encriptación soportados. Hash Algorithm: valores que representan los algoritmos de hash soportados. Auth method: métodos de autenticación soportados. 14
Group Description: valores que se usan al generar grupos de claves para el intercambio Diffie Hellman en la fase 1. Se usa también en la fase dos su se usa perfect forward secrecy. A continuación el detalle de los algoritmos propuestos por R1: Figura 24: Detalle fase 1 Vemos que se proponen los siguientes conjuntos de valores: 15
Transform payload 0: Encryption Algorithm: 3DES-CBC Hash Algorithm: MD5 Auth method: RSA-SIG Group Description: 1536 bit MODP group secrecy. Transform payload 1: Encryption Algorithm: 3DES-CBC Hash Algorithm: SHA Auth method: RSA-SIG Group Description: 1536 bit MODP group secrecy. Transform payload 2: Encryption Algorithm: 3DES-CBC Hash Algorithm: SHA Auth method: RSA-SIG Group Description: Alternate 1024 bit MODP group secrecy. Transform payload 3: Encryption Algorithm: 3DES-CBC Hash Algorithm: MD5 Auth method: RSA-SIG Group Description: Alternate 1024 bit MODP group secrecy. R2 responde aceptando el payload 0, con lo cual se utilizará 3DES-CBC para la encriptación, MD5 para verificación de integridad y RSA-SIG como método de autenticación. 16
Figura 25: Respuesta desde R2 Luego se intercambian los parámetros de Diffie Hellman y un nonce. Este último con el objetivo de evitar un replay de mensajes. Vemos el siguiente paquete: Figura 26: Intercambio parámetros Diffie Hellman de R1 17
Figura 27: Intercambio parámetros Diffie Hellman de R2 Los paquetes intercambiados hasta el momento forman parte de la etapa IKE SA INIT y comprende el intercambio y negociación de algoritmos así como el intercambio de nonces y parámetros de Diffie Hellman. El objetivo de este intercambio inicial es establecer un canal seguro transitorio que será utilizado por los siguientes intercambios. De aquí en adelante todos los intercambios viajarán encriptados. Luego comienza la etapa IKE SA AUTH a partir del canal establecido con las claves Diffie Hellman. En este momento se autentican e identifican a las partes que participan en la comunicación. Asimismo se crea el primer SA child. El paquete (encriptado) obtenido en este momento es: 18
Figura 28: IKE SA AUTH Finalmente, se inicia la segunda fase de ISAKMP, usando QuickMode y el canal encriptado con claves generadas por Diffie Hellman nuevamente. El SA de la primera etapa permite así proteger el intercambio de la segunda etapa, para negociar un nuevo SA y generar nuevas claves. Toda esta información nuevamente, viaja encriptada. Se realiza el intercambio CREATE CHILD SA, para la creación de SA child adicionales. El paquete que se observa es: Figura 29: IKE SA AUTH 19
3.7. Desencriptación de tráfico En esta sección se ingresan las claves generadas a Wireshark para obtener los mensajes en texto plano. Para lograrlo, se usa el comando setkeys -D Figura 30: Resultado de ejecución de setkey En la figura observamos claramente los datos de las SA generadas. Vemos que se especifican las claves y los algoritmos de enciptación y autenticación utilizados. Existe un SA para cada sentido posible, esto es de R1 a R2 y de R2 a R1. Para poder identificar cada SA se necesitan por lo menos los siguientes parámetros: Security Parameter Index o SPI: número de 32 bits que identifica unívocamente un SA en la base de datos para un dispositivo conectado (con significado local). Se transmite mediante el header AH o ESP según se haya seleccionado y permite al sector receptor seleccionar el SA bajo el cual se procesarán los paquetes recibidos. IP destino: IP del dispositivo para el cual se estableció la conexión (unicast) que puede ser un usuario final, un router, firewall, etc. IPSec Protocol Identifier: especifica el tipo de asociación (ESP o AH). También apreciamos que el modo seleccionado es Modo tunel. En el modo túnel, todo el paquete IP es cifrado o autenticado. Para lograrlo, tanto los campos correspondientes al header AH o ESP como el paquete original se trata como payload. Ningún router intermedio puede observar el header interno. Suele usarse este modo cuando uno de los dispositivos es un security gateway como un firewall o router que implementa IPSec. Detrás de este dispositivo, puede haber otras estaciones comunicadas sin que estas implementen IPSec. Los paquetes transmitidos por las estaciones se transmiten mediante SAs en modo túnel mediante el software instalado en el firewall al traspasar la red local. A cada paquete se puede aplicar más de un SA, a través de SA bundles. Los parámetros de las SAs generadas se guardan en Security Association Database (SAD), donde se les asigna un tiempo de vida. Cada dispositivo tiene su propia SAD. Los SPD (Security Policy Database) contiene entradas que definen subconjuntos del trafico IP y apuntan a uno o más SA para ese tráfico. Cada SPD define un set de IP y valores de campos de la capa superior llamados selectors, usados para filtrar tráfico y mapearlo a un SA en particular. A partir de la información obtenida, podemos ingresar las claves en Wireshark para desencriptar los paquetes ESP: 20
Figura 31: Ingreso de claves en Wireshark A continuación reiniciamos la captura en eth0 y hacemos ping de H1 a H2. Esta vez no hay paquetes ESP que viajen entre H1 y H2 y solo observamos el intercambio de paquetes ICMP. 21
Figura 32: Captura de paquetes una vez ingresadas las claves. Si reiniciamos la conexión, los paquetes no pueden ser desencriptados y Wireshark informa que hubo un error (Authentication data incorrect): 22
Figura 33: Luego de reiniciar la conexión, se produce un error en la autenticación. Esto se debe a que cada vez que se inicia la conexión, se asignan nuevos SA (y por lo tanto nuevas claves). Si ejecutamos nuevamente setkey -D, obtenemos: Figura 34: Ejecución de setkey -D luego de reiniciar la conexión. 23
4. Conclusión A partir del trabajo práctico fue posible explorar el funcionamiento de IPSec. Asimismo, fue posible comprender los protocolos usados por IPSec (ESP, AH e ISAKMP) y los distintos elementos (SA, SPD, SAD, etc.) para la administración y almacenamiento de información que permiten un intercambio seguro de paquetes. IPSec proporciona los servicios de autenticación, confidencialidad y distribución de claves, de forma tal que el intercambio de paquetes sea seguro a nivel de IP. Esto último es muy importante dado que a través de IPSec se puede asegurar una comunicación a pesar de que las aplicaciones (implementadas en capas superiores) no tengan en cuenta este aspecto. Otros protocolos de seguridad de uso extendido, como SSL, TLS y SSH operan en la capa de aplicación y no logran seguridad en protocolos TCP o UDP, como sí es el caso de IPSec. Del mismo modo, al estar implementado en la capa de red, las aplicaciones no necesitarán hacer ningún cambio para poder implementarlo. Finalmente, concluimos que IPSec puede configurarse fácilmente a través de los scripts usados y que presenta muchas opciones (distintos modos de funcionamiento y algoritmos, headers, etc.) haciendo que sea muy flexible. 24