Configuración de SA: Solucionar problemas del registro de auditoría global

Document created by RSA Information Design and Development on Feb 9, 2017
Version 1Show Document
  • View in full screen mode
  

En este tema se proporciona información sobre posibles problemas que pueden encontrar los usuarios de Security Analytics cuando implementan el registro de auditoría global en Security Analytics. Busque explicaciones y soluciones en este tema.

Después de configurar el registro de auditoría global, se deben probar los registros de auditoría para asegurarse de que muestren los eventos de auditoría según se define en la plantilla del registro de auditoría. Si no puede ver los registros de auditoría en el servidor de syslog de otros fabricantes o en un Log Decoder, o si los registros de auditoría no aparecen según lo previsto, busque en las sugerencias básicas de solución de problemas que aparecen a continuación. Si los problemas persisten, puede consultar las sugerencias avanzadas de solución de problemas.  

Solución de problemas básica

Si no puede ver registros de auditoría en un servidor de syslog de otros fabricantes o en Log Decoder:

  • Verifique que Puppet y RabbitMQ estén en funcionamiento.
  • Verifique la configuración del servidor de notificación de syslog y asegúrese de que esté habilitado.
    (Esta configuración se encuentra en Administration > Sistema > Notificaciones globales. No seleccione Notificaciones antiguas).
  • Compruebe la configuración del registro de auditoría global.

Configurar el registro de auditoría global y Verificar registros de auditoría global proporcionan instrucciones.

Si está enviando registros de auditoría a un Log Decoder:

  • Asegúrese de que Log Decoder realice la agregación en el Concentrator en el mismo host (Administration > Servicios > (seleccione Concentrator) > Ver > Configurar).
  • Verifique que el analizador de CEF más reciente esté implementado y habilitado.
  • Compruebe la plantilla de notificación del registro de auditoría. Debe usar una plantilla de CEF, al igual que todos los registros que alimentan el Log Decoder.

Si está enviando registros de auditoría a un servidor de syslog de otros fabricantes:

  • Asegúrese de que un firewall no bloquee el puerto de destino configurado para el servidor de syslog de otros fabricantes. 

Solución de problemas avanzada

Para usar el registro de auditoría global en la red, Puppet y RabbitMQ deben estar en funcionamiento. El siguiente diagrama arquitectónico del registro de auditoría global muestra los componentes necesarios del registro de auditoría y el flujo de registros de auditoría desde cada servicio a Logstash en el servidor de Security Analytics y, a continuación, al servidor de syslog de otros fabricantes o al Log Decoder configurados.

Para el registro de auditoría centralizado, cada uno de los servicios de Security Analytics escribe registros de auditoría en rsyslog, el cual escucha en el puerto 50514 mediante UDP en el host local. El plug-in de rsyslog que se proporciona en el paquete del registro de auditoría agrega información adicional y carga estos registros en RabbitMQ. Logstash, que se ejecuta en el host del servidor de Security Analytics, agrega registros de auditoría de todos los servicios de Security Analytics, los convierte al formato requerido y los envía a un servidor de syslog de otros fabricantes o a un Log Decoder con fines de investigación. El formato de los registros de auditoría global y el destino que usa Logstash se configuran a través de la interfaz del usuario de Security Analytics.  

Definir una configuración del registro de auditoría global proporciona instrucciones.  

Verificar los paquetes y los servicios en los hosts

Host de Security Analytics

Los siguientes paquetes o servicios deben estar presentes en el host del servidor de Security Analytics:

  • rsyslog-8.4.1
  • rsa-audit-rt
  • logstash-1.5.4-1
  • rsa-audit-plugins
  • rabbitmq server
  • puppet master
  • puppet agent

Servicios en un host además del host de Security Analytics

Los siguientes paquetes o servicios deben estar presentes en cada uno de los hosts de Security Analytics además del host del servidor de Security Analytics:

  • rsyslog-8.4.1
  • rsa-audit-rt
  • rabbitmq server
  • puppet agent

Log Decoder

Si reenvía registros de auditoría global a un Log Decoder, el siguiente analizador debe estar presente y habilitado:

  • CEF

Posibles problemas

¿Qué sucede si ejecuto una acción en un servicio, pero los registros de auditoría no llegan al servidor de syslog de otros fabricantes o a Log Decoder configurados? 

Las causas posibles podrían ser una o todas las siguientes:

  • Un servicio no está realizando el registro en el servidor de syslog local.
  • Los registros de auditoría no se están cargando en RabbitMQ desde el syslog local. 
  • Los registros de auditoría no se están agregando en el host del servidor de Security Analytics.
  • Los registros agregados en el host del servidor de Security Analytics no se están reenviando al servidor de syslog de otros fabricantes o al Log Decoder configurados.
  • El Log Decoder no está configurado para recibir registros de auditoría global en formato CEF:
    • La captura de Log Decoder no está activada
    • El analizador de CEF no está presente
    • El analizador de CEF no está habilitado

Posibles soluciones

En la siguiente tabla se proporcionan posibles soluciones para los problemas.

                             
ProblemaPosibles soluciones
Un servicio no está realizando el registro en el servidor de syslog local.
  • Asegúrese de que rsyslog esté en funcionamiento.
    Puede usar el siguiente comando:
    service rsyslog status
  • Asegúrese de que rsyslog esté escuchando en el puerto 50514 mediante UDP.
    Puede usar el siguiente comando:
    netstat -tulnp|grep rsyslog
  • Asegúrese de que la aplicación o el componente estén enviando registros de auditoría al puerto 50514. Ejecute la utilidad tcpdump en la interfaz local para el puerto 50514.
    Puede usar el siguiente comando:
    sudo tcpdump -i lo -A udp and port 50514

Consulte Ejemplos de soluciones”, a continuación, para ver las salidas del comando.

Los registros de auditoría no se están cargando en RabbitMQ desde el syslog local.
  • Asegúrese de que el plug-in de rsyslog esté en funcionamiento.
    Puede usar el siguiente comando:
    ps -ef|grep rsa_audit_onramp
  • Asegúrese de que el servidor de RabbitMQ esté en funcionamiento.
    Puede usar el siguiente comando:
    service rabbitmq-server status

Consulte “Ejemplos de soluciones” para ver las salidas del comando.

Los registros de auditoría no se están agregando en el host del servidor de Security Analytics.

  • Asegúrese de que Logstash esté en funcionamiento.
    Puede usar los siguientes comandos:
    ps -ef|grep logstash
    service logstash status
  • Asegúrese de que el servidor de RabbitMQ esté en funcionamiento.
    Puede usar el siguiente comando:
    service rabbitmq-server status
  • Asegúrese de que el servidor de RabbitMQ esté escuchando en el puerto 5672.
    Puede usar el siguiente comando:
    netstat -tulnp|grep 5672
  • Compruebe si se generaron errores en el nivel de Logstash.
    Puede usar el siguiente comando para obtener la ubicación de los archivos de registro:
    ls -l /var/log/logstash/logstash.*

Consulte “Ejemplos de soluciones” para ver las salidas del comando.

Los registros agregados en el host del servidor de Security Analytics no se están reenviando al servidor de syslog de otros fabricantes o al Log Decoder configurados.

  • Asegúrese de que Logstash esté en funcionamiento.
    Puede usar los siguientes comandos:
    ps -ef|grep logstash
    service logstash status
  • Compruebe si se generaron errores en el nivel de Logstash.
    Puede ingresar el siguiente comando para obtener la ubicación de los archivos de registro:
    ls -l /var/log/logstash/logstash.

Consulte “Ejemplos de soluciones”, a continuación, para ver las salidas del comando.

  • Asegúrese de que el servicio de destino esté en funcionamiento.
  • Asegúrese de que el servicio de destino esté escuchando en el puerto correcto y que use el protocolo correcto.
  • Asegúrese de que el puerto configurado en el host de destino no esté bloqueado.

Los registros de auditoría reenviados desde Logstash causan una falla de análisis en el Log Decoder.

  • Asegúrese de estar usando una plantilla de notificación apropiada.
    Los registros de auditoría que analiza un Log Decoder deben estar en formato CEF. El destino desde el cual los registros de auditoría llegan directa o indirectamente al Log Decoder también debe usar una plantilla de CEF.
  • La plantilla de notificación debe seguir el estándar CEF.
    Siga los pasos de esta guía para usar la plantilla de CEF predeterminada o cree una plantilla de CEF personalizada de acuerdo con estrictas reglas. Definir una plantilla para el registro de auditoría global En la sección, se ofrece más información.
  • Verifique la configuración de Logstash.

¿Por qué no se pueden ver los metadatos personalizados en Investigation?

Generalmente, si los metadatos no se ven en Investigation, se debe a que no están indexados. Si necesita usar claves de metadatos personalizadas para Investigation y Reporting, asegúrese de que las claves de metadatos que selecciona estén indexadas en el archivo table-map-custom.xml en el Log Decoder. Siga el procedimiento “Mantener los archivos de mapa de tablas” para modificar el archivo table-map-custom.xml en el Log Decoder.

Asegúrese de que las claves de metadatos personalizadas también estén indexadas en el archivo index-concentrator-custom.xml en el Concentrator. En “Editar un archivo de índice de servicios” se proporciona información adicional.

En la siguiente figura se muestra un ejemplo del archivo table-map-custom.xml en Security Analytics (Administration > Servicios > (seleccione el Log Decoder) > Ver > Configuración), y se resalta un ejemplo de los metadatos personalizados url.

