Tesina

REDES VPNs DE ACCESO REMOTO
Tesina presentada como trabajo final de los estudios en la carrera de Licenciatura de Informtica de la Facultad de Ingeniera de la Universidad Nacional de la Patagonia San Juan Bosco
Autores: APU Mario Rubn Mansilla APU Eduardo Rodolfo Colombres Tutor de Tesina: Ing. Alejandro Rosales
Trelew Abril 2009
VPNs de Acceso Remoto
Propuesta de Tesina Redes VPN de acceso Remoto
INTRODUCCIN
Las redes privadas virtuales o VPN (Virtual Private Network) por sus siglas en ingls, 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 organizacin, utilizando una infraestructura de comunicacin de datos pblica y compartida. Las tecnologas de redes privadas virtuales han evolucionado para representar ya no solo una opcin econmica para las comunicaciones sino tambin como una solucin complementaria para lograr eficiencia, velocidad, seguridad, confiabilidad en otros servicios de red de rea amplia. Adems se la considera una herramienta estratgica que permite interconectar en forma segura redes y equipos externos cuya administracin y control estn fuera del alcance de la organizacin. Debido a que se utiliza una infraestructura compartida y pblica para la interconexin, la seguridad de los datos que se transmiten es fundamental. En el contexto de una VPN esto se resuelve mediante un protocolo de tnel, es decir un mecanismo que es capaz de encapsular paquetes de protocolos arbitrarios, mediante el agregado de encabezados, utilizando adems mecanismos para preservar la confidencialidad e integridad de los datos enviados. En la actualidad existe una gran diversidad de tecnologas que implementan VPN, lo cual permite clasificarlas segn distintos criterios, por ejemplo en funcin de quien provee el servicio (el usuario o un ISP), segn en que capa del modelo de referencia ISO/OSI se establece la VPN (VPN de capa 2, capa 3 o de transporte/aplicacin) o de acuerdo a la topologa de interconexin utilizada (VPN punto a punto o punto multipunto). De acuerdo a este ltimo criterio, generales, dos escenarios donde se aplican sitios, es decir dos redes y al comunicar conoce como VPN sitio a sitio y VPN de acceso se pueden apreciar en trminos las VPNs, al interconectar dos dos hosts entre s, a esto se 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 quin se conecta y de acuerdo a esto, que permisos y autorizaciones posee. Estas precauciones deben reflejar las polticas de seguridad de la informacin definidas previamente por la organizacin.
OBJETIVOS GENERALES
Investigar las caractersticas, componentes, mecanismos de una VPN de acceso remoto y como solucionan la necesidad de un ingreso seguro a los recursos informticos de la organizacin desde cualquier sitio.
Aplicar los conceptos de VPN de acceso remoto a travs de una solucin que implemente un cliente VPN porttil que evite la instalacin de programas para esta tarea.
OBJETIVOS PARTICULARES
Determinar las caractersticas necesarias para que una solucin sea considerada una VPN. Determinar las ventajas y desventajas de la utilizacin de IPSec y SSL en la implementacin de VPNs de acceso remoto. Investigar diferentes enfoques para la creacin de una distribucin LINUX especfica para el desarrollo de la prctica. Evaluar alternativas de lenguajes de programacin para el desarrollo de aplicaciones a utilizar en la prctica. Evaluar alternativas de software de virtualizacin que sean portables para el desarrollo de la prctica.
FUNDAMENTACIN
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 tambin en la capacidad de ancho de banda ofrecido. Esta situacin beneficia la puesta en prctica de VPN de acceso remoto. Una actividad muy popular es el tele trabajo, que permite desde otra ubicacin fsica contar con los recursos de la informacin 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 da. Esto genera una problemtica que combina aspectos de seguridad y facilidad de uso. Se puede considerar estos dos aspectos antagnicos. Mientras ms seguridad se quiera aplicar menos dinmico y transparente se torna el proceso o tarea requerida (utilizacin de certificados, claves de acceso, mecanismos de distribucin de claves). Tampoco se puede priorizar la facilidad de uso sobre la seguridad, porque se estara poniendo en riesgo el recurso ms valioso de una organizacin que es la informacin, 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 solucin 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 realizacin 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 mquina virtual la cual reside en un dispositivo USB (pendrive). La aplicacin que virtualiza el sistema LINUX se ejecuta en la plataforma ms popular en la actualidad.
ORGANIZACIN DEL TRABAJO

El siguiente trabajo se compone de cuatro captulos donde se desarrollarn 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 teora sin referir el contexto general resulta en un desarrollo aislado que impide la compresin correcta del tema particular. Por esta razn se dedic un par de captulos a las definiciones y teora general para introducir el tema principal el cual es sujeto de este trabajo. El captulo 1 refiere a definiciones y terminologa utilizada en la teora de las VPNs, adems presenta las diversas clasificaciones, los criterios que provocan tales distinciones y las aplicaciones. En el captulo 2 se desarrollan las arquitecturas, los protocolos y las aplicaciones de las redes privadas virtuales. Dentro de las arquitecturas se mencionan las tecnologas involucradas. En cuanto a los protocolos VPN se destacan IPSec, L2TP y SSL, los cuales sern referidos en el captulo dedicado a las VPNs de acceso remoto. El captulo 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 ms utilizados y caractersticas de las soluciones VPN de acceso remoto. Finalmente el captulo 4 presenta el desarrollo del trabajo prctico realizado como aplicacin y las conclusiones del mismo.
ndice
CAPTULO 1 INTRODUCCIN A LAS VPN ..........................................7
1.1 DEFINICIONES Y TERMINOLOGA .............................................................................................. 8 1.1.1 Red Privada............................................................................................................................... 8 1.1.2 Red Pblica ............................................................................................................................... 9 1.1.3 Red Privada Virtual .................................................................................................................. 9 1.1.4 Definicin de VPN ..................................................................................................................10 1.1.5 Terminologa............................................................................................................................11 1.2 CLASIFICACIN .........................................................................................................................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 Integracin 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 conexin ......................................................................23 1.2.8 VPN de capa de transporte/aplicacin...........................................................................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
CAPTULO 2 ARQUITECTURAS, CLASIFICACIN Y PROTOCOLOS .....................29
2.1 INTRODUCCIN 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 Pblicas........................................................................................................................33 2.1.6 Tneles ......................................................................................................................................34 2.2 ARQUITECTURAS .........................................................................................................................34 2.2.1 Basadas en software .............................................................................................................34 2.2.2 Basadas en la Implementacin..........................................................................................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 mltiple servicios..........................................................................................................39 2.3 PROTOCOLOS DE TNEL...........................................................................................................41 2.3.1 Requerimientos de un Tnel.................................................................................................42 2.4 PROTOCOLOS DE TNEL CAPA 2 ...........................................................................................45 2.4.1 Point to Point Protocol (PPP) ................................................................................................45
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 TNEL 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 TNEL CAPA 4 ...........................................................................................62 2.6.1 Secure Shell (SSH) ...................................................................................................................62 2.6.2 Secure Sockets Layer/Transport Layer Security (SSL/TLS) ...............................................64 2.7 TOPOLOGAS ..............................................................................................................................64 2.7.1 Escenarios ................................................................................................................................65 2.7.2 Topologa Punto a Punto......................................................................................................67 2.7.3 Topologa Punto a Multipunto.............................................................................................68 2.7.4 Topologa Estrella (Hub and Spokes) .................................................................................69 2.7.5 Topologa de Malla Completa o Parcial (Full or Partial Mesh).....................................70
CAPTULO 3 VPN DE ACCESO REMOTO ..........................................72
3.1 INTRODUCCIN .........................................................................................................................73 3.1.1 Requerimientos bsicos de seguridad ..............................................................................74 3.1.2 Configuracin de las polticas de seguridad...................................................................75 3.1.3 Auditora...................................................................................................................................75 3.2 ESCENARIOS................................................................................................................................76 3.2.1 Tele trabajadores/usuarios mviles 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 mviles desde dispositivos pblicos ..............................................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 Autenticacin, Autorizacin y Registro (AAA) .................................................................86 3.3.4 Administracin 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 tecnologas de acceso remoto ....................................................94 3.5 SOLUCIONES VPNs DE ACCESO REMOTO ............................................................................99 3.5.1 IPSEC .......................................................................................................................................100 3.5.2 SSL/TLS .....................................................................................................................................101
CAPTULO 4 TRABAJO PRCTICO .............................................102
4.1 INTRODUCCIN .......................................................................................................................103 4.2 ALCANCES ................................................................................................................................104 4.3 FUNCIONAMIENTO ..................................................................................................................105 4.3.1 Perfiles de usuarios ...............................................................................................................105 4.3.2 Esquema de validacin......................................................................................................105 4.3.3 Servicios..................................................................................................................................105 4.3.4 Gateway VPN .......................................................................................................................106 4.4 TECNOLOGAS DE LA SOLUCIN..........................................................................................106
4.4.1 Lenguajes de programacin.............................................................................................106 4.4.2 Entorno de virtualizacin ....................................................................................................107 4.4.3 Distribucin LINUX.................................................................................................................107 4.4.4 Tecnologa VPN ....................................................................................................................109 4.5 LA SOLUCIN ...........................................................................................................................109 4.5.1 Funcionamiento de la Mquina Virtual ..........................................................................109 4.5.2 Aplicacin de gestin de archivos ..................................................................................112 4.6 CONCLUSIONES DEL TRABAJO PRCTICO .........................................................................113
ANEXOS ....................................................................114
5.1 NDICES DE FIGURAS................................................................................................................115 5.2 REFERENCIAS BIBLIOGRFICAS .............................................................................................116
CAPTULO 1 INTRODUCCIN A LAS VPN

1
1.1 DEFINICIONES Y TERMINOLOGA

La importancia de la tecnologa 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 econmico y funcional, siendo una herramienta estratgica que brinda soporte y permite el desenvolvimiento y transformacin de dichas organizaciones. Hoy en da no se puede concebir, a nivel organizacional, algn cambio, fusin u unin sin considerar las comunicaciones y las tecnologas de informacin 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 organizacin, permitiendo compartir la informacin, y el trabajo en grupo de una forma ms 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 deban acceder a los datos por igual. Este esquema funcion para pequeas organizaciones, pero para aquellas cuya estructura inclua sitios geogrficamente alejados, surgi la necesidad de interconectar tambin dichos lugares. La solucin vino de la mano de los proveedores de servicio de red de rea amplia de datos o WAN (Wide Area Network), a travs de la contratacin de enlaces dedicados, los cuales conectaban las redes distantes con la red central. Esta solucin implicaba un costo, que result prohibitivo para la mayora, excepto para aquellos que podan abonar un costo fijo de contratacin ms un valor que variaba proporcionalmente a la distancia existente entre los sitios a interconectar (mile-age fee). En la actualidad existen tecnologas WAN (Frame Relay, ATM1) donde el costo esta en funcin del caudal de datos o ancho de banda comprometido del enlace, que una organizacin esta dispuesta a pagar, sin considerar ya la distancia geogrfica. De esta forma se contaba con una red privada o estructura de comunicacin propia, en el sentido de que el control y la administracin de la red estaban bajo el dominio de la organizacin. Las polticas de uso, los servicios suministrados, los medios activos y pasivos de comunicacin por donde fluan los datos estaban bajo un control propio. Si bien las comunicaciones de rea amplia eran suministradas por un proveedor, este se comprometa a respetar los requerimientos de la organizacin cliente y adems los datos que atravesaban su red, no iban a estar al alcance de otros clientes.
Asynchronous Transfer Mode
1.1.2 Red Pblica

Uno de los eventos mas importantes que acompa al desarrollo de las redes en las organizaciones, fue la rpida evolucin de la mayor de las redes IP existentes, Internet. Esta se define como un sistema cooperativo de interconexin de redes que suministra un servicio de comunicacin universal. De esta manera satisface la necesidad de los usuarios de comunicar dos puntos cualesquiera, tambin denominados sistemas o nodos finales, pudiendo acceder a recursos ms all de los disponibles en un nico sistema y ubicados fuera de los lmites de la red local. Los datos atraviesan redes intermedias hasta llegar a su destino, en una operacin no orientada a la conexin, mediante el uso de equipos especiales denominados routers, tambin conocidos como sistemas o nodos intermedios. La naturaleza no orientada a la conexin de Internet, significa que no hay una ruta preestablecida o circuito virtual dedicado entre los sistemas que se comunican, tampoco niveles de servicio, priorizacin o separacin de trfico que puedan aplicarse a los datos que se transmiten. La funcin 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 pblica, en el sentido de que son muchos los que participan en su conformacin y los medios de transmisin 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 geogrficamente fuera de los lmites de sta. stos requeran desplazarse con frecuencia y en algn momento acceder a sus archivos en la red local, revisar su correo electrnico o utilizar un sistema de informacin. En un principio se utilizaron servicios de acceso remoto mediante la implementacin de servidores para tal fin o RAS (Remote Access Server), el uso de lneas discadas para la conexin y pools de modems para atender las llamadas. Toda esta infraestructura era costeada por la organizacin la cual era responsable de su administracin y mantenimiento. Si bien se solucionaba el problema de acceso a la red local, se lograba a un costo econmicamente alto. Otra necesidad fue la de encontrar una alternativa ms econmica de interconectar diversas redes entre s y ya no solamente las de una misma organizacin, sino redes de diferentes organizaciones. Razones de poltica estratgica justificaban este desafo, ya sea a nivel empresarial, universitario o gubernamental. Ambos requerimientos tuvieron su solucin 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 garanta de que estos no puedan ser captados por terceros. Tambin es claro que los sistemas finales que se comunican estn expuestos.
En la actualidad no solo se considera a Internet como medio donde una organizacin 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 travs de su red backbone. Un SP puede administrar mltiples VPNs pertenecientes a varios clientes operando a travs de su backbone.
1.1.4 Definicin 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 pblica, como la red Internet2 La idea bsica de una VPN es muy simple. Una corporacin podra tener un nmero 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 VPN3 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 telecomunicacin pblica, manteniendo la privacidad mediante protocolos de tnel y procedimientos seguros. ....El propsito principal de una VPN es dar a la compaa la misma capacidad que otorgan los enlaces dedicados contratados pero a un costo menor, utilizando medios de comunicacin pblicos. 5 Se puede definir a una VPN de manera ms formal. Esta definicin aparece publicada en el artculo What Is a VPN? Part 1 escrito por Ferguson y Houston para la publicacin 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 conexin entre sistemas pares nicamente dentro de una comunidad de inters definida, y est creado considerando alguna forma de particin de un medio de comunicacin 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 ms dispositivos finales (estos a su vez pueden interconectar una red completa) que pueden estar ubicados geogrficamente distantes y representan una comunidad de inters. Para esto se utiliza como medio de transmisin una estructura compartida comn a varios usuarios. sta puede ser Internet o la red principal o backbone de un proveedor de servicios de comunicaciones.
2 3 4 5
What Is a VPN? Part I by Ferguson -Houston - The Internet Protocol Journal Marzo 2001 Cisco System VPN Technologies a Comparison by Finlayson-Harrison-Sugarman Data Connection Limited Febrero 2003 Virtual Private Networks (VPNs) Web ProForum Tutorials - IEC VPN Technologies: Definitions and Requirements by VPN Consortium Marzo 2006
10
Se dice privada porque los dispositivos que no participan en esta comunicacin no tienen acceso al contenido de la misma y de hecho no son conscientes de su establecimiento. El acceso a esta red y su administracin est restringido solo a un nmero limitado de dispositivos. La privacidad se aplica tambin al espacio de direccionamiento y esquema de enrutamiento utilizado en una VPN, en el sentido de que estn separados o difieren de aquellos instrumentados en alguna otra red privada existente o en la infraestructura de red subyacente por donde ocurre la comunicacin. El concepto de virtual, por definicin es la representacin de un objeto no existente mediante la ejecucin 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 fsica real. Este concepto fundamenta la naturaleza discreta o de separacin, de una red lgica privada funcionando sobre una infraestructura de comunicaciones compartida y real. El aspecto de privacidad, definido en el prrafo anterior, est en funcin de la virtualizacin.
1.1.5 Terminologa
La literatura relacionada con redes privadas virtuales esta plagada de acrnimos, siglas, trminos muy especficos que tornan difcil la interpretacin de cualquier lectura relacionada con el tema. Esta seccin define los principales elementos que componen un escenario VPN. Sitio: ubicacin geogrfica con uno o ms usuarios o uno o ms servidores o una combinacin de servidores y usuarios. El usuario refiere al host o estacin de trabajo. Servidor VPN: software o firmware VPN el cual se ejecuta en un dispositivo. Tiene la funcin de establecer un tnel 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 pblica. Otras acepciones pueden ser: gateway VPN, servidor de tneles. Cliente VPN: software o firmware VPN ejecutndose en un dispositivo, cuya funcin es establecer un tnel con un servidor VPN. Previamente, debe presentar las credenciales correctas al servidor. Otra acepcin puede ser cliente de tnel. Tnel: Enlace lgico entre el servidor y cliente VPN, creado por un protocolo de tnel. Por este canal se envan los datos que han sido encapsulados y quizs encriptados por el protocolo. Es posible transmitir datos sin encriptar por un tnel. Un tnel puede establecerse en diferentes capas del modelo ISO/OSI de protocolos de comunicaciones. Extremos de un tnel: dispositivos que gestionan la creacin, el establecimiento y la finalizacin de un tnel mediante la ejecucin de software o firmware dedicado para tal fin, por lo tanto se encargan tambin del procesamiento relacionado con la des/encapsulacin, des/encriptacin y transmisin de los paquetes recibidos.
11
NAS (Network Access Server): servidor de acceso de red, un dispositivo que representa una interfase entre un medio de acceso como la red de telefona y una red de conmutacin de paquetes, como el backbone de un proveedor o Internet. En una VPN este dispositivo permite que un usuario utilizando un acceso telefnico acceda a su red mediante un tnel creado por el NAS hacia el servidor de acceso remoto de la red destino. Tnel voluntario (Voluntary Tunnel): Tnel creado y configurado a partir de la solicitud de un cliente VPN. Esta clase de tnel es comn en las VPN de acceso remoto, donde uno de los extremos es una computadora personal o notebook de un usuario hogareo o mvil. Tnel obligatorio (Compulsory Tunnel): Tnel asociado con las VPN de acceso remoto. Su creacin y configuracin 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 tnel donde funciona el cliente VPN. Es posible que mltiples usuarios conectados al servidor de acceso de red, compartan el tnel en forma concurrente. En general el NAS es propiedad y es administrado por un proveedor de servicios. Ver ms detalles en el captulo 2Protocolos de tnel capa 2. Dispositivo de borde: Es el dispositivo ubicado en la frontera entre la red local y la red pblica. CE: Dispositivo de borde del cliente (Customer Edge Device). Es el equipo perteneciente a un cliente de un servicio de comunicaciones que se sita en el borde de la red privada local y conecta con la red del proveedor del servicio a travs 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 travs del CE. Un PE puede ser un router, switch o un dispositivo que combine ambas funciones. P: Dispositivos que componen el ncleo 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.
12
Figura 1-1 Componentes de una VPN
1.2 CLASIFICACIN
Se pueden encontrar varias clasificaciones de las VPN, lo cual puede generar cierta confusin. Esto se debe a que existen diversos tipos de tecnologas y clases de redes privadas virtuales, lo que permite ms de un criterio de organizacin. Las clasificaciones generales y ms habituales son: De acuerdo a quien implementa y administra el servicio: la propia organizacin o un proveedor de servicios. Segn que comunican: redes entre s o usuarios a la red. Segn 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 aplicacin/transporte que utilizan el protocolo SSL/TLS. Estas representan una clase particular de VPN que se describen aparte. Otros criterios pueden ser: Segn si los dispositivos de borde de un proveedor participan o no en el enrutamiento del trfico de datos del cliente: VPN peer to peer o VPN overlay. Segn si son orientadas o no a la conexin. 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 implementacin y administracin de la red privada virtual, ya sea el cliente (la organizacin) o el proveedor de servicios de comunicaciones. Esto se refiere a la definicin de las polticas a cumplir con esta solucin, los requerimientos para la implementacin, la adquisicin y configuracin de equipamiento, mantenimiento, resolucin de problemas y monitoreo, especificacin del espacio de direccionamiento a utilizar, esquema de enrutamiento etc.
13
VPNS provistas por el cliente (CE o CPE VPN)

