En este tema se proporciona información sobre posibles problemas que pueden encontrar los usuarios de NetWitness Suite cuando implementan el registro de auditoría global en NetWitness Suite. 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 RabbitMQ esté 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 ADMIN > Sistema > Notificaciones globales. No seleccione Notificaciones antiguas). - Compruebe la configuración del registro de auditoría global.
En Configurar el registro de auditoría global y Verificar registros de auditoría global se 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 (ADMIN > Servicios > (seleccione Concentrator) >
> Ver > Configuración).
- 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, RabbitMQ debe estar en funcionamiento.
Para el registro de auditoría centralizado, cada uno de los servicios de NetWitness Suite 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 NetWitness agrega registros de auditoría de todos los servicios de NetWitness Suite, 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 NetWitness Suite.
En Definir una configuración del registro de auditoría global se proporcionan instrucciones.
Verificar los paquetes y los servicios en los hosts
NetWitness SuiteHost
Los siguientes paquetes o servicios deben estar presentes en el host del Servidor de NetWitness:
- rsyslog-8.4.1
- rsa-audit-rt
- logstash-1.5.4-1
- rsa-audit-plugins
- rabbitmq server
Servicios en un host además del host de NetWitness Suite
Los siguientes paquetes o servicios deben estar presentes en cada uno de los hosts de NetWitness Suite además del host del Servidor de NetWitness:
- rsyslog-8.4.1
- rsa-audit-rt
- rabbitmq server
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 NetWitness.
- Los registros agregados en el host del Servidor de NetWitness no se están reenviando al servidor de syslog de otros fabricantes o a 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.
¿Por qué no se pueden ver los metadatos personalizados en Investigation?
Generalmente, si una clave de metadatos no se ve en Investigation, se debe a que no está indexada. 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 Servidor de NetWitness (ADMIN > Servicios > (seleccione el Log Decoder) > 
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 Servidor de NetWitness (ADMIN > Servicios > (seleccione el Concentrator) > 
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.
On this page
