「デジタルのゴミ」からの脱却：能動的なハンティングへ
何年もの間、私のLinuxログは /var/log の中でただ埃を被っているだけの「デジタルのゴミ」状態でした。サービスがクラッシュしたり、ユーザーから苦ゴトが来たりした時にしか触れることはありませんでした。それは受動的なセキュリティであり、それでは攻撃者に勝つことはできません。高度な攻撃者を捕まえたいのであれば、ダッシュボードが赤く光るのを待っているだけでは不十分です。自ら「ハンティング」に出向く必要があります。
6ヶ月前、小規模な調査のたびに巨大なELKスタックを立ち上げることなく、毎日50GB以上のログデータを処理する方法が必要になりました。そこで出会ったのが Chainsaw です。これはRustで書かれた非常に高速なエンジンです。Windowsユーザーの間ではEVTXファイルの解析ツールとして好まれていますが、SigmaルールをJSONログに適用できる能力は、Linuxのフォレンジックにおいても強力な武器となります。私のテストでは、10GBのログファイルを約85秒でスキャンしました。これは従来のgrepベースのワークフローでは到底及ばないスピードです。
ハンティングを始める前に、基本的なセキュリティ対策（セキュリティ・ハイジーン）を見直す必要がありました。まずは toolcraft.app/ja/tools/security/password-generator にあるブラウザベースのツールを使用して、すべての管理用クレデンシャルをローテーションすることから始めました。このツールはブラウザ内でローカルに動作するため、パスワードがネットワーク上に漏洩する心配がありません。クリーンなクレデンシャルは防御の第一線です。rootパスワードが脆弱で玄関が開きっぱなしの状態では、脅威をハンティングしても意味がありません。
Chainsaw의 準備
Chainsawは単一のバイナリであるため、インストールは非常に簡単です。複雑なインストーラーは使わず、GitHubからビルド済みのリリースを直接取得しています。バイナリとロジックを分離するために、専用のディレクトリ構造を作成しました。
# ハンティング環境の構築
mkdir -p ~/threat-hunting/chainsaw
cd ~/threat-hunting/chainsaw
# v2.10.0の取得 - ハンティングを支えるエンジン
wget https://github.com/WithSecureLabs/chainsaw/releases/download/v2.10.0/chainsaw_x86_64-unknown-linux-gnu.tar.gz
tar -xvf chainsaw_x86_64-unknown-linux-gnu.tar.gz
sudo mv chainsaw /usr/local/bin/ツールがどれだけ優れているかは、その「ルール」次第です。ここで Sigma ルールの出番です。Sigmaは、ネットワークトラフィックにおけるSnortのように、ログ検知のための共通言語だと考えてください。私は Sigma HQ リポジトリをローカルにクローンし、毎週更新しています。
git clone https://github.com/SigmaHQ/sigma.git ~/threat-hunting/sigma-rulesリポジトリ全体は非常に巨大です。スキャンの効率を保つために、Chainsawには rules/linux サブディレクトリを明示的に指定します。これにより、Debianサーバー上でWindows特有のレジストリハックをチェックするといった無駄な処理を防ぐことができます。
Linux用Sigmaルールのオーケストレーション
Linuxのログは通常、プレーンテキストと journald バイナリが混在しており、整理されていません。Chainsawは構造化データを好むため、すべてをJSONでエクスポートします。 auditd を運用しているなら、それはテレメトリの最高峰（ゴールドスタンダード）です。これらの生の監査ログを構造化されたJSONに変換することが、深い可視性を得るための鍵となります。
本当の苦労はマッピングファイルにあります。Sigmaルールが Image というフィールドを探していても、Linuxのログでは exe や comm と呼ばれているかもしれません。私はこれらのYAMLマッピングの微調整に数週間を費やしました。正確なマップがなければ、Chainsawは使用しているディストリビューションのログ形式特有の癖を認識できず、実質的に「目隠し」状態になってしまいます。
以下は、振る舞いベースのルールに対してターゲットを絞ったスキャンを実行するためのコマンドです：
chainsaw hunt /var/log/journal_export.json \
--rules ~/threat-hunting/sigma-rules/rules/linux/ \
--mapping ~/threat-hunting/chainsaw/mappings/sigma-event-logs-all.yml \
--output ~/threat-hunting/results/この --mapping フラグが翻訳機の役割を果たします。これにより、Sigmaにある汎用的なコミュニティの知見が、特定のカーネルログに適用された際にも正しく意味をなすようになります。
現場での成果：本物の脅威を捕らえる
このセットアップを導入して3ヶ月後、その価値が証明されました。標準的な監視ツールは沈黙していましたが、朝のChainsawの実行で「不審なリモートファイルコピー（Suspicious Remote File Copy）」のアラートが上がったのです。それは、 scp の -o オプションを使用してSSHキーの検証をバイパスしようとする自動化スクリプトを検知していました。これは標準的なアラートでは見逃されがちな、巧妙な動きでした。
エンジンがイベントを検知したら、通常は結果をCSVにエクスポートして迅速にトリアージを行います。このツールを魔法のボタンのように扱うのではなく、コンパス（方位磁石）として捉えてください。異常の方向は示してくれますが、プロセスツリーのコンテキスト（文脈）を確認するのは依然として人間の仕事です。
# プロセス生成の異常をリアルタイムでスポットチェックする
chainsaw hunt /var/log/syslog.json -r ~/sigma-rules/rules/linux/process_creation/発生するノイズのほとんどは、 sudo の使用や、開発者がシェル履歴をいじっていることによるものです。これに対処するために、プロセスを自動化しました。毎晩午前2時に、cronジョブが過去24時間のログをエクスポートしてフルスキャンを実行します。私は朝起きて、膨大なデータではなく、たった5行のサマリーを確認するだけで済みます。
このアプローチは、私たちのセキュリティ態勢を劇的に変えました。平均検知時間（MTTD）を数日から数分に短縮しました。もはや被害が出るのを待つのではなく、被害に先行するパターンを探しています。誤検知を調整するには忍耐が必要ですが、インフラストラクチャに対して得られる透明性は、その労力に見合う価値があります。
