Tema11.pdf

Seguridad TEMA 11: MECANISMOS DE PROTECCIÓN Introducción Para proteger las redes de comunicaciones, la criptografía es la herramienta que nos permite evitar que alguien intercepte, manipule o falsifique los datos transmitidos. La finalidad básica de la criptografía es el envío de información secr...

Seguridad TEMA 11: MECANISMOS DE PROTECCIÓN Introducción Para proteger las redes de comunicaciones, la criptografía es la herramienta que nos permite evitar que alguien intercepte, manipule o falsifique los datos transmitidos. La finalidad básica de la criptografía es el envío de información secreta. Si aplicamos una transformación, conocida como cifrado, a la información que queremos mantener en secreto, aunque un adversario consiga ver qué datos estamos enviando le serán completamente ininteligibles. Sólo el destinatario legítimo será capaz de realizar la transformación inversa y recuperar los datos originales. Pero más allá de mantener la información en secreto, existen otros servicios que pueden ser igualmente necesarios, como, por ejemplo, la autenticación. Introducción Debemos evitar, de esta forma, que después de tomar todas las medidas necesarias para que sólo el destinatario final pueda leer la información, resulte que este destinatario sea un impostor que haya conseguido hacerse pasar por el auténtico destinatario. En la segunda parte del capítulo veremos algunos sistemas para garantizar la autenticidad en las comunicaciones, la mayoría de ellas basadas en técnicas criptográficas. En este capítulo estudiaremos ejemplos de protocolos de comunicación que, aplicado los mecanismos criptográficos, permiten proteger la información que se transmite entre ordenadores. Esta protección se puede obtener en distintos niveles de la arquitectura de comunicaciones. A nivel red, el mecanismo principal en un entorno de interconexión basado en IP es el conjunto de protocolos conocido como IPsec. Introducción Alternativamente, se puede implementar la protección a nivel de transporte, aprovechando así la infraestructura IP existente, principalmente los encaminadores o routers. Como ejemplo de protección a nivel de transporte veremos la familia de protocolos SSL/TLS/WTLS. Para finalizar el capítulo, introduciremos la tecnología de redes privadas virtuales o VPN, que permite utilizar una red pública ampliamente extendida como es Internet para comunicaciones seguras, como si fuera una red privada dedicada. Protección del nivel de red: IPsec En el momento de aplicar los mecanismos de protección criptográfica a las redes de computadores, existen diversas opciones en cuanto al nivel de las comunicaciones donde se introduzcan les funciones de seguridad. La protección a nivel de red garantiza que los datos que se envíen a los protocolos de nivel superior, como TCP o UDP, se transmitirán protegidos. El inconveniente es que puede ser necesario adaptar la infraestructura de la red y, en particular los encaminadores (routers), para que entiendan las extensiones que es preciso añadir al protocolo de red (IP) para proporcionar esta seguridad. Protección del nivel de red: IPsec La protección a nivel de transporte, por su lado, tiene la ventaja de que sólo se precisa adaptar las implementaciones de los protocolos (TCP, UDP, etc.) que haya en los nodos extremos de la comunicación, que normalmente están incorporadas al sistema operativo o en librerías especializadas. En este caso, pues, sólo sería necesario un cambio en el software. La protección a nivel de aplicación puede responder mejor a las necesidades de ciertos protocolos. Un ejemplo concreto es el del correo electrónico, en el que interesa proteger los datos de aplicación, es decir, los mensajes de correo, más que los paquetes a nivel de transporte o de red. Protección del nivel de red: IPsec Esto es así porque un mensaje es vulnerable a ataques de acceso ilegítimo o de falsificación no sólo cuando se está transmitiendo por la red sino también cuando está almacenado en el buzón del destinatario. En esta sección veremos la arquitectura IPsec, diseñada para proteger el protocolo de red usado en Internet, es decir, el protocolo IP. En la sección siguiente veremos mecanismos para proteger las comunicaciones a nivel de transporte, y en el capítulo de aplicaciones seguras veremos ejemplos de protección de los protocolos a nivel de aplicación. La arquitectura IPsec La arquitectura IPsec (RFC 2401) añade servicios de seguridad al protocolo IP (versión 4 y versión 6), que pueden ser usados por los protocolos de niveles superiores (TCP, UDP, ICMP, etc.). IPsec se basa en el uso de una serie de protocolos seguros, de los cuales hay dos que proporcionan la mayor parte de los servicios: El protocolo AH (Authentication Header, RFC 2402) ofrece el servicio de autenticación de origen de los datagramas IP (incluyendo la cabecera y los datos de los datagramas). El protocolo ESP (Encapsulating Security Payload, RFC 2406) puede ofrecer el servicio de confidencialidad, el de autenticación de origen de los datos de los datagramas IP (sin incluir la cabecera), o los dos a la vez. Opcionalmente, cada uno de estos dos protocolos también puede proporcionar otro servicio, el de protección contra repetición de datagramas. La arquitectura IPsec Para la autenticación y la confidencialidad es necesario utilizar unas determinadas claves, correspondientes a los algoritmos criptográficos que se apliquen. Una posibilidad es configurar estas claves de forma manual en los nodos IPsec. Normalmente se utilizaran protocolos para la distribución de claves, como pueden ser: ISAKMP (Internet Security Association and Key Management Protocol, RFC 2408) IKE (Internet Key Exchange, RFC 2409) El protocolo de intercambio de claves OAKLEY (RFC 2412) La arquitectura IPsec Los agentes que intervienen en la arquitectura IPSec son: Los nodos extremos de la comunicación: el origen y el destino final de los datagramas. Los nodos intermedios que suporten IPsec, llamados pasarelas seguras, como por ejemplo los encaminadores o cortafuegos con IPsec. El tráfico IPsec también puede pasar por nodos intermedios que no soporten IPsec. Estos nodos son transparentes al protocolo porque para ellos los data-gramas IPsec son como cualquier otro datagrama IP. La arquitectura IPsec La relación que se establece entre dos nodos que se envían datagramas IPsec el uno al otro se llama asociación de seguridad (SA). Estos dos nodos pueden ser o no los extremos de la comunicación, es decir, el origen de los datagramas o su destino final. Por tanto, podemos distinguir dos tipos de SA: Las SA extremo a extremo: se establecen entre el nodo que origina los datagramas y el nodo al cual van destinados. Las SA con una pasarela segura: al menos uno de los nodos es una pasarela segura (también pueden serlo ambos). Por tanto, los datagramas vienen de otro nodo y/o van hacia otro nodo. Además, se considera que las SA son unidireccionales, es decir, si A envía datagramas IPsec a B, y B envía datagramas IPsec a A, tenemos dos SA, una en cada sentido. La arquitectura IPsec Por otro lado, cuando se establece una SA entre dos nodos, se utiliza uno de los dos protocolos básicos IPsec: o AH o ESP. Si se quiere utilizar ambos a la vez, se deberá establecer dos SA, una para cada protocolo. Por tanto, puede pasar que en una comunicación entre dos nodos extremos intervengan diversas SA, cada una con sus nodos de inicio y de final y con su protocolo. La arquitectura IPsec Cada nodo debe guardar información sobre sus SA, como por ejemplo los algoritmos criptográficos que utiliza cada una, las claves, etc. En la terminología IPsec, el lugar donde se guarda esta información se llama base de datos de asociaciones de seguridad o SAD. A cada SA le corresponden un número llamado índice de parámetros de seguridad o SPI. Todas las SA que un nodo tenga establecidas con otro nodo han de tener SPI diferentes. Por tanto, cada SA en que participa un nodo queda identificada por la dirección IP de destino y su SPI. La arquitectura IPsec Para cada datagrama que llega a un nodo IPsec, se consulta una base de datos de políticas de seguridad (SPD) donde se especifican criterios para determinar cuál de las siguientes 3 acciones se debe realizar: Aplicar servicios de seguridad IPsec al datagrama, es decir, procesarlo según AH y/o ESP Procesarlo como un datagrama IP normal, es decir, de forma transparente a IPsec. Descartar el datagrama. El protocolo AH El protocolo AH define una cabecera que contiene la información necesaria para a la autenticación de origen de un datagrama. El campo Next Header sirve para indicar a que protocolo corresponden los datos que vienen a continuación de la cabecera AH. El campo Payload Length indica la longitud de la cabecera (esta información se necesita porque el último campo es de longitud variable, ya que depende del algoritmo de autentificación). El protocolo AH El campo SPI sirve para identificar a que SA corresponde esta cabecera AH, y el número de secuencia que se utiliza si se quiere proporcionar el servicio de protección contra repetición de datagramas. Finalmente, el último campo contiene un código de autentificación, por ejemplo un código MAC, calculado según el algoritmo que corresponda a esta SA. El código se obtiene a partir del datagrama entero, excepto los campos que puedan variar de nodo a nodo (como los campos TTL y Checksum de la cabecera IP), o los que tienen un valor desconocido a priori (como el propio campo de datos de autentificación de la cabecera AH). El nodo que reciba un datagrama con encabezamiento AH verificará el código de autentificación, y si es correcto dará el datagrama por bueno y lo procesará normalmente. Si a parte se utiliza el servicio de protección contra repeticiones, se necesita comprobar que el número de secuencia no sea repetido: si lo es, se descarta el datagrama. El protocolo ESP El protocolo ESP define otra cabecera, que de hecho incluye dentro todos los datos que vengan a continuación en el datagrama (lo que en inglés se llama “payload”). Los campos SPI y número de secuencia son análogos a los de la cabecera AH. El protocolo ESP A continuación, vienen los datos del datagrama (payload), a los cuales puede ser necesario añadir bytes adicionales (padding) si se utiliza un algoritmo de cifrado en bloque, para conseguir que el número de bytes a cifrar sea múltiplo de la longitud de bloque. El campo Padding Length indica exactamente el número de bytes que se han añadido (puede ser 0). El campo Next Header indica de que protocolo son los cotos del datagrama. Dependiendo del servicio o servicios que proporcione esta cabecera ESP, puede ser que los datos estén cifrados (incluyendo el padding y los campos Padding Length y Next Header), que se le añade un código de autenticación calculado a partir de la cabecera ESP (pero no de las cabeceras que pueda haber antes), o ambas cosas a la vez. El protocolo ESP El nodo que reciba un datagrama con cabecera ESP deberá verificar el código de autenticación, descifrar los datos, o ambas cosas (por este orden, porque si se aplican los dos servicios primero se cifra y después se autentican los datos cifrados). Si además se utiliza el servicio de protección contra repeticiones, también se debe comprobar el número de secuencia. Este último servicio, pero, sólo se puede utilizar cuando la cabecera ESP está autenticada. Modos de uso de los protocolos IPsec La arquitectura IPsec define dos modos de uso de los protocolos AH y ESP, dependiendo de cómo se incluyan las cabeceras correspondientes en un datagrama IP. En el modo transporte, la cabecera AH o ESP se incluye después de la cabecera IP convencional, como si fuera una cabecera de un protocolo de nivel superior, y a continuación van los datos del datagrama (por ejemplo, un segmento TCP con su cabecera correspondiente, etc.). En el modo túnel, el datagrama original se encapsula entero, con su cabecera y sus datos, dentro de otro datagrama. Este otro datagrama tendrá una cabecera IP en la cual las direcciones de origen y de destino serán las de los nodos inicio y final de la SA. Por tanto, se dice que entre estos dos nodos hay un “túnel” dentro del cual viajan intactos los datagramas originales. A continuación de la cabecera IP del datagrama “externo” hay la cabecera AH o ESP. Modos de uso de los protocolos IPsec Las siguientes figuras muestran la disposición de las cabeceras IPsec en cada modo. En estas figuras, “tráiler ESP” se refiere a los campos Padding Length y Next Header de la cabecera ESP. Modos de uso de los protocolos IPsec El protocolo IP prevé que un datagrama se pueda fragmentar, y se puede dar el caso que los fragmentos de un mismo datagrama vayan por caminos diferentes hasta llegar a su destino final. Esto representaría un problema en una SA entre pasarelas seguras (o entre un nodo extremo y una pasarela segura) si se utilizara el modo transporte: por ejemplo, algunos fragmentos podrían quedar sin proteger, otros podrían resultar indescifrables porque no han pasado por la pasarela que los había de descifrar, etc. Para evitar estas situaciones, en IPsec sólo se permite el modo transporte en las SA extremo a extremo. El modo túnel no tiene este problema porque, aunque la SA sea entre pasarelas, cada datagrama tiene como dirección de destino la del nodo que hay al final del túnel, y todos los fragmentos finalmente tienen que llegar a este nodo. Por tanto, el modo túnel se puede utilizar en cualquier SA, tanto si es extremo a extremo como si interviene una pasarela segura. Modos de uso de los protocolos IPsec Como hemos visto antes, puede haber diversas SA en el camino entre el originador de los datagramas y el destino final. Esto quiere decir que las disposiciones de cabecera AH y ESP que muestran las figuras anteriores se pueden combinar entre ellas. Por ejemplo, puede haber un túnel dentro de otro túnel, o un túnel dentro de una SA en modo transporte, etc. Otro caso que se puede dar es el de dos SA entre los mismos nodos de origen y de destino, una con el protocolo AH y la otra con el protocolo ESP. En este caso, el orden más lógico es aplicar primero ESP con servicio de confidencialidad y después AH, ya que, de esta forma la protección que ofrece AH, es decir, la autenticación, se extiende a todo el datagrama resultante. Protección del nivel de transporte: SSL/TLS/WTLS Tal y como hemos visto en el apartado anterior, el uso de un protocolo seguro a nivel de red puede requerir la adaptación de la infraestructura de comunicaciones. Por ejemplo, cambiar los encaminadores IP por otros que entiendan IPsec. Un método alternativo que no necesita modificaciones en los equipos de interconexión es introducir la seguridad en los protocolos de transporte. La solución más usada actualmente es el uso del protocolo SSL o de otros basados en SSL. Este grupo de protocolos comprende: El protocolo de transporte Secure Sockets Layer (SSL), desarrollado por Netscape Communications a principios de los años 90. La primera versión de este protocolo ampliamente difundida e implementada fue la 2.0. Poco después Netscape publicó la versión 3.0. con muchos cambios respecto a la anterior. Protección del nivel de transporte: SSL/TLS/WTLS La especificación Transport Layer Security (TLS), elaborada por la IETF (Internet Engineering Task Forcé). La versión 1.0 del protocolo TLS está publicada en el documento RFC 2246. Es prácticamente equivalente a SSL 3.0 con algunas pequeñas diferencias, por lo que en ciertos contextos se considera el TLS 1.0 como si fuera el protocolo “SSL 3.1”. El protocolo Wireless Transport Layer Security (WTLS), perteneciente a la familia de protocolos WAP (Wireless Application Protocol) para el acceso a la red des de dispositivos móviles. La mayoría de los protocolos WAP son adaptaciones de los ya existentes a las características de las comunicaciones inalámbricas y en particular el WTLS está basado en el TLS 1.0. Las diferencias se centran principalmente en aspectos relativos a el uso eficiente del ancho de banda y de la capacidad de cálculo de los dispositivos, que puede ser limitada. Características del protocolo SSL/TLS El objetivo inicial del diseño del protocolo SSL fue proteger las conexiones entre clientes y servidores web con el protocolo HTTP. Esta protección debía permitir al cliente asegurarse que se había conectado al servidor auténtico, y enviarle datos confidenciales, como por ejemplo un número de tarjeta de crédito, con la confianza que nadie más que el servidor sería capaz de ver estos datos. Las funciones de seguridad, no se implementaron directamente en el protocolo de aplicación HTTP, si no que se optó por introducirlas a nivel de transporte. De este modo podría haber muchas más aplicaciones que hicieran uso de esta funcionalidad. Características del protocolo SSL/TLS Con este fin se desarrolló una interfaz de acceso a los servicios del nivel de transporte basada en la interfaz estándar de los sockets. En esta nueva interfaz, funciones como connect, accept, send o recv fueron sustituidas por otras equivalentes pero que utilizaban un protocolo de transporte seguro: SSL_connect, SSL_accept, SSL_send, SSL_recv, etc. El diseño se realizó de tal modo que cualquier aplicación que utilizara TCP a través de las llamadas de los sockets podía hacer uso del protocolo SSL solamente cambiando estas llamadas. De aquí proviene el nombre del protocolo. Características del protocolo SSL/TLS Los servicios de seguridad que proporcionan los protocolos SSL/TLS son: Confidencialidad. El flujo normal de información en una conexión SSL/TLS consiste en intercambiar paquetes con datos cifrados mediante claves simétricas (por motivos de eficiencia y rapidez). Al inicio de cada sesión, cliente y servidor se ponen de acuerdo en que claves utilizarán para cifrar los datos. Siempre se utilizan dos claves distintas: una para los paquetes enviados del cliente al servidor, y la otra para los paquetes enviados en sentido contrario. Para evitar que un intruso que esté escuchando el diálogo inicial pueda saber cuáles son las claves acordadas, se sigue un mecanismo seguro de intercambio de claves, basado en criptografía de clave pública. El algoritmo concreto para este intercambio también se negocia durante el establecimiento de la conexión. Características del protocolo SSL/TLS Autenticación de entidad. Con un protocolo de reto-respuesta basado en firmas digitales el cliente pude confirmar la identidad del servidor al cual se ha conectado. Para validar las firmas el cliente necesita conocer la clave pública del servidor, y esto normalmente se realiza a través de certificados digitales. SSL/TLS también prevé la autenticación del cliente frente al servidor. Esta posibilidad, pero, no se usa tan a menudo porque muchas veces, en lugar de autenticar automáticamente el cliente a nivel de transporte, las mismas aplicaciones utilizan su propio método de autenticación. Características del protocolo SSL/TLS Autenticación de mensaje. Cada paquete enviado en una conexión SSL/TLS, a más de ir cifrado, puede incorporar un código MAC para que el destinatario compruebe que nadie ha modificado el paquete. Las claves secretas para el cálculo de los códigos MAC (una para cada sentido) también se acuerdan de forma segura en el diálogo inicial. A más, los protocolos SSL/TLS están diseñados con estos criterios adicionales: Eficiencia. Dos de las características de SSL/TLS, la definición de sesiones y la compresión de los datos, permiten mejorar la eficiencia de la comunicación. Características del protocolo SSL/TLS Si el cliente pide dos o más conexiones simultáneas o muy seguidas, en lugar de repetir la autenticación y el intercambio de claves (operaciones computacionalmente costosas porque intervienen algoritmos de clave pública), hay la opción de reutilizar los parámetros previamente acordados. Si se hace uso de esta opción, se considera que la nueva conexión pertenece a la misma sesión que la anterior. En el establecimiento de cada conexión se especifica un identificador de sesión, que permite saber si la conexión empieza una sesión nueva o es continuación de otra. SSL/TLS prevé la negociación de algoritmos de compresión para los datos intercambiados, para compensar el tráfico adicional que introduce la seguridad. Pero ni SSL 3.0 ni TLS 1.0 especifican ningún algoritmo concreto de compresión. Extensibilidad. Al inicio de cada sesión, cliente y servidor negocian los algoritmos que utilizarán para el intercambio de claves, la autenticación y el cifrado (a más del algoritmo de compresión). Las especificaciones de los protocolos incluyen unas combinaciones predefinidas de algoritmos criptográficos, pero dejan abierta la posibilidad de añadir nuevos algoritmos si se descubren otros que sean más eficientes o más seguros. El transporte seguro SSL/TLS La capa de transporte seguro que proporciona SSL/TLS se puede considerar dividida en dos subcapas. La subcapa superior se encarga básicamente de negociar los parámetros de seguridad y de transferir los datos de la aplicación. Tanto los datos de negociación como los de aplicación se intercambian en mensajes. En la subcapa inferior, estos mensajes son estructurados en registros a los cuales se les aplica, según corresponda, la compresión, la autenticación y el cifrado. El transporte seguro SSL/TLS El protocolo de registros SSL/TLS es el que permite que los datos protegidos sean convenientemente codificados por el emisor e interpretados por el receptor. Los parámetros necesarios para la protección, como pueden ser los algoritmos y las claves, se establecen de forma segura al inicio de la conexión mediante el protocolo de negociación SSL/TLS. El protocolo de registros SSL/TLS El protocolo de negociación SSL/TLS Ataques contra el protocolo SSL/TLS Los protocolos SSL/TLS están diseñados para resistir los siguientes ataques: Lectura de los paquetes enviados por el cliente y servidor. Cuando los datos se envían cifrados, un atacante que pueda leer los paquetes. Por ejemplo, utilizando técnicas de sniffing, se enfrenta al problema de romper el cifrado si quiere interpretar su contenido. Las claves que se utilizan para el cifrado se intercambian con métodos de clave pública, que el atacante tendría que romper si quiere saber cuáles son los valores acordados. Es preciso advertir, pero, que dependiendo de la aplicación que lo utilice, el protocolo SSL/TLS puede ser objeto de ataques con texto en claro conocido. Por ejemplo, cuando se utiliza juntamente con HTTP para acceder a servidores web con contenidos conocidos. Ataques contra el protocolo SSL/TLS Si la comunicación es totalmente anónima, es decir sin autenticación de servidor ni cliente, sí que existe la posibilidad de capturar las claves secretas con un ataque conocido como “hombre a medio camino” (en inglés, “man-in-the-middle attack"). En este ataque el espía genera sus propias claves públicas y privadas, y cuando una parte envía a la otra información sobre su clave pública, tanto en un sentido como en el otro, el atacante la intercepta y la sustituye por la equivalente con la clave pública fraudulenta. Dado que el intercambio es anónimo, el receptor no tiene manera de saber si la clave pública que recibe es la del emisor auténtico o no. En cambio, si se realiza la autenticación de servidor y/o cliente, es necesario enviar un certificado donde tiene que haber la clave pública del emisor firmada por una autoridad de certificación que el receptor reconozca, y por tanto no puede ser sustituida por otra. Ataques contra el protocolo SSL/TLS Suplantación de servidor o cliente. Cuando se realiza la autenticación de servidor o cliente, el certificado digital debidamente firmado por la CA sirve para verificar la identidad de su propietario. Un atacante que quiera hacerse pasar por el servidor (o cliente) auténtico debería obtener su clave privada, o bien la de la autoridad de certificación que ha emitido el certificado para poder generar otro con una clave pública diferente y que parezca auténtico. Alteración de los paquetes. Un atacante puede modificar los paquetes para que lleguen al destinatario con un contenido distinto del original (si están cifrados no podrá controlar cual será el contenido final descifrado, solamente sabrá que será distinto al original). Si pasa esto, el receptor detectará que el paquete ha sido alterado porque el código de autenticación (MAC) casi con total seguridad será incorrecto. Ataques contra el protocolo SSL/TLS Si la alteración se realiza en los mensajes de negociación cuando aún no se aplica ningún código MAC, con la finalidad por ejemplo de forzar la adopción de algoritmos criptográficos más débiles y vulnerables, esta manipulación será detectada en la verificación de los mensajes Finished. Repetición, eliminación o reordenación de paquetes. Si el atacante vuelve a enviar un paquete correcto que ya había sido enviado antes, o suprime algún paquete haciendo que no llegue a su destino, o los cambia de orden, el receptor lo detectará porque los códigos MAC no coincidirán con el valor esperado. Esto es así porque en el cálculo del MAC se utiliza un número de secuencia que se va incrementando en cada paquete. Tampoco se pueden copiar los mensajes enviados en un sentido (de cliente a servidor o de servidor a cliente) al sentido contrario, porque en los dos flujos de la comunicación se utilizan claves de cifrado y de MAC diferentes. Ataques contra el protocolo SSL/TLS Como consideración final, cabe destacar que la fortaleza de los protocolos seguros recae no solamente en su diseño si no en el de las implementaciones. Si una implementación solamente soporta algoritmos criptográficos débiles (con pocos bits de clave), o genera números pseudoaleatorios fácilmente predecibles, o guarda los valores secretos en almacenamiento (memoria o disco) accesible por atacantes, etc., no estará garantizando la seguridad del protocolo. Aplicaciones que utilizan SSL/TLS Como hemos visto al inicio de este apartado, los protocolos SSL/TLS fueron diseñados para permitir la protección de cualquier aplicación basada en un protocolo de transporte como TCP. Algunas aplicaciones que utilizan esta característica son: HTTPS (HTTP sobre SSL/TLS): el protocolo más utilizado actualmente para la navegación web segura. NNTPS (NNTP sobre SSL): para el acceso seguro al servicio de News. Estas aplicaciones con SSL/TLS funcionan exactamente igual que las originales. Las únicas diferencias son el uso de la capa de transporte seguro que proporciona SSL/TLS y la asignación de números de puerto TCP propios: 443 para HTTPS y 563 para NNTPS. En muchos otros casos, es preferible aprovechar los mecanismos de extensión previstos en el propio protocolo de aplicación, si los hay, para negociar el uso de SSL/TLS, a fin de evitar la utilización innecesaria de nuevos puertos TCP. Aplicaciones que utilizan SSL/TLS Así lo hacen aplicaciones como: TELNET, usando la opción de autenticación (RFC 1416). FTP, usando las extensiones de seguridad (RFC 2228). SMTP, usando sus extensiones para SSL/TLS (RFC 2487). POP3 y IMAP, también usando comandos específicos para SSL/TLS (RFC 2595). También hay definido un mecanismo para negociar el uso de SSL/TLS en HTTP (RFC 2817), como alternativa a HTTPS. Redes privadas virtuales (VPN) Los protocolos seguros que hemos visto hasta este punto permiten proteger las comunicaciones, por ejemplo, de una aplicación implementada como un proceso cliente que se ejecuta en un ordenador y un proceso servidor que se ejecuta en otro ordenador. Si hay otras aplicaciones que también necesiten una comunicación segura entre estos dos ordenadores, o entre ordenadores situados en las mismas redes locales, pueden hacer uso de otras instancias de los protocolos seguros: nuevas asociaciones de seguridad IPsec, nuevas conexiones SSL/TLS, etc. Una posibilidad alternativa es establecer una red privada virtual o VPN entre estos ordenadores o las redes locales donde están situados. En este apartado veremos las características principales de las redes privadas virtuales. Definición y tipos de VPN Una red privada virtual (VPN) es una configuración que combina el uso de dos tipos de tecnologías: Las tecnologías de seguridad que permiten la definición de una red privada, es decir, un medio de comunicación confidencial que no puede ser interceptado por usuarios ajenos a la red. Las tecnologías de encapsulamiento de protocolos que permiten que, en lugar de una conexión física dedicada para la red privada, se pueda utilizar una infraestructura de red pública, como Internet, para definir por encima de ella una red virtual. Por tanto, una VPN es una red lógica o virtual creada sobre una infraestructura compartida, pero que proporciona los servicios de protección necesarios para una comunicación segura. Definición y tipos de VPN Dependiendo de la situación de los nodos que utilizan esta red, podemos considerar tres tipos de VPN: VPN entre redes locales o intranets. Este es el caso habitual en que una empresa dispone de redes locales en diferentes sedes, geográficamente separadas, en cada una de las cuales hay una red privada o intranet, de acceso restringido a sus empleados. Si interesa que desde una de sus sedes se pueda acceder a las intranets de otras sedes, se puede usar una VPN para interconectar estas redes privadas y formar una intranet única. VPN de acceso remoto. Cuando un empleado de la empresa quiere acceder a la intranet des de un ordenador remoto, puede establecer una VPN de este tipo entre este ordenador y la intranet de la empresa. El ordenador remoto puede ser, por ejemplo, un PC que el empleado tiene en su casa, o un ordenador portátil des del cual se conecta a la red de la empresa cuando está de viaje. VPN extranet. A veces, a una empresa le interesa compartir una parte de los recursos de su intranet con determinados usuarios externos, como por ejemplo proveedores o clientes de la empresa. La red que permite estos accesos externos a una intranet se llama extranet, y su protección se consigue mediante una VPN extranet. Configuraciones y protocolos utilizados en VPN A cada uno de los tipos de VPN que acabamos de ver le suele corresponder una configuración específica. En las VPN entre intranets, la situación más habitual es que en cada intranet hay una pasarela VPN, que conecte la red local con Internet. Esta pasarela se comunica con la de las otras intranets, aplicando el cifrado y las protecciones que sean necesarias a las comunicaciones de pasarela a pasarela a través de Internet. Cuando los paquetes llegan a la intranet de destino, la pasarela correspondiente los descifra y los reenvía por la red local hasta el ordenador que los tenga que recibir. De esta manera se utiliza la infraestructura pública de Internet, en lugar de establecer líneas privadas dedicadas, que supondrían un coste más elevado. Configuraciones y protocolos utilizados en VPN También se aprovecha la fiabilidad y redundancia que proporciona Internet, ya que si una ruta no está disponible siempre se pueden encaminar los paquetes por otro camino, mientras que con una línea dedicada la redundancia supondría un coste aún más elevado. En las VPN de acceso remoto, a veces llamadas VPDN, un usuario se puede comunicar con una intranet a través de un proveedor de acceso a Internet, utilizando tecnología convencional como por ejemplo a través de un módem de fibra. El ordenador del usuario ha de disponer de software cliente VPN para comunicarse con la pasarela VPN de la intranet y llevar a cabo la autenticación necesaria, el cifrado, etc. De este modo también se aprovecha la infraestructura de los proveedores de Internet para el acceso a la intranet, sin necesidad de llamadas a un módem de la empresa, que pueden llegar a tener un coste considerable. Configuraciones y protocolos utilizados en VPN El caso de las VPN extranet puede ser como el de las VPN entre intranets, en que la comunicación segura se establece entre pasarelas VPN, o bien como el de las VPN de acceso remoto, en que un cliente VPN se comunica con la pasarela de la intranet. La diferencia, pero, es que en este caso normalmente el control de acceso es más restrictivo para permitir solamente el acceso a los recursos autorizados. La definición de una red virtual lleva a cabo mediante el establecimiento de túneles, que permiten encapsular paquetes de la red virtual, con sus protocolos, dentro de paquetes de otra red, que normalmente es Internet, con su protocolo, es decir IP. Para la comunicación entre las distintas intranets, o entre el ordenador que accede remotamente y la intranet, se pueden utilizar los protocolos que sean más convenientes. Los paquetes de estos protocolos, para poderlos hacer llegar a su destino a través de Internet, se pueden encapsular en datagramas IP, que dentro suyo contendrán los paquetes originales. Configuraciones y protocolos utilizados en VPN Cuando lleguen a su destino, se desencapsulan estos datagramas para recuperar los paquetes con el formato “nativo” del protocolo correspondiente. Configuraciones y protocolos utilizados en VPN Hay protocolos que pueden ser utilizados para establecer los túneles, dependiendo del nivel de la comunicación al cual se quiera realizar la protección. Túneles a nivel de red. El protocolo utilizado en la gran mayoría de configuraciones VPN es IPsec en modo túnel, generalmente con ESP par cifrar los datos, y opcionalmente con AH para autenticar los paquetes encapsulados. Las pasarelas VPN son, en este caso, pasarelas seguras IPsec. Túneles a nivel de enlace. En el caso de las VPN de acceso remoto o VPDN, existe la posibilidad de encapsular tramas PPP, que son las que transmite normalmente un cliente VPN de este tipo, sobre datagramas IP. Configuraciones y protocolos utilizados en VPN Hay diversas opciones para encapsular PPP (que a su vez puede encapsular otros protocolos de red, como IPX, etc. o posiblemente IP) sobre IP: El protocolo PPTP (Point-to-Point Tunneling Protocol, RFC 2637) especifica una técnica para el encapsulamiento de tramas PPP pero no añade servicios de autenticación. Estos servicios se pueden realizar con los mismos protocolos que utiliza PPP, como PAP (Password Authentication Protocol) o CHAP (Challenge Handshake Authentication Protocol). El protocolo L2F (Layer Two Forwarding, RFC 2637) es parecido al PPTP pero también puede trabajar con SLIP a más de PPP. Para la autenticación puede utilizar protocolos auxiliares como RADIUS (Remote Authentication Dial-In User Service). El protocolo L2TP (Layer Two Tunneling Protocol, RFC 2661) combina las funcionalidades que ofrecen PPTP y L2F. Configuraciones y protocolos utilizados en VPN Túneles a nivel de transporte. El protocolo SSH (Secure Shell), ofrece la posibilidad de redirigir puertos TCP sobre un canal seguro, que podemos considerar como un túnel a nivel de transporte. Desde este punto de vista, también se podría considerar una conexión SSL/TLS como un túnel a nivel de transporte que proporciona confidencialidad y autenticación. Habitualmente, este último tipo de túnel no sirve para cualquier tipo de tráfico sino solamente para datos TCP, y por tanto no se considera parte integrante de una VPN.