Tesis Elena Esqueda.pdf - Saber UCV

Universidad Central de Venezuela Facultad de Ciencias

Escuela de Computación LACORE

ANÁLISIS Y DISEÑO DE UNA SOLUCIÓN VPN ENTRE EL CAMPUS CARACAS DE LA UCV Y SUS DEPENDENCIAS EXTRAMUROS

Br. Elena Esqueda C.I. 16.887.066 Br. Karem Pérez C.I. 16.923.293

Tutores Profa. Karima Velásquez Prof. Daniel Villavicencio

Caracas, Junio 2011

2

Resumen

El presente trabajo tiene como objetivo plantear una propuesta de diseño de una solución VPN que permita la transmisión de información sensible de forma segura entre el campus Caracas y las dependencias extramuros conectadas a la red corporativa de datos de la Universidad Central de Venezuela. Para ello se realizó un levantamiento de información del ambiente de la red corporativa de datos, con el objeto de establecer las consideraciones de diseño preliminares, así como una investigación de las características técnicas de las tecnologías VPN existentes con el fin de evaluar su aplicación en el escenario planteado. Atendiendo a estas consideraciones, se plantearon diferentes propuestas de solución VPN basadas en tres principales tecnologías: PPTP, IPSec y OpenVPN, para posteriormente implementar los escenarios de prueba correspondientes donde se evaluaron las ventajas y desventajas de cada propuesta de diseño. Por último, se realizó una comparación de las propuestas de diseño de cada tecnología identificando las características relevantes, para finalmente recomendar el uso de OpenVPN como una opción viable para la implantación de la solución VPN entre el campus Caracas de la UCV y sus dependencias extramuros. Palabras claves: VPN, PPTP, IPSec, OpenVPN, Seguridad.

3

Tabla de Contenido

Resumen .............................................................................................................................................. 2

1. Introducción ................................................................................................................................ 8

2. El problema ............................................................................................................................... 10

2.1. Planteamiento del problema ............................................................................................ 10

2.2. Justificación ....................................................................................................................... 10

2.3. Objetivos ........................................................................................................................... 11

2.3.1. Objetivo general ........................................................................................................ 11

2.3.2. Objetivos específicos ................................................................................................. 12

2.4. Alcances ............................................................................................................................. 12

3. Marco teórico ............................................................................................................................ 13

3.1. Definición de VPN .............................................................................................................. 13

3.2. Elementos de una VPN ...................................................................................................... 14

3.3. Tipos de VPN ..................................................................................................................... 15

3.3.1. VPN Sitio-a-Sitio (Site-to-Site VPN) ........................................................................... 15

3.3.2. VPN de Acceso Remoto o VPDN (Virtual Private Dial-up Network) .......................... 15

3.3.3. VPN Firewall .............................................................................................................. 15

3.3.4. VPN Usuario-a-Usuario (User-to-User VPN) .............................................................. 16

3.4. Topologías de VPN ............................................................................................................ 16

3.4.1. Punto-a-Punto (Point-to-Point) ................................................................................. 16

3.4.2. Dispositivo-a-Dispositivo (Device-to-Device) ............................................................ 16

3.4.3. Red-a-Red (Network-to-Network) ............................................................................. 17

3.5. Categorías de VPN ............................................................................................................. 18

3.5.1. Intranet ...................................................................................................................... 18

3.5.2. Extranet ..................................................................................................................... 18

3.5.3. Internet ...................................................................................................................... 18

3.6. Componentes de una conexión VPN ................................................................................. 19

3.7. Ventajas de una VPN ......................................................................................................... 20

3.8. Desventajas de una VPN ................................................................................................... 20

3.9. Implementaciones de VPN ................................................................................................ 21

3.9.1. PPTP (Point-to-Point Tunneling Protocol) ................................................................. 21

4

3.9.2. L2TP (Layer 2 Tunneling Protocol) ............................................................................. 25

3.9.3. L2TP/IPSEC ................................................................................................................. 26

3.9.4. GRE ............................................................................................................................ 29

3.9.5. IPSec .......................................................................................................................... 31

3.9.6. SSL/TLS ...................................................................................................................... 41

3.9.7. OpenVPN ................................................................................................................... 45

4. Marco metodológico ................................................................................................................. 51

4.1. Fase 1. Red de datos de la UCV ......................................................................................... 52

4.1.1. Topología del Nodo Core ........................................................................................... 52

4.1.2. Topología de los nodos de Ingeniería, Ciencias y Medicina ...................................... 53

4.1.3. Topología del backbone de entrada .......................................................................... 53

4.1.4. Descripción de los extramuros .................................................................................. 54

4.1.5. Descripción de los sistemas corporativos de la UCV ................................................. 56

4.2. Fase 2. Planteamiento de las consideraciones de diseño de una VPN ............................. 58

4.2.1. Perfil de la red ........................................................................................................... 58

4.2.2. Escalabilidad .............................................................................................................. 62

4.2.3. Seguridad ................................................................................................................... 62

4.2.4. Topología de red ....................................................................................................... 63

4.3. Fase 3. Desarrollo de las propuestas de diseño de soluciones VPN ................................. 64

4.3.1. PPTP con MPPE.......................................................................................................... 64

4.3.2. IPSec/GRE .................................................................................................................. 67

4.3.3. OpenVPN ................................................................................................................... 73

4.4. Fase 4. Implementación de los escenarios de prueba ...................................................... 76

4.4.1. PPTP ........................................................................................................................... 76

4.4.2. IPSec .......................................................................................................................... 85

4.4.3. OpenVPN ................................................................................................................... 95

4.5. Fase 5. Comparación y selección de una propuesta de diseño VPN. .............................. 108

5. Conclusiones............................................................................................................................ 113

6. Referencias .............................................................................................................................. 115

7. Glosario ................................................................................................................................... 116

5

Índice de Figuras

Figura 2.1: Conexión VPN. .................................................................................................... 13

Figura 2.2: Túnel VPN. .......................................................................................................... 14

Figura 2.3: Elementos de una VPN. ...................................................................................... 15

Figura 2.4: Conexión dispositivo-a-dispositivo. .................................................................... 16

Figura 2.5: Conexión red-a-red. ............................................................................................ 17

Figura 2.6: Diseños de redes VPN fully/partially-meshed. ................................................... 18

Figura 2.7: Conexión PPTP. ................................................................................................... 22

Figura 2.8: Túneles voluntarios. ........................................................................................... 24

Figura 2.9: Túneles permanentes. ........................................................................................ 24

Figura 2.10: Estructura de un paquete PPTP. ....................................................................... 25

Figura 2.11: Estructura de un paquete L2TP. ....................................................................... 25

Figura 2.12: Mensaje de control L2TP. ................................................................................. 27

Figura 2.13: Túnel de datos L2TP. ........................................................................................ 28

Figura 2.14: Ejemplo de acceso remoto con L2TP/IPSec. .................................................... 28

Figura 2.15: Ejemplo de conexión de sucursales con L2TP/IPSec. ....................................... 29

Figura 2.16: Estructura de un paquete GRE. ........................................................................ 29

Figura 2.17: GRE header. ...................................................................................................... 30

Figura 2.18: Paquete IPSec con el AH header....................................................................... 32

Figura 2.19: AH header. ........................................................................................................ 33

Figura 2.20: Mecanismo de autenticación AH. .................................................................... 34

Figura 2.21: Un datagrama IPSec-AH en modo túnel. .......................................................... 34

Figura 2.22: Paquete IPSec con ESP header y ESP trailer. .................................................... 35

Figura 2.23: Campos del paquete ESP. ................................................................................. 35

Figura 2.24: Un paquete IPSec-ESP en modo túnel. ............................................................. 36

Figura 2.25: Asociación de seguridad. .................................................................................. 36

Figura 2.26: Fases de ISAKMP/IKE. ....................................................................................... 39

Figura 2.27: SSL/TLS en la pila de protocolos OSI................................................................. 42

Figura 2.28: Cifrado y formato de datos de aplicación con Record Protocol. ...................... 44

Figura 2.29: Formato del paquete encapsulado por OpenVPN. .......................................... 46

Figura 2.30: Encapsulación del canal de datos en OpenVPN. .............................................. 47

Figura 2.31: Formato del paquete de control de OpenVPN. ................................................ 47

Figura 3.1: Topología del backbone principal de la red de datos de la UCV. ....................... 53

Figura 3.2: Backbone de la red corporativa de datos de la UCV. ......................................... 54

Figura 3.3: Extramuros. ........................................................................................................ 55

Figura 3.4: Captura de cuentas bancarias. ........................................................................... 59

Figura 3.5: Captura de información académica. .................................................................. 60

Figura 3.6: Captura de información personal. ...................................................................... 60

Figura 3.7: Captura de información SIGAS. .......................................................................... 61

Figura 3.8: Captura de información de bases de datos. ....................................................... 62

Figura 3.9: Topología hub-and-spoke. .................................................................................. 63

Figura 3.10: Escenario propuesto usando PPTP con MPPE. ................................................. 65

6

Figura 3.11: Ejemplo de conexión PPTP. .............................................................................. 66

Figura 3.12: Ejemplo de conexión IPSec. .............................................................................. 70

Figura 3.13: Ejemplo de conexión OpenVPN. ....................................................................... 74

Figura 3.14: Escenario de prueba PPTP. ............................................................................... 77

Figura 3.15: Crear una conexión dial up. .............................................................................. 79

Figura 3.16: Tipo de conexión de red. .................................................................................. 79

Figura 3.17: Conexión de red. ............................................................................................... 79

Figura 3.18: Nombre de conexión. ....................................................................................... 80

Figura 3.19: Selección de servidor VPN. ............................................................................... 80

Figura 3.20: Finalización del asistente para conexión nueva. .............................................. 81

Figura 3.21: Conexión de red privada virtual. ...................................................................... 81

Figura 3.22: Par usuario/contraseña. ................................................................................... 82

Figura 3.23: Captura conexión de control. ........................................................................... 82

Figura 3.24: Captura de tráfico http con PPTP. .................................................................... 83

Figura 3.25: Captura comando ping. .................................................................................... 84

Figura 3.26: Comando show vpdn. ....................................................................................... 84

Figura 3.27: Comando show vpdn history failure. ................................................................ 85

Figura 3.28: Escenario de prueba IPSec................................................................................ 85

Figura 3.29: Captura de paquetes Telnet. ............................................................................ 90

Figura 3.30: Captura de sesión Telnet. ................................................................................. 90

Figura 3.31: Captura de paquetes http. ............................................................................... 91

Figura 3.32: Captura de paquetes IPSec. .............................................................................. 91

Figura 3.33: Comando show crypto isakmp sa. .................................................................... 92

Figura 3.34: Comando show crypto ipsec sa. ....................................................................... 93

Figura 3.35: Comando show crypto session. ........................................................................ 94

Figura 3.36: Comando show crypto map. ............................................................................. 94

Figura 3.37: Comando show crypto key. .............................................................................. 94

Figura 3.38: Comando show crypto isakmp policy. .............................................................. 94

Figura 3.39: Escenario de prueba OpenVPN. ....................................................................... 95

Figura 3.40: Interfaz virtual TUN/TAP. ............................................................................... 101

Figura 3.41: Archivos a copiar en el cliente OpenVPN. ...................................................... 102

Figura 3.42: Archivo de configuración del cliente. ............................................................. 102

Figura 3.43: Inicialización del servidor OpenVPN. .............................................................. 104

Figura 3.44: Icono cliente OpenVPN. .................................................................................. 104

Figura 3.45: Consola cliente OpenVPN. .............................................................................. 105

Figura 3.46: Icono interfaz virtual OpenVPN. ..................................................................... 105

Figura 3.47: Establecimiento del túnel OpenVPN. ............................................................. 106

Figura 3.48: Comando netstat –rn. ..................................................................................... 107

Figura 3.49: Captura de tráfico OpenVPN. ......................................................................... 108

7

Índice de Tablas

Tabla 2.1: Algoritmos de cifrado soportados por SSL/TLS. .................................................. 45

Tabla 3.1: Capacidades de los enlaces extramuros. ............................................................. 56

Tabla 3.2: Sistemas corporativos UCV utilizados por usuarios extramuros. ........................ 57

Tabla 3.3: Consideraciones preliminares IPSec. ................................................................... 68

Tabla 3.4: Comparación de las propuestas de diseño. ....................................................... 109

8

1. Introducción

Las empresas de hoy en día requieren que sus redes superen la barrera de lo local permitiendo la conectividad de su personal y oficinas en otros edificios, ciudades, comunidades autónomas e incluso países. Este es el caso de la Universidad Central de Venezuela, que cuenta con dependencias ubicadas en el exterior del campus universitario, denominadas dependencias extramuros, cada una de las cuales requiere mantener un estrecho vínculo de comunicación con las dependencias centrales, facultades y entre sí, para el desarrollo de actividades administrativas y académicas de docencia, investigación y extensión en los niveles de pregrado y postgrado. Como en el resto de las organizaciones, hasta ahora esto ha sido posible mediante el uso de redes de área local tradicionales que son esencialmente restringidas, por lo cual se intercambia información entre las estaciones de trabajo usualmente sin pensar en la seguridad de la información como un asunto crítico, por lo que es imprescindible la búsqueda de una alternativa que permita un intercambio de información de manera segura para los usuarios y sistemas de las distintas dependencias. Actualmente una de las soluciones más convenientes es lo que se conoce como red privada virtual o VPN (Virtual Private Network), tecnología que permite un acceso seguro a los servicios de una organización como la Universidad a través de una red insegura como Internet. Las redes privadas virtuales se implementan usando protocolos especiales de seguridad que permiten a los usuarios obtener acceso a servicios de carácter privado. Mediante estos protocolos todas las conexiones de red serán encaminadas a través de un enlace seguro. Esta comunicación está cifrada, por lo que se garantiza la confidencialidad e integridad de los datos transmitidos. Antes de establecer el túnel se requiere la autenticación del usuario, asegurando que los datos serán transmitidos o recibidos desde dispositivos remotos autorizados. El objetivo de esta investigación consiste en desarrollar una propuesta de diseño de una solución VPN entre el campus Caracas y las dependencias extramuros conectadas a la red de datos corporativa de la Universidad Central de Venezuela, para lo cual este documento ha sido estructurado en cuatro capítulos: En el Capítulo 1 se presenta el problema, la justificación y se definen los objetivos logrados y el alcance del Trabajo Especial de Grado para finalmente mencionar los factores que limitaron el desarrollo del mismo. En el Capítulo 2 se provee un conjunto de definiciones asociadas a las Redes Privadas Virtuales, así como se describen los diversos elementos técnicos que influyen en su funcionamiento y las características de los protocolos más importantes de esta tecnología. En el Capítulo 3 se presenta la metodología de investigación utilizada, y en atención a esta modalidad de investigación, se introducen cinco fases en el estudio a fin de cumplir con los requisitos involucrados en este proyecto. En la fase 1 se realiza una descripción de la

9

red corporativa de datos de la UCV y sus dependencias extramuros; en la fase 2 se plantean las consideraciones de diseño para implementar una VPN; en la fase 3 se desarrollan las propuestas de diseño de conexiones VPN atendiendo a los resultados de la fase anterior y evaluando las opciones y tecnologías existentes que mejor se adaptan a los requerimientos planteados por la Universidad; en la fase 4 se implementan los escenarios de prueba de cada una de las tecnologías utilizadas. Por último, en la fase 5 se selecciona la propuesta de diseño VPN evaluando ciertas características comunes y aspectos críticos, dando una respuesta viable al problema planteado. Para finalizar, se cierra este estudio con un conjunto de conclusiones y recomendaciones que deben tomarse en cuenta si se desea continuar con la implementación exitosa de este proyecto.

10

2. El problema

En este capítulo se describe la necesidad de diseñar una topología de red VPN, para resolver el problema abordado en el Trabajo Especial de Grado. Se delimitará y justificará el problema que será objeto de estudio así como los objetivos tanto generales como específicos que determinen el alcance del mismo.

2.1. Planteamiento del problema

La UCV cuenta con dependencias de diversa complejidad y dimensiones, cada una de las cuales requiere mantener una relación directa con las dependencias centrales, facultades y entre sí. La mayor parte de estas dependencias se interconectan con la red corporativa de datos a traves de enlaces que permiten la transmisión de datos críticos para la institución, como activos de información entre los que se encuentran los sistemas administrativos (nómina y contabilidad) y los sistemas académicos (sistema de control de estudios y de educación a distancia). Estos enlaces se hallan en un ambiente sujeto a vulnerabilidades, que puede despertar la curiosidad de algunas personas que se dedican a atacar servidores y redes para obtener información crítica, por lo que es importante garantizar la seguridad durante la transmisión de datos con el fin de proporcionar confidencialidad e integridad. Además de esto, la red debe estar disponible permanentemente y debe permitir añadir nuevos servicios y nuevos usuarios en una forma fácil y segura. También debe proporcionar confiabilidad mediante la entrega de mensajes y servicios sin demora o interrupciones y a un costo razonable. Actualmente no se dispone de mecanismos que permitan a los usuarios de las dependencias extramuros establecer conexiones seguras a la red de datos de la UCV, lo que trae como consecuencia el estudio de alternativas que permitan a los individuos y a los sistemas mantenerse comunicados de manera segura. Cualquier solución que se tome en cuenta dentro de la institución debe requerir una inversión pequeña, que no amerite mucho personal de soporte y que a su vez proporcione portabilidad y escalabilidad. Considerando que existen tecnologías mediante las cuales pueden ofrecerse alternativas viables para la prestación de servicios de datos de manera segura al personal de la UCV fuera del campus universitario, se plantea la necesidad de proponer un diseño para la implementación de la tecnologia VPN entre el campus Caracas y las dependencias extramuros de la UCV.

2.2. Justificación

Si bien la importancia que representan las dependencias extramuros de la UCV es de tal magnitud que es preciso mantener un estrecho vínculo de comunicación entre estas con las dependencias centrales y facultades, también es cierto que existe una carencia de

11

protección de los datos y sistemas de la universidad que son vulnerables a posibles ataques, que entre otras cosas pueden estar destinados a fraude, sabotaje y daños. La incorporación de la seguridad de la información es una necesidad real que presenta hoy en día la institución, por lo que es imprescindible la búsqueda de una solución que continúe brindando los servicios tradicionales a los que están acostumbrados los usuarios y que pueda incorporar nuevas características que se traduzcan en un aumento de la productividad y eficiencia del personal. Por otra parte, en los últimos años se ha venido observando una tendencia clara hacia la adopción de las tecnologías VPN por parte de instituciones de educación superior a nivel mundial [14], con la finalidad de proteger los activos informáticos y mejorar la prestación de los servicios de red que ofrecen a toda la comunidad universitaria. En este contexto, la presente investigación se justifica en los siguientes puntos:

Proporcionar una conexión segura desde las dependencias extramuros a ciertos recursos internos de la universidad, concibiendo un ambiente de trabajo virtualmente integrado y transparente para los usuarios.

Brindar un ambiente protegido para el acceso y uso de las aplicaciones críticas de la institución, como son los sistemas administrativos, académicos y los servicios corporativos, además de garantizar su continuidad e integridad operativa.

Resaltar la importancia que representan las dependencias extramuros de la UCV para el desarrollo de las diferentes actividades de docencia, investigación y extensión.

2.3. Objetivos

A continuación se precisan el conjunto de objetivos que orientarán las líneas de acción y sus límites en el presente estudio.

2.3.1. Objetivo general Elaborar una propuesta de diseño de una solución VPN entre el campus Caracas y las dependencias extramuros conectadas a la red de datos de la Universidad Central de Venezuela para proporcionar protección de sistemas e información sensible de la institución.

12

2.3.2. Objetivos específicos Para el logro del objetivo general se plantearon los siguientes objetivos específicos:

Investigar las características técnicas de las tecnologías VPN existentes, con el fin de evaluar su aplicación en el diseño de una solución VPN entre el campus Caracas de la UCV y sus dependencias extramuros.

Realizar el levantamiento de información del ambiente de la red corporativa de datos de la UCV.

Proponer consideraciones de diseño de una VPN tomando en cuenta el perfil de la red corporativa de datos de la UCV.

Plantear diferentes propuestas de solución VPN basadas en las tecnologías existentes y en las consideraciones de diseño señaladas.

Implementar los escenarios de prueba correspondientes a las propuestas de solución VPN presentadas.

Seleccionar la propuesta de solución VPN que mejor se adapte según las consideraciones de diseño planteadas.

2.4. Alcances

Se analizaron las tecnologías de VPN existentes con el fin de diseñar un esquema de seguridad en VPN que facilite y mejore la transmisión de datos de manera segura entre el campus Caracas y las dependencias extramuros conectadas a la red corporativa de datos de la UCV. El propósito es proveer una base preliminar para su futura implementación.

Este estudio contempló sólo aquellas dependencias extramuros conectadas con enlaces dedicados a la red de datos de la UCV y ubicadas físicamente en la Gran Caracas, entre las que se encuentran Centro Comercial Los Chaguaramos, IBE/ICTA (Instituto de Biología Experimental/Instituto de Ciencias y Tecnología de Alimentos), CENAMB (Centro de Estudios Integrales del Ambiente), CENDES (Centro de Estudios del Desarrollo), Escuela de Enfermería, Escuela Vargas y CDCH (Consejo de Desarrollo Científico y Humanístico). La propuesta se basó en el uso de los recursos tecnológicos con los que cuenta la UCV, tomando en cuenta inicialmente los enlaces con la tecnología MetroEthernet.

13

3. Marco teórico

Este capítulo se centrará en la presentación de las redes privadas virtuales como una solución de seguridad y de alta escalabilidad. Seguidamente se describirán las arquitecturas utilizadas en las VPN y también las diferentes tecnologías que existen en la actualidad, así como sus ventajas y desventajas.

3.1. Definición de VPN

Una red privada virtual, por sus siglas en inglés VPN (Virtual Private Network), es una tecnología que permite una extensión de la red local sobre una red pública imitando un vínculo privado punto a punto [10], como se ilustra en la Figura 2.11. Esta red pública o compartida comúnmente es Internet.

Figura 2.1: Conexión VPN.

Una manera de construir VPNs es estableciendo túneles virtuales entre los dos extremos. En este caso, un túnel es la ruta de información lógica que representa una transferencia segura a través del cual viajan los paquetes encapsulados de un equipo a otro2, como se muestra en la Figura 2.23. Para los usuarios de origen y destino, el túnel suele ser transparente y aparece simplemente como otra conexión punto a punto en la ruta de acceso a la red. Los usuarios desconocen los routers, switches, servidores proxy u otros gateways de seguridad, que pueda haber entre los extremos del túnel.

1 http://technet.microsoft.com/es-es/library/cc776079(WS.10).aspx 2 http://technet.microsoft.com/es-es/library/cc775944(WS.10).aspx 3 http://technet.microsoft.com/es-es/library/cc786563(WS.10).aspx

14

Figura 2.2: Túnel VPN.

El proceso de encapsulamiento se efectúa a la entrada del túnel y consiste en la adición al paquete original de un header (cabecera) que contiene la dirección IP pública de la red remota. Una vez recibido el nuevo paquete por el dispositivo de enrutamiento propietario de la IP pública de destino, éste retira el header adicionado anteriormente y entrega el paquete original a la estación destino identificada por la IP privada. La tecnología de VPN conforma un canal de comunicación seguro para oficinas remotas, usuarios móviles y socios comerciales que permitirá trabajar al usuario como si estuviera en la misma red local.

3.2. Elementos de una VPN

Una conexión VPN consta de los siguientes elementos, que se pueden observar en la Figura 2.34:

Servidor VPN: Un equipo que acepta conexiones VPN y puede configurarse para proporcionar acceso a toda la red o restringir el acceso sólo a sus propios recursos.

Cliente VPN: Un equipo que inicia una conexión segura a un servidor VPN. Un cliente VPN puede ser un equipo individual o un router.

Túnel: La parte de la conexión en la que se encapsulan los datos.

Conexión VPN: La parte de la conexión en la que se cifran los datos.

Protocolos de túnel: Los protocolos utilizados para administrar túneles y encapsular datos privados. Los datos que se envían por el túnel también deben estar cifrados.

Datos en túnel: Los datos que normalmente se envían a través de un vínculo punto a punto privado.

Conjunto de redes públicas o privadas de tránsito: La red compartida o privada que atraviesan los datos encapsulados. El conjunto de redes públicas o privadas de tránsito puede ser Internet o una intranet privada basada en IP (Internet Protocol).

4 http://technet.microsoft.com/es-es/library/cc776079(WS.10).aspx

15

Figura 2.3: Elementos de una VPN.

3.3. Tipos de VPN

De manera general, los tipos de VPN describen los dispositivos que se encuentran involucrados en la conexión [10]. Existen cuatro tipos de VPN: sitio-a-sitio, acceso remoto, firewall y usuario-a-usuario.

3.3.1. VPN Sitio-a-Sitio (Site-to-Site VPN) Una VPN sitio-a-sitio utiliza una conexión en modo túnel entre dispositivos VPN (gateway VPN) para proteger el tráfico entre dos o más sitios o localidades. Las conexiones sitio-a-sitio también son conocidas como conexiones L2L (LAN-to-LAN). Con este tipo de conexiones, un dispositivo central ubicado en cada localidad provee protección al tráfico entre sitios. Este proceso de protección, así como la red de transporte ubicada entre los dos dispositivos VPN, es transparente para el dispositivo final en los dos sitios.

3.3.2. VPN de Acceso Remoto o VPDN (Virtual Private Dial-up Network) Es uno de los modelos más usados, donde los usuarios remotos acceden a la red corporativa, típicamente desde distintas ubicaciones (oficinas comerciales, domicilios, hoteles, etc.). Para ello se deben tomar en cuenta ciertos aspectos de seguridad en los extremos de la comunicación, tales como el cifrado y uso de contraseñas. Los requerimientos de seguridad para los servicios VPDN nunca son tan altos como los requerimientos para las comunicaciones sitio-a-sitio. Actualmente la mayoría de los servicios VPDN están implementados sobre IP o usando el backbone privado de un proveedor de servicio. Los protocolos usados para implementar este servicio sobre IP incluyen L2F (Layer 2 Forwarding) o L2TP (Layer 2 Transport Protocol), entre otros, que serán descritos más adelante [6].

3.3.3. VPN Firewall Las VPN basadas en firewall por lo general son sólo módulos que se añaden al firewall que se esté ejecutando. Habitualmente tienen muchas funciones necesarias para la implementación de VPN como la autenticación, autorización y amplias funciones de conexión, que simplifican la supervisión de lo que sucede [10]. Estas VPN refuerzan también al sistema operativo del host porque inhabilitan o eliminan servicios innecesarios que son susceptibles a ser atacados. La mayoría tiene una interfaz adicional, llamada

16

interfaz DMZ (Demilitarized Zone), con sus propios controles de acceso. La DMZ permite un acceso controlado a los servidores, proxies y otros servicios en un entorno que se puede comprometer sin afectar a la seguridad de la red interna.

3.3.4. VPN Usuario-a-Usuario (User-to-User VPN) Una VPN de tipo usuario-a-usuario es básicamente una conexión VPN entre dos dispositivos finales. Este tipo de conexión se implementa cuando se necesita proteger un tipo de tráfico específico entre dispositivos determinados.

3.4. Topologías de VPN

Desde una perspectiva de diseño, a continuación se describen varias de las topologías implementadas en una VPN. Estas topologías incluyen punto-a-punto, hub-and-spoke, y fully meshed.

