Redes Privadas Virtuales - E-LIS repositoryeprints.rclis.org/13992/1/fernandez2006redes.pdfInforme Técnico - ecThnical Report DPTOIA-IT-2006/004 septiembre, 2006 Redes Privadas Virtuales

Informe Técnico - Technical ReportDPTOIA-IT-2006/004

septiembre, 2006

Redes Privadas Virtuales

Jesús Fernández HernándezJosé Luis Alonso Berrocal

Carlos G.-Figuerola PaniaguaÁngel F. Zazo Rodríguez

Departamento de Informática y AutomáticaUniversidad de Salamanca

Revisado por:

Dr. Ángel Luis Sánchez LázaroDra. Vivian Félix López Batista

Aprobado en el Consejo de Departamento de 28 de septiembre de 2006

Información de los Autores:

D. Jesús Fernández Hernández

Estudiante del Programa de Doctorado en Fuentes de información en seguridad en

internet

Profesor de Secundaria de Sistemas Electrónicos

Profesor Asociado en el Departamento de Física Aplicada - Universidad de Salamanca

[email protected]

Dr. José Luis Alonso Berrocal

Área de Lenguajes y Sistema Informáticos. Departamento de Informática y Automática

Facultad de Traducción y Documentación - Universidad de Salamanca

C/ Francisco Vitoria, 6-16. 37008 - Salamanca

[email protected]

Dr. Carlos G.-Figuerola Paniagua




�[email protected]

Dr. Ángel F. Zazo Rodríguez,




[email protected]

Este documento puede ser libremente distribuido.(c) 2006 Departamento de Informática y Automática - Universidad de Salamanca.

Resumen

En este documento se recoge los motivos y las razones por las cuales las RedesPrivadas Virtuales están implantándose cada día con más fuerza en el ámbito dela comunicación de datos y la seguridad informática. También se razona y motivala elección de un tipo concreto de Red Privada Virtual (OpenVPN), para su imple-mentación y prueba. Se analiza a fondo este tipo de Red Virtual, con los diferentesescenarios en los cuales se puede aplicar, su con�guración e instalación. Finalmentese hace un análisis de los resultados obtenidos y de los posibles problemas de seguri-dad que puede presentar.

Abstract

In this text we compile the grounds and reasons why the Virtual Private Networksare being strongly introduced in the context of data communication and computersecurity.It is also reasoned out the election of a speci�c Virtual Private Network(OpenVPN), in order to be implemented and tested. We deeply analyze this kindof Virtual Network, the di�erent scenarios in which it can be applied, as well asits con�guration and installation. Finally we analyze the achieved results and thepossible security problems that may arise.

DPTOIA-IT-2006/004 i

Índice

Índice de �guras iv

1. Introducción 1

2. Redes Privadas Virtuales 2

3. Aplicaciones de las Redes Privadas Virtuales 2

4. Implementación de las Redes Privadas Virtuales 5

4.1. Implementación de VPN por Hardware . . . . . . . . . . . . . . . . . 6

4.2. Implementación de VPN por Software . . . . . . . . . . . . . . . . . . 7

5. Redes Privadas Virtuales por Software 8

5.1. Redes Privadas Virtuales por Software más habituales . . . . . . . . . 8

5.1.1. IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.1.2. PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.1.3. L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.1.4. VPNs SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.1.5. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.2. Comparación entre OpenVPN y VPN IPSec . . . . . . . . . . . . . . 14

6. ¾Qué Red Privada Virtual elegir? 15

7. Escenarios de aplicación de OpenVPN 16

7.1. Unión de dos redes separadas mediante OpenVPN en un medio públi-co (Puente) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7.2. Conexión de Clientes a un Servidor (Túnel) - Road Warrior . . . . . . 20

7.3. Conexión real vía Internet a un servidor mediante un túnel . . . . . . 25

7.3.1. Transferencia de información por el canal sin VPN . . . . . . 26

7.3.2. Transferencia de información por el canal con VPN y compresión 27

7.3.3. Transferencia de información por el canal con VPN y sin com-presión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7.3.4. Ejecución de una aplicación a través de la VPN . . . . . . . . 30

8. Exploit 32

8.1. Interfaz de administración de OpenVPN . . . . . . . . . . . . . . . . 35

8.2. Comando: �management IP port [pw-�le] . . . . . . . . . . . . . 36

8.3. Implementación del exploit . . . . . . . . . . . . . . . . . . . . . . . . 36

8.4. Conclusiones sobre el exploit . . . . . . . . . . . . . . . . . . . . . . . 37

ii DPTOIA-IT-2006/004

9. Conclusiones 38

A. Instalación de OpenVPN en Windows 41

B. Instalación de OpenVPN en Linux 47

C. Con�guración modo puente (bridge [dev-tap]) 51C.1. sample.ovpn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

C.2. server_red_i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

C.3. Server_XP_Red_ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

C.4. Clave key.txt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

C.5. Veri�cación del funcionamiento . . . . . . . . . . . . . . . . . . . . . 56

D. Con�guración modo túnel (tunnel [dev-tun]) 59D.1. client.ovpn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

D.2. server.ovpn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

D.3. Con�guración del servidor (server.conf) . . . . . . . . . . . . . . . . . 70

D.4. Con�guración de los clientes (ClientLinux.ovpn) . . . . . . . . . . . . 71

E. Con�guración de los �rewalls 73

F. Generación de las claves y de los certi�cados 77F.1. Generación de claves estáticas . . . . . . . . . . . . . . . . . . . . . . 79

F.1.1. En Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

F.1.2. Línea de Comandos . . . . . . . . . . . . . . . . . . . . . . . . 79

F.2. Generación de los Certi�cados . . . . . . . . . . . . . . . . . . . . . . 80

F.2.1. Generación del certi�cado maestro y clave de la AutoridadCerti�cadora (CA) . . . . . . . . . . . . . . . . . . . . . . . . 81

F.2.2. Generación del certi�cado y clave del Servidor . . . . . . . . . 81

F.2.3. Generación del certi�cado y clave para tres clientes . . . . . . 82

F.2.4. Generar parámetros de Di�e Hellman . . . . . . . . . . . . . 83

G. Script de arranque y parada en Linux 87G.1. Script de Arranque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

G.2. Script de Parada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

H. Con�guración del router 91H.1. Enrutamiento de los paquetes de OpenVPN . . . . . . . . . . . . . . 93

H.2. Apertura del puerto y NAT al servidor . . . . . . . . . . . . . . . . . 94

Referencias 97

DPTOIA-IT-2006/004 iii

Índice de �guras

1. Encapsulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Interconexión de redes . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4. Implementación de la interconexión de redes . . . . . . . . . . . . . . 17

5. Implementación �nal . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6. Ping a los extremos del túnel . . . . . . . . . . . . . . . . . . . . . . 18

7. Las dos máquinas virtuales con el túnel levantado . . . . . . . . . . . 19

8. Las dos máquinas virtuales con el túnel deshabilitado . . . . . . . . . 19

9. Conexión de clientes a un servidor . . . . . . . . . . . . . . . . . . . . 20

10. Conexión de 3 clientes a 1 servidor con distintas plataformas . . . . . 21

11. IPCONFIG del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . 23

12. Ping al extremo del túnel opuesto . . . . . . . . . . . . . . . . . . . . 23

13. Conexiones activas con el servidor . . . . . . . . . . . . . . . . . . . . 24

14. Las cuatro máquinas virtuales funcionando . . . . . . . . . . . . . . . 25

15. Implementación real de una OpenVPN . . . . . . . . . . . . . . . . . 26

16. Activación del Servicio en el Servidor . . . . . . . . . . . . . . . . . . 26

17. Veri�cación del funcionamiento de la OpenVPN . . . . . . . . . . . . 27

18. Activación del Servicio en el Cliente . . . . . . . . . . . . . . . . . . . 27

19. Veri�cación de la conexión del cliente . . . . . . . . . . . . . . . . . . 28

20. Veri�cación de la Conexión . . . . . . . . . . . . . . . . . . . . . . . . 28

21. Cliente y servidor trans�riéndose la información . . . . . . . . . . . . 29

22. Resultado de la transferencia normal . . . . . . . . . . . . . . . . . . 29

23. Cliente y servidor trans�riéndose la información a través de la VPN . 30

24. Resultado de la transferencia a través de la VPN . . . . . . . . . . . . 30

25. Eliminación de la compresión del cliente y del servidor . . . . . . . . 31

26. Resultado de la transferencia a través de la VPN sin compresión . . . 31

27. Con�guración de la aplicación . . . . . . . . . . . . . . . . . . . . . . 32

28. Comprobación de las conexiones en el servidor . . . . . . . . . . . . . 33

29. Sesión Telnet interfaz administrador sin clave . . . . . . . . . . . . . 37

30. Sesión Telnet interfaz administrador con clave . . . . . . . . . . . . . 38

31. Ventana de bienvenida . . . . . . . . . . . . . . . . . . . . . . . . . . 43

32. Licencia del producto . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

33. Componentes a instalar . . . . . . . . . . . . . . . . . . . . . . . . . . 44

34. Ubicación de la instalación . . . . . . . . . . . . . . . . . . . . . . . . 44

35. Proceso de instalación . . . . . . . . . . . . . . . . . . . . . . . . . . 45

36. Aviso de Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

37. Finalización de la instalación . . . . . . . . . . . . . . . . . . . . . . . 46

38. Servicio OpenVPN instalado e icono red . . . . . . . . . . . . . . . . 46

iv DPTOIA-IT-2006/004

39. Descompresión del paquete y creación de la estructura de directorios . 49

40. Resultado del con�gure . . . . . . . . . . . . . . . . . . . . . . . . . . 50

41. Resultado de make y make install . . . . . . . . . . . . . . . . . . . . 50

42. Resultado de la con�guración y puesta en marcha de la VPN . . . . . 57

43. Activación del Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . 75

44. Con�guración del Firewall . . . . . . . . . . . . . . . . . . . . . . . . 75

45. Acceso al programa de generación de claves estáticas en Windows . . 79

46. Resultado de la Generación . . . . . . . . . . . . . . . . . . . . . . . 80

47. Generación de la clave desde la línea de comandos . . . . . . . . . . . 80

48. Generación certi�cado Autoridad Certi�cadora (CA) . . . . . . . . . 81

49. Contenido del certi�cado CA . . . . . . . . . . . . . . . . . . . . . . . 82

50. Generación certi�cado y clave servidor . . . . . . . . . . . . . . . . . 82

51. Contenido del certi�cado del servidor . . . . . . . . . . . . . . . . . . 84

52. Generación del �chero de Di�e Hellman . . . . . . . . . . . . . . . . 85

53. Con�guración del router I . . . . . . . . . . . . . . . . . . . . . . . . 94

54. Con�guración del router II . . . . . . . . . . . . . . . . . . . . . . . . 95

DPTOIA-IT-2006/004 v

.

Fernández et al

1. Introducción

En la actualidad como en el pasado la informática intenta dar soluciones a losproblemas que la sociedad, la industria y las compañías le plantean.

En un pasado no muy lejano la prioridad era la necesidad de procesar y almace-nar información, con lo que nacieron los equipos informáticos individuales, posteri-ormente surgió la necesidad no sólo de procesar y almacenar la información sino queademás era preciso compartir la información en tiempo real entre distintos equiposinformáticos, por ello surgieron las redes locales (LAN).

A medida que las empresas crecían las redes fueron creciendo y se fueron ex-tendiendo en distintos edi�cios, localidades, regiones y países, nuevamente surgió lanecesidad de compartir la información entre las distintas ubicaciones que se encon-traban mucho más espaciadas.

Para cubrir esta demanda aparecen las redes de área extensa (WAN) imple-mentándose las interconexiones de muy distinta forma (Red telefónica conmutada,conexión punto a punto, X25, Frame Relay, etc).

Finalmente aparece la red de redes, Internet, y rápidamente surgen aplicacionesque la utilizan como soporte para transmitir la información entre distintos puntosque pueden estar próximos o en extremos opuestos del planeta.

En muchas ocasiones la información a transmitir, es información sensible, y con-secuentemente no debe ser accesible a terceros. ¾Cómo podemos transmitir infor-mación y que sólo sea accesible al transmisor y al receptor?. Parece claro que lossistemas criptográ�cos son la solución a este problema.

En la actualidad los sistemas criptográ�cos están ampliamente estudiados y de-sarrollados, aunque queda mucho por avanzar en este campo, no impide que seutilicen en la transmisión segura de información. Hay que notar, que aunque seutilicen canales privados de comunicación, la tecnología actual, la información y losconocimientos generales están a disposición de cualquiera, por lo que comunicacionesque aparentemente pueden ser seguras como una conexión punto a punto, pueda serinterceptada por un hacker para utilizarla en su propio provecho o para realizardaños a la empresa atacada.

Si una empresa decide utilizar un sistema criptográ�co para enviar información,¾necesita implementar desde cero dicho sistema? o ¾necesitaría aplicaciones especí-�cas para la transmisión de estos datos? La respuesta es no ya que en la actualidadexisten soluciones que permiten la transmisión ciertamente segura de la información.Estas soluciones se conocen como Redes Privadas Virtuales (VPN - Virtual PrivateNetwork).

DPTOIA-IT-2006/004 1


2. Redes Privadas Virtuales

¾Qué son las Redes Privadas Virtuales?. Como su nombre indica, podemos de-ducir que son redes de comunicación entre dos puntos (próximos o todo lo alejadosque podamos suponer), que queremos que sean privadas, o lo que es lo mismo, quela información que transmite sea privada entre emisor y receptor. El término devirtual se aplica a la privacidad y no al término de red, ya que lo que se pretendeen la mayoría de los casos, es la transmisión a través de un canal público y abierto,con lo cual si tenemos una red privada a través de este canal público, ésta ha de servirtual.

En de�nitiva, las de�niciones que podemos encontrar del signi�cado e implicaciónde una red privada virtual, son múltiples [10], que concretaremos en:

�Una red privada virtual es una implementación o sistema que habilita una comu-

nicación segura a través de un medio inseguro, siendo transparente para el usuario

u aplicación que realiza y recibe la comunicación� [1][15][5][6].

Esta de�nición que es perfectamente válida, se puede ampliar y podremos decirque siempre que queramos asegurar una comunicación entre dos puntos, podremosutilizar una red privada virtual, independientemente del potencial de privacidad quetengamos en la comunicación, si la información ha de ser preservada de terceros porsu importancia.

También en algunas ocasiones se denomina a las redes privadas virtuales comotúneles, ya que estas transportan la información por un canal público, pero aislandola información del resto y consecuentemente creando unas �paredes� virtuales queseparan nuestra información de la del resto. Estas �paredes� virtuales forman untúnel virtual que impide atravesar la información en cualquiera de los dos sentidos.De ahí el nombre de túnel.

La separación de la información se logra mediante la encriptación de la misma,y el sistema será más seguro, cuanto mayor seguridad nos suministre el sistemacriptográ�co, siendo deseable que cualquier avance signi�cativo en el campo de lacriptografía, pueda ser implementado y transferido a nuestra Red Privada Virtual.

3. Aplicaciones de las Redes Privadas Virtuales

Los escenarios de aplicación de las Redes Privadas Virtuales son varios y vanparejos con la evolución histórica de la informática.

