Compare Snort 2 y Snort 3 en Firepower Threat Defence (FTD)

Introducción

Este documento describe las diferencias entre las versiones de Snort 2 y Snort 3 en Firepower.

Antecedentes

La nueva función Snort 3 se añadió en la versión 6.7 para Firepower Device Manager (FDM) y Cisco Defense Orchestrator (CDO); en la versión 7.0 para Firepower Management Center (FMC). Puede formular la pregunta: ¿Qué ha cambiado con respecto a Snort 2 y Snort 3? ¿Se puede utilizar Snort 3 en este entorno? Este documento analiza las mejoras incluidas en Snort 3, así como algunas diferencias clave que justifican ciertas consideraciones de diseño en un formato que facilita una comprensión rápida y sencilla. 

En resumen, Snort 3.0 se ha diseñado para hacer frente a los siguientes retos:

1. Reduzca el uso de memoria y CPU.

2. Mejore la eficacia de la inspección HTTP.

3. Carga de configuración más rápida y reinicio de Snort.

4. Mejor programabilidad para una incorporación más rápida de funciones.

En este documento, puede analizar cada uno de estos retos y ver cómo las nuevas funciones de Snort 3 los abordan.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Firepower Threat Defense
• Centro de administración FirePOWER
• Snort

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• FDM 6,7
• CDO 6.7
• FMC 7.0

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Diagrama de la red

Descripción general de la actualización de la función Snort 3

Novedades 

Eficacia

• Arquitectura moderna para gestionar de forma viable las evasiones de Snort2
• HTTP/2, QUIC, IoT, firmas multisesión, etc.
• Normalización inteligente del tráfico para identificar amenazas confusas
• El lenguaje de reglas mejorado permite a Talos proporcionar una mejor protección

Rendimiento

• Mejora significativa del rendimiento con respecto a Snort2
• Compatibilidad con aceleración mediante descarga regex en plataformas de última generación
• Detección elástica para aumentar o reducir los recursos de inspección
• Mejor utilización de la memoria
• Reducción del tiempo necesario para reiniciar Snort

Modularidad

• Comercialización más rápida con compatibilidad con nuevos casos prácticos
• Talos puede solucionar problemas de día cero con nuevas opciones de reglas/preprocesos
• API para una capacidad de gestión uniforme mediante Slim Shady
• Telemetría y mantenimiento mejorados

Comparación de funciones entre Snort 2 y Snort 3

La diferencia más significativa entre Snort 2 y Snort 3 es la arquitectura de procesos. Snort 2 funciona con varios procesos Snort, cada uno de ellos asociado a un núcleo de CPU individual, y dentro de cada proceso Snort hay un subproceso independiente para la gestión y el control de datos. Por otra parte, Snort 3 sólo se ejecuta en un proceso, con cada subproceso afiliado a núcleos de CPU individuales, respaldado por un subproceso de control que gestiona los datos de todos los subprocesos de procesamiento de paquetes.

La nueva arquitectura de Snort 3 elimina la necesidad de subprocesos de control por proceso y facilita el uso compartido de la configuración y los datos entre todos los subprocesos. Como resultado, se requiere menos sobrecarga para orquestar la colaboración entre los subprocesos de procesamiento de paquetes. 

Modelo de hilo de Snort 3

Dentro de un proceso Snort3, hay un subproceso de control que es responsable de activar o desactivar los subprocesos de procesamiento de paquetes y de organizar los datos, como la configuración, las reglas IPS, la tabla de reputación de IP y el mapa de red recopilados del tráfico. Todos los subprocesos de procesamiento de paquetes comparten estos recursos y el tráfico se equilibra en función de la carga para subprocesos individuales.

Reglas IPS de Snort 2 frente a Snort 3

No hay ningún cambio significativo en las reglas de sistemas de prevención de intrusiones (IPS) entre Snort 2 y Snort 3, excepto el formato. Snort 3 emplea el formato LUA para mejorar la legibilidad. 

Escenarios de recarga versus reinicio

Snort 3 mejora la conservación del tráfico durante la implementación de políticas e intenta volver a cargar las instancias de Snort siempre que puede, en lugar de reiniciarlo. La diferencia entre la recarga de Snort y el reinicio es la siguiente:

Reinicio de Snort: cuando haya disponible una nueva configuración de Snort en la implementación, primero debe eliminar todas las instancias de Snort y, a continuación, reiniciarlas de nuevo para leer y cargar la nueva configuración en la memoria.

