インシデント対応のための Linux ログ分析：journalctl の活用法

はじめに

システム管理やサイバーセキュリティの分野において、ログ分析は非常に重要なスキルです。システムログは、通常の操作から重大なエラー、潜在的なセキュリティ侵害まで、幅広いイベントを記録します。これらのログを効果的にナビゲートし、解釈する能力は、システムの健全性を監視し、問題をトラブルシューティングし、セキュリティインシデントに対応するために不可欠です。

このラボでは、最新の Linux システムにおけるjournaldサービスからのログをクエリおよび表示するための標準ツールであるjournalctlを紹介します。監視およびインシデント対応の基礎となる基本的なログ分析タスクを実行する方法を学びます。

このラボを通して、以下のことを行います。

システム起動ログを確認します。
認証失敗などの特定のイベントを見つけるためにログをフィルタリングします。
不審なイベントをシミュレートして検出します。
さらなる分析のためにログをエクスポートします。

journalctl を使用したシステム起動ログの確認

このステップでは、journalctl コマンドを使用してシステムログを確認する方法を学びます。特に、直近の起動プロセス中に生成されたメッセージに焦点を当てます。これは、起動時の問題を診断する際の一般的な最初のステップです。

journalctl コマンドを使用すると、systemd ジャーナルの内容をクエリできます。引数なしで実行すると、すべてのログが表示されますが、これは情報量が多すぎて扱いにくい場合があります。

出力をより管理しやすくするために、-b または --boot フラグを使用して、現在の起動セッションからのログのみを表示できます。

現在の起動ログを表示するには、ターミナルで以下のコマンドを実行してください。

journalctl -b

起動プロセスからの最も古いメッセージから始まるページ化された出力が表示されます。上矢印および下矢印キーを使用してナビゲートできます。ページャーを終了してコマンドプロンプトに戻るには q を押してください。

-- Journal begins at Tue 2023-10-31 08:30:00 UTC, ends at Tue 2023-10-31 09:00:00 UTC. --
Oct 31 08:30:01 labex-vm kernel: Linux version 5.15.0-87-generic ...
Oct 31 08:30:01 labex-vm kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-87-generic ...
Oct 31 08:30:01 labex-vm kernel: KERNEL supported cpus:
Oct 31 08:30:01 labex-vm kernel:   Intel GenuineIntel
Oct 31 08:30:01 labex-vm kernel:   AMD AuthenticAMD
...
(END)

このコマンドは、どのサービスが正常に開始されたかを理解し、システム起動中に発生したエラーを特定するのに非常に役立ちます。

認証失敗ログのフィルタリング

このステップでは、ジャーナルをフィルタリングして、セキュリティ監視に不可欠な認証失敗などの特定のイベントを見つけます。攻撃者がよく標的とするのは SSH サービスであるため、そのログを監視することは最優先事項です。

journalctl の -u フラグを使用して、特定の systemd ユニットでログをフィルタリングできます。SSH サービスの場合、ユニットは通常 ssh.service (Ubuntu/Debian) または sshd.service (Red Hat/CentOS) です。

SSH デーモンに関連するエントリのみを表示するようにログをフィルタリングしてみましょう。システムログを表示するには sudo が必要になる場合があることに注意してください。

sudo journalctl -u ssh

このコマンドは、sshd サービスによって生成されたすべてのログエントリを表示します。潜在的なセキュリティ問題に検索を絞り込むために、この出力を grep コマンドにパイプして、「Failed」のようなキーワードを検索できます。

SSH サービスに対するパスワード試行失敗を見つけるには、次のコマンドを実行します。

sudo journalctl -u ssh | grep "Failed password"

最近のログイン試行失敗がない場合、このコマンドは何も出力しない可能性があります。これは、安全なシステムでは正常なことです。次のステップでは、ログにどのように表示されるかを確認するために、自分でそのようなイベントを生成します。

不審なイベントのシミュレーションとログ分析

次に、不審なイベントをシミュレートし、ログ分析スキルを使用してそれを検出します。ブルートフォース攻撃の一般的な兆候は、一連のログイン試行失敗です。存在しないユーザー名で自身のマシン (localhost) に SSH 接続しようとすることで、そのような試行をシミュレートします。

