現場のエンジニア諸君、ようこそ。今日は「メモリフォレンジック」という、泥臭いが避けては通れない、インシデントレスポンスの最前線について話そう。
世の中のセキュリティ教育では「ログを保存せよ」と教えるが、プロの攻撃者はログを改ざんし、あるいはログを残さない「ファイルレス攻撃」を好む。彼らの痕跡が唯一、そして鮮明に残る場所。それがメモリ（RAM）だ。
なぜ「メモリ」なのか？ Order of Volatilityの現実
インシデント発生時、焦って電源を落とすエンジニアが後を絶たない。それは、犯人の指紋を自ら消し去るのと同じだ。
「揮発性の順序（Order of Volatility）」という概念を知っているか？ RFC 3227でも定義されているが、要は「消えやすいものから順に確保せよ」という鉄則だ。ディスク（SSD/HDD）は後回しでいい。ネットワーク状態、メモリ上の実行プロセス、そしてメモリダンプ。これらを先にとらなければ、攻撃者がメモリ内で展開した難読化されたシェルコードや、復号されたパスワード、常駐しているバックドアの「正体」は永久に闇の中だ。
攻撃者の狙い：メモリ上での「見えない」生存
攻撃者は、ディスク上にファイルを作成しない「ファイルレス攻撃」を仕掛けてくる。例えば、PHPの脆弱性を突き、eval()関数等でメモリ上にのみ存在するスクリプトを実行する手法だ。
PoC：メモリ上で完結するバックドアの悪夢
攻撃者は、ウェブサーバーの脆弱性を悪用して、以下のようにメモリ上にだけ存在するペイロードを送り込む。
<?php
// 本来は難読化されているが、メモリ上では展開される
// ファイルシステムには一切痕跡を残さない
$cmd = $_GET['cmd'];
if ($cmd) {
// exec等はログに残るリスクがあるため、
// メモリ内で直接実行するラッパーや、隠蔽されたプロセス制御を行う
system($cmd);
}
?>ディスクをスキャンしても何も出てこない。だが、メモリをダンプして Volatility Framework 等で解析すれば、system()を呼び出している不審なプロセスや、見慣れないソケット通信が一発で露呈する。
実装で防ぐ：インメモリ・バックドアへの対抗策
「メモリフォレンジック」を必要とする事態を招かないための、最も堅牢な防御策は、そもそも攻撃者が「メモリ上で何かを動かす隙」を与えないことだ。
1. PHP/Webアプリケーションのセキュア設定
eval() や system() などの関数を無効化するのは鉄則だ。php.ini での制御は必須となる。
; php.ini での制限設定
; 危険な関数の無効化。これだけで多くの攻撃の芽を摘める
disable_functions = eval,system,exec,passthru,shell_exec,proc_open,popen,curl_multi_exec
; リモートからのファイルインクルードを禁止
allow_url_fopen = Off
allow_url_include = Off2. WAFによる「異常なリクエスト」の遮断
メモリ上でペイロードを展開させないためには、WAF（AWS WAF等）で不審な文字列を弾く必要がある。
/* AWS WAF: SQLi/XSS/Command Injection 対策のルール例 */
{
"Name": "Block-Command-Injection",
"Statement": {
"ByteMatchStatement": {
"SearchString": "base64_decode",
"FieldToMatch": { "QueryString": {} },
"TextTransformations": [{ "Priority": 0, "Type": "URL_DECODE" }]
}
},
"Action": { "Block": {} }
}3. メモリの安全を守るための「最小権限の原則」
ウェブサーバープロセス（www-data等）が、メモリ上で実行できる権限を最小限に絞る。Dockerコンテナであれば、ReadOnly ファイルシステムと、no-new-privileges フラグを付与するのが現代のスタンダードだ。
# docker-compose.yml の例
services:
web:
image: my-secure-app:latest
read_only: true # ファイルシステムへの書き込みを禁止
cap_drop:
- ALL # すべての特権を剥奪
security_opt:
- no-new-privileges:true # 新規権限昇格の防止最後に：エンジニアとしての心得
メモリフォレンジックは、攻撃者が残した「最後の吐息」を捕まえる作業だ。万が一、インシデントが発生した際、君たちがすべきは、慌ててシャットダウンすることではなく、ライブレスポンス（メモリダンプの取得）を行うことだ。
LiME や DumpIt といったツールを使い、まずはメモリという「動く証拠」を確保する。これができるか否かで、君が会社を救えるか、あるいは証拠隠滅を許してしまうかが決まる。
明日から、自分のサーバーで php.ini の設定を見直し、メモリの健全性を意識した設計を心がけてほしい。それが、プロのエンジニアとしての最低限のたしなみだ。何か不明点があればいつでも聞いてくれ。現場からは以上だ。
コメント