リスク軽減と復旧操作
データのバックアップ、ログの監視、セキュリティー更新の管理
概要
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。
Jira からのフィードバック送信 (アカウントが必要)
- Jira の Web サイトにログインします。
- 上部のナビゲーションバーで Create をクリックします。
- Summary フィールドにわかりやすいタイトルを入力します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
- ダイアログの下部にある Create をクリックします。
第1章 システムの復旧および復元 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux は、既存のバックアップを使用してシステムを復旧および復元するための Relax-and-Recover (ReaR) ユーティリティーを備えています。このユーティリティーは、障害復旧ソリューションとして、またシステム移行にも使用できます。
このユーティリティーを使用すると、以下のタスクを実行できます。
- 起動可能なイメージを作成し、そのイメージを使用して既存のバックアップからシステムを復元する
- オリジナルのストレージレイアウトを複製する
- ユーザーおよびシステムファイルを復元する
- システムを別のハードウェアに復元する
また、障害復旧の場合は、特定のバックアップソフトウェアを ReaR に統合することもできます。
1.1. ReaR の設定とバックアップの手動作成 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、Relax-and-Recover (ReaR) ユーティリティーを使用するパッケージのインストール、レスキューシステムの作成、バックアップの設定および生成を行います。
前提条件
バックアップ復元計画をもとに、必要な設定ができている。
ReaR に完全に統合され組み込まれている
NETFSバックアップ方式を使用できます。
手順
ReaR ユーティリティーをインストールします。
dnf install rear
# dnf install rearCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のように、任意のエディターで ReaR 設定ファイルを変更します。
vi /etc/rear/local.conf
# vi /etc/rear/local.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow バックアップ設定の詳細を
/etc/rear/local.confに追加します。たとえば、NETFSバックアップ方式の場合は、次の行を追加します。BACKUP=NETFS BACKUP_URL=backup.location
BACKUP=NETFS BACKUP_URL=backup.locationCopy to Clipboard Copied! Toggle word wrap Toggle overflow backup.location は、バックアップ先の URL に置き換えます。
新規バックアップの作成時に以前のバックアップアーカイブを維持するように ReaR 設定を行うには、以下の行を設定ファイルに追加します。
NETFS_KEEP_OLD_BACKUP_COPY=y
NETFS_KEEP_OLD_BACKUP_COPY=yCopy to Clipboard Copied! Toggle word wrap Toggle overflow 増分バックアップ (実行するたびに変更されたファイルのみがバックアップされる) を設定する場合は、以下の行を追加します。
BACKUP_TYPE=incremental
BACKUP_TYPE=incrementalCopy to Clipboard Copied! Toggle word wrap Toggle overflow レスキューシステムを作成します。
rear mkrescue
# rear mkrescueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 復元計画に従ってバックアップを作成します。たとえば、
NETFSバックアップ方式の場合は、次のように入力します。rear mkbackuponly
# rear mkbackuponlyCopy to Clipboard Copied! Toggle word wrap Toggle overflow または、以下のコマンドを実行すると、1 つの手順でレスキューシステムとバックアップを作成できます。
rear mkbackup
# rear mkbackupCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、
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パッケージがインストールされている。
手順
次の変数を
/etc/rear/local.confに追加し、64 ビット IBM Z アーキテクチャー上でレスキューイメージを生成するように ReaR を設定します。-
IPLアウトプットメソッドを設定するには、OUTPUT=IPLを追加します。 バックアップメソッドとバックアップ先を設定するには、
BACKUP変数およびBACKUP_URL変数を追加します。以下に例を示します。BACKUP=NETFS BACKUP_URL=nfs://<nfsserver_name>/<share_path>
BACKUP=NETFS BACKUP_URL=nfs://<nfsserver_name>/<share_path>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要ローカルバックアップストレージは、現在、64 ビットの IBM Z アーキテクチャーではサポートされていません。
-
オプション:
OUTPUT_URL変数を設定して、カーネルファイルとinitrdファイルを保存することもできます。初期設定では、OUTPUT_URLはBACKUP_URLに合わせて配置されています。
-
バックアップとレスキューのイメージの作成を実行するには、次のコマンドを実行します。
rear mkbackup
# rear mkbackupCopy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、
BACKUP_URL変数またはOUTPUT_URL(設定されている場合) 変数で指定された場所にカーネルファイルと initrd ファイルが作成され、指定されたバックアップ方法を使用してバックアップが作成されます。警告レスキュープロセスは、システムに接続したすべての DASD (Direct Attached Storage Devices) を再フォーマットします。システムのストレージデバイスに貴重なデータが存在する場合は、システムの復旧を行わないでください。これには、レスキュー環境で起動するのに使用された zipl ブートローダー、ReaR カーネル、および initrd で準備されたデバイスも含まれます。必ずコピーを保管してください。
-
システムを復元するには、以前に作成した ReaR カーネルファイルおよび initrd ファイルを使用し、
ziplブートローダー、カーネル、およびinitrdで準備した DASD (Direct Attached Storage Device) または FCP (Fibre Channel Protocol) 接続の SCSI デバイスから起動します。 -
レスキューカーネルと
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/*' )
BACKUP_PROG_EXCLUDE+=( '/data/temp/*' )
/usr/share/rear/conf/default.conf ファイルで設定変数のデフォルト値を確認できます。このデフォルト値は、ローカルの /etc/rear/local.conf 設定ファイルで変更できます。
また、内部の NETFS および RSYNC バックアップ方式でバックアップされるファイルを設定することもできます。デフォルトでは、レイアウトファイルにファイルシステムが含まれている場合、マウントされたすべてのローカルディスクベースのファイルシステム上のファイルは、rear mkbackup コマンドまたは rear mkbackuponly コマンドによってバックアップされます。
rear mkbackup コマンドを使用すると、ログ内のバックアップ除外パターンがリスト表示されます。ログファイルは /var/log/rear ディレクトリーにあります。これを使用して、完全なシステム復旧を実行する前に、除外ルールを確認できます。たとえば、ログに次のエントリーが含まれているとします。
上記の出力では、/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
$ 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
システム情報の表示
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 コンソールインターフェイスで、システムログにアクセスできます。
前提条件
RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
手順
- RHEL 10 Web コンソールにログインします。
Logs をクリックします。
- リストからログを確認するログエントリーをクリックして、ログエントリーの詳細を開きます。
ボタンを使用すると、新しいログエントリーが表示されないように一時停止できます。新しいログエントリーを再開すると、Web コンソールは、 ボタンを使用した後に報告されたすべてのログエントリーを読み込みます。
Priority 時間、優先順位、または識別子でログをフィルタリングできます。詳細は、Web コンソールでのログの確認とフィルタリング を参照してください。
3.2. Web コンソールでのログのフィルタリング リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールでログエントリーをフィルタリングできます。
前提条件
RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
手順
- RHEL 10 Web コンソールにログインします。
- Logs をクリックします。
コンソールデフォルトでは、Web コンソールには最新のログエントリーが表示されます。別の時間範囲でフィルタリングするには、Time ドロップダウンメニューをクリックして、希望するオプションを選択します。
重大度ログのリストは、デフォルトで エラー以上のレベル が表示されます。優先度のフィルタリングを変更するには、ドロップダウンメニューの エラー以上のレベル をクリックして、優先度を選択します。
デフォルトでは、Web コンソールにはすべての識別子のログが表示されます。特定のサービスのログをフィルタリングするには、All ドロップダウンメニューをクリックして、識別子を選択します。
- ログエントリーを開くには、選択したログをクリックします。
3.3. Web コンソールでログをフィルターするためのテキスト検索オプション リンクのコピーリンクがクリップボードにコピーされました!
テキスト検索オプション機能では、ログをフィルタリングするためのさまざまなオプションを利用できます。テキスト検索を使用してログをフィルタリングする場合は、3 つのドロップダウンメニューに定義した事前定義オプションを使用するか、自分で検索全体を入力できます。
ドロップダウンメニュー
検索のメインパラメーターを指定するのに使用できるドロップダウンメニューには、以下の 3 つがあります。
- 時間: このドロップダウンメニューには、検索のさまざまな時間範囲が事前定義されます。
-
優先度: このドロップダウンメニューでは、さまざまな優先度のオプションを利用できます。
journalctl --priorityオプションに対応します。デフォルトの優先度の値は Error and above です。これは、他の優先度を指定しないと毎回設定されます。 -
識別子: このドロップダウンメニューでは、フィルタリングする ID を選択します。
journalctl --identifierオプションに対応します。
量記号
検索を指定するのに使用できる量記号は 6 つあります。これらは、ログテーブルをフィルタリングするための Options で説明されています。
ログフィールド
特定のログフィールドを検索する場合は、フィールドとその内容を指定することができます。
ログメッセージでの自由形式のテキスト検索
ログメッセージで任意のテキスト文字列をフィルタリングできます。文字列は、正規表現の形式にすることもできます。
高度なログのフィルタリング I
2020 年 10 月 22 日深夜以降に発生した 'systemd' によって識別されるすべてのログメッセージをフィルターします。ジャーナルフィールド 'JOB_TYPE' は 'start' または 'restart' のいずれかです。
-
フィールドを検索するには、
identifier:systemd since:2020-10-22 JOB_TYPE=start,restartと入力します。 結果を確認します。
高度なログフィルタリング II
最後の前に起動で 'cockpit.service' systemd ユニットから送信されたすべてのログメッセージ、およびメッセージのボディーに "error" または "fail" が含まれるログメッセージをすべてフィルターします。
-
検索フィールドに
service:cockpit boot:-1 error|failと入力します。 結果を確認します。
3.4. テキストボックスのボックスを使用した Web コンソールでのログのフィルター リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールのテキスト検索ボックスを使用して、さまざまなパラメーターに基づいてログをフィルタリングできます。検索では、フィルタリングドロップダウンメニュー、数量詞、ログフィールド、および自由形式の文字列検索を組み合わせて使用します。
前提条件
RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
手順
- RHEL 10 Web コンソールにログインします。
- Logs をクリックします。
ドロップダウンメニューを使用して、3 つの主要なフィルタリング対象の数量 (時間範囲、優先順位、識別子) (フィルタリングする) を指定します。
優先順位 の数量には常に値が必要です。これを指定しない場合、Error and above の優先度が自動的にフィルターされます。テキスト検索ボックスに、設定したオプションに注目してください。
フィルターするログフィールドを指定します。
ログフィールドは複数追加できます。
- 自由形式文字列を使用して他の文字を検索できます。検索ボックスにも正規表現も使用できます。
3.5. ログフィルタリングのオプション リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールでログをフィルタリングするには、journalctl オプションを使用できます。これらのオプションの一部は、Web コンソールインターフェイスのドロップダウンメニューの一部として提供されます。
| オプション名 | 用途 | 備考 |
|---|---|---|
|
| メッセージの優先度による出力をフィルタリングします。単一数値またはテキストログレベルを取ります。ログレベルは、通常の syslog ログレベルです。単一のログレベルが指定されている場合、このログレベルまたは低い (より重要な) ログレベルを持つすべてのメッセージが表示されます。 | 優先順位 ドロップダウンメニューで説明されます。 |
|
| 指定された syslog 識別子 SYSLOG_IDENTIFIER のメッセージを表示します。複数回指定できます。 | 識別子 ドロップダウンメニューで説明されています。 |
|
| 最新のジャーナルエントリーのみを表示し、ジャーナルに追加されるように新しいエントリーを継続的に出力します。 | ドロップダウンで説明しません。 |
|
|
指定した |
ドロップダウンで説明されません。 |
|
| 特定のブートのメッセージを表示します。 正の整数はジャーナルの先頭から boots を検索し、ゼロ以下の整数はジャーナルの末尾から boots を検索します。このため、1 は、時系列順でジャーナルで見つかった最初の起動を意味し、2 は次に見つかったものと続きます。また、-0 は最後の起動、-1 は最後の起動の 1 つ前などとなります。 | 時間 ドロップダウンメニューでは、現在の起動 または 以前の起動 としてのみ説明されています。その他のオプションは手動で書き込む必要があります。 |
|
| 指定の日付以降のエントリーまたは指定の日付以前のエントリーを示します。日付は、"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 システムロールを使用すると、複数のシステムで一貫して永続的なロギングを設定できます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル 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ファイルを参照してください。
Playbook の構文を検証します。
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第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/ ディレクトリーにあります。httpd、samba などの一部のアプリケーションは、ログファイルを /var/log/ 内のサブディレクトリーに保存します。
5.2. Rsyslog ドキュメントのインストール リンクのコピーリンクがクリップボードにコピーされました!
Rsyslog アプリケーションには、https://www.rsyslog.com/doc/ で利用可能な詳細なオンラインドキュメントがありますが、rsyslog-doc ドキュメントパッケージをローカルにインストールすることもできます。
前提条件
-
システムで
AppStreamリポジトリーをアクティベートしている。 -
sudoを使用して新規パッケージをインストールする権限がある。
手順
rsyslog-docパッケージをインストールします。dnf install rsyslog-doc
# dnf install rsyslog-docCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
任意のブラウザーで
/usr/share/doc/rsyslog/html/index.htmlファイルを開きます。次に例を示します。firefox /usr/share/doc/rsyslog/html/index.html &
$ firefox /usr/share/doc/rsyslog/html/index.html &Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. TCP でのリモートロギング用のサーバーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Rsyslog アプリケーションを使用すると、ロギングサーバーを実行し、個別のシステムがログファイルをロギングサーバーに送信するように設定できます。TCP 経由でリモートロギングを使用するには、サーバーとクライアントの両方を設定します。サーバーは、クライアントシステムにより送信されたログを収集し、分析します。
Rsyslog アプリケーションを使用すると、ログメッセージがネットワークを介してサーバーに転送される中央ロギングシステムを維持できます。サーバーが利用できない場合にメッセージが失われないようにするには、転送アクションのアクションキューを設定します。これにより、送信に失敗したメッセージは、サーバーが再度到達可能になるまでローカルに保存されます。このようなキューは、UDP プロトコルを使用する接続に対しては設定できないことに注意してください。
omfwd プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。このプラグインは組み込まれているため、読み込む必要はありません。
デフォルトでは、rsyslog はポート 514 で TCP を使用します。
前提条件
- rsyslog がサーバーシステムにインストールされている。
-
サーバーに
rootとしてログインしている。 -
policycoreutils-python-utilsパッケージは、semanageコマンドを使用して任意の手順でインストールします。 -
firewalldサービスが実行中である。
手順
必要に応じて、
rsyslogトラフィックに別のポートを使用するには、SELinux タイプsyslogd_port_tをポートに追加します。たとえば、ポート30514を有効にします。semanage port -a -t syslogd_port_t -p tcp 30514
# semanage port -a -t syslogd_port_t -p tcp 30514Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要に応じて、
rsyslogトラフィックに別のポートを使用するには、firewalldがそのポートでの着信rsyslogトラフィックを許可するように設定します。たとえば、ポート30514で TCP トラフィックを許可します。firewall-cmd --zone=<zone_name> --permanent --add-port=30514/tcp success firewall-cmd --reload
# firewall-cmd --zone=<zone_name> --permanent --add-port=30514/tcp success # firewall-cmd --reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/rsyslog.d/ディレクトリーに新規ファイル (例:remotelog.conf) を作成し、以下のコンテンツを挿入します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
/etc/rsyslog.d/remotelog.confファイルへの変更を保存します。 /etc/rsyslog.confファイルの構文をテストします。rsyslogd -N 1 rsyslogd: version 8.1911.0-2.el8, config validation run... rsyslogd: End of config validation run. Bye.
# rsyslogd -N 1 rsyslogd: version 8.1911.0-2.el8, config validation run... rsyslogd: End of config validation run. Bye.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Rsyslogサービスがロギングサーバーで実行中で、有効になっていることを確認します。systemctl status rsyslog
# systemctl status rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow rsyslogサービスを再起動します。systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow 必要に応じて、
rsyslogが有効になっていない場合は、再起動後にrsyslogサービスが自動的に起動するようにします。systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
環境内の他のシステムからログファイルを受け取り、保存するように、ログサーバーが設定されています。
5.4. TCP 経由のサーバーへのリモートロギングの設定 リンクのコピーリンクがクリップボードにコピーされました!
TCP プロトコル経由でログメッセージをサーバーに転送するようにシステムを設定できます。omfwd プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。プラグインは組み込まれているのでロードする必要はありません。
前提条件
-
rsyslogパッケージが、サーバーに報告する必要のあるクライアントシステムにインストールされている。 - リモートロギング用にサーバーを設定している。
- 指定したポートが SELinux で許可され、ファイアウォールで開いている。
-
システムには、
policycoreutils-python-utilsパッケージが含まれています。このパッケージは、標準以外のポートを SELinux 設定に追加するためのsemanageコマンドを提供します。
手順
/etc/rsyslog.d/ディレクトリーに新規ファイル (例:10-remotelog.conf) を作成し、以下のコンテンツを挿入します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
-
queue.type="linkedlist"設定は、LinkedList インメモリーキューを有効にします。 -
queue.filename設定は、ディスクストレージを定義します。バックアップファイルは、前のグローバルのworkDirectoryディレクティブで指定された作業ディレクトリーにexample_fwd接頭辞を付けて作成されます。 -
action.resumeRetryCount -1設定は、サーバーが応答しない場合に接続を再試行するときにrsyslogがメッセージを破棄しないようにします。 -
queue.saveOnShutdown="on"設定は、rsyslogがシャットダウンした場合にインメモリーデータを保存します。 最後の行は、受信したすべてのメッセージをロギングサーバーに転送します。ポートの指定は任意です。
この設定では、
rsyslogはメッセージをサーバーに送信しますが、リモートサーバーに到達できない場合には、メッセージをメモリーに保持します。ディスク上にあるファイルは、設定されたメモリーキュー領域がrsyslogで不足するか、シャットダウンする必要がある場合にのみ作成されます。これにより、システムパフォーマンスが向上します。
注記Rsyslog は設定ファイル
/etc/rsyslog.d/を字句順に処理します。-
rsyslogサービスを再起動します。systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
クライアントシステムがサーバーにメッセージを送信していることを確認します。
クライアントシステムで、テストメッセージを送信します。
logger test
# logger testCopy to Clipboard Copied! Toggle word wrap Toggle overflow サーバーシステムで、
/var/log/messagesログを表示します。以下に例を示します。cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: test
# cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: testCopy to Clipboard Copied! Toggle word wrap Toggle overflow hostname はクライアントシステムのホスト名です。ログには、
loggerコマンドを入力したユーザーのユーザー名 (この場合はroot) が含まれていることに注意してください。
5.5. TLS 暗号化リモートロギングの設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Rsyslog はプレーンテキスト形式でリモートロギング通信を送信します。シナリオでこの通信チャネルのセキュリティーを確保する必要がある場合は、TLS を使用して暗号化できます。
TLS を介した暗号化されたトランスポートを使用するには、サーバーとクライアントの両方を設定します。サーバーは、クライアントシステムにより送信されたログを収集し、分析します。
ossl ネットワークストリームドライバー (OpenSSL) または gtls ストリームドライバー (GnuTLS) のいずれかを使用できます。
ネットワークに接続されていない、厳格な認可を受けているなど、セキュリティーが強化された別のシステムがある場合は、その別のシステムを認証局 (CA) として使用します。
サーバー側では global、module、input レベルで、クライアント側では 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 ナレッジベース) を参照してください。
-
手順
クライアントシステムから暗号化したログを受信するようにサーバーを設定します。
-
/etc/rsyslog.d/ディレクトリーに、新規ファイル (securelogser.confなど) を作成します。 通信を暗号化するには、設定ファイルに、サーバーの証明書ファイルへのパス、選択した認証方法、および TLS 暗号化に対応するストリームドライバーが含まれている必要があります。
/etc/rsyslog.d/securelogser.confに以下の行を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記GnuTLS ドライバーが必要な場合は、
StreamDriver.Name="gtls"設定オプションを使用します。x509/nameよりも厳密ではない認証モードの詳細は、rsyslog-docにインストールされているドキュメントを参照してください。オプション: 接続設定をカスタマイズするには、
inputセクションを次のものに置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
使用するドライバーに応じて、
<driver>をosslまたはgtlsに置き換えます。 -
<ca1>は CA 証明書に、<server1_cert>は証明書に、<server1_key>はカスタマイズされた接続の鍵に、それぞれ置き換えます。
-
使用するドライバーに応じて、
-
変更を
/etc/rsyslog.d/securelogser.confファイルに保存します。 /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.
# 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 Copied! Toggle word wrap Toggle overflow Rsyslogサービスがロギングサーバーで実行中で、有効になっていることを確認します。systemctl status rsyslog
# systemctl status rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow rsyslogサービスを再起動します。systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: Rsyslog が有効になっていない場合は、再起動後に
rsyslogサービスが自動的に起動されることを確認してください。systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
暗号化したログをサーバーに送信するようにクライアントを設定するには、以下のコマンドを実行します。
-
クライアントシステムで、
/etc/rsyslog.d/ディレクトリーに、新規ファイル (securelogcli.confなど) を作成します。 /etc/rsyslog.d/securelogcli.confに以下の行を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記GnuTLS ドライバーが必要な場合は、
StreamDriver.Name="gtls"設定オプションを使用します。オプション: 接続設定をカスタマイズするには、
actionセクションを次のものに置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
使用するドライバーに応じて、
<driver>をosslまたはgtlsに置き換えます。 -
<ca1>は CA 証明書に、<client1_cert>は証明書に、<client1_key>はカスタマイズされた接続の鍵に、それぞれ置き換えます。
-
使用するドライバーに応じて、
-
変更を
/etc/rsyslog.d/securelogcli.confファイルに保存します。 /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.
# 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 Copied! Toggle word wrap Toggle overflow Rsyslogサービスがロギングサーバーで実行中で、有効になっていることを確認します。systemctl status rsyslog
# systemctl status rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow rsyslogサービスを再起動します。systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: Rsyslog が有効になっていない場合は、再起動後に
rsyslogサービスが自動的に起動されることを確認してください。systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
クライアントシステムで、
検証
クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。
クライアントシステムで、テストメッセージを送信します。
logger test
# logger testCopy to Clipboard Copied! Toggle word wrap Toggle overflow サーバーシステムで、
/var/log/messagesログを表示します。以下に例を示します。cat /var/log/remote/msg/<hostname>/root.log Feb 25 03:53:17 <hostname> root[6064]: test
# cat /var/log/remote/msg/<hostname>/root.log Feb 25 03:53:17 <hostname> root[6064]: testCopy to Clipboard Copied! Toggle word wrap Toggle overflow <hostname>はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合はroot) が含まれていることに注意してください。
5.6. UDP でリモートロギング情報を受信するためのサーバー設定 リンクのコピーリンクがクリップボードにコピーされました!
Rsyslog アプリケーションを使用すると、リモートシステムからロギング情報を受信するようにシステムを設定できます。UDP 経由でリモートロギングを使用するには、サーバーとクライアントの両方を設定します。受信サーバーは、クライアントシステムが送信したログの収集および分析を行います。デフォルトでは、rsyslog はポート 514 で UDP を使用して、リモートシステムからログ情報を受信します。
以下の手順に従って、UDP プロトコルでクライアントシステムが送信したログの収集および分析を行うサーバーを設定します。
前提条件
- rsyslog がサーバーシステムにインストールされている。
-
サーバーに
rootとしてログインしている。 -
policycoreutils-python-utilsパッケージは、semanageコマンドを使用して任意の手順でインストールします。 -
firewalldサービスが実行中である。
手順
必要に応じて、デフォルトのポート
514以外のrsyslogトラフィックに別のポートを使用するには、次のコマンドを実行します。SELinux ポリシー設定に
syslogd_port_tSELinux タイプを追加し、portnoはrsyslogで使用するポート番号に置き換えます。semanage port -a -t syslogd_port_t -p udp portno
# semanage port -a -t syslogd_port_t -p udp portnoCopy to Clipboard Copied! Toggle word wrap Toggle overflow rsyslogの受信トラフィックを許可するようにfirewalldを設定します。portnoはポート番号に、zoneはrsyslogが使用するゾーンに置き換えます。firewall-cmd --zone=zone --permanent --add-port=portno/udp success firewall-cmd --reload
# firewall-cmd --zone=zone --permanent --add-port=portno/udp success # firewall-cmd --reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow ファイアウォールルールを再読み込みします。
firewall-cmd --reload
# firewall-cmd --reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
/etc/rsyslog.d/ディレクトリーに.confの新規ファイル (例:remotelogserv.conf) を作成し、以下のコンテンツを挿入します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 514は、rsyslogがデフォルトで使用するポート番号です。代わりに別のポートを指定できます。/etc/rsyslog.confファイルの構文と/etc/rsyslog.d/ディレクトリー内の全.confファイルを確認します。rsyslogd -N 1 rsyslogd: version 8.1911.0-2.el8, config validation run...
# rsyslogd -N 1 rsyslogd: version 8.1911.0-2.el8, config validation run...Copy to Clipboard Copied! Toggle word wrap Toggle overflow rsyslogサービスを再起動します。systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow 必要に応じて、
rsyslogが有効になっていない場合は、再起動後にrsyslogサービスが自動的に起動するようにします。systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7. UDP 経由のサーバーへのリモートロギングの設定 リンクのコピーリンクがクリップボードにコピーされました!
UDP プロトコル経由でログメッセージをサーバーに転送するようにシステムを設定できます。omfwd プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。プラグインは組み込まれているのでロードする必要はありません。
前提条件
-
rsyslogパッケージが、サーバーに報告する必要のあるクライアントシステムにインストールされている。 - UDP 経由でリモートログ情報を受信するためのサーバーの設定 で説明されているように、リモートロギング用にサーバーを設定している。
手順
/etc/rsyslog.d/ディレクトリーに.confの新規ファイル (例:10-remotelogcli.conf) を作成し、以下のコンテンツを挿入します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
-
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/を字句順に処理します。-
rsyslogサービスを再起動します。systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow 必要に応じて、
rsyslogが有効になっていない場合は、再起動後にrsyslogサービスが自動的に起動するようにします。systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。
クライアントシステムで、テストメッセージを送信します。
logger test
# logger testCopy to Clipboard Copied! Toggle word wrap Toggle overflow サーバーシステムで、
/var/log/remote/msg/hostname/root.logログを表示します。以下に例を示します。cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: test
# cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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" …)
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" …)
5.9. 信頼できるリモートロギングの設定 リンクのコピーリンクがクリップボードにコピーされました!
Reliable Event Logging Protocol (RELP) を使用すると、メッセージ損失のリスクを大幅に軽減して TCP で syslog メッセージを送受信できます。RELP は、信頼できるイベントメッセージを配信するので、メッセージ損失が許されない環境で有用です。RELP を使用するには、imrelp の入力モジュール (サーバー上での実行とログの受信) と omrelp 出力モジュール (クライアント上での実行とロギングサーバーへのログの送信) を設定します。
前提条件
-
rsyslogパッケージ、librelpパッケージ、およびrsyslog-relpパッケージをサーバーおよびクライアントシステムにインストールしている。 - 指定したポートが SELinux で許可され、ファイアウォール設定で開放されている。
手順
信頼できるリモートロギング用にクライアントシステムを設定します。
クライアントシステムの
/etc/rsyslog.d/ディレクトリーに、relpclient.confなどと名前を指定して新しい.confファイルを作成し、以下のコンテンツを挿入します。module(load="omrelp") *.* action(type="omrelp" target="_target_IP_" port="_target_port_")
module(load="omrelp") *.* action(type="omrelp" target="_target_IP_" port="_target_port_")Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
-
target_IPは、ロギングサーバーの IP アドレスに置き換えます。 -
target_portはロギングサーバーのポートに置き換えます。
-
-
変更を
/etc/rsyslog.d/relpclient.confファイルに保存します。 rsyslogサービスを再起動します。systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow 必要に応じて、
rsyslogが有効になっていない場合は、再起動後にrsyslogサービスが自動的に起動するようにします。systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
信頼できるリモートロギング用にサーバーシステムを設定します。
サーバーシステムの
/etc/rsyslog.d/ディレクトリーに、relpserv.confなどと名前を指定して新しい.confファイルを作成し、以下のコンテンツを挿入します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
-
log_pathは、メッセージを保存するパスを指定します。 -
target_portはロギングサーバーのポートに置き換えます。クライアント設定ファイルと同じ値を使用します。
-
-
/etc/rsyslog.d/relpserv.confファイルへの変更を保存します。 rsyslogサービスを再起動します。systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow 必要に応じて、
rsyslogが有効になっていない場合は、再起動後にrsyslogサービスが自動的に起動するようにします。systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
クライアントシステムがサーバーにメッセージを送信していることを確認します。
クライアントシステムで、テストメッセージを送信します。
logger test
# logger testCopy to Clipboard Copied! Toggle word wrap Toggle overflow サーバーシステムで、指定された
log_pathでログを表示します。以下に例を示します。cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: test
# cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: testCopy to Clipboard Copied! Toggle word wrap Toggle overflow hostnameはクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合はroot) が含まれていることに注意してください。
5.10. サポート対象の Rsyslog モジュール リンクのコピーリンクがクリップボードにコピーされました!
Rsyslog アプリケーションの機能を拡張するために、特定のモジュールを使用できます。モジュールは、追加の入力 (入力モジュール)、出力 (出力モジュール)、およびその他の機能を提供します。モジュールは、モジュールの読み込み後に利用可能な設定ディレクティブを追加で提供することも可能です。
以下のコマンドを使用して、システムにインストールされている入出力モジュールをリスト表示できます。
ls /usr/lib64/rsyslog/{i,o}m*
# ls /usr/lib64/rsyslog/{i,o}m*
rsyslog-doc パッケージをインストールした後、/usr/share/doc/rsyslog/html/configuration/modules/idx_output.html ファイルで使用可能なすべての rsyslog モジュールのリストを表示できます。
5.11. カーネルメッセージをリモートホストに記録するように netconsole サービスを設定 リンクのコピーリンクがクリップボードにコピーされました!
ディスクへのログインやシリアルコンソールの使用ができない場合は、netconsole カーネルモジュールおよび同じ名前のサービスを使用して、ネットワーク経由でカーネルメッセージをリモートの rsyslog サービスに記録できます。
前提条件
-
rsyslogなどのシステムログサービスがリモートホストにインストールされている。 - リモートシステムログサービスは、このホストから受信ログエントリーを受け取るように設定されています。
手順
netconsole-serviceパッケージをインストールします。dnf install netconsole-service
# dnf install netconsole-serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/sysconfig/netconsoleファイルを編集し、SYSLOGADDRパラメーターをリモートホストの IP アドレスに設定します。SYSLOGADDR=192.0.2.1
# SYSLOGADDR=192.0.2.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow netconsoleサービスを有効にして起動します。systemctl enable --now netconsole
# systemctl enable --now netconsoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
-
リモートシステムログサーバーの
/var/log/messagesファイルを表示します。
第6章 RHEL システムロールを使用したロギングの設定 リンクのコピーリンクがクリップボードにコピーされました!
logging RHEL システムロールを使用すると、ローカルホストとリモートホストをロギングサーバーとして自動的に設定し、多数のクライアントシステムからログを収集できます。
ロギングソリューションは、ログと複数のロギング出力を読み取る複数の方法を提供します。
たとえば、ロギングシステムは以下の入力を受け取ることができます。
- ローカルファイル
-
systemd/journal - ネットワーク上の別のロギングシステム
さらに、ロギングシステムでは以下を出力できます。
-
/var/log/ディレクトリーのローカルファイルに保存されるログ - Elasticsearch エンジンに送信されるログ
- 別のロギングシステムに転送されるログ
logging RHEL システムロールを使用すると、状況に合わせて入力と出力を組み合わせることができます。たとえば、journal からの入力をローカルのファイルに保存しつつも、複数のファイルから読み込んだ入力を別のロギングシステムに転送してそのローカルのログファイルに保存するようにロギングソリューションを設定できます。
6.1. logging RHEL システムロールを使用したローカルログメッセージのフィルタリング リンクのコピーリンクがクリップボードにコピーされました!
logging RHEL システムロールのプロパティーベースのフィルターを使用すると、さまざまな条件に基づいてローカルログメッセージをフィルタリングできます。その結果、たとえば以下を実現できます。
- 明確なログ: トラフィック量の多い環境では、ログが急増することがあります。エラーなどの特定のメッセージに注目することで、問題をより早く特定できるようになります。
- システムパフォーマンスの最適化: ログの量が多すぎると、通常、システムパフォーマンスが低下します。重要なイベントのみを選択的にログに記録することで、リソースの枯渇を防ぎ、システムをより効率的に運用できます。
- セキュリティーの強化: システムエラーやログイン失敗などのセキュリティーメッセージを効率的にフィルタリングすることで、関連するログのみを取得できます。これは、違反を検出し、コンプライアンス基準を満たすために重要です。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル Playbook で指定されている設定は次のとおりです。
logging_inputs-
ロギングの入力ディクショナリーのリストを定義します。
type: basicsオプションを指定すると、systemdジャーナルまたは Unix ソケットからの入力が対象になります。 logging_outputs-
ロギングの出力ディクショナリーのリストを定義します。
type: filesオプションにより、ローカルファイル (通常は/var/log/ディレクトリー内) にログを保存できます。property: msg、property: contains、およびproperty_value: errorオプションを指定すると、error文字列を含むすべてのログが/var/log/errors.logファイルに保存されます。property: msg、property: !contains、およびproperty_value: errorオプションを指定すると、他のすべてのログが/var/log/others.logファイルに保存されます。error値は、フィルタリングする必要がある文字列に置き換えることができます。 logging_flows-
ロギングのフローディクショナリーのリストを定義して、
logging_inputsとlogging_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 ページを参照してください。Playbook の構文を検証します。
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
管理対象ノードで、
/etc/rsyslog.confファイルの構文をテストします。rsyslogd -N 1 rsyslogd: version 8.1911.0-6.el8, config validation run... rsyslogd: End of config validation run. Bye.
# rsyslogd -N 1 rsyslogd: version 8.1911.0-6.el8, config validation run... rsyslogd: End of config validation run. Bye.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 管理対象ノードで、システムが
error文字列を含むメッセージをログに送信することを確認します。テストメッセージを送信します。
logger error
# logger errorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のように
/var/log/errors.logログを表示します。cat /var/log/errors.log Aug 5 13:48:31 hostname root[6778]: error
# cat /var/log/errors.log Aug 5 13:48:31 hostname root[6778]: errorCopy to Clipboard Copied! Toggle word wrap Toggle overflow hostnameはクライアントシステムのホスト名に置き換えます。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合はroot) が含まれていることに注意してください。
6.2. logging RHEL システムロールを使用したリモートロギングソリューションの適用 リンクのコピーリンクがクリップボードにコピーされました!
logging RHEL システムロールを使用して、1 つ以上のクライアントで systemd-journal サービスからログを取得し、リモートサーバーに転送するリモートロギングソリューションを設定できます。このサーバーは、remote_rsyslog および remote_files 設定からリモート入力を受け取り、リモートホスト名によって指定されたディレクトリー内のローカルファイルにログを出力します。
その結果、たとえば次のようなユースケースに対応できます。
- ログの集中管理: 複数のマシンのログメッセージを 1 つのストレージポイントから収集、アクセス、管理することで、日々の監視とトラブルシューティングのタスクが簡素化されます。また、このユースケースでは、ログメッセージを確認するために個々のマシンにログインする必要性が軽減されます。
- セキュリティーの強化: ログメッセージを 1 カ所に集中して保存すると、セキュアで改ざん不可能な環境にログを保存しやすくなります。このような環境により、セキュリティーインシデントをより効果的に検出して対応し、監査要件を満たすことが容易になります。
- ログ分析の効率向上: 複数のマシンまたはサービスにまたがる複雑な問題を迅速にトラブルシューティングするには、複数のシステムからのログメッセージを相関させることが重要です。これにより、さまざまなソースからのイベントをすばやく分析し、相互参照することができます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。 - サーバーまたはクライアントシステムの SELinux ポリシーでポートを定義し、それらのポートのファイアウォールを開く。デフォルトの SELinux ポリシーには、ポート 601、514、6514、10514、および 20514 が含まれます。別のポートを使用するには、クライアントおよびサーバーシステムの SELinux ポリシーの変更 を参照してください。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル Playbook の最初のプレイで指定されている設定は次のとおりです。
logging_inputs-
ロギングの入力ディクショナリーのリストを定義します。
type: remoteオプションを指定すると、ネットワークを介した他のロギングシステムからのリモート入力が対象になります。udp_ports: [ 601 ]オプションは、監視する UDP ポート番号のリストを定義します。tcp_ports: [ 601 ]オプションは、監視する TCP ポート番号のリストを定義します。udp_portsとtcp_portsの両方が設定されている場合、udp_portsが使用され、tcp_portsは削除されます。 logging_outputs-
ロギングの出力ディクショナリーのリストを定義します。
type: remote_filesオプションを指定すると、ログの送信元であるリモートホストとプログラム名ごとに、出力がローカルファイルに保存されます。 logging_flows-
ロギングのフローディクショナリーのリストを定義して、
logging_inputsとlogging_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_inputsとlogging_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 ページを参照してください。Playbook の構文を検証します。
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
クライアントとサーバーシステムの両方で、
/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.
# 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 Copied! Toggle word wrap Toggle overflow クライアントシステムがサーバーにメッセージを送信することを確認します。
クライアントシステムで、テストメッセージを送信します。
logger test
# logger testCopy to Clipboard Copied! Toggle word wrap Toggle overflow サーバーシステムで、
/var/log/<host2.example.com>/messagesログを表示します。次に例を示します。cat /var/log/<host2.example.com>/messages Aug 5 13:48:31 <host2.example.com> root[6778]: test
# cat /var/log/<host2.example.com>/messages Aug 5 13:48:31 <host2.example.com> root[6778]: testCopy to Clipboard Copied! Toggle word wrap Toggle overflow <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 を参照してください。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル Playbook で指定されている設定は次のとおりです。
logging_certificates-
このパラメーターの値は、
certificateRHEL システムロールのcertificate_requestsに渡され、秘密鍵と証明書の作成に使用されます。 logging_pki_filesこのパラメーターを使用すると、TLS に使用する CA、証明書、および鍵ファイルを検索するためにロギングで使用するパスとその他の設定 (サブパラメーター
ca_cert、ca_cert_src、cert、cert_src、private_key、private_key_src、およびtlsで指定) を設定できます。注記logging_certificatesを使用して管理対象ノードにファイルを作成する場合は、ca_cert_src、cert_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 ページを参照してください。Playbook の構文を検証します。
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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 を参照してください。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル Playbook で指定されている設定は次のとおりです。
logging_certificates-
このパラメーターの値は、
certificateRHEL システムロールのcertificate_requestsに渡され、秘密鍵と証明書の作成に使用されます。 logging_pki_filesこのパラメーターを使用すると、TLS に使用する CA、証明書、および鍵ファイルを検索するためにロギングで使用するパスとその他の設定 (サブパラメーター
ca_cert、ca_cert_src、cert、cert_src、private_key、private_key_src、およびtlsで指定) を設定できます。注記logging_certificatesを使用して管理対象ノードにファイルを作成する場合は、ca_cert_src、cert_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 ページを参照してください。Playbook の構文を検証します。
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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) を使用して、メッセージ送信を暗号化し、ネットワーク経由でログを安全に転送します。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル Playbook で指定されている設定は次のとおりです。
target- リモートロギングシステムが稼働しているホスト名を指定する必須パラメーターです。
port- リモートロギングシステムがリッスンしているポート番号です。
tlsネットワーク上でログをセキュアに転送します。セキュアなラッパーが必要ない場合は、
tls変数をfalseに設定します。デフォルトではtlsパラメーターは true に設定されますが、RELP を使用する場合には鍵/証明書およびトリプレット {ca_cert、cert、private_key} や {ca_cert_src、cert_src、private_key_src} が必要です。-
{
ca_cert_src、cert_src、private_key_src} のトリプレットを設定すると、デフォルトの場所 (/etc/pki/tls/certsと/etc/pki/tls/private) が、コントロールノードからファイルを転送するため、管理対象ノードの宛先として使用されます。この場合、ファイル名はトリプレットの元の名前と同じです。 -
{
ca_cert、cert、private_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 ページを参照してください。Playbook の構文を検証します。
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4.2. RELP を使用したサーバーログの設定 リンクのコピーリンクがクリップボードにコピーされました!
logging RHEL システムロールを使用すると、ログメッセージを RELP を使用してリモートロギングシステムから受信するようにサーバーを設定できます。
以下の手順では、Ansible インベントリーの server グループ内の全ホストに RELP を設定します。RELP 設定は TLS を使用して、メッセージ送信を暗号化し、ネットワーク経由でログを安全に転送します。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル Playbook で指定されている設定は次のとおりです。
port- リモートロギングシステムがリッスンしているポート番号です。
tlsネットワーク上でログをセキュアに転送します。セキュアなラッパーが必要ない場合は、
tls変数をfalseに設定します。デフォルトではtlsパラメーターは true に設定されますが、RELP を使用する場合には鍵/証明書およびトリプレット {ca_cert、cert、private_key} や {ca_cert_src、cert_src、private_key_src} が必要です。-
{
ca_cert_src、cert_src、private_key_src} のトリプレットを設定すると、デフォルトの場所 (/etc/pki/tls/certsと/etc/pki/tls/private) が、コントロールノードからファイルを転送するため、管理対象ノードの宛先として使用されます。この場合、ファイル名はトリプレットの元の名前と同じです。 -
{
ca_cert、cert、private_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 ページを参照してください。Playbook の構文を検証します。
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第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 は、一部のシステムコールが使用されるたびにログエントリーを生成するように設定できます。これを使用すると、
settimeofdayやclock_adjtime、その他の時間関連のシステムコールを監視することで、システム時間への変更を追跡できます。 - ユーザーが実行したコマンドの記録
-
Audit はファイルが実行されたかどうかを追跡できるため、特定のコマンドの実行を毎回記録するようにルールを定義できます。たとえば、
/binディレクトリー内のすべての実行可能ファイルにルールを定義できます。これにより作成されるログエントリーをユーザー ID で検索すると、ユーザーごとに実行されたコマンドの監査証跡を生成できます。 - システムのパス名の実行の記録
- ルールの呼び出し時にパスを inode に変換するファイルアクセスをウォッチする以外に、ルールの呼び出し時に存在しない場合や、ルールの呼び出し後にファイルが置き換えられた場合でも、Audit がパスの実行をウォッチできるようになりました。これにより、ルールは、プログラム実行ファイルをアップグレードした後、またはインストールされる前にも機能を継続できます。
- セキュリティーイベントの記録
-
pam_faillock認証モジュールは、失敗したログイン試行を記録できます。Audit で失敗したログイン試行も記録するように設定すると、ログインを試みたユーザーに関する追加情報が提供されます。 - イベントの検索
-
Audit は
ausearchユーティリティーを提供します。これを使用すると、ログエントリーをフィルターにかけ、いくつかの条件に基づく完全な監査証跡を提供できます。 - サマリーレポートの実行
-
aureportユーティリティーを使用すると、記録されたイベントのデイリーレポートを生成できます。システム管理者は、このレポートを分析し、疑わしいアクティビティーをさらに調べることができます。 - ネットワークアクセスの監視
-
nftables、iptables、およびebtablesユーティリティーは、Audit イベントを発生するように設定できるため、システム管理者がネットワークアクセスを監視できるようになります。
収集される情報の量によっては、監査によってシステムのパフォーマンスが影響を受ける可能性があります。
7.2. Audit システムのアーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
Audit システムは、ユーザー空間アプリケーションおよびユーティリティーと、カーネル側のシステムコール処理という 2 つの主要部分で構成されます。カーネルコンポーネントは、ユーザー空間アプリケーションからシステムコールを受け、これを user、task、fstype、または exit のいずれかのフィルターで振り分けます。
システムコールが exclude フィルターを通過すると、前述のフィルターのいずれかに送られます。このフィルターにより、Audit ルール設定に基づいてシステムコールが Audit デーモンに送信され、さらに処理されます。
ユーザー空間の Audit デーモンは、カーネルから情報を収集し、ログファイルのエントリーを作成します。他のユーザー空間ユーティリティーは、Audit デーモン、カーネルの Audit コンポーネント、または Audit ログファイルと相互作用します。
-
auditctlAudit 制御ユーティリティーはカーネル 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 ログファイルが含まれるパーティションでエラーが検出された場合に発生するアクションを指定します。このパラメーターは、ハードウェアの機能不全処理に関するローカルのセキュリティーポリシーに基づいて、
syslog、single、haltのいずれかに設定する必要があります。 flush-
incremental_asyncに設定する必要があります。これはfreqパラメーターと組み合わせて機能します。これは、ハードドライブとのハード同期を強制する前にディスクに送信できるレコードの数を指定します。freqパラメーターは100に設定する必要があります。このパラメーターにより、アクティビティーが集中した際に高いパフォーマンスを保ちつつ、Audit イベントデータがディスクのログファイルと確実に同期されるようになります。
残りの設定オプションは、ローカルのセキュリティーポリシーに合わせて設定します。
7.4. auditd の開始および制御 リンクのコピーリンクがクリップボードにコピーされました!
auditd が設定されたら、サービスを起動して Audit 情報を収集し、ログファイルに保存します。root ユーザーで次のコマンドを実行し、auditd を起動します。
service auditd start
# service auditd start
システムの起動時に auditd が起動するように設定するには、次のコマンドを実行します。
systemctl enable auditd
# systemctl enable auditd
# auditctl -e 0 で auditd を一時的に無効にし、# 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 コマンドは、enable と status の 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
# auditctl -w /etc/ssh/sshd_config -p warx -k sshd_config
auditd デーモンが実行している場合は、たとえば次のコマンドを使用して、Audit ログファイルに新しいイベントを作成します。
cat /etc/ssh/sshd_config
$ cat /etc/ssh/sshd_config
このイベントは、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
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
上記のイベントは 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=-13exitフィールドには、システムコールが返した終了コードを指定する値が含まれます。この値は、システムコールにより異なります。次のコマンドを実行すると、この値を人間が判読可能なものに変換できます。ausearch --interpret --exit -13
# ausearch --interpret --exit -13Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、監査ログに、終了コード
-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) を記録します。この例の3538はcatプロセスの 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=CWD2 つ目のレコードの
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=409248inodeフィールドには、このイベントで記録されたファイルまたはディレクトリーに関連する inode 番号が含まれます。以下のコマンドは、inode 番号409248に関連するファイルまたはディレクトリーを表示します。find / -inum 409248 -print /etc/ssh/sshd_config
# find / -inum 409248 -print /etc/ssh/sshd_configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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 イベントをログに記録するかを指定するルールを定義できます。
ファイルシステムのルールの例
すべての書き込みアクセスと
/etc/passwdファイルのすべての属性変更をログに記録するルールを定義するには、次のコマンドを実行します。auditctl -w /etc/passwd -p wa -k passwd_changes
# auditctl -w /etc/passwd -p wa -k passwd_changesCopy to Clipboard Copied! Toggle word wrap Toggle overflow すべての書き込みアクセスと、
/etc/selinux/ディレクトリー内の全ファイルへのアクセスと、その属性変更をすべてログに記録するルールを定義するには、次のコマンドを実行します。auditctl -w /etc/selinux/ -p wa -k selinux_changes
# auditctl -w /etc/selinux/ -p wa -k selinux_changesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
システムロールのルールの例
システムで 64 ビットアーキテクチャーが使用され、システムコールの
adjtimexまたはsettimeofdayがプログラムにより使用されるたびにログエントリーを作成するルールを定義するには、次のコマンドを実行します。auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
# auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_changeCopy to Clipboard Copied! Toggle word wrap Toggle overflow ユーザー ID が 1000 以上のシステムユーザーがファイルを削除したりファイル名を変更するたびに、ログエントリーを作成するルールを定義するには、次のコマンドを実行します。
auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete
# auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k deleteCopy to Clipboard Copied! Toggle word wrap Toggle overflow -F auid!=4294967295オプションが、ログイン UID が設定されていないユーザーを除外するために使用されています。
実行可能なファイルルール
/bin/id プログラムのすべての実行をログに取得するルールを定義するには、次のコマンドを実行します。
auditctl -a always,exit -F exe=/bin/id -F arch=b64 -S execve -k execution_bin_id
# auditctl -a always,exit -F exe=/bin/id -F arch=b64 -S execve -k execution_bin_id
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
# auditctl -R /usr/share/audit/sample-rules/30-stig.rules
augenrules スクリプトは、/etc/audit/rules.d/ ディレクトリーにあるルールを読み込み、audit.rules ファイルにコンパイルします。このスクリプトは、自然なソート順序の特定の順番で、.rules で終わるすべてのファイルを処理します。このディレクトリーのファイルは、以下の意味を持つグループに分類されます。
- 10
- カーネルと auditctl の設定
- 20
- 一般的なルールと一致する可能性があるが、別の一致が必要なルール
- 30
- 主なルール
- 40
- オプションのルール
- 50
- サーバー固有のルール
- 70
- システムのローカルルール
- 90
- ファイナライズ (イミュータブル)
ルールは、すべてを一度に使用することは意図されていません。これらは、よく検討して、個別にファイルとして /etc/audit/rules.d/ にコピーする必要があるポリシーの一部です。たとえば、STIG 設定でシステムを設定するには、10-base-config、30-stig、31-privileged、および 99-finalize の各ルールをコピーします。
/etc/audit/rules.d/ ディレクトリーにルールを保存したら、--load ディレクティブで augenrules スクリプトを実行して読み込みます。
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
# 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
番号指定スキームを使用して監査ルールを順序付けできます。詳細は、/usr/share/audit/sample-rules/README-rules ファイルを参照してください。
7.9. augenrules の無効化 リンクのコピーリンクがクリップボードにコピーされました!
augenrules ユーティリティーを無効にすると、Audit は /etc/audit/audit.rules ファイルで定義されたルールを使用するように切り替わります。
手順
/usr/lib/systemd/system/auditd.serviceファイルを/etc/systemd/system/ディレクトリーにコピーします。cp -f /usr/lib/systemd/system/auditd.service /etc/systemd/system/
# cp -f /usr/lib/systemd/system/auditd.service /etc/systemd/system/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 任意のテキストエディターで
/etc/systemd/system/auditd.serviceファイルを編集します。以下に例を示します。vi /etc/systemd/system/auditd.service
# vi /etc/systemd/system/auditd.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow augenrulesを含む行をコメントアウトし、auditctl -Rコマンドを含む行のコメント設定を解除します。#ExecStartPost=-/sbin/augenrules --load ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
#ExecStartPost=-/sbin/augenrules --load ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rulesCopy to Clipboard Copied! Toggle word wrap Toggle overflow systemdデーモンを再読み込みして、auditd.serviceファイルの変更を取得します。systemctl daemon-reload
# systemctl daemon-reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow auditdサービスを再起動します。service auditd restart
# service auditd restartCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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 アーキテクチャーを備えたシステムでは使用できません。
前提条件
-
auditdが 「安全な環境のための監査設定」 に沿って設定されている。
手順
事前設定されたルールファイル
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/
# cp /usr/share/audit/sample-rules/44-installers.rules /etc/audit/rules.d/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 監査ルールを読み込みます。
augenrules --load
# augenrules --loadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
読み込まれたルールをリスト表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストールを実行します。以下に例を示します
dnf reinstall -y vim-enhanced
# dnf reinstall -y vim-enhancedCopy to Clipboard Copied! Toggle word wrap Toggle overflow Audit ログで最近のインストールイベントを検索します。次に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
dnf は RHEL ではシンボリックリンクであるため、dnf Audit ルールのパスにはシンボリックリンクのターゲットが含まれている必要があります。正しい Audit イベントを受信するには、path=/usr/bin/dnf パスを /usr/bin/dnf-3 に変更して、44-installers.rules ファイルを変更します。
7.11. Audit によるユーザーログイン時刻の監視 リンクのコピーリンクがクリップボードにコピーされました!
特定の時間にログインしたユーザーを監視するには、同じ情報をさまざまな方法で表示する ausearch または aureport ツールを使用できます。監査を特別な方法で設定する必要はありません。
前提条件
-
auditdが 「安全な環境のための監査設定」 に沿って設定されている。
手順
ユーザーのログイン時間を表示するには、次のいずれかのコマンドを使用します。
監査ログで
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'
# 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 Copied! Toggle word wrap Toggle overflow -
-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
# 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:33Copy to Clipboard Copied! Toggle word wrap Toggle overflow --login -iオプションを指定してaureportコマンドを使用し、ログインイベントのリストを表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第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 サブスクリプションがホストに割り当てられている。
手順
ホストにインストールされていない、利用可能なセキュリティー更新のリストを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.1.3. ホストにインストールされているセキュリティー更新の表示 リンクのコピーリンクがクリップボードにコピーされました!
dnf ユーティリティーを使用して、お使いのシステムでインストールしたセキュリティー更新をリスト表示できます。
手順
ホストにインストールされているセキュリティー更新のリストを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 1 つのパッケージに含まれる複数の更新がインストールされている場合は、
dnfで、そのパッケージのアドバイザリーがすべて表示されます。上記の例では、システムのインストール以降、python3-libsパッケージのセキュリティー更新が 2 つインストールされています。
8.1.4. DNF を使用した特定のアドバイザリーの表示 リンクのコピーリンクがクリップボードにコピーされました!
dnf ユーティリティーを使用して、更新で利用可能な特定のアドバイザリー情報を表示します。
前提条件
- Red Hat サブスクリプションがホストに割り当てられている。
- セキュリティーアドバイザリーの ID がわかっている。
- そのアドバイザリーが提供する更新がインストールされていない。
手順
特定のアドバイザリーを表示します。次に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2. セキュリティー更新のインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux では、特定のセキュリティーアドバイザリーと利用可能なすべてのセキュリティー更新をインストールできます。セキュリティー更新を自動的にダウンロードしてインストールするようにシステムを設定することもできます。
8.2.1. 利用可能なすべてのセキュリティー更新のインストール リンクのコピーリンクがクリップボードにコピーされました!
システムのセキュリティーを最新の状態に維持するには、dnf ユーティリティーを使用して、現在利用可能なすべてのセキュリティー更新をインストールできます。
前提条件
- Red Hat サブスクリプションがホストに割り当てられている。
手順
dnfユーティリティーを使用してセキュリティー更新をインストールします。dnf update --security
# dnf update --securityCopy to Clipboard Copied! Toggle word wrap Toggle overflow --securityパラメーターを指定しないと、dnf updateにより、バグ修正や機能拡張を含むすべての更新がインストールされます。y を押し、インストールを確認して開始します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 更新したパッケージのインストール後にシステムを手動で再起動する必要があるプロセスをリスト表示します。
dnf needs-restarting 1107 : /usr/sbin/rsyslogd -n 1199 : -bash
# dnf needs-restarting 1107 : /usr/sbin/rsyslogd -n 1199 : -bashCopy to Clipboard Copied! Toggle word wrap Toggle overflow 上記のコマンドは、再起動が必要なプロセスのみをリスト表示し、サービスはリスト表示しません。つまり、
systemctlユーティリティーを使用してリスト表示されるプロセスを再起動することはできません。たとえば、このプロセスを所有するユーザーがログアウトすると、この出力内のbashプロセスは終了します。
8.2.2. 特定のアドバイザリーが提供するセキュリティー更新のインストール リンクのコピーリンクがクリップボードにコピーされました!
状況によっては、特定の更新のみをインストールする場合があります。たとえば、ダウンタイムをスケジュールせずに特定のサービスを更新できる場合は、このサービスにのみセキュリティー更新をインストールし、後で残りのセキュリティー更新をインストールできます。
前提条件
- Red Hat サブスクリプションがホストに割り当てられている。
更新するセキュリティーアドバイザリーの ID がわかっている。
詳細は、セキュリティーアドバイザリーの更新の特定 を参照してください。
手順
特定のアドバイザリーをインストールします。次に例を示します。
dnf update --advisory=RHSA-2019:0997
# dnf update --advisory=RHSA-2019:0997Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、
dnf upgrade-minimalコマンドを使用して、最小限のバージョン変更で特定のアドバイザリーを適用するように更新します。次に例を示します。dnf upgrade-minimal --advisory=RHSA-2019:0997
# dnf upgrade-minimal --advisory=RHSA-2019:0997Copy to Clipboard Copied! Toggle word wrap Toggle overflow yを押し、インストールを確認して開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要に応じて、更新されたパッケージのインストール後にシステムを手動で再起動する必要のあるプロセスのリストを表示します。
dnf needs-restarting 1107 : /usr/sbin/rsyslogd -n 1199 : -bash
# dnf needs-restarting 1107 : /usr/sbin/rsyslogd -n 1199 : -bashCopy to Clipboard Copied! Toggle word wrap Toggle overflow 上記のコマンドは、再起動が必要なプロセスのみをリスト表示し、サービスはリスト表示しません。これは、
systemctlユーティリティーを使用してリスト表示されているプロセスをすべて再起動できないことを意味します。たとえば、このプロセスを所有するユーザーがログアウトすると、この出力内のbashプロセスは終了します。
8.2.3. セキュリティー更新の自動インストール リンクのコピーリンクがクリップボードにコピーされました!
すべてのセキュリティー更新を自動的にダウンロードおよびインストールするようにシステムを設定できます。
前提条件
- Red Hat サブスクリプションがホストに割り当てられている。
-
dnf-automaticパッケージがインストールされている。
手順
/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
[commands] # What kind of upgrade to perform: # default = all available upgrades # security = only the security upgrades upgrade_type = securityCopy to Clipboard Copied! Toggle word wrap Toggle overflow systemdタイマーユニットを有効にして起動します。systemctl enable --now dnf-automatic-install.timer
# systemctl enable --now dnf-automatic-install.timerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
タイマーが有効化されていることを確認します。
systemctl status dnf-automatic-install.timer
# systemctl status dnf-automatic-install.timerCopy to Clipboard Copied! Toggle word wrap Toggle overflow