NW Cfg: Troubleshooting bei der globalen Auditprotokollierung

Document created by RSA Information Design and Development on May 11, 2018
Version 1Show Document
  • View in full screen mode
 

Dieses Thema enthält Informationen zu möglichen Problemen, mit denen NetWitness Suite-Benutzer bei der Implementierung der globalen Auditprotokollierung in NetWitness Suite konfrontiert werden können. In diesem Thema finden Sie Erklärungen und Lösungen.

Nach dem Konfigurieren der globalen Auditprotokollierung sollten Sie Ihre Auditprotokolle testen, um sich zu vergewissern, dass die Auditereignisse entsprechend der Definition in Ihrer Auditprotokollierungsvorlage aufgeführt werden. Wenn Sie die Auditprotokolle nicht auf Ihrem Syslog-Server oder Log Decoder eines Drittanbieters anzeigen können oder die Auditprotokolle nicht wie erwartet angezeigt werden, lesen Sie die grundlegenden Troubleshooting-Vorschläge im Folgenden. Wenn die Probleme dann immer noch bestehen, können Sie sich die erweiterten Troubleshooting-Vorschläge ansehen.  

Grundlegendes Troubleshooting

Wenn Sie Auditprotokolle nicht auf einem Syslog-Server oder Log Decoder eines Drittanbieters anzeigen können:

  • Vergewissern Sie sich, dass RabbitMQ einwandfrei funktioniert.
  • Überprüfen Sie die Konfiguration des Syslog-Benachrichtigungsserver und vergewissern Sie sich, dass sie aktiviert ist.
    (Diese Konfiguration finden Sie unter „ADMINISTRATION“ > „System“ > „Globale Benachrichtigungen“. Wählen Sie nicht „Alte Benachrichtigungen“ aus.)
  • Überprüfen Sie die globale Auditprotokollierungskonfiguration.

Anweisungen dazu erhalten Sie unter Konfigurieren der globalen Auditprotokollierung und Überprüfen von globalen Auditprotokollen. Wenn Sie Auditprotokolle an einen Log Decoder senden:

  • Vergewissern Sie sich, dass der Log Decoder die Aggregation auf dem Concentrator auf demselben Host durchführt (ADMINISTRATION > Services > (Concentrator auswählen) >  >Ansicht > Konfiguration).
  • Überprüfen Sie, ob der neueste CEF-Parser bereitgestellt und aktiviert ist.
  • Überprüfen Sie die Benachrichtigungsvorlage für die Auditprotokollierung. Sie müssen eine CEF-Vorlage verwenden und alle Protokolle, die in den Log Decoder übertragen werden, müssen eine CEF-Vorlage verwenden.

Wenn Sie Auditprotokolle an einen Syslog-Server eines Drittanbieters senden:

  • Vergewissern Sie sich, dass der für den Drittanbieter-Syslog-Server konfigurierte Zielport nicht von einer Firewall blockiert wird. 

Erweitertes Troubleshooting

Um die globale Auditprotokollierung in Ihrem Netzwerk verwenden zu können, muss RabbitMQ ordnungsgemäß funktionieren. 

Bei der zentralisierten Auditprotokollierung schreibt jeder der NetWitness Suite-Services Auditprotokolle an das rsyslog-Plug-in auf dem lokalen Host, das Port 50514 unter Verwendung von UDP überwacht. Das im Auditprotokollierungspaket enthaltene rsyslog-Plug-in fügt zusätzliche Informationen an und lädt diese Protokolle zu RabbitMQ hoch. Der auf dem NetWitness-Server-Host ausgeführte Logstash aggregiert die Auditprotokolle aller NetWitness Suite-Services, konvertiert Sie in das erforderliche Format und sendet Sie zur Untersuchung an einen Syslog-Server eines Drittanbieters oder an Log Decoder. Sie konfigurieren das Format der globalen Auditprotokolle und das vom Logstash verwendete Ziel über die NetWitness Suite-Benutzeroberfläche.  

Anweisungen hierzu enthält der Abschnitt Definieren einer globalen Auditprotokollierungskonfiguration.  

Überprüfen der Pakete und Services auf den Hosts

NetWitness Suite-Host

Die folgenden Pakete oder Services müssen auf dem NetWitness-Server-Host vorhanden sein:

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

Services auf einem anderen Host als dem NetWitness Suite-Host

Die folgenden Pakete oder Services müssen auf allen anderen NetWitness Suite-Hosts, die nicht der NetWitness-Server-Serverhost sind, vorhanden sein:

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

Log Decoder

Wenn Sie globale Auditprotokolle an einen Log Decoder weiterleiten, müssen die folgenden Parser vorhanden und aktiviert sein:

  • CEF

Mögliche Probleme

Was ist zu tun, wenn eine Aktion auf einem Service ausgeführt wird, die Auditprotokolle den konfigurierten Syslog-Server oder Log Decoder eines Drittanbieters aber nicht erreichen? 