Inicialmente la informática nace como consecuencia de la necesidad de cálculoy de procesamiento de datos en un tiempo muy corto (como ejemplo tenemos elcálculo de tiro parabólico de un cañón), donde la información a procesar se alimentadirectamente al ordenador, éste la procesa y seguidamente devuelve los resultados.En este caso las necesidades de seguridad son mínimas, ya que la información sóloes accesible a los elementos que la manejan y en ningún instante está expuesta a

2 DPTOIA-IT-2006/004

Fernández et al

elementos externos.

Cuando la informática evoluciona, se comprueba que no es su�ciente con procesarla información, sino que además, es preciso compartir esta información entre distintosequipos, así como los recursos que pueden ser muy costosos también se puedencompartir. Nace la Red de Área Local (LAN - Local Area Network). ¾Qué ocurreen este caso cuando tenemos que transmitir información con�dencial de un equipo aotro?, la solución pasa por interconectar entre si aquellos equipos que comparten lainformación con�dencial, separando físicamente la red con�dencial de la red general.Esto presenta varios problemas, el primero es la duplicidad de recursos de red quese necesitan, ya que tendremos que montar y mantener dos redes. La segunda es queaún así la con�dencialidad no se puede considerar segura, puesto que la seguridadviene impuesta por la separación física de las dos redes, pero nada impide que en unadeterminada parte de la instalación alguien se pueda conectar a dicha red y leer losdatos que circulan. La solución pasa por usar la misma red general para transmitir lainformación con�dencial junto a la información abierta. Por consiguiente, aquí naceel primer escenario de aplicación de las Redes Privadas Virtuales, como separaciónen una Intranet de aquellos departamentos, personas o equipos, que no deban teneracceso a la información con�dencial de los que sí la puedan tener.

El siguiente paso de la Informática, se da de la mano de holding empresariales,que tienden a extender sus negocios en varios edi�cios y que necesitan interconectarentre sí todas sus o�cinas. En este caso las soluciones de interconexión pasaban porutilizar líneas punto a punto, X25, Frame Relay, etc conocidas con el nombre deRedes de Área Extensa (WAN - Wide Area Network). En este caso la informaciónse puede considerar hasta cierto punto segura, ya que los conocimientos necesariospara poder acceder a las líneas, no se encuentra al alcance de cualquier persona,además de los equipos necesario para ello. Hasta hace relativamente poco tiempoera el sistema preferido de bancos, o�cinas estatales, ejército, etc. Realmente en estetipo de conexiones no es muy necesario la utilización de las VPN.

No obstante el crecimiento empresarial y la globalización, nos lleva a un nuevoescenario, donde las empresas tienen o�cinas y sucursales en otras ciudades y enotros países. Al mismo tiempo los agentes móviles de las empresas (trabajadoresque se desplazan por la geografía, como servicios técnicos, asesores, inspectores,etc), necesitan también acceder a la información de la o�cina central o matriz, peroen este caso aparece un nuevo componente que es Internet, conocido como la Redde Redes, donde todos los ordenadores están conectados entre sí a nivel mundial.Por ser Internet de carácter público, parece lógico pensar que es el sistema másinseguro que podemos encontrar, y en efecto así es, la información que circula por lamisma está al alcance de cualquiera, y en este caso podemos encontrarnos ademáscon personal altamente cuali�cado en la interceptación de información. Pero pese aesta alto riesgo, las empresas están decididas a utilizar este medio, ¾Por qué?, buenolas razones son varias [16]:

Los costes de las comunicaciones dentro de la empresa suponen un incrementoimportante en la cuenta de resultados de la misma. Como Internet es un servi-cio que suele estar implantado en la mayoría de ellas, si se pudiera utilizar para



transmitir la información, se abaratarían los mismos de forma considerable, yaque las conexiones de Internet tiene unos precios muy bajos.

Dada la penetración de Internet en los distintos países del planeta es muyposible encontrar en la mayoría de la geografía un Proveedor de Servicios (IPS- Internet Service Provider), que permitirá la conexión de los agentes móvilesde la empresa con la o�cina principal.

Internet asegura, un encaminamiento o ruta segura desde una localización aotra. Si por alguna circunstancia, la comunicación se corta entre los dos puntosde la comunicación, los nodos de la red de Internet son capaces de buscarcaminos alternativos para que la información llegue a su lugar, claro está,siempre y cuando la zona afectada no sea uno de nuestros nodos de acceso.

Esto de�ne el segundo escenario donde pueden aparecer las VPN, que es en lascomunicaciones a larga distancia entre o�cinas, agentes móviles y la o�cina centralusando Internet, ya que la encriptación de la información por la misma impide sulectura y/o modi�cación.

El último escenario donde podemos encontrar la utilización de las VPNs es relati-vamente reciente y aparece en las conexiones inalámbricas (wireless), dado que estasconexiones están expuestas a la interceptación de cualquiera que se encuentre dentrodel alcance de la misma. Y aunque los routers con conexión wireless suelen utilizaralgún algoritmo de cifrado WPA (Wi-Fi Protected Access - Acceso Protegido Wi-Fi)y WEP (Wired Equivalent Privacy - Privacidad Equivalente a Cableado); siendo esteúltimo sistema muchos menos seguro que el primero (ataque estadístico que permiterecuperar la clave WEP). Aun así, si la información es realmente sensible, estos dossistemas de cifrado pueden ser insu�cientes y necesitaríamos recurrir a las VPNs.

Resumiendo los cuatro escenarios posibles son [7]:

1. Redes separadas y seguras en Intranets (VPN Interna).

2. Interconexión por Internet:

a) Conexión permanente entre o�cinas (VPN sitio-a-sitio).

b) Conexiones aleatorias de los agentes móviles con su o�cina (VPN de ac-ceso remoto).

3. Conexiones entre equipos mediante Wireless (VPN Interna).

¾Qué podemos esperar de una VPN? pues básicamente debe de garantizar lossiguientes puntos [4] [10]:

Con�dencialidad o privacidad Los datos transferidos deben estar disponiblessólo para las personas autorizadas.


Fernández et al

Con�abilidad o integridad Los datos transferidos no se deben poder cam-biar entre el remitente y el receptor.

Disponibilidad Los datos transferidos deben estar disponibles cuando sonnecesarios.

No Repudio para impedir que una vez �rmado un documento el signatariose retracte o niegue haberlo redactado.

Para cumplir las condiciones anteriores, los paquetes IP que se desean transmitir[1]:

Se cifran para garantizar la con�dencialidad.

Se �rman para garantizar la autenticidad, integridad y no repudio.

El paquete resultante se encapsula en un nuevo paquete IP y se envía a travésde la red insegura al otro extremo de la VPN:

Figura 1: Encapsulación

4. Implementación de las Redes Privadas Virtuales

Como hemos comentado, las redes privadas virtuales, deben de ser transparentesa los usuarios o aplicaciones que las utilizan. ¾Cómo podemos implementar unaVPN? [10].

Para responder a esta pregunta, analicemos el sistema que en la actualidad pre-domina en las comunicaciones, el modelo OSI (Open Systems Interconnection). Den-tro de este modelo de interconexión, como podemos observar en la �gura 2, sigueun �ujo continuo de datos.

El proceso de encriptación y desencriptación de la información se puede realizaren cualquier punto del �ujo de la información, sólo con la restricción de realizar losprocesos referidos en las mismas capas equivalentes [17].

Por consiguiente, atendiendo al modelo OSI, podemos apreciar en el mismo dosgrandes zonas: Hardware y Software. El término Hardware se re�ere al sistema de in-terconexión física de los dos equipos (capa física), mientras que el término Software seaplica al resto de capas del modelo OSI. Dado que la encriptación y desencriptaciónse puede realizar en los puntos que queramos, siempre y cuando sean capas equiva-lentes, podremos seleccionar estos dos puntos de�nidos, VPN por Hardware y VPNpor Software.



Figura 2: Modelo OSI

4.1. Implementación de VPN por Hardware

El proceso de encriptación y desencriptación se realiza a nivel físico en los pun-tos inmediatamente anterior e inmediatamente posterior al comienzo de la línea decomunicación. Por realizarse a nivel físico, necesitamos unos equipos que permitanrealizar esta tarea de forma transparente. Por lo general los elementos utilizados sonlos routers con VPN incorporada. Estos dispositivos llevan incorporado un proce-sador y algoritmos de encriptación y desencriptación. Tienen la ventaja de que elfabricante nos da realizada la implementación y su instalación y uso es extremada-mente sencillo, ya que solo tenemos que intercalar los routers en los puntos desalida y entrada de la línea de comunicación y activar en los routers la encriptación-desencriptación, así como con�gurar la contraseña, certi�cación o medio que servirápara la encriptación y desencriptación de la información.

Las VPN implementadas por hardware, presentan el inconveniente, de que elsistema de encriptación viene impuesto por el fabricante, y depende del mismo paralas actualizaciones.

Dentro de esta categoría se puede incluir los routers wireless con encriptación,bien mediante WPA o/y WEP, ya que crean un túnel entre el router y la tarjetawireless que impiden en cierta forma la lectura y modi�cación de la información.En este caso el medio de transporte son las ondas electromagnéticas y por tener elrouter y la tarjeta inalámbrica la antena, la encriptación se realiza a nivel de capafísica.

En [13] podemos encontrar un manual de con�guración de uno de estos produc-tos.

Las ventajas e inconvenientes que presenta este tipo de con�guración son:

1. Ventajas

La instalación y la con�guración son relativamente sencillas.

No necesita personal especializado y su mantenimiento es mínimo.


Fernández et al

Un único elemento puede habilitar varias VPNs ubicadas en distintossitios.

El sistema es independiente de las máquinas conectadas a la red.

No necesitamos máquinas dedicadas para realizar la VPN.

2. Inconvenientes

Depende de una tecnología externa y cerrada.

El �rmware de los sistemas es cerrado y dependemos del fabricante parapoder cambiarlo.

Los sistemas de encriptación suelen ser cerrados y el fabricante sueleutilizar un único tipo.

En la mayoría de las ocasiones los elementos hardware de los extremosque componen la red privada virtual, que deben ser iguales o por lo menosdel mismo fabricante. No siendo corriente que sean intercambiables porlos de otros fabricantes.

Sólo sirven para realizar conexiones VPN dentro de la misma red (in-tranet) o sólo fuera de la red, pero no pueden realizar simultáneamentelas dos opciones, aunque esto es algo que pudiera cambiar en el futuro.

La seguridad sólo se implementa desde los dos extremos de la VPN, siendoinseguro el camino que recorre la información desde el ordenador hastael dispositivo VPN.

4.2. Implementación de VPN por Software

Cada día se está imponiendo más la utilización de Redes Privadas Virtualespor software. La explicación radica en la necesidad que cada vez más tienen losmedianos y pequeños usuarios, de implementar sistemas de seguridad en el acceso asus máquinas. Como además son sistemas que tienden a crecer de forma rápida, esmucho mas barato la utilización de Redes Privadas Virtuales por software que porhardware.

Las ventajas y desventajas que pueden presentar este tipo de redes son:

1. Ventajas:

Existe una gran variedad de Redes Privadas Virtuales desarrolladas porsoftware, donde elegir y que están continuamente mejorando sus presta-ciones.

El número de usuarios de este tipo de red es mucho mayor que el númerode usuarios de VPNs realizadas por hardware, con lo que la posibilidadde encontrar documentación y ayuda para estos elementos es mayor.

Pueden dar cobertura tanto a redes internas (intranet) como redes exter-nas.



La seguridad puede cubrir de máquina a máquina, donde se encuentrencolocados los extremos de la VPN.

2. Inconvenientes:

Es necesario instalar el software en una máquina, pudiendo ser necesario,si la carga de información es muy grande, tener que dedicar una máquinapara este menester.

El sistema de claves y certi�cados están en máquinas potencialmenteinseguras, que pueden ser atacadas.

Si el software es de libre distribución, éste puede estar modi�cado y con-tener puertas traseras.

En el presente trabajo estudiaremos las Redes Privadas Virtuales por software,dadas las ventajas que presentan frente a sus homónimas realizadas por hardware.

5. Redes Privadas Virtuales por Software

Como se ha comentado con anterioridad, existe un amplio abanico de imple-mentaciones de Redes Privadas Virtuales por Software. Pasaremos a describir lasmás utilizadas con sus ventajas e inconvenientes, para �nalmente elegir aquella quemas seguridad, �abilidad y ventajas presente frente a las otras.

5.1. Redes Privadas Virtuales por Software más habituales

De todos los tipos disponibles, podemos citar por ser las más utilizadas:

IPSec

PPTP

L2TP

VPNs SSL/TLS

OpenVPN

5.1.1. IPSec

Es la abreviatura de Internet Protocol Security. [18][19] Inicialmente se de-sarrolló para usarse con el estandar IPv6 y posteriormente se adaptó a IPv4. Esuna extensión al protocolo IP. Añade los servicios de autenticación y cifrado. IPSecactúa dentro del modelo OSI en la capa 3 (capa de red). No está ligado a ningún


Fernández et al

algoritmo de encriptación o autenticación, tecnología de claves o algoritmos de se-guridad especí�co. De hecho es un estandar que permite que cualquier algoritmonuevo se pueda introducir. Por sus características es considerado como el protocoloestándar para la construcción de redes privadas virtuales.

[15] La especi�cación del protocolo se encuentra en la RFC 2401 [12]. IPSeccuenta con dos protocolos diferentes, de forma que se empleará uno u otro en funciónde lo que nos interese proteger y el modo en que realicemos las comunicaciones.

Cabecera de Autenticación (Authentication Header, AH). Se tratade una nueva cabecera que obtenemos de la básica IP y que se añade a losresúmenes criptográ�cos ("hash") de los datos e información de identi�cación.

Encapsulado de Seguridad (Encapsulating Security Payload, ESP).Permite reescribir los datos en modo cifrado. No considera los campos de lacabecera IP por lo que sólo garantiza la integridad de los datos.

Ambos protocolos controlan el acceso y distribuyen las claves criptográ�cas. Nopueden ser aplicados los dos a la vez. Lo que sí se permite es aplicarlos uno despuésde otro, es decir, a un datagrama IP aplicarle un protocolo y al paquete resultanteaplicarle otro. Si se hace esto el orden de aplicación es: ESP-AH Cada uno de estosprotocolos pueden funcionar en dos modos distintos:

modo transporte.

modo túnel.

El modo transporte [14] es el que usa un an�trión que genera los paquetes.En modo transporte, las cabeceras de seguridad se añaden antes que las cabecerasde la capa de transporte (TCP, UDP), antes de que la cabecera IP sea añadida alpaquete.

El modo Túnel se usa cuando la cabecera IP extremo-a-extremo ya ha sidoadjuntada al paquete, y uno de los extremos de la conexión segura es solamente unapasarela.

5.1.2. PPTP

PPTP (Point to Point Tunneling Protocol) [18] es un protocolo desarrolladopor Microsoft, U.S. Robotics, Ascend Communications, 3Com/Primary Access, ECITelematics conocidas colectivamente como PPTP Forum, para implementar redesprivadas virtuales o VPN.

La seguridad de PPTP ha sido completamente rota y las instalaciones con PPTPdeberían ser retiradas o actualizadas a otra tecnología de VPN. La utilidad ASLEAPpuede obtener claves de sesiones PPTP y descifrar el trá�co de la VPN. Los ataques



