Cfg de NW : Résoudre les problèmes liés à la consignation globale des audits

 

Cette rubrique fournit des informations sur les problèmes potentiels que les utilisateurs de NetWitness Suite peuvent rencontrer lors de l'implémentation de la consignation globale des audits dans NetWitness Suite. Recherchez des explications et solutions dans cette rubrique.

Après avoir configuré la consignation globale des audits, il est recommandé de tester vos logs d'audit pour vous assurer qu'ils contiennent les événements d'audit tels que définis dans votre modèle de consignation des audits. Si vous ne pouvez pas afficher les logs d'audit sur votre serveur syslog ou Log Decoder tiers, ou si les logs d'audit n'apparaissent pas comme ils le devraient, passez en revue les suggestions de dépannage de base ci-dessous. Si vos problèmes persistent, consultez les suggestions de dépannage avancées.  

Procédure de dépannage de base

Si vous ne pouvez pas afficher les logs d'audit sur un serveur syslog tiers ou Log Decoder :

• Vérifiez que RabbitMQ est opérationnel.
• Vérifiez la configuration du serveur de notification syslog et assurez-vous qu'il est activé.
  (Vous trouverez cette configuration dans Admin > Système > Notifications globales. Ne sélectionnez pas Notifications existantes.)
• Vérifiez la configuration de la consignation globale des audits.

Les rubriques Configurer la consignation globale des audits et Vérifier les logs d'audits globaux donnent des instructions. Si vous envoyez des logs d'audit vers un Log Decoder :

• Assurez-vous que le Log Decoder s'agrège au Concentrator sur le même hôte (Administration > Services > (sélectionnez Concentrator) > > Afficher > Configuration).
• Vérifiez que le dernier parser CEF est déployé et activé.
• Vérifiez le modèle de notification pour la consignation des audits. Vous devez utiliser un modèle CEF et tous les logs arrivant au Log Decoder doivent utiliser un modèle CEF.

Si vous envoyez des logs d'audit à un serveur syslog tiers :

• Assurez-vous que le port de destination configuré pour le serveur syslog tiers n'est pas bloqué par un pare-feu. 

Dépannage avancé

Pour pouvoir utiliser la consignation globale des audits sur votre réseau, RabbitMQ doivent être opérationnels. 

Pour la consignation centralisée des audits, chaque service NetWitness Suite écrit des logs d'audit vers rsyslog en écoutant le port 50514 via UDP sur l'hôte local. Le plug-in rsyslog fournit dans le package de consignation des audits ajoute des informations supplémentaires et télécharge ces logs vers RabbitMQ. Logstash s'exécutant sur l'hôte Serveur NetWitness agrège les logs d'audit à partir de tous les services NetWitness Suite, les convertit au format requis, les envoie à un serveur syslog tiers ou Log Decoder pour une procédure d'enquête. Vous pouvez configurer le format des logs d'audits globaux et la destination utilisée par Logstash via l'interface utilisateur NetWitness Suite.  

La rubrique Définir une configuration de consignation globale des audits fournit des instructions.  

Vérifier les packages et services sur les hôtes

Hôte NetWitness Suite

Les packages ou services suivants doivent être présents sur l'hôte Serveur NetWitness :

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

Services sur un hôte autre que l'hôte NetWitness Suite

Les packages et services suivants doivent être présents sur chacun des hôtes NetWitness Suite, outre l'hôte Serveur NetWitness :

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

Log Decoder

Si vous transférez des logs d'audits globaux à un Log Decoder, le parser suivant doit être présent et activé :

• CEF

Problèmes possibles

Que faire si j'effectue une action sur un service mais les logs d'audit n'atteignent pas le serveur syslog tiers ou Log Decoder configuré ? 

La cause possible peut être l'une des suivantes :

