構文解析の問題の例

ログ・ソース拡張を作成するときに、構文解析の問題が発生する場合があります。 以下の XML 例を使用して、具体的な構文解析の問題を解決していきます。

プロトコルの変換

ペイロードのいずれかの位置で TCP、UDP、ICMP、または GRE を検索する代表的なプロトコル変換を以下の例に示します。 この検索パターンは、なんらかの単語境界 (タブ、スペース、行末など) で囲まれています。 また、大文字と小文字の違いを無視しています。

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

1 回の置換

送信元 IP アドレスを構文解析し、その結果をオーバーライドして IP アドレスを 192.0.2.1 に設定し、ペイロードにある IP アドレスを無視する置換を以下の例に示します。

この例では、送信元 IP アドレスが SrcAddress=203.0.113.1 のような形式であり、その後にコンマが続くと想定しています。

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

コロン区切りの MAC アドレスの生成

QRadar は、コロン区切り形式の MAC アドレスを検出します。 すべてのデバイスがこの形式を使用するとは限らないため、以下の例では、その状況に対処する方法について説明します。

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

上記の例では、 SourceMAC=12-34-1a-2b-3c-4d12:34:1a:2b:3c:4dの MAC アドレスに変換されます。

パターンからダッシュを削除すると、そのパターンによって MAC アドレスが変換されます (区切り記号なしです)。 スペースを挿入すると、パターンによってスペース区切りの MAC アドレスが変換されます。

IP アドレスとポートの結合

通常、IP アドレスとポートは 1 つのフィールドに結合され、コロンによって区切られます。

以下の例では、1 つのパターンで複数のキャプチャー・グループを使用しています。

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

イベント・カテゴリーの変更

デバイス・イベントのカテゴリーをハードコーディングしたり、重大度を調整したりすることができます。

以下の例では、単一のイベント・タイプを対象として重大度を調整します。

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

アイデンティティー変更イベントの抑止

DSM は、アイデンティティー変更イベントを必要以上に送信する場合があります。

アイデンティティー変更イベントが単一のイベント・タイプおよびイベント・グループから送信されないように抑止する方法を以下の例に示します。

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

イベント日時スタンプの書式設定

ログ・ソース拡張は、イベントの各種の日時スタンプ形式を検出できます。

デバイスの製造元は標準的な日時スタンプの形式に従っていないため、ext-data というオプション・パラメーターをログ・ソース拡張に組み込んで、DeviceTime を書式設定し直せるようにします。 イベントを書式設定し直して日時スタンプの形式を修正する方法を以下の例に示します。

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

単一ログ・ソース内の複数のログ形式

場合によっては、単一のログ・ソース内に複数のログ形式が存在します。

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

例えば、ファイアウォール・イベントと認証イベントでログ形式が異なっているとします。 このイベントを構文解析するには、複数のパターンを記述しなければなりません。 構文解析する順序を指定できます。 通常は、頻度の高いイベントを最初に構文解析し、その後に頻度の低いイベントを処理します。 すべてのイベントを構文解析するために必要な数のパターンを記述することができます。 order 変数により、パターンの比較順序が決定されます。

複数の形式を EventName フィールドと UserName フィールドに指定する例を以下に示します。

固有の各ログ・タイプを構文解析するために、個別のパターンを記述しています。 正規化済みフィールドに値を割り当てるときに、両方のパターンが参照されます。


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

CSV ログ形式の構文解析

CSV 形式のログ・ファイルを構文解析するには、DSM エディターで使用可能なジェネリック・リストの式タイプを使用します。 詳しくは、 構造化データのジェネリック・リスト形式の式 (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