Linuxでログイン監査ログを確認する方法

Linuxサーバーを運用していると、誰がいつログインしたのか、失敗したログイン試行があったのか、root権限がどのように使われたのかを確認したくなる場面が必ず出てくる。障害調査、不正アクセスの切り分け、退職者アカウントの利用確認、SSHの総当たり調査、監査対応などでは、ログイン監査ログを正しく読めるかどうかが重要になる。Linuxでは、1つのコマンドや1つのログファイルだけ見れば十分というわけではなく、last、lastb、who、w、journalctl、/var/log/auth.log、/var/log/secure、sudo ログなどを目的に応じて使い分けると整理しやすい。

最初に理解しておくべきこと

Linuxでログイン監査ログを見るときは、まず次の観点を分けて考えると分かりやすい。
・現在ログインしているのは誰か
・過去にログインしたのは誰か
・ログイン失敗はあったか
・SSH経由かローカルログインか
・sudoやsuで権限昇格が行われたか
・どのIPアドレスから来たか
この区別をしないままログを探すと、現在の接続確認と過去の履歴確認が混ざったり、認証失敗と成功ログインが混ざったりしやすい。

まずは現在ログイン中のユーザーを確認する

今この瞬間に誰がログインしているかを確認するには、who が最も基本的。
シンプルに現在のログインセッションだけを確認できる。

who

これで、
・ユーザー名
・端末
・ログイン時刻
・接続元
をざっと確認しやすい。
サーバーに想定外のユーザーが入っていないかを見る入口として使いやすい。

w コマンドで現在の利用状況まで見る

who より少し詳しく、現在ログイン中のユーザーが何をしているかまで見たいときは w が便利。
接続しているだけなのか、長時間アイドルなのか、どのコマンドを動かしているのかを確認しやすい。

w

このコマンドでは、
・誰が
・どこから
・いつログインし
・どれだけアイドルで
・何を実行しているか
が見える。
不審な操作の気配をざっくりつかむときに役立つ。

直近のログイン履歴は last が基本

過去のログイン履歴を確認する代表的なコマンドが last。
Linuxで「誰がいつログインしたか」をまず確認したいなら、最初に使うことが多い。

last

これで、
・ユーザー名
・ログイン元
・ログイン時刻
・ログアウト時刻
・セッション時間
などが見やすい。
サーバーの利用履歴をざっくり把握するにはかなり便利。

last の件数や対象を絞る方法

last は履歴が多いとかなり長くなるため、件数を絞る方が実用的なことが多い。
たとえば直近10件だけ見たいなら次のようにする。

last -n 10

特定ユーザーだけ見たいなら、ユーザー名を指定する。

last username

再起動履歴も混ざることがあるため、必要に応じて「ユーザーのログイン」だけを意識して読む方がよい。
サーバー障害前後のログイン確認では、時系列を狭めて見る方が整理しやすい。

ログイン失敗の履歴は lastb で確認する

成功ログインだけでなく、失敗したログイン試行も監査では重要。
その確認で使われるのが lastb。

sudo lastb

これで、失敗したログイン試行の履歴を確認しやすい。
SSHへの総当たりや辞書攻撃を受けている場合、ここに大量の失敗履歴が出ることがある。
とくに外部公開サーバーでは、成功履歴より失敗履歴の方が監視価値が高いことも多い。

SSHログインの詳細は auth.log や secure を見る

ログイン監査で最も重要になることが多いのが、認証ログファイル。
Debian / Ubuntu 系では /var/log/auth.log、Red Hat 系では /var/log/secure が代表的。

Ubuntu / Debian 系の例。

sudo tail -f /var/log/auth.log

RHEL / CentOS 系の例。

sudo tail -f /var/log/secure

ここでは、
・Accepted password
・Failed password
・Invalid user
・session opened
・session closed
などの記録が見えることが多い。
SSHの成功・失敗を最も詳しく追いやすいのがこのログになる。

SSHの成功ログを絞り込む方法

SSHで誰が入れたかだけを見たいなら、認証ログを grep で絞ると見やすい。
たとえば成功したSSHログインだけを見るなら次のような形になる。

sudo grep “Accepted” /var/log/auth.log

または secure を使う環境では次。

sudo grep “Accepted” /var/log/secure

これで、
・どのユーザーが
・どのIPから
・どの認証方式で
入ったかを確認しやすい。
公開サーバーでは、成功ログイン元IPを定期的に確認するだけでも不審な挙動に気づきやすい。

SSHの失敗ログを絞り込む方法

失敗ログは、不正アクセス調査で特に重要。
まずは Failed password や Invalid user を見ると分かりやすい。

sudo grep “Failed password” /var/log/auth.log

sudo grep “Invalid user” /var/log/auth.log

Red Hat 系なら secure を使う。

sudo grep “Failed password” /var/log/secure

ここで、
・同じIPから大量に失敗している
・存在しないユーザー名が大量に試されている
・短時間に繰り返している
といったパターンが見えれば、総当たりや機械的スキャンを疑いやすい。

