
Implementación de Redes
Privadas Virtuales (VPN) utilizando el protocolo IPSec
Curso de Especialista
Universitario en
Seguridad Informática y
Servicios Electrónicos.
Trabajo final.
|
En la actualidad, las
organizaciones son cada vez más dependientes de sus redes informáticas y un
problema que las afecte, por mínimo que sea, puede llegar a comprometer la
continuidad de las operaciones.
La falta de
medidas de seguridad en las redes es un problema que está en crecimiento. Cada
vez es mayor el número de atacantes y cada vez están más organizados, por lo
que van adquiriendo día a día habilidades más especializadas que les permiten
obtener mayores beneficios. Tampoco deben subestimarse las fallas de seguridad
provenientes del interior mismo de la organización.
La propia complejidad de la
red es una dificultad para la detección y corrección de los múltiples y
variados problemas de seguridad que van apareciendo. En medio de esta variedad,
han ido aumentando las acciones poco respetuosas de la privacidad y de la
propiedad de recursos y sistemas. “Hackers”, “crakers”, entre otros, han hecho
aparición en el vocabulario ordinario de los usuarios y de los administradores
de las redes.
Además de las técnicas y
herramientas criptográficas, es importante recalcar que un componente muy
importante para la protección de los sistemas consiste en la atención y
vigilancia continua y sistemática por parte de los responsables de la red. A la
hora de plantearse en qué elementos del sistema se deben de ubicar los
servicios de seguridad podrían distinguirse dos tendencias principales:
Protección de los sistemas de
transferencia o transporte. En
este caso, el administrador de un servicio asume la responsabilidad de
garantizar la transferencia segura al usuario final de la información de forma
lo más transparente posible. Ejemplos de este tipo de planteamientos serían el
establecimiento de un nivel de transporte seguro, de un servicio de mensajería
con MTAs (Mail Transport Agents) seguras, o la instalación de un firewall, que
defiende el acceso a una parte protegida de una red.
Aplicaciones seguras extremo a extremo. Si
pensamos, por ejemplo, en el correo electrónico, consistiría en construir un
mensaje en el cual el contenido ha sido asegurado mediante un procedimiento de
encapsulado previo al envío. De esta forma, el mensaje puede atravesar sistemas
heterogéneos y poco fiables sin por ello perder la validez de los servicios de
seguridad provistos. Aunque el acto de asegurar el mensaje cae bajo la
responsabilidad del usuario final, es razonable pensar que dicho usuario deberá
usar una herramienta amigable proporcionada por el responsable de seguridad de
su organización. Esta misma operatoria, puede usarse para abordar el problema
de la seguridad en otras aplicaciones tales como videoconferencia, acceso a
bases de datos, etc.
En
ambos casos, un problema de capital importancia es la gestión de passwords.
Este problema es inherente al uso de la criptografía y debe estar resuelto
antes de que el usuario esté en condiciones de enviar un solo bit seguro. Otro
no menos importante es el nivel de implicación de los usuarios con respecto a
la seguridad de los datos que están manejando, que en la mayoría de los casos
suele ser nulo.
Aunque
en nuestro trabajo nos vamos a centrar en la seguridad en redes de
comunicaciones, a continuación destacamos las principales áreas que un sistema
de seguridad completo debería contemplar:
o
La autentificación,
para comprobar que tanto el usuario del servicio y el prestador del servicio
son realmente quienes dicen ser.
o
La confidencialidad
para garantizar que los datos que se envían sólo serán conocidos por usuario y
servidor; que nadie, en un paso intermedio podrá tener acceso a dicha
información.
o
La integridad
de los datos enviados. El servidor ha de estar seguro de que los datos
recibidos son idénticos a los enviados, es decir, que no han sido modificados
por el camino.
Así pues un sistema de seguridad
completo debe contar con la selección y diseño previo de las herramientas
adecuadas. Lo que se pretende es tener un nivel de seguridad que sea capaz de
responder favorablemente ante posibles negligencias de los usuarios, ataques
malintencionados, y posibles catástrofes naturales.
Para esta labor es necesario que
la organización que desee implantar un sistema de seguridad deberá seguir
metodología y contar con un grupo de trabajo formada tanto por personal interno
de la organización, como externo si así fuese requerido o la empresa no cuenta
con personal cualificado.
La metodología para implantar el
plan de seguridad debería desarrollar en profundidad los siguientes puntos:
·
Comité de seguridad y gestión de red.
·
Evaluación de la red
·
Administración de la red y métodos de control de
acceso
·
Sistemas de control de acceso.
·
Análisis del tráfico de la red
·
Seguridad en las aplicaciones informáticas
·
Auditoría de seguridad y detección de intrusiones
·
Política de seguridad de red
·
Política de control de virus
·
Plan de contingencia y recuperación ante
catástrofes
Comité de seguridad y gestión de
red:
Una primera reunión es necesaria
para establecer tareas, actividades y responsabilidades. El propósito es formar
un equipo que se encargue de definir los objetivos. Debería incluir
representantes de cada área funcional de la organización.
Evaluación de la red.
Arquitectura:
Es el proceso de identificar y
documentar toda la red, su topología, elementos y recursos. Este proceso
generará las herramientas necesarias para establecer una política de seguridad
efectiva.
Administración de la red y
métodos de control de acceso:
En este punto se pretende
verificar como son tratadas las cuentas de usuarios y sus permisos. Esto nos
revelará no sólo como están configurados los permisos de acceso, sino también saber
si hay uno o varios administradores para cada tarea en particular. También es
necesario conocer como trabajan los controles de acceso desde los sistemas del
usuario, incluyendo que servicios se han activado después de identificarse en
la red.
Sistemas de control de acceso:
Una vez introducidos en la red
Firewalls, dispositivos de control de acceso, sistemas de detección de
intrusos... es necesario validar su configuración y funcionalidad. Las
diferentes configuraciones y mecanismos de los sistemas de control de acceso
forman la base de la seguridad de la red.
Análisis del tráfico de la red:
Un analizador de redes nos
revelará que tipo de tráfico hay en nuestra red. Esto nos puede indicar, no
sólo si las contraseñas pueden ser fácilmente robadas, sino que también nos
ayudará a conocer el rendimiento y comportamiento de la red.
Debemos saber exactamente cuales
son las aplicaciones informáticas utilizadas en la organización y las
vulnerabilidades de cada una de ellas.
Auditoría de seguridad y
detección de intrusiones:
Una auditoría de seguridad junto
con los sistemas de detección de intrusos nos permitirá identificar
vulnerabilidades en nuestros sistemas. En este punto nos podemos encontrar con
diversas maneras en las que nuestros datos confidenciales podrían ser
sustraídos. También se pueden detectar posibles errores de diseño de la red.
Para esto se deben usar las últimas herramientas de análisis de
vulnerabilidades, cuyos resultados deberán tenerse en cuenta a la hora de
reestructurar la red.
La política de seguridad nos
ayudará a saber como de preocupada e interesada está la organización acerca de
la seguridad e integridad de sus datos. También puede clarificar objetivos
organizacionales. Deberá ser la base para implementar los controles de
seguridad que reduzcan las vulnerabilidades y riesgos. Nosotros la estamos
desarrollando en paralelo con el resto de actividades.
Una política antivirus ayudará a
prevenir perdida de datos como consecuencia de infecciones de virus
informáticos.
Bien redactados y con los pasos
y actuaciones bien claros, un Plan de Recuperación de datos minimizará el
tiempo de malfuncionamiento de la red en caso de caida de los servidores, caída
de la pasarela a Internet u otros dispositivos críticos.
Nuestro trabajo es un punto concreto de un dispositivo de
seguridad que se empezó a desarrollar en Septiembre de 2.001 y que forma parte
de un proyecto de red en el que se pretende comunicar de manera segura
diferentes sedes de una misma organización, separadas geográficamente.
Este sistema consiste en diseñar
una máquina cortafuegos, que permita de manera sencilla filtrar paquetes
tomando como referencia las direcciones y puertos IP origen y destino y otras
opciones de filtrado avanzadas. Además del filtrado, incluye, para el adecuado
nivel de seguridad y comprensión del comportamiento de la red, una herramienta
que nos permita analizar el tráfico de la red, analizador de protocolos y
sistema de detección de intrusiones.
La máquina diseñada deberá ser
el bastión de seguridad de la red, y por ella circulará todo el tráfico entre
la organización e Internet. Por este motivo es imprescindible que proporcione
un rendimiento óptimo y que en ningún caso ralentice las comunicaciones. Así
pues se debería auditar periódicamente su comportamiento conforme vaya
creciendo el tráfico extranet y si se da el caso, liberar a la máquina de
ciertas tareas.
Además el proyecto de red que se
está implementando exige seguridad en la transmisión de los datos, puesto que
estos se transmiten sobre una red IP inherentemente insegura. Así, otra
herramienta que se incluye en el sistema, y que es el punto que vamos a
desarrollar en este trabajo, es la de cifrado de los datos sobre IPSec para la
comunicación entre las distintas sedes, y para el acceso a la red corporativa
de usuarios remotos, de manera que tengan acceso seguro a los recursos de la
organización a través de Internet (IP-VPN).
2. VPN o Redes Privadas Virtuales
Es de noche.
La calle está llena de gente. Estamos esperando a cruzar la acera, cuando de
repente vemos pasar una limusina. Tiene los cristales tintados, que reflejan
las luces del neón, pero no podemos ver quién hay dentro ni lo que está
haciendo. Estamos acostumbrado a ver otro tipo de coches, así que nos
preguntamos ¿quién viajará ahí dentro? ¿Un político? ¿un actor?. De repente las
luces del semáforo cambian y nos vemos arrastrados por la multitud al otro lado
de la calle. La limusina se desvanece en la noche, dejando atrás todas nuestras
especulaciones.
Si trasladamos esta experiencia al mundo IP , nos daremos
cuenta de las ventajas de las VPN (Virtual
Private Network). La analogía reside en que al igual que la limusina viaja
por la calle sin mostrar que ocurre en su interior, la comunicación en una VPN
viaja a través de Internet, pero está encapsulada y encriptada por lo que su
contenido es secreto. Sólo el emisor y el receptor legítimo del mensaje pueden
verla en su estado normal. Así el camino de un mensaje a través de una VPN
tiene luz en los extremos, y oscuridad entre ellos, por lo que también se le
llama, metafóricamente hablando, un túnel VPN.
Hablando en un lenguaje algo más técnico,
básicamente una VPN es una unión de
redes dispersas en Internet con una relación de confianza (configurable) entre
las mismas, y niveles de autenticación y cifrado. Como indica su nombre, es una
red privada, puesto que brinda autenticación y cifrado (privacidad en
definitiva) y virtual porque se implementa sobre las redes públicas existentes
y que no tienen los niveles de seguridad adecuados.
A pesar del retroceso que atraviesan las inversiones en
tecnología, el mundo empresarial continúa viendo a Internet una manera de hacer
negocios. La tecnología VPN está pasando de ser una nueva palabra de moda, a
ser esencial para las empresas que quieren estar intercomunicadas. De hecho,
mientras que las redes privadas están únicamente al alcance de grandes corporaciones
que pueden costear su propia red, la tecnología VPN permite prácticamente a
cualquier persona que tenga un ordenador y una línea telefónica usar datos de
manera confidencial.
A continuación vamos a ver escenarios típicos de
una VPN, que objetivos se persiguen al implantarla, y la tecnología más
adecuada a la hora de implementarla.
Hay algunos modelos de empresa en los que la
tecnología VPN proporciona notables beneficios.
Branch offices o delegaciones.
En este supuesto, se trata de localizaciones de una
misma empresa separadas geográficamente. y que necesitan intercambiar datos
entre ellas, acceder a una misma base de datos, aplicación... La VPN permite conexiones confidenciales de
una red a otra.

