CCNA SECURITY Capítulo 8: La implementación de redes privadas virtuales

Capítulo 8: La implementación de redes privadas virtuales

Las organizaciones utilizan redes privadas virtuales (VPN ) para crear una conexión de red privada de extremo a extremo a través de redes de terceros , tales como Internet o extranets . Las VPN utilizan un túnel para permitir a los usuarios remotos acceder a los recursos de red centrales sitio. Sin embargo , las VPN no puede garantizar que la información permanezca segura mientras está atravesando el túnel . Por esta razón , los métodos criptográficos modernos se aplican a las VPN para establecer , de extremo a extremo , conexiones seguras de red privada .

El protocolo de seguridad IP ( IPsec ) proporciona un marco para configurar VPN seguras . Es una forma segura de mantener la privacidad de la comunicación al tiempo que agiliza las operaciones , reducir los costos, y que permite la administración de red flexible . Secure VPN de sitio a sitio, entre los sitios centrales y remotas , se pueden implementar utilizando IPsec .

La introducción de redes privadas virtuales

Una VPN es una red privada que se crea sobre una red pública, por lo general la Internet, como se muestra en la Figura 1. En lugar de utilizar una conexión física dedicada, una VPN utiliza conexiones virtuales enrutados a través de la Internet de la organización en el sitio remoto. Las primeras redes privadas virtuales eran estrictamente túneles IP que no incluían la autenticación o el cifrado de los datos. Por ejemplo, encapsulación de enrutamiento genérico (GRE) es un protocolo de túnel desarrollado por Cisco que puede encapsular una amplia variedad de tipos de paquetes de capa de red de protocolo dentro de túneles IP. Esto crea un enlace virtual punto a punto a los routers de Cisco en puntos remotos a través de una interconexión de redes IP. Las principales ventajas de las VPN se muestran en la Figura 2. Una VPN es virtual en la que lleva la información dentro de una red privada, pero que la información es en realidad transportados sobre una red pública. Una VPN es privado en que el tráfico se cifra para mantener los datos confidenciales mientras se transporta a través de la red pública. Una VPN es un entorno de comunicaciones en el que el acceso está estrictamente controlada para permitir conexiones entre pares dentro de una comunidad de interés definida. La confidencialidad se logra mediante el cifrado del tráfico dentro de la VPN. Hoy en día, una aplicación segura de VPN con encriptación es lo que generalmente se equipara con el concepto de red privada virtual.

Capa 3 IPsec VPN 

En el sentido más simple, una VPN conecta dos puntos finales , tales como dos oficinas remotas , en una red pública para formar una conexión lógica . Las conexiones lógicas se pueden realizar en cualquiera de Capa 2 o Capa 3. En este capítulo se centra en la Capa 3 La tecnología VPN . Los ejemplos más comunes de VPN de capa 3 son GRE , conmutación por etiquetas multiprotocolo ( MPLS ) , e IPsec . VPN de capa 3 pueden ser las conexiones del sitio de punto a punto , como el GRE e IPsec , o pueden establecer ningún any-to - conectividad a muchos sitios utilizando MPLS . Este curso se centra en IPsec VPN . GRE y MPLS están más allá del alcance de este curso .

IPsec es un conjunto de protocolos desarrollados con el respaldo de la IETF para lograr la seguridad de los servicios a través de redes de conmutación de paquetes IP , como se muestra en la figura. servicios de IPsec permiten la autenticación, integridad , control de acceso y confidencialidad . Con IPsec , la información intercambiada entre los sitios remotos se pueden cifrar y verificado . Tanto el acceso remoto y VPN de sitio a sitio se pueden implementar mediante IPsec .

Dos tipos de redes privadas virtuales 

Como se muestra en las figuras 1 y 2 , hay dos tipos básicos de VPN de acceso remoto : y de sitio a sitio. Una VPN de acceso remoto se crea cuando la información VPN no está configurado de forma estática , pero en cambio permite cambiar dinámicamente la información de conexión , que se puede activar y desactivar cuando sea necesario. Un sitio a sitio VPN se crea cuando los dispositivos de ambos lados de la conexión VPN son conscientes de la configuración de la VPN con antelación. La VPN permanece estático, y hosts internos no tienen conocimiento de que existe una VPN .

Los componentes de las VPN de acceso remotoCon el advenimiento de VPNs , un usuario móvil simplemente necesita tener acceso a la Internet para comunicarse con la oficina central, como se muestra en la figura. En el caso de los trabajadores a distancia , su conectividad a Internet es típicamente una conexión de banda ancha . El teletrabajador no tiene necesariamente la conexión VPN establecido en todo momento . El PC del teletrabajador es responsable de establecer la VPN . La información requerida para establecer la conexión VPN, tal como la dirección IP de la telecommuter , los cambios de forma dinámica dependiendo de la ubicación de la telecommuter en el momento de intentar la conexión.

Los componentes de Site-to-Site

