ログは集めた。
あとは訊き方を
覚えるだけ。

Splunk は何をする道具か

Splunk を一言でいうと、バラバラの機器のログを1か所に集めて、まとめて検索できるようにする道具です。SIEM と呼ばれる製品の一種です。

1.1なぜ grep ではダメなのか

ログを読むだけなら grep で足ります。実際、1台のサーバの1本のログを見るなら、そのほうが速い。問題は調査が1台で終わらないことです。

攻撃者が Web サーバに侵入して、そこから内部の端末に横移動して、ドメインコントローラの管理者権限を取った。この流れを追うには、Web サーバのアクセスログ、端末のプロセス起動ログ、DC の認証ログを突き合わせる必要があります。形式も置き場所もバラバラの3種類を。

最後の行が地味に重要です。攻撃者は痕跡を消しますが、すでに転送されたログには手が届きません。ログを集約する理由の半分はこれです。

1.2取り込みから検索までの流れ

Splunk がやっていることは大きく2段階です。

画面の見方 — 6つの領域

SPL の文法より先に、画面のどこに何があるかです。ここを知らないまま本のクエリを写経しても、結果が出たのか失敗したのかすら分かりません。

使うのは Search & Reporting というアプリです。ログイン後の左メニューから開きます。

2.1フィールドサイドバーが最重要な理由

本や記事に載っているクエリをコピーしても動かないことがよくあります。原因のほとんどはフィールド名が自分の環境と違うことです。同じ Apache のログでも、環境によって uri だったり uri_path だったり url だったりします。

サイドバーには、いま検索で返ってきたイベントに実際に存在するフィールド名が並びます。ここに無い名前を書いても絶対に動きません。

index=web sourcetype=access_combined
| head 20

2.2結果が Events に出るか Statistics に出るか

ここでつまずく人が多い。クエリの内容によって、結果が出るタブが変わります。

「クエリを実行したのに何も出ない」と思ったら、Events タブが空なだけで Statistics タブに結果が入っていることがあります。この違いの正体は第9章で説明します。

データの住所 — index と sourcetype

Splunk には何種類ものログが同居しています。だから検索するときは「どのログを見るか」を指定します。その指定に使うのが4つのフィールドです。

3.1index を書く癖をつける

index を書かないと、その利用者が読める全ての index を横断して検索します。データ量が多い環境では、これだけで検索が数分かかることがあります。

# 全部の保管庫を舐める
sourcetype=access_combined

# 保管庫を指定する
index=web sourcetype=access_combined

どんな index があるか分からないときは、これで一覧が出ます。

| eventcount summarize=false index=*
| table index, count

あるいは、どの index にどんな種類のログが入っているかを一気に見るならこちら。新しい環境を渡されたら最初に投げるクエリです。

index=*
| stats count by index, sourcetype
| sort - count

3.2sourcetype がフィールドを決める

第1章で「フィールドは検索時に切り出される」と書きました。どの切り出しルールを当てるかを決めているのが sourcetype です。

たとえば sourcetype=access_combined という名札が付いていると、Splunk は「これは Apache のアクセスログ形式だ」と判断して、あらかじめ用意されたルールを当てます。その結果、次のフィールドが自動で生えます。

イベントとフィールド

4.11行 = 1イベント

Splunk に取り込まれたログは、1件ずつバラバラの「イベント」として保管されます。Apache のアクセスログなら、リクエスト1件が1イベントです。

192.168.250.70 - - [24/Aug/2016:16:02:51] "GET /wp-admin/admin-ajax.php HTTP/1.1" 200 1043
192.168.250.70 - - [24/Aug/2016:16:02:53] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 88
40.80.148.42   - - [24/Aug/2016:16:03:11] "GET /uploads/sp-client-…/1.php HTTP/1.1" 200 12

この3行は、Splunk の中では独立した3つのイベントです。検索するというのは、この山から条件に合うものを取り出す作業です。

4.2どのログにも必ずある5つのフィールド

アンダースコアで始まる名前は、Splunk が内部で使う特別なフィールドという印です。_time と _raw がそれにあたります。

4.3自動で生えないフィールドは自分で作る

sourcetype のルールでカバーされない項目は、自分で切り出します。使うのは rex（正規表現で抜く）と eval（計算・変換して作る）の2つです。第8章で扱います。

どちらを使うかの判断はこうです。

検索は3層でできている

ここが本章の山場です。SPL のクエリは必ずこの3層でできています。この構造が頭に入ると、あとは部品を当てはめるだけになります。

5.1層1と層2の文法は違う

ベース検索は field=value やキーワードを並べるだけ。パイプの後ろは必ずコマンド名から始まります。この2つは別の言語だと思ったほうがいいくらい書き方が違います。

┌─ ベース検索：field=value を並べる
index=web sourcetype=access_combined status=404
| eval ...   ┐
| stats ...  ├─ パイプ：コマンド名から始める
| sort ...   ┘

5.2なぜ層を分けているのか

速度のためです。ベース検索は索引を引いて一気に絞れますが、パイプの後ろのコマンドは絞り込んだ全イベントを1件ずつ処理します。

だから同じ結果になる書き方でも、どちらに条件を書くかで速度が桁で変わります。

遅い ── 150万件を全部取り出してから捨てている
index=web
| where status=404

速い ── 索引の段階で絞っている
index=web status=404

絞り込みの書き方

ベース検索で覚えることは7つです。

6.1キーワードをそのまま書く

単語を書くと、その単語を含むイベントが返ります。どのフィールドかは指定しなくて構いません。

index=web failed
index=web "POST /admin"    ← 空白を含むならクォート

6.2フィールド名=値

ベース検索では不等号も使えます。

status=404
status!=200
bytes>10000
index=web status=404      ← 並べるだけで AND

6.3AND / OR / NOT

並べるだけで AND なので AND は普通は省略します。OR と NOT は必ず大文字で書きます。小文字だとただの検索語として扱われます。

status=404 OR status=500
index=web NOT clientip=10.0.0.5
(status=404 OR status=500) clientip=10.0.0.5

同じフィールドで値を並べるなら IN が読みやすい。

status IN (404, 500, 503)

6.4ワイルドカード

アスタリスクが0文字以上の任意の文字列にあたります。

uri="/uploads/*"
host="web*"

6.5大文字小文字のルール

区別して探したいときだけ CASE() で囲みます。

host=CASE(localhost)   ← 小文字の localhost だけ

6.6記号を含む文字列の罠

Splunk は取り込み時に、ピリオドやスラッシュやハイフンの位置で単語を区切って索引を作ります。

つまり 192.168.1.1 を検索すると、内部では「192 かつ 168 かつ 1 かつ 1」を含むイベントを探しにいきます。関係ないものが混ざる可能性があるということです。

1つのかたまりとして扱わせたいときは TERM() で囲みます。

TERM(192.168.1.1)

ただし実用上は、クォートで囲んで書けば大抵うまくいきます。候補を広めに拾ってから絞る動きになるだけです。

6.7時間範囲をクエリに書く場合

普段は時間ピッカーで指定しますが、保存する検索などではクエリに書きます。

index=web earliest=-24h latest=now
index=web earliest="08/24/2016:00:00:00"

コマンドは2種類しかない

SPL には百個以上のコマンドがあります。全部覚えるのは無理だし、その必要もありません。コマンドを2種類に分類するだけで、大半の混乱が消えます。

7.1この分類が効く理由

TYPE B を通した後は、元のフィールドが存在しません。だからこう書くとエラーも出ないまま結果が空になります。

index=web
| stats count by status      ← ここで status と count だけになる
| table _time, clientip     ← どちらも存在しない

逆に言えば、TYPE B は最後に置くのが基本形になります。詳しくは第9章で図解します。

| eventstats avg(bytes) as 平均
| where bytes > 平均 * 5

よく使うコマンド12個

実際の調査で使うのは、ほぼこの12個で足ります。

8.1eval — フィールドを作る TYPE A

使用頻度が最も高いコマンドです。= の左が新しく作るフィールド名、右が中身。既存の名前を左に書くと上書きになります。

| eval kb = bytes / 1024
| eval time = strftime(_time, "%Y/%m/%d %H:%M:%S")
| eval 判定 = if(status >= 400, "エラー", "正常")

よく使う関数

時刻の書式

✕ . が任意の文字として解釈される
eval x = replace(version, "HTTP/1.1", "")
○ 正しい
eval x = replace(version, "HTTP/1\.1", "")

8.2rex — 正規表現で切り出す TYPE A

自動で生えていないフィールドを自分で作ります。名前付きキャプチャがそのままフィールド名になります。

| rex field=uri "(?<filename>[^/]+\.\w+)$"

(?<filename>...) の filename が新しいフィールド名です。マッチしなかったイベントには生えません（エラーにはなりません）。field= を省略すると _raw つまりログ全文が対象になります。

| rex field=uri mode=sed "s/ HTTP\/1\.1//"

8.3search / where — 途中で絞る TYPE A

| search status=404
| where len(uri) > 100
| where bytes > 平均             ← フィールド同士は where だけ

where user = "admin"    ← 文字列 admin と比較（正しい）
where user = admin      ← admin という名前のフィールドと比較（0件）

8.4stats — 数える・まとめる TYPE B

SQL の GROUP BY にあたります。調査で最も出番の多い集計手段です。

| stats count by clientip

by を省くと全体でひとつの数字になります。

複数の集計を同時に書けます。as で列名を付けられます。

| stats count, dc(uri) as 種類数, min(_time) as 初回 by clientip

