Fase 8 del troubleshooting de la trayectoria de datos de FirePOWER: Directiva de la Análisis de red

Introducción

Este artículo es parte de a la serie de artículos que expliquen cómo resolver problemas sistemáticamente la trayectoria de datos en los sistemas de FirePOWER para determinar si los componentes de FirePOWER pueden afectar al tráfico. Refiera por favor al artículo para información de la descripción acerca de la arquitectura de las Plataformas y de los links de FirePOWER a los otros artículos del troubleshooting de la trayectoria de datos.

Este artículo cubre la octava planta del troubleshooting de la trayectoria de datos de FirePOWER, la función de políticas de la Análisis de red.

Prerrequisitos

• Este artículo es aplicable a todas las Plataformas de FirePOWER
  
  • La característica del rastro está solamente disponible en la versión de software 6.2.0 y arriba para la plataforma de la defensa de la amenaza de FirePOWER (FTD) solamente.
• El conocimiento del Snort del código abierto es útil, aunque no requerido
  • Para la información sobre el Snort del código abierto, visite por favor https://www.snort.org/

Resolver problemas la función de políticas de la Análisis de red

La directiva de la Análisis de red (SIESTA) contiene las configuraciones del preprocesador del snort que realizan los exámenes en el tráfico, sobre la base de la aplicación identificada. Los preprocesadores tienen la capacidad de caer el tráfico, sobre la base de la configuración. Direccionamientos de este artículo cómo verificar la configuración y la comprobación para de la SIESTA los descensos del preprocesador.

Nota: Las reglas del preprocesador tienen una identificación del generador (GID) con excepción del '1' o del '3' (es decir 129, 119, 124). Más información sobre GID a las asignaciones del preprocesador se puede encontrar en el FMC ConfigurationGuides.

Usando la herramienta del “rastro” para encontrar los descensos del preprocesador (FTD solamente)

La herramienta del rastro del soporte de sistema se puede utilizar para detectar los descensos realizados en el nivel del preprocesador.

En el ejemplo abajo, el preprocesador de la normalización TCP detectó una anomalía. Como consecuencia, el tráfico es caído por la regla 129:14, que busca los grupos fecha/hora que falta dentro de una secuencia TCP.

Nota: Aunque el preprocesador de la configuración de la secuencia TCP caiga el tráfico, puede hacer tan porque el preprocesador en línea de la normalización también se activa. Para más en la normalización en línea, usted puede leer este artículo.

Verifique la configuración de la SIESTA

En el centro de administración de FirePOWER (FMC) UI, la SIESTA se puede ver bajo las directivas > el control de acceso > intrusión. Entonces, haga clic en la opción de la directiva de la Análisis de red en la esquina superior derecha, después de lo cual usted puede ver las siestas, crear los nuevos y corregir los existencias.

Como se ve en el ejemplo arriba, las siestas contienen una característica del “modo en línea”, que es el equivalente del “descenso cuando en línea” opción en la directiva de la intrusión. Un paso rápido de la mitigación para prevenir la SIESTA del tráfico de caída sería uncheck el modo en línea. Los eventos de la intrusión generados por la SIESTA no visualizan cualquier cosa en la tabulación en línea del resultado con el modo en línea inhabilitado.

Configuraciones de la SIESTA de la visión

Dentro de la SIESTA, usted puede ver las configuraciones actuales. Esto incluye los preprocesadores activados totales, seguidos por

preprocesadores activados con las configuraciones no predeterminadas (unas que fueron pellizcadas manualmente) y unas que se activan con las configuraciones por defecto, como se ve en el ejemplo abajo.

Configuraciones de la SIESTA que pueden causar los descensos silenciosos

En el ejemplo mencionado en la sección del rastro, la regla 129:14 de la configuración de la secuencia de la regla TCP está cayendo el tráfico. Esto es determinada mirando el resultado de la traza del soporte de sistema. Sin embargo, si la regla dicha no se activa dentro de la directiva respectiva de la intrusión, no se envía ningunos eventos de la intrusión al FMC.

La razón por la que sucede ésta es debido a una configuración dentro del preprocesador en línea de la normalización llamado las anomalías irresolubles del encabezado TCP del bloque. Esta opción permite básicamente que el Snort realice una acción del bloque cuando ciertas GID reglas 129 detectan las anomalías en la secuencia TCP.

Si se activan las anomalías irresolubles del encabezado TCP del bloque, se recomienda para girar GID las reglas 129 por el ejemplo abajo.