Tambin 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 ms de un sitio propio, geogrficamente distante que desea conectar o bien requiere hacerlo con otra red fuera de su dominio, tambin remota. En este tipo de VPN, el tnel se establece, nicamente, entre los equipos del cliente. Estos representan los extremos del o los tneles. 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 reenvan. En el caso de la utilizacin de Internet, los routers intermedios tambin lo hacen con los paquetes IP, sin tener en cuenta el contenido encapsulado por el tnel 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 configuracin especial para el tratamiento de los paquetes de las VPN, adems 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 bsicamente de todo. Esto puede implicar un gran costo, tanto en la compra de equipamiento, como en la preparacin de personal para la configuracin y el mantenimiento de la VPN. Esta solucin presenta problemas de escalabilidad para el cliente cuando existen varios sitios para interconectar. Los tipos de VPN provistas por el cliente son: VPN IPSec VPN GRE (IP Security) (Generic Routing Encapsulation)
VPN SSL/TLS (Secure Sockets Layer/Transport Layer Security)
Figura 1-2 VPN Provista por el Cliente
14
VPNs provistas por el Proveedor (PPVPN)

En esta clase de VPN el proveedor de servicio se encarga de su implementacin. Los equipos de borde o PE participan activamente de la red virtual como as tambin, pero en menor grado, los dispositivos de borde del cliente. Esto significa que los PE realizan la mayor parte del procesamiento especfico de la VPN, permitiendo que los equipos CE puedan ser routers o switches estndar sin necesidad de comprar equipamiento especial. El proveedor es responsable de la administracin de la VPN, liberando al cliente de estas tareas. Esto resulta, para este ltimo, en un menor costo de implementacin respecto de un emprendimiento propio. Actualmente los proveedores ofrecen un servicio de VPN mejorado, donde suman adems de la conectividad, acuerdos de nivel de servicio, calidad y diferenciacin de servicio, seguridad, ingeniera de trfico 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 ncleo de Internet, no mantendrn informacin referida a la VPN, sin considerar si se utilizan protocolos de enrutamiento para distribuir o no dicha informacin. Existen cuatro escenarios donde pueden desplegarse estas VPN 6: nico Proveedor, nico Sistema Autnomo o AS (Autonomous System): escenario ms simple, el servicio se brinda a travs del AS de un nico proveedor. nico Proveedor, mltiples AS: un proveedor administra varios AS (adquisicin de varias redes). Este escenario implica la distribucin con restricciones de la informacin de enrutamiento entre los diversos Sistemas Autnomos. Multi Proveedor: es el caso ms 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)
RFC 3809 Generic Requirements for Provider Provisioned VPN
15
1.2.2 VPNs Sitio a Sitio y de Acceso Remoto

Otra forma general de distinguir las VPN es en funcin de si conectan redes entre s o usuarios a una red. Una VPN sitio a sitio (site-tosite VPN) conecta dos o ms redes entre s que estn geogrficamente dispersas, estas pueden pertenecer a una o varias organizaciones. Si las redes pertenecen a una misma organizacin, esta clase de VPN se denomina intranet. Si las redes pertenecen a varias organizaciones se conoce como extranet. La intencin en este ltimo caso es comunicar organizaciones diferentes que persiguen un objetivo comn y requieren compartir informacin til para el conjunto. El servicio de VPN entre sitios debera ser independiente del alcance geogrfico de la implementacin.
Figura 1-3 VPN Sitio a Sitio
Las VPN de Acceso Remoto o RAVPN (Remote Access VPN), tambin denominadas VPN de acceso, permiten a los usuarios mviles o itinerantes y a los usuarios hogareos de una organizacin o tele trabajadores, acceder en forma remota a la red. Esta clase de VPN puede establecer un tnel en modo voluntario u obligatorio.
Figura 1-4 VPN de Acceso Remoto
16
Las tecnologas y protocolos asociados a esta clasificacin 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 sern descriptos ms adelante en el captulo 2 dedicado a protocolos VPN.
1.2.3 VPNs de capa 2 y capa 3

El criterio de esta clasificacin se basa en las capas, del modelo de referencia ISO/OSI de protocolo de comunicaciones, por donde se establece el tnel de la VPN. Esta clasificacin surge a partir de la variedad de tecnologas existentes que se utilizan para implementar la VPN. Esta distincin 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 comunicacin esta basada en el direccionamiento de capa 2 y el reenvo del trfico esta basado respecto del enlace entrante y la informacin 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 comunicacin se basa en el direccionamiento a nivel de capa de red. El reenvo del trfico se lleva a cabo teniendo en cuenta el enlace entrante y las direcciones del encabezado IP.
17
1.2.4 Integracin de las clasificaciones

Las clasificaciones anteriores se pueden integrar para tener una perspectiva ms prctica y operativa de las VPN. Esta integracin muestra las VPN provista por el cliente o proveedor como el criterio de clasificacin ms general, dentro de la cual se pueden diferenciar las VPN sitio a sitio y remota. Finalmente se consideran segn las tecnologas VPN de capa 2 y 3. El siguiente esquema muestra esta relacin:
Figura 1-5 Clasificacin 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 reenvo del trfico de la VPN se llevan a cabo en funcin del enlace entrante y de la informacin del encabezado de capa 2. Dentro de las L2VPN se pueden distinguir dos categoras: VPNs basadas en circuitos Punto a Punto (P2P): conocidas tambin como VPWS (Virtual Private Wire Service). Se implementan usando MPLS o circuitos emulados (pseudowires) L2TPv3. VPNs Multipunto a Multipunto (M2M): en esta categora entran las VPN VPLS (Virtual Private LAN Service) e IPLS (IP-Only LAN Service).
VPN VPWS La red del proveedor puede considerarse como una emulacin 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 trfico 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 trfico al sitio destino.
18
Este esquema permite el reemplazo de redes con topologas estrella que requieren la interconexin de redes satlites hacia una red central, permitiendo alternativas de rutas hacia un destino. Unas de las tecnologas habituales, en el ncleo 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 ms escalable, respecto de la administracin del servicio, utiliza BGP (Border Gateway Protocol) como protocolo de sealizacin y auto deteccin. 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 trfico. De esta forma, cuando los otros CE reciben esta informacin, 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 funcin 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 solucin provee un servicio punto a multipunto donde los routers CE envan todo el trfico, destinados a los otros sitios, directamente al router PE. Este servicio se basa en la utilizacin de pseudowires, combinados en una topologa 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 trfico 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 nmero de direcciones MAC para el reenvo de tramas por sitio de cliente. VPN IPLS Si se requiere intercambiar trfico 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 reenvo se basa en informacin 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 reenva las tramas de capa 2, son aquellas de los routers CE. Esto es una ventaja respecto del servicio VPLS por el reducido nmero 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 tecnologas ms 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 solucin.
19
Se pueden dividir a su vez en: VPN basadas en PE: Los dispositivos PE participan en el enrutamiento y reenvo del trfico del cliente basado en el espacio de direcciones de la red del cliente. En este caso los CE no participan de la VPN. El trfico del cliente se reenva entre los PE a travs de tneles MPLS LSP, IPSec, L2TPv3 o GRE. VPN basadas en CE: En este caso los tneles son creados entre los equipos CE, mientras los PE no participan en la VPN, solo reenvan el trfico del cliente. Se utiliza IPSec o GRE para establecer los tneles.
1.2.5 Confiables y Seguras

Esta es una clasificacin donde se tiene en cuenta si es o no necesaria la encriptacin y autenticacin de los datos a transferir entre los nodos de la VPN. Los proveedores que no utilizan encriptacin 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 trfico 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 reenvan trfico de clientes basados en direccionamiento globalmente nico, por lo tanto no tiene conocimiento del direccionamiento utilizado por el cliente. Los tneles 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 nmero de adyacencias se incrementa en directa proporcin con el nmero de nodos.
20
Figura 1-6 Adyacencias del Ruteo
Pueden ser implementadas a nivel de capa fsica usando lneas telefnicas (dialup), a nivel de capa 2 utilizando Frame Relay, X-25 y ATM, o a nivel de capa 3 utilizando tneles 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 travs 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 podramos ver que la percepcin que poseen los routers CE es la que grafica la Figura 1-7
21
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
22
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 conexin

Son orientadas o no orientadas a la conexin dependiendo si el proveedor provee o no circuitos virtuales dedicados. Orientada a la conexin: Son en las que provee el proveedor un circuito virtual dedicado. Por ejemplo FRAME RELAY y ATM. No orientadas a la conexin: Son las que no poseen un circuito virtual. Por ejemplo las VPN basadas en IP.
1.2.8 VPNs de capa de transporte/aplicacin

El protocolo SSH (Secure Shell) desarrollado por Communications Security Ltd., permite acceder a otro dispositivo a travs de una red insegura, ejecutar comandos a una mquina remota y mover archivos de una computadora a otra. Utilizando encriptacin sobre canales inseguros provee una fuerte autenticacin y encriptacin. Existen dos versiones incompatibles entre s. Son dos protocolos totalmente diferentes que usan distinto cifrado.
SSH v1 Autenticacin de sistemas Autenticacin Llaves de servidor y cliente Llaves
SSH v2 Llaves de host Certificados
SSH2 es una completa reescritura del protocolo que lo hace mas seguro y utiliza una implementacin de red totalmente distinta que SSH1. Debido a la diferente implementacin ambos protocolos son incompatibles. Por ejemplo se lo utiliza para asegurar un tnel PPP. El principio de funcionamiento es el mismo que el de SSL diferencindose en la capa en la que actan y el mtodo de autenticacin. SSH Aplicacin Llaves SSL Transporte Certificados
Capa en la que trabaja Autenticacin
Tambin es posible establecer tneles en la capa de aplicacin. Para esto se utiliza un browser del lado del cliente, por lo que no es necesario instalar ningn programa. La conexin se realiza a un sitio web seguro mediante el protocolo HTTPS (Hypertext Transfer Protocol Secure). Adems, existen otros productos los cuales ofrecen una combinacin de gran flexibilidad, seguridad y que intentan lograr una configuracin que no requiera mucho conocimiento. La seguridad es lograda mediante cifrado del trfico usando el protocolo SSL/TLS.
23
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 conexin: voz, datos, multimedia, etc.
1.3 APLICACIONES
Las VPN se utilizan en situaciones donde es necesario establecer una comunicacin en forma segura utilizando un medio o infraestructura compartida de transmisin. Adems de comunicar redes propias de la organizacin, usuarios mviles, tele trabajadores etc. tambin es posible comunicar distintas organizaciones entre s. Esta alternativa surge a partir de la necesidad de establecer lazos de negocios, o la concrecin de intereses comunes. La extranet refleja dichos intereses mediante la interconexin 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 da las organizaciones dependan fuertemente de las tecnologas de informacin 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 solucin 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 relacin costo-beneficio para el cliente es posible.
1.3.1 Intranet /Intranet extendida

