ISE - 04 - Non-802.1X Authentication

El Capítulo 4 se titula "Non-802.1X Authentication" y aborda métodos de control de acceso a la red para dispositivos y escenarios donde la autenticación 802.1X no es factible o deseada.

La Necesidad de Autenticación No 802.1X

• Aunque el estándar IEEE 802.1X fue estandarizado a principios de la década de 2000 como una solución para el control de acceso a la red basado en puertos y se predijo que revolucionaría la red, no se ha convertido en la solución única y universal como algunos anticiparon.
• No es práctico ni posible que todos los puertos de red requieran autenticación 802.1X.
• Hay complicaciones en la gestión de una gran cantidad de dispositivos que no son PCs administrados, especialmente con la explosión de los dispositivos IoT (Internet of Things).
• Muchos dispositivos IoT no tienen o no pueden tener un suplicante configurado (el software cliente requerido para 802.1X). Piensa en impresoras, cámaras IP, lectores de credenciales, señalización digital. Configurar suplicantes y certificados en estos dispositivos a gran escala no es viable operativamente.
• El enfoque original de simplemente deshabilitar 802.1X en puertos específicos para dispositivos sin suplicantes es inseguro (permite que cualquier dispositivo se conecte) y crea una carga de gestión significativa si los dispositivos se mueven.
• Se necesitan otras formas de identificar y autorizar estos dispositivos. También para usuarios con suplicantes mal configurados o credenciales caducadas, o para usuarios invitados.

El capítulo cubre los siguientes temas como alternativas o complementos a 802.1X:

• Dispositivos sin un suplicante.
• MAC Authentication Bypass (MAB).
• El proceso MAB dentro de un framework 802.1X.
• Centralized Web Authentication (CWA).
• EasyConnect.

MAC Authentication Bypass (MAB)

• MAB es una "solución especial" para endpoints que no tienen un suplicante.
• En MAB, el autenticador (por ejemplo, un switch) actúa en nombre del endpoint.
• El autenticador crea y envía un mensaje RADIUS Access-Request al servidor de autenticación (por ejemplo, ISE).
• El autenticador utiliza la dirección MAC del endpoint como identidad (credencial) para la autenticación.
• El servidor de autenticación (RADIUS/ISE) realiza una búsqueda usando la MAC. Si la MAC está en una lista permitida, envía un mensaje RADIUS Access-Accept de vuelta al autenticador.
• Este proceso permite al endpoint acceder a la red.
• MAB no es un estándar. Cada proveedor puede implementarlo de manera diferente, aunque la comunicación RADIUS debe cumplir con el estándar.
• El autenticador detecta que un dispositivo no tiene suplicante por un timeout. Por defecto, el autenticador envía tramas de solicitud de identidad EAP sobre LAN cada 30 segundos. Después de tres timeouts (90 segundos por defecto), asume que el endpoint no tiene suplicante y puede intentar MAB. Estos temporizadores son ajustables.

Inseguridad y Mitigación de MAB

• MAB es inherentemente no seguro. Bypassea la seguridad más fuerte de 802.1X.
• Las direcciones MAC son fáciles de suplantar (spoof), lo que permite a un atacante configurar un endpoint para usar una MAC permitida y obtener acceso no autorizado.
• Al implementar MAB, siempre se debe seguir un enfoque de defensa en profundidad (defense-in-depth).
• Esto significa que la autorización para un dispositivo MAB debe ser limitada. No se debe conceder acceso total.
• Dado que MAB utiliza autenticación RADIUS estándar y la decisión de autorización proviene del servidor de autenticación, no hay limitaciones en los tipos de resultados de autorización que se pueden enviar al autenticador. Estos pueden incluir (entre otros):
  • Downloadable ACLs (dACLs)
  • Dynamic VLAN assignment (dVLAN)
  • Redirección de URL
  • Security Group Tags (SGTs)
  • Smartport macros
• Cambiar la VLAN asignada a un endpoint sin suplicante no es recomendable. El endpoint no sabe cómo detectar el cambio de VLAN y desencadenar una renovación de DHCP para obtener una nueva dirección IP en la nueva VLAN. Con 802.1X, el suplicante sí maneja esto.
• Si decides cambiar la VLAN en redes abiertas (no recomendadas), las opciones incluyen tiempos de arrendamiento DHCP muy bajos, usar un applet (ActiveX/Java) en un portal para detección, o configurar un port bounce como parte de un Change of Authorization (CoA). El port bounce puede causar problemas con dispositivos PoE (requieren reinicio) y no se recomienda.
• Otra forma de añadir seguridad a MAB es combinarlo con profiling. Profiling permite a ISE recopilar atributos adicionales (más allá de la MAC) para identificar el tipo de dispositivo, y basar la autorización en esta información.

