「サーバーに変な人がログインしていないか心配だけど、何のコマンドをどう見ればいいか分からない」という相談をよく受けます。last・lastb・journalctlを使えば、SSHだけでなくsudoや画面ログインまで含めた総合的なログイン監査が初心者でも手を動かして行えます。この記事では実際の出力例を見ながら「どこが正常でどこが異常か」の判断基準と、再起動やディスク容量不足でログが消えてしまった場合の対処まで、コピペで使える手順にまとめました。

last / lastb で「誰が」「いつ」ログインしたかを洗い出す

まず押さえるべきは last（成功したログイン記録）と lastb（失敗したログイン試行記録）の2つです。どちらもUbuntu/Debianに標準で入っているutil-linuxパッケージのコマンドで、追加インストールは不要です。

last コマンド（ログイン成功記録の見方）

何を見ているか一言で言うと、/var/log/wtmpというファイルに記録された「過去のログイン・ログアウト・再起動の履歴」です。

last -x

出力例：

kaz      pts/0        203.0.113.45     Mon Aug 18 09:12   still logged in
kaz      pts/0        203.0.113.45     Sun Aug 17 21:03 - 23:47  (02:44)
reboot   system boot  6.8.0-45-generic Sun Aug 17 08:00   still running
kaz      pts/0        203.0.113.45     Sat Aug 16 10:15 - 10:40  (00:24)

判断ポイントは次の3つです。

  • ユーザー名が自分の知っているアカウントだけか（見覚えのないユーザー名があれば要注意）
  • IPアドレス（3列目）が普段アクセスしている場所と一致するか。海外の見慣れないIPからのstill logged inは特に危険信号
  • ログイン時刻が業務時間外（深夜3時など）に集中していないか

異常が見つかったら、まずそのIPからの通信を今すぐ止める（後述のファイアウォールで遮断）よりも先に、まだセッションが張られたままならwhoコマンドで現在ログイン中の端末を確認し、心当たりがなければsudo pkill -KILL -u ユーザー名で強制切断、その後にパスワードやSSH鍵を変更してください。この操作はセッションを切るだけで元に戻す必要はありません。

sudo lastb（総当たり攻撃・不正ログイン試行の見方）

何を見ているかというと、/var/log/btmpというファイルに記録された「ログインに失敗した試行」です。このファイルは一般ユーザーには読み取り権限がないためsudoが必須です（設定変更は伴わないので安全に実行できます）。

sudo lastb

出力例：

root     ssh:notty    198.51.100.23    Mon Aug 18 03:14 - 03:14  (00:00)
root     ssh:notty    198.51.100.23    Mon Aug 18 03:13 - 03:13  (00:00)
admin    ssh:notty    198.51.100.23    Mon Aug 18 03:13 - 03:13  (00:00)
test     ssh:notty    198.51.100.23    Mon Aug 18 03:13 - 03:13  (00:00)

判断ポイント：同じIPからrootやadmin、testのような推測されやすいユーザー名で数秒おきに大量の失敗が並んでいれば、それは典型的な総当たり攻撃（ブルートフォース）です。件数が多いだけなら「攻撃を受けたが弾いた」証拠なので過度に慌てる必要はありませんが、同じIPからの試行が数百件を超えるようなら、SSHの設定自体を見直す価値があります。具体的な締め方は SSHログ点検2026年8月版｜今すぐ締めるべき設定3つ にまとめているので、あわせて確認してください。

journalctlでSSH以外の経路（sudo・su・デスクトップログイン）も横断監査する

last/lastbは「ログイン」しか見ませんが、実際の侵入や不正操作の痕跡は権限昇格（sudo/su）やデスクトップログインにも残ります。journalctlはsystemd系のUbuntu/Debianであれば標準で使え、これらを横断的に確認できます。

SSH認証ログをjournalctlで確認する

何を見ているかというと、SSHデーモン（sshd）が出力したログをsystemdのジャーナル（ログの一元管理システム）から絞り込んで表示しています。

sudo journalctl -u ssh --since "3 days ago"

出力例：

Aug 18 03:13:58 myserver sshd[10432]: Failed password for invalid user admin from 198.51.100.23 port 51422 ssh2
Aug 18 03:14:02 myserver sshd[10440]: Failed password for root from 198.51.100.23 port 51430 ssh2
Aug 18 09:12:10 myserver sshd[11220]: Accepted publickey for kaz from 203.0.113.45 port 60210 ssh2

Failed passwordは失敗、Accepted publickeyやAccepted passwordは成功です。lastbより1行ずつ詳細（使われた認証方式やポート番号）が出るので、lastbで気になるIPを見つけたら、そのIPで journalctl を絞り込んでgrepすると経緯が追いやすくなります。