Una intranet en principio no se refiere a esquemas o topologas de redes, sino a un conjunto de contenidos y recursos de informacin que son accedidos y compartidos en forma privada y segura entre miembros de una misma organizacin, con el objetivo de proveer la lgica de negocio para las aplicaciones de la organizacin. Es un medio, adems, para la difusin de informacin interna, permitiendo que los empleados estn al tanto de lo que sucede en su mbito laboral de una manera eficiente. Una caracterstica fundamental de las intranets, es el hecho que su funcionamiento se basa en tecnologas que implementan estndares abiertos, tanto en los protocolos de comunicacin como en aquellos protocolos a nivel de aplicacin. Es decir, utilizan la tecnologa de Internet. En particular el uso de la suite TCP/IP para la comunicacin y a nivel de aplicacin 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 electrnico, hasta sistemas de informacin basados en web, sistemas de mensajera instantnea y colaborativos, sistemas de videoconferencia y comunicaciones de voz mediante IP (VoIP). El acceso y manipulacin de la informacin, mediante estos sistemas se encuentra restringido, por lo tanto tambin existen sistemas que permiten autenticar y autorizar a los diferentes usuarios de la organizacin.
24
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 organizacin logrando su interconexin a travs de Internet y/o las redes backbone de los proveedores de servicio. La intranet debera estar disponible para aquellos usuarios de la organizacin cuyo rol requiere movilidad y estar fuera de los lmites de la misma, por lo tanto fuera de la red de datos. Es necesario que estos usuarios mviles estn conectados para acceder a aquellos recursos o datos que la intranet pone a disposicin. Las redes distantes propias que pueden interconectarse y los usuarios mviles 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 relacin esta bien definida y es establecida bajo un estricto control del acceso. Se puede definir tambin como la interseccin de un grupo de intranets de varias empresas, lo cual indica que solo se comparte una porcin de la intranet hacia el resto de la extranet. Por otro lado Internet es el medio comn que resuelve problemas de incompatibilidad entre sistemas de empresas muy diferentes. Es decir, ofrece una interfaz comn que permite una interaccin difcil de lograr con otras tecnologas. Por lo tanto, como en el caso de las intranets, adoptan las tecnologas basadas en estndares abiertos propias de Internet para lograr comunicacin dentro de la extranet. Una extranet puede tener un impacto notable en las relaciones e interrelaciones con las dems empresas que la integran. De hecho puede modificar notablemente la posicin de la organizacin frente a sus clientes y competidores. Por esta razn la decisin de su implementacin debe responder a fines estratgicos, por lo cual deber ser tomada por la alta gerencia de la organizacin. Las VPNs son la forma ms efectiva de implementar las extranets, ya que pueden hacer uso de Internet para lograr la interconexin de los diferentes sitios. Nuevamente los puntos ms importantes a considerar son la seguridad en cuanto al acceso solo de los usuarios autorizados mediante mecanismos de autenticacin, como tambin el transporte a travs de la encapsulacin y encriptado de los datos. Como se ha visto en este captulo, existen diversos protocolos de tnel utilizados en VPNs, los cuales se aplican obviamente en las extranets. Algunos de ellos como IPSec, encapsulan los paquetes originales y encriptan la informacin 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 ms de las telecomunicaciones y redes de datos. Es muy importante la interconexin de redes propias en diferentes sitios. Esta necesidad fue resuelta por proveedores de servicios de telecomunicaciones, principalmente a travs de conexiones Frame Relay, ATM y ms recientemente mediante ethernet y tneles basados en IP.
25
Estas organizaciones, requieren con ms frecuencia, servicios de conectividad sobre uno o ms backbones, incluso a travs de Internet, pero que este servicio incluya contratos de nivel de servicio (Service Level Agreement), calidad de servicio (QoS), y otros parmetros que permitan una comunicacin segura, estable, con alto grado de disponibilidad, con un umbral de ancho de banda, con priorizacin de trfico, etc. Estas caractersticas son difciles de lograr cuando la comunicacin entre sitios debe atravesar redes de diferentes proveedores ms la Internet, es decir un entorno compartido y de naturaleza no orientada a la conexin. Las VPN permiten una comunicacin segura y privada mediante la encapsulacin y encriptacin. Es decir, aslan el trfico de datos privados de una organizacin del resto con el cual pueda compartir un canal de comunicacin. Actualmente la relacin costo-beneficio en la implementacin de este mecanismo ha determinado la conveniencia de la contratacin del servicio a proveedores, en lugar de la puesta en funcionamiento y control por parte de la propia organizacin. Para poder diferenciar y aislar los trficos pertenecientes a varios clientes, el proveedor utiliza conexiones de capa 2 (VPNs tradicionales) o tneles de capa 2 o 3. Para el caso de conexiones a travs 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, adems debe funcionar con las clases de proveedor definidos en el captulo 1, adems de Internet: nico proveedor, conjunto de proveedores y proveedor de proveedores. Existen requerimientos generales para esta clase de VPNs, un anlisis detallado se expresa en la RFC 3809 7 . Estos requerimientos pueden clasificarse en: Requerimientos del servicio: atributos del servicio que el cliente puede observar o medir, por ejemplo: disponibilidad y estabilidad, garantas de seguridad, servicio de tramas o datagramas. Requerimientos del proveedor: caractersticas que el proveedor evala para determinar la viabilidad en trminos de la relacin costo-efectividad del servicio, por ejemplo escalabilidad y grado de administracin Requerimientos de Ingeniera: caractersticas de implementacin que permiten cumplir con los requerimientos del proveedor y del servicio. Estos a su vez pueden clasificarse en: Requerimientos en el plano de mecanismos de reenvo de datos. reenvo: asociados a los
Requerimientos en el plano de control: asociados de distribucin de la informacin de enrutamiento.
al mecanismo
Requerimientos relacionados a la uniformidad de los mecanismos en esta clase de VPN respecto de otros esquemas y en general con la forma de operacin de Internet.
RFC 3809 - Generic Requirements for Provider Provisioned Virtual Private Networks
26
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 parmetros especificados un contrato de nivel de servicio o SLA. La calidad esta caracterizada por la disponibilidad del servicio, tasa de demora, de variacin de la demora (jitter), tasa de proceso de paquetes (throughput), de prdida 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 trfico, controlar el ancho de banda y la demora en la red. Existen dos maneras de lograrlo en redes IP, mediante Servicios Integrados y a travs de Servicios Diferenciados8 El mbito en el cual un servicio VPN cumple con calidad de servicio depender del proveedor de servicio. En la mayora de los casos de VPN definida en el sistema autnomo de un nico proveedor es posible cumplir con este requerimiento. El soporte de QoS en ambientes de multi proveedores o diversos sistemas autnomos estar en funcin de los acuerdos de cooperacin entre los involucrados en la provisin 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 polticas al trfico (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 travs de la red de acceso al PE Desde el PE a travs de la red de acceso al CE
Los dispositivos CE y PE deberan poder soportar QoS sin importar la tecnologa 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 administracin 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 ncleo 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 lmites del tnel.
Un acuerdo de nivel de servicio SLA (Service Level Agreement) es una documentacin donde se expresan los resultados de una negociacin entre un cliente y un proveedor de servicios. En este documento se especifican los niveles de disponibilidad, perfomance, nivel de servicio, forma de operacin y otros atributos del servicio. A partir de un SLA se pueden determinar objetivos de nivel de servicio o SLO (Service Level Objective), considerando mtricas individuales con los valores deseados e informacin operacional para controlar el SLA. Estas se pueden implementarse como polticas.
RFC 1633 - Integrated Services; RFC 2475 - Differentiated Service
27
Una especificacin de nivel de servicio o SLS (Service Level Specification) engloba a las dos anteriores, es decir especifica un acuerdo negociado y las mtricas individuales y datos operacionales, para garantizar la calidad de servicio del trfico de red para ese cliente. Una SLS puede definirse sobre la base de los siguientes objetivos y parmetros, los cuales se pueden considerar sobre la base de conexiones a la red de acceso, VPNs o sitios: Disponibilidad del sitio, VPN o conexin de acceso. Duracin de los intervalos de no disponibilidad del servicio. Tiempo de activacin del servicio. Tiempo de respuesta para la resolucin de un problema. Tiempo de aviso de un inconveniente. Limites para la variacin del delay y jitter.
El sistema de administracin 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 parmetros 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 autnomo, mientras que otro, an ms estricto, se puede cumplir en un dominio de un nico proveedor pero con varios sistemas autnomos bajo su cargo. En un escenario multi proveedor es ms difcil cumplir con aquellos parmetros que requieran un alto grado de cumplimiento, por ejemplo el requerimiento de QoS.
28
CAPTULO 2 ARQUITECTURAS, CLASIFICACIN Y PROTOCOLOS

2
29
2.1 INTRODUCCIN A LAS ARQUITECTURAS DE VPN

Las distintas infraestructuras de red y los distintos requerimientos exigen diversos tipos de arquitectura de redes VPNs. Deberamos realizarnos ciertos cuestionamientos para escoger cual es la que mejor se adapta a nuestras necesidades. Podramos mencionar los siguientes: Se posee con el personal calificado como para implementar las tecnologas necesarias o las soluciones existentes en el mercado proporcionadas por un proveedor pueden ser una mejor solucin? Cual es la interoperatividad infraestructura de red actual? Es proveedores? requisito indispensable de la arquitectura con los con nuestra y/o
comunicarnos
clientes
Ser fcilmente actualizable para nuestros futuros requerimientos en cuanto a escalabilidad, seguridad, facilidad de actualizacin 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 propsito o quiero implementar servicios con valor agregado? Cuntos usuarios crecimiento futuro? tendran en la actualidad y cual seria su
Al contestar estas preguntas y algunas que puedan surgir al cuestionarse cules son sus objetivos se podr empezar a limitar las distintas soluciones que podr implementar y mantener con el transcurso del paso del tiempo.
30
2.1.1 Componentes de una Red Privada Virtual

Los componentes observar en la Figura 2-1 que forman una Red Privada Virtual se pueden
Figura 2-1 Componentes
Una solucin de VPN se compone de varios elementos, los cuales se detallan a continuacin:
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 conexin Negociar las autenticacin. Autenticar conexiones, entre otros la encriptacin y
y autorizar a los clientes VPN.
Recibir datos del cliente y enviarle los pedidos por l. Tambin 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 algn sitio usando Internet o una red pblica. Tambin puede realizarse tareas administrativas, en general son administradores remotos que realizan tareas de configuracin, monitoreo y de gestin.
31
Para tener un mejor rendimiento se recomienda utilizar hardware especfico 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 fsica y los protocolos necesarios para la encriptacin y autenticacin.
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 ubicacin del firewall en una organizacin 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 direccin 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 direccin IP pblica asociada a la conexin a Internet. En la actualidad este mecanismo se encuentra implementado por defecto en los routers.
Servidores de autenticacin
Los servidores de autenticacin ofrecen mecanismos de autenticacin y autorizacin para autenticacin remota. Estos pueden pertenecer a la organizacin 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.
32
Figura 2-3 Servidores de Autenticacin
Arquitectura AAA
AAA (Authentication Authorization Accounting) es un mecanismo de autenticacin y autorizacin, 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 ms 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 acta como proxy. Este consulta al servidor RADIUS/TACACS y permite o deniega el acceso segn 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 debera ser capaz de dar soporte a distintas tecnologas como Frame Relay, ATM, IP, IP Multicast, Voice over IP y tambin protocolos de tnel. Sera recomendable que soporte calidad de servicio. Para que brinde altos niveles de seguridad tendra que soportar IPSec y brindar servicio AAA. Sera 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 Pblicas

Las redes pblicas que podemos mencionar son Internet y la red telefnica digital que permite brindar el servicio de DSL (Digital Suscriber Line), FRAME RELAY y ATM y la analgica que soporte velocidad de hasta 56Kbps.
33
2.1.6 Tneles
Estos pueden estar basados en protocolos como PPTP, L2TP, L2F e IPSec. En este captulo y en el siguiente se tratarn con ms 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 tneles o cifrado a otro anfitrin. En el caso de no residir en el firewall, se debe configurar este para que permita la comunicacin hacia y desde el exterior al equipo en que resida el software. Este desventaja que ser adquirido seguridad o de software puede ser abierto (Open Source) o propietario. La posee el propietario es que el proveedor puede desaparecer o por otra empresa y se deja de producir actualizaciones de agregado de funcionalidad.
El Open Source tiene la ventaja de su costo de adquisicin, pero puede ser necesario tener personal capacitado o realizar un contrato anual para tener soporte con algn proveedor.
2.2.2 Basadas en la Implementacin

Dependen de quien es el responsable de la implementacin de la VPN y su administracin. Existen dos categoras y una tercera que es una combinacin de las otras dos.
Dependiente
El proveedor del servicio es el responsable de proveer una solucin llave en mano. La principal ventaja es que la organizacin no debe cambiar su infraestructura y no necesita personal con conocimientos en administracin de VPN para su gestin. La mayor desventaja surge en el mbito de la seguridad. Es recomendable que la organizacin use una infraestructura AAA y firewall y estar a cargo de su administracin.
Independiente
En esta categora toda la responsabilidad de la implementacin es de la organizacin. La encriptacin, autenticacin y autorizacin 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 tecnologas
34
Hbrida
Esta categora es una combinacin de las categoras anteriormente mencionadas. Una parte de la administracin es realizada por la organizacin 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 administracin. tiene la desventaja de que es compleja la
Figura 2-4 Basada en la Implementacin (Hibrida)
2.2.3 Basada en Seguridad

Se podran mencionar cuatro categoras: Router a Router Firewall a firewall Tneles bajo demanda Tneles Multiprotocolo bajo demanda
Router a Router
Tneles bajo demanda: El tnel es establecido entre dos routers que se encuentran en la conexin en el lado del cliente y en el lado del servidor. Puede soportar mltiples conexiones simultneamente y persisten hasta que la ltima conexin es terminada. Los routers deben soportar intercambio de claves y algoritmos de encriptacin. La Figura 2-5 muestra como se relacionan los componentes bajo esta arquitectura.
35
Figura 2-5 Tneles bajo demanda (Router a Router)
Tneles multiprotocolo bajo demanda: Es similar a routers bajo demanda con la particularidad que los routers soportan varios protocolos de tnel. Tiene la particularidad de que pueden transferir datos no-IP a travs de la red pblica. Sesiones encriptadas bajo demanda: Cada sesin es encriptada en forma individual. Tiene un tnel 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 tneles bajo demanda y tneles demanda. A continuacin daremos un breve detalle. multiprotocolo bajo
Tneles bajo demanda

Es similar a router a router con tnel bajo demanda, con la particularidad que se reemplazan los routers por firewalls. Es ms seguro y permite que se puedan implementar auditorias mas complejas.
36
Figura 2-7 Tneles bajo demanda (Firewall a Firewall)
Tneles multiprotocolo bajo demanda

Generalmente se utilizan caracterstica multiprotocolo. L2TP asegurado con IPSec gracias a su
2.2.4 Iniciadas por el cliente

Cliente a Firewall/Router
Se negocia la sesin entre el cliente y el firewall/router. ste debe soportar el pedido del cliente de inicio de sesin. 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 ms seguro que el anterior porque el proveedor de servicios ignora la existencia del tnel.
2.2.5 Dirigidas
Los datos son encriptados en el capa 5 del Modelo OSI. Es decir en la capa de sesin. El protocolo ms utilizado en socks 5. Los tneles son unidireccionales. El control de acceso puede utilizar el identificador del usuario, hora, aplicacin y hasta el contenido del paquete. La capa de sesin soporta una mayor variedad de mecanismos encriptacin. La Figura 2-8 muestra la distribucin de los componentes. de
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.
37
Figura 2-8 Dirigida
Capa de Enlace
Se pueden dividir en: Conexin 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 Clasificacin de VPNs en el captulo 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. Tambin se puede utilizar IPSec.
2.2.7 Basada en Clases

Estas arquitecturas se basan en la complejidad de la configuracin de la VPN y del tamao. 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 caractersticas.
38
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 tneles ms rpidos bajo demanda y ejecutan el proceso de cifrado con mayor rapidez. Ofrecen una administracin centralizada. Es aconsejable que soporten los protocolos para establecimiento de tneles PPTP, L2TP e IPSec. En general este dispositivo se encuentra detrs 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 conexin a travs de una red pblica con un tnel cifrado al servidor interno de la organizacin o de una lnea de acceso telefnica hacia un servidor de autenticacin. El servidor puede ser un router, un firewall, una caja negra o un servidor de autenticacin independiente.
2.2.10 VPN mltiple servicios

Son aplicaciones multiservicios que son generadas por proveedores. Por ejemplo pueden dar el servicio de filtrado de contenido web y la revisin antivirus. El primero se suele aadir a un firewall para que pueda utilizar reglas para el acceso basado en el contenido.
39
Clase N 0
Software Como mnimo sistema operativo Windows 95/98
Protocolos Utilizados PPTP
Seguridad Filtrado de paquetes ofrecido por un Gateway, firewall o router Algn mecanismo de Autenticacin de Usuarios 1 Gateway
Acceso DSL T1
Caractersticas No soporta sitio a sitio
IPSec DES IKE
T1 T3
Soft de marcacin y de acceso remoto.
IPSec 3DES IKE
Soft de marcacin y de acceso remoto
X.500 LDAP IPSec 3DES IKE
Utiliza Token 5 VPN Gateway o 1 gateway que soporte 500 usuarios concurrentes AAA,RADIUS,TACACS, NAT y firewall Token y smartcards 20 VPN Gateway o 1 gateway que soporte 1000 sesiones simultaneas AAA,RADIUS,TACACS, NAT y firewall Servicio de certificados propio
Soporta: 20 sucursales 250 usuarios remotos Soporta sitio a sitio y acceso remoto Para poder implementar una extranet esta debe soportar IPSec Soporta: 10 a 100 sitios remotos 500 usuarios remotos sitio a sitio y acceso remoto 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 administracin, configuracin e implementacin Soporta: Miles de sitios remotos 10000 usuarios remotos Extranet, sitio a sitio, usuarios remotos Comercio electrnico Audio y video en tiempo real Posee la desventaja que necesita profesionales altamente capacitados
Es necesario calidad de servicio en cuanto a retardo ISDN Xdsl T1 T3
Soft de marcacin 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
Tabla 2-1 VPNs basadas en Clases
40
2.3 PROTOCOLOS DE TNEL

Un protocolo de tnel es un mecanismo para encapsular un PDU9 denominado de carga o nativo. Se agrega un encabezado al PDU de carga propio del protocolo de tnel. Finalmente este nuevo PDU se debe entregar a su destino final mediante un protocolo de transporte o envo, por lo que es necesario agregar el encabezado correspondiente a este ltimo. Esta clase de protocolos se utilizan para el envo de datos de un determinado protocolo a travs de una red que soporta uno diferente o incompatible. Tambin se usan cuando es necesario asegurar los datos de carga mediante algn mtodo de encriptacin. 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 pblico se envan paquetes con direcciones privadas.
Figura 2-9 Funcionamiento de un Tnel
Un tnel es un medio para reenviar datos a travs 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 informacin 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 tnel 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 agregndoles un encabezado que permite reenviarlos a travs del tnel. Los nodos intermedios X e Y solo participan del proceso de transporte, pero no tienen acceso a la informacin original propia de la comunicacin entre A y B. Cuando el paquete llega al extremo final o nodo de egreso Z, del tnel, este le saca el encabezado exterior y reenva el paquete al destino real, el nodo B. La utilizacin de tneles permite la separacin del trfico de datos de varias VPNs y del trfico 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 envan por los tneles sin modificacin, an si se usa Internet para su transporte.
Unidad de datos de protocolo
41
2.3.1 Requerimientos de un Tnel

Existen requerimientos deseables en los mecanismos de tnel, pero no todos los protocolos existentes cumplen con todos ellos. Estos son 10: Multiplexacin Protocolo de sealizacin Seguridad de los datos
Transporte multiprotocolo Secuenciacin de tramas Mantenimiento Manejo de grandes MTU Sobrecarga mnima Control de congestin y flujo Manejo de trfico y Calidad de servicio (QoS)
Multiplexacin
Esto permite el anidamiento de tneles, es decir que puedan existir mltiples tneles VPN entre dos extremos que han establecido un nico tnel principal, esto implica que cada extremo del mismo puede soportar varios clientes o VPNs. El trfico de cada uno se mantendr separado del otro a travs de la existencia de un campo de multiplexin en los paquetes transmitidos para distinguir la pertenencia a un determinado tnel. Compartir un tnel de esta forma, disminuye la demora y el procesamiento asociado al establecimiento del mismo. Esta caracterstica representa una ventaja ante los problemas de escalabilidad para un proveedor de servicios VPN ya que solo tiene que mantener una estructura de tneles de menor envergadura.
Figura 2-10 Multiplexacin de Tneles
10
RFC 2764 A framework for IP Based VPN
42
Protocolo de sealizacin
Previo al establecimiento de un tnel, se deben configurar una serie de parmetros que deben ser acordados por los extremos participantes, por ejemplo la direccin de los extremos, el nivel de seguridad requerido, etc. Finalmente el tnel se puede establecer. Todo esto es posible por va manual o en forma dinmica mediante el uso de un protocolo de sealizacin. La utilizacin de un protocolo de sealizacin, facilita la tarea de administracin del tnel, tanto su creacin, distribucin y manejo de parmetros o atributos asociados al mismo, mas an cuando la VPN a la cual pertenece el o los tneles abarca ms de un dominio administrativo. En este caso simplifica la coordinacin de la administracin. Tambin permite que los tneles puedan ser creados bajo demanda, cuando los nodos que los constituyen son mviles o requieren estar interconectados en forma transitoria. Es importante que el protocolo permita el transporte de un identificador VPN para asociar esta con el tnel resultante. El rol de este protocolo debera ser negociar los atributos del tnel y no transportar informacin acerca de como utilizar el mismo.
Seguridad de los datos

Un protocolo de tnel debe soportar mecanismos que permitan varios niveles de seguridad. Esto significa incluir mtodos de encriptacin y autenticacin de diversas fortalezas. La seguridad de los datos de la VPN en general no depende nicamente de las capacidades requeridas del tnel recin mencionadas. Es importante considerar otros mecanismos, como por ejemplo el manejo de varias instancias virtuales de tablas de enrutamiento y reenvo. Cada par (enrutamiento y reenvo) estarn asociadas a una VPN. Un mismo dispositivo en el extremo de un tnel, podr manejar varias instancias por lo tanto varias VPNs. Esto evita el enrutamiento por error del trfico de una VPN hacia otra, asegurando de esta manera la separacin de los flujos de datos. Otra medida de seguridad puede ser la autenticacin de los extremos del tnel mediante el uso del protocolo de sealizacin previo a su creacin.
Transporte Multiprotocolo
Muchas aplicaciones de VPN requieren la transmisin de trfico multiprotocolo, por lo tanto el protocolo de tnel debera soportar su transporte. Debe existir alguna forma de identificar el tipo de protocolo que esta siendo enviado por el tnel. No todos los protocolos de tnel soportan esta caracterstica, para estos existen extensiones que lo posibilitan. Otros poseen campos especficos para esta sealizacin.
Secuenciacin de Tramas
La secuenciacin podra ser necesaria para una operacin extremo a extremo eficiente de algn protocolo de tnel o aplicacin en particular. Para esto es necesario un campo de secuencia en el diseo del protocolo, para garantizar la entrega en orden de los paquetes.
43
Mantenimiento
Este requerimiento implica que los extremos monitoreen el estado del tnel 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 travs del protocolo en si, ejecutando un chequeo en banda en forma peridica y en caso de prdida de conexin indicar explcitamente el problema. La otra forma es mediante mecanismos fuera de banda, por ejemplo el uso de protocolos de enrutamiento aplicados a una malla de tneles (RIP, OSPF), lo cual permite detectar cualquier falla en forma automtica. Otra herramienta es el uso del protocolo ICMP a travs de mensajes de solicitud de eco para monitorear el estado del tnel.
Manejo de Grandes MTU

Teniendo en cuenta los dispositivos intermedios que reenvan el trfico del tnel, es posible que alguno de ellos maneje un valor de Mxima Unidad de Transferencia o MTU menor al valor manejado desde el extremo de ingreso al tnel. En este caso, es necesaria alguna clase de fragmentacin. Esto traera inconvenientes de perfomance en el nodo donde sucede la fragmentacin, disminuyendo la eficacia general. Para evitar este inconveniente, el protocolo de tnel puede incorporar capacidad de segmentacin y ensamblado haciendo uso del nmero de secuencia y alguna clase de marcador de fin de mensaje.
Sobrecarga Mnima
Es importante este aspecto y ms cuando se transporta trfico de datos sensible a la demora o al defasaje temporal, como lo es el trfico de voz y video. Lo que se persigue con este requerimiento es evitar el procesamiento innecesario en los dispositivos que establecen el tnel. Los mecanismos de cifrado y encriptacin imponen una sobrecarga. Por lo tanto se debera minimizar la sobrecarga u overhead tomando en cuenta la necesidad de aplicar seguridad a los datos. En general el objetivo debera ser minimizar el overhead alrededor de la necesidad de seguridad del trfico de datos. Cuando se implementan las VPN dial-up, o de acceso remoto discado, mediante el uso de tneles voluntarios, existe la posibilidad de sobrecarga significante si se utilizan enlaces de poco ancho de banda.
Control de Congestin y Flujo

Existen protocolos de tnel, como L2TP, que incorporan procedimientos para el control de flujo y congestin. Estos fueron pensados para mejorar la perfomance de la transmisin cuando se utilizaban redes que podan generar prdidas de paquetes con la compresin PPP. Otra razn era crear un buffer al momento de utilizar lneas con menor capacidad de transferencia. Finalmente estos esquemas se aplicaron a los canales de control en lugar de aplicarlos al trfico de datos. En general no est claro si es conveniente incorporar estas caractersticas en el diseo de los protocolos de tnel, en gran medida por el hecho de la predominancia del trfico TCP y el hecho de que TCP posee sus propios y eficientes mecanismos extremos a extremo de control de flujo y congestin.
44
Manejo de Trfico y QoS

de de de de Los usuarios de un servicio de VPN, podran desear caractersticas Calidad de Servicio como sucede con los dems servicios WAN. Para el caso las VPN, lograr aplicar QoS va a depender de las caractersticas de manejo trfico que puedan efectuar los nodos involucrados en la VPN y de la red acceso o backbone donde se implemente.
2.4 PROTOCOLOS DE TNEL CAPA 2

Los tneles 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 travs de una lnea serie. Este requiere una conexin full-duplex y puede ser sincrnico o asincrnico. Puede encapsular IP o no IP a travs de lneas 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 deteccin de errores durante la transmisin. Tambin realiza la multiplexacin de los protocolos de capa 2 y renegocia parmetros como la compresin 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 transmisin.
Funciones de LCP11
Realiza las siguientes funciones: Ayuda a establecer el enlace PPP. Configura y establece el enlace para requerimientos de comunicacin de las partes. satisfacer los
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)
45
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 tnel al servidor de la organizacin. Permite realizar una conexin por marcacin y soporta protocolos que no sean IP. PPTP es una extensin de PPP y por lo tanto no soporta mltiples conexiones. PPTP es el encargado de establecer y terminar las conexiones fsicas entre las partes, autenticar los clientes PPTP, encriptar datagramas de protocolos no IP e IP para crear datagramas PPP y asegurar el intercambio de informacin 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 transaccin PPTP. Existe un cliente, el cual es el que inicia la transaccin a travs de una conexin realizada con un modem a travs de una marcacin. Si el NAS del proveedor acepta la comunicacin entonces se puede establecer el tnel con el dispositivo VPN a travs de la red pblica. En la Figura 2-12 podemos observar la relacin entre PPP y PPTP.
46
Figura 2-12 Componentes en una conexin PPTP
El dispositivo NAS debe poder soportar mltiples 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 prdida la conexin realiza una transmisin peridica de echo entre el cliente y el servidor utilizando la conexin TCP establecida. Brevemente resumiremos como es el proceso de transmisin los datos basndonos 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 direccin IP de cliente PPTP y la del servidor destino. la
La capa de enlace suma un encabezamiento y una cola, el cual viaja a travs del tnel establecido. Esto es encapsulado dentro del protocolo de transmisin puede ser por ejemplo ethernet o un protocolo de WAN. que
El servidor extrae en orden inverso y termina desencriptando los datos.
47
Para realizar la encriptacin y compresin se utiliza los servicios brindados por PPP. En cuanto a la autenticacin 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 ao 1996. El objetivo era permitir que protocolos no IP pudieran utilizarse sobre Internet. El usuario hace una conexin PPP al proveedor de marcacin y se conectan a sus organizaciones a travs de L2F.
Figura 2-14 Componentes en el Protocolo L2F
L2F provee la encriptacin de datos y la autenticacin utilizando CHAP, EAP (Extensible Authentication Protocol) y SPAP (Shiva Password Authentication Protocol). Tambin puede emplear RADIUS y TACACS como servicios adicionales. Como desventajas se puede mencionar que esta solucin requiere un mantenimiento costoso y son dependientes del proveedor que debe implementar L2F. No provee control de flujo, lo que resulta en retransmisin de trfico y provoca una comunicacin ms lenta. Es ms lento que PPTP debido al proceso de autenticacin y encriptacin.
2.4.4 Layer 2 Tunneling Protocolo (L2TP)13