a PPTP no pueden ser detectados por el cliente o el servidor porque el exploit espasivo.

El fallo de PPTP es causado por errores de diseño en la criptografía en los pro-tocolos handshake o apretón de manos LEAP de Cisco y MSCHAP-v2 de Microsofty por las limitaciones de la longitud de la clave en MPPE.

La actualización de PPTP para las plataformas Microsoft viene por parte deL2TP o IPsec. Su adopción es lenta porque PPTP es fácil de con�gurar, mientrasL2TP requiere certi�cados de clave pública, e IPsec es complejo y poco soportadopor plataformas antiguas como Windows 98 y Windows Me.

5.1.3. L2TP

(Layer 2 Tunneling Protocol) [18] L2TP fue diseñado por un grupo de trabajode IETF como el heredero aparente de los protocolos PPTP y L2F, creado paracorregir las de�ciencias de estos protocolos y establecerse como un estándar.

El transporte de L2TP está de�nido para una gran variedad de tipos de paquete,incluyendo X.25, Frame Relay y ATM.

A pesar de que L2TP ofrece un acceso económico, con soporte multiprotocolo yacceso a redes de área local remotas, no presenta unas características criptográ�casespecialmente robustas. Por ejemplo:

Sólo se realiza la operación de autenticación entre los puntos �nales del túnel,pero no para cada uno de los paquetes que viajan por él. Esto puede dar lugara suplantaciones de identidad en algún punto interior al túnel.

Sin comprobación de la integridad de cada paquete, sería posible realizar unataque de denegación del servicio por medio de mensajes falsos de control queden por acabado el túnel L2TP o la conexión PPP subyacente.

L2TP no cifra en principio el trá�co de datos de usuario, lo cual puede darproblemas cuando sea importante mantener la con�dencialidad de los datos.

A pesar de que la información contenida en los paquetes PPP puede ser cifrada,este protocolo no dispone de mecanismos para generación automática de claves,o refresco automático de claves. Esto puede hacer que alguien que escuche enla red y descubra una única clave tenga acceso a todos los datos transmitidos.

A causa de estos inconvenientes se tomó la decisión de utilizar los propios pro-tocolos IPSec para proteger los datos que viajan por un túnel L2TP.

L2TP es en realidad una variación de un protocolo de encapsulamiento IP. Untúnel L2TP se crea encapsulando una trama L2TP en un paquete UDP, el cuales encapsulado a su vez en un paquete IP, cuyas direcciones de origen y destinode�nen los extremos del túnel. Siendo el protocolo de encapsulamiento más externoIP, los protocolos IPSec pueden ser utilizados sobre este paquete, protegiendo así lainformación que se transporta por el túnel.

10 DPTOIA-IT-2006/004

Fernández et al

5.1.4. VPNs SSL/TLS

SSL/TLS Secure Sockets Layer/Transport Layer Security [18] existen pe-queñas diferencias entre SSL 3.0 y TLS 1.0, pero el protocolo permanece sustan-cialmente igual. El término "SSL"según se usa aquí, se aplica a ambos protocolosa menos que el contexto indique lo contrario. SSL proporciona autenti�cación yprivacidad de la información entre extremos sobre Internet mediante el uso de crip-tografía. Habitualmente, sólo el servidor es autenti�cado (es decir, se garantiza suidentidad) mientras que el cliente se mantiene sin autenti�car; la autenti�caciónmutua requiere un despliegue de infraestructura de claves públicas (o PKI) paralos clientes. Los protocolos permiten a las aplicaciones cliente-servidor comunicarsede una forma diseñada para prevenir escuchas (eavesdropping), la falsi�cación de laidentidad del remitente y mantener la integridad del mensaje.

SSL implica una serie de fases básicas:

Negociar entre las partes el algoritmo que se usará en la comunicación.

Intercambio de claves públicas y autenticación basada en certi�cados digitales.

Encriptación del trá�co basado en cifrado simétrico.

Durante la primera fase, el cliente y el servidor negocian qué algoritmos crip-tográ�cos se van a usar. Las implementaciones actuales proporcionan las siguientesopciones:

Para criptografía de clave pública: RSA, Di�e-Hellman, DSA (Digital Signa-ture Algorithm) o Fortezza.

Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption Al-gorithm), DES (Data Encryption Standard), Triple DES o AES (AdvancedEncryption Standard).

Con funciones hash: MD5 o de la familia SHA.

TLS/SSL poseen una variedad de medidas de seguridad:

Numerando todos los registros y usando el número de secuencia en el MAC.

Usando un resumen de mensaje mejorado con una clave (de forma que solocon dicha clave se pueda comprobar el MAC).

Protección contra varios ataques conocidos (incluidos ataques man in the mid-

dle attack), como los que implican un degradado del protocolo a versionesprevias (por tanto, menos seguras), o conjuntos de cifrados más débiles.

El mensaje que �naliza el protocolo handshake (Finished) envía un hash detodos los datos intercambiados y vistos por ambas partes.

DPTOIA-IT-2006/004 11


La función seudo aleatoria divide los datos de entrada en 2 mitades y las proce-sa con algoritmos hash diferentes (MD5 y SHA), después realiza sobre ellosuna operación XOR. De esta forma se protege a sí mismo de la eventualidadde que alguno de estos algoritmos se revelen vulnerables en el futuro.

SSL se ejecuta en una capa entre los protocolos de aplicación como HTTP, SMTP,NNTP y sobre el protocolo de transporte TCP, que forma parte de la familia deprotocolos TCP/IP. Aunque pueda proporcionar seguridad a cualquier protocoloque use conexiones de con�anza (tal como TCP), se usa en la mayoría de los casosjunto a HTTP para formar HTTPS.

SSL también puede ser usado para tunelar una red completa y crear una redprivada virtual (VPN), como en el caso de OpenVPN.

5.1.5. OpenVPN

OpenVPN [18] es una solución de conectividad basada en software: SSL (SecureSockets Layer) VPN Virtual Private Network (red virtual privada), OpenVPN ofrececonectividad punto-a-punto con validación, jerárquica de usuarios y host conectadosremotamente, resulta una muy buena opción en tecnologías Wi-Fi (redes inalámbri-cas EEI 802.11) y soporta una amplia con�guración, entre ellas balanceo de cargasentre otras. Está publicado bajo licencia de código-libre (Open Source).

Algunas de sus ventajas son [4]:

Implementación de la VPN en la capa 2 y la capa 3 del modeloOSI: OpenVPN ofrece dos modos básicos, que funcionamiento como la capa2 o capa 3. Así los túneles de OpenVPN pueden también transportar tramasde Ethernet, los paquetes del IPX, y los paquetes del navegador de la redde Windows (NETBIOS), que son un problema en la mayoría de las otrassoluciones de VPN.

Protección de sesión con el cortafuego interno: Una sesión conectadacon la o�cina central de su compañía con un túnel VPN puede cambiar elsetup de su red en su ordenador portátil, para enviar todo su trá�co de lared a través del túnel. Una vez que OpenVPN haya establecido un túnel,el cortafuego central en la o�cina central de la compañía puede proteger elordenador portátil, aún cuando él no sea una máquina local. Solamente unpuerto de la red se debe abrir en local para trabajar la sesión. El cortafuegocentral protege al empleado siempre que él o ella esté conectado a través delVPN.

Las conexiones de OpenVPN pueden ser establecidas a través de casicualquier cortafuego: Si tienes acceso a Internet y si puedes tener acceso ala Web, los túneles de OpenVPN deben de trabajar.

Soporte de Proxy y con�guraciones: OpenVPN tiene soporte de Proxy yse puede con�gurar para funcionar como un servicio de TCP o de UDP, y como

12 DPTOIA-IT-2006/004

Fernández et al

servidor o cliente. Como servidor, OpenVPN espera simplemente hasta que uncliente solicita una conexión, mientras que como cliente, intenta establecer unaconexión según su con�guración.

Apertura de un solo puerto en el cortafuego para permitir conex-iones entrantes: Desde OpenVPN 2.0, el modo especial del servidor permiteconexiones entrantes múltiples en el mismo puerto del TCP o del UDP, mien-tras que todavía usa diversas con�guraciones para cada conexión.

Los interfaces virtuales permiten reglas muy especí�cas del establec-imiento de una red y del cortafuego: Todas las reglas, restricciones,mecanismos de la expedición, y conceptos como NAT se pueden utilizar conlos túneles de OpenVPN.

Alta �exibilidad con posibilidades extensas de lenguaje interpretado(scripting): OpenVPN ofrece numerosos puntos durante la conexión para laejecución de los scripts individuales. Estos script se pueden utilizar para unagran variedad de propósitos de la autenti�cación, recuperación en caso de fallos(failover) y más.

Soporte transparente y alto rendimiento para IPs dinámicas: Si se usaOpenVPN, no hay necesidad de utilizar más IPs estáticas de cualquier ladodel túnel. Ambas puntos �nales del túnel pueden tener acceso barato de ADSLcon el IPs dinámicas y los usuarios no notarán un cambio del IP de cualquierlado. Las sesiones del Terminal Server de Windows y las sesiones seguras deShell (SSH) parecerán congeladas solamente por algunos segundos, pero noterminarán y continuarán con la acción solicitada después de una corta pausa.

Ningún problema con NAT: El servidor y los clientes de OpenVPN puedenestar dentro de una red usando solamente direcciones privadas del IP. Cadacortafuego se puede utilizar para enviar el trá�co del túnel al otro punto �naldel túnel.

Instalación simple en cualquier plataforma: La instalación y el uso sonincreíblemente simples. Especialmente, si ha intentado instalar IPsec con di-versas con�guraciones, se apreciará la facilidad de instalación de OpenVPN.

Diseño modular: El diseño modular con un alto grado de simplicidad enseguridad y establecimiento de una red es excepcional. Ninguna otra soluciónde VPN puede ofrecer la misma gama de posibilidades a este nivel de seguridad.

Además con la versión 2.0 se incorporó las siguientes mejoras:

Soporte Multi-cliente: OpenVPN ofrece un modo de conexión especial,donde proporcionan a los clientes TLS-autenticados al estilo DHCP de IPsen el establecimiento de la red (túnel). De esta manera, varios túneles (hasta128) pueden comunicarse sobre el mismo puerto del TCP o del UDP. Obvia-mente, es necesario activar un switch para activar el modo servidor.

DPTOIA-IT-2006/004 13


Opciones de Envío/Recepción: La con�guración de la red de clientes puedeser controlada por el servidor. Después de la con�guración correcta del túnel, elservidor puede decir al cliente (Windows y Linux) que utilice una con�guracióndiferente de red instantáneamente.

Interfaz de control (Telnet): Se ha añadido una interfaz de control viaTelnet.

El driver y el software de Windows se han mejorado extensamente.

5.2. Comparación entre OpenVPN y VPN IPSec

Aun cuando IPsec es el estándar de facto, existen muchos argumentos para usarOpenVPN [21]. La tabla siguiente puede darnos argumentos para seleccionar Open-VPN (los puntos precedidos por �+� son ventajas y puntos precedidos por �-� sonlas desventajas)[4]:

IPsec VPN OpenVPN+ Es la tecnología estándar de VPN - Todavía es algo desconocido, no es

compatible con IPsec+ Plataformas de hardware (disposi-tivos, aplicaciones)

- Solamente se puede instalar en los or-denadores, pero en todos los sistemasoperativos. La excepción al párrafo an-terior, es cuando tenemos dispositivos,donde está ejecutándose OpenWrt1 ba-jo UNIXs y similares

+ Tecnología bien conocida - Nueva tecnología; todavía creciendo yaumentando

+ Existen muchos GUIs para su admi-nistración

- No hay ningún GUI profesional; sinembargo, hay algunos proyectos intere-santes y prometedores

- Modi�cación compleja de la pila delIP

+ Tecnología simple

- Es necesaria una modi�cación críticadel núcleo

+ Interfaces y paquetes estandarizadosde red

- Son necesario privilegios de adminis-trador

+ El software de OpenVPN puede fun-cionar en el espacio de usuario, y puedeser chroot-ed

- Diversas implementaciones de IPsecde diversos fabricantes pueden ser in-compatibles

+ Usa tecnologías estandarizadas decifrado

- Con�guración compleja, tecnologíacompleja

+ Tecnología fácil, bien estructurada,modular, con�guración fácil

- Curva grande de aprendizaje para losnovatos

+ fácil de aprender, éxito rápido paralos novatos

14 DPTOIA-IT-2006/004

Fernández et al

- Son necesarios varios puertos y proto-colos en el cortafuego

+ Solamente es necesario un puerto enel cortafuego

- Problemas con direcciones dinámicasen ambos lados

+ DynDNS trabaja enteramente,vuelve a conectar más rápidamente

- Problemas de la seguridad con las tec-nologías de IPsec

+SSL/TLS como capa criptográ�ca es-tándar industrial+ Tra�c shaping (Control de trá�co)+ velocidad (hasta 20 Mbps en unamáquina 1Ghz)+ Compatibilidad con los cortafuegos ylos proxies+ Ningunos problemas al realizar NAT(ambos lados pueden estar en las redesde NATed)+ Posibilidades de la con�guración delviajante (road warriors)

Tabla 1: Open VPN Versus IPSec

6. ¾Qué Red Privada Virtual elegir?

De los diversos tipos de redes privadas virtuales analizadas vamos a comentar lasdos posibles candidatas. La primera de ellas es la IPSec, ¾por qué hemos seleccionadoesta red?, la razón es bien simple: se considera un estándar dentro de la industria yestá ampliamente difundida e instalada. La segunda candidata es la OpenVPN, eneste caso se ha seleccionado por las críticas tan favorables que se encuentran en laliteratura consultada [9]. De las dos seleccionadas, nos decantamos por la segundaopción, siendo las razones desfavorables de más peso de la primera las siguientes:

Proceso de instalación y con�guración muy complicados.

Es necesario recompilación del núcleo en el caso de Linux.

Una mala con�guración puede dar problemas de seguridad (una excepción enla ejecución nos abre una shell con privilegios de root).

En el caso de la OpenVPN las razones que han hecho nos decidamos por ella,son:

1Apoyándose en Linux, desarrolla todo un sistema operativo embebido para routers inalámbricosy puntos de acceso como Cisco Linksys WRT54G. OpenWRT puede ejecutarse en un Cisco Linksyscon apenas 16MB de memoria y 8MB de �ash, y tiene soporte de VLAN, Firewalling, Snort,Asterisk, VoIP, DNS, DHCP, TFTP, NFS, SAMBA, BGP, QoS, NTP, etc, etc.

DPTOIA-IT-2006/004 15


Fácil instalación y con�guración.

Es una aplicación de libre distribución (licencia Open Source).

Es Código abierto.

El sistema de criptografía se basa en OpenSSL.

Es multiplataforma corriendo en los sistemas: Linux, Windows 2000/XP andhigher, OpenBSD, FreeBSD, NetBSD, Mac OS X, and Solaris y OpenVPNPocketPC port esta en desarrollo [20].

Por todo ello, la opción elegida es OpenVPN.

7. Escenarios de aplicación de OpenVPN

¾En qué situaciones podemos aplicar VPN?, ¾Qué escenarios son los más ade-cuados para su implementación?. Seguidamente daremos cuenta de las situacionesestudiadas.

