Snare WindowsエージェントとWinSyslogで脅威に備える（２）ログを整理・分類して保存し活用する

2025年1月8日公開
2025年1月8日更新
WinSyslog Snare
RFC3164 syslog syslogメッセージフォーマット WinSysog イベントログ収集イベントログ監視エージェントログ保存不正ログイン

はじめに

前回はログ収集の準備についてと、Snare Windows(Desktop)エージェントからのログ送信設定、ならびにWinSyslogでのログ受信設定について解説しました。

今回は、Snareからの各種ログをWinSyslogで分類して使いやすいように保存する方法を解説します。更に、イベントログのフィールド分割を活用したログオン失敗によるアラートメール生成の設定を概説します。ログ活用の準備だけでなく、後半は実戦的な内容となります。

以降このブログでは簡単のため、Snare WindowsエージェントおよびSnare Windows DesktopエージェントをまとめてSnare Windowsエージェント、更に略して単にSnareと呼ぶことにします。

Snare Windowsエージェントからのイベントログのフォーマット

ここからは主にWinSyslogの設定の説明となりますが、すべてSnare Windowsエージェントから送られたログを前提とします。その点でSnareから送られてくるログのフォーマットを理解しておくことが、この先の理解の近道です。そこで簡単に今回の解説の前提としているSnareからSYSLOG(RFC3164)、縦棒（Vertical Bar、”|”）区切で送信した場合のログフォーマットを予習しておきましょう。

生（Raw）ログの確認

WinSyslogの設定クライアントでは、デフォルトの”File Logging”（ファイル書込みのアクション）は、送付されたログを一部加工したAdisconフォーマットに設定されています。そこでFile Loggingの設定で □RAWメッセージを出力 をチェックするか、○ Raw Syslog メッセージ を選択して、送付されたままの生のSyslogメッセージを確認します。

下の文字列はWindowsのイベントログをSnareからSYSLOG(RFC3164)で送信し、生（Raw）Syslogメッセージとしてファイルに保存したものです。フィールド分割が分かり易いように、区切文字のVertical Bar(“|”)を赤くハイライトしています

イベントビュアーで見たログフォーマット

これと同じログを送信元のイベントビューアーで表示したものがこれです。

SnareのLatest Eventsで見たログフォーマット

更に、同じログを送信元のSnare WindowsエージェントのLatest Eventsのページで表示したものがこれです。

ヘッダーとタグのフィールド分割

Syslog RFC3164の空白や”>”以外の最初の区切り文字は、SnareのデフォルトではTAB文字(ASCII 0x09の制御文字)です。これは、SnareのDestination Configurationの画面で、SYSLOG TAG Terminatorの設定として□Use TAB as SYSLOG(RFC3164) TAG Terminatorがデフォルトでチェックされているためです。

このタグの部分までは、SyslogのRFC3164の定義通りに、PRI、HEADER（TIMESTAMP　HOSTNAME）、MSGのTAG部分が入っています。このTIMESTAMP(タイムスタンプ)は、Snareがログを送信した時刻を指しています。詳しくはこのRFC3164の解説を見てください。

また、タグにはSnareが入れたログ種別が入っており、Windowsのイベントログの場合は、MSWinEventLogという文字が入っています。

CONTENT部分のフィールド分割

タグの直後の区切り文字より後は、RFC3164のMSGのCONTENT部分にあたります。ここにイベントログの内容が区切文字である”|”に区切られて入っています。区切文字であるTABと”|”によって一つの生ログをPowerShellのコマンドで分割すると以下のP2以降のようになります。

Snareからイベントログのフィールド分割

これらを整理して、フィールドの番号、英語の名称、イベントビューアー上の名称とイベントID 4625の実例を表にすると以下のようになります。

番号	名称（英語）	イベントビューアー名称	生(Raw)Syslogメッセージ例（イベントID 4625の例）
1	PRI Timestamp Hostname Tag	ー	<14> Dec 18 10:56:53 win-workgroup-3.kstest.internal MSWinEventLog
2	Alert Level	ー	6
3	Log Name	ログの名前	Security
4	EventCount	ー	262632
5	Date/Time	ログの日付	Wed Dec 18 10:56:52 2024
6	Event ID	イベントID	4625
7	Source	ソース	Microsoft-Windows-Security-Auditing
8	UserName (Domain\Name)	ドメイン\アカウント名	KSTEST\administrator
9	UserType	ユーザー	N/A
10	Return Code	キーワード	Failure Audit
11	System	コンピュータ―	WIN-WORKGROUP-3.kstest.internal
12	Task Category	タスクのカテゴリ	Logon
13	Strings	全般タブの枠の中身	アカウントがログオンに失敗しました。・・・・
14	Count by Source	ー	48

