Cisco VPN IPSec Site-to-Site con Certificados Digitales
Muchos de vuestros clientes cuentan con distintas oficinas en ubicaciones geográficamente distantes, y seguro que con la necesidad de comunicarlas para poder ofrecer los mismos servicios que en las oficinas centrales. Ahora llega la pregunta del millón, cómo conectar las distintas oficinas? Todos los ISP nos ofrecen múltiples tecnologías para ello:
- Metro Ethernet
- MPLS
- etc…
Estas tecnologías son las que suelen manejar los ISP cuando queremos disponer de conectividad entre distintas ubicaciones, además nos permite contratar distintos servicios de alto valor añadido:
- Redundancia
- QoS
- Ancho de Banda
- Monitorización
- Seguridad
Pero por supuesto esto tiene un coste que no todas las empresas pueden asumir, a pesar de que ahora mismo tiene un coste más que razonable. De ahí que tengamos la necesidad de buscar alternativas, que a pesar de no tener estos servicios de valor añadido. Tambin es cierto que no en todas las ocasiones necesitamos todas las funcionalidades de este tipo de enlaces, y únicamente buscamos conectar las distintas sedes del cliente. Pero claro, aquí no se nos puede pasar por alto lo más importante cuando utlizamos la WAN (insegura por defecto) para conectar distintas oficinas, que es ofrecer una capa de seguridad importante para que nadie libremente pueda interceptarlas, analizarlas y/o ser capaz de modficarlas. También es cierto que siempre debemos alinear las necesidades de seguridad con el coste que ello supone, pero hoy en día cualquier hardware que se precie soporta ciertos protocolos de seguridad. Existen múltiples tipos de VPN, esto es algo que debemos tener en cuenta en función del diseño que hagamos de la solución. Lo más común y sencillo de implementar es una VPN con IPSec Site-to-Site, para ello debemos tener dispositivos que soporten IPSec (es un conjunto de protocolos cuya función es asegurar las comunicaciones sobre el Protocolo de Internet (IP) autenticando y/o cifrando cada paquete IP en un flujo de datos) y sobre él realizar las configuraciones necesarias. Yo os voy a mostrar como configurar un VPN con IPSec Site-to-Site con hardware Cisco, en este caso entre dos routers Cisco de la serie 1800. Este sería el esquema sobre el que se fundamentará la configuración de IPSec:
Esquema: Empresa con dos delegaciones que tiene los servidores principales en la sede central y una replicación de ficheros vía DFS
Como esta configuración “tipo” ya os la había comentado en su momento en otro artículo (La Nube Privada: Migración de Oficina, Beneficios del CPD y la VoIP) , me voy a centrar en configurar la autenticación de la Fase 1 utilizando certificados digitales emitidos por nuestra CA. Para refrescarnos la memoria, aquí os dejo la configuración que había utilizado en este artículo de la Nube Privada …. pero cambiando la autenticación de Preshared Key a RSA-SIG, aportando un plus de seguridad y escalabilidad:
| Data Center | Nueva Oficina |
|---|---|
|
crypto isakmp policy 10
encr aes 192
authentication rsa-sig
group 2
crypto ipsec transform-set ipsec esp-aes 192 esp-sha-hmac
crypto dynamic-map vpneq2b 10
set transform-set ipsec
match address 180
crypto map vpnipsec 10 ipsec-isakmp dynamic vpneq2b
access-list 180 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 180 deny ip 192.168.200.0 0.0.0.255 host 0.0.0.0
No NAT
access-list 110 deny ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 110 permit ip any any
|
crypto isakmp policy 10
encr aes 192 authentication rsa-sig group 2 crypto ipsec transform-set ipsec esp-aes 192 esp-sha-hmac
crypto map vpneq2b 10 ipsec-isakmp set peer X.X.X.X set transform-set ipsec match address 180 access-list 180 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
access-list 180 deny ip 192.168.100.0 0.0.0.255 0.0.0.0 0.0.0.0 No NAT
access-list 110 deny ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
access-list 110 permit ip any any
|
| Por último se deben aplicar los crypto-map a las interfaces WAN | |
Ahora debemos configurar nuestra CA para que los dispositivos de red puedes solicitar su certificado, para ello vamos a utilizar el Servicio de Inscripción de Dispositivos de Red de nuestra CA en Windows Server. Yo utilizaré Windows Server 2012, y lo primero que debemos hacer es configurar primero nuestra CA: Windows Server 2012, Instalación de una CA. Y durante la instalación o a posteriori configuraremos el Servicio de Inscripción de Dispositivos de Red, yo ya tengo la CA instalada y vamos a ver como podemos configurar el servicio de Servicio de Inscripción de Dispositivos de Red. Para ello vamos a la consola de Administración de nuestro servidor, vamos a Administrar – Agregar Roles y Características y seguimos el asistente hasta que se complete la instalación:
Ahora debemos seleccionar Servicio de inscripción de dispositivos de red y pulsamo en Siguiente
Pulsamos en Siguiente
Una vez que se ha completado la instalación debemos pulsar en Configurar Servicios de certificados de Active Directory en el servidor de destino
Por defecto el usuario que instalará que configurará los servicios del ROL será el usuario con el que hayáis iniciado sesión, ya doy por hecho que sois miembros del grupo Admins. del Dominio. Pero en todo caso si queréis elegir otro usuario para realizar la configuración de este servicio
Debemos seleccionar un usuario que se usará para el servicio de inscripción de certificados, como véis nos avisa de que debe ser miembro del grupo IIS_IUSRS local, pulsamos en seleccionar
Introducimos el nombre del usuario del dominio (debe ser miembro únicamente del grupo de Usuarios del Dominio) e introducimos sus credenciales
pulsamos en Siguiente
Cubrimos los datos de nuestra organización y pulsamos en Siguiente
Podemos dejarlo por defecto y pulsamos en Siguiente
Por último nos muestra un resumen de la configuración y pulsamos en Configurar
Ahora que hemos finalizado veremos que los certificados que tenemos disponibles para la inscripción desde los dispositivos de red serán de la plantila de IPSecCIntermediateOffline. Si quisieramos utilizar una plantilla de certificado personalizada, tendríamos que crear nueva plantilla y editar el registro para cambiar el nombre del certificado a emitir: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP: EncryptionTemplate, GeneralPurposeTemplate, SignatureTemplate y luego reiniciar el IIS para que los cambios se hayan aplicado correctamente.
Ahora vamos a revisar que el usuario asignado para el servicio de inscripción de certificados para dispositivos de red tiene acceso de inscripción de esta plantilla, para ello vamos a la consola de la entidad certificadora, vamos a Plantillas de Certificado y pulsamos con el botón secundario del ratón y pulsamos en Administrar
Debemos ir a las propiedades de la plantilla de IPSECIntermediateOffline y vamos a la pestaña de seguridad para poder verificar que el usuarios NDES (es el usuario comentario anteriormente) tiene acceso de inscripción sobre esta plantilla
Una vez revisado los permisos básicos y que en nuestro caso la plantilla de certificado que necesitamos es esta, ahora debemos acceder a la URL de administración de emisión de certificados para dispositivos de red. Para ello debemos escribir la siguiente URL: http(s)://fqdn_servidor/certsrv/mscep_admin, ahora os solicitará las credenciales de acceso y debéis iniciar sesión con un usuario que tenga acceso de inscripción de certificados para las plantillas de IPSECIntermediateOffline, en caso contrario os dará acceso denegado.
Si cuando accedemos a la URL comentada nos encontramos con este error
debemos revisar el méto de inicio de sesión, que por defecto es negotiate pero si no tenemos los registros SPN actualizados no nos permitirá autenticar. En mi caso como no utlizo el FQDN del sevidor sino un registro CNAME para darle otra URL al acceso web de inscripción de certificados y no tener el SPN creado, no me permitirá autenticarme por Kerberos por lo que tengo que modificarlo de Negotiate a NTLM. Si bien es cierto que puedo crear el SPN adecuado y demás, pero por agilizar la guía no lo he hecho cambiando solo lo he modificado el orden de los proveedores habilitados y he puesto NTLM el primero en la lista
Ahora he vuelto a acceder a la URL comentada anteriormente y me muestra el siguiente error
Para solucionar este problema he utilizado est KB de MSFT: http://support.microsoft.com/kb/2800975 y debéis seguir estos pasos para solucionarlo
1) Install and configure NDES (and CEP/CES).
2) Open IIS.
3) Select “Default Web Site”.
4) Click “View Applications” in the action panel on the right.
5) Double click the mscep application.
6) Double click “Handler Mappings”.
7) Click “View Ordered List…” in the action panel.
8) Select ExtensionlessUrlHandler-ISAPI-4.0_64bit and move it down so it is below StaticFile.
9) Repeat steps 6-8 for the mscep_admin application.
10) Restart IIS.
Aquí so muestro los pasos en imágenes
Nota: Esto me ha pasado en casi todas las implementaciones de NDES con Windows Server 2012
Ahora volvemos a tratar de acceder a la URL de NDES y ya podemos acceder correctamente, como vemos nos ofrece la huella digital del certificado a emitir y su clave de solicitud, que como podéis obsevar tendrá una validez de 60 min y solo se puede usar una vez. Este comportamiento se puede modificar editando el registro, pero yo prefiero que dejarlo así. Se puede quitar la solicitud de contraseña, etc.. pero mejor dejémoslo así.
Nota a tener en cuenta de MSFT
- Espere hasta que una de las contraseñas haya expirado antes de enviar una solicitud nueva.
- Detenga y reinicie Internet Information Services (IIS) para eliminar todas las contraseñas almacenadas en la memoria caché.
- Configure el servicio para que almacene en la memoria caché más de cinco contraseñas.
Ya tenemos todo preparado para que nuestros dos routers Cisco puedan solicitar su certificado, para ello debemos seguir los siguientes pasos:
1º Crear los RSA necesarios: crypto key generate rsa general-keys label <Etiqueta> modulus 2048
2º (Opcional) Configurar un servidor DNS para que el router pueda resolver nombres de dominio: ip name-server <dirección_IP>. Esto nos ayudará a resolver el nombre de la URL del NDES, y no tenemos que estar utilizando la dirección IP.
3º Configuramos las opciones de inscripción del certificado por parte del router
crypto pki trustpoint EQ2B
enrollment mode ra
enrollment url http://ca.eq2b.com:80/certsrv/mscep/mscep.dll
usage ike
serial-number
revocation-check none
rsakeypair EQ2BRSA
auto-enroll
4º Enviaremos la solictud de autenticación a la CA: crypto pki authenticate <nombre_trustpoint>
Como vemos en la URL del NDES MD5 la huella digital que nos está mostrando en la misma que nos devuelve en el router
5º Enviaremos la solicitud de inscripción del certificado a la CA: crypto pki enroll <nombre_trustpoint>. Como vemos nos solicita una clave para poder solicitar el certificado, la clave es la que nos muestra en la página en la URL de NDES
Ahora si queremos ver el certificado recibido escribiremos: sh crypto ca certificates EQ2B
Ahora ya tenemos nuestro certifcado en el router, y si nos vamos a la consola de la CA a Certificados Emitidos y vemos que se ha emitido el certificado en base a la plantilla IPSEC (solicitud sin conexión) y el nombre del solicitante es el usuario NDES. Este usuario es el que previamente habíamos configurado con el asistente inicial
6º Ahora debemos cambiar el modo de autenticación de nuestra configuración de IPSec en la Fase 1: authentication rsa-sig
crypto isakmp policy 10
authentication rsa-sig
Esto es todo lo que debemos hacer en cada uno de los routers, estos seis pasos debemos repetirlos en el otro router del otro extremo de la VPN. Una vez completados si vamos a la consola de administración de la CA vemos que ya aparecen los dos certificados emitidos.
Una vez que ambos routers están configurados con sus correspondientes certificados, y que se ha cambiado la configuración de Preshared key a RSA-SIG los routers volverán a negociar IPSec y tratar de conectarse. Aquí os muestro parte de un log de la negociación de IPSec entre ambos routers:
May 4 15:33:57.044: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
May 4 15:33:57.044: ISAKMP:(0):Old State = IKE_R_MM3 New State = IKE_R_MM4
May 4 15:33:57.336: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
May 4 15:33:57.336: ISAKMP:(0):Old State = IKE_R_MM4 New State = IKE_R_MM5
May 4 15:33:57.336: ISAKMP (0:0): ID payload
next-payload : 6
type : 2
FQDN name : XXXXXXXXXXXXXX
protocol : 17
port : 0
length : 21
May 4 15:33:57.380: ISAKMP:(0): processing SIG payload. message ID = 0
May 4 15:33:57.412: ISAKMP:received payload type 17
May 4 15:33:57.412: ISAKMP:(0):SA authentication status:
authenticated
May 4 15:33:57.412: ISAKMP:(0):SA has been authenticated with XXX.XXX.XXX.XXX
May 4 15:33:57.412: ISAKMP:(0):Detected port floating to port = 4500
May 4 15:33:57.412: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
May 4 15:33:57.412: ISAKMP:(0):Old State = IKE_R_MM5 New State = IKE_R_MM5
May 4 15:33:57.420: ISAKMP (0:0): ID payload
next-payload : 6
type : 1
address : XXXXXXXXXXXXXXXXXXXXX
protocol : 17
port : 0
length : 12
May 4 15:33:57.420: ISAKMP:(0):Total payload length: 12
May 4 15:33:57.432: ISAKMP (0:0): constructing CERT payload for hostname=EQ2B.asirsl.com,ipaddress=YYY.YYY.YYY.YYY,serialNumber=FCZ102990AA
May 4 15:33:57.432: ISKAMP: growing send buffer from 1024 to 3072
May 4 15:33:57.432: ISAKMP:(0): using the EQ2B trustpoint’s keypair to sign
May 4 15:33:58.452: ISAKMP:(0): sending packet to XXX.XXX.XXX.XXX my_port 4500 peer_port 4500 (R) MM_KEY_EXCH
May 4 15:33:58.456: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
May 4 15:33:58.456: ISAKMP:(0):Old State = IKE_R_MM5 New State = IKE_P1_COMPLETE
May 4 15:33:58.456: ISAKMP:(0):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
May 4 15:34:08.959: ISAKMP: set new node 452620383 to QM_IDLE
May 4 15:34:08.959: ISAKMP:(0): processing HASH payload. message ID = 452620383
May 4 15:34:08.959: ISAKMP:(0): processing NOTIFY DPD/R_U_THERE protocol 1
spi 0, message ID = 452620383, sa = 63F8B86C
May 4 15:34:08.959: ISAKMP:(0):deleting node 452620383 error FALSE reason “Informational (in) state 1”
May 4 15:34:08.959: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
May 4 15:34:08.959: ISAKMP:(0):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
May 4 15:34:08.959: ISAKMP: set new node 1455114095 to QM_IDLE
May 4 15:34:08.959: ISAKMP:(0):Sending NOTIFY DPD/R_U_THERE_ACK protocol 1
spi 1683670752, message ID = 1455114095
May 4 15:34:08.959: ISAKMP:(0): seq. no 0x36323CCE
May 4 15:34:08.959: ISAKMP:(0): sending packet to XXX.XXX.XXX.XXX my_port 4500 peer_port 4500 (R) QM_IDLE
May 4 15:34:08.959: ISAKMP:(0):purging node 1455114095
May 4 15:34:08.959: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MESG_KEEP_ALIVE
May 4 15:34:08.963: ISAKMP:(0):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
Esto mismo lo podemos repetir en tantos routers como queramos conectar entre si. Esto permite aumentar el nivel de seguridad y escalabilidad de nuestra infraestructura de comunicaciones. Si os habéis fijado he puesto este comando en la configuración de solicitud de los certificados: revocation-check none
crypto pki trustpoint EQ2B
revocation-check none
Esto evita que compruebe las CRL para saber si hemos o no revocado algún certificado, pero siempre es más que recomendable que se comprueben las CRLs. Su configuración es muy sencilla, únicamente los routers debens poder conectarse a las URLS en donde tengamos publicada la CRL y en el router cambiar revocation-check none por revocation-check crl ocsp
RE:Cisco VPN IPSec Site-to-Site con Certificados Digitales / Autor / 5 mayo, 2013
Interesante tu articulo, normalmente los Túneles IPSec se configuran como bien has detallado, sobre los routers, en ellos se puden utilizar claves que solo los routers extremos del túnel lo saben, en el caso que describes, se utilizan claves generadas desde un servidor dentro de la LAN, me parece un escenario alternativo interesante que le da participación a los dispositivos LAN en la construcción de un Tunel.
Gracias por el aporte
Respuesta a richard.retamozo@bt.com / Autor / 6 mayo, 2013
Hola Richard,
Antes de nada gracias por tu comentario en el blog, pero me gustaría matizar lo que me comentas. La configuración con de IPSec con certificados digitales va mucho más allá de ser una simple opción de configuración, sino que nos ofrece un plus de seguridad y estabilidad. En cuanto a seguridad, no es lo mismo un clave compartida que un certificado, imagino que ahí estaremos de acuerdo. En cuanto a la escalabilidad es porque puedo crecer en número de sedes sin comprometer la seguridad a lo largo del tiempo, puesto que no estoy prisionero de una clave compartida que tendría que cambiar en todos los routers de la VPN. Además, puedo ir dando de baja distintos routers con tal solo revocar el certificado y sin que afecte al resto de routers de la VPN. Si se utilizan clave compartidas, o bien no se terminan cambiando con la periodicidad que se estima o bien se utilizan claves simples y que finalmente mueren con el router (que ya no sé qué es peor …)
Imagínate si tienes 100 routers conectados a una o varias sedes centrales, sería una locura el cambiar la pre-shared key de cada router. Por mucho que lo hagamos vía remota, automatizando el proceso para que se realice el cambio todos a la vez con herramientas de terceros (yo utilizo SolarWinds) o cualquier otro método. No es comparable a que cada router presente su propia “identidad”, pero si bien es cierto que debemos tener una infraestructura de PKI bien implementada para que todo funcione correctamente, pero eso ya es otra cosa y el artículo no pretendía explicar esto.
Siempre que se pueda implementar una VPN (del tipo que sea) con IPSec y certificados digitales, adelante!!! Nunca son en vano los esfuerzos por aumentar los niveles de seguridad de nuestras infraestructuras, y sobre todo si pasan por la WAN ….
Hay bastantes más cosas a comentar de porque es mejor utilizar certificados digitales que las pre-shared key, pero más de lo mismo, queda fuera del alcance inicial del artículo.
Un saludo y gracias por leer mi blog!!!
Tunel IPSec / Autor / 21 noviembre, 2014
Que tal Santiago,
Muchas gracias por tu aporte, una vez que los routers establecen el túnel IPSec adquiriendo los certificados automáticamente de la CA de Microsoft, que pasa si el certificado expira automáticamente se renovaría? Te agradecería si pudieras compartir algún tipo de material para asegurar los routers y la CA de Microsoft, también quería preguntarte que tipo de vulnerabilidades existen en este escenario.
Saludos y muchas gracias!!!
Respuesta / Autor / 27 noviembre, 2014
Hola Francisco:
Tienes que configurar el Cisco para que pueda renovar el certificado automáticamente, y además en la CA de Microsoft permitir la solicitud de certificados sin autenticación. Si necesitas más ayuda, házmelo saber.
Un saludo
Consulta / Autor / 4 diciembre, 2014
Me ha sido de muchísima ayuda este artículo pero quería solicitarte más ayuda con lo de la solicitud de certificados sin autenticación.
Tendrás algún email, Skype o algo así para comunicarme contigo.
Saludos y muchas gracias!!!
Consulta VM Cisco? / Autor / 8 octubre, 2015
Buenas Santiago , favor ayúdame con una consulta , que usas o como haces para emular un router cisco con Windows Server ?
Yo uso Hyper-V para mis practicas de INFRA y Packet Tracer para Cisco , y apenas estoy empezando a conocer gns3 para hacer algunos labs que no sean soportados por PKT , pero no he encontrado la forma de crear un Router cisco emulado con Hyper V o algún otro virtualizador donde pueda combinar las dos plataformas para hacer practicas como la tuya. he usado Vmware y algunas cosas que he bajado simulando routers pero no con lo que quiero , asi que en Windows me toca conformarme con RRAS.