VPN En un sitio a sitio VPN, anfitriones enviar y recibir tráfico normal TCP / IP a través de una puerta de enlace VPN, que puede ser un router, firewall, concentrador de VPN de Cisco, o Cisco ASA. La puerta de enlace VPN es responsable de la encapsulación y el cifrado de tráfico de salida a partir de un sitio en particular y de enviarlo a través de un túnel VPN a través de Internet a una pasarela VPN entre pares en el otro sitio. Tras la recepción, los pares pasarela VPN tiras de las cabeceras, descifra el contenido, y transmite el paquete hacia el host de destino dentro de su red privada. De sitio a sitio VPN topologías siguen evolucionando. Ejemplos de topologías de VPN más complejos incluyen conmutación de etiquetas multiprotocolo (MPLS) de VPN, VPN dinámica multipunto (DMVPN) y el Grupo de cifrado VPN Transporte (GETVPN). Una VPN MPLS consiste en un conjunto de sitios que están interconectados por medio de un proveedor de red central MPLS. En cada sitio del cliente, uno o más acceso de clientes (CE) dispositivos se conectan a uno o más Provider Edge (PE) dispositivos. MPLS VPN son más fáciles de administrar y ampliar de VPNs convencionales. Cuando un nuevo sitio se añade a una VPN MPLS, sólo el dispositivo de borde de proveedor de servicios que ofrece servicios a las instalaciones del cliente necesita ser actualizado. Haga clic aquí para obtener más información sobre MPLS VPN. Un DMVPN permite el aprovisionamiento automático de sitio a sitio VPN IPSec, que combina tres funciones del software Cisco IOS: Next Hop Resolution Protocol (PNDH), multipunto encapsulación de enrutamiento genérico (GRE), e IPsec VPN. Esta combinación facilita los desafíos de aprovisionamiento para los clientes, y proporciona conectividad segura entre todos los lugares. Haga clic aquí para obtener más información sobre DMVPNs. GETVPN utiliza un grupo grande para eliminar túneles punto a punto y sus conductos de superposición asociado. Todos los miembros del grupo (GMS) comparten una asociación de seguridad común (SA), también conocido como un grupo SA. Esto permite a los gerentes generales para descifrar el tráfico que se cifró por cualquier otro GM. En las redes VPN GET, no hay necesidad de negociar de punto a punto de túneles IPsec entre los miembros de un grupo, porque VPN GET es "túnel-menos." Haga clic aquí para obtener más información sobre GETVPNs. MPLS VPN, DMVPN, y GETVPN funcionamiento y la aplicación están fuera del alcance del curso.

https://static-course-assets.s3.amazonaws.com/CCNAS2/en/index.html#8.1.2.4

Hairpinning y la división de túneles

Hairpinning es un término usado para describir una situación en la que VPN tráfico que entra en una interfaz también se puede enrutar de la misma interfaz. Por ejemplo, considere la topología hub-and-spoke en la figura 1. El dispositivo de VPN que termina en la red corporativa es el cubo y el acceso remoto clientes VPN son radios. Para que uno habla para comunicarse con otro radio, el tráfico debe pasar a través del dispositivo de terminación de VPN. Hairpinning también se puede utilizar cuando las VPN de acceso remoto deben conectarse al dispositivo de terminación de VPN en la sede corporativa antes de permitir el tráfico a ir a Internet.

la división de túnel se puede utilizar si la política corporativa dicta que el tráfico VPN se debe dividir entre el tráfico destinado a las subredes corporativas (de confianza) y el tráfico destinado a Internet (no fiable). En el escenario mostrado en la Figura 2, el software VPN en el cliente de acceso remoto divide el tráfico. Si el tráfico está destinado a una subred corporativa, se envía a través del túnel VPN. De lo contrario, se envía como tráfico sin cifrar (no fiable) a Internet.

Haga clic aquí para obtener más información sobre VPN hairpinning y la división de túnel.

IPsec Tecnologías 

IPsec es un estándar IETF ( RFC 2401 a 2412 ) que define cómo una VPN puede ser asegurada a través de redes IP . IPsec protege y autentica los paquetes IP entre la fuente y el destino. IPsec puede proteger prácticamente todo el tráfico de Capa 4 Capa 7. Utilizando el marco de IPsec , IPsec proporciona estas funciones esenciales de seguridad:

Confidencialidad mediante el cifrado Integridad usando algoritmos de hash Autentificación por medio de Internet Key Exchange ( IKE ) Asegurar el intercambio de claves utilizando el algoritmo de Diffie -Hellman ( DH ) 

IPsec no está vinculado a ninguna norma específica para las comunicaciones seguras . Esta flexibilidad del marco permite IPsec para integrar fácilmente las nuevas tecnologías de seguridad sin actualizar las normas existentes IPsec . Las tecnologías disponibles en la actualidad , que se muestran en la Figura 1 , están alineados con su función de seguridad específico . Haga clic en cada sección de la estructura de IPsec para aprender más acerca de cada función . La Figura 2 muestra ejemplos de asociaciones de seguridad (SA) para dos implementaciones diferentes . Una SA es el bloque de construcción básico de IPsec . Cuando se establece un enlace VPN , los compañeros deben compartir la misma SA para negociar los parámetros de intercambio de claves , establecer una clave compartida , autenticarse entre sí , y negociar los parámetros de cifrado . 

confidencialidad 

