注意：この機能は、Splunk バージョン 5.0 で⾮推奨 (廃⽌予定) となりました。⾮推奨で廃⽌予定の機能の⼀覧は、リ リースノートの「⾮推奨 (廃⽌予定) の機能」を参照してください。
Splunk のファイルシステム変更モニター機能は、ファイルシステム内の変更を追跡する場合に役⽴ちます。ファイルシ
ステム変更モニターは、指定した任意のディレクトリを監視して、そのディレクトリに何らかの変更が⾏われた場合に、イベントを⽣成します。さまざまな設定を変更することができ、システム上の任意のファイル (Splunk 固有のファイルだ けでなく) の編集、削除、追加を検知することができます。たとえば、/etc/sysconfig/
を監視して、システム設定が変更
された時にアラートを⽣成するように設定することができます。ファイルシステム変更モニターは、inputs.conf に設定します。
重要：この機能と転送機能を使ってリモートインデクサーにイベントを送信する場合は、ヘビーフォワーダーを使⽤する か、または「ユニバーサルフォワーダーでの使⽤」の説明に従って設定を⾏う必要があります。
注意：Windows でのファイル読み取りの監査については、Splunk コミュニティのベストプラクティス Wiki を参照して ください。ユーザーによっては、Windows のネイティブ監査ツールを利⽤する⽅が簡単なこともあります。
ファイルシステム変変更モニター機能の仕組み
ファイルシステム変更モニターは、以下の情報を使って変更を検出します。
変更⽇時 グループ ID ユーザー ID
ファイルモード (読み取り/書き込み属性など) ファイルコンテンツの SHA256 ハッシュ (オプション)
ファイルシステム変更モニターの以下の機能を設定することができます。
正規表現を使ったホワイトリスト 監視対象ファイルの指定 正規表現を使ったブラックリスト
スキップするファイルの指定 ディレクトリ再帰
シンボリックリンクトラバーサルを含める
複数ディレクトリのスキャン、およびそれぞれに対する独⾃のポーリング頻度の指定 暗号化署名
ファイルシステム変更の分散監査データの作成
追加/変更時にファイル全体を 1 つのイベントとしてインデックス作成 ファイル全体やハッシュの送信⽤にサイズ削減
すべての変更イベントのインデックス作成と Splunk を使ったサーチ
警告：root ファイルシステムのモニターに、ファイルシステム変更モニターを使⽤しないでください。そうすると、ディ レクトリ再帰が有効になっている場合に危険で、また時間もかかります。
ファイルシステム変変更モニターの設定
73
デフォルトでファイルシステム変更モニターは、$SPLUNK_HOME/etc/
の内容が変更、削除、または追加された場合に、監査
イベントを⽣成します。Splunk を初めて起動する場合、$SPLUNK_HOME/etc/ディレクトリとそのサブディレクトリ内の各
ファイルに対して、監査イベントが⽣成されます。その後は、設定に変更が⾏われると (⼿段に関係なく)、影響するファ イルに対して監査イベントが作成されます。signedaudit=trueの場合、ファイルシステム変更監査イベントは監査イン
デックス (index=_audit) に保管されます。
signedauditが有効になっていない場合は、他のインデックスを指定しない限
り、デフォルトでイベントは main インデックスに書き込まれます。注意：ファイルシステム変更モニターは、変更を⾏ったアカウントのユーザー名はモニターしません。変更の発⽣のみを モニターしています。ユーザーレベルのモニタリングの場合は、その情報にアクセスするネイティブのオペレーティング システム監査ツールの使⽤を検討してください。
ファイルシステム変更モニターを使ってディレクトリを監視するには、$SPLUNK_HOME/etc/system/local/
内または
$SPLUNK_HOME/etc/apps/
の独⾃の App ディレクトリ内の、
inputs.confに
[fschange]スタンザを追加、編集します。設定
ファイルの⼀般情報については、「設定ファイルについて」を参照してください。注意：[fschange]
スタンザを変更した場合は、Splunk を再起動する必要があります。
構⽂
[fschange]
スタンザの構⽂を以下に⽰します。
[fschange:<directory or file to monitor>]
<attribute1> = <val1>
<attribute2> = <val2>
...
以下の事項に注意してください。
システムは、指定ディレクトリとそのサブディレクトリの、すべての追加/更新/削除操作をモニターします。
任意の変更によりイベントが⽣成され、Splunk によりインデックスが作成されます。
<directory or file to monitor>
のデフォルトは
$SPLUNK_HOME/etc/です。
属性
すべての属性は任意で、省略することができます。利⽤可能な属性の⼀覧を以下に⽰します。
index=<indexname>
⽣成されたすべてのイベントを保管するインデックス。
デフォルトは main です (監査イベント署名を有効にしていない場合)。
recurse=<true | false>
真 (True) の場合、<code[fschange]</code> で指定されているディレクトリ内のすべてのディレクトリが再帰さ れます。
デフォルトは真 (True) です。
followLinks=<true | false>
真 (True) の場合、ファイルシステム変更モニターはシンボリックリンクを追います。
デフォルトは偽 (false) です。
警告：followLinks
の設定には注意を払う必要があります。そうしないと、システムループが発⽣する可能性がありま
す。
pollPeriod=N
このディレクトリに対する変更を、N 秒ごとにチェックします。
デフォルトは 3600 です。
何らかの変更を⾏った場合、そのシステム監査イベントが⽣成され、それが監査⽤サーチに利⽤できるよう になるまで、1∼3600 秒ほどかかります。
hashMaxSize=N
N バイト以下の各ファイルの SHA1 ハッシュを算出します。
このハッシュは、ファイル/ディレクトリの変更を検出するための、追加の⼿段として利⽤することができます。
デフォルトは -1 です (変更検出にハッシュを使⽤しない)。
signedaudit=<true | false>
暗号化署名した追加/更新/削除イベントを送信します。
デフォルトは偽 (false) です。
真 (True) を設定すると、_audit インデックス内にイベントが⽣成されます。
index
属性を設定している場合は、偽 (False) を設定する必要があります。
注意：signedaudit
に真 (True) を設定する場合は、
audit.confで監査が有効になっていることを確認してください。
fullEvent=<true | false>
追加または更新を検出した場合に、完全なイベントを送信します。
sendEventMaxSize
属性でさらに修飾されます。
デフォルトは偽 (false) です。
sendEventMaxSize=N
イベントのサイズが N バイト以下の場合にのみ、完全なイベントを送信します。
これにより、インデックス作成されたファイルデータのサイズを制限します。
デフォルトは -1 (無制限) です。
sourcetype = <string>
この⼊⼒からのイベントのソースタイプを設定します。
"sourcetype::" is automatically prepended to
<string>.
デフォルトは audittrail
(
signedaudit=trueの場合) または
fs_notification(
signedaudit=falseの場合) になります。
filesPerDelay = <integer>
<integer>
件のファイルの処理後、
delayInMillsに指定されている時間に相当する遅延を挟みます。
これは、CPU を消費しすぎないように、ファイルシステムのモニタリングを抑制するために⽤いられます。
delayInMills = <integer>
filesPerDelay
に指定されているように、
<integer>件のファイルの処理ごとに使⽤する遅延時間 (ミリ秒)。
これは、CPU を消費しすぎないように、ファイルシステムのモニタリングを抑制するために⽤いられます。
filters=<filter1>,<filter2>,...<filterN>
これらの各フィルタは、モニターのポーリングサイクル中に⾒つかった各ファイルやディレクトリに対して、左から右へ と適⽤されていきます。フィルタの定義については、次のセクションを参照してください。
フィルタの定義
filters
属性で使⽤するフィルタを定義するには、以下のように
[filter...]スタンザを定義します。
[filter:blacklist:backups]
regex1 = .*bak regex2 = .*bk
[filter:whitelist:code]
regex1 = .*\.c regex2 = .*\.h [fschange:/etc]
filters = backups,code
Fschange ホワイトリスト/ブラックリストロジックは、⼀般的なファイアウォールと同じように処理されます。イベント
は、最初に⼀致するフィルタが⾒つかるまで、フィルタのリストと順番に照合されていきます。イベントと最初に⼀致し たフィルタがホワイトリストの場合、そのイベントのインデックスが作成されます。イベントと最初に⼀致したフィルタ がブラックリストの場合、そのイベントのインデックスは作成されません。⼀致するフィルタが⾒つからなかった場合 は、イベントのインデックスが作成されます。これは、暗黙的に「すべて通過」フィルタが存在し、すべてに該当しないイ ベントのインデックスが作成されることを意味しています。そのような場合にインデックスを作成させたくない場合は、リストの最後に残りのイベントに⼀致するブラックリストを設定します。
例：
...
filters = <filter1>, <filter2>, ... terminal-blacklist [filter:blacklist:terminal-blacklist]
regex1 = .?
重要：⼀連のホワイトリストの最後にある最終ブラックリストも含めて、あるディレクトリがブラックリストの対象と なった場合、そのすべてのサブフォルダとファイルは⾃動的にブラックリスト化され、ホワイトリストに渡されることは ありません。これに対処するために、ブラックリストフィルタの前に、必要なフォルダとサブフォルダすべてを明⽰的に ホワイトリストに指定してください。
例
指定ディレクトリ内の拡張⼦が .config、.xml、.properties、および .log
のファイルをモニターし、その他すべてを無視
75
する設定を以下に⽰します。
注意：この例では、ディレクトリがブラックリストに該当する可能性があります。その場合、そのすべてのサブフォルダ とファイルも⾃動的にブラックリスト化されます。ホワイトリストに指定されたディレクトリ内のファイルのみがモニ ターされます。
[filter:whitelist:configs]
regex1 = .*\.config regex2 = .*\.xml regex3 = .*\.properties regex4 = .*\.log
[filter:blacklist:terminal-blacklist]
regex1 = .?
[fschange:/var/apache]
index = sample recurse = true followLinks = false signedaudit = false fullEvent = true
sendEventMaxSize = 1048576 delayInMills = 1000
filters = configs,terminal-blacklist
ユニバーサルフォワーダーでの使⽤
ユニバーサルフォワーダーからファイルシステム変更モニターイベントを転送するには、signedaudit = false
と
index=_audit
を設定する必要があります。
[fschange:<directory or file to monitor>]
signedaudit = false index=_audit
この⽅法では、ファイルシステム変更モニターイベントのインデックスは _audit