このフィールド分割を、生のSyslogに合わせて分かりやすく表示すると以下のようになります。

SnareからSYSLOG(RFC3164)送信時の生（Raw）Syslogメッセージのフォーマット

WinSyslogのプロパティとSnareイベントログのフィールドとの対応

SnareからのSyslog TAGがログ種別

今見たようにSnareがSYSLOG(RFC3164)で送信した場合は、MSGの先頭にあるTAG部にSnareが入れたログ種別があります。イベントログの場合は、MSWinEventLogというログ種別名でした。

Snareから送られるハートビートのログの場合は、AgentHeartBeatとなります。このタグに入るログ名称を使ってログを種類毎に分けることができます。

なおSnareがSYSLOG (RFC5424)で送信した場合は、HeaderのMSGIDに、ログの種別が入ります。

WinSyslogの標準およびSyslogプロパティとの対応

WinSyslog の内部では、ログを受信するサービスが生成するイベントデータの単位をインフォメーションユニットと呼んでいます。インフォメーションユニットにはデータの形式の違いによってタイプがあり、主なものはSyslog、SNMP Traps、イベントログの監視 V2です。

今回の設定ではSnareはSyslogとしてイベントログを送信しますので、インフォメーションユニットのタイプはSyslogになります。この場合WinSyslogは、Syslogのフォーマットに従ってフィールドに分割します。各フィールドの値は、対応するプロパティに保存されます。

具体的なSnareからの生（Raw）Syslogメッセージのイベントログの各フィールドに対応するプロパティは以下のようになります。なお、％timereported%、%source%、%msg%は標準プロパティに、%syslogで始まるプロパティは、Syslog特有のSyslogメッセージプロパティに分類されています。

こうして、プロパティの%syslogtag%に、Snareで付けられたログ種別名が入ります。

WinSyslogでのログ種別毎のログの保存方法

3階層のディレクトリ構成でのログの保存設定

C:\Logsの以下のディレクトリ構造にログを保存する場合を考えます。前回考えたように、全体のログのディレクトリの下に日付毎のディレクトリを作り、その下にログの送信元毎のディレクトリを作ります。更に、ファイル名はログ種別とログの採取された時間帯を二けたの時刻で入れるものとします。

このように決めた場合、ログのパス名を書き下すと、C:\Logs\YYYY-MM-DD\[Source]\[ログ種別(Tag)]-hh_n.log　となります。各部分の説明をつけると以下のようになります。

ファイルは扱いやすいように4MB(4096kB)で分割するものとします。このように分割してログを保存するには、WinSyslogのアクションのファイルログの設定をデフォルトに対して以下の変更をすることで実現できます。

□ファイル名にプロパティ（変数）を使用　をチェック
ファイルパスに、　C:\Logs\%timegenerated:1:10:localtime%\%source% を入力
%timegenerated%（WinSyslogのログの受信時刻）の形式は、“YYYY-MM-DD hh:mm:ss”であり、1:10は１～10文字目を意味します。次のlocaltimeはオプションで、これを指定しないとUTCによる表示となります
%source%には、送信元のIPアドレスまたはホスト名が入ります。どの値が入るのかは、サービスの全体タブのチェックボックスの設定により決まります。詳細は「WinSyslogユーザーマニュアル v.17 」の 5.3.3. Syslogサーバーの「チェックボックスの設定とプロパティ『ソース(%source%)』にセットされる値について」をご覧ください
ファイルベース名に、%syslogtag%-%timegenerated:12:13:localtime%　を入力
%timegenerated%の12～13文字目はログ生成の時刻を24時制で表わしています
□設定値（KB）でファイルを分割　をチェック
ファイル分割サイズ　を(KB)単位で記入します。今回はデフォルトの4096KBのままとします
□ファイル名に日付を出力　のチェックを外します（ファイルパスに日付を入れたためこちらは外します）

具体的なファイルログのアクションのファイル名に関するオプションのタブの設定は、以下のようになります。

この場合ディレクトリとファイル名は以下のようになります。

