サーバーのログイン履歴を確認して不審アクセスを素早く見抜く手順

「先週末に誰かサーバーへ入ったか確認したい」「深夜帯に不審なSSHアクセスがなかったか調べたい」——そうした場面でまず実行すべきコマンドはこれです。

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

これだけで、いつ・誰が・どこから・どの端末でログインしたかが一覧できます。セッションが継続中なら still logged in、終了済みなら終了時刻と経過時間が表示されます。以降は出力の読み方・絞り込み・失敗ログの確認・systemdジャーナルの活用と、実務で使う順序で解説します。

ログイン履歴の基本的な読み方

last の出力は左から、ユーザー名・端末名・接続元IPアドレス・ログイン日時・ログアウト日時の順に並んでいます。

$ last -n 8 -F
taro     pts/0        192.168.1.100    Tue Jul 15 10:30:01 2025   still logged in
hanako   pts/1        10.0.0.5         Mon Jul 14 23:55:12 2025 - Tue Jul 15 00:12:44 2025  (00:17)
reboot   system boot  6.8.0-57-generic Mon Jul 14 09:00:05 2025
taro     pts/0        192.168.1.100    Mon Jul 14 08:45:33 2025 - Mon Jul 14 09:00:00 2025  (00:14)

wtmp begins Sun Jul  6 00:00:01 2025

端末名の pts/N はSSH経由のログイン、tty1 はコンソールへの直接接続を意味します。reboot 行はシステム再起動を示し、深夜の予期しない再起動が記録されていればカーネルパニックや電源断の可能性があります。

last が読み取るのは /var/log/wtmp というバイナリファイルです。ログローテーションで圧縮・削除されることがあるため、最終行の wtmp begins より前の記録は残っていません。長期間の履歴が必要な場合は、後述するsystemdジャーナルや外部ログ収集基盤を組み合わせてください。

出力を絞り込んで効率よく確認する

ユーザー数が多いサーバーや長期稼働のシステムでは出力が膨大になります。以下のオプションを組み合わせて必要な情報を素早く絞り込みましょう。

# 特定ユーザーのログイン履歴のみ表示
last taro -F

# システム再起動の履歴だけを抽出
last reboot -F

# 全ユーザーの「最終ログイン日時」を一覧で確認
lastlog

# 一度もログインしていないアカウントを除外して表示
lastlog | grep -v "Never logged in"

lastlog は退職者アカウントの棚卸しや、長期間使われていない休眠アカウントの確認に有効です。本来ログインするはずのないサービスアカウントに最終ログイン日時が記録されていた場合は、侵害の可能性を疑って深掘りしてください。

ログイン失敗履歴で不審なアクセスを把握する

不正アクセスの調査では、成功した履歴と同じくらい失敗した試みが重要な手がかりになります。lastb コマンドで /var/log/btmp に記録されたログイン失敗の履歴を確認できます。

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

ある運用現場では、深夜帯に海外のIPアドレスから root や admin を狙ったブルートフォース攻撃が数千件記録されていたケースがありました。lastb で大量の失敗ログが見つかった場合は、fail2ban や ufw による接続元IPのブロックを優先して検討してください。

注意：/var/log/btmp がデフォルトで存在しないディストリビューション（Ubuntu の最小インストール等）では lastb は動作しません。sudo touch /var/log/btmp && sudo chmod 600 /var/log/btmp でファイルを作成すれば以降の失敗ログが記録されますが、それ以前の記録は残りません。

現在ログイン中のユーザーをリアルタイムで確認する

過去の履歴ではなく「今この瞬間に誰が入っているか」を確認するには w コマンドが最も情報量が多く実用的です。

# 現在ログイン中のユーザーと実行中コマンドを表示
w

# ユーザー名・端末・接続元のみシンプルに確認
who

w の出力にはログイン時刻・アイドル時間・CPU使用量・現在実行中のコマンドが含まれます。見覚えのないユーザーが長時間アクティブになっていたり、不審なプロセスが稼働していれば即座に調査が必要です。インシデント対応の最初の一手として w を実行する習慣をつけると、影響範囲の初動判断が速くなります。

systemdジャーナルでSSH認証の詳細を掘り下げる

Ubuntu 20.04以降やAlmaLinux/Rocky Linux 8以降といった現代のディストリビューションでは、SSH認証のログがsystemd-journaldに集約されます。last では追えない認証方式・鍵の種類・エラーの詳細をジャーナルから確認できます。

# SSH認証ログを確認（Ubuntu/Debian系）
sudo journalctl -u ssh --since "2025-07-01" | grep -E "Accepted|Failed"

# RHEL系（AlmaLinux 9 / Rocky Linux 9）
sudo journalctl -u sshd --since today | grep -E "Accepted|Failed"

# 公開鍵認証で成功したログインだけ抽出
sudo journalctl -u sshd | grep "Accepted publickey"

# パスワード認証失敗を接続元IPごとに集計（多い順）
sudo journalctl -u sshd | grep "Failed password" \
  | awk '{print $11}' | sort | uniq -c | sort -rn | head -20

最後のコマンドはブルートフォース攻撃の発信元を可視化するものです。上位に同一IPが集中していれば、即座にブロック対象の候補として扱えます。

ジャーナルのデフォルト保持期間はディスク容量に依存します。長期保存が必要な環境では /etc/systemd/journald.conf の MaxRetentionSec を設定するか、rsyslog・Fluentd などで外部ストレージへ転送してください。

実務での確認フローと見落としやすい注意点

インシデント発生時や定期監査では、以下の順序で確認すると抜け漏れが減ります。

# ① 今誰かいるか確認
w

# ② 直近のログイン履歴を確認
last -n 30 -F

# ③ ログイン失敗件数を確認
sudo lastb -n 20 -F 2>/dev/null || echo "/var/log/btmp が存在しない環境です"

# ④ SSHの認証ログで詳細を掘り下げ（UbuntuはsshをsshdとServiceユニット名を確認すること）
sudo journalctl -u sshd --since "48 hours ago" | grep -E "Accepted|Failed"

最後に、重要な注意点を2つ挙げます。

1つ目はログの改ざん可能性です。/var/log/wtmp と /var/log/btmp はroot権限があれば削除・書き換えが可能なため、侵害後に攻撃者によって消去されているケースがあります。これらのログだけを根拠にした「アクセスなし」という判断は危険です。

2つ目はtmux・screen によるセッション分裂です。tmux や screen のデタッチ・アタッチは別端末として記録される場合があり、last の出力がセッション数より多く見えることがあります。実際の操作者数と出力行数が合わない場合は、このケースを疑ってください。

セキュリティ要件が高い環境では、auditd によるシステムコール監査や、Wazuh・Graylog などのSIEM基盤への転送も合わせて検討してください。ログをサーバー本体だけに保存している限り、侵害後の証拠保全は困難です。