Suscríbete a nosotros. protocolo ESP
A finales de los años sesenta, la Agencia Estadounidense de Proyectos de Investigación Avanzada de Defensa, DARPA, decidió crear una red experimental llamada ARPANet. En los años setenta, ARPANet comenzó a ser considerada una red estadounidense funcional y, a través de esta red, era posible obtener acceso a las principales universidades y centros de investigación de Estados Unidos. A principios de los años ochenta se inició la estandarización de los lenguajes de programación y luego de los protocolos de interacción en red. El resultado de este trabajo fue el desarrollo de un modelo de interacción de red ISO/OSI de siete niveles y la familia de protocolos TCP/IP, que se convirtió en la base para la construcción de redes locales y globales.
Los mecanismos básicos de intercambio de información en las redes TCP/IP se formaron generalmente a principios de los años ochenta y estaban destinados principalmente a garantizar la entrega de paquetes de datos entre diferentes sistemas operativos utilizando canales de comunicación heterogéneos. Aunque ARPANet (que más tarde se convertiría en la Internet moderna) fue concebida por una organización de defensa gubernamental, en realidad la red se originó en el mundo de la investigación y heredó la tradición de apertura de la comunidad académica. Incluso antes de la comercialización de Internet (que ocurrió a mediados de los años noventa), muchos investigadores reputados notaron problemas asociados con la seguridad de la pila de protocolos TCP/IP. Los conceptos básicos de los protocolos TCP/IP no satisfacen plenamente (y en algunos casos contradicen) las ideas modernas sobre seguridad informática.
Hasta hace poco, Internet se utilizaba principalmente para procesar información mediante protocolos relativamente simples: correo electrónico, transferencia de archivos y acceso remoto. Hoy en día, gracias al uso generalizado de las tecnologías WWW, se utilizan cada vez más herramientas distribuidas de procesamiento de información multimedia. Al mismo tiempo, está creciendo el volumen de datos procesados en entornos cliente/servidor y destinados al acceso colectivo simultáneo de un gran número de suscriptores. Se han desarrollado varios protocolos a nivel de aplicación para garantizar la seguridad de la información para aplicaciones como correo electrónico (PEM, PGP, etc.), WWW (Secure HTTP, SSL, etc.), gestión de redes (SNMPv2, etc.). Sin embargo, la presencia de características de seguridad en los protocolos básicos de la familia TCP/IP permitirá el intercambio de información entre una amplia gama de aplicaciones y servicios diferentes.
Breves antecedentes históricos de la aparición del protocolo
En 1994, la Junta de Arquitectura de Internet (IAB) publicó el informe "Seguridad de la arquitectura de Internet". Este documento describe las principales áreas de aplicación de herramientas de seguridad adicionales en Internet, a saber, protección contra monitoreo no autorizado, suplantación de paquetes y control del flujo de datos. Entre las medidas de protección prioritarias y más importantes estaba la necesidad de desarrollar un concepto y mecanismos básicos para garantizar la integridad y confidencialidad de los flujos de datos. Dado que el cambio de los protocolos básicos de la familia TCP/IP provocaría una reestructuración completa de Internet, se planteó la tarea de garantizar la seguridad del intercambio de información en redes de telecomunicaciones abiertas basadas en los protocolos existentes. Así, se comenzó a crear la especificación Secure IP, complementaria a los protocolos IPv4 e IPv6.
Arquitectura IPSec
La seguridad IP es un conjunto de protocolos que se ocupan de cuestiones de cifrado, autenticación y seguridad durante el transporte de paquetes IP; ahora incluye casi 20 propuestas de estándares y 18 RFC.
La especificación de seguridad IP (conocida hoy como IPsec) es desarrollada por el grupo de trabajo del protocolo de seguridad IP del IETF. IPsec incluía originalmente tres especificaciones centrales independientes del algoritmo publicadas como RFC de arquitectura de seguridad IP, encabezado de autenticación (AH) y encapsulación de datos cifrados (ESP) (RFC1825, 1826 y 1827). Cabe señalar que en noviembre de 1998, el Grupo de Trabajo sobre Protocolo de Seguridad IP propuso nuevas versiones de estas especificaciones, las cuales actualmente tienen estatus de estándares preliminares, estas son RFC2401 - RFC2412. Tenga en cuenta que RFC1825-27 se ha considerado obsoleto durante varios años y realmente no se utiliza. Además, existen varias especificaciones dependientes de algoritmos que utilizan los protocolos MD5, SHA, DES.
Arroz. 1 – Arquitectura IPSec.
El Grupo de Trabajo sobre Protocolos de Seguridad IP también está desarrollando protocolos clave de gestión de información. La misión de este grupo es desarrollar el Protocolo de administración de claves de Internet (IKMP), un protocolo de administración de claves a nivel de aplicación que es independiente de los protocolos de seguridad utilizados. Actualmente se están explorando conceptos de administración de claves utilizando la especificación del Protocolo de administración de claves y la Asociación de seguridad de Internet (ISAKMP) y el Protocolo de determinación de claves de Oakley. La especificación ISAKMP describe mecanismos para negociar los atributos de los protocolos utilizados, mientras que el protocolo Oakley le permite instalar claves de sesión en computadoras en Internet. Anteriormente, también se consideraron las posibilidades de utilizar mecanismos de gestión de claves del protocolo SKIP, pero ahora esas posibilidades prácticamente no se utilizan en ninguna parte. Los estándares emergentes de gestión de información clave pueden admitir centros de distribución de claves similares a los utilizados en Kerberos. Los protocolos de gestión de claves basados en Kerberos para IPSec están siendo abordados actualmente por el relativamente nuevo grupo de trabajo KINK (Negociación de claves de Internet Kerberizada).
Las garantías de integridad y confidencialidad de los datos en la especificación IPsec se proporcionan mediante el uso de mecanismos de autenticación y cifrado, respectivamente. Estos últimos, a su vez, se basan en el acuerdo preliminar de las partes en el llamado intercambio de información. “contexto de seguridad”: algoritmos criptográficos aplicados, algoritmos de gestión de información clave y sus parámetros. La especificación IPsec brinda la capacidad de que las partes intercambien información para admitir varios protocolos y parámetros para la autenticación y cifrado de paquetes de datos, así como varios esquemas de distribución de claves. En este caso, el resultado de acordar el contexto de seguridad es el establecimiento de un índice de parámetros de seguridad (SPI), que es un indicador de un determinado elemento de la estructura interna de la parte de intercambio de información, que describe posibles conjuntos de parámetros de seguridad.
Esencialmente, IPSec, que será un componente de IPv6, opera en la capa tres, es decir, en la capa de red. Como resultado, los paquetes IP transmitidos estarán protegidos de manera transparente para las aplicaciones e infraestructura de la red. A diferencia de SSL (Secure Socket Layer), que opera en la capa 4 (es decir, transporte) y está más estrechamente asociado con capas superiores del modelo OSI, IPSec está diseñado para proporcionar seguridad de bajo nivel.
Arroz. 2 - Modelo OSI/ISO.
Cuando los datos IP están listos para enviarse a través de una red privada virtual, IPSec agrega un encabezado para identificar los paquetes protegidos. Antes de transmitirse a través de Internet, estos paquetes se encapsulan dentro de otros paquetes IP. IPSec admite varios tipos de cifrado, incluido el estándar de cifrado de datos (DES) y el resumen de mensajes 5 (MD5).
Para establecer una conexión segura, ambos participantes en la sesión deben poder ponerse de acuerdo rápidamente sobre los parámetros de seguridad, como claves y algoritmos de autenticación. IPSec admite dos tipos de esquemas de gestión de claves mediante los cuales los participantes pueden negociar los parámetros de la sesión. Este doble apoyo en un momento causó cierta fricción en el Grupo de Trabajo del IETF.
Con la versión actual de IP, IPv4, se puede utilizar el Protocolo de administración de claves de asociación segura de Internet (ISAKMP) o la Administración de claves simple para el Protocolo de Internet. Con la nueva versión de IP, IPv6, tendrás que utilizar ISAKMP, ahora conocido como IKE, aunque no se excluye la posibilidad de utilizar SKIP. Sin embargo, hay que tener en cuenta que SKIP no ha sido considerado durante mucho tiempo como un candidato clave para la gestión y fue eliminado de la lista de posibles candidatos en 1997.
Encabezado AH
El encabezado de autenticación (AH) es un encabezado opcional común y normalmente se encuentra entre el encabezado principal del paquete IP y el campo de datos. La presencia de AH no afecta de ninguna manera el proceso de transmisión de información desde el transporte y niveles superiores. El principal y único propósito de AH es brindar protección contra ataques relacionados con cambios no autorizados en el contenido de un paquete, incluida la falsificación de la dirección de origen de la capa de red. Los protocolos de nivel superior deben modificarse para verificar la autenticidad de los datos recibidos.
El formato AH es bastante simple y consta de un encabezado de 96 bits y datos de longitud variable que consisten en palabras de 32 bits. Los nombres de los campos reflejan su contenido con bastante claridad: Siguiente encabezado indica el siguiente encabezado, Payload Len representa la longitud del paquete, SPI es un puntero al contexto de seguridad y Sequence Number Field contiene el número de secuencia del paquete.
Arroz. 3 - Formato de encabezado AH.
El número de secuencia de paquetes se introdujo en AH en 1997 como parte del proceso de revisión de la especificación IPsec. El valor de este campo lo genera el remitente y sirve para proteger contra ataques relacionados con la reutilización de los datos del proceso de autenticación. Debido a que Internet no garantiza el orden en el que se entregarán los paquetes, el destinatario debe almacenar información sobre el número de secuencia máximo de un paquete autenticado exitosamente y si se ha recibido una cantidad de paquetes que contienen números de secuencia anteriores (generalmente 64).
A diferencia de los algoritmos de cálculo de suma de verificación utilizados en los protocolos para transmitir información a través de líneas de comunicación conmutadas o a través de canales de redes locales y destinados a corregir errores aleatorios en el medio de transmisión, los mecanismos para garantizar la integridad de los datos en las redes de telecomunicaciones abiertas deben tener medios de protección contra cambios específicos. Uno de esos mecanismos es un uso especial del algoritmo MD5: durante la formación del AH, se calcula secuencialmente una función hash a partir de la unión del paquete mismo y alguna clave previamente acordada, y luego a partir de la unión del resultado resultante y la clave transformada. Este es el mecanismo predeterminado para garantizar que todas las implementaciones de IPv6 tengan al menos un algoritmo común que no esté sujeto a restricciones de exportación.
encabezado ESP
Cuando se utiliza la encapsulación de datos cifrados, el encabezado ESP es el último de los encabezados opcionales "visibles" en el paquete. Dado que el objetivo principal de ESP es garantizar la confidencialidad de los datos, diferentes tipos de información pueden requerir algoritmos de cifrado significativamente diferentes. En consecuencia, el formato ESP puede sufrir cambios importantes dependiendo de los algoritmos criptográficos utilizados. Sin embargo, se pueden distinguir los siguientes campos obligatorios: SPI, que indica el contexto de seguridad, y Sequence Number Field, que contiene el número de secuencia del paquete. El campo "Datos de autenticación ESP" (suma de verificación) es opcional en el encabezado ESP. El destinatario del paquete ESP descifra el encabezado ESP y utiliza los parámetros y datos del algoritmo de cifrado aplicado para decodificar la información de la capa de transporte.
Arroz. 4 - Formato de encabezado ESP.
Hay dos modos de utilizar ESP y AH (así como sus combinaciones): transporte y túnel.
Modo de transporte
El modo de transporte se utiliza para cifrar el campo de datos de un paquete IP que contiene protocolos de capa de transporte (TCP, UDP, ICMP), que, a su vez, contiene información del servicio de la aplicación. Un ejemplo del uso del modo de transporte es la transmisión de correo electrónico. Todos los nodos intermedios a lo largo de la ruta de un paquete desde el remitente al receptor utilizan sólo la información de la capa de red pública y posiblemente algunos encabezados de paquetes opcionales (en IPv6). La desventaja del modo de transporte es la falta de mecanismos para ocultar el remitente y el destinatario específicos de un paquete, así como la capacidad de analizar el tráfico. El resultado de dicho análisis puede ser información sobre los volúmenes y direcciones de transferencia de información, las áreas de interés de los suscriptores y la ubicación de los administradores.
Modo túnel
El modo túnel cifra todo el paquete, incluido el encabezado de la capa de red. El modo túnel se utiliza cuando es necesario ocultar el intercambio de información de la organización con el mundo exterior. En este caso, los campos de dirección del encabezado de la capa de red de un paquete que utiliza el modo túnel los completa el firewall de la organización y no contienen información sobre el remitente específico del paquete. Al transmitir información desde el mundo exterior a la red local de la organización, la dirección de red del firewall se utiliza como dirección de destino. Después de que el firewall descifra el encabezado de la capa de red inicial, el paquete se reenvía al destinatario.
Asociaciones de seguridad
Una Asociación de Seguridad (SA) es una conexión que proporciona servicios de seguridad para el tráfico que pasa a través de ella. Dos computadoras a cada lado de la SA almacenan el modo, protocolo, algoritmos y claves utilizadas en la SA. Cada SA se utiliza en una sola dirección. La comunicación bidireccional requiere dos SA. Cada SA implementa un modo y protocolo; por lo tanto, si es necesario utilizar dos protocolos para un paquete (como AH y ESP), entonces se requieren dos SA.
Política de seguridad
La política de seguridad se almacena en la SPD (Base de datos de políticas de seguridad). SPD puede especificar una de tres acciones para un paquete de datos: descartar el paquete, no procesar el paquete usando IPSec o procesar el paquete usando IPSec. En este último caso, el SPD también indica qué SA se debe utilizar (si, por supuesto, ya se ha creado una SA adecuada) o indica con qué parámetros se debe crear una nueva SA.
SPD es un mecanismo de control muy flexible que permite un muy buen control sobre el procesamiento de cada paquete. Los paquetes se clasifican según una gran cantidad de campos y el SPD puede examinar algunos o todos los campos para determinar la acción adecuada. Esto podría dar como resultado que todo el tráfico entre dos máquinas se transporte utilizando una única SA, o que se utilicen SA separadas para cada aplicación, o incluso para cada conexión TCP.
ISAKMP/Oakley
ISAKMP define la estructura general de protocolos que se utilizan para establecer SA y realizar otras funciones de gestión clave. ISAKMP soporta varios Dominios de Interpretación (DOI), uno de los cuales es IPSec-DOI. ISAKMP no define un protocolo completo, sino que proporciona "bloques de construcción" para varios DOI y protocolos de intercambio de claves.
El protocolo Oakley es un protocolo de descubrimiento de claves que utiliza el algoritmo de reemplazo de claves Diffie-Hellman. El protocolo Oakley admite Perfect Forward Secrecy (PFS). La presencia de PFS significa que es imposible descifrar todo el tráfico si alguna clave del sistema se ve comprometida.
IKE
IKE es el protocolo de intercambio de claves predeterminado para ISAKMP y actualmente es el único. IKE se encuentra encima de ISAKMP y realiza el establecimiento real tanto de ISAKMP SA como de IPSec SA. IKE admite un conjunto de varias funciones primitivas para usar en protocolos. Entre ellas se encuentran la función hash y la función pseudoaleatoria (PRF).
Una función hash es una función resistente a colisiones. La resistencia a la colisión se refiere al hecho de que es imposible encontrar dos mensajes diferentes. metro 1 Y metros 2, tal que H(m1)=Altura(m2), Dónde h- función hash.
En cuanto a las funciones pseudoaleatorias, actualmente se utiliza una función hash en lugar de PRF especiales en el diseño de HMAC (HMAC es un mecanismo de autenticación de mensajes que utiliza funciones hash). Para definir HMAC, necesitamos una función hash criptográfica (llamémosla H) y una clave secreta K. Suponemos que H es una función hash en la que los datos se procesan mediante un procedimiento de compresión aplicado secuencialmente a una secuencia de bloques de datos. Denotamos con B la longitud de dichos bloques en bytes y la longitud de los bloques obtenidos como resultado del hash con L (L Ipad = byte 0x36, repetido B veces; Para calcular HMAC a partir de datos de "texto", debe realizar la siguiente operación: H(K XOR opad, H(K XOR ipad, texto)) De la descripción se deduce que IKE utiliza valores HASH para autenticar a las partes. Tenga en cuenta que HASH en este caso se refiere únicamente al nombre de la carga útil en ISAKMP y este nombre no tiene nada que ver con su contenido. Todos los tipos de ataques a componentes IPSec se pueden dividir en los siguientes grupos: ataques que explotan los recursos finitos del sistema (un ejemplo típico es un ataque de denegación de servicio, denegación de servicio o ataque DOS), ataques que explotan las funciones y errores de una implementación específica de IPSec y, finalmente, ataques basados en las debilidades de los propios protocolos. AH y ESP. Los ataques puramente criptográficos pueden ignorarse: ambos protocolos definen el concepto de "transformación", donde toda la criptografía está oculta. Si el algoritmo criptográfico utilizado es estable y la transformación definida con él no introduce debilidades adicionales (este no es siempre el caso, por lo que es más correcto considerar la fortaleza de todo el sistema: protocolo-transformación-algoritmo), entonces De este lado todo está bien. ¿Qué queda? Ataque de repetición: nivelado mediante el uso del número de secuencia (en un solo caso, esto no funciona: cuando se usa ESP sin autenticación y sin AH). Además, el orden de las acciones (primero el cifrado, luego la autenticación) garantiza un rápido rechazo de los paquetes "malos" (además, según investigaciones recientes en el mundo de la criptografía, este orden de acciones es el más seguro; el orden inverso en algunos, aunque casos muy especiales, pueden dar lugar a posibles agujeros de seguridad; afortunadamente, ni SSL, ni IKE, ni otros protocolos comunes con el orden de acciones “primero autenticar, luego cifrar” no se aplican a estos casos especiales y, por lo tanto, no tienen estos agujeros; ). Lo que queda es el ataque de denegación de servicio. Como saben, se trata de un ataque del que no existe una defensa completa. Sin embargo, el rápido rechazo de los paquetes defectuosos y la ausencia de cualquier reacción externa hacia ellos (según el RFC) permiten afrontar este ataque más o menos bien. En principio, AH y ESP resisten con éxito la mayoría (si no todos) los ataques de red conocidos (rastreo, suplantación de identidad, secuestro, etc.) cuando se usan correctamente. Con IKE es un poco más complicado. El protocolo es muy complejo y difícil de analizar. Además, debido a errores tipográficos (en la fórmula para calcular HASH_R) al escribirlo y soluciones no del todo exitosas (los mismos HASH_R y HASH_I), contiene varios "agujeros" potenciales (en particular, en la primera fase, no todas las cargas útiles en los mensajes están autenticados), sin embargo, no son muy graves y conducen, como máximo, a una negativa a establecer una conexión. IKE se protege con mayor o menor éxito de ataques como la reproducción, la suplantación de identidad, el rastreo y el secuestro. La criptografía es algo más complicada: no se lleva a cabo por separado, como en AH y ESP, sino que se implementa en el propio protocolo. Sin embargo, si utiliza algoritmos persistentes y primitivas (PRF), no debería haber problemas. Hasta cierto punto, se puede considerar como una debilidad de IPsec que DES esté indicado como el único algoritmo criptográfico obligatorio en las especificaciones actuales (esto es válido tanto para ESP como para IKE), 56 bits de cuya clave ya no se consideran suficientes. . Sin embargo, esto es una debilidad puramente formal: las especificaciones en sí son independientes de los algoritmos y casi todos los proveedores conocidos han implementado 3DES desde hace mucho tiempo (y algunos ya han implementado AES). Por lo tanto, si se implementa correctamente, el ataque más "peligroso" sigue siendo. Denegación de servicio. El protocolo IPSec ha recibido críticas mixtas por parte de los expertos. Por un lado, cabe señalar que el protocolo IPSec es el mejor entre todos los demás protocolos desarrollados anteriormente para proteger los datos transmitidos a través de la red (incluido el PPTP desarrollado por Microsoft). Según la otra parte, el protocolo es excesivamente complejo y redundante. Así, Niels Ferguson y Bruce Schneier en su trabajo "Una evaluación criptográfica de IPsec" señalan que encontraron serios problemas de seguridad en casi todos los componentes principales de IPsec. Estos autores también señalan que el conjunto de protocolos requiere mejoras significativas para que proporcione un buen nivel de seguridad. El artículo describe una serie de ataques que explotan tanto las debilidades del esquema general de procesamiento de datos como las debilidades de los algoritmos criptográficos. En este artículo, cubrimos algunos puntos básicos sobre el protocolo de seguridad de red IPsec. Vale la pena señalar que el protocolo IPsec domina la mayoría de las implementaciones de redes privadas virtuales. Actualmente, el mercado ofrece tanto implementaciones de software (por ejemplo, el protocolo se implementa en el sistema operativo Microsoft Windows 2000) como implementaciones de hardware y software de IPsec; estas son soluciones de Cisco, Nokia. A pesar de la gran cantidad de soluciones diferentes, todas ellas son bastante compatibles entre sí. El artículo concluye con una tabla que compara IPSec y el ahora ampliamente utilizado SSL. Compañeros de clase Figura 1: ejemplo de funcionamiento de IPsec Internet se creó originalmente como un medio seguro para transferir datos entre personal militar. Dado que solo trabajaba con él un cierto círculo de personas, personas educadas y con conocimientos de política de seguridad, no había una necesidad obvia de crear protocolos seguros. La seguridad se organizó a nivel de aislamiento físico de los objetos de personas no autorizadas, y esto se justificó cuando un número limitado de máquinas tenían acceso a la red. Sin embargo, cuando Internet se hizo público y comenzó a desarrollarse y crecer activamente, surgió esa necesidad. En 1994, la Junta de Arquitectura de Internet (IAB) publicó el informe "Seguridad de la arquitectura de Internet". Este documento describe las principales áreas de aplicación de herramientas de seguridad adicionales en Internet, a saber, protección contra monitoreo no autorizado, suplantación de paquetes y control del flujo de datos. Entre las medidas de protección prioritarias y más importantes estaba la necesidad de desarrollar un concepto y mecanismos básicos para garantizar la integridad y confidencialidad de los flujos de datos. Dado que el cambio de los protocolos básicos de la familia TCP/IP provocaría una reestructuración completa de Internet, se planteó la tarea de garantizar la seguridad del intercambio de información en redes de telecomunicaciones abiertas basadas en los protocolos existentes. Así, se comenzó a crear la especificación Secure IP, complementaria a los protocolos IPv4 e IPv6. En 1995, el grupo de trabajo publicó RFC-1825 a RFC-1827, la primera implementación funcional del protocolo. La especificidad de IPsec es que se implementa en la capa de red, completándola de tal manera que todo pasa desapercibido para las capas posteriores. La principal dificultad es que en el proceso de establecimiento de una conexión, dos participantes en un canal seguro deben acordar una cantidad bastante grande de parámetros diferentes. Es decir, deben autenticarse entre sí, generar e intercambiar claves (y a través de un entorno que no sea de confianza) y también acordar qué protocolos cifrar los datos. Es por ello que IPsec consta de una pila de protocolos cuya responsabilidad es garantizar el establecimiento, funcionamiento y gestión de una conexión segura. Todo el proceso de establecimiento de conexión consta de dos fases: la primera fase se utiliza para garantizar el intercambio seguro de mensajes ISAKMP en la segunda fase. ISAKMP (Protocolo de administración de claves y asociación de seguridad de Internet) es un protocolo que sirve para negociar y actualizar políticas de seguridad (SA) entre los participantes en una conexión VPN. Estas políticas indican específicamente qué protocolo utilizar para cifrar (AES o 3DES) y con qué autenticarse (SHA o MD5). AES (Estándar de cifrado avanzado), también conocido como Rijndael, es un algoritmo de cifrado de bloques simétrico (tamaño de bloque de 128 bits, clave de 128/192/256 bits), adoptado como estándar de cifrado por el gobierno de EE. UU. a través del concurso AES. En 2009, AES es uno de los algoritmos de cifrado simétrico más utilizados. DES (Estándar de cifrado de datos)- un algoritmo de cifrado simétrico desarrollado por IBM y aprobado por el gobierno de EE. UU. en 1977 como estándar oficial (FIPS 46-3). DES tiene bloques de 64 bits y una estructura de red Feistel de 16 ciclos; utiliza una clave de 56 bits para el cifrado. El algoritmo utiliza una combinación de transformaciones no lineales (S-boxes) y lineales (permutaciones E, IP, IP-1). 3DES (Estándar de cifrado de datos triple)- un cifrado de bloques simétrico creado por Whitfield Diffie, Martin Hellman y Walt Tuchmann en 1978 basado en el algoritmo DES, para eliminar el principal inconveniente de este último: la pequeña longitud de la clave (56 bits), que puede descifrarse mediante fuerza bruta . La velocidad de 3DES es 3 veces menor que la de DES, pero la solidez criptográfica es mucho mayor: el tiempo necesario para criptoanalizar 3DES puede ser mil millones de veces mayor que el tiempo necesario para descifrar DES. 3DES se usa más comúnmente que DES, que se rompe fácilmente con la tecnología actual (en 1998, Electronic Frontier Foundation descifró DES en 3 días usando una computadora especial DES Cracker). 3DES es una forma sencilla de superar las deficiencias de DES. El algoritmo 3DES está basado en DES, por lo que es posible utilizar programas creados para DES para implementarlo. RSA (algoritmo de Ron Rivest, Adi Shamir y Leonard Adleman)- algoritmo criptográfico de clave pública. RSA fue el primer algoritmo de este tipo, adecuado tanto para cifrado como para firma digital. El algoritmo se utiliza en una gran cantidad de aplicaciones criptográficas. Certificado- un documento digital o en papel que confirma la correspondencia entre una clave pública y la información que identifica al propietario de la clave. Contiene información sobre el propietario de la clave, información sobre la clave pública, su finalidad y alcance, el nombre de la autoridad certificadora, etc. PKI (Infraestructura de clave pública)- tecnología de autenticación mediante claves públicas. Se trata de un sistema complejo que vincula las claves públicas con la identidad del usuario a través de una autoridad de certificación (CA). CRL (lista de revocación de certificados)- lista de certificados revocados. La construcción de un canal de comunicación seguro se puede implementar en diferentes niveles del modelo OSI. Por ejemplo, el popular protocolo SSL opera a nivel de presentación y PPTP a nivel de sesión. La seguridad IP es un conjunto de protocolos que se ocupan de cuestiones de cifrado, autenticación y seguridad durante el transporte de paquetes IP; ahora incluye casi 20 propuestas de estándares y 18 RFC. La especificación de seguridad IP (conocida hoy como IPsec) es desarrollada por el grupo de trabajo del protocolo de seguridad IP del IETF. IPsec incluía originalmente tres especificaciones centrales independientes del algoritmo, publicadas como RFC: arquitectura de seguridad IP, encabezado de autenticación (AH) y encapsulación de datos cifrados (ESP) (RFC1825, 1826 y 1827). Cabe señalar que en noviembre de 1998, el Grupo de Trabajo sobre Protocolo de Seguridad IP propuso nuevas versiones de estas especificaciones, las cuales actualmente tienen estatus de estándares preliminares, estas son RFC2401 - RFC2412. Tenga en cuenta que RFC1825-27 se ha considerado obsoleto durante varios años y realmente no se utiliza. Además, existen varias especificaciones dependientes de algoritmos que utilizan los protocolos MD5, SHA, DES. El Grupo de Trabajo sobre Protocolos de Seguridad IP también está desarrollando protocolos clave de gestión de información. La misión de este grupo es desarrollar el Protocolo de administración de claves de Internet (IKMP), un protocolo de administración de claves a nivel de aplicación que es independiente de los protocolos de seguridad utilizados. Actualmente se están explorando conceptos de administración de claves utilizando la especificación del Protocolo de administración de claves y la Asociación de seguridad de Internet (ISAKMP) y el Protocolo de determinación de claves de Oakley. La especificación ISAKMP describe mecanismos para negociar los atributos de los protocolos utilizados, mientras que el protocolo Oakley le permite instalar claves de sesión en computadoras en Internet. Anteriormente, también se consideraron las posibilidades de utilizar mecanismos de gestión de claves del protocolo SKIP, pero ahora esas posibilidades prácticamente no se utilizan en ninguna parte. Los estándares emergentes de gestión de información clave pueden admitir centros de distribución de claves similares a los utilizados en Kerberos. Los protocolos de gestión de claves basados en Kerberos para IPSec están siendo abordados actualmente por el relativamente nuevo grupo de trabajo KINK (Negociación de claves de Internet Kerberizada). Las garantías de integridad y confidencialidad de los datos en la especificación IPsec se proporcionan mediante el uso de mecanismos de autenticación y cifrado, respectivamente. Estos últimos, a su vez, se basan en el acuerdo preliminar de las partes en el llamado intercambio de información. “contexto de seguridad”: algoritmos criptográficos aplicados, algoritmos de gestión de información clave y sus parámetros. La especificación IPsec brinda la capacidad de que las partes intercambien información para admitir varios protocolos y parámetros para la autenticación y cifrado de paquetes de datos, así como varios esquemas de distribución de claves. En este caso, el resultado de acordar el contexto de seguridad es el establecimiento de un índice de parámetros de seguridad (SPI), que es un indicador de un determinado elemento de la estructura interna de la parte de intercambio de información, que describe posibles conjuntos de parámetros de seguridad. Básicamente, IPSec, que pasará a formar parte de IPv6, opera en la tercera capa, es decir, en la capa de red. Como resultado, los paquetes IP transmitidos estarán protegidos de manera transparente para las aplicaciones e infraestructura de la red. A diferencia de SSL (Secure Socket Layer), que opera en la capa 4 (es decir, transporte) y está más estrechamente asociado con capas superiores del modelo OSI, IPSec está diseñado para proporcionar seguridad de bajo nivel. Cuando los datos IP están listos para enviarse a través de una red privada virtual, IPSec agrega un encabezado para identificar los paquetes protegidos. Antes de transmitirse a través de Internet, estos paquetes se encapsulan dentro de otros paquetes IP. IPSec admite varios tipos de cifrado, incluido el estándar de cifrado de datos y el resumen de mensajes 5. Para establecer una conexión segura, ambas partes de la sesión deben poder ponerse de acuerdo rápidamente sobre los parámetros de seguridad, como claves y algoritmos de autenticación. IPSec admite dos tipos de esquemas de gestión de claves mediante los cuales los participantes pueden negociar los parámetros de la sesión. Este doble apoyo en un momento causó cierta fricción en el Grupo de Trabajo del IETF. Con la versión actual de IP, IPv4, se puede utilizar el Protocolo de administración de claves de asociación segura de Internet (ISAKMP) o la Administración de claves simple para el Protocolo de Internet. Con la nueva versión de IP, IPv6, tendrás que utilizar ISAKMP, ahora conocido como IKE, aunque no se excluye la posibilidad de utilizar SKIP. Sin embargo, hay que tener en cuenta que SKIP no ha sido considerado durante mucho tiempo como un candidato clave para la gestión y fue eliminado de la lista de posibles candidatos en 1997. IPsec es un conjunto de estándares de Internet y una especie de "superestructura". ”en el protocolo IP. Su núcleo consta de tres protocolos: También uno de los conceptos clave es la Asociación de Seguridad (SA). Básicamente, SA es un conjunto de parámetros que caracterizan una conexión. Por ejemplo, el algoritmo de cifrado y la función hash utilizados, claves secretas, número de paquete, etc. El encabezado de autenticación (AH) es un encabezado opcional común y normalmente se encuentra entre el encabezado principal del paquete IP y el campo de datos. La presencia de AH no afecta de ninguna manera el proceso de transmisión de información desde el transporte y niveles superiores. El principal y único propósito de AH es brindar protección contra ataques relacionados con cambios no autorizados en el contenido de un paquete, incluida la falsificación de la dirección de origen de la capa de red. Los protocolos de nivel superior deben modificarse para verificar la autenticidad de los datos recibidos. El formato AH es bastante simple y consta de un encabezado de 96 bits y datos de longitud variable que consisten en palabras de 32 bits. Los nombres de los campos reflejan su contenido con bastante claridad: Siguiente encabezado indica el siguiente encabezado, Payload Len representa la longitud del paquete, SPI es un puntero al contexto de seguridad y Sequence Number Field contiene el número de secuencia del paquete. El número de secuencia de paquetes se introdujo en AH en 1997 como parte del proceso de revisión de la especificación IPsec. El valor de este campo lo genera el remitente y sirve para proteger contra ataques relacionados con la reutilización de los datos del proceso de autenticación. Debido a que Internet no garantiza el orden en el que se entregarán los paquetes, el destinatario debe almacenar información sobre el número de secuencia máximo de un paquete autenticado exitosamente y si se ha recibido una cantidad de paquetes que contienen números de secuencia anteriores (generalmente 64). A diferencia de los algoritmos de cálculo de suma de verificación utilizados en los protocolos para transmitir información a través de líneas de comunicación conmutadas o a través de canales de redes locales y destinados a corregir errores aleatorios en el medio de transmisión, los mecanismos para garantizar la integridad de los datos en las redes de telecomunicaciones abiertas deben tener medios de protección contra cambios específicos. Uno de esos mecanismos es un uso especial del algoritmo MD5: durante la formación del AH, se calcula secuencialmente una función hash a partir de la unión del paquete mismo y alguna clave previamente acordada, y luego a partir de la unión del resultado resultante y la clave transformada. Este es el mecanismo predeterminado para garantizar que todas las implementaciones de IPv6 tengan al menos un algoritmo común que no esté sujeto a restricciones de exportación. Cuando se utiliza la encapsulación de datos cifrados, el encabezado ESP es el último de los encabezados opcionales "visibles" en el paquete. Dado que el objetivo principal de ESP es garantizar la confidencialidad de los datos, diferentes tipos de información pueden requerir algoritmos de cifrado significativamente diferentes. En consecuencia, el formato ESP puede sufrir cambios importantes dependiendo de los algoritmos criptográficos utilizados. Sin embargo, se pueden distinguir los siguientes campos obligatorios: SPI, que indica el contexto de seguridad, y Sequence Number Field, que contiene el número de secuencia del paquete. El campo "Datos de autenticación ESP" (suma de verificación) es opcional en el encabezado ESP. El destinatario del paquete ESP descifra el encabezado ESP y utiliza los parámetros y datos del algoritmo de cifrado aplicado para decodificar la información de la capa de transporte. Hay dos modos de utilizar ESP y AH (así como sus combinaciones): transporte y túnel. Una Asociación de Seguridad (SA) es una conexión que proporciona servicios de seguridad para el tráfico que pasa a través de ella. Dos computadoras a cada lado de la SA almacenan el modo, protocolo, algoritmos y claves utilizadas en la SA. Cada SA se utiliza en una sola dirección. La comunicación bidireccional requiere dos SA. Cada SA implementa un modo y protocolo; por lo tanto, si es necesario utilizar dos protocolos para un paquete (como AH y ESP), entonces se requieren dos SA. Para comenzar a intercambiar datos entre dos partes es necesario establecer una conexión denominada SA (Security Association). El concepto de SA es fundamental para IPsec; de hecho, es su esencia. Describe cómo las partes utilizarán los servicios para garantizar una comunicación segura. La conexión SA es simplex (unidireccional), por lo que se deben establecer dos conexiones para que las partes se comuniquen. También vale la pena señalar que los estándares IPsec permiten que los puntos finales de un canal seguro utilicen una SA para transmitir tráfico desde todos los hosts que interactúan a través de este canal, o para crear una cantidad arbitraria de asociaciones seguras para este propósito, por ejemplo, una para cada Conexión TCP. Esto permite elegir el nivel deseado de granularidad de protección. El establecimiento de una conexión comienza con la autenticación mutua de las partes. A continuación, se seleccionan los parámetros (si se realizará autenticación, cifrado, verificación de integridad de los datos) y el protocolo requerido (AH o ESP) para la transmisión de datos. Después de esto, se seleccionan algoritmos específicos (por ejemplo, cifrado, función hash) entre varios esquemas posibles, algunos de los cuales están definidos por el estándar (para cifrado - DES, para funciones hash - MD5 o SHA-1), otros se agregan mediante fabricantes de productos que utilizan IPsec (por ejemplo, Triple DES, Blowfish, CAST). Todas las SA se almacenan en la base de datos SAD (Base de datos de asociaciones de seguridad) del módulo IPsec. Cada SA tiene un marcador único que consta de tres elementos: El módulo IPsec, al tener estos tres parámetros, puede encontrar una entrada en SAD para una SA específica. La lista de componentes SA incluye: Un valor de 32 bits que se utiliza para formar el campo Número de secuencia en los encabezados AH y ESP. Un indicador que indica que el contador del número de secuencia se ha desbordado. Se utiliza para determinar la retransmisión de paquetes. Si el valor en el campo Número de secuencia no se encuentra dentro del rango especificado, el paquete se descarta. el algoritmo de autenticación utilizado, las claves requeridas, la vida útil de la clave y otros parámetros. algoritmos de cifrado y autenticación, claves requeridas, parámetros de inicialización (por ejemplo, IV), vida útil de la clave y otros parámetros túnel o transporte Especificado en segundos o bytes de información que pasa por el túnel. Determina la duración de la existencia de la SA; cuando se alcanza este valor, la SA actual debe finalizar si es necesario, continuar la conexión, se establece una nueva SA; AH se utiliza para autenticar al remitente de información, para garantizar la integridad de los datos y, opcionalmente, puede usarse para proteger contra la retransmisión de datos. La autenticación se lleva a cabo calculando la función hash del paquete IP (se excluyen los campos que pueden cambiar durante la transmisión del paquete (por ejemplo, TTL)). La función hash calculada se agrega al encabezado del paquete AH y se envía al destinatario del paquete. El encabezado AH contiene el campo Valor de verificación de integridad, que se calcula utilizando los algoritmos MD5 o SHA-1. En la práctica, el HMAC (Código de autenticación de mensajes hash) se utiliza con mayor frecuencia, ya que utiliza una clave secreta conocida de antemano por los participantes al calcular la función hash. HMAC, a su vez, utiliza algoritmos MD5 o SHA-1 para calcular la función hash. Dependiendo del algoritmo utilizado, HMAC se llamará HMAC-MD5 o HMAC-SHA-1, respectivamente. El tipo de encabezado de protocolo que viene después del encabezado AH. Al utilizar este campo, el módulo IP-sec receptor aprende sobre el protocolo de nivel superior protegido. El significado de este campo para diferentes protocolos se puede encontrar en RFC 1700. Este campo especifica el tamaño total del encabezado AH en palabras de 32 bits, menos 2. Sin embargo, cuando se utiliza IPv6, la longitud del encabezado debe ser un múltiplo de 8 bytes. Reservado. Lleno de ceros. Índice de parámetros de seguridad. El valor de este campo, junto con la dirección IP de destino y el protocolo de seguridad (protocolo AN), identifica de forma única la conexión virtual segura (SA) para este paquete. El rango de valores SPI de 1 a 255 está reservado por la IANA. Número de serie. Sirve para proteger contra la retransmisión. El campo contiene un valor de parámetro que aumenta monótonamente. Aunque el destinatario puede optar por no recibir la protección de reproducción de paquetes, es obligatoria y siempre está presente en el encabezado AH. El módulo IPsec emisor siempre utiliza este campo, pero es posible que el receptor no lo procese. Firma digital. Sirve para autenticar y comprobar la integridad del paquete. Debe rellenarse hasta un tamaño que sea múltiplo de 8 bytes para IPv6 y de 4 bytes para IPv4. El protocolo AH se utiliza para la autenticación, es decir, para confirmar que nos estamos comunicando con quienes creemos que somos y que los datos que recibimos no se corrompen durante la transmisión. Si el módulo IPsec emisor determina que el paquete está asociado con una SA que implica procesamiento AH, comienza el procesamiento. Dependiendo del modo (modo de transporte o de túnel), inserta el encabezado AH en el paquete IP de manera diferente. En el modo de transporte, el encabezado AH se coloca después del encabezado del protocolo IP y antes de los encabezados del protocolo de capa superior (generalmente TCP o UDP). En el modo de túnel, todo el paquete IP original se enmarca primero en el encabezado AH y luego en el encabezado del protocolo IP. Este encabezado se llama externo y el encabezado del paquete IP original se llama interno. Después de esto, el módulo IPsec transmisor debe generar un número de secuencia y escribirlo en el campo Número de secuencia. Cuando se establece una SA, el número de secuencia se establece en 0 y se incrementa en uno antes de enviar cada paquete IPsec. Además, se comprueba si el contador ha entrado en bucle. Si ha alcanzado su valor máximo, se vuelve a establecer en 0. Si se utiliza el servicio de prevención de reproducción, cuando el contador alcanza su valor máximo, el módulo IPsec emisor restablece el SA. Esto garantiza la protección contra el reenvío de paquetes; el módulo IPsec receptor comprobará el campo Número de secuencia e ignorará los paquetes que llegan repetidamente. A continuación, se calcula la suma de comprobación ICV. Cabe señalar que aquí la suma de verificación se calcula utilizando una clave secreta, sin la cual un atacante podrá recalcular el hash, pero sin conocer la clave, no podrá generar la suma de verificación correcta. Los algoritmos específicos utilizados para calcular ICV se pueden encontrar en RFC 4305. Actualmente, por ejemplo, se pueden utilizar los algoritmos HMAC-SHA1-96 o AES-XCBC-MAC-96. El protocolo AH calcula una suma de comprobación (ICV) basada en los siguientes campos del paquete IPsec: campos del encabezado IP que no estuvieron sujetos a cambios durante el proceso de transmisión, o identificados como el encabezado AH más importante (Campos: “Next Header”, “Payload Len”, “Reserved”, “SPI”, “Sequence Number”, Valor de “verificación de integridad” El campo “Valor de verificación de integridad” se establece en 0 al calcular el ICV de los datos del protocolo de nivel superior. Si el campo puede cambiar durante el transporte, su valor se establece en 0 antes de calcular el ICV. Excepciones son campos que pueden cambiar, pero cuyo valor se puede predecir en la recepción. Al calcular el ICV, no se rellenan con ceros. Un ejemplo de campo variable sería el campo de suma de comprobación. la dirección IP del destinatario. Una descripción más detallada de qué campos se tienen en cuenta al calcular el ICV se puede encontrar en el estándar RFC 2402. Después de recibir un paquete que contiene un mensaje de protocolo AH, el módulo receptor IPsec busca la conexión virtual segura (SA) SAD (Base de datos de asociaciones de seguridad) correspondiente utilizando la dirección IP, el protocolo de seguridad (AN) y el índice SPI del destinatario. Si no se encuentra ninguna SA coincidente, el paquete se descarta. Una conexión virtual segura (SA) encontrada indica si se está utilizando el servicio de prevención de reproducción de paquetes, es decir, la necesidad de verificar el campo Número de secuencia. Si se utiliza el servicio, se marca el campo. Esto utiliza un método de ventana deslizante para limitar la memoria intermedia requerida por el protocolo. El módulo IPsec receptor forma una ventana con un ancho W (normalmente se selecciona W igual a 32 o 64 paquetes). El borde izquierdo de la ventana corresponde al número de secuencia mínimo N de un paquete recibido correctamente. Un paquete con un campo Número de secuencia que contiene un valor que oscila entre N+1 y N+W se recibe correctamente. Si el paquete recibido está en el borde izquierdo de la ventana, se destruye. Luego, el módulo IPsec receptor calcula el ICV a partir de los campos correspondientes del paquete recibido utilizando el algoritmo de autenticación que aprende del registro SA y compara el resultado con el valor ICV ubicado en el campo Valor de verificación de integridad. Si el valor ICV calculado coincide con el recibido, entonces el paquete entrante se considera válido y se acepta para su posterior procesamiento IP. Si la verificación da un resultado negativo, el paquete recibido se destruye. ESP es un protocolo de seguridad que garantiza la confidencialidad y protección de datos. La autenticación (AH) y la detección de repetición son posibles. ESP encapsula completamente los paquetes. ESP se puede utilizar solo o con el uso de AH. El tamaño máximo de paquete que se puede transmitir a través de un canal virtual sin fragmentación. Cada protocolo (ESP/AH) debe tener su propia SA para cada dirección, por lo que la combinación AH+ESP requiere cuatro SA para un canal dúplex. Todos estos datos se encuentran en SAD. Además de la base de datos SAD, las implementaciones de IPsec admiten una base de datos SPD (base de datos de políticas de seguridad). SPD sirve para correlacionar los paquetes IP entrantes con las reglas de procesamiento para ellos. Los registros SPD constan de dos campos. El primero almacena las características de los paquetes, mediante las cuales se puede identificar uno u otro flujo de información. Estos campos se denominan selectores. Ejemplos de selectores que están contenidos en el SPD: El segundo campo del SPD contiene la política de seguridad correspondiente al flujo de paquetes determinado. Los selectores se utilizan para filtrar paquetes salientes para hacer coincidir cada paquete con una SA específica. Cuando llega un paquete, los valores de los campos correspondientes del paquete (campos selectores) se comparan con los contenidos en el SPD. Cuando se encuentra una coincidencia, el campo de política de protección contiene información sobre qué hacer con el paquete: transmitirlo tal cual, descartarlo o procesarlo. En caso de tramitación, el mismo campo contiene un enlace a la entrada correspondiente en el SAD. Luego se determinan el SA del paquete y el índice de parámetros de seguridad (SPI) asociado, y se realizan las operaciones IPsec (operaciones de protocolo AH o ESP). Si el paquete es entrante, inmediatamente contiene SPI; se lleva a cabo el procesamiento adecuado. La política de seguridad se almacena en la SPD (Base de datos de políticas de seguridad). SPD puede especificar una de tres acciones para un paquete de datos: descartar el paquete, no procesar el paquete usando IPSec o procesar el paquete usando IPSec. En este último caso, el SPD también indica qué SA se debe utilizar (si, por supuesto, ya se ha creado una SA adecuada) o indica con qué parámetros se debe crear una nueva SA. SPD es un mecanismo de control muy flexible que permite un muy buen control sobre el procesamiento de cada paquete. Los paquetes se clasifican según una gran cantidad de campos y el SPD puede examinar algunos o todos los campos para determinar la acción adecuada. Esto podría dar como resultado que todo el tráfico entre dos máquinas se transporte utilizando una única SA, o que se utilicen SA separadas para cada aplicación, o incluso para cada conexión TCP. Los sistemas que implementan IPSec deben admitir dos bases de datos: Todos los paquetes IP (entrantes y salientes) se comparan con un conjunto ordenado de reglas de políticas de seguridad. Al comparar, se utiliza el selector que aparece en cada regla: un conjunto de campos analizados del nivel de red y niveles de protocolo superiores. La primera regla adecuada determina el futuro destino del paquete: De esta forma, los sistemas que implementan IPSec funcionan como firewalls, filtrando y transformando los flujos de datos en base a una política de seguridad predefinida. El contexto de seguridad del protocolo en IPSec es una "conexión" unidireccional (de origen a destino) que proporciona a los flujos de datos servidos un conjunto de servicios de seguridad dentro del marco de un único protocolo (AH o ESP). En el caso de interacción simétrica, los socios deberán organizar dos contextos (uno en cada dirección). Si se utilizan tanto AH como ESP, se requieren cuatro contextos. Los elementos de la base de datos de contexto de protocolo contienen los siguientes campos (en cada caso, algunos valores de campo estarán vacíos): Los usuarios de contextos de protocolo suelen ser procesos de aplicación. En términos generales, puede existir un número arbitrario de contextos de protocolo entre dos nodos de red, ya que el número de aplicaciones en los nodos es arbitrario. Los usuarios de los contextos de control suelen ser nodos de red (ya que en estos contextos es deseable concentrar la funcionalidad común requerida por los servicios de seguridad de todas las capas de protocolo del modelo de referencia para la gestión de claves criptográficas). Los contextos de control son bidireccionales, es decir, cualquiera de los socios puede iniciar un nuevo intercambio de claves. Un par de nodos pueden mantener simultáneamente múltiples contextos de control activo si existen aplicaciones con requisitos criptográficos significativamente diferentes. Por ejemplo, es posible generar parte de las claves a partir de material predistribuido, mientras que la otra parte se genera mediante el algoritmo Diffie-Hellman. El contexto del protocolo para IPSec se identifica mediante la dirección IP de destino, el protocolo (AH o ESP) y un valor adicional, el índice de parámetros de seguridad (SPI). El último valor es necesario porque puede haber varios contextos con las mismas direcciones IP y protocolos. A continuación se muestra cómo se utilizan los índices SPI al procesar paquetes entrantes. IPSec exige soporte para la gestión manual y automática de contextos de seguridad y claves criptográficas. En el primer caso, todos los sistemas reciben de antemano material clave y otros datos necesarios para una interacción segura con otros sistemas. En el segundo, el material y los datos se generan dinámicamente, basándose en un protocolo específico, IKE, cuyo soporte es obligatorio. El contexto del protocolo se crea sobre la base del administrador utilizando el material de clave y los medios de autenticación y cifrado de este último. En el caso más simple, cuando las claves de protocolo se generan a partir de las existentes. Cuando se desarrolló el contexto de control, se crearon tres tipos de claves para él: Todos los tipos de claves enumerados participan en el intercambio. Los mensajes se cifran utilizando la clave SKEYID_e. La clave SKEYID_a sirve como argumento para las funciones hash y, por lo tanto, autentica los mensajes. Finalmente, las claves de protocolo son el resultado de aplicar una función pseudoaleatoria (hash) a SKEYID_d con parámetros adicionales, que incluyen el iniciador y los noces de pares. Como resultado, la creación de un contexto de protocolo se autentica y se protege contra accesos no autorizados, reproducción de mensajes y interceptación de conexiones. Los mensajes (1) y (2) pueden transportar una carga útil adicional, por ejemplo, datos para generar claves secretas "completamente nuevas" o identificadores de cliente en nombre de los cuales los servidores ISAKMP forman un contexto de protocolo. Según el protocolo IKE, un intercambio (que consta de los tres mensajes mostrados) crea dos contextos unidireccionales, uno en cada dirección. El destinatario del contexto lo establece en un índice de parámetros de seguridad (SPI), que le ayuda a encontrar un contexto para procesar paquetes IPSec entrantes. Los contextos de protocolo desempeñan un papel de apoyo, siendo sólo un medio para hacer cumplir la política de seguridad; debe configurarse para cada interfaz de red con IPSec habilitado y para cada dirección de flujo de datos (entrante/saliente). Según las especificaciones IPSec, la política está diseñada para procesar paquetes IP sin contexto (de forma independiente), en el espíritu de los enrutadores de filtrado modernos. Por supuesto, debería haber herramientas para administrar la base de datos SPD, así como herramientas para administrar la base de reglas del firewall, pero este no es un aspecto que esté estandarizado. Desde una perspectiva externa, una base de datos de políticas de seguridad (SPD) es un conjunto ordenado de reglas. Cada regla se especifica como un par: Los selectores se utilizan para seleccionar paquetes, los contextos especifican el procesamiento requerido. Si una regla hace referencia a un contexto que no existe, debe contener información suficiente para crearlo dinámicamente. En este caso, se requiere soporte para contexto automático y gestión de claves. En principio, el funcionamiento del sistema puede comenzar configurando la base del SPD con una base de datos de contexto vacía (SAD); este último se llenará según sea necesario. La diferenciación de la política de seguridad está determinada por los selectores utilizados en las reglas. Por ejemplo, un par de hosts en comunicación pueden utilizar un único conjunto de contextos si los selectores incluyen sólo direcciones IP; por otro lado, el conjunto puede ser diferente para cada aplicación si se analizan los números de puerto TCP y UDP. De manera similar, dos puertas de enlace de seguridad son capaces de organizar un único túnel para todos los hosts servidos o dividirlo (organizando diferentes contextos) entre pares de hosts o incluso aplicaciones. Todas las implementaciones de IPSec deben admitir la selección de los siguientes elementos: El procesamiento del tráfico saliente y entrante no es simétrico. Para los paquetes salientes, se escanea la base de datos SPD, se encuentra una regla adecuada, se recuperan los contextos de protocolo asociados con ella y se aplican los mecanismos de seguridad adecuados. Los paquetes entrantes para cada protocolo de seguridad ya tienen un valor SPI, que identifica de forma única el contexto. En este caso, no es necesario visualizar la base de datos SPD; Se puede suponer que la política de seguridad se tuvo en cuenta al crear el contexto adecuado. (En la práctica, esto significa que los paquetes ISAKMP necesitan un tratamiento especial y se deben incluir reglas con selectores apropiados en el SPD). La asimetría observada refleja cierta incompletitud de la arquitectura IPSec. El RFC 1825 anterior no tenía los conceptos de base de datos de políticas de seguridad ni selectores. La nueva edición da medio paso adelante: la visualización de la base de datos SPD se especifica como obligatoria para cada paquete saliente, pero el procesamiento de los paquetes entrantes no cambia. Recuperar el contexto de un índice SPI es más eficiente que ver un conjunto de reglas, pero este enfoque dificulta cambiar rápidamente la política de seguridad. En cuanto a la eficiencia de la exploración de reglas, se puede mejorar mediante técnicas de almacenamiento en caché, que se utilizan ampliamente en implementaciones de IP. ISAKMP define la estructura general de protocolos que se utilizan para establecer SA y realizar otras funciones de gestión clave. ISAKMP soporta varios Dominios de Interpretación (DOI), uno de los cuales es IPSec-DOI. ISAKMP no define un protocolo completo, sino que proporciona "bloques de construcción" para varios DOI y protocolos de intercambio de claves. El protocolo Oakley es un protocolo de descubrimiento de claves que utiliza el algoritmo de reemplazo de claves Diffie-Hellman. El protocolo Oakley admite Perfect Forward Secrecy (PFS). La presencia de PFS significa que es imposible descifrar todo el tráfico si alguna clave del sistema se ve comprometida. Dado que ambas partes de la conversación deben conocer los valores secretos utilizados en el proceso de hash o cifrado, surge la pregunta de cómo se intercambian estos datos. Las claves propias requieren la entrada manual de valores secretos en ambos extremos, presumiblemente transmitidos a través de algún mecanismo externo, y IKE (Internet Key Exchange) proporciona un mecanismo complejo para hacerlo en línea. IKE es el protocolo de intercambio de claves predeterminado para ISAKMP y actualmente es el único. IKE se encuentra encima de ISAKMP y realiza el establecimiento real tanto de ISAKMP SA como de IPSec SA. IKE admite un conjunto de varias funciones primitivas para usar en protocolos. Entre ellas se encuentran la función hash y la función pseudoaleatoria (PRF). Una "función hash" es una función resistente a colisiones. La resistencia a la colisión significa el hecho de que es imposible encontrar dos mensajes diferentes m1 y m2 tales que H(m1)=H(m2), donde H es una función hash. En cuanto a las funciones pseudoaleatorias, actualmente se utiliza una función hash en lugar de PRF especiales en el diseño de HMAC (HMAC es un mecanismo de autenticación de mensajes que utiliza funciones hash). Para definir HMAC, necesitamos una función hash criptográfica (llamémosla H) y una clave secreta K. Suponemos que H es una función hash en la que los datos se procesan mediante un procedimiento de compresión aplicado secuencialmente a una secuencia de bloques de datos. Denotamos con B la longitud de dichos bloques en bytes y la longitud de los bloques obtenidos como resultado del hash con L (L ipad = byte 0x36, repetido B veces; opad = byte 0x5C repetido B veces. IKE combina tres direcciones principales (protocolos separados): IKE contiene dos fases de acuerdo clave. En la primera fase se crea un canal seguro, en la segunda se negocian e intercambian claves y se establece una SA. La primera fase utiliza uno de dos modos: modo principal o modo agresivo. La diferencia entre ellos es el nivel de seguridad y la velocidad de operación. El modo básico, que es más lento, protege toda la información transferida entre nodos. El modo agresivo para acelerar el trabajo deja una serie de parámetros abiertos y vulnerables a las escuchas; se recomienda utilizarlo sólo cuando la velocidad sea un tema crítico; La segunda fase utiliza el modo rápido, llamado así porque no autentica los nodos, asumiendo que esto se hizo en la primera fase. Esta fase asegura el intercambio de claves con las que se cifran los datos. Es posible configurar manualmente una clave para una sesión (no debe confundirse con una clave previamente compartida para autenticación). En este caso, no se utiliza IKE. Sin embargo, esta opción no se recomienda y rara vez se utiliza. Tradicionalmente, IKE opera a través del puerto UDP 500. Existe IKE y una versión más nueva del protocolo: IKEv2. Existen algunas diferencias en las especificaciones y el funcionamiento de estos protocolos. IKEv2 establece los parámetros de conexión en una sola fase que consta de varios pasos. El proceso IKE se puede dividir en dos fases. IKE crea un canal seguro entre dos pares llamado asociación de seguridad IKE (IKE SA). Además, en esta fase, dos nodos acuerdan una clave de sesión utilizando el algoritmo Diffie-Hellman. La primera fase de IKE puede llevarse a cabo en uno de dos modos: Consta de tres intercambios bidireccionales entre el remitente y el destinatario: durante el primer intercambio, los algoritmos y funciones hash que se utilizarán para asegurar la conexión IKE se negocian haciendo coincidir la SA IKE de cada nodo. Utilizando el algoritmo Diffie-Hellman, las partes intercambian una clave secreta compartida. Los nodos también verifican la identificación de cada uno transmitiendo y confirmando una secuencia de números pseudoaleatorios. La identidad de la parte contraria se verifica utilizando la dirección IP cifrada. Como resultado de la ejecución del modo principal, se crea un canal seguro para el intercambio ISAKMP posterior (este protocolo define el procedimiento para autenticar conexiones de nodos, crear y administrar SA, generar claves y mitigar amenazas como ataques DoS o ataques de repetición). Este modo requiere una menor cantidad de intercambios y, en consecuencia, una menor cantidad de paquetes. El primer mensaje contiene casi toda la información necesaria para establecer una IKE SA: la clave pública Diffie-Hellman, para la sincronización de paquetes, confirmada por otro participante, el identificador del paquete. El destinatario devuelve todo lo necesario para completar el intercambio. El primer nodo sólo necesita confirmar la conexión. Desde el punto de vista de la seguridad, el modo agresivo es más débil, ya que los participantes comienzan a intercambiar información antes de establecer un canal seguro, por lo que es posible la interceptación no autorizada de datos. Sin embargo, este modo es más rápido que el principal. Según el estándar IKE, cualquier implementación debe admitir el modo básico y es muy deseable admitir el modo agresivo. En la fase dos de IKE, solo hay un modo rápido. El modo rápido se ejecuta sólo después de la creación de un canal seguro durante la primera fase. Negocia una política IPsec común, obtiene claves secretas compartidas para los algoritmos del protocolo IPsec (AH o ESP) y establece una SA IPsec. El uso de números secuenciales proporciona protección contra ataques de repetición. El modo rápido también se utiliza para revisar la SA IPsec actual y seleccionar una nueva cuando expire la vida útil de la SA. De forma predeterminada, el modo rápido actualiza las claves secretas compartidas utilizando el algoritmo Diffie-Hellman desde la primera fase. Con el tiempo, quedó claro que PSK por sí solo no era suficiente para garantizar la seguridad. Por ejemplo, si la estación de trabajo de un empleado se viera comprometida, el atacante podría obtener acceso inmediato a toda la red interna de la empresa. Por lo tanto, la Fase 1.5 se desarrolló justo entre la primera y la segunda fase clásica. Por cierto, esta fase generalmente no se usa en una conexión VPN estándar de sitio a sitio, pero se usa al organizar conexiones VPN remotas (nuestro caso). Esta fase contiene dos nuevas extensiones: Autenticación extendida (XAUTH) y Configuración de modo (MODECFG). XAUTH es una autenticación adicional de usuarios dentro del protocolo IKE. Esta autenticación a veces también se denomina segundo factor IPsec. MODOCFG sirve para transmitir información adicional al cliente, esta puede ser una dirección IP, máscara, servidor DNS, etc. Se puede observar que esta fase simplemente complementa las comentadas anteriormente, pero su utilidad es indudable. Ambos protocolos operan en el puerto UDP número 500, pero son incompatibles entre sí; no se permite una situación en la que hay IKEv1 en un extremo del túnel y IKEv2 en el otro. Estas son las principales diferencias entre la segunda versión y la primera: Configurar una conexión IPsec implica todo tipo de soluciones criptográficas, pero se simplifica enormemente por el hecho de que una conexión determinada no puede utilizar más de dos o (raramente) tres a la vez. La autenticación calcula el valor de verificación de integridad (ICV) del contenido del paquete y normalmente utiliza un algoritmo hash criptográfico como MD5 o SHA-1. Incluye una clave secreta conocida por ambas partes, permitiendo al destinatario calcular el ICV de la misma forma. Si el destinatario recibe el mismo valor, entonces el remitente ha sido autenticado exitosamente (basado en el supuesto de que los hashes criptográficos son prácticamente imposibles de revertir). AH siempre proporciona autenticación, pero esto es opcional para ESP. El cifrado utiliza una clave secreta para cifrar los datos antes de la transmisión, lo que protege el contenido real del paquete contra escuchas ilegales. Hay bastantes opciones de algoritmos, los más comunes son DES, 3DES, Blowfish y AES. Otros también son posibles. Todos los tipos de ataques a componentes IPSec se pueden dividir en los siguientes grupos: ataques que explotan los recursos finitos del sistema (un ejemplo típico es un ataque de denegación de servicio, denegación de servicio o ataque DOS), ataques que explotan las funciones y errores de una implementación específica de IPSec y, finalmente, ataques basados en las debilidades de los propios protocolos. AH y ESP. Los ataques puramente criptográficos pueden ignorarse: ambos protocolos definen el concepto de "transformación", donde toda la criptografía está oculta. Si el criptoalgoritmo utilizado es estable y la transformación definida con él no introduce debilidades adicionales (este no es siempre el caso, por lo que es más correcto considerar la fortaleza de todo el sistema: protocolo-transformación-algoritmo), entonces De este lado todo está bien. ¿Qué queda? Ataque de repetición: nivelado usando el número de secuencia (en un solo caso esto no funciona: cuando se usa ESP sin autenticación y sin AH). Además, el orden de las acciones (primero el cifrado, luego la autenticación) garantiza un rápido rechazo de los paquetes "malos" (además, según investigaciones recientes en el mundo de la criptografía, este orden de acciones es el más seguro; el orden inverso en algunos, aunque casos muy especiales, pueden dar lugar a posibles agujeros de seguridad; afortunadamente, ni SSL, ni IKE, ni otros protocolos comunes con el orden de acciones “primero autenticar, luego cifrar” no se aplican a estos casos especiales y, por lo tanto, no tienen estos agujeros; ). Lo que queda es el ataque de denegación de servicio. Como saben, se trata de un ataque del que no existe una defensa completa. Sin embargo, el rápido rechazo de los paquetes defectuosos y la ausencia de cualquier reacción externa hacia ellos (según el RFC) permiten afrontar este ataque más o menos bien. En principio, AH y ESP resisten con éxito la mayoría (si no todos) los ataques de red conocidos (rastreo, suplantación de identidad, secuestro, etc.) cuando se usan correctamente. Con IKE es un poco más complicado. El protocolo es muy complejo y difícil de analizar. Además, debido a errores tipográficos (en la fórmula para calcular HASH_R) al escribirlo y soluciones no del todo exitosas (los mismos HASH_R y HASH_I), contiene varios "agujeros" potenciales (en particular, en la primera fase, no todas las cargas útiles en los mensajes están autenticados), sin embargo, no son muy graves y conducen, como máximo, a una negativa a establecer una conexión. IKE se protege con mayor o menor éxito de ataques como la reproducción, la suplantación de identidad, el rastreo y el secuestro. Con la criptografía es algo más complicado: no se lleva a cabo por separado, como en AH y ESP, sino que se implementa en el propio protocolo. Sin embargo, si utiliza algoritmos persistentes y primitivas (PRF), no debería haber problemas. Hasta cierto punto, se puede considerar como una debilidad de IPsec que DES esté indicado como el único algoritmo criptográfico obligatorio en las especificaciones actuales (esto es válido tanto para ESP como para IKE), 56 bits de cuya clave ya no se consideran suficientes. . Sin embargo, esto es una debilidad puramente formal: las especificaciones en sí son independientes de los algoritmos y casi todos los proveedores conocidos han implementado 3DES desde hace mucho tiempo (y algunos ya han implementado AES). Por lo tanto, si se implementa correctamente, el ataque más "peligroso" sigue siendo. Denegación de servicio. Los protocolos IPsec operan en cinco etapas: El protocolo IPsec se utiliza principalmente para organizar túneles VPN. En este caso, los protocolos ESP y AH operan en modo túnel. Además, al configurar las políticas de seguridad de cierta manera, el protocolo se puede utilizar para crear un firewall. El objetivo de un firewall es que controla y filtra los paquetes que lo atraviesan de acuerdo con reglas específicas. Se instala un conjunto de reglas y la pantalla observa todos los paquetes que pasan a través de ella. Si los paquetes transmitidos entran dentro del alcance de estas reglas, el firewall los procesa en consecuencia. Por ejemplo, puede rechazar ciertos paquetes, deteniendo así conexiones inseguras. Al configurar adecuadamente su política de seguridad, puede, por ejemplo, bloquear el tráfico web. Para ello, basta con prohibir el envío de paquetes que contengan mensajes de protocolo HTTP y HTTPS. IPsec también se puede utilizar para proteger servidores; para ello, se descartan todos los paquetes, excepto los necesarios para la correcta ejecución de las funciones del servidor. Por ejemplo, para un servidor web, puede bloquear todo el tráfico excepto las conexiones a través del puerto TCP 80 o a través del puerto TCP 443 en los casos en que se utiliza HTTPS. Aquí se utiliza IPsec para garantizar el acceso seguro de los usuarios al servidor. Cuando se utiliza el protocolo ESP, todas las llamadas al servidor y sus respuestas están cifradas. Sin embargo, los mensajes claros se transmiten detrás de la puerta de enlace VPN (en el dominio de cifrado). Otros ejemplos de uso de IPsec: El protocolo IPSec ha recibido críticas mixtas por parte de los expertos. Por un lado, cabe señalar que el protocolo IPSec es el mejor entre todos los demás protocolos desarrollados anteriormente para proteger los datos transmitidos a través de la red (incluido el PPTP desarrollado por Microsoft). Según la otra parte, el protocolo es excesivamente complejo y redundante. Así, Niels Ferguson y Bruce Schneier en su trabajo "Una evaluación criptográfica de IPsec" señalan que encontraron serios problemas de seguridad en casi todos los componentes principales de IPsec. Estos autores también señalan que el conjunto de protocolos requiere mejoras significativas para que proporcione un buen nivel de seguridad. El artículo describe una serie de ataques que explotan tanto las debilidades del esquema general de procesamiento de datos como las debilidades de los algoritmos criptográficos. IPsec tiene las siguientes ventajas: Aunque IPSec es la solución más popular y posiblemente la mejor para crear redes privadas virtuales, existen algunas limitaciones. Si se utiliza en modo transporte, no se excluye la posibilidad de ataques desde el exterior, lo que se debe a algunas limitaciones del protocolo ISAKMP. El secuestro de sesión IPSec es muy probable si no se utiliza el encabezado de autenticación AH. Con este tipo de ataque, los datos del atacante pueden insertarse en información transmitida útil, por ejemplo, en el caso de los sistemas Unix, basta con insertar el comando rm -R en el flujo para que al destinatario le acaben perdiendo muchos, o incluso todos, archivos en el disco duro. Debido a que el tráfico IPSec es enrutable, varias implementaciones prácticas de IPSec pueden estar sujetas a un ataque más sutil: falsificar la ruta original. Hagamos una reserva de que este tipo de ataque solo es posible cuando se usa IPSec en modo de transporte, pero si se usa para construir un túnel, toda la información de enrutamiento en este caso está cifrada y este tipo de ataque no tendrá éxito. AT&T Research señala que muchas debilidades potenciales en IPSec resultan de debilidades específicas en los algoritmos de cifrado utilizados en una implementación de IPSec particular. Por lo tanto, a medida que aumenta la confiabilidad de estos algoritmos, IPSec puede volverse mucho más seguro. Actualmente, IPSec forma parte de IPv6, pero no de IPv4. Aunque, por supuesto, también existen implementaciones IPSec para la cuarta versión del protocolo IP. La implementación de IPv6 aborda algunas de las debilidades de IPSec que aún existen en la versión IPv4. Por ejemplo, los campos de fragmentación en el encabezado del paquete IPv4 pueden cambiarse potencialmente, por lo que cuando se opera IPSec en modo de transporte, un atacante podría interceptar el paquete y cambiar el campo de fragmentación, y luego insertar los datos necesarios en el flujo transmitido. En IPv6, los enrutadores intermedios no permiten cambios en los campos de fragmentación. Muchos productos que pueden utilizar IPSec interactúan con una tecnología de cifrado alternativa llamada Secure Sockets Layer (SSL). La principal diferencia entre IPSec y SSL es que IPSec opera a nivel de red, asegurando la conexión de red de un extremo a otro. SSL opera a nivel de aplicación y brinda protección solo a una aplicación seleccionada, como un navegador web o un programa de correo electrónico. Aunque tanto IPSec como SSL están diseñados para garantizar la confidencialidad del intercambio de información, esto se logra de formas completamente diferentes. SSL fue desarrollado por Netscape para proteger el tráfico HTTP que pasa a través de un programa de navegador. SSL es un protocolo a nivel de sesión y, en este sentido, sin duda es inferior a IPSec, que le permite construir un túnel permanente que es independiente del tráfico de red que lo atraviesa. El protocolo SSL se basa en un modelo cliente-servidor y normalmente se utiliza para la seguridad de host a host. Debido a que IPSec se comunica a nivel de red, son posibles opciones como subred a subred, red a red o red a host. Esto sugiere que IPSec permite el enrutamiento, pero SSL no. Aunque muchos usuarios consideran que SSL e IPSec son tecnologías competidoras, esta afirmación no es del todo precisa porque IPSec y SSL están destinados a resolver problemas diferentes. Si bien la implementación de IPSec requiere una planificación avanzada de la infraestructura, SSL simplifica mucho las cosas. Como regla general, si tanto el cliente como el servidor son inicialmente capaces de trabajar con SSL, entonces el procedimiento para configurar una sesión segura se reduce a un conjunto de acciones extremadamente trivial, accesible incluso para un usuario novato. A continuación se muestra una tabla que compara IPSec y SSL. En el mundo moderno, se utilizan diversas tecnologías VPN en todas partes. Algunos (por ejemplo, PPTP) se reconocen como inseguros con el tiempo y desaparecen gradualmente, otros (OpenVPN), por el contrario, aumentan su impulso cada año. Pero el líder indiscutible y la tecnología más reconocible para crear y mantener canales privados seguros sigue siendo IPsec VPN. A veces, durante un pentest puedes encontrar una red seriamente protegida en la que solo sobresale el puerto UDP quinientos. Todo lo demás se puede cerrar, parchear y filtrar de forma fiable. En tal situación, puede surgir la idea de que no hay nada especial que hacer aquí. Pero este no es siempre el caso. Además, existe una idea generalizada de que IPsec, incluso en las configuraciones predeterminadas, es inexpugnable y proporciona el nivel adecuado de seguridad. Ésta es exactamente la situación que veremos en la práctica hoy. Pero primero, para combatir IPsec de la manera más efectiva posible, es necesario comprender qué es y cómo funciona. ¡Esto es lo que haremos! El primer tipo sirve para la comunicación constante de varias islas de red, por ejemplo, una oficina central con muchas sucursales dispersas. Bueno, RA VPN es un escenario en el que un cliente se conecta por un corto período de tiempo, obtiene acceso a ciertos recursos de la red y luego se desconecta de manera segura después de completar el trabajo. Nos interesará la segunda opción, ya que en caso de un ataque exitoso, es posible obtener acceso inmediato a la red interna de la empresa, lo cual es un logro bastante importante para un pentester. IPsec, a su vez, le permite implementar VPN de acceso remoto y de sitio a sitio. ¿Qué tipo de tecnología es esta y de qué componentes se compone? Vale la pena señalar que IPsec no es uno, sino un conjunto completo de protocolos diferentes que brindan protección de datos transparente y segura. La especificidad de IPsec es que se implementa en la capa de red, completándola de tal manera que todo pasa desapercibido para las capas posteriores. La principal dificultad es que en el proceso de establecimiento de una conexión, dos participantes en un canal seguro deben acordar una cantidad bastante grande de parámetros diferentes. Es decir, deben autenticarse entre sí, generar e intercambiar claves (y a través de un entorno que no sea de confianza) y también acordar qué protocolos cifrar los datos. Es por ello que IPsec consta de una pila de protocolos cuya responsabilidad es garantizar el establecimiento, funcionamiento y gestión de una conexión segura. Todo el proceso de establecimiento de conexión consta de dos fases: la primera fase se utiliza para garantizar el intercambio seguro de mensajes ISAKMP en la segunda fase. ISAKMP (Protocolo de administración de claves y asociación de seguridad de Internet) es un protocolo que sirve para negociar y actualizar políticas de seguridad (SA) entre los participantes en una conexión VPN. Estas políticas indican específicamente qué protocolo utilizar para cifrar (AES o 3DES) y con qué autenticarse (SHA o MD5). En cuanto a IKEv2, sus primeros borradores se realizaron en 2005, se describió completamente en RFC 5996 (2010) y recién a fines del año pasado se anunció como estándar de Internet (RFC 7296). Puede leer más sobre las diferencias entre IKEv1 e IKEv2 en la barra lateral. Habiendo abordado IKE, volvemos a las fases de IPsec. Durante la primera fase, los participantes se autentican entre sí y acuerdan los parámetros para establecer una conexión especial destinada únicamente a intercambiar información sobre los algoritmos de cifrado deseados y otros detalles del futuro túnel IPsec. Los parámetros de este primer túnel (también llamado túnel ISAKMP) están determinados por la política ISAKMP. El primer paso es acordar los hashes y los algoritmos de cifrado, luego se produce un intercambio de claves Diffie-Hellman (DH), y sólo entonces se determina quién es quién. Es decir, el último paso es el proceso de autenticación, ya sea mediante clave PSK o RSA. Y si las partes llegan a un acuerdo, se establece un túnel ISAKMP, por el que ya pasa la segunda fase de IKE. En la segunda fase, los participantes que ya confían entre sí acuerdan cómo construir el túnel principal para la transferencia directa de datos. Se ofrecen mutuamente las opciones especificadas en el parámetro transform-set y, si están de acuerdo, levantan el túnel principal. Es importante enfatizar que una vez establecido, el túnel ISAKMP auxiliar no va a ninguna parte: se utiliza para actualizar periódicamente el SA del túnel principal. Como resultado, IPsec de alguna manera establece no uno, sino dos túneles. Por ejemplo, el comando `crypto ipsec transform-set SET10 esp-aes` indicará al enrutador que el transform-set con el nombre `SET10` solo debe funcionar usando el protocolo ESP y con cifrado AES. De cara al futuro, diré que de ahora en adelante utilizaremos enrutadores y firewalls de Cisco como objetivos. En realidad, con ESP todo está más o menos claro, su trabajo es cifrar y así garantizar la confidencialidad, pero ¿por qué entonces se necesita AH? AH proporciona autenticación de datos, es decir, confirma que estos datos provienen exactamente de aquel con quien establecimos la conexión y no fueron modificados en el camino. Proporciona lo que a veces se denomina protección antirrepetición. En las redes modernas, AH prácticamente no se utiliza; solo se puede encontrar ESP en todas partes. Los parámetros (también conocidos como SA) seleccionados para cifrar información en un túnel IPsec tienen una vida útil, después de la cual deben ser reemplazados. La configuración predeterminada de IPsec SA de duración es de 86.400 segundos o 24 horas. Como resultado, los participantes recibieron un túnel cifrado con parámetros adecuados para todos y enviaron flujos de datos para cifrarlos allí. Periódicamente, de acuerdo con la vida útil, las claves de cifrado del túnel principal se actualizan: los participantes se comunican nuevamente a través del túnel ISAKMP, pasan por la segunda fase y restablecen la SA. Bueno, todo el cifrado posterior se produce sin cambios, como de costumbre. ¿Por qué entonces se sigue utilizando este modo? El hecho es que es mucho más rápido, aproximadamente el doble de rápido. De particular interés para el pentester es el hecho de que el modo agresivo se usa muy a menudo en RA IPsec VPN. Otra pequeña característica de RA IPsec VPN cuando se usa el modo agresivo: cuando el cliente contacta al servidor, le envía un identificador (nombre de grupo). El nombre del grupo de túneles (consulte la Figura 2) es el nombre de una entrada que contiene un conjunto de políticas para una conexión IPsec determinada. Esta ya es una de las características específicas de los equipos Cisco. XAUTH es una autenticación de usuario adicional dentro del protocolo IKE. Esta autenticación a veces también se denomina segundo factor IPsec. Bueno, MODECFG sirve para transmitir información adicional al cliente, esta podría ser una dirección IP, máscara, servidor DNS, etc. Se puede observar que esta fase simplemente complementa las comentadas anteriormente, pero su utilidad es indudable. En IKEv2 ya no existen conceptos como modos agresivos o principales. El primer paso es determinar la presencia de una puerta de enlace VPN IPsec. Esto se puede hacer realizando un escaneo de puertos, pero aquí hay una pequeña característica. ISAKMP utiliza el protocolo UDP, puerto 500, mientras que el escaneo predeterminado con Nmap afecta sólo a los puertos TCP. Y como resultado aparecerá un mensaje: "Se han filtrado los 1000 puertos escaneados en 37.59.0.253". Parece que todos los puertos están filtrados y no hay ningún puerto abierto. Pero después de ejecutar el comando Nmap -sU --top-ports=20 37.59.0.253 Iniciando Nmap 6.47 (http://nmap.org) el 21 de marzo de 2015 a las 12:29 GMT Informe de escaneo de Nmap para 37.59.0.253 El host está activo (latencia de 0,066 s) . SERVICIO ESTADO PUERTO 500/udp abierto isakmp Root@kali:~# ike-scan -M -A 37.59.0.253 0 apretón de manos devuelto; 0 devuelto notificar El interruptor `-A` indica que se debe usar el modo agresivo y `-M` indica que los resultados deben mostrarse línea por línea (multilínea), para facilitar la lectura. Está claro que no se obtuvo ningún resultado. El motivo es que debe especificar el mismo identificador, el nombre del grupo VPN. Por supuesto, la utilidad ike-scan le permite configurar este identificador como uno de sus parámetros. Pero como todavía lo desconocemos, tomemos un valor arbitrario, por ejemplo 0000. Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Se devolvió el protocolo de enlace en modo agresivo Esta vez vemos que se recibió la respuesta (ver Fig. 5) y se nos proporcionó bastante información útil. Una parte bastante importante de la información recibida es el conjunto de transformaciones. En nuestro caso, indica que “Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK”. Todos estos parámetros se pueden especificar para la utilidad ike-scan usando el interruptor `--trans`. Por ejemplo, `--trans=5,2,1,2` indicará que el algoritmo de cifrado es 3DES, hash HMAC-SHA, método de autenticación PSK y el segundo grupo tipo DH (MODP de 1024 bits). Puede consultar las tablas de correspondencia de valores en esta dirección. Agreguemos una clave más (`-P`) para mostrar la carga útil del paquete directamente, o más bien el hash PSK. Raíz@kali:~# ike-scan -M -A --id=0000 37.59.0.253 -P La cuestión es que existe una ligera diferencia entre las respuestas durante el intercambio inicial de mensajes. En resumen, si se utiliza el nombre de grupo correcto, hay cuatro intentos de continuar estableciendo la conexión VPN más dos paquetes cifrados de fase dos. Mientras que en el caso de una identificación incorrecta, solo llegan dos paquetes como respuesta. Como puede ver, la diferencia es bastante significativa, por lo que SpiderLabs (el autor de la igualmente interesante herramienta Responder) desarrolló primero un PoC y luego la utilidad IKEForce para explotar esta vulnerabilidad. Clon de Git https://github.com/SpiderLabs/ikeforce Python ikeforce.py 37.59.0.253 -e -w listas de palabras/group.txt -t 5 2 1 2 Como resultado, fue posible obtener el valor de ID correcto con bastante rapidez (Fig. 7). El primer paso se ha completado, puedes seguir adelante. Ike-escaneo -M -A --id=vpn 37.59.0.253 -Pkey.psk Psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk Pero incluso restaurar PSK con éxito (ver Fig. 8) es sólo la mitad de la batalla. En esta etapa, debemos recordar que lo que nos espera a continuación es XAUTH y el segundo factor de IPsec VPN. Python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+]Programa iniciado en modo de fuerza bruta XAUTH [+]Proporcionado por un solo usuario - fuerza bruta contraseñas para el usuario: admin [*] ¡Autenticación XAUTH exitosa! Nombre de usuario: admin Contraseña: cisco En este caso, se indican todos los valores encontrados anteriormente: ID (cambiador `-i`), PSK restaurado (cambiador `-k`) y el inicio de sesión deseado (cambiador `-u`). IKEForce admite tanto la búsqueda por fuerza bruta de un inicio de sesión como la búsqueda a través de una lista de inicios de sesión, que se puede especificar con el parámetro `-U`. En caso de posible bloqueo de selección, existe la opción `-s`, que permite reducir la velocidad de fuerza bruta. Por cierto, la utilidad viene con varios diccionarios buenos, especialmente útiles para configurar el valor del parámetro ID. Puerta de enlace IPSec 37.59.0.253 Aquí vemos que se utilizaron absolutamente todos los datos encontrados en los pasos anteriores: el valor de ID, PSK, nombre de usuario y contraseña del segundo factor. Después de lo cual la conexión se produce con un comando: Raíz@kali:~# vpnc vpn Root@kali:~# vpnc-desconexión Suscríbete a "hackers" (Internet Security Association and Key Management Protocol (ISAKMP)) - Gestión de claves y autenticadores para conexiones seguras. Los protocolos IPsec, a diferencia de otros protocolos conocidos SSL y TLS, operan en la capa de red (capa 3 del modelo OSI). Esto hace que IPsec sea más flexible para que pueda usarse para proteger cualquier protocolo basado en TCP y UDP. IPsec se puede utilizar para proporcionar seguridad entre dos hosts IP, entre dos puertas de enlace de seguridad o entre un host IP y una puerta de enlace de seguridad. El protocolo es una "superestructura" encima del protocolo IP y procesa los paquetes IP generados de la manera que se describe a continuación. IPsec puede garantizar la integridad y/o confidencialidad de los datos transmitidos a través de una red. IPsec utiliza los siguientes protocolos para realizar diversas funciones: El concepto de "Conexión Virtual Segura" (SA, "Asociación de Seguridad") es fundamental para la arquitectura IPsec. Una SA es una conexión simplex que se forma para transportar el tráfico apropiado a través de ella. Al implementar servicios de seguridad, se forma una SA basada en el uso de los protocolos AH o ESP (o ambos al mismo tiempo). SA se define de acuerdo con el concepto de conexión entre terminales (punto a punto) y puede operar en dos modos: modo de transporte (RTR) y modo de túnel (RTU). El modo de transporte se implementa con SA entre dos nodos IP. En el modo de túnel, la SA forma un túnel IP. Todas las SA se almacenan en la SADB (Base de datos de asociaciones de seguridad) del módulo IPsec. Cada SA tiene un token único que consta de tres elementos: El módulo IPsec, que tiene estos tres parámetros, puede encontrar una entrada en la SADB para una SA específica. La lista de componentes SA incluye: Dado que las conexiones virtuales seguras (SA) son simplex, se necesitan al menos dos SA para organizar un canal dúplex. Además, cada protocolo (ESP/AH) debe tener su propia SA para cada dirección, es decir, la combinación AH+ESP requiere cuatro SA. Todos estos datos se encuentran en SADB. Además de SADB, las implementaciones de IPsec admiten una SPD (base de datos de políticas de seguridad). Una entrada SPD consta de un conjunto de valores de campo de encabezado IP y campos de encabezado de protocolo de capa superior. Estos campos se denominan selectores. Los selectores se utilizan para filtrar paquetes salientes para hacer coincidir cada paquete con una SA específica. Cuando se genera un paquete, los valores de los campos correspondientes del paquete (campos selectores) se comparan con los contenidos en el SPD. Se encuentran las SA correspondientes. Luego se determina la SA (si la hay) para el paquete y su índice de parámetros de seguridad (SPI) asociado. Después de lo cual se realizan las operaciones IPsec (operaciones de protocolo AH o ESP). Ejemplos de selectores que están contenidos en el SPD: El protocolo AH se utiliza para la autenticación, es decir, para confirmar que nos estamos comunicando con quienes creemos que somos y que los datos que recibimos no se corrompen durante la transmisión. Si el módulo IPsec emisor determina que el paquete está asociado con una SA que implica procesamiento AH, comienza el procesamiento. Dependiendo del modo (modo de transporte o de túnel), inserta el encabezado AH en el paquete IP de manera diferente. En el modo de transporte, el encabezado AH se coloca después del encabezado del protocolo IP y antes de los encabezados del protocolo de capa superior (generalmente TCP o UDP). En el modo de túnel, todo el paquete IP original se enmarca primero en el encabezado AH y luego en el encabezado del protocolo IP. Este encabezado se llama externo y el encabezado del paquete IP original se llama interno. Después de esto, el módulo IPsec emisor debe generar un número de serie y escribirlo en el campo Número de secuencia. Cuando se establece una SA, el número de secuencia se establece en 0 y se incrementa en uno antes de enviar cada paquete IPsec. Además, se comprueba si el contador ha entrado en bucle. Si ha alcanzado su valor máximo, se vuelve a establecer en 0. Si se utiliza el servicio de prevención de reproducción, cuando el contador alcanza su valor máximo, el módulo IPsec emisor restablece el SA. Esto garantiza la protección contra el reenvío de paquetes: el módulo IPsec receptor comprobará el campo Número de secuencia e ignorar los paquetes que vuelven a llegar. A continuación, se calcula la suma de comprobación ICV. Cabe señalar que aquí la suma de verificación se calcula utilizando una clave secreta, sin la cual un atacante podrá recalcular el hash, pero sin conocer la clave, no podrá generar la suma de verificación correcta. Los algoritmos específicos utilizados para calcular ICV se pueden encontrar en RFC 4305. Actualmente, por ejemplo, se pueden utilizar los algoritmos HMAC-SHA1-96 o AES-XCBC-MAC-96. El protocolo AH calcula una suma de comprobación (ICV) basada en los siguientes campos del paquete IPsec: Después de recibir un paquete que contiene un mensaje del protocolo AH, el módulo receptor IPsec busca la SADB (Base de datos de asociaciones de seguridad) correspondiente utilizando la dirección IP del destinatario, el protocolo de seguridad (SA) y el índice SPI. Si no se encuentra ninguna SA coincidente, el paquete se descarta. La conexión virtual segura (SA) encontrada indica si se está utilizando el servicio de prevención de reproducción de paquetes, es decir, sobre la necesidad de verificar el campo Número de secuencia. Si se utiliza el servicio, se marca el campo. Para ello se utiliza el método de la ventana corredera. El módulo IPsec receptor genera una ventana con un ancho de W. El borde izquierdo de la ventana corresponde al número de secuencia mínimo ( Número de secuencia) N de paquetes recibidos correctamente. Paquete con campo Número de secuencia, que contiene un valor que oscila entre N+1 y N+W, se acepta correctamente. Si el paquete recibido está en el borde izquierdo de la ventana, se destruye. Luego, el módulo receptor IPsec calcula el ICV a partir de los campos correspondientes del paquete recibido utilizando el algoritmo de autenticación que aprende del registro SA y compara el resultado con el valor ICV ubicado en el campo Valor de verificación de integridad. Si el valor ICV calculado coincide con el recibido, entonces el paquete entrante se considera válido y se acepta para su posterior procesamiento IP. Si la verificación es negativa, el paquete receptor se destruye. Si el módulo IPsec emisor determina que el paquete está asociado con una SA que requiere procesamiento ESP, comienza el procesamiento. Dependiendo del modo (modo de transporte o de túnel), el paquete IP original se procesa de forma diferente. En modo transporte, el módulo IPsec transmisor lleva a cabo el procedimiento de encuadrar (encapsular) el protocolo de nivel superior (por ejemplo, TCP o UDP), utilizando el encabezado ESP y el final ESP, sin afectar el encabezado del paquete IP de origen. En el modo de túnel, el paquete IP está rodeado por un encabezado ESP y un final ESP, y luego está rodeado por un encabezado IP externo. A continuación, se realiza el cifrado: en modo de transporte, solo se cifra el mensaje de protocolo sobre la capa subyacente (es decir, todo lo que estaba después del encabezado IP en el paquete de origen), en modo de túnel, todo el paquete IP de origen. El módulo IPsec emisor determina el algoritmo de cifrado y la clave secreta del registro SA. Los estándares IPsec permiten el uso de algoritmos de cifrado triple DES, AES y Blowfish. Dado que el tamaño del texto plano debe ser múltiplo de un determinado número de bytes, por ejemplo el tamaño del bloque en los algoritmos de bloque, el relleno necesario del mensaje cifrado también se realiza antes del cifrado. El mensaje cifrado se coloca en el campo. Datos de carga útil. en el campo Longitud de la almohadilla se ajusta a la longitud de la adición. Luego, como en AH, se calcula Número de secuencia. Después de lo cual se calcula la suma de verificación (ICV). La suma de comprobación, a diferencia del protocolo AH, donde también se tienen en cuenta algunos campos del encabezado IP al calcularlo, en ESP se calcula solo a partir de los campos del paquete ESP menos el campo ICV. Se llena de ceros antes de calcular la suma de verificación. El algoritmo de cálculo ICV, como en el protocolo AH, lo aprende el módulo IPsec transmisor a partir del registro del SA al que está asociado el paquete que se está procesando. Después de recibir un paquete que contiene un mensaje del protocolo ESP, el módulo receptor IPsec busca la conexión virtual segura (SA) correspondiente en la SADB (Base de datos de asociaciones de seguridad) utilizando la dirección IP, el protocolo de seguridad (ESP) y el índice SPI del destinatario. Si no se encuentra ninguna SA coincidente, el paquete se descarta. La conexión virtual segura (SA) encontrada indica si se está utilizando el servicio de prevención de reproducción de paquetes, es decir, la necesidad de verificar el campo Número de secuencia. Si se utiliza el servicio, se marca el campo. Para ello, al igual que en AH, se utiliza el método de la ventana deslizante. El módulo IPsec receptor genera una ventana con un ancho de W. El borde izquierdo de la ventana corresponde al número de secuencia mínimo N de un paquete recibido correctamente. Un paquete con un campo Número de secuencia que contiene un valor que oscila entre N+1 y N+W se recibe correctamente. Si el paquete recibido está en el borde izquierdo de la ventana, se destruye. Luego, si se utiliza el servicio de autenticación, el módulo receptor IPsec calcula el ICV a partir de los campos apropiados del paquete recibido utilizando el algoritmo de autenticación que aprende del registro SA y compara el resultado con el valor ICV ubicado en el campo Valor de verificación de integridad. Si el valor ICV calculado coincide con el recibido, entonces el paquete entrante se considera válido. Si la verificación es negativa, el paquete receptor se destruye. A continuación, se descifra el paquete. El módulo receptor IPsec aprende del registro SA qué algoritmo de cifrado se utiliza y la clave secreta. Cabe señalar que el procedimiento de verificación y descifrado de la suma de verificación se puede realizar no solo de forma secuencial, sino también en paralelo. En este último caso, el procedimiento de verificación de la suma de control debe finalizar antes que el procedimiento de descifrado, y si la verificación ICV falla, el procedimiento de descifrado también debe finalizar. Esto le permite identificar rápidamente paquetes corruptos, lo que, a su vez, aumenta el nivel de protección contra ataques de denegación de servicio (ataques DOS). El siguiente es el mensaje descifrado de acuerdo con el campo Siguiente encabezado transferido para su posterior procesamiento. El protocolo IPsec se utiliza principalmente para organizar túneles VPN. En este caso, los protocolos ESP y AH operan en modo túnel. Además, al configurar las políticas de seguridad de cierta manera, el protocolo se puede utilizar para crear un firewall. El objetivo de un firewall es que controla y filtra los paquetes que lo atraviesan de acuerdo con reglas específicas. Se instala un conjunto de reglas y la pantalla observa todos los paquetes que pasan a través de ella. Si los paquetes transmitidos entran dentro del alcance de estas reglas, el firewall los procesa en consecuencia. Por ejemplo, puede rechazar ciertos paquetes, deteniendo así conexiones inseguras. Al configurar la política de seguridad en consecuencia, puede, por ejemplo, bloquear el tráfico de Internet. Para ello, basta con prohibir el envío de paquetes que contengan mensajes de protocolo HTTP y HTTPS. IPsec también se puede utilizar para proteger servidores; para ello, se descartan todos los paquetes, excepto los necesarios para la correcta ejecución de las funciones del servidor. Por ejemplo, para un servidor web, puede bloquear todo el tráfico excepto las conexiones a través del puerto TCP 80 o a través del puerto TCP 443 en los casos en que se utiliza HTTPS. En el mundo moderno, se utilizan diversas tecnologías VPN en todas partes. Algunos (por ejemplo, PPTP) se reconocen como inseguros con el tiempo y desaparecen gradualmente, otros (OpenVPN), por el contrario, aumentan su impulso cada año. Pero el líder indiscutible y la tecnología más reconocible para crear y mantener canales privados seguros sigue siendo IPsec VPN. A veces, durante un pentest puedes encontrar una red seriamente protegida en la que solo sobresale el puerto UDP quinientos. Todo lo demás se puede cerrar, parchear y filtrar de forma fiable. En tal situación, puede surgir la idea de que no hay nada especial que hacer aquí. Pero este no es siempre el caso. Además, existe una idea generalizada de que IPsec, incluso en las configuraciones predeterminadas, es inexpugnable y proporciona el nivel adecuado de seguridad. Ésta es exactamente la situación que veremos en la práctica hoy. Pero primero, para combatir IPsec de la manera más efectiva posible, es necesario comprender qué es y cómo funciona. ¡Esto es lo que haremos! Antes de pasar directamente al propio IPsec, sería bueno recordar qué tipos de VPN existen. Hay muchas clasificaciones de VPN, pero no profundizaremos en las tecnologías de red y elegiremos la más simple. Por lo tanto, dividiremos las VPN en dos tipos principales: conexiones VPN de sitio a sitio (también pueden denominarse permanentes) y VPN de acceso remoto (RA, también temporal). Nos interesará la segunda opción, ya que en caso de un ataque exitoso, es posible obtener acceso inmediato a la red interna de la empresa, lo cual es un logro bastante importante para un pentester. IPsec, a su vez, le permite implementar VPN de acceso remoto y de sitio a sitio. ¿Qué tipo de tecnología es esta y de qué componentes se compone? Vale la pena señalar que IPsec no es uno, sino un conjunto completo de protocolos diferentes que brindan protección de datos transparente y segura. La especificidad de IPsec es que se implementa en la capa de red, completándola de tal manera que todo pasa desapercibido para las capas posteriores. La principal dificultad es que en el proceso de establecimiento de una conexión, dos participantes en un canal seguro deben acordar una cantidad bastante grande de parámetros diferentes. Es decir, deben autenticarse entre sí, generar e intercambiar claves (y a través de un entorno que no sea de confianza) y también acordar qué protocolos cifrar los datos. Es por ello que IPsec consta de una pila de protocolos cuya responsabilidad es garantizar el establecimiento, funcionamiento y gestión de una conexión segura. Todo el proceso de establecimiento de conexión consta de dos fases: la primera fase se utiliza para garantizar el intercambio seguro de mensajes ISAKMP en la segunda fase. ISAKMP (Protocolo de administración de claves y asociación de seguridad de Internet) es un protocolo que sirve para negociar y actualizar políticas de seguridad (SA) entre los participantes en una conexión VPN. Estas políticas indican específicamente qué protocolo utilizar para cifrar (AES o 3DES) y con qué autenticarse (SHA o MD5). Entonces, descubrimos que los participantes primero deben ponerse de acuerdo sobre qué mecanismos se utilizarán para crear una conexión segura, por lo que ahora entra en juego el protocolo IKE. IKE (Internet Key Exchange) se utiliza para formar una IPsec SA (Security Association, esas mismas políticas de seguridad), es decir, para coordinar el trabajo de los participantes en una conexión segura. A través de este protocolo, los participantes acuerdan qué algoritmo de cifrado se utilizará, qué algoritmo se utilizará para comprobar la integridad y cómo autenticarse entre sí. Cabe señalar que hoy en día existen dos versiones del protocolo: IKEv1 e IKEv2. Solo nos interesará IKEv1: a pesar de que el IETF (The Internet Engineering Task Force) lo introdujo por primera vez en 1998, todavía se usa con mucha frecuencia, especialmente para RA VPN (ver Figura 1). En cuanto a IKEv2, sus primeros borradores se realizaron en 2005, se describió completamente en RFC 5996 (2010) y recién a fines del año pasado se anunció como estándar de Internet (RFC 7296). Puede leer más sobre las diferencias entre IKEv1 e IKEv2 en la barra lateral. Habiendo abordado IKE, volvemos a las fases de IPsec. Durante la primera fase, los participantes se autentican entre sí y acuerdan los parámetros para establecer una conexión especial destinada únicamente a intercambiar información sobre los algoritmos de cifrado deseados y otros detalles del futuro túnel IPsec. Los parámetros de este primer túnel (también llamado túnel ISAKMP) están determinados por la política ISAKMP. El primer paso es acordar hashes y algoritmos de cifrado, luego intercambiar claves Diffie-Hellman (DH) y solo entonces descubrir quién es quién. Es decir, el último paso es el proceso de autenticación, ya sea mediante clave PSK o RSA. Y si las partes llegan a un acuerdo, se establece un túnel ISAKMP, por el que ya pasa la segunda fase de IKE. En la segunda fase, los participantes que ya confían entre sí acuerdan cómo construir el túnel principal para la transferencia directa de datos. Se ofrecen mutuamente las opciones especificadas en el parámetro transform-set y, si están de acuerdo, levantan el túnel principal. Es importante enfatizar que una vez establecido, el túnel ISAKMP auxiliar no va a ninguna parte: se utiliza para actualizar periódicamente el SA del túnel principal. Como resultado, IPsec de alguna manera establece no uno, sino dos túneles. Ahora unas palabras sobre el conjunto de transformaciones. Después de todo, es necesario cifrar de alguna manera los datos que atraviesan el túnel. Por lo tanto, en una configuración típica, transform-set es un conjunto de parámetros que indican explícitamente cómo se debe procesar el paquete. En consecuencia, existen dos opciones para dicho procesamiento de datos: los protocolos ESP y AH. ESP (Encapsulating Security Payload) se ocupa directamente del cifrado de datos y también puede proporcionar verificación de la integridad de los datos. AH (Encabezado de autenticación), a su vez, solo es responsable de autenticar la fuente y verificar la integridad de los datos. Por ejemplo, el comando crypto ipsec transform-set SET10 esp-aes le indicará al enrutador que el conjunto de transformación denominado SET10 solo debería funcionar utilizando el protocolo ESP y con cifrado AES. De cara al futuro, diré que de ahora en adelante utilizaremos enrutadores y firewalls de Cisco como objetivos. En realidad, con ESP todo está más o menos claro, su trabajo es cifrar y así garantizar la confidencialidad, pero ¿por qué entonces se necesita AH? AH proporciona autenticación de datos, es decir, confirma que estos datos provienen exactamente de aquel con quien establecimos la conexión y no fueron modificados en el camino. Proporciona lo que a veces se denomina protección antirrepetición. En las redes modernas, AH prácticamente no se utiliza; solo se puede encontrar ESP en todas partes. Los parámetros (también conocidos como SA) seleccionados para cifrar información en un túnel IPsec tienen una vida útil, después de la cual deben ser reemplazados. La configuración predeterminada de IPsec SA de duración es de 86.400 segundos o 24 horas. Hemos echado un vistazo rápido a la mecánica básica de cómo funciona IPsec, pero hay algunas cosas más en las que debemos centrarnos. La primera fase, entre otras cosas, puede funcionar en dos modos: modo principal o modo agresivo. Ya hemos comentado la primera opción arriba, pero nos interesa el modo agresivo. Este modo utiliza tres mensajes (en lugar de seis en el modo principal). En este caso, quien inicia la conexión proporciona todos sus datos a la vez: lo que quiere y lo que puede hacer, así como su parte del intercambio DH. Luego, el respondedor completa inmediatamente su parte de la generación DH. Como resultado, en este modo existen esencialmente sólo dos etapas. Es decir, las dos primeras etapas del modo principal (acuerdo hash e intercambio DH) están, por así decirlo, comprimidas en una. Como resultado, este modo es mucho más peligroso debido al hecho de que la respuesta viene con mucha información técnica en texto plano. Y lo más importante, la puerta de enlace VPN puede enviar un hash de contraseña, que se utiliza para la autenticación en la primera fase (esta contraseña a menudo se denomina clave precompartida o PSK). Bueno, todo el cifrado posterior se produce sin cambios, como de costumbre. ¿Por qué entonces se sigue utilizando este modo? El hecho es que es mucho más rápido, aproximadamente el doble de rápido. De particular interés para el pentester es el hecho de que el modo agresivo se usa muy a menudo en RA IPsec VPN. Otra pequeña característica de RA IPsec VPN cuando se usa el modo agresivo: cuando el cliente contacta al servidor, le envía un identificador (nombre de grupo). El nombre del grupo de túneles (consulte la Figura 2) es el nombre de una entrada que contiene un conjunto de políticas para una conexión IPsec determinada. Esta ya es una de las características específicas de los equipos Cisco. Parecería que este no es un esquema de trabajo muy simple, pero en realidad es un poco más complicado. Con el tiempo, quedó claro que PSK por sí solo no era suficiente para garantizar la seguridad. Por ejemplo, si la estación de trabajo de un empleado se viera comprometida, el atacante podría obtener acceso inmediato a toda la red interna de la empresa. Por lo tanto, la Fase 1.5 se desarrolló justo entre la primera y la segunda fase clásica. Por cierto, esta fase generalmente no se usa en una conexión VPN estándar de sitio a sitio, pero se usa al organizar conexiones VPN remotas (nuestro caso). Esta fase contiene dos nuevas extensiones: Autenticación extendida (XAUTH) y Configuración de modo (MODECFG). XAUTH es una autenticación de usuario adicional dentro del protocolo IKE. Esta autenticación a veces también se denomina segundo factor IPsec. Bueno, MODECFG sirve para transmitir información adicional al cliente, esta podría ser una dirección IP, máscara, servidor DNS, etc. Se puede observar que esta fase simplemente complementa las comentadas anteriormente, pero su utilidad es indudable. Ambos protocolos operan en el puerto UDP número 500, pero son incompatibles entre sí; no se permite una situación en la que hay IKEv1 en un extremo del túnel y IKEv2 en el otro. Estas son las principales diferencias entre la segunda versión y la primera: Una vez que finalmente haya comprendido las características operativas de IPsec y sus componentes, puede pasar a lo principal: los ataques prácticos. La topología será bastante simple y al mismo tiempo cercana a la realidad (ver Fig. 3). El primer paso es determinar la presencia de una puerta de enlace VPN IPsec. Esto se puede hacer realizando un escaneo de puertos, pero aquí hay una pequeña característica. ISAKMP utiliza el protocolo UDP, puerto 500, mientras que el escaneo predeterminado con Nmap afecta sólo a los puertos TCP. Y como resultado aparecerá un mensaje: Se filtran los 1000 puertos escaneados en 37.59.0.253. Parece que todos los puertos están filtrados y no hay ningún puerto abierto. Pero después de ejecutar el comando Nmap -sU --top-ports=20 37.59.0.253 Iniciando Nmap 6.47 (http://nmap.org) el 21 de marzo de 2015 a las 12:29 GMT Informe de escaneo de Nmap para 37.59.0.253 El host está activo (latencia de 0,066 s) . SERVICIO ESTADO PUERTO 500/udp abierto isakmp Nos aseguramos de que este no sea el caso y que efectivamente se trate de un dispositivo VPN. Ahora nos interesará la primera fase, el modo agresivo y la autenticación mediante clave precompartida (PSK). En este escenario, como recordamos, el dispositivo VPN o el respondedor envía un PSK con hash al iniciador. Una de las utilidades más famosas para probar el protocolo IKE es ike-scan, está incluida en la distribución Kali Linux. Ike-scan le permite enviar mensajes IKE con varios parámetros y, en consecuencia, decodificar y analizar paquetes de respuesta. Intentemos sondear el dispositivo de destino: Root@kali:~# ike-scan -M -A 37.59.0.253 0 apretón de manos devuelto; 0 devuelto notificar El modificador -A indica que se debe utilizar el modo agresivo y -M indica que los resultados deben mostrarse línea por línea (multilínea), para una lectura más conveniente. Está claro que no se obtuvo ningún resultado. El motivo es que debe especificar el mismo identificador, el nombre del grupo VPN. Por supuesto, la utilidad ike-scan le permite configurar este identificador como uno de sus parámetros. Pero como todavía lo desconocemos, tomemos un valor arbitrario, por ejemplo 0000. Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Se devolvió el protocolo de enlace en modo agresivo Esta vez vemos que se recibió la respuesta (ver Fig. 5) y se nos proporcionó bastante información útil. Una parte bastante importante de la información recibida es el conjunto de transformaciones. En nuestro caso, indica que “Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK”. Todos estos parámetros se pueden especificar para la utilidad ike-scan usando el interruptor --trans. Por ejemplo, --trans=5,2,1,2 indicará que el algoritmo de cifrado es 3DES, hash HMAC-SHA, método de autenticación PSK y el segundo tipo de grupo DH (MODP de 1024 bits). Puede consultar las tablas de correspondencia de valores en esta dirección. Agreguemos otra clave (-P) para mostrar la carga útil del paquete directamente, o más bien el hash PSK. Raíz@kali:~# ike-scan -M -A --id=0000 37.59.0.253 -P Parecería que se ha obtenido el hash y puedes intentar triturarlo, pero no todo es tan sencillo. Érase una vez, en 2005, algunos hardware de Cisco tenían una vulnerabilidad: estos dispositivos daban un hash sólo si el atacante pasaba el valor de ID correcto. Ahora, por supuesto, es casi imposible encontrar dicho equipo y siempre se envía un valor hash, independientemente de si el atacante envió el valor de ID correcto o no. Obviamente, el hash de fuerza bruta no tiene sentido. Por lo tanto, la primera tarea es determinar el valor de ID correcto para obtener el hash correcto. Y una vulnerabilidad descubierta recientemente nos ayudará con esto. La cuestión es que existe una ligera diferencia entre las respuestas durante el intercambio inicial de mensajes. En resumen, si se utiliza el nombre de grupo correcto, hay cuatro intentos de continuar estableciendo la conexión VPN más dos paquetes cifrados de fase dos. Mientras que en el caso de una identificación incorrecta, solo llegan dos paquetes como respuesta. Como puede ver, la diferencia es bastante significativa, por lo que SpiderLabs (el autor de la igualmente interesante herramienta Responder) desarrolló primero un PoC y luego la utilidad IKEForce para explotar esta vulnerabilidad. Puede instalar IKEForce en un directorio arbitrario ejecutando el comando Clon de Git https://github.com/SpiderLabs/ikeforce Funciona en dos modos principales: modo de cálculo -e (enumeración) y modo de fuerza bruta -b (fuerza bruta). Llegaremos al segundo cuando analicemos los ataques al segundo factor, pero ahora nos ocuparemos del primero. Antes de comenzar el proceso real de determinar el ID, debe establecer el valor exacto de transform-set. Ya lo hemos definido anteriormente, por lo que lo especificaremos con la opción -t 5 2 1 2. Como resultado, el proceso de búsqueda de la identificación se verá así: Python ikeforce.py 37.59.0.253 -e -w listas de palabras/group.txt -t 5 2 1 2 Como resultado, fue posible obtener el valor de ID correcto con bastante rapidez (Fig. 7). El primer paso se ha completado, puedes seguir adelante. Ahora necesita guardar el hash PSK en un archivo usando el nombre de grupo correcto. Esto se puede hacer usando ike-scan: Ike-escaneo -M -A --id=vpn 37.59.0.253 -Pkey.psk Y ahora que se encontró el valor de ID correcto y se obtuvo el hash PSK correcto, finalmente podemos comenzar con la fuerza bruta sin conexión. Hay muchas opciones para tal fuerza bruta: esta es la utilidad clásica psk-crack, John the Ripper (con un parche gigante), e incluso oclHashcat, que, como saben, le permite usar el poder de GPU. Para simplificar, usaremos psk-crack, que admite tanto fuerza bruta directa como ataque de diccionario: Psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk Pero incluso restaurar PSK con éxito (ver Fig. 8) es sólo la mitad de la batalla. En esta etapa, debemos recordar que lo que nos espera a continuación es XAUTH y el segundo factor de IPsec VPN. Entonces déjame recordarte que XAUTH es una seguridad adicional, un segundo factor de autenticación, y se encuentra en la fase 1.5. Puede haber varias opciones para XAUTH: esto incluye verificación mediante el protocolo RADIUS, contraseñas de un solo uso (OTP) y una base de usuarios local habitual. Nos centraremos en la situación estándar en la que se utiliza una base de usuarios local para comprobar el segundo factor. Hasta hace poco, no existía ninguna herramienta públicamente disponible para XAUTH de fuerza bruta. Pero con la llegada de IKEForce, este problema recibió una solución digna. Lanzar la fuerza bruta XAUTH es bastante sencillo: Python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+]Programa iniciado en modo de fuerza bruta XAUTH [+]Proporcionado por un solo usuario - fuerza bruta contraseñas para el usuario: admin [*] ¡Autenticación XAUTH exitosa! Nombre de usuario: admin Contraseña: cisco En este caso, se indican todos los valores encontrados anteriormente: ID (interruptor -i), PSK restaurado (interruptor -k) e inicio de sesión esperado (interruptor -u). IKEForce admite tanto la búsqueda por fuerza bruta de un inicio de sesión como la búsqueda a través de una lista de inicios de sesión, que se puede especificar con el parámetro -U. En caso de posible bloqueo de selección, existe la opción -s, que permite reducir la velocidad de fuerza bruta. Por cierto, la utilidad viene con varios diccionarios buenos, especialmente útiles para configurar el valor del parámetro ID. Ahora que tenemos todos los datos, queda el último paso: penetrar en la red local. Para ello necesitaremos algún tipo de cliente VPN, de los cuales hay muchísimos. Pero en el caso de Kali, puedes utilizar fácilmente el VPNC ya preinstalado. Para que funcione, necesita ajustar un archivo de configuración: /etc/vpnc/vpn.conf. Si no existe, entonces deberá crear y completar una serie de parámetros obvios: Puerta de enlace IPSec 37.59.0.253 ID de IPSec vpn Secreto de IPSec cisco123 IKE Authmode psk Xauth Nombre de usuario admin Xauth contraseña cisco Aquí vemos que se utilizaron absolutamente todos los datos encontrados en los pasos anteriores: el valor de ID, PSK, nombre de usuario y contraseña del segundo factor. Después de lo cual la conexión se produce con un comando: Raíz@kali:~# vpnc vpn Deshabilitarlo también es bastante simple: Root@kali:~# vpnc-desconexión Puede comprobar si la conexión funciona utilizando el comando ifconfig tun0. La protección contra los ataques discutidos hoy debe ser integral: es necesario instalar parches a tiempo, usar claves fuertes precompartidas que, si es posible, deben reemplazarse con certificados digitales. La política de contraseñas y otros elementos obvios de la seguridad de la información también desempeñan un papel importante para garantizar la seguridad. También cabe señalar que la situación está cambiando gradualmente y, con el tiempo, solo quedará IKEv2. Hemos cubierto en detalle el proceso de auditoría de RA IPsec VPN. Sí, por supuesto, esta tarea está lejos de ser trivial. Debe dar muchos pasos y es posible que le aguarden dificultades en cada uno de ellos, pero si tiene éxito, el resultado es más que impresionante. Obtener acceso a los recursos de la red interna abre un margen más amplio para acciones futuras. Por lo tanto, quienes son responsables de proteger el perímetro de la red no deben confiar en plantillas predeterminadas ya preparadas, sino pensar detenidamente en cada capa de seguridad. Bueno, para aquellos que realizan pentests, el puerto UDP 500 detectado es una razón para realizar un análisis profundo de la seguridad de VPN IPsec y, posiblemente, obtener buenos resultados.
opad = byte 0x5C repetido B veces.Ataques a AH, ESP e IKE.
Evaluación de protocolo
Conclusión
Peculiaridades
IPSec
SSL
Independencia del hardware
Sí
Sí
Código
No se requieren cambios en la aplicación. Puede requerir acceso al código fuente de la pila TCP/IP.
Se requieren cambios en la aplicación. Es posible que se requieran nuevas DLL o acceso al código fuente de la aplicación.
Protección
Paquete IP completo. Habilita la protección para protocolos de nivel superior.
Solo nivel de aplicación.
Filtrado de paquetes
Basado en encabezados autenticados, direcciones de remitente y destinatario, etc. Sencillo y barato. Adecuado para enrutadores.
Basado en contenido y semántica de alto nivel. Más inteligente y más complejo.
Actuación
Menos cambios de contexto y movimiento de datos.
Más cambios de contexto y movimiento de datos. Grandes bloques de datos pueden acelerar las operaciones criptográficas y proporcionar una mejor compresión.
Plataformas
Cualquier sistema, incluidos enrutadores.
Principalmente sistemas finales (clientes/servidores), también firewalls.
Cortafuegos/VPN
Todo el tráfico está protegido.
Sólo se protege el tráfico a nivel de aplicación. ICMP, RSVP, QoS, etc. puede estar desprotegido.
Transparencia
Para usuarios y aplicaciones.
Sólo para usuarios.
Estado actual
Estándar emergente.
Ampliamente utilizado por los navegadores WWW, también utilizado por algunos otros productos.
Campo de golf
Expresiones de gratitud
Breves antecedentes históricos de la aparición del protocolo
Peculiaridades
Conceptos básicos
Estándares
Arquitectura IPSec
Encabezado AH
encabezado ESP
AH y ESP
Asociaciones de seguridad
Base de datos de asociaciones de seguridad
Número de serie
Desbordamiento del contador de números de secuencia
Ventana para suprimir ataques de repetición
Información AH
información ESP
Modo de funcionamiento IPsec
Vida útil de SA
Encabezado de autenticación
"Formato de encabezado de autenticación"
Compensaciones
Octeto 16
0
1
2
3
Octeto 16
Bit 10
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
0
0
Siguiente encabezado
Longitud de carga útil
Reservado
4
32
Índice de parámetros de seguridad (SPI)
8
64
Número de secuencia
do
96
Valor de verificación de integridad (ICV)
...
...
Siguiente tipo de encabezado (8 bits)
Longitud del contenido (8 bits)
Reservado (16 bits)
Índice de parámetros del sistema de seguridad (32 bits)
Número de secuencia (32 bits)
Datos de autenticación
Procesamiento de paquetes IP de salida
Procesamiento de paquetes IP de entrada
Encapsulación de carga útil de seguridad
MTU
Política de seguridad
ISAKMP/Oakley
IKE
IKE (pronunciado ike, abreviatura de Internet Key Exchange) es un protocolo que vincula todos los componentes IPsec en un todo funcional. En particular, IKE proporciona autenticación inicial de las partes, así como el intercambio de claves secretas compartidas.Primera fase
Modo básico
Modo agresivo
Segunda fase
Además
IKEv2 frente a IKEv1
MD5, SHA-1, etc.
Ataques a AH, ESP e IKE
Cómo funciona IPsec
Uso
Evaluación de protocolo
Ventajas y desventajas
Competidores
Comparación de IPSec y SSL
Peculiaridades
IPSec
SSL
"Independencia del hardware"
Sí
Sí
"Código"
No se requieren cambios en la aplicación. Puede requerir acceso al código fuente de la pila TCP/IP.
Se requieren cambios en la aplicación. Es posible que se requieran nuevas DLL o acceso al código fuente de la aplicación.
Proteja todo el paquete IP.
Habilita la protección para protocolos de nivel superior.
Solo nivel de aplicación.
Filtrado de paquetes
Basado en encabezados autenticados, direcciones de remitente y destinatario, etc. Sencillo y barato. Adecuado para enrutadores
Basado en contenido y semántica de alto nivel. Más inteligente y más complejo.
Actuación
Menos cambios de contexto y movimiento de datos.
Más cambios de contexto y movimiento de datos. Grandes bloques de datos pueden acelerar las operaciones criptográficas y proporcionar una mejor compresión.
Plataformas
Cualquier sistema, incluidos enrutadores.
Principalmente sistemas finales (clientes/servidores), también firewalls.
Cortafuegos/VPN
Todo el tráfico está protegido.
Sólo se protege el tráfico a nivel de aplicación. ICMP, RSVP, QoS, etc. puede estar desprotegido.
Transparencia
Para usuarios y aplicaciones
Sólo para usuarios.
Estado actual
Estándar emergente.
Ampliamente utilizado por los navegadores WWW, también utilizado por algunos otros productos.
Fuentes
Campo de golf
IPsec desde el interior
Antes de pasar directamente al propio IPsec, sería bueno recordar qué tipos de VPN existen. Hay muchas clasificaciones de VPN, pero no profundizaremos en las tecnologías de red y elegiremos la más simple. Por lo tanto, dividiremos las VPN en dos tipos principales: conexiones VPN de sitio a sitio (también pueden denominarse permanentes) y VPN de acceso remoto (RA, también temporal). Dos fases principales de IPsec
Entonces, descubrimos que los participantes primero deben ponerse de acuerdo sobre qué mecanismos se utilizarán para crear una conexión segura, por lo que ahora entra en juego el protocolo IKE. IKE (Internet Key Exchange) se utiliza para formar una IPsec SA (Security Association, esas mismas políticas de seguridad), es decir, para coordinar el trabajo de los participantes en una conexión segura. A través de este protocolo, los participantes acuerdan qué algoritmo de cifrado se utilizará, qué algoritmo se utilizará para comprobar la integridad y cómo autenticarse entre sí. Cabe señalar que hoy en día existen dos versiones del protocolo: IKEv1 e IKEv2. Solo nos interesará IKEv1: a pesar de que el IETF (The Internet Engineering Task Force) lo introdujo por primera vez en 1998, todavía se usa con mucha frecuencia, especialmente para RA VPN (ver Figura 1). 
Arroz. 1. Asistente de VPN de Cisco ASDMCómo procesar datos
Ahora unas palabras sobre el conjunto de transformaciones. Después de todo, es necesario cifrar de alguna manera los datos que atraviesan el túnel. Por lo tanto, en una configuración típica, transform-set es un conjunto de parámetros que indican explícitamente cómo se debe procesar el paquete. En consecuencia, existen dos opciones para dicho procesamiento de datos: los protocolos ESP y AH. ESP (Encapsulating Security Payload) se ocupa directamente del cifrado de datos y también puede proporcionar verificación de la integridad de los datos. AH (Encabezado de autenticación), a su vez, solo es responsable de autenticar la fuente y verificar la integridad de los datos. Modos IKEv1
Hemos echado un vistazo rápido a la mecánica básica de cómo funciona IPsec, pero hay algunas cosas más en las que debemos centrarnos. La primera fase, entre otras cosas, puede funcionar en dos modos: modo principal o modo agresivo. Ya hemos comentado la primera opción arriba, pero nos interesa el modo agresivo. Este modo utiliza tres mensajes (en lugar de seis en el modo principal). En este caso, quien inicia la conexión proporciona todos sus datos a la vez: lo que quiere y lo que puede hacer, así como su parte del intercambio DH. Luego, el respondedor completa inmediatamente su parte de la generación DH. Como resultado, en este modo existen esencialmente sólo dos etapas. Es decir, las dos primeras etapas del modo principal (acuerdo hash e intercambio DH) están, por así decirlo, comprimidas en una. Como resultado, este modo es mucho más peligroso debido al hecho de que la respuesta viene con mucha información técnica en texto plano. Y lo más importante, la puerta de enlace VPN puede enviar un hash de contraseña, que se utiliza para la autenticación en la primera fase (esta contraseña a menudo se denomina clave precompartida o PSK). 
Arroz. 2. Nombre del grupo de túnelesDos fases no fueron suficientes
Parecería que este no es un esquema de trabajo muy simple, pero en realidad es un poco más complicado. Con el tiempo, quedó claro que PSK por sí solo no era suficiente para garantizar la seguridad. Por ejemplo, si la estación de trabajo de un empleado se viera comprometida, el atacante podría obtener acceso inmediato a toda la red interna de la empresa. Por lo tanto, la Fase 1.5 se desarrolló justo entre la primera y la segunda fase clásica. Por cierto, esta fase generalmente no se usa en una conexión VPN estándar de sitio a sitio, pero se usa al organizar conexiones VPN remotas (nuestro caso). Esta fase contiene dos nuevas extensiones: Autenticación extendida (XAUTH) y Configuración de modo (MODECFG). IKEv2 frente a IKEv1
Ambos protocolos operan en el puerto UDP número 500, pero son incompatibles entre sí; no se permite una situación en la que hay IKEv1 en un extremo del túnel y IKEv2 en el otro. Estas son las principales diferencias entre la segunda versión y la primera:
- En IKEv2, el término primera fase se reemplaza por IKE_SA_INIT (un intercambio de dos mensajes que asegura la negociación de protocolos de cifrado/hashing y la generación de claves DH), y la segunda fase se reemplaza por IKE_AUTH (también dos mensajes que implementan autenticación sí mismo).
- Mode Config (lo que se llamaba fase 1.5 en IKEv1) ahora se describe directamente en la especificación del protocolo y es una parte integral de la misma.
- IKEv2 agregó un mecanismo adicional para proteger contra ataques DoS. Su esencia es que antes de responder a cada solicitud para establecer una conexión segura (IKE_SA_INIT) IKEv2, la puerta de enlace VPN envía una determinada cookie a la fuente de dicha solicitud y espera una respuesta. Si la fuente respondió: todo está en orden, puedes comenzar a generar DH con él. Si la fuente no responde (esto es lo que sucede en el caso de un ataque DoS; esta técnica recuerda a la inundación TCP SYN), entonces la puerta de enlace VPN simplemente se olvida. Sin este mecanismo, con cada solicitud de cualquier persona, la puerta de enlace VPN intentaría generar una clave DH (que es un proceso que consume bastantes recursos) y pronto tendría problemas. Como resultado, debido al hecho de que ahora todas las operaciones requieren confirmación del otro lado de la conexión, es imposible crear una gran cantidad de sesiones medio abiertas en el dispositivo atacado.Estamos alcanzando el hito
Una vez que finalmente haya comprendido las características operativas de IPsec y sus componentes, puede pasar a lo principal: los ataques prácticos. La topología será bastante simple y al mismo tiempo cercana a la realidad (ver Fig. 3). 
Arroz. 3. Diagrama general de red
Nos aseguramos de que este no sea el caso y que efectivamente se trate de un dispositivo VPN.Ataquemos la primera fase
Ahora nos interesará la primera fase, el modo agresivo y la autenticación mediante clave precompartida (PSK). En este escenario, como recordamos, el dispositivo VPN o el respondedor envía un PSK con hash al iniciador. Una de las utilidades más famosas para probar el protocolo IKE es ike-scan, está incluida en la distribución Kali Linux. Ike-scan le permite enviar mensajes IKE con varios parámetros y, en consecuencia, decodificar y analizar paquetes de respuesta. Intentemos sondear el dispositivo de destino:
Arroz. 4. Modo agresivo de escaneo Ike
Arroz. 5. Identificación de escaneo de Ike
Arroz. 6. Carga útil del escaneo IkeSuperar las primeras dificultades
Parecería que se ha obtenido el hash y puedes intentar triturarlo, pero no todo es tan sencillo. Érase una vez, en 2005, algunos hardware de Cisco tenían una vulnerabilidad: estos dispositivos daban un hash sólo si el atacante pasaba el valor de ID correcto. Ahora, por supuesto, es casi imposible encontrar dicho equipo y siempre se envía un valor hash, independientemente de si el atacante envió el valor de ID correcto o no. Obviamente, el hash de fuerza bruta no tiene sentido. Por lo tanto, la primera tarea es determinar el valor de ID correcto para obtener el hash correcto. Y una vulnerabilidad descubierta recientemente nos ayudará con esto. ¿Cuál es la fuerza de IKE?
Puede instalar IKEForce en un directorio arbitrario ejecutando el comando
Funciona en dos modos principales: modo de cálculo `-e` (enumeración) y modo de fuerza bruta `-b` (fuerza bruta). Llegaremos al segundo cuando analicemos los ataques al segundo factor, pero ahora nos ocuparemos del primero. Antes de comenzar el proceso real de determinar el ID, debe establecer el valor exacto de transform-set. Ya lo hemos definido anteriormente, por lo que lo especificaremos con la opción `-t 5 2 1 2`. Como resultado, el proceso de búsqueda de la identificación se verá así:
Arroz. 7. Enumeración IKEForceRecibimos PSK
Ahora necesita guardar el hash PSK en un archivo usando el nombre de grupo correcto. Esto se puede hacer usando ike-scan:
Y ahora que se encontró el valor de ID correcto y se obtuvo el hash PSK correcto, finalmente podemos comenzar con la fuerza bruta sin conexión. Hay muchas opciones para tal fuerza bruta: esta es la utilidad clásica psk-crack, John the Ripper (con un parche gigante), e incluso oclHashcat, que, como saben, le permite usar el poder de GPU. Para simplificar, usaremos psk-crack, que admite tanto fuerza bruta directa como ataque de diccionario:
Arroz. 8. Psk-crackLidiando con el segundo factor IPsec
Entonces déjame recordarte que XAUTH es una seguridad adicional, un segundo factor de autenticación, y se encuentra en la fase 1.5. Puede haber varias opciones para XAUTH: esto incluye verificación mediante el protocolo RADIUS, contraseñas de un solo uso (OTP) y una base de usuarios local habitual. Nos centraremos en la situación estándar en la que se utiliza una base de usuarios local para comprobar el segundo factor. Hasta hace poco, no existía ninguna herramienta públicamente disponible para XAUTH de fuerza bruta. Pero con la llegada de IKEForce, este problema recibió una solución digna. Lanzar la fuerza bruta XAUTH es bastante sencillo: 
Arroz. 9. IKEForce XAUTHIniciar sesión en la red interna
Ahora que tenemos todos los datos, queda el último paso: penetrar en la red local. Para ello necesitaremos algún tipo de cliente VPN, de los cuales hay muchísimos. Pero en el caso de Kali, puedes utilizar fácilmente el VPNC ya preinstalado. Para que funcione, necesita ajustar un archivo de configuración: `/etc/vpnc/vpn.conf`. Si no existe, entonces deberá crear y completar una serie de parámetros obvios:
VPN de identificación IPSec
Cisco secreto IPSec123
Modo de autenticación IKE psk
Xauth Nombre de usuario administrador
contraseña xauth cisco
Deshabilitarlo también es bastante simple:
Puede verificar la funcionalidad de la conexión usando el comando `ifconfig tun0`. 
Arroz. 10. VPNCCómo construir una protección confiable
La protección contra los ataques discutidos hoy debe ser integral: es necesario instalar parches a tiempo, usar claves fuertes precompartidas que, si es posible, deben reemplazarse con certificados digitales. La política de contraseñas y otros elementos obvios de la seguridad de la información también desempeñan un papel importante para garantizar la seguridad. También cabe señalar que la situación está cambiando gradualmente y, con el tiempo, solo quedará IKEv2. ¿Cuál es el resultado?
Hemos cubierto en detalle el proceso de auditoría de RA IPsec VPN. Sí, por supuesto, esta tarea está lejos de ser trivial. Debe dar muchos pasos y es posible que le aguarden dificultades en cada uno de ellos, pero si tiene éxito, el resultado es más que impresionante. Obtener acceso a los recursos de la red interna abre un margen más amplio para acciones futuras. Por lo tanto, quienes son responsables de proteger el perímetro de la red no deben confiar en plantillas predeterminadas ya preparadas, sino pensar detenidamente en cada capa de seguridad. Bueno, para aquellos que realizan pentests, el puerto UDP 500 detectado es una razón para realizar un análisis profundo de la seguridad de VPN IPsec y, posiblemente, obtener buenos resultados. 
Arquitectura IPsec
Asociación de seguridad
Encabezado de autenticación
Encabezado de autenticación formato
Siguiente encabezado(8 bits) El tipo de encabezado de protocolo que viene después del encabezado AH. Al utilizar este campo, el módulo IP-sec receptor aprende sobre el protocolo de nivel superior protegido. El significado de este campo para diferentes protocolos se puede encontrar en RFC 1700. Longitud de carga útil(8 bits) Este campo especifica el tamaño total del encabezado AH en palabras de 32 bits, menos 2. Sin embargo, cuando se utiliza IPv6, la longitud del encabezado debe ser un múltiplo de 8 bytes. Reservado(16 bits) Reservado. Lleno de ceros. Índice de parámetros de seguridad(32 bits) Índice de parámetros de seguridad. El valor de este campo, junto con la dirección IP de destino y el protocolo de seguridad (protocolo AN), identifica de forma única la conexión virtual segura (SA) para este paquete. El rango de valores SPI de 1 a 255 está reservado por la IANA. Número de secuencia(32 bits) Número de serie. Sirve para proteger contra la retransmisión. El campo contiene un valor de parámetro que aumenta monótonamente. Aunque el destinatario puede optar por no recibir la protección de reproducción de paquetes, es obligatoria y siempre está presente en el encabezado AH. El módulo IPsec emisor siempre utiliza este campo, pero es posible que el receptor no lo procese. Valor de verificación de integridadCompensaciones
Octeto 16
0
1
2
3
Octeto 16
Bit 10
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
0
0
Siguiente encabezado
Longitud de carga útil
Reservado
4
32
8
64
Número de secuencia
do
96
Valor de verificación de integridad (ICV)
…
…
…
Procesamiento de paquetes IP de salida
Si un campo puede cambiar durante el transporte, su valor se establece en 0 antes de calcular el ICV. Las excepciones son campos que pueden cambiar, pero cuyo valor se puede predecir al recibirlo. Al calcular los ICV, no se rellenan con ceros. Un ejemplo de un campo mutable sería el campo de suma de comprobación; un ejemplo de un campo mutable pero predefinido sería la dirección IP del destinatario. Puede encontrar una descripción más detallada de qué campos se tienen en cuenta al calcular el ICV en el estándar RFC 2402. Procesamiento de paquetes IP de entrada
Encapsulación de carga útil de seguridad formato
Índice de parámetros de seguridad(32 bits) Índice de parámetros de seguridad. El valor de este campo, junto con la dirección IP de destino y el protocolo de seguridad (protocolo AN), identifica de forma única la conexión virtual segura (SA) para este paquete. La IANA reserva el rango de valores SPI de 1 a 255 para uso futuro. Número de secuencia(32 bits) Número de serie. Sirve para proteger contra la retransmisión. El campo contiene un valor de parámetro que aumenta monótonamente. Aunque el destinatario puede rechazar el servicio de protección de retransmisión de paquetes, siempre está presente en el encabezado AH. El remitente (el módulo IPsec emisor) DEBE utilizar siempre este campo, pero es posible que el destinatario no necesite procesarlo. Datos de carga útil(variable) Este campo contiene datos según el campo "Siguiente encabezado". Este campo es obligatorio y consta de un número entero de bytes. Si el algoritmo que se utiliza para cifrar este campo requiere datos para sincronizar procesos criptográficos (por ejemplo, un vector de inicialización), entonces este campo puede contener estos datos explícitamente. Relleno(0-255 octetos) Adición. Necesario, por ejemplo, para algoritmos que requieren que el texto sin formato sea un múltiplo de una cierta cantidad de bytes), como el tamaño de bloque para un cifrado de bloque. Longitud de la almohadilla(8 bits) El tamaño del relleno (en bytes). Siguiente encabezado(8 bits) Este campo especifica el tipo de datos contenidos en el campo "Datos de carga útil". Valor de verificación de integridad Suma de comprobación. Debe ser un múltiplo de 8 bytes para IPv6 y de 4 bytes para IPv4. Compensaciones
Octeto 16
0
1
2
3
Octeto 16
Bit 10
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
0
0
Índice de parámetros de seguridad (SPI)
4
32
Número de secuencia
8
64
Datos de carga útil
…
…
…
…
…
…
Relleno (0-255 octetos)
…
…
Longitud de la almohadilla
Siguiente encabezado
…
…
Valor de verificación de integridad (ICV)
…
…
…
Procesamiento de paquetes de salida IPsec
Procesamiento de paquetes IPsec entrantes
Uso
Ver también
Campo de golf
Redes privadas virtuales (VPN)
Software
IPsec desde el interior
El primer tipo sirve para la comunicación constante de varias islas de red, por ejemplo, una oficina central con muchas sucursales dispersas. Bueno, RA VPN es un escenario en el que un cliente se conecta por un corto período de tiempo, obtiene acceso a ciertos recursos de la red y luego se desconecta de manera segura después de completar el trabajo.Dos fases principales de IPsec
Cómo procesar datos
Como resultado, los participantes recibieron un túnel cifrado con parámetros adecuados para todos y enviaron flujos de datos para cifrarlos allí. Periódicamente, de acuerdo con la vida útil, las claves de cifrado del túnel principal se actualizan: los participantes se comunican nuevamente a través del túnel ISAKMP, pasan por la segunda fase y restablecen la SA.Modos IKEv1
Dos fases no fueron suficientes
IKEv2 frente a IKEv1
Estamos alcanzando el hito
Ataquemos la primera fase
Superar las primeras dificultades
¿Cuál es la fuerza de IKE?
Recibimos PSK
Lidiando con el segundo factor IPsec
Iniciar sesión en la red interna
Cómo construir una protección confiable
¿Cuál es el resultado?