Extranets.
Empresas diferentes, pero que trabajan
conjuntamente (p ej, proveedor y fabricante), pueden compartir información de
manera eficiente y segura entre sus respectivos negocios sin que terceras
personas tengan acceso a los datos compartidos. En este caso también se
interconectan las redes corporativas, aunque sólo se da acceso a un segmento de
cada red.
Usuarios móviles.
Ahora hablamos de trabajadores que pasan gran parte
del tiempo fuera de la empresa, como teletrabajadores o los llamados “road warriors”,
personas que necesitan acceder a la red de la empresa pero que están
constantemente cambiando de ubicación. Ahora lo que se permite es a un
ordenador personal o portátil el acceso a la red corporativa, manteniendo la
privacidad.

Los
objetivos básicos que persigue una empresa cuando decide instalar un servidor
de VPN en una o varias de sus sedes son los siguientes:
1º.
Proporcionar movilidad a los empleados.
2º. Acceso a la base de datos
central sin utilización de operadores telefónicos .
3º. Interconexión total a la red de todos los comerciales
(empleados), de forma segura a través
de una infraestructura pública.
4º.
Intercambio de información en tiempo real.
5º.Correo
electrónico corporativo
6º.Acceso
remoto a la información corporativa
7º.
Teletrabajo.
8º.
Flexibilidad y facilidad de uso.
9º.
Obtención de la máxima velocidad de transferencia de datos usando con
eficiencia los recursos empleados.
10º. Fácil
adaptación a las nuevas tecnologías.
Obviamente
existen diferentes tecnologías sobre las que una VPN puede estar implementada.
A continuación destacamos las más importantes. Resaltar que se mencionan según
su momento de aparición.
PPTP (Point-to-Point Tunneling Protocol).
Encapsulado
de tramas PPP en datagramas IP, utilizando una versión extendida del GRE
(Generic Routing Encapsulation, protocolo IP 47). La conexión de control se
realiza sobre TCP, puerto 1723.
Actualmente
este protocolo, aunque muy popular en el mundo Microsoft, está siendo
sustituido por el L2TP. La implementación de Microsoft, además, sufre de varios
importantísimos errores de diseño que hacen que su protección criptográfica sea
inefectiva para alguien más motivado que un simple observador casual. Por lo
tanto, está opción será descartada.
L2TP (Layer 2 Tunnelling Protocol).
Encapsulado
de tramas PPP sobre cualquier medio, no necesariamente redes IP. En el caso IP
se usa UDP, puerto 1701. Tras un largo proceso como borrador, L2TP pasa a ser
una propuesta de estándar en Agosto de 1.999. Aporta grandes ventajas y es
sencillo de configurar, aunque debido a su falta de seguridad e
incompatibilidades está opción también será descartada
IPSEC.
IPSec es el nuevo marco de seguridad IP, definido con el advenimiento del IPv6. Aunque IPv6 está muy poco difundido en este momento, la tecnología marco IPSec se está utilizando ya, lo que asegura, entre otras cosas, la interoperatividad entre sistemas de diversos fabricantes y sistemas operativos, como Linux, windows macintosh, firewalls y routers comerciales. IPSec integra confidencialidad, integridad y autentificación en un mismo marco interoperante por lo que esta será la opción escogida para la implementación de las VPN. Además, como trabaja a nivel IP, es transparente a la aplicación, ya que esta no necesita modificación alguna, y ni siquiera se entera de la existencia de criptografía intermedia, a diferencia de protocolos de nivel de transporte, como son los túneles sobre TCP (SSL, SSH).
3. IPSec
Ipsec es una tecnología que
protege los paquetes IP de la capa de red, así se forma una capa segura de un
nodo de la red a otro.
IPsec utiliza dos protocolos
para la protección de los paquetes IP: “Cabecera de Autenticación” (AH: Authentication
Header) y “Cargo de Seguridad Encapsulado” (ESP: Encapsulated Security
Payload). AH provee autenticación,
integridad y protección a la réplica, mientras que ESP provee además confidencialidad (mediante cifrado).
Una Asociación de Seguridad (SA: Security Association) es un enlace
seguro de IPsec definido por un único flujo unidireccional de datos desde un
único punto hasta otro. Consiste en el acuerdo de las dos partes comunicantes
en el método utilizado para la comunicación segura. Todo el flujo de tráfico
sobre un SA se trata del mismo modo. El tráfico puede ser entre dos hosts,
entre un host y una pasarela de seguridad (Security Gateway) o entre dos
pasarelas de seguridad.
Si el enlace es entre dos hosts,
la SA es de modo transporte. En este
modo de funcionamiento de SA, las cabeceras de seguridad se añaden entre la
cabecera de la capa de red IP y la cabecera de transporte (TCP o UDP),
garantizando la seguridad al paquete IP sin cabecera.
AH en modo transporte:
|
IP Header |
AH Header |
TCP Header |
Carga |
ESP en
modo transporte:
|
IP Header |
ESP Header |
TCP Header |
Carga |
ESP Trailer |
ESP Authen |
Si alguno de los extremos del
enlace es una pasarela de seguridad, se utiliza el modo túnel de SA. En este caso, las cabeceras de seguridad engloban
también a la cabecera IP original del paquete IP, teniendo que añadir una nueva
cabecera IP que cubre solamente el salto al otro extremo de la conexión segura.
AH en modo túnel:
|
New IP Header |
AH Header |
IP Header |
Carga |
![]()
ESP en modo túnel:
|
New IP Header |
ESP Header |
IP Header |
Carga |
ESP Trailer |
ESP Authen |
Cada paquete IP se asigna a una
SA mediante tres campos: Dirección IP del Destino, Índice del Parámetro de
Seguridad (SPI: Security Parameter Index) y Protocolo de Seguridad (AH o ESP).
Sin embargo, el protocolo no
estipula cómo se han de autentificar los pares ni cómo se intercambian las
claves de sesión. Estas tareas son gestionadas por el protocolo de intercambio
de claves de Internet IKE (Internet Key Exchange). IKE permite que dos puntos
extremos puedan establecer conexiones seguras, utilizando la infraestructura de
llaves precompartidas o llaves públicas (PKI), certificados digitales
administrados por una autoridad certificadora---un servicio externo o interno
que registra las llaves públicas. IKE permite también que una red privada
virtual (VPN) pueda ampliarse a cientos de puntos extremos, mediante el uso del
equivalente a una tarjeta de identificación digital que identifica cada punto
extremo.
IPSec y NAT
NAT (Network Ardes Traslation),
es un método de asignar direcciones IP dinámicamente, sobre todo en
circunstancias donde el número total de máquinas que necesitan acceso a
Internet sobrepasa el número de direcciones IP públicas disponibles.
Cualquier intento de realizar
traslación de direcciones (NAT) en paquetes IPSec, entre gateways IPSec creará
un conflicto, por otro parte lógico:
·
IPSec autentifica paquetes y comprueba que no han
sido alterados en su camino entre los dos gateways
·
NAT reescribe la cabecera del paquete (cambiar la
dirección/puerto IP fuente u origen) y los encamina.
·
IPSec falla si los paquetes comprobados han sido
reescritos en cualquier punto entre los dos gateways.
Para AH, que autentifica partes
de la cabecera del paquete incluyendo direcciones IP origen y destino, esto es
fatal. Si el NAT cambia alguno de estos campos, AH falla.
Para IKE y ESP no resulta tan
catastrófico, pero si es una complicación añadida.
NAT
en o detrás de los
gateways
Este
problema se puede solucionar si hacemos el NAT en el gateway o detrás del gateway IPSec:
Subred-----NAT-----IPSec-----Internet-----IPSec---xxx
o
Subred-----NAT/IPSec-----Internet-----IPSec---xxx