7.1. Unión de dos redes separadas mediante OpenVPN en unmedio público (Puente)

Un caso frecuente es que tengamos dos redes que pertenecen a la misma corpo-ración y que se necesita unir para compartir recursos (acceso a servidores, trabajo deherramientas corporativas, etc.) Las dos redes se encuentran separadas físicamentey necesitamos unirlas a través de un medio público como puede ser una línea ADLSque da acceso a Internet.

Figura 3: Interconexión de redes

16 DPTOIA-IT-2006/004

Fernández et al

En este caso usaremos dos ordenadores donde levantaremos los extremos deltúnel. Toda la información que pongamos en un extremo del túnel pasará a travésde éste hasta el otro extremo, de forma cifrada y comprimida. El modo de operaciónde la VPN es en modo puente (bridge). En este caso estamos transmitiendo lainformación a nivel de enlace (nivel 2 del Modelo Osi) y consecuentemente, de modoindependiente al protocolo usado. Este quiere decir que todas las tramas (tcp, udp,ipx, NetBEUI, etc) que pongamos en el extremo del túnel aparecerá en el otroextremo, quedando unidas de esta forma las dos redes.

Sin embargo la implementación de prueba que se iba a realizar, no se pudo llevara cabo debido a problemas con la máquina virtual. La implementación que se intentómontar fue la de la �gura 4.

Figura 4: Implementación de la interconexión de redes

Lo que se pretendía, era compartir las carpetas ubicadas en cada una de las redesque estaban unidas mediante la VPN, para comprobar que las tramas de NetBEUIpodían atravesar de forma transparente el túnel. Sin embargo no fue posible poneren marcha esta implementación por problemas de las máquinas virtuales, que loimpidió. Ante estos problemas se decidió buscar una alternativa que permitieracomprobar estos extremos. La solución buscada fue la siguiente:

En la �gura 5 están las dos máquinas virtuales montadas sobre la misma redlocal, pero los �rewall de los dos equipos se han con�gurado de tal forma que lasúnicas tramas que se permiten son las del túnel VPN. Si efectivamente el túnelpermite el paso de cualquier trama, al estar levantado se podrán compartir y verlas carpetas entre ambos equipos, pero al deshabilitar el túnel las carpetas no seránvisibles desde el otro equipo1.

Desde una de las máquinas virtuales podemos hacer ping a los extremos deltúnel para comprobar su funcionamiento, tal y como vemos en la �gura 6.

1Se puede consultar el Anexo E para ver cómo están con�gurados los �rewalls.

DPTOIA-IT-2006/004 17


Figura 5: Implementación �nal

Figura 6: Ping a los extremos del túnel

Aquí podemos ver las dos máquinas virtuales activas con el puente funcionandoy podemos ver las carpetas compartidas.

Si por el contrario deshabilitamos el túnel en uno de los extremos para que dejede funcionar, obtenemos el siguiente resultado de la �gura 8 cuando intentamos abrirlas carpetas compartidas.

De esto deducimos que tanto las tramas NetBEUI como las tramas tcp (como sepuede comprobar con el ping), están atravesando el túnel. Por consiguiente hemosconseguido comprobar nuestro primer objetivo, y que no era otro que veri�car quela red OpenVPN en modo bridge actúa a nivel de enlace, permitiendo el paso decualquier trama a través del túnel, lo cual deja unidas de forma segura las dos redes.

Los problemas encontrados a la hora de realizar esta implementación, fueron lossiguientes:

18 DPTOIA-IT-2006/004

Fernández et al

Figura 7: Las dos máquinas virtuales con el túnel levantado

Figura 8: Las dos máquinas virtuales con el túnel deshabilitado

No se puede levantar un túnel entre 2 Windows 2003 Server (si se cambia unWindows 2003 Server por un XP funciona correctamente).

Para unir dos redes locales independientes necesitamos dos tarjetas de red quese conectarán mediante un puente de Windows y esto no se ha podido realizarporque las tarjetas de red de la máquina virtual han de ser distintas.

La con�guración de los dos equipos la podemos ver en el Anexo C.

DPTOIA-IT-2006/004 19


7.2. Conexión de Clientes a un Servidor (Túnel) - Road War-rior

Esta es una situación muy habitual dentro de las empresas corporativas. Nosencontramos con una serie de agentes móviles que necesitan desplazarse por distintasubicaciones relacionadas con la empresa (visita a clientes, visita a sucursales, visita aproveedores, etc). En esta situación también es típico que el viajero necesite accedera la red corporativa, para realizar pedidos, informes, consultas, acceder a su correo,etc. Un grá�co de esta situación lo tenemos en la �gura 9.

Figura 9: Conexión de clientes a un servidor

La OpenVPN permite un modo de conexión que soluciona este problema. Es elmodo dev_tun. En este modo la comunicación se realiza a nivel de red (nivel 3 delmodelo OSI ). También permite la conexión de más de un cliente con el servidor deforma segura.

En este modo el servidor actúa de DHCP para dar direcciones a los clientes.Estas direcciones tienen una máscara de subred, que no permite al cliente establecerninguna conexión más.

En esta opción comprobaremos que es posible la comunicación a través del túnelde la OpenVPN entre distintas plataformas (Linux, Windows 2003 server y Win-dows XP), así como la utilización de certi�cados para asegurar la seguridad de lacomunicación. La simulación que se realizará la podemos ver en la �gura 10.

Como se puede observar en la �gura utilizaremos 4 máquinas virtuales con unLinux Red Hat, un Windows 2003 server y 2 Windows XP, siendo el servidor lamáquina Linux. Probaremos a hacer un telnet desde los clientes al servidor y com-probaremos como se encuentran montados los túneles entre los clientes y el servidor,así como el funcionamiento adecuado de los certi�cados digitales.

Una vez con�gurados las 4 OpenVPN con los �cheros de con�guración y con loscerti�cados procedemos a levantar el servidor, ejecutando el script que tenemos a

20 DPTOIA-IT-2006/004

Fernández et al

Figura 10: Conexión de 3 clientes a 1 servidor con distintas plataformas

tal efecto (consultar el anexo G):

. ./openvpn-startup.sh

Y comprobamos que el extremo del túnel de la parte del servidor ha funcionadocorrectamente, comprobando el archivo de log server-openvpn.log como podemos verseguidamente:

Wed Jul 5 06:21:26 2006 OpenVPN 2.0.7 i686-pc-linux [SSL] [LZO] built on Jun 6 2006

Wed Jul 5 06:21:26 2006 Diffie-Hellman initialized with 1024 bit key

Wed Jul 5 06:21:26 2006 TLS-Auth MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]

Wed Jul 5 06:21:26 2006 TUN/TAP device tun0 opened

Wed Jul 5 06:21:26 2006 /sbin/ifconfig tun0 10.3.3.1 pointopoint 10.3.3.2 mtu 1500

Wed Jul 5 06:21:26 2006 /sbin/route add -net 10.3.3.0 netmask 255.255.255.0 gw 10.3.3.2

Wed Jul 5 06:21:26 2006 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]

Wed Jul 5 06:21:26 2006 Listening for incoming TCP connection on [undef]:1194

Wed Jul 5 06:21:26 2006 TCPv4_SERVER link local (bound): [undef]:1194

Wed Jul 5 06:21:26 2006 TCPv4_SERVER link remote: [undef]

Wed Jul 5 06:21:26 2006 MULTI: multi_init called, r=256 v=256

Wed Jul 5 06:21:26 2006 IFCONFIG POOL: base=10.3.3.4 size=62

Wed Jul 5 06:21:26 2006 IFCONFIG POOL LIST

Wed Jul 5 06:21:26 2006 LIN-CLI-1,10.3.3.4

Wed Jul 5 06:21:26 2006 LIN-CLI-2,10.3.3.8

Wed Jul 5 06:21:26 2006 LIN-CLI-3,10.3.3.12

Wed Jul 5 06:21:26 2006 MULTI: TCP INIT maxclients=1024 maxevents=1028

Wed Jul 5 06:21:26 2006 Initialization Sequence Completed

El extremo del túnel ha arrancado perfectamente. Seguidamente arrancamosla segunda máquina virtual con Windows 2003 server y estableceremos el primerpuente completo. Para ello pondremos en marcha el servicio de la OpenVPN en elWindows 2003 server. El �chero de log de esta máquina nos con�rmará si se haestablecido el túnel:

Mon Aug 14 22:06:15 2006 NOTE: --user option is not implemented on Windows

Mon Aug 14 22:06:15 2006 NOTE: --group option is not implemented on Windows

DPTOIA-IT-2006/004 21


Mon Aug 14 22:06:15 2006 OpenVPN 2.0.7 Win32-MinGW [SSL] [LZO] built on Apr 12 2006

Mon Aug 14 22:06:15 2006 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number

assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.

Mon Aug 14 22:06:15 2006 LZO compression initialized

Mon Aug 14 22:06:15 2006 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]

Mon Aug 14 22:06:15 2006 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]

Mon Aug 14 22:06:15 2006 Local Options hash (VER=V4): '69109d17'

Mon Aug 14 22:06:15 2006 Expected Remote Options hash (VER=V4): 'c0103fa8'

Mon Aug 14 22:06:15 2006 Attempting to establish TCP connection with 10.1.171.120:1194

Mon Aug 14 22:06:15 2006 TCP connection established with 10.1.171.120:1194

Mon Aug 14 22:06:15 2006 TCPv4_CLIENT link local: [undef]

Mon Aug 14 22:06:15 2006 TCPv4_CLIENT link remote: 10.1.171.120:1194

Mon Aug 14 22:06:16 2006 TLS: Initial packet from 10.1.171.120:1194, sid=016b51be 77a9837d

Mon Aug 14 22:06:16 2006 VERIFY OK: depth=1, /C=SP/ST=AV/L=AVILA/O=USAL/CN=LINUX/[email protected]

Mon Aug 14 22:06:16 2006 VERIFY OK: depth=0, /C=SP/ST=AV/O=USAL/CN=SERVER/[email protected]

Mon Aug 14 22:06:16 2006 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

Mon Aug 14 22:06:16 2006 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Mon Aug 14 22:06:16 2006 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key

Mon Aug 14 22:06:16 2006 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Mon Aug 14 22:06:16 2006 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

Mon Aug 14 22:06:16 2006 [SERVER] Peer Connection Initiated with 10.1.171.120:1194

Mon Aug 14 22:06:17 2006 SENT CONTROL [SERVER]: 'PUSH_REQUEST' (status=1)

Mon Aug 14 22:06:17 2006 PUSH: Received control message: 'PUSH_REPLY,route 10.3.3.1,ping 10,

ping-restart 120,ifconfig 10.3.3.6 10.3.3.5'

Mon Aug 14 22:06:17 2006 OPTIONS IMPORT: timers and/or timeouts modified

Mon Aug 14 22:06:17 2006 OPTIONS IMPORT: --ifconfig/up options modified

Mon Aug 14 22:06:17 2006 OPTIONS IMPORT: route options modified

Mon Aug 14 22:06:18 2006 TAP-WIN32 device [OpenVPN] opened: \\.\Global\{0D1F1079-1514-4DA8-9C8F-00A5FDD9F37F}.tap

Mon Aug 14 22:06:18 2006 TAP-Win32 Driver Version 8.1

Mon Aug 14 22:06:18 2006 TAP-Win32 MTU=1500

Mon Aug 14 22:06:18 2006 Notified TAP-Win32 driver to set a DHCP IP/netmask of

10.3.3.6/255.255.255.252 on interface {0D1F1079-1514-4DA8-9C8F-00A5FDD9F37F}

[DHCP-serv: 10.3.3.5, lease-time: 31536000]

Mon Aug 14 22:06:18 2006 Successful ARP Flush on interface [2] {0D1F1079-1514-4DA8-9C8F-00A5FDD9F37F}

Mon Aug 14 22:06:18 2006 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down

Mon Aug 14 22:06:18 2006 Route: Waiting for TUN/TAP interface to come up...









Mon Aug 14 22:06:23 2006 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up

Mon Aug 14 22:06:23 2006 route ADD 10.3.3.1 MASK 255.255.255.255 10.3.3.5

Mon Aug 14 22:06:23 2006 Route addition via IPAPI succeeded

Mon Aug 14 22:06:23 2006 Initialization Sequence Completed

Podemos apreciar como la secuencia de inicialización en el Windows 2003 Serverha �nalizado correctamente. Para veri�car que el puente funciona correctamenteveamos como ha quedado la red de esta máquina según la �gura 11.

Observar la máscara de subred que el servidor ha dado al cliente (255.255.255.252).

Si realizamos un ping sobre el extremo del túnel en el servidor el resultado es la�gura 12.

El resultado sobre el servidor lo podemos ver en el siguiente listado:

Wed Jul 5 06:21:26 2006 OpenVPN 2.0.7 i686-pc-linux [SSL] [LZO] built on Jun 6 2006

Wed Jul 5 06:21:26 2006 Diffie-Hellman initialized with 1024 bit key

Wed Jul 5 06:21:26 2006 TLS-Auth MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]

Wed Jul 5 06:21:26 2006 TUN/TAP device tun0 opened

Wed Jul 5 06:21:26 2006 /sbin/ifconfig tun0 10.3.3.1 pointopoint 10.3.3.2 mtu 1500

Wed Jul 5 06:21:26 2006 /sbin/route add -net 10.3.3.0 netmask 255.255.255.0 gw 10.3.3.2

22 DPTOIA-IT-2006/004

Fernández et al

Figura 11: IPCONFIG del cliente

Figura 12: Ping al extremo del túnel opuesto


Wed Jul 5 06:21:26 2006 Listening for incoming TCP connection on [undef]:1194

Wed Jul 5 06:21:26 2006 TCPv4_SERVER link local (bound): [undef]:1194

Wed Jul 5 06:21:26 2006 TCPv4_SERVER link remote: [undef]

Wed Jul 5 06:21:26 2006 MULTI: multi_init called, r=256 v=256

Wed Jul 5 06:21:26 2006 IFCONFIG POOL: base=10.3.3.4 size=62

Wed Jul 5 06:21:26 2006 IFCONFIG POOL LIST

Wed Jul 5 06:21:26 2006 LIN-CLI-1,10.3.3.4

Wed Jul 5 06:21:26 2006 LIN-CLI-2,10.3.3.8

Wed Jul 5 06:21:26 2006 LIN-CLI-3,10.3.3.12

Wed Jul 5 06:21:26 2006 MULTI: TCP INIT maxclients=1024 maxevents=1028

Wed Jul 5 06:21:26 2006 Initialization Sequence Completed

Wed Jul 5 06:33:02 2006 MULTI: multi_create_instance called

Wed Jul 5 06:33:02 2006 Re-using SSL/TLS context

Wed Jul 5 06:33:02 2006 LZO compression initialized

Wed Jul 5 06:33:02 2006 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]


Wed Jul 5 06:33:02 2006 Local Options hash (VER=V4): 'c0103fa8'

Wed Jul 5 06:33:02 2006 Expected Remote Options hash (VER=V4): '69109d17'

DPTOIA-IT-2006/004 23


Wed Jul 5 06:33:02 2006 TCP connection established with 10.1.171.130:1120

Wed Jul 5 06:33:02 2006 TCPv4_SERVER link local: [undef]

