こんにちは！インシデントレスポンスの世界へようこそ。
システムを管理していて、ある日突然画面が真っ暗になり、あるいはパニックを起こしてフリーズしてしまう……想像しただけでも冷や汗が流れますよね。
「サーバーがクラッシュした！」となると、どうしても「ハードウェアの故障かな？」とか「プログラムのバグかな？」と考えがちですが、セキュリティの現場では、「もしかして、巧妙なサイバー攻撃者がシステムの中枢（カーネル）を乗っ取ろうとして、失敗した結果のクラッシュ（自爆）ではないか？」という疑いを持って調査を始めます。
今回は、そんなLinuxの心臓部が突然止まったときに残される遺言、通称 vmcore（カーネルダンプ）を読み解く「メモリフォレンジック」の世界へ、一緒に一歩ずつ足を踏み入れてみましょう！
—
1. 家の鍵に例える「カーネルパニック」と「vmcore」
まず、Linuxの仕組みをすごく身近なものに例えてみますね。
LinuxのOSの中心には、「カーネル」と呼ばれる最高権限を持った番人がいます。この番人は、メモリやハードウェアへのアクセスをすべて管理している、いわば「お家の金庫番」です。
通常、外からの泥棒（マルウェアや不正なプログラム）がこの金庫番を言いくるめようとしても、セキュリティ機能が「何をするんですか！」と追い返してくれます。
しかし、時々、非常に凶悪な泥棒が、金庫番の隙を突いてメモリのルールをめちゃくちゃに書き換えようとすることがあります。
ここでLinuxのすごいところは、金庫番が「あ、やばい！このままじゃ家全体が乗っ取り返される！」と察知した瞬間、わざと自分からシステム全体を急停止（カーネルパニック）させるんです。泥棒に好き勝手されるくらいなら、家全体のブレーカーを落としてしまえ、という最後の防衛策ですね。
この「パニックを起こして倒れ込む瞬間、金庫番が自分の脳みそ（メモリの中身）をノートにメモして机の上に残した状態」が、今回主役にする vmcore（ダンプファイル）というわけです。
—
2. なぜ kdump を仕込んでおく必要があるのか？
突然サーバーがプツンと切れたとき、何も準備をしていないと「あれ？ なんか落ちたな……再起動しよっと」で終わってしまいます。これでは、泥棒が入った痕跡も、犯人の足跡もすべて消えてしまいますよね。
そこであらかじめ準備しておくのが kdump という仕組みです。
kdump は、万が一のパニックに備えて、メモリの一部を「緊急避難用の特別スペース」として普段からこっそり確保しておく防犯カメラのようなものです。
メインのシステムが「うわっ、やられた！」と倒れ込んだ瞬間、この kdump が裏でサッと起動して、メインのメモリに何が起きていたのかをそっくりそのままハードディスクに保存（ダンプ）してくれます。
kdumpの簡単な設定を見てみましょう
実際のインフラ現場では、この kdump がきちんと有効化されているかが、インシデントレスポンスの成否を分けます。設定ファイル（通常は /etc/kdump.conf など）を覗いてみましょう。
# /etc/kdump.conf の設定例
# クラッシュした際に、vmcoreをどこに保存するかを指定します
path /var/crash
# メモリの何MBを緊急避難用にあらかじめ予約しておくか（例：512MB確保する場合）
# サーバーの総メモリ量に合わせて調整します
core_collector makedumpfile -c --message-level 1 -d 31このように、あらかじめ「落ちたときの証拠を残す箱」を用意しておくことが、セキュリティ運用の第一歩になります。
—
3. crash ユーティリティで「脳みそ」を覗き見する
さて、無事に vmcore という証拠品（ダンプファイル）が手に入りました。しかし、このファイルはただの巨大なバイデータの塊です。人間の目でそのまま読んでも、ただの暗号にしか見えません。
そこで登場するのが、crash ユーティリティという専用の虫眼鏡です。これを使うと、クラッシュした瞬間のメモリの隅々まで覗き見ることができます。
実際に調査を行う際のコマンドの雰囲気を見てみましょう。
# crashユーティリティを使って、カーネルのシンボルファイルとvmcoreを読み込みます
# ※解析には、クラッシュしたときと同じバージョンのカーネルパッケージ(kernel-debuginfo等)が必要です
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/127.0.0.1-2023-10-25-10:00:00/vmcore無事に crash が起動すると、専用のプロンプト（crash>）が表示されます。ここからがアナリストの腕の見せ所です。
—
4. 現場で使える！怪しい痕跡を見つけるための基本コマンド
crash の中に入ったら、次のようなコマンドを使って「何が原因でパニックが起きたのか」を探っていきます。
① まずは「誰が最後に暴れたか」を見る
パニックを引き起こした直接の原因（どのCPUで、どのプロセスが暴走したか）を確認します。
crash> btbt（Backtrace）コマンドを使うと、クラッシュしたスレッドの関数呼び出し履歴（足跡）が上から順に表示されます。- もし、見たこともないサードパーティ製のカーネルモジュールや、メモリー破壊を示すようなおかしな関数名が並んでいたら……そこが怪しい容疑者（マルウェアや脆弱性を突いたコード）の足跡です。
② メモリの破壊状況を確認する
攻撃者がバッファオーバーフローなどの手法を使ってメモリを書き換えた場合、特定のデータ構造が破壊されていることがあります。
# タスク（プロセス）のリストを表示して、おかしな動きをしているものがないか探す
crash> ps
# 特定のアドレスのメモリ内容を16進数でダンプして確認する
crash> rd 0xffff98810234a000 32こうした地道な解析を通じて、「あ、このプロセスは本来触ってはいけないカーネルの領域を書き換えようとして、番人（カーネル）に検知され、パニックに至ったんだな」というストーリーを組み立てていくわけです。
—
まとめ：一歩ずつ、確実な備えを
今回は、カーネルパニックと vmcore、そして crash ユーティリティを使ったメモリフォレンジックの基本を、お家の防衛に例えてお話ししました。
「なんだか難しそう……」と感じたかもしれませんが、安心してください。インシデントレスポンスのプロたちも、最初はみんな「サーバーが落ちた、どうしよう！」というパニックから始まっています。
大切なのは、
1. 万が一のときに備えて kdump をきちんと有効にしておくこと
2. いざというときに vmcore という証拠を回収できるようにしておくこと
この2つを日頃から意識しておくことです。
システムが発する「最後のSOS」を読み解けるようになると、セキュリティのスキルがぐっと広がりますよ。ぜひ、ご自身の環境でも設定や仕組みを確認してみてくださいね。一歩ずつ、一緒に学んでいきましょう！
コメント