リスク軽減と復旧操作


Red Hat Enterprise Linux 10

データのバックアップ、ログの監視、セキュリティー更新の管理

Red Hat Customer Content Services

概要

障害復旧ツールである Relax-and-Recover (ReaR) を使用して、障害による影響を最小限に抑え、障害発生後にシステムとデータを復元するための体系的な計画を作成します。システムの安定性、セキュリティー、パフォーマンスを向上させるために、セキュリティー更新を管理および監視する方法を説明します。ログファイルを使用して、記録されたシステムイベントを調べ、問題の特定、トラブルシューティング、および回避を行い、システム機能を監視します。

Red Hat ドキュメントへのフィードバック (英語のみ)

Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。

Jira からのフィードバック送信 (アカウントが必要)

  1. Jira の Web サイトにログインします。
  2. 上部のナビゲーションバーで Create をクリックします。
  3. Summary フィールドにわかりやすいタイトルを入力します。
  4. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
  5. ダイアログの下部にある Create をクリックします。

第1章 システムの復旧および復元

Red Hat Enterprise Linux は、既存のバックアップを使用してシステムを復旧および復元するための Relax-and-Recover (ReaR) ユーティリティーを備えています。このユーティリティーは、障害復旧ソリューションとして、またシステム移行にも使用できます。

このユーティリティーを使用すると、以下のタスクを実行できます。

  • 起動可能なイメージを作成し、そのイメージを使用して既存のバックアップからシステムを復元する
  • オリジナルのストレージレイアウトを複製する
  • ユーザーおよびシステムファイルを復元する
  • システムを別のハードウェアに復元する

また、障害復旧の場合は、特定のバックアップソフトウェアを ReaR に統合することもできます。

1.1. ReaR の設定とバックアップの手動作成

以下の手順を使用して、Relax-and-Recover (ReaR) ユーティリティーを使用するパッケージのインストール、レスキューシステムの作成、バックアップの設定および生成を行います。

前提条件

  • バックアップ復元計画をもとに、必要な設定ができている。

    ReaR に完全に統合され組み込まれている NETFS バックアップ方式を使用できます。

手順

  1. ReaR ユーティリティーをインストールします。

    # dnf install rear
    Copy to Clipboard Toggle word wrap
  2. 以下の例のように、任意のエディターで ReaR 設定ファイルを変更します。

    # vi /etc/rear/local.conf
    Copy to Clipboard Toggle word wrap
  3. バックアップ設定の詳細を /etc/rear/local.conf に追加します。たとえば、NETFS バックアップ方式の場合は、次の行を追加します。

    BACKUP=NETFS
    BACKUP_URL=backup.location
    Copy to Clipboard Toggle word wrap

    backup.location は、バックアップ先の URL に置き換えます。

  4. 新規バックアップの作成時に以前のバックアップアーカイブを維持するように ReaR 設定を行うには、以下の行を設定ファイルに追加します。

    NETFS_KEEP_OLD_BACKUP_COPY=y
    Copy to Clipboard Toggle word wrap
  5. 増分バックアップ (実行するたびに変更されたファイルのみがバックアップされる) を設定する場合は、以下の行を追加します。

    BACKUP_TYPE=incremental
    Copy to Clipboard Toggle word wrap
  6. レスキューシステムを作成します。

    # rear mkrescue
    Copy to Clipboard Toggle word wrap
  7. 復元計画に従ってバックアップを作成します。たとえば、NETFS バックアップ方式の場合は、次のように入力します。

    # rear mkbackuponly
    Copy to Clipboard Toggle word wrap

    または、以下のコマンドを実行すると、1 つの手順でレスキューシステムとバックアップを作成できます。

    # rear mkbackup
    Copy to Clipboard Toggle word wrap

    このコマンドは、rear mkrescue コマンドと rear mkbackuponly コマンドの機能を組み合わせたものです。

1.2. 64 ビット IBM Z アーキテクチャーで ReaR レスキューイメージの使用

64 ビット IBM Z アーキテクチャーでは、基本的な Relax and Recover (ReaR) 機能が使用でき、完全にサポートされています。IBM Z では、z/VM 環境でのみ ReaR レスキューイメージを作成できます。論理パーティション (LPAR) のバックアップおよび復元はテストされていません。

現在利用できる出力方法は、Initial Program Load (IPL) のみです。IPL は、zIPL ブートローダーで使用できるカーネルと初期 RAM ディスク (initrd) を生成します。

前提条件

  • rear パッケージがインストールされている。

手順

  1. 次の変数を /etc/rear/local.conf に追加し、64 ビット IBM Z アーキテクチャー上でレスキューイメージを生成するように ReaR を設定します。

    1. IPL アウトプットメソッドを設定するには、OUTPUT=IPL を追加します。
    2. バックアップメソッドとバックアップ先を設定するには、BACKUP 変数および BACKUP_URL 変数を追加します。以下に例を示します。

      BACKUP=NETFS
      
      BACKUP_URL=nfs://<nfsserver_name>/<share_path>
      Copy to Clipboard Toggle word wrap
      重要

      ローカルバックアップストレージは、現在、64 ビットの IBM Z アーキテクチャーではサポートされていません。

    3. オプション: OUTPUT_URL 変数を設定して、カーネルファイルと initrd ファイルを保存することもできます。初期設定では、OUTPUT_URLBACKUP_URL に合わせて配置されています。
  2. バックアップとレスキューのイメージの作成を実行するには、次のコマンドを実行します。

    # rear mkbackup
    Copy to Clipboard Toggle word wrap
  3. これにより、BACKUP_URL 変数または OUTPUT_URL (設定されている場合) 変数で指定された場所にカーネルファイルと initrd ファイルが作成され、指定されたバックアップ方法を使用してバックアップが作成されます。

    警告

    レスキュープロセスは、システムに接続したすべての DASD (Direct Attached Storage Devices) を再フォーマットします。システムのストレージデバイスに貴重なデータが存在する場合は、システムの復旧を行わないでください。これには、レスキュー環境で起動するのに使用された zipl ブートローダー、ReaR カーネル、および initrd で準備されたデバイスも含まれます。必ずコピーを保管してください。

  4. システムを復元するには、以前に作成した ReaR カーネルファイルおよび initrd ファイルを使用し、zipl ブートローダー、カーネル、および initrd で準備した DASD (Direct Attached Storage Device) または FCP (Fibre Channel Protocol) 接続の SCSI デバイスから起動します。
  5. レスキューカーネルと initrd が起動すると、ReaR レスキュー環境が起動します。システムの復元を続行します。

1.3. ReaR の除外

ReaR ユーティリティーは、復旧プロセス中に、/var/lib/rear/layout/disklayout.conf レイアウトファイルの内容に従って、レスキューイメージが作成された元のシステムのストレージレイアウトを、復旧されたシステムのディスク上に再作成します。ストレージレイアウトには、パーティション、ボリュームグループ、論理ボリューム、ファイルシステム、その他のストレージコンポーネントが含まれます。

ReaR は、レスキューイメージを作成するときにレイアウトファイルを作成し、このファイルをイメージに埋め込みます。レイアウトファイルは、rear savelayout コマンドを使用して作成することもできます。これを使用すると、レスキューイメージ全体を作成しなくても、レイアウトファイルをすばやく作成して調べることができます。

レイアウトファイルには、一部の例外を除き、元のシステムのストレージレイアウト全体が記述されます。ReaR は、復旧中に再作成されないように、一部のストレージコンポーネントをレイアウトファイルから除外します。ストレージコンポーネントをレイアウトから除外するかどうかは、次の設定変数によって制御されます。

  • AUTOEXCLUDE_DISKS
  • AUTOEXCLUDE_MULTIPATH
  • AUTOEXCLUDE_PATH
  • EXCLUDE_RECREATE

設定変数によってレイアウトファイルから一部のファイルシステムを除外すると、そのコンテンツもバックアップから除外されます。また、BACKUP_PROG_EXCLUDE 設定変数を使用すると、レイアウトファイルからファイルシステムを除外せずに、一部のファイルまたはディレクトリーツリーをバックアップから除外できます。

この方法でファイルシステム内のすべてのファイルとディレクトリーを除外しても、復旧時にファイルシステムが再作成されます。しかし、バックアップに復元するデータが含まれていないため、ファイルシステムは空になります。これは、一時データが含まれており保存する必要のないファイルシステム、または ReaR によらない方法を使用してバックアップされるデータに役立ちます。

