Posted inSecurity

Linuxサーバーのランサムウェア対策：プロアクティブな保護、早期検知、データ復旧

Security tutorial - IT technology blog
Security tutorial - IT technology blog

LinuxのRansomware — もはや珍しい話ではない

10台以上のサーバーのセキュリティ監査をしていると、同じパターンが繰り返し見えてきます：SSHが弱いパスワードを使っている、素性不明のスクリプトをcronジョブで実行している、ちゃんとしたバックアッププランがない。実際にランサムウェアに攻撃されたとき、DevOpsチームは顔を見合わせるしかありませんでした — 復旧できるものが何もなかったのです。

LinuxはWindowsよりランサムウェアの被害が少ないと思っている方は多いです。確かに少ない — しかし免疫があるわけではありません。REvil、Cl0p、LockBitはいずれもLinuxサーバーを直接標的にするバージョンを持っています。問題は「攻撃されるかどうか」ではなく、「攻撃されたとき、チームは何を準備していたか」です。

防御アプローチの比較

アプローチ1：リアクティブ — 攻撃を受けてから対応

最もよく見かけるパターンです。サーバーが暗号化されてから慌てて解決策を探し、ベンダーに連絡し、身代金の支払いを検討する。IBM Cost of Data Breach Reportによると、ランサムウェアインシデントからの復旧には平均21日かかります — 規模によって$20万から数百万ドルの身代金は別として。このアプローチをとっているチームは、今すぐ変えてください。

アプローチ2：バックアップのみ — バックアップだけに頼る

バックアップは必要ですが、それだけでは不十分です。検知機能がなければ、ランサムウェアがいつ暗号化を始めたかわかりません。感染したサーバーにNASをマウントしていたケースで、NAS上の3TB分のデータも一緒に暗号化され、復元できるものが何もなくなった事例があります。クリーンなバックアップがあっても、侵入経路を塞がずに復元すれば、数日後にまた感染します。

アプローチ3：多層防御 — Defense-in-depth

システムのハードニング＋リアルタイム監視＋オフラインバックアップ＋対応プランを組み合わせます。初期セットアップに数時間かかりますが、インシデントが発生したとき、復旧時間が数週間から数時間に短縮できます。インターネットに公開しているサーバーには、このアプローチを推奨します。

各アプローチのメリット・デメリット

  • リアクティブ：セットアップ不要 — しかしダウンタイムは週単位、データが永久に失われる可能性があり、身代金を払っても鍵が返ってくる保証はない。
  • バックアップのみ：シンプルで導入しやすい — ただしオンラインでマウントされたバックアップも暗号化される恐れがあり、早期検知ができない。
  • 多層防御：早期検知、被害最小化、迅速な復旧 — 初期セットアップに数時間必要。時間コストは最大だが、被害コストは最小。

状況に応じたアプローチの選択

個人VPSや重要データの少ないステージングサーバーであれば、3-2-1バックアップと基本的な監視を組み合わせれば十分です。顧客データベース、ユーザーファイル、独自コードを持つ本番サーバーには、3つの層すべてが必要で、妥協はできません。

実装の優先順位：まずオフラインバックアップ（命綱）、次にハードニング、最後に検知。すべてを一度にやる必要はありません — 週に一つずつ進めるだけで、リスクを大幅に減らせます。

実装ガイド：3層の防御

レイヤー1：ハードニング — 攻撃面を最初から最小化

ランサムウェアはたいてい3つの経路から侵入します：SSHブルートフォース、未修正のWebの脆弱性、cronジョブの悪意あるスクリプト。入口を塞ぐことが最も効果的な対策です。

SSHパスワード認証を無効化し、鍵認証のみ使用：

# sshd_configを編集
sudo nano /etc/ssh/sshd_config

# 以下の行を変更：
PasswordAuthentication no
PermitRootLogin no
Port 2222

sudo systemctl restart sshd

fail2banをインストールしてブルートフォース攻撃をブロック：

sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# jail.localに追加：
[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 86400
findtime = 600

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

/tmpと/var/tmpをnoexecでマウント — 一時ディレクトリからのマルウェア実行を防止：

# /etc/fstabに追加
tmpfs /tmp     tmpfs defaults,noexec,nosuid,nodev 0 0
tmpfs /var/tmp tmpfs defaults,noexec,nosuid,nodev 0 0

# 再起動なしですぐ適用
sudo mount -o remount,noexec,nosuid /tmp
sudo mount -o remount,noexec,nosuid /var/tmp

レイヤー2：検知 — 被害が拡大する前に早期発見

幸いなことに、ランサムウェアはかなり明確な痕跡を残します：大量のファイルが見慣れない拡張子（.encrypted、.locked）に変わる、CPUが突然スパイクする、深夜3時にディスクI/Oが急上昇する。このシグナルをタイムリーに捉えることで、被害がシステム全体に広がる前に食い止められます。

不審なファイル拡張子を検知するスクリプト：

#!/bin/bash
# /usr/local/bin/ransomware-detector.sh

WATCH_DIRS="/var/www /home /etc"
SUSPICIOUS_EXT="\.encrypted$|\.locked$|\.crypt$|\.enc$|\.WNCRY$"
THRESHOLD=10
ALERT_EMAIL="[email protected]"

for dir in $WATCH_DIRS; do
    count=$(find "$dir" -newer /tmp/.ransomware_check -type f 2>/dev/null \
            | grep -E "$SUSPICIOUS_EXT" | wc -l)
    
    if [ "$count" -gt "$THRESHOLD" ]; then
        msg="ALERT: $dir で $count 件のファイルが暗号化されました ($(date))"
        echo "$msg" | mail -s "RANSOMWARE ALERT: $(hostname)" "$ALERT_EMAIL"
        logger -t ransomware-detector "$msg"
        # オプション：即座にネットワークを隔離
        # iptables -I INPUT -j DROP && iptables -I OUTPUT -j DROP
    fi
done

touch /tmp/.ransomware_check
# 5分ごとに実行
chmod +x /usr/local/bin/ransomware-detector.sh
echo "*/5 * * * * root /usr/local/bin/ransomware-detector.sh" \
    | sudo tee /etc/cron.d/ransomware-monitor

auditdで重要ディレクトリの変更を監視：

sudo apt install auditd -y
sudo systemctl enable --now auditd

# WebディレクトリとHomeディレクトリを監視
sudo auditctl -w /var/www -p wa -k ransomware_watch
sudo auditctl -w /home -p wa -k ransomware_watch

# リアルタイムでログを確認
sudo ausearch -k ransomware_watch --start recent | tail -30

レイヤー3：オフラインバックアップ — すべてが失敗したときの命綱

生存の鉄則：バックアップはオフラインまたはイミュータブルでなければなりません。感染したサーバーにマウントされたバックアップは同様に暗号化されます — 前述のNASが暗号化された事例がその典型例です。同じ過ちを二度繰り返す必要はありません。

BorgBackup — 暗号化・重複排除対応で最も効率的：

sudo apt install borgbackup -y

# 別のバックアップサーバーにリポジトリを初期化
borg init --encryption=repokey \
    backup-user@backup-server:/backups/$(hostname)

# 日次バックアップスクリプト
borg create --stats --compression lz4 \
    backup-user@backup-server:/backups/$(hostname)::backup-{now:%Y%m%d_%H%M} \
    /var/www /home /etc /var/lib/mysql

# 日次7世代、週次4世代、月次6世代を保持
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 \
    backup-user@backup-server:/backups/$(hostname)

# バックアップ一覧を表示
borg list backup-user@backup-server:/backups/$(hostname)
# スナップショットから特定ファイルを復元
borg extract \
    backup-user@backup-server:/backups/$(hostname)::backup-20250601_030000 \
    var/www/html/wp-config.php
# crontabに追加 — 毎朝3時に実行
echo "0 3 * * * root /usr/local/bin/borg-backup.sh >> /var/log/borg-backup.log 2>&1" \
    | sudo tee /etc/cron.d/borg-backup

インシデント対応プラン — 攻撃を受けたとき

どれだけ防御を固めていても、対応シナリオは必要です。最初の15分が被害の範囲を決定します — 適切に対処すれば数台のサーバーで食い止められますが、誤った対処をすればインフラ全体に広がります。

  1. 即座に隔離：サーバーをネットワークから切り離す。電源は落とさないこと — RAMダンプがフォレンジックに必要になる場合がある。
  2. 被害範囲の特定：どのファイルが暗号化されたか？いつ？侵入経路はどこか？
  3. 身代金を払わない：鍵が返ってくる保証はない。FBIは支払わないよう勧告しており、Cybereasonによると身代金を支払った被害者の80%が1年以内に再び攻撃されている。
  4. 最もクリーンなスナップショットから復元：感染前のバックアップを選ぶ。
  5. サーバーを復帰させる前に脆弱性を修正：侵入経路を見つけて塞ぐ。修正しなければ、数日後にまた感染する。
# 最近変更されたファイルを確認
find /var/www /home -newer /tmp/.last_check -type f \
    | grep -v ".log$" | head -50

# 不審なプロセスを確認
ps aux --sort=-%cpu | head -20

# 不審なネットワーク接続を確認
ss -tunap | grep ESTABLISHED | grep -v "127.0.0.1\|::1"

まとめ

バックアッププランがなかったためにランサムウェア後の復旧に1週間かかったチームを見てきました。別のチームは、BorgBackupのスナップショットが準備されていたおかげで、同様のインシデントを4時間で処理しました。違いはツールや予算ではなく、早い段階でプロセスをセットアップしているかどうかです。

今すぐ始める3ステップ：SSHパスワード認証を無効化する、別サーバーにBorgBackupをセットアップする、検知スクリプトをcronに追加する。それだけで — 画面中が.encryptedファイルだらけになる恐怖を経験せずに済みます。

Share:
Tags: