Posted inSecurity

サーバー侵害の検出と対処：実践的なステップバイステップガイド

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

自分のサーバーが深夜に SSH ブルートフォース攻撃を受けたことがあります。auth.log を確認すると、海外の IP アドレスから数万回ものログイン試行が記録されており、心臓が飛び出しそうになりました。ポートを変更してキー認証を使っていたおかげで、攻撃者はまだ侵入できていませんでした。それ以来、受動的な防御だけでなく、不正侵入を検出する方法を真剣に学ぶようになりました。

この記事では実践的な内容に直接踏み込みます。サーバーが攻撃を受けているかどうかを把握する方法、調査に使うツール、そして実際にハックされた場合の正しい対処手順を解説します。

サーバー侵害検出手法の比較

主なアプローチは3つあり、シンプルなものから複雑なものへと続きます：

方法1：手動チェック

Linux コマンドを手動で実行し、システムログ、実行中のプロセス、現在のネットワーク接続を確認します。追加インストール不要で、疑いが生じた際にすぐ実行できます。重要なポイント：異常を検出するには、サーバーの「通常状態」を把握しておく必要があります。

方法2：ルートキットスキャナーと監査ツール

rkhunter、chkrootkit、Lynis などのツールは、既知の悪意あるパターンのリストに基づいてシステムを自動スキャンします。手動よりも多くの問題を検出できますが、誤検知（フォールスポジティブ）が発生してノイズになる場合があります。

方法3：リアルタイム IDS/モニタリング

Fail2ban、OSSEC、Wazuh はまったく異なるアプローチを取ります。24/7 継続的に監視し、自動対応します。IP のブロックやイベント発生時の即時アラート送信を行います。本番環境に最適ですが、セットアップとルールのチューニングに手間がかかります。

長所・短所の分析

手動チェック

  • メリット：追加インストール不要、何が起きているか正確に把握できる、ツールのフォールスネガティブの影響を受けない
  • デメリット：時間がかかる、出力を読むには経験が必要、攻撃者がログを削除したりルートキットでプロセスを隠したりすると見落としやすい

ルートキットスキャナー

  • メリット：自動化、一般的なルートキットを多数検出可能、定期実行のスケジュール設定が可能
  • デメリット：ゼロデイは検出できない、データベースの定期更新が必要、lwp-request や Perl モジュールなどのパッケージ追加後に誤検知が頻発する

リアルタイム IDS/モニタリング

  • メリット：即時検出、自動ブロック、事後調査のための完全な監査証跡の保存
  • デメリット：セットアップと管理が複雑、サーバーリソースを消費、誤検知を減らすためのルールチューニングが必要

状況に応じた手法の選択

よく遭遇する3つのシナリオ — それぞれ異なるアプローチが必要です：

  • 今まさに攻撃を受けている疑いがあるサーバー：まず手動チェックを実施 — 5分以内に全体像を把握できる最速の方法
  • 毎週定期的に監査したい：rkhunter または Lynis を cron で実行し、結果をメールで送信するよう設定
  • 重要な本番サーバー：今すぐ最低限 Fail2ban をデプロイし、運用リソースがあれば OSSEC/Wazuh の追加も検討

実際には3つすべてを組み合わせています。異常なアラートが発生した時は手動チェック、rkhunter を週次の cron でスキャン、Fail2ban は 24/7 稼働。シンプルですが、個人サーバーや中小企業（SMB）向けには十分です。

ステップバイステップ実装ガイド

ステップ1：不正侵害が疑われる場合の迅速チェックリスト

数分で状況を把握するため、すぐに以下のコマンドを実行してください：

# 現在サーバーにログインしているユーザーを確認
who
w

# 最近のログイン履歴 — 成功と失敗の両方
last -n 20
lastb -n 20

# CPU/RAM を異常に消費しているプロセス
ps aux --sort=-%cpu | head -20
ps aux --sort=-%mem | head -20

# 現在のネットワーク接続 — 不審な IP を探す
ss -tnp

# システムディレクトリで過去7日間に変更されたファイル
find /etc /bin /usr/bin /sbin /usr/sbin -mtime -7 -type f 2>/dev/null

注意すべきサイン：見覚えのない奇妙な名前のプロセス、80/443/22以外のポートで外部 IP への接続、または見知らぬユーザーがログインしている場合。

# SSH ログを確認 — ブルートフォースと成功したログインをチェック
grep "Failed password" /var/log/auth.log | tail -50
grep "Accepted" /var/log/auth.log | tail -20

# 全ユーザーの crontab を確認 — マルウェアが cron バックドアをインストールすることがある
for user in $(cut -f1 -d: /etc/passwd); do
  echo "=== $user ==="
  crontab -u $user -l 2>/dev/null