Dies kann eine oder alle der folgenden Ursachen haben:

  • Ein Service protokolliert nicht auf den lokalen Syslog-Server.
  • Auditprotokolle werden nicht vom lokalen Syslog-Server an RabbitMQ hochgeladen. 
  • Auditprotokolle werden nicht auf dem NetWitness-Server-Host aggregiert.
  • Aggregierte Protokolle auf dem NetWitness-Server-Host werden nicht an den konfigurierten Syslog-Server eines Drittanbieters oder an Log Decoder weitergeleitet.
  • Der Log Decoder ist nicht für das Empfangen globaler Auditprotokolle im CEF-Format konfiguriert:
    • Die Log Decoder-Erfassung ist nicht aktiviert.
    • Es ist kein CEF-Parser vorhanden.
    • Der CEF-Parser ist nicht aktiviert.

Mögliche Lösungen

Die folgende Tabelle enthält mögliche Lösungen für die Probleme.

                             
ProblemMögliche Lösungen
Ein Service protokolliert nicht auf den lokalen Syslog-Server.
  • Vergewissern Sie sich, dass rsyslog ordnungsgemäß funktioniert.
    Dazu können Sie den folgenden Befehl verwenden:
    service rsyslog status
  • Vergewissern Sie sich, dass rsyslog den Port 50514 unter Verwendung von UDP überwacht.
    Dazu können Sie den folgenden Befehl verwenden:
    netstat -tulnp|grep rsyslog
  • Vergewissern Sie sich, dass die Anwendung oder Komponente Auditprotokolle an Port 50514 sendet. Führen Sie das Dienstprogramm tcpdump auf der lokalen Schnittstelle für Port 50514 aus.
    Dazu können Sie den folgenden Befehl verwenden:
    sudo tcpdump -i lo -A udp and port 50514

Die Befehlsausgaben finden Sie unten unter Lösungsbeispiele.

Auditprotokolle werden nicht vom lokalen Syslog-Server an RabbitMQ hochgeladen.
  • Vergewissern Sie sich, dass das rsyslog-Plug-in ordnungsgemäß funktioniert.
    Dazu können Sie den folgenden Befehl verwenden:
    ps -ef|grep rsa_audit_onramp
  • Vergewissern Sie sich, dass der RabbitMQ-Server ordnungsgemäß funktioniert.
    Dazu können Sie den folgenden Befehl verwenden:
    service rabbitmq-server status

Die Befehlsausgaben finden Sie unter „Lösungsbeispiele“.

Auditprotokolle werden nicht auf dem NetWitness-Server-Host aggregiert.

  • Vergewissern Sie sich, dass Logstash ordnungsgemäß funktioniert.
    Dazu können Sie die folgenden Befehle verwenden:
    ps -ef|grep logstash
    service logstash status
  • Vergewissern Sie sich, dass der RabbitMQ-Server ordnungsgemäß funktioniert.
    Dazu können Sie den folgenden Befehl verwenden:
    service rabbitmq-server status
  • Vergewissern Sie sich, dass der RabbitMQ-Server Port 5672 überwacht.
    Dazu können Sie den folgenden Befehl verwenden:
    netstat -tulnp|grep 5672
  • Suchen Sie nach Fehlern, die auf der Logstash-Ebene entstehen.
    Sie können den folgenden Befehl verwenden, um den Speicherort der Protokolldateien zu suchen:
    ls -l /var/log/logstash/logstash.*

Die Befehlsausgaben finden Sie unter „Lösungsbeispiele“.

Aggregierte Protokolle auf dem NetWitness-Server-Host werden nicht an den konfigurierten Syslog-Server eines Drittanbieters oder an Log Decoder weitergeleitet.

  • Vergewissern Sie sich, dass Logstash ordnungsgemäß funktioniert.
    Dazu können Sie die folgenden Befehle verwenden:
    ps -ef|grep logstash
    service logstash status
  • Suchen Sie nach Fehlern, die auf der Logstash-Ebene entstehen.
    Sie können den folgenden Befehl für den Speicherort der Protokolldateien verwenden:
    ls -l /var/log/logstash/logstash.

Die Befehlsausgaben finden Sie unten unter „Lösungsbeispiele“.

  • Vergewissern Sie sich, dass der Zielservice ausgeführt wird.
  • Vergewissern Sie sich, dass der Zielservice den korrekten Port unter Verwendung des korrekten Protokolls überwacht.
  • Vergewissern Sie sich, dass der konfigurierte Port auf dem Zielhost nicht blockiert wird.