La confidencialidad se consigue mediante el cifrado de los datos , como se muestra en la Figura 1. El grado de seguridad depende de la longitud de la clave utilizada en el algoritmo de cifrado . Si alguien trata de hackear la clave a través de un ataque de fuerza bruta , el número de posibilidades para intentar es una función de la longitud de la clave . El tiempo para procesar todas las posibilidades es una función de la potencia de los ordenadores del dispositivo de ataque . Cuanto más corta sea la clave , más fácil es romper . Una clave de 64 bits puede tomar aproximadamente un año para romper con un equipo relativamente sofisticado. Una clave de 128 bits con la misma máquina puede tomar aproximadamente 10 ^ 19 años para descifrar . Los algoritmos de cifrado de relieve en la Figura 2 son todos los sistemas criptográficos de clave simétrica . Haga clic en cada algoritmo de cifrado para obtener más información .

Integridad 

Integridad de los datos significa que los datos que se recibe es exactamente los mismos datos que se envió. Potencialmente, los datos podrían ser interceptadas y modificadas. Por ejemplo, en la Figura 1, se supone que un cheque de $ 100 está escrito para Alex. La verificación a continuación, se envía por correo a Alex, pero fue cortado por un atacante. El atacante cambia el nombre en el cheque a Jeremy y la cantidad en el cheque a $ 1.000 y los intentos de sacar provecho de ella. Dependiendo de la calidad de la falsificación en el cheque alterado, el atacante podría tener éxito. Dado que los datos VPN es transportado a través de Internet pública, se requiere un método para probar la integridad de datos para garantizar que el contenido no ha sido alterado. El código de autenticación de mensaje resumido (HMAC) es un algoritmo de integridad de los datos que garantiza la integridad del mensaje usando un valor hash. La figura 2 pone de relieve los dos algoritmos HMAC más comunes. Haga clic en cada algoritmo para obtener más información. Nota: Cisco ahora clasifica SHA-1 como legado y recomienda al menos SHA-256 para la integridad. Haga clic aquí para mas información.

Autenticación

Al llevar a cabo los negocios de larga distancia, es necesario saber quién está en el otro lado del teléfono, correo electrónico o fax. Lo mismo es cierto de redes VPN. El dispositivo en el otro extremo del túnel VPN debe autenticarse antes de que se considera seguro el camino de comunicación. La figura 1 pone de relieve los dos métodos de autenticación entre pares. Haga clic en cada uno para más información.

Se muestra un ejemplo de autenticación PSK en la Figura 2. En el dispositivo local, la clave de autenticación y la información de identidad son enviados a través de un algoritmo de control para formar el hash para el peer local (Hash_L). la autenticación de un solo sentido se establece mediante el envío de Hash_L al dispositivo remoto. Si el dispositivo remoto puede crear de forma independiente el mismo hash, el dispositivo local está autenticado. Después de que el dispositivo remoto se autentica el dispositivo local, el proceso de autenticación se inicia en la dirección opuesta, y todos los pasos se repiten desde el dispositivo remoto al dispositivo local.

Se muestra un ejemplo de autenticación de RSA en la Figura 3. En el dispositivo local, la clave de autenticación y la información de identidad son enviados a través del algoritmo de control para formar el hash para el peer local (Hash_L). A continuación, el Hash_L se cifra utilizando la clave de cifrado privada del dispositivo local. Esto crea una firma digital. La firma digital y un certificado digital se reenvían al dispositivo remoto. La clave de cifrado pública para descifrar la firma está incluido en el certificado digital. El dispositivo remoto verifica la firma digital mediante el descifrado con la clave de cifrado pública. El resultado es Hash_L. A continuación, el dispositivo remoto crea independientemente Hash_L de información almacenada. Si el Hash_L calculada es igual a la Hash_L descifrado, el dispositivo local está autenticado. Después de que el dispositivo remoto se autentica el dispositivo local, el proceso de autenticación se inicia en la dirección opuesta y todas las etapas se repiten desde el dispositivo remoto al dispositivo local.

Intercambio de claves seguras

Los algoritmos de cifrado requieren una clave secreta simétrica , compartido para realizar el cifrado y el descifrado. ¿Cómo los dispositivos de cifrado y descifrado de obtener la clave secreta compartida ? El método de intercambio de claves más sencilla es utilizar un método de intercambio de clave pública , tal como Diffie -Hellman (DH) .

DH es un método de intercambio de clave pública que proporciona una manera para que dos compañeros para establecer una clave secreta compartida que sólo ellos conocen , a pesar de que se están comunicando por un canal inseguro. Las variaciones del intercambio de claves DH se especifican como grupos DH :

1. grupos DH 1, 2 , y 5 de soporte de exponenciación más de un módulo primario con un tamaño de clave de 768 bits, 1024 bits , y 1536 bits, respectivamente. Estos grupos no se recomienda su uso a partir de 2012 .

2. grupos DH 14 , 15 y 16 consumen mayores tamaños de clave de 2048 bits , con 3072 bits, y 4096 bits, respectivamente, y se recomienda su uso hasta 2030 .

3. grupos DH 19, 20 , 21 y 24 con los respectivos tamaños de clave de 256 bits, 384 bits , 521 bits, y 2048 bits soportan la criptografía de curva elíptica ( ECC ) , lo que reduce el tiempo necesario para generar las claves . grupo DH 24 es la próxima generación de cifrado preferido .