Wed Jul 5 06:33:02 2006 TCPv4_SERVER link remote: 10.1.171.130:1120

Wed Jul 5 06:33:02 2006 10.1.171.130:1120 TLS: Initial packet from 10.1.171.130:1120, sid=ef731f91 e1b57f6a

Wed Jul 5 06:33:02 2006 10.1.171.130:1120 VERIFY OK: depth=1,

/C=SP/ST=AV/L=AVILA/O=USAL/CN=LINUX/[email protected]

Wed Jul 5 06:33:02 2006 10.1.171.130:1120 VERIFY OK: depth=0,

/C=SP/ST=AV/O=USAL/CN=LIN-CLI-1/[email protected]

Wed Jul 5 06:33:02 2006 10.1.171.130:1120 Data Channel Encrypt:

Cipher 'BF-CBC' initialized with 128 bit key

Wed Jul 5 06:33:02 2006 10.1.171.130:1120 Data Channel Encrypt:

Using 160 bit message hash 'SHA1' for HMAC authentication

Wed Jul 5 06:33:02 2006 10.1.171.130:1120 Data Channel Decrypt:

Cipher 'BF-CBC' initialized with 128 bit key

Wed Jul 5 06:33:02 2006 10.1.171.130:1120 Data Channel Decrypt:

Using 160 bit message hash 'SHA1' for HMAC authentication

Wed Jul 5 06:33:03 2006 10.1.171.130:1120 Control Channel:

TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

Wed Jul 5 06:33:03 2006 10.1.171.130:1120 [LIN-CLI-1] Peer Connection Initiated with 10.1.171.130:1120

Wed Jul 5 06:33:03 2006 LIN-CLI-1/10.1.171.130:1120 MULTI: Learn: 10.3.3.6 -> LIN-CLI-1/10.1.171.130:1120

Wed Jul 5 06:33:03 2006 LIN-CLI-1/10.1.171.130:1120 MULTI: primary virtual IP for

LIN-CLI-1/10.1.171.130:1120: 10.3.3.6

Wed Jul 5 06:33:04 2006 LIN-CLI-1/10.1.171.130:1120 PUSH: Received control message: 'PUSH_REQUEST'

Wed Jul 5 06:33:04 2006 LIN-CLI-1/10.1.171.130:1120 SENT CONTROL [LIN-CLI-1]:

'PUSH_REPLY,route 10.3.3.1,ping 10,ping-restart 120,ifconfig 10.3.3.6 10.3.3.5' (status=1)

El siguiente paso es levantar los túneles de las dos máquinas Windows XP ycomprobar que existe comunicación desde las tres máquinas al servidor. Para elloharemos uso del comando netstat -n, que nos indicara las conexiones activas quetenemos, la �gura 13 nos indica el resultado obtenido.

Figura 13: Conexiones activas con el servidor

Podemos observar que el extremo del túnel del servidor tiene la dirección IP10.3.3.1, y las otras tres máquinas tienen las direcciones IPs: 10.3.3.6 10.3.3.1010.3.3.14. También se puede observar el establecimiento de los túneles entre el servi-dor 10.1.171.120 y los clientes 10.1.171.130 10.1.171.135 10.1.171.140.

Todo ello indica claramente que los tres clientes están conectados vía telnet alservidor.

24 DPTOIA-IT-2006/004

Fernández et al

La con�guración la podemos ver en el Anexo D y la creación de los certi�cadosy de las claves en el Anexo F [11].

Finalmente en la �gura 14 podemos ver las cuatro máquinas virtuales.

Figura 14: Las cuatro máquinas virtuales funcionando

7.3. Conexión real vía Internet a un servidor mediante untúnel

Como última implementación de un escenario, vamos a montar una OpenVPN deforma real entre dos máquinas separadas físicamente y conectadas mediante Internet.

El servidor es un Windows 2003 Server que ha generado los certi�cados para ély para el cliente. El cliente se encuentra en una máquina virtual instalada en unordenador portátil.

Se establecerá la conexión entre el servidor y el portátil y se harán pruebas derendimiento en la transmisión de los datos, para ello se enviará un �chero en distintassituaciones mediante ftp. La con�guración que vamos a implementar la tenemos enla �gura 15.

En el lado del servidor tenemos un router que ha de ser con�gurado (Ver el anexoH) para que admita el puerto de OpenVPN y además tenemos que realizar NAT paraenviar los paquetes de la VPN al servidor correspondiente. En la parte del clienteno hace falta, ya que como son salida de paquetes no hay que abrir ningún puerto.También dejaremos abierto unos puertos para poder conectarnos al servidor con elprograma de control VNC.

Comenzaremos activando el servicio de OpenVPN en el servidor, �gura 16.

Comprobamos que se ha levantado el extremo del túnel correctamente, �gura 17.

Y realizamos la misma operación en el cliente, �gura 18.

DPTOIA-IT-2006/004 25


Figura 15: Implementación real de una OpenVPN

Figura 16: Activación del Servicio en el Servidor

En el servidor, una vez se ha conectado el cliente, podemos observar esta acciónen la �gura 19.

Comprobamos que el DHCP del servidor le ha dado la IP del extremo del túnely veri�camos en el �chero de log que se ha realizado la conexión correctamente, estolo podemos observar en la �gura 20.

7.3.1. Transferencia de información por el canal sin VPN

Vamos a veri�car las velocidades de transferencia entre el cliente y el servidor.Para ello se ha dispuesto un servidor ftp, que nos permitirá transferir un �chero entreel cliente y el servidor en distintas situaciones y medir el tiempo de transferencia [3].

26 DPTOIA-IT-2006/004

Fernández et al

Figura 17: Veri�cación del funcionamiento de la OpenVPN

Figura 18: Activación del Servicio en el Cliente

La primera prueba de velocidad se realizará trans�riendo un �chero de aproxi-madamente 10 Mb entre las dos máquinas, sin pasar por la VPN. En la �gura 21podemos ver el cliente y el servidor ftp trans�riendo la información.

El resultado de la transferencia es: se envió 10.566.617 bytes en 493,543segundos, que corresponde a un tiempo de 8' 13� , como se pude apreciar enla �gura 22.

7.3.2. Transferencia de información por el canal con VPN y compresión

Seguidamente se conecta el cliente y el servidor a través de la VPN, veri�candoen la �gura 23 el establecimiento de la conexión.

DPTOIA-IT-2006/004 27


Figura 19: Veri�cación de la conexión del cliente

Figura 20: Veri�cación de la Conexión

El resultado de la transferencia del mismo �chero a través de la VPN con com-presión de datos es el siguiente: 10.566.617 bytes en 482,734 segundos, quecorresponde a un tiempo de 8' 2� , como se pude apreciar en la �gura 24. Estetiempo es ligeramente inferior al obtenido con la transferencia normal.

7.3.3. Transferencia de información por el canal con VPN y sin compre-sión

Para �nalizar esta prueba de transferencia de información a través de la VPN,volveremos a transmitir el �chero, pero en este caso quitaremos la compresión, paraveri�car que este parámetro puede tener relevancia a la hora de enviar una grancantidad de información.

28 DPTOIA-IT-2006/004

Fernández et al

Figura 21: Cliente y servidor trans�riéndose la información

Figura 22: Resultado de la transferencia normal

Se modi�can los dos �cheros de con�guración para suprimir la compresión comose puede apreciar en la �gura 25.

Se vuelve a transferir el �chero, una vez eliminada la compresión, obteniendolos siguientes resultados: 10.566.617 bytes en 464,682 segundos, que corre-sponde a un tiempo de 7' 44� . Tiempo inferior a los dos anteriores. Estos no sonsigni�cativos, dado que solo se ha realizado una única transmisión para cada caso ypueden haber in�uido otros factores que no se han teniendo en cuenta.

En la �gura 26 podemos ver la pantalla del cliente ftp con los resultados comen-tados.

DPTOIA-IT-2006/004 29


Figura 23: Cliente y servidor trans�riéndose la información a través de la VPN

Figura 24: Resultado de la transferencia a través de la VPN

7.3.4. Ejecución de una aplicación a través de la VPN

Para �nalizar las pruebas de conexión de la VPN a través de Internet, vamos aejecutar una aplicación que va a transferir los datos a través del túnel de la VPN.

En concreto la aplicación consiste en un programa de control de bibliotecasdenominado Abies 2, que utiliza como base de datos Microsoft Access. Esta base dedatos se encuentra en el servidor y se abrirá desde el cliente a través del túnel paraver en la pantalla del mismo la aplicación en ejecución.

Empezamos con�gurando la aplicación para que los datos pasen a través deltúnel de la VPN, tal y como se observa en la �gura 27, apuntando al extremo deltúnel de la VPN (10.3.3.1).

30 DPTOIA-IT-2006/004

Fernández et al

Figura 25: Eliminación de la compresión del cliente y del servidor

Figura 26: Resultado de la transferencia a través de la VPN sin compresión

En la Administración de Equipos podemos comprobar que la conexión se ha rea-lizado correctamente a través del túnel de la VPN. Para ello veremos las sesiones quetenemos abiertas y las direcciones IP de los equipos conectados; también compro-baremos los archivos abiertos que han viajado a través de la VPN, como observamosen la �gura 28.

La con�guración utilizada tanto en el servidor como en el cliente, es muy similara la empleada en el apartado anterior.

Se pueden consultar los Anexos D y F para con�gurar el servidor y el cliente, asícomo para generar los certi�cados y las claves.

DPTOIA-IT-2006/004 31


Figura 27: Con�guración de la aplicación

8. Exploit

Una búsqueda de los exploit2 conocidos hasta la fecha, que ha padecido Open-VPN, lo podemos localizar en la referencia [2] que nos da una relación de los últimosexploit de esta VPN, siendo:

.

CVE-2006-2229

• Summary: OpenVPN 2.0.7 and earlier, when con�gured to use the �management option with an IP that is not 127.0.0.1, uses a cleartextpassword for TCP sessions to the management interface, which mightallow remote attackers to view sensitive information or cause a denial ofservice.

• Published: 5/5/2006

• CVSS Severity: 3.7 (Low)

2Exploit (del inglés to exploit, explotar, aprovechar) es el nombre con el que se identi�ca unprograma informático malicioso, o parte del programa, que trata de forzar alguna de�ciencia o vul-nerabilidad de otro programa. El �n puede ser la destrucción o inhabilitación del sistema atacado,aunque normalmente se trata de violar las medidas de seguridad para poder acceder al mismo deforma no autorizada y emplearlo en bene�cio propio o como origen de otros ataques a terceros [18]

32 DPTOIA-IT-2006/004

Fernández et al

Figura 28: Comprobación de las conexiones en el servidor

CVE-2006-1629

• Summary: OpenVPN 2.0 through 2.0.5 allows remote malicious serversto execute arbitrary code on the client by using setenv with the LD_PRE-LOAD environment variable.


• CVSS Severity: 6.0 (Medium)

CVE-2005-3409

• Summary: OpenVPN 2.x before 2.0.4, when running in TCP mode,allows remote attackers to cause a denial of service (segmentation fault)by forcing the accept function call to return an error status, which leadsto a null dereference in an exception handler.

DPTOIA-IT-2006/004 33



• CVSS Severity: 3.3 (Low) Approximated

CVE-2005-3393

• Summary: Format string vulnerability in the foreign_option function inoptions.c for OpenVPN 2.0.x allows remote clients to execute arbitrarycode via format string speci�ers in a push of the dhcp-option commandoption.


• CVSS Severity: 8.0 (High) Approximated

CVE-2005-2534

• Summary: Race condition in OpenVPN before 2.0.1, when �duplicate-cn is not enabled, allows remote attackers to cause a denial of service(server crash) via simultaneous TCP connections from multiple clientsthat use the same client certi�cate.



CVE-2005-2533

• Summary: OpenVPN before 2.0.1, when running in "dev tap"Ethernetbridging mode, allows remote authenticated clients to cause a denial ofservice (memory exhaustion) via a �ood of packets with a large numberof spoofed MAC addresses.



CVE-2005-2532

• Summary: OpenVPN before 2.0.1 does not properly �ush the OpenSSLerror queue when a packet can not be decrypted by the server, whichallows remote authenticated attackers to cause a denial of service (clientdisconnection) via a large number of packets that can not be decrypted.



CVE-2005-2531

• Summary: OpenVPN before 2.0.1, when running with "verb 0.and with-out TLS authentication, does not properly �ush the OpenSSL error queuewhen a client fails certi�cate authentication to the server and causes theerror to be processed by the wrong client, which allows remote attackersto cause a denial of service (client disconnection) via a large number offailed authentication attempts.

34 DPTOIA-IT-2006/004

Fernández et al



Veremos en más detalle el último exploit conocido:

CVE-2006-2229

OpenVPN 2.0.7 y versiones anteriores, cuando está con�gurado para utilizar laopción �management con una IP que no sea 127.0.0.1, utilizando una contraseña enblanco para las sesiones de TCP contra la interfaz de mantenimiento, puede permitirque los atacantes remotos vean información sensible o causen una denegación deservicios.

En de�nitiva se puede abrir una puerta para entrar al sistema como administra-dor y sin necesidad de poner una password. Vamos a simular esta situación entredos máquinas virtuales. Empezaremos estudiando el comando management :

8.1. Interfaz de administración de OpenVPN

La interfaz OpenVPN Management [18] permite que OpenVPN sea administra-tivamente controlado por un programa externo vía conexión TCP.

El interfaz se ha diseñado especí�camente para desarrolladores de GUI quequisieran controlar mediante un programa o remotamente un demonio OpenVPN.

Esta interfaz de administración se implementa usando una conexión TCP clien-te/servidor, donde OpenVPN escuchará una dirección IP y un puerto procedentesde conexiones de clientes administradores.

El protocolo de administración es actualmente texto en claro sin una capa ex-plícita de la seguridad. Por esta razón, se recomienda que el interfaz de adminis-tración escuche en el localhost (127.0.0.1) o en la dirección local de la VPN. Es posi-ble conectar remotamente con el interfaz de administración sobre la propia VPN,aunque algunas capacidades serán limitadas en este modo, tal como la capacidad deproporcionar contraseñas y claves privadas.

Futuras versiones de la interface de administración.

Las versiones futuras de la interfaz de administración podrán permitir conexionesout-of-band (es decir no sobre la VPN) y aseguradas con SSL/TLS.

El interfaz de administración permite en el archivo de con�guración de la Open-VPN las siguientes directivas:

--management--management-query-passwords--management-log-cache

Ver la página del manual para documentarse sobre estas directivas.

DPTOIA-IT-2006/004 35


Una vez que OpenVPN se esté ejecutando con la capa de administración ha-bilitada, se puede realizar telnet al puerto de administración (cerciorarse de poderutilizar un cliente de telnet que entienda el modo �raw�).

Una vez conectado con el puerto de administración, puedes utilizar el comando�help� para listar todos los comandos.

8.2. Comando: �management IP port [pw-�le]

Habilitar un servidor TCP en IP:port para utilizar funciones del demonio de ad-ministración. pw-�le, si está especi�cado, es un archivo de la contraseña (contraseñaen la primera línea) o �stdin� al prompt desde la entrada estándar. La contraseñaproporcionada �jará la contraseña que los clientes del TCP necesitarán proporcionarpara tener acceso a las funciones de administración.

