2.4 Protocolo de seguridad

Protocolo de seguridad

Un protocolo de seguridad define las reglas que gobiernan estas comunicaciones, diseñadas para que el sistema pueda soportar ataques de carácter malicioso.

Protegerse contra todos los ataques posibles es generalmente muy costoso, por lo cual los protocolos son diseñados bajo ciertas premisas con respecto a los riesgos a los cuales el sistema está expuesto. La evaluación de un protocolo por lo tanto envuelve dos preguntas básicas: ¿Es el modelo de riesgo realista? ¿El protocolo puede controlar ese nivel de riesgo?

Un protocolo es una serie de pasos, que involucra a dos o más principales, diseñado para realizar una tarea particular.

1. Todos los principales deben conocer los pasos del protocolo de antemano.

2. Todos deben estar de acuerdo en seguir el protocolo.

3. El protocolo no admite ambigüedades.

4. El protocolo debe ser completo – define qué hacer en cualquier circunstancia posible.

5. No debe ser posible hacer más (o aprender más) que lo que el protocolo define.

Protegerse contra todos los ataques posibles es generalmente muy costoso, por lo cual los protocolos son diseñados bajo ciertas premisas con respecto a los riesgos a los cuales el sistema está expuesto.

Existen varios protocolos posibles. Las distintas compañías que instalan y administran este tipo de redes eligen unos u otros protocolos. En todos los casos se cran túneles entre origen y destino. Dentro de estos túneles viaja la información, bien por una conexión normal (en este caso no se encriptan los datos) o bien por una conexión VPN. El protocolo IP Sec es uno de los más empleados. Este se basa en GRE que es un protocolo de tunneling. Este protocolo también se utiliza de forma conjunta con otros protocolos como PPTP.

Generic Routing Encapsulation (GRE 47)

Point-to-Point Tunneling Protocol (PPTP)

IP Sec

Protocolo de tunelado nivel 2 (L2TP)

Secure shell (SSH)

Generic Routing Encapsulation (GRE 47)

Es el protocolo de Encapsulación de Enrutamiento Genérico. Se emplea en combinación con otros protocolos de túnel para crear redes virtuales privadas.

El GRE está documentado en el RFC 1701 y el RFC 1702. Fue diseñado para proporcionar mecanismos de propósito general, ligeros y simples, para encapsular datos sobre redes IP. El GRE es un protocolo cliente de IP que usa el protocolo IP 47.  Este protocolo es normalmente usado con VPN de Microsoft entre servidores con acceso remoto (RRAS) configurados para el enrutamiento entre redes de área local.

Esquema: GRE se encarga del encapsulamiento de los datos para enviarlos por un túnel, pero él no crea no los túneles, de eso de encarga el protocolo PPTP u otro que estemos empleando.

El proceso de encapsulamiento tienen los siguientes pasos:

• El paquete IP con los datos se transmite desde el Ecliente al servidor E-RRAS.
• Se le añade la cabecera del PPP y se cifra todo junto obteniendo un ‘fragmento PPP’.
• Los datos cifrados se colocan dentro de un paquete GRE con su correspondiente cabecera.
• Se envía el paquete GRE del servidor E-RRAS al servidor R-RRAS a través de Internet.
• Este envía se realiza por una conexión VPN creada anteriormente.
• El servidor R-RRAS elimina los encabezados GRE, descifra, elimina el encabezado PPP y transmite los datos (paquete IP) al Rcliente.
• Los datos cifrados se colocan dentro de un paquete GRE con su correspondiente cabecera.

Esquema: Formato de un paquete GRE

Point-to-Point Tunneling Protocol

El Protocolo de Túnel Punto a Punto (PPTP) encapsula los paquetes (frames) del Protocolo Punto a Punto (Point-to-Point Protocol, PPP) con datagramas IP para transmitirlos por una red IP como Internet o una intranet privada.

El PPTP utiliza una conexión TCP conocida como la conexión de control de PPTP para crear, mantener y terminar el túnel, y una versión modificada de GRE, para encapsular los paquetes (frames) PPP como datos para el túnel. Las cargas de los paquetes encapsulados pueden estar encriptadas o comprimidas o ambas cosas.

El PPTP supone la disponibilidad de una red IP entre un cliente PPTP (un cliente de túnel que utiliza el protocolo PPTP) y un servidor PPTP (un servidor de túnel que utiliza el protocolo PPTP). El cliente PPTP podría estar ya conectado a una red IP por la que puede tener acceso al servidor PPTP, o podría tener que llamar telefónicamente a un servidor de acceso de red (Network Access Server, NAS) para establecer la conectividad IP como en el caso de los usuarios de accesos telefónicos para Internet.

La autentificación que ocurre durante la creación de una conexión VPN con PPTP utiliza los mismos mecanismos de autentificación que las conexiones PPP, tales como el Protocolo de Autentificación Extendible (Extensible Authentication Protocol, EAP), el Protocolo de Autentificación con Reto/Negociación de Microsoft (Microsoft Challenge-Handshake Authentication Protocol, MS-CHAP), el CHAP, el Protocolo de Autentificación de Claves Shiva (Shiva Password Authentication Protocol, SPAP) y el Protocolo de Autentificación de Claves (Password Authentication Protocol, PAP). El PPTP hereda la encriptación, la compresión o ambas de las cargas PPP del PPP. Para servidores PPTP sobre Internet, el servidor PPTP es un servidor VPN con PPTP con una interfase con Internet y una segunda interfase con la intranet.

IP Sec

IP Sec es un grupo de extesiones de la familia del protocolo IP pensado para proveer servicios de seguridad a nivel de red, de un modo transparente a las aplicaciones superiores.

IP Sec está ya explicado en su trabajo correspondiente: I Pv 6 e IP Sec

Protocolo de tunelado de nivel 2 (L2TP)

Es un componente de creación importante para las VPN de acceso. Es una extensión del protocolo Punto a Punto, fundamental para la creación de VPNs. L2TP combina las mejores funciones de los otros dos protocolos tunneling. Layer 2 Forwarding (L2F) de Cisco Systems y Point-to-Point Tunneling (PPTP) de Microsoft. L2TP es un estándar emergente, que se encuentra actualmente en codesarrollo y que cuenta con el respaldo de Cisco Systems, Microsoft, Ascend, 3Com y otros líderes en la industria de la conectividad.

Add a comment May 29, 2011