「カーネルは聖域である」：Linuxのモジュールロードを封じ込め、ルートキットを無力化せよ
現場でインシデント対応をしていると、侵入者がOSを掌握した後に必ず行う「お決まりの儀式」がある。それが、悪意あるカーネルモジュール（LKM: Loadable Kernel Module）の注入だ。
一度カーネルに潜り込まれたら、psコマンドやnetstatコマンドの結果すら改ざんされる。システム管理者が何をどう調べても、攻撃者は「見えない存在」として居座り続ける。これがルートキットの恐ろしさだ。
今回は、この「OSの最後の砦」を物理的に守るための、極めて実務的な要塞化手法を伝授する。教科書的な「不要なサービスを止めろ」という助言の、その先の話だ。
—
なぜカーネルモジュール読み込み制限が必要なのか
攻撃者は通常、Webアプリケーションの脆弱性（RCE等）を突いて一般ユーザー権限で侵入した後、権限昇格を狙う。彼らにとって、カーネルモジュールを読み込める環境は、OSの心臓部を直接書き換える「魔法の杖」だ。
特にコンテナ環境や仮想サーバーであっても、カーネルがホストと共有されている場合、一箇所の脆弱性がクラウドインフラ全体の崩壊を招く。これを防ぐ唯一の防御策が、カーネルレベルでの「モジュール読み込みの恒久的な停止」である。
—
実装：カーネルモジュールのロードを封じ込める
Linuxにおいて、一度起動してしまえば、sysctlを使ってモジュール読み込みを禁止できる。しかし、それでは「再起動時に攻撃者が解除してしまう」というリスクが残る。我々が目指すのは、「起動直後からモジュールを一切受け付けない」という強固な設定だ。
1. sysctl による動的制限（まずはここから）
システム稼働中に、即座にモジュール読み込みを遮断する設定だ。
# /etc/sysctl.d/99-kernel-hardening.conf に以下の設定を追加
# カーネルモジュールのロードを禁止する
kernel.modules_disabled = 1
# 設定を反映
sysctl -p /etc/sysctl.d/99-kernel-hardening.conf一度 kernel.modules_disabled を 1 に設定すると、システムを再起動するまで元に戻すことはできない。これがセキュリティの「不変性」だ。
—
運用上の「盲点」：なぜコンテナ環境では注意が必要か
ここで一つ、現場の知見を共有しておく。Dockerコンテナなどで運用する場合、ホスト側のカーネルパラメータを変更すると、全コンテナに影響が及ぶ。
例えば、アプリケーションが必要とする iptables のモジュールなどが後からロードできなくなり、サービスが突然死する事故がよくある。「必要なモジュールは起動時に読み込み、その後即座にロックする」という運用フローを徹底すること。
—
実装サンプル：Pythonによるカーネルパラメータ監査ツール
インフラ担当者が「本当に要塞化できているか」をCI/CDパイプラインや監視エージェントでチェックするためのコードを置いておく。これを定期的に実行するだけで、誰かが設定をいじっていないか即座に検知できる。
import os
def check_kernel_hardening():
"""
カーネルモジュールのロードが制限されているか確認する。
本番環境の監視エージェントとして利用することを想定。
"""
path = "/proc/sys/kernel/modules_disabled"
try:
with open(path, 'r') as f:
status = f.read().strip()
if status == '1':
print("[OK] カーネルモジュールのロードは無効化されています。")
return True
else:
print("[ALERT] 警告: カーネルモジュールのロードが許可されています！")
return False
except FileNotFoundError:
print("[ERROR] カーネルパラメータが見つかりません。OSを確認してください。")
return False
if __name__ == "__main__":
# セキュリティチェック実行
if not check_kernel_hardening():
# ここでSlack通知やPagerDutyへのアラートを飛ばす運用を推奨
exit(1)—
最高セキュリティ責任者からの提言
多くのエンジニアが「WAFを入れれば大丈夫」「パッチを当てれば終わり」と考えがちだが、OSのカーネルという「足元」が揺らいでいれば、その上のレイヤーでどれだけ強固な盾を構えても無意味だ。
今回の設定は、一度入れてしまえばメンテナンスの手間はほとんどない。しかし、「導入時に依存関係を破壊する可能性がある」というリスクがある。必ずステージング環境で十分に検証し、必要なモジュール（br_netfilter や overlay など）がロードされていることを確認した上で、本番のロックをかけてほしい。
セキュリティとは、完璧を目指すことではなく、攻撃者の「最短ルート」を一つずつ消していく泥臭い作業の積み重ねである。今日、この設定を一行加えるだけで、君たちのインフラは格段に硬くなるはずだ。
健闘を祈る。
コメント