VPN Teoria

REDES VPNs DE ACCESO REMOTO

Tesina presentada como trabajo final de los estudios en la carrera de Licenciatura de Informática de la Facultad de Ingeniería de la Universidad

Nacional de la Patagonia San Juan Bosco

Autores:

APU Mario Rubén Mansilla

APU Eduardo Rodolfo Colombres

Tutor de Tesina: Ing. Alejandro Rosales

Trelew Abril 2009

VPNs de Acceso Remoto

1

Propuesta de Tesina

Redes VPN de acceso Remoto

INTRODUCCIÓN Las redes privadas virtuales o VPN (Virtual Private Network) por sus

siglas en inglés, han surgido como alternativa de bajo costo a servicios contratados, dedicados de red de área amplia para las comunicaciones de datos, tanto para conectar redes distantes como usuarios remotos con la red de la organización, utilizando una infraestructura de comunicación de datos pública y compartida.

Las tecnologías de redes privadas virtuales han evolucionado para representar ya no solo una opción económica para las comunicaciones sino también como una solución complementaria para lograr eficiencia, velocidad, seguridad, confiabilidad en otros servicios de red de área amplia. Además se la considera una herramienta estratégica que permite interconectar en forma segura redes y equipos externos cuya administración y control están fuera del alcance de la organización.

Debido a que se utiliza una infraestructura compartida y pública para la interconexión, la seguridad de los datos que se transmiten es fundamental. En el contexto de una VPN esto se resuelve mediante un protocolo de túnel, es decir un mecanismo que es capaz de encapsular paquetes de protocolos arbitrarios, mediante el agregado de encabezados, utilizando además mecanismos para preservar la confidencialidad e integridad de los datos enviados.

En la actualidad existe una gran diversidad de tecnologías que implementan VPN, lo cual permite clasificarlas según distintos criterios, por ejemplo en función de quien provee el servicio (el usuario o un ISP), según en que capa del modelo de referencia ISO/OSI se establece la VPN (VPN de capa 2, capa 3 o de transporte/aplicación) o de acuerdo a la topología de interconexión utilizada (VPN punto a punto o punto multipunto).

De acuerdo a este último criterio, se pueden apreciar en términos generales, dos escenarios donde se aplican las VPNs, al interconectar dos sitios, es decir dos redes y al comunicar dos hosts entre sí, a esto se conoce como VPN sitio a sitio y VPN de acceso remoto respectivamente.

Las redes privadas virtuales de acceso remoto son el mecanismo ideal para extender o acercar los servicios de red local, en forma completa o parcial, a los usuarios itinerantes y tele trabajadores. Esta circunstancia dista de ser ideal si no se tiene en cuenta, nuevamente, el aspecto seguridad respecto a validar a quién se conecta y de acuerdo a esto, que permisos y autorizaciones posee. Estas precauciones deben reflejar las políticas de seguridad de la información definidas previamente por la organización.


2

OBJETIVOS GENERALES Investigar las características, componentes, mecanismos de una VPN de

acceso remoto y como solucionan la necesidad de un ingreso seguro a los recursos informáticos de la organización desde cualquier sitio.

Aplicar los conceptos de VPN de acceso remoto a través de una solución que implemente un cliente VPN portátil que evite la instalación de programas para esta tarea.

OBJETIVOS PARTICULARES Determinar las características necesarias para que una solución sea

considerada una VPN.

Determinar las ventajas y desventajas de la utilización de IPSec y SSL en la implementación de VPNs de acceso remoto.

Investigar diferentes enfoques para la creación de una distribución LINUX específica para el desarrollo de la práctica.

Evaluar alternativas de lenguajes de programación para el desarrollo de aplicaciones a utilizar en la práctica.

Evaluar alternativas de software de virtualización que sean portables para el desarrollo de la práctica.

FUNDAMENTACIÓN En la actualidad existe un incremento de las conexiones de banda

ancha tanto en puntos de acceso comerciales como en los hogares. Este aumento se observa también en la capacidad de ancho de banda ofrecido. Esta situación beneficia la puesta en práctica de VPN de acceso remoto. Una actividad muy popular es el tele trabajo, que permite desde otra ubicación física contar con los recursos de la información que se poseen en la oficina. Las organizaciones o empresas necesitan de estas herramientas para poder adaptarse al dinamismo de los negocios de hoy en día.

Esto genera una problemática que combina aspectos de seguridad y facilidad de uso. Se puede considerar estos dos aspectos antagónicos. Mientras más seguridad se quiera aplicar menos dinámico y transparente se torna el proceso o tarea requerida (utilización de certificados, claves de acceso, mecanismos de distribución de claves). Tampoco se puede priorizar la facilidad de uso sobre la seguridad, porque se estaría poniendo en riesgo el recurso más valioso de una organización que es la información, los sistemas que la generan y los datos que estos procesan. En este campo, algo que no es negociable es la seguridad.

Se trata, entonces, de buscar una solución que balancee seguridad con facilidad de uso. Es este intento de equilibrio y la importancia de la flexibilidad del acceso remoto para los usuarios de una red, que motivan la realización de este trabajo.

Para esto se desarrolla un cliente sobre plataforma LINUX que se conecta con un servidor VPN. El cliente se ejecuta en una máquina virtual la cual reside en un dispositivo USB (pendrive). La aplicación que virtualiza el sistema LINUX se ejecuta en la plataforma más popular en la actualidad.


3

ORGANIZACIÓN DEL TRABAJO El siguiente trabajo se compone de cuatro capítulos donde se

desarrollarán los diversos temas relacionados con las redes privadas virtuales (VPNs) en general y aquellos en particular referidos a las VPNs de acceso remoto.

Las redes privadas virtuales resulta ser un tema amplio que involucra diversos conceptos. Un desarrollo particular de la teoría sin referir el contexto general resulta en un desarrollo aislado que impide la compresión correcta del tema particular. Por esta razón se dedicó un par de capítulos a las definiciones y teoría general para introducir el tema principal el cual es sujeto de este trabajo.

El capítulo 1 refiere a definiciones y terminología utilizada en la teoría de las VPNs, además presenta las diversas clasificaciones, los criterios que provocan tales distinciones y las aplicaciones.

En el capítulo 2 se desarrollan las arquitecturas, los protocolos y las aplicaciones de las redes privadas virtuales. Dentro de las arquitecturas se mencionan las tecnologías involucradas. En cuanto a los protocolos VPN se destacan IPSec, L2TP y SSL, los cuales serán referidos en el capítulo dedicado a las VPNs de acceso remoto.

El capítulo 3 esta dedicado a las VPNs de acceso remoto. Su desarrollo presenta los requerimientos de seguridad y todo lo concerniente a la arquitectura de seguridad, los escenarios de acceso remoto existentes, los protocolos más utilizados y características de las soluciones VPN de acceso remoto.

Finalmente el capítulo 4 presenta el desarrollo del trabajo práctico realizado como aplicación y las conclusiones del mismo.


4

Índice CAPÍTULO 1 –INTRODUCCIÓN A LAS VPN ..........................................7 1.1 DEFINICIONES Y TERMINOLOGÍA ..............................................................................................8 1.1.1 Red Privada...............................................................................................................................8 1.1.2 Red Pública ...............................................................................................................................9 1.1.3 Red Privada Virtual ..................................................................................................................9 1.1.4 Definición de VPN ..................................................................................................................10 1.1.5 Terminología............................................................................................................................11 1.2 CLASIFICACIÓN .........................................................................................................................13 1.2.1 VPNs provistas por el cliente o por el proveedor ............................................................13 1.2.2 VPNs Sitio a Sitio y de Acceso Remoto..............................................................................16 1.2.3 VPNs de capa 2 y capa 3....................................................................................................17 1.2.4 Integración de las clasificaciones......................................................................................18 1.2.5 Confiables y Seguras .............................................................................................................20 1.2.6 Overlay y Peer ........................................................................................................................20 1.2.7 No Orientadas y orientadas a la conexión ......................................................................23 1.2.8 VPN de capa de transporte/aplicación...........................................................................23 1.2.9 VPN multiservicio ....................................................................................................................24 1.3 APLICACIONES...........................................................................................................................24 1.3.1 Intranet /Intranet extendida ................................................................................................24 1.3.2 Extranets ...................................................................................................................................25 1.3.3 Servicio VPN provisto por un proveedor ...........................................................................25 CAPÍTULO 2 – ARQUITECTURAS, CLASIFICACIÓN Y PROTOCOLOS .....................29 2.1 INTRODUCCIÓN A LAS ARQUITECTURAS DE VPN ................................................................30 2.1.1 Componentes de una Red Privada Virtual ......................................................................31 2.1.2 Hardware .................................................................................................................................31 2.1.3 Seguridad de la infraestructura ..........................................................................................32 2.1.4 Infraestructura de soporte para el servicio del proveedor...........................................33 2.1.5 Redes Públicas........................................................................................................................33 2.1.6 Túneles ......................................................................................................................................34 2.2 ARQUITECTURAS .........................................................................................................................34 2.2.1 Basadas en software .............................................................................................................34 2.2.2 Basadas en la Implementación..........................................................................................34 2.2.3 Basada en Seguridad ...........................................................................................................35 2.2.4 Iniciadas por el cliente..........................................................................................................37 2.2.5 Dirigidas....................................................................................................................................37 2.2.6 Basado en la capa................................................................................................................37 2.2.7 Basada en Clases...................................................................................................................38 2.2.8 Basada en Caja Negra.........................................................................................................39 2.2.9 Basada en Acceso Remoto.................................................................................................39 2.2.10 VPN múltiple servicios..........................................................................................................39 2.3 PROTOCOLOS DE TÚNEL...........................................................................................................41 2.3.1 Requerimientos de un Túnel.................................................................................................42 2.4 PROTOCOLOS DE TÚNEL CAPA 2 ...........................................................................................45 2.4.1 Point to Point Protocol (PPP) ................................................................................................45


5

2.4.2 Point to Point Tunneling Protocol (PPTP) ............................................................................46 2.4.3 Layer 2 Forwarding Protocolo (L2F)....................................................................................48 2.4.4 Layer 2 Tunneling Protocolo (L2TP) .....................................................................................48 2.5 PROTOCOLOS DE TÚNEL CAPA 3 ...........................................................................................51 2.5.1 IP Security Protocol (IPSec)...................................................................................................51 2.5.2 Generic Routing Encapsulation protocol (GRE)..............................................................59 2.5.3 Multiprotocol Label Switching (MPLS)................................................................................61 2.6 PROTOCOLOS DE TÚNEL CAPA 4 ...........................................................................................62 2.6.1 Secure Shell (SSH) ...................................................................................................................62 2.6.2 Secure Sockets Layer/Transport Layer Security (SSL/TLS) ...............................................64 2.7 TOPOLOGÍAS ..............................................................................................................................64 2.7.1 Escenarios ................................................................................................................................65 2.7.2 Topología Punto a Punto......................................................................................................67 2.7.3 Topología Punto a Multipunto.............................................................................................68 2.7.4 Topología Estrella (Hub and Spokes) .................................................................................69 2.7.5 Topología de Malla Completa o Parcial (Full or Partial Mesh).....................................70 CAPÍTULO 3 – VPN DE ACCESO REMOTO ..........................................72 3.1 INTRODUCCIÓN .........................................................................................................................73 3.1.1 Requerimientos básicos de seguridad ..............................................................................74 3.1.2 Configuración de las políticas de seguridad...................................................................75 3.1.3 Auditoría...................................................................................................................................75 3.2 ESCENARIOS................................................................................................................................76 3.2.1 Tele trabajadores/usuarios móviles operando dispositivos propios ............................76 3.2.2 Acceso con un dispositivo propio a la red local desde una extranet.......................77 3.2.3 Acceso desde una extranet con un dispositivo propio de esta, a la red local.......77 3.2.4 Acceso de usuarios móviles desde dispositivos públicos..............................................77 3.3 ARQUITECTURA DE SEGURIDAD ..............................................................................................78 3.3.1 Gateway VPN y Firewall, seguridad en la frontera.........................................................79 3.3.2 Disponibilidad .........................................................................................................................84 3.3.3 Autenticación, Autorización y Registro (AAA).................................................................86 3.3.4 Administración y monitoreo.................................................................................................88 3.4 PROTOCOLOS ............................................................................................................................89 3.4.1 SSH .............................................................................................................................................89 3.4.2 IPSec..........................................................................................................................................91 3.4.3 SSL/TLS .......................................................................................................................................94 3.4.4 Comparativa de las tecnologías de acceso remoto....................................................94 3.5 SOLUCIONES VPNs DE ACCESO REMOTO ............................................................................99 3.5.1 IPSEC .......................................................................................................................................100 3.5.2 SSL/TLS .....................................................................................................................................101 CAPÍTULO 4 – TRABAJO PRÁCTICO .............................................102 4.1 INTRODUCCIÓN .......................................................................................................................103 4.2 ALCANCES ................................................................................................................................104 4.3 FUNCIONAMIENTO ..................................................................................................................105 4.3.1 Perfiles de usuarios ...............................................................................................................105 4.3.2 Esquema de validación......................................................................................................105 4.3.3 Servicios..................................................................................................................................105 4.3.4 Gateway VPN .......................................................................................................................106 4.4 TECNOLOGÍAS DE LA SOLUCIÓN..........................................................................................106


6

4.4.1 Lenguajes de programación.............................................................................................106 4.4.2 Entorno de virtualización....................................................................................................107 4.4.3 Distribución LINUX.................................................................................................................107 4.4.4 Tecnología VPN ....................................................................................................................109 4.5 LA SOLUCIÓN ...........................................................................................................................109 4.5.1 Funcionamiento de la Máquina Virtual ..........................................................................109 4.5.2 Aplicación de gestión de archivos ..................................................................................112 4.6 CONCLUSIONES DEL TRABAJO PRÁCTICO.........................................................................113 ANEXOS ....................................................................114 5.1 ÍNDICES DE FIGURAS................................................................................................................115 5.2 REFERENCIAS BIBLIOGRÁFICAS .............................................................................................116


7

CAPÍTULO 1 INTRODUCCIÓN A LAS VPN

1


8

1.1 DEFINICIONES Y TERMINOLOGÍA La importancia de la tecnología de las redes de datos para las

comunicaciones en las organizaciones (empresas, instituciones gubernamentales, no gubernamentales) ha sido fundamental para su desarrollo y crecimiento, tanto en el aspecto económico y funcional, siendo una herramienta estratégica que brinda soporte y permite el desenvolvimiento y transformación de dichas organizaciones. Hoy en día no se puede concebir, a nivel organizacional, algún cambio, fusión u unión sin considerar las comunicaciones y las tecnologías de información que le dan soporte.

1.1.1 Red Privada Las redes de datos interconectaban, en un principio en forma local,

las computadoras personales de una organización, permitiendo compartir la información, y el trabajo en grupo de una forma más ágil y eficiente. Sin embargo esto requirió considerar el aspecto de la seguridad, ya que si bien se trabajaba en un mismo ámbito, es decir dentro de la misma empresa, no todos los usuarios debían acceder a los datos por igual. Este esquema funcionó para pequeñas organizaciones, pero para aquellas cuya estructura incluía sitios geográficamente alejados, surgió la necesidad de interconectar también dichos lugares.

La solución vino de la mano de los proveedores de servicio de red de área amplia de datos o WAN (Wide Area Network), a través de la contratación de enlaces dedicados, los cuales conectaban las redes distantes con la red central. Esta solución implicaba un costo, que resultó prohibitivo para la mayoría, excepto para aquellos que podían abonar un costo fijo de contratación más un valor que variaba proporcionalmente a la distancia existente entre los sitios a interconectar (mile-age fee). En la actualidad existen tecnologías WAN (Frame Relay, ATM1) donde el costo esta en función del caudal de datos o ancho de banda comprometido del enlace, que una organización esta dispuesta a pagar, sin considerar ya la distancia geográfica.

De esta forma se contaba con una red privada o estructura de comunicación propia, en el sentido de que el control y la administración de la red estaban bajo el dominio de la organización. Las políticas de uso, los servicios suministrados, los medios activos y pasivos de comunicación por donde fluían los datos estaban bajo un control propio. Si bien las comunicaciones de área amplia eran suministradas por un proveedor, este se comprometía a respetar los requerimientos de la organización cliente y además los datos que atravesaban su red, no iban a estar al alcance de otros clientes.

1 Asynchronous Transfer Mode


9

1.1.2 Red Pública Uno de los eventos mas importantes que acompañó al desarrollo de las

redes en las organizaciones, fue la rápida evolución de la mayor de las redes IP existentes, Internet. Esta se define como un sistema cooperativo de interconexión de redes que suministra un servicio de comunicación universal. De esta manera satisface la necesidad de los usuarios de comunicar dos puntos cualesquiera, también denominados sistemas o nodos finales, pudiendo acceder a recursos más allá de los disponibles en un único sistema y ubicados fuera de los límites de la red local.

Los datos atraviesan redes intermedias hasta llegar a su destino, en una operación no orientada a la conexión, mediante el uso de equipos especiales denominados routers, también conocidos como sistemas o nodos intermedios. La naturaleza no orientada a la conexión de Internet, significa que no hay una ruta preestablecida o circuito virtual dedicado entre los sistemas que se comunican, tampoco niveles de servicio, priorización o separación de tráfico que puedan aplicarse a los datos que se transmiten.

La función de los routers es interconectar al menos dos redes, transfiriendo paquetes desde una red a otra. Estas pertenecen a diversas organizaciones y proveedores. Esto convierte a Internet en una red pública, en el sentido de que son muchos los que participan en su conformación y los medios de transmisión son compartidos. Dependerá de quien utilice la infraestructura de Internet para comunicar dos sistemas finales, tomar las medidas de seguridad apropiadas para asegurar la confidencialidad, autenticidad, integridad y no repudio de los datos transmitidos.

1.1.3 Red Privada Virtual El funcionamiento de algunas organizaciones, determinaron la

necesidad de permitir el acceso a la red propia a usuarios que se encontraban geográficamente fuera de los límites de ésta. Éstos requerían desplazarse con frecuencia y en algún momento acceder a sus archivos en la red local, revisar su correo electrónico o utilizar un sistema de información.

En un principio se utilizaron servicios de acceso remoto mediante la implementación de servidores para tal fin o RAS (Remote Access Server), el uso de líneas discadas para la conexión y pools de modems para atender las llamadas. Toda esta infraestructura era costeada por la organización la cual era responsable de su administración y mantenimiento. Si bien se solucionaba el problema de acceso a la red local, se lograba a un costo económicamente alto.

Otra necesidad fue la de encontrar una alternativa más económica de interconectar diversas redes entre sí y ya no solamente las de una misma organización, sino redes de diferentes organizaciones. Razones de política estratégica justificaban este desafío, ya sea a nivel empresarial, universitario o gubernamental.

Ambos requerimientos tuvieron su solución a partir de la idea de utilizar Internet, teniendo en cuenta su alcance global y su capacidad de entrega de datos a casi cualquier sistema final a un bajo costo.

Dado que se utiliza Internet para transmitir datos, no hay garantía de que estos no puedan ser captados por terceros. También es claro que los sistemas finales que se comunican están expuestos.


10

En la actualidad no solo se considera a Internet como medio donde una organización puede implementar una VPN. Los proveedores de servicios de comunicaciones o SP (Service Provider) ofrecen servicios de VPN de acuerdo a las necesidades del cliente a través de su red backbone. Un SP puede administrar múltiples VPNs pertenecientes a varios clientes operando a través de su backbone.

1.1.4 Definición de VPN Es habitual encontrar varias definiciones sobre VPN, aunque éstas no

difieren en esencia. Algunas de ellas pueden ser:

“Una VPN es una red privada construida dentro de una infraestructura de red pública, como la red Internet”2

“La idea básica de una VPN es muy simple. Una corporación podría tener un número de oficinas (o grupos de ellas) en diferentes lugares, y en cada uno de estos tener su propia red local. Muchas corporaciones han aumentado la cantidad de empleados que deben trabajar en forma remota, ya sea desde sus hogares o en forma itinerante. Interconectar estas redes y lugares mediante una red compartida (no privada) crea una VPN”3

“Una red privada virtual basada en Internet utiliza la infraestructura abierta y distribuida de Internet para transmitir datos entre sitios corporativos” 4

“Una red privada virtual es una red privada de datos que utiliza una infraestructura de telecomunicación pública, manteniendo la privacidad mediante protocolos de túnel y procedimientos seguros.

....El propósito principal de una VPN es dar a la compañía la misma capacidad que otorgan los enlaces dedicados contratados pero a un costo menor, utilizando medios de comunicación públicos.” 5

Se puede definir a una VPN de manera más formal. Esta definición aparece publicada en el artículo What Is a VPN? Part 1 escrito por Ferguson y Houston para la publicación mensual The Internet Protocol Journal de Cisco System en Marzo de 2001:

“Una VPN es un ambiente de comunicaciones en el cual existe un control de acceso, para permitir la conexión entre sistemas pares únicamente dentro de una comunidad de interés definida, y está creado considerando alguna forma de partición de un medio de comunicación subyacente, donde este brinda servicios a la red de una forma no exclusiva.”

De acuerdo a estas definiciones se puede decir que una red privada virtual es una red, que comunica dos o más dispositivos finales (estos a su vez pueden interconectar una red completa) que pueden estar ubicados geográficamente distantes y representan una comunidad de interés. Para esto se utiliza como medio de transmisión una estructura compartida común a varios usuarios. Ésta puede ser Internet o la red principal o backbone de un proveedor de servicios de comunicaciones.

2What Is a VPN? Part I by Ferguson -Houston - The Internet Protocol Journal Marzo 2001 Cisco System 3VPN Technologies a Comparison by Finlayson-Harrison-Sugarman – Data Connection Limited Febrero 2003 4Virtual Private Networks (VPNs) – Web ProForum Tutorials - IEC 5VPN Technologies: Definitions and Requirements by VPN Consortium – Marzo 2006


11

Se dice privada porque los dispositivos que no participan en esta comunicación no tienen acceso al contenido de la misma y de hecho no son conscientes de su establecimiento. El acceso a esta red y su administración está restringido solo a un número limitado de dispositivos. La privacidad se aplica también al espacio de direccionamiento y esquema de enrutamiento utilizado en una VPN, en el sentido de que están separados o difieren de aquellos instrumentados en alguna otra red privada existente o en la infraestructura de red subyacente por donde ocurre la comunicación.

El concepto de virtual, por definición es la representación de un objeto no existente mediante la ejecución de funciones que simulan su existencia. En el contexto de una VPN, significa que esta última representa una red de comunicaciones, que no tiene una contraparte física real. Este concepto fundamenta la naturaleza discreta o de separación, de una red lógica privada funcionando sobre una infraestructura de comunicaciones compartida y real. El aspecto de privacidad, definido en el párrafo anterior, está en función de la virtualización.

1.1.5 Terminología La literatura relacionada con redes privadas virtuales esta plagada

de acrónimos, siglas, términos muy específicos que tornan difícil la interpretación de cualquier lectura relacionada con el tema. Esta sección define los principales elementos que componen un escenario VPN.

Sitio: ubicación geográfica con uno o más usuarios o uno o más servidores o una combinación de servidores y usuarios. El usuario refiere al host o estación de trabajo.

Servidor VPN: software o firmware VPN el cual se ejecuta en un dispositivo. Tiene la función de establecer un túnel con un cliente VPN. Previamente verifica la identidad del cliente para autorizar su acceso y determinar los permisos de este para acceder a los recursos locales. El dispositivo donde se ejecuta el servidor VPN puede ser un host, router o switch. Este equipo comunica la red local con la red pública. Otras acepciones pueden ser: gateway VPN, servidor de túneles.

Cliente VPN: software o firmware VPN ejecutándose en un dispositivo, cuya función es establecer un túnel con un servidor VPN. Previamente, debe presentar las credenciales correctas al servidor. Otra acepción puede ser cliente de túnel.

Túnel: Enlace lógico entre el servidor y cliente VPN, creado por un protocolo de túnel. Por este canal se envían los datos que han sido encapsulados y quizás encriptados por el protocolo. Es posible transmitir datos sin encriptar por un túnel. Un túnel puede establecerse en diferentes capas del modelo ISO/OSI de protocolos de comunicaciones.

Extremos de un túnel: dispositivos que gestionan la creación, el establecimiento y la finalización de un túnel mediante la ejecución de software o firmware dedicado para tal fin, por lo tanto se encargan también del procesamiento relacionado con la des/encapsulación, des/encriptación y transmisión de los paquetes recibidos.


12

NAS (Network Access Server): servidor de acceso de red, un dispositivo que representa una interfase entre un medio de acceso como la red de telefonía y una red de conmutación de paquetes, como el backbone de un proveedor o Internet. En una VPN este dispositivo permite que un usuario utilizando un acceso telefónico acceda a su red mediante un túnel creado por el NAS hacia el servidor de acceso remoto de la red destino.

Túnel voluntario (Voluntary Tunnel): Túnel creado y configurado a partir de la solicitud de un cliente VPN. Esta clase de túnel es común en las VPN de acceso remoto, donde uno de los extremos es una computadora personal o notebook de un usuario hogareño o móvil.

Túnel obligatorio (Compulsory Tunnel): Túnel asociado con las VPN de acceso remoto. Su creación y configuración está a cargo de un dispositivo denominado servidor de acceso de red o NAS. Éste se ubica entre la PC del usuario y el servidor VPN. En el NAS se ubica el extremo del túnel donde funciona el cliente VPN. Es posible que múltiples usuarios conectados al servidor de acceso de red, compartan el túnel en forma concurrente. En general el NAS es propiedad y es administrado por un proveedor de servicios. Ver más detalles en el capítulo 2”Protocolos de túnel capa 2”.

Dispositivo de borde: Es el dispositivo ubicado en la frontera entre la red local y la red pública.

CE: Dispositivo de borde del cliente (Customer Edge Device). Es el equipo perteneciente a un cliente de un servicio de comunicaciones que se sitúa en el borde de la red privada local y conecta con la red del proveedor del servicio a través de un PE. Un CE puede ser un router o switch.

C: Dispositivo que pertenece al cliente y que se ubica dentro de la red del mismo. Estos no tiene conectividad directa con la red del Proveedor ni participan de la VPN. Pueden ser routers o switchs.

PE: Dispositivo de borde del proveedor (Provider Edge Device). Este es propiedad del proveedor de servicio de comunicaciones. Se conecta directamente a la red del cliente a través del CE. Un PE puede ser un router, switch o un dispositivo que combine ambas funciones.

P: Dispositivos que componen el núcleo de la red del Proveedor. No tienen conectividad directa con la red del cliente ni participan de las VPN. Estos son equipos como routers y switches.


13

Figura 1-1 Componentes de una VPN

1.2 CLASIFICACIÓN Se pueden encontrar varias clasificaciones de las VPN, lo cual

puede generar cierta confusión. Esto se debe a que existen diversos tipos de tecnologías y clases de redes privadas virtuales, lo que permite más de un criterio de organización.

Las clasificaciones generales y más habituales son:

De acuerdo a quien implementa y administra el servicio: la propia organización o un proveedor de servicios.

Según que comunican: redes entre sí o usuarios a la red.