El grupo DH elegido debe ser lo suficientemente fuerte, o tienen suficientes bits , para proteger las claves IPsec durante la negociación . Por ejemplo , el grupo DH 1 es suficientemente fuerte para soportar sólo DES y cifrado 3DES , AES , pero no . Si los algoritmos de cifrado o autenticación utilizan una clave de 128 bits , un grupo del uso 14 , 19 , 20 o 24. Si los algoritmos de cifrado o autenticación utilizan una clave de 256 bits o superior , un grupo del uso 21 o 24. La configuración de ejemplo más adelante en el capítulo utiliza el cifrado y DH grupo de 256 bits 24. Durante la configuración del túnel , pares VPN negocian qué grupo DH para su uso. RFC 4869 define un conjunto de algoritmos criptográficos para adherirse a la Agencia de Seguridad Nacional ( NSA ) normas para la información clasificada . Llamado Suite B , que incluye estos algoritmos se especifica: 

· Cifrado AES debe utilizar las teclas 128 o 256 bits

· Hashing debe utilizar SHA- 2

· Firmas Digitales debe utilizar la firma digital de curva elíptica Algoritmo ( ECDSA ) con módulos primos de 256 o 384 bits· El intercambio de claves debe utilizar curva elíptica Diffie - Hellman ( ECDH )

https://static-course-assets.s3.amazonaws.com/CCNAS2/en/index.html#8.2.1.6

Descripción general del protocolo IPsec 

Los dos principales protocolos de autenticación IPsec son Header ( AH ) y el protocolo de seguridad de encapsulación ( ESP ) . El protocolo IPsec es el primer bloque de construcción del marco . La elección de AH o ESP establece qué otros bloques de construcción están disponibles . Haga clic en cada protocolo IPsec en la figura para obtener más información

Cabecera de Autenticación 

AH logra autenticidad mediante la aplicación de una función hash unidireccional con llave al paquete para crear un hash o resumen del mensaje. El hash se combina con el texto y se transmite en texto plano, como se muestra en la Figura 1. El receptor detecta cambios en cualquier parte del paquete que se producen durante el transporte mediante la realización de la misma función hash unidireccional en el paquete recibido y comparando el resultado al valor de la de resumen de mensaje que el remitente suministra. Autenticidad está asegurada porque el hash unidireccional también emplea una clave secreta compartida entre los dos sistemas. La función AH se aplica a todo el paquete, a excepción de los campos de cabecera IP que normalmente cambian en tránsito. Los campos que normalmente cambian durante el tránsito se denominan campos variables. Por ejemplo, el tiempo de vida (TTL) se considera mutable porque los enrutadores modificar este campo. El proceso de AH se produce en este orden: 

1. La cabecera IP y la carga útil de datos se hash utilizando la clave secreta compartida. 

2. El hash construye una nueva cabecera AH, que se inserta en el paquete original (Figura 2). 

3. El nuevo paquete se transmite al enrutador IPsec. 

4. El enrutador del mismo nivel hashes de la carga útil de la cabecera IP y datos utilizando la clave secreta compartida, extrae el hash transmitido desde la cabecera AH, y compara los dos valores hash (Figura 3). Los hashes deben coincidir exactamente. Si un bit se cambia en el paquete transmitido, la salida de hash en los cambios de paquetes recibidos y la cabecera AH no coincidirán. AH es compatible con MD5 y SHA algoritmos. AH no puede funcionar si el entorno utiliza NAT.

ESP 

ESP proporciona confidencialidad mediante el cifrado de la carga útil, como se muestra en la figura. Es compatible con una variedad de algoritmos de cifrado simétrico. Si se selecciona ESP como el protocolo IPsec, un algoritmo de cifrado también debe ser seleccionado. El algoritmo predeterminado para IPsec es DES de 56 bits. Los productos de Cisco también apoyan el uso de 3DES, AES, y el sello para el cifrado fuerte. ESP también puede proporcionar integridad y autenticación. En primer lugar, la carga útil está cifrada. A continuación, la carga útil cifrada se envía a través de un algoritmo de control, tales como MD5 o SHA. El hash proporciona autenticación e integridad de datos para la carga de datos. Opcionalmente, ESP también puede cumplir la protección contra reproducción. Protección anti-replay verifica que cada paquete es único y no se duplica. Esta protección se asegura de que un hacker no puede interceptar los paquetes y insertar las modificaciones de paquetes en el flujo de datos. Antirreproducción trabaja llevando un registro de los números de secuencia de paquetes y el uso de una ventana deslizante en el extremo de destino. Cuando se establece una conexión entre un origen y un destino, sus contadores se inicializan a cero. Cada vez que se envía un paquete, un número de secuencia se anexa al paquete por la fuente. El destino utiliza la ventana deslizante para determinar qué números de secuencia se espera. El destino verifica que el número de secuencia del paquete no se duplica y se recibe en el orden correcto. Por ejemplo, si la ventana deslizante en el destino se establece en uno, el destino está a la espera de recibir el paquete con el número de secuencia uno. Después de que se recibe, la ventana deslizante se mueve a dos. Cuando la detección de un paquete repetido se produce, tal como el destino de recibir un segundo paquete con el número de secuencia de uno, un mensaje de error se envía, el paquete repetido es descartado, y el evento se registra. Antirreproducción se usa típicamente en ESP, pero también es compatible con AH.

ESP Cifra y Autentica 