Web Authentication (WebAuth)

• WebAuth es una alternativa cuando el endpoint no tiene suplicante, pero el usuario del endpoint sí necesita autenticarse (por ejemplo, invitados, usuarios con credenciales expiradas, o configuraciones erróneas).
• WebAuth es efectivo solo para dispositivos interactivos donde un usuario puede introducir credenciales en un navegador web (no para impresoras).
• El autenticador redirige el tráfico web (HTTP/HTTPS) del usuario a una página web (portal).
• El portal puede estar alojado localmente en el dispositivo autenticador (switch, WLC, firewall, VPN concentrator) o centralmente en el servidor de autenticación (ISE).
• El usuario introduce un nombre de usuario y contraseña en el portal.
• Estas credenciales se envían al servidor de autenticación (ISE) para validar al usuario.
• Si el portal es local en el switch, el switch envía la solicitud al servidor de autenticación en nombre del endpoint, de forma similar a MAB.
• Las credenciales pueden ser de Active Directory, credenciales de invitado, etc..
• Al igual que MAB, WebAuth no es un estándar.

Tipos de WebAuth

• Local Web Authentication (LWA): Es la forma original. El portal está alojado localmente en el autenticador.

  • El autenticador envía el RADIUS Access-Request usando el nombre de usuario y contraseña del formulario web. Cuando el switch envía las credenciales del usuario, se considera LWA.
  • LWA no se usa tanto hoy en día debido a limitaciones de personalización del portal local. Cisco switches tienen muy poca personalización. Las organizaciones a menudo requieren portales con marca corporativa.
  • LWA en Cisco switches no soporta servicios avanzados como páginas de aceptación de políticas de uso aceptable, aprovisionamiento de clientes, cambio de contraseña, autorregistro o registro de dispositivos.
  • La opción Guest VLAN en switches Cisco (para asignar una VLAN a dispositivos sin suplicante tras un timeout) es mutuamente excluyente con LWA.
  • LWA no soporta asignación de VLAN; está limitado a asignación de ACL.
  • LWA no soporta Change of Authorization (CoA), lo que impide cambiar la política de acceso basada en estado de postura, profiling o acciones administrativas.

• Local Web Authentication with a Centralized Portal: Una opción para redirigir LWA a un portal alojado centralmente (por ejemplo, en ISE). Permite personalización con marca corporativa.

  • Los portales locales en Cisco switches pueden contener la cadena de redirección al portal centralizado.
  • El portal centralizado envía las credenciales al NAD (autenticador) usando HTTP POST o un hidden iframe.
  • El método iframe no funciona con navegadores modernos. El método POST no funciona con algunos navegadores móviles y es inseguro porque las credenciales se pasan por la red al autenticador. El portal necesita lógica para elegir el método.
  • Aunque el portal es centralizado, persisten las mismas restricciones que LWA tradicional: CoA no funciona y las funcionalidades avanzadas no están disponibles. Por estas razones, no es un método ampliamente adoptado.

• Centralized Web Authentication (CWA): El método usado por Cisco ISE para WebAuth.

• CWA es solo para usuarios interactivos con navegadores web.
• La función Guest VLAN y CWA son mutuamente excluyentes.
• CoA funciona completamente con CWA. Esto permite soporte para todos los resultados de autorización, incluyendo ACL, asignación de VLAN, dACLs, SGTs, etc..
• Si se cambia la VLAN con CWA (y no hay suplicante), el portal debe usar un applet (ActiveX/Java) para manejar la detección del cambio de VLAN y desencadenar la renovación de la dirección IP. Esto puede ser problemático si las máquinas están bloqueadas. Otras opciones como dACLs o SGTs son a menudo preferibles al cambio de VLAN en CWA.
• CWA soporta servicios avanzados como aprovisionamiento de clientes, evaluaciones de postura, políticas de uso aceptable, cambio de contraseña, autorregistro y registro de dispositivos.
• El funcionamiento de CWA es diferente. El autenticador solo ve un MAB.
  • El endpoint se conecta sin suplicante.
  • El autenticador realiza MAB, enviando RADIUS Access-Request a ISE.
  • ISE envía un resultado RADIUS con una redirección de URL al portal centralizado en ISE.
  • El usuario introduce credenciales en el portal centralizado. Las credenciales NUNCA se envían al switch; se almacenan en el directorio de sesión de ISE y se vinculan a la sesión MAB.
  • ISE envía un CoA de reautenticación (CoA-reauth) al switch.
  • El switch envía una nueva solicitud MAB con el mismo ID de sesión a ISE.
  • ISE procesa la solicitud y envía el resultado de autorización final al switch para el usuario.