journalctl で認証イベントを追う方法

systemd 環境では、journalctl で認証関連ログを時系列で追うのもかなり便利。
特に sshd や sudo を単位に絞れると見やすい。

SSH関連を追う例。

sudo journalctl -u ssh

または sshd 名義の環境では次。

sudo journalctl -u sshd

sudo のログなら次。

sudo journalctl | grep sudo

ログファイルを直接読むより、systemd 管理下のサービスを軸に追いたいときに便利。
時刻範囲指定と組み合わせると、障害や不審操作の直前だけ確認しやすい。

期間を絞って確認する方法

ログイン監査では、「昨日だけ」「障害発生時刻の前後だけ」を見たいことが多い。
journalctl なら時間で絞りやすい。

sudo journalctl –since “2026-04-19 00:00:00” –until “2026-04-19 23:59:59”

SSH関連だけなら組み合わせる。

sudo journalctl -u ssh –since “1 hour ago”

認証ログファイルを grep するときも、日付文字列である程度絞れるが、systemd 環境では journalctl の方が扱いやすいことが多い。

sudo の利用履歴もログイン監査の一部

ログインできたかどうかだけでなく、その後に権限昇格が行われたかも重要。
特に sudo の利用履歴は、運用監査や不正調査でかなり重要になる。

Ubuntu / Debian 系なら auth.log を絞る。

sudo grep “sudo” /var/log/auth.log

systemd環境なら journalctl でも見られる。

sudo journalctl | grep sudo

ここで、
・誰が
・どの端末から
・どのコマンドを
sudo で実行したか
が見えることがある。
単なるログイン履歴より一段深い操作監査として使いやすい。

su コマンドや root 切り替えも確認する

sudo だけでなく、su を使ったユーザー切り替えも確認対象になる。
特に root へ切り替わっている場合は見落とさない方がよい。

sudo grep “su:” /var/log/auth.log

または secure 環境では次。

sudo grep “su:” /var/log/secure

これにより、
・誰が root へ切り替えたか
・どの端末から実行したか
を追いやすい。
sudo が禁止されている環境や、su 運用が混ざっている環境では重要になる。

過去ログのローテーションも忘れず見る

監査で「最近の分しか出てこない」と感じるときは、ログローテーションされている可能性が高い。
たとえば auth.log には過去ログが圧縮されて残っていることがある。

ls -l /var/log/auth.log*

圧縮済みログを確認するなら zgrep が便利。

sudo zgrep “Failed password” /var/log/auth.log*.gz

secure 側でも同様に過去ログを確認できる。
インシデント調査では、現行ログだけでは足りず、ローテート済みファイルまで見ることがよくある。

監査で特に注意して見るべきポイント

ログイン監査では、単に成功・失敗を見るだけではなく、次の観点を持つと精度が上がりやすい。
・想定外のIPアドレスからの成功ログイン
・深夜や休日など不自然な時刻のログイン
・存在しないユーザー名への大量試行
・短時間に集中した失敗ログ
・sudo 実行の急増
・root 直接ログインの有無
・退職者や無効化済み想定ユーザーの利用
特に、成功ログインは件数が少ない分、1件ずつの重要度が高いことが多い。

よくある失敗と勘違い

ログイン監査でやりがちな失敗はかなり典型的。
・last だけ見て満足する
・成功ログインだけ見て失敗試行を見ない
・auth.log と secure の違いを意識していない
・ローテーション済みログを見ていない
・sudo や su の履歴を確認していない
・IPアドレスだけ見て正当性確認をしていない
・journalctl とログファイルを使い分けていない
たとえば、last は便利だが、それだけでは認証失敗や sudo 利用までは十分に見えない。
そのため、目的に応じて複数の入口を使い分ける方がよい。

実務で使いやすい確認手順

ログイン監査を実務で行うなら、次の順番がかなり使いやすい。

1. who と w で現在ログイン中ユーザーを確認
2. last で過去の成功ログインを見る
3. lastb で失敗ログインを見る
4. auth.log または secure で SSH 成功・失敗を grep する
5. journalctl で時刻やサービス単位に絞る
6. sudo / su の履歴を確認する
7. 必要ならローテート済みログまで遡る
   この順で進めると、現在・過去・失敗・権限昇格の流れを一通り追いやすい。

まとめ

Linuxでログイン監査ログを確認するときは、
・現在ログイン中の確認は who と w
・過去の成功ログインは last
・失敗ログインは lastb
・SSHの詳細は auth.log や secure
・systemd環境では journalctl
・権限昇格の監査は sudo / su ログ
という分け方で見ると整理しやすい。
重要なのは、「誰が入ったか」だけではなく、
・どこから
・いつ
・何回失敗し
・その後に sudo や su を使ったか
まで追うこと。
この視点で見ると、障害調査だけでなく、不正アクセス対策や監査対応でもかなり役立ちやすい。