ESP proporciona la capacidad de proteger los datos originales, porque todo el datagrama IP original y el remolque ESP están cifradas. Con la autenticación de ESP, el datagrama IP cifrada y el remolque, y la cabecera ESP se incluyen en el proceso hashing, como se muestra en la figura. Entonces, una nueva cabecera IP se fija a la carga útil autenticado. La nueva dirección IP se utiliza para encaminar el paquete a través de Internet. Cuando se seleccionan la autenticación y el cifrado, el cifrado se realiza en primer lugar. Una de las razones para esta orden de procesamiento es que facilita la rápida detección y el rechazo de paquetes reproducidos o falsas por el dispositivo receptor. Antes de descifrar el paquete, el receptor puede autenticar los paquetes entrantes. De esta manera, se puede detectar rápidamente los problemas y potencialmente reducir el impacto de los ataques de denegación de servicio. Para reiterar, ESP proporciona confidencialidad con el cifrado y proporciona integridad con la autenticación. Hasta este punto, la discusión de IPsec se ha centrado en IPv4. Sin embargo, IPsec se estableció inicialmente para proporcionar seguridad a los paquetes IPv6. Por lo tanto, las implementaciones IPsec para IPv4 y IPv6 son similares en lo que se refiere a las normas. En IPv4, AH y ESP son cabeceras de protocolo IP. IPv6 utiliza las cabeceras de extensión con un valor de nueva cabecera de 50 para ESP y 51 para AH.

Modos de transporte y túnel 

ESP y AH se puede aplicar a los paquetes IP en dos modos diferentes , el modo de transporte y el modo de túnel , como se muestra en la Figura 1 .

Modo de transporte : 

modo de transporte n , se proporciona seguridad sólo para la capa de transporte del modelo OSI y por encima . El modo de transporte protege la carga útil del paquete , pero deja la dirección IP original en texto plano . La dirección IP original se utiliza para encaminar el paquete a través de Internet . modo de transporte ESP se utiliza entre los hosts .

Modo de túnel

El modo de túnel proporciona seguridad para el paquete original completo IP. El paquete IP original es encriptada y después se encapsula en otro paquete IP. Esto se conoce como el cifrado IP-en-IP. La dirección IP en el paquete IP exterior se utiliza para encaminar el paquete a través de Internet. modo túnel ESP se utiliza entre un host y una pasarela de seguridad, o entre dos puertas de enlace de seguridad, como se muestra en la Figura 2. Para aplicaciones de host a la puerta de enlace, una oficina en casa podría no tener un router para llevar a cabo la encapsulación IPsec y el cifrado. En este caso, un cliente de IPsec se ejecuta en el PC realiza la encapsulación y el cifrado IPsec IP en IP. Para aplicaciones de puertas de enlace, en lugar de la carga IPsec en todos los equipos en las oficinas remotas y corporativos, que es más fácil tener los gateways de seguridad realizan la encriptación y encapsulación IP-en-IP. En la oficina corporativa, el router de-encapsulados y descifra el paquete. Como se muestra en la Figura 3, el modo de transporte AH proporciona autenticación y la integridad de todo el paquete. No cifra los datos, sino que está protegido frente a posibles modificaciones. AH en modo túnel encapsula el paquete IP con un AH y una nueva cabecera IP, y firma todo el paquete para la integridad y autenticación.

https://static-course-assets.s3.amazonaws.com/CCNAS2/en/index.html#8.2.2.6

El protocolo IKE

El protocolo Internet Key Exchange (IKE) es un estándar de protocolo de gestión de claves. IKE se utiliza en conjunción con el estándar IPsec. Como se muestra en la figura, IKE negocia automáticamente asociaciones de seguridad IPsec IPsec y permite comunicaciones seguras. IKE IPsec mejora por la adición de características y simplifica la configuración para el estándar IPSec. Sin IKE en su lugar, la configuración de IPsec sería un proceso de configuración compleja, manual que no escala bien.

IKE es un protocolo híbrido que implementa los protocolos de intercambio de claves dentro del marco de seguridad en Internet Protocolo de administración de claves Asociación (ISAKMP). ISAKMP (pronunciado "Ice-a-campo") define el formato de los mensajes, la mecánica de un protocolo de intercambio de claves, y el proceso de negociación para construir una SA de IPsec. IKE implementa partes de los protocolos de Oakley y SKEME pero es de ninguna manera depende de estos protocolos. Por ejemplo, algunos de los proceso de intercambio de IKE se basa en el protocolo de Oakley y el método de cifrado de clave pública utilizada por IKE se basa en SKEME. Discusión adicional de Oakley y SKEME están más allá del alcance de este curso. Consulte la RFC 2409 para más información.

En lugar de transmitir las claves directamente a través de una red, IKE calcula claves compartidas basadas en el intercambio de una serie de paquetes de datos. Esto inhabilita a los terceros el descifrado de las claves, incluso si el tercero capturado todos los datos intercambiados que se utilizó para calcular las claves. IKE utiliza el puerto UDP 500 para intercambiar información IKE entre las pasarelas de seguridad. El puerto UDP 500 paquetes deben ser permitidos en cualquier interfaz IP que se conecta a un compañero pasarela de seguridad.

https://static-course-assets.s3.amazonaws.com/CCNAS2/en/index.html#8.2.3.2

Fase 1 y 2 negociación de llave IKE 