La interfaz de administración proporciona un modo especial donde el enlace TCPde administración puede funcionar sobre el mismo túnel. Para permitir este modo,�jar IP = "túnel". El modo túnel hará que la interfaz de administración espere aescuchar una conexión TCP en la dirección local de la interfaz TUN/TAP de laVPN.

Mientras que el puerto de administración se ha diseñado para el control pro-gramático de OpenVPN por otras aplicaciones, es posible hacer telnet al puerto,usando un cliente del telnet en modo �raw�. Una vez que esté conectado, teclear�help� para una lista de comandos.

Se recomienda encarecidamente que la IP esté �jada a 127.0.0.1 (localhost) pararestringir la accesibilidad del servidor de administración a los clientes locales.

8.3. Implementación del exploit

Vamos a reproducir en qué circunstancias podemos encontrarnos con este exploit.Para ello modi�caremos el script de arranque de la máquina Linux para permitir laconexión a la interfaz administrativa sin contraseña, quedando el script como:

#!/bin/bash

# directorio de openvpn para los ficheros de configuración

dir=/etc/openvpn-2.0.7/config

filelog=/etc/openvpn-2.0.7/config/server-openvpn.log

# cargar el modulo del kernerl TUN/TAP

modprobe tun

# habilitar IP forwardig

# echo 1 > /proc/sys/net/ipv4/ipforward

# invocar openvpn

/etc/openvpn-2.0.7/openvpn --cd $dir --log $filelog

--daemon --config server.conf --management 10.1.171.120 7505

Donde se ha añadido el comando: �management 10.1.171.120 7505

36 DPTOIA-IT-2006/004

Fernández et al

Seguidamente, una vez levantada la VPN en Linux hacemos desde otra máquinaun telnet con la siguiente orden:

telnet 10.1.171.120 7505

Y seguidamente ejecutamos el comando �help� cuyo resultado se presenta en la�gura 29.

Figura 29: Sesión Telnet interfaz administrador sin clave

Añadimos al script el nombre de un �chero, cuya primera línea contiene la clave(OpenVPN ) a utilizar, quedando el script:

#!/bin/bash





modprobe tun



# invocar openvpn

/etc/openvpn-2.0.7/openvpn --cd $dir --log $filelog

--daemon --config server.conf --management 10.1.171.120 7505 paswwd.txt

Al ejecutar el Telnet, nos pide la password, como se puede ver en la �gura 30.

8.4. Conclusiones sobre el exploit

Una vez implementada la simulación mediante dos máquinas virtuales, llegamosa la siguiente conclusión sobre el exploit:

1. Se han simulado o veri�cado los siguientes puntos:

DPTOIA-IT-2006/004 37


Figura 30: Sesión Telnet interfaz administrador con clave

La administración remota no se permite por defecto, hay que habilitarloexplícitamente.

Se permite la habilitación de la administración de forma remota y sincontraseña.

Se permite la habilitación de la administración de forma remota con con-traseña, pero esta contraseña se envía como texto en claro, con lo cual,la seguridad se ve comprometida.

El intento de realizar la administración remota, a través de la VPN, noha sido posible realizarla, dado que cuando asignamos la IP de adminis-tración al extremo del túnel, obtenemos un error, de que dicha IP no esválida (el túnel no se encuentra levantado cuando realiza la veri�cación).Esto implica que no se puede realizar la administración remota a travésde la VPN.

2. A nuestro entender no se puede considerar un exploit, como tal, aunque haydiversidad de opiniones sobre este punto. Para nosotros es su�ciente con nohabilitar la administración remota, habida cuenta que esta perfectamente do-cumentado y advertido en los manuales de la VPN. Pero un usuario pocoavanzado o que no lea todos los puntos sobre la documentación de uso dela VPN, puede pasar por alto este problema y dejar abierta una puerta alsistema. Sobre este punto la opinión mas conservadora es que �la seguridaddebe de ser por defecto�.

9. Conclusiones

La red privada virtual OpenVPN es una alternativa seria a las tradicionales ycomerciales VPNs [8].

38 DPTOIA-IT-2006/004

Fernández et al

La facilidad de instalación y mantenimiento, su alto grado de seguridad, la posi-bilidad de instalación en la mayoría de las plataformas, ser código abierto (evitandopuertas traseras), etc. la hacen idónea para ser instalada tanto en grandes corpo-raciones como en las instalaciones de pequeños usuarios para proteger sus redesinalámbricas.

El principal problema que tiene en la actualidad todas las VPNs es su desco-nocimiento por el público en general y la poca documentación que sobre el temaexiste.

Sería interesante para futuros trabajos ahondar en el estudio de los diversosparámetros de con�guración de OpenVPN, así como el estudio del código de lamisma, intentando encontrar exploit y bugs que pudieran hacer esta magní�ca VPNmas segura.

DPTOIA-IT-2006/004 39

Fernández et al

A. Instalación de OpenVPN en Windows

DPTOIA-IT-2006/004 41

Fernández et al

Para realizar la instalación de OpenVPN en Windows, comenzaremos por descar-gar el programa que encontraremos en la página del mismo cuya referencia tenemosen [20], descargando un programa autoinstalable.

El proceso de instalación es tan sencillo como seguir las instrucciones y selec-cionar las opciones que nos presente el asistente de instalación.

Seguidamente procederemos a instalarlo apareciendo la ventana de bienvenida:

Figura 31: Ventana de bienvenida

Pulsamos en siguiente y se nos presenta la ventana con la licencia (podemos

observar que es Open Source) que tendremos que aceptar pulsando en I Agree:

Figura 32: Licencia del producto

DPTOIA-IT-2006/004 43


Seguidamente nos pide los componentes del producto a instalar, por defectoseleccionaremos todos, tal y como podemos ver en 33.

Figura 33: Componentes a instalar

El asistente nos indicará en qué directorio queremos colocar el software y elespacio requerido, así como el espacio disponible:

Figura 34: Ubicación de la instalación

44 DPTOIA-IT-2006/004

Fernández et al

Comienza la instalación.

Figura 35: Proceso de instalación

Este proceso se para en el punto TAP-Win32 INSTALL donde Windows nosadvierte que se va a proceder a instalar un componente potencialmente peligroso,en realidad estamos instalando una tarjeta de red virtual. Pulsamos Continuar.

Figura 36: Aviso de Windows

DPTOIA-IT-2006/004 45


El proceso de instalación ha �nalizado, al completar las dos siguientes ventanas,tal y como podemos observar:

Figura 37: Finalización de la instalación

Para comprobar que la VPN se ha instalado como un servicio, realizaremos lasiguiente secuencia de pulsaciones: Inicio->Panel de Control ->Herramientas Ad-

ministrativas->Servicios, y podremos comprobar que se ha instalado el servicio de

OpenVPN, aunque se encuentra parado, como podemos observar en la �gura 38.

Figura 38: Servicio OpenVPN instalado e icono red

También podremos observar que tenemos un icono de una conexión de red queno está activada, dado que el túnel no se encuentra levantado.

46 DPTOIA-IT-2006/004

Fernández et al

B. Instalación de OpenVPN en Linux

DPTOIA-IT-2006/004 47

Fernández et al

De todas las posibles instalaciones de Linux, nos centraremos en la que vamos arealizar para una Red Hat 9, aunque la instalación en otras distribuciones es muysimilar.

Empezaremos descargando el paquete de OpenVPN de su página [18], siendola versión disponible en este momento la 2.0.7 y que corresponde con el archivo:openvpn-2.0.7.tar.gz, esta versión es NO-RPM, se ha seleccionado por ser un pocomás compleja de instalar que las distribuciones bajo RPM.

Los pasos a seguir son:

Posicionarnos en el directorio donde queremos hacer la instalación (/usr) con elpaquete a instalar y ejecutar:

tar xfz openvpn-2.0.7.tar.gz

Esto crea el directorio openvpn-2.0.7 con toda su estructura interna, �gura 39 :

Figura 39: Descompresión del paquete y creación de la estructura de directorios

Entramos dentro del directorio creado openvpn-2.0.7 con el comando:

cd openvpn-2.0.7

Seguidamente dentro del directorio ejecutamos:

./con�gure

Esto comprueba las dependencias del paquete OpenVPN con otros paquetes quedeberá tener el sistema operativo. En caso de faltar algún elemento, descargarlo einstalarlo. En la �gura 40 podemos ver el resultado de este comando.

Si no da errores o estos están subsanados, seguidamente teclearemos los coman-dos:

make make install

Estos comandos realizaran la compilación y ubicación de los programas de laOpenVPN, el resultado de la aplicación de los comandos se puede ver en la �gura41.

Si no ha habido errores la instalación está completada. Consultar los anexoscorrespondientes para con�gurar la OpenVPN.

DPTOIA-IT-2006/004 49


Figura 40: Resultado del con�gure

Figura 41: Resultado de make y make install

50 DPTOIA-IT-2006/004

Fernández et al

C. Con�guración modo puente (bridge [dev-tap])

DPTOIA-IT-2006/004 51

Fernández et al

En la con�guración en Modo Puente (bridge) utilizaremos como partida el�chero de plantilla que el proceso de instalación deja en la carpeta:

C:\Archivos de programa\OpenVPN\sample-config\ en el caso de Windows

Y que se llama:

sample.ovpn

Pondremos este archivo de forma comentada.

C.1. sample.ovpn

# Editar este archivo, y salvar con la extensión .ovpn# para que OpenVPN lo active cuando funcione como un servicio.

# Cambiar 'myremote' a su host remoto,# o comentarlo para poner el servidor en# modo escucha; remote myremote

# Descomentar esta línea para poner un# número de puerto diferente al de por# defecto 1194; port 1194

# Elegir una de los tres protocolos soportados por# OpenVPN. Si se comenta la línea por defecto se# usa udp; proto [tcp-server | tcp-client | udp]

# Se debe de especificar uno de los dos protocolos# posibles de red, 'dev tap' o 'dev tun' para ser usado# en ambos extremos de la conexión. 'tap crea una# VPN usando el protocolo de ethernet mientras que# 'tun' usa el protocolo IP. Use 'tap' si se quiere# realizar un puente ethernet o hacer enrutamiento# de broadcasts. 'tun' es algo mas eficiente pero# requiere la configuración del cliente software# que no depende de broadcasts. Algunas plataformas# como Solaris, OpenBSD, y Mac OS X solo soportan# interfaces 'tun', así que si desea conectar con# alguna de estas plataformas debes también usar# el interface 'tun' en el lado de Windows.

# Habilitar 'dev tap' o 'dev tun' pero no ambos!

DPTOIA-IT-2006/004 53


dev tap

# Este es un 'dev tap' ifconfig que crea# una subred ethernet virtual.# 10.3.0.1 es la dirección IP local de la VPN# y 255.255.255.0 es la subred VPN.# Solamente definir esta opción para 'dev tap'.ifconfig 10.3.0.1 255.255.255.0

# Este es un ifconfig 'dev tun' que crea# una unión IP Punto a Punto.# 10.3.0.1 es la dirección IP local de la VPN y# 10.3.0.2 es la dirección IP remota de la VPN.# Definir solamente esta opción para 'dev tun'.# Se cerciore de incluir la opción "tun-mtu"# en la máquina remota, pero intercambie las# las direcciones en la orden ifconfig.; cuba-MTU 1500; ifconfig 10.3.0.1 10.3.0.2

# Si tiene fragmentaciones o mal configurados routers# en el camino de los bloques MTU, bajo el TCP MSS e# internamente fragmentos de protocolo no-TCP.;fragment 1300;mssfix

#si has instalado más de un adaptador TAP-Win32# en tu sistema, debes referirle por su nombre.;dev-node my-tap

# Puedes generar una llave estática para# OpenVPN seleccionando la opción ``Generate Key'# en el menú de inicio.## También puede generar una key.txt manualmente# con el siguiente comando:# openvpn --genkey --secret key.txt## La llave ha de ser igual en ambos extremos de la# conexión. Así que se debe de generar en una máquina# y copiarla a la otra por un medio seguro.# Colocar key.txt en el mismo directorio donde# esta el fichero de configuración.secret key.txt

# Descomentar esta sección para una detección

54 DPTOIA-IT-2006/004

Fernández et al

# más fiable que cuando un sistema pierde la conexión.# Como por ejemplo llamadas telefónicas o portátiles# que se desplacen a otras localizaciones.## Si se habilita esta sección y ``myremote''# es un nombre dinámico DNS (por ejemplo dyndns.org),# OpenVPN ``sigue'' de forma dinámica la dirección IP# si esta cambia.; ping-restart 60; ping-timer-rem; persist-tun; persist-key; resolv-retry 86400

# ping conexión persistenteping 10

# Habilitar la compresión LZOcomp-lzo

# respuesta moderadaverb 4mute 10

Para el escenario especi�cado (ver �gura 5) hemos utilizado los siguientes �cheros:

C.2. server_red_i

remote 10.1.171.200port 1194proto udpdev tapifconfig 10.3.3.1 255.255.255.0secret key.txtping 10comp-lzoverb 4mute 10

C.3. Server_XP_Red_ii

remote 10.1.171.100port 1194proto udp

DPTOIA-IT-2006/004 55


dev tapifconfig 10.3.3.2 255.255.255.0secret key.txtping 10comp-lzoverb 4mute 10

C.4. Clave key.txt

## 2048 bit OpenVPN static key#-----BEGIN OpenVPN Static key V1-----59880e66645bc643ed548873112fa3ee4de557c4d262899d6e6e426078039b90cea0c71c7ca6a131b3e5a5b238ad7fdb439eeee749516b9c18cd0a9201eb9510c7fec1c2ffd9e25ffefa5a715edc31cc19e4a94d2f768d9f4cc7d53abc86c77c4c52f48d9485d2207c825d3d15d1cdeee577a9cb261e00dcbb92cea20dd262a6633616e1a150ff2c241b81b6b951dc2fb2268b50fd8128109e88307a1ccca2962d92e2a971e71a6930a593be06b2fd918912b4baaf39e00c2227cc25686efc2e8153e3773c84598dbb5be24ff4f9bcf6fbbcb9cc9c30903978174516d95e896b1cac378da9deefdee1433271da4bf6d32393d7338a4c01f284313f17413b01a0-----END OpenVPN Static key V1-----

C.5. Veri�cación del funcionamiento

Si todo es correcto y la VPN funciona correctamente obtendremos un �chero conlas siguientes líneas:

56 DPTOIA-IT-2006/004

Fernández et al

Figura 42: Resultado de la con�guración y puesta en marcha de la VPN

DPTOIA-IT-2006/004 57

Fernández et al

D. Con�guración modo túnel (tunnel [dev-tun])

DPTOIA-IT-2006/004 59

Fernández et al

Veamos los �cheros de ejemplo que trae OpenVPN y que son dos:

client.ovpn server.ovpn

Que permiten la con�guración en modo cliente y modo servidor.

D.1. client.ovpn

El �chero de ejemplo de con�guración de un cliente en modo túnel es:

############################################### Fichero de ejemplo de OpenVPN del lado del ## cliente para conectar con un servidor ## multi-cliente. ## ## Esta configuración se puede usar para ## múltiples clientes, no obstante cada ## cliente debe tener su propios ficheros ## de certificados y de claves. ## ## En Windows, puede ser que quiera renombrar ## este fichero tiene que tener extensión ## .ovpn ###############################################