En 1998 las compaas que desarrollaron PPTP y Cisco que trabaj con L2F acordaron una nueva especificacin para el establecimiento de tneles 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 configuracin para proteger el trafico L2TP a travs de redes IP y no IP.
12 13
RFC 2341 - Cisco Layer Two Forwarding (Protocol) "L2F" RFC 2661 - Layer Two Tunneling Protocol "L2TP"
48
Las ventajas que tiene es que soporta multiprotocolos y tecnologas como por ejemplo IP, ATM, Frame Relay y PPP. No requiere implementacin de software especfico como drivers o soporte en el sistema operativo. Permite que clientes con IP privadas se comuniquen a travs de redes pblicas con sitios remotos. Y por ltimo se puede mencionar que la autorizacin y autenticacin 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 tnel 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 conexin entre el LAC y el sistema remoto es mediante un enlace PPP. Un LNS es el otro extremo del tnel L2TP y representa la terminacin lgica de la sesin PPP que es enviada por el tnel.
Modos de tnel
L2TP soporta los modos de tnel obligatorio y voluntario. En el modo obligatorio Figura 2-15, el proveedor es el encargado de establecer entre el LAC y el LNS el tnel 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 Tnel obligatorio
En el tnel voluntario Figura 2-16, el usuario remoto acta de LAC. El tnel es transparente para el proveedor como ocurre con los tneles basados en PPTP.
49
Entre las ventajas que podemos mencionar esta que es una solucin genrica, independiente de la plataforma. Puede soportar la transmisin a travs de enlaces WAN no IP sin la necesidad de IP. No se requiere configuracin en el proveedor y en el cliente. Permite que la autenticacin sea realizada por la organizacin y no por el proveedor. Provee control de flujo. Es ms rpida que L2F. Permite que clientes remotos con IP privada puedan conectarse a su organizacin a travs de redes pblicas. Se puede utilizar IPSec para poder brindar una mayor seguridad. Como desventajas podemos mencionar que es ms lento que PPTP o L2F cuando se utiliza IPSec para autenticacin de cada paquete y es ms complejo de implementar que PPTP.
Figura 2-16 L2TP Tnel voluntario Caracterstica Soporta multiprotocolo Soporta mltiples conexiones PPP por tnel Soporta mltiples conexiones por tnel Modos de Tnel Protocolo de Entrega PPTP Si No No Voluntario IP/GRE TCP Puerto 1723 L2F Si Si Si Voluntario y Obligatorio IP/UDP IP/FR IP/ATM UDP Puerto 1701 CHAP PAP SPAP RADIUS TACACS MPPE IPSec L2TP Si Si Si Voluntario y Obligatorio IP/UDP IP/FR IP/ATM UDP Puerto 1701 CHAP PAP SPAP EAP IPSec TACACS MPPE IPSec ECP
Protocolo de Control
Autenticacin
MS-CHAP PAP
Encriptacin
MPPE
Tabla 2-2 Comparativa protocolos Capa 2
50

En la siguiente seccin se describir los principales protocolos de tnel 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 extensin del protocolo IP que brinda seguridad a IP y a los protocolos de capa superior. Fue desarrollado para el nuevo estndar de IP versin 6 (IPv6) y luego adaptado para implementarlo en la versin 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 Autenticacin (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 Autenticacin 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 tnel 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 HMAC 14 (Hash Message Authentication Code) o Cdigo de autenticacin 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
51
IPSec utiliza algoritmos de encriptacin simtricos estndar de elevada fortaleza como 3DES, AES o Blowfish para asegurar la confidencialidad del trfico transportado. IPSec protege la comunicacin respecto de ataques de denegacin de servicio o ataques de repeticin, mediante el mecanismo de ventana deslizante. Los nmeros 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 informacin como claves secretas, algoritmos, direcciones IP utilizadas en la conexin etc. Estos parmetros 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 parmetros: Direcciones IP origen y destino del encabezado IPSec resultante (direcciones que coinciden con las de los pares que establecen la comunicacin segura). El protocolo IPSec a utilizar (AH o ESP). Algoritmo y claves secretas a utilizar. SPI (Security Parameter Index) de la SA. Es un nmero de 32 bits que identifica la SA.
Algunas implementaciones de bases de datos de SA permiten, adems, almacenar estos parmetros: Modo IPSec (tnel o transporte). Tamao de la ventana deslizante. Tiempo de duracin de la SA.
Una SA representa una conexin unidireccional. IPSec requiere que se definan dos SA para una comunicacin bidireccional o full duplex. Las asociaciones solo determinan como proteger el trfico. Las Polticas de Seguridad o SP establecen que trfico proteger y cundo. Las SP se almacenan a su vez en una SPD o base de datos de polticas de seguridad. Una SP define los siguientes parmetros: Direcciones IP origen y destino de cada paquete. En modo transporte estas direcciones coinciden con las IP almacenadas en la SA. En modo tnel estas podran diferir. Puerto y protocolo a proteger. Algunas implementaciones de IPSec no permiten estos parmetros, en estos casos se aseguran todos los paquetes. La SA a utilizar.
La SPD discrimina el trfico entrante o saliente, de forma tal que puede descartar el paquete en trnsito, ignorarlo o aplicar el servicio de seguridad de acuerdo a la asociacin de seguridad relacionada con esa entrada de la SPD. La SPD debe ser consultada durante el procesamiento de todo el trfico, entrante y saliente. Por esta razn esta contendr entradas diferentes para uno y otro. Adems cada interfaz de red que es protegida por IPSec tendr asociada sendas bases, de polticas y de asociaciones, para el trfico entrante y saliente.
52
Cada implementacin 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 accin 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 creacin de entradas y la definicin de los filtros selectores, adems 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 continuacin se determina si existe una Asociacin 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 autenticacin de encriptacin y las claves a utilizar. Cuando varios nodos participan de una VPN que utiliza IPSec para crear los tneles, surge un inconveniente al momento de compartir informacin para la comunicacin dentro de la VPN. Durante la creacin de las Asociaciones de Seguridad, se deben difundir las claves secretas y los algoritmos de encriptacin a utilizar. El intercambio de claves es un proceso crtico ya que en esta etapa an no hay un medio seguro establecido para transmitir esta informacin. 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 encriptacin simtrica mediante el algoritmo Diffie Hellman de intercambio de claves. Una vez compartidos en forma segura los datos necesarios, IKE se encarga en forma peridica de regenerar claves que protegen la confidencialidad de las claves para encriptacin simtrica.
Protocolo AH
Este protocolo se encarga de autenticar los datagramas asegurando la integridad de los datos incluyendo la direccin IP de origen, brindando adems proteccin contra ataques de repeticin de datagramas (replay attacks). Para establecer la integridad de los datos calcula un cdigo de autenticacin 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 Autenticacin del encabezado AH.
Figura 2-18 Encabezado AH
53
Los campos del encabezado AH son: Prximo Encabezamiento: identifica el tipo de datos de la carga til, es decir el protocolo de capa superior. Utiliza 1 byte. Longitud del encabezamiento: encabezado, utiliza 1 byte. Reservado: utiliza 2 bytes. SPI: Identifica la SA a utilizar. Utiliza 4 bytes. Nmero de Secuencia: Previene los ataques de repeticin (replay) en forma opcional y adems sirve para mantener una recepcin ordenada de paquetes. Este campo almacena un nmero que se incrementa en uno cuando un paquete es enviado en forma consecutiva a la misma direccin y con el mismo SPI. Utiliza 4 bytes. Datos de Autenticacin: Compendio (Digest) calculado mediante el HMAC, utilizado por el receptor para comparar lo recibido luego de aplicar la misma operacin al datagrama. identifica el tamao del
AH puede usarse solo o junto con ESP cuando se usa el modo tnel. Cuando se utiliza el modo transporte, el encabezado AH se coloca justo detrs 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 tnel, 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 autenticacin 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 traduccin de direcciones de red o NAT, debido a que su proteccin de integridad abarca campos del encabezado IP como la direccin de origen. Es adecuado si lo nico que se persigue es asegurar la integridad y autenticar el origen de los datos.
54
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 ms 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 vara si adems de la encriptacin se usa autenticacin (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 tnel 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 tnel. El proceso de encriptado incluye todos los campos posteriores al encabezado ESP, pero no este mismo. La autenticacin se aplica a lo encriptado ms 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 tnel.
55
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. Nmero de Secuencia: igual que en AH. Campo de datos IP (payload)
56
Vector de Inicializacin: utilizado en el proceso de encriptacin si este requiere datos de sincronizacin. Este vector sirve para que dos paquetes con la misma carga resulten en dos cargas encriptadas diferentes. Los algoritmos de encriptacin simtrica son vulnerables a ataques de frecuencia si no se utilizaran los vectores de inicializacin. Encabezado TCP Datos Cola ESP Relleno (Padding): Se usa en caso que el algoritmo de encriptado requiera que el texto a encriptar sea mltiplo de cierta cantidad de bytes (cifrado en bloques). Tambin es necesario para lograr un mltiplo 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 nmero mltiplo par de 16 bits. Longitud del anterior. relleno (Padding Length): identifica el campo
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 autenticacin: Es opcional y solo aparece si se utiliza ESP con autenticacin. Su longitud vara segn el algoritmo de Hash empleado: 16 bytes si es MD5 o 20 bytes si es SHA.
ESP puede utilizarse solamente con encriptacin o incluyendo adems autenticacin. Otra alternativa es con encriptado nulo, o sea sin encriptacin pero con autenticacin. ESP puede combinarse con AH. Si bien ESP puede autenticar, no abarca al encabezamiento IP externo, es decir no lo protege de cualquier alteracin en aquellos campos que no deberan cambiar. Por ejemplo, lo anterior podra derivar en la fragmentacin del datagrama si se alterara el campo correspondiente. Esta operacin podra permitir la insercin de datagramas de ataque.
Protocolo IKE
Tambin conocido como ISAKMP/Oakley (Internet Security Association and Key Management Protocol), este protocolo resuelve el problema ms importante relacionado con las comunicaciones seguras: la autenticacin de los pares, el intercambio de claves simtricas, creacin de las SA y actualizacin 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 Asociacin de Seguridad ISAKMP (ISAKMP SA). En la segunda, esta SA es utilizada para negociar y establecer las SA propias de la comunicacin IPSec (IPSec SA).
57
La autenticacin 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 autenticacin 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 proteccin de la identidad de los hosts intervenientes. Esto puede permitir un ataque del tipo hombre del medio. En la segunda fase el negocia en base a la ISAKMP SA, operacin de ataques del tipo finalmente son al menos dos, una protocolo intercambia propuestas de SA y las la cual brinda la autenticacin y protege la mencionado anteriormente. Las SA negociadas para cada direccin de la comunicacin.
Rendimiento
La utilizacin de IPSec en las comunicaciones requiere capacidad de procesamiento. En particular con ESP esta necesidad se evidencia en la encriptacin y desencriptacin de los paquetes, considerando la complejidad de los algoritmos empleados y en la autenticacin 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 verificacin en el otro, son tareas mucho ms complejas que el enrutamiento o la traduccin de direcciones. Las principales limitaciones no se originan en Internet, debido a que por naturaleza es un ambiente heterogneo donde el transporte y entrega de las tramas implica una operacin con el mejor esfuerzo y no asegura confiabilidad ni alta velocidad. De todas formas utilizando compresin previa a la encriptacin 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 trfico afectando directamente los paquetes transportados mediante UDP e inclusive el trfico 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 prctica se considera como asociado al tiempo en que tardan los datos en viajar desde el origen a su destino. En un dispositivo que cumple ms de una funcin, 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.
58
2.5.2 Generic Routing Encapsulation protocol (GRE)

El protocolo GRE o de encapsulacin genrica de enrutamiento, es un estndar de facto desarrollado por Cisco. Est diseado 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 seccin se basa en la descripcin 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 vnculo punto-a-punto con routers en cada extremo sobre una red IP. Se diferencia de IPSec en que maneja trfico 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 envo 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 tnel desencapsula un paquete GRE, el cual contiene un datagrama IP como carga, la direccin destino en el encabezado IP debe ser utilizado para reenviar dicho datagrama y el campo TTL debe ser decrementado. Si la direccin IP destino resultara ser del extremo que encapsul, entonces deber descartarse el datagrama para evitar un bucle o loop.
15 16
RFC 1701 - Generic Routing Encapsulation (GRE) RFC 1702 - Generic Routing Encapsulation over IPv4 networks
59
Operaciones Conjuntas con otros protocolos

La utilizacin ms comn y simple de este protocolo, es la creacin de tneles que permiten la utilizacin de un espacio de direcciones internas, a travs de un espacio pblico de direccionamiento, para el trfico 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 estn encriptados. Por lo tanto hace falta alguna medida de seguridad para poder utilizar GRE en un entorno VPN. Es en esta situacin que se utiliza en conjunto con IPSec, el cual le suma la seguridad de sus mecanismos de encriptacin y autenticacin. Pero esta relacin es bilateral, ya que IPSec falla en aquellos escenarios donde la naturaleza de las comunicaciones es del tipo multicast: propagacin de la actualizacin de rutas en un entorno de enrutamiento dinmico, trfico de voz y video, etc. La manera de salvar este escollo es mediante la encapsulacin del paquete multicast en un paquete GRE. A continuacin 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 tnel IPSec, desencapsular el paquete multicast y lo entregar a los dispositivos que integren el grupo multicast destino. Utilizar GRE para crear tneles como mecanismo para una VPN, genera algunas desventajas principalmente asociadas a la carga en tareas de administracin de la VPN, escalabilidad en cuanto al crecimiento del nmero de tneles, perfomance y QoS. Debido a que los tneles GRE deben ser configurados en forma manual, existe una relacin directa entre la cantidad de tneles a configurar y la cantidad de tarea administrativa necesaria para mantener dichos tneles. Tambin la capacidad de procesamiento requerida para la encapsulacin GRE, est en con el nmero de tneles configurados.
Figura 2-23 Encapsulamiento Multicast con GRE asegurado con IPSec
60
2.5.3 Multiprotocol Label Switching (MPLS)

MPLS se dice multiprocolo porque se aplica a cualquier protocolo de red, pero su uso ms habitual es con el protocolo IP. La esencia de MPLS es la generacin de pequeas etiquetas (labels) de tamao fijo que cumplen el rol de un encabezado IP pero con menos informacin. Esta etiqueta se usa para tomar las decisiones de enrutamiento del paquete. MPLS no es un protocolo de capa 2 ni de capa 3 especficamente, 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 direccin destino) para decidir el siguiente salto. Esta decisin es tomada en forma independiente por cada router basado en su anlisis 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 seleccin del siguiente salto se compone de dos funciones. La primera consiste en clasificar o particionar el conjunto completo de paquetes en clases de equivalencia, tambin denominadas FEC (Forwarding Equivalence Class). La segunda funcin mapea cada FEC con el siguiente salto. Los paquetes pertenecern a una determinada FEC, si la direccin IP destino de cada uno de ellos coincide, en la manera ms exacta, con algn 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 asignacin 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 enva la etiqueta tambin 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 travs 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 ncleo de la red MPLS, solo se encargan de reenviarlo hasta el router de borde de egreso de la red. Este mtodo de reenvo permite que, una vez que el paquete fue clasificado en una FEC, no se efecte ningn anlisis posterior del encabezado por parte de los routers que participarn 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 mtodos de tneles habituales para implementar VPN.
61
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, nmeros de usuarios, complejidad en el esquema de enrutamiento, aplicaciones crticas, volmenes de trfico, patrones de trfico, habilidad del propio personal de networking, etc. Existen dos opciones: VPN MPLS de capa 3 o capa 2. Uno de los modelos de mayor aceptacin 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 informacin de enrutamiento de la VPN a travs del backbone mientras que MPLS se encarga de reenviar el trfico 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 cliente y solapamiento de direcciones privadas. en la red del
Soporte de solapamiento de VPN, es decir que un sitio puede pertenecer a ms de una VPN.
Las VPNs BGP/MPLS toman un datagrama IP de la red del cliente, determinan la direccin IP destino buscando en una tabla de reenvo y luego envan ese datagrama hacia su destino a travs de la red del proveedor mediante un LSP.

Adems de los protocolos de capa 2 y capa 3, se pueden considerar, adems, dos protocolos para crear tneles pero en las capas superiores. En particular entre la capa de transporte y de aplicacin. Se describirn 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 travs de una red insegura. Si bien su cometido principal es la creacin de una sesin remota mediante un tnel a un equipo remoto, es posible la transmisin de otra clase de trfico TCP mediante la redireccin de puertos.
17
RFC 4251 - The Secure Shell (SSH) Protocol Architecture
62
Este protocolo consiste de tres componentes principales: Protocolo de capa de transporte: brinda autenticacin del servidor, confidencialidad e integridad con PFS (Perfect Forward Secrecy) ejecutndose sobre la conexin TCP/IP. El protocolo de autenticacin del cliente: protocolo de transporte. opera sobre el
Protocolo de conexin: multiplexa el tnel en varios canales lgicos y se ejecuta sobre el protocolo anterior.
SSH utiliza, en un principio, autenticacin 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 pblicas de host (host key)18. Esta capa no realiza la autenticacin basada en usuario, la cual es relegada a las capas superiores. Este procedimiento requiere que el cliente confe en la clave que le presenta el servidor. Para esto el cliente puede tener un conocimiento previo de la misma y efectuar una comparacin, mediante algn mecanismo de firma o encriptacin de un hash o certificando la validez de la misma a travs de una Autoridad Certificante o CA. Si bien la segunda alternativa facilita la administracin del mapeo nombre de servidor/clave pblica, requiere la presencia de una infraestructura PKI (Public Key Infraestructure), la cual no es simple de implementar e implica costos econmicos importantes para la organizacin. El protocolo de capa de transporte de SSH, es el encargado de autenticar el servidor y negociar el mtodo de intercambio de clave, los algoritmos de encriptacin simtrica, de clave pblica, de autenticacin de mensaje (HMAC) y de hash. El mtodo de intercambio de claves es importante ya que define como generar las claves de sesin a utilizar en la conexin para encriptar y firmar digitalmente, adems de establecer como autenticar al servidor. El protocolo de capa de autenticacin de SSH19 se encarga de efectuar la autenticacin basada en usuario. SSH soporta autenticacin basada en usuario mediante clave pblica, passwords y basada en equipo. En el caso de usar passwords, estas son encriptadas cuando el paquete de autenticacin es procesado por la capa inferior de transporte. La autenticacin 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 pblica del cliente. Luego se verifica que el nombre de usuario enviado por el cliente tenga autorizacin. Este mtodo no es aconsejable en escenarios que requieran seguridad.
18 19
RFC4253 The Secure Shell (SSH) Transport Layer Protocol RFC 4252 SSH Authentication Protocol
63
Finalmente el protocolo de capa de conexin se ejecuta por encima de los protocolos de transporte y autenticacin de SSH. Brinda sesiones interactivas de login, ejecucin remota de comandos, reenvo de trfico TCP/IP y de conexiones del servicio de manejo de ventanas X11. Todo estas conexiones son establecidas mediante canales que son multiplexados a travs de un nico tnel establecido por el protocolo de capa de transporte, a esto se lo denomina multiplexacin ascendente20 (upward multiplexing).
2.6.2 Secure Sockets Layer/Transport Layer Security (SSL/TLS)

SSL fue creado originalmente para asegurar el trfico web, pero se utiliza tambin para asegurar protocolos diferentes a HTTP. Brinda confidencialidad a la capa de transporte mediante el uso de criptografa simtrica mientras que la autenticacin y manejo de claves se realiza mediante la criptografa de clave pblica. TLS21 esta basado en la versin 3 de SSL, pero no es el mismo protocolo. Se trata de un estndar sobre el cual se basan implementaciones tantos comerciales como abiertas. Brinda privacidad e integridad a los datos transmitidos en una comunicacin entre dos aplicaciones. La interoperabilidad de SSL/TLS es muy alta, no es comn los problemas en la interaccin entre clientes y servidores de diferentes fabricantes. Dado que no se utiliza el encabezado IP para el procesamiento, sino la conexin autenticada y establecida, SSL/TLS no es afectado por la presencia de dispositivos que efecten operaciones de traduccin de direcciones o NAT. SSL/TLS soporta una variedad de mtodos de autenticacin, siendo el ms comn el uso de certificados digitales para la autenticacin tanto del servidor como del cliente (opcional). Las VPNs SSL pueden transportar cualquier trfico TCP inclusive trfico 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 aplicacin 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 caracterstica hace que una solucin VPN SSL sea ms 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 TOPOLOGAS
La topologa aplicada a las redes de datos, describe las relaciones entre los componentes de una red. Su aplicacin ms simple define como se interconectan los dispositivos que integran una red. Adems, el uso correcto de la terminologa topolgica evita confusiones cuando se hace referencia a esquemas de redes.
20 21
Data & Computer Communications Cap. 2 William Stallings RFC 4346 - The Transport Layer Security (TLS) Protocol Version 1.1
64
La clasificacin ms bsica de las topologas est en funcin de la naturaleza de la relacin de conectividad de los componentes de la red. Puede ser de naturaleza fsica como un medio de transmisin (cable tecnologa ethernet, fibra ptica, enlace satelital etc.) o de naturaleza lgica, como la ruta que utiliza un flujo de bytes para conectar dos host. En este caso se considerarn las topologas desde una perspectiva lgica, debido a que las redes privadas virtuales son un objeto lgico, tal como se las define en el primer captulo. Lo ms importante al estudiar la topologa de una red es el impacto de esta sobre otros aspectos que influyen en el desempeo de la misma. Uno de estos aspectos es la escalabilidad la cual es crtica cuando se trata de redes que tienden a crecer o que el nmero de nodos a interconectar es numeroso y variable. La escalabilidad de una red se puede definir en funcin de tres caractersticas de su diseo22: Capacidad de manejar mas conexiones Facilidad de mantenimiento Costo
En el caso particular de las VPN, existen otros aspectos que estn influenciados por la topologa: el mecanismo de distribucin de claves para la autenticacin de los nodos y la distribucin de la informacin de enrutamiento necesaria para permitir la comunicacin entre los componentes de una misma VPN.
2.7.1 Escenarios
En el terreno de las redes privadas virtuales existen bsicamente tres escenarios que describen las relaciones entre los nodos de una VPN. Las conexiones entre sitios o redes, la conexin entre un host y una red y la conexin entre solo un par de hosts. El escenario red a red (Figura 2-24) presenta la conexin de dos o ms subredes mediante uno o ms tneles. Cada subred consiste de un gateway y al menos un host. EL gateway posee dos interfaces de red, una para conectarse al tnel y la restante para conectarse con la subred interna. El gateway realiza el proceso de creacin y eliminacin del tnel, as cmo la aplicacin de mecanismos de seguridad al trfico que reenva.
22
Kolesnikov, Hatch, Davis, Mongol - Building Linux VPN: VPN Fundamentals - Cap 2
65
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 organizacin se encuentran fsicamente 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 podrn establecer una comunicacin segura. Este escenario es una reduccin del caso host a red. Si hubiera necesidad de comunicar ms hosts, entonces seran ms apropiados los escenarios anteriores. Estas formas de relacin determinan los esquemas topolgicos ms 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 tambin es posible combinar alguna de ellas e implementar una topologa hbrida. Su aplicacin a las VPNs posee sus ventajas y desventajas.
66
2.7.2 Topologa Punto a Punto

Esta es la topologa ms simple, ya que es una conexin directa entre dos entidades. Esta relacin de conectividad directa an es vlida si en un nivel inferior existen entidades cuya tarea es el reenvo de la comunicacin hasta llegar al destino. Es decir, es una comunicacin directa en la capa N an cuando en la capa N-1 es necesario atravesar varios nodos hasta llegar al destino23. Esta topologa se puede encontrar en VPNs, como casos particulares de otros esquemas ms 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 dems extremos. Los ejemplos mas simples de VPNs con esta topologa son las tradicionales de capa de enlace basadas en servicios ATM o Frame Relay, ya que establecen una conexin punto a punto entre sitios de una organizacin. Tambin se puede considerar los tneles 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 ms especfico 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 tneles 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 tneles MPLS (LSP) establecidos a travs del backbone. Esta solucin 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 administracin, adems el aumento de los tneles 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 ncleo 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 situacin se mejora la escalabilidad utilizando un nmero fijo de LSP entre los dispositivos PE del backbone del proveedor. Luego se crean conexiones emuladas punto a punto (pseudowires) entre los PE mediante tneles 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 24
Designing Addressing Architectures for Routing & Switching Howard Berkowitz, Cap. 2 draft-ietf-pwe3-atm-encap; draft-ietf-pwe3-frame-relay; draft-ietf-pwe3-ethernet-encap.
67
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 situacin cada dispositivo PE usa BGP multiprotocolo para anunciar las VPN y dispositivos CE que este controla. Esta informacin acompaa las etiquetas MPLS utilizadas por los PE para reenviarse datos entre s. De esta forma, cuando los CE reciben esta informacin, poseen los datos necesarios para crear los pseudowires25 sobre los PE.
2.7.3 Topologa Punto a Multipunto

Esta topologa permite establecer ms de un camino desde un lugar a mltiples destinos. Cualquier transmisin de datos, originados en un punto de conexin central es recibida por todos los puntos de conexin perifricos, mientras que la comunicacin en el otro sentido, desde la periferia, slo 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 configuracin de malla completa. Una VPLS es establecida por un proveedor de servicios y emula una LAN tradicional. Permite conectar varios segmentos de LAN, distantes geogrficamente, sobre una red de conmutacin de paquetes de manera que las redes remotas se comporten como una nica LAN. En esta situacin los equipos CE no deben seleccionar el pseudowire para reenviar los datos para un destino determinado (topologa punto a punto); simplemente reenvan todo el trfico al dispositivo PE del proveedor, quien se encarga de enviarlo al destino correspondiente.
25
draft-kompella-ppvpn-l2vpn
68
Esto es posible en redes MPLS donde se establece una topologa de malla completa de pseudowires entre los dispositivos PE del proveedor que integran una determinada VPLS. Gracias a este esquema los PE pueden realizar replicacin de paquetes (inundacin por destino desconocido, broadcast, multicast) y aprendizaje de direcciones MACs tal como lo hara un bridge o switch ethernet. Para simplificar la configuracin de una VPLS, son necesarios mecanismos automticos para obtener informacin de los integrantes de la VPLS, como llegar hacia ellos y conectarse finalmente. Esto facilita tambin el agregado de nuevos nodos y la administracin de las conexiones (manejo de pseudowires) entre ellos. De lo contrario el manejo y escalabilidad de la VPN se vera afectada.
2.7.4 Topologa Estrella (Hub and Spokes)

Esta es la topologa ms comn en VPNs. Existe un gateway VPN o concentrador (hub) y una serie de clientes (spokes) que establecen una conexin punto a punto con este, un tnel de hecho. Para que pueda existir comunicacin entre los clientes remotos, el trfico de datos deber ir desde el cliente emisor hasta el concentrador, luego este retransmitir esos datos hacia el cliente receptor. No existe una conexin directa entre los clientes, toda la comunicacin deber atravesar primero el concentrador. Esta topologa afecta la escalabilidad en cuanto a que est limitada al desempeo y la capacidad de procesamiento del concentrador. Este deber soportar conexiones simultneas. Por esta razn el desempeo 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 geogrficamente cerca, igual debern enviar su trfico al concentrador en lugar de utilizar una conexin directa entre ellos. Sin embargo, este esquema tiene la ventaja de una administracin centralizada, respecto del monitoreo, mantenimiento, control de accesos, registro de eventos. Adems el hecho de agregar un nuevo componente a la VPN es simple debido a que esta operacin se centraliza en el hub. Una forma de paliar la desventaja que significa un nico punto de falla, es una variacin de la topologa donde exista ms de un concentrador, tanto para brindar redundancia como para balancear la carga relacionada con las conexiones simultneas 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 trfico emitido desde el cliente a travs de la duplicacin de la conexin con el concentrador. Si bien esta organizacin brinda la mxima disponibilidad, es prohibitiva en trminos de costo en equipos y en la poca conveniencia de invertir recursos en el extremo del cliente. Esta topologa y sus variantes se aplican en los escenarios red a red, tanto para conectar los sitios de una misma organizacin como as tambin cuando se implementan VPN extranets con sitios de otras organizaciones.
69
Las VPN sitio a sitio utilizando IPSec son un ejemplo de la aplicacin de esta topologa. Es comn considerar el uso del protocolo GRE para permitir el trfico 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 nmero de asociaciones de seguridad activas a soportar, as como su deteccin, eliminacin 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 tneles IPSec: Las polticas de seguridad que se aplican pueden impactar en la perfomance del concentrador. La seleccin de algoritmos criptogrficos fuertes lleva a una sobrecarga de la capacidad de cmputo. Hay que balancear el requerimiento de la poltica y la carga en el mantenimiento de los tneles con un clculo apropiado de las necesidades futuras de agregaciones de nodos clientes a la VPN. Capacidad de procesamiento criptogrfico: este aspecto esta relacionado directamente con el anterior, en trminos del throughput de paquetes por segundo que es capaz de procesar el mdulo de encriptacin. Capacidad de mantenimiento de tneles GRE: Si bien la mayora de los dispositivos VPN soportan los tneles GRE, no lo implementan a nivel de hardware. Si se requiere esta encapsulacin, la misma no deber limitar el throughput o el procesamiento en el concentrador.
2.7.5 Topologa Mesh)
de
Malla
Completa
o Parcial
(Full
or
Partial
En un diseo de malla completa (full mesh), cada dispositivo se comunica en forma directa con todos los dems. En el caso de malla parcial (partial mesh) solo ciertos dispositivos tienen conexin directa entre s. La razn de ello radica en que no todos requieren ms de una conexin. Solo aquellos que requieren alta disponibilidad y que la interrupcin de una de sus conexiones no deje al sitio incomunicado con el resto. Este modelo tiene beneficios son: varios beneficios y una gran desventaja. Los
No existe un nico punto de falla, los dispositivos no dependen de un concentrador para la comunicacin dentro de la VPN La perfomance general no est limitada a un solo sistema. Aquellos dispositivos que estn prximos geogrficamente, pueden comunicarse directamente sin intermediario.
70
La desventaja radica en el incremento del mantenimiento en cuanto a la distribucin de las claves para asegurar las comunicaciones o en la distribucin de informacin de enrutamiento. En particular si se usa IPSec, la creacin de asociaciones de seguridad necesarias para cada nodo que se sume a la VPN representa un costo en el mantenimiento. La situacin puede mejorar si se utilizan mtodos automticos para la distribucin de claves, o la transmisin dinmica de rutas. Nuevamente los escenarios red a red implementan esta topologa 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 topologa 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.
71
CAPTULO 3 VPNs DE ACCESO REMOTO

3
72
3.1 INTRODUCCIN
En un principio el acceso remoto se caracterizaba por la utilizacin de la red de telefona urbana, mediante lneas discadas, para conectarse hacia la red de datos de la organizacin. El usuario perteneca a esta organizacin. Estas conexiones se establecan desde la ubicacin del usuario hasta el servidor RAS. Los protocolos utilizados se basaban en PPP y las funciones AAA es decir Autenticacin, Autorizacin y Auditora, estaban a cargo de un servicio especfico como RADIUS. Se asuma 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 comunicacin. Teniendo en cuenta esto, la seguridad de la conexin estaba limitada respecto del control de acceso en el RAS, a un par usuario/contrasea. En la actualidad, las tecnologas de acceso a Internet mediante ISP, como un servicio dial-up o DSL, poseen carcter masivo y relativamente barato para los usuarios, brindando un servicio por dems adecuado para reemplazar los accesos discados directos que podan ser extremadamente caros si el usuario remoto se encontraba fuera de los lmites del sistema de telefona local. Sin embargo el inconveniente es la naturaleza pblica 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 conexin con un gateway de seguridad o servidor de acceso remoto, para luego configurar un tnel por donde fluirn los datos de la comunicacin en forma segura. Esta comunicacin generalmente se establece desde una red corporativa diferente a la red destino. Es habitual la utilizacin de la red de un proveedor de servicios de Internet o ISP (Internet Service Provider) con una conexin 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.
73
3.1.1 Requerimientos bsicos de seguridad

Existen requerimientos bsicos en cuanto a la seguridad, los que pueden ser clasificados en: autenticacin de los extremos de la conexin, configuracin de la poltica de seguridad (control de acceso y autorizacin) y auditora.
Autenticacin de los extremos

Existen dos clases de autenticacin: la autenticacin del origen de datos y la autenticacin de la entidad. En el primer caso se asegura que los paquetes de red se originan desde un nico sistema, host, usuario o aplicacin, mientras que en el segundo caso se asegura que quien genera dichos paquetes, es quien dice ser. Ambos tipos de autenticacin se relacionan entre s, la autenticacin del origen de datos depende de la autenticacin 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 informacin del origen de datos (IP, puerto, protocolo de transporte) a esta relacin de confianza establecida por el proceso de autenticacin. La entidad autenticada puede ser un host, un usuario, o ambos. Por esta razn la autenticacin puede ser a nivel de mquina 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).
Autenticacin a nivel de mquina/usuario