• CWA with Third-Party Network Device Support: Añadido en ISE Versión 2.1. Permite soportar NADs de terceros que no soportan redirección de URL nativa.
• Utiliza una VLAN de autenticación (auth VLAN) para simular el flujo de redirección.
• ISE proporciona servicios DHCP y DNS sinkhole en la auth VLAN.
• Flujo resumido con Auth VLAN: Endpoint conecta -> NAD envía MAB a ISE -> ISE envía RADIUS Access-Accept con auth VLAN -> Endpoint obtiene IP y DNS de ISE (DHCP) -> Endpoint navega, DNS query es redirigida a ISE -> ISE redirige el navegador al portal CWA -> Usuario inicia sesión en portal -> ISE envía CoA al NAD, autoriza el endpoint -> Acceso basado en CoA, endpoint obtiene IP de DHCP empresarial.

Remote-Access Connections

• Además de las conexiones cableadas e inalámbricas, un tercer caso de uso es el acceso desde otra ubicación, conocido como acceso remoto (RA).
• Históricamente usaba acceso telefónico (RADIUS significa Remote Authentication Dial-In User Service). Hoy en día, se usa principalmente VPN (Virtual Private Network).
• El concentrador VPN (por ejemplo, Cisco ASA) actúa como el autenticador, y ISE como el servidor de autenticación.
• El cliente remoto establece un túnel seguro (IPsec o SSL).
• Las credenciales del usuario se pasan dentro del túnel seguro.
• El VPN headend envía el RADIUS Access-Request a ISE.
• Las credenciales del usuario se envían típicamente a través de PAP o MS-CHAPv2 desde el ASA a ISE.
• 802.1X no está involucrado con las VPN de acceso remoto.

EasyConnect

• EasyConnect es una característica añadida en ISE Versión 2.1.
• Es una alternativa a 802.1X o WebAuth para la autenticación de usuarios.
• Proporciona autenticación basada en puertos.
• Es más fácil de implementar que 802.1X.
• Permite a los usuarios conectar un endpoint cableado y concede suficiente acceso para que los usuarios se autentiquen a través de Active Directory (AD).
• ISE recopila la información de autenticación del usuario de Active Directory y emite un CoA al dispositivo de red para conceder acceso completo.
• Puede implementarse en el mismo puerto que 802.1X y usarse durante la migración a 802.1X.

Ventajas de EasyConnect:

• No se requiere configuración de suplicante en el endpoint.
• No se requiere configuración de PKI (infraestructura de clave pública).
• ISE emite el CoA después de que Active Directory autentica al usuario.

Desventajas de EasyConnect:

• Solo se soportan NADs (Network Access Devices) de Cisco.
• IPv6 no está soportado.
• Las conexiones inalámbricas no están soportadas.
• Solo permite autenticación de usuario, no de máquina.
• Solo se soportan endpoints con Windows instalado.
• Solo se capturan eventos de inicio de sesión (logon events). No hay detección de cierre de sesión (logoff). La sesión termina con la desconexión del puerto o el inicio de sesión de un nuevo usuario.

Cómo funciona EasyConnect (Flujo Básico):

• El endpoint se conecta al autenticador cableado (switch).
• El autenticador envía una solicitud de acceso a ISE, y ISE responde con acceso basado en la configuración del usuario, permitiendo acceso a Active Directory, DNS y DHCP.
• El usuario inicia sesión en el dominio AD.
• El controlador de dominio AD envía un evento de auditoría de seguridad a ISE.
• ISE recopila la dirección MAC del evento RADIUS y la dirección IP, nombre de dominio e información de inicio de sesión del usuario del evento de auditoría de seguridad.
• Una vez que los datos se recopilan y fusionan en el directorio de sesión de ISE, ISE emite un CoA al autenticador.
• Se concede el acceso completo a la red al endpoint.
• Para interceptar la info de auth del AD, ISE debe poder conectarse al DC usando WMI y consultar logs de eventos de Windows. ISE puede simplificar esta configuración. Se requiere una cuenta AD con permisos de acceso remoto a WMI y acceso de lectura al log de eventos de seguridad del DC

Preguntas del Tema