Girando GID el 129 gobierna los eventos de la intrusión de las causas que se enviarán al FMC cuando toman medidas en el tráfico. Sin embargo, mientras se activen las anomalías irresolubles del encabezado TCP del bloque, puede todavía caer el tráfico incluso si el estado de la regla en la directiva de la intrusión se fija para generar solamente los eventos. Este comportamiento se explica en las guías de configuración FMC.

La documentación antedicha se puede encontrar en este artículo (para la versión 6.4, que es la mayoría de la versión reciente a la hora de esta fijación del artículo).

Verifique la configuración backend

Otra capa de complejidad se agrega al comportamiento del preprocesador en que ciertas configuraciones se pueden activar en la parte, sin el reflejo en el FMC. Éstas son algunas razones posibles.

• Otras características activadas tienen la capacidad de forzar las configuraciones del preprocesador del permiso (la principal que es la directiva del fichero)
• Algunas reglas de la directiva de la intrusión requieren ciertas opciones del preprocesador para realizar la detección
• Un defecto puede causar el comportamiento
  • Hemos visto un caso de esto: CSCuz50295 - “clasifíe la directiva con la normalización de los permisos TCP del bloque de Malware con el indicador del bloque”

Antes de mirar la configuración backend, observe que las palabras claves del Snort, que se utilizan en los archivos de configuración backend del Snort, pueden ser consideradas asomando sobre una configuración específica dentro de la SIESTA. Refiera por favor al ejemplo abajo.

La opción irresoluble de las anomalías del encabezado TCP del bloque en la tabulación de la SIESTA traduce a la palabra clave del bloque en la parte. Con esa información en la mente, la configuración backend se puede controlar del shell experto.

 Crear una SIESTA apuntada

Si ciertos host están accionando los eventos del preprocesador, una SIESTA de encargo se puede utilizar para examinar el tráfico a o desde los host dichos. Dentro de la SIESTA de encargo, las configuraciones que están causando los problemas pueden ser inhabilitadas.

Éstos son los pasos para ejecutar una SIESTA apuntada.

1. Cree la SIESTA por las instrucciones mencionadas adentro verifican la sección de configuración de la SIESTA de este artículo.
2. En la ficha Avanzadas de la directiva del control de acceso, navegue a la Análisis de red y a la sección de las directivas de la intrusión. El tecleo agrega la regla y crea una regla, usando los host apuntados y elige la SIESTA creada recientemente en la sección Política de la Análisis de red.

Análisis del falso positivo

El controlar para saber si hay falsos positivos en los eventos de la intrusión para las reglas del preprocesador es muy diferente que el de las reglas del Snort usadas para la evaluación de la regla (que contienen a GID de 1 y 3).

Para realizar un análisis del falso positivo para los eventos de la regla del preprocesador, una captura de la sesión completa es necesaria buscar las anomalías dentro de la secuencia TCP.

En el ejemplo abajo, el análisis del falso positivo se está realizando en la regla 129:14, que se muestra para caer el tráfico en los ejemplos anteriores. Puesto que 129:14 está buscando el TCP fluye en qué grupos fecha/hora faltan, usted puede ver claramente porqué la regla fue accionada por el análisis de la captura de paquetes ilustrado abajo.

Pasos de la mitigación

Para atenuar rápidamente los posibles problemas con la SIESTA, los pasos siguientes pueden ser realizados.

• Si se está utilizando una SIESTA de encargo y usted no está seguro si una configuración de la SIESTA está cayendo el tráfico pero usted sospecha que puede ser que sea, usted puede intentar substituirlo por “Seguridad y Conectividad” o “Conectividad equilibrada sobre una directiva de la Seguridad”.

• Si se están utilizando algunas “reglas de encargo”, asegúrese de fijar la SIESTA a uno de los valores por defecto mencionados anteriormente
• Si algunas reglas del control de acceso utilizan una directiva del fichero, usted puede necesitar intentar temporalmente quitarla mientras que una directiva del fichero puede activar las configuraciones del preprocesador en la parte que no deben para ser reflejadas en el FMC, y ésta sucede en un nivel “global”, significando que todas las siestas están modificadas.

Cada protocolo tiene un diverso preprocesador y resolverlas problemas pueden ser muy específicas al preprocesador. Este artículo no cubre todas las configuraciones del preprocesador y métodos del troubleshooting para cada uno.

Usted puede controlar la documentación para que cada preprocesador consiga una mejor idea de lo que hace cada opción, que es útil al resolver problemas un preprocesador específico.

Datos a proporcionar a TAC

Datos	Instrucciones
Fichero del Troubleshooting del dispositivo de FirePOWER	http://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html
Captura completa del paquete de sesión del dispositivo de FirePOWER	http://www.cisco.com/c/en/us/support/docs/security/sourcefire-firepower-8000-series-appliances/117778-technote-sourcefire-00.html