Solución de problemas entre FireSIGHT System y eStreamer Client (SIEM)

 

Introducción

Event Streamer (eStreamer) permite transmitir varios tipos de datos de eventos desde un sistema FireSIGHT a una aplicación cliente desarrollada a medida. Después de crear una aplicación cliente, puede conectarla a un servidor eStreamer (por ejemplo, un FireSIGHT Management Center), iniciar el servicio eStreamer y comenzar a intercambiar datos. La integración de eStreamer requiere programación personalizada, pero permite solicitar datos específicos de un dispositivo. Este documento describe cómo se comunica un cliente eStreamer y cómo resolver un problema con un cliente.

 

Método de comunicación entre el cliente eStreamer y el servidor

Existen cuatro etapas principales de comunicación entre un cliente y el servicio eStreamer:

Paso 1: El cliente establece una conexión con el servidor eStreamer

Primero, un cliente establece una conexión con el servidor eStreamer y la conexión es autenticada por ambas partes. Antes de que un cliente pueda solicitar datos de eStreamer, debe iniciar una conexión TCP con SSL habilitada con el servicio eStreamer. Cuando el cliente inicia la conexión, el servidor eStreamer responde, iniciando un intercambio de señales SSL con el cliente. Como parte del intercambio de señales SSL, el servidor eStreamer solicita el certificado de autenticación del cliente y verifica que el certificado sea válido.
 
Después de establecer la sesión SSL, el servidor eStreamer realiza una verificación adicional posterior a la conexión del certificado. Una vez finalizada la verificación posterior a la conexión, el servidor eStreamer espera una solicitud de datos del cliente.
 

Paso 2: El cliente solicita datos del servicio eStreamer

En este paso, el cliente solicita datos del servicio eStreamer y especifica los tipos de datos que se van a transmitir. Un único mensaje de solicitud de evento puede especificar cualquier combinación de los datos de evento disponibles, incluidos los metadatos del evento. Una solicitud de perfil de host único puede especificar un host único o varios hosts. Hay dos modos de solicitud disponibles para solicitar datos y puntos de evento;

• Solicitud de flujo de evento: El cliente envía un mensaje que contiene indicadores de solicitud que especifican los tipos de eventos solicitados y la versión de cada tipo, y el servidor eStreamer responde transmitiendo los datos solicitados.
• Solicitud ampliada: El cliente envía una solicitud con el mismo formato de mensaje que para las solicitudes de flujo de eventos, pero establece un indicador para una solicitud extendida. Esto inicia una interacción de mensajes entre el cliente y el servidor eStreamer a través del cual el cliente solicita información adicional y combinaciones de versiones no disponibles a través de solicitudes de flujo de eventos.

 

Paso 3: eStreamer establece el flujo de datos solicitado

En esta etapa, eStreamer establece el flujo de datos solicitado al cliente. Durante los períodos de inactividad, eStreamer envía mensajes nulos periódicos al cliente para mantener la conexión abierta. Si recibe un mensaje de error del cliente o de un host intermedio, cierra la conexión.

 

Paso 4: La conexión finaliza

El servidor eStreamer también puede cerrar una conexión de cliente por los siguientes motivos:

• Cuando se envía un mensaje, se produce un error. Esto incluye tanto los mensajes de datos de eventos como el mensaje de mantenimiento nulo que eStreamer envía durante los períodos de inactividad.
• Se produce un error al procesar una solicitud de cliente.
• La autenticación del cliente falla (no se envía ningún mensaje de error).
• El servicio eStreamer se está cerrando (no se envía ningún mensaje de error).

El Cliente No Muestra Ningún Evento

Si no ve ningún evento en su aplicación cliente eStreamer, siga estos pasos para solucionar este problema:

Paso 1: Verifique la Configuración

Paso 2: Verificar el certificado