sudo journalctl -u ssh | grep "198.51.100.23"

※Ubuntu/Debianはサービス名がsshですが、CentOS/RHEL/Fedora系ではsshdになります（-u sshd）。ログファイルの場所もDebian系は/var/log/auth.log、RHEL系は/var/log/secureと異なります。

sudo/suの権限昇格ログを確認する

攻撃者が一般ユーザーでログインに成功したあと管理者権限を取ろうとした形跡は、sudoのログに残ります。

sudo journalctl _COMM=sudo --since "7 days ago"

出力例：

Aug 18 10:02:15 myserver sudo[12011]: kaz : TTY=pts/0 ; PWD=/home/kaz ; USER=root ; COMMAND=/usr/bin/apt update
Aug 18 10:05:40 myserver sudo[12030]: kaz : TTY=pts/0 ; PWD=/home/kaz ; USER=root ; COMMAND=/usr/bin/systemctl status nginx

判断ポイント：COMMAND=の内容が自分の作業と一致しているか確認してください。useraddやpasswd、見知らぬファイルへのchmod、curl | bashのような外部スクリプト実行が身に覚えなく並んでいたら、既に権限を奪われている可能性が高いです。この場合はネットワークを切断してから調査する（証拠保全）のが定石で、稼働中のまま調べ続けると証跡が上書きされてしまいます。

デスクトップ（GUI）ログインの履歴を確認する

PCとして使っているUbuntuデスクトップ環境（GNOME）なら、画面ロック解除やログイン画面の履歴も残ります。

sudo journalctl -u gdm --since "7 days ago" | grep -i "login\|unlock"

出力例：

Aug 17 08:05:02 myserver gdm-password][1203]: gkr-pam: unlocked login keyring

物理アクセスされた形跡がないか（自分が触っていない時間帯にロック解除の記録があるか）を見ます。サーバー用途でGUIを入れていない場合はこの項目は該当しません。

last/lastbの記録が改ざんされていないかjournalctlと突き合わせる

ここが今回いちばん重要なポイントです。/var/log/wtmp・/var/log/btmpはただのバイナリファイルなので、root権限を奪われた攻撃者は自分の侵入記録だけを消したり、ファイルごと空にしたりできます。一方でjournalctl（systemdジャーナル）は完全に改ざんに強いわけではありませんが、記録の仕組みが別系統なので両者を突き合わせると矛盾が見えることがあります。

確認手段

見ているログ

改ざんへの強さ

必要権限

last

/var/log/wtmp

低い（単純なファイル削除・編集で消せる）

不要（環境により要sudo）

lastb

/var/log/btmp

低い（同上）

sudo必須

journalctl

systemdジャーナル（バイナリ・追記型）

中程度（rootなら操作可能だが手順が煩雑）

一般ユーザーでも一部閲覧可・全件はsudo推奨

再起動回数の食い違いを見る

何を見ているかというと、システムが何回起動したかという記録を2つの方法で数え、件数が一致するか比較します。

last reboot
sudo journalctl --list-boots

journalctl --list-bootsの出力例：

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -2 3f1e9c2a1b7a4d8e9f0a1b2c3d4e5f60 Sun 2026-08-10 07:55:12 JST Sun 2026-08-17 07:58:00 JST
 -1 9ac2b4d6e8f0123456789abcdef01234 Sun 2026-08-17 08:00:03 JST Mon 2026-08-18 09:00:00 JST
  0 7bd4a1c9e3f5678901234567890abcde Mon 2026-08-18 09:00:05 JST Mon 2026-08-18 12:10:44 JST

判断ポイント：last rebootで表示される再起動回数よりjournalctl --list-bootsのIDX件数の方が明らかに多い場合、wtmpの一部が消されている疑いがあります。journalctlのほうが起動回数を余分に記録しているのがサインです。逆にjournalctl側が少ない・履歴が7日程度で途切れているのは、後述する「揮発設定」が原因であることが大半です。

utmpdumpで生ログを確認する

wtmpファイルが編集された場合、レコードの並びや長さが崩れてlastコマンドでは正しく表示できなくなることがあります。その崩れ自体が改ざんの手がかりになります。

sudo utmpdump /var/log/wtmp | tail -30

utmpdump: /var/log/wtmp: Invalid or damaged file.のようなエラーが出た場合、ファイルが正常な手順（ログアウトやシステム終了）以外で書き換えられた可能性が高いです。util-linuxパッケージに含まれるため追加インストールは不要です（入っていなければsudo apt install util-linux）。