Cuando dos partes se comunican de manera segura, la fase inicial de ese proceso corresponde a la autenticacin del cliente remoto y/o del servidor. En el caso de que el cliente posea las credenciales para intentar una autenticacin y no requiera la participacin 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 intervencin de un usuario donde verifique algn 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 autenticacin de usuario implica la presentacin de alguna informacin de autenticacin en forma directa hacia el servidor durante la fase de autenticacin. 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 interaccin 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.
74
En general los requerimientos de autenticacin son asimtricos. 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 autenticacin a nivel de mquina. Desde la perspectiva del servidor la situacin 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 organizacin. Autenticar a un usuario requiere alguna forma de entrada por parte de este para el envo de credenciales y este mecanismo debera ser renovado peridicamente. Este ltimo aspecto debera ser un equilibrio entre el intervalo de renovacin (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 organizacin al usuario mvil. Se asume que el dispositivo es confiable porque, como equipamiento de la organizacin, cumple con las polticas de seguridad de la misma y tendr el software necesario, tanto el cliente VPN como antivirus, firewall y dems herramientas de seguridad instaladas y actualizadas que el staff de administracin, con los privilegios correspondientes, se encargaron de incorporar al equipo.
3.1.2 Configuracin de las polticas de seguridad

Es posible configurar polticas de acceso tanto en como en el gateway de seguridad. En el primer caso se puede acceso a Internet desde el cliente, tambin se redirija a con la red de la organizacin, evitando que el trfico HTTP inseguras. el cliente remoto considerar que el travs del tnel lo haga por redes
En cuanto a polticas aplicables al gateway de seguridad, se puede establecer la asignacin dinmica de permisos de acuerdo al usuario o sistema que establece la conexin. Este esquema puede valerse de un mapeo uno a uno, respecto de la direccin IP origen de la conexin y los permisos correspondientes. Una alternativa ms escalable sera asociar una serie de permisos a un conjunto o rango de direcciones.
3.1.3 Auditora
La auditora se refiere a la recoleccin de informacin de estado de las conexiones dirigidas al gateway de seguridad por parte de los clientes remotos. El propsito de esta operacin es mantener la seguridad e integridad de la red destino de la organizacin. Desde una perspectiva de la seguridad, es de utilidad tener el registro del tiempo de inicio y fin de una conexin. Es necesario un mtodo para monitorear el tiempo de conexin de los clientes y poder manejar los casos en donde estos finalicen su conexin en forma no explcita. Para estas situaciones se utiliza un mecanismo de heartbeat por el cual el cliente remoto enva una seal luego de un tiempo para indicar al gateway que an se mantiene en lnea. Pasado un tiempo (umbral de reset), sin recibir una nueva seal por parte del cliente, el gateway da por finalizada la conexin.
75
El intervalo de heartbeat puede influir en forma negativa si es demasiado corto. Si se presenta congestin en la red, es probable que se pierdan algunos paquetes de heartbeat del cliente y el gateway finalice la conexin al alcanzar el umbral de reset rpidamente. Ambos parmetros deberan poder ser ajustados mediante configuracin o durante la negociacin de la conexin.
3.2 ESCENARIOS
Existen escenarios comunes en las VPNs de acceso remoto: Tele trabajadores/usuarios mviles operando dispositivos propios Acceso con extranet un dispositivo local a la red local desde una
Acceso desde una extranet con un dispositivo de esta a la red local Acceso de usuarios mviles desde dispositivos pblicos bsicos de
Las diferencias se aprecian en los requerimientos seguridad que se necesitan cumplir en cada escenario.
3.2.1 Tele trabajadores/usuarios mviles operando dispositivos propios

Este escenario presenta a usuarios de una organizacin que se encuentran fuera de los lmites de esta y requieren acceso a la red de datos. Estos pueden estar en sus casas o en un sitio geogrficamente distante. En cualquier caso estos usuarios estn operando equipos de la organizacin o personales, en este ltimo caso deben cumplir con las polticas de seguridad. El usuario utiliza la red pblica y la de un ISP para establecer la conexin. Para el caso del gateway VPN, ste debe autenticarse a nivel de equipo, lo cual es suficiente. En cuanto al cliente es recomendable la autenticacin a nivel de usuario. Para el caso de conexiones permanentes es conveniente la renovacin peridica de las credenciales del usuario. Esto puede ser opcional en el caso de conexiones discadas de corta duracin. En trminos de polticas de seguridad aplicable al cliente, se destaca el hecho de que si el cliente tiene acceso a Internet, entonces tambin es posible un acceso recproco desde Internet hacia el cliente, todo esto mientras esta conectado a la red local de la organizacin. Es recomendable desestimar el acceso a Internet mientras se utilice el acceso VPN. Como alternativa se puede derivar el trfico hacia y desde Internet a travs del tnel de la VPN donde podra estar sujeto a la aplicacin de alguna poltica de seguridad. Otra opcin sera aplicar esa poltica directamente en el cliente para el trfico Internet sin requerir la derivacin de ese flujo hacia la red local.
76
3.2.2 Acceso con un dispositivo propio a la red local desde una extranet
En esta situacin, hay una extranet establecida. La extranet puede reunir dos o ms 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 relacin 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 porttil. Su intencin es conectarse a su red local. Aqu los requerimientos de autenticacin en el cliente son a nivel de usuario ya que es necesario asegurar que quien inici la conexin sea el mismo usuario activo durante todo el tiempo que dure la misma. Es recomendable la doble autenticacin, tanto a nivel de mquina como de usuario. Cualquiera sea el caso, la autenticacin deber ser renovada frecuentemente. El gateway o servidor VPN deber realizar la autenticacin a nivel de mquina. Si bien el dispositivo pertenece a la corporacin A, no se le puede aplicar la poltica para derivar todo su trfico hacia la red de pertenencia ya que se encuentra en los dominios de la red B y de hecho posee su configuracin 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 trfico 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 excepcin que el dispositivo es externo a la red destino, esta fuera del control de esta. Nuevamente el tipo de autenticacin ms importante debe ser a nivel de usuario ya que a nivel de mquina es difcil de determinar el nivel de confianza sobre el equipo. Las credenciales del usuario deben renovarse peridicamente.
3.2.4 Acceso de usuarios mviles desde dispositivos pblicos

Los dispositivos de acceso son pblicos y no estn bajo el control de la organizacin. En el caso donde el dispositivo utilizado no sea propio o no pertenezca a la organizacin, por ejemplo un usuario remoto mvil operando una PC en un cyber caf, la autenticacin a nivel de dispositivo del cliente carece de sentido. Tampoco es aconsejable el uso de claves estticas, ya que pueden ser capturadas mediante un programa de captura de teclas instalado en dicha PC, an 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 organizacin, 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 informacin que permita autenticar al servidor, previo a la conexin, por ejemplo una clave precompartida (su uso no es aconsejable) o un certificado de clave pblica de la CA que emiti el certificado del gateway.
77
Esta informacin se incorpora al dispositivo al momento de la instalacin de un software cliente VPN. Esta operacin suele requerir privilegios de administrador, por lo que sera difcil realizarlo con un dispositivo pblico. Peor es la situacin donde s es posible hacerlo, porque si se obtienen privilegios para la instalacin del cliente se tiene que asumir que un programa malicioso tambin 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 mayora 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 adems unos mecanismos de autenticacin. Como complemento a este acceso limitado se puede implementar lo que se conoce como un sistema de Evaluacin y Validacin 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 conexin. Esto se logra buscando virus o programas maliciosos mediante un anlisis 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 conexin, caso contrario se impide el acceso. Se considera imprudente la utilizacin 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 autenticacin, tanto a nivel de dispositivo como de usuario.
3.3 ARQUITECTURA DE SEGURIDAD

Cuando desde la propia red local se interacta con equipos presentes en redes externas como extranets, o pblicas como Internet, se accede a un entorno fuera del control de la organizacin, por lo tanto inseguro. Permitir interactuar equipos situados en estos entornos con los propios de la organizacin es un panorama an ms crtico que requiere tener presente la seguridad considerando: Las polticas de seguridad de la organizacin y definir aplicacin tanto a los clientes como al servidor VPN. su
Definir claramente los servicios de la red local que estarn disponibles para los usuarios remotos. Control del trfico entrante y saliente. Un adecuado manejo del servicio de autenticacin de los usuarios remotos. Una correcta disposicin del gateway VPN en el esquema de la red junto con una adecuada interaccin con el firewal.
78
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 auditora asociados a los accesos a la VPN. que registre los eventos
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 combinacin de hardware y software utilizado para implementar una poltica de seguridad que controla el trfico de datos entre dos o ms redes. La poltica se aplica solamente sobre la red o redes que estn bajo el control de la organizacin26. Al conjunto formado por la red o redes incluidas en el alcance de la poltica se lo denomina dominio de seguridad. Es necesario tener claro los lmites de este dominio para evaluar en forma correcta la aplicacin de la poltica. La interseccin 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 organizacin. Un gateway o servidor VPN permite el acceso a usuarios remotos ubicados fuera del dominio de seguridad de la organizacin, como Internet, la red de un proveedor u otra red perteneciente a un dominio de seguridad diferente. Por esta razn deber estar ubicado en el mismo mbito que el firewall. En general el gateway VPN es parte del conjunto de herramientas y tecnologas que brindan seguridad a la red de la organizacin. Existen diferentes topologas relacionadas con la ubicacin del gateway VPN, en la mayora de ellas es aconsejable el diseo 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 pblicos de una organizacin. Estos son accedidos desde el exterior, por esta razn deben estar separados de la red local de la organizacin. 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 separacin cuenta con al menos tres interfases de red: para la red externa, la DMZ y la red interna.
Gateway VPN sobre el Firewall

La solucin ms natural y simple es la implementacin 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 lnea de productos firewall ASA PIX. Este diseo permite tener un nico punto de entrada a la red de la organizacin, donde el firewall autoriza las conexiones salientes hacia el exterior, previene las conexiones entrantes no autorizadas hacia el interior y la funcin de gateway VPN es administrar las conexiones de los usuarios remotos, autorizando su acceso y encriptando su trfico.
26
Deploying Firewalls Fithen,Allen,Stoner - Carnige Mellon University
79
Las ventajas de este esquema son: Centraliza el control de toda la seguridad, disminuye el costo de administracin. con lo que se
La interaccin Firewall-Gateway VPN es natural y directa, lo que facilita la creacin dinmica de reglas del firewall aplicadas al trfico VPN. Menos equipamiento.
Figura 3-2 Gateway VPN sobre el Firewall
Las desventajas son: nico punto de falla. El protocolo de tnel no es transparente al firewall. Una configuracin incorrecta de las reglas del firewall podran permitir el acceso, a travs del espacio de direcciones de la VPN, de trfico 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 mdulos para des/encriptar. Si se incrementa la cantidad de clientes remotos, el punto anterior ser ms evidente. Costo de entrenamiento para un uso adecuado del dispositivo, si se trata de una solucin propietaria.
80
Gateway VPN y Firewall en paralelo

Como en el diseo anterior los servicios se sitan separados fsicamente en diferentes equipos, pero esta vez la separacin del procesamiento es completa. Este esquema se basa en una DMZ estndar donde ambos dispositivos tienen acceso a la red interna y a la red externa, establecindose una zona buffer entre el gateway predeterminado de la red local, el firewall y el Gateway VPN. Las ventajas son: Procesamiento en paralelo de trfico especfico sobre los dispositivos correspondientes. Se desliga completamente al firewall de atender el trfico 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
81
Las desventajas son: 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 trfico no permitido. Incremento en el costo de administracin y mantenimiento configuraciones. Mayor costo econmico por la adquisicin de equipos de las
Este diseo 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 despus de ste un firewall dedicado para asegurar el trfico 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 tnel.
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 trfico VPN es atendido por el Gateway VPN y es filtrado por el firewall a travs las interfaces de ambos equipos en la DMZ, para finalmente reenviarlo a la red local interna. Este es un diseo simple y muy seguro, por lo tanto el ms adecuado. Las ventajas son: Distribucin del procesamiento del trfico entrante, el gateway se encarga estrictamente del trfico VPN. Menor configuracin relacionada al trfico VPN en el firewall. Mayor seguridad al trfico de la VPN que llega a la red interna. El trfico VPN puede ser analizado para prevenir ataques en su paso por la interfaz de la DMZ del firewall. El procesamiento del trfico VPN, en el firewall, es independiente del protocolo de tnel utilizado y no se requiere procesamiento NAT.
82
Figura 3-4 Gateway VPN con DMZ nica
Las desventajas son: 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 mxima 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 travs de dos DMZ establecidas. Este esquema, si bien es muy seguro, agrega demora al procesamiento del trfico ya que se requiere atravesar dos redes adems del doble anlisis por parte del firewall, sin embargo el trfico VPN entrante a la red interna es confiable. Las ventajas son: Acceso remoto hacia la red interna es muy seguro. Separacin del flujo VPN entrante y saliente, lo que aplicarle reglas de control de forma ms especfica. permite
83
Figura 3-5 Uso de una doble DMZ
Las desventajas son: Doble procesamiento del trfico VPN, proveniente de los clientes remotos mediante la DMZ Outside y de la red interna a travs de la DMZ Inside. El firewall es dependiente del protocolo de tnel, al menos durante el procesamiento en su interfaz conectada en la DMZ Outside. Alto costo administrativo de la configuracin
3.3.2 Disponibilidad
El servicio de acceso remoto en una organizacin representa un valor activo de la misma, ya que permite un mejor desarrollo de las actividades de sus integrantes. Muchas veces ms que por una razn de eficiencia es por una necesidad estratgica, en concordancia con los objetivos que persigue la organizacin. Es decir, la presencia de tal recurso tiene un fundamento y cumple con un requerimiento importante de la organizacin. 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 funcin de los costos que puede asumir la organizacin ya que implementar HA no es barato.
84
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 automtica a un dispositivo o equipo redundante para que tome el manejo del servicio o funcin 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 funcin, 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 sincronizacin entre las unidades de la informacin de las sesiones VPN de manera de minimizar la interrupcin durante el failover. Active-active failover: en este caso ambas unidades estn operando y manejando el trfico. Mediante el protocolo de failover se monitorea el estado de ambos equipos. Dado que ambos equipos estn operando la falla de uno de ellos activar el mecanismo de failover sin interrumpir el servicio. Mutiunit clustering: similar al esquema anterior pero con ms 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 nmero de clientes remotos. Esta solucin es la ms costosa y requiere entrenamiento del personal para una correcta administracin.
Figura 3-6 Alta disponibilidad con Failover Activo
85
Figura 3-7 Alta disponibilidad mediante un Cluster
3.3.3 Autenticacin, Autorizacin y Registro (AAA)

El manejo efectivo de los usuarios VPN y de sus privilegios de acceso es vital en cualquier diseo de VPN de acceso remoto. Existen dos aspectos principales a considerar: Una solucin segura y escalable para autenticar usuarios Decisiones basadas en atributos de usuario y de seguridad para definir los permisos de acceso.
La tecnologa AAA permite establecer un esquema de seguridad dinmico 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. Adems es necesaria la asignacin de privilegios en forma dinmica de acuerdo al rol del usuario que intenta acceder remotamente. Adems de validar al usuario, el proceso de autenticacin permite asignar al usuario a una poltica de grupo. Esta asignacin se realiza en base a la informacin de grupo del usuario en la organizacin y a otros atributos. Esta poltica de grupo define los privilegios de acceso del usuario para la fase de autorizacin. Dentro de los protocolos AAA reconocidos est RADIUS cuyas especificaciones aparecen en la RFC 2058. ste posee la condicin de protocolo estndar 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 pblica internacional cuyo mejoramiento constante de Internet. Su misin se documenta en la RFC-3935.
objetivo
es
el
86
Componentes Principales
Dentro de una arquitectura AAA existen componentes que interactan entre s. Esta distincin no refiere a dispositivos fsicos dedicados sino a contenedores lgicos 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 Aplicacin de Poltica (PEP): tambin 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 Informacin de Poltica (PIP): es un repositorio de informacin que ayuda a tomar la decisin 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 Decisin de Poltica (PDP): es el componente principal de la arquitectura que toma la decisin de permitir o no el acceso. Este recibe la solicitud de acceso del cliente a travs del PEP. Tambin consulta al PIP para obtener informacin necesaria para tomar la decisin. Tambin puede enviar al PEP informacin especfica para la autorizacin del cliente para que el PEP aplique las restricciones en los privilegios de acceso correspondientes. Sistema de Registro y Autenticacin: este componente registra los diferentes eventos relacionados con el acceso de los clientes remotos. Adems 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 autenticacin
El diseo de un sistema AAA vara dependiendo del tamao de la red y de la disparidad de mtodos de acceso que se requieran. En general las opciones para servidores de autenticacin pueden dividirse en dos categoras: 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 interaccin es mediante el protocolo RADIUS. Esta es una solucin flexible ya que el propio protocolo soporta la interaccin con una gran variedad de mtodos de acceso.
87
Gateway VPN interactuando con un PIP: en esta situacin depende del gateway interactuar con el servidor de identidad o PIP, por lo tanto deber soportar la interaccin con diferentes tipos de servidores de identificacin. Un aspecto a tener en cuenta con este modelo es la capacidad del gateway para obtener informacin adicional del cliente o usuario para aplicarlo a la fase de autorizacin. Soportar esta caracterstica requiere una mayor dependencia entre el gateway y el PIP.
3.3.4 Administracin y monitoreo

La administracin y monitoreo del servicio de VPN son aspectos importantes a considerar, simplemente porque permiten a los administradores manejar y conocer el estado del servicio adems 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 organizacin cumplir con estas. Esto en trminos 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 organizacin. El monitoreo permite establecer una lnea base para referencia de futuras mediciones y determinar cuando las condiciones son las normales y cuando se presentan casos atpicos que representan problemas que deberan generar una alarma. La administracin requiere tener las herramientas necesarias para el cumplimiento de tareas relacionadas al manejo de usuarios, clientes VPN y del servidor VPN. La capacidad de administracin y monitoreo va a depender de las herramientas y utilidades que provea la solucin 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 parmetros de importancia a monitorear se pueden distinguir: Respecto del gateway: Utilizacin del Ancho de Banda. Estadsticas de las interfaces pblicas y privadas (Outside vs. Inside). Uso del CPU. Troughtput respecto de cantidad de sesiones en un perodo de tiempo.
Respecto de las sesiones de usuario Ranking de usuarios con mayor actividad en un perodo de tiempo respecto de: o o o o Throughput Duracin de la conexin Trfico total (Inbound+Outbound) Perodos de tiempo de mayor actividad.
88
Intento Fallidos de conexiones.
3.4 PROTOCOLOS
En los escenarios de acceso remoto se destacan algunos protocolos de tnel tanto de capa 2, 3 y 4. En el captulo 2 se han descrito la mayora 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 ms existentes son IPSec y SSL. Sin permite establecer un tnel que transporta trfico correspondiente destacados en funcin de las soluciones VPN embargo el protocolo SSH o Secure Shell se utiliza para acceso remoto. SSH solo a aplicaciones basadas en TCP.
A continuacin se describirn los protocolos SSH, IPSec y SSL mencionando los aspectos ms importantes de cada uno, desde una perspectiva global de implementacin para una VPN de acceso remoto.
3.4.1 SSH
Lo ms 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 electrnico o de terminal remota. A esta funcionalidad se la conoce como reenvo de puertos (port forwarding). El concepto es desviar el trfico asociado a un puerto de una conexin, hacia un puerto manejado por SSH y transportarlo a travs del tnel SSH hacia el otro extremo en forma encriptada. Es necesario un cliente y un servidor SSH con una cuenta de usuario vlida para el cliente. Existen dos clases de reenvo de puertos: local y remoto. Estos son establecidos por el cliente SSH.
Reenvo Local de Puerto (Local Port Forwarding)

Tambin denominado tnel saliente, reenva el trfico 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 vlido, por lo tanto el trfico 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 reenva el trfico destinado a local_port hacia el remote_port del remote_host luego de la conexin y autenticacin 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 aplicacin cuyo puerto de conexin es remote_port. En esta circunstancia, ssh_server es el intermediario de la conexin entre el cliente SSH y remote_host. Es importante aclarar que esta ltima parte de la conexin es realizada sin encriptacin. Un ejemplo prctico del reenvo local de puertos es la conexin al servicio de correo electrnico mediante un tnel SSH para brindar seguridad al proceso de autenticacin POP3. La Figura 3-8, ilustra la situacin de un usuario mvil conectndose a su red local en forma remota mediante SSH para procesar su correo electrnico en forma segura. 89
Figura 3-8 SSH Reenvo Local de puerto
En la red local existe un servidor SSH y un servidor de correo electrnico, ambos ejecutndose en equipos diferentes pero en la misma red. El usuario remoto se autentica en el servidor SSH con una cuenta de usuario vlida y ejecuta en su cliente el comando para reenviar el trfico POP3 mediante el tnel SSH. A continuacin el usuario mediante su aplicacin de correo electrnico o MUA (Mail User Agent) se conecta en forma local al puerto 1110 donde el trfico POP3 ser manejado por el cliente SSH y transportado por el tnel hasta el servidor SSH remoto. En el otro extremo, el servidor SSH reenva el trfico del cliente hacia el servidor de correo, esta ltima conexin no es encriptada. El servidor de correo responde al servidor SSH el cual reenva la respuesta al cliente SSH. Esto es posible si las polticas de seguridad de la organizacin permiten establecer conexiones SSH desde el exterior hacia algn gateway de la red local.
Reenvo Remoto de Puerto (Remote Port Forwarding)

Denominado tambin tnel entrante, reenva el trfico que arriba a un puerto remoto en el servidor, hacia un host y puerto local especfico en el cliente, (Figura 3-9). Para esto el cliente inicia una conexin SSH con el servidor mediante el comando: ssh R remote_port:local_host:local_port [username]@ssh_server Este comando conecta y establece una sesin con el servidor SSH utilizando username y solicita redireccionar el trfico que arribe a remote_port de ssh_server hacia local_port en local_host. Este esquema habilita el acceso desde el exterior hacia algn 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.
90
Figura 3-9 SSH reenvo 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 reenvo remoto solicita que todo el trfico que arribe al puerto remoto 5900 en ssh_server se reenve 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 polticas de seguridad de la organizacin permiten establecer conexiones SHH hacia el exterior. En la prctica utilizar SSH requiere conocimiento por parte del usuario para configurar un acceso remoto. Sin embargo existen herramientas que facilitan su utilizacin mediante interfaces grficas. Es una herramienta til en situaciones donde el acceso remoto es una excepcin y se realiza bajo determinadas condiciones, como por ejemplo la presencia de un servidor SSH, polticas de seguridad de la organizacin 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 solucin corporativa para el grueso de los usuarios mviles de la misma. Tampoco es una solucin escalable, dado que es necesaria la instalacin del software SSH en cada cliente y la configuracin manual de la conexin con sus particularidades en cada uno de ellos.
3.4.2 IPSec
Las VPN IPSec extienden el permetro de seguridad de una red permitiendo la conexin de hosts individuales o redes enteras. Una VPN segura verifica la identidad de los extremos del tnel. A diferencia de las VPN red a red utilizando IPSec, las de acceso remoto requieren mayor consideracin respecto de la autenticacin de las partes que se comunican, en general para evitar establecer tneles con partes no autorizadas. En particular porque en este escenario, habr muchos clientes intentando conectarse a los recursos de la red local de la organizacin. Adems porque se tratan de conexiones temporales y el origen de red de las mismas vara con frecuencia.
91
Es importante considerar que en IPSec la autenticacin precede el establecimiento del canal seguro por donde se llevar a cabo la comunicacin entre las partes, por lo tanto, cualquier vulnerabilidad que pueda ser explotada en esta primera etapa, comprometer el resto de la comunicacin. El protocolo IPSec encargado de realizar la autenticacin de las partes es IKE. Este protocolo de intercambio de claves presenta dos fases en su operacin, tres modos, una variedad de mecanismos para llevar a cabo la autenticacin, pero ms importante an una nueva versin de este protocolo: IKEv228, la cual no es interoperable con IKEv1. De manera que son varios aspectos que hay que considerar para la implementacin de una VPN IPSec de acceso remoto con mecanismos de autenticacin seguros. La primera versin de IKE es la ms difundida entre los productos que implementan IPSec. Su forma de operacin trae aparejado riesgos de seguridad si el mecanismo de autenticacin utilizado no es el adecuado. La segunda versin, ya definida como estndar por el IETF es una mejora de la anterior poniendo nfasis en la solucin 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 autenticacin que eviten el ataque conocido como hombre del medio, como encriptacin de clave pblica y firma digital con uso de certificados. El protocolo IKE se basa en la identificacin de los pares que se conectan como parte del proceso de autenticacin. Puede utilizar varios tipos estndar de identificacin: direccin IP (Ipv4 e Ipv6), nombre del host FQDN (Fullly Qualified Domain Name), una direccin de correo electrnico, o un nombre distinguido DN (Distinguished Name) X.500 LDAP (Lightweight Directory Access Protocol). Estas identificaciones necesitan ser comprobadas, para esto se utilizan los mtodos de autenticacin. Los identificadores de los pares pueden encriptarse o no, segn 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 informacin 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 autenticacin mediante clave pre compartida (PSK) con el modo main, ya que esta combinacin modo/mtodoautenticacin, requiere usar como ID la direccin IP de quien inicia la conexin, en este caso el cliente remoto. Dado que se trata de clientes mviles, la direccin IP origen de estos es de naturaleza dinmica y puede variar durante una misma sesin.
28
RFC 4306 - Internet Key Exchange (IKEv2) Protocol
92
Tal como se menciona en la introduccin de este captulo, es muy importante en este escenario de VPN, implementar una doble autenticacin para el cliente: basada en host y en usuario. Una desventaja de IKEv1 es la falta de este ltimo tipo de autenticacin. Si bien se han implementado extensiones a IKEv1 por algunos fabricantes, como la autenticacin extendida (XAUTH) de Cisco, estas no han sido consideradas como estndares por parte de la IETF. Los gateways VPN que utilizan XAUTH solicitan al usuario un segundo login; si tiene xito se contina con la segunda fase de IKE que prepara la conexin IPSec, caso contrario se finaliza el intercambio IKE y no se lleva a cabo la conexin. Una alternativa a XAUTH es la encapsulacin L2TP sobre IPSec, permitiendo la autenticacin 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 diseo lo que se denomina mecanismos de autenticacin heredados (legacy authentication); estos implementan la autenticacin de un usuario sobre un servidor. Es el caso de los mecanismos de passwords e intercambios desafos/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 versin 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 versin 2 de IKE. De acuerdo a la introduccin de acceso remoto va a consistir de un servidor se conectarn al servidor. El servidor se borde de la red de la organizacin. Puede bien en otro equipo. este captulo una VPN IPSec de VPN y de varios clientes VPN que ejecutar en un dispositivo de hacerlo en el mismo firewall o
Hay que considerar las polticas de seguridad de la organizacin y establecer en funcin de estas los parmetros necesarios para definir las polticas de seguridad IPSec (SP) a partir de las cuales se derivarn las asociaciones de seguridad de IKE (IKE SA) e IPSec (IPSec SA). Estos parmetros 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 efectivizarn el servicio, es decir que seguridad aplicar. Esto ltimo implica determinar los algoritmos de autenticacin, de encriptacin, protocolo de seguridad, modo de operacin a usar con esta poltica. Esta informacin se almacena en base de datos. Como se mencion en el captulo anterior, existen dos clases de bases de datos: la referida a las polticas de seguridad (SPD) y la de asociaciones de seguridad (SAD). La primera especifica las polticas que determinan el trfico entrante o saliente que debe ser asegurado, si bien todo el trfico es procesado por el motor IPSec. La segunda contiene parmetros relacionados con cada asociacin de seguridad activa, que indican cmo procesar y que servicio de seguridad aplicar.
93
Cuando un cliente remoto se conecta debe recibir informacin de configuracin de red referente a la red de la organizacin destino de la conexin. Esto se puede lograr mediante la encapsulacin L2TP sobre IPSec, donde los mecanismos PPP permite obtener la direccin IP local para el host remoto(PPP IPCP), sin embargo la informacin dinmica ofrecida es muy escasa y no es un mecanismo integrado a IPSec. Existe otro mtodo 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 tnel. Para esto el cliente define una asociacin de seguridad DHCP (DHCP SA) la cual solo es utilizada para el intercambio de trfico 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 solucin VPN SSL sin cliente (clientless), refiriendo a que no es necesaria la presencia de software cliente VPN especfico para la conexin. En realidad este esquema no representa realmente una VPN. Se trata de un sistema que implementa tanto un web proxy o un mecanismo de traduccin de protocolos de aplicacin (Application Traslation). En el primer caso, existe un dispositivo servidor que acta como intermediario entre los servicios destino y el cliente remoto. El proxy recibe la peticin del cliente, la rescribe por completo y la enva al servidor destino. Antes del reenvo, el proxy puede analizar la correctitud del requerimiento en busca de solicitudes malformadas creadas con la intencin de un ataque. La respuesta del servidor destino recorre el camino inverso, hacia el proxy primero y de all al cliente. Toda la conexin 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 aplicacin se adapta o se traduce a HTTP y HTML para poder ser visualizado en un navegador. Este mtodo 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 interacte con el servidor para la creacin de un tnel por el cual se transmite trfico IP en forma segura. Los mecanismos anteriores no proveen esta clase de conectividad. Existen soluciones VPN SSL verdaderas, donde el tnel creado permite la comunicacin segura independientemente del protocolo de aplicacin que se ejecute. Esto permite, si las polticas 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 tecnologas de acceso remoto

Este cuadro presenta una comparacin entre las tecnologas VPN de acceso remoto de mayor uso en la actualidad. Cuando se considera implementar el servicio de acceso remoto las tecnologas a considerar son IPSec y SSL/TLS.
94
En particular la utilizacin de IPSec es anterior a la aplicacin 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 utilizacin de dispositivos bajo el control de la organizacin. SSL/TLS permiti salvar estas limitaciones de IPSec. Los criterios utilizados describen en general las caractersticas (limitaciones y ventajas) presentes en estas tecnologas VPN, independiente de alguna solucin particular.
Criterios
VPNs IPSec
VPNs SSL/TLS
Escalabilidad
Limitada
Buena a Muy buena Muy Buena considerando el uso de navegadores web como clientes Aplicaciones Web, Aplicaciones cliente/servidor Acceso completo a la red o restringido, Muy Buena Clave precompartida, Certificados Digitales, Claves RSA Doble autenticacin No administrados Administrados No, solo soporta aplicaciones basadas en SSL Servicio de capa de transporte Proxy reverso con Encapsulamiento HTTP, Traductor de protocolo, Tnel IP en capa de red Bajo (considerando navegadores web como clientes) a Alto Si
Interoperabilidad
Buena
Funcionalidad
Acceso completo a la red o restringido
Seguridad en la transmisin
Muy Buena Clave precompartida, Claves RSA, Certificados digitales Doble autenticacin nativa con IKEv2 Administrados por la organizacin No, solo datagramas IP
Mtodos de autenticacin
Tipos de Dispositivos soportados
clientes
Soporte Multiprotocolo Nativo
Capa de Operacin
Servicio de capa de Red
Mecanismo de Acceso
Tnel IP a nivel de capa de red Medio a Alto, segn el nmero de usuarios remotos Si
Nivel de Soporte requerido Soluciones Abiertas
Tabla 3-1 Comparativa de Tecnologas de Acceso Remoto
95
Escalabilidad
Cuando la cantidad de usuarios remotos aumenta, se requiere mayor capacidad en el servidor VPN en cuanto al procesamiento para el manejo de ms tneles y funciones de des/encriptacin. En este caso ambas tecnologas se pueden valer de hardware especial para estas tareas. En el lado de los clientes se incrementa el costo de administracin del software cliente VPN si la solucin 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 administracin 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, tendrn una carga similar a IPSec.
Interoperabilidad
Las soluciones que implementan el mismo protocolo deberan poder comunicarse sin problemas, de lo contrario, stas no podrn interoperar. Esto ha sucedido con soluciones VPN IPSec, en particular con la eleccin del mecanismo de autenticacin de las partes. Sin embargo el consorcio VPN 29 ha establecido pruebas de interoperabilidad, tanto para soluciones basadas en IPSec como en SSL, que permiten una mejor interaccin entre soluciones de distintos fabricantes. Las soluciones SSL/TLS no poseen estas limitaciones considerando la utilizacin 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 segn 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 transmisin
Ambas tecnologas permiten un excelente nivel de seguridad en la transmisin de los datos. El servicio de confidencialidad se basa en una fuerte suite de algoritmos de encriptacin, bien probados, utilizando protocolos como 3DES, AES, IDEA, algoritmos de hash y firma digital como RC4, SHA. La autenticacin puede estar basada en criptografa de clave pblica mediante el uso de certificados digitales. En este caso IPSec se destaca por ser ms estricto, ya que requiere que ambas partes posean un certificado que demuestre su identidad para poder usar el mtodo. El diseo de SSL/TLS, en cambio, es ms flexible en este punto, permitiendo que solo el servidor se autentique. De esta manera no cumple la caracterstica de no repudio y es vulnerable a un ataque del tipo hombre del medio. Sin embargo, una buena solucin VPN SSL/TLS, debera requerir la autenticacin mediante certificados, de ambas partes.
29
http://www.vpnc.org
96
Otra caracterstica es que ambos protocolos permiten definir una configuracin a nivel criptogrfica (algoritmos criptogrficos permitidos, tamaos de claves, regeneracin de claves, tiempos de vida de las claves, etc.) que se aplican como polticas a las conexiones segn el nivel se seguridad requerido para cada caso.
Mtodos de Autenticacin
En general ambos protocolos brindan los mismos mtodos de autenticacin 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 autenticacin del usuario que controla el dispositivo que se conecta, logrando una autenticacin doble: dispositivo y usuario. El diseo de SSL/TLS permite esto mediante el mecanismo ms simple, pero menos seguro, de usuario/contrasea hasta mtodos ms complejos como OTP (One Time Password) o una infraestructura PKI que valide certificados de usuario. Por supuesto esta operacin se realiza posterior al establecimiento de un canal seguro. IPSec ofreci la posibilidad de la doble autenticacin luego de la incorporacin de las extensiones al protocolo IKE por parte de Cisco (XAUTH, HYBRID AUTH) luego de establecer el canal seguro. La nueva versin de IKE IKEv2 incorpora el soporte nativo de autenticacin de usuario mediante EAP. Lamentablemente la nueva versin de IKE no es interoperable con su antecesora.
Tipos de dispositivos soportados

Aqu se marca una diferencia entre ambas tecnologas. El uso de IPSec requiere la instalacin de un cliente VPN en el dispositivo mvil. 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 conexin no represente una amenaza. Por lo tanto las VPN IPSec de acceso remoto requieren usar dispositivos bajo el control de la organizacin. Es impensable intentar esta operacin sobe un equipo ajeno a la organizacin 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.
97
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 tnel para encapsular datagramas IP. Este tnel 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 traduccin de protocolos permite acceder a servicios cuyos protocolos pueden traducirse y adaptarse a HTTP y lograr tunelizarlos, finalmente a travs de un tnel IP al igual que IPSec. Esto permite un control de acceso ms granular para SSL/TL, es decir permite mecanismos de autorizacin ms variados y no solo basarse en parmetros a nivel de red (IP origen, puerto destino etc.)
Nivel de soporte requerido

En el caso de IPSec es de medio a alto en funcin de la cantidad de usuarios remotos. Se tiene en cuenta la carga que representa la administracin y mantenimiento de los clientes, las polticas de acceso y conjuntos de transformacin. 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 administracin de los clientes.
Soluciones Abiertas
Ambas tecnologas 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 ms conocidas estn: OpenVPN: solucin VPN SSL/TLS que permite acceso completo a la red, desarrollada para LINUX. Existe la versin para WINDOWS. Ipsec-tools30 : conjunto de utilidades para el manejo de la implementacin 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 polticas de seguridad y la base de asociaciones de seguridad. StrongSwan31: Solucin VPN basada en IPSec desarrollada para plataforma LINUX. Implementa el demonio IKE versin 2, adems de la versin inicial.
30 31
http://ipsec-tools.sourceforge.net/ http://www.strongswan.org/
98
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 administracin del servicio y monitoreo, dispositivos mviles con cliente embebido etc. Sin embargo, existe un costo econmico importante a la hora de elegir alguna de ellas, ya sea en la adquisicin de la infraestructura como en la capacitacin del personal. Adems de estas soluciones propietarias, existen alternativas abiertas y gratuitas, en particular orientadas a plataformas LINUX y FreeBSD aunque hay casos donde la solucin se puede ejecutar tambin en Windows. Tambin existen sistemas basados en una solucin abierta pero embebidas o como una imagen de disco que se puede virtualizar o bien instalar en hardware dedicado con software de administracin todo en uno, pero estas no son gratuitas32. Una caracterstica de las soluciones propietarias es la implementacin como firmware de la lgica 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 caractersticas bsicas deseable que deberan poseer las soluciones VPNs de acceso remoto segn la tecnologa 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
99
3.5.1 IPSEC
Cliente para Windows/Macintosh Ecapsulamiento L2TP Soporte de certificados X.509 durante IKE Soporte de encriptacin 3DES Soporte Failover Software IPSec Cliente para ejecutarse sobre un sistema monousuario WINDOWS/MACINTOSH. Ejecutar L2TP para autenticacin y enrutamiento sobre un tnel IPSec Uso de certificados de clave pblica para autenticacin. Soporte para fuerte encriptacin 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) 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 direccionamiento Ipv6. Creacin de un tnel IP con encriptacin 3DES, SHA1 para hash, intercambio de claves de 1024 bits y PSK para autenticacin. Uso de algoritmo AES con claves de 128 bits para encriptacin. Creacin de un tnel IP mediante IKEv2 con AES para encriptacin, SHA-1 para hash, intercambio de claves de 1024 bits y PSK para autenticacin. La compatibilidad debe ser total con otras soluciones. Los sistemas deben interoperar sin problemas utilizando direcciones IPv6 con redes externas e internas Herramientas y utilidades para facilitar la administracin del servicio Uso de compresin estndar para el trfico IPSec Tabla 3-2 Caractersticas de soluciones IPSec
Soporte de Clustering
Soporte para Ipv6 VPNC interoperabilidad bsica
VPNC interoperabilidad AES VPNC interoperabilidad bsica para IKEv2
VPNC interoperabilidad
Ipv6
Interfaz de Administracin y monitoreo Compresin IPPCP
100
3.5.2 SSL/TLS
Soporte LDAP Soporte RADIUS Soporte certificados X.509 para usuarios Soporte Failover Permite comunicarse con un servidor LDAP para autenticar los usuarios remotos Permite comunicarse con un servidor RADIUS para autenticar los usuarios remotos Permite utilizar certificados X.509 para autenticar usuarios remotos. 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) 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. Permite el acceso total a la red descargando un plugin para SSL que lo permita. Soporte para verificacin del nivel de seguridad del extremo remoto del cliente. El gateway debe funcionar como portal para aplicaciones web permitiendo a los usuarios remotos el acceso a sitios web internos. El gateway debe permitir la lectura y escritura en servidores CIFS33/SMB34 internos: Windows 2000 y 2003 Servers. El gateway debe funcionar como Portal con soporte de JAVA script para el acceso a aplicaciones internas. Herramientas y utilidades para facilitar la administracin del servicio
Soporte de Clustering
Acceso completo a la red mediante plugin SSL Endpoint Security Checking VPNC interoperabilidad SSL Portal VPNC interoperabilidad SSL File Access VPNC interoperabilidad JAVA Script SSL
Interfaz de Administracin y monitoreo
Tabla 3-3 caractersticas para soluciones SSL/TLS
El consorcio VPN rene como sus miembros a importantes empresas destacadas en el mbito del networking, entre ellas estn: 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 carcter general y abarcativo de esta caracterizacin aplicable a cualquier solucin VPN. La seleccin de los criterios deseables fue definida a partir del anlisis e investigacin realizada para el desarrollo y elaboracin de este captulo y del resto del trabajo en general.
33
Common Internet Filesystem: Protocolo de dominio pblico para transferencia de archivos en forma simple y potente Server Message Block: Protocolo para compartir archivos, base de los sistemas de red LAN Manager y Microsoft Networking .
34
101
CAPTULO 4 TRABAJO PRCTICO