ターミナルで以下のコマンドを実行してください。パスワードを求められますが、失敗することが予想されるため、何を入力しても構いません。

ssh non_existent_user@localhost

システムは接続を拒否します。これは予期された結果です。以下のようなメッセージが表示されるはずです。

non_existent_user@localhost's password:
Permission denied, please try again.
non_existent_user@localhost's password:
Permission denied (publickey,password).

これでログイン失敗イベントが生成されたので、前のステップのログ分析コマンドを再度実行して、それを見つけられるか確認しましょう。

sudo journalctl -u ssh | grep "Failed password"

今回は、コマンドを実行すると、先ほど行った失敗した試行を示す出力が表示されるはずです。

Oct 31 09:15:12 labex-vm sshd[1234]: Failed password for invalid user non_existent_user from 127.0.0.1 port 48492 ssh2

この簡単な演習は、インシデント対応の基本的なループを示しています。イベントが発生し、ログに記録され、管理者または自動化されたシステムがログを分析してそれを検出します。

集中分析シミュレーションのためのログエクスポート

実際のシナリオでは、長期保存や相関分析のために、個々のマシンからログを一元化されたログサーバー（SIEM など）にエクスポートすることがよくあります。このステップでは、最近の SSH ログをファイルにエクスポートすることでこれをシミュレートします。

journalctl はさまざまな形式でログを出力できます。json-pretty 形式は、人間が読めるだけでなく、他のツールで簡単に解析できるため、特に便利です。

過去 10 分間のすべての SSH ログを、現在のディレクトリ (~/project) に ssh_logs.json という名前のファイルにエクスポートしましょう。

sudo journalctl -u ssh --since "10 minutes ago" -o json-pretty > ~/project/ssh_logs.json

次に、ファイルが作成されたことを確認します。

ls -l ~/project

ファイルリストに ssh_logs.json が表示されるはずです。

total 4
-rw-r--r-- 1 labex labex 1234 Oct 31 09:20 ssh_logs.json

最後に、エクスポートされたログファイルの内容を表示しましょう。

cat ~/project/ssh_logs.json

出力は構造化された JSON 配列になり、各ログエントリはオブジェクトとして表示されます。この形式は、他の分析プラットフォームへの取り込みに最適です。

[
    {
        "__CURSOR" : "s=...",
        "__REALTIME_TIMESTAMP" : "...",
        "__MONOTONIC_TIMESTAMP" : "...",
        "_BOOT_ID" : "...",
        "_TRANSPORT" : "syslog",
        "PRIORITY" : "6",
        "SYSLOG_FACILITY" : "4",
        "SYSLOG_IDENTIFIER" : "sshd",
        "MESSAGE" : "Failed password for invalid user non_existent_user from 127.0.0.1 port 48492 ssh2",
        "_PID" : "1234",
        ...
    }
]

これで、一元化された分析のためにログを準備するプロセスを正常にシミュレートできました。

まとめ

この実験では、最新の Linux システムにおける強力なログ分析ツールである journalctl の実践的な経験を積みました。これらは、システム管理者、DevOps エンジニア、またはセキュリティ専門家にとって基本的なスキルです。

以下の方法を学びました。

システムおよびブートログを確認して、起動時の問題を診断する。
特定のサービスやメッセージ内容でログをフィルタリングして、関連イベントを見つける。
ログエントリから、ログイン失敗などの不審なアクティビティを特定する。
JSON のような構造化された形式でログをエクスポートして、一元化されたストレージとさらなる分析を行う。

これらのテクニックを習得することで、システムの監視、問題の効率的なトラブルシューティング、およびセキュリティインシデントへの対応の第一歩を踏み出すことができるようになります。

監視とインシデント対応のためのログ分析

はじめに

journalctl を使用したシステム起動ログの確認

認証失敗ログのフィルタリング

不審なイベントのシミュレーションとログ分析

集中分析シミュレーションのためのログエクスポート

まとめ