8.5table — 列を選ぶ TYPE B

指定した列だけの表を作ります。書いた順に左から並びます。書かなかった列は消えます。

| table _time, clientip, uri, status

8.6fields — 列を残す・捨てる TYPE A

table と似ていますが、こちらは形を変えません。マイナスを付けると「捨てる」。

| fields clientip, uri     ← この2つだけ残す
| fields - _raw          ← _raw を捨てて軽くする

途中で軽くしたいときは fields、最後に見た目を整えるときは table と使い分けます。

8.7sort — 並べ替える TYPE A

| sort count             ← 昇順（少ない順）
| sort - count           ← 降順（多い順）
| sort - count, uri      ← 同数なら uri で昇順

| sort 0 _time          ← 全件
| sort 100 - count       ← 上位100件だけ

8.8dedup / head / tail TYPE A

| dedup clientip     ← clientip の重複を1つに
| head 20            ← 先頭20件
| tail 20            ← 末尾20件

8.9rename — 列名を変える TYPE A

| rename clientip AS "接続元IP"

8.10top / rare TYPE B

stats count by して sort するのを1コマンドでやる省略形。件数と割合も出ます。

| top 10 uri
| rare 10 uri           ← 珍しいもの＝ハンティングの主戦場
| top 5 uri by clientip

8.11timechart — 時間ごとに集計 TYPE B

「時間で区切った stats」です。深夜に跳ねている、といった異常が視覚的に出ます。

| timechart span=1h count by status

span は 1m 5m 1h 1d のように指定します。

8.12eventstats — 集計しつつ形は保つ 例外

集計結果を「全イベントに列として配る」コマンドです。全体平均と各イベントを比較したいときに使います。

| eventstats avg(bytes) as 平均, stdev(bytes) as 標準偏差
| where bytes > 平均 + 標準偏差 * 3

「全体から見て極端に大きいレスポンス」を探す型です。データ持ち出しの検知などに使えます。

データの形が変わる

コマンドを覚えても書けるようにならない人が、ほぼ全員つまずくのがここです。逆にここを掴めば、クエリを自分で組み立てられるようになります。

9.1だから静かに空になる

この2つはどちらもエラーが出ません。結果が空か、列が全部空欄になるだけです。

stats の後で消えたフィールドを使っている
index=web
| stats count by status
| table _time, clientip, status, count

table の後で消えたフィールドで並べ替えている
index=web
| table uri, status
| sort 0 _time

9.2解決は2通り

①捨てる前に処理を済ませる。

index=web
| sort 0 _time          ← 先に並べる
| table uri, status     ← 見せる列は最後に決める

②集計の中で一緒に拾っておく。

index=web
| stats count, values(clientip) as 接続元, min(_time) as 初回 by status

9.3組み立ての型

ほとんどの調査クエリは、この4段階に収まります。迷ったらこの型に当てはめてください。

実践 — 1行ずつ組み立てる

10.1まず日本語で書く

SPL をいきなり書き始めないでください。やりたいことを日本語で書くと、そのまま構造になります。

第9章の4段階に割り当てます。

• 絞る — Web の index で、Apache のログのうちそのパスを含むもの
• 足す — 時刻を読める形にする
• 整える — 古い順に並べる
• 見せる — 時刻・ステータス・URL の3列

集計しない、というのがこの調査の性格です。攻撃の流れを追うときは、数を数えるより1件ずつ時系列で読むほうが分かります。

10.2ボタンで1行ずつ進める

各段階でデータの形がどう変わるかに注目してください。

10.3完成形

index=web sourcetype=access_combined "/uploads/sp-client-document-manager"
| eval time = strftime(_time, "%Y/%m/%d %H:%M:%S")
| sort 0 _time
| table time, status, uri

ハマりどころ

エラーが出れば直せます。厄介なのはエラーが出ないまま間違った結果が返るケースです。ここに挙げるのは全部そのタイプです。

11.1sort が1万件で黙って切れる

件数の多い調査では条件反射で 0 を書いてください。切り捨てられても何も表示されません。

11.2TYPE B の後で消えたフィールドを使う

結果が空になるか、列が全部空欄になります。結果が意味不明なときは、まず TYPE B のコマンドより前に戻して確認。

11.3フィールド名が環境で違う

本や記事のクエリが動かない原因の大半です。ベース検索だけ投げて、サイドバーで実際の名前を確認してからコピーしてください。

11.4_time と time を混同する

年月日の書式なら文字列順でも偶然そろいますが、%m/%d のような書式にした瞬間に順番が壊れます。

11.5where で文字列をクォートし忘れる

| where user = admin は admin というフィールドとの比較になります。そんなフィールドは無いので0件。エラーは出ません。

11.6絞り込みをパイプの後ろに書く

