はじめに
この記事は、ログを取ったことがない中小規模のシステムを管理していて、どうしたらいいのかまだよく分からないというWindowsを中心としたシステムの管理者の皆様向けです。また、取り敢えずログは集めているが活用方法が分からないという皆様にもお役に立てるだろうと思います。
ログとは何か、特に基本的なログ形式であるSyslogについては、弊社の紹介記事にあるような予備知識があると理解しやすいと思います。
何のためのログ収集か
ログ収集・管理に際しては、何のためにどんなログを取って集めて保存し、異常がないかを調べるかが大事です。ログの世界は、コンピューターとネットワークの発展とともにとても多様で複雑になってきているからです。どんな脅威からシステムの何を特に守りたいのか、具体的なイメージを持つ必要があります。
そうは言っても、最初はどんなログで何が分かるかも分からないということもあると思います。そこで、弊社製品の Snare Windows（Desktop）エージェントと弊社の代表的なログサーバーである WinSyslog を使って、こうすればこんなログが取れてこんなことが分かる、というだけでなく、こんな対応が取れるということまで紹介しますので、この記事でイメージを膨らませて頂ければと思います。
Snare Windows (Desktop) エージェントについて
そこで今回取り上げる弊社製品の一つであるSnare Windows (Desktop) エージェントを簡単に紹介します。Snare WindowsエージェントおよびSnare Windows Desktopエージェントは、WindowsサーバーやWindows PCのようなエンドポイントからログをログサーバーに転送するエージェントです。
このブログでは二つをまとめて、Snare Windows（Desktop）エージェントと表記します。この二つは機能は同等で、Snare WindowsエージェントはサーバーとPCのどちらにもインストールできますが、Snare Windows DesktopエージェントはPCのみにインストールできる廉価版です。
Snare Windows（Desktop）エージェントの特長
Snare Windows（Desktop）エージェントはWindowsのイベントログが取れるだけでなく、以下の機能もあり、サーバーやPCの総合的なログ採取による脅威への備えが可能です。
- ファイルログのフィルタリングと転送 DNSサーバーやWebサーバーのアクセスログやエラーログなどイベントログには含まれないファイルに書き出されるログをフィルタリングし転送する機能
- ファイルやレジストリの改ざん検出 ファイルやレジストリのチェックサムを定期的に比較し、異動があった場合にログを送信する FIM(File Integrity Monitoring)/RIM(Registry Integrity Monitoring)の機能
- USBイベントの検出 WindowsマシンにUSBの挿抜を行ったことを示すSnare Windows (Desktop) エージェント独自のログ生成機能
- CPU、ディスク、メモリ、ネットワークのテレメトリー CPU、ディスク、メモリ、ネットワークの稼働状況をモニターしたログを送信する機能（v5.9.0版以降、v5.9.0はジュピターでは2025年1月末頃よりサポート予定）
Snare Windows（Desktop）エージェントは、採取したログを送信先であるログサーバーやSIEMの要件に合わせフォーマットやプロトコルを選んで送信できます。
本ブログで前提とするシステム構成
このブログでは、下図のようなSnare Windows(Desktop)エージェントとログサーバーのWinSyslogと連携を例に、上記の特長を生かす使い方を解説します。
Snare Windows（Desktop）エージェントからログをWinSyslogに転送することで以下のようなメリットが生まれます。
- サーバー/PCのログを集中管理・監視することで外部及び内部からの不正アクセスやファイル改ざんを早期に見つけ、影響範囲を確定して対応できる
- サーバーおよびPCの健全性をリアルタイムまたは保存されたログで長期にわたって確認できる
最初の今回は、以下の内容を説明します。
- Snare Windows（Desktop）エージェントで採取可能なイベントログやその他のログを、WinSyslogで一か所で集中管理し活用しやすいように整理し、保存する方針の検討
- 上記整理の方針に則ったSnare Windows（Desktop）エージェントからログを送信し、WinSyslogで受信する場合の具体的な設定内容と方法
ログ整理の方針
タイムスタンプとログ送信元（ソース）が重要
後々のログの検索などの活用を考えれば、ログを整理して保存することが重要です。
その整理の方針としては、ログの時系列調査やバックアップやアーカイブの観点からも、ログの日付や時間が最も重要です。これは通常、タイムスタンプと呼ばれています。
次に重要なのはそれがどこで起きたかです。これはログを一か所に集約して活用する上で欠かせない情報で、ログの送信元（ソース）がそれに当たります。その次が、ログの種類などです。
ログは形式の異なる種別毎に分離
一方、Snare Windows (Desktop) エージェントではWindowsのイベントログ以外のログも採取できます。またWinSyslogでは、多くのネットワーク系の機器のログも収集できます。
そのログの種類によってログを構成する情報がどのように表現されているかの形式、英語で言うフォーマットが異なります。ですから、種類の異なるログは別々のファイルに分けて保存するのがよいと考えられます。
タイムスタンプ、送信元（ソース）、ログ種別で整理する
上記の考察を踏まえて、ここではタイムスタンプと送信元とログの種類のこの3つをこの順番で重要なキーとしてログを整理する方針とします。特に、Snare Windows（Desktop）エージェントからは、イベントログ以外の形式の異なる多種類のログが送付できるので、それらのログの種別を明確に切り分けることが重要です。
この辺りの背景については、ログの標準規格であるSyslogについての弊社の記事が参考になります。
ログ保存の方針
ログ量の見積もりと保存・バックアップ・アーカイブの方針
ログを保存するにあたっては、毎日発生するログの量の見積もりと、保存期間、そのうち非圧縮で保存する期間と、圧縮しアーカイブして保存する期間、ログの圧縮率などを検討する必要があります。
毎日のログ量の見積もりに加えて、ログが大量に発生する時間帯のピークのログ量も、機器やソフトの能力が足りるかを見極めるために必要です。それが分からない場合は、評価版のソフトなどを使って小規模に試してみるとよいでしょう。
ログ検索と保存形態の関係の検討
ログ量の概要が把握できたなら、保存期間や保存場所の構成についても結論を出しましょう。
その際、一年を超えるような比較的長期のログを検索する必要がある場合と、通常は1か月程度前までのログを調べれば済む場合では、保存の仕方を変えたほうがよいです。
その理由は、ディレクトリ名やファイル名で検索範囲が絞りこめる方が検索は速くなり、また圧縮ファイルの検索は時間がかかり、アーカイブについては通常はそのままでは検索できないからです。
ディレクトリ構成やファイル命名規則の検討
検索対象が長期にわたる場合は、一か所のディレクトリに年単位のログを保存するとファイル数が非常に多くなってしまうので、日付毎にディレクトリを分ける必要が出てきます。
更にログを分離して整理するならば、その下にログソース名のディレクトも作るとよいでしょう。検索対象のログ量が少ない場合、ディレクトリは一つでも構わないでしょう。
Snare Windows（Desktop）エージェントのログをWinSyslogに転送して集中管理する場合は、ログ量もそれなりになると思われます。そこで、日付毎のディレクトリを作り、更にその下にソースごとのディレクトリを作り、更にログ種別毎にファイルを分けることをお薦めします。
Snare Windows (Desktop) エージェント側の転送設定
SnareエージェントとWinSyslogのインストール
SnareやWinSyslogのインストールの説明は、「Snare Windows（Desktop）エージェント v2 インストールガイド」や「WinSyslogのインストールとライセンス登録」にあります。
インストールについては、上記マニュアルを参照してください。
Windowsイベントログの監査ポリシー設定
Snare Windows（Desktop）エージェントは、デフォルトでインストール直後からWindowsイベントログの監査ポリシーが設定されています。このポリシーでは、Windows ログのApplication、セキュリティ、システムのログの他、アプリケーションとサービスログの中で有効となっているログのほとんど全てが転送先に送付されます。
また、Windowsのセキュリティのログに関しては、監査ポリシーにデフォルトでフィルタが設定されており、選択されているイベントIDのログのみが送付されます。
詳しい監査ポリシーの設定については、「Snare Windows（Desktop）エージェント v2 ユーザーガイド」の「8.1 イベントログの監査ポリシー設定」、および、「付録 C – 監査ポリシーとセキュリティイベント ID」をご覧ください。
その他のログの設定
Snare Windows（Desktop）エージェントでは、イベントログ以外のログも採取できますが、それらの設定方法については、回を改めて説明します。ただしデフォルトの設定であっても、重大なエラーがあった場合などに、AgentHeartBeatログが送付されることがあります。
Snare Windows（Desktop）エージェントでは、このAgentHeartBeatログも含めて全てのログが、送付先に同じストリームで転送されるので、受信側でログ種別を判別し分離する手立てが必要です。
ここからはSnare Windows（Desktop）エージェントのデフォルト監査設定を前提に、イベントログなどをWinSyslogに転送して使う場合の送受信設定のポイントを説明します。
Snareでのログ送信フォーマットの検討
Snare Windows (Desktop) エージェントのログ送信フォーマットは、多くのログ形式に対応しており、これもSnareエージェントの特長の一つです。
中でもログのフィールド（項目、トークンともいう）をタブ文字(ASCII 0x09の制御文字)で区切ったフォーマットはSnareフォーマットとして知られているもので、これがSnare Windows (Desktop) エージェントの大きな特長です。
一方、ログを各所から受信して保存するログサーバーのWinSyslogは、その名の通りWindows上のSyslogサーバーです。まさにSyslogを扱うようにできています。
以上の前提から、Snare Windows (Desktop) エージェントからイベントログなどの送信には、WinSyslog側で扱いやすいsyslogフォーマットで送るのがよいと考えられます。なおSnareからsyslogフォーマットでログ送信した場合、WinSyslogでログ種別は簡単に判別でき、その点でも問題ありません。具体的な判別方法などは次回説明します。
第一候補：SYSLOG(RFC3164)でVertical Bar区切り
Snareの標準の区切り文字のタブは、残念ながらWinSyslogは区切文字（Delimiter Character）としてうまく扱うことができません。代わりに”|”（Vertical Bar、縦線、ASCII 0x7C）を使いましょう。
そこで、Snareからのログ送信フォマートはSYSLOG(RFC3164)でDelimiter CharacterはVertical Bar ”|”とします。これを第一候補とするのは、より進んだRFC5424を選んでも、イベントログなどのログ本体の構成は同じなので、よりシンプルなRFC3164で十分だからです。
第二候補：SYSLOG(JSON)でタブ区切り
しかしこれでは、イベントログのXMLにある詳細データが転送できないという問題があります。XMLにしかないデータが必要な場合は、SYSLOG(JSON)を使ってください。
ただし、JSONが一行に押し込められるので、検索には便利ですが、そのままではとても見にくいので、ログの表示に際しては工夫が必要になります。また、XMLの部分のみが転送対象となるため、それ以外の日本語のメッセージなども送付されないので、そこは不要という場合にのみこの形式を選択してください。
更にこの場合のSYSLOGは、RFC3164ではなくRFC5424であることに注意してください。区切文字はStructured-DataとMSGの間に一つ入るだけなので、デフォルトのタブのままでも問題ないでしょう。
ログ送信プロトコルとポートの選択
ログ送信のプロトコルの選択は、ログのロストする可能性のあるUDPよりもその心配のないTCPがお薦めです。
更に、社外を通過するなどのセキュリティ上の懸念がある場合は、TLSでデータを暗号化する必要があります。
Snareのログ送信のデフォルトはUDP 6161で、WinSyslogの受信はUDPの514です。TCPを使うと決めたので、ポート番号はWinSyslog側に合わせて一般的によく使われる514でログを送受信することにします。
Snare Windows (Desktop) エージェントでの具体的なログ送信設定
Snare Windows (Desktop) エージェントで具体的に上記の第一候補のフォーマットでTCP 514ポートを使って、WinSyslogにログを送信する場合の設定例は以下の通りです。
Snare エージェントのWeb GUIをhttps://localhost:6161などで開いて、左側のペインでDestination Configurationを選択します。
Domain/IP欄にWinSyslogのドメイン名もしくはIPアドレスを設定します。第一候補の例では、Portには514を入力し、ProtocolはTCPをプルダウンから選択します。
また、FormatではSYSLOG(RFC3164)を選択し、Delimiter CharacterではVertical Barを選択します。
一番下にある赤いUpdate Destinationsをクリックして設定値を確定した後、左側のペインのApply Configuration & Restart Serviceをクリックして設定をサービスに反映しサービスを再起動してください。
第二候補の設定の場合は、FormatにSYSLOG(JSON)を指定して、Delimiter CharacterはデフォルトのままのTabを選択します。
WinSyslog（ログサーバー）側の受信設定
Snare向けSyslogサーバーの追加
WinSyslogはインストール直後の設定では、Default Syslog ListenerというサービスがUDP 514ポートでSyslogを待ち受ける設定になっています。
先ほどのSnareエージェントの設定に合わせて、Snare用にTCP 514で待ち受けるSyslog Listenerを設定します。Snare用なので、Snare Syslog Listenerとしましょう。
通常UDP 514でネットワーク機器のsyslogを受信するので、Snare Syslog Listenerのサービスは新に追加します。WinSyslogの設定クライアントで、サービスを右クリックして、サービスを作成、Syslogサーバーを選択して、Syslogサーバーを追加します。
Snare向けSyslogサーバーの設定のポイント
このサービスの設定でポイントは、デフォルトの設定に対して以下の設定をすることです。
- 全体タブでインターネットプロトコルタイプにTCPを設定する（ポート番号は514のままでよい）
- エンコードタブで □メッセージのエンコードを自動検出する（UTF-8、SHIFT_JIS、EUCJP） のチェックをそのままに（デフォルトでチェックされているはずです）□メッセージ文字コードを全てUTF-8として処理する にもチェックを入れる
これはSnare Windows（Desktop）エージェントでは、イベントログをUTF-8で送信しますが、BOMなしUTF-8であるため、自動検出の設定だけでは文字化けするためです。そのため、Shift-JISのログをこの設定で受信した場合は文字化けします。この問題に対する対策は、別途説明します。
Snare向けSyslogサーバーのルールセットの設定
ログを処理するルールセットは、UDP 514のネットワーク機器向けのSyslog ListenerとTCP 514のSnare Syslog Listenerでは、その先の処理が異なるので分離します。
ここでは、UDP 514のルールセットはdefault rule setのままとし、Snare用のルールセットは、Snare rule setとして新たに作成するものとします。この場合、Snare用サービス側で指定するルールセットをSnare rule setに変更する必要があります。この作業は、Snare用のルールセット作成後でないとできないことに注意してください。
今回はここまでです。
おわりに
最後までお読みいただき、ありがとうございました。
次回は、WinSyslogでのログの分類保存の方法と、ログ種別毎のフィールド分割の方法について、特にイベントログのフィールド分割の方法について詳しく説明します。更に、具体的なログの活用として、イベントログから不正ログオンの予兆となるログイン失敗があった場合にアラートメールを送付する方法も解説します。
30日無償で利用いただける評価版を以下ダウンロードリンクに用意しております。簡単に検証が開始できますので、ぜひお気軽にお試しください。