Según la capa del modelo de referencia de pila ISO/OSI para comunicaciones donde se establece la VPN: capa 2, 3 y las VPNs de capa de aplicación/transporte que utilizan el protocolo SSL/TLS. Estas representan una clase particular de VPN que se describen aparte.

Otros criterios pueden ser:

Según si los dispositivos de borde de un proveedor participan o no en el enrutamiento del tráfico de datos del cliente: VPN peer to peer o VPN overlay.

Según si son orientadas o no a la conexión.

Si son confiables o seguras.

1.2.1 VPNs provistas por el cliente o por el proveedor Uno de los principales criterios para clasificar las VPN, define

quien esta a cargo de la implementación y administración de la red privada virtual, ya sea el cliente (la organización) o el proveedor de servicios de comunicaciones. Esto se refiere a la definición de las políticas a cumplir con esta solución, los requerimientos para la implementación, la adquisición y configuración de equipamiento, mantenimiento, resolución de problemas y monitoreo, especificación del espacio de direccionamiento a utilizar, esquema de enrutamiento etc.


14

VPNS provistas por el cliente (CE o CPE VPN)

También denominadas VPNs del ámbito del cliente (Customer Promises VPN). Estas VPNs son definidas e implementadas por el cliente de un servicio de comunicaciones. Generalmente este tiene acceso al backbone de un proveedor o bien posee un servicio de acceso a Internet. En este contexto el cliente puede tener más de un sitio propio, geográficamente distante que desea conectar o bien requiere hacerlo con otra red fuera de su dominio, también remota.

En este tipo de VPN, el túnel se establece, únicamente, entre los equipos del cliente. Estos representan los extremos del o los túneles. Los equipos del proveedor o PE, no participan de la VPN. Tampoco del esquema de direccionamiento que esta utiliza o del enrutamiento necesario. Tratan a los paquetes o tramas como proveniente de un cliente del servicio, es decir solo lo reenvían. En el caso de la utilización de Internet, los routers intermedios también lo hacen con los paquetes IP, sin tener en cuenta el contenido encapsulado por el túnel de la VPN.

La ventaja de esta clase de VPN radica en que el cliente tiene el control de la seguridad aplicada a los datos que transmite. Para el proveedor sus dispositivos de borde no requieren ninguna configuración especial para el tratamiento de los paquetes de las VPN, además no surgen problemas de escalabilidad al momento de aumentar la cantidad de VPNs o los sitios a interconectar mediante estas ya que, como se mencionó anteriormente, estos equipos no participan en este escenario virtual.

Como desventaja, el cliente debe hacerse cargo básicamente de todo. Esto puede implicar un gran costo, tanto en la compra de equipamiento, como en la preparación de personal para la configuración y el mantenimiento de la VPN. Esta solución presenta problemas de escalabilidad para el cliente cuando existen varios sitios para interconectar.

Los tipos de VPN provistas por el cliente son:

VPN IPSec (IP Security)

VPN GRE (Generic Routing Encapsulation)

VPN SSL/TLS (Secure Sockets Layer/Transport Layer Security)

Figura 1-2 VPN Provista por el Cliente


15

VPNs provistas por el Proveedor (PPVPN)

En esta clase de VPN el proveedor de servicio se encarga de su implementación. Los equipos de borde o PE participan activamente de la red virtual como así también, pero en menor grado, los dispositivos de borde del cliente. Esto significa que los PE realizan la mayor parte del procesamiento específico de la VPN, permitiendo que los equipos CE puedan ser routers o switches estándar sin necesidad de comprar equipamiento especial.

El proveedor es responsable de la administración de la VPN, liberando al cliente de estas tareas. Esto resulta, para este último, en un menor costo de implementación respecto de un emprendimiento propio.

Actualmente los proveedores ofrecen un servicio de VPN mejorado, donde suman además de la conectividad, acuerdos de nivel de servicio, calidad y diferenciación de servicio, seguridad, ingeniería de tráfico etc. Esto redunda en un producto con valor agregado que beneficia a ambas partes.

Las soluciones VPN de esta clase, pueden operar en la red de un único proveedor, entre un conjunto de proveedores de servicio y sobre Internet. En este último caso se asume que los routers de núcleo de Internet, no mantendrán información referida a la VPN, sin considerar si se utilizan protocolos de enrutamiento para distribuir o no dicha información. Existen cuatro escenarios donde pueden desplegarse estas VPN6:

Único Proveedor, único Sistema Autónomo o AS (Autonomous System): escenario más simple, el servicio se brinda a través del AS de un único proveedor.

Único Proveedor, múltiples AS: un proveedor administra varios AS (adquisición de varias redes). Este escenario implica la distribución con restricciones de la información de enrutamiento entre los diversos Sistemas Autónomos.

Multi Proveedor: es el caso más complejo, debido a que es necesario negociar relaciones de confianza entre los backbones de los diversos proveedores para cumplir con las medidas de seguridad y niveles de servicio acordados para la VPN de un cliente. En este caso el servicio se denomina VPN inter-AS o ínter proveedor.

