VPSのCPU使用率が突然100パーセントに張り付いた、クラウドサービスの月額請求が数万円に跳ね上がった、見覚えのない海外IPアドレスからSSHでログインされた通知が届いたなど、個人で運用しているサーバーの異変に気づいた瞬間は誰しも強い不安を覚えます。「今すぐサーバーを削除すべきか」「再起動して様子を見るべきか」と慌ててしまいがちですが、パニックに任せた操作を行うと、攻撃の侵入経路や被害実態を突き止めるための重要なログが失われてしまいます。
インターネット上に公開されているサーバーには、24時間365日、世界中からボットによるスキャンや辞書攻撃が絶え間なく到達しています。ここで重要なのは、「攻撃の試行（機械的スキャン）」と「侵入の成功（実際の侵害）」を冷静に切り分け、客観的な証拠に基づいて状況を正確に判断することです。
この記事では、個人運用サーバーやクラウド環境を対象とした不正アクセス調査シリーズの全体ハブとして、侵入の有無を切り分ける5大兆候、調査に不可欠な5大ログ領域の見方、技術的な調査限界、そしてパニック時に厳守すべき初動原則を体系的に解説します。
この記事で行うこと
- 不正アクセスの「試行」と「侵入成功」を正しく見極める侵害4段階モデルを理解する
- サーバーの異変を即座に察知する5大兆候を点検する
- Linuxおよびクラウド環境における5大ログ領域の役割と調査コマンドを把握する
- ログ調査における技術的な限界と注意点を理解する
- パニック時に絶対に避けるべきNG行動と安全な初動原則を確認する
- ご自身の運用環境に応じた個別詳細記事への最短ルートを把握する
前提条件・対象読者
- さくらのVPS、ConoHa、Linode、DigitalOceanなどのVPSや、AWS、Google Cloud等のクラウドでLinuxサーバーを運用している個人開発者・エンジニア
- サーバーの負荷異常、不審な通信、請求急増などに直面し、不正侵入の有無を白黒つけたい方
- Linuxの標準的なシェルコマンド（
grep、cat、journalctl、ss等）に関する基礎的な操作知識がある方 - 最終確認日：2026年11月（IPA「中小企業の情報セキュリティ対策ガイドライン 付録8」およびAWS・Google Cloud公式技術資料に準拠）
1. Quick Reference：不正アクセス調査の全体フロー早見表
まずは、不正アクセスの疑いが生じた際にどのような順序で何を確認すべきか、全体像を整理しました。
| フェーズ | 調査項目 | 主な確認場所・コマンド | 判断基準・注目ポイント |
|---|---|---|---|
| 第1段階（兆候確認） | 請求・リソースの異常 | クラウド請求画面、top、uptime | 身に覚えのない課金急増、CPU常時高負荷 |
| 第2段階（認証確認） | 不正ログインの有無 | last -F、/var/log/auth.log | 自分が接続していない日時のAccepted記録 |
| 第3段階（アカウント確認） | ユーザー・鍵の改ざん | /etc/passwd、~/.ssh/authorized_keys | 未知のUID 0ユーザー、見知らぬ公開鍵 |
| 第4段階（ネットワーク確認） | 不審な通信・待ち受け | ss -tulpn、lsof -i | 未知ポートのリッスン、海外不審IPとの接続 |
| 第5段階（プロセス確認） | 不正常駐・自動実行 | ps aux、/etc/cron*、systemctl | 難読化されたプロセス名、未知の定期実行 |
不正アクセス調査では、攻撃がどの段階まで進んでいるかを把握することが極めて重要です。攻撃の進行度合いは、以下の4段階に分類できます。
[攻撃の侵害4段階モデル]
段階1：偵察・侵入試行 ──> ポートスキャン、パスワード総当たり（日常茶飯事・侵入未遂）
│
段階2：侵入成功 ──> 脆弱性悪用や認証突破によりシェルの獲得に成功
│
段階3：権限昇格・常駐 ──> root権限奪取、バックドア設置、cron登録
│
段階4：実害発生 ──> 仮想通貨マイニング、DDoS加担、データ外部送信、踏み台化
2. 攻撃の侵害4段階：不正アクセスの「試行」と「侵入成功」を区別する
インターネットにLinuxサーバーを公開すると、数分もしないうちに世界中のIPアドレスからSSH接続試行が記録され始めます。ログに大量の接続エラーが残っているからといって、直ちに侵入されたと早合点してはいけません。
2-1. 段階1：偵察・侵入試行（Reconnaissance & Attempt）
公開サーバーに対して、攻撃ボットがポートスキャンを行ったり、root や admin といった典型的なユーザー名でパスワード認証を試みたりしている段階です。認証ログに Failed password が何千件並んでいても、すべて拒絶されていれば侵入は成立していません。この段階であれば、パスワード認証の無効化や接続元IP制限といった予防策で十分に対処可能です。
2-2. 段階2：侵入成功・初期足場（Initial Compromise）
攻撃者が脆弱性のあるWebアプリケーション（WordPressプラグイン等）を突いたり、漏洩したSSH鍵や弱い認証情報を利用して、サーバー内部へログインまたはコマンド実行に成功した段階です。認証ログに Accepted publickey や Accepted password が記録され、見覚えのない接続元IPアドレスが残ります。
2-3. 段階3：権限昇格・内部活動（Privilege Escalation & Persistence）
侵入に成功した攻撃者が、OSのローカル権限昇格脆弱性を突いて root 権限を奪取したり、再起動後も接続を維持できるようにバックドアを仕込む段階です。~/.ssh/authorized_keys への公開鍵追加、/etc/cron* や systemd サービスへの悪意あるスクリプト登録、未知の管理者ユーザー作成などが行われます。
2-4. 段階4：実害発生・目的達成（Impact）
攻撃者が最終的な目的を実行に移す段階です。代表的な被害には、CPUリソースを限界まで消費する暗号資産（仮想通貨）マイニングマルウェアの実行、外部サイトへのDDoS攻撃への加担、データベースや個人情報の外部持ち出し、他の内部ネットワークへの踏み台攻撃などがあります。クラウド環境では、高額なGPUインスタンスが大量に不正作成されて数十万円単位の請求が発生することもあります。
3. 最初に確認すべき5大兆候と一次切り分け
不正アクセスが疑われる場合、以下の5つの観点から順番に兆候の有無を確認します。
3-1. 兆候1：クラウド請求・利用料の異常急増
AWSやGoogle Cloud等のクラウドを利用している場合、最も早く異変を検知できるのが請求ダッシュボードです。普段は月数百円から数千円で推移している環境で、身に覚えのないGPUインスタンス（g4dn や a2 等）が複数リージョンで起動されたり、NATゲートウェイのデータ転送量が爆発的に増えている場合、アカウントの認証情報（IAMキー等）が窃取されて悪用されている可能性が極めて濃厚です。
3-2. 兆候2：身に覚えのないIPアドレスからのログイン成功履歴
サーバーのシェルにログインできる場合、過去のログイン成功履歴を直ちに確認します。以下のコマンドを実行します。
last -F -n 20
出力されるユーザー名、接続元IPアドレス、ログイン日時を確認します。自分がアクセスしていない時間帯や、契約プロバイダと異なる地域・海外のIPアドレスから still logged in（現在もログイン中）またはログイン完了の記録があれば、侵入成功の決定的な証拠となります。
3-3. 兆候3：未知のシステムユーザー・SSH公開鍵の追加
攻撃者は自身がいつでも再侵入できるように、新しい管理者アカウントを作成したり、既存ユーザーのSSH許可鍵リストに自身の鍵を追記します。
grep -E ':0:' /etc/passwd
cat ~/.ssh/authorized_keys
ls -la /home/*/.ssh/authorized_keys
UIDが 0（root権限同等）の未知のユーザーが定義されていないか、身に覚えのない公開鍵コメント（攻撃者のメールアドレスや自動生成された文字列）が追記されていないかを点検します。
3-4. 兆候4：不審なリソース・コンテナ・APIデプロイ
コンテナ環境を利用している場合、攻撃者は既製のマイニング用Dockerイメージを勝手にプルしてバックグラウンドで起動することが多々あります。
docker ps -a
見知らぬイメージ名（xmrig、monero、stratum等の文字列を含むものや、ランダムな英数字の名前）のコンテナが常時稼働していないかを確認します。クラウド環境では、普段利用していないリージョン（オハイオ、バージニア、フランクフルト等）に不審な仮想マシンが作成されていないかをコンソールで確認します。
3-5. 兆候5：CPU高負荷・未知の不審プロセス
サーバーの動作が極端に重い場合、プロセスの稼働状況を確認します。
top -b -n 1 | head -n 20
ps aux --sort=-%cpu | head -n 10
CPU使用率を90パーセント以上占有しているプロセスがないか、/tmp や /dev/shm、/var/tmp などの一時ディレクトリから直接実行されているバイナリがないかを確認します。攻撃者はプロセス名を systemd や kworker など正規のOSプロセスに偽装することがあるため、実行ファイルのパス（ls -l /proc/<PID>/exe）まで確認することが重要です。
4. サーバー・クラウドにおける5大ログ領域の役割と見方
不正アクセスの全容を解明するためには、OS内部からクラウド基盤まで、多層的なログを突き合わせる必要があります。主要な5大ログ領域とそれぞれの役割は以下の通りです。
4-1. 領域1：OS認証ログ（Authentication Log）
OSへのログイン試行、特権昇格（sudo）、認証成功・失敗のすべてを記録する最も基本となるログです。
Debian・Ubuntu環境
- ファイルパス:
/var/log/auth.logまたはjournalctl -u ssh - 確認コマンド:
grep -E "Accepted|Failed" /var/log/auth.log | tail -n 30
RHEL・Rocky Linux・AlmaLinux環境
- ファイルパス:
/var/log/secure - 確認コマンド:
grep -E "Accepted|Failed" /var/log/secure | tail -n 30
Accepted password または Accepted publickey の直後に続くIPアドレスとポート番号、対象ユーザー名をリストアップし、自身の正当なアクセス履歴と突き合わせます。
4-2. 領域2：Webサーバー・リバースプロキシログ
Webサーバー（Nginx、Apache、Caddy等）を運用している場合、外部からの脆弱性スキャンや攻撃リクエストが記録されます。
Nginxの例
- アクセスログ:
/var/log/nginx/access.log - エラーログ:
/var/log/nginx/error.log
攻撃者は環境変数ファイル（.env）、設定ファイル（wp-config.php）、Gitメタデータ（/.git/HEAD）、PHP脆弱性（phpinfo.php）などを探索する大量のHTTPリクエストを送信します。ステータスコード 200 で不正なリクエストが返っていないか、Webシェル（不審な .php ファイル等）がアップロードされて実行されていないかを調べます。
4-3. 領域3：OSシステムログ・サービスログ
OSの起動・停止、カーネルメッセージ、デーモンの稼働状況を記録するログです。
- システムログ:
/var/log/syslogまたは/var/log/messages - カーネルログ:
dmesg -T - systemdログ:
journalctl -xe
マルウェアがセグメンテーション違反でクラッシュした記録、カーネルモジュール（ルートキット）のロード警告、予期せぬサービスの自動登録などを追跡できます。
4-4. 領域4：クラウド監査ログ（Cloud Audit Logs）
AWSやGoogle Cloud等のパブリッククラウドにおいて、OSの外側（クラウドAPI基盤）で行われた操作履歴を記録するログです。
AWSの場合
- サービス名: AWS CloudTrail
- 調査対象: イベント履歴（Event history）、
CreateUser、CreateAccessKey、RunInstances、AuthorizeSecurityGroupIngress
Google Cloudの場合
- サービス名: Cloud Audit Logs（Cloud Logging内）
- 調査対象:
protoPayload.methodName（例:v1.compute.instances.insert、SetIamPolicy）
攻撃者がクラウドのコンソールやCLIのアクセスキーを不正取得した場合、OSのログには何も残さずに外部から新しい仮想マシンを起動したり、セキュリティグループを開放したりします。OS内部の調査だけでなく、クラウド監査ログの確認が必須となる理由がここにあります。
4-5. 領域5：ネットワーク・フローログ
サーバーを出入りするパケットのメタデータ（送信元IP、宛先IP、ポート番号、パケット数、アクション）を記録するログです。
- Linuxローカル:
netstat -antpまたはss -tulpn（現在の接続状態） - クラウド基盤: AWS VPCフローログ、Google Cloud VPCフローログ
OS上のログファイルが攻撃者によって消去されていても、クラウドの仮想ネットワーク基盤に記録されたVPCフローログはOS内部から消去できません。未知の海外IPアドレス宛に大量のデータが送信されている場合、情報の外部持ち出しやDDoS攻撃への加担が客観的に証明されます。
5. 調査で確認できること・確認できないこと（調査の限界）
ログ調査は強力な武器ですが、万能ではありません。調査に着手する前に、「何がわかり、何がわからないのか」の技術的限界を正しく認識しておく必要があります。
5-1. 調査で確認できること
- 正常に保存されているログファイルに記載された接続元IPアドレス、アクセス日時、実行コマンド
- 調査時点で稼働しているプロセスのPID、親プロセス、オープンしているファイルディスクリプタ
- クラウド基盤側（CloudTrail、VPCフローログ等）で記録された、OS外側のAPI呼び出しおよび通信パケット量
- 攻撃者が残したバックドアファイル、追加されたSSH公開鍵、変更された設定ファイルの差分
5-2. 調査で確認できないこと（技術的限界）
root権限奪取後のローカルログ改ざん
攻撃者が完全な root 権限を獲得した場合、/var/log/ 配下のログファイルを編集・削除したり、シェル履歴（~/.bash_history）を消去することが容易に可能です。改ざんされた形跡がある場合、ローカルログ単体から真実を復元することはできません。
揮発性メモリ（RAM）上の痕跡
ディスクにファイルを書き込まず、メモリ上にのみ展開されるファイルレスマルウェアの場合、サーバーを再起動またはシャットダウンすると痕跡が完全に消失します。
ログのローテーションと保存期間
多くのLinux環境では、logrotate により数週間から1ヶ月程度で古いログが自動削除されます。数ヶ月前に侵入されて長期間潜伏されていた場合、侵入初期のログが残っていないケースがあります。
改ざんされた標準コマンドの出力
高機能なルートキットが組み込まれた場合、ps、ls、netstat などのOSコマンド自体が細工され、悪意あるプロセスやファイルが意図的に画面から隠蔽されることがあります。
6. パニック時のNG行動と初動の鉄則
不正アクセスの証拠を発見した際、焦りから誤った対応をとると、状況を悪化させたり復旧を不可能にしてしまいます。
6-1. やってはいけない3大NG行動
NG行動1：慌ててサーバーインスタンスを削除・初期化する
「怖いから今すぐ消そう」とサーバーを破棄してしまうと、侵入経路、漏洩したデータの範囲、悪用された原因が永遠に闇の中となります。同じ脆弱性を残したまま新サーバーを構築すれば、数日以内に再び同じ被害に遭います。
NG行動2：安易にOSを再起動する
再起動を行うと、メモリ上に常駐していた不正プロセスの痕跡、ネットワーク接続状態、削除されたファイルのファイル記述子がすべて消去されます。
NG行動3：不審なプロセスを単発でkillする
攻撃者は多くの場合、プロセスが停止したことを検知して再生成するスクリプトやcronジョブを仕込んでいます。単発でプロセスを終了させると、攻撃者に調査開始を気づかれ、証拠隠滅のスクリプトを一斉実行される危険があります。
6-2. 守るべき初動の3大原則
原則1：スナップショットを取得して証拠を固定する
何かの変更を加える前に、クラウドやVPSの管理画面からディスク全体の「スナップショット（複製）」を取得します。これにより、調査で誤って状態を変えてしまっても、侵入直後の状態をいつでも再現できます。
原則2：ネットワークを遮断（隔離）する
OS内部を操作するのではなく、クラウドのセキュリティグループやVPSのパケットフィルタ機能を使い、外部との通信（インバウンド・アウトバウンド双方）を全遮断します。管理用の自分自身の固定IPアドレスのみを許可するか、管理コンソール（VNCコンソールやシリアルコンソール）経由の接続に切り替えます。
原則3：認証情報を即座に無効化・ローテーションする
サーバーで使用していたSSH鍵、データベース接続パスワード、APIキー、クラウド管理コンソールのパスワードをすべて安全な別環境から変更・失効させます。
7. クラウド・VPS別：専用詳細記事へのナビゲーション
不正アクセスの調査と対策は、利用しているプラットフォームの特性によって具体的な手順や確認画面が異なります。ご自身の運用形態に合わせて、以下の詳細解説記事をご活用ください。
- 個人クラウドのセキュリティ対策｜不正アクセスを防ぐ設定と月次点検チェックリスト：侵入を未然に防ぎ早期検知するための恒久対策と点検表
- 個人サーバーの不正アクセス初動対応｜証拠保全・通信遮断・認証失効から復旧まで：侵入発覚直後の最初の30分初動フローと公的機関への相談基準
よくある質問（FAQ）
Q1. SSHの認証失敗（Failed password）が毎日数千件記録されていますが、侵入されているのでしょうか？
直ちに侵入されているわけではありません。インターネット上の公開IPアドレスに対しては、世界中の攻撃ボットが無差別にパスワード総当たり攻撃（ブルートフォースアタック）を行っています。重要なのは、ログの中に Accepted（認証成功）が存在しないかどうかです。Failed のみであれば侵入は防げていますが、安全性を高めるためにパスワード認証を禁止し、SSH公開鍵認証またはポート変更、接続元IP制限の導入を強く推奨します。
Q2. ログファイルがすでに消去されている形跡がある場合、どうすればよいですか？
攻撃者が侵入後に history -c やログ削除を行った場合、OS内部のテキストファイルから追跡することは困難です。ただし、クラウド環境であれば上位のクラウド基盤ログ（AWS CloudTrail、VPCフローログ、Google Cloud Audit Logs等）にOS外側の記録が残っています。また、ディスクのスナップショットを取得した上で、フォレンジックツールを用いた削除ファイルのカービング（復元）を試みる手法があります。
Q3. 個人が趣味で動かしているサーバーでも、警察や公的機関への相談は必要ですか？
実害の性質によります。単にサーバー内部で不審なプロセスが動いていただけの段階であれば、サーバーの隔離と再構築で自己解決するケースが一般的です。しかし、自身のサーバーが大規模なDDoS攻撃の踏み台にされて他社に損害を与えている場合や、管理していた他者の個人データ（ブログ読者のメールアドレス等）が流出した疑いがある場合、または身代金要求などの金銭被害が生じている場合は、IPA（情報処理推進機構）の「情報セキュリティ安心相談窓口」や各都道府県警察のサイバー犯罪相談窓口への相談を検討してください。
まとめ
個人運用サーバーやクラウド環境における不正アクセス調査は、恐怖心から焦って行動するのではなく、客観的な事実とログを積み重ねて冷静に状況を切り分けることが鉄則です。
- 攻撃の4段階を区別する: 日常的なスキャン（試行）とシェルの奪取（侵入成功）を混同しない。
- 5大兆候を素早く点検する: 請求急増、未知のログイン成功、新規ユーザー、不審コンテナ、CPU高負荷を確認する。
- 多層的なログを突き合わせる: OS認証ログだけでなく、Webアクセスログ、クラウド監査ログ、ネットワークフローログを網羅する。
- 調査の限界を把握する: root権限奪取後のローカルログ改ざんやメモリ揮発性の制約を理解しておく。
- パニック時のNG行動を避ける: 慌ててサーバーを削除・再起動せず、スナップショット取得とネットワーク遮断を最優先する。
- 再発防止と月次点検を定着させる: 調査完了後は原因となった脆弱性を特定し、MFA強制や最小権限による恒久対策を実施する。
本記事の全体フローを起点として、まずは現状のサーバーで何が起きているのかを落ち着いて特定してください。
次に読むおすすめ記事
個人で運用するサーバーやWebサービスの総合的なセキュリティ対策、多要素認証や端末保護の全体像については、以下の完全ガイドもあわせて参考にしてください。
また、日頃の予防設定や月次点検表、有事の際の緊急初動手順は以下の関連記事で詳しく解説しています。