# Específica que somos un cliente y que# nosotros usaremos ciertas directivas# de configuración del servidor.client

# Utiliza el mismo ajuste que se usa en el# servidor.# En la mayoría de los sistemas la VPN no# funcionará si no se deshabilita parcial# o totalmente el firewall para el interface# TUN/TAP;dev tapdev tun# Windows necesita el nombre del adaptador# TAP-Win32 del panel de Conexiones de Red# si se tiene mas de uno. En XP SP2, puedes# necesitar deshabilitar el firewall para# el adaptador TAP;dev-node MyTap

# Estamos conectados a un servidor TCP

DPTOIA-IT-2006/004 61


# o UDP? Usar la misma configuración# que en el servidor.;proto tcpproto udp

# NombreHost/Ip y puerto del servidor.# Puede tener múltiples entradas remotas# para tener cargas balanceadas en los servidoresremote my-server-1 1194;remote my-server-2 1194

# Elegir al azar un host de la lista# remota para cargas balanceadas. En# otro caso se usarán los host en el# orden especificado.;remote-random

# Mantener el intento indefinido de resolver# el nombre del host de el servidor OpenVPN.# Muy útil en las máquinas que no están# permanentemente conectadas a Internet# tales como ordenadores portátiles.resolv-retry infinite

# La mayoría de los clientes no# necesitan conectarse a un número# específico de puerto local.nobind

# Quita privilegios después de la inicialización# (solo en sistemas No-Windows);user nobody;group nobody

# Intenta preservar un cierto# estado a través de los reinicios.persist-keypersist-tun

# Si está conectado a través de un proxy HTTP# para alcanzar el actual servidor OpenVPN,# colocar el server/IP y número del puerto# aquí. Ver la página del manual de su# servidor proxy si se requiere autenticación.;http-proxy-retry # Reintentar si la conexión falla;http-proxy [proxy server] [proxy port #]

62 DPTOIA-IT-2006/004

Fernández et al

# Las redes Wireless producen muchos paquetes# duplicados. Activar este indicador para silenciar# el aviso de paquetes duplicados.;mute-replay-warnings

# Parámetros SSL/TLS.

# Ver el fichero de configuración del servidor# para una mayor descripción. Seria bueno usar# un par de ficheros separados \emph{.crt/.key} para# cada cliente. Un solo fichero \emph{ca} se puede usar# para todos los clientes.ca ca.crtcert client.crtkey client.key

# Verifica el certificado del servidor# comprobando que el certificado tenga# el campo nsCertType puesto a "server".# Esta es una importante precaución# importante para proteger de un ataque# potencial discutido aquí:# http://openvpn.net/howto.html#mitm## Para utilizar esta característica,# necesitaras generar tus certificados# del servidor con el campo nsCertType# fijado en "servidor". El script# build-key-server situado en el# directorio easy-rsa hará esto.;ns-cert-type server

# Si una llave tls-auth se utiliza en el servidor# entonces cada cliente debe también tener la llave.;tls-auth ta.key 1

# Selecciona un cifrado criptográfico.# Si la opción de cifrado se utiliza en el servidor# entonces debe también especificarlo aquí.;cipher x

# Habilitar compresión en el enlace VPN.# No habilitar esta opción a no ser que# esté habilitada también en el fichero# de configuración del servidor.

DPTOIA-IT-2006/004 63


comp-lzo

# Fijar el fichero de log a verbosity.verb 3

# Silenciar cada repetición del mensaje;mute 20

D.2. server.ovpn

El �chero de con�guración que trae OpenVPN de ejemplo es:

################################################## Ejemplo fichero de configuración OpenVPN 2.0 ## para un servidor multi-cliente. ## ## Este fichero es para la parte servidor de ## una configuración OpenVPN ## varios-clientes <-> un-servidor ## ## OpenVPN también soporta configuraciones ## una-máquina <-> una-máquina ## (Ver la página de Ejemplos en su Web ## para mas información). ## ## Esta configuración debe trabajar en sistemas ## Windows o Linux/BSD. Recordar en ## Windows entrecomillar el pathnames y usar ## doble barra inversa, e.g.: ## "C:\\Program Files\\OpenVPN\\config\\foo.key" ## ## Los comentarios irán precedidos por '#' o ';' ##################################################

# ¾En cual dirección IP local debe OpenVPN# escuchar? (opcional);local a.b.c.d

# ¾En qué puerto de TCP/UDP debe OpenVPN escuchar?# Si desea ejecutar múltiple instancias de OpenVPN# en la misma máquina, use diferentes número puerto# para cada uno. Necesitará abrir este puerto# en su firewall.port 1194

64 DPTOIA-IT-2006/004

Fernández et al

# ¾Servidor TCP o UDP?;proto tcpproto udp

# "dev tun" creará un túnel IP ruteador,# "dev tap" creará un túnel de red.# Use "dev tap0" si tienes un puente de red# y tienes precreado un interface virtual tap0# y el puente es su interface de red.# Si deseas controlar políticas del acceso# sobre el VPN, debes crear reglas en el firewall# para el interfaz de TUN/TAP.# En los sistemas de no-Windows, puedes dar# un número explícito de la unidad, tal como tun0.# En Windows, use "dev-node" para esto.# En la mayoría de los sistemas, el VPN no funcionará# a menos que inhabilite parcialmente o completamente# el firewall para el interfaz de TUN/TAP.;dev tapdev tun

# Windows necesita el nombre del adaptador TAP-Win32# del panel de las conexiones de red si# tienes más de uno. En XP SP2 o superiores,# puede necesitar deshabilitar selectivamente el firewall de# Windows para el adaptador TAP. Los sistemas# No-Windows no necesitan generalmente esto.;dev-node MyTap

# SSL/TLS certificado raíz (ca), certificado# (cert), y clave privada (key). Cada cliente# y el servidor deben tener su propio certificado y fichero clave.# El servidor y todos los clientes usarán el mismo archivo de \emph{ca}.## Ver el directorio "easy-rsa" para una serie# de scripts para la generación de los certificados# RSA y las claves privadas. Recordar usar un único# nombre común para el servidor y cada uno de los certificados# del cliente.## Cualquier sistema administración X509 puede ser utilizado.# OpenVPN puede también utilizar un archivo clave ajustado al formato PKCS #12# (véase la directiva "pkcs12" en la página del manual).ca ca.crtcert server.crtkey server.key # Este archivo se debe mantener secreto

DPTOIA-IT-2006/004 65


# Parámetros Diffie Hellman.# Generar uno propio con:# openssl dhparam -out dh1024.pem 1024# Sustituya 1024 por 2048 si quiere usar# claves de 2048 bit.dh dh1024.pem

# Configura el modo servidor y suministra una subred# de VPN para OpenVPN a las direcciones del cliente.# El servidor tomará 10.8.0.1 para sí mismo,# el resto será puesto a disposición los clientes.# Cada cliente podrá alcanzar el servidor# en 10.8.0.1. Comenta esta línea si se quiere tender# un puente de red. Ver la página del manual para más Información.server 10.8.0.0 255.255.255.0

# Mantiene un registro asociaciones de# clientes <-> direcciones IP virtuales# en este fichero. Si OpenVPN se detiene# o reinicia, al reconectar los clientes# se vuelve a asignar la misma dirección# IP virtual desde la combinación# previamente asignada.ifconfig-pool-persist ipp.txt

# Configura el modo servidor para tender un puente red.# Debe primero utilizar la capacidad que tiene un puente sobre# su OS para tender un puente sobre el interfaz TAP# con el interfaz del NIC de red.# Entonces debes fijar manualmente IP/netmask# en el interfaz del puente, aquí se# asume 10.8.0.4/255.255.255.0. Finalmente nosotros# debe asignar un rango de IP a un lado en esta subred# (comienzo=10.8.0.50 final=10.8.0.100) para asignar# a los clientes que conectan. Dejar esta línea comentada# a menos que desee tender un puente de red.;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100

# Impulsar rutas en el cliente para permitirle# alcanzar otras subredes privadas detrás del servidor.# Recordar que las subredes privadas también necesitan# conocer como encaminar los paquetes del cliente# OpenVPN (10.8.0.0/255.255.255.0) de nuevo al servidor# OpenVPN;push "route 192.168.10.0 255.255.255.0"

66 DPTOIA-IT-2006/004

Fernández et al

;push "route 192.168.20.0 255.255.255.0"

# Para asignar una dirección IP específica# a un específico cliente o si un cliente# que conecta tiene una subred privada# detrás de él que deba también tener# acceso a la VPN, usar el subdirectorio 'CCD'# para ficheros de configuración cliente-específico# (véase la página del manual para más información).

# EJEMPLO: Suponer el cliente# que tiene el certificado con el nombre común# "Thelonious", también tiene una subred pequeña# detrás de su máquina que conecta como# 192.168.40.128/255.255.266.248# Primero, descomentar estas líneas:;client-config-dir ccd;route 192.168.40.128 255.255.255.248# Crear el fichero ccd/Thelonious con la línea:# iroute 192.168.40.128 255.255.255.248# Esto permitirá a la subred privada Thelonious# el acceso a la VPN. Este ejemplo trabaja solamente# si estás encaminando, no tendiendo un puente,# es decir estas usando directivas "dev tun" y "server".

# EJEMPLO: Suponer que desea dar a Thelonious# una dirección IP fija de VPN 10.9.0.1.# primero decomentar las líneas:;client-config-dir ccd;route 10.9.0.0 255.255.255.252# entonces agrega esta línea al ccd/Thelonious:# ifconfig-push 10.9.0.1 10.9.0.2

# Supone que desea permitir diferentes políticas de# acceso al firewall para diversos grupos de clientes.# Hay dos métodos:# (1) Ejecución de múltiples demonios OpenVPN, uno para# cada grupo, y firewall interfaz TUN/TAP para cada# grupo/demonio apropiadamente.# (2) (Avanzado) Crear un script modificado dinámicamente# para que el firewall responda al acceso de diversos# clientes. Ver las páginas del manual para más# información en aprender-trata los scripts.;learn-address ./script

# Si está habilitado, esta directiva configurará

DPTOIA-IT-2006/004 67


# todos los clientes para volver a redirigir su# puerta de enlace por defecto a través de la VPN,# causando que todo el tráfico IP tal como los navegadores y# y operaciones de búsqueda del DNS a pasar a través del VPN# (la máquina del servidor de OpenVPN puede necesitar# NAT al interfaz de TUN/TAP al objeto de que Internet# trabaje correctamente).# ADVERTENCIA: Puede romperse la configuración de la# red de clientes si el servidor DHCP local sirve paquetes# que consiguen encaminarse a través del túnel.# Solución: cerciórese de que el servidor local de DHCP# del cliente sea accesible vía a una ruta más específica# que el enrutado por defecto 0.0.0.0/0.0.0.0.;push "redirect-gateway"

# Ciertos ajustes específicos de Windows# de la red se pueden colocar en los clientes,# tales como DNS o WINS servidor de direcciones.# ADVERTENCIA:# http://openvpn.net/faq.html#dhcpcaveats;push "dhcp-option DNS 10.8.0.1";push "dhcp-option WINS 10.8.0.1"

# Descomentar esta directiva para permitir que diversos clientes# puedan "ver" cada uno a otros.# Por defecto, los clientes verán solamente el servidor.# Para forzar a los clientes a ver solamente al servidor,# también necesitarás configurar el servidor firewall# con el interfaz TUN/TAP.;client-to-client

# Descomentar esta directiva si múltiples# conectan con el mismo fichero de certificado/clave# o nombre común. Esto solo se recomienda con propósito# de testeo. En producción use, cada cliente debe tener# su propio par de certificado/clave.## SI NO HAS GENERADO UNA PAREJA CERTIFICADO/CLAVE# INDIVIDUAL PARA CADA CLIENTE,# CADA UNO TIENE QUE TENER SU PROPIO "NOMBRE COMÚN ÚNICO",# DESCOMENTAR ESTA LÍNEA.;duplicate-cn

# La directiva keepalive envía mensajes ping-vivo hacia# adelante y hacia atrás de modo que en el enlace cada# lado sepa cuando el otra se ha desconectado.

68 DPTOIA-IT-2006/004

Fernández et al

# Ping cada 10 segundos, asume que el par remoto está# desconectado si no recibe ningún ping durante# un período de tiempo de 120 segundos.keepalive 10 120

# Para seguridad adicional más allá de lo proporcionado# por SSL/TLS, cree un "HMAC firewall"# para ayudar a bloquear ataques del DOS y desbordar# el puerto UDP.## Generar con:# openvpn --genkey --secret ta.key## El servidor y cada cliente deben tener# una copia de esta llave.# El segundo parámetro debe ser '0'# en el servidor y '1' en los clientes.;tls-auth ta.key 0 # Este fichero es secreto

# Selecciona un cifrado criptográfico.# Este opción del config se debe copiar a# el archivo de config del cliente también.;cipher BF-CBC # Blowfish (default);cipher AES-128-CBC # AES;cipher DES-EDE3-CBC # Triple-DES

# Permite la compresión en el enlace VPN.# Si lo permite aquí, debe también# permitirlo en el archivo de config de cliente.comp-lzo

# El número máximo de clientes concurrentes conectados# que deseamos permitir.;max-clients 100

# Es una buena idea el reducir los privilegios# de los demonios OpenVPN después de la inicialización## Puede descomentar esta línea si el sistemas es# distinto de Windows.;user nobody;group nobody

# La opción de persistencia quiere evitar# el acceso a ciertos recursos en el reinicio, que

DPTOIA-IT-2006/004 69


# no serán accesibles por que los privilegios# disminuyen.persist-keypersist-tun

# Hace salir el estado corto a un archivo# que muestra las conexiones actuales,# truncado y reescrito cada minuto.status openvpn-status.log

# Por defecto, los mensajes del registro irán al syslog (o# en Windows, si funcionan como servicio, van a al directorio# "\Program Files\OpenVPN\log").# Utiliza el registro o registro-añadido para eliminar este defecto.# "log" truncará el fichero en el arranque diario de OpenVPN,# mientras que "log-append" añadirá a él. Utilizar uno# o el otro (pero no ambos).

;log openvpn.log;log-append openvpn.log

# Fija el nivel apropiado de# verbosity del archivo de log.## 0 es silencioso, a excepción de errores fatales# 4 es razonable para el uso general# 5 y 6 puede ayudar a eliminar errores de problemas de la conexión# 9 es extremadamente prolijoverb 3

# Silencia los mensajes repetidos. A los 20# mensajes secuenciales de la misma categoría# de mensaje serán eliminados del registro.;mute 20

D.3. Con�guración del servidor (server.conf)

La con�guración utilizada en la máquina virtual con Linux Red Hat, en formatoreducido, es la siguiente:

port 1194proto tcpdev tunca /etc/openvpn-2.0.7/easy-rsa/keys/ca.crtcert /etc/openvpn-2.0.7/easy-rsa/keys/server.crt

70 DPTOIA-IT-2006/004

Fernández et al

key /etc/openvpn-2.0.7/easy-rsa/keys/server.keydh /etc/openvpn-2.0.7/easy-rsa/keys/dh1024.pemserver 10.3.3.0 255.255.255.0ifconfig-pool-persist ipp.txtkeepalive 10 120comp-lzopersist-keypersist-tunstatus openvpn-status.logverb 3