Proveedor de Proveedores (Carrier's Carrier): este es un caso especial del primer escenario, excepto que los clientes son proveedores de servicios de comunicaciones que contratan el servicio de VPN a un proveedor principal, para ofrecerlo a su vez a sus propios clientes.

Los tipos de VPN provistas por el Proveedor son:

VPN VPWS (Virtual Private Wire Service)

VPN VPLS (Virtual Private Lan Service)

VPN IPLS (IP only Private Lan Service)

VPN basada en routers virtuales

VPN IPSec

VPN MPLS (Multiprotocol Label Switching)

6RFC 3809 – Generic Requirements for Provider Provisioned VPN


16

1.2.2 VPNs Sitio a Sitio y de Acceso Remoto Otra forma general de distinguir las VPN es en función de si

conectan redes entre sí o usuarios a una red. Una VPN sitio a sitio (site-to-site VPN) conecta dos o más redes entre sí que están geográficamente dispersas, estas pueden pertenecer a una o varias organizaciones.

Si las redes pertenecen a una misma organización, esta clase de VPN se denomina intranet. Si las redes pertenecen a varias organizaciones se conoce como extranet. La intención en este último caso es comunicar organizaciones diferentes que persiguen un objetivo común y requieren compartir información útil para el conjunto. El servicio de VPN entre sitios debería ser independiente del alcance geográfico de la implementación.

Figura 1-3 VPN Sitio a Sitio

Las VPN de Acceso Remoto o RAVPN (Remote Access VPN), también denominadas VPN de acceso, permiten a los usuarios móviles o itinerantes y a los usuarios hogareños de una organización o tele trabajadores, acceder en forma remota a la red. Esta clase de VPN puede establecer un túnel en modo voluntario u obligatorio.

Figura 1-4 VPN de Acceso Remoto


17

Las tecnologías y protocolos asociados a esta clasificación son:

VPNs sitio a sitio:

IPSec

GRE

AtoM (Any Transport over MPLS)

L2TPv3 (Layer 2 Tunneling Protocol version 3)

IEEE 802.1Q

MPLS LSP (MPLS Label Switched Path)

VPNs de acceso remoto:

L2F (Layer 2 Forwarding)

PPTP (Point to Point Tunneling Protocol)

L2TPv2/v3

IPSec

SSL/TLS

Algunos de estos serán descriptos más adelante en el capítulo 2 dedicado a protocolos VPN.

1.2.3 VPNs de capa 2 y capa 3 El criterio de esta clasificación se basa en las capas, del modelo

de referencia ISO/OSI de protocolo de comunicaciones, por donde se establece el túnel de la VPN. Esta clasificación surge a partir de la variedad de tecnologías existentes que se utilizan para implementar la VPN.

Esta distinción tiene sentido cuando se la aprecia en el contexto de las clasificaciones anteriores.

Las VPN de capa 2 permiten la conectividad a nivel de la capa de enlace de datos y puede ser establecida entre switches, routers o hosts. La comunicación esta basada en el direccionamiento de capa 2 y el reenvío del tráfico esta basado respecto del enlace entrante y la información de encabezados de dicha capa, tales como direcciones MAC (Media Access Control) o DLCI (Frame Relay Data Link Connection Identifier).

Las VPN de capa 3 interconectan hosts o routers, la comunicación se basa en el direccionamiento a nivel de capa de red. El reenvío del tráfico se lleva a cabo teniendo en cuenta el enlace entrante y las direcciones del encabezado IP.


18

1.2.4 Integración de las clasificaciones Las clasificaciones anteriores se pueden integrar para tener una

perspectiva más práctica y operativa de las VPN. Esta integración muestra las VPN provista por el cliente o proveedor como el criterio de clasificación más general, dentro de la cual se pueden diferenciar las VPN sitio a sitio y remota. Finalmente se consideran según las tecnologías VPN de capa 2 y 3. El siguiente esquema muestra esta relación:

Figura 1-5 Clasificación de las VPN

VPN Sitio a Sitio Provistas por el Proveedor de Capa 2 (L2VPN)

Estas VPN pueden ser establecidas entre switches, routers y hosts, permitiendo la conectividad a nivel de capa de enlace entre sitios separados. Tanto el direccionamiento como el reenvío del tráfico de la VPN se llevan a cabo en función del enlace entrante y de la información del encabezado de capa 2.

Dentro de las L2VPN se pueden distinguir dos categorías:

VPNs basadas en circuitos Punto a Punto (P2P): conocidas también como VPWS (Virtual Private Wire Service). Se implementan usando MPLS o circuitos emulados (pseudowires) L2TPv3.

VPNs Multipunto a Multipunto (M2M): en esta categoría entran las VPN VPLS (Virtual Private LAN Service) e IPLS (IP-Only LAN Service).

VPN VPWS

La red del proveedor puede considerarse como una emulación de un conjunto de enlaces punto a punto o pseudowires entre los sitios del cliente. Es útil en escenarios donde el cliente ya posee circuitos virtuales ATM o Frame Relay que interconectan sus redes. En lugar de que el tráfico del cliente atraviese el backbone hasta su destino en su formato nativo de capa 2, éste es encapsulado y enrutado sobre la infraestructura IP del Proveedor.

El cliente mantiene las conexiones de capa 2 al backbone. Los routers CE deben seleccionar el circuito virtual a usar para enviar el tráfico al sitio destino.


19

Este esquema permite el reemplazo de redes con topologías estrella que requieren la interconexión de redes satélites hacia una red central, permitiendo alternativas de rutas hacia un destino.

Unas de las tecnologías habituales, en el núcleo de la red del proveedor, para esta clase de VPN es MPLS junto a extensiones conocidas como PWE3 (Pseudowire Emulation Edge to Edge). Un enfoque más escalable, respecto de la administración del servicio, utiliza BGP (Border Gateway Protocol) como protocolo de señalización y auto detección. En este caso, los dispositivos PE usan BGP multiprotocolo para anunciar los dispositivos CE y VPN que controlan, junto con las etiquetas MPLS utilizadas para encaminar el tráfico. De esta forma, cuando los otros CE reciben esta información, saben como establecer los pseudowires.

VPN VPLS

En este caso la red LAN ethernet de cada sitio del cliente se extiende hasta el borde de la red backbone del proveedor. Luego, una vez aquí, se emula la función de un bridge o switch para conectar todas las LANs del cliente. De esta forma se emula, en la red del proveedor, una única LAN ethernet. Esta solución provee un servicio punto a multipunto donde los routers CE envían todo el tráfico, destinados a los otros sitios, directamente al router PE.

Este servicio se basa en la utilización de pseudowires, combinados en una topología de malla completa (full mesh) de interconexiones entre los dispositivos PE que participan en una VPN determinada. Éstos llevan a cabo el aprendizaje de las direcciones MAC, de la misma forma que un switch ethernet para reenviar las tramas desde un CE a otro. Así, un CE puede reenviar tráfico en una forma punto a multipunto a otros CE.

Existe un problema de escalabilidad con este servicio, y tiene que ver con el incremento de sitios del cliente. Es necesario mantener en los PE un gran número de direcciones MAC para el reenvío de tramas por sitio de cliente.

VPN IPLS

Si se requiere intercambiar tráfico IP exclusivamente y los dispositivos CE son routers IP, entonces es posible el servicio IP sobre LAN. Si bien se transmiten datagramas IP, el mecanismo de reenvío se basa en información de encabezado de capa 2.

Dado que el siguiente salto o hop para cada datagrama IP es otro CE, las únicas direcciones MAC que un PE debe aprender, cuando reenvía las tramas de capa 2, son aquellas de los routers CE. Esto es una ventaja respecto del servicio VPLS por el reducido número de direcciones MAC a preservar por sitio de cliente.

VPN Sitio a Sitio Provistas por el Proveedor de Capa 3 (L3VPN)

Esta clase de VPN se basa en tecnologías más estables que las empleadas en las L2VPN, debido al estudio y desarrollo de las mismas. Esto le permite al proveedor de servicio tener mayor seguridad al momento de implementar una u otra solución.


20

Se pueden dividir a su vez en:

VPN basadas en PE: Los dispositivos PE participan en el enrutamiento y reenvío del tráfico del cliente basado en el espacio de direcciones de la red del cliente. En este caso los CE no participan de la VPN. El tráfico del cliente se reenvía entre los PE a través de túneles MPLS LSP, IPSec, L2TPv3 o GRE.

VPN basadas en CE: En este caso los túneles son creados entre los equipos CE, mientras los PE no participan en la VPN, solo reenvían el tráfico del cliente. Se utiliza IPSec o GRE para establecer los túneles.

1.2.5 Confiables y Seguras Esta es una clasificación donde se tiene en cuenta si es o no

necesaria la encriptación y autenticación de los datos a transferir entre los nodos de la VPN.

Los proveedores que no utilizan encriptación para los datos de sus clientes debido a que utilizan circuitos virtuales de capa 2 se pueden definir como VPN Confiables. Podemos mencionar las redes FRAME RELAY, ATM y MPLS.

En cambio en las VPN Seguras el tráfico de datos es autenticado y encriptado sobre el backbone del proveedor del servicio. Utilizan los protocolos IPSEC, SSL, L2TP asegurado mediante IPSEC, PPTP asegurado con MPPE (Microsoft Point-to-Point Encryption).

1.2.6 Overlay y Peer Las VPN overlay se dan entre dispositivos CE, los dispositivos PE no

participan en el enrutamiento de los clientes de la red, sino que reenvían tráfico de clientes basados en direccionamiento globalmente único, por lo tanto no tiene conocimiento del direccionamiento utilizado por el cliente.

Los túneles son configurados entre dispositivos CE usando protocolos como IPSec y GRE. Cabe observar que el modelo overlay tiene serios problemas de escalabilidad debido a que si se cuenta con muchos nodos de egreso el número de adyacencias se incrementa en directa proporción con el número de nodos.


21

Figura 1-6 Adyacencias del Ruteo

Pueden ser implementadas a nivel de capa física usando líneas telefónicas (dialup), a nivel de capa 2 utilizando Frame Relay, X-25 y ATM, o a nivel de capa 3 utilizando túneles IP o GRE.

Con el fin de clarificar veamos un ejemplo, la Figura 1-6, muestra un esquema en el que figuran tres sitios. Un sitio se conecta a través de los circuitos virtuales VC #1 Y VC #2 con otros dos sitios. Si suponemos que el sitio principal es Londres y los otros son Paris y Zurich podríamos ver que la percepción que poseen los routers CE es la que grafica la Figura 1-7


22

Figura 1-7 Infraestructura del proveedor

Si son reemplazados los dispositivo PE por routers y estos participan en el enrutamiento entonces es una VPN tipo Peer. Los routers tienen que poseer conocimiento del direccionamiento que utiliza el cliente. Esto es necesario debido a que las rutas se intercambian entre dispositivos CE y los dispositivos PE. Estas VPN son provistas por un proveedor de servicios.

Figura 1-8 VPNs tipo Peer


23

En la Figura 1-8 podemos observar que al reemplazar los switches por routers se convierte en una VPN tipo Peer.

1.2.7 No Orientadas y orientadas a la conexión Son orientadas o no orientadas a la conexión dependiendo si el

proveedor provee o no circuitos virtuales dedicados.

Orientada a la conexión: Son en las que provee el proveedor un circuito virtual dedicado. Por ejemplo FRAME RELAY y ATM.

No orientadas a la conexión: Son las que no poseen un circuito virtual. Por ejemplo las VPN basadas en IP.

1.2.8 VPNs de capa de transporte/aplicación El protocolo SSH (Secure Shell) desarrollado por Communications

Security Ltd., permite acceder a otro dispositivo a través de una red insegura, ejecutar comandos a una máquina remota y mover archivos de una computadora a otra. Utilizando encriptación sobre canales inseguros provee una fuerte autenticación y encriptación.

Existen dos versiones incompatibles entre sí. Son dos protocolos totalmente diferentes que usan distinto cifrado.

SSH v1 SSH v2

Autenticación de sistemas

Llaves de servidor y cliente Llaves de host

Autenticación Llaves Certificados

SSH2 es una completa reescritura del protocolo que lo hace mas seguro y utiliza una implementación de red totalmente distinta que SSH1. Debido a la diferente implementación ambos protocolos son incompatibles. Por ejemplo se lo utiliza para asegurar un túnel PPP. El principio de funcionamiento es el mismo que el de SSL diferenciándose en la capa en la que actúan y el método de autenticación.

SSH SSL

Capa en la que trabaja Aplicación Transporte Autenticación Llaves Certificados

También es posible establecer túneles en la capa de aplicación. Para esto se utiliza un browser del lado del cliente, por lo que no es necesario instalar ningún programa. La conexión se realiza a un sitio web seguro mediante el protocolo HTTPS (Hypertext Transfer Protocol Secure).

Además, existen otros productos los cuales ofrecen una combinación de gran flexibilidad, seguridad y que intentan lograr una configuración que no requiera mucho conocimiento. La seguridad es lograda mediante cifrado del tráfico usando el protocolo SSL/TLS.


24

1.2.9 VPN multiservicio Trabajan sobre MPLS, cuyo sello distintivo es la calidad de servicio

o QoS (Quality of Service). El objetivo de estas VPN es integrar diferentes aplicaciones en una sola conexión: voz, datos, multimedia, etc.

1.3 APLICACIONES Las VPN se utilizan en situaciones donde es necesario establecer una

comunicación en forma segura utilizando un medio o infraestructura compartida de transmisión. Además de comunicar redes propias de la organización, usuarios móviles, tele trabajadores etc. también es posible comunicar distintas organizaciones entre sí. Esta alternativa surge a partir de la necesidad de establecer lazos de negocios, o la concreción de intereses comunes.

La extranet refleja dichos intereses mediante la interconexión de las redes de datos de las distintas organizaciones. En realidad solo comparten los recursos necesarios para cumplir con los objetivos comunes, por lo que el acceso es parcial y controlado.

Finalmente las VPN se pueden considerar como un negocio con valor agregado en la forma de un servicio. El hecho de que hoy en día las organizaciones dependan fuertemente de las tecnologías de información para su desenvolvimiento y que sus necesidades sean diferentes, plantea un mercado donde las soluciones de comunicaciones de datos son casi a la medida del cliente. No existe una única solución para todos los tipos de organizaciones. Es por esto que los proveedores de servicios han sumado a su oferta de soluciones empresariales, el servicio de VPN, donde una buena relación costo-beneficio para el cliente es posible.

1.3.1 Intranet /Intranet extendida Una intranet en principio no se refiere a esquemas o topologías de

redes, sino a un conjunto de contenidos y recursos de información que son accedidos y compartidos en forma privada y segura entre miembros de una misma organización, con el objetivo de proveer la lógica de negocio para las aplicaciones de la organización. Es un medio, además, para la difusión de información interna, permitiendo que los empleados estén al tanto de lo que sucede en su ámbito laboral de una manera eficiente.

Una característica fundamental de las intranets, es el hecho que su funcionamiento se basa en tecnologías que implementan estándares abiertos, tanto en los protocolos de comunicación como en aquellos protocolos a nivel de aplicación. Es decir, utilizan la tecnología de Internet. En particular el uso de la suite TCP/IP para la comunicación y a nivel de aplicación los protocolos: HTTP, FTP, SMTP, POP3, LDAP, etc.

La clase de aplicaciones que se pueden encontrar en una intranet van desde el servicio de correo electrónico, hasta sistemas de información basados en web, sistemas de mensajería instantánea y colaborativos, sistemas de videoconferencia y comunicaciones de voz mediante IP (VoIP). El acceso y manipulación de la información, mediante estos sistemas se encuentra restringido, por lo tanto también existen sistemas que permiten autenticar y autorizar a los diferentes usuarios de la organización.


25

Una VPN sirve para expandir el alcance de una intranet. La privacidad que aporta una red privada virtual brinda la seguridad para acercar la intranet a los diferentes sitios o redes de datos que integran la organización logrando su interconexión a través de Internet y/o las redes backbone de los proveedores de servicio.

La intranet debería estar disponible para aquellos usuarios de la organización cuyo rol requiere movilidad y estar fuera de los límites de la misma, por lo tanto fuera de la red de datos. Es necesario que estos usuarios móviles estén conectados para acceder a aquellos recursos o datos que la intranet pone a disposición. Las redes distantes propias que pueden interconectarse y los usuarios móviles que pueden tener acceso se denominan, en su totalidad, una intranet extendida.

1.3.2 Extranets Una extranet es un conjunto de intranets de organizaciones

diferentes que se interconectan entre sí para cumplir con objetivos comunes. Esta relación esta bien definida y es establecida bajo un estricto control del acceso. Se puede definir también como la intersección de un grupo de intranets de varias empresas, lo cual indica que solo se comparte una porción de la intranet hacia el resto de la extranet.

Por otro lado Internet es el medio común que resuelve problemas de incompatibilidad entre sistemas de empresas muy diferentes. Es decir, ofrece una interfaz común que permite una interacción difícil de lograr con otras tecnologías. Por lo tanto, como en el caso de las intranets, adoptan las tecnologías basadas en estándares abiertos propias de Internet para lograr comunicación dentro de la extranet.

Una extranet puede tener un impacto notable en las relaciones e interrelaciones con las demás empresas que la integran. De hecho puede modificar notablemente la posición de la organización frente a sus clientes y competidores. Por esta razón la decisión de su implementación debe responder a fines estratégicos, por lo cual deberá ser tomada por la alta gerencia de la organización.

Las VPNs son la forma más efectiva de implementar las extranets, ya que pueden hacer uso de Internet para lograr la interconexión de los diferentes sitios. Nuevamente los puntos más importantes a considerar son la seguridad en cuanto al acceso solo de los usuarios autorizados mediante mecanismos de autenticación, como también el transporte a través de la encapsulación y encriptado de los datos. Como se ha visto en este capítulo, existen diversos protocolos de túnel utilizados en VPNs, los cuales se aplican obviamente en las extranets. Algunos de ellos como IPSec, encapsulan los paquetes originales y encriptan la información sensible, otros como PPTP y L2TP se valen de IPSec para brindar la confidencialidad.

1.3.3 Servicio VPN provisto por un proveedor Las corporaciones y organizaciones dependen cada vez más de las

telecomunicaciones y redes de datos. Es muy importante la interconexión de redes propias en diferentes sitios. Esta necesidad fue resuelta por proveedores de servicios de telecomunicaciones, principalmente a través de conexiones Frame Relay, ATM y más recientemente mediante ethernet y túneles basados en IP.


26

Estas organizaciones, requieren con más frecuencia, servicios de conectividad sobre uno o más backbones, incluso a través de Internet, pero que este servicio incluya contratos de nivel de servicio (Service Level Agreement), calidad de servicio (QoS), y otros parámetros que permitan una comunicación segura, estable, con alto grado de disponibilidad, con un umbral de ancho de banda, con priorización de tráfico, etc.

Estas características son difíciles de lograr cuando la comunicación entre sitios debe atravesar redes de diferentes proveedores más la Internet, es decir un entorno compartido y de naturaleza no orientada a la conexión.

Las VPN permiten una comunicación segura y privada mediante la encapsulación y encriptación. Es decir, aíslan el tráfico de datos privados de una organización del resto con el cual pueda compartir un canal de comunicación. Actualmente la relación costo-beneficio en la implementación de este mecanismo ha determinado la conveniencia de la contratación del servicio a proveedores, en lugar de la puesta en funcionamiento y control por parte de la propia organización.

Para poder diferenciar y aislar los tráficos pertenecientes a varios clientes, el proveedor utiliza conexiones de capa 2 (VPNs tradicionales) o túneles de capa 2 o 3. Para el caso de conexiones a través de Internet, las VPN se han basado en IPSec para brindar la mayor seguridad.

El concepto de servicio VPN provisto por el proveedor debe soportar los tipos tradicionales de VPN, además debe funcionar con las clases de proveedor definidos en el capítulo 1, además de Internet: único proveedor, conjunto de proveedores y proveedor de proveedores.

Existen requerimientos generales para esta clase de VPNs, un análisis detallado se expresa en la RFC 38097 . Estos requerimientos pueden clasificarse en:

Requerimientos del servicio: atributos del servicio que el cliente puede observar o medir, por ejemplo: disponibilidad y estabilidad, garantías de seguridad, servicio de tramas o datagramas.

Requerimientos del proveedor: características que el proveedor evalúa para determinar la viabilidad en términos de la relación costo-efectividad del servicio, por ejemplo escalabilidad y grado de administración

Requerimientos de Ingeniería: características de implementación que permiten cumplir con los requerimientos del proveedor y del servicio. Estos a su vez pueden clasificarse en:

Requerimientos en el plano de reenvío: asociados a los mecanismos de reenvío de datos.

Requerimientos en el plano de control: asociados al mecanismo de distribución de la información de enrutamiento.

Requerimientos relacionados a la uniformidad de los mecanismos en esta clase de VPN respecto de otros esquemas y en general con la forma de operación de Internet.

7 RFC 3809 - Generic Requirements for Provider Provisioned Virtual Private Networks


27

Calidad de servicio (QoS) y Acuerdos de nivel de servicio (SLA)

En general calidad de servicio se refiere a la habilidad de brindar servicios de redes y comunicaciones de acuerdo a un conjunto de parámetros especificados un contrato de nivel de servicio o SLA. La calidad esta caracterizada por la disponibilidad del servicio, tasa de demora, de variación de la demora (jitter), tasa de proceso de paquetes (throughput), de pérdida de paquetes. En particular, y desde una perspectiva de recurso de red, calidad de servicio se refiere a un conjunto de herramientas que permiten a un proveedor de servicio priorizar tráfico, controlar el ancho de banda y la demora en la red. Existen dos maneras de lograrlo en redes IP, mediante Servicios Integrados y a través de Servicios Diferenciados8

El ámbito en el cual un servicio VPN cumple con calidad de servicio dependerá del proveedor de servicio. En la mayoría de los casos de VPN definida en el sistema autónomo de un único proveedor es posible cumplir con este requerimiento. El soporte de QoS en ambientes de multi proveedores o diversos sistemas autónomos estará en función de los acuerdos de cooperación entre los involucrados en la provisión del servicio y de que todos utilicen los mismos mecanismos. Es decir que los dispositivos CE y/o PE ejecuten al menos formateo y apliquen políticas al tráfico (shaping y policing).

La necesidad de aplicar calidad de servicio ocurre principalmente en la red de acceso al backbone del proveedor y no en el interior del mismo, de hecho QoS sobre las conexiones PE a PE no son un inconveniente. En cuanto a la calidad de servicio en el acceso, se pueden distinguir dos enfoques:

Desde el CE a través de la red de acceso al PE

Desde el PE a través de la red de acceso al CE

Los dispositivos CE y PE deberían poder soportar QoS sin importar la tecnología de acceso ya sea de capa 2 o 3: circuitos virtuales ATM y Frame Relay, acceso basado en MPLS, DSL etc. Se pueden distinguir dos modelos de servicio para QoS:

Servicio de administración del acceso: este provee QoS sobre el acceso entre CE y los puertos del lado de cliente en el PE. No es requerido en el núcleo del backbone.

QoS borde a borde: brinda QoS sobre el backbone del proveedor, ya sea entre pares de dispositivos CE o pares de PE, dependiendo de los límites del túnel.

Un acuerdo de nivel de servicio SLA (Service Level Agreement) es una documentación donde se expresan los resultados de una negociación entre un cliente y un proveedor de servicios. En este documento se especifican los niveles de disponibilidad, perfomance, nivel de servicio, forma de operación y otros atributos del servicio.

A partir de un SLA se pueden determinar objetivos de nivel de servicio o SLO (Service Level Objective), considerando métricas individuales con los valores deseados e información operacional para controlar el SLA. Estas se pueden implementarse como políticas.

8 RFC 1633 - Integrated Services; RFC 2475 - Differentiated Service


28

Una especificación de nivel de servicio o SLS (Service Level Specification) engloba a las dos anteriores, es decir especifica un acuerdo negociado y las métricas individuales y datos operacionales, para garantizar la calidad de servicio del tráfico de red para ese cliente. Una SLS puede definirse sobre la base de los siguientes objetivos y parámetros, los cuales se pueden considerar sobre la base de conexiones a la red de acceso, VPNs o sitios:

Disponibilidad del sitio, VPN o conexión de acceso.

Duración de los intervalos de no disponibilidad del servicio.

Tiempo de activación del servicio.

Tiempo de respuesta para la resolución de un problema.

Tiempo de aviso de un inconveniente.

Limites para la variación del delay y jitter.

El sistema de administración y monitoreo del proveedor deberá medir y generar reportes respecto si las perfomance medida cumple o no los objetivos de la SLS. Muchas veces el nivel garantizado para los parámetros de los objetivos de nivel de servicio, dependen del alcance de la VPN, por ejemplo ciertos niveles pueden ser garantizados en el ámbito de un solo sistema autónomo, mientras que otro, aún más estricto, se puede cumplir en un dominio de un único proveedor pero con varios sistemas autónomos bajo su cargo. En un escenario multi proveedor es más difícil cumplir con aquellos parámetros que requieran un alto grado de cumplimiento, por ejemplo el requerimiento de QoS.


29

CAPÍTULO 2 ARQUITECTURAS, CLASIFICACIÓN

Y PROTOCOLOS

2


30

2.1 INTRODUCCIÓN A LAS ARQUITECTURAS DE VPN Las distintas infraestructuras de red y los distintos requerimientos

exigen diversos tipos de arquitectura de redes VPNs. Deberíamos realizarnos ciertos cuestionamientos para escoger cual es la que mejor se adapta a nuestras necesidades. Podríamos mencionar los siguientes:

¿Se posee con el personal calificado como para implementar las tecnologías necesarias o las soluciones existentes en el mercado proporcionadas por un proveedor pueden ser una mejor solución?

¿Cual es la interoperatividad de la arquitectura con nuestra infraestructura de red actual?

¿Es requisito indispensable comunicarnos con los clientes y/o proveedores?

¿Será fácilmente actualizable para nuestros futuros requerimientos en cuanto a escalabilidad, seguridad, facilidad de actualización y flexibilidad?

¿Soporta conferencia en red y multimedia?

¿El equipo actual soportara la carga nueva del procesamiento de la VPN o tendré que adquirir hardware?

¿Los ahorros son el único propósito o quiero implementar servicios con valor agregado?

¿Cuántos usuarios tendrían en la actualidad y cual seria su crecimiento futuro?

Al contestar estas preguntas y algunas que puedan surgir al cuestionarse cuáles son sus objetivos se podrá empezar a limitar las distintas soluciones que podrá implementar y mantener con el transcurso del paso del tiempo.


31

2.1.1 Componentes de una Red Privada Virtual Los componentes que forman una Red Privada Virtual se pueden

observar en la Figura 2-1

Figura 2-1 Componentes

Una solución de VPN se compone de varios elementos, los cuales se detallan a continuación:

2.1.2 Hardware El hardware es muy variado, lo integran servidores, PC y notebooks,

netbooks, routers, gateways y switches.

Las funciones que tienen asignadas el servidor son:

Esperar por los pedidos de conexión

Negociar las conexiones, entre otros la encriptación y autenticación.

Autenticar y autorizar a los clientes VPN.

Recibir datos del cliente y enviarle los pedidos por él.

También puede actuar como VPN gateway o VPN router.

El cliente generalmente se ejecuta en un equipo de un empleado en su hogar (tele trabajo), en una notebook, netbook o palmtops en algún sitio usando Internet o una red pública.

También puede realizarse tareas administrativas, en general son administradores remotos que realizan tareas de configuración, monitoreo y de gestión.


32

Para tener un mejor rendimiento se recomienda utilizar hardware específico como pueden ser routers que se encuentran optimizados para las tareas de VPN o se puede adicionar placas a routers existentes para dotarlos con la capacidad física y los protocolos necesarios para la encriptación y autenticación.

2.1.3 Seguridad de la infraestructura Consta de algunos de los siguientes elementos:

Firewall

El firewall protege a la intranet de ataques externos. En la Figura 2-2 se puede observar la ubicación del firewall en una organización con enlace a Internet.

Figura 2-2 Firewall

NAT

Los dispositivos que realizan NAT (Network Address Translation) permiten conectan dispositivos a otra red sin dar a conocer las verdaderas IP de los equipos. Este mecanismo se basa en el reemplazo de la dirección IP origen o destino real por otras direcciones IP. Esto permite economizar direcciones IP, al reemplazar varias direcciones IP privadas de origen por una única dirección IP pública asociada a la conexión a Internet. En la actualidad este mecanismo se encuentra implementado por defecto en los routers.

Servidores de autenticación

Los servidores de autenticación ofrecen mecanismos de autenticación y autorización para autenticación remota.

Estos pueden pertenecer a la organización o puede ser un servicio dado por el proveedor junto con el NAS. La Figura 2-3 describe estas dos opciones en el mismo grafico.


33

Figura 2-3 Servidores de Autenticación

Arquitectura AAA

AAA (Authentication Authorization Accounting) es un mecanismo de autenticación y autorización, puede ser implementado mediante los protocolos RADIUS (Remote Authentication Dial-In User Server) o TACACS (Terminal Access Controller Access Control System) con el objetivo de brindar un nivel más de seguridad. Tiene la capacidad de reconocer quien accede a la red, y saber a que recursos puede acceder y puede monitorear quien realiza que cosas en que lugar.

El mecanismo AAA funciona en conjunto con el servidor NAS que actúa como proxy. Este consulta al servidor RADIUS/TACACS y permite o deniega el acceso según corresponda.

2.1.4 Infraestructura de soporte para el servicio del proveedor Incluye los dispositivos que componen el backbone y el backbone de

Internet. El backbone del proveedor debería ser capaz de dar soporte a distintas tecnologías como Frame Relay, ATM, IP, IP Multicast, Voice over IP y también protocolos de túnel. Sería recomendable que soporte calidad de servicio. Para que brinde altos niveles de seguridad tendría que soportar IPSec y brindar servicio AAA.

Sería recomendable el soporte de protocolos de enrutamiento como RIP (Routing Information Protocol), OSPF (Open Shortest Path First), EGP (Exterior Gateway Protocol) y BGP (Border Gateway Protocol).

2.1.5 Redes Públicas Las redes públicas que podemos mencionar son Internet y la red

telefónica digital que permite brindar el servicio de DSL (Digital Suscriber Line), FRAME RELAY y ATM y la analógica que soporte velocidad de hasta 56Kbps.


34

2.1.6 Túneles Estos pueden estar basados en protocolos como PPTP, L2TP, L2F e

IPSec. En este capítulo y en el siguiente se tratarán con más detalle estos protocolos.

2.2 ARQUITECTURAS Existen muchas formas de combinar los distintos elementos que

componen una VPN. Esto origina que existan distintas arquitecturas que se clasifican de la siguiente manera:

2.2.1 Basadas en software Es un programa para establecer túneles o cifrado a otro anfitrión.

En el caso de no residir en el firewall, se debe configurar este para que permita la comunicación hacia y desde el exterior al equipo en que resida el software.

Este software puede ser abierto (Open Source) o propietario. La desventaja que posee el propietario es que el proveedor puede desaparecer o ser adquirido por otra empresa y se deja de producir actualizaciones de seguridad o de agregado de funcionalidad.

El Open Source tiene la ventaja de su costo de adquisición, pero puede ser necesario tener personal capacitado o realizar un contrato anual para tener soporte con algún proveedor.

2.2.2 Basadas en la Implementación Dependen de quien es el responsable de la implementación de la VPN y

su administración. Existen dos categorías y una tercera que es una combinación de las otras dos.

Dependiente

El proveedor del servicio es el responsable de proveer una solución llave en mano. La principal ventaja es que la organización no debe cambiar su infraestructura y no necesita personal con conocimientos en administración de VPN para su gestión.

La mayor desventaja surge en el ámbito de la seguridad. Es recomendable que la organización use una infraestructura AAA y firewall y estar a cargo de su administración.

Independiente

En esta categoría toda la responsabilidad de la implementación es de la organización. La encriptación, autenticación y autorización esta dada por elementos de la propia Intranet. El proveedor puede dar el servicio de Internet. Como desventaja se puede mencionar que se debe poseer personal capacitado en estas tecnologías


35

Híbrida

Esta categoría es una combinación de las categorías anteriormente mencionadas. Una parte de la administración es realizada por la organización y otra por el proveedor. Una arquitectura que se puede tener en cuenta es la que muestra la Figura 2-4 en la que se puede observar que existen varios proveedores de servicios. La ventaja es que si existe problemas con un proveedor se puede seguir conectado a los sitios que sean administrados por los otros proveedores. Provee una mejor disponibilidad.

Este acercamiento tiene la desventaja de que es compleja la administración.

Figura 2-4 Basada en la Implementación (Hibrida)

2.2.3 Basada en Seguridad Se podrían mencionar cuatro categorías:

Router a Router

Firewall a firewall

Túneles bajo demanda

Túneles Multiprotocolo bajo demanda

Router a Router

Túneles bajo demanda: El túnel es establecido entre dos routers que se encuentran en la conexión en el lado del cliente y en el lado del servidor. Puede soportar múltiples conexiones simultáneamente y persisten hasta que la última conexión es terminada. Los routers deben soportar intercambio de claves y algoritmos de encriptación. La Figura 2-5 muestra como se relacionan los componentes bajo esta arquitectura.


36

Figura 2-5 Túneles bajo demanda (Router a Router)

Túneles multiprotocolo bajo demanda: Es similar a routers bajo demanda con la particularidad que los routers soportan varios protocolos de túnel. Tiene la particularidad de que pueden transferir datos no-IP a través de la red pública.

Sesiones encriptadas bajo demanda: Cada sesión es encriptada en forma individual. Tiene un túnel distinto para cada pedido entre los routers como grafica la Figura 2-6. La desventaja es que esto genera una gran sobrecarga.

Figura 2-6 Sesiones encriptadas bajo demanda

Firewall a Firewall Consta de túneles bajo demanda y túneles multiprotocolo bajo

demanda. A continuación daremos un breve detalle.

Túneles bajo demanda Es similar a router a router con túnel bajo demanda, con la

particularidad que se reemplazan los routers por firewalls. Es más seguro y permite que se puedan implementar auditorias mas complejas.


37

Figura 2-7 Túneles bajo demanda (Firewall a Firewall)

Túneles multiprotocolo bajo demanda

Generalmente se utilizan L2TP asegurado con IPSec gracias a su característica multiprotocolo.

2.2.4 Iniciadas por el cliente

Cliente a Firewall/Router

Se negocia la sesión entre el cliente y el firewall/router. Éste debe soportar el pedido del cliente de inicio de sesión. El cliente debe poder comunicarse con el sistema operativo correspondiente.

Cliente a Server

El servidor VPN se encuentra dentro de la intranet corporativa, en vez de cumplir las funciones de servidor VPN y firewall/Router.

Es más seguro que el anterior porque el proveedor de servicios ignora la existencia del túnel.

2.2.5 Dirigidas Los datos son encriptados en el capa 5 del Modelo OSI. Es decir en

la capa de sesión. El protocolo más utilizado en socks 5. Los túneles son unidireccionales. El control de acceso puede utilizar el identificador del usuario, hora, aplicación y hasta el contenido del paquete.

La capa de sesión soporta una mayor variedad de mecanismos de encriptación. La Figura 2-8 muestra la distribución de los componentes.

2.2.6 Basado en la capa Depende en que capa del modelo OSI se encuentra configurada la Red

Privada Virtual. Puede ser en la capa de red o la capa de enlace.


38

Figura 2-8 Dirigida

Capa de Enlace

Se pueden dividir en:

Conexión Frame Relay: La principal ventaja es que provee el CIR (Committed Information Rate).

Conexiones virtuales ATM.

MultiProtocolo sobre ATM (MPOA)

MPLS

Capa de Red

Estos modelos ya fueron explicados cuando se desarrollo el tema de la Clasificación de VPNs en el capítulo anterior. Por lo tanto solo las mencionaremos. Un tipo son las Redes Privadas tipo Peer y el otro son las Redes Privadas tipo Overlay.

En este nivel se pueden usar los protocolos de capa 2 PPTP y L2TP. También se puede utilizar IPSec.

2.2.7 Basada en Clases Estas arquitecturas se basan en la complejidad de la configuración

de la VPN y del tamaño. Existen 5 clases que van de la 0 a la 4. Fue propuesta por VPN Technologies.

En la Tabla 2-1, podremos observar las clases y sus características.


39

2.2.8 Basada en Caja Negra Consiste en un dispositivo que contiene software de cifrado que se

ejecuta en un equipo del cliente. Se presupone que estos dispositivos de hardware crean túneles más rápidos bajo demanda y ejecutan el proceso de cifrado con mayor rapidez. Ofrecen una administración centralizada.

Es aconsejable que soporten los protocolos para establecimiento de túneles PPTP, L2TP e IPSec. En general este dispositivo se encuentra detrás del firewall.

2.2.9 Basada en Acceso Remoto En esta arquitectura existe un software que se ejecuta en un equipo

remoto que quiere establecer una conexión a través de una red pública con un túnel cifrado al servidor interno de la organización o de una línea de acceso telefónica hacia un servidor de autenticación. El servidor puede ser un router, un firewall, una caja negra o un servidor de autenticación independiente.

2.2.10 VPN múltiple servicios Son aplicaciones multiservicios que son generadas por proveedores.

Por ejemplo pueden dar el servicio de filtrado de contenido web y la revisión antivirus. El primero se suele añadir a un firewall para que pueda utilizar reglas para el acceso basado en el contenido.


40

Clase Nº

Software Protocolos Utilizados

Seguridad Acceso Características

0 Como mínimo sistema

operativo Windows 95/98

PPTP Filtrado de paquetes ofrecido por un

Gateway, firewall o router

DSL T1

No soporta sitio a sitio

1 IPSec DES IKE

Algún mecanismo de Autenticación de

Usuarios 1 Gateway

T1 T3

Soporta: 20 sucursales

250 usuarios remotos Soporta sitio a sitio

y acceso remoto Para poder

implementar una extranet esta debe

soportar IPSec 2 Soft de

marcación y de acceso remoto.

IPSec 3DES IKE

Utiliza Token 5 VPN Gateway o 1 gateway que soporte

500 usuarios concurrentes

AAA,RADIUS,TACACS, NAT y firewall

Soporta: 10 a 100 sitios

remotos 500 usuarios remotos

sitio a sitio y acceso remoto

3 Soft de marcación y de acceso remoto

X.500 LDAP IPSec 3DES IKE

Token y smartcards 20 VPN Gateway o 1 gateway que soporte

1000 sesiones simultaneas

AAA,RADIUS,TACACS, NAT y firewall Servicio de

certificados propio

Es necesario calidad de servicio en cuanto a retardo ISDN Xdsl T1 T3

Soporta: Cientos de sitios remotos y miles de usuarios remotos

Extranet usuarios remotos y

sitio a sitio Videoconferencia

Tiene la desventaja que es compleja la administración, configuración e implementación

4 Soft de marcación y de acceso remoto

LDAP IPSec 3DES IKE

Token y smartcards 10 a 20 gateway o 1 que soporte 5000

conexiones simultaneas

AAA,RADIUS,TACACS, NAT y firewall Servicio de

certificados propio

ISDN Xdls T3 OC3

Soporta: Miles de sitios

remotos 10000 usuarios

remotos Extranet, sitio a sitio, usuarios

remotos Comercio electrónico Audio y video en

tiempo real Posee la desventaja

que necesita profesionales

altamente capacitados

Tabla 2-1 VPNs basadas en Clases


41

2.3 PROTOCOLOS DE TÚNEL Un protocolo de túnel es un mecanismo para encapsular un PDU9

denominado de carga o nativo. Se agrega un encabezado al PDU de carga propio del protocolo de túnel. Finalmente este nuevo PDU se debe entregar a su destino final mediante un protocolo de transporte o envío, por lo que es necesario agregar el encabezado correspondiente a este último.

Esta clase de protocolos se utilizan para el envío de datos de un determinado protocolo a través de una red que soporta uno diferente o incompatible. También se usan cuando es necesario asegurar los datos de carga mediante algún método de encriptación. Otro uso extendido es resolver problemas de espacio de direcciones para los datos a transmitir, por ejemplo cuando mediante el uso de un espacio de direccionamiento público se envían paquetes con direcciones privadas.

Figura 2-9 Funcionamiento de un Túnel

Un túnel es un medio para reenviar datos a través de una red desde un nodo a otro, como si ambos estuvieran conectados en forma directa. Luego de los encapsulamientos, el PDU resultante es reenviado por nodos intermedios basados en la información del encabezado externo sin tener en cuenta el contenido original del paquete.

La Figura 2-9, muestra dos nodos A y B que se comunican mediante el túnel entre los nodos W y Z. Estos últimos se denominan nodos de ingreso y de egreso respectivamente. Los datos originales entre A y B son modificados agregándoles un encabezado que permite reenviarlos a través del túnel. Los nodos intermedios X e Y solo participan del proceso de transporte, pero no tienen acceso a la información original propia de la comunicación entre A y B. Cuando el paquete llega al extremo final o nodo de egreso Z, del túnel, este le saca el encabezado exterior y reenvía el paquete al destino real, el nodo B.

La utilización de túneles permite la separación del tráfico de datos de varias VPNs y del tráfico correspondiente a la red del proveedor o de Internet. Esto significa que el espacio de direcciones utilizado por los dispositivos involucrados en la VPN forma parte de los datos que se envían por los túneles sin modificación, aún si se usa Internet para su transporte.

9 Unidad de datos de protocolo


42

2.3.1 Requerimientos de un Túnel Existen requerimientos deseables en los mecanismos de túnel, pero no

todos los protocolos existentes cumplen con todos ellos. Estos son10:

Multiplexación

Protocolo de señalización

Seguridad de los datos

Transporte multiprotocolo

Secuenciación de tramas

Mantenimiento

Manejo de grandes MTU

Sobrecarga mínima

Control de congestión y flujo

Manejo de tráfico y Calidad de servicio (QoS)

Multiplexación

Esto permite el anidamiento de túneles, es decir que puedan existir múltiples túneles VPN entre dos extremos que han establecido un único túnel principal, esto implica que cada extremo del mismo puede soportar varios clientes o VPNs. El tráfico de cada uno se mantendrá separado del otro a través de la existencia de un campo de multiplexión en los paquetes transmitidos para distinguir la pertenencia a un determinado túnel.

Compartir un túnel de esta forma, disminuye la demora y el procesamiento asociado al establecimiento del mismo. Esta característica representa una ventaja ante los problemas de escalabilidad para un proveedor de servicios VPN ya que solo tiene que mantener una estructura de túneles de menor envergadura.

Figura 2-10 Multiplexación de Túneles

10 RFC 2764 – A framework for IP Based VPN


43

Protocolo de señalización

Previo al establecimiento de un túnel, se deben configurar una serie de parámetros que deben ser acordados por los extremos participantes, por ejemplo la dirección de los extremos, el nivel de seguridad requerido, etc. Finalmente el túnel se puede establecer. Todo esto es posible por vía manual o en forma dinámica mediante el uso de un protocolo de señalización.

La utilización de un protocolo de señalización, facilita la tarea de administración del túnel, tanto su creación, distribución y manejo de parámetros o atributos asociados al mismo, mas aún cuando la VPN a la cual pertenece el o los túneles abarca más de un dominio administrativo. En este caso simplifica la coordinación de la administración.

También permite que los túneles puedan ser creados bajo demanda, cuando los nodos que los constituyen son móviles o requieren estar interconectados en forma transitoria. Es importante que el protocolo permita el transporte de un identificador VPN para asociar esta con el túnel resultante.

El rol de este protocolo debería ser negociar los atributos del túnel y no transportar información acerca de como utilizar el mismo.

Seguridad de los datos

Un protocolo de túnel debe soportar mecanismos que permitan varios niveles de seguridad. Esto significa incluir métodos de encriptación y autenticación de diversas fortalezas.

La seguridad de los datos de la VPN en general no depende únicamente de las capacidades requeridas del túnel recién mencionadas. Es importante considerar otros mecanismos, como por ejemplo el manejo de varias instancias virtuales de tablas de enrutamiento y reenvío. Cada par (enrutamiento y reenvío) estarán asociadas a una VPN. Un mismo dispositivo en el extremo de un túnel, podrá manejar varias instancias por lo tanto varias VPNs. Esto evita el enrutamiento por error del tráfico de una VPN hacia otra, asegurando de esta manera la separación de los flujos de datos. Otra medida de seguridad puede ser la autenticación de los extremos del túnel mediante el uso del protocolo de señalización previo a su creación.

Transporte Multiprotocolo

Muchas aplicaciones de VPN requieren la transmisión de tráfico multiprotocolo, por lo tanto el protocolo de túnel debería soportar su transporte. Debe existir alguna forma de identificar el tipo de protocolo que esta siendo enviado por el túnel.

No todos los protocolos de túnel soportan esta característica, para estos existen extensiones que lo posibilitan. Otros poseen campos específicos para esta señalización.

Secuenciación de Tramas

La secuenciación podría ser necesaria para una operación extremo a extremo eficiente de algún protocolo de túnel o aplicación en particular. Para esto es necesario un campo de secuencia en el diseño del protocolo, para garantizar la entrega en orden de los paquetes.


44

Mantenimiento

Este requerimiento implica que los extremos monitoreen el estado del túnel para determinar si se pierde o no la conectividad y tomar las medidas adecuadas en caso de corte o falla de la misma.

Las formas de realizar este monitoreo pueden ser dos: a través del protocolo en si, ejecutando un chequeo en banda en forma periódica y en caso de pérdida de conexión indicar explícitamente el problema. La otra forma es mediante mecanismos fuera de banda, por ejemplo el uso de protocolos de enrutamiento aplicados a una malla de túneles (RIP, OSPF), lo cual permite detectar cualquier falla en forma automática. Otra herramienta es el uso del protocolo ICMP a través de mensajes de solicitud de eco para monitorear el estado del túnel.

Manejo de Grandes MTU

Teniendo en cuenta los dispositivos intermedios que reenvían el tráfico del túnel, es posible que alguno de ellos maneje un valor de Máxima Unidad de Transferencia o MTU menor al valor manejado desde el extremo de ingreso al túnel. En este caso, es necesaria alguna clase de fragmentación. Esto traería inconvenientes de perfomance en el nodo donde sucede la fragmentación, disminuyendo la eficacia general.

Para evitar este inconveniente, el protocolo de túnel puede incorporar capacidad de segmentación y ensamblado haciendo uso del número de secuencia y alguna clase de marcador de fin de mensaje.

Sobrecarga Mínima

Es importante este aspecto y más cuando se transporta tráfico de datos sensible a la demora o al defasaje temporal, como lo es el tráfico de voz y video. Lo que se persigue con este requerimiento es evitar el procesamiento innecesario en los dispositivos que establecen el túnel.

Los mecanismos de cifrado y encriptación imponen una sobrecarga. Por lo tanto se debería minimizar la sobrecarga u overhead tomando en cuenta la necesidad de aplicar seguridad a los datos. En general el objetivo debería ser minimizar el overhead alrededor de la necesidad de seguridad del tráfico de datos.

Cuando se implementan las VPN dial-up, o de acceso remoto discado, mediante el uso de túneles voluntarios, existe la posibilidad de sobrecarga significante si se utilizan enlaces de poco ancho de banda.

Control de Congestión y Flujo

Existen protocolos de túnel, como L2TP, que incorporan procedimientos para el control de flujo y congestión. Estos fueron pensados para mejorar la perfomance de la transmisión cuando se utilizaban redes que podían generar pérdidas de paquetes con la compresión PPP. Otra razón era crear un buffer al momento de utilizar líneas con menor capacidad de transferencia. Finalmente estos esquemas se aplicaron a los canales de control en lugar de aplicarlos al tráfico de datos.

En general no está claro si es conveniente incorporar estas características en el diseño de los protocolos de túnel, en gran medida por el hecho de la predominancia del tráfico TCP y el hecho de que TCP posee sus propios y eficientes mecanismos extremos a extremo de control de flujo y congestión.


45

Manejo de Tráfico y QoS

Los usuarios de un servicio de VPN, podrían desear características de Calidad de Servicio como sucede con los demás servicios WAN. Para el caso de las VPN, lograr aplicar QoS va a depender de las características de manejo de tráfico que puedan efectuar los nodos involucrados en la VPN y de la red de acceso o backbone donde se implemente.

2.4 PROTOCOLOS DE TÚNEL CAPA 2 Los túneles mas usuales son los implementados en la capa 2 o capa

enlace del modelo OSI. Entre ellos podemos mencionar Point to Point Tunneling Protocol (PPTP), Layer 2 Forwarding (L2F) y Layer 2 Tunneling Protocol (L2TP). Los protocolos de esta capa se basan en otro protocolo denominado Point to Point Protocol (PPP), por lo que comenzaremos explicando este protocolo.

2.4.1 Point to Point Protocol (PPP) Es un protocolo para encapsular que permite transmitir a través de

una línea serie. Este requiere una conexión full-duplex y puede ser sincrónico o asincrónico. Puede encapsular IP o no IP a través de líneas series.

Las funciones que realiza son administrar las direcciones IP del trafico no IP. Configura y realiza las pruebas necesarias para establecer el enlace, encapsula los datagramas y realiza la detección de errores durante la transmisión. También realiza la multiplexación de los protocolos de capa 2 y renegocia parámetros como la compresión de los datos transmitidos.

Para realizar estas funciones se basa en LCP (Link Control Protocol) para establecer, configurar y probar las conexiones punto a punto y NCP (Network Control Protocol) para establecer y configurar varios protocolos de la capa de red y para detectar errores durante la transmisión.

Funciones de LCP11

Realiza las siguientes funciones:

Ayuda a establecer el enlace PPP.

Configura y establece el enlace para satisfacer los requerimientos de comunicación de las partes.

Realiza las tareas necesarias para mantener el enlace.

Da por finalizado el enlace cuando se termina el intercambio de datos entre las partes.

11 RFC 1661- The Point-to-Point Protocol (PPP)


46

2.4.2 Point to Point Tunneling Protocol (PPTP) El protocolo punto a punto (PPTP) se creó para permitir a usuarios

remotos conectarse a su proveedor y establecer un túnel al servidor de la organización. Permite realizar una conexión por marcación y soporta protocolos que no sean IP.

PPTP es una extensión de PPP y por lo tanto no soporta múltiples conexiones. PPTP es el encargado de establecer y terminar las conexiones físicas entre las partes, autenticar los clientes PPTP, encriptar datagramas de protocolos no IP e IP para crear datagramas PPP y asegurar el intercambio de información entre las partes. Esto se puede observar en la Figura 2-11.

Figura 2-11 Funciones del Protocolo PPP en PPTP

En la figura podemos ver los elementos involucrados en una transacción PPTP. Existe un cliente, el cual es el que inicia la transacción a través de una conexión realizada con un modem a través de una marcación. Si el NAS del proveedor acepta la comunicación entonces se puede establecer el túnel con el dispositivo VPN a través de la red pública. En la Figura 2-12 podemos observar la relación entre PPP y PPTP.


47

Figura 2-12 Componentes en una conexión PPTP

El dispositivo NAS debe poder soportar múltiples clientes concurrentemente y distintos tipos de cliente, como por ejemplo cliente WINDOWS, LINUX, Apple, etc. Si se realiza dentro de una red local no es necesario el dispositivo NAS. El servidor PPTP debe tener capacidad de enrutamiento.

PPTP utiliza el puerto 1723. Para detectar la pérdida la conexión realiza una transmisión periódica de echo entre el cliente y el servidor utilizando la conexión TCP establecida. Brevemente resumiremos como es el proceso de transmisión los datos basándonos en la Figura 2-13.

Figura 2-13 Encapsulamiento PPTP

Se encapsula y se encripta los datos en un datagrama PPP

Se encapsula dentro de un paquete GRE

Se encapsula de un paquete IP. El encabezamiento contiene la dirección IP de cliente PPTP y la del servidor destino.

La capa de enlace suma un encabezamiento y una cola, el cual viaja a través del túnel establecido.

Esto es encapsulado dentro del protocolo de transmisión que puede ser por ejemplo ethernet o un protocolo de WAN.

El servidor extrae en orden inverso y termina desencriptando los datos.


48

Para realizar la encriptación y compresión se utiliza los servicios brindados por PPP. En cuanto a la autenticación se utiliza MS-CHAP (Microsoft Challenge-Handshake Authentication Protocol) o PAP (Password Authenticaction Protocol). PPTP permite realizar un filtrado en el servidor aceptando solamente los clientes que fueron aprobados para acceder a la red.

2.4.3 Layer 2 Forwarding Protocolo (L2F)12 Es un protocolo desarrollado por Cisco en el año 1996. El objetivo

era permitir que protocolos no IP pudieran utilizarse sobre Internet. El usuario hace una conexión PPP al proveedor de marcación y se conectan a sus organizaciones a través de L2F.

Figura 2-14 Componentes en el Protocolo L2F

L2F provee la encriptación de datos y la autenticación utilizando CHAP, EAP (Extensible Authentication Protocol) y SPAP (Shiva Password Authentication Protocol). También puede emplear RADIUS y TACACS como servicios adicionales.

Como desventajas se puede mencionar que esta solución requiere un mantenimiento costoso y son dependientes del proveedor que debe implementar L2F. No provee control de flujo, lo que resulta en retransmisión de tráfico y provoca una comunicación más lenta. Es más lento que PPTP debido al proceso de autenticación y encriptación.

2.4.4 Layer 2 Tunneling Protocolo (L2TP)13 En 1998 las compañías que desarrollaron PPTP y Cisco que trabajó con

L2F acordaron una nueva especificación para el establecimiento de túneles de nivel 2 (L2TP). Por lo tanto L2TP combina PPTP y L2F en una sola norma.

IPSec se puede utilizar con L2TP para poder brindar una mayor seguridad. Se recomienda implementar esta configuración para proteger el trafico L2TP a través de redes IP y no IP.

12 RFC 2341 - Cisco Layer Two Forwarding (Protocol) "L2F"

13 RFC 2661 - Layer Two Tunneling Protocol "L2TP"


49

Las ventajas que tiene es que soporta multiprotocolos y tecnologías como por ejemplo IP, ATM, Frame Relay y PPP. No requiere implementación de software específico como drivers o soporte en el sistema operativo. Permite que clientes con IP privadas se comuniquen a través de redes públicas con sitios remotos. Y por último se puede mencionar que la autorización y autenticación se realizan en un gateway por lo tanto el proveedor no necesita implementar y mantener una base de datos de los usuarios remotos y sus derechos de acceso.

Es necesario definir antes, dos componentes principales en el funcionamiento de L2TP: LAC (L2TP Access Concentrator) y LNS (L2TP Network Server). Un LAC es un dispositivo que es uno de los extremos del túnel L2TP y siendo el LNS el otro extremo. De hecho un LAC se ubica entre un cliente remoto y el LNS reenviando los paquetes entre ellos. La conexión entre el LAC y el sistema remoto es mediante un enlace PPP. Un LNS es el otro extremo del túnel L2TP y representa la terminación lógica de la sesión PPP que es enviada por el túnel.

Modos de túnel

L2TP soporta los modos de túnel obligatorio y voluntario. En el modo obligatorio Figura 2-15, el proveedor es el encargado de establecer entre el LAC y el LNS el túnel y de validar el usuario. Para comunicarse con Internet es necesario pasar por gateway de la intranet corporativa, brindando una mayor seguridad.

Figura 2-15 L2TP Túnel obligatorio

En el túnel voluntario Figura 2-16, el usuario remoto actúa de LAC. El túnel es transparente para el proveedor como ocurre con los túneles basados en PPTP.


50

Entre las ventajas que podemos mencionar esta que es una solución genérica, independiente de la plataforma. Puede soportar la transmisión a través de enlaces WAN no IP sin la necesidad de IP. No se requiere configuración en el proveedor y en el cliente. Permite que la autenticación sea realizada por la organización y no por el proveedor. Provee control de flujo. Es más rápida que L2F. Permite que clientes remotos con IP privada puedan conectarse a su organización a través de redes públicas. Se puede utilizar IPSec para poder brindar una mayor seguridad.

Como desventajas podemos mencionar que es más lento que PPTP o L2F cuando se utiliza IPSec para autenticación de cada paquete y es más complejo de implementar que PPTP.

Figura 2-16 L2TP Túnel voluntario

Tabla 2-2 Comparativa protocolos Capa 2

Característica PPTP L2F L2TP Soporta multiprotocolo Si Si Si Soporta múltiples conexiones PPP por túnel No Si Si

Soporta múltiples conexiones por túnel No Si Si

Modos de Túnel Voluntario Voluntario y Obligatorio

Voluntario y Obligatorio

Protocolo de Entrega IP/GRE IP/UDP IP/FR IP/ATM

IP/UDP IP/FR IP/ATM

Protocolo de Control TCP

Puerto 1723

UDP Puerto 1701

UDP Puerto 1701

Autenticación MS-CHAP PAP

CHAP PAP SPAP RADIUS TACACS

CHAP PAP SPAP EAP IPSec TACACS

Encriptación MPPE MPPE IPSec

MPPE IPSec ECP


51

2.5 PROTOCOLOS DE TÚNEL CAPA 3 En la siguiente sección se describirá los principales protocolos de

túnel de capa 3, empezando con IPSec, GRE y finalmente MPLS. Si bien este último no es en si un protocolo de capa 3, su funcionamiento esta muy ligado al protocolo de red IP.

2.5.1 IP Security Protocol (IPSec) IPSec es una extensión del protocolo IP que brinda seguridad a IP y

a los protocolos de capa superior. Fue desarrollado para el nuevo estándar de IP versión 6 (IPv6) y luego adaptado para implementarlo en la versión 4 (IPv4).

Figura 2-17 Paquete/Datagrama usando IPSec

La Figura 2-17 muestra un paquete con los encabezados de capa 2 que encapsulan un datagrama IP procesado mediante IPSec. Se puede observar el encabezamiento IPSec posterior al encabezado IP y un campo Datos de Autenticación (HMAC) como cola del datagrama. Como resultado surge un nuevo datagrama IP con nuevos encabezados.

IPSec utiliza dos protocolos diferentes para asegurar la autenticidad, integridad y confidencialidad, estos son el protocolo de Autenticación de Encabezado AH (Authentication Header) y el protocolo de Encapsulado de Seguridad de Datos o ESP (Encapsulated Security Payload).

IPSec puede proteger todo el datagrama IP o solamente los protocolos de capa superior mediante los modos túnel y transporte. En el primer caso el datagrama IP es encapsulado en forma completa en otro. En el modo transporte solo los datos del datagrama IP original es procesada por IPSec, insertando el encabezado AH o ESP entre el encabezado IP y los datos.

Para asegurar la integridad del datagrama IP, IPSec utiliza HMAC14 (Hash Message Authentication Code) o Código de autenticación de mensajes basados en hash, mediante algoritmos como MD5 y SHA. Lo calcula basado en una clave secreta y en el contenido del datagrama. El HMAC se incluye en el encabezado IPSec. El receptor verifica este HMAC si tiene acceso a la clave secreta.

14 RFC 2104 - HMAC: Keyed-Hashing for Message Authentication


52

IPSec utiliza algoritmos de encriptación simétricos estándar de elevada fortaleza como 3DES, AES o Blowfish para asegurar la confidencialidad del tráfico transportado. IPSec protege la comunicación respecto de ataques de denegación de servicio o ataques de repetición, mediante el mecanismo de ventana deslizante. Los números de secuencia de los paquetes deben estar dentro del rango aceptado por la ventana, sino son descartados.

Para encapsular y desencapsular los paquetes IPSec, los extremos participantes necesitan un mecanismo para mantener información como claves secretas, algoritmos, direcciones IP utilizadas en la conexión etc. Estos parámetros se guardan en Asociaciones de Seguridad o SA (Security Association). Estas a su vez se almacenan en una Base de Datos o SAD. Cada SA define los siguientes parámetros:

Direcciones IP origen y destino del encabezado IPSec resultante (direcciones que coinciden con las de los pares que establecen la comunicación segura).

El protocolo IPSec a utilizar (AH o ESP).

Algoritmo y claves secretas a utilizar.

SPI (Security Parameter Index) de la SA. Es un número de 32 bits que identifica la SA.

Algunas implementaciones de bases de datos de SA permiten, además, almacenar estos parámetros:

Modo IPSec (túnel o transporte).

Tamaño de la ventana deslizante.

Tiempo de duración de la SA.

Una SA representa una conexión unidireccional. IPSec requiere que se definan dos SA para una comunicación bidireccional o full duplex. Las asociaciones solo determinan como proteger el tráfico. Las Políticas de Seguridad o SP establecen que tráfico proteger y cuándo. Las SP se almacenan a su vez en una SPD o base de datos de políticas de seguridad. Una SP define los siguientes parámetros:

Direcciones IP origen y destino de cada paquete. En modo transporte estas direcciones coinciden con las IP almacenadas en la SA. En modo túnel estas podrían diferir.

Puerto y protocolo a proteger. Algunas implementaciones de IPSec no permiten estos parámetros, en estos casos se aseguran todos los paquetes.

La SA a utilizar.

La SPD discrimina el tráfico entrante o saliente, de forma tal que puede descartar el paquete en tránsito, ignorarlo o aplicar el servicio de seguridad de acuerdo a la asociación de seguridad relacionada con esa entrada de la SPD.

La SPD debe ser consultada durante el procesamiento de todo el tráfico, entrante y saliente. Por esta razón esta contendrá entradas diferentes para uno y otro. Además cada interfaz de red que es protegida por IPSec tendrá asociada sendas bases, de políticas y de asociaciones, para el tráfico entrante y saliente.


53

Cada implementación IPSec debe tener una interfase administrativa que permita a un administrador manejar la SPD. Dado que cada paquete entrante o saliente es procesado por IPSec y donde la SPD especifica la acción a ser tomada en cada caso, esta interfaz debe permitir al administrador establecer el procesamiento de seguridad que se aplicará a cada paquete, mediante la creación de entradas y la definición de los filtros selectores, además deberá permitir el ordenamiento de las mismas.

Si los valores de un paquete IP corresponden con los selectores de una entrada en la SPD, entonces se determina que un paquete IP esta relacionado con la misma y esto dispara un proceso IPSec. A continuación se determina si existe una Asociación de Seguridad (SA) para la entrada de la SPD. Si existe, entonces esta indicará el protocolo de seguridad a utilizar, el modo, el algoritmo de autenticación de encriptación y las claves a utilizar.

Cuando varios nodos participan de una VPN que utiliza IPSec para crear los túneles, surge un inconveniente al momento de compartir información para la comunicación dentro de la VPN. Durante la creación de las Asociaciones de Seguridad, se deben difundir las claves secretas y los algoritmos de encriptación a utilizar.

El intercambio de claves es un proceso crítico ya que en esta etapa aún no hay un medio seguro establecido para transmitir esta información. Para resolver este problema se diseñó el protocolo de intercambio de claves o IKE (Internet Key Exchange).

IKE autentica, en una primera fase, a los pares o nodos que participan en la VPN. En una segunda fase se negocian las SA y se eligen las claves secretas para la encriptación simétrica mediante el algoritmo Diffie Hellman de intercambio de claves. Una vez compartidos en forma segura los datos necesarios, IKE se encarga en forma periódica de regenerar claves que protegen la confidencialidad de las claves para encriptación simétrica.

Protocolo AH

Este protocolo se encarga de autenticar los datagramas asegurando la integridad de los datos incluyendo la dirección IP de origen, brindando además protección contra ataques de repetición de datagramas (replay attacks). Para establecer la integridad de los datos calcula un código de autenticación basado en hash o HMAC. Este se realiza utilizando una clave secreta, los datos del datagrama y el encabezado IP original. El valor resultante del procedimiento se coloca en el campo Datos de Autenticación del encabezado AH.

Figura 2-18 Encabezado AH


54

Los campos del encabezado AH son:

Próximo Encabezamiento: identifica el tipo de datos de la carga útil, es decir el protocolo de capa superior. Utiliza 1 byte.

Longitud del encabezamiento: identifica el tamaño del encabezado, utiliza 1 byte.

Reservado: utiliza 2 bytes.

SPI: Identifica la SA a utilizar. Utiliza 4 bytes.

Número de Secuencia: Previene los ataques de repetición (replay) en forma opcional y además sirve para mantener una recepción ordenada de paquetes. Este campo almacena un número que se incrementa en uno cuando un paquete es enviado en forma consecutiva a la misma dirección y con el mismo SPI. Utiliza 4 bytes.

Datos de Autenticación: Compendio (Digest) calculado mediante el HMAC, utilizado por el receptor para comparar lo recibido luego de aplicar la misma operación al datagrama.

AH puede usarse solo o junto con ESP cuando se usa el modo túnel. Cuando se utiliza el modo transporte, el encabezado AH se coloca justo detrás del encabezado IP y antes del encabezado ESP, en caso de funcionar en conjunto, u otro encabezado de protocolo de mayor nivel como UDP o TCP. Ver Figura 2-19.

Cuando se usa el modo túnel, se agrega un nuevo encabezado IP y el encabezado de AH se inserta luego de este y antes del encabezado IP del datagrama original. Si bien el proceso de autenticación abarca este nuevo encabezado IP, la norma especifica que no deberá afectar aquellos campos que puedan variar durante el transporte, por ejemplo el campo de Tiempo de vida o TTL (Time To Life), que es decrementado en uno cada vez que el datagrama atraviesa un router. Ver Figura 2-19.

El protocolo AH no es conveniente de utilizar cuando se considera el uso de traducción de direcciones de red o NAT, debido a que su protección de integridad abarca campos del encabezado IP como la dirección de origen. Es adecuado si lo único que se persigue es asegurar la integridad y autenticar el origen de los datos.


55

Figura 2-19 Modos con protocolo AH

Protocolo ESP

Este protocolo provee privacidad o confidencialidad a los datagramas IP por medio del encriptado de los datos correspondientes. Adicionalmente puede asegurar la integridad mediante un HMAC propio. ESP altera el datagrama IP original en más de un sitio: agrega un encabezado propio, una cola (CE en la Figura 2-20) y si es necesario rellena el campo de datos. La cola varía si además de la encriptación se usa autenticación (DA en la Figura 2-20).

En el modo transporte, de igual manera que AH, el encabezado de ESP se agrega luego del encabezado IP y antes de otro encabezado de protocolo de mayor nivel como UDP o TCP. En modo túnel el encabezado de ESP se inserta delante del encabezamiento IP original pero antes del nuevo encabezado IP propio de este modo. Esto se muestra en la Figura 2-20, modo túnel.

El proceso de encriptado incluye todos los campos posteriores al encabezado ESP, pero no este mismo. La autenticación se aplica a lo encriptado más el encabezado ESP. El encabezado IP externo no se autentica, es decir, el encabezado IP original en el modo transporte o el nuevo encabezamiento IP del modo túnel.


56

Figura 2-20 Modos en ESP

Figura 2-21 Encabezado y Cola ESP

De acuerdo a la Figura 2-21 los campos del encabezado ESP son:

SPI: Este indica que SA utilizar para desencapsular el paquete ESP, igual a AH. Utiliza 4 bytes.

Número de Secuencia: igual que en AH.

Campo de datos IP (payload)


57

Vector de Inicialización: utilizado en el proceso de encriptación si este requiere datos de sincronización. Este vector sirve para que dos paquetes con la misma carga resulten en dos cargas encriptadas diferentes. Los algoritmos de encriptación simétrica son vulnerables a ataques de frecuencia si no se utilizaran los vectores de inicialización.

Encabezado TCP

Datos

Cola ESP

Relleno (Padding): Se usa en caso que el algoritmo de encriptado requiera que el texto a encriptar sea múltiplo de cierta cantidad de bytes (cifrado en bloques). También es necesario para lograr un múltiplo impar de 16 bits del encabezamiento hasta ese punto, de manera que los campos restantes, de 8 bits cada uno, logren que la longitud total, del encabezado, sea un número múltiplo par de 16 bits.

Longitud del relleno (Padding Length): identifica el campo anterior.

Siguiente Encabezado (Next Header): indica el tipo de datos de la carga útil. En Ipv4 identifica el protocolo de capa superior. Utiliza 1 byte.

Datos de autenticación: Es opcional y solo aparece si se utiliza ESP con autenticación. Su longitud varía según el algoritmo de Hash empleado: 16 bytes si es MD5 o 20 bytes si es SHA.

ESP puede utilizarse solamente con encriptación o incluyendo además autenticación. Otra alternativa es con encriptado nulo, o sea sin encriptación pero con autenticación. ESP puede combinarse con AH.

Si bien ESP puede autenticar, no abarca al encabezamiento IP externo, es decir no lo protege de cualquier alteración en aquellos campos que no deberían cambiar. Por ejemplo, lo anterior podría derivar en la fragmentación del datagrama si se alterara el campo correspondiente. Esta operación podría permitir la inserción de datagramas de ataque.

Protocolo IKE

También conocido como ISAKMP/Oakley (Internet Security Association and Key Management Protocol), este protocolo resuelve el problema más importante relacionado con las comunicaciones seguras: la autenticación de los pares, el intercambio de claves simétricas, creación de las SA y actualización la Base de Datos que las contiene. IKE se implementa mediante un demonio en el espacio de usuario. Utiliza el puerto UDP 500.

Su funcionamiento se puede dividir en dos etapas o fases. En la primera fase IKE establece una Asociación de Seguridad ISAKMP (ISAKMP SA). En la segunda, esta SA es utilizada para negociar y establecer las SA propias de la comunicación IPSec (IPSec SA).


58

La autenticación de la primera fase puede estar basada en claves precompartidas (PSK), claves RSA y Certificados X.509. En esta etapa se pueden utilizar dos modos para la autenticación y establecimiento de la ISAKMP SA: modo principal o modo agresivo. Este último utiliza la mitad de los mensajes para lograrlo pero no brinda la protección de la identidad de los hosts intervenientes. Esto puede permitir un ataque del tipo “hombre del medio”.

En la segunda fase el protocolo intercambia propuestas de SA y las negocia en base a la ISAKMP SA, la cual brinda la autenticación y protege la operación de ataques del tipo mencionado anteriormente. Las SA negociadas finalmente son al menos dos, una para cada dirección de la comunicación.

Rendimiento

La utilización de IPSec en las comunicaciones requiere capacidad de procesamiento. En particular con ESP esta necesidad se evidencia en la encriptación y desencriptación de los paquetes, considerando la complejidad de los algoritmos empleados y en la autenticación de su encabezado, el agregado de este y de la cola al datagrama original.

Inclusive con AH el proceso de calcular un compendio en un extremo y la posterior verificación en el otro, son tareas mucho más complejas que el enrutamiento o la traducción de direcciones.

Las principales limitaciones no se originan en Internet, debido a que por naturaleza es un ambiente heterogéneo donde el transporte y entrega de las tramas implica una operación con el mejor esfuerzo y no asegura confiabilidad ni alta velocidad. De todas formas utilizando compresión previa a la encriptación puede mejorar el rendimiento.

Es el dispositivo o gateway de seguridad donde se ejecuta IPSec, quien es sensible a limitaciones que afectan la perfomance. Es importante que un gateway maneje un ancho de banda mayor al de la red a la cual se conecta, caso contrario deberá descartar paquetes provocando interrupciones en el tráfico afectando directamente los paquetes transportados mediante UDP e inclusive el tráfico TCP.

Otro aspecto que afecta la perfomance en un dispositivo es el retardo, o tiempo adicional de procesamiento en el equipo, previo a la salida del paquete. En la práctica se considera como asociado al tiempo en que tardan los datos en viajar desde el origen a su destino. En un dispositivo que cumple más de una función, incluyendo el procesamiento de IPSec, su retardo será importante. Es muy diferente procesar solo el encabezado (firewall de filtrado de paquetes) que sobre todo el datagrama completo con mecanismos de encriptado, sumado la carga u overhead del tratamiento e intercambio de claves, que requiere un uso intensivo del CPU.


59

2.5.2 Generic Routing Encapsulation protocol (GRE) El protocolo GRE o de encapsulación genérica de enrutamiento, es un

estándar de facto desarrollado por Cisco. Está diseñado para encapsular protocolos de capa de red arbitrarios dentro de otro protocolo de capa de red arbitrario15. Existen al menos tres RFCs referidas directamente con este protocolo, la RFC 1701 define en forma general el protocolo y el formato de su encabezado. La RFC 1702 refiere a su uso en conjunto con IP, tanto como protocolo de carga como de transporte. Finalmente la RFC 2784 es un memo que actualiza las anteriores, redefiniendo el formato del encabezado y definiendo como obsoletos a algunos de sus campos. Sin embargo deja establecido las operaciones con implementaciones anteriores. Esta sección se basa en la descripción del protocolo de acuerdo a esta última RFC pero con algunas referencias a las anteriores. En general GRE se ejecuta en la capa IP, utilizando datagramas IP como carga y como transporte16.

GRE crea un vínculo punto-a-punto con routers en cada extremo sobre una red IP. Se diferencia de IPSec en que maneja tráfico multicast. De hecho GRE se utiliza en conjunto con este protocolo para esta tarea debido a la naturaleza unicast de IPSec. La estructura general de un paquete GRE encapsulado para el envío es la siguiente:

Figura 2-22 Paquete GRE encapsulado

Cuando se usa IP como protocolo de carga y de entrega, los campos TTL, TOS y opciones de seguridad IP pueden ser copiados desde el paquete de carga a los mismos campos en el encabezado del paquete de entrega. El campo TTL del paquete de carga se decrementa cuando se desencapsula.

Cuando el extremo de egreso del túnel desencapsula un paquete GRE, el cual contiene un datagrama IP como carga, la dirección destino en el encabezado IP debe ser utilizado para reenviar dicho datagrama y el campo TTL debe ser decrementado. Si la dirección IP destino resultara ser del extremo que encapsuló, entonces deberá descartarse el datagrama para evitar un bucle o loop.

15 RFC 1701 - Generic Routing Encapsulation (GRE) 16 RFC 1702 - Generic Routing Encapsulation over IPv4 networks


60

Operaciones Conjuntas con otros protocolos

La utilización más común y simple de este protocolo, es la creación de túneles que permiten la utilización de un espacio de direcciones internas, a través de un espacio público de direccionamiento, para el tráfico de datos. Esto es posible por la capacidad de GRE de encapsular un datagrama IP y a su vez integrar la carga de otro datagrama IP que le permitirá atravesar una red IP hasta su destino.

La desventaja es que la carga que encapsula GRE no está en condiciones de atravesar una red insegura como Internet ya que los datos no están encriptados. Por lo tanto hace falta alguna medida de seguridad para poder utilizar GRE en un entorno VPN. Es en esta situación que se utiliza en conjunto con IPSec, el cual le suma la seguridad de sus mecanismos de encriptación y autenticación. Pero esta relación es bilateral, ya que IPSec falla en aquellos escenarios donde la naturaleza de las comunicaciones es del tipo multicast: propagación de la actualización de rutas en un entorno de enrutamiento dinámico, tráfico de voz y video, etc.

La manera de salvar este escollo es mediante la encapsulación del paquete multicast en un paquete GRE. A continuación este último, se encapsula en un paquete IPSec (Figura 2-23), para ser enviado a la red destino en forma segura, donde el extremo remoto del túnel IPSec, desencapsulará el paquete multicast y lo entregará a los dispositivos que integren el grupo multicast destino.

Utilizar GRE para crear túneles como mecanismo para una VPN, genera algunas desventajas principalmente asociadas a la carga en tareas de administración de la VPN, escalabilidad en cuanto al crecimiento del número de túneles, perfomance y QoS.

Debido a que los túneles GRE deben ser configurados en forma manual, existe una relación directa entre la cantidad de túneles a configurar y la cantidad de tarea administrativa necesaria para mantener dichos túneles. También la capacidad de procesamiento requerida para la encapsulación GRE, está en con el número de túneles configurados.

Figura 2-23 Encapsulamiento Multicast con GRE asegurado con IPSec


61

2.5.3 Multiprotocol Label Switching (MPLS) MPLS se dice multiprocolo porque se aplica a cualquier protocolo de

red, pero su uso más habitual es con el protocolo IP. La esencia de MPLS es la generación de pequeñas etiquetas (labels) de tamaño fijo que cumplen el rol de un encabezado IP pero con menos información. Esta etiqueta se usa para tomar las decisiones de enrutamiento del paquete. MPLS no es un protocolo de capa 2 ni de capa 3 específicamente, sino un protocolo que funciona en conjunto con estos.

En un mecanismo de enrutamiento convencional, cada router que recibe un paquete, verifica el encabezado IP (la dirección destino) para decidir el siguiente salto. Esta decisión es tomada en forma independiente por cada router basado en su análisis del encabezado del paquete y de los resultados de ejecutar algoritmos de enrutamiento. Esto se denomina enrutamiento salto a salto (hop by hop routing).

La selección del siguiente salto se compone de dos funciones. La primera consiste en clasificar o particionar el conjunto completo de paquetes en clases de equivalencia, también denominadas FEC (Forwarding Equivalence Class). La segunda función mapea cada FEC con el siguiente salto. Los paquetes pertenecerán a una determinada FEC, si la dirección IP destino de cada uno de ellos coincide, en la manera más exacta, con algún prefijo de red existente en la tabla de enrutamiento de ese router. A medida que el paquete atraviesa la red, cada router en su camino lo reexamina y vuelve a realizar este proceso.

En MPLS, la asignación de un determinado paquete a una determinada FEC es realizado solo una vez, en el momento que el paquete ingresa a la red MPLS. La FEC es codificada como un valor de longitud fija denominada etiqueta. Cuando el paquete es reenviado se envía la etiqueta también la cual es utilizada para indexar una tabla donde figura el siguiente salto y una nueva etiqueta. Luego de reemplazarla, el paquete es reenviado al siguiente salto. Cuando el paquete alcanza el último router de la red MPLS, este se encarga de remover la etiqueta y enrutar a través de los algoritmos convencionales.

Los routers dentro de una red MPLS se denominan LSR (Label Switched Routers). Aquellos que se ubican en el ingreso a y egreso de la red, se denominan LER (Label Edge Router) o dispositivos de borde. Estos últimos son los encargados de encapsular el paquete, mientras que los routers pertenecientes al núcleo de la red MPLS, solo se encargan de reenviarlo hasta el router de borde de egreso de la red.

Este método de reenvío permite que, una vez que el paquete fue clasificado en una FEC, no se efectúe ningún análisis posterior del encabezado por parte de los routers que participarán en el transporte del paquete.

VPNS BGP/MPLS

Una de las aplicaciones mas utilizadas de MPLS es el servicio de VPN provisto por un proveedor. Esta es una alternativa viable respecto de los métodos de túneles habituales para implementar VPN.


62

No existe un modelo de servicio de VPN único ya que cada cliente tiene diversos requerimientos, por ejemplo, pueden diferir en los requisitos de seguridad, cantidad de sitios a interconectar, números de usuarios, complejidad en el esquema de enrutamiento, aplicaciones críticas, volúmenes de tráfico, patrones de tráfico, habilidad del propio personal de networking, etc.

Existen dos opciones: VPN MPLS de capa 3 o capa 2. Uno de los modelos de mayor aceptación por parte de los proveedores para poder manejar esta variabilidad de requerimientos, es el propuesto en la RFC 2547 y RFC 2547bis VPN BGP/MPLS. Se trata de una VPN MPLS de capa 3.

Este modelo define un mecanismo que permite a los proveedores de servicios utilizar su red backbone IP para dar servicio VPN a sus clientes. El protocolo de enrutamiento de borde BGP (Border Gateway Protocol) es utilizado para distribuir información de enrutamiento de la VPN a través del backbone mientras que MPLS se encarga de reenviar el tráfico de la VPN entre los sitios que la componen.

Las VPN BGP/MPLS buscan cumplir con lo siguiente:

Facilidad de uso para los clientes

Escalabilidad y flexibilidad para facilitar implementaciones a gran escala.

Soporte de direcciones IP globalmente únicas en la red del cliente y solapamiento de direcciones privadas.

Soporte de solapamiento de VPN, es decir que un sitio puede pertenecer a más de una VPN.

Las VPNs BGP/MPLS toman un datagrama IP de la red del cliente, determinan la dirección IP destino buscando en una tabla de reenvío y luego envían ese datagrama hacia su destino a través de la red del proveedor mediante un LSP.

2.6 PROTOCOLOS DE TÚNEL CAPA 4 Además de los protocolos de capa 2 y capa 3, se pueden considerar,

además, dos protocolos para crear túneles pero en las capas superiores. En particular entre la capa de transporte y de aplicación. Se describirán las generalidades de SSH (Secure Shell) y SSL/TLS (Secure SocketsLayer)/ (Transport Layer Security).

2.6.1 Secure Shell (SSH) Secure Shell17 es un protocolo cliente-servidor que permite el

servicio de login remoto seguro a través de una red insegura. Si bien su cometido principal es la creación de una sesión remota mediante un túnel a un equipo remoto, es posible la transmisión de otra clase de tráfico TCP mediante la redirección de puertos.

17 RFC 4251 - The Secure Shell (SSH) Protocol Architecture


63

Este protocolo consiste de tres componentes principales:

Protocolo de capa de transporte: brinda autenticación del servidor, confidencialidad e integridad con PFS (Perfect Forward Secrecy) ejecutándose sobre la conexión TCP/IP.

El protocolo de autenticación del cliente: opera sobre el protocolo de transporte.

Protocolo de conexión: multiplexa el túnel en varios canales lógicos y se ejecuta sobre el protocolo anterior.

SSH utiliza, en un principio, autenticación basada en host para autenticar el servidor. Este procedimiento es llevado a cabo por la capa de transporte de SSH. Durante esta etapa se utilizan claves públicas de host (host key)18. Esta capa no realiza la autenticación basada en usuario, la cual es relegada a las capas superiores.

Este procedimiento requiere que el cliente confíe en la clave que le presenta el servidor. Para esto el cliente puede tener un conocimiento previo de la misma y efectuar una comparación, mediante algún mecanismo de firma o encriptación de un hash o certificando la validez de la misma a través de una Autoridad Certificante o CA.

Si bien la segunda alternativa facilita la administración del mapeo nombre de servidor/clave pública, requiere la presencia de una infraestructura PKI (Public Key Infraestructure), la cual no es simple de implementar e implica costos económicos importantes para la organización.

El protocolo de capa de transporte de SSH, es el encargado de autenticar el servidor y negociar el método de intercambio de clave, los algoritmos de encriptación simétrica, de clave pública, de autenticación de mensaje (HMAC) y de hash. El método de intercambio de claves es importante ya que define como generar las claves de sesión a utilizar en la conexión para encriptar y firmar digitalmente, además de establecer como autenticar al servidor.

El protocolo de capa de autenticación de SSH19 se encarga de efectuar la autenticación basada en usuario. SSH soporta autenticación basada en usuario mediante clave pública, passwords y basada en equipo. En el caso de usar passwords, estas son encriptadas cuando el paquete de autenticación es procesado por la capa inferior de transporte. La autenticación basada en equipo o host, consiste en verificar la identidad del host desde donde el usuario se conecta, junto con la existencia del nombre de usuario. El cliente firma un mensaje con su clave privada y el servidor la verifica con la clave pública del cliente. Luego se verifica que el nombre de usuario enviado por el cliente tenga autorización. Este método no es aconsejable en escenarios que requieran seguridad.

18 RFC4253 The Secure Shell (SSH) Transport Layer Protocol 19 RFC 4252 SSH Authentication Protocol


64

Finalmente el protocolo de capa de conexión se ejecuta por encima de los protocolos de transporte y autenticación de SSH. Brinda sesiones interactivas de login, ejecución remota de comandos, reenvío de tráfico TCP/IP y de conexiones del servicio de manejo de ventanas X11. Todo estas conexiones son establecidas mediante canales que son multiplexados a través de un único túnel establecido por el protocolo de capa de transporte, a esto se lo denomina multiplexación ascendente20 (upward multiplexing).

2.6.2 Secure Sockets Layer/Transport Layer Security (SSL/TLS) SSL fue creado originalmente para asegurar el tráfico web, pero se

utiliza también para asegurar protocolos diferentes a HTTP. Brinda confidencialidad a la capa de transporte mediante el uso de criptografía simétrica mientras que la autenticación y manejo de claves se realiza mediante la criptografía de clave pública.

TLS21 esta basado en la versión 3 de SSL, pero no es el mismo protocolo. Se trata de un estándar sobre el cual se basan implementaciones tantos comerciales como abiertas. Brinda privacidad e integridad a los datos transmitidos en una comunicación entre dos aplicaciones.

La interoperabilidad de SSL/TLS es muy alta, no es común los problemas en la interacción entre clientes y servidores de diferentes fabricantes. Dado que no se utiliza el encabezado IP para el procesamiento, sino la conexión autenticada y establecida, SSL/TLS no es afectado por la presencia de dispositivos que efectúen operaciones de traducción de direcciones o NAT.

SSL/TLS soporta una variedad de métodos de autenticación, siendo el más común el uso de certificados digitales para la autenticación tanto del servidor como del cliente (opcional).

Las VPNs SSL pueden transportar cualquier tráfico TCP inclusive tráfico UDP. Debido a que SSL/TLS es un servicio de la capa de transporte, una VPN SSL puede aplicar control de acceso a nivel de aplicación y por supuesto de transporte.

A diferencia de IPSec, el cual es un proceso que se ejecuta en modo kernel o privilegiado, SSL es un protocolo que se ejecuta como proceso a nivel de usuario. Esta característica hace que una solución VPN SSL sea más estable y robusta. Cuando existe una dependencia directa con el sistema operativo, cualquier falla del proceso puede generar inestabilidad a todo el sistema.

2.7 TOPOLOGÍAS La topología aplicada a las redes de datos, describe las relaciones

entre los componentes de una red. Su aplicación más simple define como se interconectan los dispositivos que integran una red. Además, el uso correcto de la terminología topológica evita confusiones cuando se hace referencia a esquemas de redes.

20 Data & Computer Communications Cap. 2 – William Stallings 21 RFC 4346 - The Transport Layer Security (TLS) Protocol Version 1.1


65

La clasificación más básica de las topologías está en función de la naturaleza de la relación de conectividad de los componentes de la red. Puede ser de naturaleza física como un medio de transmisión (cable tecnología ethernet, fibra óptica, enlace satelital etc.) o de naturaleza lógica, como la ruta que utiliza un flujo de bytes para conectar dos host. En este caso se considerarán las topologías desde una perspectiva lógica, debido a que las redes privadas virtuales son un objeto lógico, tal como se las define en el primer capítulo.

Lo más importante al estudiar la topología de una red es el impacto de esta sobre otros aspectos que influyen en el desempeño de la misma. Uno de estos aspectos es la escalabilidad la cual es crítica cuando se trata de redes que tienden a crecer o que el número de nodos a interconectar es numeroso y variable. La escalabilidad de una red se puede definir en función de tres características de su diseño22:

Capacidad de manejar mas conexiones

Facilidad de mantenimiento

Costo

En el caso particular de las VPN, existen otros aspectos que están influenciados por la topología: el mecanismo de distribución de claves para la autenticación de los nodos y la distribución de la información de enrutamiento necesaria para permitir la comunicación entre los componentes de una misma VPN.

2.7.1 Escenarios En el terreno de las redes privadas virtuales existen básicamente

tres escenarios que describen las relaciones entre los nodos de una VPN. Las conexiones entre sitios o redes, la conexión entre un host y una red y la conexión entre solo un par de hosts.

El escenario red a red (Figura 2-24) presenta la conexión de dos o más subredes mediante uno o más túneles. Cada subred consiste de un gateway y al menos un host. EL gateway posee dos interfaces de red, una para conectarse al túnel y la restante para conectarse con la subred interna. El gateway realiza el proceso de creación y eliminación del túnel, así cómo la aplicación de mecanismos de seguridad al tráfico que reenvía.

22 Kolesnikov, Hatch, Davis, Mongol - Building Linux VPN: VPN Fundamentals - Cap 2


66

Figura 2-24 Escenario Red a Red

El escenario host a red (Figura 2-25) se puede considerar un caso especial del anterior donde una de las partes, en lugar de ser una red, es solo un host y no hay presencia de un gateway. Este esquema se aprecia en las VPN de acceso remoto, donde los usuarios de una organización se encuentran físicamente alejados de su lugar de trabajo, pero pueden acceder remotamente a los recursos de la red de datos local.

Figura 2-25 Escenario Host a Red

Finalmente en el esquema host a host solo dos equipos podrán establecer una comunicación segura. Este escenario es una reducción del caso host a red. Si hubiera necesidad de comunicar más hosts, entonces serían más apropiados los escenarios anteriores.

Estas formas de relación determinan los esquemas topológicos más habituales en el mundo de las redes: punto a punto, punto multipunto, estrella (hub and spokes) y malla total o parcial (full or partial mesh), aunque también es posible combinar alguna de ellas e implementar una topología híbrida. Su aplicación a las VPNs posee sus ventajas y desventajas.


67

2.7.2 Topología Punto a Punto Esta es la topología más simple, ya que es una conexión directa

entre dos entidades. Esta relación de conectividad directa aún es válida si en un nivel inferior existen entidades cuya tarea es el reenvío de la comunicación hasta llegar al destino. Es decir, es una comunicación directa en la capa N aún cuando en la capa N-1 es necesario atravesar varios nodos hasta llegar al destino23.

Esta topología se puede encontrar en VPNs, como casos particulares de otros esquemas más complejos, como en el caso de la estrella (hub and spoke), donde cada extremo (spoke) tiene un enlace punto a punto con el centro (hub) para poder comunicarse con los demás extremos.

Los ejemplos mas simples de VPNs con esta topología son las tradicionales de capa de enlace basadas en servicios ATM o Frame Relay, ya que establecen una conexión punto a punto entre sitios de una organización. También se puede considerar los túneles de capa de red basados en IP que se crean con el mismo fin y conectan dos dispositivos CE, utilizando IPSec o GRE.

Un caso más específico es el servicio VPWS (Virtual Private Wire Service). Se trata de un tipo de VPN de capa 2 provista por el proveedor. Este brinda un servicio de conectividad punto a punto entre los sitios de un cliente. Este servicio emula enlaces dedicados entre los sitios mediante túneles IP dentro del backbone del proveedor, manteniendo a la vez la infraestructura ATM o Frame Relay existente del cliente. Una forma de realizarlo es utilizando los circuitos virtuales (CV) Frame Relay o ATM entre los dispositivos CE del cliente y PE del proveedor y mapearlos a túneles MPLS (LSP) establecidos a través del backbone.

Esta solución presenta problemas de escalabilidad cuando el proveedor tiene que servir varias VPNs, ya que cada LSP deberá ser configurado individualmente y mapeado a cada CV de los clientes. Esto conlleva un gran esfuerzo de administración, además el aumento de los túneles LSP para satisfacer nuevas demandas impactará en la capacidad del manejo de estos en los routers y switchs del proveedor, tanto los equipos de borde (PE) como los pertenecientes al núcleo del backbone (P).

Una mejora al enfoque anterior es el denominado PWE3 (Pseudowire Emulation Edge-to-Edge) VPWS, como lo muestra la Figura 2-26. En esta situación se mejora la escalabilidad utilizando un número fijo de LSP entre los dispositivos PE del backbone del proveedor. Luego se crean conexiones emuladas punto a punto (pseudowires) entre los PE mediante túneles basados en los LSP ya establecidos. Estas conexiones simuladas son encapsulaciones de protocolos de capa 2 (ATM, Frame Relay, Ethernet, etc.) en tramas MPLS24. Nuevamente es necesario que cada pseudowire sea configurado en forma individual, afectando la escalabilidad cuando el proveedor sirve varias VPNs. Sin embargo se reduce la carga de procesamiento a solo los routers de borde ya que únicamente en estos se definen los pseudowires.

23 Designing Addressing Architectures for Routing & Switching – Howard Berkowitz, Cap. 2 24 draft-ietf-pwe3-atm-encap; draft-ietf-pwe3-frame-relay; draft-ietf-pwe3-ethernet-encap.


68

Figura 2-26 Punto a Punto en VPN VPWS

Para mejorar la escalabilidad, se requiere que las conexiones punto a punto se establezcan mediante un mecanismo automatizado, como por ejemplo el protocolo BGP. En esta situación cada dispositivo PE usa BGP multiprotocolo para anunciar las VPN y dispositivos CE que este controla. Esta información acompaña las etiquetas MPLS utilizadas por los PE para reenviarse datos entre sí. De esta forma, cuando los CE reciben esta información, poseen los datos necesarios para crear los pseudowires25 sobre los PE.

2.7.3 Topología Punto a Multipunto Esta topología permite establecer más de un camino desde un lugar a

múltiples destinos. Cualquier transmisión de datos, originados en un punto de conexión central es recibida por todos los puntos de conexión periféricos, mientras que la comunicación en el otro sentido, desde la periferia, sólo es recibida por el extremo central.

El servicio de VPN de capa de enlace VPLS (Virtual Private LAN Service) brinda un servicio multipunto mediante una configuración de malla completa. Una VPLS es establecida por un proveedor de servicios y emula una LAN tradicional. Permite conectar varios segmentos de LAN, distantes geográficamente, sobre una red de conmutación de paquetes de manera que las redes remotas se comporten como una única LAN. En esta situación los equipos CE no deben seleccionar el pseudowire para reenviar los datos para un destino determinado (topología punto a punto); simplemente reenvían todo el tráfico al dispositivo PE del proveedor, quien se encarga de enviarlo al destino correspondiente.

25 draft-kompella-ppvpn-l2vpn


69

Esto es posible en redes MPLS donde se establece una topología de malla completa de pseudowires entre los dispositivos PE del proveedor que integran una determinada VPLS. Gracias a este esquema los PE pueden realizar replicación de paquetes (inundación por destino desconocido, broadcast, multicast) y aprendizaje de direcciones MACs tal como lo haría un bridge o switch ethernet.

Para simplificar la configuración de una VPLS, son necesarios mecanismos automáticos para obtener información de los integrantes de la VPLS, como llegar hacia ellos y conectarse finalmente. Esto facilita también el agregado de nuevos nodos y la administración de las conexiones (manejo de pseudowires) entre ellos. De lo contrario el manejo y escalabilidad de la VPN se vería afectada.

2.7.4 Topología Estrella (Hub and Spokes) Esta es la topología más común en VPNs. Existe un gateway VPN o

concentrador (hub) y una serie de clientes (spokes) que establecen una conexión punto a punto con este, un túnel de hecho. Para que pueda existir comunicación entre los clientes remotos, el tráfico de datos deberá ir desde el cliente emisor hasta el concentrador, luego este retransmitirá esos datos hacia el cliente receptor. No existe una conexión directa entre los clientes, toda la comunicación deberá atravesar primero el concentrador.

Esta topología afecta la escalabilidad en cuanto a que está limitada al desempeño y la capacidad de procesamiento del concentrador. Este deberá soportar conexiones simultáneas. Por esta razón el desempeño general de la VPN dependerá fundamentalmente de la capacidad del concentrador. Por otro lado este esquema presenta un único punto de falla en el concentrador mismo. La disponibilidad de la VPN dependerá de la falla de solo uno de sus componentes. Otra desventaja que presenta es que si dos clientes remotos se encuentran geográficamente cerca, igual deberán enviar su tráfico al concentrador en lugar de utilizar una conexión directa entre ellos.

Sin embargo, este esquema tiene la ventaja de una administración centralizada, respecto del monitoreo, mantenimiento, control de accesos, registro de eventos. Además el hecho de agregar un nuevo componente a la VPN es simple debido a que esta operación se centraliza en el hub.

Una forma de paliar la desventaja que significa un único punto de falla, es una variación de la topología donde exista más de un concentrador, tanto para brindar redundancia como para balancear la carga relacionada con las conexiones simultáneas de los clientes. Existe un esquema donde se busca la redundancia pero en el lado del cliente, duplicando el componente spoke. Esto permite el balanceo del tráfico emitido desde el cliente a través de la duplicación de la conexión con el concentrador. Si bien esta organización brinda la máxima disponibilidad, es prohibitiva en términos de costo en equipos y en la poca conveniencia de invertir recursos en el extremo del cliente.

Esta topología y sus variantes se aplican en los escenarios red a red, tanto para conectar los sitios de una misma organización como así también cuando se implementan VPN extranets con sitios de otras organizaciones.


70

Las VPN sitio a sitio utilizando IPSec son un ejemplo de la aplicación de esta topología. Es común considerar el uso del protocolo GRE para permitir el tráfico multicast entre los sitios de la VPN. En este caso particular, existen una serie de aspectos relacionados con la escalabilidad debido al protocolo IPSec:

Escalabilidad SA (Asociaciones de Seguridad): se refiere al número de asociaciones de seguridad activas a soportar, así como su detección, eliminación y manejo. Esto es un aspecto importante en el concentrador y no en el cliente. El primero debe mantener una base de datos de SA relacionadas con la conectividad de todos los clientes.

Capacidad de túneles IPSec: Las políticas de seguridad que se aplican pueden impactar en la perfomance del concentrador. La selección de algoritmos criptográficos fuertes lleva a una sobrecarga de la capacidad de cómputo. Hay que balancear el requerimiento de la política y la carga en el mantenimiento de los túneles con un cálculo apropiado de las necesidades futuras de agregaciones de nodos clientes a la VPN.

Capacidad de procesamiento criptográfico: este aspecto esta relacionado directamente con el anterior, en términos del throughput de paquetes por segundo que es capaz de procesar el módulo de encriptación.

Capacidad de mantenimiento de túneles GRE: Si bien la mayoría de los dispositivos VPN soportan los túneles GRE, no lo implementan a nivel de hardware. Si se requiere esta encapsulación, la misma no deberá limitar el throughput o el procesamiento en el concentrador.

2.7.5 Topología de Malla Completa o Parcial (Full or Partial Mesh)

En un diseño de malla completa (full mesh), cada dispositivo se comunica en forma directa con todos los demás. En el caso de malla parcial (partial mesh) solo ciertos dispositivos tienen conexión directa entre sí. La razón de ello radica en que no todos requieren más de una conexión. Solo aquellos que requieren alta disponibilidad y que la interrupción de una de sus conexiones no deje al sitio incomunicado con el resto.

Este modelo tiene varios beneficios y una gran desventaja. Los beneficios son:

No existe un único punto de falla, los dispositivos no dependen de un concentrador para la comunicación dentro de la VPN

La perfomance general no está limitada a un solo sistema.

Aquellos dispositivos que están próximos geográficamente, pueden comunicarse directamente sin intermediario.


71

La desventaja radica en el incremento del mantenimiento en cuanto a la distribución de las claves para asegurar las comunicaciones o en la distribución de información de enrutamiento. En particular si se usa IPSec, la creación de asociaciones de seguridad necesarias para cada nodo que se sume a la VPN representa un costo en el mantenimiento. La situación puede mejorar si se utilizan métodos automáticos para la distribución de claves, o la transmisión dinámica de rutas.

Nuevamente los escenarios red a red implementan esta topología cuando hay un requerimiento de alta disponibilidad o bien sea necesario un servicio multipunto como en el caso de las VPLS, donde se crea una topología de malla completa de pseudowires entre los dispositivos PE del proveedor y así los dispositivos del cliente pueden llegar mediante multicast o broadcast hacia las otras redes integrantes de la misma VPLS.


72

CAPÍTULO 3 VPNs DE ACCESO REMOTO

3


73

3.1 INTRODUCCIÓN En un principio el acceso remoto se caracterizaba por la utilización

de la red de telefonía urbana, mediante líneas discadas, para conectarse hacia la red de datos de la organización. El usuario pertenecía a esta organización. Estas conexiones se establecían desde la ubicación del usuario hasta el servidor RAS. Los protocolos utilizados se basaban en PPP y las funciones AAA es decir Autenticación, Autorización y Auditoría, estaban a cargo de un servicio específico como RADIUS.

Se asumía que la infraestructura de comunicaciones por donde se prestaba el servicio de acceso era relativamente segura y por ende no significaba un entorno hostil que amenazara la confidencialidad ni la integridad de la comunicación. Teniendo en cuenta esto, la seguridad de la conexión estaba limitada respecto del control de acceso en el RAS, a un par usuario/contraseña.

En la actualidad, las tecnologías de acceso a Internet mediante ISP, como un servicio dial-up o DSL, poseen carácter masivo y relativamente barato para los usuarios, brindando un servicio por demás adecuado para reemplazar los accesos discados directos que podían ser extremadamente caros si el usuario remoto se encontraba fuera de los límites del sistema de telefonía local. Sin embargo el inconveniente es la naturaleza pública por ende insegura de Internet.

Figura 3-1 Escenario General

El escenario de las VPN de acceso remoto puede ser definido en general de forma única (Figura 3-1) si bien hay variaciones particulares del mismo. En cualquiera de los casos, un cliente desea conectarse en forma segura a una red remota y poder tener acceso a los recursos disponibles en la misma. Para esto deberá establecer una conexión con un gateway de seguridad o servidor de acceso remoto, para luego configurar un túnel por donde fluirán los datos de la comunicación en forma segura.

Esta comunicación generalmente se establece desde una red corporativa diferente a la red destino. Es habitual la utilización de la red de un proveedor de servicios de Internet o ISP (Internet Service Provider) con una conexión dial-up o DSL, donde es posible la presencia de dispositivos intermedios que conectan varias redes entre el cliente remoto y el gateway de seguridad.


74

3.1.1 Requerimientos básicos de seguridad Existen requerimientos básicos en cuanto a la seguridad, los que

pueden ser clasificados en: autenticación de los extremos de la conexión, configuración de la política de seguridad (control de acceso y autorización) y auditoría.

Autenticación de los extremos

Existen dos clases de autenticación: la autenticación del origen de datos y la autenticación de la entidad. En el primer caso se asegura que los paquetes de red se originan desde un único sistema, host, usuario o aplicación, mientras que en el segundo caso se asegura que quien genera dichos paquetes, es quien dice ser.

Ambos tipos de autenticación se relacionan entre sí, la autenticación del origen de datos depende de la autenticación de la entidad. Para asegurar que un paquete se origina en un host particular o que provenga realmente de la red en la cual reside el host, es necesario en principio, autenticar la entidad y luego asociar la información del origen de datos (IP, puerto, protocolo de transporte) a esta relación de confianza establecida por el proceso de autenticación.

La entidad autenticada puede ser un host, un usuario, o ambos. Por esta razón la autenticación puede ser a nivel de máquina o a nivel de usuario. Entre los mecanismos utilizados para este proceso se cuentan: clave compartida o PSK (Pre Shared Key), la firma digital con el uso de certificados, claves RSA (Rivest Shamir Adleman).

Autenticación a nivel de máquina/usuario

Cuando dos partes se comunican de manera segura, la fase inicial de ese proceso corresponde a la autenticación del cliente remoto y/o del servidor. En el caso de que el cliente posea las credenciales para intentar una autenticación y no requiera la participación de un usuario para poder utilizar dichas credenciales, la entidad autenticada será el dispositivo donde se encuentren almacenadas. El nivel de seguridad de este procedimiento dependerá de cuan fiable sea almacenar y utilizar las credenciales en el dispositivo.

Si se requiere la intervención de un usuario donde verifique algún criterio para tener acceso a las credenciales, el servidor no tendrá una certeza sobre la identidad de este. Para tenerla, son necesarias las credenciales de usuario.

La autenticación de usuario implica la presentación de alguna información de autenticación en forma directa hacia el servidor durante la fase de autenticación. Si el dispositivo desde donde el usuario esta intentando acceder no presenta sus propias credenciales, entonces la entidad autenticada será solo el usuario.

Para lograr autenticar ambas entidades, se requiere la interacción con el usuario mediante una entrada de datos. Esta puede o no complementar a las credenciales del dispositivo, por ejemplo el ingreso de una passphrase para desencriptar una clave privada contenida en el dispositivo. En el otro caso la entrada del usuario es independiente de las credenciales almacenadas allí.


75

En general los requerimientos de autenticación son asimétricos. Desde la perspectiva del cliente es importante asegurarse que el servidor, en el otro extremo, sea realmente quien dice ser. Es decir es necesaria una autenticación a nivel de máquina.

Desde la perspectiva del servidor la situación es un poco diferente. Es importante determinar que la entidad en este extremo sea la autorizada y no un programa malicioso o alguien no autorizado que esté utilizando un dispositivo de la organización. Autenticar a un usuario requiere alguna forma de entrada por parte de este para el envío de credenciales y este mecanismo debería ser renovado periódicamente. Este último aspecto debería ser un equilibrio entre el intervalo de renovación (lo que puede ser molesto para el usuario) y el riesgo real de compromiso de las credenciales. En este caso es aconsejable el uso de sistemas de claves de uso único u OTP (One Time Password).

Este no es el caso cuando se trata de equipamiento provisto por la organización al usuario móvil. Se asume que el dispositivo es confiable porque, como equipamiento de la organización, cumple con las políticas de seguridad de la misma y tendrá el software necesario, tanto el cliente VPN como antivirus, firewall y demás herramientas de seguridad instaladas y actualizadas que el staff de administración, con los privilegios correspondientes, se encargaron de incorporar al equipo.

3.1.2 Configuración de las políticas de seguridad Es posible configurar políticas de acceso tanto en el cliente remoto

como en el gateway de seguridad. En el primer caso se puede considerar que el acceso a Internet desde el cliente, también se redirija a través del túnel con la red de la organización, evitando que el tráfico HTTP lo haga por redes inseguras.

En cuanto a políticas aplicables al gateway de seguridad, se puede establecer la asignación dinámica de permisos de acuerdo al usuario o sistema que establece la conexión. Este esquema puede valerse de un mapeo uno a uno, respecto de la dirección IP origen de la conexión y los permisos correspondientes. Una alternativa más escalable sería asociar una serie de permisos a un conjunto o rango de direcciones.

3.1.3 Auditoría La auditoría se refiere a la recolección de información de estado de

las conexiones dirigidas al gateway de seguridad por parte de los clientes remotos. El propósito de esta operación es mantener la seguridad e integridad de la red destino de la organización. Desde una perspectiva de la seguridad, es de utilidad tener el registro del tiempo de inicio y fin de una conexión.

Es necesario un método para monitorear el tiempo de conexión de los clientes y poder manejar los casos en donde estos finalicen su conexión en forma no explícita. Para estas situaciones se utiliza un mecanismo de heartbeat por el cual el cliente remoto envía una señal luego de un tiempo para indicar al gateway que aún se mantiene en línea. Pasado un tiempo (umbral de reset), sin recibir una nueva señal por parte del cliente, el gateway da por finalizada la conexión.


76

El intervalo de heartbeat puede influir en forma negativa si es demasiado corto. Si se presenta congestión en la red, es probable que se pierdan algunos paquetes de heartbeat del cliente y el gateway finalice la conexión al alcanzar el umbral de reset rápidamente. Ambos parámetros deberían poder ser ajustados mediante configuración o durante la negociación de la conexión.

3.2 ESCENARIOS Existen escenarios comunes en las VPNs de acceso remoto:

Tele trabajadores/usuarios móviles operando dispositivos propios

Acceso con un dispositivo local a la red local desde una extranet

Acceso desde una extranet con un dispositivo de esta a la red local

Acceso de usuarios móviles desde dispositivos públicos

Las diferencias se aprecian en los requerimientos básicos de seguridad que se necesitan cumplir en cada escenario.

3.2.1 Tele trabajadores/usuarios móviles operando dispositivos propios

Este escenario presenta a usuarios de una organización que se encuentran fuera de los límites de esta y requieren acceso a la red de datos. Estos pueden estar en sus casas o en un sitio geográficamente distante. En cualquier caso estos usuarios están operando equipos de la organización o personales, en este último caso deben cumplir con las políticas de seguridad.

El usuario utiliza la red pública y la de un ISP para establecer la conexión. Para el caso del gateway VPN, éste debe autenticarse a nivel de equipo, lo cual es suficiente. En cuanto al cliente es recomendable la autenticación a nivel de usuario. Para el caso de conexiones permanentes es conveniente la renovación periódica de las credenciales del usuario. Esto puede ser opcional en el caso de conexiones discadas de corta duración.

En términos de políticas de seguridad aplicable al cliente, se destaca el hecho de que si el cliente tiene acceso a Internet, entonces también es posible un acceso recíproco desde Internet hacia el cliente, todo esto mientras esta conectado a la red local de la organización. Es recomendable desestimar el acceso a Internet mientras se utilice el acceso VPN. Como alternativa se puede derivar el tráfico hacia y desde Internet a través del túnel de la VPN donde podría estar sujeto a la aplicación de alguna política de seguridad. Otra opción sería aplicar esa política directamente en el cliente para el tráfico Internet sin requerir la derivación de ese flujo hacia la red local.


77

3.2.2 Acceso con un dispositivo propio a la red local desde una extranet

En esta situación, hay una extranet establecida. La extranet puede reunir dos o más redes diferentes cuyo control administrativo es independiente en cada caso. Este escenario plantea el caso de usuario y su notebook perteneciente la red corporativa A funcionado en la red de B. Dada la relación entre ambas corporaciones, por la cual se generó tal extranet, el usuario de la red A se encuentra trabajando en la red corporativa B con su portátil. Su intención es conectarse a su red local.

Aquí los requerimientos de autenticación en el cliente son a nivel de usuario ya que es necesario asegurar que quien inició la conexión sea el mismo usuario activo durante todo el tiempo que dure la misma. Es recomendable la doble autenticación, tanto a nivel de máquina como de usuario. Cualquiera sea el caso, la autenticación deberá ser renovada frecuentemente. El gateway o servidor VPN deberá realizar la autenticación a nivel de máquina.

Si bien el dispositivo pertenece a la corporación A, no se le puede aplicar la política para derivar todo su tráfico hacia la red de pertenencia ya que se encuentra en los dominios de la red B y de hecho posee su configuración de red. Hay que tener en cuenta que, dada la naturaleza de este escenario, la notebook necesitará interactuar con los recursos de B. Puede estar sujeto a estas restricciones el tráfico hacia y desde Internet.

3.2.3 Acceso desde una extranet con un dispositivo propio de esta, a la red local

Este es un caso similar al anterior, con la excepción que el dispositivo es externo a la red destino, esta fuera del control de esta. Nuevamente el tipo de autenticación más importante debe ser a nivel de usuario ya que a nivel de máquina es difícil de determinar el nivel de confianza sobre el equipo. Las credenciales del usuario deben renovarse periódicamente.

3.2.4 Acceso de usuarios móviles desde dispositivos públicos Los dispositivos de acceso son públicos y no están bajo el control

de la organización. En el caso donde el dispositivo utilizado no sea propio o no pertenezca a la organización, por ejemplo un usuario remoto móvil operando una PC en un cyber café, la autenticación a nivel de dispositivo del cliente carece de sentido. Tampoco es aconsejable el uso de claves estáticas, ya que pueden ser capturadas mediante un programa de captura de teclas instalado en dicha PC, aún cuando se este utilizando un smartcard que almacene las credenciales de usuario.

Existe otro inconveniente en este escenario. Al no estar la PC bajo el control de la organización, no es posible que el cliente pueda verificar los datos del servidor o gateway VPN con el cual desea conectarse. Es imposible el almacenamiento seguro de información que permita autenticar al servidor, previo a la conexión, por ejemplo una clave precompartida (su uso no es aconsejable) o un certificado de clave pública de la CA que emitió el certificado del gateway.


78

Esta información se incorpora al dispositivo al momento de la instalación de un software cliente VPN. Esta operación suele requerir privilegios de administrador, por lo que sería difícil realizarlo con un dispositivo público. Peor es la situación donde sí es posible hacerlo, porque si se obtienen privilegios para la instalación del cliente se tiene que asumir que un programa malicioso también los tendrá.

En este escenario se aplican soluciones, que si bien no son verdaderas VPNs, el mercado ha forzado a que se las considere como tales (Web VPNs). El uso del protocolo SSL, presente en la mayoría de los clientes web o navegadores, permite un acceso seguro muy limitado, únicamente a aplicaciones basadas en este protocolo. Esto requiere de un mecanismo de proxy reverso que permita el manejo de las peticiones, considerando además unos mecanismos de autenticación.

Como complemento a este acceso limitado se puede implementar lo que se conoce como un sistema de Evaluación y Validación de la Seguridad del Extremo (Endpoint Security Posture Assessment and Validation) que permite analizar el estado del dispositivo remoto y determinar cuan confiable es para permitirle la conexión. Esto se logra buscando virus o programas maliciosos mediante un análisis en el dispositivo remoto, determinando si su SO esta actualizado y si tiene software de seguridad activo y actualizado. Si cumple con el nivel de confianza esperado se le permite la conexión, caso contrario se impide el acceso.

Se considera imprudente la utilización de esta clase de dispositivos si no se tiene un nivel de certeza respecto de la confiabilidad del mismo. Este escenario no es el adecuado para tener un acceso completo a la red local mediante la VPN, debido a las limitaciones del entorno respecto a la integridad del proceso de autenticación, tanto a nivel de dispositivo como de usuario.

3.3 ARQUITECTURA DE SEGURIDAD Cuando desde la propia red local se interactúa con equipos presentes

en redes externas como extranets, o públicas como Internet, se accede a un entorno fuera del control de la organización, por lo tanto inseguro.

Permitir interactuar equipos situados en estos entornos con los propios de la organización es un panorama aún más crítico que requiere tener presente la seguridad considerando:

Las políticas de seguridad de la organización y definir su aplicación tanto a los clientes como al servidor VPN.

Definir claramente los servicios de la red local que estarán disponibles para los usuarios remotos.

Control del tráfico entrante y saliente.

Un adecuado manejo del servicio de autenticación de los usuarios remotos.

Una correcta disposición del gateway VPN en el esquema de la red junto con una adecuada interacción con el firewal.


79

El nivel de hardening, o cuan seguro es el gateway VPN si este se ubica directamente en el borde de la red.

Mantener un sistema de auditoría que registre los eventos asociados a los accesos a la VPN.

Asegurar la disponibilidad del servicio de VPN de acceso remoto

3.3.1 Gateway VPN y Firewall, seguridad en la frontera Un firewall es una combinación de hardware y software utilizado para

implementar una política de seguridad que controla el tráfico de datos entre dos o más redes. La política se aplica solamente sobre la red o redes que están bajo el control de la organización26.

Al conjunto formado por la red o redes incluidas en el alcance de la política se lo denomina dominio de seguridad. Es necesario tener claro los límites de este dominio para evaluar en forma correcta la aplicación de la política.

La intersección con otros dominios es el escenario donde se requiere la presencia de un firewall, es decir en el borde o frontera de la red de la organización.

Un gateway o servidor VPN permite el acceso a usuarios remotos ubicados fuera del dominio de seguridad de la organización, como Internet, la red de un proveedor u otra red perteneciente a un dominio de seguridad diferente. Por esta razón deberá estar ubicado en el mismo ámbito que el firewall. En general el gateway VPN es parte del conjunto de herramientas y tecnologías que brindan seguridad a la red de la organización.

Existen diferentes topologías relacionadas con la ubicación del gateway VPN, en la mayoría de ellas es aconsejable el diseño basado en DMZ (Demilitarized Zone) o zona desmilitarizada, ya que brinda mayor seguridad a la red interna.

Una DMZ es una red donde se ubican los equipos que brindan los servicios públicos de una organización. Estos son accedidos desde el exterior, por esta razón deben estar separados de la red local de la organización. La DMZ es una red aislada de la red interna mediante un firewall que se encarga de proteger ésta última y los equipos en la DMZ. Para lograr esta separación cuenta con al menos tres interfases de red: para la red externa, la DMZ y la red interna.

Gateway VPN sobre el Firewall

La solución más natural y simple es la implementación del servidor VPN en el mismo dispositivo donde funciona el firewall. Es habitual en dispositivos firewall comerciales, los cuales incluyen funcionalidad de gateway VPN en sus productos, por ejemplo CISCO en su línea de productos firewall ASA PIX.

Este diseño permite tener un único punto de entrada a la red de la organización, donde el firewall autoriza las conexiones salientes hacia el exterior, previene las conexiones entrantes no autorizadas hacia el interior y la función de gateway VPN es administrar las conexiones de los usuarios remotos, autorizando su acceso y encriptando su tráfico.

26 Deploying Firewalls Fithen,Allen,Stoner - Carnige Mellon University


80

Las ventajas de este esquema son:

Centraliza el control de toda la seguridad, con lo que se disminuye el costo de administración.

La interacción Firewall-Gateway VPN es natural y directa, lo que facilita la creación dinámica de reglas del firewall aplicadas al tráfico VPN.

Menos equipamiento.

Figura 3-2 Gateway VPN sobre el Firewall

Las desventajas son:

Único punto de falla.

El protocolo de túnel no es transparente al firewall.

Una configuración incorrecta de las reglas del firewall podrían permitir el acceso, a través del espacio de direcciones de la VPN, de tráfico no permitido.

Competencia de recursos de hardware a causa del procesamiento por parte de los dos servicio. Se requiere un equipo potente en CPU y memoria.

Escalabilidad limitada si el dispositivo no soporta el agregado de módulos para des/encriptar. Si se incrementa la cantidad de clientes remotos, el punto anterior será más evidente.

Costo de entrenamiento para un uso adecuado del dispositivo, si se trata de una solución propietaria.


81

Gateway VPN y Firewall en paralelo

Como en el diseño anterior los servicios se sitúan separados físicamente en diferentes equipos, pero esta vez la separación del procesamiento es completa. Este esquema se basa en una DMZ estándar donde ambos dispositivos tienen acceso a la red interna y a la red externa, estableciéndose una zona buffer entre el gateway predeterminado de la red local, el firewall y el Gateway VPN.

Las ventajas son:

Procesamiento en paralelo de tráfico específico sobre los dispositivos correspondientes. Se desliga completamente al firewall de atender el tráfico relacionado con la VPN.

Mejor escalabilidad respecto del crecimiento de usuarios remotos. Se puede agregar mas servidores VPN y distribuir la carga.

No hay un único punto de falla.

No se requiere procesamiento NAT en el gateway VPN ni en el firewall.

Figura 3-3 Esquema en paralelo


82


El servidor VPN esta conectado directamente a la red externa. Debe configurarse cuidadosamente (hardening) para evitar que sea comprometido.

Configurar cuidadosamente ambos equipos para evitar el flujo de tráfico no permitido.

Incremento en el costo de administración y mantenimiento de las configuraciones.

Mayor costo económico por la adquisición de equipos

Este diseño se basa en una DMZ tradicional, donde el dispositivo que separa la red local es un router de filtrado de paquetes, lo cual lo hace un esquema poco seguro.

Dependiendo del nivel de seguridad que brinda el servidor VPN, es recomendable ubicar antes o después de éste un firewall dedicado para asegurar el tráfico entrante VPN antes de alcanzar la red interna. Esta alternativa agrega una demora en el procesamiento de los datos y requiere compatibilidad con el protocolo de túnel.

Gateway VPN integrado a DMZ única

El gateway VPN se ejecuta en un dispositivo separado del firewall, una de sus interfaces se conecta a la red externa mientras que la restante se conecta a la única DMZ compartida con el firewall.

En este caso el tráfico VPN es atendido por el Gateway VPN y es filtrado por el firewall a través las interfaces de ambos equipos en la DMZ, para finalmente reenviarlo a la red local interna. Este es un diseño simple y muy seguro, por lo tanto el más adecuado.

Las ventajas son:

Distribución del procesamiento del tráfico entrante, el gateway se encarga estrictamente del tráfico VPN.

Menor configuración relacionada al tráfico VPN en el firewall.

Mayor seguridad al tráfico de la VPN que llega a la red interna.

El tráfico VPN puede ser analizado para prevenir ataques en su paso por la interfaz de la DMZ del firewall.

El procesamiento del tráfico VPN, en el firewall, es independiente del protocolo de túnel utilizado y no se requiere procesamiento NAT.


83

Figura 3-4 Gateway VPN con DMZ única


El servidor VPN esta conectado directamente a la red externa. Debe configurarse cuidadosamente (hardening) para evitar que sea comprometido.

El firewall representa un único punto de falla.

Gateway VPN y Firewall con doble DMZ

Este es un esquema de máxima seguridad aplicado al gateway VPN. Se utilizan dos DMZ para separar el flujo entrante y saliente de la VPN. Nuevamente los servicios se encuentran en dispositivos separados, pero solo el firewall se conecta a la red externa. Este filtra el flujo VPN entrante y saliente a través de dos DMZ establecidas.

Este esquema, si bien es muy seguro, agrega demora al procesamiento del tráfico ya que se requiere atravesar dos redes además del doble análisis por parte del firewall, sin embargo el tráfico VPN entrante a la red interna es confiable.

Las ventajas son:

Acceso remoto hacia la red interna es muy seguro.

Separación del flujo VPN entrante y saliente, lo que permite aplicarle reglas de control de forma más específica.


84

Figura 3-5 Uso de una doble DMZ


Doble procesamiento del tráfico VPN, proveniente de los clientes remotos mediante la DMZ Outside y de la red interna a través de la DMZ Inside.

El firewall es dependiente del protocolo de túnel, al menos durante el procesamiento en su interfaz conectada en la DMZ Outside.

Alto costo administrativo de la configuración

3.3.2 Disponibilidad El servicio de acceso remoto en una organización representa un valor

activo de la misma, ya que permite un mejor desarrollo de las actividades de sus integrantes. Muchas veces más que por una razón de eficiencia es por una necesidad estratégica, en concordancia con los objetivos que persigue la organización. Es decir, la presencia de tal recurso tiene un fundamento y cumple con un requerimiento importante de la organización.

Es en este marco que asegurar la disponibilidad del servicio de acceso remoto es un aspecto a considerar. La disponibilidad o Alta disponibilidad o HA (High Availability) de una VPN de acceso remoto está en función de los costos que puede asumir la organización ya que implementar HA no es barato.


85

Hay tres esquemas reconocidos que se utilizan para este fin los cuales son de naturaleza local, es decir se aplican donde se encuentra el gateway VPN. Estos se basan en el concepto de failover, que significa la capacidad de cambiar o delegar el control en forma automática a un dispositivo o equipo redundante para que tome el manejo del servicio o función para la cual se implementó este mecanismo.

Los esquemas usados para alta disponibilidad son:

Host standby failover: en este esquema hay dos servidores VPN, uno de los cuales esta inactivo (host standby) respecto de su función, mientras que el restante está operando como tal. Ante la falla de este último se activa y toma el control el segundo servidor. Para que esto suceda deben existir ciertos mecanismos como protocolos para failover y sincronización entre las unidades de la información de las sesiones VPN de manera de minimizar la interrupción durante el failover.

Active-active failover: en este caso ambas unidades están operando y manejando el tráfico. Mediante el protocolo de failover se monitorea el estado de ambos equipos. Dado que ambos equipos están operando la falla de uno de ellos activará el mecanismo de failover sin interrumpir el servicio.

Mutiunit clustering: similar al esquema anterior pero con más de dos unidades. Si bien se utiliza para brindar alta disponibilidad, su cometido principal es mejorar la escalabilidad. Este esquema ofrece redundancia y balanceo de carga cuando aumenta el número de clientes remotos. Esta solución es la más costosa y requiere entrenamiento del personal para una correcta administración.

Figura 3-6 Alta disponibilidad con Failover Activo


86

Figura 3-7 Alta disponibilidad mediante un Cluster

3.3.3 Autenticación, Autorización y Registro (AAA) El manejo efectivo de los usuarios VPN y de sus privilegios de

acceso es vital en cualquier diseño de VPN de acceso remoto. Existen dos aspectos principales a considerar:

Una solución segura y escalable para autenticar usuarios

Decisiones basadas en atributos de usuario y de seguridad para definir los permisos de acceso.

La tecnología AAA permite establecer un esquema de seguridad dinámico respecto del control de acceso. En la actualidad existe una gran variedad de mecanismos que permiten autenticar a un usuario, de hecho los protocolos de VPN se caracterizan por esto. Además es necesaria la asignación de privilegios en forma dinámica de acuerdo al rol del usuario que intenta acceder remotamente.

Además de validar al usuario, el proceso de autenticación permite asignar al usuario a una política de grupo. Esta asignación se realiza en base a la información de grupo del usuario en la organización y a otros atributos. Esta política de grupo define los privilegios de acceso del usuario para la fase de autorización.

Dentro de los protocolos AAA reconocidos está RADIUS cuyas especificaciones aparecen en la RFC 2058. Éste posee la condición de protocolo estándar por la IETF27. TACACS es otro conocido protocolo AAA desarrollado por CISCO. Obviamente se trata de una alternativa propietaria, que se encuentra y utilizan, por defecto, todos los dispositivos de este fabricante.

27 Internet Engineering Task Force: Comunidad pública internacional cuyo objetivo es el

mejoramiento constante de Internet. Su misión se documenta en la RFC-3935.


87

Componentes Principales

Dentro de una arquitectura AAA existen componentes que interactúan entre sí. Esta distinción no refiere a dispositivos físicos dedicados sino a contenedores lógicos de funciones, los cuales suelen estar combinados:

Cliente: es quien intenta acceder a la red y autenticarse a si mismo o servir como medio para autenticar al usuario que lo utiliza.

Punto de Aplicación de Política (PEP): también denominado autenticador. En este caso se trata del gateway VPN, procesa la solicitud de acceso del cliente y se encarga de aplicar las restricciones al acceso del cliente.

Punto de Información de Política (PIP): es un repositorio de información que ayuda a tomar la decisión de permitir o no el acceso. Se trata de cualquier sistema que almacene datos relevantes respecto del dispositivo o usuario que requiere acceso. Por ejemplo servidor LDAP, OTP token server etc.

Punto de Decisión de Política (PDP): es el componente principal de la arquitectura que toma la decisión de permitir o no el acceso. Este recibe la solicitud de acceso del cliente a través del PEP. También consulta al PIP para obtener información necesaria para tomar la decisión. También puede enviar al PEP información específica para la autorización del cliente para que el PEP aplique las restricciones en los privilegios de acceso correspondientes.

Sistema de Registro y Autenticación: este componente registra los diferentes eventos relacionados con el acceso de los clientes remotos. Además permite generar reportes que relacionan estos eventos para describir el comportamiento de la VPN. Este puede funcionar en un dispositivo dedicado o ser parte del PDP.

Servidores de autenticación

El diseño de un sistema AAA varía dependiendo del tamaño de la red y de la disparidad de métodos de acceso que se requieran. En general las opciones para servidores de autenticación pueden dividirse en dos categorías:

Servidor AAA dedicado ejecutando RADIUS: en este caso el servidor AAA es la interfase entre el gateway VPN (PEP) y el servidor de identidad (PIP), servidor LDAP, servidor de Token OTP, Active Directory. Esta interacción es mediante el protocolo RADIUS. Esta es una solución flexible ya que el propio protocolo soporta la interacción con una gran variedad de métodos de acceso.


88

Gateway VPN interactuando con un PIP: en esta situación depende del gateway interactuar con el servidor de identidad o PIP, por lo tanto deberá soportar la interacción con diferentes tipos de servidores de identificación. Un aspecto a tener en cuenta con este modelo es la capacidad del gateway para obtener información adicional del cliente o usuario para aplicarlo a la fase de autorización. Soportar esta característica requiere una mayor dependencia entre el gateway y el PIP.

3.3.4 Administración y monitoreo La administración y monitoreo del servicio de VPN son aspectos

importantes a considerar, simplemente porque permiten a los administradores manejar y conocer el estado del servicio además de su impacto en la red local. Esto se aplica en forma general para todas las VPNs, no solo a las de acceso remoto.

Como contrapartida a la importancia de estas actividades, esta el costo que representa para la organización cumplir con estas. Esto en términos de equipamiento y el entrenamiento necesario del personal administrativo. En el escenario general de VPNs, este es el principal motivo para tener que decidir por un servicio provisto por un proveedor o por la misma organización.

El monitoreo permite establecer una línea base para referencia de futuras mediciones y determinar cuando las condiciones son las normales y cuando se presentan casos atípicos que representan problemas que deberían generar una alarma. La administración requiere tener las herramientas necesarias para el cumplimiento de tareas relacionadas al manejo de usuarios, clientes VPN y del servidor VPN.

La capacidad de administración y monitoreo va a depender de las herramientas y utilidades que provea la solución implementada.

El monitoreo en una VPN de acceso remoto implica determinar el estado del gateway VPN y las sesiones establecidas de los usuarios. Entre los parámetros de importancia a monitorear se pueden distinguir:

Respecto del gateway:

Utilización del Ancho de Banda.

Estadísticas de las interfaces públicas y privadas (Outside vs. Inside).

Uso del CPU.

Troughtput respecto de cantidad de sesiones en un período de tiempo.

Respecto de las sesiones de usuario

Ranking de usuarios con mayor actividad en un período de tiempo respecto de:

o Throughput

o Duración de la conexión

o Tráfico total (Inbound+Outbound)

o Períodos de tiempo de mayor actividad.


89

Intento Fallidos de conexiones.

3.4 PROTOCOLOS En los escenarios de acceso remoto se destacan algunos protocolos de

túnel tanto de capa 2, 3 y 4. En el capítulo 2 se han descrito la mayoría de ellos, en particular L2TP, L2F y PPTP de capa 2, mientras que de capa 3 se ha mencionado IPSec y en capa 4 SSH y SSL.

En la actualidad los más destacados en función de las soluciones VPN existentes son IPSec y SSL. Sin embargo el protocolo SSH o Secure Shell permite establecer un túnel que se utiliza para acceso remoto. SSH solo transporta tráfico correspondiente a aplicaciones basadas en TCP.

A continuación se describirán los protocolos SSH, IPSec y SSL mencionando los aspectos más importantes de cada uno, desde una perspectiva global de implementación para una VPN de acceso remoto.

3.4.1 SSH Lo más destacado del uso de SSH es la posibilidad de brindar un

canal seguro a aquellos protocolos TCP que no lo son, como los protocolos de correo electrónico o de terminal remota. A esta funcionalidad se la conoce como reenvío de puertos (port forwarding).

El concepto es desviar el tráfico asociado a un puerto de una conexión, hacia un puerto manejado por SSH y transportarlo a través del túnel SSH hacia el otro extremo en forma encriptada. Es necesario un cliente y un servidor SSH con una cuenta de usuario válida para el cliente. Existen dos clases de reenvío de puertos: local y remoto. Estos son establecidos por el cliente SSH.

Reenvío Local de Puerto (Local Port Forwarding)

También denominado túnel saliente, reenvía el tráfico que llega a un puerto local en el cliente, hacia un puerto remoto ubicado en el servidor. Es necesario que el cliente pueda registrarse en el servidor mediante un usuario válido, por lo tanto el tráfico SSH hacia el servidor deberá estar permitido. Esto habilita el acceso a puertos no disponibles en forma directa. La sintaxis del comando SSH para esta funcionalidad es:

ssh –L local_port:remote_host:remote_port [username]@ssh_server

Este comando reenvía el tráfico destinado a local_port hacia el remote_port del remote_host luego de la conexión y autenticación en ssh_server. En general remote_host se refiere al propio ssh_server, pero no siempre es así. Existen situaciones donde remote_host es otro equipo en la misma red que ssh_server y donde se ejecuta la aplicación cuyo puerto de conexión es remote_port. En esta circunstancia, ssh_server es el intermediario de la conexión entre el cliente SSH y remote_host. Es importante aclarar que esta última parte de la conexión es realizada sin encriptación.

Un ejemplo práctico del reenvío local de puertos es la conexión al servicio de correo electrónico mediante un túnel SSH para brindar seguridad al proceso de autenticación POP3. La Figura 3-8, ilustra la situación de un usuario móvil conectándose a su red local en forma remota mediante SSH para procesar su correo electrónico en forma segura.


90

Figura 3-8 SSH Reenvío Local de puerto

En la red local existe un servidor SSH y un servidor de correo electrónico, ambos ejecutándose en equipos diferentes pero en la misma red. El usuario remoto se autentica en el servidor SSH con una cuenta de usuario válida y ejecuta en su cliente el comando para reenviar el tráfico POP3 mediante el túnel SSH. A continuación el usuario mediante su aplicación de correo electrónico o MUA (Mail User Agent) se conecta en forma local al puerto 1110 donde el tráfico POP3 será manejado por el cliente SSH y transportado por el túnel hasta el servidor SSH remoto.

En el otro extremo, el servidor SSH reenvía el tráfico del cliente hacia el servidor de correo, esta última conexión no es encriptada. El servidor de correo responde al servidor SSH el cual reenvía la respuesta al cliente SSH. Esto es posible si las políticas de seguridad de la organización permiten establecer conexiones SSH desde el exterior hacia algún gateway de la red local.

Reenvío Remoto de Puerto (Remote Port Forwarding)

Denominado también túnel entrante, reenvía el tráfico que arriba a un puerto remoto en el servidor, hacia un host y puerto local específico en el cliente, (Figura 3-9). Para esto el cliente inicia una conexión SSH con el servidor mediante el comando:

ssh –R remote_port:local_host:local_port [username]@ssh_server

Este comando conecta y establece una sesión con el servidor SSH utilizando username y solicita redireccionar el tráfico que arribe a remote_port de ssh_server hacia local_port en local_host. Este esquema habilita el acceso desde el exterior hacia algún servicio interno en local_host mediante ssh_server como intermediario. Para que esto funcione, ssh_server deberá ejecutar un proceso que escuche en remote_port.


91

Figura 3-9 SSH reenvío Remoto de puerto

Como un ejemplo considerar el servicio de control remoto o VNC, que permite el control remoto de un equipo. Éste utiliza el puerto TCP 5900, con lo cual el comando SSH para el reenvío remoto solicita que todo el tráfico que arribe al puerto remoto 5900 en ssh_server se reenvíe al equipo local al mismo puerto.

ssh –R 5900:pc_a_controlar:5900 user@ssh_server

Allí estará funcionado el servidor VNC propio del equipo a controlar. El administrador remoto deberá ejecutar el visor VNC desde su equipo y entonces podrá visualizar el escritorio de la PC a controlar. Esto es posible si las políticas de seguridad de la organización permiten establecer conexiones SHH hacia el exterior.

En la práctica utilizar SSH requiere conocimiento por parte del usuario para configurar un acceso remoto. Sin embargo existen herramientas que facilitan su utilización mediante interfaces gráficas. Es una herramienta útil en situaciones donde el acceso remoto es una excepción y se realiza bajo determinadas condiciones, como por ejemplo la presencia de un servidor SSH, políticas de seguridad de la organización que permitan los tipos de conexiones necesarias. Por lo general es utilizado por los administradores de redes para el acceso remoto, pero no como una solución corporativa para el grueso de los usuarios móviles de la misma. Tampoco es una solución escalable, dado que es necesaria la instalación del software SSH en cada cliente y la configuración manual de la conexión con sus particularidades en cada uno de ellos.

3.4.2 IPSec Las VPN IPSec extienden el perímetro de seguridad de una red

permitiendo la conexión de hosts individuales o redes enteras. Una VPN segura verifica la identidad de los extremos del túnel.

A diferencia de las VPN red a red utilizando IPSec, las de acceso remoto requieren mayor consideración respecto de la autenticación de las partes que se comunican, en general para evitar establecer túneles con partes no autorizadas. En particular porque en este escenario, habrá muchos clientes intentando conectarse a los recursos de la red local de la organización. Además porque se tratan de conexiones temporales y el origen de red de las mismas varía con frecuencia.


92

Es importante considerar que en IPSec la autenticación precede el establecimiento del canal seguro por donde se llevará a cabo la comunicación entre las partes, por lo tanto, cualquier vulnerabilidad que pueda ser explotada en esta primera etapa, comprometerá el resto de la comunicación.

El protocolo IPSec encargado de realizar la autenticación de las partes es IKE. Este protocolo de intercambio de claves presenta dos fases en su operación, tres modos, una variedad de mecanismos para llevar a cabo la autenticación, pero más importante aún una nueva versión de este protocolo: IKEv228, la cual no es interoperable con IKEv1. De manera que son varios aspectos que hay que considerar para la implementación de una VPN IPSec de acceso remoto con mecanismos de autenticación seguros.

La primera versión de IKE es la más difundida entre los productos que implementan IPSec. Su forma de operación trae aparejado riesgos de seguridad si el mecanismo de autenticación utilizado no es el adecuado. La segunda versión, ya definida como estándar por el IETF es una mejora de la anterior poniendo énfasis en la solución a estos problemas. Actualmente se recomienda utilizar IKEv2 si se requiere implementar una VPN de acceso remoto IPSec por primera vez. En casos donde ya hubiera una VPN establecida, se recomienda utilizar los mecanismos de autenticación que eviten el ataque conocido como “hombre del medio”, como encriptación de clave pública y firma digital con uso de certificados.

El protocolo IKE se basa en la identificación de los pares que se conectan como parte del proceso de autenticación. Puede utilizar varios tipos estándar de identificación: dirección IP (Ipv4 e Ipv6), nombre del host FQDN (Fullly Qualified Domain Name), una dirección de correo electrónico, o un nombre distinguido DN (Distinguished Name) X.500 LDAP (Lightweight Directory Access Protocol). Estas identificaciones necesitan ser comprobadas, para esto se utilizan los métodos de autenticación.

Los identificadores de los pares pueden encriptarse o no, según el modo utilizado en la primera fase de IKE. En el modo agresivo el ID de los hosts se transmite en texto claro. Esto permite que esa información pueda ser capturada y manipulada para un ataque del tipo mencionado anteriormente. Por lo tanto una VPN de acceso remoto deberá usar el modo main de IKE el cual si encripta el ID de los hosts.

Por otro lado, deberá descartarse la autenticación mediante clave pre compartida (PSK) con el modo main, ya que esta combinación modo/método-autenticación, requiere usar como ID la dirección IP de quien inicia la conexión, en este caso el cliente remoto. Dado que se trata de clientes móviles, la dirección IP origen de estos es de naturaleza dinámica y puede variar durante una misma sesión.

28 RFC 4306 - Internet Key Exchange (IKEv2) Protocol


93

Tal como se menciona en la introducción de este capítulo, es muy importante en este escenario de VPN, implementar una doble autenticación para el cliente: basada en host y en usuario. Una desventaja de IKEv1 es la falta de este último tipo de autenticación. Si bien se han implementado extensiones a IKEv1 por algunos fabricantes, como la autenticación extendida (XAUTH) de Cisco, estas no han sido consideradas como estándares por parte de la IETF. Los gateways VPN que utilizan XAUTH solicitan al usuario un segundo login; si tiene éxito se continúa con la segunda fase de IKE que prepara la conexión IPSec, caso contrario se finaliza el intercambio IKE y no se lleva a cabo la conexión. Una alternativa a XAUTH es la encapsulación L2TP sobre IPSec, permitiendo la autenticación de un usuario mediante los mecanismos de L2TP basados en PPP.

IKEv2 fue desarrollado teniendo en cuenta esta desventaja y lograr resolverla. Introdujo en su diseño lo que se denomina mecanismos de autenticación heredados (legacy authentication); estos implementan la autenticación de un usuario sobre un servidor. Es el caso de los mecanismos de passwords e intercambios desafíos/respuestas (Challenge/response Authentication) (PAP/CHAP).En particular implementa los mecanismos definidos en la RFC 3748(Extensible Authentication Protocol).

Ambas versiones de IKE no son inter operables, por lo que si se decide utilizar la última versión sobre una estructura de VPN de acceso remoto ya existente, deberá migrarse todo el software IPSec de los componentes de la VPN por aquellas que contengan la versión 2 de IKE.

De acuerdo a la introducción de este capítulo una VPN IPSec de acceso remoto va a consistir de un servidor VPN y de varios clientes VPN que se conectarán al servidor. El servidor se ejecutará en un dispositivo de borde de la red de la organización. Puede hacerlo en el mismo firewall o bien en otro equipo.

Hay que considerar las políticas de seguridad de la organización y establecer en función de estas los parámetros necesarios para definir las políticas de seguridad IPSec (SP) a partir de las cuales se derivarán las asociaciones de seguridad de IKE (IKE SA) e IPSec (IPSec SA).

Estos parámetros tienen que ver con las direcciones IP de los hosts a los cuales se les brindará el servicio de seguridad, los puertos y protocolos a proteger y las Asociaciones de seguridad que efectivizarán el servicio, es decir que seguridad aplicar. Esto último implica determinar los algoritmos de autenticación, de encriptación, protocolo de seguridad, modo de operación a usar con esta política. Esta información se almacena en base de datos.

Como se mencionó en el capítulo anterior, existen dos clases de bases de datos: la referida a las políticas de seguridad (SPD) y la de asociaciones de seguridad (SAD). La primera especifica las políticas que determinan el tráfico entrante o saliente que debe ser asegurado, si bien todo el tráfico es procesado por el motor IPSec. La segunda contiene parámetros relacionados con cada asociación de seguridad activa, que indican cómo procesar y que servicio de seguridad aplicar.


94

Cuando un cliente remoto se conecta debe recibir información de configuración de red referente a la red de la organización destino de la conexión. Esto se puede lograr mediante la encapsulación L2TP sobre IPSec, donde los mecanismos PPP permite obtener la dirección IP local para el host remoto(PPP IPCP), sin embargo la información dinámica ofrecida es muy escasa y no es un mecanismo integrado a IPSec. Existe otro método que implementa IPSec, definido en la RFC 3456 que permite el intercambio de mensajes DHCP v4 luego de la fase dos de IKE o quick mode en modo túnel. Para esto el cliente define una asociación de seguridad DHCP (DHCP SA) la cual solo es utilizada para el intercambio de tráfico DHCP. Dicha SA puede ser eliminada o seguir siendo utilizada entre las partes.

3.4.3 SSL/TLS Dentro de las VPN SSL de acceso remoto, ha surgido la tendencia,

impuesto por el marketing de los fabricantes, de considerar los navegadores web con soporte SSL, como una solución VPN SSL sin cliente (clientless), refiriendo a que no es necesaria la presencia de software cliente VPN específico para la conexión. En realidad este esquema no representa realmente una VPN. Se trata de un sistema que implementa tanto un web proxy o un mecanismo de traducción de protocolos de aplicación (Application Traslation).

En el primer caso, existe un dispositivo servidor que actúa como intermediario entre los servicios destino y el cliente remoto. El proxy recibe la petición del cliente, la rescribe por completo y la envía al servidor destino. Antes del reenvío, el proxy puede analizar la correctitud del requerimiento en busca de solicitudes malformadas creadas con la intención de un ataque. La respuesta del servidor destino recorre el camino inverso, hacia el proxy primero y de allí al cliente. Toda la conexión se realiza en seguro bajo SSL. Este funcionamiento requiere que el proxy soporte los protocolos para los cuales va a operar.

En el segundo caso, un protocolo de aplicación se adapta o se traduce a HTTP y HTML para poder ser visualizado en un navegador. Este método se aplica sobre la base de protocolos individuales y es necesario un traductor por cada uno de estos, sin embargo este mecanismo no es aplicable a cualquier protocolo.

Una VPN SSL verdadera implica la presencia de un software cliente en el dispositivo que interactúe con el servidor para la creación de un túnel por el cual se transmite tráfico IP en forma segura. Los mecanismos anteriores no proveen esta clase de conectividad.

Existen soluciones VPN SSL verdaderas, donde el túnel creado permite la comunicación segura independientemente del protocolo de aplicación que se ejecute. Esto permite, si las políticas de seguridad lo disponen, acceso completo a la red destino. Sin embargo el mercado ha impuesto las soluciones clientless o semi-clientless como soluciones bajo la etiqueta de VPN SSL.

3.4.4 Comparativa de las tecnologías de acceso remoto Este cuadro presenta una comparación entre las tecnologías VPN de

acceso remoto de mayor uso en la actualidad. Cuando se considera implementar el servicio de acceso remoto las tecnologías a considerar son IPSec y SSL/TLS.


95

En particular la utilización de IPSec es anterior a la aplicación de SSL/TLS como protocolo para VPNs, principalmente en el contexto de un escenario sitio a sitio. IPSec se comenzó a utilizar para el acceso remoto, pero estaba limitado a la utilización de dispositivos bajo el control de la organización. SSL/TLS permitió salvar estas limitaciones de IPSec.

Los criterios utilizados describen en general las características (limitaciones y ventajas) presentes en estas tecnologías VPN, independiente de alguna solución particular.

Tabla 3-1 Comparativa de Tecnologías de Acceso Remoto

Criterios VPNs IPSec VPNs SSL/TLS

Escalabilidad Limitada Buena a Muy buena

Interoperabilidad Buena Muy Buena considerando el uso de navegadores web como clientes

Funcionalidad Acceso completo a la red o restringido

Aplicaciones Web, Aplicaciones

cliente/servidor Acceso completo a la red

o restringido,

Seguridad en la transmisión Muy Buena Muy Buena

Métodos de autenticación

Clave precompartida, Claves RSA, Certificados

digitales Doble autenticación nativa con IKEv2

Clave precompartida, Certificados Digitales,

Claves RSA Doble autenticación

Tipos de Dispositivos clientes soportados

Administrados por la organización

No administrados - Administrados

Soporte Multiprotocolo Nativo No, solo datagramas IP No, solo soporta

aplicaciones basadas en SSL

Capa de Operación Servicio de capa de Red Servicio de capa de transporte

Mecanismo de Acceso Túnel IP a nivel de capa de red

Proxy reverso con Encapsulamiento HTTP, Traductor de protocolo, Túnel IP en capa de red

Nivel de Soporte requerido Medio a Alto, según el

número de usuarios remotos

Bajo (considerando navegadores web como

clientes) a Alto

Soluciones Abiertas Si Si


96

Escalabilidad

Cuando la cantidad de usuarios remotos aumenta, se requiere mayor capacidad en el servidor VPN en cuanto al procesamiento para el manejo de más túneles y funciones de des/encriptación. En este caso ambas tecnologías se pueden valer de hardware especial para estas tareas.

En el lado de los clientes se incrementa el costo de administración del software cliente VPN si la solución lo utiliza. Desde esa perspectiva, la escalabilidad de IPSec es limitada. Las soluciones SSL/TLS basados en clientes web no poseen carga de mantenimiento y administración del software cliente. Teniendo en cuenta esto SSL/TLS posee mejor escalabilidad que IPSec. Sin embargo aquellas soluciones que posean clientes VPN para el acceso, tendrán una carga similar a IPSec.

Interoperabilidad

Las soluciones que implementan el mismo protocolo deberían poder comunicarse sin problemas, de lo contrario, éstas no podrán interoperar. Esto ha sucedido con soluciones VPN IPSec, en particular con la elección del mecanismo de autenticación de las partes. Sin embargo el consorcio VPN29 ha establecido pruebas de interoperabilidad, tanto para soluciones basadas en IPSec como en SSL, que permiten una mejor interacción entre soluciones de distintos fabricantes.

Las soluciones SSL/TLS no poseen estas limitaciones considerando la utilización de clientes web con soporte SSL

Funcionalidad

Este criterio se refiere a los recursos a los que puede tener acceso un usuario en forma remota. Las VPN IPSec pueden brindar acceso completo a nivel de red, excepto que se establezcan restricciones. En cambio, las VPN SSL/TLS permiten un acceso diferenciado según el modo de acceso. Se puede tener acceso solo a aplicaciones Web, o a aplicaciones cliente-servidor o bien a toda la red como IPSec.

Seguridad en la transmisión

Ambas tecnologías permiten un excelente nivel de seguridad en la transmisión de los datos. El servicio de confidencialidad se basa en una fuerte suite de algoritmos de encriptación, bien probados, utilizando protocolos como 3DES, AES, IDEA, algoritmos de hash y firma digital como RC4, SHA.

La autenticación puede estar basada en criptografía de clave pública mediante el uso de certificados digitales. En este caso IPSec se destaca por ser más estricto, ya que requiere que ambas partes posean un certificado que demuestre su identidad para poder usar el método. El diseño de SSL/TLS, en cambio, es más flexible en este punto, permitiendo que solo el servidor se autentique. De esta manera no cumple la característica de no repudio y es vulnerable a un ataque del tipo “hombre del medio”. Sin embargo, una buena solución VPN SSL/TLS, debería requerir la autenticación mediante certificados, de ambas partes.

29 http://www.vpnc.org


97

Otra característica es que ambos protocolos permiten definir una configuración a nivel criptográfica (algoritmos criptográficos permitidos, tamaños de claves, regeneración de claves, tiempos de vida de las claves, etc.) que se aplican como políticas a las conexiones según el nivel se seguridad requerido para cada caso.

Métodos de Autenticación

En general ambos protocolos brindan los mismos métodos de autenticación para los extremos o host. Esto es, el uso de certificados digitales, claves pre compartidas, claves RSA. Sin embargo en un escenario de acceso remoto, cobra importancia la autenticación del usuario que controla el dispositivo que se conecta, logrando una autenticación doble: dispositivo y usuario.

El diseño de SSL/TLS permite esto mediante el mecanismo más simple, pero menos seguro, de usuario/contraseña hasta métodos más complejos como OTP (One Time Password) o una infraestructura PKI que valide certificados de usuario. Por supuesto esta operación se realiza posterior al establecimiento de un canal seguro.

IPSec ofreció la posibilidad de la doble autenticación luego de la incorporación de las extensiones al protocolo IKE por parte de Cisco (XAUTH, HYBRID AUTH) luego de establecer el canal seguro. La nueva versión de IKE IKEv2 incorpora el soporte nativo de autenticación de usuario mediante EAP. Lamentablemente la nueva versión de IKE no es interoperable con su antecesora.

Tipos de dispositivos soportados

Aquí se marca una diferencia entre ambas tecnologías. El uso de IPSec requiere la instalación de un cliente VPN en el dispositivo móvil. Para esto es necesario instalar el software cliente, lo que significa hacerlo sobre un dispositivo confiable y seguro, de manera que su uso posterior para la conexión no represente una amenaza. Por lo tanto las VPN IPSec de acceso remoto requieren usar dispositivos bajo el control de la organización. Es impensable intentar esta operación sobe un equipo ajeno a la organización y por lo tanto no confiable.

Las VPN SSL/TLS marcaron su diferencia al incluir el uso de los dispositivos no confiables, limitando el acceso desde ellos hacia la red corporativa solo a aplicaciones web, mediante el uso de navegadores web con soporte SSL/TLS, encapsulando HTTP. Sin embargo si se requiere un acceso completo a la red es necesario, al igual que IPSec, instalar un software cliente y de igual manera, esto solo es posible sobre dispositivos confiables.

Soporte multiprotocolo nativo

Ninguno de los dos protocolos tienen soporte multiprocolo. Sin embargo esta capacidad se puede lograr, encapsulando otro protocolo como L2TP o PPP.


98

Mecanismos de accesos

Estos son los mecanismos que permiten el acceso de forma segura a la red corporativa. IPSec utiliza su protocolo ESP en modo túnel para encapsular datagramas IP. Este túnel IP es el medio de acceso. En el caso de SSL/TLS existen varias formas de acceder a la red. Utilizando un proxy HTTP reverso, para acceder a aplicaciones web, mediante traducción de protocolos permite acceder a servicios cuyos protocolos pueden traducirse y adaptarse a HTTP y lograr tunelizarlos, finalmente a través de un túnel IP al igual que IPSec.

Esto permite un control de acceso más granular para SSL/TL, es decir permite mecanismos de autorización más variados y no solo basarse en parámetros a nivel de red (IP origen, puerto destino etc.)

Nivel de soporte requerido

En el caso de IPSec es de medio a alto en función de la cantidad de usuarios remotos. Se tiene en cuenta la carga que representa la administración y mantenimiento de los clientes, las políticas de acceso y conjuntos de transformación. Esto es similar para SSL/TLS, pero a diferencia de IPSec, la posibilidad de implementar esquemas donde se utilice un navegador web como cliente de acceso, minimiza en gran medida la carga en la administración de los clientes.

Soluciones Abiertas

Ambas tecnologías han sido implementadas mediante soluciones abiertas y libres pero de gran calidad las cuales se desarrollaron para plataformas UNIX aunque algunas han sido portadas para su uso con Windows.

Entre las más conocidas están:

OpenVPN: solución VPN SSL/TLS que permite acceso completo a la red, desarrollada para LINUX. Existe la versión para WINDOWS.

Ipsec-tools30 : conjunto de utilidades para el manejo de la implementación de IPSec para el kernel de LINUX. Se basa en el proyecto KAME el cual tiene cumple con el mismo objetivo pero para FreeBSD. Entre las utilidades se encuentra el demonio IKE denominado Racoon y setkey una herramienta para el manejo de la base de políticas de seguridad y la base de asociaciones de seguridad.

StrongSwan31: Solución VPN basada en IPSec desarrollada para plataforma LINUX. Implementa el demonio IKE versión 2, además de la versión inicial.

30 http://ipsec-tools.sourceforge.net/ 31 http://www.strongswan.org/


99

3.5 SOLUCIONES VPNs DE ACCESO REMOTO El mercado de soluciones VPN de acceso remoto presenta una gran

variedad de alternativas en general provenientes de fabricantes muy relacionados con el ámbito de las redes y comunicaciones de datos, esto es: Cisco System, Check Point, Juniper Networks, Nortel, Sonic Wall, etc.

Muchas de estas propuestas son en realidad completas soluciones de alta complejidad para acceso remoto, lo cual implica el equipamiento de servidores VPN, el software de cliente VPN, software de administración del servicio y monitoreo, dispositivos móviles con cliente embebido etc. Sin embargo, existe un costo económico importante a la hora de elegir alguna de ellas, ya sea en la adquisición de la infraestructura como en la capacitación del personal.

Además de estas soluciones propietarias, existen alternativas abiertas y gratuitas, en particular orientadas a plataformas LINUX y FreeBSD aunque hay casos donde la solución se puede ejecutar también en Windows. También existen sistemas basados en una solución abierta pero embebidas o como una imagen de disco que se puede virtualizar o bien instalar en hardware dedicado con software de administración todo en uno, pero estas no son gratuitas32.

Una característica de las soluciones propietarias es la implementación como firmware de la lógica tanto del servidor VPN como de los clientes en un hardware dedicado para la tarea. Esto permite alcanzar buenos niveles de perfomance. Por el contrario las soluciones abiertas, en general, se basan en software.

La siguiente tabla muestra un conjunto de características básicas deseable que deberían poseer las soluciones VPNs de acceso remoto según la tecnología en la cual se basan. Este cuadro es una referencia que incluye requerimientos establecido por el consorcio VPN o VPNC (VPN Consortium) para alcanzar buenos niveles de interoperabilidad entre soluciones de distintos fabricantes.

32 http://www.endian.com, http://www.arrowdot.com


100

3.5.1 IPSEC

Cliente para Windows/Macintosh

Software IPSec Cliente para ejecutarse sobre un sistema monousuario WINDOWS/MACINTOSH.

Ecapsulamiento L2TP Ejecutar L2TP para autenticación y enrutamiento sobre un túnel IPSec

Soporte de certificados X.509 durante IKE

Uso de certificados de clave pública para autenticación.

Soporte de encriptación 3DES Soporte para fuerte encriptación Soporte Failover Soporte para la herencia de sesiones en forma

transparente para el usuario remoto , ante el fallo de algunos de los dispositivos funcionando como gateway VPN (disponibilidad)

Soporte de Clustering Habilidad para balancear la carga total de la VPN sobre varios nodos en un esquema de clustering presentando una única identidad para los usuarios remotos.

Soporte para Ipv6 Soporte para direccionamiento Ipv6. VPNC interoperabilidad básica Creación de un túnel IP con encriptación 3DES, SHA-

1 para hash, intercambio de claves de 1024 bits y PSK para autenticación.

VPNC interoperabilidad AES Uso de algoritmo AES con claves de 128 bits para encriptación.

VPNC interoperabilidad básica para IKEv2

Creación de un túnel IP mediante IKEv2 con AES para encriptación, SHA-1 para hash, intercambio de claves de 1024 bits y PSK para autenticación. La compatibilidad debe ser total con otras soluciones.

VPNC interoperabilidad Ipv6 Los sistemas deben interoperar sin problemas utilizando direcciones IPv6 con redes externas e internas

Interfaz de Administración y monitoreo

Herramientas y utilidades para facilitar la administración del servicio

Compresión IPPCP Uso de compresión estándar para el tráfico IPSec

Tabla 3-2 Características de soluciones IPSec


101

3.5.2 SSL/TLS Soporte LDAP Permite comunicarse con un servidor LDAP para

autenticar los usuarios remotos Soporte RADIUS Permite comunicarse con un servidor RADIUS para

autenticar los usuarios remotos Soporte certificados X.509 para usuarios

Permite utilizar certificados X.509 para autenticar usuarios remotos.

Soporte Failover Soporte para la herencia de sesiones en forma transparente para el usuario remoto, ante el fallo de algunos de los dispositivos funcionando como gateway VPN (disponibilidad)

Soporte de Clustering Habilidad para balancear la carga total de la VPN sobre varios nodos en un esquema de clustering presentando una única identidad para los usuarios remotos.

Acceso completo a la red mediante plugin SSL

Permite el acceso total a la red descargando un plugin para SSL que lo permita.

Endpoint Security Checking Soporte para verificación del nivel de seguridad del extremo remoto del cliente.

VPNC interoperabilidad SSL Portal

El gateway debe funcionar como portal para aplicaciones web permitiendo a los usuarios remotos el acceso a sitios web internos.

VPNC interoperabilidad SSL File Access

El gateway debe permitir la lectura y escritura en servidores CIFS33/SMB34 internos: Windows 2000 y 2003 Servers.

VPNC interoperabilidad SSL JAVA Script

El gateway debe funcionar como Portal con soporte de JAVA script para el acceso a aplicaciones internas.

Interfaz de Administración y monitoreo

Herramientas y utilidades para facilitar la administración del servicio

Tabla 3-3 características para soluciones SSL/TLS

El consorcio VPN reúne como sus miembros a importantes empresas destacadas en el ámbito del networking, entre ellas están: AEPNetworks, Certicom, Cisco Systems, D-Link, Encore Networks, IBM, Juniper Networks, Microsoft, Nokia, Nortel, SonicWALL, etc.

Una de sus tareas es establecer test de interoperabilidad para lograr un funcionamiento sin problemas entre soluciones de diferentes fabricantes. Los cuadros anteriores incluyen algunas de estas pruebas como requerimiento deseable. Sin embargo no se consideraron todas dado que las soluciones abiertas y aquellos sistemas basados en estas no integran este consorcio. Por otro lado, debido al carácter general y abarcativo de esta caracterización aplicable a cualquier solución VPN.

La selección de los criterios deseables fue definida a partir del análisis e investigación realizada para el desarrollo y elaboración de este capítulo y del resto del trabajo en general.

33 Common Internet Filesystem: Protocolo de dominio público para transferencia de archivos en

forma simple y potente

34 Server Message Block: Protocolo para compartir archivos, base de los sistemas de red LAN Manager y Microsoft Networking.


102

CAPÍTULO 4 TRABAJO PRÁCTICO

4


103

4.1 INTRODUCCIÓN Siempre se ha deseado tener la posibilidad de acceder a los

recursos corporativos de información y sistemas desde el hogar u otro punto geográfico de una manera sencilla; además de contar con las herramientas necesarias para el acceso. En el caso de un administrador, estas son las que permiten administrar los equipos y/o los sistemas de forma remota. En el caso de un usuario corriente, poder acceder a sus archivos o a su correo.

Actualmente esto se logra mediante las VPNs de acceso remoto, las cuales requieren la instalación de clientes VPNs en los equipos provistos a los usuarios móviles o tele trabajadores. Este proceso requiere una dependencia del software VPN cliente con el sistema operativo anfitrión.

La intención de este trabajo es lograr independizar el cliente VPN del sistema operativo anfitrión, no solo respecto de aspectos de compatibilidad entre sí sino también de los privilegios necesarios para la instalación de esta clase de aplicación.

A partir de esta idea la solución debe cumplir con las siguientes características:

Ser portable es decir que se pueda trasladar en un pendrive o una memoria flash convencional.

No requerir la instalación de software en el equipo anfitrión y no utilizarlo para guardar información.

No requerir permisos administrativos en el host anfitrión. Poder ejecutar la solución sobre la plataforma Windows por ser

la más popular. Tener acceso a la red sin restricciones, pero poder

establecerlas en forma dinámica si es necesario. Poder descargar un archivo ubicado en la red corporativa al

pendrive. Utilizar herramientas y utilidades Open Source.

Para cumplir estos requerimientos se propuso una solución mediante virtualización, además de brindar las herramientas necesarias para efectuar la conexión y el software específico para realizar las tareas. La Figura 4-1 muestra el diseño de la solución propuesta, donde se aprecia el túnel desde la aplicación virtualizada hasta el gateway VPN. Para esto se utiliza la conexión a Internet del equipo anfitrión. El extremo remoto del túnel termina en el gateway VPN el cual permite el acceso a la red local corporativa a los servicios disponibles.


104

Figura 4-1 Diseño de la solución

4.2 ALCANCES La solución propuesta está orientada principalmente a su uso

sobre equipos que estén bajo control y administración de la organización, lo cual establezca cierto nivel de seguridad respecto a la presencia de software malicioso.

No es una solución pensada para uso masivo por parte de los usuarios. El sistema operativo anfitrión donde se ejecutará la solución será Microsoft WINDOWS 2000, XP o Vista.

Es necesario hardware adecuado para ejecutar una virtualización en el host anfitrión. En particular capacidad de procesamiento. El pendrive o memoria flash deberá tener una capacidad de al menos 2GB.

Es necesario software para virtualización, es decir una máquina virtual que pueda ejecutarse en las versiones de WINDOWS mencionadas anteriormente.

La solución se implementará en la plataforma LINUX y utilizará el sistema OpenVPN35 para establecer la VPN.

La solución incluirá una aplicación externa a la virtualización que tendrá como cometido, transferir los archivos descargados en la aplicación virtualizada al pendrive, donde quedarán disponibles para su procesamiento posterior.

35 http://www.openvpn.org


105

Del lado del servidor, éste ejecutará el sistema OpenVPN en modo servidor y atenderá las conexiones de los usuarios. De acuerdo a ello establecerá en forma dinámica las restricciones para el acceso a la red.

4.3 FUNCIONAMIENTO La solución propuesta permite la conexión segura a la red

corporativa mediante un túnel SSL/TLS. La misma es efectuada por un usuario, el cual deberá autenticarse previamente en forma local, mediante un nombre de usuario y contraseña. Una vez autenticado ejecutará la aplicación que le permitirá establecer la conexión, habilitando el acceso a las aplicaciones según su rol o perfil.

4.3.1 Perfiles de usuarios Se implementan dos perfiles de usuarios, uno es el perfil del

usuario estándar que puede realizar ciertas tareas y otro es el de administrador. Este tendrá acceso total al resto de las aplicaciones, la mayoría de las cuales son de naturaleza administrativas. El gateway VPN que recibe la conexión genera las reglas en forma dinámica las cuales establecen las restricciones para ambos perfiles de usuario.

4.3.2 Esquema de validación Se definen dos etapas de autenticación. En la primera se

autentica el usuario localmente a través del sistema de validación de LINUX. Esto le permite ingresar al entorno de trabajo de la solución. La segunda etapa consiste en la validación del usuario respecto del Gateway VPN mediante certificado para establecer el túnel. Esto le permite el acceso a la red corporativa.

4.3.3 Servicios Los servicios que el usuario tendrá disponible una vez

autenticado y autorizado son los siguientes de acuerdo a su perfil:

Perfil Usuario:

Mail

Mensajería

SMB (Credenciales de sesión Windows)

FTP

Perfil Administrador:

Todas las anteriores

SSH

Escritorio Remoto (RDP/VNC)


106

4.3.4 Gateway VPN El servidor VPN implementado a través del sistema OpenVPN,

establecerá en forma dinámica las restricciones según el usuario que se conecte. Esto se logra mediante una opción en el archivo de configuración del servidor. Además es necesario crear un script para cada perfil donde se definen las restricciones a nivel de puertos TCP/UDP y a nivel de la dirección origen asignada al usuario.

4.4 TECNOLOGÍAS DE LA SOLUCIÓN El desarrollo de la solución requirió determinar que

herramientas eran necesarias para cumplir con las características establecidas. El componente más importante de la solución es la máquina virtual que permite la ejecución del cliente VPN.

Dado que el cliente se ejecuta en una plataforma LINUX, se analizó alternativas de distribuciones existentes además de considerar la creación de una propia. Lo siguiente fue considerar el desarrollo de la aplicación que controla la lógica del cliente y las aplicaciones necesarias para acceder a los servicios disponibles, además de la aplicación para la transferencias de archivos de la maquina virtual al pendrive. Para esto se evaluaron lenguajes de programación, distribuciones LINUX y entornos de virtualización.

4.4.1 Lenguajes de programación Las características deseables analizadas fueron:

Desarrollo rápido de entornos gráficos.

Soporte para el desarrollo de aplicaciones para networking.

Curva de aprendizaje de crecimiento rápido.

Confiabilidad (Antecedentes en la utilización en casos comprobables).

Soporte multiplataforma (LINUX, WINDOWS).

Perfomance.

Alternativas consideradas

Los lenguajes considerados fueron:

JAVA

PYTHON

RUBY

El lenguaje elegido fue PYTHON. Entre los motivos de la elección se consideraron la perfomance respecto de los demás, la posibilidad de correr aplicaciones sin requerir un entorno de ejecución, ni la instalación en el equipo anfitrión de bibliotecas o dependencias. También incidió la curva de aprendizaje rápido.


107

4.4.2 Entorno de virtualización Se tuvieron en cuenta las siguientes alternativas:

VIRTUALBOX

QEMU36

VMWARE

VIRTUALPC

VMWARE y VIRTUALPC no tienen una distribución que se pueda ejecutar desde un pendrive. Por su parte VIRTUALBOX esta basado en QEMU, posee un mejor rendimiento y existe una versión para ser ejecutada en un pendrive que no es oficial, pero es necesario contar con permisos administrativos para poder instalar una biblioteca de enlace dinámico y un proceso que le permita a la maquina virtual tener un mejor rendimiento.

La característica principal que determinó la elección de la máquina virtual QEMU es que se puede ejecutar en un pendrive sin el requerimiento de tener permisos de administrador sobre el equipo anfitrión. La limitación que presenta esta opción es su rendimiento ya que para mejorarlo, al igual que las demás soluciones, es necesaria la instalación de un módulo para optimización en el sistema operativo anfitrión y poseer privilegios de administrador para hacerlo.

Sin embargo, la perfomance de QEMU, lograda sin el módulo optimizador, en equipos con buena capacidad de procesamiento es aceptable permitiendo cumplir con la funcionalidad deseada.

4.4.3 Distribución LINUX La plataforma de ejecución de la aplicación es el sistema

LINUX. Esta elección se basa en sus características favorables en cuanto a la seguridad, estabilidad, robustez, disponibilidad del kernel del sistema operativo para adaptarlo a los requerimientos de la solución y finalmente por ser una base óptima para aplicaciones orientadas a las comunicaciones. Si bien el propósito no fue crear una mini distribución, se trató de minimizar, dentro de las posibilidades, las instalaciones realizadas.

Se evaluó la utilización de versiones básicas de distribuciones conocidas: DEBIAN y FEDORA. Dado que la solución se basa en una virtualización y además la alternativa elegida para esta tarea no posee un perfomance destacada, se decidió crear una distribución propia. Encarar esta tarea asegura la instalación de las herramientas mínimas para la funcionalidad deseada y sobre todo poseer un control más estricto sobre este proceso.

El método elegido para la creación se basó en el proyecto LINUX desde cero o LFS37 (LINUX From Scratch). Este consiste en cumplir una serie de etapas hasta lograr la distribución final. La versión de LFS utilizada fue la 6.3. Actualmente la versión estable es la 6.4.

36 http://www.nongnu.org/qemu/ 37 http://www.LINUXfromscratch.org


108

La primera etapa consiste en utilizar una distribución LINUX operativa como base para la creación del nuevo sistema, en este caso una DEBIAN Etch. En particular se seleccionó una partición disponible para la instalación del nuevo sistema. Luego se utilizó el LiveCD del proyecto LFS como sistema anfitrión, el cual provee las herramientas básicas necesarias y las fuentes de los programas que formarán la estructura del nuevo sistema.

Una vez elegida la partición, ésta se monta luego de iniciar el LiveCD. Éste además monta su propio sistema de archivo raíz donde se encuentra todo lo necesario para el proceso de creación.

La segunda etapa consiste en la creación de un sistema mínimo en la partición dedicada, que contendrá una cadena de herramientas (toolschain) necesarias para generar el sistema final. Esta cadena estará compuesta por un compilador, ensamblador, enlazador, bibliotecas y algunas utilidades. En principio se compilará cada una de éstas y luego serán utilizadas para compilar e instalar el resto de los paquetes.

La tercera etapa consiste en crear un entorno chroot o de jaula sobre la partición dedicada, y a partir de las herramientas generadas en la etapa anterior se dará forma al sistema final. Esto se logra mediante la compilación e instalación del resto de los paquetes utilizando el compilador, ensamblador, enlazador y bibliotecas de la cadena de herramientas. También es necesario la creación de los sistemas de archivos virtuales para el kernel (/dev, /proc, /sys), creación de la estructura de directorios del sistema de archivos raíz, enlaces dinámicos etc. Es decir instalar el sistema básico.

Luego de esto es necesario que el sistema pueda iniciar. Para esto se utilizó la herramienta mkbimage que permite crear una imagen de boot a partir de un sistema de archivos. En este caso se aplicó a la partición contenida en el chroot donde se compiló e instaló el sistema final. Esta imagen es la que utiliza la máquina virtual QEMU para ejecutar la solución propuesta.

En realidad, el proceso es más extenso. Lo anterior es solo un resumen general. Para más detalles y consideraciones es mejor acceder al sitio www.linuxfromscratch.org, donde LFS es una parte de un proyecto más ambicioso para la creación y personalización de una distribución LINUX.

Paquetes principales instalados

Luego de la creación de la distribución propia se fueron instalando las herramientas y aplicaciones necesarias y sus dependencias relacionadas con la solución. Este fue un proceso de descarga, compilación e instalación de cada una. Las aplicaciones principales son:

Kernel

Kernel 2.28.5

Desarrollo

PYTHON 2.5

Bibliotecas QT 4.4.3

Gtk+2.14

PyGTK-2.14


109

Entorno gráfico

XORG (X11 R7.4)38

Window Manager FLUXBOX 1.0.039

XDM y XSM (login y session manager)

Para el entorno gráfico Se eligió un Windows Manager en lugar de un Destktop Manager como GNOME o KDE, considerando el requerimiento de perfomance debido a la virtualización. Se optó por el Windows Manager FLUXBOX debido a que fue desarrollado para ser ejecutado en entornos de poca capacidad de procesamiento y memoria, brindando además un entorno agradable y funcional.

4.4.4 Tecnología VPN Se optó por una VPN SSL/TSL en lugar de una solución basada

en IPSec, principalmente por la flexibilidad en la asignación de puerto de conexión donde se brinda el servicio VPN de acceso remoto. Las soluciones IPSec requieren una asignación de puertos bien conocidas para el demonio IKE el cual gestiona el intercambio de claves de sesión y las asociaciones de seguridad y para el protocolo ESP para asegurar los datagramas en modo túnel (Puerto TCP 51 para ESP y puerto UDP 500 para IKE). Esto representa una restricción que limita la funcionalidad y la movilidad de la solución.

4.5 LA SOLUCIÓN El pendrive consta de dos archivos de extensión bat los

cuales realizan las siguientes funciones:

Vmvpn.bat : Ejecuta la maquina virtual

Penvpncl.bat: Ejecuta el cliente Windows para bajar o subir archivos a la maquina virtual

4.5.1 Funcionamiento de la Máquina Virtual Al inicializar la maquina virtual nos encontramos con el

pedido de usuario y clave para la autenticación local como lo muestra la Figura 4-2:

38 http://www.x.org 39 http://www.fluxbox.org


110

Figura 4-2 Pedido de credenciales locales

Al ingresar podemos acceder al menú principal (Figura 4-3) haciendo click con el botón derecho del Mouse sobre el área de la pantalla.

Figura 4-3 Menú principal, sesión local del usuario

Al seleccionar la opción Cliente VPN, accedemos a la aplicación. Al ingresar la única opción habilitada es la que nos permite conectarnos. Al realizar la conexión se habilitan las opciones de acuerdo a nuestro perfil de usuario (Administrador o usuario normal) permitiendo acceder a los servicios de nuestra corporación, esto se visualiza en la Figura 4-4:


111

Figura 4-4 Menú del Cliente VPN

Las opciones de izquierda a derecha son: conectar, desconectar, correo electrónico, acceso al servidor de archivos, FTP, SSH, mensajería instantánea, terminal remota y cliente VNC.

Por ejemplo la Figura 4-5 muestra la pantalla para acceder a los archivos remotos del usuario. Se solicita las credenciales válidas del usuario para acceder al servidor que contiene los archivos.

Una vez autenticado el usuario, la conexión con el servidor se establece montando, mediante el protocolo CIFS, el directorio del usuario en /media/vpnsmb.

Figura 4-5 Acceso a los archivos remotos


112

4.5.2 Aplicación de gestión de archivos Para poder descargar o subir de la maquina virtual archivos

debemos ingresar usuario y contraseña, siendo estas credenciales las mismas que para ingresar a la solución. La pantalla de conexión se muestra en la Figura 4-6.

Para comunicar ambas aplicaciones se establece una comunicación mediante SSH. Se utiliza la biblioteca de PYTHON PARAMIKO, la cual implementa la versión 2 del protocolo SSH.

Figura 4-6 Pantalla de conexión a la maquina virtual

En la parte inferior se informa sobre el estado de la aplicación. Si se desea bajar un archivo se oprime Listar Directorio y muestra el contenido del directorio VpnFolder del usuario. Al seleccionar un archivo se habilita la opción para Bajar el Archivo. El mismo queda en la carpeta VpnFolder del pendrive.

Para ingresar el archivo a la maquina virtual se oprime la opción subir archivo. Se selecciona un archivo, se tiene la libertad de poder seleccionar una carpeta del host si se desea. El archivo se sube a la carpeta VpnFolder del usuario. Si se desea subir el archivo al servidor se puede hacer a través del FTP.


113

4.6 CONCLUSIONES DEL TRABAJO PRÁCTICO El objetivo inicial del trabajo práctico se ha cumplido. Se

logro concretar el concepto de portabilidad de un cliente VPN de acceso remoto. La motivación principal del trabajo fue esta, sin importar en principio que tecnología y protocolo VPN era más conveniente usar.

La complejidad de la solución estriba en la elección más adecuada de sus componentes y en la búsqueda de la optimización de los mismos en función de la virtualización requerida. Sin embargo esta propuesta se puede mejorar para lograr un resultado aún más óptimo en términos de perfomance y funcionalidad.

Entre estos aspectos se puede mencionar la posibilidad de lograr una distribución LINUX aún más compacta, mejorar la aplicación principal para que controle la conexión de manera más precisa, crear un mecanismo que permita la actualización en forma dinámica de dicha aplicación además de un mecanismo de actualización de paquetes para la distribución propia.

Una mejora en la seguridad del cliente VPN sería la utilización de un mecanismo de doble autenticación al momento de la conexión. Esta consistiría en autenticar el dispositivo o sistema mediante un certificado y luego el usuario mediante el mecanismo OTP o claves de una sola sesión. Este esquema brindaría una mayor seguridad en cuanto a la validación del usuario. Otro componente para flexibilizar aún más esta alternativa sería un servidor RADIUS que permite que un usuario se autentique en forma centralizada y segura usando varios esquemas posibles mediante el protocolo EAP.

Durante el desarrollo del trabajo se evaluó el uso de un servidor RADIUS en conjunto con OpenVPN a través de un plugin. Junto con un certificado para el dispositivo se logró concretar una doble autenticación, pero con el mecanismo más débil que es el par usuario y contraseña común. RADIUS es una tecnología compleja, y debido a falta de tiempo se decidió no continuar con la evaluación de sus características para una posible aplicación a la solución. Sin embargo se la evaluó como una valiosa alternativa mejoradora.

El trabajo se centra en el desarrollo de un cliente VPN y como tal, las soluciones VPN de acceso remota basadas en estos requieren de una carga administrativa en relación al mantenimiento e instalación de los mismos. Por esta razón se considera limitado el conjunto de usuarios que la utilizarían. En particular puede resultar útil para personal del tipo administrador, de redes o de sistemas.

La limitante en perfomance de la virtualización es posible minimizarla gracias al hardware existente de gran capacidad de procesamiento y virtualización comunes en la actualidad, tanto en equipos portátiles como en equipos de escritorio. Las tecnologías de doble, triple y hasta cuádruple núcleo en los CPU, y el soporte de virtualización de los sistemas operativos actuales, habilitan que esta sea una solución viable.

Finalmente la posibilidad de adquirir una memoria flash o dispositivos pendrive de gran capacidad de almacenamiento, descartan las limitantes de espacio para la instalación, en estos dispositivos de la solución descripta en este capítulo.


114

5

Anexos


115

5.1 ÍNDICES DE FIGURAS

Figura 1-1 Componentes de una VPN .................................. 13 Figura 1-2 VPN Provista por el Cliente ............................. 14 Figura 1-3 VPN Sitio a Sitio ....................................... 16 Figura 1-4 VPN de Acceso Remoto .................................... 16 Figura 1-5 Clasificación de las VPN ............................... 18 Figura 1-6 Adyacencias del Ruteo ................................... 21 Figura 1-7 Infraestructura del proveedor ........................... 22 Figura 1-8 VPNs tipo Peer .......................................... 22 Figura 2-1 Componentes ............................................. 31 Figura 2-2 Firewall ................................................ 32 Figura 2-3 Servidores de Autenticación ............................. 33 Figura 2-4 Basada en la Implementación (Hibrida) ................... 35 Figura 2-5 Túneles bajo demanda (Router a Router) .................. 36 Figura 2-6 Sesiones encriptadas bajo demanda ....................... 36 Figura 2-7 Túneles bajo demanda (Firewall a Firewall) .............. 37 Figura 2-8 Dirigida ................................................ 38 Figura 2-9 Funcionamiento de un Túnel .............................. 41 Figura 2-10 Multiplexación de Túneles .............................. 42 Figura 2-11 Funciones del Protocolo PPP en PPTP .................... 46 Figura 2-12 Componentes en una conexión PPTP ....................... 47 Figura 2-13 Encapsulamiento PPTP ................................... 47 Figura 2-14 Componentes en el Protocolo L2F ........................ 48 Figura 2-15 L2TP Túnel obligatorio ................................. 49 Figura 2-16 L2TP Túnel voluntario .................................. 50 Figura 2-17 Paquete/Datagrama usando IPSec ......................... 51 Figura 2-18 Encabezado AH .......................................... 53 Figura 2-19 Modos con protocolo AH ................................. 55 Figura 2-20 Modos en ESP ........................................... 56 Figura 2-21 Encabezado y Cola ESP .................................. 56 Figura 2-22 Paquete GRE encapsulado ................................ 59 Figura 2-23 Encapsulamiento Multicast con GRE asegurado con IPSec .. 60 Figura 2-24 Escenario Red a Red .................................... 66 Figura 2-25 Escenario Host a Red ................................... 66 Figura 2-26 Punto a Punto en VPN VPWS .............................. 68 Figura 3-1 Escenario General ....................................... 73 Figura 3-2 Gateway VPN sobre el Firewall ........................... 80 Figura 3-3 Esquema en paralelo ..................................... 81 Figura 3-4 Gateway VPN con DMZ única ............................... 83 Figura 3-5 Uso de una doble DMZ .................................... 84 Figura 3-6 Alta disponibilidad con Failover Activo ................. 85 Figura 3-7 Alta disponibilidad mediante un Cluster ................. 86 Figura 3-8 SSH Reenvío Local de puerto ............................. 90 Figura 3-9 SSH reenvío Remoto de puerto ............................ 91 Figura 4-1 Diseño de la solución .................................. 104 Figura 4-2 Pedido de credenciales locales ......................... 110 Figura 4-3 Menú principal, sesión local del usuario ............... 110 Figura 4-4 Menú del Cliente VPN ................................... 111 Figura 4-5 Acceso a los archivos remotos .......................... 111 Figura 4-6 Pantalla de conexión a la maquina virtual .............. 112


116

5.2 REFERENCIAS BIBLIOGRÁFICAS

BIBLIOGRAFÍA

BERKOWITZ, HOWARD C.[1999], Designing Addressing Architectures for Routing and Switching.

BROWN, STEVEN [2001], Implementación de Redes Privadas Virtuales

COMER, DOUGLAS E.[2000], Internetworking with TCP/IP Vol.1 Principles, Protocols, and Architectures.

GUPTA, MEETA [2003], Building a Virtual Private Network

STALLINGS, WILLIAM [Junio 2000], Data & Computer Communications 6ta. Edición.

TANENBAUM, ANDREW S.[1996], Computer Networks 3ra. Edición.

SCOTT, CHARLIE-PAUL WOLFE-MIKE ERWIN [Enero 1999], Virtual Private Networks, Second edition

PUBLICACIONES

CISCO SYSTEM [Abril 2006], Packet Networking Professionals Magazine.

CISCO SYSTEM [Junio 1998],The Internet Protocol Journal Nº1 Vol 1

CISCO SYSTEM [Septiembre 1998],The Internet Protocol Journal Nº2 Vol 1

CISCO SYSTEM [Marzo 2007],The Internet Protocol Journal Nº1 Vol 10

CISCO SYSTEM [Junio 2007],The Internet Protocol Journal Nº2 Vol 10

NETXIT SPECIALIST Nº13, Elementos Básicos de Criptografía, Algoritmos de Hash Seguros, El Gran Debate: PASSPHRASES vs. PASSWORDS

NETXIT SPECIALIST Nº14, Elementos Básicos de Criptografía, Algoritmos de Hash Seguros, El Gran Debate: PASSPHRASES vs. PASSWORDS-Parte 2

NETXIT SPECIALIST Nº27, ABC de VPNs

NETXIT SPECIALIST Nº30, Virtualización

NETXIT SPECIALIST Nº32, Virtualization Technologies

WHITE PAPERS

FINLAYSON, M. HARRISON, J. SUGARMAN, R.[Febrero 2003], VPN Technologies – A Comparison HTTP://www.dataconnection.com

SEMERIA, CHUCK [Marzo 2001], RFC 2547bis: BGP/MPLS VPN Fundamentals – Juniper Networks HTTP://ftp.utcluj.ro/pub/users/dadarlat/retele_master/TARC_08_09/MPLS-VPN/200012.pdf


117

CISCO SYSTEMS [2004], Enterprise guide for selecting an IP VPN Architecture – Comparing MPLS, IPSec, and SSL.

HTTP://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns465/net_implementation_white_paper0900aecd801b1b0f.pdf

JUNIPER NETWORKS [Junio 2007], VPN Decision Guide – IPSec vs. SSL VPN Decision Criteria.

HTTP://www.juniper.net/us/en/local/pdf/whitepapers/2000232-en.pdf

AVOLIO FREDERICK [2000], Security Review: SSL VPNs – Avolio Consulting

HTTP://www.avolio.com/papers/SSLVPN_SecWP.pdf

SCHULTZ, KEITH [Febrero 2005], SSL VPNs Come of Age

HTTP://www.infoworld.com/article/05/02/04/06FEsslvpn_1.html

NCP SECURE COMMUNICATIONS [Abril 2001], Remote Access VPN and IPSec

HTTP://www.symtrex.com/pdfdocs/wp_ipsec.pdf

CARMOUCHE,JAMES H.[Septiembre 2006], Basic VPN Topologies and Configurations

HTTP://www.ciscopress.com/articles

SAARINEN, MIKKO [Febrero 2004], Legacy User Authentiaction with IPSec HELSINKI UNIVERSITY OF TECHNOLOGY

MASON, ANDREW [Febrero 2002], IPSec Overview: IKE – CiscoPress

HTTP://www.informit.com/articles

JAZIB, F. QIANG, H. [Junio 2008], SSL VPN Design Considerations

HTTP://www.ciscopress.com/articles

SHINDER, DEB [Mayo 2005], Soluction Base: Introduction to SSL VPNs

KOLESNIKOV, OLEG - HATCH, BRIAN – DAVIS, CRHIS – MONGOL, CRHIS BUILDING LINUX VPNs, VPN FUNDAMENTALS CAPÍTULO 2

HTTP://www.buildinglinuxvpns.net/chapter2.pdf

Documents

VPN Teoria