本番環境からコンパイラを排除せよ：攻撃者の「武器庫」を解体する極意
現場でインシデント対応をしていると、侵入を許したサーバーの中で必ずと言っていいほど目にする光景がある。それは、Webシェルがアップロードされた後のディレクトリで、攻撃者がせっせと gcc を回してエクスプロイトコードをビルドしている姿だ。
多くのエンジニアは「本番環境にソースコードを置かないから大丈夫」と高を括るが、それは甘い。攻撃者は侵入した環境にツールがないと分かれば、スクリプト言語で動く自作ツールを持ち込むか、あるいは環境内の既存ライブラリを悪用する。しかし、標的環境に gcc や make、ld といったビルドツールが残っていれば、彼らはその場でOSの脆弱性に合わせた実行ファイルをビルドし、権限昇格を完遂する。
本日は、攻撃者の「武器庫」を本番環境から物理的に撤去するための、泥臭くも確実なハーデニング術を伝授しよう。
—
1. なぜ「ツール削除」が最強の防壁なのか
攻撃者が侵入した際、最初に行うのは「環境偵察（Enumeration）」だ。カーネルバージョンを確認し、対応するエクスプロイトコード（例えば Dirty COW や PwnKit 等）をインターネットから落とし、その場でコンパイルする。
もし、サーバー上に gcc が存在しなければ？
攻撃者は「コンパイル環境がない」という壁にぶつかり、攻撃手法の変更を余儀なくされる。この「一瞬の足止め」こそが、EDRやログ監視が異常を検知する貴重な時間稼ぎになる。セキュリティとは、100%防ぐことではなく、攻撃者のコストを跳ね上げ、検知の網にかかる確率を高めるゲームなのだ。
—
2. Linux環境における「不要ツールの根絶」
Debian/Ubuntu系、RHEL系を問わず、本番環境のサーバーには以下のパッケージは不要だ。デプロイメントパイプライン（CI/CD）が正常に機能しているなら、これらはすべてビルドサーバーに押し込めばいい。
削除すべきパッケージリスト
gcc,g++,make,autoconf,automakebinutils(ld, nm, stripなどを含むため極めて危険)git,svn(ソースコードの持ち出しやクローンを防ぐ)
実行コマンド例（Debian/Ubuntu）:
# 依存関係も含めて削除を試みる
# 運用のCI/CDに影響がないことをステージング環境で必ず確認すること
sudo apt-get purge -y gcc g++ make binutils git
sudo apt-get autoremove -y—
3. 【実務的対策】実行権限の制限と堅牢化
ツールを消すだけでなく、OSレベルで「実行」そのものを制限するアプローチも併用する。特に /tmp や /dev/shm といった、書き込み可能な領域での実行権限を剥奪するのは鉄則だ。
NginxやPHP環境で「実行権限」を封じる（fstabの修正）
/etc/fstab を編集し、一時ディレクトリに noexec オプションを付与することで、仮にバイナリを配置されても実行を阻止できる。
# /etc/fstab の設定例
# /tmp を noexec でマウントし、実行ファイルが動かないようにする
tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev 0 0PHPからの実行を封じる（php.ini）
アプリケーション層からのシステムコマンド実行を物理的に封じる設定だ。
; php.ini
; 攻撃者のWebシェルが最も多用する関数を無効化する
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec—
4. CI/CDの設計思想を変える
「本番環境にコンパイラを置かない」という運用は、実は開発の質を上げる。なぜなら、「動く環境でビルドする」という場当たり的な運用を強制的に排除できるからだ。
CI/CDサーバー（JenkinsやGitHub Actionsなど）でビルドを行い、成果物（バイナリや静的ファイル）だけをデプロイする。このパイプラインを守るため、以下のIAMポリシーの考え方を徹底してほしい。
AWS IAM Policyのベストプラクティス（イメージ）:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:RunInstances"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalTag/Role": "CI-CD-Runner"
}
}
}
]
}*※これは「CI/CD以外の役割を持つIAMユーザーやインスタンスが、勝手に開発環境を構築したりツールをインストールしたりするのを防ぐ」という防衛線の一例だ。*
—
最後に：エンジニアへのメッセージ
「不便になるから」といってツールを残すのは、攻撃者に「どうぞ私のサーバーで存分に悪事を働いてください」と招待状を送っているのと同じだ。
真の要塞化とは、「本来あるべき状態」を維持し、それ以外を容赦なく切り捨てることにある。 今すぐ本番環境のサーバーにログインし、which gcc を打ってみてほしい。もしパスが返ってくるようなら、それはあなたが次に担当する「インシデント対応」の伏線かもしれない。
明日の朝、君の手でそのサーバーの不要な武器を解体しておくことを強く勧める。セキュリティは、コードを一行書くよりも先に、こうした泥臭い「環境の掃除」から始まるのだから。
コメント