Vom Logstash weitergeleitete Auditprotokolle führen zu Parserfehlern auf dem Log Decoder.

  • Vergewissern Sie sich, dass Sie eine passende Benachrichtigungsvorlage verwenden.
    Von einem Log Decoder geparste Auditprotokolle müssen im CEF-Format vorliegen. Das Ziel, von dem Auditprotokolle direkt oder indirekt zum Log Decoder gelangen, muss ebenfalls eine CEF-Vorlage verwenden.
  • Die Benachrichtigungsvorlage muss dem CEF-Standard entsprechen.
    Befolgen Sie die Schritte in diesem Handbuch, um die standardmäßige CEF-Vorlage zu verwenden oder eine den strengen Richtlinien entsprechende benutzerdefinierte CEF-Vorlage zu erstellen. Weitere Informationen erhalten Sie unter Definieren einer Vorlage für die globale Auditprotokollierung.
  • Überprüfen Sie die Logstash-Konfiguration.

Warum werden benutzerdefinierte Metadaten nicht in Investigation angezeigt?

Wenn Metadaten nicht in Investigation angezeigt werden, bedeutet das normalerweise, dass sie nicht indexiert sind. Wenn Sie benutzerdefinierte Metadaten für Investigation und Reporting verwenden möchten, vergewissern Sie sich, dass die ausgewählten Metaschlüssel in der Datei table-map-custom.xml auf dem Log Decoder indexiert sind. Befolgen Sie das Verfahren „Pflegen der Tabellenzuordnungsdateien“, um die Datei table-map-custom.xml auf dem Log Decoder zu bearbeiten.

Vergewissern Sie sich, dass die benutzerdefinierten Metaschlüssel auch in der Datei index-concentrator-custom.xml auf dem Concentrator indexiert sind. Weitere Informationen erhalten Sie unter „Bearbeiten einer Serviceindexdatei“.

Die folgende Abbildung zeigt ein Beispiel für die Datei table-map-custom.xml in NetWitness-Server (ADMINISTRATION > Services > (Log Decoder auswählen) >  > Ansicht > Konfiguration). Das Beispiel für den benutzerdefinierten Metawert url ist hervorgehoben.

Im folgenden Codebeispiel aus der oben genannten Datei table-map-custom.xml ist der benutzerdefinierte Metawert url hervorgehoben:

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

Die folgende Abbildung zeigt ein Beispiel für die Datei index-concentrator-custom.xml in NetWitness-Server (ADMINISTRATION > Services > (Concentrator auswählen) >  > Ansicht > Konfiguration). Das Beispiel für den benutzerdefinierten Metawert url ist hervorgehoben.

Im folgenden Codebeispiel aus der Datei index-concentrator-custom.xml oben ist der benutzerdefinierte Metawert url hervorgehoben:

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

Lösungsbeispiele

Die folgenden möglichen Lösungsbeispiele zeigen die Ausgaben der Beispielbefehle. Eine vollständige Liste aller Lösungen finden Sie in der Tabelle oben.

Vergewissern Sie sich, dass rsyslog ordnungsgemäß funktioniert.

Dazu können Sie den folgenden Befehl verwenden:
service rsyslog status

Vergewissern Sie sich, dass rsyslog den Port 50514 unter Verwendung von UDP überwacht.

Dazu können Sie den folgenden Befehl verwenden:
netstat -tulnp|grep rsyslog

Vergewissern Sie sich, dass die Anwendung oder Komponente Auditprotokolle an Port 50514 sendet.

Die folgende Abbildung zeigt die Ausgabe bei Ausführen des Dienstprogramms tcpdump auf der lokalen Schnittstelle für Port 50514.

Dazu können Sie den folgenden Befehl verwenden:
sudo tcpdump -i lo -A udp and port 50514

Vergewissern Sie sich, dass das rsyslog-Plug-in ordnungsgemäß funktioniert.

Dazu können Sie den folgenden Befehl verwenden:
ps -ef|grep rsa_audit_onramp

Vergewissern Sie sich, dass der RabbitMQ-Server ordnungsgemäß funktioniert.

Dazu können Sie den folgenden Befehl verwenden:
service rabbitmq-server status

Vergewissern Sie sich, dass Logstash ordnungsgemäß funktioniert.

Dazu können Sie den folgenden Befehl verwenden:
ps -ef|grep logstash
service logstash status

Vergewissern Sie sich, dass der RabbitMQ-Server Port 5672 überwacht.

Geben Sie beispielsweise den folgenden Befehl ein:
netstat -tulnp|grep 5672

Suchen Sie nach Fehlern, die auf der Logstash-Ebene entstehen.

Sie können den folgenden Befehl für den Speicherort der Protokolldateien verwenden:
ls -l /var/log/logstash/logstash.*

Eine vollständige Liste aller Probleme und möglichen Lösungen finden Sie in der Tabelle unter „Mögliche Lösungen“ oben.

You are here
Table of Contents > Troubleshooting der Systemkonfiguration > Troubleshooting bei der globalen Auditprotokollierung

Attachments

    Outcomes