Asegúrese de agregar los certificados necesarios. Antes de que eStreamer pueda enviar eventos eStreamer a un cliente, el cliente debe agregarse a la base de datos de peers del servidor eStreamer mediante la página de configuración de eStreamer. El certificado de autenticación generado por el servidor eStreamer también se debe copiar al cliente.

Paso 3: Verifique los mensajes de error

Identifique cualquier error obvio relacionado con eStreamer en /var/log/messages usando el siguiente comando:
 

admin@FireSIGHT:~$ grep -i estreamer /var/log/messages | grep -i error

Paso 4: Verifique la conexión

Verifique que el servidor esté aceptando conexiones entrantes.
 

admin@FireSIGHT:~$ netstat -an | grep 8302

El resultado debe verse como se muestra a continuación. Si no es así, es posible que el servicio no se esté ejecutando.
 

tcp 0 0 <local_ip>:8302 0.0.0.0:* LISTEN

Paso 5: Comprobar el estado del proceso

Para verificar si hay un proceso sfestreamer en ejecución, utilice el siguiente comando:
 

admin@FireSIGHT:~$ pstree -a | grep -i sfestreamer

El cliente muestra eventos duplicados

Controlar eventos duplicados mostrados en un cliente

El servidor eStreamer no guarda un historial de los eventos que envía, por lo que la aplicación cliente debe comprobar si hay eventos duplicados. Los eventos duplicados pueden ocurrir por diversos motivos.  Por ejemplo, al iniciar una nueva sesión de streaming, el tiempo especificado por el cliente como punto de partida para la nueva sesión puede tener varios mensajes, algunos de los cuales pueden haberse enviado en la sesión anterior y otros no. eStreamer envía todos los mensajes que cumplen los criterios de solicitud especificados. Las aplicaciones cliente EStreamer deben estar diseñadas para detectar y desduplicar cualquier duplicado resultante.

Administrar solicitudes duplicadas de datos

Si solicita varias versiones de los mismos datos, ya sea por varios indicadores o por varias solicitudes extendidas, se utiliza la versión más alta. Por ejemplo, si eStreamer recibe solicitudes de indicador para eventos de detección versiones 1 y 6 y una solicitud extendida para la versión 3, envía la versión 6.

El cliente muestra un ID de regla de Snort incorrecto (SID)

Esto suele ocurrir debido a un conflicto SID cuando se importa una regla al sistema, el SID se remapea internamente.

Para utilizar el SID especificado, en lugar del SID reasignado, debe habilitar el encabezado extendido. El bit 23 solicita encabezados de eventos extendidos. Si este campo se establece en 0, los eventos se envían con un encabezado de evento estándar que sólo incluye el tipo de registro y la longitud del registro.

Figura: El diagrama ilustra el formato de mensaje utilizado para solicitar datos de eStreamer. Los campos específicos del formato del mensaje de solicitud se resaltan en gris.

Figura: El diagrama ilustra el formato de la información del mensaje de regla para un evento que se transmite dentro de un registro de mensaje de regla. Muestra el RuleID (que está utilizando ahora) y el Rendering Signature ID (que es el número que espera).

Consejo: Para encontrar la descripción detallada de cada bit y mensaje, lea la Guía de Integración de eStreamer.

Recopilación y análisis de datos adicionales

Prueba con el script ssl_test.pl

Utilice el script ssl_test.pl proporcionado en el Kit de desarrollo de software (SDK) para identificar el problema. El SDK está disponible en un archivo zip en el sitio de soporte. Las instrucciones para el script están disponibles en README.txt, que se incluye en ese archivo zip.

Paquetes de captura (PCAP)

Capture paquetes en la interfaz de administración del servidor eStreamer y analícelos. Verifique que el tráfico no esté bloqueado o denegado en algún lugar de la red.

Generar archivo de resolución de problemas

Si ha completado los pasos anteriores para la resolución de problemas y aún no puede determinar el problema, genere un archivo de solución de problemas desde su FireSIGHT Management Center. Proporcione todos los datos adicionales para la resolución de problemas al Soporte Técnico de Cisco para un análisis adicional.