3.4.1. Punto-a-Punto (Point-to-Point) Existen dos tipos básicos de conexiones VPN punto-a-punto:

Dispositivo-a-Dispositivo (Device-to-Device).

Red-a-Red (Network-to-Network).

3.4.2. Dispositivo-a-Dispositivo (Device-to-Device) Una conexión VPN dispositivo-a-dispositivo es una VPN de tipo usuario-a-usuario, donde sólo dos dispositivos están involucrados en la VPN [10]. Esta topología es usualmente implementada cuando sólo un tipo de tráfico específico entre dos dispositivos necesita ser protegido. Una de las preocupaciones de las conexiones de dispositivo-a-dispositivo es que agregan una carga adicional sobre el dispositivo VPN final, como se puede observar en la Figura 2.4 [10].

Figura 2.4: Conexión dispositivo-a-dispositivo.

17

3.4.3. Red-a-Red (Network-to-Network) Una conexión VPN red-a-red podría ser considerada como una VPN de tipo L2L. Con una conexión red-a-red, dos gateways VPN proporcionan protección al tráfico entre dos o más redes. Una ventaja de este tipo de conexión es que el tráfico de varios dispositivos puede ser protegido por una misma conexión VPN. Además, se puede escoger un dispositivo apropiado como gateway VPN para manejar la sobrecarga y el procesamiento del tráfico VPN, quitando este trabajo a los clientes finales. La Figura 2.5 [10], muestra una topología red-a-red.

Figura 2.5: Conexión red-a-red.

Las VPN red-a-red se pueden dividir en dos categorías:

Fully-Meshed: En una red VPN fully-meshed todos los dispositivos o redes VPN se encuentran conectados entre sí. La parte izquierda de la Figura 2.6 [10], muestra un ejemplo de un diseño fully-meshed, conectando múltiples redes entre sí. Una ventaja de este diseño es que un dispositivo o red puede enviar tráfico directamente a través de una VPN hasta un destino remoto sin tener que implementar más conexiones VPN. Sin embargo, la principal desventaja de esta solución es la escalabilidad.

Hub-and-Spoke (Partially-Meshed): En este diseño, no todo dispositivo VPN tiene una conexión con otros dispositivos VPN, como se muestra en la sección derecha de la Figura 2.6. El diseño hub-and-spoke es común en redes corporativas, donde el hub es típicamente la empresa y los spokes son las oficinas remotas. Este es el diseño que mejor se adapta cuando los spokes necesitan comunicarse con los recursos ubicados en el hub; sin embargo, no es muy escalable cuando los spokes necesitan comunicarse entre sí.

18

Figura 2.6: Diseños de redes VPN fully/partially-meshed.

3.5. Categorías de VPN

Cada organización tiene su propia clasificación. Cisco Systems [6] define tres categorías básicas que describen dónde es implementada una VPN: intranet, extranet e Internet.

3.5.1. Intranet Una VPN intranet conecta recursos de la misma empresa a través de la infraestructura de la compañía ofreciendo altos niveles de seguridad y aislamiento de zonas y servicios de la red interna. También requieren garantía de calidad de servicio para los procesos de misión crítica. Las VPN para comunicaciones intranet son usualmente implementadas con tecnologías como Frame Relay, MetroEthernet o ATM (Asynchronous Transfer Mode). Un ejemplo clásico es un equipo VPN que proporcione autenticación y cifrado a la información de un servidor de nóminas de sueldo, haciendo posible que sólo el personal autorizado pueda acceder a la misma.

3.5.2. Extranet Una VPN extranet conecta recursos de una empresa a otra mediante el uso de dispositivos de seguridad dedicados, como firewalls o técnicas de cifrado. Estas comunicaciones pueden tener requerimientos menos estrictos de calidad de servicio, por lo que hacen que Internet sea el medio más adecuado para las comunicaciones inter-organizacionales ya que permite eliminar los costosos enlaces punto-a-punto tradicionales.

3.5.3. Internet Una VPN Internet utiliza una red pública como backbone para transportar tráfico VPN entre dos dispositivos. Por ejemplo, se podría utilizar Internet para conectar dos sitios entre sí (conexión sitio-a-sitio), o tener usuarios de acceso remoto usando su ISP (Internet Service Provider) local para conectarse a la red corporativa a través de una conexión VPN.

19

3.6. Componentes de una conexión VPN

En esta sección se describirán los componentes de una VPN tradicional. No todas las implementaciones de VPN incluirán todos estos componentes. Dependerá de las necesidades de seguridad de la empresa determinar cuál implementación de VPN (o implementaciones) posee los componentes necesarios para cubrir todos sus requerimientos de seguridad [10].

Autenticación: Asegura que el intercambio de información se lleve a cabo con el usuario o dispositivo correcto, es decir, verifica la identidad de los usuarios. Se realiza normalmente al inicio de una sesión, y luego aleatoriamente durante el transcurso de la sesión, para asegurar que no haya algún tercer usuario no autorizado. La mayor parte de los sistemas de autenticación de dispositivos usados en VPN están basados en sistema de claves compartidas. También se utilizan las firmas digitales o certificados.

Integridad: Garantiza que los datos enviados no han sido alterados, a través del uso de algoritmos de hash como MD5 (Message Digest Algorithm 5) y el SHA (Secure Hash Algorithm).

Confidencialidad: Se garantiza a través del cifrado de los datos. El cifrado protege los datos transportados para que no sean interpretados por nadie más que sus destinatarios. Esta tarea se realiza con algoritmos de cifrado como DES (Data Encryption Standard), 3DES (Triple DES), AES (Advanced Encryption Standard), entre otros. En las redes virtuales, el cifrado debe ser realizado en tiempo real, de esta manera las claves son válidas únicamente para la sesión usada en un determinado momento.

No repudio: Involucra dos componentes, autenticación y contabilización (accounting). La autenticación se refiere a que los mensajes deben estar firmados, y quien los firma no puede negar su autoría [14]. La contabilización es el registro de la sesión VPN, esto puede incluir la identidad de los dispositivos que establecieron la conexión, su duración, la información transmitida a través de ella, y así sucesivamente. Esto puede ser utilizado posteriormente para detectar ataques de acceso y para propósitos de gestión de la conexión.

Método de Encapsulado: Define cómo la información del usuario será encapsulada y transportada a través de la red, así como las aplicaciones o protocolos contenidos en la carga útil del paquete VPN.

Además de garantizar los aspectos de seguridad mencionados anteriormente, se debe cumplir con:

Soporte a protocolos múltiples: Manejo de los protocolos comunes utilizados en las redes públicas, como IP, IPX (Internetwork Packet Exchange), etc.

Administración de direcciones: Asignación de una dirección al cliente en la red privada, asegurando que las direcciones privadas se conserven así.

20

Administración de claves: Las claves de codificación se deben generar y renovar periódicamente.

3.7. Ventajas de una VPN

Bajo costo: Una forma de reducir costo en las VPN es eliminando la necesidad de largos enlaces dedicados de costo elevado, líneas alquiladas, equipos de acceso dial-up, etc.

Escalabilidad: Las redes VPN son arquitecturas de red más escalables y flexibles que las WAN (Wide Area Network) tradicionales, debido a que permiten a las corporaciones agregar o eliminar sus sistemas localizados remotamente, usuarios móviles o aliados comerciales de forma fácil y poco costosa en función de las necesidades del negocio.

Compatibilidad: Como aceptan la mayor parte de los protocolos de red más comunes, incluidos TCP/IP (Transmission Control Protocol/Internet Protocol), IPX (Internetwork Packet Exchange) y NetBEUI (NetBIOS Extended User Interface), las VPN puede ejecutar de forma remota cualquier aplicación que dependa de estos protocolos de red específicos.

Movilidad: Las VPN utilizan Internet para comunicarse con la intranet por lo que el acceso puede llevarse a cabo prácticamente desde cualquier lugar que tenga acceso a Internet.

Seguridad: Utilizan mecanismos para transmitir información a través de redes inseguras, lo que garantiza la confidencialidad, integridad y autenticación de los datos transmitidos.

Administración centralizada: Algunos proveedores soportan la característica de administración centralizada de sus productos VPN. Esto representa una fuerte característica de seguridad y un buen mecanismo para la resolución de problemas.

Prioridad de tráfico: Algunos proveedores ofrecen la funcionalidad de priorizar tráfico en sus productos VPN. Esto agrega gran flexibilidad a la corporación en cuanto a la utilización de los enlaces de Internet, debido a que se puede decidir en qué orden se preserva el ancho de banda según el tipo de tráfico permitido y de acuerdo a su importancia.

Transparencia: Interconectar distintos equipos es transparente para el usuario final.

Simplicidad: Son de fácil instalación y uso en cualquier equipo.

Control de Acceso: Basado en políticas de la organización.

3.8. Desventajas de una VPN

El rendimiento de la red basada en VPN es dependiente del rendimiento de Internet, se puede garantizar un ancho de banda pero no su rendimiento. Una sobrecarga de Internet puede afectar negativamente el rendimiento de toda la VPN.

21

Debido a las distintas soluciones disponibles para implementar una VPN, se pueden encontrar incompatibilidades entre las usadas en los distintos nodos de la misma. Además, no todos los equipos actualmente instalados poseen facilidades para realizar VPNs y se rigen por distintas normas y estándares.

El tiempo de respuesta no está garantizado y, por lo tanto, no son recomendables para aplicaciones críticas.

Son propensas a ataques de negación de servicio, dado que los túneles están sobre Internet.

La posibilidad de pérdida de paquetes en tránsito es alta.

3.9. Implementaciones de VPN

Actualmente se dispone de una gran variedad de protocolos para VPN, cada uno con sus ventajas y desventajas en cuanto a los parámetros de seguridad, facilidad, mantenimiento y tipos de clientes soportados. En esta sección se describen los más utilizados.

3.9.1. PPTP (Point-to-Point Tunneling Protocol) PPTP es un protocolo normalizado por la IETF (Internet Engineering Task Force) [8] y desarrollado originalmente por Microsoft como una solución de acceso remoto para permitir transferencias seguras desde un cliente, a través de una red pública, a un servidor Microsoft. PPTP es una extensión del PPP (Point-to-Point Protocol) lo que permite encapsular múltiples protocolos como NetBEUI, IPX/SPX (Internetwork Packet Exchange/Sequenced Packet Exchange), etc., en un paquete IP, para luego poder encaminarlos a través de un túnel VPN. La autenticación PPTP está basada en el sistema de acceso de Windows, en el cual todos los clientes deben proporcionar un par usuario/contraseña. En el caso de Microsoft, la autenticación de clientes PPTP soporta los protocolos CHAP (Challenge Handshake Authentication Protocol), MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol versión 2), y PAP (Password Authentication Protocol). Para el cifrado de los datos, PPTP utiliza MPPE (Microsoft Point-to-Point Encryption) donde sólo los extremos de la conexión comparten la clave. Esta clave es generada empleando el estándar RSA RC-4 (Rivest-Shamir-Adleman Rivest Cipher 4) a partir de la contraseña del usuario. La longitud de la clave puede ser 128 bits o 40 bits [16]. El establecimiento de conexiones PPTP se divide en tres fases que se describen a continuación:

Fase 1 PPTP: En la fase 1, se utiliza el LCP (Link Control Protocol) para iniciar la conexión. Esto incluye la negociación de parámetros de capa 2, tales como el uso de autenticación, cifrado con MPPE, entre otros protocolos.

Fase 2 PPTP: En la fase 2, el usuario es autenticado ante el servidor. PPP soporta cuatro tipos de autenticación: PAP, CHAP, MS-CHAPv1 y MS-CHAPv2.

22

Fase 3 PPTP: En la fase 3, son invocados los protocolos utilizados por la conexión de datos negociados durante la fase 1. Una vez completada la fase 3, los datos pueden ser enviados a través de la conexión PPP [10].

Componentes de PPTP PPTP se basa en una arquitectura cliente-servidor para conectividad de acceso remoto que involucra dos entidades, como se observa en la Figura 2.75.

El cliente es comúnmente referido como PAC (PPTP Access Concentrator). El PAC es responsable de establecer una conexión segura hacia un servidor y enviar los datos en paquetes PPP a través del túnel hacia el servidor.

El servidor es conocido como PNS (PPTP Network Server). El servidor toma los paquetes protegidos PPP que viajan a través del túnel, verifica la protección, descifra los paquetes, y reenvía la información de la carga útil PPP encapsulada, por ejemplo un paquete IP, al destino.

Figura 2.7: Conexión PPTP.

El PAC es responsable de iniciar la conexión con el PNS, utilizando LCP para la negociación, y participando en el proceso de autenticación de PPP. El PNS es responsable de autenticar al PAC y de enrutar el tráfico encapsulado del PAC hacia otras localidades. Funcionamiento de PPTP PPTP es un protocolo orientado a conexión, en donde el PAC y el PNS mantienen un estado de su comunicación. Dos conexiones son establecidas para la sesión: una conexión de control entre cada pareja PAC-PNS y una conexión de datos sobre la misma pareja PAC-PNS. Una vez que la sesión es establecida, el PAC y el PNS pueden utilizar GRE (Generic Routing Encapsulation) a través de la conexión de datos para transmitir el tráfico de usuario. Generalmente, la conexión de datos es llamada túnel. A continuación se describen ambas conexiones [10].


23

Conexión de control La conexión de control es una sesión TCP (Transmission Control Protocol) que mantiene control sobre la sesión e intercambia mensajes de información. La conexión de control es responsable del establecimiento, mantenimiento, y terminación del túnel PPTP. El PNS y el PAC establecen la conexión de control usando mensajes Start-Control-Connection-Request y Start-Control-Connection-Reply. Estos mensajes son también usados para intercambiar información básica entre los dos extremos del túnel. La conexión de control puede comunicar cambios entre las dos partes con un mensaje Set-Link-Info. Una sesión puede ser terminada por el PAC o por el PNS. La conexión de control es mantenida por mensajes de eco keep-alive. Esto asegura que una falla en la conectividad entre el PNS y el PAC pueda ser detectada anticipadamente. PPTP define un conjunto de mensajes enviados como datos TCP en la conexión de control entre un PNS y un PAC. La sesión TCP es establecida hacia el puerto 1723. El puerto origen es asignado a cualquier número de puerto que no esté siendo usado en el momento del establecimiento del túnel. Conexión de datos La conexión de datos o túnel transporta todos los paquetes PPP de la sesión de usuario. Utiliza una versión extendida de GRE como protocolo de transporte para los paquetes PPP. Este protocolo proporciona el envío, control de flujo y control de congestión de los paquetes PPP. Algunos de los parámetros que necesitan ser negociados son la asignación de dirección del PAC, el algoritmo de cifrado a usar, y el uso de compresión, de ser necesario. PPTP permite a los usuarios y a los ISPs crear varios tipos de túneles, basados en la capacidad del equipo del usuario final y en el soporte del ISP para implementar PPTP. De esta manera, el equipo del usuario final determina el lugar de terminación del túnel, bien sea en su equipo, si está ejecutando un cliente PPTP, o en el servidor de acceso remoto del ISP, si su equipo solo soporta PPP y no PPTP. Dado lo anterior, los túneles se pueden dividir en dos clases, voluntarios y permanentes. Los túneles voluntarios son creados por requerimiento de un usuario y para un uso específico. Los túneles permanentes son creados automáticamente sin la acción de un usuario y no le permite escoger ningún tipo de privilegio. En los túneles voluntarios, la configuración del mismo depende del usuario final, cuando se usan túneles de este tipo, el usuario puede simultáneamente acceder a Internet y abrir un túnel seguro hacia el servidor PPTP. En este caso el cliente PPTP reside en el equipo del usuario. Los túneles voluntarios proveen más privacidad e integridad de los datos que un

24

túnel permanente. La Figura 2.8 [5] muestra un escenario de túneles voluntarios creados desde dos clientes distintos a un mismo servidor PPTP a través de Internet.

Figura 2.8: Túneles voluntarios.

Los túneles permanentes son creados sin el consentimiento del usuario, por lo tanto, son transparentes para el mismo. El cliente PPTP reside en el RAS (Remote Access Server) del ISP al que se conectan los usuarios finales. En este caso la conexión del usuario se limita solo a la utilización del túnel PPTP, no hay acceso a la red pública (Internet) sobre la cual se establece el túnel. Un túnel permanente PPTP permite que múltiples conexiones sean transportadas sobre el mismo túnel. La Figura 2.9 [5] muestra un túnel permanente entre un servidor PPTP y por medio del cual van multiplexadas dos sesiones de clientes A y B.

Figura 2.9: Túneles permanentes.

Encapsulado de la carga útil PPTP encapsula los paquetes PPP en datagramas IP con un GRE header y un IP header, como se muestra en la Figura 2.10 [16]. En el IP header están las direcciones IP de origen y destino que corresponden al PAC y al PNS. Cuando los datagramas llegan al PNS, son desencapsulados con la finalidad de obtener el paquete PPP y descifrados de acuerdo al protocolo de red transmitido [16]. El paquete PPP contiene los datos del usuario.

25

IP Header

GRE Header

PPP Header

PPP Payload

Figura 2.10: Estructura de un paquete PPTP.

3.9.2. L2TP (Layer 2 Tunneling Protocol) L2TP fue diseñado y aprobado por un grupo de trabajo de la IETF [9] como una evolución y combinación de los protocolos PPTP y L2F (Layer-2 Forwarding) para corregir así las deficiencias de ambos.

L2TP es un protocolo orientado a conexión y utiliza PPP para encapsular los datos de usuario, permitiendo el envío de múltiples protocolos a través del túnel. A diferencia de PPTP, L2TP utiliza UDP como método de encapsulación tanto para el túnel de control como para el de datos de usuario. Mientras PPTP utiliza MPPE como método de cifrado, L2TP posee una solución más segura donde los paquetes L2TP son protegidos por ESP (Encapsulation Security Payload) de IPSec (IP Security) en modo túnel. Aunque puede utilizarse sin IPSec, L2TP por sí sólo no realiza cifrado y por eso debe apoyarse en otros métodos, es por esto que la mayoría de las implementaciones de L2TP incluyen IPSec [10].

L2TP es considerado como una solución de acceso remoto y consiste de dos dispositivos, un cliente y un servidor. Los túneles de datos y de control utilizados entre estos dos dispositivos usan la misma estructura de paquete, simplificando así su implementación. Al utilizar PPP para el establecimiento del enlace, L2TP aprovecha las ventajas de los procesos de autenticación y compresión de este protocolo, así como también permite la utilización de protocolos de autenticación como PAP, CHAP, MS-CHAP, RADIUS (Remote Authentication Dial-In User Server) [15] y servicios de autenticación actuales como EAP (Extensible Authentication Protocol) y sus derivados.

L2TP envía los paquetes por UDP al puerto 1701. La Figura 2.11 [15], contiene la estructura de un paquete L2TP, donde se encapsulan las tramas PPP con un L2TP header, un UDP header y IP header.

IP Header

UDP Header

L2TP Header

PPP Header

PPP Payload

Figura 2.11: Estructura de un paquete L2TP.

Trama PPP

Trama PPP

Cifrado

26

La configuracion de túneles L2TP consiste de dos pasos:

Establecimiento de la conexión de control para el túnel.

Establecimiento de sesión para la transmisión de los datos de usuario a través del túnel.

Al igual que en PPTP, existen dos tipos de túneles:

Voluntario: El equipo de usuario y el servidor son los puntos extremos del túnel.

Obligatorio: El equipo de usuario no es un punto extremo del túnel, en lugar de este, algunos otros dispositivos ubicados frente al equipo de usuario, como un RAS, actúan como punto extremo del túnel.

Con el túnel voluntario, el cliente de acceso remoto utiliza un software L2TP y crea una conexión con el servidor. Con el túnel obligatorio, otro dispositivo en nombre del usuario es responsable de establecer el túnel. El dispositivo que inicia el túnel es conocido como LAC (L2TP Access Concentrator). El servidor es llamado LNS (L2TP Network Server). Generalmente, los LAC son utilizados en situaciones donde una empresa no puede manejar las funcionalidades de L2TP en los equipos de usuario, y necesita contratar el servicio de L2TP VPN en un ISP. De esta manera los clientes establecerán una conexión PPP con el ISP y un dispositivo LAC dentro del mismo ISP será el encargado de enviar a través de un túnel el tráfico PPP a las oficinas corporativas.

El LAC tiene la capacidad de enviar tráfico hacia un destino particular, basado en el número telefónico o nombre de usuario. A través de cualquiera de estos dos métodos, el ISP sabrá qué conexión de túnel LNS utilizar (en el caso de que el ISP preste este servicio a múltiples clientes). El primer usuario que realice una llamada al ISP hará que el LAC plantee la creación de un túnel al LNS ubicado en la oficina corporativa de usuario. Todos los clientes de esta empresa se conectarán a través del mismo LAC utilizando el mismo túnel. Una vez que todos los usuarios se han desconectado del ISP, el LAC terminará el túnel con el LNS.

Como se mencionó anteriormente, el protocolo no posee cifrado de datos y para lidiar con esto L2TP puede ser colocado en la carga útil de un paquete IPSec, combinando las ventajas de seguridad que provee IPSec y los beneficios de la autenticación de usuario, asignación y configuración de direcciones de túnel y soporte a protocolos múltiples con PPP. Esta combinación es comúnmente conocida como L2TP sobre IPSec o L2TP/IPSec [10].

3.9.3. L2TP/IPSEC Debido a que L2TP utiliza IPSec como transporte, la conexión IPSec se establece entre el LAC y el LNS. Primero, debe ser construida una conexión de manejo de claves ISAKMP/IKE

27

(Internet Security Association and Key Management Protocol/Internet Key Exchange), luego debe establecerse una conexión de datos ESP en modo transporte. La información de L2TP es finalmente encapsulada en la carga útil de ESP. Mensajes de control L2TP L2TP utiliza una sola conexión para transmitir tanto información de control como datos de usuario. Tanto el LAC como el LNS usan el puerto UDP número 1701 como origen y destino. La estructura típica de un paquete de control L2TP se puede observar en la Figura 2.12 [10]. IPSec utiliza ESP en modo transporte para compartir mensajes y datos de usuario entre dispositivos. Cuando el LAC y el LNS necesitan establecer, mantener, o cerrar un túnel, la fase 2 de la conexión de datos ESP IPSec es utilizada. Se puede observar que el UDP header, el mensaje L2TP y el ESP trailer son cifrados por ESP y que opcionalmente puede utilizarse la autenticacion ESP para verificar que el origen de los paquetes y que los componentes ESP del paquete IP no han sido alterados.

IP Header

ESP Header

UDP Header

L2TP Message

ESP Trailer

ESP Authentication

Figura 2.12: Mensaje de control L2TP.

L2TP se apoya en UDP para asegurarse del envío de mensajes de control. Dentro del mensaje de control existe un campo de Next-Received, este campo funciona de la misma manera que el campo Acknowledgment del TCP header. Otro campo, Next-Sent, cumple la misma función que el campo Sequence Number del TCP header. Estos campos pueden ser usados para control de flujo y de secuencia de los mensajes de control y los paquetes de datos, por ende, cualquier mensaje de control Out-of-Sequence recibido es automaticamente eliminado. L2TP utiliza los mismos mensajes de control que utiliza PPTP, y como es orientado a conexión, el LNS y el LAC mantienen información de estado por cada llamada de túnel y control. Además de esto, cada sesión entre el LAC y el LNS tendrá un identificador de túnel único (tunnel-ID). Este identificador es empleado para diferenciar las distintas conexiones de túnel entre el LNS y los distintos LACs. Cuando el túnel es obligatorio, se le asigna un identificador de llamada o sesión único a cada sesión de usuario a través del túnel. Este es empleado para diferenciar a los distintos usuarios (sesiones PPP) que están usando el LAC para conectarse con el LNS a través del túnel. En caso de que el equipo de usuario cumpla las funciones del LAC, este será un solo valor de identificador de sesión.

Cifrado por ESP

Mensaje de control L2TP

28

Túnel de datos L2TP La Figura 2.13 [10], muestra el método de encapsulación utilizado para el tráfico de usuario a través de una conexión L2TP/IPSec. Se puede observar que los datos de usuario son encapsulados en paquetes PPP, y luego son adheridos los headers de L2TP y PPTP para sucesivamente ser encapsulados y protegidos en paquetes ESP.

IP Header

ESP Header

UDP Header

L2TP Header

PPP Header

PPP Payload

ESP Trailer

ESP Authentication

Figura 2.13: Túnel de datos L2TP.

Cuando un paquete L2TP/IPSec es recibido por el destino, el IP header es removido y la firma digital del paquete ESP es validada. Si la firma es válida, el contenido de L2TP es descifrado. El UDP header es procesado y el paquete L2TP es remitido a proceso L2TP del dispositivo. L2TP revisa los identificadores de túnel y de sesión para determinar el túnel L2TP específico que manejará el paquete. Una vez que el túnel es determinado, el PPP header es utilizado para identificar el tipo de información de la carga útil en el paquete PPP y remitir esta información encapsulada, por ejemplo, un paquete IP, a la pila de protocolos apropiada para su procesamiento. Dos situaciones comunes para L2TP/IPSec son la protección de comunicaciones entre clientes de acceso remoto y la red corporativa, y la protección de las comunicaciones entre sucursales. Clientes de acceso remoto con L2TP/IPSec

Un requisito habitual es proteger las comunicaciones entre los clientes de acceso remoto y la red corporativa a través de Internet.

Figura 2.14: Ejemplo de acceso remoto con L2TP/IPSec.

Túnel de datos L2TP

Cifrado por ESP

29

En el ejemplo de la Figura 2.146, el gateway remoto es un servidor que proporciona alta seguridad para la intranet corporativa. El cliente remoto representa un usuario itinerante que precisa obtener acceso frecuente a los recursos y la información de la red. El cliente utiliza un ISP para el acceso a Internet. L2TP se combina con IPSec para proporcionar un modo sencillo y eficaz de construir el túnel y proteger la información a través de Internet. Conectar sucursales con L2TP/IPSec Las grandes compañías suelen disponer de varias sucursales que necesitan comunicarse, por ejemplo, una oficina corporativa en Caracas y una sede en Maracay.

Figura 2.15: Ejemplo de conexión de sucursales con L2TP/IPSec.

En el ejemplo de la Figura 2.157, el router proporciona alta seguridad. Es posible que los routers utilicen una línea alquilada, acceso telefónico u otro tipo de conexión a Internet. La AS (Asociación de Seguridad) de IPSec y el túnel L2TP se establecen entre los routers, y permiten la comunicación segura a través de Internet.

3.9.4. GRE GRE es una tecnología VPN desarrollada originalmente por Cisco como un método para tomar paquetes de un protocolo, encapsularlos en paquetes IP, y transportarlos a través de una red IP sin tener que configurarla para que soporte protocolos adicionales. Tiene el identificador de protocolo 47 en el paquete IP [4]. GRE es un protocolo de capa 3 y puede encapsular protocolos como IP, IPX, entre otros. Los paquetes GRE que se utilizan para encapsular los datos tiene el formato que se muestra en la Figura 2.16 [4].

IP Header

GRE Header

Payload

Figura 2.16: Estructura de un paquete GRE.

El header de los paquetes GRE tiene el formato que se muestra en la Figura 2.17 [4]. La longitud mínima del GRE header es de 4 octetos.

6 http://technet.microsoft.com/es-es/library/cc739674(WS.10).aspx 7 http://technet.microsoft.com/es-es/library/cc739674(WS.10).aspx

30

0 1

2

3

4

5

8

13

16

32

C R K S s Recursion Control