• Un service n'effectue pas la consignation sur le serveur syslog local.
• Les logs d'audit ne sont pas téléchargés vers RabbitMQ à partir du syslog local. 
• Les logs d'audit ne sont pas agrégés sur l'hôte Serveur NetWitness.
• Les logs agrégés sur l'hôte Serveur NetWitness ne sont pas transférés vers le serveur Syslog ou le Log Decoder tiers configuré.
• Log Decoder n'est pas configuré pour recevoir des logs d'audit globaux au format CEF :
  • La capture Log Decoder n'est pas activée
  • Le Parser CEF n'est pas présent
  • Le Parser CEF n'est pas activé

Solutions possibles

Le tableau suivant propose des solutions possibles à ces problèmes.

                             

Pourquoi ne pouvons-nous pas voir les métadonnées personnalisées dans Investigation ?

Généralement, si une méta n'est pas visible dans Investigation, elle n'est pas indexée. Si vous avez besoin d'utiliser les clés méta personnalisées pour Investigation et Reporting, assurez-vous que les clés méta que vous avez sélectionnées sont indexées dans le fichier table-map-custom.xml sur Log Decoder. Suivez la procédure « Maintenir les fichiers de mappage des tables » pour modifier le fichier table-map-custom.xml sur Log Decoder.

Assurez-vous que les clés méta personnalisées sont également indexées dans index-concentrator-custom.xml sur le Concentrator. La rubrique « Modifier un fichier d'index de service » fournit des informations supplémentaires.

La figure suivante montre un exemple de fichier table-map-custom.xml dans Serveur NetWitness (ADMIN > Services > (sélectionnez le Log Decoder) > >Vue > Config) avec l'exemple de méta personnalisé url mis en surbrillance.

L'exemple de méta personnalisé url est mis en surbrillance dans l'échantillon de code suivant provenant du fichier table-map-custom.xml ci-dessus :

 <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"/> 

La figure suivante montre un exemple de fichier index-concentrator-custom.xml dans Serveur NetWitness (ADMIN > Services > (sélectionnez le Concentrator) > > Vue > Config) avec l'exemple de méta personnalisé url mis en surbrillance.

L'exemple de méta personnalisé url est mis en surbrillance dans l'échantillon de code suivant provenant du fichier index-concentrator-custom.xml ci-dessus :

 <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"/> 

Exemples de solutions

Les exemples de solutions possibles qui suivent montrent les résultats des commandes citées en exemple. Consultez le tableau ci-dessous pour obtenir la liste complète des solutions possibles.

Vérifier que ce rsyslog est fonctionnel

Vous pouvez utiliser la commande suivante :
service rsyslog status

Vérifier que ce rsyslog est à l'écoute sur le port 50514 à l'aide du protocole UDP

Vous pouvez utiliser la commande suivante :
netstat -tulnp|grep rsyslog

Vérifier que l'application ou le composant envoie les lots d'audit vers le port 50514

La figure suivante montre le résultat de l'exécution de l'utilitaire tcpdump sur l'interface locale pour le port 50514.

Vous pouvez utiliser la commande suivante :
sudo tcpdump -i lo -A udp and port 50514

Vérifier que le plug-in rsyslog est fonctionnel

Vous pouvez utiliser la commande suivante :
ps -ef|grep rsa_audit_onramp

Vérifier que le serveur RabbitMQ est fonctionnel

Vous pouvez utiliser la commande suivante :
service rabbitmq-server status

Vérifier que Logstash est opérationnel

Vous pouvez utiliser les commandes suivantes :
ps -ef|grep logstash
service logstash status

Vérifier que le serveur RabbitMQ est à l'écoute sur le port 5672

Par exemple, saisissez la commande suivante :
netstat -tulnp|grep 5672

Consulter les erreurs générées au niveau de Logstash

Vous pouvez saisir la commande suivante pour l'emplacement des fichiers :
ls -l /var/log/logstash/logstash.*

Consultez le tableau des solutions possibles ci-dessous pour obtenir la liste complète des problèmes et solutions possibles.