El ejemplo de los metadatos personalizados url se resalta en el siguiente ejemplo de código del archivo table-map-custom.xml anterior:

 <mapping envisionName="url" nwName="url" flags="None" envisionDisplayName="Url"/> <mapping envisionName="protocol" nwName="protocol" flags="None" envisionDisplayName="Protocol"/><mapping envisionName="cs_devservice" nwName="cs.devservice" flags="None" envisionDisplayName="DeviceService" /><mapping envisionName="cs_paramkey" nwName="cs.paramkey" flags="None" envisionDisplayName="ParamKey" /><mapping envisionName="cs_paramvalue" nwName="cs.paramvalue" flags="None" envisionDisplayName="ParamValue" /><mapping envisionName="cs_operation" nwName="cs.operation" flags="None" envisionDisplayName="Operation" /><mapping envisionName="sessionid" nwName="log.session.id" flags="None" envisionDisplayName="sessionid" /><mapping envisionName="group" nwName="group" flags="None" envisionDisplayName="group" /><mapping envisionName="process" nwName="process" flags="None" envisionDisplayName="process" /><mapping envisionName="user_agent" nwName="user.agent" flags="None"/><mapping envisionName="info" nwName="index" flags="None"/> 

En la siguiente figura se muestra un ejemplo del archivo index-concentrator-custom.xml en Security Analytics (Administration > Servicios > (seleccione el Concentrator) > Ver > Configuración), y se resalta un ejemplo de los metadatos personalizados url.

El ejemplo de los metadatos personalizados url se resalta en el siguiente ejemplo de código del archivo index-concentrator-custom.xml anterior:

 <key description="Severity" level="IndexValues" name="severity" valueMax="10000" format="Text"/><key description="Result" level="IndexValues" name="result" format="Text"/><key level="IndexValues" name="ip.srcport" format="UInt16" description="SourcePort"/><key description="Process" level="IndexValues" name="process" format="Text"/><key description="Process ID" level="IndexValues" name="process_id" format="Text"/><key description="Protocol" level="IndexValues" name="protocol" format="Text"/><key description="UserAgent" level="IndexValues" name="user_agent" format="Text"/><key description="DestinationAddress" level="IndexValues" name="ip.dst" format="IPv4"/><key description="SourceProcessName" level="IndexValues" name="process.src" format="Text"/><key description="Username" level="IndexValues" name="username" format="Text"/><key description="Info" level="IndexValues" name="index" format="Text"/><key description="customdevservice" level="IndexValues" name="cs.devservice" format="Text"/> <key description="url" level="IndexValues" name="url" format="Text"/> <key description="Custom Key" level="IndexValues" name="cs.paramkey" format="Text"/><key description="Custom Value" level="IndexValues" name="cs.paramvalue" format="Text"/><key description="Operation" level="IndexValues" name="cs.operation" format="Text"/><key description="CS Device Service" level="IndexValues" name="cs.device" format="Text" valueMax="10000" defaultAction="Closed"/> 

Ejemplos de soluciones

Los siguientes ejemplos de posibles soluciones muestran las salidas de los ejemplos de comandos. Consulte la tabla anterior para obtener la lista completa de posibles soluciones.

Asegúrese de que rsyslog esté en funcionamiento

Puede usar el siguiente comando:
service rsyslog status

Asegúrese de que rsyslog esté escuchando en el puerto 50514 mediante UDP

Puede usar el siguiente comando:
netstat -tulnp|grep rsyslog

Asegúrese de que la aplicación o el componente estén enviando registros de auditoría al puerto 50514

En la siguiente figura se muestra la salida de la ejecución de la utilidad tcpdump en la interfaz local para el puerto 50514.

Puede usar el siguiente comando:
sudo tcpdump -i lo -A udp and port 50514

Asegúrese de que el plug-in de rsyslog esté en funcionamiento

Puede usar el siguiente comando:
ps -ef|grep rsa_audit_onramp

Asegúrese de que el servidor de RabbitMQ esté en funcionamiento

Puede usar el siguiente comando:
service rabbitmq-server status

Asegúrese de que Logstash esté en funcionamiento

Puede usar los siguientes comandos:
ps -ef|grep logstash
service logstash status

Asegúrese de que el servidor de RabbitMQ esté escuchando en el puerto 5672

Por ejemplo, escriba el siguiente comando:
netstat -tulnp|grep 5672

Compruebe si se generaron errores en el nivel de Logstash

Puede ingresar el siguiente comando para obtener la ubicación de los archivos de registro:
ls -l /var/log/logstash/logstash.*

Consulte la tabla anterior Posibles soluciones para obtener la lista completa de problemas y posibles soluciones.

You are here
Table of Contents > Solución de problemas de configuración del sistema > Solucionar problemas del registro de auditoría global

Attachments

    Outcomes