Flags Version Protocol Type

Checksum (optional) Offset (optional)

Key (optional)

Sequence Number (optional)

Routing (optional)

Figura 2.17: GRE header.

Descripción de los campos

C: Presencia del campo de integridad de la trama o Checksum (1 bit). Si el valor es 1 los campos Checksum y Offset están presentes y contienen información válida.

R: Presencia del campo Routing (1 bit). Cuando el valor es 1 el campo Routing está presente y contiene información válida y los campos Checksum y Offset están presentes.

K: Presencia del campo Key (1 bit). Si el valor es 1 el campo Key existe y tiene información válida.

S: Presencia del campo Sequence Number (1 bit). Si el valor es 1 el campo sequence number existe y tiene información válida.

s: Campo Strict Source Route (1 bit). Se recomienda configurar su valor a 1 sólo si toda la información de enrutamiento está formada por rutas estrictas.

Recursion Control: (3 bits). Número de encapsulaciones recursivas permitidas. Por defecto cero.

Flags: (5 bits). Reservado. Por defecto cero.

Version: (3 bits). Versión del protocolo GRE. Debe ser cero.

Protocol Type: (16 bits). Indica el protocolo contenido en el paquete GRE. Para ello utiliza los mismos indicadores que Ethernet.

Checksum: (16 bits). Opcional. Contiene la suma en complemento a 1 de los datos y el GRE header.

Offset: (16 bits). Opcional. Indica el primer octeto a examinar dentro del campo routing para conocer la entrada de enrutamiento activa.

Key: (32 bits). Opcional. Contiene un número insertado por la parte encapsuladora del túnel que puede utilizar el destino para propósitos de comprobación del remitente correcto.

Sequence Number: (32 bits). Opcional. Contiene un número insertado por la parte encapsuladora del túnel que puede utilizar el destino para controlar el orden de los paquetes.

Routing: (Longitud variable). Opcional. Este campo consiste en una lista de rutas. GRE posee dos grandes desventajas. En primer lugar, desde la perspectiva de los productos Cisco, GRE sólo funciona con routers Cisco. En segundo lugar, GRE no realiza tareas de autenticación, cifrado ni chequeo de integridad. Debido a estas dos limitaciones, GRE no es usado como una tecnología VPN completa; sin embargo, puede combinarse con otras soluciones, como IPSec, para crear una solución VPN más robusta y escalable.

31

3.9.5. IPSec IP Security o IPSec, es un conjunto de estándares que proveen las siguientes características claves de seguridad a la capa de red entre dos pares de dispositivos [10]:

Confidencialidad: Utilizando el cifrado para proteger los datos de ataques de escuchas; soporta algoritmos como DES, 3DES y AES.

Integridad y autenticación de los datos: A través de funciones HMAC (Hash-based Message Authentication Code) incluyendo MD5 y SHA-1.

Autenticación de dispositivos: Es soportada con claves pre-compartidas simétricas, claves pre-compartidas asimétricas y certificados digitales.

La IETF define los estándares para IPSec en varios RFCs (Request For Comments). IPSec es comúnmente utilizado en las redes IPv4 e IPv6 de hoy en día, ya que provee protección a nivel de la capa de red entre dispositivos o redes, y es un estándar abierto [1]. Las dos grandes agrupaciones de estándares que IPSec utiliza son:

ISAKMP (Internet Security Association and Key Management Protocol)/IKE (Internet Key Exchange): Estos estándares son usados para crear una conexión de gestión segura, determinan información clave para el cifrado, y utilizan firmas para la autenticación de dicha conexión para que los dos dispositivos IPSec puedan compartir mensajes entre sí.

AH (Authentication Header) y ESP (Encapsulation Security Payload): Estos estándares son utilizados para proveer protección de los datos de usuario. Pueden proveer confidencialidad (sólo ESP), integridad de los datos, autenticación de origen de los datos, y servicios de anti-replay.

Normalmente, ambas partes de la comunicación requieren una configuración de IPSec (denominada directiva IPSec) para establecer las opciones y los parámetros de seguridad que permitirán que ambos sistemas acuerden el modo de proteger el tráfico entre ellos. Cada equipo trata la seguridad en su extremo respectivo y supone que el medio a través del cual tiene lugar la comunicación no es seguro. La seguridad ofrecida por el uso de IPSec es críticamente dependiente en muchos aspectos del entorno de operaciones en el que se ejecuta la implementación de IPSec. Por ejemplo, defectos en la seguridad en el sistema operativo, prácticas y protocolo de manejo de sistemas descuidado, entre otros aspectos, pueden todos degradar la seguridad proporcionada por IPSec. Modos de conexión IPSec

IPSec fue proyectado para proporcionar seguridad en modo transporte o extremo a extremo del tráfico de paquetes, en el que los equipos de los extremos finales llevan a

32

cabo el proceso de seguridad, o en modo túnel o gateway a gateway en el que la seguridad del tráfico de paquetes es proporcionada a varias máquinas, incluso a toda la red de área local, por un único nodo. A continuación se describen los modos de conexión IPSec8. Modo transporte En el modo transporte sólo la carga útil del paquete IP es cifrada. El enrutamiento permanece intacto, ya que no se modifica ni se cifra el IP header. Las capas de transporte y aplicación están siempre aseguradas por un hash, de forma que no pueden ser modificadas. El modo transporte se utiliza para comunicaciones end-to-end. Modo túnel En el modo túnel, todo el paquete IP (es decir, los datos más los headers del mensaje) es cifrado. Debe ser entonces encapsulado en un nuevo paquete IP para que funcione el enrutamiento. El modo túnel se utiliza principalmente para comunicaciones sitio-a-sitio (túneles seguros entre routers o firewalls). El motivo principal por el que se utiliza el modo de túnel IPSec es la interoperabilidad con otros routers, gateways o sistemas finales que no son compatibles con los túneles de VPN L2TP/IPSec o PPTP. Protocolos de seguridad IPSec Los servicios IPSec son llevados a cabo mediante el uso de protocolos de seguridad, así como también mediante un conjunto de protocolos necesarios para la gestión de claves criptográficas que se definirán en la siguiente sección [15]. AH (Authentication Header) El protocolo AH proporciona únicamente mecanismos de autenticación. Como se ilustra en la Figura 2.18, en modo transporte los datos de autenticación AH son insertados entre el IP header y los datos referentes al paquete de nivel superior (TCP, UDP, ICMP) [11] [3].

IP Header

AH Header

User Data (IP Packet, TCP or UDP Segment, etc.)

Figura 2.18: Paquete IPSec con el AH header.

AH tiene asignado el número de protocolo 51. Éste es el número que lleva el IP header en el campo Protocol, en lugar de los valores 6 o 7 que corresponden a TCP y UDP, respectivamente.


33

En la Figura 2.19 se pueden observar los campos del AH header.

Next Header Payload Length Reserved

Security Parameter Index (SPI)

Sequence Number

Authentication

Figura 2.19: AH header.

El AH header está formado por los siguientes campos:

Un campo Next Header el cual identifica el protocolo que se está llevando, como por ejemplo TCP.

El campo Payload Length indica el tamaño del AH header.

El campo Security Parameter Index (SPI) es utilizado para identificar la asociación de seguridad con la que se protege el paquete.

Con el Sequence Number se provee protección contra ataques de réplicas de los paquetes.

El campo Authentication es de tamaño variable, y contiene el Integrity Check Value (ICV) o Message Authentication Code (MAC) para ese datagrama, utilizando una función hash que puede ser MD5 o SHA.

En la Figura 2.20 [15], se puede observar el mecanismo de autenticación AH en donde se tiene un mensaje original al cual se le aplica una función de hash con una clave y se obtiene un MAC y esa información es colocada en el AH header para posteriormente agregarlo entre el IP header y la carga útil de IP. Luego cuando el mensaje es recibido el receptor le aplica un hash con la misma clave y obtiene el MAC del mensaje recibido y lo compara con el MAC que se encuentra en el header de AH y si son iguales el paquete es autenticado y en caso contrario se asume que el paquete está alterado.

34

Figura 2.20: Mecanismo de autenticación AH.

El modo de túnel AH encapsula un paquete IP con un AH header y un nuevo IP header y firma todo el paquete para asegurar su integridad y autenticación, como se muestra en la Figura 2.21.

New IP Header

AH Header

IP Header


Figura 2.21: Un datagrama IPSec-AH en modo túnel.

ESP (Encapsulation Security Payload) El protocolo ESP proporciona confidencialidad, autenticación, integridad y protección contra réplica para la carga útil IP. ESP hace uso de una amplia variedad de algoritmos de cifrado entre los cuales se encuentran DES, 3DES y Blowfish. La carga útil IP está cifrada para su confidencialidad y firmada para garantizar su integridad y autenticación. Al recibirse, una vez completado el proceso de comprobación de la integridad, se descifra la carga de datos del paquete [12]. ESP trabaja a nivel de la capa de enlace de datos y se identifica con el número de protocolo 50. En modo transporte, el ESP header se coloca delante de la carga IP, y tras ella se incluye un ESP trailer y un ICV, como se ilustra en la Figura 2.22.

Firmado por AH header

Paquete IP

35

IP Header

ESP Header


ESP Trailer

ICV

Figura 2.22: Paquete IPSec con ESP header y ESP trailer.

El IP header no se firma y no está necesariamente protegido frente a modificaciones. Para proporcionar integridad de datos y autenticación al IP header, puede utilizarse ESP conjuntamente con AH. En la Figura 2.23 se puede observar el ESP header.

Security Parameter Index (SPI)

Sequence Number Encrypted Data

ICV


Padding Padding Length Next Header

Figura 2.23: Campos del paquete ESP.

A continuación se describen los campos del paquete ESP.

El campo SPI identifica la asociación de seguridad correcta para la comunicación cuando se utiliza junto con la dirección de destino y el protocolo de seguridad (AH o ESP). El receptor utiliza este valor para determinar la asociación de seguridad con la que se debe identificar este paquete.

El Sequence Number es un número de 32 bits que indica el número de paquetes enviados a través de la asociación de seguridad para una comunicación dada. El sequence number no se puede repetir mientras perdure la asociación de seguridad. El receptor comprueba este campo para asegurarse de que no ha recibido ya un paquete para una asociación de seguridad con este número; si se recibió alguno, se rechazará este paquete.

El ESP trailer contiene el campo de Padding en donde se coloca un valor entre 0 y 255 bytes y asegura que la carga cifrada junto con los bytes de relleno se ajuste a los límites de bytes que requieren los algoritmos de cifrado.

El campo Padding Length indica la longitud en bytes del campo Padding. El receptor utiliza este campo para eliminar los bytes de relleno una vez descifrada la carga que los contiene.

El campo Next Header identifica el tipo de datos de la carga, por ejemplo TCP o UDP.

El ESP Trailer contiene el ICV que se utiliza para comprobar la autenticación del mensaje y su integridad. El receptor calcula el valor del ICV y lo compara con este valor (calculado por el origen) para comprobar la integridad. El ICV se calcula para el ESP header, los datos de la carga y el ESP trailer.

ESP trailer

Data

ESP

Firmado por ICV

Cifrado con el ESP Header

36

El modo túnel ESP encapsula un paquete IP con un ESP header, un nuevo IP header y un ICV, como se ilustra en la Figura 2.24. Debido al nuevo header agregado al paquete para el túnel, todo lo que se encuentra a partir del ESP header está firmado, excepto el ICV. El IP header original se coloca después del ESP header. El paquete entero se anexará con un ESP trailer antes del cifrado. Todo lo que sigue al ESP header, salvo el ICV, se cifra. Esto incluye el IP header original, que ahora se considera parte de los datos del paquete.

New IP Header

ESP Header

IP Header


ESP Trailer

ICV

Figura 2.24: Un paquete IPSec-ESP en modo túnel.

Toda la carga ESP se encapsula dentro del nuevo header de túnel, el cual no se cifra. La información del nuevo header de túnel sólo se utiliza para enrutar el paquete desde el origen hasta el destino. Si el paquete se envía a través de una red pública, se enrutará hacia la dirección IP del servidor de túnel de la intranet receptora. En la mayoría de los casos, el paquete irá destinado a un equipo de una intranet. El servidor de túnel descifra el paquete, descarta el ESP header y utiliza el IP header original para enrutar el paquete hacia el equipo de la intranet. AH y ESP pueden combinarse al utilizar túneles para lograr tanto la confidencialidad del paquete IP enviado por el túnel como la integridad y la autenticación de todo el paquete. Asociaciones de seguridad Las asociaciones de seguridad (AS) son acuerdos que se establecen entre dos equipos antes del intercambio de información protegida y especifican los servicios de seguridad que se aplicarán al tráfico correspondiente. Estos servicios son ofrecidos por una AS mediante el uso de los headers AH o ESP, pero no ambos. Una AS puede ser una conexión IPSec entre dos dispositivos finales, entre dos dispositivos VPN, o incluso entre un dispositivo final y un dispositivo extremo de un túnel IPSec. Dichos equipos establecen el modo de intercambiar y proteger la información, como se muestra en la Figura 2.25 [15].

Figura 2.25: Asociación de seguridad.

Cifrado con el ESP Header

Firmado por ICV

Paquete IP

37

Todos los parámetros necesarios para que los participantes de una comunicación puedan encapsular y desencapsular paquetes IPSec, se almacenan en la AS y estas a su vez se almacenan en bases de datos de asociaciones de seguridad [15]. Cada asociación de seguridad define los siguientes parámetros de una conexión IPSec que conjuntamente definen el método de seguridad utilizado para proteger la comunicación desde el origen hasta el destino:

Dirección IP origen y destino de la comunicación, que normalmente es una dirección unicast, aunque también puede ser una dirección broadcast o una dirección multicast.

Protocolo de seguridad, AH o ESP. Una AS permite protocolos de seguridad mediante el uso de AH o de ESP pero no de ambos.

Algoritmo de cifrado y autenticación a usar en las comunicaciones.

Clave secreta.

Tiempos de vida de las claves y de la propia AS.

Modo IPSec, modo transporte o modo túnel.

SPI, es un número de 32 bits elegido aleatoriamente que identifica la asociación de seguridad.

Como se mencionó anteriormente, en una AS se definen las direcciones IP de origen y destino de la comunicación, por ello mediante una única AS sólo se puede proteger un sentido del tráfico en una comunicación IPSec full duplex. Para proteger ambos sentidos de la comunicación, IPSec necesita de dos AS unidireccionales, es decir, habrá dos AS por cada conexión (una en cada sentido). Además, dos mismos extremos pueden establecer múltiples pares de AS, uno para cada sesión de comunicaciones.

Básicamente, cada AS se identifica por medio del SPI y por la dirección de destino correspondiente, algunos incluyen también un identificador de protocolo de seguridad (AH o ESP). El número en cuestión se inserta en el encabezamiento IPSec. En el otro extremo dicho número permite identificar la AS correspondiente y por lo tanto, su procesamiento.

Es importante mencionar que las AS sólo especifican cómo se supone que IPSec protegerá el tráfico. Para definir qué tráfico proteger, y cuándo hacerlo, se necesita información adicional. Esta información se almacena en la política de seguridad. Para establecer o mantener las AS se utiliza un protocolo denominado ISAKMP/IKE [15]. Protocolo ISAKMP/IKE ISAKMP (Internet Security Association and Key Management Protocol) es utilizado para negociar AS de manera segura y autenticada, y las políticas para proteger la comunicación, a través de un intercambio seguro de claves. De esta manera proporciona un método para centralizar la administración y creación de AS [15].

38

IKE (Internet Key Exchange) es un protocolo estándar de asociación de seguridad y resolución de intercambio de claves, establecido por la IETF [15]. ISAKMP e IKE trabajan juntos para establecer conexiones seguras entre dos dispositivos. ISAKMP define el formato del mensaje, el mecanismo del protocolo de intercambio de claves y el proceso de negociación para construir conexiones. ISAKMP, sin embargo, no define como las claves son creadas, compartidas, o manejadas para proteger las conexiones seguras; IKE es responsable de esto [15]. ISAKMP/IKE presentan tres características principales [15]:

Asegura que la comunicación IPSec y el intercambio de claves se lleve a cabo entre partes autenticadas.

Negocia los protocolos, algoritmos, y claves que serán utilizados en la comunicación IPSec.

Proporciona un método seguro para actualizar y renegociar asociaciones una vez que éstas han expirado.

De este modo, se resuelve el problema más importante del establecimiento de comunicaciones seguras: la autenticación de los participantes y el intercambio de claves simétricas. IPSec implementa ISAKMP/IKE en dos fases. En la primera fase, los dos extremos crean una conexión de gestión, estableciendo así un canal seguro entre ellos. Ya en la segunda fase, esta conexión será empleada para establecer la conexión de datos. La confidencialidad y la autenticación se aseguran durante cada una de las fases mediante el uso del cifrado y los algoritmos de autenticación acordados entre los dos equipos durante las negociaciones de seguridad. Al estar las tareas divididas entre las dos fases se agiliza la creación de claves. En la siguiente sección se describirán brevemente los pasos de las dos fases de ISAKMP/IKE [15]. Fases ISAKMP/IKE En la Figura 2.26 [15], se resumen los pasos de las dos fases de IKE.

39

Figura 2.26: Fases de ISAKMP/IKE.

Fase 1 ISAKMP/IKE Esta fase se realiza a través del intercambio de 6 mensajes, es por ello que se dice que se realiza en modo principal y puede verse como el establecimiento de la política básica de seguridad. En una primera parte (mensajes 1 y 2) se negocian las características de las AS ISAKMP/IKE, mediante la definición de directivas. Una directiva es una lista de aspectos de seguridad que deben ser utilizados para proteger la conexión, estos son:

Algoritmo de cifrado: DES, 3DES o AES.

Algoritmo de integridad: MD5 o SHA1.

Grupo Diffie-Hellman: Grupo 1, 2, 5 o 7 que se utilizará para el material base de generación de claves.

Método de autenticación: Certificados digitales o autenticación por claves pre-compartidas.

La segunda parte del modo principal (mensajes 3 y 4) se refiere especialmente al intercambio Diffie-Hellman, las claves reales no se intercambian en ningún momento. Sólo se intercambia la información básica que requiere el algoritmo de determinación de la clave Diffie-Hellman para generar la clave secreta compartida. Después de este intercambio, el servicio ISAKMP/IKE de cada equipo genera la clave principal utilizada para proteger la autenticación.

40

Finalmente (mensajes 5 y 6) los dispositivos proveen una autenticación mutua (se aseguran de que su interlocutor es quien dice ser). Si se produce un error en la autenticación, no se continuará con la comunicación. Para autenticar las identidades se utiliza la clave principal junto con los algoritmos y métodos de negociación. Los algoritmos de hash y cifrado se aplican a toda la carga de identidad mediante las claves generadas a partir del intercambio Diffie-Hellman del segundo paso. El origen presenta una oferta para establecer una posible asociación de seguridad con el destino. El destino no puede modificar la oferta. En caso de que se modifique la oferta, el origen rechazará el mensaje del destino. El destino envía una respuesta para aceptar la oferta o bien una respuesta con alternativas, de esta manera se establece un canal seguro. Una vez que un dispositivo reconoce la identidad del otro y viceversa, los intercambios de información bajo ISAKMP/IKE se realizan por medio de mensajes en el puerto 500 de UDP. Esta primera fase también suele soportar un modo agresivo (sólo usa la mitad de los mensajes para alcanzar su objetivo), aunque este no proteja identidades. Sea cual sea el modo, los participantes son autenticados. Fase 2 ISAKMP/IKE Una vez establecido un canal seguro en la fase 1 se inicia la fase 2 que se realiza en el modo agresivo o rápido por medio de tres mensajes. Esta fase define las AS y las claves de IPSec. En el primer mensaje el dispositivo origen indica al destino el tipo de protocolo de seguridad a utilizar (ESP, AH o ESP+AH) incluyendo el SPI, así como los algoritmos de hash para la integridad y autenticación (MD5 o SHA1) y para el cifrado, si se solicita (DES, 3DES o AES). De esta manera, se llega a un acuerdo y se establecen dos AS, una para la comunicación entrante y otra para la comunicación saliente. Con el segundo mensaje, y previa autenticación, el destino reconoce y acepta el uso de lo establecido en el primer mensaje. Si es necesario, el material de clave de sesión se actualiza generando nuevas claves compartidas e intercambiándolas para la integridad de los datos, la autenticación y el cifrado. Finalmente, el tercer mensaje simplemente indica que el origen está en funcionamiento, tras lo cual ambos dispositivos pueden comenzar a usar los protocolos en cuestión. Esta segunda negociación de la configuración de seguridad y el material de claves (con el fin de proteger los datos) está protegida por la conexión de gestión. Mientras que la primera fase protege la identidad, la segunda fase proporciona protección mediante la actualización del material de las claves antes de enviar los datos. Mientras la conexión de gestión no caduque, no es necesario volver a negociar o a autenticar.

41

Conexiones IPSec En la siguiente sección se describirá el proceso de comunicación para compartir de manera segura los datos entre dos dispositivos IPSec.

Un administrador o usuario inicia el proceso de IPSec manualmente desde uno de los dos dispositivos.

Si no existe una conexión VPN, IPSec utilizará la fase 1 ISAKMP/IKE para construir una conexión de gestión segura. Esta conexión es usada para que los dispositivos puedan comunicarse entre ellos de manera segura, vía IPSec, y puedan construir conexiones de datos.

A través de la conexión gestión, los dispositvos IPSec negociarán los parámetros de seguridad que son usados para construir las conexiones de datos; dichas conexiones son utilizadas para transmitir los datos de usuario como archivos, mensajes de correo electrónico, video, y voz.

Una vez que las conexiones de datos son creadas, los dispositivos IPSec pueden utilizarlas para compartir datos de usuario de manera segura. Si son usadas funciones HMAC por la fuente para crear firmas, el destino las verifica para la integridad de los datos y autenticación; además, si los datos están cifrados por el origen, el destino descifrará los datos.

Tanto la conexión de gestión como la conexión de datos tienen un tiempo de vida asociado a ellas. Esto asegura que la información clave es regenerada para proveer mayor seguridad en caso de que alguien esté tratando de romper las claves de seguridad. Una vez que el tiempo de vida de una conexión es alcanzado, esta es terminada. Por supuesto, si aun se necesita enviar datos, la conexión será reconstruida dinámicamente.

3.9.6. SSL/TLS Los protocolos SSL9 (Secure Socket Layer) y TLS (Transport Layer Security) [13] son protocolos de la capa de transporte que proporcionan comunicaciones seguras en Internet. SSL/TLS permite la autenticación tanto de cliente como servidor, usando claves públicas y certificados digitales y proporciona comunicación segura mediante el cifrado de la información entre emisor y receptor. SSL/TLS funciona por encima del protocolo de transporte (normalmente TCP) y por debajo de los protocolos de aplicación. Hay que destacar que SSL/TLS se compone de cuatro protocolos, como se muestra en la Figura 2.27. En la siguiente sección se definen estos cuatro protocolos:

Record Protocol: Encapsula los protocolos de nivel más alto y construye un canal de comunicaciones seguro.

9 SSL fue diseñado por Netscape en 1996. http://netscape.aol.com

42

Handshake Protocol: Se encarga de gestionar la negociación de los algoritmos de cifrado y la autenticación entre cliente y servidor. Define las claves de sesión utilizadas para cifrar.

Change Cipher Spec Protocol: Utiliza un mensaje de un byte para notificar cambios en la estrategia de cifrado.

Alert Protocol: Señaliza alertas y errores en la sesión establecida.

POP3s

IRCs

IMAPs

Telnets

…

HTTPs

SSL Handshake Protocol SSL Change Cipher Spec Protocol

SSL Alert Protocol

SSL Aplication Data

SSL Record Protocol

TCP

IP

Figura 2.27: SSL/TLS en la pila de protocolos OSI.

Existen diversas implementaciones del protocolo, tanto comerciales como de libre distribución siendo una de las más populares la biblioteca OpenSSL [7]. SSL es capaz de interactuar con la mayoría de protocolos que trabajan sobre TCP de tal manera que la IANA10 les tiene asignado un número de puerto por defecto, por ejemplo el protocolo HTTP sobre SSL ha sido denominado HTTPS (Hypertext Transfer Protocol Secure) y utiliza el puerto TCP 443. SSL se basa en un esquema de clave pública para el intercambio de claves de sesión. En primer lugar el cliente y el servidor intercambian una clave mediante un algoritmo de cifrado asimétrico como RSA (Rivest-Shamir-Adleman) o Diffie-Hellman utilizando certificados. Mediante esa clave se establece un canal seguro, utilizando para ello un algoritmo simétrico previamente negociado. Los mensajes a ser transmitidos se fragmentan en bloques, se comprimen y se les aplica un algoritmo hash para obtener un resumen que asegure la integridad.

10 IANA (Internet Assigned Numbers Authority). http://www.iana.org

43

Funcionamiento de SSL/TLS El funcionamiento de SSL/TLS está comprendido por una sesión y una conexión. En SSL/TLS una sesión es una asociación entre un cliente y un servidor. Las sesiones se crean mediante el protocolo Handshake y coordina los estados del cliente y del servidor. El estado de una sesión incluye la siguiente información [17]:

Identificador de Sesión: Consiste en una secuencia arbitraria de bytes elegida por el servidor para identificar una sesión activa.

Certificado de la Entidad Par: El certificado del otro extremo de la comunicación (puede ser nulo).

Método de Compresión: Indica el algoritmo usado para comprimir los datos antes de cifrarlos.

Especificación de Cifrado: Especifica el algoritmo de cifrado de datos (DES, AES, etc.) y el algoritmo HMAC (MD5 o SHA-1). También define atributos como el tamaño del Hash.

Clave Maestra: Una clave secreta de 48 bytes intercambiada entre cliente y servidor.

En SSL/TLS una conexión es transitoria y está asociada solamente a una sesión, mientras que una sesión puede tener múltiples conexiones. En otras palabras, las sesiones se usan para evitar la costosa negociación de los parámetros de cada conexión. El estado de una conexión incluye la siguiente información:

Valores aleatorios del servidor y del cliente: Secuencia de bytes elegidos por el servidor y el cliente para cada conexión.

Clave secreta HMAC de escritura del servidor: Secreto utilizado en operaciones HMAC sobre los datos del servidor.

Clave secreta HMAC de escritura del cliente: Secreto utilizado en operaciones HMAC sobre los datos del cliente.

Clave de escritura del servidor: Clave secreta para el cifrado de datos por el servidor y descifrado de datos por el cliente.

Clave de escritura del cliente: Clave secreta para el cifrado de datos por el cliente y descifrado de datos por el servidor.

Vector de Inicialización (IV) del cliente y servidor: Vectores de inicialización utilizados para bloques de cifrado.

Número de secuencia: Cada estado de conexión contiene un número de secuencia que se mantiene independientemente para los estados de lectura y escritura. El número de secuencia debe ser inicializado en cero cada vez que un estado de conexión pasa a estado activo.

44

EL SSL/TLS Record Protocol es el protocolo de transporte que proporciona a cada conexión:

Confidencialidad: Utilizando una clave compartida generada durante el protocolo Handshake para el cifrado convencional de los datos.

Integridad del mensaje: El protocolo de Handshake también genera una clave secreta común que se usa para formar el HMAC o código de autenticación del mensaje.