Con
cualquiera de estas configuraciones no existe el mencionado problema, puesto
que el cambio en la cabecera del paquete se produce después de haber verificado
la seguridad de los paquetes IP.
Certificados
de clave pública
Transmisión de claves públicas
En la
criptografía simétrica la transmisión de la clave es un problema importante ya
que si se descubre todo el sistema se rompe. La solución adoptada ha sido
enviarla cifrada con un sistema asimétrico. Pero, ¿cuál es el problema de la
transmisión de las claves públicas?
La clave
privada no se transmite nunca y, por lo tanto, es segura. El conocimiento de la
clave pública no pone en peligro la seguridad del sistema. Pero el problema
cuando se recibe una clave pública es ¿cómo saber que la identidad del
propietario de esta clave no es falsa? Si una persona se hace pasar por otra y
envía claves públicas a los receptores podrá realizar:
Este
problema es conocido como suplantación de personalidad. La solución no
es transmitir la clave pública por un canal secreto ya que así perdería sus
propiedades de pública. La solución son los certificados de clave pública.
En los
certificados de clave pública hay los siguientes datos:
Así la
firma de esta tercera persona asegura que la clave pública pertenece al nombre
del usuario. Toda la confianza se basa en la autenticidad de la firma y, por lo
tanto, de la clave pública de la tercera persona. Actualmente todas las claves
públicas se envían en certificados excepto las primeras de confianza que sirven
para firmarlos. Aceptar o rechazar una clave pública depende de la firma que la
avala en el certificado. Todos los programas navegadores y de correo actuales
están preparados para recibir certificados, comprobarlos y dar un mensaje al
usuario de auténtico o no.
Con los
certificados, el problema de la suplantación de personalidad se ha trasladado
de la recepción de claves públicas a la confianza en las claves de terceras
personas. Para resolver este problema el método más utilizados
son:
Autoridades de certificación (CA)
El
sistema de PGP sirve para grupos pequeños de usuarios donde siempre hay un
enlace entre ellos, aunque sea por una cadena de confianzas de muchas personas.
Pero tiene dos inconvenientes:
Para
solucionar estos problemas se han creado las Autoridades de Certificación
(CA). Son entidades públicas o privadas cuya función es ofrecer
confianza en los certificados que firman. Generan claves públicas y
certificados para usuarios bajo demanda, además de dar a conocer sus claves
públicas para las comprobaciones. Los usuarios se deben identificar
personalmente para pedir un certificado a una CA. Es un sistema parecido al
carnet de identidad, donde el estado, como entidad de confianza, genera un
documento que los bancos y las empresas consideran fiable. Para descentralizar
la gestión de CAs está previsto crear una estructura jerárquica a nivel
mundial. Las CAs locales son certificadas por otras de nivel superior hasta
llegar a la principal que es de confianza en todo el mundo. Así se consigue que
la confianza sea mundial, para la red Internet sin fronteras, y que la gestión
pueda ser local, para los procesos judiciales y facilitar el proceso de
identificación personal.
Las CA
de orden superior certifican las inferiores y se pueden anidar certificados
desde la CA principal hasta la clave del usuario. Esto permite comunicar de
manera segura dos personas dispersas por el mundo con la única condición de que
conozcan la clave pública de la CA principal que obtendrán de su CA local.
Actualmente
la CA más conocida es la empresa privada americana VeriSign, además de las
empresas de tarjetas de crédito Visa, Mastercard y American Express. En España
los CA más conocidos son FESTE y ACE que gestionan los certificados a través de
bancos, notarios o agentes de comercio. Muchas empresas crean sus propias CA
privadas para el sistema de correo interno.
Protocolo X.509
El protocolo X.509 es el sistema de certificados de clave pública más
utilizado. Su origen es el directorio X.500, inventado por la UIT para dar
servicio al correo electrónico X.400. Actualmente se utiliza en los protocolos
seguros y en los sistemas de correo Internet más conocidos, excepto el PGP.
Permite trabajar con CA y anidar certificados para crear estructuras
jerárquicas.El formato de los certificados X.509 tiene los siguientes campos con
sus respectivos contenidos:
FreeS/WAN
es una implementación libre
distribuida bajo licencia GPL[1]
del protocolo IPsec para sistemas operativos GNU/Linux[2]. IPsec proporciona
servicios de cifrado y autentificación en red a nivel IP, protegiendo de esta
forma todo el tráfico IP entre los
dos equipos que hayan establecido una sesión IPsec, en lugar de cifrar sólo el
tráfico de un determinado protocolo como es el caso con los servidores seguros
tipo SSH, HTTPS, etc. De esta forma se consigue un nivel de seguridad mucho
mayor entre los dos hosts que intervienen en la conversación.
El
protocolo IPsec (y, por lo tanto, FreeS/WAN) se puede utilizar en cualquier
equipo en una red IP, ya sea su papel el de cliente, servidor, router, etc. El
caso más común que nos podremos encontrar es el de un router de una red
corporativa que se conecta a través de Internet (una red insegura) utilizando
IPsec al router de la red corporativa de otra sede de la misma empresa, estableciendo
así una VPN (Virtual Private Network, Red
Privada Virtual) entre ambas sedes. FreeS/WAN es la solución perfecta en el
caso de que el router que realiza la conexión IPsec sea un PC con Linux.
Otro
caso común de uso de IPsec y/o FreeS/WAN es el del denominado “Road Warrior” o Guerrero de Carretera. Bajo este nombre
que nos recuerda a la película Mad Max se esconde el escenario en el que una
persona quiere conectar un único equipo (su equipo de sobremesa) a una red
corporativa desde fuera de esta. Sería el caso de un trabajador que quiere
conectar con su empresa desde casa, un representante en viaje de negocios que
necesita conectarse al servidor de BD desde la habitación de su hotel, etc.
FreeS/WAN también contempla este caso, y es capaz de operar tanto en modo
cliente (en el ordenador del trabajador remoto) como servidor (en el router de
entrada a la red corporativa) para dar conexión a los road warriors.
La
importancia de IPsec sobre otros tipos de VPNs radica en que ha sido
establecido como el estandard de encriptación IP de obligada adopción para
todas las implementaciones de la nueva versión del protocolo IP, IP versión 6
(Ipv6). FreeS/WAN provee hoy por hoy del protocolo IPsec a la implementación
IPv4 (la actual versión de IP) del núcleo de Linux, y ya se está trabajando en
la integración de FreeS/WAN en la pila IPv6 de Linux, por lo que con toda
probabilidad será la implementación oficial del estandard IPsec para Linux.
Como
ya se vió en el capítulo anterior, IPsec se compone de tres protocolos:
·
AH (Authentication Header, Encabezado de Autentificación), que
proporciona autentificación a nivel de paquetes.
·
ESP (Encapsulating Security
Payload, Encapsulación Segura de Datos),
que proporciona tanto autentificación como cifrado a una conexión.
·
IKE (Internet Key Exchange, Intercambio de Llaves por Internet), que
gestiona la configuración de los parámetros de la conexión, incluyendo el
intercambio de llaves criptográficas para el cifrado y autentificación.
FreeS/WAN
se compone de varias partes, que entre todas colaboran para implementar todos
los protocolos de IPsec:
·
KLIPS (Kernel IPsec, IPsec en el Núcleo), una serie de rutinas en el núcleo del sistema
operativo Linux que implementan los protocolos AH y ESP, y todas las
funcionalidades necesarias para manejar estos tipos de paquetes en la red.
·
Pluto (demonio
IKE), un servicio que se ejecuta ya fuera del kernel, en espacio de
usuario, que gestiona la totalidad del protocolo IKE.
·
Varios scripts y utilidades en espacio de usuario,
para configurar y gestionar IPsec.
Para
instalar FreeS/WAN en nuestro equipo deberemos disponer del código fuente del
núcleo (kernel) de Linux, así como
del de FreeS/WAN, para posteriormente compilarlo todo. Según la distribución de
Linux que usemos, puede que parte de (o todo) este trabajo nos lo podamos
ahorrar porque ya haya sido hecho por nosotros. Como veremos, utilizando Debian
GNU/Linux nos ahorraremos gran parte del trabajo.
El
código de la última versión de Linux se puede descargar de http://www.kernel.org,
y el de FreeS/WAN de http://www.freeswan.org.
Siguiendo las directrices del Linux Standard Base (LSB), descomprimiremos ambos
paquetes en /usr/src.
El
primer paso será parchear el kernel para añadir KLIPS, la parte de FreeS/WAN
que maneja los protocolos AH y ESP. Esto en una Debian con el paquete freeswan-kernel-patch instalado lo
haríamos siguiendo las instrucciones en /usr/doc/freeswan/README.Debian y
continuaríamos con la configuración normal del kernel (p.ej., make menuconfig). En cualquier otro
sistema iríamos a /usr/src/freeswan-x.xx y haríamos make menugo, tras lo que tendríamos que seleccionar todas las
opciones relevantes para FreeS/WAN (en “Networking Options”, abajo del todo):