4
102
4.1 INTRODUCCIN
Siempre se ha deseado tener la posibilidad de acceder a los recursos corporativos de informacin y sistemas desde el hogar u otro punto geogrfico de una manera sencilla; adems 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 las cuales requieren la instalacin de clientes VPNs en los provistos a los usuarios mviles o tele trabajadores. Este requiere una dependencia del software VPN cliente con el operativo anfitrin. remoto, equipos proceso sistema
La intencin de este trabajo es lograr independizar el cliente VPN del sistema operativo anfitrin, no solo respecto de aspectos de compatibilidad entre s sino tambin de los privilegios necesarios para la instalacin de esta clase de aplicacin. A partir de esta siguientes caractersticas: idea la solucin debe cumplir con las
Ser portable es decir que se pueda trasladar en un pendrive o una memoria flash convencional. No requerir la instalacin de software en el equipo anfitrin y no utilizarlo para guardar informacin. No requerir permisos administrativos en el host anfitrin. Poder ejecutar la solucin sobre la plataforma Windows por ser la ms popular. Tener acceso a la red sin restricciones, pero poder establecerlas en forma dinmica 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 solucin mediante virtualizacin, adems de brindar las herramientas necesarias para efectuar la conexin y el software especfico para realizar las tareas. La Figura 4-1 muestra el diseo de la solucin propuesta, donde se aprecia el tnel desde la aplicacin virtualizada hasta el gateway VPN. Para esto se utiliza la conexin a Internet del equipo anfitrin. El extremo remoto del tnel termina en el gateway VPN el cual permite el acceso a la red local corporativa a los servicios disponibles.
103
Figura 4-1 Diseo de la solucin
4.2 ALCANCES
La solucin propuesta est orientada principalmente a su uso sobre equipos que estn bajo control y administracin de la organizacin, lo cual establezca cierto nivel de seguridad respecto a la presencia de software malicioso. No es una solucin pensada para uso masivo por parte de los usuarios. El sistema operativo anfitrin donde se ejecutar la solucin ser Microsoft WINDOWS 2000, XP o Vista. Es necesario hardware adecuado para ejecutar una virtualizacin en el host anfitrin. En particular capacidad de procesamiento. El pendrive o memoria flash deber tener una capacidad de al menos 2GB. Es necesario software para virtualizacin, es decir una mquina virtual que pueda ejecutarse en las versiones de WINDOWS mencionadas anteriormente. La solucin se implementar en la plataforma utilizar el sistema OpenVPN35 para establecer la VPN. LINUX y
La solucin incluir una aplicacin externa a la virtualizacin que tendr como cometido, transferir los archivos descargados en la aplicacin virtualizada al pendrive, donde quedarn disponibles para su procesamiento posterior.
35
http://www.openvpn.org
104
VPNs de Acceso Remoto 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 dinmica las restricciones para el acceso a la red.
4.3 FUNCIONAMIENTO
La solucin propuesta permite la conexin segura a la red corporativa mediante un tnel SSL/TLS. La misma es efectuada por un usuario, el cual deber autenticarse previamente en forma local, mediante un nombre de usuario y contrasea. Una vez autenticado ejecutar la aplicacin que le permitir establecer la conexin, habilitando el acceso a las aplicaciones segn su rol o perfil.
4.3.1 Perfiles de usuarios