En el funcionamiento del SSL Record Protocol intervienen mecanismos criptográficos, para los cuales son necesarios ciertos parámetros como la clave secreta para el cifrado. Estos parámetros se negocian durante el establecimiento del protocolo Handshake, que además permite la autenticación de cliente y servidor. Como se muestra en la Figura 2.28 [17], el proceso que sigue el SSL/TLS Record Protocol es el siguiente: 1. Los mensajes se fragmentan en bloques de 214 bytes o menos. 2. Se aplica compresión opcionalmente. 3. Se calcula un HMAC o una función hash sobre los datos comprimidos. 4. El HMAC junto con el mensaje se cifra con un algoritmo simétrico. 5. Finalmente se le añade un header de registro o SSL Record Header.

Figura 2.28: Cifrado y formato de datos de aplicación con Record Protocol.

Los algoritmos de cifrado soportados por SSL son los que se muestran en la Tabla 2.1 [17].

45

Tipo de Cifrado Algoritmo Tamaño K

Cifrado Bloque

IDEA 128

DES 56

3DES 112

RSA 1024

DSA 1024

Cifrado Flujo RC4-40 40

RC4-128 128

Tabla 2.1: Algoritmos de cifrado soportados por SSL/TLS.

El protocolo Change Cipher Spec utiliza un único mensaje de un byte de valor 1 que tiene como objetivo pasar del modo pendiente, para negociar los parámetros de una conexión, al modo operativo, en el que los parámetros ya se han establecido y la comunicación es totalmente segura. El tercer protocolo de SSL/TLS, Alert Protocol, tiene como objetivo transmitir alertas mediante mensajes de 2 bytes. El cuarto protocolo y más importante que forma SSL/TLS es el Handshake Protocol, mediante este protocolo se generan los parámetros criptográficos que van a definir el estado de una sesión (una sesión SSL/TLS siempre empieza con el Handshake). Este protocolo permite la autenticación entre el cliente y el servidor y la negociación de los algoritmos de cifrado y las claves y subclaves. Este protocolo consta de cuatro fases en los que se negocian los parámetros de una sesión:

Fase 1: Se establecen las características de seguridad (versión de protocolo, identificador de sesión, suite de cifrado, método de compresión y números aleatorios iniciales).

Fase 2: En esta fase el servidor puede enviar un certificado, intercambio de clave y solicitud de certificado.

Fase 3: El cliente envía su certificado, en caso de habérselo solicitado, el intercambio de clave y puede enviar verificación de certificado.

Fase 4: Se produce el intercambio de suite de cifrado y finalización del protocolo Handshake. En esta fase se completa el establecimiento de la conexión segura.

3.9.7. OpenVPN OpenVPN es una solución de conectividad basada en software de código abierto (publicado bajo la licencia GPL) para soluciones VPN SSL/TLS11, creada por James Yonan en el año 2001. OpenVPN ofrece conectividad punto a punto con validación de usuarios y host conectados remotamente, además de una variedad de configuraciones VPN basadas en SSL/TLS, incluyendo acceso remoto, sitio-a-sitio, seguridad para redes inalámbricas bajo el estándar IEEE 802.11, soluciones de balanceo de carga, respuesta ante fallos y

11 http://openvpn.net

46

diferentes técnicas de control de acceso. OpenVPN tiene asignado y reservado el puerto 1194 de manera oficial por la IANA. Esta herramienta implementa redes seguras en la capa 2 o 3 del modelo de referencia OSI utilizando como extensión el protocolo SSL/TLS y soportando métodos de autenticación del cliente de manera flexible mediante dos factores: permite utilizar políticas de acceso a usuarios y grupos específicos, y reglas de firewall aplicadas a las interfaces virtuales utilizadas por OpenVPN para el filtrado de paquetes IP. OpenVPN no es una aplicación web Proxy ni opera a través de un navegador web. OpenVPN es una herramienta multiplataforma, soportada en sistemas operativos como Linux, Windows 2000/XP, Vista y 7, OpenBSD, FreeBSD, NetBSD, Mac OS X, Solaris, entre otros. Ofrece compatibilidad con la infraestructura de clave pública (PKI, Public Key Infrastructure) mediante el uso de certificados X.509 y la técnica de intercambio de claves RSA, compatible con NAT (Network Address Translation), DHCP (Dynamic Host Configuration Protocol) y con los dispositivos de red virtuales TUN/TAP. Por el contrario, OpenVPN no ofrece compatibilidad con estándares tales como IPSec, IKE, PPTP o L2TP. Por otra parte, OpenVPN permite encapsular el tráfico en paquetes que utilicen como protocolo de transporte TCP o UDP, como se puede observar en la Figura 2.29 [7]. Otra característica en las versiones más recientes de OpenVPN es la posibilidad de utilizar un único puerto en el servidor para todas las conexiones VPN o de soportar más de una conexión TCP.

Figura 2.29: Formato del paquete encapsulado por OpenVPN.

OpenVPN encapsula en un mismo datagrama UDP (o TCP, pero no recomendado) los canales de control y datos. Es decir, utiliza el mismo puerto para ambos canales, por lo que un datagrama UDP puede contener un mensaje de control y de datos a la vez.

47

Además, un paquete de OpenVPN puede contener información IP o una trama Ethernet pudiendo operar a nivel IP o a nivel de enlace. Utilizando UDP como protocolo encapsulador se obtiene una encapsulación del paquete original como la que se observa en la Figura 2.30.

IP Header

UDP Header

Packet Header

Data Payload Header

IP Header

TCP Header

Data

Figura 2.30: Encapsulación del canal de datos en OpenVPN.

OpenVPN divide el campo Data Payload Header en dos partes: el Packet Header, que identifica el tipo de paquete y los parámetros para las claves, y el Data Payload Header, que contiene parámetros de autentificación, vector de inicialización y campos de número de secuencia del paquete de datos. El formato de un paquete de control de OpenVPN se observa en la Figura 2.31.

Session ID

HMAC (optional)

Packet ID

ACK Buffer Length ACK Buffer

Message Sequence Number

TLS Payload

Figura 2.31: Formato del paquete de control de OpenVPN.

Descripción de los campos:

Session ID: (64 bits aleatorios). Identifica la sesión TLS.

HMAC: (16 - 20 bytes). Función que se aplica a todo el header de encapsulación para obtener integridad y poder prevenir ataques de denegación de servicio (DoS).

Packet ID: (32 – 64 bits). Incluye el número de secuencia. Realiza la misma función en los paquetes de datos y en los paquetes de control.

ACK Buffer Length: (1 byte). Indica el número de reconocimientos que hay en el buffer de ACK. Cuando este valor es cero, el buffer de reconocimientos ACK no existe.

ACK Buffer: (si ACK Buffer Length > 0). Realiza el reconocimiento de paquetes entre ambos puntos de la comunicación.

ACK Remote Session ID: (si ACK Buffer Length > 0). Representa el indicador de sesión (session ID) de los pares que componen la VPN. Estos participantes de la VPN utilizan el session ID para enlazar los reconocimientos ACK a una sesión VPN particular.

Message Sequence Number: (32 bits). Número de secuencia del paquete.

TLS payload: (n bytes). Carga TLS cifrada.

Cifrado

Autenticado

0 7 8 32

48

Cuando se inicia la conexión VPN, ambos extremos del túnel ejecutan la autenticación del cliente de SSL mediante el protocolo Handshake, donde cada uno presenta su certificado al otro extremo. Tras la autenticación, ambos lados saben que se están comunicando con quien dice ser y tienen un canal seguro mediante SSL sobre el cual pueden realizar el intercambio para generar las claves para el túnel seguro. Aplicaciones y características de OpenVPN De las aplicaciones y características que OpenVPN ofrece se pueden citar las siguientes [7]:

Enviar a través de un solo puerto TCP o UDP cualquier subred IP o adaptador de red virtual.

Posibilidad de implementar dos modos básicos: bridge en la capa 2 o tunnel en la capa 3, con lo que se logran túneles capaces de enviar información en otros protocolos no IP como por ejemplo IPX.

Configurar granjas de servidores VPN escalables y con balanceo de carga. Cada servidor puede mantener miles de conexiones dinámicas de clientes VPN.

Uso de todos los protocolos de cifrado, autenticación y certificación que ofrece la librería OpenSSL para proteger el tráfico de la VPN.

OpenVPN permite escoger entre el mecanismo de cifrado mediante claves compartidas o mediante clave pública basado en certificados.

Uso de compresión en tiempo real y gestión del tráfico para manejar la utilización del ancho de banda.

Funciona a través de proxy y puede ser configurado para ejecutarse como un servicio TCP o UDP y además como servidor (esperando conexiones entrantes) o como cliente (iniciando conexiones).

Establecer túneles donde los extremos utilizan direcciones IP dinámicas con técnicas como DHCP.

Tanto los clientes como el servidor pueden estar en la red usando solamente direccionamiento IP privado.

Crear puentes Ethernet seguros utilizando para ello adaptadores Ethernet virtuales (o TAP).

Controlar y monitorizar conexiones OpenVPN mediante interfaces gráficas de usuario (GUI, Graphical User Interface) para diferentes plataformas (Windows, Linux, MAC OS, etc.).

Las interfaces virtuales (tun0, tun1,…) permiten la implementación de rutas y reglas de firewall específicas.

Controladores virtuales TUN/TAP OpenVPN depende de los controladores virtuales TUN/TAP para poder establecer túneles punto a punto entre los dos extremos de la comunicación. Estos túneles fueron

49

desarrollados por Maxim Krasnyansky en 1999 contenidos en la herramienta para creación de adaptadores virtuales VTUN, de libre distribución [7]. El modelo que utiliza OpenVPN para implementar una VPN se basa en utilizar el espacio de usuario y enlazar una interfaz de red virtual punto a punto llamada TUN con otra interfaz de red virtual punto a punto TUN remota. Un adaptador de red virtual TUN a su vez se podría ver como un enlace punto a punto entre la tarjeta de red del equipo y el sistema operativo. La interfaz TUN en lugar de entregar los bits al medio físico los entrega al espacio de usuario del sistema operativo y éste abre, lee y/o escribe datos de paquete IP en la interfaz TUN como si se tratara de un archivo. Cuando una interfaz virtual TUN/TAP recibe el nombre TUN significa que está trabajando en modo tunnel punto a punto, enlazando con otra interfaz virtual del mismo tipo. Por otro lado, si una interfaz virtual TUN/TAP recibe el nombre de TAP, significa que está trabajando en modo bridge, simulando de esta manera una interfaz de red Ethernet en lugar de una interfaz punto a punto. Seguridad con OpenSSL OpenVPN utiliza OpenSSL para implementar su modelo de seguridad. OpenSSL se compone de la herramienta de línea de comandos OpenSSL y de dos librerías, la librería SSL y la librería Crypto. Estas herramientas ayudan al sistema a implementar el protocolo SSL, así como otros protocolos relacionados con la seguridad, como el protocolo TLS. OpenSSL también permite crear certificados digitales que se pueden aplicar a servidores. OpenSSL soporta varios algoritmos criptográficos diferentes según la finalidad:

Algoritmos de cifrado: Blowfish, AES, DES, 3DES, RC2 (Rivest Cipher 2), RC4 (Rivest Cipher 4), RC5 (Rivest Cipher 5), IDEA (International Data Encryption Algorithm).

Algoritmos para funciones hash: MD5, SHA-1, MD2 (Message Digest Algorithm 2).

Algoritmos de intercambio de clave pública: RSA, Diffie-Hellman, entre otros. Compresión con LZO LZO (Lempel-Ziv-Oberhumer)12 es una librería multiplataforma de compresión de datos codificados en ANSI C13, creada bajo la GNU/GPL (General Public License). LZO ofrece gran velocidad en la compresión y descompresión de datos, requiere de algún tipo de buffer de 64 KB de memoria para la compresión y no demanda memoria para la descompresión.

12 http://www.oberhumer.com/opensource/lzo 13 ANSI C es un estándar publicado por el Instituto Nacional Estadounidense de Estándares (ANSI, American National Standards

Institute), para el lenguaje de programación C.

50

Modos de funcionamiento de OpenVPN OpenVPN puede trabajar en dos modos: modo TUN (tunnel) o modo TAP (bridge). Ambos modos utilizan el adaptador TUN/TAP, en concreto, utilizando el adaptador TUN para transmitir tráfico IP a lo largo del túnel o por el contrario, utilizando el adaptador TAP para transmitir tráfico Ethernet por el túnel. La principal diferencia entre los adaptadores TUN y los adaptadores TAP es que un adaptador TUN es como un dispositivo virtual IP punto a punto entre los dos extremos de la comunicación (al igual que una línea dedicada) y un dispositivo TAP es como un dispositivo Ethernet virtual entre los dos extremos de la comunicación (al igual que una red Ethernet). Las principales ventajas del modo TUN o tunnel son:

Eficiencia y mayor escalabilidad.

Permite un mejor establecimiento de la MTU (Maximum Transfer Unit) para una mayor eficiencia.

Entre sus principales desventajas se pueden encontrar:

En algunas configuraciones los clientes necesitan tener un servidor WINS (Windows Internet Naming Service).

Se deben establecer las rutas que unen cada subred.

El software que dependa de tráfico broadcast no podrá ver a los equipos pertenecientes a la red del otro extremo de la VPN.

Sólo funciona para los protocolos de nivel de red IPv4 e IPv6 siempre que en ambos extremos del túnel se use el mismo protocolo.

El modo TAP o bridge tiene como ventajas principales:

Permite al tráfico broadcast.

Admite cualquier protocolo de red como IPv4, IPv6, IPX, etc. La principal desventaja de este modo es que es menos eficiente y escalable que el modo tunnel.

51

4. Marco metodológico

Con el propósito de cumplir con los objetivos de estudio planteados, se seleccionó un diseño de investigación que será aplicado al contexto particular del trabajo. En el caso específico vinculado a la creación de una propuesta de diseño de una VPN entre el campus Caracas y las dependencias extramuros de la UCV, se adoptará la modalidad de Proyecto Factible que consiste en la investigación, elaboración y desarrollo de una propuesta de un modelo operativo viable para solucionar problemas, requerimientos o necesidades de organizaciones o grupos sociales. En atención a esta modalidad de investigación, se introducen cinco fases en el estudio a fin de cumplir con los requisitos involucrados en un Proyecto Factible. La Tabla 3.2 muestra un resumen de la metodología propuesta [10].

Fase Descripción

1 Descripción de la red corporativa de datos de la UCV.

2 Planteamiento de las consideraciones de diseño de una VPN.

3 Desarrollo de las propuestas de diseño de soluciones VPN.

4 Implementación de los escenarios de prueba.

5 Comparación y selección de una propuesta de diseño VPN.

Tabla 3.2: Metodología propuesta. Fase 1. Descripción de la red corporativa de datos de la UCV En esta fase se realiza un estudio de la situación existente en la red corporativa de datos de la UCV y sus dependencias extramuros, a fin de identificar los distintos componentes que puedan ser aprovechados para el desarrollo de cada propuesta VPN, y los flujos de datos que requieran protección. Fase 2. Planteamiento de las consideraciones de diseño de una VPN Esta fase se inicia con la descripción de las consideraciones de diseño preliminares para el caso de estudio, teniendo en cuenta un conjunto de características comunes y se identifica la topología VPN a implementar, incluyendo los dispositivos VPN y sus roles, información que será necesaria para ayudar a seleccionar una solución VPN adecuada. Fase 3. Desarrollo de las propuestas de diseño de soluciones VPN Atendiendo a los resultados de la fase anterior y evaluando las opciones y tecnologías existentes que mejor se adaptan a los requerimientos planteados por la universidad, se sugieren tres posibles escenarios de implementación de una red privada virtual que permitan el acceso seguro a los servidores privados ubicados en el campus Caracas de la UCV por parte de usuarios autorizados de las dependencias extramuros, especificando sus

52

ventajas y desventajas y todos aquellos recursos (hardware y software) previstos para el diseño. Fase 4. Implementación de los escenarios de prueba Se describe el proceso de implementación del ambiente de prueba en base a las propuestas de diseño definidas en la fase anterior, incluyendo la plataforma de hardware y software utilizada, la configuración de cada protocolo en sus respectivos escenarios y la descripción de las pruebas de conectividad realizadas para verificar el funcionamiento de cada una de las tecnologías utilizadas. Fase 5. Comparación y selección de una propuesta de diseño VPN En base a lo expuesto en cada una de las propuestas de diseño y sus respectivos escenarios de prueba, se realizará un cuadro comparativo evaluando ciertas características comunes y aspectos críticos que conllevarán a la selección de la propuesta que mejor se adapte a las necesidades expuestas las fases 1 y 2, dando una respuesta viable al problema planteado. A continuación se describen cada una de estas fases.

4.1. Fase 1. Red de datos de la UCV

La red corporativa de datos de la UCV está formada por un backbone constituido por enlaces de fibra óptica monomodo que unen cuatro nodos principales utilizando switches con capacidad de enrutamiento. Un nodo representa un equipo que interconecta las redes de una facultad o localidad. Los cuatro nodos que componen el backbone son: Core, Medicina, Ciencias e Ingeniería, ubicados en los edificios principales de estas facultades y dependencias, los cuales se interconectan formando una estrella, siendo el Core Cisco 6506 el centro de la topología. Los equipos activos que participan en el backbone corporativo son switches LAN, de puertos conmutados tipo 10/100/1000Base-TX, 1000Base-LX y 1000Base-SX14. La velocidad de transmisión en el backbone corporativo varía desde 1 Gbps hasta 10 Gbps, utilizando Ethernet como protocolo de transmisión de capa 2 y TCP/IP como pila de protocolos.

4.1.1. Topología del Nodo Core El nodo Core se ubica en la DTIC (Dirección de Tecnología de Información y Comunicaciones) está conformado por un equipo modular (switch Cisco modelo Catalyst 6506) que posee 4 puertos de fibra monomodo de 10 Gbps, un módulo de 8 puertos de fibra monomodo de 1 Gbps, un módulo de 48 puertos de 10/100/1000 Mbps, un módulo

14 Dirección de Tecnología de Información y Comunicaciones (DTIC). División de Operaciones - Caracas, 2008.

53

de 24 puertos de fibra óptica SFP (Small Form-factor Pluggable) y 2 tarjetas supervisoras. A este nodo se conectan los switches de otros nodos, la salida hacia Internet, el Centro de Datos UCV y los extramuros. Los switches que se encargan de atender cada uno de los nodos principales son: Nodo Medicina, Nodo Ciencias y Nodo Ingeniería. Cada uno de estos equipos es a su vez un centro de estrella que permite interconectar las redes de las escuelas e institutos de esa facultad o localidad, así como otras facultades cercanas. Estas conexiones también son realizadas utilizando como medio físico fibra óptica monomodo. La Figura 3.1 muestra la topología del backbone principal de la red de datos de la UCV.

Figura 3.1: Topología del backbone principal de la red de datos de la UCV.

Al Core también se encuentran conectados los siguientes switches: Edificio Rectorado, Biblioteca, Faces, Trasbordo, Residencias I, Residencias II, Residencias III, Seguridad, Edificio Museo, Secretaría, Jardín Botánico, Aula Magna y Comunicaciones. Además se conectan los servidores públicos y privados que prestan servicios a toda la comunidad universitaria y al público en general (servidores de aplicaciones administrativas y académicas, servidores de nombres de dominios, entre otros).

4.1.2. Topología de los nodos de Ingeniería, Ciencias y Medicina Cada uno de estos equipos (Cisco modelo Catalyst 4506) posee 18 puertos conmutados Gigabit Ethernet de fibra óptica monomodo, 24 puertos UTP Gigabit Ethernet y una tarjeta controladora.

4.1.3. Topología del backbone de entrada La conexión a Internet de la UCV está conformada por 2 enlaces : un enlace a 60 Mbps provisto por la empresa CANTV y un enlace a 100 Mbps provisto por el Centro Nacional de Innovación Tecnológica (CENIT), para un total de 160 Mbps de acceso a Internet. Se

54

estima que esta conexión sirve a más de 6.000 estaciones de trabajo de toda la universidad y a más de 200 servidores que prestan servicios tanto públicos como privados. Los dos enlaces llegan a un switch (Cisco modelo 3750) que a su vez está conectado a un router (Cisco modelo 7200), este dispositivo está conectado a un firewall Checkpoint y es usado para el filtrado de paquetes a nivel de protocolos y la traducción de las direcciones IP internas de la UCV mediante NAT. Por último, este firewall se conecta al switch Core. Todos los enlaces para la conexión a Internet y la conexión a Internet2 llegan al Centro de Datos de la DTIC. La topología del backbone de la red corporativa de datos de la UCV, incluyendo los switches capa 3 de las facultades y dependencias, se muestra en la Figura 3.2.

Figura 3.2: Backbone de la red corporativa de datos de la UCV.

4.1.4. Descripción de los extramuros Los extramuros son todas aquellas dependencias ubicadas fuera del campus universitario de Caracas. La universidad cuenta con doce (12) dependencias extramuros:

Centro de Desarrollo Científico y Humanístico (CDCH).

Centro Comercial Los Chaguaramos (CCLCH).

55

Centro de Estudio del Desarrollo (CENDES).

Centro de Estudios Integrales del Ambiente (CENAMB).

Instituto de Biología Experimental / Instituto de Ciencia y Tecnología de Alimentos (IBE/ICTA).

Escuela José María Vargas.

Escuela de Enfermería.

Campus Maracay.

Núcleo Cagua.

Estudios Supervisados (EUS) Ciudad Bolívar.

Estudios Supervisados (EUS) Barquisimeto.

Programa Nueva Esparta. Estas dependencias se conectan a través de enlaces MetroEthernet y Frame Relay a un router (Cisco modelo 3640), ubicado en la Ciudad Universitaria denominado “router Extramuros” con velocidades de acceso entre 256 Kbps y 12 Mbps, y a un switch (Cisco modelo 3560), como se muestra en la Figura 3.3.

Figura 3.3: Extramuros.

En la Tabla 3.1 se resumen las características que definen las capacidades de los enlaces de las dependencias extramuros conectadas a la red corporativa de datos de la UCV. Cabe resaltar que dichos extramuros se conectan a través de enlaces MetroEthernet a

56

excepción del extramuros CENAMB que se conecta con un enlace Frame Relay con un CIR y un EIR de 128 Kbps respectivamente.

DIRECCIÓN VELOCIDAD

(Mbps)

Campus Maracay 12

Centro Comercial Los Chaguaramos (CCLCH) 8

Consejo de Desarrollo Científico y Humanístico (CDCH) 2

Escuela José Maria Vargas 2

Núcleo Cagua 2

EUS Ciudad Bolívar 2

Programa Nueva Esparta 2

Escuela de Enfermería 2

IBE/ICTA 2

Centro de Estudio del Desarrollo (CENDES) 2

EUS Barquisimeto 2

Tabla 3.1: Capacidades de los enlaces extramuros.

4.1.5. Descripción de los sistemas corporativos de la UCV En la Tabla 3.2 se realizará una breve descripción de las principales aplicaciones utilizadas por los usuarios ubicados en las dependencias extramuros de la UCV.

57

SISTEMA DESCRIPCIÓN USUARIO RESPONSABLE

Sistema Nómina

Sistema que maneja la nómina del personal docente, directivo, administrativo, vigilante, obreros y preparadores tanto activo como pasivo. Adicionalmente maneja la nómina de OBE (Organización de Bienestar Estudiantil).

Aplicación cliente/servidor desarrollada en Informix – 4GL.

Sistema operativo AIX 4.31

División de Nómina.

Dirección de Administración y Finanzas.

Dirección de Planificación y Presupuesto.

Contabilidad.

Tesorería.

RRHH.

Facultades y dependencias.

DTIC.

AJC

Sistema de Administración

Financiera

Sistema administrativo descentralizado que controla los ingresos, egresos, presupuesto y compras de cada una de las facultades y dependencias centrales.

Desarrollado en software Fivetech.

Sistema operativo Windows 2000 Server.

VRAD.

Tesorería y RRHH.

CDCH.

VRAD (Vicerrectorado Administrativo).

Soporte técnico y mantenimiento AJC.

Correo electrónico

UCV

Sistema de cuentas de correo electrónico de uso corporativo bajo el dominio ucv.ve.

Aplicación cliente/servidor.

Sistema operativo Debian.

Interfaz web PHP- MySQL.

Personal docente, directivo, administrativo.

DTIC.

SIGAS

Sistema de control de estudios centralizado (Secretaria) y en las facultades utilizado para el manejo de la información de los procesos de admisión, inscripción, control de estudios, certificación y grados.

Aplicación cliente/servidor desarrollada en Oracle versión 9.

Sistema Operativo Solaris 9.

Secretaria y Control de Estudio de las facultades UCV.

Secretaría y Unidades de Informática de cada facultad.

Tabla 3.2: Sistemas corporativos UCV utilizados por usuarios extramuros.

58

4.2. Fase 2. Planteamiento de las consideraciones de diseño de una VPN

En esta fase se llevó a cabo la recolección de información teórica y práctica, para estudiar de manera detallada todos los aspectos conceptuales relacionados con el diseño de redes VPN. Esta recolección de información se realizó utilizando el método de campo que implica la elaboración de entrevistas a empleados, quienes son las personas capaces de proporcionar datos importantes para la aplicación del proyecto. Mediante la revisión de libros de texto, artículos presentes en Internet, documentos técnicos y otras fuentes bibliográficas, se exploró y profundizó sobre todos los conceptos y protocolos necesarios para el diseño de una red VPN. Como resultado de esta investigación, se tomó en cuenta una serie de características que se consideran premisas para el diseño, entre estas se incluyen:

Perfil de la red.

Escalabilidad.

Seguridad.

Topología de red. A continuación se describen estas premisas de diseño.

4.2.1. Perfil de la red Algunos factores que se deben considerar son la cantidad de tráfico y si este necesita ser protegido en su totalidad cuando se envía entre dos dispositivos que tienen una conexión VPN establecida. Si la cantidad de tráfico VPN enviado es mayor al soportado por el dispositivo VPN, se presentarán problemas de rendimiento en dicho dispositivo. Para evitar esto, se recomienda implementar la función de split tunnelig o reglas de acceso que permitan enviar una parte del tráfico protegido y otra en texto claro, por lo tanto no es necesario proteger todo el tráfico del enlace. Adicionalmente se debe determinar que aplicaciones se esperan ejecutar en la VPN. El servicio de correo electrónico de la UCV, bajo el protocolo POP3, descuida la seguridad y confidencialidad de los datos que envía. Por ejemplo, cuando usuario ingresa a su correo electrónico desde la universidad, envía su usuario y contraseña en texto plano por la red. Por otra parte, según información suministrada por la División de Operaciones de la DTIC, la aplicación SIGAS tiene una deficiencia importante de seguridad, ya que la transmisión de datos se realiza en texto plano. Para validar esta información, se configuró un puerto mirror al cual se redirigía el tráfico entrante y saliente del router Extramuros y a través de una captura de tráfico se pudo constatar lo siguiente:

59

Información de cuentas bancarias: En la Figura 3.4 se observa un número de cuenta perteneciente a Banesco Banco Universal.

Figura 3.4: Captura de cuentas bancarias.

Información académica: En la Figura 3.5 se observa información de estudiantes como nombres (Néstor E.), apellidos (González A.), semestre cursante (segundo semestre) y facultad (Ciencias Económicas y Sociales).

60

Figura 3.5: Captura de información académica.

Adicionalmente, en la Figura 3.6 se muestra información como el número de cédula (18713646), número de expediente académico (22965), entre otros.

Figura 3.6: Captura de información personal.

61

Información del sistema SIGAS: En la Figura 3.7 se observa el nombre del servidor SIGAS (sigadb1.rect.ucv.ve) junto a un nombre de usuario de acceso a la base de datos (perozoa).