ここで見て分かるように、MSWinEventLogという名前のついたログファイルが、Windowsのイベントログで、それ以外のログは別のファイルに分離して保存されています。MSDNSServerは、WindowsのADサーバーのDNSサーバーのログです。AgentHeartBeatは、Snareのハートビートやエラーのログです。これらの採取方法などについては別の回で説明します。

ディレクトリ階層を設けない場合の保存設定

ログが少なくてディレクトリを分けない場合は、ベース名に%syslogtag%を入れて、□ファイル名に日付に出力 と □ファイル名にソースを出力 にチェックを入れるぐらいでよいかもしれません。

この場合、以下のように先にソース名が来て後ろに日付がYYYY-MM-DDで入り、最後にアンダースコアの後ろに追番が来ます。

いずれにしろログ量と検索しやすさを考慮してディレクトリ構造、ファイル分割の方針を予め決めてそれに従った指定をしてください。途中でディレクトリ構成やファイルの命名規則を変えると厄介なことになります。予めよく考えておくことが重要です。

ApacheLogやTelemetryLogについては別の機会に説明します。

ログを使いやすくするフィールド分割

フィールド分割しない場合のフィルタ条件の設定

例えば、不正なログオンの試みをWinSyslogでリアルタイムで検出し、アラートメールを送る場合を考えます。

Windowsイベントログのイベント ID 4625がログオン失敗のイベントログです。イベント ID 4625の生ログはこのブログの「生(Raw)ログの確認」で紹介しました。これから、単純に4625を検索すると、Snareからのイベントログには他にもEventCountなど数字だけのフィールドもあり、条件として不十分であることが分かります。また、イベントIDはイベントログのソース/ログの名前ごとに定義されているので同じIDが他にもある可能性があります。

したがって、ログの名前とイベントIDが何番目のフィールドかを意識してサーチ（検索）する必要があります。イベントログの本体は、SYSLOG(RFC3164)の場合、標準プロパティの%msg%にあります。その中で、「Snareからイベントログのフィールド分割」で説明したように、Snareからのログは[Alert Lvevel]|[Log Name]|[EventCount]|[Date/Time]|[Event ID]とVertical Barで区切られて並んでいます。よって%msg%の中を正規表現で、例えば、
^[^\|]+\|Security\|[^\|]+\|[^\|]+\|4625\|　と検索する必要があります。

Snareからのイベントログを使ったログオン失敗アラートメールのフィルタ条件設定例

上記の例では、Snareからのログがsyslogであり、かつイベントログであるという条件とともに、SecurityログでEvent IDが4625であるという条件が設定されています。

このログオン失敗のアラート条件をWinSyslogで具体的に設定するには、ルールを作成した後で、フィルタをクリックし、Add Filterをクリックして、メニューから目的のフィルタを選びます。最初は、インフォメーションユニットタイプ > Syslog を選択します。

続いて、再度「Add Filter」をクリックして、Syslog > Syslog タグを選択します。「EVAL　Property: %syslogtag% contains “”」という行が追加されます。そのPropertyから右をクリックすると、下に「詳細」のタブが現れるので、「比較のオペレーション」を「is equal」に変更し、「プロパティ値を設定」に「MSWinEventLog」を入力します。

最後に、「AND」の横にカーソルを移動してから、「Add Filter」をクリックして、全般 > メッセージを選択します。現れた「Property: %msg% contains “”」をクリックして、「詳細」タブで、「比較のオペレーション」に正規表現を入れるために「match regex」を選択し、「プロパティ値を設定」に先ほどのイベントID 4625のための正規表現を入力することで、目的のフィルタ条件が設定できます。

設定を確認し反映するためには、設定クライアントの停止ボタンをクリックして、まずサービスを止めてから、確認、保存のボタンをクリックし、最後に開始ボタンをクリックします。サービスを停止しないで設定を保存すると、サービスの動作がおかしくなることがあるので注意が必要です。

フィールド分割でフィルタ条件を簡単明瞭にする

もう少しシステマティックに分かりやすく条件設定を行うには、きちんとフィールド分割して、フィールド毎に名前のついたプロパティとすることが有効です。実際、いくつかのフィールドの条件を組み合わせるなど複雑な条件を設定しようとすると、正規表現で対応するのは難しく現実的ではありません。

例えば、ログオン失敗を検出しアラートメールを送信する場合に、同一のユーザーIDで決められた時間内に決められた回数のログオン失敗があったという条件は、正規表現だけではできません。WinSyslogのフィルタにある「全体の条件」の「選択したプロパティに対する全体の条件」でフィールド分割した際の、ユーザーIDに当たるプロパティを指定する必要があります。