Se implementan dos perfiles de usuarios, uno es el perfil del usuario estndar que puede realizar ciertas tareas y otro es el de administrador. Este tendr acceso total al resto de las aplicaciones, la mayora de las cuales son de naturaleza administrativas. El gateway VPN que recibe la conexin genera las reglas en forma dinmica las cuales establecen las restricciones para ambos perfiles de usuario.
4.3.2 Esquema de validacin

Se definen dos etapas de autenticacin. En la primera se autentica el usuario localmente a travs del sistema de validacin de LINUX. Esto le permite ingresar al entorno de trabajo de la solucin. La segunda etapa consiste en la validacin del usuario respecto del Gateway VPN mediante certificado para establecer el tnel. 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 Mensajera SMB (Credenciales de sesin Windows) FTP
Perfil Administrador: Todas las anteriores SSH Escritorio Remoto (RDP/VNC)
105
4.3.4 Gateway VPN

El servidor VPN implementado a travs del sistema OpenVPN, establecer en forma dinmica las restricciones segn el usuario que se conecte. Esto se logra mediante una opcin en el archivo de configuracin del servidor. Adems es necesario crear un script para cada perfil donde se definen las restricciones a nivel de puertos TCP/UDP y a nivel de la direccin origen asignada al usuario.
4.4 TECNOLOGAS DE LA SOLUCIN