done

# 不審な authorized_keys を確認 — 攻撃者が自分の鍵を設置することがある
find /home /root -name "authorized_keys" -exec echo "--- {} ---" \; -exec cat {} \;

ステップ2：rkhunter と chkrootkit でルートキットをスキャン

# インストール
apt install rkhunter chkrootkit -y  # Ubuntu/Debian
yum install rkhunter chkrootkit -y  # CentOS/RHEL

# スキャン前にデータベースを更新
rkhunter --update

# システム全体をスキャン、各ステップの確認をスキップ
rkhunter --check --sk

# chkrootkit でクロスチェック
chkrootkit

Warning と表示されている出力部分をよく読みましょう — ただし、すぐにパニックになる必要はありません。rkhunter は Perl モジュールや /usr/bin/lwp-request についての誤検知がよく発生します。ハックされたと結論付ける前に、各 warning を個別に検索して確認してください。

ステップ3：Lynis で包括的な監査

apt install lynis -y

# システム全体の監査を実行
lynis audit system

# 出力には3つの重要なセクションがある：
# - Hardening index: 総合セキュリティスコア（高いほど良い）
# - Warnings: すぐに対処が必要な問題
# - Suggestions: スコアを上げるための推奨事項

ステップ4：侵害確認後の隔離と対処

侵入が確認されましたか？この順序に従って実行してください — ステップを省略しないこと：

4.1. 即座にサーバーを隔離：

# 自分の IP 以外のすべての受信をブロック（YOUR_IP を実際の IP に置き換える）
iptables -I INPUT -s YOUR_IP -j ACCEPT
iptables -I INPUT -j DROP

# または ufw を使用
ufw default deny incoming
ufw allow from YOUR_IP
ufw enable

4.2. クリーンアップ前に証拠を収集：

TIMESTAMP=$(date +%s)
ps aux > /tmp/evidence-ps-$TIMESTAMP.txt
ss -tnp > /tmp/evidence-ss-$TIMESTAMP.txt
cp /var/log/auth.log /tmp/evidence-auth-$TIMESTAMP.log
crontab -l > /tmp/evidence-cron-root-$TIMESTAMP.txt

4.3. 悪意あるプロセスを終了してバックドアを削除：

# PID でプロセスを終了（上の ps aux コマンドで取得した PID を使用）
kill -9 PID_CUA_TIEN_TRINH_LA

# シェルログイン可能な全ユーザーのパスワードを変更
grep -v '/nologin\|/false' /etc/passwd
passwd root
passwd ten_user_khac

# 使用していないユーザーをロック
usermod -L username_khong_dung

# 不審な SSH 鍵を削除 — 各ファイルを開いて見覚えのない行を削除
nano /root/.ssh/authorized_keys
nano /home/your_user/.ssh/authorized_keys

ステップ5：将来の防御のために Fail2ban をセットアップ

apt install fail2ban -y

# ローカル設定ファイルを作成（アップデート時の上書きを防ぐため元の .conf は編集しない）
cat > /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true
port    = ssh
EOF

systemctl enable fail2ban
systemctl start fail2ban

# 現在 ban されている IP を確認
fail2ban-client status sshd

Fail2ban を有効にしてから、毎日約50〜150の IP アドレスが SSH ブルートフォースだけで自動的にbanされているのが確認できます。すべてボットで、実際のユーザーには一切影響ありません。Fail2ban 以外に、新しいサーバーを構築した直後に必ず行う2つのこと：

# SSH パスワード認証を無効化 — キー認証のみ許可
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd

# デフォルト SSH ポートを変更（自動スキャナーからのノイズを90%削減できる）
sed -i 's/^#*Port.*/Port 2222/' /etc/ssh/sshd_config
systemctl restart sshd

実践的な結論

ハッカーはあなたの特定のサーバーを狙っているわけではありません。自動スキャナーを使って何百万もの IP アドレスを一度にスキャンしています。サーバーが侵害されるのは主にハードニング不足が原因であり、特定のターゲットとして選ばれているわけではありません。午前2時に SSH ブルートフォースへの対応に追われた夜は、非常に実践的な教訓を与えてくれました：最初からセキュリティをセットアップするのに30分、インシデント後の対応には丸一日かかり、データを失う可能性もあります。

現在使用している手順：Fail2ban をバックグラウンドで24/7稼働させ、rkhunter を cron で週次スキャン。異常なアラートを受け取ったら、他のことをする前にまずステップ1のチェックリストを実行します。複雑なインフラなしで、ほとんどの個人サーバーや中小企業のサーバーに十分対応できます。

Share:
Tags: