サーバーへの不正アクセスが疑われる場合の初動対応

[更新:2026年08月26日]

VPSの利用中に、不正アクセスや不審な挙動に気づいた場合の初動対応について記載します。
契約直後に実施しておくべき予防的なセキュリティ設定については サーバー作成直後に設定しておくべき初期セキュリティ設定 をご確認ください。

Note

本ドキュメントは、さくらのVPSの標準OS(Ubuntu 24.04)がインストールされているサーバーが対象です。 他のディストリビューションをご利用の場合、コマンドやログファイルのパスを適宜読み替えてください。

該当する状況

  • 身に覚えのないプロセスやログインセッションがある

  • サーバーの動作が急に重くなった、見慣れない通信が発生している

  • 第三者から「あなたのサーバーから攻撃を受けた」と連絡があった

  • ログインパスワードやSSH秘密鍵が漏えいした可能性がある

対応方法

Step1. 兆候を確認する

まず、実際に不正な兆候があるかどうかを確認します。以下のコマンドは、SSHで接続した状態で実行してください。

ログイン履歴を確認する

ログイン成功履歴・失敗履歴を確認する場合
$ last -n 20
$ sudo lastb -n 20

Note

lastb には、心当たりのないユーザー名やIPアドレスからのログイン試行が記録されることがあります。 ただし、インターネットに公開されているサーバーには、契約直後から国内外の第三者による総当たり的なログイン試行が日常的に発生します。 lastb に記録があること自体は珍しくないため、「試行があったか」ではなく「実際にログインに成功した形跡があるか」を last 側で確認することが重要です。

実行中のプロセスを確認する

実行中のプロセスを一覧表示する場合
$ ps aux

見覚えのないプロセス、特にランダムな名前の実行ファイルや /tmp 配下から起動しているプロセスがないか確認してください。

ネットワーク接続を確認する

現在の通信状況を確認する場合
$ sudo ss -tunap

LISTEN 状態のポートのうち、自分が設定した覚えのないものがないか、ESTAB (確立済み接続) のうち見覚えのない接続先がないかを確認します。

認証ログを確認する

認証ログを確認する場合
$ sudo tail -n 200 /var/log/auth.log

Accepted password や Accepted publickey の行から、実際にログインに成功した記録を洗い出します。

cronジョブを確認する

自ユーザー・rootのcronジョブを確認する場合
$ crontab -l
$ sudo crontab -l -u root

心当たりのないジョブが登録されていないか確認してください。不正アクセス後、定期的に不正なプログラムを再実行する目的でcronに登録されるケースがあります。

Step2. 被害の拡大を防ぐ

不審な形跡が見つかった場合、まず被害の拡大を防ぐことを優先します。

ネットワークアクセスを制限する

さくらのVPSの パケットフィルター で、SSHの接続元IPアドレスを自分の環境に限定するか、状況によっては一時的に全ての通信を遮断することを検討してください。

Note

パケットフィルターを無効化すると、既存のルール設定は失われます。再度有効化する際は空の状態から設定し直す必要があるため、一時的な遮断が目的の場合は、無効化ではなくルールの変更で対応することを推奨します。

警告

接続元IPアドレスを制限する際、自分自身の現在の接続元IPアドレスを正しく確認してから設定してください。 誤ったIPアドレスを設定すると、SSH・コントロールパネル経由の操作両方で自分自身がアクセスできなくなる可能性があります。 コンソールからの復旧手段( コンソール )を確保した上で作業することを推奨します。

不審なプロセスを停止する

Step1で見つかった不審なプロセスは、原因調査の前に安易に停止すると証拠が失われる場合があります。緊急性が高い場合(外部への攻撃が継続している、リソースを大量に消費している等)を除き、次のStepで証拠を保全してから対応することを検討してください。

Step3. 認証情報を一新する

不正ログインの形跡が確認された場合、認証情報はすべて漏えいした前提で対応します。

  • SSHの秘密鍵を再作成し、authorized_keys を新しい公開鍵に入れ替える

  • パスワード認証を利用している場合は、パスワードを変更する(推奨される文字数等は サーバー作成直後に設定しておくべき初期セキュリティ設定 を参照)

  • サーバー上で管理していたその他の認証情報(データベースのパスワード、APIキー、Webアプリケーションの管理画面のパスワード等)もあわせて見直してください

警告

既存の authorized_keys を削除する前に、新しい鍵で実際にログインできることを必ず確認してください。確認前に削除すると、サーバーにアクセスできなくなります。

Step4. 証拠を保全する

原因究明や、必要に応じた第三者への報告のために、現在の状態をできる範囲で記録しておきます。

  • Step1で確認したコマンドの出力を、ファイルに保存しておく

  • 可能であれば、ディスクの状態をスナップショットやバックアップとして保全しておく

  • 侵入されたサーバー上のログは改ざんされている可能性があるため、疑わしい場合は結果を過信せず、次のStepの再構築も検討する

Step5. サーバーを復旧する

不正アクセスの侵入経路や被害範囲が完全に特定できない場合、サーバー内部からの調査だけで「安全になった」と判断するのは困難です。 最も確実な復旧方法は、 OS再インストール によってサーバーをクリーンな状態に戻すことです。

再インストール後は、以下を必ず実施してください。

第三者への影響を確認する

サーバーが不正アクセスの踏み台として悪用され、他のサーバーへの攻撃やスパム送信に利用されていた可能性がある場合、影響を受けた第三者への対応や、状況によっては警察への相談も検討してください。 踏み台として悪用された形跡がある場合は、サポート窓口までご連絡ください。