BACKUP_PROG_EXCLUDE 変数は、tar または rsync に渡される glob スタイルのワイルドカードパターンの配列です。このパターンは引用符で囲む必要があることに注意してください。これは、シェルが設定ファイルを読み取るときにパターンが拡張されるのを防ぐために行います。この変数のデフォルト値は、/usr/share/rear/conf/default.conf ファイルで設定されています。デフォルト値には、たとえば /tmp/* パターンが含まれています。このパターンは、/tmp ディレクトリーの下にあるすべてのファイルとディレクトリーを除外しますが、/tmp ディレクトリー自体は除外しません。

他のファイルやディレクトリーを除外する必要がある場合は、デフォルト値を保持するために、変数をオーバーライドするのではなく、変数に + を使用してパターンをさらに追加します。たとえば、デフォルト値に加えて、ディレクトリー /data/temp の下にあるすべてのファイルとディレクトリーを除外するには、次のようにします。

BACKUP_PROG_EXCLUDE+=( '/data/temp/*' )
Copy to Clipboard Toggle word wrap

/usr/share/rear/conf/default.conf ファイルで設定変数のデフォルト値を確認できます。このデフォルト値は、ローカルの /etc/rear/local.conf 設定ファイルで変更できます。

また、内部の NETFS および RSYNC バックアップ方式でバックアップされるファイルを設定することもできます。デフォルトでは、レイアウトファイルにファイルシステムが含まれている場合、マウントされたすべてのローカルディスクベースのファイルシステム上のファイルは、rear mkbackup コマンドまたは rear mkbackuponly コマンドによってバックアップされます。

rear mkbackup コマンドを使用すると、ログ内のバックアップ除外パターンがリスト表示されます。ログファイルは /var/log/rear ディレクトリーにあります。これを使用して、完全なシステム復旧を実行する前に、除外ルールを確認できます。たとえば、ログに次のエントリーが含まれているとします。

2025-04-29 10:17:41.312431050 Making backup (using backup method NETFS)
2025-04-29 10:17:41.314369109 Backup include list (backup-include.txt contents):
2025-04-29 10:17:41.316197323   /
2025-04-29 10:17:41.318052001 Backup exclude list (backup-exclude.txt contents):
2025-04-29 10:17:41.319857125   /tmp/*
2025-04-29 10:17:41.321644442   /dev/shm/*
2025-04-29 10:17:41.323436363   /var/lib/rear/output/*
Copy to Clipboard Toggle word wrap

上記の出力では、/tmp/dev/shm/var/lib/rear/output ディレクトリーの下にあるすべてのファイルとディレクトリーを除いて、ルートファイルシステム全体がバックアップの対象になります。

第2章 ログファイルを使用した問題のトラブルシューティング

ログファイルの情報は、システム機能のトラブルシューティングや監視に使用できます。ログファイルには、カーネルやシステム上で実行されているサービスやアプリケーションなど、システムに関するメッセージが含まれています。Red Hat Enterprise Linux のロギングシステムは、組み込みの syslog プロトコルに基づいています。さまざまなプログラムが syslog を使用してイベントを記録し、ログファイルに整理します。

2.1. syslog メッセージを処理するサービス

syslog メッセージを処理するサービスを以下に示します。

systemd-journald デーモン

次のソースからメッセージを収集し、さらなる処理のために Rsyslog に転送します。

  • カーネル
  • ブートプロセスの初期段階
  • 起動時および実行時のデーモンの標準出力とエラー
  • syslog
Rsyslog サービス
syslog メッセージをタイプと優先度で分類し、/var/log ディレクトリー内のファイルに書き込みます。/var/log ディレクトリーは、ログメッセージを永続的に保存します。

2.2. syslog メッセージを保存するサブディレクトリー

syslog メッセージは、/var/log ディレクトリー配下の次のサブディレクトリーに保存されます。

/var/log/messages
以下のものを除くすべての syslog メッセージ
/var/log/secure
セキュリティーおよび認証関連のメッセージとエラー
/var/log/maillog
メールサーバー関連のメッセージとエラー
/var/log/cron
定期的に実行されるタスクに関連するログファイル
/var/log/boot.log
システムの起動に関連するログファイル

2.3. ログを表示するためのコマンド

systemd のコンポーネントである Journal を使用すると、ログファイルを表示および管理できます。Journal は、従来のロギングに関連する問題に対処します。システムの他の部分と密接に統合されており、さまざまなロギングテクノロジーとログファイルへのアクセス管理をサポートします。

journalctl コマンドを使用すると、システムジャーナル内のメッセージを表示できます。次に例を示します。

$ journalctl -b | grep kvm
May 15 11:31:41 localhost.localdomain kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00
May 15 11:31:41 localhost.localdomain kernel: kvm-clock: cpu 0, msr 76401001, primary cpu clock
Copy to Clipboard Toggle word wrap

システム情報の表示

journalctl
収集されたジャーナルエントリーをすべて表示します。
journalctl FILEPATH
特定のファイルに関連するログを表示します。たとえば、journalctl /dev/sda コマンドは、/dev/sda ファイルシステムに関連するログを表示します。
journalctl -b
現在のブートのログを表示します。
journalctl -k -b -1
現在のブートのカーネルログを表示します。

特定のサービスに関する情報の表示

journalctl -b _SYSTEMD_UNIT=<name.service>
ログをフィルターして、systemd サービスに一致するエントリーを表示します。
journalctl -b _SYSTEMD_UNIT=<name.service> _PID=<number>
一致を組み合わせます。たとえば、このコマンドは、<name.service> と PID <number> に一致する systemd-units のログを表示します。
journalctl -b _SYSTEMD_UNIT=<name.service> _PID=<number> + _SYSTEMD_UNIT=<name2.service>
プラス記号 (+) セパレーターは、論理 OR で 2 つの式を組み合わせます。たとえば、このコマンドは <name.service> サービスプロセスからのすべてのメッセージを PID で表示し、(プロセスのいずれかの) <name2.service> サービスからのすべてのメッセージも表示します。
journalctl -b _SYSTEMD_UNIT=<name.service> _SYSTEMD_UNIT=<name2.service>
このコマンドは、同じフィールドを参照し、いずれかの式に一致するエントリーをすべて表示します。このコマンドは、systemd-unit <name.service> または systemd-unit <name2.service> に一致するログを表示します。

特定のブートに関連するログの表示

journalctl --list-boots
ブート番号、その ID、およびブートに関する最初のメッセージと最後のメッセージのタイムスタンプの表形式リストが表示されます。以下のコマンドの ID を使用して詳細情報を表示できます。
journalctl --boot=ID _SYSTEMD_UNIT=<name.service>
指定したブート ID に関する情報を表示します。

第3章 Web コンソールでのログ確認およびフィルタリング

Red Hat Enterprise Linux Web コンソールは、ログにアクセスし、確認し、フィルタリングするためのグラフィカルインターフェイスを提供します。対応するコマンドやオプションを記憶しなくても、最も一般的な機能を使用できます。

3.1. Web コンソールでログの確認

RHEL Web コンソールのログセクションは、journalctl ユーティリティーの UI です。Web コンソールインターフェイスで、システムログにアクセスできます。

前提条件

手順

  1. RHEL 10 Web コンソールにログインします。
  2. Logs をクリックします。

    Logs page

  3. リストからログを確認するログエントリーをクリックして、ログエントリーの詳細を開きます。
注記

Pause ボタンを使用すると、新しいログエントリーが表示されないように一時停止できます。新しいログエントリーを再開すると、Web コンソールは、Pause ボタンを使用した後に報告されたすべてのログエントリーを読み込みます。

Priority 時間、優先順位、または識別子でログをフィルタリングできます。詳細は、Web コンソールでのログの確認とフィルタリング を参照してください。

3.2. Web コンソールでのログのフィルタリング

Web コンソールでログエントリーをフィルタリングできます。

前提条件

手順

  1. RHEL 10 Web コンソールにログインします。
  2. Logs をクリックします。
  3. コンソールデフォルトでは、Web コンソールには最新のログエントリーが表示されます。別の時間範囲でフィルタリングするには、Time ドロップダウンメニューをクリックして、希望するオプションを選択します。

    cockpit logs time new

  4. 重大度ログのリストは、デフォルトで エラー以上のレベル が表示されます。優先度のフィルタリングを変更するには、ドロップダウンメニューの エラー以上のレベル をクリックして、優先度を選択します。

    cockpit logs priority

  5. デフォルトでは、Web コンソールにはすべての識別子のログが表示されます。特定のサービスのログをフィルタリングするには、All ドロップダウンメニューをクリックして、識別子を選択します。

    cockpit logs identifier

  6. ログエントリーを開くには、選択したログをクリックします。

3.3. Web コンソールでログをフィルターするためのテキスト検索オプション

テキスト検索オプション機能では、ログをフィルタリングするためのさまざまなオプションを利用できます。テキスト検索を使用してログをフィルタリングする場合は、3 つのドロップダウンメニューに定義した事前定義オプションを使用するか、自分で検索全体を入力できます。

ドロップダウンメニュー

検索のメインパラメーターを指定するのに使用できるドロップダウンメニューには、以下の 3 つがあります。

  • 時間: このドロップダウンメニューには、検索のさまざまな時間範囲が事前定義されます。
  • 優先度: このドロップダウンメニューでは、さまざまな優先度のオプションを利用できます。journalctl --priority オプションに対応します。デフォルトの優先度の値は Error and above です。これは、他の優先度を指定しないと毎回設定されます。
  • 識別子: このドロップダウンメニューでは、フィルタリングする ID を選択します。journalctl --identifier オプションに対応します。

量記号

検索を指定するのに使用できる量記号は 6 つあります。これらは、ログテーブルをフィルタリングするための Options で説明されています。

ログフィールド

特定のログフィールドを検索する場合は、フィールドとその内容を指定することができます。

ログメッセージでの自由形式のテキスト検索

ログメッセージで任意のテキスト文字列をフィルタリングできます。文字列は、正規表現の形式にすることもできます。

高度なログのフィルタリング I

2020 年 10 月 22 日深夜以降に発生した 'systemd' によって識別されるすべてのログメッセージをフィルターします。ジャーナルフィールド 'JOB_TYPE' は 'start' または 'restart' のいずれかです。

  1. フィールドを検索するには、identifier:systemd since:2020-10-22 JOB_TYPE=start,restart と入力します。
  2. 結果を確認します。

    advanced logs search I

高度なログフィルタリング II

最後の前に起動で 'cockpit.service' systemd ユニットから送信されたすべてのログメッセージ、およびメッセージのボディーに "error" または "fail" が含まれるログメッセージをすべてフィルターします。

  1. 検索フィールドに service:cockpit boot:-1 error|fail と入力します。
  2. 結果を確認します。

    advanced logs search II

3.4. テキストボックスのボックスを使用した Web コンソールでのログのフィルター

Web コンソールのテキスト検索ボックスを使用して、さまざまなパラメーターに基づいてログをフィルタリングできます。検索では、フィルタリングドロップダウンメニュー、数量詞、ログフィールド、および自由形式の文字列検索を組み合わせて使用します。

前提条件

手順

  1. RHEL 10 Web コンソールにログインします。
  2. Logs をクリックします。
  3. ドロップダウンメニューを使用して、3 つの主要なフィルタリング対象の数量 (時間範囲、優先順位、識別子) (フィルタリングする) を指定します。

    優先順位 の数量には常に値が必要です。これを指定しない場合、Error and above の優先度が自動的にフィルターされます。テキスト検索ボックスに、設定したオプションに注目してください。

  4. フィルターするログフィールドを指定します。

    ログフィールドは複数追加できます。

  5. 自由形式文字列を使用して他の文字を検索できます。検索ボックスにも正規表現も使用できます。

3.5. ログフィルタリングのオプション

Web コンソールでログをフィルタリングするには、journalctl オプションを使用できます。これらのオプションの一部は、Web コンソールインターフェイスのドロップダウンメニューの一部として提供されます。

Expand
表3.1 Table
オプション名用途備考

priority

メッセージの優先度による出力をフィルタリングします。単一数値またはテキストログレベルを取ります。ログレベルは、通常の syslog ログレベルです。単一のログレベルが指定されている場合、このログレベルまたは低い (より重要な) ログレベルを持つすべてのメッセージが表示されます。

優先順位 ドロップダウンメニューで説明されます。

identifier

指定された syslog 識別子 SYSLOG_IDENTIFIER のメッセージを表示します。複数回指定できます。

識別子 ドロップダウンメニューで説明されています。

follow

最新のジャーナルエントリーのみを表示し、ジャーナルに追加されるように新しいエントリーを継続的に出力します。

ドロップダウンで説明しません。

service

指定した systemd ユニットのメッセージを表示します。複数回指定できます。

ドロップダウンで説明されません。journalctl --unit パラメーターに対応します。

boot

特定のブートのメッセージを表示します。

正の整数はジャーナルの先頭から boots を検索し、ゼロ以下の整数はジャーナルの末尾から boots を検索します。このため、1 は、時系列順でジャーナルで見つかった最初の起動を意味し、2 は次に見つかったものと続きます。また、-0 は最後の起動、-1 は最後の起動の 1 つ前などとなります。

時間 ドロップダウンメニューでは、現在の起動 または 以前の起動 としてのみ説明されています。その他のオプションは手動で書き込む必要があります。

since

指定の日付以降のエントリーまたは指定の日付以前のエントリーを示します。日付は、"2012-10-30 18:17:16" の形式にする必要があります。時間部分を省略すると、"00:00:00" が想定されます。2 番目のコンポーネントのみを省略すると、":00" が想定されます。日付コンポーネントを省略すると、現在の日付が想定されます。"yesterday"、"today"、"tomorrow" も利用できます。それぞれ、現在の日付けの前の 00:00:00、現在の日付け、現在の日付けの後の日を参照します。"now" は、現在時刻を意味します。最後に、相対時間は"-" または "+" を前に付けてを指定できます。これは、現在時間の前または後の時間を参照します。

ドロップダウンで説明しません。

第4章 RHEL システムロールを使用した systemd ジャーナルの設定

journald RHEL システムロールを使用すると、systemd ジャーナルを自動化し、Red Hat Ansible Automation Platform を使用して永続的なロギングを設定できます。

4.1. journald RHEL システムロールを使用した永続的なロギングの設定

デフォルトでは、systemd ジャーナルは /run/log/journal 内の小さなリングバッファーにのみログを保存します。これは永続的なものではありません。システムを再起動すると、ジャーナルデータベースログも削除されます。journald RHEL システムロールを使用すると、複数のシステムで一貫して永続的なロギングを設定できます。

前提条件

手順

  1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    ---
    - name: Configure journald
      hosts: managed-node-01.example.com
      tasks:
        - name: Configure persistent logging
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.journald
          vars:
            journald_persistent: true
            journald_max_disk_size: <size>
            journald_per_user: true
            journald_sync_interval: <interval>
    Copy to Clipboard Toggle word wrap

    サンプル Playbook で指定されている設定は次のとおりです。

    journald_persistent: true
    永続的なロギングを有効にします。
    journald_max_disk_size: <size>
    ジャーナルファイルの最大ディスク領域サイズを MB 単位で指定します (例: 2048)。
    journald_per_user: true
    各ユーザーのログデータを個別に保持するように journald を設定します。
    journald_sync_interval: <interval>

    同期の間隔を分単位で設定します (例: 1)。

    Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.journald/README.md ファイルを参照してください。

  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard Toggle word wrap

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard Toggle word wrap

第5章 リモートロギングソリューションの設定

環境内の各種マシンからのログをロギングサーバーに集中的に記録するために、クライアントシステムからサーバーに特定の基準に合致するログを記録するように Rsyslog アプリケーションを設定できます。

5.1. Rsyslog ロギングサービス

Rsyslog アプリケーションは、systemd-journald サービスと組み合わせて、Red Hat Enterprise Linux でローカルおよびリモートのロギングサポートを提供します。rsyslogd デーモンは、ジャーナルから systemd-journald サービスが受信した syslog メッセージを継続的に読み取ります。rsyslogd は、syslog イベントをフィルタリングして処理し、rsyslog ログファイルに記録するか、設定に応じて他のサービスに転送します。

rsyslogd デーモンは、拡張されたフィルタリング、暗号化で保護されたメッセージのリレー、入出力モジュール、TCP プロトコルおよび UDP プロトコルを使用した転送のサポートも提供します。

rsyslog の主な設定ファイルである /etc/rsyslog.conf では、どの rsyslogd がメッセージを処理するかに応じてルールを指定できます。通常は、ソースおよびトピック (ファシリティー) 別および緊急度 (優先度) 別にメッセージを分類し、メッセージがその基準に合致したときに実行するアクションを割り当てることができます。

/etc/rsyslog.conf では、rsyslogd が維持するログファイルのリストも確認できます。ほとんどのログファイルは /var/log/ ディレクトリーにあります。httpdsamba などの一部のアプリケーションは、ログファイルを /var/log/ 内のサブディレクトリーに保存します。

5.2. Rsyslog ドキュメントのインストール

Rsyslog アプリケーションには、https://www.rsyslog.com/doc/ で利用可能な詳細なオンラインドキュメントがありますが、rsyslog-doc ドキュメントパッケージをローカルにインストールすることもできます。

前提条件

  • システムで AppStream リポジトリーをアクティベートしている。
  • sudo を使用して新規パッケージをインストールする権限がある。

手順

  • rsyslog-doc パッケージをインストールします。

    # dnf install rsyslog-doc
    Copy to Clipboard Toggle word wrap

検証

  • 任意のブラウザーで /usr/share/doc/rsyslog/html/index.html ファイルを開きます。次に例を示します。

    $ firefox /usr/share/doc/rsyslog/html/index.html &
    Copy to Clipboard Toggle word wrap

5.3. TCP でのリモートロギング用のサーバーの設定

Rsyslog アプリケーションを使用すると、ロギングサーバーを実行し、個別のシステムがログファイルをロギングサーバーに送信するように設定できます。TCP 経由でリモートロギングを使用するには、サーバーとクライアントの両方を設定します。サーバーは、クライアントシステムにより送信されたログを収集し、分析します。

Rsyslog アプリケーションを使用すると、ログメッセージがネットワークを介してサーバーに転送される中央ロギングシステムを維持できます。サーバーが利用できない場合にメッセージが失われないようにするには、転送アクションのアクションキューを設定します。これにより、送信に失敗したメッセージは、サーバーが再度到達可能になるまでローカルに保存されます。このようなキューは、UDP プロトコルを使用する接続に対しては設定できないことに注意してください。

omfwd プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。このプラグインは組み込まれているため、読み込む必要はありません。

デフォルトでは、rsyslog はポート 514 で TCP を使用します。

前提条件

  • rsyslog がサーバーシステムにインストールされている。
  • サーバーに root としてログインしている。
  • policycoreutils-python-utils パッケージは、semanage コマンドを使用して任意の手順でインストールします。
  • firewalld サービスが実行中である。

手順

  1. 必要に応じて、rsyslog トラフィックに別のポートを使用するには、SELinux タイプ syslogd_port_t をポートに追加します。たとえば、ポート 30514 を有効にします。

    # semanage port -a -t syslogd_port_t -p tcp 30514
    Copy to Clipboard Toggle word wrap
  2. 必要に応じて、rsyslog トラフィックに別のポートを使用するには、firewalld がそのポートでの着信 rsyslog トラフィックを許可するように設定します。たとえば、ポート 30514 で TCP トラフィックを許可します。

    # firewall-cmd --zone=<zone_name> --permanent --add-port=30514/tcp
    success
    # firewall-cmd --reload
    Copy to Clipboard Toggle word wrap
  3. /etc/rsyslog.d/ ディレクトリーに新規ファイル (例: remotelog.conf) を作成し、以下のコンテンツを挿入します。

    # Define templates before the rules that use them
    # Per-Host templates for remote systems
    template(name="TmplAuthpriv" type="list") {
        constant(value="/var/log/remote/auth/")
        property(name="hostname")
        constant(value="/")
        property(name="programname" SecurePath="replace")
        constant(value=".log")
        }
    
    template(name="TmplMsg" type="list") {
        constant(value="/var/log/remote/msg/")
        property(name="hostname")
        constant(value="/")
        property(name="programname" SecurePath="replace")
        constant(value=".log")
        }
    
    # Provides TCP syslog reception
    module(load="imtcp")
    
    # Adding this ruleset to process remote messages
    ruleset(name="remote1"){
         authpriv.*   action(type="omfile" DynaFile="TmplAuthpriv")
          *.info;mail.none;authpriv.none;cron.none
    action(type="omfile" DynaFile="TmplMsg")
    }
    
    input(type="imtcp" port="30514" ruleset="remote1")
    Copy to Clipboard Toggle word wrap
  4. /etc/rsyslog.d/remotelog.conf ファイルへの変更を保存します。
  5. /etc/rsyslog.conf ファイルの構文をテストします。

    # rsyslogd -N 1
    rsyslogd: version 8.1911.0-2.el8, config validation run...
    rsyslogd: End of config validation run. Bye.
    Copy to Clipboard Toggle word wrap
  6. Rsyslog サービスがロギングサーバーで実行中で、有効になっていることを確認します。

    # systemctl status rsyslog
    Copy to Clipboard Toggle word wrap
  7. rsyslog サービスを再起動します。

    # systemctl restart rsyslog
    Copy to Clipboard Toggle word wrap
  8. 必要に応じて、rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

    # systemctl enable rsyslog
    Copy to Clipboard Toggle word wrap

環境内の他のシステムからログファイルを受け取り、保存するように、ログサーバーが設定されています。

5.4. TCP 経由のサーバーへのリモートロギングの設定

TCP プロトコル経由でログメッセージをサーバーに転送するようにシステムを設定できます。omfwd プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。プラグインは組み込まれているのでロードする必要はありません。

前提条件

  • rsyslog パッケージが、サーバーに報告する必要のあるクライアントシステムにインストールされている。
  • リモートロギング用にサーバーを設定している。
  • 指定したポートが SELinux で許可され、ファイアウォールで開いている。
  • システムには、policycoreutils-python-utils パッケージが含まれています。このパッケージは、標準以外のポートを SELinux 設定に追加するための semanage コマンドを提供します。

手順

  1. /etc/rsyslog.d/ ディレクトリーに新規ファイル (例: 10-remotelog.conf) を作成し、以下のコンテンツを挿入します。

    *.* action(type="omfwd"
          queue.type="linkedlist"
          queue.filename="example_fwd"
          action.resumeRetryCount="-1"
          queue.saveOnShutdown="on"
          target="example.com" port="30514" protocol="tcp"
         )
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    • queue.type="linkedlist" 設定は、LinkedList インメモリーキューを有効にします。
    • queue.filename 設定は、ディスクストレージを定義します。バックアップファイルは、前のグローバルの workDirectory ディレクティブで指定された作業ディレクトリーに example_fwd 接頭辞を付けて作成されます。
    • action.resumeRetryCount -1 設定は、サーバーが応答しない場合に接続を再試行するときに rsyslog がメッセージを破棄しないようにします。
    • queue.saveOnShutdown="on" 設定は、rsyslog がシャットダウンした場合にインメモリーデータを保存します。
    • 最後の行は、受信したすべてのメッセージをロギングサーバーに転送します。ポートの指定は任意です。

      この設定では、rsyslog はメッセージをサーバーに送信しますが、リモートサーバーに到達できない場合には、メッセージをメモリーに保持します。ディスク上にあるファイルは、設定されたメモリーキュー領域が rsyslog で不足するか、シャットダウンする必要がある場合にのみ作成されます。これにより、システムパフォーマンスが向上します。

    注記

    Rsyslog は設定ファイル /etc/rsyslog.d/ を字句順に処理します。

  2. rsyslog サービスを再起動します。

    # systemctl restart rsyslog
    Copy to Clipboard Toggle word wrap

検証

クライアントシステムがサーバーにメッセージを送信していることを確認します。

  1. クライアントシステムで、テストメッセージを送信します。

    # logger test
    Copy to Clipboard Toggle word wrap
  2. サーバーシステムで、/var/log/messages ログを表示します。以下に例を示します。

    # cat /var/log/remote/msg/hostname/root.log
    Feb 25 03:53:17 hostname root[6064]: test
    Copy to Clipboard Toggle word wrap

    hostname はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

5.5. TLS 暗号化リモートロギングの設定

デフォルトでは、Rsyslog はプレーンテキスト形式でリモートロギング通信を送信します。シナリオでこの通信チャネルのセキュリティーを確保する必要がある場合は、TLS を使用して暗号化できます。

TLS を介した暗号化されたトランスポートを使用するには、サーバーとクライアントの両方を設定します。サーバーは、クライアントシステムにより送信されたログを収集し、分析します。

ossl ネットワークストリームドライバー (OpenSSL) または gtls ストリームドライバー (GnuTLS) のいずれかを使用できます。

注記

ネットワークに接続されていない、厳格な認可を受けているなど、セキュリティーが強化された別のシステムがある場合は、その別のシステムを認証局 (CA) として使用します。

サーバー側では globalmoduleinput レベルで、クライアント側では global および action レベルで、ストリームドライバーを使用して接続設定をカスタマイズできます。より具体的な設定は、より一般的な設定よりも優先されます。そのため、たとえば、ほとんどの接続のグローバル設定で ossl を使用し、特定の接続の入力とアクション設定で gtls を使用することができます。

前提条件

  • クライアントシステムとサーバーシステムの両方に root にアクセスできる。
  • サーバーおよびクライアントシステムに次のパッケージがインストールされている。

    • rsyslog パッケージ
    • ossl ネットワークストリームドライバー用の rsyslog-openssl パッケージ
    • gtls ネットワークストリームドライバー用の rsyslog-gnutls パッケージ
    • certtool コマンドを使用して証明書を生成するための gnutls-utils パッケージ
  • ログサーバーの /etc/pki/ca-trust/source/anchors/ ディレクトリーには、次の証明書があり、update-ca-trust コマンドを使用してシステム設定を更新します。

    • ca-cert.pem - ログサーバーとクライアントで鍵と証明書を検証できる CA 証明書。
    • server-cert.pem - ロギングサーバーの公開鍵。
    • server-key.pem - ロギングサーバーの秘密鍵。
  • ログクライアントでは、次の証明書が /etc/pki/ca-trust/source/anchors/ ディレクトリーにあり、update-ca-trust を使用してシステム設定を更新します。

    • ca-cert.pem - ログサーバーとクライアントで鍵と証明書を検証できる CA 証明書。
    • client-cert.pem - クライアントの公開鍵。
    • client-key.pem - クライアントの秘密鍵。
    • サーバーが RHEL 9.2 以降を実行し、FIPS モードが有効になっている場合、クライアントが Extended Master Secret (EMS) 拡張機能をサポートしているか、TLS 1.3 を使用している必要があります。EMS を使用しない TLS 1.2 接続は失敗します。詳細は、TLS extension "Extended Master Secret" enforced 記事 (Red Hat ナレッジベース) を参照してください。

手順

  1. クライアントシステムから暗号化したログを受信するようにサーバーを設定します。

    1. /etc/rsyslog.d/ ディレクトリーに、新規ファイル (securelogser.conf など) を作成します。
    2. 通信を暗号化するには、設定ファイルに、サーバーの証明書ファイルへのパス、選択した認証方法、および TLS 暗号化に対応するストリームドライバーが含まれている必要があります。/etc/rsyslog.d/securelogser.conf に以下の行を追加します。

      # Set certificate files
      global(
        DefaultNetstreamDriverCAFile="/etc/pki/ca-trust/source/anchors/ca-cert.pem"
        DefaultNetstreamDriverCertFile="/etc/pki/ca-trust/source/anchors/server-cert.pem"
        DefaultNetstreamDriverKeyFile="/etc/pki/ca-trust/source/anchors/server-key.pem"
      )
      
      # TCP listener
      module(
        load="imtcp"
        PermittedPeer=["client1.example.com", "client2.example.com"]
        StreamDriver.AuthMode="x509/name"
        StreamDriver.Mode="1"
        StreamDriver.Name="ossl"
      )
      
      # Start up listener at port 514
      input(
        type="imtcp"
        port="514"
      )
      Copy to Clipboard Toggle word wrap
      注記

      GnuTLS ドライバーが必要な場合は、StreamDriver.Name="gtls" 設定オプションを使用します。x509/name よりも厳密ではない認証モードの詳細は、rsyslog-doc にインストールされているドキュメントを参照してください。

    3. オプション: 接続設定をカスタマイズするには、input セクションを次のものに置き換えます。

      input(
        type="imtcp"
        Port="50515"
        StreamDriver.Name="<driver>"
        streamdriver.CAFile="/etc/rsyslog.d/<ca1>.pem"
        streamdriver.CertFile="/etc/rsyslog.d/<server1_cert>.pem"
        streamdriver.KeyFile="/etc/rsyslog.d/<server1_key>.pem"
      )
      Copy to Clipboard Toggle word wrap
      • 使用するドライバーに応じて、<driver>ossl または gtls に置き換えます。
      • <ca1> は CA 証明書に、<server1_cert> は証明書に、<server1_key> はカスタマイズされた接続の鍵に、それぞれ置き換えます。
    4. 変更を /etc/rsyslog.d/securelogser.conf ファイルに保存します。
    5. /etc/rsyslog.conf ファイルの構文と /etc/rsyslog.d/ ディレクトリー内のすべてのファイルを確認します。

      # rsyslogd -N 1
      rsyslogd: version 8.1911.0-2.el8, config validation run (level 1)...
      rsyslogd: End of config validation run. Bye.
      Copy to Clipboard Toggle word wrap
    6. Rsyslog サービスがロギングサーバーで実行中で、有効になっていることを確認します。

      # systemctl status rsyslog
      Copy to Clipboard Toggle word wrap
    7. rsyslog サービスを再起動します。

      # systemctl restart rsyslog
      Copy to Clipboard Toggle word wrap
    8. オプション: Rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動されることを確認してください。

      # systemctl enable rsyslog
      Copy to Clipboard Toggle word wrap
  2. 暗号化したログをサーバーに送信するようにクライアントを設定するには、以下のコマンドを実行します。

    1. クライアントシステムで、/etc/rsyslog.d/ ディレクトリーに、新規ファイル (securelogcli.conf など) を作成します。
    2. /etc/rsyslog.d/securelogcli.conf に以下の行を追加します。

      # Set certificate files
      global(
        DefaultNetstreamDriverCAFile="/etc/pki/ca-trust/source/anchors/ca-cert.pem"
        DefaultNetstreamDriverCertFile="/etc/pki/ca-trust/source/anchors/client-cert.pem"
        DefaultNetstreamDriverKeyFile="/etc/pki/ca-trust/source/anchors/client-key.pem"
      )
      
      
      # Set up the action for all messages
      *.* action(
        type="omfwd"
        StreamDriver="ossl"
        StreamDriverMode="1"
        StreamDriverPermittedPeers="server.example.com"
        StreamDriverAuthMode="x509/name"
        target="server.example.com" port="514" protocol="tcp"
      )
      Copy to Clipboard Toggle word wrap
      注記

      GnuTLS ドライバーが必要な場合は、StreamDriver.Name="gtls" 設定オプションを使用します。

    3. オプション: 接続設定をカスタマイズするには、action セクションを次のものに置き換えます。

      local1.* action(
        type="omfwd"
        StreamDriver="<driver>"
        StreamDriverMode="1"
        StreamDriverAuthMode="x509/certvalid"
        streamDriver.CAFile="/etc/rsyslog.d/<ca1>.pem"
        streamDriver.CertFile="/etc/rsyslog.d/<client1_cert>.pem"
        streamDriver.KeyFile="/etc/rsyslog.d/<client1_key>.pem"
        target="server.example.com" port="514" protocol="tcp"
        )
      Copy to Clipboard Toggle word wrap
      • 使用するドライバーに応じて、<driver>ossl または gtls に置き換えます。
      • <ca1> は CA 証明書に、<client1_cert> は証明書に、<client1_key> はカスタマイズされた接続の鍵に、それぞれ置き換えます。
    4. 変更を /etc/rsyslog.d/securelogcli.conf ファイルに保存します。
    5. /etc/rsyslog.conf ファイルの構文と /etc/rsyslog.d/ ディレクトリー内のその他のファイルを確認します。

      # rsyslogd -N 1
      rsyslogd: version 8.1911.0-2.el8, config validation run (level 1)...
      rsyslogd: End of config validation run. Bye.
      Copy to Clipboard Toggle word wrap
    6. Rsyslog サービスがロギングサーバーで実行中で、有効になっていることを確認します。

      # systemctl status rsyslog
      Copy to Clipboard Toggle word wrap
    7. rsyslog サービスを再起動します。

      # systemctl restart rsyslog
      Copy to Clipboard Toggle word wrap
    8. オプション: Rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動されることを確認してください。

      # systemctl enable rsyslog
      Copy to Clipboard Toggle word wrap

検証

クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。

  1. クライアントシステムで、テストメッセージを送信します。

    # logger test
    Copy to Clipboard Toggle word wrap
  2. サーバーシステムで、/var/log/messages ログを表示します。以下に例を示します。

    # cat /var/log/remote/msg/<hostname>/root.log
    Feb 25 03:53:17 <hostname> root[6064]: test
    Copy to Clipboard Toggle word wrap

    <hostname> はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

5.6. UDP でリモートロギング情報を受信するためのサーバー設定

Rsyslog アプリケーションを使用すると、リモートシステムからロギング情報を受信するようにシステムを設定できます。UDP 経由でリモートロギングを使用するには、サーバーとクライアントの両方を設定します。受信サーバーは、クライアントシステムが送信したログの収集および分析を行います。デフォルトでは、rsyslog はポート 514 で UDP を使用して、リモートシステムからログ情報を受信します。

以下の手順に従って、UDP プロトコルでクライアントシステムが送信したログの収集および分析を行うサーバーを設定します。

前提条件

  • rsyslog がサーバーシステムにインストールされている。
  • サーバーに root としてログインしている。
  • policycoreutils-python-utils パッケージは、semanage コマンドを使用して任意の手順でインストールします。
  • firewalld サービスが実行中である。

手順

  1. 必要に応じて、デフォルトのポート 514 以外の rsyslog トラフィックに別のポートを使用するには、次のコマンドを実行します。

    1. SELinux ポリシー設定に syslogd_port_t SELinux タイプを追加し、portnorsyslog で使用するポート番号に置き換えます。

      # semanage port -a -t syslogd_port_t -p udp portno
      Copy to Clipboard Toggle word wrap
    2. rsyslog の受信トラフィックを許可するように firewalld を設定します。portno はポート番号に、zonersyslog が使用するゾーンに置き換えます。

      # firewall-cmd --zone=zone --permanent --add-port=portno/udp
      success
      # firewall-cmd --reload
      Copy to Clipboard Toggle word wrap
    3. ファイアウォールルールを再読み込みします。

      # firewall-cmd --reload
      Copy to Clipboard Toggle word wrap
  2. /etc/rsyslog.d/ ディレクトリーに .conf の新規ファイル (例: remotelogserv.conf) を作成し、以下のコンテンツを挿入します。

    # Define templates before the rules that use them
    # Per-Host templates for remote systems
    template(name="TmplAuthpriv" type="list") {
        constant(value="/var/log/remote/auth/")
        property(name="hostname")
        constant(value="/")
        property(name="programname" SecurePath="replace")
        constant(value=".log")
        }
    
    template(name="TmplMsg" type="list") {
        constant(value="/var/log/remote/msg/")
        property(name="hostname")
        constant(value="/")
        property(name="programname" SecurePath="replace")
        constant(value=".log")
        }
    
    # Provides UDP syslog reception
    module(load="imudp")
    
    # This ruleset processes remote messages
    ruleset(name="remote1"){
         authpriv.*   action(type="omfile" DynaFile="TmplAuthpriv")
          *.info;mail.none;authpriv.none;cron.none
    action(type="omfile" DynaFile="TmplMsg")
    }
    
    input(type="imudp" port="514" ruleset="remote1")
    Copy to Clipboard Toggle word wrap

    514 は、rsyslog がデフォルトで使用するポート番号です。代わりに別のポートを指定できます。

  3. /etc/rsyslog.conf ファイルの構文と /etc/rsyslog.d/ ディレクトリー内の全 .conf ファイルを確認します。

    # rsyslogd -N 1
    rsyslogd: version 8.1911.0-2.el8, config validation run...
    Copy to Clipboard Toggle word wrap
  4. rsyslog サービスを再起動します。

    # systemctl restart rsyslog
    Copy to Clipboard Toggle word wrap
  5. 必要に応じて、rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

    # systemctl enable rsyslog
    Copy to Clipboard Toggle word wrap

5.7. UDP 経由のサーバーへのリモートロギングの設定

UDP プロトコル経由でログメッセージをサーバーに転送するようにシステムを設定できます。omfwd プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。プラグインは組み込まれているのでロードする必要はありません。

前提条件

手順

  1. /etc/rsyslog.d/ ディレクトリーに .conf の新規ファイル (例: 10-remotelogcli.conf) を作成し、以下のコンテンツを挿入します。

    *.* action(type="omfwd"
          queue.type="linkedlist"
          queue.filename="example_fwd"
          action.resumeRetryCount="-1"
          queue.saveOnShutdown="on"
          target="example.com" port="portno" protocol="udp"
         )
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    • queue.type="linkedlist" 設定は、LinkedList インメモリーキューを有効にします。
    • queue.filename 設定は、ディスクストレージを定義します。バックアップファイルは、前のグローバルの workDirectory ディレクティブで指定された作業ディレクトリーに example_fwd 接頭辞を付けて作成されます。
    • action.resumeRetryCount -1 設定は、サーバーが応答しない場合に接続を再試行するときに rsyslog がメッセージを破棄しないようにします。
    • queue.saveOnShutdown="on" 設定を有効にすると、rsyslog がシャットダウンした場合にインメモリーデータが保存されます。
    • portno 値は、rsyslog で使用するポート番号です。デフォルト値は 514 です。
    • 最後の行は受信メッセージをすべてロギングサーバーに転送します。ポートの指定は任意です。

      この設定では、rsyslog はメッセージをサーバーに送信しますが、リモートサーバーに到達できない場合には、メッセージをメモリーに保持します。ディスク上にあるファイルは、設定されたメモリーキュー領域が rsyslog で不足するか、シャットダウンする必要がある場合にのみ作成されます。これにより、システムパフォーマンスが向上します。

    注記

    Rsyslog は設定ファイル /etc/rsyslog.d/ を字句順に処理します。

  2. rsyslog サービスを再起動します。

    # systemctl restart rsyslog
    Copy to Clipboard Toggle word wrap
  3. 必要に応じて、rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

    # systemctl enable rsyslog
    Copy to Clipboard Toggle word wrap

検証

クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。

  1. クライアントシステムで、テストメッセージを送信します。

    # logger test
    Copy to Clipboard Toggle word wrap
  2. サーバーシステムで、/var/log/remote/msg/hostname/root.log ログを表示します。以下に例を示します。

    # cat /var/log/remote/msg/hostname/root.log
    Feb 25 03:53:17 hostname root[6064]: test
    Copy to Clipboard Toggle word wrap

    hostname はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

5.8. Rsyslog の負荷分散ヘルパー

Rsyslog をクラスターで使用する場合、RebindInterval 設定を変更することで Rsyslog の負荷分散を改善できます。

RebindInterval では、現在の接続を切断して再確立する間隔を指定します。この設定は、TCP、UDP、および RELP のトラフィックに適用されます。ロードバランサーはこれを新しい接続と認識し、メッセージを別の物理ターゲットシステムに転送します。

RebindInterval は、ターゲットシステムの IP アドレスが変更された場合に役立ちます。Rsyslog アプリケーションは、接続の確立時に IP アドレスをキャッシュするため、メッセージは同じサーバーに送信されます。IP アドレスが変更されると、Rsyslog サービスが再起動するまで UDP パケットが失われます。接続を再確立すると、IP が DNS により再度解決されます。

TCP、UDP、および RELP トラフィックに対する RebindInterval の使用例

action(type="omfwd" protocol="tcp" RebindInterval="250" target="example.com" port="514" …)

action(type="omfwd" protocol="udp" RebindInterval="250" target="example.com" port="514" …)

action(type="omrelp" RebindInterval="250" target="example.com" port="6514" …)
Copy to Clipboard Toggle word wrap

5.9. 信頼できるリモートロギングの設定

Reliable Event Logging Protocol (RELP) を使用すると、メッセージ損失のリスクを大幅に軽減して TCP で syslog メッセージを送受信できます。RELP は、信頼できるイベントメッセージを配信するので、メッセージ損失が許されない環境で有用です。RELP を使用するには、imrelp の入力モジュール (サーバー上での実行とログの受信) と omrelp 出力モジュール (クライアント上での実行とロギングサーバーへのログの送信) を設定します。

前提条件

  • rsyslog パッケージ、librelp パッケージ、および rsyslog-relp パッケージをサーバーおよびクライアントシステムにインストールしている。
  • 指定したポートが SELinux で許可され、ファイアウォール設定で開放されている。

手順

  1. 信頼できるリモートロギング用にクライアントシステムを設定します。

    1. クライアントシステムの /etc/rsyslog.d/ ディレクトリーに、relpclient.conf などと名前を指定して新しい .conf ファイルを作成し、以下のコンテンツを挿入します。

      module(load="omrelp")
      *.* action(type="omrelp" target="_target_IP_" port="_target_port_")
      Copy to Clipboard Toggle word wrap

      ここでは、以下のようになります。

      • target_IP は、ロギングサーバーの IP アドレスに置き換えます。
      • target_port はロギングサーバーのポートに置き換えます。
    2. 変更を /etc/rsyslog.d/relpclient.conf ファイルに保存します。
    3. rsyslog サービスを再起動します。

      # systemctl restart rsyslog
      Copy to Clipboard Toggle word wrap
    4. 必要に応じて、rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

      # systemctl enable rsyslog
      Copy to Clipboard Toggle word wrap
  2. 信頼できるリモートロギング用にサーバーシステムを設定します。

    1. サーバーシステムの /etc/rsyslog.d/ ディレクトリーに、relpserv.conf などと名前を指定して新しい .conf ファイルを作成し、以下のコンテンツを挿入します。

      ruleset(name="relp"){
      *.* action(type="omfile" file="_log_path_")
      }
      
      
      module(load="imrelp")
      input(type="imrelp" port="_target_port_" ruleset="relp")
      Copy to Clipboard Toggle word wrap

      ここでは、以下のようになります。

      • log_path は、メッセージを保存するパスを指定します。
      • target_port はロギングサーバーのポートに置き換えます。クライアント設定ファイルと同じ値を使用します。
    2. /etc/rsyslog.d/relpserv.conf ファイルへの変更を保存します。
    3. rsyslog サービスを再起動します。

      # systemctl restart rsyslog
      Copy to Clipboard Toggle word wrap
    4. 必要に応じて、rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

      # systemctl enable rsyslog
      Copy to Clipboard Toggle word wrap

検証

クライアントシステムがサーバーにメッセージを送信していることを確認します。

  1. クライアントシステムで、テストメッセージを送信します。

    # logger test
    Copy to Clipboard Toggle word wrap
  2. サーバーシステムで、指定された log_path でログを表示します。以下に例を示します。

    # cat /var/log/remote/msg/hostname/root.log
    Feb 25 03:53:17 hostname root[6064]: test
    Copy to Clipboard Toggle word wrap

    hostname はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

5.10. サポート対象の Rsyslog モジュール

Rsyslog アプリケーションの機能を拡張するために、特定のモジュールを使用できます。モジュールは、追加の入力 (入力モジュール)、出力 (出力モジュール)、およびその他の機能を提供します。モジュールは、モジュールの読み込み後に利用可能な設定ディレクティブを追加で提供することも可能です。

以下のコマンドを使用して、システムにインストールされている入出力モジュールをリスト表示できます。

# ls /usr/lib64/rsyslog/{i,o}m*
Copy to Clipboard Toggle word wrap

rsyslog-doc パッケージをインストールした後、/usr/share/doc/rsyslog/html/configuration/modules/idx_output.html ファイルで使用可能なすべての rsyslog モジュールのリストを表示できます。

5.11. カーネルメッセージをリモートホストに記録するように netconsole サービスを設定

ディスクへのログインやシリアルコンソールの使用ができない場合は、netconsole カーネルモジュールおよび同じ名前のサービスを使用して、ネットワーク経由でカーネルメッセージをリモートの rsyslog サービスに記録できます。

前提条件

  • rsyslog などのシステムログサービスがリモートホストにインストールされている。
  • リモートシステムログサービスは、このホストから受信ログエントリーを受け取るように設定されています。

手順

  1. netconsole-service パッケージをインストールします。

    # dnf install netconsole-service
    Copy to Clipboard Toggle word wrap
  2. /etc/sysconfig/netconsole ファイルを編集し、SYSLOGADDR パラメーターをリモートホストの IP アドレスに設定します。

    # SYSLOGADDR=192.0.2.1
    Copy to Clipboard Toggle word wrap
  3. netconsole サービスを有効にして起動します。

    # systemctl enable --now netconsole
    Copy to Clipboard Toggle word wrap

検証

  • リモートシステムログサーバーの /var/log/messages ファイルを表示します。

第6章 RHEL システムロールを使用したロギングの設定

logging RHEL システムロールを使用すると、ローカルホストとリモートホストをロギングサーバーとして自動的に設定し、多数のクライアントシステムからログを収集できます。

ロギングソリューションは、ログと複数のロギング出力を読み取る複数の方法を提供します。

たとえば、ロギングシステムは以下の入力を受け取ることができます。

  • ローカルファイル
  • systemd/journal
  • ネットワーク上の別のロギングシステム

さらに、ロギングシステムでは以下を出力できます。

  • /var/log/ ディレクトリーのローカルファイルに保存されるログ
  • Elasticsearch エンジンに送信されるログ
  • 別のロギングシステムに転送されるログ

logging RHEL システムロールを使用すると、状況に合わせて入力と出力を組み合わせることができます。たとえば、journal からの入力をローカルのファイルに保存しつつも、複数のファイルから読み込んだ入力を別のロギングシステムに転送してそのローカルのログファイルに保存するようにロギングソリューションを設定できます。

6.1. logging RHEL システムロールを使用したローカルログメッセージのフィルタリング

logging RHEL システムロールのプロパティーベースのフィルターを使用すると、さまざまな条件に基づいてローカルログメッセージをフィルタリングできます。その結果、たとえば以下を実現できます。

  • 明確なログ: トラフィック量の多い環境では、ログが急増することがあります。エラーなどの特定のメッセージに注目することで、問題をより早く特定できるようになります。
  • システムパフォーマンスの最適化: ログの量が多すぎると、通常、システムパフォーマンスが低下します。重要なイベントのみを選択的にログに記録することで、リソースの枯渇を防ぎ、システムをより効率的に運用できます。
  • セキュリティーの強化: システムエラーやログイン失敗などのセキュリティーメッセージを効率的にフィルタリングすることで、関連するログのみを取得できます。これは、違反を検出し、コンプライアンス基準を満たすために重要です。

前提条件

手順

  1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    ---
    - name: Deploy the logging solution
      hosts: managed-node-01.example.com
      tasks:
        - name: Filter logs based on a specific value they contain
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.logging
          vars:
            logging_inputs:
              - name: files_input
                type: basics
            logging_outputs:
              - name: files_output0
                type: files
                property: msg
                property_op: contains
                property_value: error
                path: /var/log/errors.log
              - name: files_output1
                type: files
                property: msg
                property_op: "!contains"
                property_value: error
                path: /var/log/others.log
            logging_flows:
              - name: flow0
                inputs: [files_input]
                outputs: [files_output0, files_output1]
    Copy to Clipboard Toggle word wrap

    サンプル Playbook で指定されている設定は次のとおりです。

    logging_inputs
    ロギングの入力ディクショナリーのリストを定義します。type: basics オプションを指定すると、systemd ジャーナルまたは Unix ソケットからの入力が対象になります。
    logging_outputs
    ロギングの出力ディクショナリーのリストを定義します。type: files オプションにより、ローカルファイル (通常は /var/log/ ディレクトリー内) にログを保存できます。property: msgproperty: contains、および property_value: error オプションを指定すると、error 文字列を含むすべてのログが /var/log/errors.log ファイルに保存されます。property: msgproperty: !contains、および property_value: error オプションを指定すると、他のすべてのログが /var/log/others.log ファイルに保存されます。error 値は、フィルタリングする必要がある文字列に置き換えることができます。
    logging_flows
    ロギングのフローディクショナリーのリストを定義して、logging_inputslogging_outputs の関係を指定します。inputs: [files_input] オプションは、ログの処理を開始する入力のリストを指定します。outputs: [files_output0, files_output1] オプションは、ログ送信先の出力のリストを指定します。

    Playbook で使用されるすべての変数の詳細と rsyslog の詳細は、/usr/share/ansible/roles/rhel-system-roles.logging/README.md ファイルと、コントロールノードの rsyslog.conf(5) および syslog(3) man ページを参照してください。

  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard Toggle word wrap

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard Toggle word wrap

検証

  1. 管理対象ノードで、/etc/rsyslog.conf ファイルの構文をテストします。

    # rsyslogd -N 1
    rsyslogd: version 8.1911.0-6.el8, config validation run...
    rsyslogd: End of config validation run. Bye.
    Copy to Clipboard Toggle word wrap
  2. 管理対象ノードで、システムが error 文字列を含むメッセージをログに送信することを確認します。

    1. テストメッセージを送信します。

      # logger error
      Copy to Clipboard Toggle word wrap
    2. 以下のように /var/log/errors.log ログを表示します。

      # cat /var/log/errors.log
      Aug  5 13:48:31 hostname root[6778]: error
      Copy to Clipboard Toggle word wrap

      hostname はクライアントシステムのホスト名に置き換えます。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

6.2. logging RHEL システムロールを使用したリモートロギングソリューションの適用

logging RHEL システムロールを使用して、1 つ以上のクライアントで systemd-journal サービスからログを取得し、リモートサーバーに転送するリモートロギングソリューションを設定できます。このサーバーは、remote_rsyslog および remote_files 設定からリモート入力を受け取り、リモートホスト名によって指定されたディレクトリー内のローカルファイルにログを出力します。

その結果、たとえば次のようなユースケースに対応できます。

  • ログの集中管理: 複数のマシンのログメッセージを 1 つのストレージポイントから収集、アクセス、管理することで、日々の監視とトラブルシューティングのタスクが簡素化されます。また、このユースケースでは、ログメッセージを確認するために個々のマシンにログインする必要性が軽減されます。
  • セキュリティーの強化: ログメッセージを 1 カ所に集中して保存すると、セキュアで改ざん不可能な環境にログを保存しやすくなります。このような環境により、セキュリティーインシデントをより効果的に検出して対応し、監査要件を満たすことが容易になります。
  • ログ分析の効率向上: 複数のマシンまたはサービスにまたがる複雑な問題を迅速にトラブルシューティングするには、複数のシステムからのログメッセージを相関させることが重要です。これにより、さまざまなソースからのイベントをすばやく分析し、相互参照することができます。

前提条件

手順

  1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    ---
    - name: Deploy the logging solution
      hosts: managed-node-01.example.com
      tasks:
        - name: Configure the server to receive remote input
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.logging
          vars:
            logging_inputs:
              - name: remote_udp_input
                type: remote
                udp_ports: [ 601 ]
              - name: remote_tcp_input
                type: remote
                tcp_ports: [ 601 ]
            logging_outputs:
              - name: remote_files_output
                type: remote_files
            logging_flows:
              - name: flow_0
                inputs: [remote_udp_input, remote_tcp_input]
                outputs: [remote_files_output]
    
    - name: Deploy the logging solution
      hosts: managed-node-02.example.com
      tasks:
        - name: Configure the server to output the logs to local files in directories named by remote host names
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.logging
          vars:
            logging_inputs:
              - name: basic_input
                type: basics
            logging_outputs:
              - name: forward_output0
                type: forwards
                severity: info
                target: <host1.example.com>
                udp_port: 601
              - name: forward_output1
                type: forwards
                facility: mail
                target: <host1.example.com>
                tcp_port: 601
            logging_flows:
              - name: flows0
                inputs: [basic_input]
                outputs: [forward_output0, forward_output1]
    Copy to Clipboard Toggle word wrap

    サンプル Playbook の最初のプレイで指定されている設定は次のとおりです。

    logging_inputs
    ロギングの入力ディクショナリーのリストを定義します。type: remote オプションを指定すると、ネットワークを介した他のロギングシステムからのリモート入力が対象になります。udp_ports: [ 601 ] オプションは、監視する UDP ポート番号のリストを定義します。tcp_ports: [ 601 ] オプションは、監視する TCP ポート番号のリストを定義します。udp_portstcp_ports の両方が設定されている場合、udp_ports が使用され、tcp_ports は削除されます。
    logging_outputs
    ロギングの出力ディクショナリーのリストを定義します。type: remote_files オプションを指定すると、ログの送信元であるリモートホストとプログラム名ごとに、出力がローカルファイルに保存されます。
    logging_flows
    ロギングのフローディクショナリーのリストを定義して、logging_inputslogging_outputs の関係を指定します。inputs: [remote_udp_input、remote_tcp_input] オプションは、ログの処理を開始する入力のリストを指定します。outputs: [remote_files_output] オプションは、ログ送信先の出力のリストを指定します。

    サンプル Playbook の 2 番目のプレイで指定されている設定は次のとおりです。

    logging_inputs
    ロギングの入力ディクショナリーのリストを定義します。type: basics オプションを指定すると、systemd ジャーナルまたは Unix ソケットからの入力が対象になります。
    logging_outputs
    ロギングの出力ディクショナリーのリストを定義します。type: forwards オプションにより、ネットワーク経由でリモートログサーバーにログを送信できます。severity: info オプションは、重大度が情報のログメッセージを示します。facility: mail オプションは、ログメッセージを生成するシステムプログラムの種類を示します。target: <host1.example.com> オプションは、リモートログサーバーのホスト名を指定します。udp_port: 601/tcp_port: 601 オプションは、リモートログサーバーがリッスンする UDP/TCP ポートを定義します。
    logging_flows
    ロギングのフローディクショナリーのリストを定義して、logging_inputslogging_outputs の関係を指定します。inputs: [basic_input] オプションは、ログの処理を開始する入力のリストを指定します。outputs: [forward_output0, forward_output1] オプションは、ログ送信先の出力のリストを指定します。

    ロール変数の詳細と rsyslog の詳細は、/usr/share/ansible/roles/rhel-system-roles.logging/README.md ファイルと、コントロールノードの rsyslog.conf(5) および syslog(3) man ページを参照してください。

  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard Toggle word wrap

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard Toggle word wrap

検証

  1. クライアントとサーバーシステムの両方で、/etc/rsyslog.conf ファイルの構文をテストします。

    # rsyslogd -N 1
    rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf
    rsyslogd: End of config validation run. Bye.
    Copy to Clipboard Toggle word wrap
  2. クライアントシステムがサーバーにメッセージを送信することを確認します。

    1. クライアントシステムで、テストメッセージを送信します。

      # logger test
      Copy to Clipboard Toggle word wrap
    2. サーバーシステムで、/var/log/<host2.example.com>/messages ログを表示します。次に例を示します。

      # cat /var/log/<host2.example.com>/messages
      Aug  5 13:48:31 <host2.example.com> root[6778]: test
      Copy to Clipboard Toggle word wrap

      <host2.example.com> は、クライアントシステムのホスト名に置き換えます。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

6.3. TLS を使用した logging RHEL システムロールの使用

Transport Layer Security (TLS) は、コンピューターネットワーク上でセキュアな通信を可能にするために設計された暗号化プロトコルです。

RHEL システムロールの logging を使用すると、ログメッセージのセキュアな転送を設定して、1 つ以上のクライアントで systemd-journal サービスからログを取得し、TLS を使用してリモートサーバーに転送できます。

通常、リモートロギングソリューションでログを転送するための TLS は、インターネットなどの信頼性の低いネットワークやパブリックネットワーク経由で機密データを送信する場合に使用されます。また、TLS で証明書を使用することで、クライアントから正しい信頼できるサーバーにログを確実に転送できます。これにより、"中間者攻撃" などの攻撃を防ぐことができます。

6.3.1. TLS を使用したクライアントロギングの設定

logging RHEL システムロールを使用すると、RHEL クライアントでのロギングを設定し、TLS 暗号化を使用してログをリモートロギングシステムに転送できます。

この手順では、秘密鍵と証明書を作成します。その後、Ansible インベントリーのクライアントグループ内の全ホストに TLS を設定します。TLS プロトコルは、メッセージ送信を暗号化し、ネットワーク経由でログを安全に転送します。

注記

証明書を作成するために、Playbook で certificate RHEL システムロールを呼び出す必要はありません。このロールは、logging_certificates 変数が設定されている場合、logging RHEL システムロールによって自動的に呼び出されます。

CA が作成された証明書に署名できるようにするには、管理対象ノードが IdM ドメインに登録されている必要があります。

前提条件

  • コントロールノードと管理対象ノードの準備が完了している。
  • 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
  • 管理対象ノードへの接続に使用するアカウントに、そのノードに対する sudo 権限がある。
  • 管理対象ノードが IdM ドメインに登録されている。
  • 管理対象ノード上で設定するロギングサーバーが RHEL 9.2 以降を実行し、FIPS モードが有効になっている場合、クライアントが Extended Master Secret (EMS) 拡張機能をサポートしているか、TLS 1.3 を使用している。EMS を使用しない TLS 1.2 接続は失敗します。詳細は、Red Hat ナレッジベースソリューション TLS extension "Extended Master Secret" enforced を参照してください。

手順

  1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    ---
    - name: Configure remote logging solution by using TLS for secure transfer of logs
      hosts: managed-node-01.example.com
      tasks:
        - name: Deploying files input and forwards output with certs
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.logging
          vars:
            logging_certificates:
              - name: logging_cert
                dns: ['www.example.com']
                ca: ipa
                principal: "logging/{{ inventory_hostname }}@IDM.EXAMPLE.COM"
            logging_pki_files:
              - ca_cert: /local/path/to/ca_cert.pem
                cert: /local/path/to/logging_cert.pem
                private_key: /local/path/to/logging_cert.pem
            logging_inputs:
              - name: input_name
                type: files
                input_log_path: /var/log/containers/*.log
            logging_outputs:
              - name: output_name
                type: forwards
                target: your_target_host
                tcp_port: 514
                tls: true
                pki_authmode: x509/name
                permitted_server: 'server.example.com'
            logging_flows:
              - name: flow_name
                inputs: [input_name]
                outputs: [output_name]
    Copy to Clipboard Toggle word wrap

    サンプル Playbook で指定されている設定は次のとおりです。

    logging_certificates
    このパラメーターの値は、certificate RHEL システムロールの certificate_requests に渡され、秘密鍵と証明書の作成に使用されます。
    logging_pki_files

    このパラメーターを使用すると、TLS に使用する CA、証明書、および鍵ファイルを検索するためにロギングで使用するパスとその他の設定 (サブパラメーター ca_certca_cert_srccertcert_srcprivate_keyprivate_key_src、および tls で指定) を設定できます。

    注記

    logging_certificates を使用して管理対象ノードにファイルを作成する場合は、ca_cert_srccert_src、および private_key_src を使用しないでください。これらは、logging_certificates によって作成されていないファイルのコピーに使用されます。

    ca_cert
    管理対象ノード上の CA 証明書ファイルへのパスを表します。デフォルトのパスは /etc/pki/tls/certs/ca.pem で、ファイル名はユーザーが設定します。
    cert
    管理対象ノード上の証明書ファイルへのパスを表します。デフォルトのパスは /etc/pki/tls/certs/server-cert.pem で、ファイル名はユーザーが設定します。
    private_key
    管理対象ノード上の秘密鍵ファイルへのパスを表します。デフォルトのパスは /etc/pki/tls/private/server-key.pem で、ファイル名はユーザーが設定します。
    ca_cert_src
    ターゲットホストの ca_cert で指定された場所にコピーされる、コントロールノード上の CA 証明書ファイルへのパスを表します。logging_certificates を使用する場合は、これを使用しないでください。
    cert_src
    ターゲットホストの cert で指定された場所にコピーされる、コントロールノード上の証明書ファイルへのパスを表します。logging_certificates を使用する場合は、これを使用しないでください。
    private_key_src
    ターゲットホストの private_key で指定された場所にコピーされる、コントロールノード上の秘密鍵ファイルへのパスを表します。logging_certificates を使用する場合は、これを使用しないでください。
    tls
    このパラメーターを true に設定すると、ネットワーク上でログがセキュアに転送されます。セキュアなラッパーが必要ない場合は、tls: false に設定します。

    ロール変数の詳細と rsyslog の詳細は、/usr/share/ansible/roles/rhel-system-roles.logging/README.md ファイルと、コントロールノードの rsyslog.conf(5) および syslog(3) man ページを参照してください。

  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard Toggle word wrap

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard Toggle word wrap

6.3.2. TLS を使用したサーバーロギングの設定

logging RHEL システムロールを使用すると、RHEL サーバーでのロギングを設定し、TLS 暗号化を使用してリモートロギングシステムからログを受信するようにサーバーを設定できます。

この手順では、秘密鍵と証明書を作成します。その後、Ansible インベントリーのサーバーグループ内の全ホストに TLS を設定します。

注記

証明書を作成するために、Playbook で certificate RHEL システムロールを呼び出す必要はありません。logging RHEL システムロールがこのロールを自動的に呼び出します。

CA が作成された証明書に署名できるようにするには、管理対象ノードが IdM ドメインに登録されている必要があります。

前提条件

  • コントロールノードと管理対象ノードの準備が完了している。
  • 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
  • 管理対象ノードへの接続に使用するアカウントに、そのノードに対する sudo 権限がある。
  • 管理対象ノードが IdM ドメインに登録されている。
  • 管理対象ノード上で設定するロギングサーバーが RHEL 9.2 以降を実行し、FIPS モードが有効になっている場合、クライアントが Extended Master Secret (EMS) 拡張機能をサポートしているか、TLS 1.3 を使用している。EMS を使用しない TLS 1.2 接続は失敗します。詳細は、Red Hat ナレッジベースソリューション TLS extension "Extended Master Secret" enforced を参照してください。

手順

  1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    ---
    - name: Configure remote logging solution by using TLS for secure transfer of logs
      hosts: managed-node-01.example.com
      tasks:
        - name: Deploying remote input and remote_files output with certs
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.logging
          vars:
            logging_certificates:
              - name: logging_cert
                dns: ['www.example.com']
                ca: ipa
                principal: "logging/{{ inventory_hostname }}@IDM.EXAMPLE.COM"
            logging_pki_files:
              - ca_cert: /local/path/to/ca_cert.pem
                cert: /local/path/to/logging_cert.pem
                private_key: /local/path/to/logging_cert.pem
            logging_inputs:
              - name: input_name
                type: remote
                tcp_ports: [514]
                tls: true
                permitted_clients: ['clients.example.com']
            logging_outputs:
              - name: output_name
                type: remote_files
                remote_log_path: /var/log/remote/%FROMHOST%/%PROGRAMNAME:::secpath-replace%.log
                async_writing: true
                client_count: 20
                io_buffer_size: 8192
            logging_flows:
              - name: flow_name
                inputs: [input_name]
                outputs: [output_name]
    Copy to Clipboard Toggle word wrap

    サンプル Playbook で指定されている設定は次のとおりです。

    logging_certificates
    このパラメーターの値は、certificate RHEL システムロールの certificate_requests に渡され、秘密鍵と証明書の作成に使用されます。
    logging_pki_files

    このパラメーターを使用すると、TLS に使用する CA、証明書、および鍵ファイルを検索するためにロギングで使用するパスとその他の設定 (サブパラメーター ca_certca_cert_srccertcert_srcprivate_keyprivate_key_src、および tls で指定) を設定できます。

    注記

    logging_certificates を使用して管理対象ノードにファイルを作成する場合は、ca_cert_srccert_src、および private_key_src を使用しないでください。これらは、logging_certificates によって作成されていないファイルのコピーに使用されます。

    ca_cert
    管理対象ノード上の CA 証明書ファイルへのパスを表します。デフォルトのパスは /etc/pki/tls/certs/ca.pem で、ファイル名はユーザーが設定します。
    cert
    管理対象ノード上の証明書ファイルへのパスを表します。デフォルトのパスは /etc/pki/tls/certs/server-cert.pem で、ファイル名はユーザーが設定します。
    private_key
    管理対象ノード上の秘密鍵ファイルへのパスを表します。デフォルトのパスは /etc/pki/tls/private/server-key.pem で、ファイル名はユーザーが設定します。
    ca_cert_src
    ターゲットホストの ca_cert で指定された場所にコピーされる、コントロールノード上の CA 証明書ファイルへのパスを表します。logging_certificates を使用する場合は、これを使用しないでください。
    cert_src
    ターゲットホストの cert で指定された場所にコピーされる、コントロールノード上の証明書ファイルへのパスを表します。logging_certificates を使用する場合は、これを使用しないでください。
    private_key_src
    ターゲットホストの private_key で指定された場所にコピーされる、コントロールノード上の秘密鍵ファイルへのパスを表します。logging_certificates を使用する場合は、これを使用しないでください。
    tls
    このパラメーターを true に設定すると、ネットワーク上でログがセキュアに転送されます。セキュアなラッパーが必要ない場合は、tls: false に設定します。

    ロール変数の詳細と rsyslog の詳細は、/usr/share/ansible/roles/rhel-system-roles.logging/README.md ファイルと、コントロールノードの rsyslog.conf(5) および syslog(3) man ページを参照してください。

  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard Toggle word wrap

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard Toggle word wrap

6.4. RELP で logging RHEL システムロールの使用

Reliable Event Logging Protocol (RELP) とは、TCP ネットワークを使用する、データとメッセージロギング用のネットワーキングプロトコルのことです。イベントメッセージを確実に配信するので、メッセージの損失が許されない環境で使用できます。

RELP の送信側はコマンド形式でログエントリーを転送し、受信側は処理後に確認応答します。RELP は、一貫性を保つために、転送されたコマンドごとにトランザクション番号を保存し、各種メッセージの復旧します。

RELP Client と RELP Server の間に、リモートロギングシステムを検討することができます。RELP Client はリモートロギングシステムにログを転送し、RELP Server はリモートロギングシステムから送信されたすべてのログを受け取ります。このユースケースを実現するには、logging RHEL システムロールを使用して、ログエントリーが確実に送受信されるようにロギングシステムを設定できます。

6.4.1. RELP を使用したクライアントロギングの設定

logging RHEL システムロールを使用すると、ローカルに保存されたログメッセージを RELP を使用してリモートロギングシステムに転送するように設定できます。

この手順では、Ansible インベントリーの clients グループ内の全ホストに RELP を設定します。RELP 設定は Transport Layer Security (TLS) を使用して、メッセージ送信を暗号化し、ネットワーク経由でログを安全に転送します。

前提条件

手順

  1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    ---
    - name: Configure client-side of the remote logging solution by using RELP
      hosts: managed-node-01.example.com
      tasks:
        - name: Deploy basic input and RELP output
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.logging
          vars:
            logging_inputs:
              - name: basic_input
                type: basics
            logging_outputs:
              - name: relp_client
                type: relp
                target: logging.server.com
                port: 20514
                tls: true
                ca_cert: /etc/pki/tls/certs/ca.pem
                cert: /etc/pki/tls/certs/client-cert.pem
                private_key: /etc/pki/tls/private/client-key.pem
                pki_authmode: name
                permitted_servers:
                  - '*.server.example.com'
            logging_flows:
              - name: example_flow
                inputs: [basic_input]
                outputs: [relp_client]
    Copy to Clipboard Toggle word wrap

    サンプル Playbook で指定されている設定は次のとおりです。

    target
    リモートロギングシステムが稼働しているホスト名を指定する必須パラメーターです。
    port
    リモートロギングシステムがリッスンしているポート番号です。
    tls

    ネットワーク上でログをセキュアに転送します。セキュアなラッパーが必要ない場合は、tls 変数を false に設定します。デフォルトでは tls パラメーターは true に設定されますが、RELP を使用する場合には鍵/証明書およびトリプレット {ca_certcertprivate_key} や {ca_cert_srccert_srcprivate_key_src} が必要です。

    • {ca_cert_srccert_srcprivate_key_src} のトリプレットを設定すると、デフォルトの場所 (/etc/pki/tls/certs/etc/pki/tls/private) が、コントロールノードからファイルを転送するため、管理対象ノードの宛先として使用されます。この場合、ファイル名はトリプレットの元の名前と同じです。
    • {ca_certcertprivate_key} トリプレットが設定されている場合は、ファイルはロギング設定の前にデフォルトのパスに配置されている必要があります。
    • トリプレットの両方が設定されている場合には、ファイルはコントロールノードのローカルのパスから管理対象ノードの特定のパスへ転送されます。
    ca_cert
    CA 証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/ca.pem で、ファイル名はユーザーが設定します。
    cert
    証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/server-cert.pem で、ファイル名はユーザーが設定します。
    private_key
    秘密鍵へのパスを表します。デフォルトのパスは /etc/pki/tls/private/server-key.pem で、ファイル名はユーザーが設定します。
    ca_cert_src
    ローカルの CA 証明書ファイルパスを表します。これは管理対象ノードにコピーされます。ca_cert を指定している場合は、その場所にコピーされます。
    cert_src
    ローカルの証明書ファイルパスを表します。これは管理対象ノードにコピーされます。cert を指定している場合には、その証明書が場所にコピーされます。
    private_key_src
    ローカルキーファイルのパスを表します。これは管理対象ノードにコピーされます。private_key を指定している場合は、その場所にコピーされます。
    pki_authmode
    name または fingerprint の認証モードを使用できます。
    permitted_servers
    ロギングクライアントが、TLS 経由での接続およびログ送信を許可するサーバーのリスト。
    inputs
    ロギング入力ディクショナリーのリスト。
    outputs
    ロギング出力ディクショナリーのリスト。

    ロール変数の詳細と rsyslog の詳細は、/usr/share/ansible/roles/rhel-system-roles.logging/README.md ファイルと、コントロールノードの rsyslog.conf(5) および syslog(3) man ページを参照してください。

  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard Toggle word wrap

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard Toggle word wrap

6.4.2. RELP を使用したサーバーログの設定

logging RHEL システムロールを使用すると、ログメッセージを RELP を使用してリモートロギングシステムから受信するようにサーバーを設定できます。

以下の手順では、Ansible インベントリーの server グループ内の全ホストに RELP を設定します。RELP 設定は TLS を使用して、メッセージ送信を暗号化し、ネットワーク経由でログを安全に転送します。

前提条件

手順

  1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    ---
    - name: Configure server-side of the remote logging solution by using RELP
      hosts: managed-node-01.example.com
      tasks:
        - name: Deploying remote input and remote_files output
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.logging
          vars:
            logging_inputs:
              - name: relp_server
                type: relp
                port: 20514
                tls: true
                ca_cert: /etc/pki/tls/certs/ca.pem
                cert: /etc/pki/tls/certs/server-cert.pem
                private_key: /etc/pki/tls/private/server-key.pem
                pki_authmode: name
                permitted_clients:
                  - '*client.example.com'
            logging_outputs:
              - name: remote_files_output
                type: remote_files
            logging_flows:
              - name: example_flow
                inputs: [relp_server]
                outputs: [remote_files_output]
    Copy to Clipboard Toggle word wrap

    サンプル Playbook で指定されている設定は次のとおりです。

    port
    リモートロギングシステムがリッスンしているポート番号です。
    tls

    ネットワーク上でログをセキュアに転送します。セキュアなラッパーが必要ない場合は、tls 変数を false に設定します。デフォルトでは tls パラメーターは true に設定されますが、RELP を使用する場合には鍵/証明書およびトリプレット {ca_certcertprivate_key} や {ca_cert_srccert_srcprivate_key_src} が必要です。

    • {ca_cert_srccert_srcprivate_key_src} のトリプレットを設定すると、デフォルトの場所 (/etc/pki/tls/certs/etc/pki/tls/private) が、コントロールノードからファイルを転送するため、管理対象ノードの宛先として使用されます。この場合、ファイル名はトリプレットの元の名前と同じです。
    • {ca_certcertprivate_key} トリプレットが設定されている場合は、ファイルはロギング設定の前にデフォルトのパスに配置されている必要があります。
    • トリプレットの両方が設定されている場合には、ファイルはコントロールノードのローカルのパスから管理対象ノードの特定のパスへ転送されます。
    ca_cert
    CA 証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/ca.pem で、ファイル名はユーザーが設定します。
    cert
    証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/server-cert.pem で、ファイル名はユーザーが設定します。
    private_key
    秘密鍵へのパスを表します。デフォルトのパスは /etc/pki/tls/private/server-key.pem で、ファイル名はユーザーが設定します。
    ca_cert_src
    ローカルの CA 証明書ファイルパスを表します。これは管理対象ノードにコピーされます。ca_cert を指定している場合は、その場所にコピーされます。
    cert_src
    ローカルの証明書ファイルパスを表します。これは管理対象ノードにコピーされます。cert を指定している場合には、その証明書が場所にコピーされます。
    private_key_src
    ローカルキーファイルのパスを表します。これは管理対象ノードにコピーされます。private_key を指定している場合は、その場所にコピーされます。
    pki_authmode
    name または fingerprint の認証モードを使用できます。
    permitted_clients
    ロギングサーバーが TLS 経由での接続およびログ送信を許可するクライアントのリスト。
    inputs
    ロギング入力ディクショナリーのリスト。
    outputs
    ロギング出力ディクショナリーのリスト。

    ロール変数の詳細と rsyslog の詳細は、/usr/share/ansible/roles/rhel-system-roles.logging/README.md ファイルと、コントロールノードの rsyslog.conf(5) および syslog(3) man ページを参照してください。

  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard Toggle word wrap

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard Toggle word wrap

第7章 システムの監査

Audit は、追加のセキュリティー機能をシステムに提供するのではありません。システムで使用されるセキュリティーポリシーの違反を発見するために使用できます。このような違反は、SELinux などの別のセキュリティー対策で防ぐことができます。

7.1. Linux の Audit

Linux Audit を使用すると、システムのセキュリティー関連情報を追跡できます。事前に設定されたルールに従って、監査はログエントリーを生成し、システムで発生しているイベントに関する可能な限り多くの情報を記録します。この情報は、ミッションクリティカルな環境でセキュリティーポリシーの違反者と、違反者によるアクションを判断する上で必須のものです。

監査では、次のような情報をログファイルに記録できます。

  • イベントの日時、タイプ、結果
  • サブジェクトとオブジェクトの機密性のラベル
  • イベントを開始したユーザーの ID とイベントの関連性
  • Audit 設定の全修正および Audit ログファイルへのアクセス試行
  • SSH、Kerberos などの認証メカニズムのすべての使用
  • 信頼できるデータベース (/etc/passwd など) への変更
  • システムからの情報のインポート、およびシステムへの情報のエクスポートの試行
  • ユーザー ID、サブジェクトとオブジェクトのラベルなどの属性に基づくイベントの追加と除外

Audit システムの使用は、多くのセキュリティー関連の認定における要件でもあります。Audit は、以下の認定またはコンプライアンスガイドの要件に合致するか、それを超えるように設計されています。

  • Controlled Access Protection Profile (CAPP)
  • Labeled Security Protection Profile (LSPP)
  • Rule Set Base Access Control (RSBAC)
  • NISPOM (National Industrial Security Program Operating Manual)
  • Federal Information Security Management Act (FISMA)
  • Payment Card Industry - Data Security Standard (PCI-DSS)
  • Security Technical Implementation Guides (STIG)

監査は、National Information Assurance Partnership (NIAP) および Best Security Industries (BSI) によっても評価されています。

ユースケース

ファイルアクセスの監視
Audit は、ファイルやディレクトリーがアクセス、修正、または実行されたか、もしくはファイル属性が変更されたかを追跡できます。これはたとえば、重要なファイルへのアクセスを検出し、これらのファイルが破損した場合に監査証跡を入手可能とする際に役に立ちます。
システムコールの監視
Audit は、一部のシステムコールが使用されるたびにログエントリーを生成するように設定できます。これを使用すると、settimeofdayclock_adjtime、その他の時間関連のシステムコールを監視することで、システム時間への変更を追跡できます。
ユーザーが実行したコマンドの記録
Audit はファイルが実行されたかどうかを追跡できるため、特定のコマンドの実行を毎回記録するようにルールを定義できます。たとえば、/bin ディレクトリー内のすべての実行可能ファイルにルールを定義できます。これにより作成されるログエントリーをユーザー ID で検索すると、ユーザーごとに実行されたコマンドの監査証跡を生成できます。
システムのパス名の実行の記録
ルールの呼び出し時にパスを inode に変換するファイルアクセスをウォッチする以外に、ルールの呼び出し時に存在しない場合や、ルールの呼び出し後にファイルが置き換えられた場合でも、Audit がパスの実行をウォッチできるようになりました。これにより、ルールは、プログラム実行ファイルをアップグレードした後、またはインストールされる前にも機能を継続できます。
セキュリティーイベントの記録
pam_faillock 認証モジュールは、失敗したログイン試行を記録できます。Audit で失敗したログイン試行も記録するように設定すると、ログインを試みたユーザーに関する追加情報が提供されます。
イベントの検索
Audit は ausearch ユーティリティーを提供します。これを使用すると、ログエントリーをフィルターにかけ、いくつかの条件に基づく完全な監査証跡を提供できます。
サマリーレポートの実行
aureport ユーティリティーを使用すると、記録されたイベントのデイリーレポートを生成できます。システム管理者は、このレポートを分析し、疑わしいアクティビティーをさらに調べることができます。
ネットワークアクセスの監視
nftablesiptables、および ebtables ユーティリティーは、Audit イベントを発生するように設定できるため、システム管理者がネットワークアクセスを監視できるようになります。
注記

収集される情報の量によっては、監査によってシステムのパフォーマンスが影響を受ける可能性があります。

7.2. Audit システムのアーキテクチャー

Audit システムは、ユーザー空間アプリケーションおよびユーティリティーと、カーネル側のシステムコール処理という 2 つの主要部分で構成されます。カーネルコンポーネントは、ユーザー空間アプリケーションからシステムコールを受け、これを usertaskfstype、または exit のいずれかのフィルターで振り分けます。

システムコールが exclude フィルターを通過すると、前述のフィルターのいずれかに送られます。このフィルターにより、Audit ルール設定に基づいてシステムコールが Audit デーモンに送信され、さらに処理されます。

ユーザー空間の Audit デーモンは、カーネルから情報を収集し、ログファイルのエントリーを作成します。他のユーザー空間ユーティリティーは、Audit デーモン、カーネルの Audit コンポーネント、または Audit ログファイルと相互作用します。

  • auditctl Audit 制御ユーティリティーはカーネル Audit コンポーネントと相互作用し、ルールを管理するだけでなくイベント生成プロセスの多くの設定やパラメーターも制御します。
  • 残りの Audit ユーティリティーは、Audit ログファイルのコンテンツを入力として受け取り、ユーザーの要件に基づいて出力を生成します。たとえば、aureport ユーティリティーは、記録された全イベントのレポートを生成します。

RHEL 10 では、Audit dispatcher デーモン (audisp) 機能は、Audit デーモン (auditd) に統合されています。監査イベントと、リアルタイムの分析プログラムの相互作用に使用されるプラグイン設定ファイルは、デフォルトで /etc/audit/plugins.d/ ディレクトリーに保存されます。

7.3. 安全な環境のための監査設定

デフォルトの auditd 設定は、ほとんどの環境に適しています。ただし、環境が厳格なセキュリティーポリシーを満たす必要がある場合は、/etc/audit/auditd.conf ファイル内の Audit デーモン設定の次の設定を変更できます。

log_file
Audit ログファイル (通常は /var/log/audit/) を保持するディレクトリーは、別のマウントポイントにマウントされている必要があります。これにより、その他のプロセスがこのディレクトリー内の領域を使用しないようにし、Audit デーモンの残りの領域を正確に検出します。
max_log_file
1 つの Audit ログファイルの最大サイズを指定します。Audit ログファイルを保持するパーティションで利用可能な領域をすべて使用するように設定する必要があります。max_log_file パラメーターは、最大ファイルサイズをメガバイト単位で指定します。指定する値は、数値にする必要があります。
max_log_file_action
max_log_file に設定した制限に達すると実行するアクションを指定します。Audit ログファイルが上書きされないように keep_logs に設定する必要があります。
space_left
space_left_action パラメーターに設定したアクションが発生するディスクの空き容量を指定します。管理者は、ディスクの領域を反映して解放するのに十分な時間を設定する必要があります。space_left の値は、Audit ログファイルが生成される速度によって異なります。space_left の値が整数として指定されている場合は、メガバイト (MiB) 単位の絶対サイズとして解釈されます。値が 1 〜 99 の数値の後にパーセント記号を付けて指定されている場合 (5% など)、Audit デーモンは、log_file を含むファイルシステムのサイズに基づいて、メガバイト単位で絶対サイズを計算します。
space_left_action
space_left_action パラメーターは、適切な通知方法 (email または exec) に設定することが推奨されます。
admin_space_left
admin_space_left_action パラメーターに設定したアクションが発生するディスクの空き領域の最小サイズ。管理者が実行するアクションのログを記録するのに十分なサイズを残す必要があります。このパラメーターの数値は、space_left の数値より小さくする必要があります。また、数値にパーセント記号を追加 (1% など) して、Audit デーモンが、ディスクパーティションサイズに基づいて、数値を計算するようにすることもできます。
admin_space_left_action
single を、システムをシングルユーザーモードにし、管理者がディスク領域を解放できるようにします。
disk_full_action
Audit ログファイルが含まれるパーティションに空き領域がない場合に発生するアクションを指定します (halt または single に設定する必要があります)。これにより、Audit がイベントをログに記録できなくなると、システムは、シングルユーザーモードでシャットダウンまたは動作します。
disk_error_action
Audit ログファイルが含まれるパーティションでエラーが検出された場合に発生するアクションを指定します。このパラメーターは、ハードウェアの機能不全処理に関するローカルのセキュリティーポリシーに基づいて、syslogsinglehalt のいずれかに設定する必要があります。
flush
incremental_async に設定する必要があります。これは freq パラメーターと組み合わせて機能します。これは、ハードドライブとのハード同期を強制する前にディスクに送信できるレコードの数を指定します。freq パラメーターは 100 に設定する必要があります。このパラメーターにより、アクティビティーが集中した際に高いパフォーマンスを保ちつつ、Audit イベントデータがディスクのログファイルと確実に同期されるようになります。

残りの設定オプションは、ローカルのセキュリティーポリシーに合わせて設定します。

7.4. auditd の開始および制御

auditd が設定されたら、サービスを起動して Audit 情報を収集し、ログファイルに保存します。root ユーザーで次のコマンドを実行し、auditd を起動します。

# service auditd start
Copy to Clipboard Toggle word wrap

システムの起動時に auditd が起動するように設定するには、次のコマンドを実行します。

# systemctl enable auditd
Copy to Clipboard Toggle word wrap

# auditctl -e 0auditd を一時的に無効にし、# auditctl -e 1 で再度有効にできます。

service Auditd <action> コマンドを使用すると、auditd で他のアクションを実行できます。<action> は次のいずれかです。

stop
auditd を停止します。
restart
auditd を再起動します。
reload または force-reload
/etc/audit/auditd.conf ファイルから auditd の設定を再ロードします。
rotate
/var/log/audit/ ディレクトリーのログファイルをローテーションします。
resume
Audit イベントのログが一旦停止した後、再開します。たとえば、Audit ログファイルが含まれるディスクパーティションの未使用領域が不足している場合などです。
condrestart または try-restart
auditd がすでに起動している場合にのみ、これを再起動します。
status
auditd の稼働状況を表示します。
注記

service コマンドは、auditd デーモンと正しく相互作用する唯一の方法です。auid 値が適切に記録されるように、service コマンドを使用する必要があります。systemctl コマンドは、enablestatus の 2 つのアクションにのみ使用できます。

7.5. 監査ログエントリー

デフォルトでは、Audit システムはログエントリーを /var/log/audit/audit.log ファイルに保存します。ログローテーションが有効になっていれば、ローテーションされた audit.log ファイルは同じディレクトリーに保存されます。

下記の Audit ルールを追加して、/etc/ssh/sshd_config ファイルの読み取りまたは修正の試行をすべてログに記録します。

# auditctl -w /etc/ssh/sshd_config -p warx -k sshd_config
Copy to Clipboard Toggle word wrap

auditd デーモンが実行している場合は、たとえば次のコマンドを使用して、Audit ログファイルに新しいイベントを作成します。

$ cat /etc/ssh/sshd_config
Copy to Clipboard Toggle word wrap

このイベントは、audit.log ファイルでは以下のようになります。

type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sshd_config"
type=CWD msg=audit(1364481363.243:24287):  cwd="/home/shadowman"
type=PATH msg=audit(1364481363.243:24287): item=0 name="/etc/ssh/sshd_config" inode=409248 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0  nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=PROCTITLE msg=audit(1364481363.243:24287) : proctitle=636174002F6574632F7373682F737368645F636F6E666967
Copy to Clipboard Toggle word wrap

上記のイベントは 4 つのレコードで構成されており、タイムスタンプとシリアル番号を共有します。レコードは、常に type= で始まります。各レコードは、スペースまたはコンマで区切られた複数の名前と値のペア (name=value ) で構成されます。上記のイベントの詳細な分析は以下のようになります。

1 つ目のレコード

type=SYSCALL
type フィールドには、レコードのタイプが記載されます。この例の SYSCALL 値は、カーネルへのシステムコールによりこれが記録されたことを示しています。
msg=audit(1364481363.243:24287):

msg フィールドには以下が記録されます。

  • audit(time_stamp:ID) 形式のレコードのタイムスタンプおよび一意の ID。複数のレコードが同じ Audit イベントの一部として生成されている場合は、同じタイムスタンプおよび ID を共有できます。タイムスタンプは Unix の時間形式です (1970 年 1 月 1 日 00:00:00 UTC からの秒数)。
  • カーネル空間およびユーザー空間のアプリケーションが提供するさまざまなイベント固有の name=value ペア。
arch=c000003e
arch フィールドには、システムの CPU アーキテクチャーに関する情報が含まれます。c000003e の値は 16 進数表記で記録されます。ausearch コマンドを使用して監査レコードを検索する場合は、-i または --interpret オプションを使用して、16 進数値を人間が判読できる値に自動的に変換します。c000003e 値は x86_64 として解釈されます。
syscall=2
syscall フィールドは、カーネルに送信されたシステムコールのタイプを記録します。値が 2 の場合は、/usr/include/asm/unistd_64.h ファイルに、人間が判読できる値を指定できます。この場合の 2 は、オープン なシステムコールです。ausyscall ユーティリティーを使用すると、システムコール番号を人間が判読できる形式に変換できることに注意してください。ausyscall --dump コマンドを使用して、すべてのシステムコールとその番号のリストを表示します。詳細は、ausyscall(8) の man ページを参照してください。
success=no
success フィールドは、その特定のイベントで記録されたシステムコールが成功したかどうかを記録します。この例では、呼び出しが成功しませんでした。
exit=-13

exit フィールドには、システムコールが返した終了コードを指定する値が含まれます。この値は、システムコールにより異なります。次のコマンドを実行すると、この値を人間が判読可能なものに変換できます。

# ausearch --interpret --exit -13
Copy to Clipboard Toggle word wrap

この例では、監査ログに、終了コード -13 で失敗したイベントが含まれていることが前提となります。

a0=7fffd19c5592, a1=0, a2=7fffd19c5592, a3=a
a0 から a3 までのフィールドは、このイベントにおけるシステムコールの最初の 4 つの引数を、16 進法で記録します。これらの引数は、使用されるシステムコールに応じて異なります。ausearch ユーティリティで解釈できます。
items=1
items フィールドには、システムコールのレコードに続く PATH 補助レコードの数が含まれます。
ppid=2686
ppid フィールドは、親プロセス ID (PPID) を記録します。この例では、2686 は、bash などの親プロセスの PPID です。
pid=3538
pid フィールドは、プロセス ID (PID) を記録します。この例の 3538cat プロセスの PID です。
auid=1000
auid フィールドには、loginuid である Audit ユーザー ID が記録されます。この ID はログイン時にユーザーに割り当てられ、su - john などのコマンドでユーザーアカウントを切り替えてユーザーのアイデンティティーが変更された場合でも、すべてのプロセスに継承されます。
uid=1000
uid フィールドは、解析しているプロセスを開始したユーザーのユーザー ID を記録します。ausearch -i --uid UID のコマンドを使用して、ユーザー ID をユーザー名に変換できます。
gid=1000
gid フィールドは、解析しているプロセスを開始したユーザーのグループ ID を記録します。
euid=1000
euid フィールドは、解析しているプロセスを開始したユーザーの実効ユーザー ID を記録します。
suid=1000
suid フィールドは、解析しているプロセスを開始したユーザーのセットユーザー ID を記録します。
fsuid=1000
fsuid フィールドは、解析しているプロセスを開始したユーザーのファイルシステムユーザー ID を記録します。
egid=1000
egid フィールドは、解析しているプロセスを開始したユーザーの実効グループ ID を記録します。
sgid=1000
sgid フィールドは、解析しているプロセスを開始したユーザーのセットグループ ID を記録します。
fsgid=1000
fsgid フィールドは、解析しているプロセスを開始したユーザーのファイルシステムグループ ID を記録します。
tty=pts0
tty フィールドは、解析しているプロセスが開始したターミナルを記録します。
ses=1
ses フィールドは、解析しているプロセスが開始したセッションのセッション ID を記録します。
comm="cat"
comm フィールドは、解析しているプロセスを開始するために使用したコマンドのコマンドライン名を記録します。この例では、この Audit イベントを発生するのに、cat コマンドが使用されました。
exe="/bin/cat"
exe フィールドは、解析しているプロセスを開始するために使用した実行可能ファイルへのパスを記録します。
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
subj フィールドは、解析しているプロセスの実行時にラベル付けされた SELinux コンテンツを記録します。
key="sshd_config"
key フィールドは、Audit ログでこのイベントを生成したルールに関連付けられている管理者による定義の文字列を記録します。

2 つ目のレコード

type=CWD

2 つ目のレコードの type フィールドの値は、CWD (現在の作業ディレクトリー) です。このタイプは、最初のレコードで指定されたシステムコールを開始したプロセスの作業ディレクトリーを記録するために使用されます。

この記録の目的は、相対パスが関連する PATH 記録に保存された場合に、現行プロセスの位置を記録することにあります。これにより、絶対パスを再構築できます。

msg=audit(1364481363.243:24287)
msg フィールドは、最初のレコードと同じタイムスタンプと ID の値を保持します。タイムスタンプは Unix の時間形式です (1970 年 1 月 1 日 00:00:00 UTC からの秒数)。
cwd="/home/user_name"
cwd フィールドは、システムコールが開始したディレクトリーのパスになります。

3 つ目のレコード

type=PATH
3 つ目のレコードでは、type フィールドの値は PATH です。Audit イベントには、システムコールに引数として渡されたすべてのパスに PATH タイプのレコードが含まれます。この Audit イベントでは、1 つのパス (/etc/ssh/sshd_config) のみが引数として使用されます。
msg=audit(1364481363.243:24287):
msg フィールドは、1 つ目と 2 つ目のレコードと同じタイムスタンプと ID になります。
item=0
item フィールドは、SYSCALL タイプレコードで参照されているアイテムの合計数のうち、現在のレコードがどのアイテムであるかを示します。この数はゼロベースで、0 は最初の項目であることを示します。
name="/etc/ssh/sshd_config"
name フィールドは、システムコールに引数として渡されたファイルまたはディレクトリーのパスを記録します。この場合、これは /etc/ssh/sshd_config ファイルです。
inode=409248

inode フィールドには、このイベントで記録されたファイルまたはディレクトリーに関連する inode 番号が含まれます。以下のコマンドは、inode 番号 409248 に関連するファイルまたはディレクトリーを表示します。

# find / -inum 409248 -print
/etc/ssh/sshd_config
Copy to Clipboard Toggle word wrap
dev=fd:00
dev フィールドは、このイベントで記録されたファイルまたはディレクトリーを含むデバイスのマイナーおよびメジャーの ID を指定します。ここでは、値が /dev/fd/0 デバイスを示しています。
mode=0100600
mode フィールドは、ファイルまたはディレクトリーのパーミッションを、st_mode フィールドの stat コマンドが返す数字表記で記録します。詳細は、stat(2) の man ページを参照してください。この場合、0100600-rw------- と解釈され、root ユーザーのみが /etc/ssh/sshd_config ファイルへの読み取りおよび書き込み権限を持つことを意味します。
ouid=0
ouid フィールドは、オブジェクトの所有者のユーザー ID を記録します。
ogid=0
ogid フィールドは、オブジェクトの所有者のグループ ID を記録します。
rdev=00:00
rdev フィールドには、特定ファイルにのみ記録されたデバイス識別子が含まれます。ここでは、記録されたファイルは通常のファイルであるため、このフィールドは使用されません。
obj=system_u:object_r:etc_t:s0
obj フィールドは、実行時に、記録されているファイルまたはディレクトリーにラベル付けする SELinux コンテキストを記録します。
nametype=NORMAL
nametype フィールドは、指定したシステムコールのコンテキストで各パスのレコード操作の目的を記録します。
cap_fp=none
cap_fp フィールドは、ファイルまたはディレクトリーオブジェクトで許可されたファイルシステムベースの機能の設定に関連するデータを記録します。
cap_fi=none
cap_fi フィールドは、ファイルまたはディレクトリーオブジェクトの継承されたファイルシステムベースの機能の設定に関するデータを記録します。
cap_fe=0
cap_fe フィールドは、ファイルまたはディレクトリーオブジェクトのファイルシステムベースの機能の有効ビットの設定を記録します。
cap_fver=0
cap_fver フィールドは、ファイルまたはディレクトリーオブジェクトのファイルシステムベースの機能のバージョンを記録します。

4 つ目のレコード

type=PROCTITLE
type フィールドには、レコードのタイプが記載されます。この例の PROCTITLE 値は、このレコードにより、カーネルへのシステムコールにより発生するこの監査イベントを発生させた完全なコマンドラインを提供することが指定されることを示しています。
proctitle=636174002F6574632F7373682F737368645F636F6E666967
proctitle フィールドは、解析しているプロセスを開始するために使用したコマンドのコマンドラインを記録します。このフィールドは 16 進数の表記で記録され、Audit ログパーサーに影響が及ばないようにします。このテキストは、この Audit イベントを開始したコマンドに復号します。ausearch コマンドを使用して監査レコードを検索する場合は、-i または --interpret オプションを使用して、16 進数値を人間が判読できる値に自動的に変換します。636174002F6574632F7373682F737368645F636F6E666967 値は、cat /etc/ssh/sshd_config として解釈されます。

7.6. Auditctl で定義された監査ルールの例

Audit システムは、ログファイルで取得するものを定義する一連のルールで動作します。Audit ルールは、auditctl ユーティリティーを使用してコマンドラインで設定するか、/etc/audit/rules.d/ ディレクトリーで設定できます。

auditctl コマンドを使用すると、Audit システムの基本的な機能を制御し、どの Audit イベントをログに記録するかを指定するルールを定義できます。

ファイルシステムのルールの例

  1. すべての書き込みアクセスと /etc/passwd ファイルのすべての属性変更をログに記録するルールを定義するには、次のコマンドを実行します。

    # auditctl -w /etc/passwd -p wa -k passwd_changes
    Copy to Clipboard Toggle word wrap
  2. すべての書き込みアクセスと、/etc/selinux/ ディレクトリー内の全ファイルへのアクセスと、その属性変更をすべてログに記録するルールを定義するには、次のコマンドを実行します。

    # auditctl -w /etc/selinux/ -p wa -k selinux_changes
    Copy to Clipboard Toggle word wrap

システムロールのルールの例

  1. システムで 64 ビットアーキテクチャーが使用され、システムコールの adjtimex または settimeofday がプログラムにより使用されるたびにログエントリーを作成するルールを定義するには、次のコマンドを実行します。

    # auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
    Copy to Clipboard Toggle word wrap
  2. ユーザー ID が 1000 以上のシステムユーザーがファイルを削除したりファイル名を変更するたびに、ログエントリーを作成するルールを定義するには、次のコマンドを実行します。

    # auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete
    Copy to Clipboard Toggle word wrap

    -F auid!=4294967295 オプションが、ログイン UID が設定されていないユーザーを除外するために使用されています。

実行可能なファイルルール

/bin/id プログラムのすべての実行をログに取得するルールを定義するには、次のコマンドを実行します。

# auditctl -a always,exit -F exe=/bin/id -F arch=b64 -S execve -k execution_bin_id
Copy to Clipboard Toggle word wrap

7.7. 永続的なルールを監査する

再起動後も持続するように Audit ルールを定義するには、/etc/audit/rules.d/audit.rules ファイルに直接追加するか、/etc/audit/rules.d/ ディレクトリーにあるルールを読み込む augenrules プログラムを使用する必要があります。

auditd サービスを開始すると、/etc/audit/audit.rules ファイルが生成されることに注意してください。/etc/audit/rules.d/ のファイルは、同じ auditctl コマンドライン構文を使用してルールを指定します。ハッシュ記号 (#) に続く空の行とテキストは無視されます。

また、auditctl コマンドは、以下のように -R オプションを使用して指定したファイルからルールを読み込むのに使用することもできます。

# auditctl -R /usr/share/audit/sample-rules/30-stig.rules
Copy to Clipboard Toggle word wrap

augenrules スクリプトは、/etc/audit/rules.d/ ディレクトリーにあるルールを読み込み、audit.rules ファイルにコンパイルします。このスクリプトは、自然なソート順序の特定の順番で、.rules で終わるすべてのファイルを処理します。このディレクトリーのファイルは、以下の意味を持つグループに分類されます。

10
カーネルと auditctl の設定
20
一般的なルールと一致する可能性があるが、別の一致が必要なルール
30
主なルール
40
オプションのルール
50
サーバー固有のルール
70
システムのローカルルール
90
ファイナライズ (イミュータブル)

ルールは、すべてを一度に使用することは意図されていません。これらは、よく検討して、個別にファイルとして /etc/audit/rules.d/ にコピーする必要があるポリシーの一部です。たとえば、STIG 設定でシステムを設定するには、10-base-config30-stig31-privileged、および 99-finalize の各ルールをコピーします。

/etc/audit/rules.d/ ディレクトリーにルールを保存したら、--load ディレクティブで augenrules スクリプトを実行して読み込みます。

# augenrules --load
/sbin/augenrules: No change
No rules
enabled 1
failure 1
pid 742
rate_limit 0
...
Copy to Clipboard Toggle word wrap

7.8. 標準に準拠するための事前設定された監査ルールファイル

特定の認定標準 (OSPP、PCI DSS、STIG など) に準拠するように Audit を設定するには、audit パッケージとともにインストールされる事前設定済みルールファイルのセットを出発点として使用できます。サンプルルールは、/usr/share/audit/sample-rules ディレクトリーにあります。

警告

セキュリティー標準は動的であり、変更される可能性があるため、sample-rules ディレクトリー内の Audit サンプルルールは網羅的なものではなく、最新のものでもありません。これらのルールは、Audit ルールがどのように構造化および記述されるかを示すためにのみ提供されています。これらは、最新のセキュリティー標準に即時に準拠することを保証するものではありません。特定のセキュリティーガイドラインに従ってシステムを最新のセキュリティー標準に準拠させるには、SCAP ベースのセキュリティーコンプライアンスツール を使用してください。

30-nispom.rules
「National Industrial Security Program Operating Manual」の「Information System Security」の章で指定されている要件を満たす監査ルール設定
30-ospp-v42*.rules
OSPP (Protection Profile for General Purpose Operating Systems) プロファイルバージョン 4.2 に定義されている要件を満たす監査ルール設定
30-pci-dss-v31.rules
PCI DSS (Payment Card Industry Data Security Standard) v3.1 に設定されている要件を満たす監査ルール設定
30-stig.rules
Security Technical Implementation Guides (STIG) で設定されている要件を満たす監査ルール設定

上記の設定ファイルを使用するには、/etc/audit/rules.d/ ディレクトリーにコピーして、以下のように augenrules --load コマンドを使用します。

# cd /usr/share/audit/sample-rules/
# cp 10-base-config.rules 30-stig.rules 31-privileged.rules 99-finalize.rules /etc/audit/rules.d/
# augenrules --load
Copy to Clipboard Toggle word wrap

番号指定スキームを使用して監査ルールを順序付けできます。詳細は、/usr/share/audit/sample-rules/README-rules ファイルを参照してください。

7.9. augenrules の無効化

augenrules ユーティリティーを無効にすると、Audit は /etc/audit/audit.rules ファイルで定義されたルールを使用するように切り替わります。

手順

  1. /usr/lib/systemd/system/auditd.service ファイルを /etc/systemd/system/ ディレクトリーにコピーします。

    # cp -f /usr/lib/systemd/system/auditd.service /etc/systemd/system/
    Copy to Clipboard Toggle word wrap
  2. 任意のテキストエディターで /etc/systemd/system/auditd.service ファイルを編集します。以下に例を示します。

    # vi /etc/systemd/system/auditd.service
    Copy to Clipboard Toggle word wrap
  3. augenrules を含む行をコメントアウトし、auditctl -R コマンドを含む行のコメント設定を解除します。

    #ExecStartPost=-/sbin/augenrules --load
    ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
    Copy to Clipboard Toggle word wrap
  4. systemd デーモンを再読み込みして、auditd.service ファイルの変更を取得します。

    # systemctl daemon-reload
    Copy to Clipboard Toggle word wrap
  5. auditd サービスを再起動します。

    # service auditd restart
    Copy to Clipboard Toggle word wrap

7.10. ソフトウェアの更新を監視するための Audit の設定

事前設定されたルール 44-installers.rules を使用して、ソフトウェアをインストールする次のユーティリティーを監視するように Audit を設定できます。

  • dnf [1]
  • yum
  • pip
  • npm
  • cpan
  • gem
  • luarocks

rpm ユーティリティーを監視するには、rpm-plugin-audit パッケージをインストールします。その後、Audit は、パッケージをインストールまたは更新するときに SOFTWARE_UPDATE イベントを生成します。これらのイベントをリスト表示するには、コマンドラインで ausearch -m SOFTWARE_UPDATE と入力します。

注記

事前設定されたルールファイルは、ppc64le および aarch64 アーキテクチャーを備えたシステムでは使用できません。

前提条件

手順

  1. 事前設定されたルールファイル 44-installers.rules/usr/share/audit/sample-rules/ ディレクトリーから /etc/audit/rules.d/ ディレクトリーにコピーします。

    # cp /usr/share/audit/sample-rules/44-installers.rules /etc/audit/rules.d/
    Copy to Clipboard Toggle word wrap
  2. 監査ルールを読み込みます。

    # augenrules --load
    Copy to Clipboard Toggle word wrap

検証

  1. 読み込まれたルールをリスト表示します。

    # auditctl -l
    -p x-w /usr/bin/dnf-3 -k software-installer
    -p x-w /usr/bin/yum -k software-installer
    -p x-w /usr/bin/pip -k software-installer
    -p x-w /usr/bin/npm -k software-installer
    -p x-w /usr/bin/cpan -k software-installer
    -p x-w /usr/bin/gem -k software-installer
    -p x-w /usr/bin/luarocks -k software-installer
    Copy to Clipboard Toggle word wrap
  2. インストールを実行します。以下に例を示します

    # dnf reinstall -y vim-enhanced
    Copy to Clipboard Toggle word wrap
  3. Audit ログで最近のインストールイベントを検索します。次に例を示します。

    # ausearch -ts recent -k software-installer
    &#8211;&#8211;&#8211;&#8211;
    time->Thu Dec 16 10:33:46 2021
    type=PROCTITLE msg=audit(1639668826.074:298): proctitle=2F7573722F6C6962657865632F706C6174666F726D2D707974686F6E002F7573722F62696E2F646E66007265696E7374616C6C002D790076696D2D656E68616E636564
    type=PATH msg=audit(1639668826.074:298): item=2 name="/lib64/ld-linux-x86-64.so.2" inode=10092 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=PATH msg=audit(1639668826.074:298): item=1 name="/usr/libexec/platform-python" inode=4618433 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=PATH msg=audit(1639668826.074:298): item=0 name="/usr/bin/dnf" inode=6886099 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpm_exec_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=CWD msg=audit(1639668826.074:298): cwd="/root"
    type=EXECVE msg=audit(1639668826.074:298): argc=5 a0="/usr/libexec/platform-python" a1="/usr/bin/dnf" a2="reinstall" a3="-y" a4="vim-enhanced"
    type=SYSCALL msg=audit(1639668826.074:298): arch=c000003e syscall=59 success=yes exit=0 a0=55c437f22b20 a1=55c437f2c9d0 a2=55c437f2aeb0 a3=8 items=3 ppid=5256 pid=5375 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="dnf" exe="/usr/libexec/platform-python3.6" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="software-installer"
    Copy to Clipboard Toggle word wrap


[1] dnf は RHEL ではシンボリックリンクであるため、dnf Audit ルールのパスにはシンボリックリンクのターゲットが含まれている必要があります。正しい Audit イベントを受信するには、path=/usr/bin/dnf パスを /usr/bin/dnf-3 に変更して、44-installers.rules ファイルを変更します。

7.11. Audit によるユーザーログイン時刻の監視

特定の時間にログインしたユーザーを監視するには、同じ情報をさまざまな方法で表示する ausearch または aureport ツールを使用できます。監査を特別な方法で設定する必要はありません。

前提条件

手順

ユーザーのログイン時間を表示するには、次のいずれかのコマンドを使用します。

  • 監査ログで USER_LOGIN メッセージタイプを検索します。

    # ausearch -m USER_LOGIN -ts '12/02/2020' '18:00:00' -sv no
    time->Mon Nov 22 07:33:22 2021
    type=USER_LOGIN msg=audit(1637584402.416:92): pid=1939 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="(unknown)" exe="/usr/sbin/sshd" hostname=? addr=10.37.128.108 terminal=ssh res=failed'
    Copy to Clipboard Toggle word wrap
    • -ts オプションを使用して日付と時刻を指定できます。このオプションを使用しない場合、ausearch は今日の結果を提供し、時刻を省略すると、ausearch は午前 0 時からの結果を提供します。
    • 成功したログイン試行を除外するには -sv yes オプションを、失敗したログイン試行を除外するには -sv no を、それぞれ使用することができます。
  • ausearch コマンドの生の出力を aulast ユーティリティーにパイプで渡します。このユーティリティーは、last コマンドの出力と同様の形式で出力を表示します。以下に例を示します。

    # ausearch --raw | aulast --stdin
    root     ssh          10.37.128.108    Mon Nov 22 07:33 - 07:33  (00:00)
    root     ssh          10.37.128.108    Mon Nov 22 07:33 - 07:33  (00:00)
    root     ssh          10.22.16.106     Mon Nov 22 07:40 - 07:40  (00:00)
    reboot   system boot  4.18.0-348.6.el8 Mon Nov 22 07:33
    Copy to Clipboard Toggle word wrap
  • --login -i オプションを指定して aureport コマンドを使用し、ログインイベントのリストを表示します。

    # aureport --login -i
    
    Login Report
    ============================================
    # date time auid host term exe success event
    ============================================
    1. 11/16/2021 13:11:30 root 10.40.192.190 ssh /usr/sbin/sshd yes 6920
    2. 11/16/2021 13:11:31 root 10.40.192.190 ssh /usr/sbin/sshd yes 6925
    3. 11/16/2021 13:11:31 root 10.40.192.190 ssh /usr/sbin/sshd yes 6930
    4. 11/16/2021 13:11:31 root 10.40.192.190 ssh /usr/sbin/sshd yes 6935
    5. 11/16/2021 13:11:33 root 10.40.192.190 ssh /usr/sbin/sshd yes 6940
    6. 11/16/2021 13:11:33 root 10.40.192.190 /dev/pts/0 /usr/sbin/sshd yes 6945
    Copy to Clipboard Toggle word wrap

第8章 セキュリティー更新の管理および監視

セキュリティー更新をインストールし、更新に関する追加の詳細を表示して、新たに発見された脅威や脆弱性から Red Hat Enterprise Linux システムを保護する方法を説明します。

8.1. セキュリティー更新の特定

エンタープライズシステムを現在および今後の脅威から保護するには、定期的なセキュリティー更新が必要です。Red Hat Product Security チームは、エンタープライズソリューションを確実にデプロイおよび維持するのに必要なガイダンスを提供します。

8.1.1. セキュリティーアドバイザリーとは

Red Hat セキュリティーアドバイザリー (RHSA) には、Red Hat 製品およびサービスで修正されたセキュリティーの不具合に関する情報が記載されています。

各 RHSA には、以下の情報が含まれています。

  • 重大度
  • タイプおよびステータス
  • 影響を受ける製品
  • 修正された問題の概要
  • その問題に関するチケットへのリンク。すべてのチケットが公開されているわけではないことに注意してください。
  • CVE (Common Vulnerabilities and Exposures) 番号および攻撃の複雑性などの追加情報へのリンク。

Red Hat カスタマーポータルでは、Red Hat が公開している Red Hat セキュリティーアドバイザリーの一覧を提供しています。Red Hat セキュリティーアドバイザリーのリストからアドバイザリーの ID に移動して、特定のアドバイザリーの詳細を表示できます。

図8.1 セキュリティーアドバイザリーのリスト

カスタマーポータル: セキュリティーアドバイザリーのリスト

必要に応じて、特定の製品、バリアント、バージョン、およびアーキテクチャーで結果を絞り込むこともできます。たとえば、Red Hat Enterprise Linux 9 のアドバイザリーのみを表示するには、以下のフィルターを設定します。

  • 製品: Red Hat Enterprise Linux
  • バリアント: すべてのバリアント
  • バージョン: 9
  • 必要に応じて、マイナーバージョンを選択します。

8.1.2. ホストにインストールされていないセキュリティー更新の表示

dnf ユーティリティーを使用して、お使いのシステムで利用可能なセキュリティー更新のリストを表示できます。

前提条件

  • Red Hat サブスクリプションがホストに割り当てられている。

手順

  • ホストにインストールされていない、利用可能なセキュリティー更新のリストを表示します。

    # dnf updateinfo list updates security
    …
    RHSA-2019:0997 Important/Sec. platform-python-3.6.8-2.el8_0.x86_64
    RHSA-2019:0997 Important/Sec. python3-libs-3.6.8-2.el8_0.x86_64
    RHSA-2019:0990 Moderate/Sec.  systemd-239-13.el8_0.3.x86_64
    …
    Copy to Clipboard Toggle word wrap

8.1.3. ホストにインストールされているセキュリティー更新の表示

dnf ユーティリティーを使用して、お使いのシステムでインストールしたセキュリティー更新をリスト表示できます。

手順

  • ホストにインストールされているセキュリティー更新のリストを表示します。

    # dnf updateinfo list security --installed
    …
    RHSA-2019:1234 Important/Sec. libssh2-1.8.0-7.module+el8+2833+c7d6d092
    RHSA-2019:4567 Important/Sec. python3-libs-3.6.7.1.el8.x86_64
    RHSA-2019:8901 Important/Sec. python3-libs-3.6.8-1.el8.x86_64
    …
    Copy to Clipboard Toggle word wrap

    1 つのパッケージに含まれる複数の更新がインストールされている場合は、dnf で、そのパッケージのアドバイザリーがすべて表示されます。上記の例では、システムのインストール以降、python3-libs パッケージのセキュリティー更新が 2 つインストールされています。

8.1.4. DNF を使用した特定のアドバイザリーの表示

dnf ユーティリティーを使用して、更新で利用可能な特定のアドバイザリー情報を表示します。

前提条件

  • Red Hat サブスクリプションがホストに割り当てられている。
  • セキュリティーアドバイザリーの ID がわかっている。
  • そのアドバイザリーが提供する更新がインストールされていない。

手順

  • 特定のアドバイザリーを表示します。次に例を示します。

    # dnf updateinfo info RHSA-2019:0997
    ====================================================================
      Important: python3 security update
    ====================================================================
      Update ID: RHSA-2019:0997
           Type: security
        Updated: 2019-05-07 05:41:52
           Bugs: 1688543 - CVE-2019-9636 python: Information Disclosure due to urlsplit improper NFKC normalization
           CVEs: CVE-2019-9636
    Description: …
    Copy to Clipboard Toggle word wrap

8.2. セキュリティー更新のインストール

Red Hat Enterprise Linux では、特定のセキュリティーアドバイザリーと利用可能なすべてのセキュリティー更新をインストールできます。セキュリティー更新を自動的にダウンロードしてインストールするようにシステムを設定することもできます。

8.2.1. 利用可能なすべてのセキュリティー更新のインストール

システムのセキュリティーを最新の状態に維持するには、dnf ユーティリティーを使用して、現在利用可能なすべてのセキュリティー更新をインストールできます。

前提条件

  • Red Hat サブスクリプションがホストに割り当てられている。

手順

  1. dnf ユーティリティーを使用してセキュリティー更新をインストールします。

    # dnf update --security
    Copy to Clipboard Toggle word wrap

    --security パラメーターを指定しないと、dnf update により、バグ修正や機能拡張を含むすべての更新がインストールされます。

  2. y を押し、インストールを確認して開始します。

    …
    Transaction Summary
    ===========================================
    Upgrade  … Packages
    
    Total download size: … M
    Is this ok [y/d/N]: y
    Copy to Clipboard Toggle word wrap
  3. オプション: 更新したパッケージのインストール後にシステムを手動で再起動する必要があるプロセスをリスト表示します。

    # dnf needs-restarting
    1107 : /usr/sbin/rsyslogd -n
    1199 : -bash
    Copy to Clipboard Toggle word wrap

    上記のコマンドは、再起動が必要なプロセスのみをリスト表示し、サービスはリスト表示しません。つまり、systemctl ユーティリティーを使用してリスト表示されるプロセスを再起動することはできません。たとえば、このプロセスを所有するユーザーがログアウトすると、この出力内の bash プロセスは終了します。

8.2.2. 特定のアドバイザリーが提供するセキュリティー更新のインストール

状況によっては、特定の更新のみをインストールする場合があります。たとえば、ダウンタイムをスケジュールせずに特定のサービスを更新できる場合は、このサービスにのみセキュリティー更新をインストールし、後で残りのセキュリティー更新をインストールできます。

前提条件

手順

  1. 特定のアドバイザリーをインストールします。次に例を示します。

    # dnf update --advisory=RHSA-2019:0997
    Copy to Clipboard Toggle word wrap
  2. または、dnf upgrade-minimal コマンドを使用して、最小限のバージョン変更で特定のアドバイザリーを適用するように更新します。次に例を示します。

    # dnf upgrade-minimal --advisory=RHSA-2019:0997
    Copy to Clipboard Toggle word wrap
  3. y を押し、インストールを確認して開始します。

    …
    Transaction Summary
    ===========================================
    Upgrade  … Packages
    
    Total download size: … M
    Is this ok [y/d/N]: y
    Copy to Clipboard Toggle word wrap
  4. 必要に応じて、更新されたパッケージのインストール後にシステムを手動で再起動する必要のあるプロセスのリストを表示します。

    # dnf needs-restarting
    1107 : /usr/sbin/rsyslogd -n
    1199 : -bash
    Copy to Clipboard Toggle word wrap

    上記のコマンドは、再起動が必要なプロセスのみをリスト表示し、サービスはリスト表示しません。これは、systemctl ユーティリティーを使用してリスト表示されているプロセスをすべて再起動できないことを意味します。たとえば、このプロセスを所有するユーザーがログアウトすると、この出力内の bash プロセスは終了します。

8.2.3. セキュリティー更新の自動インストール

すべてのセキュリティー更新を自動的にダウンロードおよびインストールするようにシステムを設定できます。

前提条件

  • Red Hat サブスクリプションがホストに割り当てられている。
  • dnf-automatic パッケージがインストールされている。

手順

  1. /etc/dnf/automatic.conf ファイルの [commands] セクションで、upgrade_type オプションが default または security に設定されていることを確認します。

    [commands]
    #  What kind of upgrade to perform:
    # default                            = all available upgrades
    # security                           = only the security upgrades
    upgrade_type = security
    Copy to Clipboard Toggle word wrap
  2. systemd タイマーユニットを有効にして起動します。

    # systemctl enable --now dnf-automatic-install.timer
    Copy to Clipboard Toggle word wrap

検証

  1. タイマーが有効化されていることを確認します。

    # systemctl status dnf-automatic-install.timer
    Copy to Clipboard Toggle word wrap

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る