utiliza ISAKMP para la fase 1 y la fase 2 de la negociación de claves . Fase 1 negocia una asociación de seguridad (una clave ) entre dos interlocutores IKE . La clave negociada en la fase 1 permite a los interlocutores IKE comunicarse de forma segura en la fase 2. Durante la fase 2 negociación, IKE establece teclas (asociaciones de seguridad ) para otras aplicaciones , tales como IPsec . En la Fase 1 , dos pares IPsec realizan la negociación inicial de las SV . El propósito básico de la Fase 1 es negociar la política de ISAKMP , autenticar a los compañeros , y establecer un túnel seguro entre los pares. Este túnel se utilizará entonces en la Fase 2 de negociar la política IPsec, como se muestra en la figura. Nota: Las frases política IKE y la política de ISAKMP son equivalentes . La política de ISAKMP frase se utiliza en este curso para adaptarse mejor a la utilese e cimado crypto isakmp policy, show isakmp policy, 

así como para aclarar que la política de ISAKMP se aplica al túnel IKE Fase 1 . Fase 1 se puede implementar de modo principal o el modo agresivo. Cuando se utiliza el modo principal , las identidades de los dos interlocutores IKE están ocultos . modo agresivo lleva menos tiempo que el modo principal para negociar claves entre pares . Sin embargo, desde el hash de autenticación se envía sin cifrar antes de que se establezca el túnel , el modo agresivo es vulnerable a ataques de fuerza bruta . Nota : En el software Cisco IOS , la acción predeterminada para la autenticación IKE es para iniciar el modo principal. Sin embargo , el software Cisco IOS responderá en modo agresivo a un interlocutor IKE que inicia el modo agresivo.

Fase 2: La negociación de las SA

El propósito de IKE Fase 2 es negociar los parámetros de seguridad IPsec que se utilizarán para asegurar el túnel IPsec, como se muestra en la figura. IKE fase 2 se denomina modo rápido y sólo puede ocurrir después de IKE ha establecido un túnel seguro en la Fase 1. Los SV son negociados por el proceso de ISAKMP IKE en nombre de IPsec, que necesita las claves de cifrado para la operación. de modo rápido negocia los IKE fase 2 SA. En esta fase, las SA IPsec que los usos son unidireccionales; por lo tanto, se requiere un intercambio de claves por separado para cada flujo de datos.

de modo rápido también renegocia un nuevo IPsec SA cuando la vida útil de IPsec SA expire. Básicamente, de modo rápido refresca el material clave que crea la clave secreta compartida. Esto se basa en el material de claves que se deriva del intercambio DH en la Fase 1.

IKE versión 2, un protocolo de gestión de claves de próxima generación basado en el RFC 4306, es una mejora del protocolo IKE. IKE versión 2 es compatible con la detección de NAT en la Fase 1 y NAT (NAT-T) durante la Fase 1. Si ambos dispositivos VPN son capaces de NAT-T, y si detectan que se conectan entre sí a través de un dispositivo NAT, NAT-T es auto detectado y concesionarios negociado. NAT-T encapsula los paquetes ESP dentro de UDP y asigna la fuente y Puertos de destino como 4500. Ahora los paquetes ESP puede atravesar NAT. Haga clic aquí para obtener más información sobre NAT-T.

La negociación de IPsec 

negociación de IPsec para establecer una VPN consta de cinco pasos , que incluyen IKE Fase 1 y la Fase 2 : 

Paso 1. Se inicia un túnel de ISAKMP cuando el host A envía tráfico " interesante " para acoger B. El tráfico se considera interesante cuando se viaja entre los compañeros y cumple con los criterios que se definen en una ACL ( Figura 1 ) . Paso 2. IKE Fase 1 comienza . Los pares negocian la política de ISAKMP SA . Cuando los compañeros están de acuerdo en la política y se autentican , un túnel seguro se crea ( Figura 2 ) .

Paso 3. IKE Fase 2 comienza . Los homólogos de IPsec utilizan el túnel seguro autenticado para negociar la directiva IPsec SA . La negociación de la política compartida determina cómo se establece el túnel IPsec ( Figura 3 ) . Se crea Paso 4. El túnel IPsec , y los datos se transfieren entre los homólogos de IPsec en base a la SA IPsec ( Figura 4 ) . El túnel IPsec 

Paso 5. termina cuando la SA IPsec se elimina manualmente , o cuando expire su vida útil ( Figura 5 ) .

Site-to -Site VPN IPsec Topología

La implementación de un sitio a sitio VPN requiere la configuración de opciones tanto para la fase IKE 1 y Fase 2. En la configuración de la etapa 1 , los dos sitios se configuran con las asociaciones de seguridad de ISAKMP necesarias para que un túnel de ISAKMP puede ser creado. En la configuración de la fase 2 , los dos sitios se configuran con las asociaciones de seguridad IPsec para asegurar que se crea un túnel IPsec en el túnel de ISAKMP . Ambos túneles se crean sólo cuando se detecta tráfico interesante .

La topología en la figura para XYZ Corp. se utiliza en esta sección para demostrar un sitio web a la implementación de IPsec VPN . Haga clic en cada router para ver la configuración actual . Ambos routers están configurados con direcciones IP y enrutamiento estático . Un ping extendido en R1 verifica que el enrutamiento entre las LAN está en funcionamiento .

Tareas de configuración VPN IPsec. 

Los requisitos de directiva de seguridad para XYZ Corp. sitio - a - sitio implementaciones VPN IPsec se muestran en la Figura 1. Las tareas de configuración necesarias para cumplir con esta política se muestran en la Figura 2 .

