Linuxランサムウェア対策：「暗号化不可能」なサーバーの構築方法

Table of Contents

午前2時のアラート：ファイルが書き換えられ始めた時

火曜日の午前2時。PagerDutyのアラートでスマホが震えました。Grafanaを確認すると、ディスクI/Oが98%に張り付き、CPU使用率は100%に達しています。本番環境のサーバーにSSHでログインしようとするも、遅延がひどくて使い物になりません。Webルートディレクトリで ls -la を実行すると、そこには悪夢が広がっていました。 index.php.locked や config.php.crypt といったファイルが並び、一番上には README_FOR_DECRYPT.txt というテキストファイルが鎮座していたのです。

2018年、私は深夜にブルートフォース攻撃によってサーバーが破壊されるのを目の当たりにしました。それ以来、私はセキュリティに対して執着的になりました。ファイアウォール、SSHキー、Fail2Banも導入していました。しかし、現代のランサムウェアはより巧妙です。単に隙を突くだけでなく、家全体を人質に取ろうとします。もし暗号化された拡張子を目にしたなら、攻撃者はすでに境界を突破し、権限昇格を済ませています。彼らはすでに「内部」にいるのです。

根本的な原因：なぜLinuxサーバーは脆弱なのか

Linuxのランサムウェアが複雑なゼロデイ脆弱性に依存することは稀です。むしろ、驚くほど予測可能な経路を辿ります。始まりは脆弱なWordPressプラグインや、漏洩したAPIクレデンシャルです。そこから攻撃者は **PwnKit (CVE-2021-4034)** のような脆弱性を利用してroot権限を取得します。ひとたび sudo 権限を握れば、マウントポイントを巡回し、あらゆるデータベース、設定ファイル、メディアファイルを暗号化するスクリプトを実行します。

本当の災難は、ランサムウェアがバックアップを見つけた時に起こります。もしバックアップドライブがローカルパーティションや、書き込み権限のある単純なNFSシェアであれば、一瞬で消え去ります。スクリプトは数ミリ秒で見つけ出し、復旧の可能性をゼロにします。結果として、攻撃者からの高額な請求書だけが残ることになります。

防御戦略：基本的なバックアップから「不変の鎧」まで

多くのチームは、3つの方法のいずれかでLinuxのセキュリティを管理しています。しかし、そのすべてが標的型攻撃に耐えられるわけではありません。

標準的なローカルバックアップ（偽りの安心感）

多くの管理者は rsync を使ってデータを第2の内部ディスクにコピーしています。これはドライブの故障には有効ですが、ランサムウェアに対しては無力です。OSがディスクに書き込みを行えるなら、ランサムウェアも同様に書き込めるからです。理屈は単純です。

クラウドスナップショット（24時間の空白）

AWSのEBSスナップショットやDigitalOceanのバックアップは、OSの外部で管理されるため一歩前進です。しかし、ほとんどのチームは24時間に1回しかスナップショットを取得しません。トラフィックの多い環境では、23時間分の顧客データを失うことは、ビジネスの存続に関わる致命的な事態です。さらに、クラウドコンソール自体が侵害された場合、攻撃者は暗号化を開始する前にスナップショットを削除してしまうでしょう。

イミュータブル（不変）アプローチ（絶対的な防御）

これこそが、実際に機能する唯一の戦略です。システムレベルのハードニングを行って重要なファイルを凍結し、一定期間「削除」や「変更」コマンドを物理的に拒絶するオフサイトストレージを使用します。たとえ攻撃者が root になっても、彼らが勝つことはできません。

究極のランサムウェア防御設計図

安心して眠るためには、暗号化の試行に対して能動的に敵対する環境が必要です。

1. 不変属性によるファイルシステムの要塞化

Linuxでは、実は root ユーザーの行動すら制限できます。 chattr （属性変更）コマンドを使用すると、コアファイルに「不変（immutable）」ビットを立てることができます。これにより、スーパーユーザーであっても変更、削除、名前の変更ができなくなります。

# 重要なシステムファイルを凍結する
sudo chattr +i /etc/passwd
sudo chattr +i /etc/shadow
sudo chattr +i /etc/fstab

# これらを更新するには、まず手動でビットを解除する必要があります
# sudo chattr -i /etc/passwd

デプロイ後、私はアプリケーションのソースコード全体を不変に設定します。もしPHPの脆弱性を突いて攻撃者がコードを実行したとしても、 index.php を暗号化されたバージョンに書き換えることはできません。彼らのスクリプトは単に “Operation not permitted” （許可されていない操作）というエラーで失敗します。

2. Auditdによるリアルタイム監視

ランサムウェアは非常に「騒がしい」動きをします。わずか数秒の間に数千ものファイルにアクセスします。LinuxのAuditデーモン（ auditd ）を使えば、この挙動を監視できます。しきい値を超えた場合、ネットワークのキルスイッチを発動させます。

# auditdをインストール
sudo apt install auditd -y

# Webディレクトリの書き込みや属性変更を監視
sudo auditctl -w /var/www/html -p wa -k web_integrity

私は簡単なPythonスクリプトを使って /var/log/audit/audit.log を監視しています。機密性の高いディレクトリで1秒間に50回以上のファイル変更を検知した場合、自動的にネットワークインターフェースを落とします（ ip link set eth0 down ）。一時的にダウンタイムが発生しますが、データは守られます。

3. 不変のオフサイトバックアップの導入

これがセーフティネットになります。 **Restic** や **BorgBackup** を使い、WasabiやBackblaze B2のような「オブジェクトロック（Object Lock）」をサポートするS3互換バックエンドに転送します。コンプライアンスモードでアップロードされたバックアップは、保持期間（例：30日間）が経過するまで物理的に削除不可能です。

# S3互換バックエンドを使用したResticの例
export AWS_ACCESS_KEY_ID="アクセスキー"
export AWS_SECRET_ACCESS_KEY="シークレットキー"
export RESTIC_REPOSITORY="s3:s3.wasabisys.com/ロックされたバックアップ用バケット"
export RESTIC_PASSWORD="ボルトパスワード"

# バックアップを実行
restic backup /var/www/html /etc

# たとえ攻撃者がこれらのキーを盗んだとしても、データを削除することはできません。
# S3バケットは、ロック期限が切れるまで削除リクエストを拒否します。

復旧：数分でオンラインに戻る方法

最悪の事態が発生しても、感染したサーバーを修理しようとしてはいけません。不変のバックアップがあれば、復旧への道筋は明快です。

隔離: 影響を受けたVMの電源を即座に落とします。
再構築: クリーンなイメージから新しいOSインスタンスを起動します。感染したカーネルを信用してはいけません。
リストア: 不変のリポジトリからデータを引き出します。

# 最新のクリーンなスナップショットをプル
restic restore latest --target /

サーバーは一時的なもの（エフェメラル）として扱い、データは不変（イミュータブル）なものとして扱いましょう。ランサムウェアが勝つのは、こちらが「ノー」と言えない時だけです。ファイルレベルのハードニングとロックされたS3バケットがあれば、誰にroot権限を握られようとも、王国の鍵を守り続けることができます。