サーバーへの不審なログインを素早く検知・調査する実務手順

まず手を動かす：ログイン履歴を一覧で確認する

ログイン履歴の確認に最初に使うのは last コマンドです。一般ユーザー権限でも実行でき、接続元IPアドレス・接続日時・セッション時間がひと目でわかります。

# 直近20件のログイン履歴を表示
last -n 20

# ISO形式のタイムスタンプで表示（GNU拡張・タイムゾーンの確認に有効）
last -n 20 --time-format iso

出力の各列は左から「ユーザー名」「端末」「接続元IP」「ログイン日時」「ログアウト日時（またはstill logged in）」「在席時間」の順です。

alice    pts/1   203.0.113.45    Sat Aug  9 10:12   still logged in
bob      pts/0   192.168.1.10    Sat Aug  9 08:55 - 09:30  (00:35)
reboot   system  boot            Sat Aug  9 08:50
alice    pts/0   198.51.100.22   Fri Aug  8 23:42 - 00:10  (00:28)

still logged in は現在もセッションが続いていることを示します。reboot 行はシステム再起動のタイミングを表しており、「再起動前後でどのユーザーがいたか」という時系列の把握にも役立ちます。

不審なアクセスを見つけるための着眼点

出力を眺めるだけでなく、次の3点を意識すると異常に気づきやすくなります。

見慣れない接続元IPアドレス：社内IPや既知のVPNアドレス帯以外からのログインが混ざっていないか確認します。海外IPからの接続は特に要注意です。

深夜・早朝のアクセス：通常業務時間外のログインは、盗用した認証情報による不正アクセスで起きやすい傾向があります。

数秒で切れるセッションが大量にある：スクリプトによる自動攻撃の痕跡であるケースが多く、次項の lastb と合わせて確認します。

特定ユーザーだけに絞り込んで確認することもできます。

# 特定ユーザーの履歴のみ表示
last alice

# rootのログイン履歴を確認
last root

全ユーザーの最終ログイン日時を一括で把握する

「このユーザーは最後にいつログインしたか」を全アカウント分まとめて確認したい場合は lastlog を使います。退職者アカウントの棚卸しや、休眠アカウントの検出に特に効果的です。

# 全ユーザーの最終ログイン一覧
lastlog

# 出力例
Username         Port     From             Latest
root             pts/0    192.168.1.5      Sat Aug  9 08:00:01 +0900 2026
alice            pts/1    203.0.113.45     Sat Aug  9 10:12:33 +0900 2026
olduser                                   **Never logged in**

# 90日以上ログインのないユーザーだけ表示
lastlog -b 90

**Never logged in** と出るアカウントは一度もログインがありません。不要なアカウントはロック（sudo usermod -L ユーザー名）または削除を検討します。

認証失敗の記録を洗い出してブルートフォースを検知する

ログイン失敗の履歴は lastb コマンドで確認できます。root権限が必要ですが、SSH総当たり攻撃を受けているかどうかを手早く判断できます。

# ログイン失敗の履歴を表示（root権限が必要）
sudo lastb -n 30

# 出力例
root     ssh:notty    45.33.32.156     Sat Aug  9 03:21    gone - no logout
admin    ssh:notty    45.33.32.156     Sat Aug  9 03:21    gone - no logout
root     ssh:notty    185.220.101.23   Sat Aug  9 03:20    gone - no logout

同一IPから root や admin への試行が短時間に集中している場合、SSH総当たり攻撃を受けています。該当IPをファイアウォールで即時ブロックし、並行して fail2ban などの自動対応ツールの導入を検討します。

注意：lastb の記録ファイル /var/log/btmp はデフォルトで存在しないディストリビューションがあります。存在しない場合は以下で作成できます。

sudo touch /var/log/btmp
sudo chmod 600 /var/log/btmp

systemdジャーナルでSSH認証の詳細を追う

Ubuntu・Debian・Rocky Linux・AlmaLinuxなど現代的なディストリビューションでは、journalctl でSSH認証ログの詳細を確認できます。last では見えない「公開鍵認証の成否」や「セッション開始・終了の細かいタイムスタンプ」まで追えます。

# Ubuntu / Debian系（サービス名はssh）
sudo journalctl -u ssh -n 100 --no-pager

# Rocky Linux / AlmaLinux / RHEL系（サービス名はsshd）
sudo journalctl -u sshd -n 100 --no-pager

# 認証成功だけに絞り込む
sudo journalctl -u ssh --no-pager | grep "Accepted"

# 認証失敗だけに絞り込む
sudo journalctl -u ssh --no-pager | grep "Failed password"

# 特定日時範囲に絞って調査する
sudo journalctl -u ssh --since "2026-08-08 00:00:00" --until "2026-08-09 23:59:59" --no-pager

インシデントの時刻が絞り込めている場合は --since / --until を必ず使います。全件を流し読みするより格段に速く証跡を特定できます。

ログ記録ファイルの特性と証跡保全の注意点

last や lastb の情報源となるファイルはバイナリ形式です。cat で直接読もうとしても文字化けするだけなので、必ず専用コマンドを通じて参照します。各ファイルの役割は以下のとおりです。

/var/log/wtmp   # last の参照先。過去のログイン・ログアウト・再起動を記録
/var/run/utmp   # 現在ログイン中のユーザー情報（who コマンドの参照先）
/var/log/btmp   # lastb の参照先。認証失敗を記録

インシデント対応で見落としやすいのが、これらのファイルはrootが消去・改ざんできるという点です。侵入者がroot権限を取得していた場合、証跡をすでに消去している可能性があります。

対策として有効なのは、journald の永続化とリモートログの組み合わせです。/etc/systemd/journald.conf で Storage=persistent を設定するとジャーナルがディスクに残り、再起動後も参照できます。さらにリモートのsyslogサーバーや集中ログ管理基盤（Loki・Elasticsearchなど）に転送しておくことで、ローカルの証跡が消えても外部に記録が残ります。

ある情報系企業の運用現場では、last と journalctl を組み合わせたチェックスクリプトを週次で自動実行し、通常業務時間外や未知IPからのログインをSlackへ通知する仕組みを構築しています。ワンオフの目視確認だけでなく、定期モニタリングに組み込むことで不審なアクセスの早期発見精度が大きく上がります。