Recarga de Snort: simplemente cargue la nueva configuración sin reiniciar Snort, evitando así la interrupción del tráfico.

Gestión de excepciones de Snort 3

Cuando un proceso Snort encuentra un error, como un acceso a direcciones no válidas, se fuerza a salir para evitar daños adicionales. Con Snort 2, dado que cada instancia de Snort tiene su propio proceso, normalmente solo una instancia de Snort se ve afectada por una salida forzada (por ejemplo, un crash). En tal situación, cada proceso Snort bloqueado genera un vaciado de memoria. 

Con el nuevo modelo de subprocesos de Snort 3, todas las instancias de Snort se ejecutan en el mismo proceso, por lo que una excepción fatal hace que se cierre todo el proceso de Snort 3 y mata todas las instancias de Snort. Si permite que todas las instancias de Snort generen un vaciado de memoria, la cantidad de datos llena rápidamente un disco duro. Por lo tanto, genera un vaciado de memoria de forma predeterminada. De forma predeterminada, un proceso Snort 3 bloqueado sólo genera un archivo de minivolcado (.dmp), que contiene únicamente el seguimiento de pila del subproceso que inició el bloqueo.

En la sección Resolución de problemas encontrará más información sobre el desperfecto de Snort 3.

Resolución de problemas de Snort 3

Esta sección proporciona algunas técnicas para verificar el estado de Snort 3 y recopilar datos de solución de problemas.

Proceso Verify Snort 3

Siga estos pasos para verificar el proceso de Snort 3:

1. En el indicador CLI de Firepower Thread Defense, ejecute expert para entrar en el modo Expert

2. Ingrese el comando sudo top y busque el nombre de proceso snort3. Registre el PID del proceso para el siguiente paso.

3. Ingrese el comando top -H <PID> para enumerar todos los subprocesos que se ejecutan en el proceso Snort 3. Ejemplo: top -H 3885

En condiciones normales de funcionamiento, el uso de la CPU para cada subproceso debe ser relativamente uniforme. Si algún subproceso tiene un uso de CPU significativamente mayor, es probable que haya un flujo de elefante que se procese bajo este subproceso.

Vaciado de memoria Snort 3

De forma predeterminada, Firepower Threat Defense solo genera un mini-coredump durante la caída del proceso de Snort 3, y el mini-dump solo contiene el seguimiento del subproceso que se bloqueó. Este comportamiento se puede inhabilitar si se requiere un vaciado de memoria completo para la resolución de problemas. 

Para activar o desactivar la función de minivolcado de núcleo:

> configure mini-coredump enable

> configure mini-coredump disable

Para verificar el estado actual de la función mini-coredump:

> show mini-coredump status

Cuando se genera un vaciado de memoria en Firepower Threat Defence, se puede encontrar en el directorio /ngfw/var/data/cores/. 

Aparte del mini volcado, Snort 3 también escribe un archivo de información de desperfecto en /ngfw/var/log/crashinfo/ que contiene la traza posterior descodificada. Este es un ejemplo de archivo crashinfo:

{
    "appid_version": "76",
    "backtrace": [
        "#0 0x1535548406d0 in nanosleep+0x40 (/lib64/libpthread.so.0 @0x15355482f000)",
        "#1 0x563293b78d89 (/ngfw/var/sf/detection_engines/945b4154-0759-11eb-ac5f-1ee9a3297167/snort3 @0x563293a8d000)",
        "#2 0x153553eb80ab in __libc_start_main+0xeb (/lib64/libc.so.6 @0x153553e94000)",
        "#3 0x563293b8edaa in _start+0x2a (/ngfw/var/sf/detection_engines/945b4154-0759-11eb-ac5f-1ee9a3297167/snort3 @0x563293a8d000)"
    ],
    "daq_msg_data": "",
    "daq_msg_data_len": 0,
    "daq_msg_header": "",
    "daq_msg_header_len": 0,
    "daq_msg_type": 0,
    "ims_build": "12",
    "ims_version": "7.0.0",
    "lsp_version": "lsp-rel-20201210-1755",
    "model": "Cisco Firepower 4120 Threat Defense",
    "model_number": "76",
    "navl_version": "100",
    "pid": 35010,
    "signal": 6,
    "snort_build": "6.114",
    "snort_version": "3.0.3",
    "ssp_build": "2.10(1.77)",
    "timestamp": "1612215695.102968",
    "vdb_build": "338",
    "vdb_version": "4.5.0"
}
snort3-crashinfo.1612215695.102968 (END)