ACL existente Configuraciones 

Aunque XYZ Corp. no tiene una configuración de ACL existente, esto no sería el caso en una red de producción . enrutadores perimetrales suelen implementar una política de seguridad restrictiva , bloqueando todo el tráfico excepto para el tráfico que se permitan específicamente . Antes de implementar un sitio a sitio VPN IPsec , asegúrese de que las ACL existentes no bloquea el tráfico necesario para las negociaciones de IPsec. La sintaxis del comando ACL para permitir ISAKMP , ESP , y el tráfico AH se muestra en la Figura 1. Haga clic en R1 en la Figura 2 para ver una configuración de ACL que permita el tráfico necesario para las negociaciones de IPsec. R2 tendría una configuración similar.

Manipulación de difusión y multidifusión de tráfico

La topología XYZ Corp. utiliza el enrutamiento estático, lo que no hay tráfico de multidifusión o de difusión que tiene que ser encaminada a través del túnel. Pero lo que si XYZ Corp. decidió implementar EIGRP o OSPF? Estos protocolos de enrutamiento utilizan direcciones de multidifusión para intercambiar información de enrutamiento con los vecinos. IPsec sólo es compatible con el tráfico unicast. Para habilitar el tráfico de protocolo de enrutamiento, los pares en un sitio a sitio VPN IPsec aplicación tendría que ser configurado con un túnel de encapsulación de enrutamiento genérico (GRE) para el tráfico de multidifusión.

GRE apoya túnel multiprotocolo, como se muestra en la figura. Se puede encapsular múltiples OSI de nivel 3 tipos de paquetes de protocolo en el interior de un túnel IP. Adición de un encabezado adicional GRE entre la carga útil y la cabecera IP de túnel proporciona la funcionalidad multiprotocolo. GRE también es compatible con un túnel de multidifusión IP. Los protocolos de enrutamiento que se utilizan a través del túnel permiten un intercambio dinámico de información de enrutamiento en la red virtual. GRE no proporciona cifrado. configuración de GRE está más allá del alcance de este curso.

https://static-course-assets.s3.amazonaws.com/CCNAS2/en/index.html#8.3.1.6

Las Políticas de ISAKMP predeterminado 

La primera tarea consiste en configurar la política de ISAKMP para la Fase IKE 1. La política de ISAKMP enumera las SV que el router está dispuesto a utilizar para establecer el túnel IKE Fase 1 . El Cisco IOS ya viene con las políticas de ISAKMP por defecto en su lugar. Para ver las políticas predeterminadas , introduzca el comadno show crypto isakmp default policy 

tiene siete políticas ISAKMP predeterminados que van desde el más seguro (política 65507 ) a la menos segura (política 65514 ) . Si no hay otra política ha sido definida por el administrador , R1 intentará utilizar la política predeterminada más segura . Si R2 tiene una política de coincidencia, entonces R1 y R2 pueden negociar con éxito el túnel IKE Fase 1 de ISAKMP sin ninguna configuración por parte del administrador . Siete políticas predeterminadas permiten flexibilidad en las negociaciones . Si no hay un acuerdo para utilizar la política predeterminada más segura , R1 se intente utilizar la siguiente política más segura . En este ejemplo , ninguna de las políticas por defecto coincide con la política de seguridad para XYZ Corp. . Por lo que una nueva política de ISAKMP tendrá que ser configurado . 

Sintaxis para configurar una nueva política de ISAKMP 

Para configurar una nueva política de ISAKMP , utilice el comando crypto isakmp policy 

como se muestra en la figura. El único argumento para el comando es para establecer una prioridad de la política (de 1 a 10000) . Compañeros intentarán negociar el uso de la política con el número más bajo (prioridad más alta ) . Los compañeros no requieren búsqueda de números de prioridad . En el modo de configuración de la política de ISAKMP , las SA para el túnel IKE fase 1 se puede configurar . Utilice la Hagle mnemotécnica para recordar los cinco SAs para configurar : 

· Hash

· Authentication

· Group

· Lifetime

· Encrypti

Configuración de la directiva ISAKMP XYZ Corp. 

Para cumplir con los requisitos de la política de seguridad para XYZ Corp. , configure la directiva ISAKMP SAs con la siguiente : Hash es SHA La autenticación es clave pre-compartida Grupo es 24 Tiempo de vida es de 3600 segundos El cifrado es AES Utilizar el comando how crypto isakmp policy del sistema para comprobar la configuración . En la figura, haga clic en R1 para ver la configuración de la política de ISAKMP . R2 tiene una configuración equivalente.

Configuración de un Clave Pre-Compartida 

La política de seguridad XYZ Corp. requiere que una clave pre- compartida se utiliza para la autenticación entre los pares. La sintaxis del comando se muestra en la Figura 1. El administrador puede especificar un nombre de host o una dirección IP para los pares. XYZ Corp. utiliza el cisco12345 frase clave y la dirección IP del par . Haga clic en los routers en la Figura 2 para ver la configuración de clave pre- compartida para R1 y R2. Utilizar el comprobador de sintaxis en la Figura 3 para configurar la política de ISAKMP para R2 .

Definir tráfico interesante 

Aunque la política ISAKMP para el IKE Fase 1 túnel está configurado , sin embargo, no existe el túnel. Esto se verifica con el comadno show crypto isakmp sa 

