VPN - ADSL Ayuda

Interconexión
de
Redes
VPN
(Virtual Private Networking)
Mauricio Alonso Caneiro
Mauricio Alonso Caneiro
-1-
VPN
Indice
1.Introducción.
.
.
.
.
.
.
.
04
2. Mecanismos de Protección.
.
.
.
.
.
06
3. Implementación.
.
.
.
.
.
.
07
.
.
.
.
.
.
08
.
4. Problemas de VPN.
.
5. Requisitos.
.
.
.
.
.
.
.
.
09
6. Protocolos.
.
.
.
.
.
.
.
.
11
.
.
.
.
.
.
.
13
7.2. El origen del protocolo IPSec.
.
.
.
.
13
7.3. VPNs e IPSec .
.
.
.
.
.
.
14
7.4. Servicios de IPSec.
.
.
.
.
.
.
17
7.5. Asociaciones de seguridad (SAs).
.
.
.
19
7. IPSec
7.1. Introducción.
7.6. Base de datos de asociaciones de seguridad (SAD).
24
7.7. Base de datos de política de seguridad ( SPD).
.
26
7.8.. Gestión de claves.
.
.
.
.
.
.
27
7.9. Proceso de tráfico: un ejemplo práctico.
.
.
28
8. Conclusiones.
.
.
.
.
.
.
.
30
9. Bibliografía. .
.
.
.
.
.
.
.
32
Mauricio Alonso Caneiro
-2-
VPN
Indice de figuras
3.1. Dos redes conectadas a una pública con gateway seguro
.14
3.2. Formato de paquetes IPSec en modo transporte. .
.
.18
3.3. Formato de paquetes IPSec en modo túnel. .
.
.
.18
3.4. Una conexión IPSec a dos niveles.
.
.
.
.
.18
3.5. Comunicación bidireccional con IPSec.
.
.
.
.19
3.6. Adyacencia de transporte..
.
.
.
.
.20
3.7. Encapsulamiento iterativo. Nivel 1.
.
.
.
.
.20
3.8. Encapsulamiento iterativo. Nivel 2.
.
.
.
.
.21
3.9. Encapsulamiento iterativo. Nivel 3.
.
.
.
.
.21
.
.
.22
3.11. Modos de comunicación en la combinación básica 1.
.
.22
3.12. Soporte para VPN's simples . .
.
3.10. Seguridad entre los hosts a través de Internet.
.
.
.
.22
3.13. Combinación de los dos primeros casos.
.
.
.
.23
3.14. Una VPN mediante acceso remoto . .
.
.
.
.23
Mauricio Alonso Caneiro
-3-
.
VPN
1. Introducción
¿Qué es?
Una VPN es una forma de conectar uno o más redes privadas preexistentes
por medio de una red pública (como Internet) de tal manera que las redes
parezcan una sola para los usuarios. En este sentido, las siglas hacen
referencia a que la red es Virtual porque para los usuarios parece que sea
una única red, y será Privada porque la comunicación a través de ella es
segura y está protegida.
¿Para qué se usa?
Un escenario típico de uso de VPN es una compañía que tiene una serie de
trabajadores remotos a los que quiere permitir el acceso a sus servicios. Si
esto es lo único que se desea hacer, no hace falta una VPN: basta con utilizar
tecnologías como Firewalls o proxys. Ahora bien, una VPN permite, además
que la comunicación se realice por un canal seguro. Por seguro se entiende
que la comunicación cumpla estos requisitos:
•
Confidencialidad: Los datos que circulan por el canal sólo pueden ser
leídos por emisor y receptor. La manera de conseguir esto es mediante
técnicas de encriptación.
•
Autentificación: Emisor y receptor son capaces de determinar de forma
inequívoca sus identidades, de tal manera que no exista duda sobre las
mismas. Esto puede conseguirse mediante firmas digitales o aplicando
mecanismos desafío-respuesta.
•
Integridad: Debe garantizarse la integridad de los datos, esto es, que los
datos que le llegan al receptor sean exactamente los que el emisor
transmitió por el canal. Para esto se pueden utilizar firmas digitales.
•
No repudio: Cuando un mensaje va firmado, el que lo firma no puede
negar que el mensaje lo emitió él.
Existen varias formas de garantizar la existencia de un canal seguro entre
emisor y receptor. Algunas de ellas pueden ser el uso de extranets, o bien
proteger los servidores propios mediante passwords utilizando mecanismos
de autentificación de terceras partes, o incluso utilizar líneas privadas para
todas las comunicaciones que requieran un canal seguro.
Sin embargo, utilizar tecnología VPN tiene una serie de ventajas con respecto
a otras soluciones, como pueden ser:
•
Ahorro en costes de comunicaciones. En el caso de usuarios remotos,
cuando quieren utilizar los servicios de la compañía no necesitan
conectarse directamente a los servidores de la compañía, sino que se
conectan directamente por su conexión a Internet. Por otro lado, la
compañía puede utilizar sus líneas de conexión a Internet para realizar
transmisiones de datos, sin necesidad de contratar líneas privadas
adicionales.
Mauricio Alonso Caneiro
-4-
VPN
•
Ahorro en costes operacionales. Usando VPN para dar acceso a los
usuarios, la compañía puede deshacerse de los bancos de módems y
de los servidores para acceso remoto, de manera que ya no habrá que
administrar esos dispositivos.
•
Entorno de trabajo independiente de tiempo y lugar a un coste
reducido. Mediante el uso de una VPN, los trabajadores remotos
pueden acceder a los servicios de la compañía sin necesidad de
realizar llamadas a larga distancia ni utilizando líneas privadas.
•
Los servicios de la compañía están disponibles siempre. Una VPN
permite a las compañías ofrecer servicios globales. Los trabajadores
remotos pueden conectarse a la red interna sin importar dónde estén
situados físicamente. Esto implica que pueden utilizar los servicios de
la LAN de la compañía, como impresoras o archivos compartidos, sin
problemas.
•
Una compañía puede ofrecer servicios a sus socios mediante una
VPN, ya que la tecnología VPN permite accesos controlados y
proporciona un canal seguro para compartir información de negocios.
Mauricio Alonso Caneiro
-5-
VPN
2. Mecanismos de protección
Los mecanismos para garantizar la privacidad de las comunicaciones dentro
de una VPN son dos:
- Basados en password.
- Basados en clave pública.
Los basados en password son similares a la autentificación tradicional
mediante pares ID de usuario-password. Estos mecanismos tienen la
desventaja de que no es fácil conseguir un password seguro y que a la vez
sea fácil de recordar por el usuario. Por lo tanto, los passwords se vuelven
vulnerables a ataques basados en diccionarios o en fuerza bruta.
Un refinamiento de estos sistemas son los basados en dispositivos que
generan claves de un solo uso. Estos dispositivos generan passwords
temporales automáticamente, que caducan al cabo de un cierto tiempo. Este
mecanismo es razonablemente seguro, ya que para romper la seguridad de
un sistema basado en claves únicas se deben dar dos circunstancias: poseer
el dispositivo generador y el código para activarlo.
Los sistemas basados en passwords tienen el defecto de que suelen
ocuparse solamente de la autentificación, sin prestar demasiada atención a la
privacidad.
En este sentido, los sistemas basados en clave pública ofrecen:
confidencialidad, autentificación, integridad y garantía de no repudio.
−
La confidencialidad implica que sólo el destinatario podrá leer los datos,
lo que se consigue encriptándolos de tal manera que sólo podrá leerlos
quien posea la clave para desencriptarlos.
−
La autentificación (por ejemplo mediante firmas digitales) permite
establecer exactamente la identidad de ambas partes.
−
En cuanto a la integridad, consiste en impedir que los datos puedan ser
modificados por terceras personas sin que ello pase inadvertido.
−
Finalmente, la garantía de no repudio implica que cuando un mensaje
lleva una firma digital, el dueño de la firma no puede negar que el
mensaje fue enviado por él.
En una VPN, se utilizan sistemas de clave pública para la autentificación,
mientras que la integridad y privacidad de los datos se garantiza con
protocolos como IPSec.
Por último, mencionar que en un esquema de clave privada lo más importante
es precisamente proteger la clave privada, puesto que la clave identifica a su
dueño, y si es robada, el ladrón puede actuar como si fuera el dueño real, con
consecuencias imprevisibles. Es por ello por lo que normalmente se deberían
utilizar dispositivos hardware para protegerla, tales como tarjetas inteligentes
o tokens hardware, que son difíciles de copiar y ofrecen parecidas garantías
de seguridad que los dispositivos generadores de claves que se mencionan
más arriba.
Mauricio Alonso Caneiro
-6-
VPN
3. Implementación
En una primera aproximación, se puede implementar una VPN mediante
mecanismos hardware. Éstos se basan normalmente en routers con
encriptación, que tienen la ventaja de ser lo más parecido a equipos
"plug&play". Su única tarea es encriptar y desencriptar las tramas que pasan
a través de ellos, por lo que tienen buenas prestaciones y no introducen
demasiado retardo en la red. Ahora bien, no tienen tanta flexibilidad como los
sistemas basados en software.
Otra aproximación son sistemas basados en Firewalls. Estos sistemas
aprovechan las ventajas del firewall como la restricción de acceso a la red o
generación de registros de posibles amenazas, y ofrecen además otros como
traducción de direcciones o facilidades de autentificación fuerte. Ahora bien,
el hecho de insertar el servicio de VPN dentro de un firewall puede afectar en
mayor o menor medida al rendimiento del sistema, lo que puede o no ser un
problema dependiendo de nuestras necesidades. Si esto se convierte en un
problema, algunos fabricantes de firewalls ofrecen procesadores dedicados a
encriptación para minimizar el efecto del servicio VPN en el sistema.
Por último, los sistemas puramente software son ideales en los casos en
los que los dos extremos de la comunicación no pertenecen a la misma
organización, o cuando aun estando dentro de la misma organización, las
tecnologías de routers y/o firewalls difieren. Esta solución permite mayor
flexibilidad en cuanto a la decisión de qué tráfico enviar o no por el túnel
seguro, pudiendo decidir por protocolo o por dirección, a diferencia de los
sistemas hardware, que normalmente sólo permiten decidir por dirección.
Puede ser conveniente en situaciones donde la VPN es útil en algunos casos
(consultas a una base de datos) pero irrelevante en otros (navegación normal
por la web). También es útil en los casos en los que la conexión se realiza por
líneas lentas.
Ahora bien, no todo son ventajas. Los sistemas software son difíciles de
administrar, ya que requieren estar familiarizados con el sistema operativo
cliente, la aplicación VPN y los mecanismos de seguridad adecuados. Y
algunos paquetes VPN requieren cambios en las tablas de encaminamiento y
los esquemas de traducción de direcciones.
Sin embargo, las fronteras entre estas tres aproximaciones se van diluyendo
conforme pasa el tiempo. Existen fabricantes que proporcionan soluciones
basadas en hardware, pero que incluyen clientes software para VPN e incluso
características que sólo se encontraban en los sistemas basados en firewalls.
Por otro lado, la introducción del protocolo IPSec está facilitando la mezcla de
distintos productos VPN.
En cuanto a los algoritmos de encriptación, se puede utilizar prácticamente
cualquiera: desde la encriptación de 40 bits que lleva W9x por defecto a
algoritmos más elaborados como triple DES.
La autentificación de usuarios se realiza utilizando cualquier técnica, desde
métodos software a passwords dinámicos tanto software como hardware.
Mauricio Alonso Caneiro
-7-
VPN
4. Problemas de VPN
VPN puede provocar una sobrecarga en la conexión de red debido a la
encriptación utilizada.
La mayoría de dispositivos VPN, tanto software como hardware podrán
manejar encriptación para velocidades de conexión 10baseT.
Para conexiones más lentas, como los módems, el procesamiento puede ser
más rápido que la latencia de la red.
Muchas veces las bajas prestaciones dependen más de la pérdida de
paquetes provocada por una mala conexión a Internet que por la sobrecarga
debida a la encriptación.
Mauricio Alonso Caneiro
-8-
VPN
5. Requisitos
Para poder establecer una VPN, ya sea entre varias subnets o entre una LAN
y un host "móvil", son necesarios algunos requisitos:
Requisitos Hardware:
Es necesario tener un encaminador o router a internet, que va a ser la pieza
clave de la VPN. Cualquier tipo de encaminador, en principio, sería
suficiente. Por supuesto, también es necesario el soporte físico para la
comunicación entre las dos subnets o entre la LAN y el host "móvil".
Requisitos Software:
Se debe tener un sistema de transporte `opaco' entre los dos puntos a unir
por la VPN. Esto es, que debe actuar sólo como transporte, sin `mirar' dentro
de los datos que va a transportar. El transporte debe asegurar una cierta
calidad de servicio, si esto es posible, y debe proporcionar seguridad
(encriptación) a los datos.
Además será necesario que junto con los encaminadores (ya comentados en
los requisitos hardware) se disponga de algún tipo de encapsulamiento
disponible para que la red de transporte intermedio (ya sea dialup, Internet u
otro tipo de red) sea capaz de entregar los paquetes entre los dos
encaminadores de la VPN, sin tener que `mirar' dentro de los datos de la
transmisión que, además, podrían estar encriptados.
Otro de los requisitos más importantes a la hora de construir una VPN es el
hecho de que las aplicaciones deberían seguir funcionando perfectamente
como hasta ahora habían funcionado. Es decir, la creación de la VPN debería
ser transparente a las aplicaciones que se estén usando o se puedan usar en
cualquiera de las redes que forman la VPN.
Es de observar que un protocolo que cumple la parte de seguridad y opacidad
es el IPSec, y es por ello que será en el que más empeño ponga en su
descripción. El encapsulamiento de los datos se podrá cumplir con IPSec
también.
Veamos las soluciones propuestas por los fabricantes y estándares para
estos requisitos:
En primer lugar, existen variedad de compañías:
Cisco, Alcatel, 3Com, .... que ofrecen paquetes completos de solución, con
un hardware que hace las funciones de encaminador-pasarela
(a través
de Internet) de la VPN, y unos protocolos soportados (normalmente
embebidos en el hardware).
Mauricio Alonso Caneiro
-9-
VPN
Yo me voy a centrar en lo siguiente:
−
Internet o alguna red IP como medio de transporte entre las dos
más) redes a unir.
−
Router o similar capaz de encaminar paquetes IP.
Mauricio Alonso Caneiro
- 10 -
VPN
(o
6. Protocolos
Con el fin de sintetizar algunos de los protocolos de VPN, aquí tenemos una
lista de los más famosos:
•
mppe (Microsoft Point-to-Point Encryption): protocolo que sirve para
encriptar los datos de las transmisiones.
•
mschap: tanto la versión 1 como la número 2, que sirve para establecer
la conexión segura y el intercambio de las claves. En la versión 1 se
descubrió una vulnerabilidad, que todavía no ha sido confirmada, que le
obligó a evolucionar hasta la versión 2 (actual).
•
IPIP: protocolo de encapsulamiento de IP sobre tramas IP. Este
protocolo, que puede parecer poco útil, nos sirve para hacer el tunneling
que se marca como uno de los requisitos de VPN.
•
IP-GRE: protocolo de encapsulamiento de otros protocolos sobre IP. En
un principio el tráfico que puede encapsular IP-GRE sería cualquiera. Es
útil en el sentido de que podemos tener redes de otro tipo además de IP
(como por ejemplo IPX) y funcionar con una VPN de igual manera. Más
adelante se verá como IPSec sirve para este mismo fin (a la vez que
proporciona otros muchos servicios).
•
PPTP (Point-to-Point Tunneling Protocol) : protocolo de encapsulado de
PPP sobre IP. Es una especificación desarrollada por un consorcio de
fabricantes, entre los que estaban gente como Microsoft, 3Com o U.S.
Robotics. El protocolo se diseñó originalmente como una forma de
encapsular protocolos no TCP/IP (como IPX) para poder ser transmitidos
por Internet usando GRE (Generic Routing Encapsulation). Es una
especificación genérica, que permite la adición de diversos mecanismos
de autentificación y algoritmos de encriptación. Nótese que estas técnicas
de seguridad no están dentro del protocolo, sino que se añaden a
posteriori.
•
L2TP (Layer 2 Tunneling Protocol) : protocolo que permite separar el
servidor de conexión de nivel 2 OSI (el que “escucha” en el final de la
línea telefónica en un módem por ejemplo) del servidor de PPP. De esta
manera el cliente accede a un servidor de conexión (ej. banco de
módems) y éste -usando L2TP- se comunica con la red (host) con el que
el cliente quiere tener acceso. Esto consigue `juntar' dos segmentos de
red (uno de ellos es point-to-point) virtualmente.
•
IPSec : protocolo que sirve para establecer una sesión segura entre dos
hosts que se comuniquen a través de IP, proporcionando encriptación a
nivel de la capa de red, definiendo nuevos formatos de paquete: la
cabecera de autentificación (AH), que permite asegurar la integridad de
los datos y el ESP (Encapsulating Security Payload), que permite
asegurar la privacidad e integridad de los datos.
AH protege la
integridad y autenticidad de los datos, incluyendo los campos invariantes
de la cabecera IP. Esta cabecera no proporciona confidencialidad,
mientras que ESP protege tanto la confidencialidad como la integridad y
Mauricio Alonso Caneiro
- 11 -
VPN
la autenticidad de los datos. Cuando se usa para comprobar la integridad
de los datos no incluye los invariantes de la cabecera IP.
Éste es el protocolo estrella para la comunicación segura, y es el que,
consecuentemente, voy a explicar con más detalle.
Mauricio Alonso Caneiro
- 12 -
VPN
7. IPSec
7.1. Introducción
IPSec es un acrónimo de IP Security. Se trata de un protocolo cuyo objetivo
es proporcionar seguridad y autentificación para las comunicaciones que
utilicen el protocolo IP. Es un protocolo de seguridad a nivel de red que se
sitúa entre IP y los protocolos de transporte. De esta manera proporciona
seguridad a la capa de transporte y de aplicación según el modelo de
referencia TCP/IP. Si tomamos el modelo de referencia ISO OSI, IPSec
proporcionaría seguridad desde el nivel 3 o nivel 4. Esto será matizado más
adelante cuando diferenciemos entre IPSec en sus dos modalidades:
transporte y encapsulamiento (tunneling).
7.2. El origen del protocolo IPSec
Los orígenes de este protocolo se remontan al año 1994, cuando la Comisión
de Arquitectura de Internet (Internet Architecture Board o IAB) realizaron un
informe que llevaba por título “La seguridad en la arquitectura de Internet”
(RFC 1636). Según dicho informe la opinión generalizada sobre Internet era
que carecía de mecanismos para una mayor seguridad. Se identificaron
diversas áreas para implementar dichos mecanismos, como la intrusión no
autorizada, control de tráfico de red y formas para cifrar y autentificar una
comunicación entre dos máquinas cualesquiera dentro de la red.
Estas preocupaciones se vieron confirmadas en otro informe más tardío, de
1998, del Equipo Informático de Emergencia y Respuesta (Computer
Emergency Response Team o CERT) en el que figuraba una extensa lista de
incidentes relacionados con la seguridad de Internet (disponible en
http://www.cert.org/annual_rpts/cert_rpt_98.html).
El número era superior a 1.300 y afectaba a casi 20.000 localizaciones
distintas. Los ataques más serios eran los relacionados con la técnica de
suplantación de IP (más conocida según la terminología anglosajona como IP
spoofing), aunque también se incluían diferentes formas de intrusión y
espionaje del tráfico de paquetes, mediante las cuales los atacantes leían
información concerniente a identificación y contraseña dentro de un sistema,
bases de datos y otra información de tipo confidencial.
Fue por estas razones por las cuales la IAB incluyó cifrado y autentificación
como características estrictamente necesarias en la nueva versión del
protocolo IP (IPv6). Sin embargo, también se diseñaron de forma que
pudieran ser usadas en versiones previas del protocolo IP, como el muy
extendido IPv4.
Mauricio Alonso Caneiro
- 13 -
VPN
7.3. VPNs e IPSec
Como ya se ha comentado anteriormente, IPSec es el protocolo que se ha
considerado más adecuado para diseñar e implementar VPNs. Veamos
brevemente por qué. A lo largo de estas líneas se hará referencia a diferentes
campos del protocolo IPSec, aunque será más adelante cuando exponga el
formato de los paquetes IPSec detalladamente.
Toda VPN requerirá algún tipo de mecanismo de encapsulamiento, como
ya hemos visto. Supongamos que tenemos dos redes, red A y red B. Tanto la
red A como la red B están separadas entre sí por una red pública IP. A su
vez, ambas están conectadas a esta mediante un router o firewall capaz de
utilizar el protocolo IPSec (a partir de ahora los llamaré gateways seguros
para ser consistentes con la bibliografía existente sobre IPSec). Esta
situación la vemos ilustrada en la figura a continuación.
Figura 3.1: Dos redes conectadas a una pública con gateway seguro
Lógicamente, si cualquier máquina dispone de una implementación IPSec
cualquier conexión entre ambas sería segura, pero se podría realizar un
análisis de tráfico, pues es posible ver el diálogo entre ellas. La aproximación
más convencional y que resulta más lógica es que tan sólo los gateways
seguros estén conectados utilizando IPSec. De esta forma, para los hosts que
forman las dos subredes, la integración en una VPN es totalmente
transparente y se deja que sean los gateways quienes realicen todo el
trabajo.
Para toda VPN en la que esté presente el encapsulamiento es deseable que
se realice una multiplexación de paquetes, ya que pueden existir múltiples
túneles VPN entre dos mismos extremos, precisamente cuando nos
encontramos con un caso como el de la figura anterior pero con más de dos
redes. Tráfico para diferentes clientes viaja por el mismo dispositivo físico, así
que se hace necesario distinguir qué paquetes pertenecen a qué túnel o
conexión.
De entre los protocolos presentados L2TP (por medio de los campos tunnel-id
y session-id) e IPSec (por el campo SPI) permiten multiplexación.
Mauricio Alonso Caneiro
- 14 -
VPN
Igualmente cierta información de configuración debe saberse por un extremo
al que se solicita establecer un túnel VPN, como la dirección IP del otro
extremo y atributos relevantes sobre el túnel como, por ejemplo, el nivel de
seguridad deseado.
El intercambio de estos datos se puede realizar de dos formas: con una
operación realizada por un gestor de túneles o a través de un protocolo de
señalización que permite el establecimiento de túneles de forma dinámica.
El protocolo de señalización, al estar integrado en el propio protocolo de
encapsulamiento reduce la sobrecarga del sistema para formar VPNs.
Reduce claramente la cantidad de configuración y administración. Todos los
datos antes mencionados pueden ser negociados de forma automática entre
dos puntos, mientras que un gestor significa una herramienta administrativa.
En entornos con usuarios móviles que están intermitentemente conectados a
la red privada las ventajas de un protocolo de señalización se muestran más
evidentes si cabe.
Los protocolos que implementan protocolos de señalización son L2TP
(protocolo de control L2TP), IPSec (protocolo IKE) e IPGRE (usado con
encapsulamiento de IP móvil).
En muchas aplicaciones de VPNs, la red puede transportar tráfico opaco
(incomprensible por el hecho de estar cifrado) o multiprotocolo. El protocolo
de encapsulamiento debe, por tanto, permitir el transporte multiprotocolo.
- L2TP está diseñado para transportar paquetes PPP, que a su vez puede
ser usado para transportar tráfico multiprotocolo.
- IPGRE también incluye identificación de protocolo.
- IP/IP e IPSec asumen que el tráfico encapsulado es de tipo IP, protocolo
para el cual están diseñados, pero, de todas formas, IPSec se puede
extender al transporte multiprotocolo durante la negociación de los
parámetros del túnel, con lo que habría que modificar este módulo del
protocolo (el protocolo de señalización IKE).
Si queremos características propias de calidad de servicio (Quality of
Service o QoS) IPSec no proporciona un mecanismo de secuenciación de
tramas como L2TP o IPGRE. IPSec utiliza un identificador de trama para
evitar el reenvío y así protegerse de ataques de denegación de servicio
(Denial of Service o DoS), pero no garantiza una entrega ordenada de
paquetes.
El mantenimiento de túneles es otra característica a tener en cuenta.
Especialmente relevante resulta este aspecto cuando se trata de cerrar
túneles inactivos para liberar así recursos no usados. Al igual que ocurría con
el protocolo de señalización esto puede no estar contemplado en el protocolo
de encapsulamiento propiamente dicho.
Un ejemplo de este último caso sería el envío de mensajes fuera de banda
por parte del protocolo de encaminamiento. Estos mensajes serían enviados
fuera de banda declarando la no necesidad del túnel entre los dos extremos,
dando por finalizada la conexión segura. El algoritmo de encaminamiento
podría detectar esta situación cuando no es capaz de obtener respuesta de
un vecino durante un período de tiempo prudencial.
Mauricio Alonso Caneiro
- 15 -
VPN
Por otro lado, L2TP examina periódicamente la validez de los túneles
supuestamente activos. IPSec establece los túneles ante la llegada de datos
que lo exigen (por su dirección IP de destino, como veremos más adelante) y
tiene parámetros para establecer un tiempo de vida tras el cual se deben
renegociar los parámetros para iniciar un nuevo túnel seguro, si la
comunicación entre los dos extremos no ha finalizado, claro está. En el caso
contrario se cierra la conexión.
La sobrecarga que introduce un protocolo de encapsulamiento puede ser
un asunto preocupante a priori, pero como veremos, teniendo en cuenta que
IPSec utiliza cifrado simétrico o de clave privada, esto no llega a suponer un
verdadero problema. Y en lo que se refiere al proceso de encapsulamientodesencapsulamiento, la automatización es extremadamente simple y rápida.
De hecho, las implementaciones por software suelen ser eficientes con
ordenadores domésticos de gama media/alta.
El punto más importante es que un protocolo de encapsulamiento en una
VPN debe permitir diferentes niveles de seguridad, sean cuales sean los
exigidos por los clientes de la red. Esto se logra con algoritmos de cifrado y
autentificación con diferente nivel de complejidad. Ningún protocolo
mencionado, a excepción de IPSec, lleva mecanismos de cifrado y/o
autentificación intrínsecos, sino que se apoyan en la seguridad de los niveles
inferiores (en concreto el nivel 2). Esta característica es la que nos conlleva a
adoptar de forma definitiva el protocolo IPSec como el medio de implementar
una VPN segura.
Cabe destacar que una VPN sin cifrado ni autentificación es posible con
encapsulamiento IP/IP o IPGRE, pero no sería una VPN segura. Sería una
red privada a efectos administrativos porque todos los hosts intercambiarían
información como si estuvieran en una misma red. No obstante hay que tener
presente, en todo momento, que la información sería visible a terceros
cuando los envíos se producen entre las dos redes separadas por la red
pública y que carece de seguridad.
Mauricio Alonso Caneiro
- 16 -
VPN
7.4. Servicios de IPSec
IPSec proporciona tres servicios:
−
Una función únicamente de autentificación denominada Authentication
Header (AH), es decir, cabecera de autentificación,
−
Una función de autentificación y/o cifrado llamada Encapsulating
Security Payload (ESP) que equivale a carga encapsulada de forma
segura y por última,
−
Una función de intercambio de claves en un principio contemplada por el
protocolo ISAKMP/Oakley, pero que finalmente fue integrado en el
protocolo IKE.
En una VPN tanto el cifrado como la autentificación son deseables ya que es
importante asegurar:
(1) Qué usuarios no autorizados se introduzcan en la red.
(2) Qué terceras partes que practiquen la escucha o espionaje de
comunicaciones en la red pública IP (de ahora en adelante Internet)
puedan leer mensajes enviados por nuestra VPN.
En concreto, AH facilita integridad sin conexión, autentificación propiamente
dicha y un servicio opcional para evitar el reenvío de paquetes. ESP puede
proporcionar confidencialidad (cifrado) y ocultación limitada del flujo de tráfico
así como los servicios ya mencionados de AH. Cuando ESP es invocado, es
obligatorio que al menos uno de los dos servicios sean utilizados.
Estos dos protocolos pueden ser usados independientemente o de forma
combinada. Las diferentes combinaciones se utilizan para aumentar el nivel
de seguridad de IPSec. Por ejemplo, ESP puede proporcionar los dos
servicios, en cambio, AH tan sólo puede facilitar uno de ellos, pero se
diferencia de ESP en que, al autentificar puede también ocultar determinados
campos de la cabecera de un paquete IP. Aunque en general se utiliza ESP,
una combinación de ESP para cifrado y AH para autentificación proporciona
un grado adicional de seguridad.
Ambos protocolos pueden ser utilizados de acuerdo a dos modalidades:
Modo Transporte:
Está contemplado, principalmente, para protocolos de capas superiores. En
IPv4, el encabezado IPSec en modo transporte aparece inmediatamente
después del encabezado IP más opciones y antes de cualquier protocolo de
nivel superior (por ejemplo TCP o UDP). Se diferencia de IPv6 en que en este
último se sitúa tras el encabezado IP junto con sus extensiones y,
opcionalmente, antes o después de opciones de destino pero siempre antes
de los protocolos de capas superiores.
Mauricio Alonso Caneiro
- 17 -
VPN
Figura 3.2: Formato de paquetes IPSec en modo transporte
Modo Túnel:
Además de aplicar los servicios de seguridad, realiza un encapsulamiento del
paquete IP, haciendo de IPSec un protocolo ideal para la construcción de
VPNs. Recordemos que el diseño de IPSec no está relacionado, en modo
alguno, con el concepto de VPN, sino con la concepción de Internet como una
red con escasos mecanismos de seguridad. Cuando se aplica un
encapsulamiento aparecen dos direcciones IP de destino. La exterior que
indica el destino capaz de desencapsular tráfico IPSec y la interior, el destino
final a donde se entrega el paquete. El encabezado de IPSec aparece entre la
dirección exterior y la interior.
Figura 3.3: Formato de paquetes IPSec en modo túnel
Puede deducirse de lo anterior que la granularidad con la que se puede
utilizar el protocolo IPSec es variable. Si deseamos que los paquetes entre
dos hosts de dos redes distintas atraviesen Internet de forma segura, pero
además queremos asegurarnos que nadie más dentro de la red A o red B es
capaz de leerlos, se pueden combinar ESP y AH (opcionalmente) en modo
transporte y encapsulado. Un escenario de estas características es el
representado a continuación.
Figura 3.4: Una conexión IPSec a dos niveles
Mauricio Alonso Caneiro
- 18 -
VPN
7.5. Asociaciones de seguridad (Security Associations o SAs)
El concepto clave en el protocolo IPSec son las asociaciones de seguridad o
Security Associations, a las cuales me referiré de ahora en adelante por su
acrónimo en inglés, SA. Una SA es una conexión unidireccional entre un
emisor y un receptor que además proporciona seguridad sobre el tráfico que
circula entre los dos extremos que conforman dicha conexión. Nótese que se
trata de una comunicación unidireccional o simplex. Si el diálogo entre las
dos máquinas es bidireccional significa que necesitamos dos SAs (una en
cada dirección, según la figura 3.5, en la que las flechas apuntan al extremo
receptor de la SA).
Figura 3.5: Comunicación bidireccional con IPSec
Una SA tiene un identificador único formado por tres parámetros:
•
Índice de parámetros de seguridad (Security parameters index o SPI):
una cadena de bits asignada a esta SA y tiene significado en un contexto
local, es decir, en los extremos de la SA. El SPI se envía dentro de los
encabezados de ESP o AH para permitir al receptor seleccionar la SA
bajo la cual se procesará el paquete recibido.
•
Dirección IP de destino: en un principio la dirección de destino puede ser
de tipo unicast, broadcast o multicast, pero los mecanismos actuales de
gestión de SAs en IPSec sólo están definidos para tratar direcciones
unicast. Esta dirección será, por tanto, un host dentro de una red o un
gateway seguro.
•
Identificador del protocolo de seguridad: indica si se utiliza AH o ESP en
la SA.
Sobre una misma SA puede actuar ESP o AH, pero no ambos. Para combinar
los dos protocolos se necesitaría establecer dos SAs, cada una con un
protocolo, e indicar mediante las herramientas de gestión apropiadas el orden
por el que se procesará el tráfico de paquetes. Cuando más de una SA se
aplica sobre el tráfico de paquetes aparece el término de agrupación de SAs
(SA bundle), esto es, una secuencia de SAs, ejecutadas de manera ordenada
para satisfacer cierto nivel de seguridad.
Mauricio Alonso Caneiro
- 19 -
VPN
Las agrupaciones responden a dos tipos diferenciados:
Adyacencia de transporte
Hace referencia a la aplicación de más de un protocolo de seguridad al
mismo datagrama IP, sin invocar encapsulamiento. Esta aproximación sólo
aumenta la seguridad respecto a una SA (no una agrupación) cuando
aplicamos primero ESP y AH posteriormente (ver arriba Servicios IPSec).
Figura 3.6: Adyacencia de transporte
Encapsulamiento iterativo
Consigue construir niveles de seguridad a base de combinar SAs en modo
túnel entre los dos hosts que desean establecer una comunicación segura y
entre los gateways seguros. Las tres formas contempladas presuponen que
los hosts son capaces de procesar tráfico encapsulado con IPSec.
En un primer nivel de seguridad se encapsula doblemente, directamente
entre los hosts combinando ESP y AH. Utilizar el mismo protocolo es una
elección poco probable ya que no se consigue incrementar cualitativamente
la complejidad a la que se enfrentaría un atacante espiando el tráfico de
red.
Figura 3.7: Encapsulamiento iterativo. Nivel 1
Mauricio Alonso Caneiro
- 20 -
VPN
En el siguiente nivel de seguridad sólo uno de los dos extremos de las SAs
es el mismo. Los túneles pueden ser o bien AH o bien ESP.
Figura 3.8: Encapsulamiento iterativo. Nivel 2
El tercer nivel de seguridad aplica dos túneles en los que ningún par de
extremos coinciden. Al igual que antes AH o ESP son aplicables.
Figura 3.9: Encapsulamiento iterativo. Nivel 3
A partir de esta tipología se obtienen las llamadas combinaciones básicas
de SAs. Cualquier sistema que se considere que cumpla la definición del
protocolo IPSec, obligatoriamente tiene que ser capaz de generar estas
combinaciones y también de procesarlas si es el receptor de la información.
En todos los diagramas mostrados, la línea doblemente punteada representa
una SA o una agrupación de SAs, indistintamente.
Mauricio Alonso Caneiro
- 21 -
VPN
Combinación Básica 1
Figura 3.10: Seguridad entre los hosts a través de Internet
Se trata del caso más simple. Se puede seleccionar modo transporte o
modo túnel, así que los encabezados del host 1 y del host 2 pueden tener
cualesquiera de los siguientes aspectos:
Figura 3.11: Modos de comunicación en la combinación básica 1
Combinación Básica 2
Figura 3.12: Soporte para VPN's simples
Este es un ejemplo muy ilustrativo de la capacidad de IPSec para
implementar VPNs seguras. Veremos este caso con cierto detalle en la
aplicación de un caso práctico más adelante en el proceso de
comunicación, paso a paso, entre el host 1 y el host 2. AH o ESP se pueden
utilizar dependiendo de cual sea la política de seguridad de la organización.
Mauricio Alonso Caneiro
- 22 -
VPN
Combinación Básica 3
Figura 3.13: Combinación de los dos primeros casos
Añade un nivel adicional de seguridad respecto al caso anterior. Como ya
hemos comentado evita la intromisión de terceras partes dentro de la red
local y asegura que única y exclusivamente el extremo receptor puede leer
la información enviada por el emisor.
En esta modalidad un cliente itinerante puede autentificarse dentro de la red
privada y pasar a formar parte de la misma con los mismos derechos que si
fuera físicamente parte de la misma. Esta modalidad, aunque contemplada
por IPSec, es la menos utilizada ya que hay protocolos más aconsejables
como L2TP o PPTP ideados específicamente con este fin.
Con esta división vemos como a partir del primer caso como bloque básico, el
resto de lo casos se van añadiendo y superponiendo, haciendo de IPSec un
protocolo ideal para construir VPNs en todas sus diferentes modalidades, ya
sea conectando dos redes remotas a través de una red pública no segura o
añadiendo hosts remotamente.
Figura 3.14: Una VPN mediante acceso remoto
Mauricio Alonso Caneiro
- 23 -
VPN
7.6.
Base de datos de asociaciones
Association Database o SAD)
de
seguridad
(Security
En cada una de las entradas de esta base de datos (que se genera de forma
dinámica) se definen los parámetros de una SA. Para el proceso hacia el
exterior cada una de estas entradas está vinculada a una entrada de la base
de datos de políticas de seguridad o SPD (ver el siguiente punto). Si llega un
paquete dirigido a un host o gateway con el que se quiere establecer una
conexión segura, se crea junto con la SA una entrada en la SAD asociada y
se vincula a la SPD.
Para tráfico entrante, cada entrada de la SAD se indexa por dirección IP de
destino, tipo del protocolo utilizado en esa conexión de IPSec (ESP y/o AH) y
SPI. Cada entrada de esta base de datos contiene una lista de parámetros
que se dividen según se utilicen para asociar el tráfico que llega por una SA a
la entrada en concreto de la SAD (se realiza una búsqueda secuencial por las
tuplas hasta que se encuentra una coincidencia), y otros campos destinados
al proceso de paquetes IPSec.
Voy a incluir una lista de los parámetros de cada una de las entradas de esta
base de datos. Tan sólo se incluyen los estrictamente necesarios. Otros
parámetros son posibles si se desean funcionalidades adicionales o
características específicas, pero no están contempladas por IPSec:
•
Dirección IP exterior: la dirección destino.
•
Protocolo IPSec: AH o ESP. Especifica el protocolo a ser aplicado sobre
el tráfico de esta SA.
•
SPI: el valor de 32 bits que se usa para distinguir entre diferentes SAs
que terminan en el mismo extremo y que utilizan el mismo protocolo.
Hasta aquí los campos relacionados con la identificación de una entrada con
la SA por la cual se recibe tráfico entrante. Los parámetros usados para el
proceso de IPSec son estos (tanto para tráfico entrante como saliente):
•
Contador de número de secuencia: valor de 32 bits usado para generar
un número de secuencia en el campo correspondiente en la cabecera
AH o ESP.
•
Desbordamiento de contador de secuencia: flag indicando si un
desbordamiento en el contador de secuencia debería registrar este
evento (evento auditable) para evitar transmisión adicional de paquetes
sobre la SA.
•
Ventana anti-reenvío: contador de 32 bits y mapa de bits (o
equivalente) usado para determinar si un paquete ESP o AH entrante
es un reenvío.
•
Algoritmo de autentificación AH, claves, etc.
•
Algoritmo de cifrado ESP, claves, modo IV, IV, etc.
Mauricio Alonso Caneiro
- 24 -
VPN
•
Algoritmo de autentificación ESP, claves, etc. Si el servicio de
autentificación de ESP no está activado este campo estará vacío o
marcado como null.
•
Tiempo de vida de la SA: intervalo de tiempo tras el cual una SA debe
ser reemplazada por una nueva SA (y nuevo SPI) o darla por finalizada,
junto con qué opción de estas dos posibles debería ser ejecutada.
Expresable como un valor temporal, cuenta de bytes o ambos. El
primero que se supere será el que provoque la acción marcada.
•
Modo del protocolo IPSec: túnel, transporte o cualquiera de los dos. En
este último caso la implementación de IPSec debe tener mecanismos
para saber cuando aplicar cada modo de forma apropiada. De esta
forma podemos enviar protocolo en ambos modos por la misma SA.
•
PMTU: cualquier variable relacionada con el MTU y otros datos
cambiantes del camino seguido por el paquete.
Mauricio Alonso Caneiro
- 25 -
VPN
7.7. Base de datos de política de seguridad (Security Policy Database o
SPD)
Con esta base de datos se especifica en un sistema qué servicios se ofrecen
a los datagramas IP procesados y en qué manera.
El protocolo IPSec no incluye detalles de implementación o la interfaz de
dicha base de datos, pero sí que especifica ciertas funcionalidades mínimas
para que un usuario o administrador en un sistema pueda controlar cómo
IPSec debería ser aplicado al tráfico de red, enviado o recibido por un host o
gateway seguro. Todo paquete que abandone o llegue al sistema debe
generar una consulta en esta base de datos para tomar una decisión
respecto a cómo tratarlo. Podría implementarse como dos bases de datos
diferenciadas o con un campo determinado para distinguir los dos tipos de
tráfico.
Para todo paquete entrante o saliente existen tres acciones posibles:
•
Aplicar IPSec: consiste en cifrar y/o autentificar un paquete de
acuerdo con las normas establecidas en la propia entrada de la base
de datos. Cuando esto se hace se comprueba si la entrada
correspondiente está vinculada a una de la SAD (para consultar claves
y resto de parámetros a añadir a las cabeceras ESP o AH) y si no se
crea una nueva y se procede al envío de la información.
•
No aplicar IPSec: consiste en realizar un encaminamiento normal del
paquete, o tratarlo como lo haría un sistema que no implementase
IPSec.
•
Descartar el paquete: significa inhibir todo tipo de acción, similar a lo
que haría un firewall. Generalmente se emplea como medida de
seguridad.
Cuando se aplica IPSec, en esta misma base de datos se incluye una
especificación de una SA o agrupación de SAs, el listado de protocolos de
IPSec, modos y algoritmos empleados junto con los requisitos de
anidamiento. Aunque en un principio cierta información pudiera parecer
redundante respecto a la SAD, recordemos que las entradas de la SAD se
forman dinámicamente y a priori no sabemos siquiera si existe una SA
destinada a manejar el tráfico IPSec entrante o saliente.
A la hora de elegir una entrada se hace en base a las direcciones de destino
u origen IP que se encuentran en la cabecera del datagrama IP. Cada una
de las tuplas de la base de datos tienen como primer campo un selector, que
consiste en una dirección IP, un rango o un rango mediante comodines.
Mauricio Alonso Caneiro
- 26 -
VPN
7.8. Gestión de claves
La porción de IPSec encargada de la gestión de claves incluye la elección y
distribución de claves secretas para cifrado simétrico. La arquitectura IPSec
obliga a que cualquier producto IPSec soporte dos tipos de administración
de claves:
•
Manual: el administrador de una red dada configura manualmente
cada sistema con sus propias claves para que coincidan entre sí. Es
práctico para entornos pequeños y relativamente estáticos.
•
Automático: un sistema automático permite la creación de claves
para SAs en base a una petición y da servicio al uso de claves en
grandes sistemas distribuidos con una configuración en permanente
cambio.
El protocolo por defecto definido para la distribución de claves en IPSec fue,
inicialmente, el conocido como ISAKMP/Oakley, que hace referencia a los
dos módulos que permiten el intercambio de claves. Ambos se integran en
un esquema más general, IKE. Veamos en qué consisten, exactamente, los
módulos Oakley e ISAKMP, respectivamente:
•
Protocolo de determinación de claves Oakley : Oakley es un protocolo
de intercambio de claves basado en el algoritmo Di-e-Hellman, pero
con ciertas medidas adicionales de seguridad. En particular, el
algoritmo Di-e-Hellman por sí solo no autentifica a dos usuarios que
intercambien claves, por lo que el protocolo es vulnerable a ataques de
suplantación. Oakley incluye mecanismos para evitar este problema.
•
ISAKMP (Internet Security Association and Key Management
Protocol): ISAKMP especifica un marco para el intercambio de claves
en Internet junto con los protocolos (y formatos) capaces de negociar
atributos de seguridad.
ISAKMP por sí mismo no dicta el uso de un algoritmo de intercambio
de claves; en lugar de ello, ISAKMP consiste de un conjunto de tipos
de mensajes que permiten el uso de una serie de algoritmos. Oakley es
el algoritmo de intercambio de claves en concreto que apareció con la
versión inicial de ISAKMP.
Mauricio Alonso Caneiro
- 27 -
VPN
7.9. Proceso de tráfico: un ejemplo práctico
El caso práctico que presento se remite a la combinación básica 2, VPNs
simples (Ver figura 3.12).
En esta VPN disponemos de 2 hosts, pertenecientes a dos redes distintas.
Cada una de estas dos redes están conectadas a Internet mediante un
gateway seguro, que serán los que establezcan una comunicación mediante
IPSec. Dada la simplicidad de la configuración de nuestra VPN el secreto
compartido (la clave) se introducirá manualmente. En un caso real donde la
complejidad sea de esta magnitud también es lo más aconsejable, así que
podemos afirmar que intentamos ajustarnos a una realidad práctica en la
que una organización desea implementar una VPN.
Los pasos en los que se produce la comunicación son los siguientes:
1. El host 1 envía un paquete al host 2. La difusión del paquete en la red
local es atendida por el gateway seguro.
2. El gateway seguro analiza el paquete, comparando su dirección IP de
destino contra las entradas de la SPD. Al encontrar una entrada o
patrón que coincida, negocia una SA con el gateway seguro que
separa al host 2 de Internet.
3. Mediante el protocolo IKE el gateway seguro 2 acepta
establecimiento de la SA. Al ser el secreto compartido conocido
antemano ninguna distribución de claves es necesaria ni el envío
certificados digitales. El segundo gateway informa al primero que
abierto al SA.
el
de
de
ha
4. El primer gateway, ya habiendo asociado la entrada apropiada de la
SPD con una entrada establecida dinámicamente en la SAD cifra y
encapsula el paquete con los parámetros contenidos en esta base de
datos. Se procede así al envío. Cualquier encabezado adicional AH y/o
ESP es añadido al paquete y luego este se introduce en el campo de
datos de un nuevo paquete, dirigido al segundo gateway.
5. El paquete, a primera vista, es un paquete IP sin ninguna distinción y
es encaminado de forma normal hasta llegar al segundo gateway. Este
paso, en el que no interfiere IPSec en modo alguno, es no obstante la
clave de la VPN segura, ya que cualquier atacante que intente
averiguar el contenido de la información enviada se encontrará con un
mensaje cifrado y/o autentificado en la carga de datos. Si quiere leer el
texto en claro o modificar el contenido del mensaje se enfrenta a un
problema computacionalmente intratable.
6. El paquete llega al segundo gateway. Se aplica el tercer paso de
forma inversa. Se compara contra las entradas de la SPD de tráfico
entrante. Una de sus entradas está vinculada a una de la SAD, en la
que se encuentran los parámetros de la SA que comparten emisor y
receptor. La parte de datos del paquete es extraída
(desencapsulamiento) y descifrada.
Mauricio Alonso Caneiro
- 28 -
VPN
7. El paquete original con el texto en claro es entregado al host 2.
Todo tráfico con los datos no cifrados se realiza en un entorno seguro,
siendo el envío a través de la red pública con los niveles de seguridad
deseados por los dos extremos que se ponen en contacto.
Mauricio Alonso Caneiro
- 29 -
VPN
8. Conclusiones
Como vemos, la creación de una VPN ha dado solución a la mayoría de los
retos que le habíamos impuesto. Ahora, gracias a que podemos tener
direcciones IP correspondientes a una misma subred IP, podemos cumplir el
punto de requisitos que nos pedía mayor facilidad para la administración de
la red. Usando IPSec hemos conseguido, además, otorgar los servicios de
autentificación (AH) y encriptación / opacidad de los datos (ESP).
El punto de requisitos que mencionaba la necesidad (o quizás el deseo) de
que las aplicaciones deberían seguir funcionando sin tener que modificarlas
debido a la creación de la VPN no se va a cumplir enteramente. Esto es
debido a que algunas aplicaciones que trabajen directamente a un nivel
inferior que el de IP (que deberían de ser aquellas que monitoricen la red,
por ejemplo) van a "darse cuenta" de que hay dos redes físicamente
separadas, ya que, por ejemplo, no serán capaces de analizar el tráfico que
suceda entre dos hosts de otras subredes, que sí serían capaces de analizar
en un segmento de una auténtica LAN. Esto se puede solucionar, si es una
necesidad crítica, usando un protocolo que trabaje sobre el nivel 2 OSI (L2),
como sería por ejemplo L2TP, que está pensado para `juntar', en un
principio, un host con una subnet, pero que puede servirnos para comunicar
dos gateways de las subnets a unir por el VPN.
Las aplicaciones que hacen uso de las capacidades de broadcast de IP
plantean un problema que tampoco se soluciona con el uso de IPSec para la
creación de la VPN. Debido a que IPSec tiene un secreto compartido por
cada par de IP's, el broadcast no tiene sentido para él, ya que tan sólo un
host sería capaz de desencriptar los datos.
El último problema que podría existir aparece cuando intentamos reunir dos
VPN's existentes (o más) en una sola VPN.
Pongamos un ejemplo:
La compañía A tiene configurada una VPN, al igual que la compañía B, y,
de mutuo acuerdo, deciden unir ambas, para formar una sola empresa.
Tanto A como B deben de asegurarse que ninguna de ellas tiene
direcciones de red que existan en la otra, es decir, sus direcciones de red
privadas no deben de solaparse, para que no exista ninguna IP que esté
tanto en la red de A como en la de B.
Esto puede no ser un problema si las IP's asignadas a sus redes son IP's
reales de Internet.
Pasada la primera comprobación se debe asegurar que tanto A como B
usan el mismo estándar de comunicación en sus subnets ya que, en caso
contrario no se podría, en un principio, establecer rutas de encaminamiento
para protocolos diferentes.
Este mismo problema aparece cuando una de las compañías usa IPSec
para la comunicación entre sus hosts de sus subnets, y la otra compañía
no.
Mauricio Alonso Caneiro
- 30 -
VPN
Para solucionar estas dificultades de `entendimiento' que pudiesen aparecer
entre dos VPN's, el VPNC (VPN Consortium) ha definido unos tests que
definen nuestra VPN con uno de los tres niveles que voy a indicar a
continuación. Según si nuestra solución de VPN consigue pasar 1, 2 ó 3 de
los tests definidos, será más segura y "estándar".
VPNC Comformance Tests:
Basic Test :
La prueba consiste en averiguar si un gateway de VPN (con IPSec)
funciona correctamente o no. Para ello, se escoge un host de la red de
detrás del gateway a probar, y se intenta acceder a una página web que
está en otra red detrás de otro VPN-gateway. Este último gateway debe de
haber sido probado previamente, y para asegurarse de ello, VPNC escoge
dos VPN-gateways ampliamente usados: uno corriendo sobre OpenBSD y
el otro sobre KAME
Rekeying :
Se probará si nuestro VPN-gateway es capaz de hacer 'rekeying'. Esto es
que cuando se le solicite, nuestro gateway deberá ser capaz de renegociar
una nueva clave de secreto compartido. Esto se hará a través del IKE.
Certificates Test :
El test probará en nuestro VPN-gateway la capacidad de autentificarse
usando un certificado digital PKIX en modo firma RSA, que es el método
más común de certificación usado con IKE.
Los certificados los expide el VPNC tras comprobar ellos mismos que se
superan las pruebas establecidas. La primera vez que se pide pasar el test
es necesario pagar una cantidad (media) al consorcio.
Desde entonces se pueden renovar los certificados de forma gratuita, si se
deciden volver a pasar, o intentar pasar los que quedasen.
Es de notar que los certificados hacen mención a los gateways
implementando únicamente IPSec, con lo que el problema anterior con
respecto a la necesidad de definir un estándar de conexión para las VPN's
ha quedado bastante reducido. Ahora sólo nos tendríamos que preocupar
de no compartir las mismas IP's.
Si nuestras necesidades no se ajustan al uso de IPSec para tráfico IP,
estos tests no podrán ser superados, puesto que se realizan
exclusivamente para comprobar IPSec funcionando como cápsula.
Mauricio Alonso Caneiro
- 31 -
VPN
9. Bibliografía
La bibliografía usada
encontrada en la web.
corresponde
principalmente
a
documentación
Hago especial hincapié en los RFC's (Request For Comments) que he tenido
que leer por ser la fuente principal de información que he usado.
•
Internet Engineering Task Force (www.ietf.org)
RFCs: 2401, 2764, 2709, 2411, 2521, 2685 (IPSec)
•
Virtual Private Network Consortium (www.vpnc.org)
•
Cisco (www.cisco.com)
IPSec (White paper)
•
TechGuide (techguide.com)
Managing the costs and complexities of VPN deployment
•
Network World Fusion Focus on VPNs, 06/16/99, by Tim Greene
Mauricio Alonso Caneiro
- 32 -
VPN