Figura 3.7: Captura de información SIGAS.

Información de Bases de Datos: En la Figura 3.8 se observa una consulta completa con información de tablas y campos de la base de datos de SIGAS.

62

Figura 3.8: Captura de información de bases de datos.

Existen otros tipos de aplicaciones como HTTPS (Hypertext Transfer Protocol Secure) y SSH (Secure Shell) que proporcionan sus propios mecanismos de seguridad, este sería el caso de los sistemas de nómina y contabilidad, donde se garantiza el acceso seguro mediante la aplicación Secure CRT que es un cliente Secure Shell.

4.2.2. Escalabilidad El número de oficinas remotas, además del tráfico esperado para cada una, determina cuántos dispositivos centrales se requieren. Cada diseño propuesto contemplará siete sedes extramuros que serán agregadas al dispositivo central: C.C. Los Chaguaramos, IBE/ICTA, CENAMB, CENDES, Escuela de Enfermería, Escuela Vargas y CDCH.

4.2.3. Seguridad Existen diferentes niveles de complejidad para la implementación de los distintos métodos de autenticación. Por ejemplo, la configuración de claves compartidas es el método menos complejo; sin embargo, puede presentar problemas de escalabilidad, mientras que el uso de certificados es escalable, pero es más complejo de implementar. En general, para soluciones con un número reducido de oficinas remotas, la mejor elección sería el método de claves compartidas [1]. Otras soluciones sólo soportan el uso de certificados digitales. Por otro lado, para garantizar la confidencialidad de los datos transportados a través de la VPN, se considerarán los siguientes estándares por ser considerados los más seguros y

63

rápidos [1]: 3DES, AES y Blowfish. Sin embargo, existen tecnologías VPN que manejan algoritmos de cifrado predefinidos como es el caso de PPTP que utiliza MPPE.

4.2.4. Topología de red Como se mencionó en el Capítulo II, las VPNs sitio-a-sitio son implementadas principalmente para conectar localidades de oficinas remotas con la oficina central de una empresa. Los componentes clave de este diseño de VPN sitio-a-sitio son los siguientes:

Un dispositivo VPN sirviendo como dispositivo final VPN en el campus Caracas.

Un dispositivo VPN de acceso sirviendo como dispositivo final VPN en cada extramuros.

Servicios de red adquiridos de un ISP sirviendo como el medio de interconexión WAN.

Otra consideración técnica importante cuando se desarrollan VPNs sitio-a-sitio es la definición de la topología de diseño. La topología que representa una VPN intranet que conecta la oficina principal de una empresa con sus oficinas remotas es hub-and-spoke. En la Figura 3.9 se puede observar un modelo hub-and-spoke el cual es muy similar a la topología de la red UCV y la interconexión con sus extramuros, donde se puede ubicar fácilmente al hub dentro del campus Caracas y a los spokes como los dispositivos VPN en cada extramuro, pudiendo ser tanto un servidor, como un router o una estación de trabajo.

Figura 3.9: Topología hub-and-spoke.

64

4.3. Fase 3. Desarrollo de las propuestas de diseño de soluciones VPN

Partiendo de la infraestructura tecnológica y física de la UCV y del estudio acerca de las tecnologías VPN existentes, se sugiere que los escenarios de implementación de una Red Privada Virtual se basen en los siguientes protocolos:

1. PPTP con MPPE. 2. IPSec/GRE. 3. OpenVPN.

A continuación se describe en detalle cada escenario con algunos requerimientos e instrucciones básicas de configuración.

4.3.1. PPTP con MPPE Este escenario se propone basándose en PPTP ya que es un protocolo desarrollado por Microsoft para estaciones de trabajo bajo el sistema operativo Windows predominante en la mayoría de las estaciones de trabajo pertenecientes a la red corporativa de la UCV. Requerimientos Los componentes principales de este diseño son:

Software: Windows XP o 2000. Soporta también Windows 95/98 y Windows NT 4.0

Hardware: Router Cisco 3640, IOS versión 12.1 (5) T915 [2].

Aspectos de seguridad Esta propuesta garantiza los siguientes aspectos de seguridad:

Autenticación: Para proveer la autenticación del PAC ante el PNS, se seleccionó el tipo de autenticación MS-CHAP versión 2, debido a sus ventajas frente a las tres opciones restantes de autenticación utilizadas por PPTP [10]. Se debe hacer obligatorio el uso de contraseñas fuertes.

Cifrado: Para garantizar la confidencialidad de los datos se utilizará el algoritmo de cifrado MPPE. Se recomienda utilizar el MPPE de 128 bits para mayor seguridad [10].

Escenario propuesto El escenario propuesto permitirá integrar a cada usuario de los extramuros con el campus Caracas de manera segura utilizando un router Cisco y estaciones de trabajo con sistema 15 PPTP fue incorporado en el Cisco IOS Software Release 12.1(4)T http://www.cisco.com/en/US/tech/tk827/tk369/technologies_configuration_example09186a00800949c0.shtml

65

operativo Windows como dispositivos esenciales para establecer la VPN entre las distintas dependencias de la UCV. Esta propuesta exige la presencia de un PNS, este será el caso del router Extramuros que tendrá la función de servidor de acceso a la red en el campus Caracas. Cada usuario ubicado en las distintas dependencias extramuros actuará como PAC. Para establecer la comunicación entre el PNS y cada PAC, será creado un túnel voluntario entre cada uno de los extremos y por el mismo pueden existir varias sesiones, como se muestra en la Figura 3.10.

Figura 3.10: Escenario propuesto usando PPTP con MPPE.

En este caso el PNS proporciona acceso y conexiones VPN PPTP. Será responsable de aceptar los paquetes PPP, quitar el header del protocolo de transferencia de datos del túnel, descifrar el paquete y enviar la carga útil al servidor privado correspondiente. El sistema operativo Windows permite que las estaciones de trabajo de cada uno de los usuarios de las distintas sedes funcionen como clientes VPN, de esta manera el usuario mediante su equipo se puede conectar en forma segura desde una sede con cualquier servidor privado de la UCV. Cada PAC es responsable de establecer un túnel con el PNS, utilizando LCP para la negociación, y participando con el proceso de autenticación PPP. Por ejemplo, para que un usuario de Enfermería se comunique con algún servidor privado del campus Caracas, previamente configurado PPTP en su equipo de trabajo, se

66

construyen dos conexiones: una de control y una de datos, como se puede observar en la Figura 3.11.

Figura 3.11: Ejemplo de conexión PPTP.

Durante la conexión de control se establece un enlace PPP a través del puerto TCP 1723, que incluye la negociación de parámetros de capa 2, como el uso de autenticación, cifrado mediante MPPE, entre otros. Posteriormente, el usuario es autenticado ante el router Extramuros mediante el protocolo MS-CHAPv2. Los protocolos utilizados para la conexión de datos, negociados anteriormente, son invocados. Estos protocolos incluyen IP, IPX, entre otros. La conexión de datos utiliza GRE para el mantenimiento del túnel proporcionando gestion de envío, control de flujo y congestión de los paquetes PPP. Una vez completado este proceso los datos pueden ser enviados a través de la conexión PPP. Ventajas y desventajas Ventajas Esta implementación permite servicios seguros, escalabilidad y la reducción de costos, como se describe a continuación [2].

PPTP con MPPE proporciona un mecanismo para el envío de los datos de usuario a través de túneles aprovechando la tecnología existente dentro de la universidad, como la plataforma Windows y los equipos Cisco, lo que no representa un costo adicional de implementación. MPPE provee un servicio de cifrado que protege el flujo de datos a medida que este atraviesa la red corporativa.

Un router Cisco implementando PPTP puede soportar más de 2000 túneles PPTP simultáneos sin cifrado MPPE. Para túneles PPTP con cifrado MPPE, los routers Cisco pueden soportar más de 500 túneles simultáneos [10].

67

PPTP es la tecnología VPN más fácil de implementar y al mismo tiempo de diagnosticar y solventar problemas.

Desventajas

Originalmente PPTP fue desarrollado pensando en brindar soluciones de acceso remoto VPN. Los túneles sitio-a-sitio no fueron soportados en un comienzo. Sólo hasta el año 1997 cuando Microsoft introdujo su servicio de RRAS (Routing and Remote Access Service) para servidores NT 4.0, se pudieron implementar topologías sitio-a-sitio usando PPTP como protocolo de túnel. Sin embargo, la gran desventaja de usar PPTP en topologías sitio-a-sitio es la inseguridad inherente a la arquitectura del protocolo. En efecto, la autenticación y el cifrado son controlados por protocolos que ofrecen un nivel muy bajo de confiabilidad, como CHAP o MS-CHAP.

Ya que toda la señalización de PPTP es a través de TCP, la configuración de TCP afectará el rendimiento de PPTP en entornos de gran escala como lo es la red corporativa de la UCV.

La implementación de PPTP en los sistemas operativos de Cisco contiene una vulnerabilidad que hará que el router se sobrecargue si este recibe por el puerto 1723 un paquete PPTP malformado o manipulado, pudiendo causar una denegación de servicio (DoS) permanente del router. Para exponer esta vulnerabilidad, sólo se necesita que PPTP esté habilitado en el router16.

Ya que no existe protección de seguridad para la conexión de control de TCP usada por PPTP (no se realiza autenticación ni verificación de integridad), los datos son susceptibles a la manipulación y a ataques de suplantación.

Otro aspecto que afecta la seguridad es que la información de los headers IP, GRE y PPP no está protegida en la conexión de túnel. Por lo que es posible para un atacante escuchar en la conexión de túnel y modificarla, o realizar un ataque de suplantación igual que en el caso de las conexiones de control.

Tanto el cifrado de 40 bits y el de 128 bits de MPPE son conocidos como vulnerables.

4.3.2. IPSec/GRE Esta propuesta se basa en la tecnología IPSec implementada frecuentemente en routers Cisco los cuales componen la infraestructura tecnológica de la red corporativa de la UCV.

16 Esta vulnerabilidad está documentada como Cisco Bug ID CSCdt46181. http://www.cisco.com/en/US/products/products_security_advisory09186a00800b1695.shtml

68

Requerimientos Los componentes clave en este diseño VPN son los siguientes:

Router Cisco 3640.

Router Cisco 2620. Aspectos de seguridad Este diseño garantiza los siguientes aspectos de seguridad:

Confidencialidad: Para proteger los datos de ataques de escucha se implementará el algoritmo de cifrado 3DES.

Integridad: Para garantizar la integridad de los datos, el protocolo IPSec es utilizado junto con un método de hash. En este diseño en particular se implementará el método SHA-1 por ser más seguro que MD5 [10].

Autenticación: Para la validación de la identidad de los dispositivos IPSec, se seleccionó el método de claves pre-compartidas debido a que la cantidad de sitios remotos a manejar es relativamente pequeña.

Consideraciones preliminares de diseño de IPSec Tomando en cuenta las consideraciones de diseño planteadas en la fase II y otros aspectos relacionados directamente con la tecnología IPSec, se resumen en la Tabla 3.3 las consideraciones preliminares para este diseño.

Pregunta Respuesta Comentarios

¿Qué aplicaciones espera correr el cliente sobre la VPN?

Sistema de Control de Estudio SIGAS.

¿Cuántos spokes espera el cliente agregar al hub?

11 sedes.

¿Qué nivel de cifrado es requerido?

3DES.

¿Cuál función HMAC será utilizada?

SHA-1.

¿Qué método de autenticación será utilizado?

Claves pre-compartidas. La migración a certificados digitales debe ser considerada si el número de spokes supera los 50 en el futuro.

Tabla 3.3: Consideraciones preliminares IPSec.

69

Escenario propuesto En este diseño se propone una topología IPSec/GRE comúnmente utilizada como lo es hub-and-spoke, donde el router Extramuros tendrá la función del hub y cada uno de los routers ubicados en las distintas sedes funcionará como spoke. Esto permitirá a cada spoke ser autenticado y transmitir datos de manera segura a través de la red. Al mismo tiempo, el cifrado se logra mediante túneles IPSec/GRE. El hub debe tener una ruta explícita para cada spoke. A pesar de que IPSec proporciona un método seguro para transportar los datos a través de una red IP, tiene ciertas limitantes. En primer lugar, IPSec no soporta tráfico broadcast o multicast, restringiendo la utilización de protocolos tales como EIGRP (Enhanced Interior Gateway Routing Protocol), que es implementado dentro de la red corporativa de datos de la UCV como protocolo de enrutamiento. En segundo lugar, IPSec no soporta el uso de tráfico multi-protocolo. Para superar estas limitaciones se propone la implementación de túneles GRE en conjunto con IPSec. Aun cuando no existan requerimientos de multi-protocolo dentro de la red corporativa actual, realizar un diseño flexible de la VPN previene un re-diseño costoso en un futuro donde esto se convierta en un requerimiento. Combinando GRE con IPSec, todo el tráfico entre el campus Caracas y los extramuros será encapsulado en paquetes GRE antes del proceso de cifrado. Esto simplifica la lista de acceso utilizada en el crypto map ya que se necesita sólo una línea que permita GRE. Para la conexión entre el hub (campus Caracas) y cada uno de los spokes se utilizará el modo túnel. Como se mencionó anteriormente, en el modo túnel un dispositivo intermedio es utilizado para la protección del tráfico y no los dispositivos origen y destino de los datos. En este caso, el router Extramuros y los routers ubicados en cada sede serán responsables de la protección VPN. La selección de este modo de conexión proporciona flexibilidad al diseño ya que al añadir nuevos dispositivos que necesiten protección no será necesario realizar cambios en la configuración VPN. También permite que los dispositivos origen y destino puedan utilizar direccionamiento privado ya que el paquete original es encapsulado en otro paquete por los dispositivos VPN. Otra de las ventajas de este modo es que oculta las comunicaciones, ya que un atacante no tiene forma de conocer si los dispositivos VPN del paquete interceptado son el origen y el destino reales de la transmisión, o si los datos son transmitidos por otros dispositivos. El protocolo de seguridad ESP será utilizado para proporcionar confidencialidad, autenticación, integridad y protección contra réplica de los datos. Como se mencionó anteriormente, ESP hace uso de una amplia variedad de algoritmos de cifrado entre los cuales se encuentra 3DES.

70

El proceso de comunicación para compartir datos de manera segura entre el hub y un determinado spoke se llevará a cabo mediante los siguientes pasos:

Paso 1: Uno de los dispositivos (hub o spoke) inicia el proceso IPSec.

Paso 2: IPSec utilizará la fase 1 ISAKMP/IKE para construir una conexión de gestión segura. Esta fase comienza cuando los dispositivos negocian como dicha conexión de gestión será protegida, esto se realiza definiendo un transform. Diffie-Hellman es utilizado para compartir de forma segura las claves del algoritmo de cifrado y de las funciones HMAC. Por último, se realizará la autenticación de dispositivo a través de la conexión de gestión.

Paso 3: A través de la conexión de gestión, los dos dispositivos IPSec negociarán los parámetros de seguridad que serán utilizados para establecer la conexión segura de datos.

Paso 4: Una vez establecida la conexión de datos, los dispositivos IPSec pueden utilizar dicha conexión para compartir datos de usuario de manera segura. La función HMAC es usada por el origen para crear firmas y el destino las verifica para garantizar la integridad y la autenticación de los datos; adicionalmente, el destino descifrará los datos.

Paso 5: Tanto la conexión de gestión como la de datos tendrán asociado un tiempo de vida. Esto asegurará que la información de claves sea regenerada para proporcionar mayor seguridad. Una vez finalizado este tiempo de vida, las conexiones expirarán y tendrán que ser restablecidas dinámicamente.

En la Figura 3.12 se muestra un ejemplo de la comunicación entre un usuario ubicado en la dependencia Enfermería y un servidor privado de la red corporativa de datos a través de IPSec según el escenario planteado anteriormente.

Figura 3.12: Ejemplo de conexión IPSec.

El usuario A ubicado en Enfermería, que utiliza la aplicación SIGAS en su equipo, envía un paquete IP de aplicación al servidor privado B ubicado en el campus Caracas de la UCV.

71

El router Enfermería comprueba sus listas de filtros IP de salida y determina que el paquete debe protegerse ya que tiene como destino la dirección IP del servidor privado B. Esta acción sirve para negociar la seguridad, de forma que IKE inicie las negociaciones.

El servicio IKE del router Enfermería completa una búsqueda de directivas, utilizando su propia dirección IP como origen y la dirección IP del router Extramuros como destino. El router Enfermería envía el primer mensaje de IKE mediante el puerto de origen UDP 500, puerto de destino 500.

El router Extramuros recibe un mensaje IKE que solicita negociación segura. Utiliza la dirección IP origen y destino del paquete UDP para realizar una búsqueda de directivas y determinar la configuración de seguridad que se va a acordar. Si el router tiene un archivo que coincide con esta información, responde para iniciar la negociación de la conexión de gestión.

El router Enfermería y el router Extramuros negocian opciones, intercambian identidades, se autentican y generan una clave principal compartida. Han establecido una conexión de gestión.

A continuación, el router Enfermería realiza una búsqueda de directiva de ISAKMP/IKE, selecciona la configuración de seguridad y el filtro, y lo propone al router Extramuros. El router Extramuros también realiza una búsqueda de directiva de ISAKMP/IKE mediante la descripción de filtro ofrecida por el router Enfermería. El router Extramuros selecciona las opciones de seguridad requeridas por su directiva y las compara con las ofrecidas por el router Enfermería. El router Extramuros acepta un conjunto de opciones y completa el resto de la negociación para crear un par de asociaciones de seguridad de la conexión de datos.

Una asociación de seguridad se usa para el tráfico entrante y otra para el tráfico saliente. El SPI insertado en el IPSec header de cada paquete enviado identifica las asociaciones de seguridad.

El router Enfermería utiliza la AS saliente para firmar los paquetes, cifrarlos y enviarlos.

El router Extramuros recibe los paquetes cifrados de la red. El receptor de un paquete IPSec utiliza el SPI para buscar la asociación de seguridad correspondiente, con las claves criptográficas necesarias para comprobar y descifrar los paquetes.

El router Extramuros utiliza el índice SPI de la asociación de seguridad de entrada para recuperar las claves necesarias para validar la autenticación e integridad y descifrar los paquetes.

El router Extramuros convierte los paquetes de formato IPSec a formato de paquete IP estándar. Pasa los paquetes IP validados y descifrados al controlador TCP/IP del servidor privado B, que a su vez, los pasa a la aplicación receptora.

Cuando la aplicación deja de enviar y recibir datos, las asociaciones de seguridad pasan a inactividad y se eliminan.

72

Ventajas y desventajas Ventajas Los principales beneficios de este diseño incluyen los siguientes:

Seguridad - El tráfico entre el hub y cada uno de los spokes es cifrado utilizando 3DES y

autenticado con SHA-1.

Escalabilidad - Es un diseño modular y sencillo. Si es necesario agregar una nueva sede, sólo se

necesitaría contar con un router VPN remoto conectado a la red del ISP y configurar los túneles IPSec hacia el hub.

- Desempeño comprobado de más de 500 spokes (1000 túneles) por cada hub [1].

Flexibilidad - Soporte en todos los routers con plataforma IOS de Cisco. - Soporte de protocolos de enrutamiento dinámico a través del túnel VPN. - Soporte de multicast y protocolos no-IP. - Mediante el split tunneling se envía sólo el tráfico que requiere protección a

través del túnel IPSec, reduciendo el nivel de utilización del router.

Bajo costo - Al aprovechar los recursos existentes dentro de la red corporativa de datos de

la UCV, los costos de una posible implementación serían mínimos. Desventajas

El punto crítico de este modelo es el hub, de tal manera que si existe alguna eventualidad con el mismo se generará un severo impacto en la conectividad VPN. En este caso se recomienda disponer de un router redundante.

En caso de un crecimiento drástico en el número de spokes, sobrepasando las 50 sedes, el mantenimiento de claves compartidas por cada par hub/spoke puede convertirse en un problema de escalabilidad.

Los headers de IPSec y GRE incrementan el tamaño de los paquetes, por lo tanto pueden presentarse problemas de fragmentación de paquetes que reducen el rendimiento de la red. Existen varios métodos para mitigar este problema como lo son la reducción del tamaño del MTU, la implementación de PMTUD (Path MTU Discovery) o la implementación de Look Ahead Fragmentation [1].

La configuración de GRE afecta negativamente el rendimiento del router debido a que los headers de este protocolo también deben ser cifrados.

IPSec opera en el kernel, comprometiendo la seguridad del sistema.

73

4.3.3. OpenVPN El tercer escenario propuesto es una solución de conectividad basada en software de código abierto, creada recientemente, que está siendo utilizada ampliamente por sus ventajas frente a otras implementaciones de VPN [7]. Requerimientos

Software: Cliente OpenVPN a partir de la versión 2.1.1.

Hardware: Un servidor con sistema operativo Linux [7]. Aspectos de seguridad Para implementar la seguridad en los túneles OpenVPN se hace uso de algunos scripts proporcionados por el paquete criptográfico OpenSSL. Esta propuesta garantiza los siguientes aspectos de seguridad:

Autenticación: Este modelo de seguridad de OpenVPN se basa en el modo TLS utilizando certificados para la autenticación mediante el establecimiento de una infraestructura de clave pública (PKI).

Confidencialidad: Se utilizará el algoritmo de cifrado simétrico por defecto Blowfish, con un tamaño de clave de 128 bits.

Integridad: Se utiliza autenticación HMAC basada en la opción --tls-auth para prevenir ataques de inyección de paquetes al subsistema SSL/TLS. Por defecto, el algoritmo SHA-1 con un tamaño de clave de 160 bits es la función Hash para los HMACs.

Escenario propuesto En este diseño se propone un escenario cliente/servidor, que permite a los usuarios ubicados en los extramuros de la institución conectarse de forma segura con el campus Caracas utilizando la WAN como vinculo de acceso. Para este modelo se cuenta con un servidor ubicado en la red corporativa de datos conectado en la DMZ del firewall principal y clientes OpenVPN ubicados en las estaciones de trabajo de los usuarios de cada extramuro autorizados para el acceso a la VPN, como se muestra en la Figura 3.13.

74

Figura 3.13: Ejemplo de conexión OpenVPN.

Las estaciones de trabajo que actúan como clientes OpenVPN tendrán comúnmente instalados sistemas operativos Windows (2000, XP, Vista o 7), ya que en este caso es el sistema operativo más utilizado a nivel de usuario. El servidor OpenVPN tendrá instalado un sistema operativo Linux, ya que estas distribuciones son la mejor opción al tener que implementar un servidor [7]. La seguridad implementada en este escenario consiste en un modelo basado en certificados, utilizando una infraestructura de clave pública (PKI) y el protocolo TLS para establecer un canal seguro para el intercambio y generación de claves. En este modelo los clientes se irán conectando al servidor conforme quieran acceder a la VPN, por lo que habrá que crear un certificado para cada cliente que desee conectarse o bien utilizar el mismo certificado para todos los clientes (no recomendable). Este modo de seguridad consiste en:

Un certificado público (conocido también como clave pública) y una clave privada para el servidor.

Un certificado público y una clave privada para cada cliente.

Un certificado público y clave privada de la CA (Certification Authority) que tendrá la función de firmar cada uno de los certificados del cliente y del servidor.

Tanto el servidor como el cliente se autenticarán verificando, primero, que el certificado que le ha presentado el otro participante fue firmado por la CA y, tras esto, comprobarán algunos campos del certificado, como el “Common Name” o el tipo de certificado (tipo cliente o tipo servidor). Este modelo de seguridad tiene algunas características que se desean en una VPN:

75

El servidor sólo necesita su propio certificado y clave privada. No es necesario que el servidor conozca los certificados de cada uno de los clientes que puedan conectarse.

El servidor sólo aceptará clientes cuyos certificados fueron firmados por el certificado de la CA, ya que este certificado lo tienen tanto el servidor como los clientes. Además, como el servidor puede verificar si la firma es o no de la CA sin necesidad de acceder a la clave privada de esta CA (esta clave es la más importante de toda la infraestructura de clave pública, PKI), dicha clave privada puede residir en un equipo diferente al del servidor e incluso en un equipo no conectado a la red.

Si una clave privada (del servidor, de algún cliente o de la CA) está comprometida, esta puede ser deshabilitada añadiendo el certificado a una lista de revocación de certificados o CRL (Certificate Revocation List). La CRL permite rechazar certificados comprometidos sin necesitar hacer una reconstrucción de la infraestructura de clave pública o PKI.

El servidor puede forzar a los clientes reglas de acceso específicas basadas en los campos del certificado, como el “Common Name”.

Una vez la autenticación SSL/TLS se ha realizado con éxito, la clave para cifrado/descifrado y la clave para la HMAC es generada aleatoriamente por la función de OpenSSL RAND_bytes y se hace el intercambio mediante la conexión SSL/TLS. Una vez cada uno de los participantes tiene su juego de claves, la transmisión de la información puede comenzar en el túnel. Ventajas y desventajas Tras describir las funcionalidades y características de este escenario se hace una revisión de sus ventajas y desventajas. Ventajas

OpenVPN opera en el espacio de usuario pudiendo contener los fallos en este espacio más rápidamente sin comprometer la seguridad del sistema.

Ofrece compatibilidad con la infraestructura de clave pública (PKI) mediante el uso de certificados X.509 y la técnica de intercambio de claves RSA, compatible con NAT, DHCP y con los dispositivos de red virtuales TUN/TAP.

Facilidad de instalación y configuración.

Proporciona portabilidad multiplataforma para la mayoría de sistemas operativos. En la actualidad OpenVPN se puede ejecutar en entornos Linux, Solaris, OpenBSD, FreeBSD, NetBSD, Mac OS X y Windows 2000/XP, Vista y 7 [7].

Provee de un marco extensible para la implementación de VPN de manera que proporciona la capacidad de distribuir un paquete de instalación personalizada a cada cliente, o la capacidad de implementar más de un método de autenticación a través de plugins, como por ejemplo, autenticación con certificados X.509

76

combinada con autenticación basada en el paquete PAM (Pluggable Authentication Method).

Ofrece una interfaz de manejo que puede ser utilizada de manera remota permitiendo el control o manejo centralizado del proceso OpenVPN.

Utiliza un modelo de seguridad robusto para proteger contra ataques tanto pasivos como activos.

OpenVPN se ha construido con un diseño modular. Todo lo relacionado con el cifrado está soportado por la librería OpenSSL y todo lo relacionado con la funcionalidad de los túneles IP está proporcionado por el adaptador virtual TUN/TAP.

El uso de dispositivos de red virtuales TUN/TAP permite aplicarles rutas y reglas de firewall como si de una tarjeta de red física Ethernet se tratase.

Posibilidad de implementar dos modos básicos, en capa 2 o capa 3, con lo que se logran túneles capaces de enviar información en otros protocolos no-IP como IPX.

Desventajas

OpenVPN es una tecnología nueva y aún en crecimiento.

Sólo puede ser configurado en estaciones de trabajo, aunque ya existen compañías desarrollando dispositivos con clientes OpenVPN integrados.

Escasa documentación.

4.4. Fase 4. Implementación de los escenarios de prueba

En base a las propuestas de diseño llevadas a cabo en la fase anterior, en esta fase se describe el proceso de implementación del ambiente de prueba, así como la plataforma de hardware y software utilizada. En este sentido se procederá a describir los ambientes de prueba.