comando en la Figura 1. tráfico interesante debe ser detectada antes de IKE fase 1 puedan comenzar las negociaciones . Para el XYXCORP VPN de sitio a sitio , el tráfico interesante es cualquier comunicación entre las redes locales del sitio 1 y sitio 2 . Para definir tráfico interesante , configurar cada router con una ACL para permitir el tráfico de la red local a la LAN remota . La ACL se utiliza en la configuración del mapa criptográfico para especificar qué tráfico va a desencadenar el inicio de la Fase IKE 1. Haga clic en los routers en la Figura 2 para ver la configuración de ACL para R1 y R2.

Configurar IPSec conjunto de transformación 

El siguiente paso consiste en configurar el conjunto de algoritmos de cifrado y de hashing que se utilizarán para transformar los datos enviados a través del túnel IPsec. Esto se llama el conjunto de transformación . Durante IKE negociaciones de fase 2 , los compañeros están de acuerdo en la IPsec conjunto de transformación que deben utilizarse para proteger el tráfico interesante. Configurar un conjunto de transformación mediante el comando crypto ipsec transform-set como se muestra en la Figura 1. En primer lugar, especificar un nombre para el conjunto de transformación (R1 -R2 , en el ejemplo) . El algoritmo de encriptación y hashing entonces se puede configurar en cualquier orden. Haga clic en los routers en la Figura 2 para ver la configuración de transformación establecido para R1 y R2.

Utilizar el comprobador de sintaxis en la Figura 3 para configurar la directiva IPsec para R2 .

Sintaxis configurar un mapa Crypto

Ahora que el tráfico interesante es definida , y un conjunto de transformación IPsec está configurado , es el momento de unirse a esas configuraciones con el resto de la directiva IPsec en un mapa criptográfico . La sintaxis para iniciar un conjunto de mapas de cifrado se muestra en la Figura 1. El número de secuencia es importante si desea configurar varias entradas de correlación de cifrado . XYZ Corp. sólo se necesita una entrada de mapa de cifrado para que coincida con el tráfico y la cuenta para el resto de las SA . Aunque se muestra la opción de ipsec - manual, su uso está más allá del alcance de este curso .

Haga clic en R1 en la Figura 2 para ver las configuraciones disponibles para una entrada de mapa de cifrado cuando se está en el modo de configuración mapa criptográfico . El nombre del mapa es R1 - R2_MAP , y ese número es 10 .

Configuración Mapa Crypto XYZ Corp. 

Para finalizar la configuración para cumplir con la política de seguridad IPsec para XYZ Corp. , complete lo siguiente: Paso 1. Enlace del LCA y el conjunto de transformación en el mapa. Paso 2. Especificar la dirección IP de los pares. Paso 3. Configurar el grupo DH . Paso 4. Configurar el tiempo de vida de túnel IPsec . Haga clic en los routers en la Figura 1 para ver la configuración del mapa criptográfico para R1 y R2. Utilizar el comando show crypto mapa comando para verificar la configuración del mapa criptográfico , como se muestra en la Figura 2. Todas las SA requerido debe estar en su lugar . Observe en la sección resaltada de la figura 2 que hay interfaces recientemente registrados usando el mapa criptográfico 

Aplicar el Crypto Mapa 

Para aplicar el mapa criptográfico , entrar en el modo de configuración de interfaz para la interfaz de salida y configurar el comando crypto map map-name 

Haga clic en R1 en la Figura 1 para ver la configuración de XYZ Corp. . Nótese el comando show crypto map salida ahora muestra que la interfaz serial 0/0/0 está utilizando el mapa criptográfico . R2 se configura con el mismo comando en su interfaz Serial 0/0/0 .

Utilizar el comprobador de sintaxis en la Figura 2 para configurar , aplicar y verificar un mapa cripto en R2.

Enviar tráfico interesante

Ahora que tanto las directivas IPsec ISAKMP y se configuran , y el mapa de cifrado se aplica a las interfaces de salida apropiadas , prueba los dos túneles mediante el envío de tráfico interesante a través del enlace .

Tráfico de la interfaz LAN en R1 con destino a la interfaz LAN en R2 se considera tráfico interesante porque coincide con las ACL configuradas en ambos routers . Un ping extendido desde R1 pondrá a prueba efectivamente la configuración de la VPN . Haga clic en R1 para ver la sintaxis del comando ping extendido y resultados . La primera de ping falló porque se tarda unos pocos milisegundos para establecer la ISAKMP y túneles IPsec .

Verificar el ISAKMP y IPsec Túneles

Enviar el tráfico interesante en realidad no significa que se establecen los túneles . R1 y R2 se enrutar el tráfico entre las dos redes de área local , incluso si las configuraciones de ISAKMP y de política IPsec están equivocados . Para comprobar que se han establecido los túneles , utilice el comando show crypto isakmp sa andshow crypto ipsec sa 

ck R1 en la figura 1 para ver la salida del túnel ISAKMP . Observe que el túnel está activo entre los dos compañeros, 172.30.2.1 y 172.30.2.2 . Haga clic en R1 en la Figura 2 para ver la salida del túnel IPsec . Utilice el Revisar sintaxis en la Figura 3 para verificar la VPN IPsec de R2 . https://static-course-assets.s3.amazonaws.com/CCNAS2/en/index.html#8.4.1.1