こんにちは！インフラやセキュリティの世界へようこそ。
初めてサーバーに触れるとき、「何から手をつければいいんだろう？」と途方に暮れてしまいますよね。セキュリティの対策と言われると、なんだか難解な暗号や、見たこともない専門用語の壁にぶつかって圧倒されてしまうかもしれません。
でも、一歩ずつ仕組みを紐解いていけば大丈夫です。今回は、Linuxサーバーの心臓部を守るための「カーネルモジュールの読み込み制限」について、身近な防犯の例えを交えながら優しく解説していきますね。
一緒に、堅牢なサーバーを作る第一歩を踏み出していきましょう！
—
家の鍵と「合鍵を勝手に作られる」リスクに例えてみよう
突然ですが、あなたが大切にしている自宅の玄関を思い浮かべてみてください。普段はしっかり鍵をかけて、信頼できる家族以外は入れないようにしていますよね。
では、もし「家に勝手に入り込んだ泥棒が、こっそり合鍵メーカーを持ち込んで、自分専用の合鍵を自由自在に作れてしまったらどうなるでしょうか？」
……想像しただけでゾッとしますよね。一度合鍵を作られてしまえば、泥棒はいつでも、あなたの留守中に自由に出入りできるようになり、しかもあなたがそれに気づくのは極めて難しくなります。
これとまったく同じことが、Linuxサーバーの内部でも起こり得るのです。
Linuxの「合鍵工房」が狙われる理由
Linuxサーバーの根っこ（一番大事な中枢部分）には、「カーネル（Kernel）」と呼ばれる、すべてのハードウェアやソフトウェアを統括する最高責任者のようなプログラムが鎮座しています。
そしてLinuxには、このカーネルの機能を後から自由に追加・拡張するための「カーネルモジュール」という仕組みが備わっています。通常は、新しいハードウェアをつなげたときなどに、必要なプログラム（ドライバなど）を「モジュール」として読み込ませて使います。これはとても便利な機能です。
しかし、もしサーバーが何らかの攻撃を受けて侵入されてしまったとき、悪いハッカー（攻撃者）がこの仕組みを悪用するとどうなるでしょうか？
彼らはinsmodやmodprobeというコマンド（いわば、モジュールを読み込ませるための工具です）を使って、「自分たちの存在を完全に隠し、システムを裏から牛耳るための悪意あるプログラム（ルートキット）」を、カーネルの中に直接組み込んでしまうのです。
これが成功してしまうと、サーバーのOSが持つすべての権限が奪われ、どんなに優秀なセキュリティソフトを入れても、改ざんされたカーネルが「すべて正常です」と嘘をつくため、侵入に気づくことができなくなってしまいます。
だからこそ、「侵入されたとしても、カーネルという聖域に勝手に合鍵（モジュール）を作らせないようにする」という強力なバリケードが必要になるのです。これが、今回学ぶ「カーネルモジュールの読み込み制限」の目的です。
—
カーネルモジュールの読み込みを制限する仕組み
では、具体的にどうやってこの「勝手な合鍵作り」を防ぐのでしょうか？
Linuxには、一度サーバーが起動してしまえば、「もうこれ以上、新しいモジュールを後から追加するな！」とカーネルに厳命する素晴らしい機能が備わっています。
それが、 /proc/sys/kernel/modules_disabled という特殊なスイッチです。
このスイッチを「1」に切り替えておくと、サーバーの起動直後や特定のタイミング以降、insmodやmodprobeを使って外から新しいモジュールをロードしようとしても、カーネルが「申し訳ありませんが、現在はセキュリティポリシーにより新しいモジュールの追加は禁止されています」と門前払いしてくれるようになります。
普段の運用では、必要なハードウェアのドライバなどは最初から読み込ませておき、サーバーが動き出した後は「もう追加の拡張は不要！」とフタをしてしまう。これが、現場のエンジニアが実践する鉄壁の要塞化（ハーデニング）のテクニックです。
—
実践！設定ファイルを書く手順とコード例
それでは、実際にこの制限をかける手順を見ていきましょう。
「難しそう……」と思うかもしれませんが、設定自体はとてもシンプルです。一緒に手を動かしていきましょう！
ステップ1: 一時的な動作確認（手動での設定）
まずは、現在のサーバーでモジュールの読み込みがどうなっているかを確認し、一時的に制限をかけてみます。サーバーのターミナルを開き、管理者権限（root）で以下のコマンドを叩いてみてください。
# 現在の状態を確認する（「0」であれば、まだ制限されておらず追加できる状態）
cat /proc/sys/kernel/modules_disabled
# 制限を有効にする（「1」を書き込むことで、以降のモジュール追加を禁止する）
echo 1 > /proc/sys/kernel/modules_disabledこれで、この瞬間から新しいカーネルモジュールの読み込みがブロックされるようになります。
ステップ2: サーバーを再起動しても消えない設定にする
ただし、上記のやり方だとサーバーを再起動したときに設定がリセットされてしまいます。実務では、サーバーが万が一再起動しても自動でこの制限がかかるように、設定ファイルに書き込んでおく必要があります。
システムの設定を管理する /etc/sysctl.conf というファイルに、ルールを追記していきましょう。
お好きなテキストエディタ（ここではnanoを使います）で設定ファイルを開きます。
sudo nano /etc/sysctl.confファイルの最下行などに、以下の1行を書き加えて保存してください。
# セキュリティ強化: カーネルモジュールの動的ロードを禁止する
# これにより、システム稼働後に悪意あるモジュールが勝手にロードされるのを防ぎます
kernel.modules_disabled = 1ファイルを保存したら、設定をすぐに反映させるために以下のコマンドを実行します。
# /etc/sysctl.conf の内容をシステムに再読み込みさせる
sudo sysctl -pこれで、設定が永続化され、いつでも安全な状態が保たれるようになります！
—
現場で気をつけるべき「注意点」と心構え
ここまで読んで、「じゃあ、すべてのサーバーで今すぐこの設定を有効にしよう！」と思ったあなた、素晴らしい着眼点です。しかし、ベテランのインフラエンジニアとして、現場で気をつけるべき大切なポイントを一つだけお伝えしておきますね。
それは、「この設定を入れると、後から必要なドライバや仮想化の機能を追加できなくなる」ということです。
例えば、
- 後から新しいNIC（ネットワークカード）や外付けデバイスを認識させたいとき
- Dockerなどのコンテナ技術や、特定の仮想化支援機能を後から有効にしたいとき
これらはすべて、カーネルモジュールの読み込みを必要とする場合があります。そのため、
1. 「サーバーの初期構築（プロビジョニング）が終わって、必要なモジュールが出揃った段階で最後にこの設定をかける」
2. 「クラウド環境などで、あらかじめビルド済みのカーネルを使用しており、後からモジュールを追加する予定が一切ないことを確認する」
という手順を踏むのが、実務における安全な進め方になります。
—
まとめ
今回は、Linuxにおけるカーネルモジュールの読み込み制限について、家の鍵や合鍵の例えを交えながら解説しました。
- 攻撃のメカニズム: 侵入されたサーバーで、攻撃者は
insmodやmodprobeを使って悪意ある「合鍵（ルートキット）」をカーネルに作ろうとする。 - 防御の仕組み:
/proc/sys/kernel/modules_disabledを有効化（1に設定）することで、稼働後のモジュール追加に硬いフタをする。 - 実務のポイント: 必要な初期設定がすべて終わった段階で適用し、システムの中枢をガッチリ守る。
セキュリティの世界は、こうした「当たり前の小さなフタ」を一つずつ確実に閉めていくことの積み重ねです。難しく考えず、まずは仕組みを面白がりながら、自分の手元の環境で試してみてくださいね。
あなたのエンジニアライフと、サーバーの安全を心から応援しています！
コメント