1. ¿Por qué hay necesidad de autenticar endpoints sin usar 802.1X?

   • Existe la necesidad de autenticar endpoints sin usar 802.1X porque, más de una década después de su estandarización, 802.1X no se ha implementado en todos los puertos como se predijo.
   • Esto se debe a que no es práctico gestionar un gran número de dispositivos que no son PC administrados, especialmente con la proliferación de dispositivos IoT (Internet de las Cosas).
   • Muchos dispositivos, como impresoras, cámaras IP, lectores de credenciales, señalización digital, IP phones, thin clients y otros dispositivos "headless" o IoT, no tienen un supplicant configurado o no soportan 802.1X.
   • Incluso si un dispositivo tiene un supplicant (como los Cisco IP Phones), configurarlo de forma individual no escala bien. La configuración centralizada puede no estar disponible para todos los tipos de dispositivos.
   • La habilitación y configuración del supplicant puede ser muy complicada u operativamente difícil para la empresa.
   • El concepto original de 802.1X implicaba denegar el acceso a dispositivos sin supplicant o que no pudieran autenticarse.
   • Una "solución" anterior, que consistía en no configurar 802.1X en puertos con endpoints no autenticadores, permitía que cualquiera conectara su laptop a ese puerto para obtener acceso completo sin desafío, lo cual es inseguro. Mover estos dispositivos implicaba una carga de gestión significativa para TI.
   • Además, hay escenarios con supplicants mal configurados, credenciales expiradas, dispositivos temporales o usuarios invitados que también requieren acceso a la red de alguna forma, lo cual es difícil de manejar solo con 802.1X.
   • Por estas razones, existen métodos de autenticación alternativos a 802.1X, como MAC Authentication Bypass (MAB), Centralized Web Authentication (CWA), Local Web Authentication (LWA) y EasyConnect.

2. ¿Cuáles son algunas de las ventajas de usar EasyConnect en una empresa?

   • Según la Tabla 4-2 y la sección EasyConnect:
     • No se requiere configuración del supplicant en el endpoint.
     • No se requiere configuración de infraestructura de clave pública (PKI).
     • EasyConnect es más fácil de implementar que 802.1X.
     • ISE emite un Change of Authorization (CoA) después de que Active Directory autentica al usuario, concediendo mayor acceso a la red.
     • Puede implementarse en el mismo puerto que 802.1X y proporcionar autenticación inicial durante la migración a 802.1X.

3. ¿Por qué MAB solo se considera inseguro?

   • MAB es inherentemente no es un método de autenticación seguro.
   • Esto se debe a que se está omitiendo la seguridad más fuerte de 802.1X.
   • La principal razón de su inseguridad es que las direcciones MAC por sí solas son fácilmente falsificables (spoofed). Es sencillo configurar un endpoint para usar una dirección MAC diferente a la que está grabada en el hardware.
   • Al usar MAB, se recomienda seguir un enfoque de defensa en profundidad y conceder al endpoint un nivel de acceso limitado a las redes y servicios que realmente necesita, en lugar de acceso completo.

4. ¿Cuáles son algunas de las ventajas de CWA sobre LWA?

   • Centralized Web Authentication (CWA) ofrece varias ventajas sobre Local Web Authentication (LWA):
     • CoA funciona completamente con CWA, lo que permite soportar todos los resultados de autorización, como la asignación de ACL y VLAN. LWA está restringido del soporte de CoA, por lo tanto, la política de acceso no puede cambiar basándose en el estado de postura, perfilado o un cambio administrativo.
     • CWA soporta servicios avanzados como aprovisionamiento de cliente, evaluaciones de postura, políticas de uso aceptable (AUP), cambio de contraseña, auto-registro y registro de dispositivos. LWA no soporta servicios avanzados como páginas de aceptación de AUP, aprovisionamiento de cliente, cambio de contraseña, auto-registro o registro de dispositivos con switches Cisco, y esta restricción también aplica a LWA con portal centralizado.
     • Con CWA, las credenciales de usuario introducidas en el portal nunca se envían al switch; se almacenan en el directorio de sesión de ISE y se vinculan con la sesión MAB iniciada por el switch. Con LWA tradicional o LWA con portal centralizado (usando HTTP POST o iframe), las credenciales son enviadas al authenticator (el switch o WLC). La transferencia de credenciales al authenticator puede ser insegura con el método POST.
     • CWA utiliza intrínsecamente un portal centralizado, que, a diferencia de los portales LWA almacenados localmente en switches Cisco, permite mayor personalización para cumplir con la identidad corporativa.

5. Para el acceso remoto, ¿cómo se envían típicamente las credenciales desde el VPN headend a ISE?

   • En el caso de las conexiones de acceso remoto (RA), el VPN concentrator (generalmente un Cisco ASA) actúa como el authenticator, e ISE es el authentication server.
   • El cliente remoto (usualmente usando software AnyConnect) forma un túnel seguro (IPsec o SSL) con el VPN headend.
   • Las credenciales del usuario se pasan dentro de este túnel seguro.
   • El VPN headend envía una solicitud RADIUS Access-Request a ISE.
   • Específicamente, con un VPN de acceso remoto, las credenciales del usuario se envían típicamente a través de PAP o MS-CHAPv2 desde el ASA a ISE.

.