Beispiele für Parsing-Probleme

Protokoll konvertieren

Das folgende Beispiel zeigt eine typische Protokollkonvertierung, die an einer beliebigen Stelle in den Nutzdaten nach TCP, UDP, ICMP oder GRE sucht. Das Suchmuster wird von einer beliebigen Wortgrenze umgeben, z. B. Tabulator, Leerzeichen, Zeilenende. Außerdem wird die Groß-/Kleinschreibung ignoriert:

<pattern id="Protocol" case-insensitive="true" xmlns="">
<![CDATA[\b(TCP|UDP|ICMP|GRE)\b]]>
</pattern> 
<matcher field="Protocol" order="1" pattern-id="Protocol" capture-group="1" />

Einzelne Ersetzung vornehmen

Das folgende Beispiel zeigt eine Substitution, die die Quellen-IP-Adresse analysiert, dann das Ergebnis überschreibt und die IP-Adresse auf 192.0.2.1setzt, wobei die IP-Adresse in den Nutzdaten ignoriert wird.

In diesem Beispiel wird davon ausgegangen, dass die Quellen-IP-Adresse mit einem Komma gefolgt von SrcAddress=203.0.113.1 übereinstimmt:

<pattern id="SourceIp_AuthenOK" xmlns=""> 
<![CDATA[SrcAddress=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}),]]>
</pattern>

<matcher field="SourceIp" order="1" pattern-id="SourceIp_AuthenOK" 
capture-group="192.0.2.1" enable-substitutions="true"/>

Durch Doppelpunkte getrennte MAC-Adresse generieren

QRadar erkennt MAC-Adressen in einem durch Doppelpunkte getrennten Format. Da möglicherweise nicht alle Einheiten dieses Formular verwenden, zeigt das folgende Beispiel, wie diese Situation korrigiert werden kann:

<pattern id="SourceMACWithDashes" xmlns="">
    <![CDATA[SourceMAC=([0-9a-fA-F]{2})-([0-9a-fA-F]{2})-([0-9a-fA-F]{2})-
    ([0-9a-fA-F]{2})-([0-9a-fA-F]{2})-([0-9a-fA-F]{2})]]>
</pattern> 
 <matcher field="SourceMAC" order="1" pattern-id=" 
    SourceMACWithDashes" capture-group="\1:\2:\3:\4:\5:\6" />

Im vorherigen Beispiel wird SourceMAC=12-34-1a-2b-3c-4d in die MAC-Adresse 12:34:1a:2b:3c:4dkonvertiert.

Wenn die Gedankenstriche aus dem Muster entfernt werden, konvertiert das Muster eine MAC-Adresse und hat keine Trennzeichen. Wenn Leerzeichen eingefügt werden, konvertiert das Muster eine durch Leerzeichen getrennte MAC-Adresse.

IP-Adresse und Port kombinieren

Normalerweise werden IP-Adresse und Port in einem Feld kombiniert, das durch einen Doppelpunkt getrennt ist.

Im folgenden Beispiel werden mehrere Erfassungsgruppen mit einem Muster verwendet:

pattern id="SourceIPColonPort" xmlns="">
<! [CDATA[Source=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}):([\d]{1,5})]]>
</pattern> 

<matcher field="SourceIp" order="1" pattern-id="SourceIPColonPort" capture-group="1" /> 
<matcher field="SourcePort" order="1" pattern-id="SourceIPColonPort" capture-group="2" />

Ereigniskategorie ändern

Eine Geräteereigniskategorie kann fest codiert sein oder die Wertigkeit kann angepasst werden.

Im folgenden Beispiel wird die Wertigkeit für einen einzelnen Ereignistyp angepasst:

<event-match-single event-name="TheEvent" device-event-category="Actual Category" severity="6" send-identity="UseDSMResults" />

Identitätsänderungsereignisse unterdrücken

Ein DSM sendet möglicherweise unnötigerweise Identitätsänderungsereignisse.

Die folgenden Beispiele zeigen, wie das Senden von Identitätsänderungsereignissen von einem einzelnen Ereignistyp und einer Gruppe von Ereignissen unterdrückt wird.

// Never send identity for the event with an EventName of Authen OK 
<event-match-single event-name="Authen OK" device-event-category="ACS" 
severity="6" send-identity="OverrideAndNeverSend" />

// Never send any identity for an event with an event name starting with 7, 
followed by one to five other digits: 
<pattern id="EventNameId" xmlns=""><![CDATA[(7\d{1,5})]]>
</pattern>

<event-match-multiple pattern-id="EventNameId" capture-group-index="1" 
device-event-category="Cisco Firewall" severity="7" 
send-identity="OverrideAndNeverSend"/> 

Ereignisdatumsangaben und Zeitmarken formatieren

Eine Protokollquellenerweiterung kann verschiedene Datums-und Zeitmarkenformate für Ereignisse erkennen.

