誰がマシンにログインしたか：ログインログ
成功したログインと失敗したログインを確認する場所、last、lastb、journalctlの読み方、sudoによる操作の追跡方法、ログ保持の設定方法を説明します。
更新日 2026年8月23日
マシンへのログインはすべて痕跡を残します。その痕跡を5分で読み解けるかどうかが、落ち着いたインシデント調査と当て推量を分けます。
概要
last -a -n 20
lastb -a -n 20
lastlog
who
w
last は成功したログインをアドレス付きで表示し、lastb は失敗した試行、lastlog は各ユーザーが最後にログインした日時を表示します。who と w は現在マシンに誰がログインしているかを表示します。
lastlog で www-data のようなシステムユーザーのログイン日時が表示されたら、それは調査すべき重大な理由です。
systemd ジャーナル
journalctl -u ssh -n 100
journalctl -u ssh --since "2026-08-20" --until "2026-08-21"
journalctl _COMM=sshd | grep "Accepted"
journalctl _COMM=sshd | grep "Failed password" | tail -50
重要な行：
| 行 | 意味 |
|---|---|
Accepted publickey for artem | 鍵によるログイン成功 |
Accepted password for root | パスワードによるログイン成功 — 懸念材料 |
Failed password for invalid user admin | 存在しない名前へのブルートフォース、バックグラウンドノイズ |
Disconnected from authenticating user | 試行が中断された |
Debian と Ubuntu では、同じイベントが /var/log/auth.log に重複して記録されます。AlmaLinux では /var/log/secure に記録されます。
grep "Accepted" /var/log/auth.log
grep -c "Failed password" /var/log/auth.log
公開アドレスに対して1日あたり数百回の失敗試行があるのは正常です。異常なのは別のことです。見覚えのないアドレスからのログイン成功です。fail2ban はノイズ対策に役立ちます。
ログイン後に何が行われたか
journalctl -t sudo -n 100
grep sudo /var/log/auth.log
cat /home/artem/.bash_history
コマンド履歴は信頼できません。簡単に消去でき、非対話セッションでは記録されないからです。sudo のログのほうがはるかに正直です。シェルではなくシステムによって管理されているからです。これは記事ユーザーと sudoで説明している「一般ユーザー＋sudo」方式を支持するもう一つの論拠です。
カーネルレベルでの完全な監査：
apt install -y auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
ausearch -k passwd_changes
保存
デフォルトでは、systemd ジャーナルはメモリ上に置かれ、再起動時に失われる可能性があります。これはインシデント調査にとって好ましくありません。ファイル /etc/systemd/journald.conf：
[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month
systemctl restart systemd-journald
journalctl --disk-usage
サイズ制限は必須です。ディスクを食い尽くしたジャーナルはサービスを停止させます。
よくある間違い
| 間違い | 結果 | 解決策 |
|---|---|---|
| ジャーナルが再起動間で保存されない | 痕跡が失われる | Storage=persistent |
.bash_history だけに頼る | データが容易に改ざんされる | sudo と auditd のログを確認する |
| ジャーナルのサイズを制限していない | ディスクが満杯になる | SystemMaxUse |
| ブルートフォースのノイズをハッキングとみなす | 誤警報 | Failed ではなく Accepted を見る |
他人のアドレスからのログイン成功を見つけた場合、マシン自体のログはもはや信頼できるものとは見なせません。ログインした人物がログを編集できた可能性があるからです。記事侵害の兆候に従い、マシンを再インストールする必要があると想定してください。