このような矛盾を見つけたら、その時点で自力調査を続けるより先にネットワークから切り離してオフラインで調査する、または信頼できるバックアップからの復旧を検討してください。ログが改ざんされている環境は「クリーンな状態」を証明できないため、中途半端な駆除より作り直しの方が安全です。

再起動・電源断・容量不足でログが消えている時に確認すべきこと

「調べようとしたらそもそもログがほとんど残っていなかった」というケースも多く、これは攻撃とは無関係な設定の問題であることがよくあります。

journalctlのログが揮発設定になっていないか確認する

何を見ているかというと、journalのログをディスクに保存しているか、メモリ上だけに置いて再起動で消える設定になっているかです。

journalctl --disk-usage
ls -ld /var/log/journal

出力例：

Archived and active journals take up 104.0M in the file system.

/var/log/journalディレクトリが存在しない場合、Ubuntu/Debianの初期設定ではログはメモリ上（/run/log/journal）にしか保存されず、再起動すると消えます。これが「再起動したらログが無くなっていた」の主な原因です。永続化したい場合は次のコマンドで有効化できます（sudo必須・設定変更を伴います）。

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

元に戻す方法：sudo rm -rf /var/log/journalで削除して再起動すれば元の揮発設定に戻ります。ディスク容量が心配な場合は保存上限を決めておくと安心です。

sudo journalctl --vacuum-size=500M

これは既存ログを500MBまで間引くだけの操作で、システムの動作には影響しません。

ディスク容量不足でログが書き込めていないか確認する

何を見ているかというと、ログを保存するパーティションの空き容量です。

df -h /var/log

出力例：

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        20G   19G  200M   99%  /

Use%が95%を超えていると要注意で、100%近いとログの書き込みそのものが失敗し始めます。この場合は容量不足の原因（大きくなりすぎた古いログや不要ファイル）を特定してから削除してください。

du -sh /var/log/* | sort -rh | head -10

容量が原因でログが欠けていた期間は、その時間帯の記録自体が存在しないため「侵入がなかった」とは判断できません。空き容量を確保したうえで、他の手がかり（後述）を探す必要があります。

ログが無い時に残っている手がかりを探す

wtmp/btmp/journalすべてが期待した期間をカバーしていない場合でも、次の場所には別系統の記録が残っていることがあります。

  • ls -la /var/log/auth.log*：logrotateによりauth.log.1やauth.log.2.gzとして過去分が圧縮保存されている場合がある（zcat auth.log.2.gz | lessで閲覧可）
  • cat /var/log/apt/history.log：見覚えのないパッケージインストールがないか（攻撃者がツールを入れた痕跡）
  • crontab -lおよびsudo ls /etc/cron.d/ /etc/systemd/system/：身に覚えのない自動起動ジョブがないか
  • w／who：ログは消えていても今まさに開いているセッションは表示される
  • ss -tulpn：現在どのプロセスがどのポートで通信を待ち受けているか。ログが無くても侵入後に設置されたバックドアが今も動いていれば見つかる可能性がある。具体的な見方は ss -tulpn/lsof -iで不審ポート点検【26年8月】 を参照

いずれも「過去に何が起きたか」の代わりに「今どういう状態か」を確認する手段です。過去ログが無いこと自体を過度に恐れず、現在の状態点検に切り替えるのが実務的な対応です。

異常を見つけたときの初動対応と点検の頻度

この記事の手順で異常が見つかった場合の優先順位は次の通りです。

  1. 不審なセッションが現在もログインしたままなら切断する（sudo pkill -KILL -u ユーザー名）
  2. パスワードとSSH鍵をすべて変更する
  3. sudoログに見覚えのない操作があれば、ネットワークを切り離して原因調査を優先する
  4. wtmp改ざんの疑いがある場合は、その環境を信頼できる状態とみなさず作り直しを検討する

点検の頻度は、個人利用のVPSなら週1回、業務で使うサーバーなら日次でのlastb確認が現実的です。手作業が負担な場合はlast -xやsudo lastbの出力を定期的にファイル保存してdiffを取るだけでも、変化に気づく仕組みになります。

まとめ

last/lastbは手軽ですがwtmp/btmpという単純なファイルに依存するため改ざんに弱く、journalctlと突き合わせて再起動回数などの矛盾を確認することで信頼性が上がります。ログ自体が消えている場合は、まずjournalctlの永続化設定とディスク容量を確認し、それでも足りなければauth.logの過去分やapt履歴、現在の通信状況といった別の手がかりに切り替えましょう。どの操作もsudoは必要でも設定破壊のリスクは低く、永続化設定も1コマンドで元に戻せるので、まずは自分の環境で一通り実行して「正常な状態の基準」を把握しておくことをおすすめします。