Tras
esto, tendríamos que continuar con la configuración, compilación e instalación
del nuevo núcleo. Explicar este proceso queda fuera del alcance de este
trabajo, por lo que se remite al lector a la documentación disponible en el
proyecto LDP (Linux Documentation Project) y Proyecto Lucas[3].
Una
vez reiniciado el sistema, ya tenemos un núcleo capaz de “hablar” ESP y AH. Si
tenemos un sistema Debian instalando el paquete freeswan ya podemos pasar a configurar el sistema, ya que el
demonio Pluto (encargado de IKE) y el resto de utilidades son instaladas por
nosotros y se nos generará una clave criptográfica. En cualquier otro sistema
conviene leer la documentación y revisar que con los pasos anteriores todo se
haya instalado de forma adecuada en nuestro sistema.
Lo
primero que tendremos que hacer para configurar nuestra conexión IPsec es
generar un par de claves pública/privada para el cifrado y autentificación de
la conexión. Esto se realizaría mediante el siguiente comando:
eliza:~# ipsec newhostkey --output /etc/ipsec.secrets
getting 128 random bytes from /dev/random...
looking for a prime starting there (can take a
while)...
found it after 182 tries.
getting 128 random bytes from /dev/random...
looking for a prime starting there (can take a
while)...
found it after 149 tries.
swapping primes so p is the larger...
computing modulus...
computing lcm(p-1, q-1)...
computing d...
computing exp1, exp1, coeff...
output...
Esto
almacenará en el fichero /etc/ipsec.secrets toda la información criptográfica
sobre nuestras llaves. Este fichero tendrá este aspecto (algunas líneas se han
acortado por brevedad):
:
RSA {
# RSA 2048 bits eliza
Tue Sep 3 18:36:17 2002
# for signatures only, UNSAFE FOR ENCRYPTION
#pubkey=0sAQPDvNGTfcMBGkGtqF+nCVy3x79bh1moDOrm2emMS4mpUj5/GWrdO ...
#IN KEY
0x4200 4 1 AQPDvNGTfcMBGkGtqF+nCVy3x79bh1moDOrm2emMS4mp ...
#
(0x4200 = auth-only host-level, 4 = IPSec, 1 = RSA)
Modulus:
0xc3bcd1937dc3011a41ada85fa7095cb7c7bf5b8759a80ceae6d9 ...
PublicExponent: 0x03
#
everything after this point is secret
PrivateExponent:
0x04a9112e2da936e226229c63cd1eb2f82f6c2cd88e53 ...
Prime1: 0xfcf6cb1c85307abf8ca8a9fc07b566cdc733bb53c1e802662a626
...
Prime2:
0xc61633e3828b9be146d16559879a673af27680b926e3b72d2b15f ...
Exponent1:
0xa8a4876858cafc7fb31b1bfd5a78ef33da227ce2814556eec6 ...
Exponent2: 0x840ecd425707bd40d9e0ee3bafbc44d1f6f9ab2619ed24c8c7
...
Coefficient:
0xa65b1bc78bcc715d073d8588464e7335c99786d5415d06cc ...
}
# do not change the indenting of that "}"
Los
parámetros Modulus, PublicExponent, PrivateExponent, Prime 1 y 2, Exponent 1 y
2 y Coefficient son los datos a partir de los cuales se pueden calcular
nuestras llaves pública y privada RSA. En cualquier documentación sobre RSA
puede encontrar más información sobre el proceso. El parámetro pubkey (aparece
comentado) será nuestra clave pública, que habrá que intercambiar con los hosts
con los que nos queramos comunicar.
Tan
sólo nos queda configurar lo que será la conexión IPsec en sí. Esto se realiza
en el fichero /etc/ipsec.conf, que tiene este aspecto:
#
/etc/ipsec.conf - FreeS/WAN IPsec configuration file
# More elaborate and more varied sample
configurations can be found
# in FreeS/WAN's doc/examples file, and
in the HTML documentation.
# basic configuration
config setup
#
THIS SETTING MUST BE CORRECT or almost nothing will work;
#
%defaultroute is okay for most simple cases.
interfaces=%defaultroute
#
Debug-logging controls: "none"
for (almost) none, "all" for lots.
klipsdebug=none
plutodebug=none
#
Use auto= parameters in conn descriptions to control startup actions.
plutoload=%search
plutostart=%search
#
Close down old connection when new one using same ID shows up.
uniqueids=yes
# defaults for subsequent connection
descriptions
# (mostly to fix internal defaults
which, in retrospect, were badly chosen)
conn %default
keyingtries=0
disablearrivalcheck=no
authby=rsasig
leftrsasigkey=%dns
rightrsasigkey=%dns
# connection description for
(experimental!) opportunistic encryption
# (requires KEY record in your DNS
reverse map; see doc/opportunism.howto)
conn me-to-anyone
left=%defaultroute
right=%opportunistic
keylife=1h
rekey=no
#
uncomment this next line to enable it
#auto=route
# sample VPN connection
conn sample
#
Left security gateway, subnet behind it, next hop toward right.
left=10.0.0.1
leftsubnet=172.16.0.0/24
leftnexthop=10.22.33.44
#
Right security gateway, subnet behind it, next hop toward left.
right=10.12.12.1
rightsubnet=192.168.0.0/24
rightnexthop=10.101.102.103
#
To authorize this connection, but not actually start it, at startup,
#
uncomment this.
#auto=add
Este es
el archivo de configuración de ejemplo que viene con la distribución de
FreeS/WAN, y contiene valores generales razonables y ejemplos de
configuraciones. El campo “config setup” contiene la configuración global,
aplicable a todas las conexiones definidas, mientras que cada campo “conn ...”
define una conexión a parte.
Veamos
en detalle la conexión “sample”:
·
left y right son los dos hosts que intervienen
en la conexión. Da igual a quién llamemos left
y a quién right, pero estos nombres
se deben mantener a ambos lados de la conexión.
·
leftsubnet
y rightsubnet son las
direcciónes de red (en formato direccion/bits_máscara) de las subredes que hay
tras cada uno de los hosts. Son las redes que interconectaremos de forma segura
a través de una VPN IPsec.
·
leftnexthop
y rightnexthop son las
direcciones de los siguientes equipos en dirección a Internet de cada uno de
los hosts, es decir, sus gateways.
·
auto (aparece
comentado) indica si la conexión se debe establecer de forma automática cuando
se arranque el sistema.
El
siguiente esquema clarifica un poco el significado de left, leftsubnet,
leftnexthop y sus equivalentes con right:
Red A-----Host A----Router
A---INTERNET---Router B----Host B---Red B
leftsubnet left
leftnetxthop
rightnexthop right rightsubnet
Existen
más parámetros para definir las conexiones. Le remitimos a la documentación de
FreeS/WAN o al siguiente capítulo, donde analizaremos en detalle un caso
particular de conexión entre dos subredes.
En
este apartado vamos a tratar un par de asuntos relacionados con FreeS/WAN: la
posibilidad de usar certificados X.509 y la configuración de un firewall para
su correcto funcionamiento con IPsec.
FreeS/WAN
no soporta de serie los certificados X.509 de los que se ha hablado en el
capítulo anterior, pero existe un parche para poder utilizarlos y así poder
conectarse a otros equipos que utilicen IPsec con certificados X.509 y OpenPGP.
El
parche se puede descargar de la dirección http://www.strongsec.com/freeswan/ y
es de fácil instalación: tan sólo habrá que parchear el código de FreeS/WAN con
el fichero freeswan.diff antes de
compilar e instalarlo todo. Este parche únicamente afecta a las utilidades de
usuario, no al código del kernel, ya que como se ha comentado anteriormente
quien se encarga del intercambio y gestión de llaves es el demonio Pluto. En
este caso, se le está añadiendo a Pluto la capacidad de trabajar con
certificados X.509.
Una
vez aplicado el parche e instalada la nueva versión parcheada de FreeS/WAN,
dispondremos de una serie de nuevos comandos y parámetros para poder trabjar
con certificados X.509 de forma sencilla, similar a cómo generábamos y
manejábamos las llaves RSA en el apartado anterior.
Los
paquetes de FreeS/WAN de Debian (freeswan
y freeswan-kernel-patch) ya
incorporan este parche, y por defecto generan un certificado X.509 para nuestro
equipo. También incluyen parches con protocolos de cifrado adicionales, entre otros
para utilizar el algoritmo AES (Advanced Encrytion Standard), futuro sustituto
del DES.
Para
más información sobre el asunto, le remitimos a la documentación del parche.
Una vez
que tenemos instalado FreeS/WAN y conectadas dos redes a través del protocolo
seguro IPsec, no podemos olvidar otros importantes aspectos de la seguridad de
redes y sistemas: la máquina haciendo de router FreeS/WAN está conectada a
Internet, expuesta a ataques de todo tipo, que podrían poner en peligro tanto
ese propio equipo como a toda la red corporativa que tiene detrás. Es por esto
que resulta áltamente recomendable instalar un firewall en el propio equipo. En
versiones actuales del kernel Linux (2.4.x) esto se realiza activando netfilter
en el núcleo y mediante la utilidad iptables.
Analicemos
qué tráfico queremos que atraviese el firewall:
·
Tráfico ESP (protocolo IP 50)
·
Tráfico AH (protocolo IP 51)
·
Tráfico IKE (UDP, puerto 500)
·
Cualquier otro servicio que se ofrezca en esa misma
máquina (p.ej., si hay un servidor HTTP) o si ese mismo equipo da salida a
Internet a la red mediante NAT/masquerading.
Por
ejemplo, el siguiente archivo de configuración para iptables que puede ser
cargado en el sistema con la utilidad iptables-restore, permitiría el uso de
IPsec (ESP, AH e IKE), de un servidor HTTP (puerto TCP 80 abierto) y HTTPS
(puerto TCP 443), y que además de acceso al exterior a toda la red mediante IP
masquerading. El resto del tráfico entrante es bloqueado, salvo el relacionado
con una conexión ya autorizada.
En
el ejemplo, eth0 es la interfaz pública (en internet) y eth1 la privada:
# Generated by
iptables-save v1.2.7a on Mon Sep 2
20:14:37 2002
*mangle
:PREROUTING ACCEPT [3920567:1974664178]
:INPUT ACCEPT [3833069:1919800972]
:FORWARD ACCEPT [87408:54853117]
:OUTPUT ACCEPT [4907150:3825732377]
:POSTROUTING ACCEPT [4996343:3880999657]
COMMIT
# Completed on Mon Sep 2 20:14:37 2002
# Generated by iptables-save v1.2.7a on
Mon Sep 2 20:14:37 2002
*filter
:INPUT ACCEPT [3833069:1919800972]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [4907106:3825728925]
:FIREWALL - [0:0]
-A INPUT -d 213.96.206.148 -i eth0 -j
FIREWALL
-A FORWARD -i eth0 -o eth1 -m state
--state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -p esp -j ACCEPT
-A FORWARD -p ah -j ACCEPT
-A FIREWALL -m state --state
RELATED,ESTABLISHED -j ACCEPT
-A FIREWALL -p tcp -m tcp --dport 80 -j
ACCEPT
-A FIREWALL -p tcp -m tcp --dport 443 -j
ACCEPT
-A FIREWALL -p udp -m udp --dport 500 -j
ACCEPT
-A FIREWALL -p esp -j ACCEPT
-A FIREWALL -p ah -j ACCEPT
-A FIREWALL -j DROP
COMMIT
# Completed on Mon Sep 2 20:14:38 2002
# Generated by iptables-save v1.2.7a on
Mon Sep 2 20:14:38 2002
*nat
:PREROUTING ACCEPT [4675:449083]
:POSTROUTING ACCEPT [5097:427286]
:OUTPUT ACCEPT [238616:14636581]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Mon Sep 2 20:14:38 2002
Nuestro
trabajo se ha centrado en la implementación de VPNs para conexión entre
delegaciones de una gran empresa. Para ello se han realizado pruebas de
interconexión entre dos servidores de VPNs con Linux, concretamente con
FreeS/WAN.
También se
ha contemplado la posibilidad de interconexión entre Linux y Windows 2000/XP
utilizando certificados X.509.
Se ha
montado una red para realizar las pruebas, que consta de:
·
Dos servidores de VPNs, uno en cada extremo de la
conexión.
·
Dos subredes independientes, una tras cada uno de
los servidores de VPN, que tras el correcto establecimiento de la conexión mediante
IPSec, quedarán “unidas” de forma segura.
·
Un equipo intermedio programado como router, que
une los dos servidores de IPSec. La función de este equipo es la de simular de
alguna forma toda la gran maraña de routers y redes (Internet) que debe atravesar
nuestra VPN para llegar de un equipo pa otro. Además, en este equipo podremos
instalar algún sniffer para analizar el tráfico de red.
El esquema
de la red tendría este aspecto:

Todos los
equipos utilizados son PCs clónicos de gama media, con procesadores Pentium III
o Celeron, velocidades de 1 a 1.5Ghz, y 128 ó 256 Mb de RAM.
El equipo
router central y los dos servidores de VPNs necesitan tener dos tarjetas de red
para poder interconectar los dos extremos de las redes.
En los dos
servidores de VPN se ha instalado Debian Woody, una versión actual del kernel
de Linux (2.4.19), y la versión de FreeS/WAN incluida con la Debian que, como
mencionamos en el capítulo anterior, incluye los parches para soporte de
certificados X.509.
El servidor
router central también tiene Debian Woody, esta vez con una instalación mucho
más sencilla ya que no necesita IPSec, tan sólo ser configurado para que haga
forwarding entre sus dos interfaces de red (ip_forward=yes
en /etc/network/options).
Tras
instalar el sistema en los dos servidores Linux, instalamos los fuentes del
kernel y los paquetes con el soporte para FreeS/WAN. Parcheamos el kernel
siguiendo las instrucciones en /usr/doc/freeswan/README.Debian y recompilamos,
añadiendo soporte para IPSec y varios algoritmos de cifrado. Una vez compilado
el kernel, reiniciamos la máquina para utilizarlo.
Ya con el
nuevo kernel, generamos un par de claves RSA en cada equipo y configuramos el
fichero /etc/ipsec.conf tal y como se vió en el capítulo anterior. Una vez
hecho esto en ambas máquinas, en teoría ya están preparadas para
interconectarse entre sí de forma segura. Reiniciando IPSec (/etc/init.d/ipsec
restart) y activando alguna conexión que hayamos definido (ipsec auto –up <nombre-conexión>) ya tendremos una sesión IP
cifrada entre los dos equipos.
Vamos a
realizar una pequeña traza del protocolo IPSec para comprender mejor su
funcionamiento. Para esto hemos instalado un sniffer (tcpdump) en el equipo que
hace de router.
En primer
lugar, y antes de establecer la conexión segura, vamos a realizar un ping entre
las dos máquinas para ver un ejemplo de tráfico “normal” (sin cifrar) y para
habituarnos al formato de salida del tcpdump:
11:01:58.282791 right > left: icmp: echo request
(DF)
11:01:58.282973 left > right: icmp: echo reply
11:01:59.281624 right > left: icmp: echo request
(DF)
11:01:59.281748 left > right: icmp: echo reply
11:02:00.281526 right > left: icmp: echo request
(DF)
11:02:00.281617 left > right: icmp: echo reply
Podemos ver los paquetes de petición eco ICMP de
ida, y los de respuesta al eco de vuelta.
Con la
opción -X de tcpdump podemos ver el contenido de los paquetes, y con la opción
-p de ping, indicar dos bytes de la carga del ping que se repetirán en todo el
contenido del paquete enviado. De esta forma podemos ver que, efectivamente, la
información se envía “en claro”. P.ej., con ping
-p ae IP_destino obtenemos esto, donde en el volcado hexadecimal podemos
ver que la información no va cifrada:
11:02:13.714968 right > left: icmp: echo request
(DF)
0x0000 4500
0054 0000 4000 4001 6ff5 c0a8 0002 E..T..@.@.o.....
0x0010 0a00 000a 0800 4dc4 cf07 0000 3d7c e39d ......M.....=|..
0x0020 0006 59b3 aeae aeae aeae aeae aeae aeae ..Y.............
0x0030 aeae aeae aeae aeae aeae aeae aeae aeae ................
0x0040 aeae aeae aeae aeae aeae aeae aeae aeae ................
0x0050
aeae ..
11:02:13.715121 left > right: icmp: echo reply
0x0000 4500 0054 3bde 0000 3f01 7517 0a00 000a E..T;...?.u.....
0x0010 c0a8 0002 0000 55c4 cf07 0000 3d7c e39d ......U.....=|..
0x0020 0006 59b3 aeae aeae aeae aeae aeae aeae ..Y.............
0x0030 aeae aeae aeae aeae aeae aeae aeae aeae ................
0x0040 aeae aeae aeae aeae aeae aeae aeae aeae ................
0x0050
aeae ..
11:02:14.710547 right > left: icmp: echo request
(DF)
0x0000 4500
0054 0000 4000 4001 6ff5 c0a8 0002 E..T..@.@.o.....
0x0010 0a00 000a 0800 5da7 cf07 0100 3d7c e39e ......].....=|..
0x0020 0006 48cf aeae aeae aeae aeae aeae aeae ..H.............
0x0030 aeae aeae aeae aeae aeae aeae aeae aeae ................
0x0040 aeae aeae aeae aeae aeae aeae aeae aeae ................
0x0050
aeae ..
11:02:14.710668 left > right: icmp: echo reply
0x0000 4500 0054 3bdf 0000 3f01 7516 0a00 000a E..T;...?.u.....
0x0010 c0a8 0002 0000 65a7 cf07 0100 3d7c e39e ......e.....=|..
0x0020 0006 48cf aeae aeae aeae aeae aeae aeae ..H.............
0x0030 aeae aeae aeae aeae aeae aeae aeae aeae ................
0x0040 aeae aeae aeae aeae aeae aeae aeae aeae ................
0x0050
aeae ..
11:02:15.710449 right > left: icmp: echo request
(DF)
0x0000 4500
0054 0000 4000 4001 6ff5 c0a8 0002 E..T..@.@.o.....
0x0010 0a00 000a 0800 5cbd cf07 0200 3d7c e39f ......\.....=|..
0x0020 0006 48b8 aeae aeae aeae aeae aeae aeae ..H.............
0x0030 aeae aeae aeae aeae aeae aeae aeae aeae ................
0x0040 aeae aeae aeae aeae aeae aeae aeae aeae ................
0x0050
aeae ..
11:02:15.710539 left > right: icmp: echo reply
0x0000 4500
0054 3be0 0000 3f01 7515 0a00 000a E..T;...?.u.....
0x0010 c0a8 0002 0000 64bd cf07 0200 3d7c e39f ......d.....=|..
0x0020 0006 48b8 aeae aeae aeae aeae aeae aeae ..H.............
0x0030 aeae aeae aeae aeae aeae aeae aeae aeae ................
0x0040 aeae aeae aeae aeae aeae aeae aeae aeae ................
0x0050 aeae
..
Ejecutando
ipsec look obtenemos información sobre el estado de IPSec en cualquier momento.
Si lo ejecutamos ahora que no hay establecida ninguna conexión, esta es la
información que nos ofrece:
video:/usr/lib/ipsec# ipsec look
video Mon Sep 9
18:20:59 CEST 2002
ipsec0->eth1 mtu=16260(1500)->1500
Destination
Gateway Genmask Flags
MSS Window irtt Iface
0.0.0.0
10.0.0.1 0.0.0.0 UG 40 0 0 eth1
10.0.0.0
0.0.0.0 255.255.255.0 U
40 0 0 eth1
10.0.0.0 0.0.0.0 255.255.255.0 U
40 0 0 ipsec0
Si hubiera
alguna sesión establecida, nos lo diría y también indicaría parámetros de las
llaves.
Ahora
iniciamos IPSec con ipsec auto –up
<nombre-conexión>. Esto negociará los parámetros de la conexión y se
intercambian las claves:
11:04:20.424371 right.500 > left.500: isakmp: phase
1 I ident: [|sa] (DF)
11:04:20.425131 left.500 > right.500: isakmp: phase
1 R ident: [|sa] (DF)
11:04:20.437795 right.500 > left.500: isakmp: phase
1 I ident: [|ke] (DF)
11:04:20.457871 left.500 > right.500: isakmp: phase
1 R ident: [|ke] (DF)
11:04:20.510679 right.500 > left.500: isakmp: phase
1 I ident[E]: [|id] (DF)
11:04:20.547650 left.500 > right.500: isakmp: phase
1 R ident[E]: [|id] (DF)
11:04:20.573193 right.500 > left.500: isakmp: phase
2/others I oakley-quick[E]: [|hash] (DF)
11:04:20.594471 left.500 > right.500: isakmp: phase
2/others R oakley-quick[E]: [|hash] (DF)
11:04:20.654567 right.500 > left.500: isakmp: phase
2/others I oakley-quick[E]: [|hash] (DF)
Como se puede ver en la traza, se está utilizando
el puerto 500 UDP, tal y como ya habíamos visto.
En este
momento ya está establecida la conexión segura IPSec. Podemos comprobarlo de
nuevo haciendo un ping con la opción -p
ae para asignar un contenido conocido al paquete. En este caso, no podremos
descifrar su contenido:
11:18:59.173226 right > left:
ESP(spi=0x43d2c293,seq=0x16)
0x0000 4500
0088 9bc0 0000 4032 13d0 c0a8 0002 E.......@2......
0x0010 0a00
000a 43d2 c293 0000 0016 cfb6 b8ea ....C...........
0x0020 4874
3d2a 5d1b df17 e54c 2ea0 a9dc ea8c Ht=*]....L......
0x0030 d492
7fae 0cc2 8a11 5bcc b733 fa88 dee1 ........[..3....
0x0040 c415 c2a5 7fed fc80 4f73 a685 1210 11a7 ........Os......
0x0050
8511 ..
11:18:59.173577 left > right:
ESP(spi=0x00486fe1,seq=0x16)
0x0000 4500
0088 564b 0000 3f32 5a45 0a00 000a E...VK..?2ZE....
0x0010 c0a8
0002 0048 6fe1 0000 0016 2480 a092 .....Ho.....$...
0x0020 42ad
c6f7 0765 15f1 d66a 5d3b 38cc b442 B....e...j];8..B
0x0030 217d
bfae 575d bb1d 44a4 6915 af6c 2af1 !}..W]..D.i..l*.
0x0040 1677 4292 aaaa 88e7 0d34 4888 b3c8 5f95 .wB......4H..._.
0x0050
ef4e .N
11:19:00.170389 right > left:
ESP(spi=0x43d2c293,seq=0x17)
0x0000 4500
0088 9bc1 0000 4032 13cf c0a8 0002 E.......@2......
0x0010 0a00 000a 43d2 c293 0000 0017 1971 f245 ....C........q.E
0x0020 2af9 192f f824 57ee e147 cf85 0243 da22 *../.$W..G...C."
0x0030 8ac1
bce5 5bc6 ed57 9b47 d528 6640 a913 ....[..W.G.(f@..
0x0040 609f
3b9d f6ef d644 7b32 398c 053d fd6c `.;....D{29..=.l
0x0050
ad06 ..
11:19:00.170573 left > right:
ESP(spi=0x00486fe1,seq=0x17)
0x0000 4500 0088 564d 0000 3f32 5a43 0a00 000a E...VM..?2ZC....
0x0010 c0a8 0002 0048 6fe1 0000 0017 020f c08e .....Ho.........
0x0020 b4ee aca3 3048 d0a9 11c4 45f4 efdb 9315 ....0H....E.....
0x0030 c717 f27e 2ffe 4b3e 128a 7863 2ec2 4203 ...~/.K>..xc..B.
0x0040 7df8 f59c 4649 aae9 536b 5dc6 95b9 8614 }...FI..Sk].....
0x0050
e7e1 ..
11:19:01.170291 right > left:
ESP(spi=0x43d2c293,seq=0x18)
0x0000 4500
0088 9bc2 0000 4032 13ce c0a8 0002 E.......@2......
0x0010 0a00 000a 43d2 c293 0000 0018 3a74 efe9 ....C.......:t..
0x0020 774a
1992 c2ce 3fc6 d739 5bc8 2b77 4b9b wJ....?..9[.+wK.
0x0030 571c
5708 b8c2 dd9d 4e25 476f 45a1 5dbd W.W.....N%GoE.].
0x0040 8b7c
e29c 2136 04ad 40c7 3270 b390 5be5 .|..!6..@.2p..[.
0x0050
f704 ..
11:19:01.170446 left > right:
ESP(spi=0x00486fe1,seq=0x18)
0x0000 4500 0088 564f 0000 3f32 5a41 0a00 000a E...VO..?2ZA....
0x0010 c0a8 0002 0048 6fe1 0000 0018 f78e 3fc6 .....Ho.......?.
0x0020 7fde f4b4 c345 7104 6a97 24dd e025 725c .....Eq.j.$..%r\
0x0030 3204 c46e 629e 8a3b 47af 8c8b 9392 4bcc 2..nb..;G.....K.
0x0040 d989 2413 8d55 c156 3ff4 6d55 f4b7 5da7 ..$..U.V?.mU..].
0x0050
b809 ..
11:19:02.170227 right > left:
ESP(spi=0x43d2c293,seq=0x19)
0x0000 4500
0088 9bc3 0000 4032 13cd c0a8 0002 E.......@2......
0x0010 0a00 000a 43d2 c293 0000 0019 fcd2 cd76 ....C..........v
0x0020 fa02 de90 4479 bc5e 17d2 f71a 1524 e736 ....Dy.^.....$.6
0x0030 0d77
cc63 4f25 20bb b661 a284 fb24 8ce6 .w.cO%...a...$..
0x0040 cffc 1e57 a475 abbd 5b70 69ca c5a9 ccdf ...W.u..[pi.....
0x0050
0261 .a
11:19:02.170425 left > right:
ESP(spi=0x00486fe1,seq=0x19)
0x0000 4500 0088 5651 0000 3f32 5a3f 0a00 000a E...VQ..?2Z?....
0x0010 c0a8 0002 0048 6fe1 0000 0019 72e6 dfcc .....Ho.....r...
0x0020 661f
1810 1bcd f450 a528 b660 cb96 688d f......P.(.`..h.
0x0030 917a
7d57 b7c3 696a b041 fe21 7061 0687 .z}W..ij.A.!pa..
0x0040 eb2a
7b36 7083 b466 d8c7 c32b 76e2 9ab6 .*{6p..f...+v...
0x0050 ff2a .*
Además, podemos ver que el
propio tcpdump nos indica que se trata de paquetes ESP, el protocolo IP de
conexión cifrada/autentificada de IPSec.
Ejecutando
ahora ipsec look, obtenemos toda esta información sobre la sesión IPSec entre
las dos máquinas:
video:~# ipsec look
video Mon Sep 9
18:27:27 CEST 2002
10.0.0.10/32
-> 192.168.0.2/32 =>
tun0x1002@192.168.0.2 esp0x486fe1@192.168.0.2
(50)
ipsec0->eth1 mtu=16260(1443)->1500
esp0x43d2c293@10.0.0.10 ESP_3DES_HMAC_MD5: dir=in src=192.168.0.2 iv_bits=64bits
iv=0xa48305b1f2286e71 ooowin=64 seq=25 bit=0x1ffffff alen=128 aklen=128
eklen=192
life(c,s,h)=bytes(2600,0,0)addtime(4536,0,0)usetime(4548,0,0)packets(25,0,0)
idle=175
esp0x486fe1@192.168.0.2 ESP_3DES_HMAC_MD5: dir=out
src=10.0.0.10 iv_bits=64bits iv=0xbc06ad4d8722c949 ooowin=64 seq=25 alen=128
aklen=128 eklen=192
life(c,s,h)=bytes(3400,0,0)addtime(4536,0,0)usetime(4548,0,0)packets(25,0,0)
idle=175
tun0x1001@10.0.0.10 IPIP: dir=in src=192.168.0.2 policy=192.168.0.2/32->10.0.0.10/32
flags=0x8<>
life(c,s,h)=bytes(2600,0,0)addtime(4536,0,0)usetime(4548,0,0)packets(25,0,0)
idle=175
tun0x1002@192.168.0.2 IPIP: dir=out src=10.0.0.10
life(c,s,h)=bytes(2600,0,0)addtime(4536,0,0)usetime(4548,0,0)packets(25,0,0)
idle=175
Destination
Gateway Genmask Flags
MSS Window irtt Iface
0.0.0.0
10.0.0.1 0.0.0.0 UG 40 0 0 eth1
10.0.0.0
0.0.0.0 255.255.255.0 U
40 0 0 eth1
10.0.0.0 0.0.0.0 255.255.255.0 U
40 0 0 ipsec0
192.168.0.2 10.0.0.1 255.255.255.255 UGH 40 0 0 ipsec0
En estos
momentos podemos estar seguros de disponer de una sesión cifrada entre las dos
subredes.
La
implementación en windows se ha realizado para el sistema operativo windows
2000 profesional, aunque ésta es igualmente válida para el windows XP
profesional. Dado que este tipo de sistemas se van a utilizar básicamente en el
mundo empresarial se ha elegido estas versiones del sistema de Microsoft en
detrimento de otras más destinadas al mundo doméstico como el windows 98 y el
Millenium.
Nuestro
trabajo se ha basado en la utilidad de Marcus Müller que se puede encontrar en http://vpn.ebootis.de.
Esta utilidad está diseñada y optimizada para la interconexión entre windows
2000 y el FreeS/WAN utilizado en nuestro servidor Linux.
Lo primero
que hay que hacer es instalar FreeS/WAN en el servidor, según vimos en el
apartado específico. Es muy importante realizar la instalación del parche X.509
para permitir al FreeS/WAN trabajar con el cliente windows 2000.
Por otra
parte, en lo referente al windows 2000 y con el fin de que éste pueda negociar
con el Linux, debe “fortificarse”, ya que windows solo soporta DES simple como
algoritmo de cifrado. Este algoritmo se considera “poco seguro” por los
desarrolladores de FreeS/WAN y de muchos otros paquetes Linux. Por tanto, el
algoritmo de cifrado común debe ser 3DES. Para “fortificar” windows 2000 es
necesario instalar el “High Encryption Pack”, que puede encontrarse en la
dirección http://www.microsoft.com/WINDOWS2000/downloads/recommended/encrytion/default.asp
Los pasos a
realizar en la máquina windows son los siguientes:
·
El primer paso a realizar conseguir un certificado
exportándolo desde la máquina Linux. Este fichero debe ser copiado a la máquina
windows en una sesión segura (con alguna utilidad tipo “scp” o mediante un
disquete). ¡ NO debe usarse FTP ¡
·
Descomprimir la utilidad de Marcus Müller ipsec.exe
en algún directorio de la máquina windows (por ejemplo, C:\ipsec)
·
Crear una asociación IPSEC + Certificado MMC. Para
ello hay que seguir los siguientes pasos:
·
Start/Run/MMC
·
File (or
Console) – Add/Remove Snap-in
·
Click on
“Add”
·
Click on
“Certificates” y “add”
·
Seleccionar “cuenta del equipo” y “next”
·
Seleccionar “local computer” y “finish”
·
Click on
“IP Security Policy Management” y “add”
·
Seleccionar “local computer” y “finish”
·
Click “Cerrar” y “OK”
·
Añadir el certificado. Para ello hay que seguir los
siguientes pasos:
·
Colocar el puntero del ratón sobre “certificados
(ordenador local)”
·
Pinchar con el botón derecho en “Personal” y luego
en las opciones “todas las tareas” y en “Importar”
·
Pinchar en “Siguiente”
·
Escribir la ruta del fichero .p12 y pinchar en
“siguiente”
·
Escribir la clave secreta y pinchar en “siguiente”
·
Seleccionar “Selección automática del almacén de
certificados según el tipo de certificado” y pinchar en “siguiente”
·
Pinchar en “finalizar” y decir “si” a cualquier ventana emergente de windows
·
Salir de la consola MMC y grabarla como un fichero.
Una vez se han dado todos los pasos anteriores, lo único que resta por hacer es lanzar el servicio IPSec mediante la ejecución del comando ipsec.exe del paquete de Marcus Müller. La salida del comando es la que podemos ver en la siguiente figura:

Ahora, al hacer un ping al
gateway de la máquina, dirá “Negociando la seguridad IP” unas cuantas veces,
mientras se realiza el intercambio de claves. Una vez inicializada la conexión
el ping responderá, viajando ya a través de la conexión segura.
Índice
1.
Introducción........................................................................3
2.
Redes Privadas
Virtuales......................................................7
3.
IPSec..................................................................................10
4.
Implementación de VPN’s con IPSec y
FreeS/WAN.............14
5.
Trabajo
desarrollado............................................................21
[1]Para más información sobre el Software Libre y sus distintas licencias, consulte la web de la Free Software Foundation en http://www.fsf.org/home.es.html.
[2]Puede obtener información sobre el Sistema Operativo libre GNU/Linux en http://www.linux.com, http://www.linux.org, o realizando una búsqueda en http://www.google.com.