Políticas de Autenticación
Este capítulo trata sobre las Políticas de Autenticación en el contexto del control de acceso a la red, particularmente utilizando Cisco ISE. La autenticación es la validación de una credencial. Es una parte crucial del proceso de control de acceso a la red.
Se utiliza una analogía real, como ser detenido por exceso de velocidad, para explicar la autenticación: el oficial valida la licencia de conducir y el seguro, comprobando su validez, hologramas, fechas y bases de datos (como la del DMV). Si pasa estas verificaciones, la autenticación es exitosa.
Las políticas de autenticación tienen varios objetivos principales:
- Descartar tráfico no permitido para ahorrar recursos de procesamiento. Similar a cómo un oficial rechazaría una tarjeta de biblioteca como identificación para conducir.
- Dirigir las solicitudes de autenticación al almacen de identidad correcta. Esto se compara con un oficial que consulta la base de datos del DMV apropiado.
- Validar la identidad. El oficial determina si la licencia es válida para el conductor.
- Pasar las autenticaciones exitosas a la política de autorización. Similar a cómo el oficial anota las leyes que el conductor ha infringido.
Es fundamental comprender la diferencia entre autenticación y autorización. La autenticación es la verificación de una identidad. Un ejemplo es un empleado de banco verificando tu identificación. Sin embargo, una autenticación exitosa no significa automáticamente que tengas derecho al acceso solicitado.
La autorización determina qué acceso se debe conceder después de una autenticación exitosa. Utilizando la analogía del banco, después de validar tu identificación (autenticación), el empleado verifica si estás autorizado a retirar dinero de la cuenta y hasta qué límite (autorización). La mayor parte del trabajo en Cisco ISE se dedica a configurar y ajustar la política de autorización.
Políticas de Autenticación en ISE
Las políticas de autenticación son el primer punto de interacción de Cisco ISE con una solicitud RADIUS Access-Request de un dispositivo de acceso a la red (NAD). Su objetivo es procesar la solicitud rápidamente: descartarla si es inválida, denegarla si las credenciales son incorrectas, o reenviarla a las políticas de autorización si es exitosa.
Objetivo 1: Aceptar solo Protocolos Permitidos
Por defecto, ISE permite casi todos los protocolos de autenticación soportados, pero se recomienda permitir solo los esperados y soportados por seguridad y eficiencia. Esto reduce la carga en los PSNs, ayuda a elegir almacén de identidad correcta y previene el uso de protocolos vulnerables u obsoletos. Por ejemplo, si solo se soporta EAP-TLS para un SSID corporativo, se puede configurar para que solo ese protocolo esté permitido. La elección de protocolos debe basarse en la política de seguridad de la organización. Deshabilitar protocolos menos seguros es una práctica recomendada. La configuración incluye no solo qué protocolos permitir, sino también su ajuste específico (como EAP-FAST con aprovisionamiento de PAC o EAP chaining).
Los protocolos permitidos se configuran en una lista. La lista Default Network Access por defecto es muy inclusiva, pero se recomienda limitarla. Puedes crear listas de protocolos permitidos más restrictivas para cada conjunto de políticas (Policy Set). Algunos protocolos de autenticación comunes son:
- Process Host Lookup: Usado para MAC Authentication Bypass (MAB). ISE toma la MAC address como usuario/contraseña y la busca en la base de datos interna.
- PAP (Password Authentication Protocol): Envía el usuario en texto plano y la contraseña opcionalmente encriptada.
- CHAP (Challenge Handshake Authentication Protocol): Encripta usuario/contraseña usando un desafío del servidor. No muy común en acceso a red.
- Tipos EAP (Extensible Authentication Protocol): Un framework para transportar credenciales (usuarios, contraseñas, certificados). 802.1X define EAP over LAN.
- EAP-MD5: Usa un algoritmo de hash MD5 para ocultar credenciales. No soporta autenticación mutua (el cliente no autentica al servidor). Común en algunos teléfonos IP.
- EAP-TLS: Usa TLS (Transport Layer Security) para transacciones seguras. Muy seguro, usa certificados X.509 y soporta autenticación mutua. Considerado el estándar de oro de los tipos EAP.
- Tipos EAP Tunelizados: Forman túneles seguros encriptados primero y luego transmiten credenciales dentro del túnel.
- PEAP (Protected EAP): Propuesto por Microsoft. El método EAP más popular. Forma un túnel TLS usando el certificado del servidor. Usa otro tipo EAP como "método interno" para autenticar al cliente. Métodos internos soportados: EAP-MS-CHAPv2 (el más común, para usuario/contraseña o nombre/contraseña de ordenador, autentica a Active Directory), EAP-GTC (Generic Token Card, creado por Cisco, permite autenticaciones genéricas a casi cualquier tienda de identidad, como OTP, LDAP), EAP-TLS (raramente usado).
- EAP-FAST (Flexible Authentication via Secure Tunneling): Creado por Cisco. Similar a PEAP, forma un túnel TLS exterior. Permite reautenticación y roaming inalámbrico más rápidos usando PACs (Protected Access Credentials). Un PAC es como una cookie segura que prueba una autenticación exitosa. No soportado nativamente por Windows hasta Vista (requiere Cisco AnyConnect NAM). Métodos internos soportados: EAP-MS-CHAPv2 (el más común, para usuario/contraseña o nombre/contraseña de ordenador a Active Directory), EAP-GTC (para autenticaciones genéricas a varias tiendas de identidad), EAP-TLS (popular para EAP chaining). EAP chaining con EAP-FASTv2 permite autenticar múltiples credenciales (usuario y máquina) en una sola transacción EAP.
- EAP-TTLS (Tunneled TLS EAP): Similar a PEAP. Encapsula una sesión TLS. Puede autenticar al servidor o tener autenticación mutua. Windows previo a Windows 8 no lo soporta nativamente. Métodos internos aceptados: PAP, CHAP, MS-CHAPv1, MS-CHAPv2, EAP-MD5.
- TEAP: Nueva adición en Windows 10. Usa TLS para establecer un túnel mutuamente autenticado. Introduce la posibilidad de EAP-Chaining nativamente en Windows 10 (build 2004) y ISE 2.7 patch 1.
Objetivo 2: Seleccionar el almacén de Identidad Correcta
Después de aceptar la autenticación, ISE decide qué almacén de identidad (fuente de identidad o PIP) usar para verificar las credenciales. La decisión se basa en los atributos de la solicitud entrante. Por ejemplo, si se presenta un certificado, ISE no lo validará contra una base de datos de usuarios y contraseñas. Si hay múltiples dominios de Active Directory o almacenes LDAP, ISE puede usar atributos de la solicitud para determinar cuál consultar.
Objetivo 3: Validar la Identidad
Una vez identificada el almacén de identidad correcta, ISE verifica la validez de las credenciales.
- Para autenticaciones basadas en contraseña: ¿Usuario válido? ¿Contraseña coincide?.
- Para autenticaciones basadas en certificado: ¿Emitido por una CA de confianza? ¿Expirado? ¿Revocado? ¿Cliente probó posesión? ¿Certificado tiene el uso de clave y extensiones correctos?.
Objetivo 4: Pasar la Solicitud a la Política de Autorización
Si una autenticación falla, la política de autenticación puede rechazar la solicitud. Si una solicitud pasa la autenticación, se evalúa la política de autorización.
Comprensión de los Conjuntos de Políticas (Policy Sets)
Los Conjuntos de Políticas son contenedores lógicos para las políticas de autenticación y autorización. En versiones anteriores de ISE, había una única política general de autenticación y autorización, lo que hacía los cambios y la resolución de problemas arriesgados. Los policy sets mitigan esto.
Cada policy set tiene una regla de nivel superior con condiciones que deben cumplirse. Si una solicitud RADIUS cumple las condiciones de la regla de nivel superior, se evalúa contra las políticas de autenticación y autorización dentro de ese policy set específico. Esto localiza las políticas y reduce el riesgo de que una mala configuración afecte otras solicitudes.
La regla de nivel superior define la lista de protocolos permitidos para ese policy set. Aunque parezca confuso que esto esté encima de la política de autenticación, simplifica la configuración al definirla una vez por policy set en lugar de por cada regla individual.
Los policy sets son jerárquicos. Si una solicitud RADIUS coincide con las reglas de nivel superior de varios policy sets, se elige el que aparece más alto en la lista.
Estructura de las Reglas de Autenticación
Las reglas básicas de autenticación en un policy set se estructuran lógicamente así:
IF condiciones THEN CHECK THE IDENTITY STORE IN LIST IdentityStore
Las reglas se procesan de arriba hacia abajo, primera coincidencia.
- Condiciones: Definen cuándo se aplica una regla. Pueden usar condiciones inteligentes predefinidas como Wired_MAB o Wireless_MAB, que contienen condiciones específicas. Las condiciones inteligentes pueden ser reutilizadas.
- Las condiciones se configuran en el Conditions Studio. El Conditions Studio tiene un Editor (donde creas/editas condiciones simples/compuestas, agregas niveles jerárquicos con AND/OR, estableces "Is Not", seleccionas atributos y valores) y una Librería (donde se guardan las condiciones reutilizables, arrastras condiciones de la librería al editor para usarlas).
- Wired_MAB busca el tipo de flujo RADIUS normalizado Wired_MAB. Wireless_MAB busca Wireless_MAB. El atributo
Called-Station-ID describe el nombre del SSID inalámbrico.
- Almacén de Identidad (Identity Store): Después de coincidir con las condiciones, la solicitud se autentica contra el almacén de identidad seleccionada. Para MAB, se compara con la base de datos interna de endpoints (direcciones MAC). Si la MAC address está en la base de datos, se considera un MAB exitoso. MAB omite la autenticación y no se considera seguro por sí mismo. Un almacén de identidad puede ser una secuencia de fuentes de identidad (ISS).
- Opciones (Options): Un conjunto de opciones asociadas con la selección del almacén de identidad. Le dicen a ISE qué hacer si la autenticación falla, el usuario/dispositivo es desconocido o el proceso falla.
- Reject: Envía Access-Reject de vuelta al NAD.
- Continue: Continúa a la política de autorización, independientemente de si la autenticación pasó o falló. Usado con autenticación web.
- Drop: No responde al NAD; el NAD actúa como si el servidor RADIUS estuviera caído.
Más sobre MAB (MAC Authentication Bypass)
El MAB a menudo no se entiende bien, especialmente al mezclar proveedores de dispositivos de acceso. No existe un estándar para MAB; los proveedores lo implementan de diferentes maneras. El objetivo es permitir que el supplicant en el switch ejecute una solicitud de autenticación para un endpoint que no tiene supplicant propio.
Algunos proveedores usan Service-Type Login o Framed en el mensaje RADIUS para MAB. Cisco utiliza Service-Type Call-Check para MAB. Cisco lo hace de manera diferente por seguridad. Históricamente, había una vulnerabilidad al no diferenciar las solicitudes MAB de las solicitudes de autenticación web local, permitiendo a un usuario malintencionado usar una MAC address como usuario/contraseña para obtener acceso.
Para cerrar esta brecha, Cisco implementó requisitos únicos para MAB:
- Para ser procesadas como MAB (por defecto), las solicitudes deben tener
Service-Type establecido en Call-Check.
- Los servidores RADIUS (ISE) mantienen una base de datos de endpoints separada (direcciones MAC).
- El valor de
Calling-Station-Id se compara con la base de datos de endpoints, e IGNORA los campos de usuario y contraseña de la solicitud MAB.
Los NADs soportados por Cisco usan Call-Check para Service-Type en solicitudes MAB y aseguran que el campo Calling-Station-Id esté lleno con la MAC address del endpoint. ISE tiene una opción (Process Host Lookup) en la lista de protocolos permitidos para permitir/denegar acceso a la base de datos de endpoints para MAB.
MAB no es una tecnología segura. Al implementarlo, se omite la seguridad de 802.1X. Al usar MAB, siempre sigue un enfoque de defensa en profundidad: concede acceso solo a las redes y servicios que el dispositivo realmente necesita. No proporciones acceso completo a dispositivos autenticados por MAB, sino una autorización más limitada.
Respuestas al Q&A
Las respuestas a estas preguntas aparecen en el Apéndice A de la fuente. Basándome en el texto proporcionado:
- ¿Qué es autenticación?
La autenticación es simplemente la validación de una credencial. En otras palabras, es la verificación de una identidad.
- ¿Qué es autorización?
La autorización es el proceso que determina si, después de una autenticación exitosa, un usuario o dispositivo tiene el derecho o permiso para acceder a un recurso o realizar una acción. Es donde se especifica qué acceso debe concederse después de una autenticación exitosa.
- ¿Cuáles son los objetivos de una política de autenticación?
Los objetivos de una política de autenticación son:
- Descartar tráfico no permitido.
- Dirigir las solicitudes de autenticación a la tienda de identidad correcta.
- Validar la identidad.
- Pasar las autenticaciones exitosas a la política de autorización.
La opción 'c' en la pregunta 3 del quiz resume bien estos objetivos: Descartar solicitudes usando un método incorrecto, dirigir solicitudes a la tienda de identidad correcta, validar la identidad y pasar autenticaciones exitosas a la política de autorización.
- ¿Qué son los policy sets?
Los policy sets son contenedores lógicos que encapsulan políticas de autenticación y autorización específicas. Proporcionan una forma de agrupar y organizar políticas para diferentes casos de uso de acceso a la red, mejorando la administración y reduciendo el riesgo de cambios. Cada policy set tiene una regla de nivel superior que determina si una solicitud RADIUS se evalúa contra las políticas dentro de ese contenedor.
- ¿Cómo hacen los NADs de Cisco el MAB de manera diferente a los NADs de otros proveedores?
Mientras que otros proveedores pueden usar
Service-Type Login o Framed para MAB, los NADs de Cisco soportados usan Service-Type Call-Check para las solicitudes MAB. Además, ISE mantiene una base de datos de endpoints separada y compara el valor de Calling-Station-Id (que contiene la MAC address del endpoint) con esa base de datos, ignorando los campos de usuario y contraseña de la solicitud MAB. Esta diferencia en el uso de Service-Type y el enfoque en Calling-Station-Id junto con una base de datos separada fue implementado por Cisco para mejorar la seguridad y mitigar vulnerabilidades históricas.
Respuestas al Cuestionario “Do I Know This Already?” Quiz
-
¿Cuál de los siguientes es requerido para realizar MAB desde un dispositivo de red Cisco? El MAB de Cisco, Service-Type debe ser Call-Check y Calling-Station-Id debe estar poblado con la MAC address del endpoint.
La opción que coincide es:
b. The RADIUS packet must have Service-Type set to Call-Check and Calling-Station-Id populated with the MAC address of the endpoint.
-
¿Qué tipo de EAP es capaz de realizar EAP chaining? EAP chaining en la descripción de EAP-FAST (específicamente EAP-FASTv2) y también menciona la posibilidad con TEAP. De las opciones proporcionadas, EAP-FAST es el que se describe explícitamente como capaz de realizar EAP chaining.
La opción que coincide es:
b. EAP-FAST
-
¿Cuáles de los siguientes son propósitos de una política de autenticación? c. To drop requests using an incorrect authentication method, route authentication requests to the correct identity store, validate the identity, and pass successful authentications over to the authorization policy.
-
¿Qué opción necesita estar habilitada en la lista de protocolos permitidos de autenticación para aceptar MAB?
La sección "Allowed Protocols" menciona que la opción Process Host Lookup se usa para MAC Authentication Bypass (MAB).
La opción que coincide es:
b. Process Host Lookup
-
¿Dónde se guardan las condiciones reutilizables?
La sección Conditions Studio menciona que al hacer clic en "Save" en el editor, puedes añadir una condición a la Librería. La librería muestra los bloques de condición guardados.
La opción que coincide es:
a. Library
-
¿Qué método funcionará efectivamente para permitir que se seleccione un almacén de identidad diferente para cada tipo de EAP utilizado?
La sección "Alternative ID Stores Based on EAP Type" describe el proceso de crear una regla separada en la política de autenticación para cada tipo de EAP (EAP-TLS, PEAP, EAP-FAST, EAP-MD5) y asociar cada regla con una tienda de identidad diferente.
La opción que coincide es:
d. Create a rule for each EAP type under the policy set’s authentication policy that points to the appropriate identity store for each rule.
-
¿Qué atributo RADIUS se usa para coincidir con el SSID?
La sección "Using the Wireless SSID" indica que el atributo a usar es Called-Station-Id ya que es el campo que describe el nombre del SSID inalámbrico.
La opción que coincide es:
d. Called-Station-ID
-
¿Qué atributo RADIUS contiene la MAC address del endpoint?
La sección "More on MAB" indica que el campo Calling-Station-Id está poblado con la MAC address del endpoint para las solicitudes MAB de Cisco.
La opción que coincide es:
a. Calling-Station-ID
-
¿Cuál es el propósito de la opción 'continue' de una regla de autenticación?
La sección "Options" describe la opción Continue como la que permite continuar a la política de autorización, independientemente de si la autenticación pasó o falló.
La opción que coincide es:
c. The continue option is used to send an authentication to the authorization policy, even if the authentication was not successful.
-
En el Conditions Studio, ¿cuál de las siguientes opciones no puedes hacer? (Elige tres.) El Conditions Studio con un Editor y una Librería. En el Editor, puedes crear y editar condiciones simples y compuestas y seleccionar atributos y valores. Puedes guardar condiciones creadas/editadas en el Editor a la Librería. Puedes usar condiciones de la Librería arrastrándolas al Editor. Las configuraciones de tienda de identidad y opciones (el "resultado" de la regla de autenticación) se realizan fuera del Conditions Studio.
Basado en esta descripción:
- b. Create and edit simple and compound conditions. SÍ puedes hacerlo en el Editor.
- d. Select the attribute and attribute value to use. SÍ puedes hacerlo en el Editor.
Esto significa que no puedes hacer 'b' ni 'd' según la pregunta, pero la descripción dice lo contrario.
- a. Create and edit the authentication rule result. NO puedes hacerlo en el Conditions Studio, se hace fuera.
- c. Create and edit library conditions. NO puedes hacerlo directamente en la lista de la librería. Creas/editas en el Editor y guardas a la librería, o usas de la librería arrastrando al Editor. No hay una función descrita para editar elementos dentro de la lista de la librería.
Dado que las opciones 'b' y 'd' son claramente descritas como acciones posibles dentro del Conditions Studio Editor, y la pregunta pide TRES cosas que no puedes hacer, parece haber una inconsistencia en la pregunta tal como se presenta en la fuente o las opciones proporcionadas. No puedo identificar de manera concluyente TRES acciones que no se puedan realizar basándome únicamente en la descripción del Conditions Studio proporcionada. Sin embargo, 'a' (crear/editar el resultado de la regla) y 'c' (crear/editar directamente en la librería) parecen ser cosas que no se pueden hacer como se describe el flujo de trabajo. Necesitaría una tercera, pero las opciones b y d contradicen la descripción si se seleccionan como acciones imposibles. Por lo tanto, no puedo responder definitivamente a esta pregunta tal como está planteada con las opciones proporcionadas y la descripción del texto.