D.4. Con�guración de los clientes (ClientLinux.ovpn)

Los tres clientes se con�guran igual, con la excepción del certi�cado y la claveque son únicos para cada uno de ellos. El �chero de con�guración es:

clientdev tunproto tcpremote 10.1.171.120 1194resolv-retry infinitenobindpersist-keypersist-tunca "C:\\Archivos de programa\\OpenVPN\\easy-rsa\\Keys\\ca.crt"cert "C:\\Archivos de programa\\OpenVPN\\easy-rsa\\Keys\\lin-cli-1.crt"key "C:\\Archivos de programa\\OpenVPN\\easy-rsa\\Keys\\lin-cli-1.key"comp-lzoverb 3

DPTOIA-IT-2006/004 71

Fernández et al

E. Con�guración de los �rewalls

DPTOIA-IT-2006/004 73

Fernández et al

La con�guración de los �rewalls para veri�car la conexión en puente (bridge),la vamos a realizar de tal forma que solo se permita el paso de la VPN, el resto detrá�co será rechazado.

Pulsar: Inicio->Panel de Control ->Firewall de Windows. Obtendremos la pan-talla de la �gura 43.

Figura 43: Activación del Firewall

Si el �rewall está desactivado lo activaremos seleccionando la opción: Activado.

Figura 44: Con�guración del Firewall

Como se puede apreciar en la �gura 44, seleccionamos la pestaña Excepciones

y deshabilitamos todos los programas y servicios a excepción de OpenVPN y enla pestaña Opciones avanzadas seleccionamos OpenVpn y pulsamos con�guración,seguidamente desactivamos cualquier opción que estuviera activada.

DPTOIA-IT-2006/004 75

Fernández et al

F. Generación de las claves y de los certi�cados

DPTOIA-IT-2006/004 77

Fernández et al

F.1. Generación de claves estáticas

F.1.1. En Windows

En Windows podemos utilizar una utilidad que trae para generar de forma au-tomática la clave, para ello accedemos al programa siguiendo la secuencia de pulsa-ciones indicadas:

inicio->Todos los programas->OpenVPN ->Generate a static OpenVPN key taly como se indica:

Figura 45: Acceso al programa de generación de claves estáticas en Windows

Una vez seleccionada la opción obtendremos una ventana indicándonos que seha generado la clave y la ubicación de la misma que podemos observar en la �gura46.

F.1.2. Línea de Comandos

Si por el contrario queremos generar la clave desde la línea de comandos, tecleare-mos la siguiente instrucción, dentro del directorio

C:\Archivos de programa\OpenVPN\config

(también es válido para la generación de la clave en Linux):

DPTOIA-IT-2006/004 79


Figura 46: Resultado de la Generación

OpenVPN �genkey �secret key.txt

Obteniendo la imagen siguiente:

Figura 47: Generación de la clave desde la línea de comandos

F.2. Generación de los Certi�cados

Esta operación la realizaremos sobre la plataforma de Linux. El proceso en Win-dows es similar.

80 DPTOIA-IT-2006/004

Fernández et al

F.2.1. Generación del certi�cado maestro y clave de la Autoridad Cer-ti�cadora (CA)

Nos situamos en el directorio:

/usr/openvpn-2.0.7/easy-rsa

Y una vez situados dentro de este directorio, ejecutaremos los siguientes coman-dos:

. ./vars

./clean-all

./build-ca

El último comando genera una pantalla interactiva que nos pide unos datos, taly como se muestra:

Figura 48: Generación certi�cado Autoridad Certi�cadora (CA)

Esto genera unos �cheros con nombres ca.key y ca.crt que moveremos a undirectorio creado previamente keys y cuyo contenido lo podemos ver en la �gura 49.

F.2.2. Generación del certi�cado y clave del Servidor

Ejecutar el siguiente comando:

./build-key-server server

Esto genera los �cheros server.crt, server.csr y server.key que también movere-mos a la ubicación indicada con anterioridad. El contenido del certi�cado se exponeen la �gura 51.

DPTOIA-IT-2006/004 81


Figura 49: Contenido del certi�cado CA

Figura 50: Generación certi�cado y clave servidor

F.2.3. Generación del certi�cado y clave para tres clientes

Ejecutar el siguiente comando:

./build-key cliente1



El resultado del script es muy similar al obtenido para el servidor. Se crean dos�cheros cliente1.crt, cliente1.key, cliente2.crt, cliente2.key, cliente3.crt y cliente3.keyque pasaremos al directorio pertinente.

82 DPTOIA-IT-2006/004

Fernández et al

Nombre �chero Necesario en Propósito Secretoca.crt Servidor + todos los clientes Certi�cado raíz CA NOca.key Máquina que �rma el certi�cado Clave raíz CA SI

dh{n}.pem Solo en el servidor Parámetros Di�e Hellman NOserver.crt Solo en el servidor Certi�cado del servidor NOserver.key Solo en el servidor Clave del servidor SIcliente1.crt Solo en el cliente 1 Certi�cado del cliente 1 NOcliente1.key Solo en el cliente 1 Clave del cliente 1 SIcliente2.crt Solo en el cliente 2 Certi�cado del cliente 2 NOcliente2.key Solo en el cliente 2 Clave del cliente 2 SIcliente3.crt Solo en el cliente 3 Certi�cado del cliente 3 NOcliente3.key Solo en el cliente 3 Clave del cliente 3 SI

Tabla 2: Ficheros de claves y certi�cados [13]

F.2.4. Generar parámetros de Di�e Hellman

Ejecutar el comando:

./build-dh

La pantalla de generación es la de la �gura 52.

Esto crea el �chero dh1024.pem, que será movido como los anteriores al directoriocreado a tal efecto.

Con esto se han generado todos los �cheros necesarios para trabajar con los cer-ti�cados digitales. Seguidamente daremos una tabla con los �cheros, sus ubicacionesy si han de ser secretos o no (Tabla 2).

Tanto en el servidor como en los clientes se creará un directorio con nombre keys,donde su ubicarán todos los �cheros que correspondan según la tabla 2.

DPTOIA-IT-2006/004 83


Figura 51: Contenido del certi�cado del servidor

84 DPTOIA-IT-2006/004

Fernández et al

Figura 52: Generación del �chero de Di�e Hellman

DPTOIA-IT-2006/004 85

Fernández et al

G. Script de arranque y parada en Linux

DPTOIA-IT-2006/004 87

Fernández et al

G.1. Script de Arranque

#!/bin/bash





modprobe tun



# invocar openvpn

/etc/openvpn-2.0.7/openvpn --cd $dir --log $filelog --daemon --config server.conf

G.2. Script de Parada

#!/bin/bash

# Parar todos los procesos openvpn

killall -TERM openvpn

DPTOIA-IT-2006/004 89

Fernández et al

H. Con�guración del router

DPTOIA-IT-2006/004 91

Fernández et al

Para poder trabajar correctamente con OpenVPN en una red donde tenemos unrouter que �ltra los paquetes que nos llegan del exterior, es preciso con�gurar elmismo. Esta con�guración se compone de 3 partes:

Enrutamiento de los paquetes de OpenVPN.

Apertura del puerto de OpenVPN.

NAT3 al equipo servidor.

.

El router que vamos a con�gurar es un Prestige 643 de ZyXEL, aunque cualquierotro se con�gurará de forma similar.

H.1. Enrutamiento de los paquetes de OpenVPN

En este paso vamos a indicarle al router lo que tiene que hacer con los paquetesque le llegan del extremo del túnel y tiene que volver por él. Como la dirección IPdel extremo del túnel no es una dirección de la red física, el router no sabe dondeenviarlo y por defecto lo pasará al exterior que es donde envía los paquetes que noson de su red. Le tenemos que decir que todo aquello que vaya al extremo del túnelde la VPN, vaya al dispositivo de red del servidor. En nuestro caso enviaremos todolo que sea de la red 10.3.3.0 al servidor cuya dirección es 10.1.171.105 y que es dondeestá el extremo del túnel de la VPN.

Una vez conectados al router, seguimos la siguiente secuencia de comandos:12(Static Routing Setup)->1(IP Static Route)->1(OpenVPN), tal y como se mues-tra en la �gura 53.

Las opciones a aplicar son:

Route #: 1 (no de la ruta)Route Name= OpenVPN (Nombre de la ruta)Active= Yes (Si esta la ruta activa o no)Destination IP Address= 10.3.3.0 (Dirección IP destino)IP Subnet Mask= 255.255.255.0 (Mascara de subred)Gateway IP Address=10.1.171.105 (punto de destino de los paquetes)Metric= 1Private= Yes

3NAT (Network Address Translation - Traducción de Dirección de Red) Se utilizauna o más direcciones IP para conectar varios ordenadores a otra red (normalmente a Internet), loscuales tiene una dirección IP completamente distinta. En este caso utilizaremos NAT estático querealiza un mapeo en la que una dirección IP privada se traduce a una correspondiente direcciónIP pública de forma unívoca. Normalmente se utiliza cuando un dispositivo necesita ser accesibledesde fuera de la red privada [18].

DPTOIA-IT-2006/004 93


Figura 53: Con�guración del router I

H.2. Apertura del puerto y NAT al servidor

En este router, estas dos operaciones se realizan de forma simultánea, al mismotiempo que se abre el puerto, se indica a que dirección IP interna se envían lospaquetes. Para realizar la con�guración, desde la pantalla principal seleccionamos laopción 15 (SUA Server Setup) y especi�camos el puerto a abrir (1194) y la direccióndonde se enviarán los paquetes (10.1.171.105).

En este tipo de router al abrir el puerto, se abre para todas las tramas (TCP,UDP, etc) con lo que no hace falta especi�car nada más. Observar que también seha abierto el puerto 21 (ftp) y los puertos 5800 y 5900 para poder administrar deforma remota el servidor mediante la aplicación VNC. En la �gura 54 tenemos estaopción del router con�gurada.

94 DPTOIA-IT-2006/004

Fernández et al

Figura 54: Con�guración del router II

DPTOIA-IT-2006/004 95

Fernández et al

Referencias

[1] Isaac Clerencia. �redes privadas virtuales�. InWarp Networks S.L., 2005. [citado19 septiembre 2006]. [Citado en págs. 2 y 5.]

[2] Computer Security Division. �national vulnerability database�.http://nvd.nist.gov/, 2006. [citado 19 septiembre 2006]. [Citado en pág. 32.]

[3] Nick G. Du�eld, Pawan Goyal, Albert G. Greenberg, Partho Pratim Mishra,K. K. Ramakrishnan, and Jacobus E. van der Merive. �a �exible model forresource management in virtual private networks�. In SIGCOMM, pages 95�108, 1999. [citado 19 septiembre 2006]. [Citado en pág. 26.]

[4] Markus Feilner. �OpenVPN - Building and Integrating Virtual Private Net-

work�. Packt Publishing Ltd., 2006. ISBN 1-904811-85-X [citado 19 septiembre2006]. [Citado en págs. 4, 12 y 14.]

[5] Paul Ferguson and Geo� Huston. �what is a vpn: Part i�. In Protocol Journal,pages vol. 1, no. 1, June 1998. [citado 19 septiembre 2006]. [Citado en pág. 2.]

[6] Paul Ferguson and Geo� Huston. �what is a vpn: Part ii�. In Protocol Journal,pages vol. 1, no. 2, September 1998. [citado 19 septiembre 2006].

[Citado en pág. 2.]

[7] Damián Ferrer. �vpn: Una introducción a las redes privadas virtuales�. In VPN:

Una introducción a las Redes Privadas Virtuales, 2005. [citado 19 septiembre2006]. [Citado en pág. 4.]

[8] Charlie Hosner. �openvpn and the ssl vpn revolution�.http://www.sans.org/reading_room/whitepapers/vpns/1459.php. [citado19 septiembre 2006]. [Citado en pág. 38.]

[9] Charlie Hosner. �ssl vpns and openvpn: A lot of liesand a shred of truth�. Technical report, newsforge,http://software.newsforge.com/print.pl?sid=05/09/22/164231, 2005. [citado19 septiembre 2006]. [Citado en pág. 15.]

[10] Ray Hunt and Chris Rodgers. �virtual private networks: Strong security at whatcost¾`. http://citeseer.ist.psu.edu/hunt01virtual.html. [citado 19 septiembre2006]. [Citado en págs. 2, 4 y 5.]

[11] Telindus High-Tech Institute. �openvpn 101: introduction to openvpn�.http://openvpn.net/papers/openvpn-101.pdf, 2004. [citado 19 septiembre2006]. [Citado en pág. 25.]

[12] S. Kent and R. Atkinson. �security architecture for the internet protocol�,November 1998. RFC 2401 [citado 19 septiembre 2006]. [Citado en pág. 9.]

[13] Linksys. �VPN usando routers Linksys por banda ancha con IP dinámica�.[citado 19 septiembre 2006]. [Citado en págs. 6 y 83.]

DPTOIA-IT-2006/004 97


[14] Marco Hernáiz Mayo. �ipv6 e ipsec - seguridad en redes telemáticas�.http://asignaturas.diatel.upm.es/seguridad/trabajos/trabajos/ipv6c.pdf. [cita-do 19 septiembre 2006]. [Citado en pág. 9.]

[15] Coral Martínez Millas. �vpn redes vir-tuales privadas - seguridad en redes telemáticas�.http://asignaturas.diatel.upm.es/seguridad/trabajos/trabajos/vpn.pdf. [cita-do 19 septiembre 2006]. [Citado en págs. 2 y 9.]

[16] Virtual Private Networks. �network working group a. nagarajan, ed. request forcomments: 3809 juniper networks category: Informational june 2004 generic re-quirements for provider provisioned�. http://citeseer.ist.psu.edu/660271.html.[citado 19 septiembre 2006]. [Citado en pág. 3.]

[17] Gustav Rosenbaum, William Lau, and Sanjay Jha. �recent directions in virtualprivate network solutions�. http://citeseer.ist.psu.edu/617359.html. [citado 19septiembre 2006]. [Citado en pág. 5.]

[18] Inc. Wikimedia Foundation. �wikipedia�.http://es.wikipedia.org/wiki/Portada. [citado 19 septiembre 2006].

[Citado en págs. 8, 9, 10, 11, 12, 32, 35, 49 y 93.]

[19] Paul Wouters and Ken Bantoft. �Building and Integrating Virtual Private Net-

works with Openswan�. Packt Publishing Ltd., 2006. ISBN 1-904811-25-6 [cita-do 19 septiembre 2006]. [Citado en pág. 8.]

[20] James Yonan. �openvpn�. http://openvpn.net/. [citado 19 septiembre 2006].[Citado en págs. 16 y 43.]

[21] James Yonan. �the user-space vpn and openvpn�.http://openvpn.net/papers/BLUG-talk/BLUG-talk.ppt, 2003. [citado 19septiembre 2006]. [Citado en pág. 14.]

98 DPTOIA-IT-2006/004

Documents

Redes Privadas Virtuales - E-LIS repositoryeprints.rclis.org/13992/1/fernandez2006redes.pdfInforme Técnico - ecThnical Report DPTOIA-IT-2006/004 septiembre, 2006 Redes Privadas Virtuales