4.4.1. PPTP Para simular este escenario se ha disminuido la complejidad de lo que podría ser la red corporativa de la UCV, de tal manera que no se ha utilizado ningún enlace WAN, por lo que las redes de las oficinas que hemos implementado (campus Caracas y extramuros) estarán separadas por una red aparte implementada mediante un switch que simulará dicho enlace WAN; igualmente se han supuesto direcciones IP fijas. Equipos Utilizados

Un router Cisco 2811, IOS versión 12.4.

Dos switches Cisco Catalyst 2960-48TC.

Dos PCs Dell Pentium 4 1.8Ghz, 1GB de RAM y 160GB de disco duro, con sistema operativo Windows XP, actuando como estaciones de trabajo en cada una de las LAN corporativas (campus Caracas y extramuros).

77

Escenario de Prueba

Figura 3.14: Escenario de prueba PPTP.

Configuración Para la configuración del escenario de prueba de PPTP, como se muestra en la Figura 3.14, se siguieron los pasos que a continuación se describen:

Paso 1: Configuración de parámetros VPDN (Virtual Private Dialup Network).

Paso 2: Configuración del modelo virtual para sesiones dial-in.

Paso 3: Creación de cuentas para usuarios PPTP.

Paso 4: Configuración del cliente (PAC) en Windows.

Paso1: Configuración de parámetros VPDN (Virtual Private Dialup Network). En el primer paso se debe habilitar VPDN en el router PNS y crear el grupo de parámetros VPDN que definirán varios aspectos de la conexión PPTP.

1: PNS(config)# vpdn enable 2: PNS(config)# vpdn-group 1 3: PNS(config-vpdn)# accept-dialin 4: PNS(config-vpdn-acc-in)# protocol pptp 5: PNS(config-vpdn-acc-in)# virtual-template <número> 6: PNS(config-vpdn-acc-in)# exit

Esto permite al router aceptar conexiones PPTP entrantes y especifica la interfaz virtual a la que es configurado el túnel PPTP. Paso 2: Configuración del modelo virtual para sesiones dial-in. Para configurar el router PNS como servidor de túnel, se debe vincular la interfaz virtual PPTP a una interfaz real; también se debe crear un pool de direcciones IP que serán asignadas a los usuarios VPDN mediante los siguientes pasos:

78

1: PNS(config)# interface virtual-template <número> 2: PNS(config-if)# ip unnumbered <tipo-interfaz> <número> 3: PNS(config-if)# peer default ip address pool <nombre-pool> 4: PNS(config-if)# no keepalive 5: PNS(config-if)# ppp encrypt mppe 128 6: PNS(config-if)# ppp authentication ms-chap ms-chap-v2

El comando ppp encrypt especifica el algoritmo de cifrado a ser utilizado, en este caso MPPE de 128 bits. MS-CHAP y MS-CHAP v2 son configurados como métodos de autenticación, de manera que se pueda ofrecer el mejor mecanismo posible de autenticación para este caso. Los clientes VPN pueden obtener direcciones IP pertenecientes a la red interna existente, o se le pueden asignar direcciones IP totalmente diferentes al esquema de direcciones de la red interna, en el primer caso se debe utilizar el comando ip unnumbered para vincular el adaptador virtual a la interfaz real conectada a la red interna. En el segundo caso se debe configurar la interfaz Virtual-Template con una dirección IP perteneciente a la red y el pool VPDN con el rango apropiado a dicha red. En este escenario de pruebas se utilizó el pool 192.168.0.20-192.168.0.25 por razones prácticas.

1: PNS(config)# ip local pool PPTP-Pool 192.168.0.20 192.168.0.25

Paso 3: Creación de cuentas para usuarios PPTP

El último paso en la configuración del router PNS es crear la cuenta de usuario que el cliente PPTP requerirá para autenticarse con el PNS y acceder a los recursos internos. Ya que se utilizan MS-CHAP y MPPE conjuntamente, ambos extremos del túnel deben usar la misma contraseña.

1: PNS(config)# username vpn password 123456

El PAC necesitará el usuario y la contraseña especificados en el comando anterior para conectarse satisfactoriamente a la VPN. Paso 4: Configuración del cliente (PAC) en Windows. PPTP es soportado por la mayoría de los sistemas operativos Windows, siendo este el caso de los equipos con los que cuenta la red corporativa de la Universidad. Esto implica que no es necesario instalar componentes adicionales o programas para el desarrollo de esta propuesta de diseño. Con la finalidad de conectar la VPN, se necesita crear una conexión dial up en el PAC y modificar ciertos parámetros como se muestra a continuación.

79

En Panel de Control/Conexiones de red seleccionar “Crear una conexión nueva”, como se muestra en la Figura 3.15.

Figura 3.15: Crear una conexión dial up.

Seleccionar “Conectarse a la red de mi lugar de trabajo” para crear la conexión PPTP, como se muestra en la Figura 3.16.

Figura 3.16: Tipo de conexión de red.

Seleccionar “Conexión de red privada virtual”, como se muestra en la Figura 3.17.

Figura 3.17: Conexión de red.

80

Se debe proporcionar una descripción para la nueva conexión PPTP como se muestra en la Figura 3.18.

Figura 3.18: Nombre de conexión.

Se debe indicar la dirección IP externa del router PNS con salida hacia la WAN, donde terminará el túnel PPTP, como se observa en la Figura 3.19.

Figura 3.19: Selección de servidor VPN.

Por último, hacer click en “Finalizar” para guardar la configuración de la conexión PPTP, como se muestra en la Figura 3.20.

81

Figura 3.20: Finalización del asistente para conexión nueva.

Prueba de Conectividad Para comprobar que la red PPTP funciona correctamente, se realizaron los siguientes pasos: Paso 1: Desde el cliente, acceder al servidor de túnel (PNS) Hacer doble-click en la conexión de red privada virtual, que se muestra en la Figura 3.21, para abrir la ventana de diálogo donde se deben introducir el par usuario/contraseña (vpn/123456) que anteriormente fue creado en el router PNS, como se puede observar en la Figura 3.22.

Figura 3.21: Conexión de red privada virtual.

82

Figura 3.22: Par usuario/contraseña.

Con la finalidad de comprobar el funcionamiento del protocolo PPTP se configuró un puerto mirror en el switch A para llevar a cabo las capturas de tráfico correspondientes. En la Figura 3.23 se puede comprobar que el establecimiento de la conexión PPTP se lleva a cabo en tres fases, como se describen a continuación: Las dos primeras pertenecen a la conexión de control, la fase 1 utiliza el LCP para iniciar dicha conexión, esto incluye la negociación de parámetros de capa 2 tales como el uso de autenticación, cifrado con MPPE, entre otros protocolos. En la fase 2 el usuario es autenticado ante el servidor mediante MS-CHAP y MS-CHAPv2. Se puede observar claramente en la captura de tráfico que el campo usuario=vpn (frame 12), sin embargo la contraseña se encuentra cifrada.

Figura 3.23: Captura conexión de control.

83

En la fase 3, son invocados los protocolos utilizados por la conexión de datos negociados durante la fase 1. Una vez completada la fase 3, los datos pueden ser enviados a través de la conexión PPP. Para esta prueba se configuró un servidor Apache en el servidor privado y desde el PAC se realizó una petición a la dirección IP 192.168.0.5 por el puerto 80, donde se pueden observar en la Figura 3.24 los paquetes TCP y http correspondientes, así como también el contenido de la página web solicitada en texto plano, direcciones IP privadas de origen y destino, puertos asociados, entre otros.

Figura 3.24: Captura de tráfico http con PPTP.

Paso 2: Desde el cliente, hacer ping al servidor privado Se realizaron pruebas de conectividad desde el cliente (PAC) que consistieron en alcanzar al servidor privado por medio del comando ping, donde se pudo apreciar mediante la captura de tráfico de la Figura 3.25 las direcciones IP de origen y destino y el contenido de los mensajes ICMP en texto plano, a pesar de estar habilitada la conexión PPTP.

84

Figura 3.25: Captura comando ping.

Paso 3: Desde el router PNS, verificar con el comando show vpdn que el cliente haya establecido una sesión PPTP El comando show vpdn muestra información básica sobre todos los túneles VPDN activos, como se puede observar en la Figura 3.26 existe un túnel y una sesión PPTP activos, además de información relevante como el estado de la conexión, la IP del par remoto, el puerto asociado, el ID del túnel PPTP, el valor correspondiente al usuario de dicha conexión, entre otros.

Figura 3.26: Comando show vpdn.

Este comando también puede ofrecer información más detallada sobre la conexión PPTP, como se muestra con los comandos: show vpdn history failure, show vpdn sesión, show vpdn tunnel, entre otros. Por ejemplo, el comando show vpdn history failure muestra el contenido de la tabla de registro de fallas de conexión PPTP al realizar pruebas de conexión con una contraseña inválida, como se puede observar en la Figura 3.27, incluyendo información detallada como el tipo y razón de la falla, la fecha y hora exacta de su ocurrencia , entre otros.

85

Figura 3.27: Comando show vpdn history failure.

4.4.2. IPSec En este escenario, también se han hecho algunas suposiciones como en el caso anterior. Para empezar, no se ha utilizado ningún enlace WAN por lo que las redes de las oficinas que hemos implementado (campus Caracas y extramuros) estarán separadas por una red aparte implementada mediante un switch que simulará dicho enlace WAN. Igualmente se han supuesto direcciones IP fijas, utilizando direcciones IP privadas para las redes de las oficinas y direcciones IP públicas para la red denominada como enlace WAN. Equipos utilizados

Dos routers Cisco 2811, IOS versión 12.4.

Tres switches Cisco Catalyst 2960-48TC.

Dos PCs Dell Pentium 4 1.8Ghz, 1GB de RAM y 160GB de disco duro, con sistema operativo Windows XP, actuando como estaciones de trabajo en cada una de las LAN corporativas (campus Caracas y extramuros).

Escenario de Prueba

Figura 3.28: Escenario de prueba IPSec.

86

Configuración Para la configuración de IPSec/GRE se siguieron los pasos que a continuación se describen:

Paso 1: Configuración de la política IKE.

Paso 2: Configuración del protocolo y directivas IPSec.

Paso 3: Configuración de las listas de acceso para el cifrado.

Paso 4: Configuración de los crypto map.

Paso 5: Aplicar los cripto map. Paso 1: Configuración de la política IKE Debe existir al menos una política IKE que coincida entre dos potenciales pares IPSec. La siguiente configuración para el escenario propuesto muestra una política que utiliza claves pre-compartidas con 3DES como el algoritmo de cifrado. Existe una política IKE por defecto que contiene valores de algoritmo de cifrado, método de hash, grupo Diffie-Hellman, tipo de autenticación y tiempo de vida de la SA. Cuando se utilizan claves pre-compartidas, estas claves deben ser cuidadosamente seleccionadas preferiblemente incluyendo caracteres alfanuméricos y de puntuación. La política IKE se negocia a través del puerto UDP 500 y se debe configurar lo siguiente:

Suite de protección ISAKMP.

Clave ISAKMP.

Router Hub: Para configurar la suite de protección ISAKMP se utilizan las siguientes instrucciones:

1: Hub(config)#interface FastEthernet 0/1 2: Hub(config-if)#ip address <ip_hub> <máscara>

Este comando asigna estáticamente una dirección IP pública correspondiente al router hub.

1: Hub(config)#crypto isakmp policy 10

Este comando crea el objeto de la política ISAKMP. Es posible crear múltiples políticas ISAKMP con diferentes valores.

1:Hub(config-isakmp)#group 2

87

Con este comando se puede declarar el grupo Diffie-Hellman. En este caso se utilizará el grupo 2 que tiene 1024 bits de longitud.

1: Hub(config-isakmp)#lifetime 3600

El tiempo de vida de la SA es de 3600 segundos en este caso. Si no se especifica, el tiempo de vida por defecto es de 86400 segundos o de un día. Cuando transcurre este lapso de tiempo la SA es renegociada como medida de seguridad.

1: Hub(config-isakmp)#authentication pre-share 2: Hub(config-isakmp)#exit

Mediante este comando se le especifica a IKE manualmente el método de autenticación a utilizar, en este caso claves pre-compartidas. Para configurar la clave ISAKMP se utilizan las siguientes instrucciones:

1: Hub(config)#crypto isakmp key <clave> address <ip_spoke>

Con este comando se le indica a IKE la clave a utilizar. El par, en este caso, uno de los router de las sedes, debe tener la misma clave de esta configuración. Router Spoke:

1: Spoke(config)#interface serial 0/1 2: Spoke(config-if)#ip address <ip_spoke> <máscara> 3: Spoke(config)#crypto isakmp policy 10 4: Spoke(config-isakmp)#group 2 5: Spoke(config-isakmp)#lifetime 3600 6: Spoke(config-isakmp)#authentication pre-share 7: Spoke(config-isakmp)#exit 8: Spoke(config)#cryto isakmp key <clave> address <ip_hub>

Paso 2: Configuración del protocolo y directivas IPSec Con la directiva se describe el protocolo de seguridad (AH o ESP) a utilizar con sus algoritmos correspondientes (algoritmo de cifrado, autenticación y hash). La directiva debe coincidir en ambos pares IPSec. Los nombres de las directivas tienen sólo significado local. Puede haber múltiples directivas para usar entre los diferentes pares, durante la negociación de la AS de IPSec todas las directivas son ofrecidas al par, el cual escoge una. En este caso se utilizará el modo túnel por defecto.

88

Router Hub:

1: Hub(config)#crypto ipsec transform-set <nombre_transform_set> esp-3des esp-sha-hmac

Router Spoke:

1: Spoke(config)#crypto ipsec transform-set <nombre_ transform_set> esp-3des esp-sha-hmac

Paso 3: Configuración de las listas de acceso para el cifrado Las entradas de la lista de acceso que definen el tráfico a ser cifrado deben ser imágenes exactas una de otra en los pares IPSec. En este caso, el protocolo IP GRE es especificado en ambas partes origen y destino de la lista de acceso. Todo el tráfico encapsulado en los paquetes GRE está protegido. En el caso específico de las ACL IPSec, permit significa cifrar y deny significa no cifrar. Router Hub:

1: Hub(config)#access-list 101 permit gre host <ip_hub> host <ip_spoke>

Router Spoke:

1: Spoke(config)#access-list 101 permit gre host <ip_spoke> host <ip_hub>

Paso 4: Configuración de los crypto map. La entrada del crypto map une los pares IPSec, la directiva definida, y la lista de acceso utilizada para definir el tráfico a ser cifrado. Las entradas del crypto map son evaluadas secuencialmente. Router Hub:

1: Hub(config)#crypto map <nombre_crypto_map> <num_secuencia> ipsec-isakmp 2: Hub(config-crypto-map)#set peer <ip_spoke> 3: Hub(config-crypto-map)#set session-key lifetime seconds 4000 4: Hub(config-crypto-map)#set transform-set <nombre_transform_set> 5: Hub(config-crypto-map)#match address 101

En este caso, los nombres de los crypto map y los números de secuencia tienen solo significado local. La segunda sentencia establece la dirección IP utilizada por este par para identificar los pares dentro del crypto map. El comando set transform-set asocia las directivas con el crypto map. El comando match address 101 indica que se debe utilizar el access list 101 para determinar que tráfico es relevante.

89

Router Spoke:

1: Spoke(config)#crypto map <nombre_crypto_map> <num_secuencia> ipsec-isakmp 2: Spoke(config-crypto-map)#set peer <ip_hub> 3: Spoke(config-crypto-map)#set session-key lifetime seconds 4000 4: Spoke(config-crypto-map)#set transform-set <nombre_transform_set> 5: Spoke(config-crypto-map)#match address 101

Paso 5: Aplicar los cripto map. Para aplicar el crypto map en la interfaz del router así como las interfaces de los túneles GRE se utilizan los siguientes comandos: Router Hub:

1: Hub(config)#interface Tunel1 2: Hub(config)#bandwidth 1536 3: Hub(config)#ip address <ip_interfaz_tunel> <máscara> 4: Hub(config)#tunnel source <ip_hub> 5: Hub(config)#tunnel destination <ip_spoke> 6: Hub(config)#interface FastEthernet 0/1 7: Hub(config)#crypto map <nombre_crypto_map>

El crypto map debe aplicarse a la interfaz de salida, no a la interfaz de entrada. Router Spoke:

1: Spoke(config)#interface Tunel1 2: Spoke(config)#bandwidth 1536 3: Spoke(config)#ip address <ip_interfaz_tunel> <máscara> 4: Spoke(config)#tunnel source <ip_spoke> 5: Spoke(config)#tunnel destination <ip_hub> 6: Spoke(config)#interface FastEthernet 0/1 7: Spoke(config)#crypto map <nombre_crypto_map>

Prueba de Conectividad Tras haber implementado este escenario de prueba se ha comprobado si se puede establecer la VPN de manera correcta, es decir, si el dispositivo que va a actuar como hub y el que va a actuar como spoke pueden comunicarse antes de iniciar la conexión IPSec correspondiente por medio del comando “ping”. Con la finalidad de comprobar el funcionamiento del protocolo IPSec se configuró un puerto mirror en el switch B para llevar a cabo las capturas de tráfico de protocolos como Telnet y HTTP. En primer lugar se abrieron conexiones Telnet, como se muestra en la

90

Figura 3.29, donde se pueden observar los paquetes pertenecientes a dicho protocolo y las direcciones IP privadas de origen y destino asociadas.

Figura 3.29: Captura de paquetes Telnet.

En la Figura 3.30, se observan en texto plano los datos de una sesión Telnet.

Figura 3.30: Captura de sesión Telnet.

En segundo lugar se configuró un servidor Apache en el servidor privado y desde la PC A se realizó una petición a la dirección IP 192.168.2.2 por el puerto 80. En la Figura 3.31 se pueden observar los paquetes TCP y HTTP correspondientes, así como también el contenido de la página web solicitada en texto plano, direcciones IP privadas de origen y destino, puertos asociados, entre otros.

91

Figura 3.31: Captura de paquetes http.

Por último se habilitó el crypto map en las interfaces f0/1 de cada router, a fin de levantar el túnel IPSec. En la Figura 3.32 se puede observar el inicio de la conexión IPSec con sus respectivas fases ISAKMP/IKE. En la fase 1 (paquetes 739 al 744) se establece la política básica de seguridad a través del intercambio de 6 mensajes, es por ello que se dice que se realiza en modo principal (main mode). Una vez establecido un canal seguro en la fase 1 se inicia la fase 2 (paquetes 745 al 747) que define las ASs y las claves de IPSec y se realiza en el modo agresivo o rápido (quick mode) por medio de tres mensajes, indicando que el origen está en funcionamiento, tras lo cual ambos dispositivos pueden comenzar a usar los protocolos en cuestión.

Figura 3.32: Captura de paquetes IPSec.

Asimismo, se puede identificar el campo SPI en los paquetes ESP que identifica la asociación de seguridad correcta para la comunicación, siendo SPI=0x37e2ed33 la AS para

92

la comunicación en el sentido spoke-hub y SPI=0x93870a8c para la comunicación en el sentido hub-spoke. El receptor utiliza este valor para determinar la asociación de seguridad con la que se debe identificar este paquete. Toda la carga ESP se encapsula dentro de un nuevo header de túnel, el cual no se cifra. La información del nuevo header de túnel sólo se utiliza para enrutar el paquete desde el origen hasta el destino, por lo tanto en la captura de tráfico sólo se visualizan las direcciones IP públicas origen y destino. Si el paquete se envía a través de una red pública, se enrutará hacia la dirección IP del servidor de túnel (hub o spoke) de la intranet receptora. En el ejemplo de la conexión http, donde el paquete irá destinado al servidor privado dentro de la intranet, el servidor de túnel (hub) descifra el paquete, descarta el ESP header y utiliza el IP header original para enrutar el paquete hacia el servidor privado de la intranet. Una vez establecido el túnel IPSec, todos los paquetes contarán con la misma estructura independientemente del protocolo a transmitir, es por esto que en la captura de tráfico sólo se observarán paquetes del protocolo ESP cuya carga útil permanecerá totalmente cifrada. Igualmente se puede obtener información relevante de la configuración del protocolo IPSec en cada uno de los router vinculados, mediante una serie de comandos específicos como por ejemplo show crypto isakmp sa.

Figura 3.33: Comando show crypto isakmp sa.

La Figura 3.33 indica que existe una AS asociada al par 201.201.201.2-201.201.201.1.

93

Figura 3.34: Comando show crypto ipsec sa.

A través del comando mostrado en la Figura 3.34 se puede conocer la configuración completa utilizada por las asociaciones de seguridad existentes:

1. Nombre del crypto map. 2. Interfaz asociada al crypto map. 3. Direcciones IP privadas asociadas al hub y al spoke. 4. Direcciones IP públicas asociadas al hub y al spoke. 5. Número de paquetes encapsulados y desencapsulados hasta el momento. 6. Número de paquetes cifrados y descifrados hasta el momento. 7. Datos de cada asociación de seguridad vinculada al par hub-spoke.

1 2

3

4

5 66

7

94

Figura 3.35: Comando show crypto session.

En la Figura 3.35 se pueden verificar las sesiones existentes, en este caso existe una sesión asociada a la interfaz FastEthernet0/1, cuyo estado es activo y se puede obtener información acerca del peer, de las asociaciones de seguridad y las listas de control de acceso asociadas.

Figura 3.36: Comando show crypto map.

Con esta sentencia se dan a conocer todos los detalles relacionados al crypto map “vpnmap” configurado anteriormente como se muestra en la Figura 3.36.

Figura 3.37: Comando show crypto key.

A través de show crypto key es posible conocer el valor de la clave pre-compartida. En la Figura 3.37 se puede observar que la clave pre-compartida es “ipsec”.

Figura 3.38: Comando show crypto isakmp policy.

95

En la Figura 3.38 se dan a conocer los parámetros de las políticas IKE desarrolladas para este escenario.

4.4.3. OpenVPN A diferencia de los casos anteriores, en este escenario se cuenta con una conexión a Internet para tener en cuenta que tenemos una red WAN de por medio entre el campus Caracas de la UCV y sus extramuros. En este caso, se han utilizado direcciones IP públicas proporcionadas por CANTV como proveedor de servicio a Internet. Equipos utilizados

Una PC con sistema operativo Fedora release 10, kernel Linux 2.6.21.5-117.fc10.i686, actuando como servidor OpenVPN.

Una PC Dell Pentium 4 1.8Ghz, 1GB de RAM y 160GB de disco duro, con sistema operativo Windows XP y cliente OpenVPN versión 2.1.1 actuando como estación de trabajo.

Una PC Dell Pentium 4 1.8Ghz, 1GB de RAM y 160GB de disco duro, con sistema operativo Windows XP actuando como servidor web.

Un switch Cisco Catalyst 2960-48TC.

Escenario de Prueba

Figura 3.39: Escenario de prueba OpenVPN.

Configuración A continuación se describirá el proceso de instalación y configuración de OpenVPN en los sistemas operativos Windows y Linux. Algunos prerrequisitos son imprescindibles si se quiere instalar OpenVPN en un equipo. Las versiones de Windows que soportan OpenVPN son las versiones XP, 2000, Vista y 7, sin embargo, OpenVPN puede ser instalado en casi todas las distribuciones de Linux

Túnel VPN

96

existentes. Además, OpenVPN requiere de las siguientes características en el sistema donde va a ser instalado:

El sistema debe proporcionar soporte para los drivers TUN/TAP. Casi todas las distribuciones de Linux, a partir de la versión 2.4 del kernel, proporcionan soporte para los drivers TUN/TAP.

Las librerías OpenSSL deben estar instaladas en el sistema. En casi todas las distribuciones de Linux es complemento necesario la instalación del paquete OpenSSL, en muchas distribuciones dicho paquete viene ya instalado.

La librería de compresión LZO debe estar instalada. La mayoría de las distribuciones de Linux actuales proporciona esta aplicación ya instalada por defecto.

En las instalaciones de Windows (archivos .exe ejecutable) se instalan a la vez todos los paquetes que hacen falta para poder utilizar OpenVPN, es decir, no es necesario descargar ningún archivo de instalación excepto el que proporciona OpenVPN para los sistemas operativos Windows. La herramienta OpenVPN debe ser instalada tanto en los equipos que funcionen como servidor como en los clientes. No existe una versión para clientes y otra para servidores, desde que OpenVPN se instala en el dispositivo, proporciona tanto las funciones del cliente como las del servidor con sus respectivos comandos y directivas. Para la configuración de OpenVPN se siguieron los pasos que a continuación se describen:

Paso 1: Instalación y configuración del servidor OpenVPN en Linux.

Paso 2: Instalación y configuración del cliente OpenVPN en Windows. Paso 1: Instalación y configuración del Servidor OpenVPN en Linux Al utilizar una distribución de Linux que soporta paquetes de tipo RPM (Red Hat Package Manager) como lo es Fedora en este caso, el método más sencillo para instalar OpenVPN es buscar un archivo RPM binario existente en dicha distribución. También se puede construir el archivo RPM mediante los siguientes comandos:

1: rpmbuild -tb openvpn-[versión].tar.gz

Una vez se tiene el paquete RPM, se puede instalar como cualquier paquete RPM.

1: rpm –ivh openvpn-[detalles].rpm

97

También se puede actualizar la versión de una versión ya instalada mediante la siguiente línea.

1: rpm –Uvh openvpn-[detalles].rpm Instalando OpenVPN mediante un paquete RPM binario se obtienen las siguientes librerías:

OpenSSL.

LZO. Creación de Clave/Certificado de la CA (Certification Authority) Para generar el certificado público y la clave privada de la CA se hizo uso de los scripts proporcionados por OpenVPN que se encuentran en el directorio “easy-rsa” de la distribución. Este directorio generalmente se encuentra en /usr/share/doc/packages/openvpn o /usr/share/doc/openvpn-2.0. Es recomendable copiar este directorio a otra ruta como /etc/openvpn. Una vez en este directorio, se debe editar el archivo “vars”. Entre los parámetros que podemos modificar encontramos la ruta del archivo donde se crearán las claves y certificados, el tamaño de las claves privadas (del servidor, cliente y CA) para su uso en el algoritmo RSA, y los valores por defecto de algunos campos de los certificados tales como key_country, key_province, key_city, key_org y key_email. Por último se deben ejecutar los siguientes scripts para generar la clave privada y el certificado de la CA:

1: . ./vars 2: ./clean-all 3: ./build-ca

Mediante este procedimiento se han generado 2 archivos nuevos:

ca.crt: Archivo correspondiente al certificado público de la CA.

ca.key: Archivo correspondiente a la clave privada de la CA, la cual debe mantenerse protegida ya que es la clave más importante de toda la PKI.

El archivo “ca.key” se puede guardar en algún dispositivo seguro que no tenga conexión (por seguridad) pero el archivo “ca.crt” debe guardarse tanto en el cliente OpenVPN como en el servidor OpenVPN.

98

Creación de Clave/Certificado del Servidor Tras crear la CA se tienen que crear, en el mismo equipo donde se ha creado la CA, el certificado público y la clave privada del Servidor OpenVPN. Para crear la clave privada y el certificado público del servidor se deben ejecutar los siguientes scripts:

1: ../vars Al ejecutar este script se asegura que se han creado y asignado las variables que se utilizarán en el resto de scripts. La variable <nombre_certificado> equivale al campo “Common Name” del certificado. En este escenario se le asignó a la variable <nombre_certificado> el valor “servidor”.

1: ./build-key-server <nombre_certificado>