El desarrollo de la solucin requiri determinar que herramientas eran necesarias para cumplir con las caractersticas establecidas. El componente ms importante de la solucin es la mquina virtual que permite la ejecucin del cliente VPN. Dado que el cliente se ejecuta en una plataforma LINUX, se analiz alternativas de distribuciones existentes adems de considerar la creacin de una propia. Lo siguiente fue considerar el desarrollo de la aplicacin que controla la lgica del cliente y las aplicaciones necesarias para acceder a los servicios disponibles, adems de la aplicacin para la transferencias de archivos de la maquina virtual al pendrive. Para esto se evaluaron lenguajes de programacin, distribuciones LINUX y entornos de virtualizacin.
4.4.1 Lenguajes de programacin

Las caractersticas deseables analizadas fueron: Desarrollo rpido de entornos grficos. Soporte para el desarrollo de aplicaciones para networking. Curva de aprendizaje de crecimiento rpido. Confiabilidad (Antecedentes comprobables). en la utilizacin en casos
Soporte multiplataforma (LINUX, WINDOWS). Perfomance.
Alternativas consideradas
Los lenguajes considerados fueron: JAVA PYTHON RUBY
El lenguaje elegido fue PYTHON. Entre los motivos de la eleccin se consideraron la perfomance respecto de los dems, la posibilidad de correr aplicaciones sin requerir un entorno de ejecucin, ni la instalacin en el equipo anfitrin de bibliotecas o dependencias. Tambin incidi la curva de aprendizaje rpido.
106
4.4.2 Entorno de virtualizacin

Se tuvieron en cuenta las siguientes alternativas: VIRTUALBOX QEMU36 VMWARE VIRTUALPC
VMWARE y VIRTUALPC no tienen una distribucin que se pueda ejecutar desde un pendrive. Por su parte VIRTUALBOX esta basado en QEMU, posee un mejor rendimiento y existe una versin para ser ejecutada en un pendrive que no es oficial, pero es necesario contar con permisos administrativos para poder instalar una biblioteca de enlace dinmico y un proceso que le permita a la maquina virtual tener un mejor rendimiento. La caracterstica principal que determin la eleccin de la mquina virtual QEMU es que se puede ejecutar en un pendrive sin el requerimiento de tener permisos de administrador sobre el equipo anfitrin. La limitacin que presenta esta opcin es su rendimiento ya que para mejorarlo, al igual que las dems soluciones, es necesaria la instalacin de un mdulo para optimizacin en el sistema operativo anfitrin y poseer privilegios de administrador para hacerlo. Sin embargo, la perfomance de QEMU, lograda sin el mdulo optimizador, en equipos con buena capacidad de procesamiento es aceptable permitiendo cumplir con la funcionalidad deseada.
4.4.3 Distribucin LINUX

La plataforma de ejecucin de la aplicacin es el sistema LINUX. Esta eleccin se basa en sus caractersticas favorables en cuanto a la seguridad, estabilidad, robustez, disponibilidad del kernel del sistema operativo para adaptarlo a los requerimientos de la solucin y finalmente por ser una base ptima para aplicaciones orientadas a las comunicaciones. Si bien el propsito no fue crear una mini distribucin, se trat de minimizar, dentro de las posibilidades, las instalaciones realizadas. Se evalu la utilizacin de versiones bsicas de distribuciones conocidas: DEBIAN y FEDORA. Dado que la solucin se basa en una virtualizacin y adems la alternativa elegida para esta tarea no posee un perfomance destacada, se decidi crear una distribucin propia. Encarar esta tarea asegura la instalacin de las herramientas mnimas para la funcionalidad deseada y sobre todo poseer un control ms estricto sobre este proceso. El mtodo elegido para la creacin se bas en el proyecto LINUX desde cero o LFS37 (LINUX From Scratch). Este consiste en cumplir una serie de etapas hasta lograr la distribucin final. La versin de LFS utilizada fue la 6.3. Actualmente la versin estable es la 6.4.
36 37
http://www.nongnu.org/qemu/ http://www.LINUXfromscratch.org
107
VPNs de Acceso Remoto La primera etapa consiste en utilizar una distribucin LINUX operativa como base para la creacin del nuevo sistema, en este caso una DEBIAN Etch. En particular se seleccion una particin disponible para la instalacin del nuevo sistema. Luego se utiliz el LiveCD del proyecto LFS como sistema anfitrin, el cual provee las herramientas bsicas necesarias y las fuentes de los programas que formarn la estructura del nuevo sistema. Una vez elegida la particin, sta se monta luego de iniciar el LiveCD. ste adems monta su propio sistema de archivo raz donde se encuentra todo lo necesario para el proceso de creacin. La segunda etapa consiste en la creacin de un sistema mnimo en la particin 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 sern utilizadas para compilar e instalar el resto de los paquetes. La tercera etapa consiste en crear un entorno chroot o de jaula sobre la particin dedicada, y a partir de las herramientas generadas en la etapa anterior se dar forma al sistema final. Esto se logra mediante la compilacin e instalacin del resto de los paquetes utilizando el compilador, ensamblador, enlazador y bibliotecas de la cadena de herramientas. Tambin es necesario la creacin de los sistemas de archivos virtuales para el kernel (/dev, /proc, /sys), creacin de la estructura de directorios del sistema de archivos raz, enlaces dinmicos etc. Es decir instalar el sistema bsico. 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 particin contenida en el chroot donde se compil e instal el sistema final. Esta imagen es la que utiliza la mquina virtual QEMU para ejecutar la solucin propuesta. En realidad, el proceso es ms extenso. Lo anterior es solo un resumen general. Para ms detalles y consideraciones es mejor acceder al sitio www.linuxfromscratch.org, donde LFS es una parte de un proyecto ms ambicioso para la creacin y personalizacin de una distribucin LINUX.
Paquetes principales instalados

Luego de la creacin de la distribucin propia se fueron instalando las herramientas y aplicaciones necesarias y sus dependencias relacionadas con la solucin. Este fue un proceso de descarga, compilacin e instalacin 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
108
VPNs de Acceso Remoto Entorno grfico XORG (X11 R7.4)38 Window Manager FLUXBOX 1.0.039 XDM y XSM (login y session manager)
Para el entorno grfico Se eligi un Windows Manager en lugar de un Destktop Manager como GNOME o KDE, considerando el requerimiento de perfomance debido a la virtualizacin. 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 adems un entorno agradable y funcional.
4.4.4 Tecnologa VPN

Se opt por una VPN SSL/TSL en lugar de una solucin basada en IPSec, principalmente por la flexibilidad en la asignacin de puerto de conexin donde se brinda el servicio VPN de acceso remoto. Las soluciones IPSec requieren una asignacin de puertos bien conocidas para el demonio IKE el cual gestiona el intercambio de claves de sesin y las asociaciones de seguridad y para el protocolo ESP para asegurar los datagramas en modo tnel (Puerto TCP 51 para ESP y puerto UDP 500 para IKE). Esto representa una restriccin que limita la funcionalidad y la movilidad de la solucin.
4.5 LA SOLUCIN
El pendrive consta de dos archivos cuales realizan las siguientes funciones: de extensin bat los
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 Mquina Virtual

Al inicializar la maquina virtual nos encontramos con el pedido de usuario y clave para la autenticacin local como lo muestra la Figura 4-2:
38 39
http://www.x.org http://www.fluxbox.org
109
Figura 4-2 Pedido de credenciales locales
Al ingresar podemos acceder al men principal (Figura 4-3) haciendo click con el botn derecho del Mouse sobre el rea de la pantalla.
Figura 4-3 Men principal, sesin local del usuario
Al seleccionar la opcin Cliente VPN, accedemos a la aplicacin. Al ingresar la nica opcin habilitada es la que nos permite conectarnos. Al realizar la conexin se habilitan las opciones de acuerdo a nuestro perfil de usuario (Administrador o usuario normal) permitiendo acceder a los servicios de nuestra corporacin, esto se visualiza en la Figura 4-4:
110
Figura 4-4 Men del Cliente VPN
Las opciones de izquierda a derecha son: conectar, desconectar, correo electrnico, acceso al servidor de archivos, FTP, SSH, mensajera instantnea, 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 vlidas del usuario para acceder al servidor que contiene los archivos. Una vez autenticado el usuario, la conexin 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
111
4.5.2 Aplicacin de gestin de archivos

Para poder descargar o subir de la maquina virtual archivos debemos ingresar usuario y contrasea, siendo estas credenciales las mismas que para ingresar a la solucin. La pantalla de conexin se muestra en la Figura 4-6. Para comunicar ambas aplicaciones se establece una comunicacin mediante SSH. Se utiliza la biblioteca de PYTHON PARAMIKO, la cual implementa la versin 2 del protocolo SSH.
Figura 4-6 Pantalla de conexin a la maquina virtual
En la parte inferior se informa sobre el estado de la aplicacin. 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 opcin para Bajar el Archivo. El mismo queda en la carpeta VpnFolder del pendrive. Para ingresar el archivo a la maquina virtual se oprime la opcin 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 travs del FTP.
112
4.6 CONCLUSIONES DEL TRABAJO PRCTICO

El objetivo inicial del trabajo prctico se ha cumplido. Se logro concretar el concepto de portabilidad de un cliente VPN de acceso remoto. La motivacin principal del trabajo fue esta, sin importar en principio que tecnologa y protocolo VPN era ms conveniente usar. La complejidad de la solucin estriba en la eleccin ms adecuada de sus componentes y en la bsqueda de la optimizacin de los mismos en funcin de la virtualizacin requerida. Sin embargo esta propuesta se puede mejorar para lograr un resultado an ms ptimo en trminos de perfomance y funcionalidad. Entre estos aspectos se puede mencionar la posibilidad de lograr una distribucin LINUX an ms compacta, mejorar la aplicacin principal para que controle la conexin de manera ms precisa, crear un mecanismo que permita la actualizacin en forma dinmica de dicha aplicacin adems de un mecanismo de actualizacin de paquetes para la distribucin propia. Una mejora en la seguridad del cliente VPN sera la utilizacin de un mecanismo de doble autenticacin al momento de la conexin. Esta consistira en autenticar el dispositivo o sistema mediante un certificado y luego el usuario mediante el mecanismo OTP o claves de una sola sesin. Este esquema brindara una mayor seguridad en cuanto a la validacin del usuario. Otro componente para flexibilizar an ms esta alternativa sera 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 travs de un plugin. Junto con un certificado para el dispositivo se logr concretar una doble autenticacin, pero con el mecanismo ms dbil que es el par usuario y contrasea comn. RADIUS es una tecnologa compleja, y debido a falta de tiempo se decidi no continuar con la evaluacin de sus caractersticas para una posible aplicacin a la solucin. 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 relacin al mantenimiento e instalacin de los mismos. Por esta razn se considera limitado el conjunto de usuarios que la utilizaran. En particular puede resultar til para personal del tipo administrador, de redes o de sistemas. La limitante en perfomance de la virtualizacin es posible minimizarla gracias al hardware existente de gran capacidad de procesamiento y virtualizacin comunes en la actualidad, tanto en equipos porttiles como en equipos de escritorio. Las tecnologas de doble, triple y hasta cudruple ncleo en los CPU, y el soporte de virtualizacin de los sistemas operativos actuales, habilitan que esta sea una solucin viable. Finalmente la posibilidad de adquirir una memoria flash o dispositivos pendrive de gran capacidad de almacenamiento, descartan las limitantes de espacio para la instalacin, en estos dispositivos de la solucin descripta en este captulo.
113
Anexos
114
5.1 NDICES DE FIGURAS

Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura 1-1 Componentes de una VPN .................................. 13 1-2 VPN Provista por el Cliente ............................. 14 1-3 VPN Sitio a Sitio ....................................... 16 1-4 VPN de Acceso Remoto .................................... 16 1-5 Clasificacin de las VPN ............................... 18 1-6 Adyacencias del Ruteo ................................... 21 1-7 Infraestructura del proveedor ........................... 22 1-8 VPNs tipo Peer .......................................... 22 2-1 Componentes ............................................. 31 2-2 Firewall ................................................ 32 2-3 Servidores de Autenticacin ............................. 33 2-4 Basada en la Implementacin (Hibrida) ................... 35 2-5 Tneles bajo demanda (Router a Router) .................. 36 2-6 Sesiones encriptadas bajo demanda ....................... 36 2-7 Tneles bajo demanda (Firewall a Firewall) .............. 37 2-8 Dirigida ................................................ 38 2-9 Funcionamiento de un Tnel .............................. 41 2-10 Multiplexacin de Tneles .............................. 42 2-11 Funciones del Protocolo PPP en PPTP .................... 46 2-12 Componentes en una conexin PPTP ....................... 47 2-13 Encapsulamiento PPTP ................................... 47 2-14 Componentes en el Protocolo L2F ........................ 48 2-15 L2TP Tnel obligatorio ................................. 49 2-16 L2TP Tnel voluntario .................................. 50 2-17 Paquete/Datagrama usando IPSec ......................... 51 2-18 Encabezado AH .......................................... 53 2-19 Modos con protocolo AH ................................. 55 2-20 Modos en ESP ........................................... 56 2-21 Encabezado y Cola ESP .................................. 56 2-22 Paquete GRE encapsulado ................................ 59 2-23 Encapsulamiento Multicast con GRE asegurado con IPSec .. 60 2-24 Escenario Red a Red .................................... 66 2-25 Escenario Host a Red ................................... 66 2-26 Punto a Punto en VPN VPWS .............................. 68 3-1 Escenario General ....................................... 73 3-2 Gateway VPN sobre el Firewall ........................... 80 3-3 Esquema en paralelo ..................................... 81 3-4 Gateway VPN con DMZ nica ............................... 83 3-5 Uso de una doble DMZ .................................... 84 3-6 Alta disponibilidad con Failover Activo ................. 85 3-7 Alta disponibilidad mediante un Cluster ................. 86 3-8 SSH Reenvo Local de puerto ............................. 90 3-9 SSH reenvo Remoto de puerto ............................ 91 4-1 Diseo de la solucin .................................. 104 4-2 Pedido de credenciales locales ......................... 110 4-3 Men principal, sesin local del usuario ............... 110 4-4 Men del Cliente VPN ................................... 111 4-5 Acceso a los archivos remotos .......................... 111 4-6 Pantalla de conexin a la maquina virtual .............. 112
115
5.2 REFERENCIAS BIBLIOGRFICAS
BIBLIOGRAFA
BERKOWITZ, HOWARD C.[1999], Routing and Switching. Designing Addressing Architectures for
BROWN, STEVEN [2001], Implementacin 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. Edicin. TANENBAUM, ANDREW S.[1996], Computer Networks 3ra. Edicin. 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 N1 Vol 1 CISCO SYSTEM [Septiembre 1998],The Internet Protocol Journal N2 Vol 1 CISCO SYSTEM [Marzo 2007],The Internet Protocol Journal N1 Vol 10 CISCO SYSTEM [Junio 2007],The Internet Protocol Journal N2 Vol 10 NETXIT SPECIALIST N13, Elementos Bsicos de Criptografa, Algoritmos de Hash Seguros, El Gran Debate: PASSPHRASES vs. PASSWORDS NETXIT SPECIALIST N14, Elementos Bsicos de Criptografa, Algoritmos de Hash Seguros, El Gran Debate: PASSPHRASES vs. PASSWORDS-Parte 2 NETXIT SPECIALIST N27, ABC de VPNs NETXIT SPECIALIST N30, Virtualizacin NETXIT SPECIALIST N32, Virtualization Technologies
WHITE PAPERS
FINLAYSON, M. HARRISON, Technologies A Comparison J. SUGARMAN, R.[Febrero 2003], HTTP://www.dataconnection.com VPN
SEMERIA, CHUCK [Marzo 2001], RFC 2547bis: BGP/MPLS VPN Fundamentals Juniper Networks HTTP://ftp.utcluj.ro/pub/users/dadarlat/retele_master/TARC_08_09/MPLSVPN/200012.pdf
116
VPNs de Acceso Remoto CISCO SYSTEMS [2004], Enterprise guide for Architecture Comparing MPLS, IPSec, and SSL. selecting an IP VPN
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 Configurations
H.[Septiembre
2006],
Basic
VPN
Topologies
and
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 BUILDING LINUX VPNs, VPN FUNDAMENTALS CAPTULO 2 HTTP://www.buildinglinuxvpns.net/chapter2.pdf
MONGOL,
CRHIS
117

Tesina

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tesina

Uploaded by

Copyright:

Available Formats

REDES VPNs DE ACCESO REMOTO

Trelew Abril 2009

VPNs de Acceso Remoto

Propuesta de Tesina Redes VPN de acceso Remoto

VPNs de Acceso Remoto

VPNs de Acceso Remoto

ORGANIZACIN DEL TRABAJO

VPNs de Acceso Remoto

VPNs de Acceso Remoto

VPNs de Acceso Remoto

5.1 NDICES DE FIGURAS................................................................................................................115 5.2 REFERENCIAS BIBLIOGRFICAS .............................................................................................116

VPNs de Acceso Remoto

CAPTULO 1 INTRODUCCIN A LAS VPN

VPNs de Acceso Remoto

1.1 DEFINICIONES Y TERMINOLOGA

1.1.1 Red Privada

Asynchronous Transfer Mode

VPNs de Acceso Remoto

1.1.2 Red Pblica

1.1.3 Red Privada Virtual

VPNs de Acceso Remoto

1.1.4 Definicin de VPN

VPNs de Acceso Remoto

VPNs de Acceso Remoto

VPNs de Acceso Remoto

Figura 1-1 Componentes de una VPN

1.2.1 VPNs provistas por el cliente o por el proveedor

VPNs de Acceso Remoto

VPNS provistas por el cliente (CE o CPE VPN)

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

Figura 1-2 VPN Provista por el Cliente

VPNs de Acceso Remoto

VPNs provistas por el Proveedor (PPVPN)

RFC 3809 Generic Requirements for Provider Provisioned VPN

VPNs de Acceso Remoto

1.2.2 VPNs Sitio a Sitio y de Acceso Remoto

Figura 1-3 VPN Sitio a Sitio

Figura 1-4 VPN de Acceso Remoto

VPNs de Acceso Remoto

VPNs de acceso remoto: L2F (Layer 2 Forwarding)

PPTP (Point to Point Tunneling Protocol) L2TPv2/v3 IPSec SSL/TLS

Algunos de estos sern descriptos ms adelante en el captulo 2 dedicado a protocolos VPN.

1.2.3 VPNs de capa 2 y capa 3

VPNs de Acceso Remoto

1.2.4 Integracin de las clasificaciones

Figura 1-5 Clasificacin de las VPN

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

VPNs de Acceso Remoto

VPN Sitio a Sitio Provistas por el Proveedor

VPNs de Acceso Remoto

1.2.5 Confiables y Seguras

1.2.6 Overlay y Peer

VPNs de Acceso Remoto

Figura 1-6 Adyacencias del Ruteo

VPNs de Acceso Remoto

Figura 1-7 Infraestructura del proveedor

Figura 1-8 VPNs tipo Peer

VPNs de Acceso Remoto

1.2.7 No Orientadas y orientadas a la conexin

1.2.8 VPNs de capa de transporte/aplicacin

SSH v1 Autenticacin de sistemas Autenticacin Llaves de servidor y cliente Llaves

SSH v2 Llaves de host Certificados

Capa en la que trabaja Autenticacin