Da Einheitenhersteller nicht dem Standardformat für Datums-und Zeitmarken entsprechen, wird der optionale Parameter 'ext-data' in die Protokollquellenerweiterung eingeschlossen, damit die DeviceTime neu formatiert werden kann. Das folgende Beispiel zeigt, wie ein Ereignis neu formatiert werden kann, um die Formatierung der Datums-und Zeitmarke zu korrigieren:

<device-extension> 
<pattern id="EventName1">(logger):</pattern> 
<pattern id="DeviceTime1">time=\[(\d{2}/\w{3}/\d{4}:\d{2}:\d{2}:\d{2})\]</pattern> 
<pattern id="Username">(TLSv1)</pattern> 

<match-group order="1" description="Full Test"> 
   <matcher field="EventName" order="1" pattern-id="EventName1_Pattern" capture-group="1"/> 
   <matcher field="DeviceTime" order="1" pattern-id="DeviceTime1_Pattern" 
   capture-group="1" ext-data="dd/MMM/YYYY:hh:mm:ss"/> 
   <matcher field="UserName" order="1" pattern-id="Username_Pattern" capture-group="1"/>
</match-group>
</device-extension>

Mehrere Protokollformate in einer einzelnen Protokollquelle

Gelegentlich sind mehrere Protokollformate in einer einzigen Protokollquelle enthalten.

May 20 17:15:50 kernel: DROP IN=vlan2 OUT= MAC= SRC=<Source_IP_address> 
DST=<Destination_IP_address> PROTO=UDP SPT=1900 DPT=1900
May 20 17:16:26 <server>[22331]: password auth succeeded for 'root' from <IP_address>
May 20 17:16:28 <server>[22331]: exit after auth (root): Exited normally </br>
May 20 17:16:14 <server>[22331]: bad password attempt for 'root' from <IP_address>:3364

Es gibt beispielsweise zwei Protokollformate: eines für Firewallereignisse und eines für Authentifizierungsereignisse. Sie müssen mehrere Muster für das Parsing der Ereignisse schreiben. Sie können die zu analysierende Reihenfolge angeben. Normalerweise werden die häufigsten Ereignisse zuerst geparst, gefolgt von den weniger häufigen Ereignissen. Sie können so viele Muster wie erforderlich haben, um alle Ereignisse zu analysieren. Die Reihenfolgevariable bestimmt, in welcher Reihenfolge die Muster abgeglichen werden.

Das folgende Beispiel zeigt mehrere Formate für die Felder EventName und UserName

Es werden separate Muster geschrieben, um jeden eindeutigen Protokolltyp zu analysieren. Beide Muster werden referenziert, wenn Sie den normalisierten Feldern den Wert zuordnen.

<pattern id="EventName-DDWRT-FW_Pattern" xmlns=""><![CDATA[kernel\:\s(.*?)\s]]></pattern>
<pattern id="EventName-DDWRT-Auth_Pattern" xmlns=""><![CDATA[sdrophear\[\d{1,5}\]|:\s(.*?\s.*?)\s]]>
</pattern>

<pattern id="UserName_DDWRT-Auth1__Pattern" xmlns=""><![CDATA[\sfor\s\'(.*?)\'s]]></pattern>
<pattern id="UserName_DDWRT-Auth2__Pattern" xmlns=""><![CDATA[\safter\sauth\s\((.*?)\)\:]]></pattern>

<match-group order="1" description="DD-WRT Device Extensions xmlns=""> 
   <matcher field="EventName" order="1" pattern-id="EventName-DDWRT-FW_Pattern" capture-group="1"/> 
   <matcher field="EventName" order="2" pattern-id="EventName-DDWRT-Auth_Pattern" capture-group="1"/> 
   
   <matcher field="UserName" order="1" pattern-id="UserName-DDWRT-Auth1_Pattern" capture-group="1"/> 
   <matcher field="UserName" order="2" pattern-id="UserName-DDWRT-Auth2_Pattern" capture-group="1"/> 
   

Parsing eines CSV-Protokollformats

Um eine Protokolldatei im CSV-Format zu parsen, verwenden Sie den Ausdruckstyp "Generische Liste", der im DSM-Editor verfügbar ist. Weitere Informationen finden Sie unter Ausdrücke im Format einer generischen Liste für strukturierte Daten (https://www.ibm.com/docs/en/qsip/7.5?topic=editor-expressions-in-generic-list-format-structured-data).

Event,User,Source IP,Source Port,Destination IP,Destination Port
Failed Login,<Username>,<Source_IP_address>,1024,<Destination_IP_address>,22 
Successful Login,<Username>,<Source_IP_address>,1743,<Destination_IP_address>,110 
Privilege Escalation,<Username>,<Source_IP_address>,1028,<Destination_IP_address>,23