Este script se ejecuta para crear el par clave/certificado del servidor. Tras completar todos los campos del certificado del servidor, se solicita si se quiere firmar el certificado, utilizando para ello el certificado de la CA, y se debe responder que “si”. Por último, se solicita si se quiere comprometer con el certificado que se va a crear, y también se debe contestar “si”. Tras realizar estos pasos se han generado 4 archivos nuevos:

servidor.crt: Archivo correspondiente al certificado público del servidor.

servidor.key: Archivo correspondiente a la clave privada del servidor, la cual debe permanecer protegida.

X.pem: Archivo correspondiente al certificado público del servidor en formato PEM (Privacy Enhanced Mail). El nombre del archivo proviene de su número de serie del certificado, el cual es X.

servidor.csr: Este archivo sirve para poder crear el certificado del servidor en otro equipo que pueda crearlo y firmarlo, ya que este tiene toda la información que le hace falta.

Creación de Clave/Certificado del Cliente Los pasos para crear la clave privada y el certificado público de los clientes son similares a los que se han realizado para el servidor y para la CA. De nuevo, se deben ejecutar los siguientes scripts:

1: ../vars Al ejecutar este script se crean y se asignan las variables que se utilizarán para poder ejecutar el resto de los scripts.

99

1: ./build-key <nombre_certificado_clienteX> Al introducir el campo <nombre_certificado_clienteX> equivalente al campo “Common Name” en cada uno de los certificados de cliente, conviene utilizar algún identificador para diferenciar uno de otro. En este escenario, al tratarse de un solo cliente, el valor del campo <nombre_certificado_clienteX> es “cliente”. Al igual que en el caso del servidor, tras completar todos los campos del certificado de cada cliente se verifica si se desea firmar el certificado. Al finalizar estos pasos se han generado 4 archivos nuevos:

cliente.crt: Archivo correspondiente al certificado público del cliente.

cliente.key: Archivo correspondiente a la clave privada del cliente, la cual debe permanecer protegida.

X.pem: Archivo correspondiente al certificado público del cliente en formato PEM. El nombre del archivo proviene de su número de serie del certificado, el cual es X.

cliente.csr: Este archivo sirve para poder crear el certificado del cliente en otro equipo que pueda crearlo y firmarlo, ya que este tiene toda la información que le hace falta.

Los archivos “cliente.crt” y “cliente”.key deben ser transferidos al cliente OpenVPN mediante un canal seguro. Creación de los parámetros Diffie-Hellman Los parámetros Diffie Hellman deben ser generados para el servidor OpenVPN. Para esto se debe volver a ejecutar el script “vars” como se ha hecho en los casos anteriores y después ejecutar el script “build-dh”. El tamaño de estos parámetros dependerá del valor que le hayamos asignado a la variable “key_size” en el script “vars” (lo normal es utilizar un tamaño de 1024 bits o 2048 bits).

1: . ./vars 2: ./build-dh

Luego de ejecutar este script se genera un archivo en formato PEM llamado dh1024.pem o dh2048.pem (según sea el caso). Los parámetros Diffie Hellman se utilizan para poder realizar el intercambio de una clave entre dos participantes de manera segura.

100

El archivo de configuración del servidor OpenVPN (servidor.conf) es el siguiente:

1: local 190.38.123.48 2: port 1194 3: dev tun 4: proto udp 5: ca ca.crt 6: cert servidor.crt7 7: key servidor.key 8: dh dh1024.pem 9: server 10.8.0.0 255.255.255.0 10: ifconfig-pool-persist ipp.txt 11: tls-server 12: comp-lzo 13: keepalive 10 120 14: persist-key 15: persist-tun 16: status openvpn-status.log 17: verb 6

A continuación se describe brevemente cada línea del archivo de configuración del servidor OpenVPN (servidor.conf):

local 190.38.123.48: Vincula OpenVPN a la interfaz con la dirección IP 190.38.123.48.

port 1194: Utiliza el puerto 1194.

dev tun: Indica que se va a implementar un túnel mediante un dispositivo “tun” de los drivers TUN/TAP.

proto udp: Utiliza el protocolo UDP como protocolo de transporte del túnel.

ca ca.crt: Carga el certificado público de la CA.

cert servidor.crt: Carga el certificado del servidor OpenVPN.

key servidor.key: Carga la clave privada del servidor OpenVPN.

dh dh1024.pem: Carga los parámetros Diffie Hellman.

server 10.8.0.0 255.255.255.0: Indica que este equipo va a actuar como un servidor y asignará las direcciones IP de la VPN a los clientes que se conecten. El servidor en este caso tomará la dirección IP 10.8.0.1.

ifconfig-pool-persist ipp.txt: Mantiene un archivo llamado “ipp.txt” en el que se encuentran los clientes que se conectan al servidor OpenVPN incluyendo la dirección IP que se le ha asignado y el “Common Name” del certificado que han entregado al servidor OpenVPN.

tls-server: Indica que este equipo actuará como servidor durante el establecimiento del protocolo TLS.

comp-lzo: Indica que se va a utilizar la librería de compresión LZO.

101

keepalive 10 120: Indica que el servidor OpenVPN enviará un ping cada 10 segundos y esperará 120 segundos máximo para recibir una respuesta, sino asumirá que el otro extremo (el cliente OpenVPN) ha caído.

persist-key: Permite que las claves no tengan que ser leídas nuevamente cuando el servidor OpenVPN es reiniciado.

persist-tun: Permite que el túnel no tenga que ser cerrado y abierto de nuevo tras reiniciar el servidor OpenVPN.

status openvpn-status.log: Indica el archivo donde se almacenará la información de estado del túnel.

verb 6: Indica el grado de detalle de información de estado del túnel. Paso 2: Instalación y configuración del Cliente OpenVPN en Windows En los sistemas Windows soportados por OpenVPN (XP, 2000, Vista y 7) todas las aplicaciones y paquetes necesarios (OpenVPN, GUI, librerías de OpenSSL, librería de compresión LZO y los drivers TAP-win32) se instalan a partir de un mismo archivo ejecutable que puede ser descargado de la Internet. En Windows, OpenVPN puede ser ejecutado mediante el comando “openvpn” junto con sus opciones a través de la consola de comandos, o bien puede ser iniciado cargando un archivo de configuración con la extensión .ovpn (extensión .conf en el resto de sistemas operativos). Además, OpenVPN puede ser ejecutado como servicio en equipos Windows, lo que significa que OpenVPN puede ser ejecutado automáticamente al iniciar el sistema operativo. Hay que destacar que OpenVPN debe ser instalado y ejecutado mediante un usuario que tenga privilegios de administrador. Esta restricción se puede evitar en el caso de ejecutar OpenVPN en segundo plano, como un servicio, ya que en tal caso también podrían utilizar OpenVPN usuarios que no posean privilegios de administrador una vez instalado. Al finalizar la instalación de OpenVPN, se añade una interfaz de red adicional (virtual) para la interfaz TUN/TAP, como se muestra en la Figura 3.40.

Figura 3.40: Interfaz virtual TUN/TAP.

Los archivos obtenidos al generar el certificado y la clave de seguridad de cada cliente, deben ser copiados en OpenVPN\config del directorio de instalación de Windows. Estos archivos son los siguientes: ca.crt, clienteX.crt y clienteX.key como se muestran en la Figura 3.41.

102

Figura 3.41: Archivos a copiar en el cliente OpenVPN.

Teniendo en cuenta que “X” es el número que se corresponde con el cliente, por ejemplo, cliente2.crt y cliente2.key para el cliente 2. Estos archivos se encuentran en el directorio /etc/openvpn/easy-rsa/keys del servidor, y deben copiarse de forma segura hacia el cliente, por ejemplo con ssh, o mediante algún medio magnético seguro. Seguidamente se debe guardar una copia del archivo de configuración del cliente (client.ovpn) que se encuentra en el directorio OpenVPN\sample-config en el directorio OpenVPN\config de cada cliente, como se muestra en la Figura 3.42, y con un editor de texto realizar los cambios necesarios, en este caso solo se cambió el siguiente campo:

Antes Después

remote <my-server-1> 1194 remote <ip estática del servidor> 1194

Figura 3.42: Archivo de configuración del cliente.

El archivo de configuración del cliente OpenVPN (cliente.ovpn) es el siguiente:

1: dev tun 2: proto udp 3: remote 190.38.123.48 1194 4: tls-client 5: nobind 6: ca ca.crt 7: cert cliente.crt 8: key cliente.key 9: comp-lzo 10: resolv-retry infinite 11: keepalive 10 120 12: persist-key 13: persist-tun 14: status openvpn-status.log 15: verb 6

103

A continuación se describe brevemente cada línea del archivo de configuración del cliente OpenVPN (cliente.conf).

dev tun: Indica que se va a implementar un túnel mediante un dispositivo “tun” de los drivers TUN/TAP.

proto udp: Utiliza el protocolo UDP como protocolo de transporte del túnel, en este caso particular.

remote 190.38.123.48 1194: Indica a que equipo se tiene que conectar el cliente para establecer el túnel utilizando el puerto 1194.

tls-client: Indica que este equipo actuará como cliente durante el establecimiento del protocolo TLS.

nobind: Indica que OpenVPN no se vinculará a la IP local y puerto de este equipo.

ca ca.crt: Carga el certificado de la CA.

cert cliente.crt: Carga el certificado del cliente OpenVPN.

key cliente.key: Carga la clave privada del cliente OpenVPN.

comp-lzo: Indica que se va a utilizar la librería de compresión LZO.

resolv-retry infinite: Indica que el cliente intentará de manera indefinida resolver la dirección o nombre de host dado por la directiva “remote”.

keepalive 10 120: Indica que el cliente OpenVPN enviará un ping cada 10 segundos y esperará 120 segundos máximo para recibir una respuesta, sino asumirá que el otro extremo (el servidor OpenVPN) no está activo.

persist-key: Permite que las claves no tengan que ser leídas nuevamente cuando el cliente OpenVPN es reiniciado.

persist-tun: Permite que el túnel no tenga que ser cerrado y abierto de nuevo tras reiniciar el cliente OpenVPN.

status openvpn-status.log: Indica el archivo donde se almacenará la información de estado del túnel.

verb 6: Indica el grado de detalle de información de estado del túnel. Prueba de Conectividad Para comprobar que la conexión OpenVPN funciona correctamente, se realizaron los siguientes pasos: Paso 1: Desde el servidor OpenVPN se inició el servicio mediante la línea de comando “openvpn - -config /etc/openvpn/serve.conf” desde el directorio /etc/openvpn/keys, como se muestra en la Figura 3.43. Una vez inicializados los parámetros correspondientes (Diffie-Hellman, autenticación TLS, interfaces TUN/TAP, entre otros) se muestra finalmente el mensaje “Initialization Sequence Completed” en la consola del servidor, indicando que se encuentra disponible para recibir conexiones de clientes OpenVPN.

104

Figura 3.43: Inicialización del servidor OpenVPN.

Paso 2: Desde el cliente se inició el servicio haciendo doble click en el ícono de la aplicación, como se muestra en la Figura 3.44.

Figura 3.44: Icono cliente OpenVPN.

Una vez inicializados los parámetros correspondientes (Diffie-Hellman, compresión LZO, interfaces TUN/TAP, entre otros) y autenticado el cliente mediante TLS se muestra finalmente el mensaje “Initialization Sequence Completed” en la consola del cliente OpenVPN, indicando que fue establecido un túnel OpenVPN con el servidor, como se observa en la Figura 3.45.

105

Figura 3.45: Consola cliente OpenVPN.

En la barra de herramientas se muestra un ícono de la interfaz virtual OpenVPN donde indica que el cliente ahora está conectado, como se observa en la Figura 3.46.

Desconectado Conectado

Figura 3.46: Icono interfaz virtual OpenVPN.

Se puede observar en detalle el establecimiento de la conexión con el cliente en la consola del servidor OpenVPN, como se muestra en la Figura 3.47.

106

Figura 3.47: Establecimiento del túnel OpenVPN.

Paso 3: Tras el montaje de este escenario se comprobó la tabla de rutas del cliente OpenVPN a través del comando “netstat -rn” como se observa en la Figura 3.48.

107

Figura 3.48: Comando netstat –rn.

Al tener clientes Windows se utilizan subredes /30 para implementar los túneles [7] debido a limitaciones dadas por los controladores TUN/TAP de Windows (conocidos como TAP-Win32 drivers) para la emulación de túneles, por lo que el servidor OpenVPN utiliza las cuatro primeras IPs para implementar el túnel:

10.8.0.0: Dirección de Red y de Subred.

10.8.0.1: Dirección IP del túnel en el extremo del servidor OpenVPN. Es la dirección IP que se le da a la interfaz “tun” del servidor OpenVPN.

10.8.0.2: Es la dirección IP asignada al otro extremo del túnel que ha implementado el servidor OpenVPN, pero no es asignada a ningún cliente.

10.8.0.3: Es la dirección de broadcast de subred. Teniendo en cuenta que las subredes tienen direcciones de subred y de broadcast que no podrán ser asignadas a los clientes, el primer cliente tendrá asignada a su interfaz “tun” la IP 10.8.0.6 y como extremo contrario del túnel la IP 10.8.0.5, que es una IP que no se utiliza, pero sirve para representar el otro extremo del túnel. De la misma manera, el segundo cliente en conectarse tendrá la IP 10.8.0.10 en su interfaz “tun”, el tercero la IP 10.8.0.14 y el cuarto cliente tendrá la IP 10.8.0.18.

108

Como 10.8.0.5 es solo una dirección IP virtual dentro del servidor OpenVPN utilizada como un extremo final para las rutas del cliente con la IP 10.8.0.6, OpenVPN no tiene ningún problema para responder los ping enviados a la dirección 10.8.0.5. Pero, en este escenario, hay que destacar que la dirección IP real del servidor no es la 10.8.0.5 sino que es la 10.8.0.1, ya que es la dirección IP que se reconoce en el sistema operativo del servidor, pero no existe ningún problema para responder ping que proceden de la IP 10.8.0.6 (IP del cliente). Paso 4: Por último, para comprobar el funcionamiento de OpenVPN, se configuró un puerto mirror en el switch A para llevar a cabo las capturas de tráfico de protocolos como ICMP y HTTP, donde se pudo observar, como se muestra en la Figura 3.49, el intercambio de mensajes cifrados a través del protocolo UDP.

Figura 3.49: Captura de tráfico OpenVPN.

Se recomienda utilizar UDP como protocolo de transporte de OpenVPN. Esto no ofrece ninguna capa extra de seguridad al modelo ya implementado, pero permite que OpenVPN trabaje de manera más eficiente y que no tenga problemas en el caso de utilizar TCP, ya que la fiabilidad que proporcionan las capas TCP es contraproducente en este caso. La capa TCP superior es completamente innecesaria, porque la capa inferior garantiza la entrega de segmentos TCP pero la capa superior TCP no sabe nada de esto, por lo que dicha capa siempre asume que tiene protocolos no fiables por debajo de ella y hace su función de protocolo fiable (aunque no deba hacerlo, en este caso).

4.5. Fase 5. Comparación y selección de una propuesta de diseño VPN.

En base a la investigación realizada sobre las principales implementaciones de VPN y a lo expuesto en cada una de las propuestas de diseño con sus respectivos escenarios de prueba, se describe en la Tabla 3.5 un cuadro comparativo evaluando ciertas características comunes y aspectos críticos que conllevarán a la selección de la propuesta

109

que mejor se adapte a las necesidades expuestas las fases 1 y 2, dando una respuesta viable al problema planteado.

Componente PPTP con MPPE IPSec OpenVPN

Autenticación CHAP.

MS-CHAP v2.

PAP.

Claves pre-compartidas.

Certificados digitales.

Claves pre-compartidas.

Certificados digitales.

Confidencialidad

Cifrado de conexión de control utilizando:

MPPE (40 y 128 bits).

Cifrado de conexión de control y de datos utilizando:

DES (64 bits).

3DES (192 bits).

AES (128, 192 y 256 bits).

Cifrado de conexión de control y de datos utilizando:

DES (64 bits).

IDEA (128 bits).

3DES (192 bits).

AES (128, 192 y 256 bits).

RC2 (40, 64 y 128 bits).

RC4 (40, 64 y 128 bits).

Blowfish (40 a 448 bits).

RC5 (40 a 2040 bits).

Integridad No proporciona

integridad de datos17.

SHA-1 (160 bits). MD2 (128 bits).

MD5 (128 bits).

SHA-1 (160 bits).

Topología de Red Sitio-a-sitio.

Acceso remoto.

Sitio-a-sitio.

Acceso remoto.

Firewall.

Sitio-a-sitio.

Acceso remoto.

Requerimientos de

implementación de las propuestas.

Requiere de configuración de cliente.

No requiere de configuración de cliente.

Requiere de configuración de cliente.

Necesidad de permisos de administrador en el cliente.

No requiere permisos de administrador en el cliente.

Necesidad de permisos de administrador en el cliente.

Complejidad (configuración)

Baja. Alta. Baja.

Propietario Sí. No. No.

Documentación Amplia. Amplia. Escasa.

Portabilidad No. Sí. Sí.

Escalabilidad Sí. Sí. Sí.

Tabla 3.4: Comparación de las propuestas de diseño.


http://technet.microsoft.com/es-es/library/cc736821(WS.10).aspx

110

De la Tabla 3.5 se puede concluir que existen tres aspectos de seguridad importantes por los que no se recomienda la propuesta basada en PPTP en comparación con las otras dos propuestas:

Ataques a la conexión de control: No existe protección para la conexión de control TCP utilizada por PPTP, ya que no se proporciona integridad de los mensajes enviados entre el PAC y el PNS. Por lo tanto es susceptible a manipulación de los datos y ataques de suplantación (session hijacking) [10].

Algoritmo de cifrado débil: En PPTP sólo la carga útil PPP se encuentra encriptada. Cualquier otra información, como la conexión de control y los headers de la conexión de túnel no se encuentran cifrados. Además, MPPE soporta RC-40 y RC-128 para el cifrado, los cuales son ampliamente conocidos como sistemas vulnerables [10].

Ataques a la información de los headers IP, GRE y PPP: La información de estos headers no se encuentra protegida en la conexión de túnel, como se mencionó en el Capítulo II. Por lo tanto es posible para un atacante escuchar en dicha conexión y modificarla o realizar un ataque de suplantación (como en el caso de la conexión de control).

Aunque la implementación de PPTP es relativamente sencilla, otra desventaja de esta propuesta es que dicha implementación es dependiente del sistema operativo Windows. Del mismo modo, aunque IPSec es un estándar, en el escenario que considera su uso dentro de la red corporativa de datos de la UCV se propone la configuración de routers Cisco como dispositivos VPN, por lo tanto este diseño es dependiente de dicho fabricante, siendo una de sus principales limitantes en caso de que existan cambios en la plataforma tecnológica actual; sin embargo IPSec es considerada como la tecnología estándar de VPN, además de proporcionar mayor seguridad que PPTP al proveer mecanismos de autenticación, integridad y confidencialidad a todo el enlace y contar con algoritmos más robustos, como por ejemplo AES, que se utiliza para cifrar todo el paquete IP (incluyendo los headers del mensaje). El escenario IPSec presenta ventajas adicionales al tratarse de un modelo de conectividad sitio-a-sitio resultando transparente tanto para aplicaciones como para usuarios finales. Esta propuesta sólo requiere de la configuración de los routers en los extremos del túnel por lo que no es necesaria la instalación de clientes en cada usuario final de la VPN. Sin embargo, este modelo compromete la seguridad entre el usuario final y los extremos del túnel pudiendo ser vulnerable a ataques del tipo man in the middle y de denegación de servicio (DoS). Otra de las desventajas es que IPSec autentica equipos, no usuarios: la definición de identificación y contraseña de usuarios no es entendida por IPSec. Si lo que se requiere es limitar el acceso a recursos dependiendo del usuario que desee ingresar, como es el caso

111

de estudio, entonces se deberán utilizar otros mecanismos de autenticación en combinación con IPSec. Adicionalmente, la implementación de IPSec necesita del uso de muchos puertos y protocolos en el sistema que lo implemente y requiere modificaciones críticas al kernel dando como resultado que su configuración sea compleja. Por su parte, OpenVPN no opera en el kernel sino que opera en el espacio de usuario, incrementando de esta manera la seguridad y la escalabilidad, pudiendo contener los fallos en este espacio más rápidamente sin comprometer todo el sistema. OpenVPN emplea interfaces virtuales del espacio de usuario para controlar el acceso sin la necesidad de depender del kernel, separando lógicamente los componentes de red de los componentes de cifrado y seguridad, obteniendo de esta manera un modelo que puede ser exportado a diferentes plataformas. OpenVPN es soportada en sistemas operativos como Linux, Windows 2000/XP/Vista/7, OpenBSD, FreeBSD, NetBSD, Mac OS X y Solaris. Además, soporta autenticación del cliente mediante dos factores, permite utilizar políticas de acceso a usuarios y grupos específicos, y reglas de firewall aplicadas a las interfaces virtuales. La integración de las interfaces virtuales en el kernel de ciertos sistemas operativos viene en concordancia con la aparición de las VPN. IPSec y otras tecnologías como SSL/TLS o PPTP permiten la implementación de VPN, pero no si el tiempo para crearlas es muy reducido. Por ejemplo, para un usuario que tenga la necesidad de desplazarse le supone un beneficio en tiempo la implementación de un túnel con la sede central mediante estos adaptadores virtuales ya que en el caso de optar por otra opción, como IPSec, el tiempo de aprendizaje e implementación se incrementaría considerablemente. El modelo de seguridad de OpenVPN se basa en la utilización de SSL/TLS para la sesión de autenticación y un modelo muy similar al del protocolo ESP de IPSec para cifrar el túnel de transporte sobre UDP, y proteger así de ataques activos y pasivos. Además OpenVPN utiliza para la infraestructura de clave pública (PKI) certificados X.509 para la autenticación, el protocolo TLS para el intercambio de claves y algoritmos HMAC para la autenticación de los datos del túnel y así prevenir ataques de inyección de paquetes al subsistema SSL/TLS. En resumen, tomando en cuenta lo descrito en las propuestas definidas en la fase 3, la configuración de sus respectivos escenarios de prueba detallados en la fase 4, y la comparación presentada en la fase 5 de las tecnologías VPN según sus ventajas y desventajas en relación al caso de estudio, se recomienda la implementación de la tecnología OpenVPN como solución de seguridad para la conexión entre el campus Caracas y las dependencias extramuros de la UCV según las siguientes ventajas:

Permite su instalación en casi cualquier plataforma.

112

Tanto la instalación como su uso son relativamente simples.

Es una solución de conectividad de código abierto (está publicado bajo la licencia GPL, de software libre)

Variedad de algoritmos de cifrado, tamaños de clave, o resúmenes HMAC mediante la librería OpenSSL.

Uso de compresión en tiempo real y gestión del tráfico para manejar la utilización del ancho de banda.

Las interfaces virtuales permiten la implementación de reglas de firewall muy específicas como si se tratase de una tarjeta Ethernet.

Se desplaza la complejidad de la VPN al espacio de usuario, separando lógicamente los componentes de red de los componentes de cifrado y seguridad.

Se ha construido con un diseño modular. Todo lo relacionado con el cifrado está soportado por la librería OpenSSL y todo lo relacionado con la funcionalidad de los túneles IP está proporcionado por el adaptador virtual TUN/TAP.

Puede ser configurado para ejecutarse como un servicio TCP o UDP y además como servidor (simplemente esperando conexiones entrantes) o como cliente (iniciando conexiones).

Permite múltiples conexiones en el mismo puerto TCP o UDP.

Puede ser implementado fácilmente tanto en topologías sitio-a-sitio como de acceso remoto.

Proporciona opciones para dar protección en la seguridad a nivel de usuario, con comandos para restringir la parte del sistema de archivos al que OpenVPN puede acceder, para disminuir los privilegios al iniciar el sistema, y para asegurar que las claves y los datos del túnel nunca se guardarán en el disco donde después puedan ser recuperados.

113

5. Conclusiones

A lo largo de este documento se ha hecho una completa recopilación de los conceptos teóricos y prácticos de las VPN, con lo que se obtuvo un conjunto de conocimientos y experiencias aplicados directamente a la ejecución del proyecto. Mediante el levantamiento de información del ambiente de la red corporativa de datos de la UCV, se detectó la falta de seguridad que presentan los usuarios de las dependencias extramuros al transmitir datos críticos pertenecientes a los sistemas académicos y de correo electrónico corporativo, ya que algunos de ellos se envían en texto plano por la red, generando una brecha de seguridad que compromete dicha información. Otro aspecto importante derivado de esta investigación lo constituye el hecho de que se logró ampliar el uso de las características técnicas de algunos elementos de hardware que conforman la infraestructura de datos de la UCV. De este modo se llevaron a cabo tres propuestas de diseño, con sus respectivos escenarios de prueba, para dar respuesta al problema planteado siendo la primera de ellas una solución PPTP, la segunda una solución IPSec y la tercera una solución SSL/TLS. La disponibilidad de los equipos de red utilizados para implementar los escenarios de prueba representó una limitante del presente estudio ya que pertenecen a un laboratorio de investigación con un horario restringido. Luego de la implementación del conjunto de escenarios de prueba y el análisis donde se tomaron en cuenta las ventajas y desventajas de cada solución con respecto a la situación planteada, se sugirió SSL/TLS como tecnología para implementar la VPN, optando por OpenVPN por ser una herramienta de software libre completa que se adapta de la mejor manera al caso de estudio y puede ser ampliamente aprovechada para lograr que los diferentes sitios sean capaces de comunicarse a través de un mecanismo sencillo, compatible e independiente de la plataforma utilizada. Esta propuesta sugiere la expansión de la movilidad de los usuarios de la red universitaria, hacia cualquier parte del mundo dónde exista una conexión a Internet, porque se permite acceder a los servicios de la red sin tener que estar físicamente dentro de ella. Por otra parte, en cuanto al aporte o importancia de la presente investigación en relación al proceso de implantación de la tecnología VPN en la UCV, se puede calificar como significativo tomando en cuenta que actualmente la DTIC se encuentra en la búsqueda de una solución VPN que provea seguridad al mencionado enlace. En base a los aspectos descritos anteriormente, desde el punto de vista de todos los objetivos alcanzados durante el desarrollo de la investigación, se puede afirmar que se propone una solución viable al problema planteado inicialmente, pues se ha diseñado una propuesta técnicamente factible para la implantación de la tecnología VPN entre el

114

campus Caracas de la UCV y sus dependencias extramuros utilizando OpenVPN como protocolo de red privada virtual. En base al escenario propuesto, se recomienda:

Crear para cada cliente su propia llave y certificado.

Realizar la distribución de llaves y certificados de manera segura, en lo posible de manera personal.

Mantener la clave privada de la CA en otro equipo que no esté conectado a la red o en cualquier dispositivo de almacenamiento seguro.

Utilizar UDP como protocolo de transporte de OpenVPN.

Utilizar un plugin de autenticación a través de login y password para clientes que deseen conectarse al servidor OpenVPN.

Implementar reglas de acceso que permitan enviar una parte del tráfico protegido y otra en texto plano, por lo que no es necesario proteger todo el tráfico del enlace.

Algunas propuestas a considerar para posibles trabajos futuros, son las siguientes:

Implementar la autenticación de los clientes OpenVPN mediante login y password vía LDAP (Lightweight Directory Access Protocol), utilizando para ello el paquete OpenLDAP.

Utilización de OpenVPN bajo la versión 2.2.1 (release 07/06/2011).

Desarrollo de alguna interfaz gráfica de usuario GUI que además de ofrecer alguna manera más amigable de generar los archivos de configuración ofreciera también la posibilidad de generar los certificados, claves privadas, CA y otros aspectos relacionados con la seguridad.

