El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este artículo forma parte de una serie de artículos que explican cómo resolver sistemáticamente los problemas de la ruta de datos en sistemas Firepower para determinar si los componentes de Firepower pueden estar afectando al tráfico. Consulte el artículo Descripción general para obtener información sobre la arquitectura de las plataformas Firepower y los enlaces a otros artículos de Troubleshooting de Trayectoria de Datos.
En este artículo se describe la sexta etapa de la solución de problemas de la ruta de datos de Firepower, la función de autenticación activa.
Al intentar determinar si un problema es causado por la identidad, es importante entender qué tráfico puede afectar esta función. Las únicas funciones de la identidad que pueden causar interacciones de tráfico son las relacionadas con la autenticación activa. La autenticación pasiva no puede hacer que el tráfico se descarte inesperadamente. Es importante comprender que sólo el tráfico HTTP(S) se ve afectado por la autenticación activa. Si hay otro tráfico afectado porque la identidad no funciona, esto es más probable porque la política utiliza usuarios/grupos para permitir/bloquear el tráfico, de modo que cuando la función de identidad no puede identificar a los usuarios, pueden ocurrir cosas inesperadas, pero depende de la política de control de acceso del dispositivo y de la política de identidad. La resolución de problemas de esta sección aborda los problemas relacionados con la autenticación activa solamente.
Las funciones de autenticación activas involucran al dispositivo Firepower que ejecuta un servidor HTTP. Cuando el tráfico coincide con una regla de política de identidad que contiene una acción de autenticación activa, Firepower envía un paquete 307 (redirección temporal) a la sesión, para redirigir clientes a su servidor de portal cautivo.
Actualmente hay cinco tipos diferentes de autenticación activa. Dos redirige a un nombre de host que consta del nombre de host del sensor y el dominio primario de Active Directory vinculado al rango, y tres redirige a la dirección IP de la interfaz en el dispositivo Firepower que está realizando la redirección del portal cautivo.
Si algo sale mal en el proceso de redirección, la sesión puede interrumpirse porque el sitio no está disponible. Por este motivo, es importante comprender cómo funciona el redireccionamiento en la configuración en ejecución. El siguiente gráfico ayuda a entender este aspecto de la configuración.
Si la autenticación activa se redirige al nombre de host, se redirigiría a los clientes a ciscoasa.my-ad.domain:<port_used_for_cautive_portal>
La recolección de capturas de paquetes es la parte más importante de la resolución de problemas de autenticación activa. Las capturas de paquetes tienen lugar en dos interfaces:
Las dos capturas se inician, el tráfico interesante se ejecuta a través del dispositivo Firepower y luego se detienen las capturas.
Observe que el archivo de captura de paquetes de la interfaz interna, "ins_ntlm", se copia en el directorio /mnt/disk0. A continuación, se puede copiar en el directorio /var/common para descargarlo del dispositivo (/ngfw/var/common en todas las plataformas FTD):
> expert
# copy /mnt/disk0/<pcap_file> /var/common/
Los archivos de captura de paquetes se pueden copiar del dispositivo Firepower desde el mensaje > usando las direcciones de este artículo.
Alternativamente, no hay opción en Firepower Management Center (FMC) en Firepower versión 6.2.0 y posterior. Para acceder a esta utilidad en el FMC, navegue hasta Dispositivos > Administración de dispositivos. A continuación, haga clic en el botón junto al dispositivo en cuestión, seguido de Resolución de problemas avanzada > Descarga de archivos. A continuación, puede introducir el nombre de un archivo en cuestión y hacer clic en Descargar.
El análisis de PCAP en Wireshark se puede realizar para ayudar a identificar el problema dentro de las operaciones de autenticación activas. Dado que un puerto no estándar se utiliza en la configuración del portal cautivo (885 de forma predeterminada), Wireshark debe configurarse para decodificar el tráfico como SSL.
Se deben comparar la captura de la interfaz interna y la captura de la interfaz de túnel. La mejor manera de identificar la sesión en cuestión en ambos archivos PCAP es localizar el puerto de origen único, ya que las direcciones IP son diferentes.
En el ejemplo anterior, observe que falta el paquete hello del servidor en la captura de la interfaz interna. Esto significa que nunca regresó al cliente. Es posible que el paquete haya sido descartado por snort, o posiblemente debido a un defecto o configuración incorrecta.
Nota: Snort inspecciona su propio tráfico de portal cautivo para evitar cualquier ataque HTTP.
Si el problema no está en la pila SSL, puede ser beneficioso descifrar los datos en el archivo PCAP para ver la secuencia HTTP. Hay dos métodos para lograrlo.
Precaución: Si se utiliza el método 2, no proporcione Cisco Technical Assistance Center (TAC) su clave privada. Sin embargo, se puede utilizar un certificado de prueba temporal y una clave. También se debe utilizar un usuario de prueba en las pruebas.
En el siguiente ejemplo, se descifró un archivo PCAP. Muestra que NTLM se está utilizando como método de autenticación activo.
Después de que se realice la autorización NTLM, el cliente se redirige a la sesión original, de modo que pueda alcanzar su destino previsto, que es http://www.cisco.com.
Cuando se utiliza en una política de identidad, la autenticación activa tiene la capacidad de descartar tráfico permitido (sólo tráfico HTTP), si algo sale mal en el proceso de redirección. Un paso de mitigación rápido es inhabilitar cualquier regla dentro de la política de identidad con la acción de Autenticación activa.
Además, asegúrese de que las reglas con 'Autenticación pasiva' como acción no tengan marcada la opción 'Usar autenticación activa si la autenticación pasiva no puede identificar al usuario'.
Datos | Instrucciones |
Solución de problemas de archivo de Firepower Management Center (FMC) | https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html |
Solución de problemas de archivo del dispositivo Firepower que inspecciona el tráfico | https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html |
Capturas de paquetes de sesión completa | Consulte este artículo para obtener instrucciones |
Si se ha determinado que el componente de Autenticación activa no es la causa del problema, el siguiente paso sería resolver el problema de la función Política de intrusiones.
Haga clic aquí para continuar con el siguiente artículo.