フィールド分割（再構成）の実際

WinSyslogの再構成(Post Processing)

WinSyslogの再構成（Post Processing）の機能を、SyslogのMSGのContent部分から各フィールドを独立したプロパティとして抽出するために使うことができます。

この機能の解説は、「WinSyslogユーザーマニュアル v.17 」5.5.4.5 再構成(Post Processing)と、「WinSyslog v14 Post-Process（再構成）アクションの使用例」にあります。更に詳しい解説はメーカーのサイトの「Post Processing」というドキュメントにあります。

Snareのイベントログを再構成しプロパティを抽出

再構成を行うには、Snareのログを受信するサービスから呼び出したルールセット（この場合はDefault RuleSet）に、再構成のルールを作成します。

Default RuleSetを右クリックし、プルダウンで「ルールを作成」を選択すると、「新規でルールを作成します…」の画面が開きます。「再構成」など適切なルール名を入力し、「ルールの作成後…」で、「選択したアクションをルールに作成」で内部アクションの中から「再構成」にチェックを入れてOKをクリックします。

再構成のルールが作成されるので、フィルタにSyslogインフォメーションユニットと%syslogtag%がMSWinEventLogである条件を入力します。Actionsにできた「再構成」をクリックして、再構成のルール入力画面を開きます。

今回の設定ではイベントログの本体の入った%msg%は、Snareで縦棒（Vertical Bar “|”）でフィールドに分割されています。そこで、数字が入るところはIntegerで読み込み、それ以外はUpToで次の縦棒までを一つのフィールドとして読み込み、縦棒はfillerとして読み飛ばします。

SnareでStringsと呼んでいる部分は、イベントビューアーで見ると全般のタブの枠内の内容に対応しています。この部分との境界は、Vertical Barが二本なので注意してください。

プロパティの名前は、u-_______として、先のフィールド分割の表にある英語のフィールド名称をベースに名付けます。%msg%を分割して、%u-AlertLevel%、%u-LogName%、%u-EventCounter%、%u-Date/Time%、%u-Source%、%u-UserName%、%u-UserType%、%u-ReturnCode%、%u-System%、%u-TaskCategory%という10個のフィールドを抽出し、残りを%msg%に戻す再構成のルールは以下の通りです。

<PPRules>
  <Rule Property="u-AlertLevel" Syntax="101">
  </Rule>
  <Rule Property="Filler" Syntax="201">|</Rule>
  <Rule Property="u-LogName" Syntax="204">|</Rule>
  <Rule Property="Filler" Syntax="201">|</Rule>
  <Rule Property="u-EventCounter" Syntax="101">
  </Rule>
  <Rule Property="Filler" Syntax="201">|</Rule>
  <Rule Property="u-Date/Time" Syntax="204">|</Rule>
  <Rule Property="Filler" Syntax="201">|</Rule>
  <Rule Property="u-EventID" Syntax="101">
  </Rule>
  <Rule Property="Filler" Syntax="201">|</Rule>
  <Rule Property="u-Source" Syntax="204">|</Rule>
  <Rule Property="Filler" Syntax="201">|</Rule>
  <Rule Property="u-UserName" Syntax="204">|</Rule>
  <Rule Property="Filler" Syntax="201">|</Rule>
  <Rule Property="u-UserType" Syntax="204">|</Rule>
  <Rule Property="Filler" Syntax="201">|</Rule>
  <Rule Property="u-ReturnCode" Syntax="204">|</Rule>
  <Rule Property="Filler" Syntax="201">|</Rule>
  <Rule Property="u-System" Syntax="204">|</Rule>
  <Rule Property="Filler" Syntax="201">|</Rule>
  <Rule Property="u-TaskCategory" Syntax="204">|</Rule>
  <Rule Property="Filler" Syntax="201">||</Rule>
  <Rule Property="msg" Syntax="202">*Enter value for 値*</Rule>
</PPRules>

このルールを、再構成ルールファイル(.fxm)としてファイルに保存し、ルールとしてインポートすれば、ここで定義したプロパティがカスタムプロパティとしてそのまま使えます。再構成ルールのインポートは、アクション画面の「ルールをインポート」 をクリックしてファイルを選択し、「開く」をクリックすることでできます。

再構成後のプロパティを使ったフィルタ条件の活用