Implementar las propuestas de diseño llevadas a cabo, en un escenario real entre uno de los extramuros y el campus Caracas.

115

6. Referencias

[1] Cisco Systems, Inc. Data-only site-to-site IPSec VPN design guide. Cisco Press. 2005. [2] Cisco Systems, Inc. PPTP with MPPE. Cisco Press. Enero, 2001. [3] D. Eastlake. Cryptographic Algorithm Implementation Requirements for ESP and AH. RFC 4305. Diciembre, 2005. [4] D. Farinacci et al. Generic Routing Encapsulation (GRE). RFC 2784. Marzo, 2000. [5] F. Arévalo. Cómo escoger e implementar una VPN conceptos teóricos y prácticos. Tesis de Grado. 2003. [6] I. Pepelnjak, J. Guichard. MPLS and VPN Architectures. Cisco Press. Junio, 2000. [7] J. Tomás. Servicio VPN de acceso remoto basado en SSL mediante OpenVPN. Tesis de Grado. Octubre, 2008. [8] K. Hamzeh et al. Point-to-Point Tunneling Protocol (PPTP). RFC 2637. Julio, 1999. [9] M. Townsley. Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update. RFC 3438. Diciembre, 2002. [10] R. Deal. The Complete Cisco VPN Configuration Guide. Cisco Press. Diciembre, 2005. [11] S. Kent. IP Authentication Header. RFC 4302. Diciembre, 2005. [12] S. Kent. IP Encapsulating Security Payload (ESP). RFC 4303. Diciembre, 2005. [13] T. Dierks, C. Allen. The TLS Protocol Version 1.0. RFC 2246. Enero, 1999. [14] V. Aceituno. Seguridad de la Información. Limusa. 2006. [15] V. Mendillo. Práctica sobre Red Privada Virtual (VPN) con L2TP e IPSEC. Notas de docencia. 2007. [16] V. Mendillo. Práctica sobre Red Privada Virtual (VPN) con PPTP y SSH. Notas de docencia. 2007. [17] V. Mendillo. Práctica sobre Red Privada Virtual (VPN) con SSL Y TLS. Notas de docencia. 2007.

116

7. Glosario 3DES (Triple DES): Algoritmo que hace triple cifrado del DES. También es conocido como TDES, fue desarrollado por IBM en 1978. AC (Autoridad de Certificación): Entidad de confianza, responsable de emitir y revocar los certificados digitales. ACK (Acknowledgement): También conocido como acuse de recibo, es un mensaje que se envía para confirmar que un mensaje o un conjunto de mensajes han llegado a su destino. ACL (Access Control List): Lista de control de acceso cuyo objetivo principal es filtrar tráfico, permitiendo o denegando el tráfico de red de acuerdo a alguna condición. AES (Advanced Encryption Standard): Esquema de cifrado por bloques adoptado como un estándar de cifrado por el gobierno de los Estados Unidos de América, también conocido como Rijndael. Al contrario que su predecesor DES, Rijndael es una red de sustitución-permutación. Es rápido, fácil de implementar y requiere poca memoria. AH (Authentication Header): Protocolo que proporciona únicamente mecanismos de autenticación. ANSI C: Estándar publicado por el Instituto Nacional Estadounidense de Estándares (ANSI), para el lenguaje de programación C. Apache: Servidor web HTTP de código abierto. AS (Asociación de Seguridad): Acuerdos que se establecen entre dos equipos antes del intercambio de información protegida y especifican los servicios de seguridad que se aplicarán al tráfico correspondiente. ATM (Asynchronous Transfer Mode): Método de transmisión de paquetes, llamados celdas, usando un tamaño de paquete fijo. Backbone: Principales conexiones troncales de una red. Blowfish: Codificador de bloques simétricos que usa bloques de 64 bits, diseñado por Bruce Schneier en 1993 intentando reemplazar al antiguo DES e incluido en un gran número de conjuntos de codificadores y productos de cifrado. Bridge: Dispositivo de interconexión de redes que opera en la capa 2 del modelo de referencia OSI, que interconecta dos segmentos de red. Broadcast: Modo de transmisión de información donde un nodo emisor envía información a una multitud de nodos receptores de manera simultánea. Canal D: Tipo de canal de ISDN que transporta la señalización de llamada.

117

CHAP (Challenge Handshake Authentication Protocol): Protocolo de autenticación remota o inalámbrica mediante desafío y respuesta que utiliza el esquema de hash estándar del MD5 para cifrar la respuesta. Diversos proveedores de servicios emplean CHAP (IETF RFC 1994-1996). CIR (Commited Information Rate): Ancho de banda contratado por un tiempo determinado. CRL (Certificate Revocation List): Lista de certificados que han sido revocados, ya no son válidos y en los que no debe confiar ningún usuario del sistema. DES (Data Encryption Standard): Esquema de cifrado simétrico, que trabaja con bloques de 64 bits, creado con el objeto de proporcionar un algoritmo de cifrado normalizado para redes de computadores. Se basa en un sistema monoalfabético, consistente en la aplicación sucesiva de varias permutaciones y sustituciones. DHCP (Dynamic Host Configuration Protocol): Protocolo de red que permite a los clientes de una red IP obtener sus parámetros de configuración de red automáticamente (IETF RFC 2131). Dialup: Forma de acceso a Internet en la que el cliente utiliza un módem para llamar a través de la Red Telefónica Conmutada (RTC) al nodo del ISP, un servidor de acceso (por ejemplo PPP) y el protocolo TCP/IP para establecer un enlace, que permite entonces que se enrute a Internet. Diffie-Hellman: Protocolo que permite el intercambio secreto de claves entre dos partes que no han tenido contacto previo, utilizando un canal inseguro, y de manera anónima (no autenticada). Se emplea generalmente como medio para acordar claves simétricas. DMZ (Demilitarized Zone): También conocida como zona desmilitarizada, es una red local que se ubica entre la red interna de una organización y una red externa, que permite un acceso controlado a los servidores, proxies y otros servicios de web en un entorno que se puede poner en compromiso sin afectar a la seguridad de la red interna. DoS (Denial of Service): También conocido como denegación de servicio, es un ataque a un sistema de computadoras o red que causa que un servicio o recurso sea inaccesible a los usuarios legítimos. DSA (Digital Signature Algorithm): También conocido como algoritmo de firma digital, es un estándar del gobierno federal de los Estados Unidos de América para firmas digitales. EAP (Extensible Authentication Protocol): Autenticación framework usada habitualmente en redes WLAN. EIGRP (Enhanced Interior Gateway Routing Protocol): Protocolo de enrutamiento híbrido, propiedad de Cisco Systems, que ofrece lo mejor de los algoritmos de vector de distancias y del estado de enlace. EIR (Excess Information Rate): Especifica la cantidad de información mayor o igual que el CIR, hasta el cual las tramas son transmitidas sin pérdidas.

118

Enlaces E1 y E3: Grupo de circuitos que se empaquetan entre dos centrales telefónicas. Esto permite al operador de redes proporcionar circuitos privados E1 de extremo a extremo entre clientes ubicados en diferentes países y que comparten entre ellos enlaces comunes de alta capacidad. Físicamente el E1 transmite 32 intervalos de tiempo (timeslots) y el E3 transmite 512, pero uno se usa para sincronización de tramas y otro, normalmente, para señalización. Escalabilidad: Capacidad del sistema informático de cambiar su tamaño o configuración para adaptarse a las circunstancias cambiantes. ESP (Encapsulation Security Payload): Protocolo que proporciona confidencialidad, autenticación, integridad y protección contra réplica para la carga útil IP. Ethernet: Tecnología de redes LAN basada en tramas de datos, que define las características de cableado y señalización de nivel físico y los formatos de trama del nivel de enlace de datos del modelo OSI. Failover: Modo de operación de backup en el cual las funciones de un componente del sistema son asumidas por un segundo componente del sistema cuando el primero no se encuentra disponible debido a un fallo ó un tiempo de parada preestablecido. Fibra Óptica Monomodo: Fibra óptica en la que sólo se propaga un modo de luz. Se logra reduciendo el diámetro del núcleo de la fibra. Su transmisión es paralela al eje de la fibra. Permiten alcanzar grandes distancias y transmitir elevadas tasas de información. Firewall: Elemento de hardware o software utilizado en una red de computadoras para controlar las comunicaciones, permitiéndolas o prohibiéndolas según las políticas de red que haya definido la organización responsable de la red. Frame Relay: Técnica de comunicación mediante retransmisión de tramas para redes de circuito virtual, que consiste en la transmisión de una variedad de tamaños de tramas o marcos para datos. FreeBSD: Sistema operativo libre para computadoras basado en los CPU de arquitectura Intel. FTP (File Transfer Protocol): Protocolo de transferencia de archivos entre sistemas conectados a una red TCP basado en la arquitectura cliente-servidor (IETF RFC 959). Gateway: También conocido como pasarela o puerta de enlace, es un dispositivo que permite interconectar redes con protocolos y arquitecturas diferentes a todos los niveles de comunicación. Gigabit Ethernet: También conocida como GigE o 1000-Base/T, es una ampliación del estándar Ethernet que consigue una capacidad de transmisión de 1 Gbps, correspondientes a unos 1000 Mbps de rendimiento contra unos 100 Mbps de Fast Ethernet. GNU/GPL (GNU General Public License): Licencia creada por la Free Software Foundation en 1989 y está orientada principalmente a proteger la libre distribución, modificación y uso de software.

119

GRE (Generic Routing Encapsulation): Tecnología desarrollada originalmente por Cisco como un método para tomar paquetes de un protocolo, encapsularlos en paquetes IP, y transportarlos a través de una red IP (IETF RFC 1701-1702). GUI (Graphical User Interface): También conocido como interfaz gráfica de usuario, es un programa que proporciona un entorno visual sencillo para permitir la comunicación con el sistema operativo de una máquina o computador. Handshake: Proceso automatizado de negociación que define de forma dinámica los parámetros de un canal de comunicaciones establecido entre dos entidades antes de que comience la comunicación normal por el canal. Hash: Función o método para generar claves o llaves que representen de manera casi unívoca a un documento, registro, archivo, etc. Header: También conocido como cabecera, se refiere a la información suplementaria situada al principio de un bloque de información que va a ser almacenada o transmitida y que contiene información necesaria para el correcto tratamiento del bloque de información. HMAC: Código de autenticación de mensajes basado en funciones hash criptográficas. HMAC puede usarse con cualquier función hash criptográfica iterativa como, por ejemplo, MD5, SHA-1, combinada con una clave compartida secreta. Host: Computadora conectada a una red, que provee y utiliza servicios de ella. HTTP (HyperText Transfer Protocol): Protocolo usado en cada transacción de la web (WWW). HTTP fue desarrollado por el consorcio W3C y la IETF (IETF RFC 1945-2616-2774). HTTPS (Hyper Text Transfer Protocol Secure): Protocolo de aplicación basado en el protocolo HTTP, destinado a la transferencia segura de datos de hiper texto (IETF RFC 2818). IANA (Internet Assigned Numbers Authority): Agencia de Asignación de Números de Internet. ICMP (Internet Control Message Protocol): Subprotocolo de control y notificación de errores del Protocolo de Internet (IP). Como tal, se usa para enviar mensajes de error (IETF RFC 792). ICV (Integrity Check Value): Valor que se utiliza para comprobar la autenticación del mensaje y su integridad. IDEA (International Data Encryption Algorithm): Cifrador por bloques de 64 bits diseñado por Xuejia Lai y James L. Massey. Fue un algoritmo propuesto como reemplazo del DES. IDEA fue utilizado como el cifrador simétrico en las primeras versiones de PGP. IETF (Internet Engineering Task Force): Organización internacional abierta de normalización, que tiene como objetivos el contribuir a la ingeniería de Internet, actuando en diversas áreas, tales como transporte, encaminamiento, seguridad.

120

IKE (Internet Key Exchange): Protocolo estándar de asociación de seguridad y resolución de intercambio de claves (IETF RFC 2409). Internet2: Proyecto que agrupa un gran número de universidades y centros de investigación a nivel mundial con el objetivo principal de promover las tecnologías de redes de alta velocidad, que contribuyan al desarrollo de las aplicaciones con alta demanda de recursos tecnológicos. IOS (Internetwork Operating System): Sistema operativo creado por Cisco Systems para programar y mantener equipos de interconexión de redes informáticas IP (Internet Protocol): Protocolo no orientado a conexión usado tanto por el origen como por el destino para la comunicación de datos a través de una red de paquetes conmutados (IETF RFC 791). IPSec (IP Security): Conjunto de estándares que proveen autenticación, integridad y confidencialidad a la capa de red entre dos pares de dispositivos, también incluye protocolos para el establecimiento de claves de cifrado (IETF RFC 4301-4309). IPv4 (Internet Protocol version 4): Cuarta versión de IP, y la primera en ser implementada a gran escala (IETF RFC 791). IPv6 (Internet Protocol version 6): Versión de IP diseñada para reemplazar a IPv4 (IETF RFC 2460). IPX (Internetwork Packet Exchange): Protocolo de datagramas rápido orientado a comunicaciones sin conexión que se encarga de transmitir datos a través de la red, incluyendo en cada paquete la dirección de destino. ISAKMP/Oakley (Internet Security Association and Key Management Protocol/Oalkey): Protocolo por omisión para la administración de las claves públicas utilizadas por AH y ESP. Oakley es un protocolo de intercambio de llaves basado en una versión mejorada del algoritmo de Diffie-Hellman. ISAKMP es un marco de trabajo para la administración de claves en Internet, definiendo formatos para negociación y atributos de seguridad (IETF RFC 2408). ISDN (Integrated Services Digital Network): Red que permite la integración de servicios en un único acceso, independientemente de la naturaleza de la información a transmitir y del equipo terminal que la genere, al ofrecer conexiones digitales de extremo a extremo. ISP (Internet Service Provider): Empresa dedicada a conectar a Internet a los usuarios o las distintas redes que tengan, y dar el mantenimiento necesario para que el acceso funcione correctamente. También ofrecen servicios relacionados, como alojamiento web o registro de dominios entre otros. ITU-T: El Sector de Normalización de las Telecomunicaciones de la UIT (UIT-T) es el órgano permanente de la Unión Internacional de Telecomunicaciones (UIT) que estudia los aspectos técnicos, de explotación y tarifarios, y publica normativas sobre los mismos, con vista a la normalización de las telecomunicaciones a nivel mundial.

121

Kerberos: Protocolo de autenticación de redes que permite a dos computadores en una red insegura demostrar su identidad mutuamente de manera segura. Kerberos se basa en criptografía de clave simétrica. L2F (Layer 2 Forwarding): Protocolo diseñado por Cisco para establecer túneles de capa 2 desde usuarios remotos hasta sus sedes corporativas. L2TP (Layer 2 Tunneling Protocol): Protocolo creado para corregir las deficiencias de los protocolos PPTP y L2F, utiliza PPP para proporcionar acceso telefónico que puede ser dirigido a través de un túnel por Internet hasta un punto determinado (IETF RFC 2661). LAC (L2TP Access Concentrator): Cliente que inicia túneles L2TP. LAN (Local Área Network): Red de comunicación que proporciona interconexión entre varios dispositivos de comunicación de datos en un área pequeña. Su extensión está limitada físicamente a un edificio o a un entorno de 200 metros, con repetidores podría llegar a la distancia de un campo de 1 kilómetro. LCP (Link Control Protocol): Protocolo de control de enlace que ofrece diferentes opciones de encapsulación para PPP. LNS (L2TP Network Server): Servidor que recibe conexiones L2TP. LZO (Lempel-Ziv-Oberhumer): Librería multiplataforma de compresión de datos creada bajo la GNU/GPL. MAC (Message Authentication Code): Código que se genera a partir de un mensaje de longitud arbitraria y de una clave secreta compartida entre remitente y destinatario, y que sirve para autenticar el mensaje. Mac OS (Macintosh Operating System): Sistema operativo creado por Apple para su línea de computadoras Macintosh. Man in the middle: Ataque en el que el enemigo adquiere la capacidad de leer, insertar y modificar a voluntad, los mensajes entre dos partes sin que ninguna de ellas conozca que el enlace entre ellos ha sido violado. MD2 (Message-Digest Algorithm 2): Función de hash criptográfica desarrollada por Ronald Rivest en 1989. El valor hash de cualquier mensaje se forma haciendo que el mensaje sea múltiplo de la longitud de bloque en el computador y añadiéndole un checksum. MD5 (Message-Digest Algorithm 5): Función de hash criptográfica que acepta una cadena de texto como entrada, y devuelve un número de 128 bits. Fue desarrollada por Ronald Rivest en 1991 como reemplazo del algoritmo MD4. MDC (Modification Detection Codes): Funciones hash basadas en métodos de compresión de datos.

122

MetroEthernet: Arquitectura tecnológica destinada a suministrar servicios de conectividad MAN/WAN de nivel 2. Estas redes se basan en sistemas multiservicio, es decir que soportan una amplia gama de servicios, aplicaciones y mecanismos donde se incluye tiempo real, streaming, flujo de datos continuo como por ejemplo audio y vídeo. MPPE (Microsoft Point-to-Point Encryption): Algoritmo de cifrado punto a punto de Microsoft. MS-CHAP (Microsoft Challenge Handshake Authentication Protocol): Protocolo de autenticación de contraseñas de cifrado no reversible de Microsoft. MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol versión 2): Versión 2 de CHAP de Microsoft y proporciona seguridad de alto nivel para las conexiones de acceso remoto y resuelve algunos problemas de MS-CHAP versión 1. MySQL: Sistema de gestión de bases de datos relacional, multihilo y multiusuario. MTU (Maximum Transfer Unit): También conocida como unidad máxima de transferencia, expresa el tamaño en bytes de la unidad de datos más grande que puede enviarse usando un Protocolo de Internet. Multicast: Servicio de red en el cual un único flujo de datos, proveniente de una determinada fuente, puede ser enviada simultáneamente para diversos destinatarios. NAT (Network Address Translation): Mecanismo utilizado por routers IP para intercambiar paquetes entre dos redes que se asignan mutuamente direcciones privadas. Consiste en convertir en tiempo real las direcciones utilizadas en los paquetes transportados. Su uso más común es permitir utilizar direcciones privadas y aún así proveer conectividad con el resto de Internet. NetBEUI (NetBIOS Extended User Interface): Protocolo de nivel de red sin encaminamiento y bastante sencillo utilizado como una de las capas en las primeras redes de Microsoft. NetBSD: Sistema operativo de la familia Unix, de código abierto y libre. NTFS (New Technology File System): Sistema de archivos diseñado específicamente para Windows NT con el objetivo de crear un sistema de archivos eficiente, robusto y con seguridad incorporada desde su base. OpenBSD: Sistema operativo libre tipo Unix multiplataforma. Es un descendiente de NetBSD, con un foco especial en la seguridad y la criptografía. OpenSSL: Paquete de herramientas de administración y bibliotecas relacionadas con la criptografía, que suministran funciones criptográficas a otros paquetes como OpenVPN. OpenVPN: Solución de conectividad basada en software de código abierto (publicado bajo la licencia GPL) para soluciones VPN SSL/TLS. Oracle: Sistema de gestión de base de datos objeto-relacional desarrollado por Oracle Corporation.

123

OSI (Open System Interconnection): Liberado en 1984 fue el modelo de red descriptivo creado por ISO, es un marco de referencia para la definición de arquitecturas de interconexión de sistemas de comunicaciones. PAC (PPTP Access Concentrator): Cliente PPTP responsable de establecer una conexión segura hacia un servidor y enviar los datos en paquetes PPP a través del túnel hacia el servidor. PAM (Pluggable Authentication Modules): Mecanismo flexible para la autenticación de usuarios que permite el desarrollo de programas independientes del mecanismo de autenticación a utilizar. PAP (Password Authentication Protocol): Protocolo simple para autenticar un usuario contra un servidor de acceso remoto o contra un ISP y es usado por la autenticación del protocolo PPP. PDU (Protocol Data Unit): Unidad de datos de protocolo. Se utiliza para el intercambio entre unidades pares, dentro una capa del modelo OSI. PEM (Privacy Enhanced Mail): Estándar de Internet que provee el intercambio seguro de correo electrónico (IETF RFC 1421). PHP (PHP Hypertext Pre-processor): Lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas. PKI (Public Key Infrastructure): También conocida como infraestructura de clave pública, es una combinación de hardware y software, políticas y procedimientos de seguridad que permiten la ejecución con garantías de operaciones criptográficas como el cifrado, la firma digital o el no repudio de transacciones electrónicas. PNS (PPTP Network Server): Servidor PPTP que toma los paquetes protegidos PPP que viajan a través del túnel, verifica la protección, descifra los paquetes, y reenvía la información de la carga útil PPP encapsulada al destino. POP3 (Post Office Protocol): Protocolo que se utiliza en clientes locales de correo para obtener los mensajes almacenados en un servidor remoto (IETF RFC 1939). Portabilidad: Característica que posee un sistema informático para ejecutarse en diferentes plataformas. PPP (Point-to-point Protocol): Protocolo de nivel de enlace que permite establecer una comunicación entre dos computadoras. Generalmente, se utiliza para establecer la conexión a Internet de un particular con su proveedor de acceso a través de un modem telefónico (IETF RFC 1661). PPTP (Point to Point Tunneling Protocol): Protocolo que opera en la capa 2 del modelo de referencia OSI, desarrollado originalmente por Microsoft como una solución de acceso remoto para permitir transferencias seguras desde un cliente, a través de una red pública, a un servidor Microsoft.

124

Proxy: Programa o dispositivo que realiza una acción en representación de otro, su finalidad más habitual es la de servidor proxy, que sirve para interceptar las conexiones de red que un cliente hace a un servidor de destino, por varios motivos posibles como seguridad, rendimiento, anonimato, etc. RADIUS (Remote Authentication Dial-In User Server): Protocolo de autenticación y autorización para aplicaciones de acceso a la red o movilidad IP. Utiliza el puerto 1813 UDP para establecer sus conexiones (IETF RFC 2865-2866). RAS (Remote Access Server): Servidor que permite el acceso remoto a herramientas o información que residen en una red de dispositivos. RC-2 (Rivest Cipher 2): Algoritmo de cifrado por bloques de clave de tamaño variable diseñado por Ron Rivest de RSA Data Security. El algoritmo trabaja con bloques de 64 bits y entre dos y tres veces más rápido que el DES en software. RC-4 (Rivest Cipher 4): Sistema de cifrado de flujo más utilizado y se usa en algunos de los protocolos más populares como TLS/SSL para proteger el tráfico de Internet y WEP (Wired Equivalent Privacy) para añadir seguridad en las redes inalámbricas. RFC (Request for Comments): Notas cuyo contenido es una propuesta oficial para un nuevo protocolo de la red Internet que se explica con todo detalle para que en caso de ser aceptado pueda ser implementado sin ambigüedades. Router: También conocido como enrutador, es un dispositivo de hardware usado para la interconexión de redes informáticas que permite asegurar el direccionamiento de paquetes de datos entre ellas o determinar la mejor ruta que deben tomar. Opera en la capa tres del modelo OSI. RPM (RPM Package Manager): Herramienta de administración de paquetes capaz de instalar, actualizar, desinstalar, verificar y solicitar programas. RSA (Rivest-Shamir-Adleman): Algoritmo asimétrico de cifrado de bloques, que utiliza una clave pública, la cual se distribuye (en forma autenticada preferentemente), y otra privada, la cual es guardada en secreto por su propietario. SHA (Secure Hash Algorithm): Sistema de funciones hash criptográficas relacionadas de la Agencia de Seguridad Nacional de los Estados Unidos de América y publicadas por el NIST (National Institute of Standards and Technology). Snooping: Tiene como objetivo obtener información de una red a la que se esté conectado sin modificarla. La información que un usuario introduce en un computador es clonada en otro, permitiendo tanto la entrada como la salida de datos a través de ambos. SO (Sistema Operativo): es el programa o conjunto de programas que efectúan la gestión de los procesos básicos de un sistema informático, y permite la normal ejecución del resto de las operaciones.

125

Solaris: Sistema operativo de tipo Unix desarrollado inicialmente por Sun Microsystems y actualmente por Oracle Corporation como sucesor de SunOS. SPI (Security Parameter Index): Número de 32 bits elegido aleatoriamente que identifica una asociación de seguridad. SPX (Sequenced Packet Exchange): Protocolo de red de Novell perteneciente al sistema operativo NetWare utilizado para controlar la entrega de datos a través de una red de área local mediante el protocolo IPX. SSH (Secure Shell): Protocolo que permite el acceso seguro a máquinas remotas a través de una red utilizando técnicas de cifrado. SSL (Secure Socket Layer): Protocolo de la capa de transporte del modelo de referencia OSI que proporciona comunicaciones seguras en una red, comúnmente Internet. Switch Cisco Modelo Catalyst: Conjunto de conmutadores modulares inteligentes que posibilitan la existencia tanto de intranets empresariales como Internet para multimedia, datos de tareas críticas y aplicaciones de voz. También ofrecen capacidad de ampliación, redundancia, mejor control de la red, rendimiento, flexibilidad, resistencia, seguridad, calidad de servicio (QoS) y gestión de tráfico. De esta forma, los clientes pueden hacer converger y controlar mejor los datos IP. TACACS+ (Terminal Access Controller Access Control System): Protocolo de autenticación remota que se usa para gestionar el acceso a servidores y dispositivos de comunicaciones (IETF RFC 1492). TAP: Interfaz virtual que trabaja en modo puente o bridge simulando de esta manera una interfaz de red Ethernet. TCP (Transmission Control Protocol): Protocolo creado entre los años 1973 - 1974 por Vint Cerf y Robert Kahn que garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que se transmitieron. También proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma máquina, a través del concepto de puerto (IETF RFC 793-1393). Telnet (TELecommunication NETwork): Protocolo de red que se utiliza para acceder a un computador y manejarlo de forma remota. El término también permite nombrar al programa informático que implementa el cliente (IETF RFC 854-855). TLS (Transport Layer Security): Sucesor del protocolo de capa de conexión segura SSL, opera en la capa de transporte del modelo de referencia OSI (IETF RFC 2246). TUN: Interfaz virtual que trabaja en modo tunnel emulando un dispositivo punto a punto. UDP (User Datagram Protocol): Protocolo del nivel de transporte basado en el intercambio de datagramas. Permite el envío de datagramas a través de la red sin que se haya establecido previamente una conexión, no tiene confirmación, ni control de flujo (IETF RFC 768-1980)

126

VPDN (Virtual Private Dial-up Network): Red que extiende acceso remoto a una red privada usando una infraestructura compartida, utilizan la tecnología del túnel de capa 2. VPN (Virtual Private Network): Tecnología que permite una extensión de la red local sobre una red pública imitando un vínculo privado punto a punto. VTUN: Herramienta para creación de adaptadores virtuales. WAN (Wide Área Network): Tipo de red de computadoras capaz de cubrir distancias desde unos 100 hasta unos 1000 km, dando el servicio a un país o un continente. WINS (Windows Internet Naming Service): Servidor de nombres de Microsoft, que mantiene una tabla con la correspondencia entre direcciones IP y nombres de computadoras. X.509: Estándar UIT-T para infraestructuras de claves públicas que especifica formatos para certificados de claves públicas y un algoritmo de validación de la ruta de certificación.

Tesis Elena Esqueda.pdf - Saber UCV

Documents

Transcript of Tesis Elena Esqueda.pdf - Saber UCV