結果は同じですが遅くなります。ベース検索に書ける条件はベース検索に。

11.7時間範囲が前回のまま

時間ピッカーは設定が残ります。結果が多すぎる・遅すぎると感じたら、まずここを疑ってください。

11.8index を書き忘れる

全保管庫を横断するので、データ量の多い環境では数分待たされます。

脅威ハンティングで使う型

調査で繰り返し出てくる6つの型です。フィールド名を差し替えればそのまま使えます。

12.1環境に何があるか把握する

知らない環境を渡されたら最初に投げます。時間範囲は15分程度に絞ってください。

index=*
| stats count by index, sourcetype
| sort - count

12.2珍しいものを探す

ハンティングの基本発想です。正常な活動は大量に繰り返されるので、1〜2回しか出ていないものに異常が紛れます。

index=win sourcetype="WinEventLog:Security" EventCode=4688
| stats count, values(host) as ホスト by New_Process_Name
| sort count
| head 50

「全社で1台しか実行していないプロセス」が上に来ます。Web アクセスなら by uri、DNS なら by query に変えるだけです。

12.3起点の前後を時系列で読む

怪しい IP やホストが1つ見つかったら、そこを軸に周辺を洗います。第10章と同じ型です。

index=web clientip=40.80.148.42
| eval time = strftime(_time, "%H:%M:%S")
| sort 0 _time
| table time, method, uri, status, bytes

12.41つの主体がやったことを1行にまとめる

「この IP は結局どこにアクセスしたのか」を一望する型。values() が効きます。

index=web sourcetype=access_combined
| stats count,
        dc(uri) as URL種類数,
        values(status) as ステータス,
        min(_time) as 初回,
        max(_time) as 最終
      by clientip
| eval 初回 = strftime(初回, "%m/%d %H:%M")
| eval 最終 = strftime(最終, "%m/%d %H:%M")
| sort - URL種類数

短時間に大量の URL を叩いている IP が上に来ます。スキャンや探索の痕跡が出る型です。

12.5時間ごとの推移を見る

index=web
| timechart span=1h count by status

深夜に跳ねている、平日と休日で形が違う、といった異常が視覚的に出ます。

12.6全体から外れたものを拾う

eventstats の出番です。「レスポンスサイズが全体平均から極端に外れているリクエスト」を探します。データ持ち出しの兆候を拾う型です。

index=web sourcetype=access_combined
| eventstats avg(bytes) as 平均, stdev(bytes) as 偏差
| where bytes > 平均 + 偏差 * 3
| eval time = strftime(_time, "%m/%d %H:%M")
| sort 0 - bytes
| table time, clientip, uri, bytes

練習問題

読むだけでは書けるようになりません。手で書いてから答えを開いてください。フィールド名は access_combined の標準的なものを使います。

index=web sourcetype=access_combined status=404

index=web sourcetype=access_combined status=404
| stats count by uri
| sort - count

index=web
| table uri, status
| sort 0 _time

index=web
| sort 0 _time
| table uri, status

index=web sourcetype=access_combined
| rex field=uri "(?<filename>[^/]+\.\w+)$"
| stats count by filename
| sort - count

index=web sourcetype=access_combined earliest=-24h
| stats dc(uri) as 種類数, count, min(_time) as 初回 by clientip
| eval 初回 = strftime(初回, "%m/%d %H:%M:%S")
| sort - 種類数

チートシートと練習環境

14.1コマンド早見表

14.2覚えておく6つのルール

1. 検索は3層。時間範囲 → ベース検索 → パイプ。
2. 絞れる条件はできるだけ上の層に、できるだけ左に。
3. コマンドは2種類。TYPE B（stats / table / top / timechart）は最後に置く。
4. sort には 0 を付ける。付けないと1万件で切れる。
5. 並べ替えは _time、表示は自分で作った文字列。
6. フィールド名は環境依存。書く前にサイドバーで確認する。

14.3練習環境

Splunk Enterprise の無償トライアル

公式サイトから落として自分の PC に入れられます。60日間はフル機能で、その後も無償ライセンスに切り替えて使い続けられます（1日あたりの取り込み量に上限あり）。

BOTS データセット

Splunk 公式が CC0 で公開している、実際の攻撃シナリオを含む演習用ログです。GitHub に置かれています。インデックス済みの形で配布されているので、無償ライセンスの取り込み量制限にも引っかかりません。

攻撃部分だけを抜き出した小さい版（attack-only）もあるので、ディスクが厳しければそちらから始められます。設問と解答も公式から入手できます。

進め方

1. index=botsv3 | stats count by sourcetype を投げて、何のログがあるか見る
2. 気になった sourcetype を1つ選び、素で検索してサイドバーのフィールド名を眺める
3. 第12章の型を、その sourcetype のフィールド名に差し替えて実行する
4. BOTS の設問を1問ずつ解く