OSSECパーサー構成ノート(デコーダー)

著名なコミュニティへの挨拶。 この記事では、OSSECソフトウェア(HIDS、SIEMシステム)をセットアップする際に留意する必要があるいくつかの重要な(私の意見では)ポイントについて説明します。 システムの公式ドキュメントは、ネットワークの広大さに関してかなり大量に提示されていますが、いくつかの重要なポイントはどこにも記載されていません。 「旅行メモ」として、それらを以下に示します。 システムのインストール、エージェントの展開、初期構成については説明しませんが、すぐに予約してください。 つまり 読者は、OSSECのコンテキストでデコーダーとルールがどのようなものかを既に知っていると思います。 以下はすべてバージョン2.8.1でテストされていますが、将来のバージョンで修正される可能性があります。 戦いに。



パーサーを開発するとき、またはOSSECがパーサーを呼び出すとき、「デコーダー」はいくつかのレベルを使用する可能性があります。 親デコーダー(親)と子。



親は、特定のクラスのすべてのイベント(たとえば、Windows OSのイベントログのすべてのイベント)が分類される一般的なビューを説明します。 元のメッセージの特定のパラメーター(つまり、事前一致パラメーター)に応じて、子パーサーを適用できるかどうかに応じて、さまざまな種類のメッセージからさまざまな情報を受信(解析)できます。 ここでは、ドキュメントに記載されていない次の点に留意する必要があります。



1-子デコーダーは、元の「生の」メッセージから受信したすべてのデータを完全に再消去します(解析を使用)。



2-パラグラフ1の結果-親デコーダーでは、解析を実行する必要はありません 。 正規表現ディレクティブを使用します(OSSECコンテキストに精通している人なら誰でも理解できます)。 その中で行われるべきことは、特定のパターンに従って特定のソースからのすべてのイベントを決定することです。 ただし、解析用のフィールドを指定しないでください。 すべての解析は、子パーサーによって実行されます。



3-OSSECで使用される正規表現は、「。*」形式のレコードを処理できません。 例。 フォームの行から必要な場合:



2017 Mar 05 19:45:26 WinEvtLog: Security: AUDIT_SUCCESS(4634): Microsoft-Windows-Security-Auditing: DOM_WINSRV-DC$: DOMAIN: nsrv_WinSRV-DC.domain.test: An account was logged off. Subject: Security ID: S-1-5-18 Account Name: DOM_WINSRV-DC$ Account Domain: DOMAIN Logon ID: 0x6dd15b4 Logon Type: 3 This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer." 4646,1
      
      





たとえば、タイムスタンプとログオンタイプのみを取得し、正規表現を使用します。



 (\d\d\d\d\s+\w\w\w\s+\d\d\s+\d\d:\d\d:\d\d)\s+.*?Logon\s+Type:\s+(\d+)
      
      





これは成功しません。 OSSECはそれを処理しません。 エラーメッセージはありません。 どうする? 以下でそれについて読んでください。 ああ、ところで、OSSEC正規表現に埋め込まれた\ d {3}のような構文も理解できません。 連続して正確に3桁が必要な場合は、\ d \ d \ dと書いてください。 ホラーホラーホラー。



4-複数のデコーダーを同時に使用する機能



そのため、さまざまな形式の「生の」イベントからデータを取得する問題は、次のように解決できます(Windws OSログを例として使用することを検討します)。 このソリューションはここから引き出されました 。 事実、OSSECは階層順ではなく、複数のデコーダーを1つの生メッセージに同時に適用できます(階層を構築すると、デコーダー階層の最後の1つが親が受信したすべてのデータを上書きします。この記事)。



OSSECに複数のデコーダーを一度に使用させるには、同じ名前を付ける必要があります。



以下の例では、デコーダーの2レベルの階層が構築されています。 最初のレベルでは、すべてのWindowsイベントログイベントが検索され、子デコーダレベルが解析されます。 図1に、視覚的な形式を示します。







図1-デコーダーの階層



親デコーダーは次のとおりです。



 <decoder name="windows"> <type>windows</type> <prematch>^\d\d\d\d \w\w\w \d\d \d\d:\d\d:\d\d WinEvtLog: </prematch> </decoder>
      
      





階層の2番目のレベルには、すぐに3つのデコーダーがあります。これらのデコーダーの名前は同じで、「windows-generic」です。



最初のデコーダーは、Windowsログの生のメッセージからデータを受信し、スキームの次のフィールド(OSSEC内のイベントを記述)に配置します:status、id、extra_data、srcuser、system_name



 <decoder name="windows-generic"> <type>windows</type> <parent>windows</parent> <prematch offset="after_parent">Security</prematch> <regex offset="after_parent">\S+:\s+(\w+)\((\d+)\):\s+(\S+):\s+</regex> <regex>(\.+):\s+\.+:\s+(\S+):\s+</regex> <order>status, id, extra_data, srcuser, system_name</order> <fts>name, location, user, system_name</fts> </decoder>
      
      





他の2つのデコーダーを使用して、WindowsログからソースIPアドレスを抽出します。 最初に、「。*」を使用して正規表現を記述することにより、この問題を解決しようとしました。 ただし、前に書いたように、OSSECはそのような正規表現を処理しません。 そのため、「生の」WindowsログからIPソースを取得するためのデコーダーを個別に作成することにしました。



なぜなら ソースIPアドレスはWindowsログに別の形式で表示できます(たとえば、「ソースIPアドレス:」という表現の後、または「クライアントアドレス」という表現の後)、それぞれ独自の設計用に2つのデコーダーを作成しました。 それらは以下にリストされています。



「ソースIPアドレス:<IPアドレス>」形式のデザインからIPを取得するためのデコーダー:



 <decoder name="windows-generic"> <type>windows</type> <parent>windows</parent> <regex offset="after_regex">Source\s+IP\s+Address:\s+(\S+)</regex> <order>srcip</order> </decoder>
      
      





「クライアントアドレス:<IPアドレス>」形式のデザインからIPを取得するためのデコーダー:



 <decoder name="windows-generic"> <type>windows</type> <parent>windows</parent> <regex offset="after_regex">Client\s+Address:\s+(\S+)</regex> <order>srcip</order> </decoder>
      
      





regexディレクティブでソースIPを取得する両方のデコーダーで、offset = after_regexが設定されていることに注意してください。 これはタイプミスではありません。 実際、このタイプのオフセットは、同じ名前の別のデコーダーがすでに存在する場合にのみ機能しますが、正規表現オフセットパラメーターに標準値のいずれかがあります(after_prematch、after_parent、またはoffsetは前にありません)。 また、それに応じて、after_regexを持つデコーダーは、標準値を持つデコーダーの後にトリガーされます。



ご理解のとおり、Windowsログから他のデータを取得するために、同様の構造を作成できます。



読んでくれてありがとう。 そして、知られていないことを知って頑張ってください!



All Articles