ここでは、先の再構成で抽出したイベントIDなどのプロパティを活かしたアラートメールの条件設定ついて説明します。

WinSyslogでのアラートメールの設定方法は、「E-mail送信(アラートメール)設定」という資料があります。一般的なアラートメール自体の設定方法については、こちらを参考にしてください。

イベント IDによるフィルタリング

再構成で作成したカスタムプロパティを使うには、同じルールセットの中に再構成のルールよりも下にルールを作るか、再構成のアクションの下に「ルールセットの呼び出し」というアクションを追加するか、どちらかです。ここでは、「ルールセットの呼び出し」でイベントログを処理するための別のルールセットを呼び出す作りとしています。

「ルールセットの呼び出し」を使えば、呼び出すルールセットをサブルーチンのように使えます。また、再構成ルールのフィルタ条件が既にかかった状態で、ルールセットが呼ばれるので、その部分のフィルタ条件（Syslogかつイベントログ）は不要となります。

ルールセットの呼び出しを行うには、まず先に呼び出されるルールセットを作成します。その後で、呼び出す側のアクションを「Actions」を右クリックして、アクションを作成のメニューの中から、「ルールセットの呼び出し」を選択します。「処理を実行するルールセット」のプルダウンから、先に作成したルールセットを選択します。

呼び出されたルールセット（以下の例では「MSWinEventLog処理」）の中で、フィルタを使ってイベントID 4625だけを残すことは以下のように簡単にできます。

カスタムプロパティによるフィルタを設定するには、Add Filterで、カスタムプロパティを選択して条件を設定します。ここで%u-EventID%は数値ですが、文字列扱いとなります。

回数しきい値ありのアラート設定

全てのログオン失敗でアラートメールを発信すると、誰でもパスワードを入れ間違えることがあるので、過剰にメールが発行されることになります。そこで、一定のしきい値を設けて、ある単位時間内に複数回のログオン失敗を捕まえれば、不正にログオンしようとした場合について過不足なく捕まえることができると考えられます。そのしきい値については適宜環境の特性を見極めながらチューニングすることで精度を上げられるでしょう。

そのような設定がWinSyslogでは、フィルタの「全体の条件」でできます。例えば、60秒以内に連続2回ログオン失敗した場合にアラートメールを発行し、その後60秒たたないと次の連続ログオン失敗の検出は行わないという設定は以下のようになります。

User ID毎のしきい値ありのアラート設定

通常はこの程度の絞込みで十分かもしれません。しかし、場合によってはアカウント毎にログオン失敗が連続しているかどうか見たほうが確実でしょう。そのような場合は、「全体の条件」で、□選択したプロパティに対する全体の条件、にチェックを入れて、その右の枠に先ほど抽出したカスタムプロパティの、%u-UserName%を入力します。

「選択したプロパティに対する全体の条件」をチェックし%u-UserName%を手で入れる

プロパティを挿入する枠の右にある「挿入」をクリックしても、これはカスタムプロパティであるためメニューにリストされません。自ら定義した名前を切り貼りするなどして、間違いなく正しい名称を入れるようにする必要があります。

これにより、%u-UserName%の値ごとに連続してログオン失敗したかどうかを判別してアラートメールを発行することが可能となります。このようにきめ細かい条件を指定する必要がある場合、再構成で作成したカスタムプロパティを使うことが有用です。また、イベントID毎に異なる条件を設定するような場合にも、フィールド分割されたプロパティがある方が使いやすいことは言うまでもありません。

おわりに

最後までお読みいただき、ありがとうございました。元のログの構成を理解して、フィルタ条件の設定方法が分かれば、ログを本格的に活用しやすくなります。少々、読みこなすのが大変だったかと思いますが、ここまで読んだ甲斐があったと思って頂ければ幸いです。

次回は、Snareの特長的な機能であるファイル整合性監視（File Integrity Monitoring）/レジストリ整合性監視（Registry Integrity Monitoring）を使って、ファイルやシステム設定の改ざんをログから検出する方法について詳しく説明します。

Snare紹介ページ

WinSyslog紹介ページ

お問い合わせ

30日無償で利用いただける評価版を以下のダウンロードリンクに用意しております。簡単に検証が開始できますので、ぜひお気軽にお試しください。

評価版ダウンロード

WinSyslog 使い方ガイド#6 ログに送信元 IP アドレスと Hostname を両方出力する

Snare WindowsエージェントとWinSyslogで脅威に備える（２）ログを整理・分類して保存し活用する

はじめに