リスク軽減と復旧操作

手順

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

   # dnf install rear

2. 以下の例のように、任意のエディターで ReaR 設定ファイルを変更します。

   # vi /etc/rear/local.conf

   • バックアップ設定の詳細を /etc/rear/local.conf に追加します。たとえば、NETFS バックアップ方式の場合は、次の行を追加します。

     BACKUP=NETFS
     OUTPUT=ISO
     BACKUP_URL=<data-backup-location>
     OUTPUT_URL=<rescue-image-location>

     <data-backup-location> は tar データバックアップの場所に、<rescue-image-location> はレスキューシステムの ISO イメージの場所に置き換えます。以下に例を示します。

     BACKUP=NETFS
     OUTPUT=ISO
     
     # Backup is stored on an external drive
     BACKUP_URL=file:///run/media/user/external_drive/server_backups/
     
     # The ISO is stored on a dedicated NFS share
     OUTPUT_URL=nfs://backup-server.local/exports/rear/

     /etc/rear/local.conf ファイルの構文、および BACKUP_URL と OUTPUT_URL のサポートされている形式の詳細は、rear(8) の man ページを参照してください。

     /etc/rear/local.conf で使用できる設定変数のリストと、それらのデフォルト値については、/usr/share/rear/conf/default.conf ファイルを参照してください。

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

     NETFS_KEEP_OLD_BACKUP_COPY=y

   • 増分バックアップ (実行するたびに変更されたファイルのみがバックアップされる) を設定する場合は、以下の行を追加します。

     BACKUP_TYPE=incremental

   • UEFI ファームウェアで ReaR レスキューシステムを起動する予定がある場合は、起動が失敗しないように、次の行を追加します。

     SECURE_BOOT_BOOTLOADER=/boot/efi/EFI/redhat/shimx64.efi

3. 復元計画に基づき、レスキューシステムとデータバックアップを作成します。たとえば、NETFS バックアップ方式を使用する場合は、次のコマンドを実行します。

   # rear mkbackup

   システムが 64 ビット ARM アーキテクチャー (aarch64) を使用している場合は、代わりに次の行を使用します。

   SECURE_BOOT_BOOTLOADER=/boot/efi/EFI/redhat/shimaa64.efi

   1. レスキューシステムのみを作成する必要がある場合は、代わりに rear mkrescue コマンドを使用します。
   2. データバックアップのみを作成する必要がある場合は、代わりに rear mkbackuponly コマンドを使用します。

4. オプション: 定期的な自動 ReaR バックアップをスケジュールします。ユースケースに応じて、さまざまなバックアップ方法を選択できます。以下に例を示します。

   • /etc/cron.d/rear という crontab ファイルを作成し、以下の行を追加します。

     30 1 * * * /usr/sbin/rear mkbackup

     これにより、毎日午前 1 時 30 分に rear mkbackup コマンドが実行され、/etc/rear/local.conf ファイルで設定された場所にレスキューシステムとデータバックアップが作成されます。

   • 外部バックアップ方式を使用する場合は、外部バックアップをスケジュールします。詳細は、ReaR で使用しているバックアップ方法により異なります。

検証

1. レスキューシステムの ISO イメージを DVD に書き込み、その DVD を使用して起動を試みます。

   起動後に Relax-and-Recover インターフェイスが表示されれば、レスキュー DVD は正常に動作しています。

2. ReaR インターフェイスを使用してシステムを復元し、復元されたシステムが正常に動作するかテストします。

手順

1. ReaR をインストールします。

   # dnf install rear

2. 次の変数を /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>

      重要

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

   3. オプション: OUTPUT_URL 変数を設定して、カーネルファイルと initrd ファイルを保存することもできます。初期設定では、OUTPUT_URL は BACKUP_URL に合わせて配置されています。

3. バックアップとレスキューのイメージの作成を実行するには、次のコマンドを実行します。

   # rear mkbackup

   これにより、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. 新しいハードウェア上でレスキューシステムを起動します。たとえば、レスキューシステムの ISO イメージを DVD に書き込み、その DVD から起動できます。
2. Relax-and-Recover 起動メニューで、復旧環境を起動するオプションを選択します。

3. RESCUE プロンプトで、rear recover コマンドを実行します。

   レスキューシステムは、パーティションのレイアウトとファイルシステムを再構築します。

4. データバックアップから /mnt/local/ ディレクトリーにユーザーおよびシステムファイルを復元します。

   たとえば、NETFS 方式を使用してバックアップを作成した場合、ReaR は自動的に復元プロセスを実行します。ただし、バックアップ設定によっては、復元プロセスのいずれかの段階で ReaR が確認を求める場合があります。

手順

1. 現在のレイアウトファイルを生成します。

   # rear savelayout

2. レイアウトファイルを開き、その設定を確認します。以下に例を示します。

   # vi /var/lib/rear/layout/disklayout.conf

3. バックアップから特定のファイルやストレージデバイスを除外するには、レスキューイメージの作成時にそれらを無視するように ReaR を設定します。

   1. ReaR のローカル設定ファイルを開いて編集します。以下に例を示します。

      # vi /etc/rear/local.conf

   2. レイアウトファイルから除外するストレージデバイスを調整します。/etc/rear/local.conf ファイルでは、以下のようなさまざまな exclude 変数を使用できます。

      • AUTOEXCLUDE_DISKS
      • AUTOEXCLUDE_MULTIPATH
      • AUTOEXCLUDE_PATH
      • EXCLUDE_RECREATE

      これらの変数の機能と構文、およびレイアウトファイルの詳細は、ReaR ユーザーガイドの レイアウト設定 の章を参照してください。このガイドは rear パッケージに同梱されており、/usr/share/doc/rear/user-guide/relax-and-recover-user-guide.html で入手できます。

   3. デフォルトでは、レイアウトファイルにローカルディスクベースのファイルシステムが含まれている場合、rear mkbackup コマンドまたは rear mkbackuponly コマンドを使用すると、そのファイルシステム上のすべてのファイルがバックアップされます。

      バックアップから除外する特定のファイルまたはディレクトリーツリーを設定するには、BACKUP_PROG_EXCLUDE 変数を使用します。

      BACKUP_PROG_EXCLUDE の値は、tar または rsync が使用する glob(3) スタイルのワイルドカードパターンの配列でなければなりません。設定ファイルを読み込む際にシェルがパターンを展開しないように、パターンを引用符で囲む必要があることに注意してください。

      この変数のデフォルト値は、/usr/share/rear/conf/default.conf ファイルで設定されています。デフォルト値には、たとえば /tmp/* パターンが含まれています。このパターンは、/tmp ディレクトリーの下にあるすべてのファイルとディレクトリーを除外しますが、/tmp ディレクトリー自体は除外しません。

      他のファイルやディレクトリーを除外する必要がある場合は、変数にさらにパターンを追加します。デフォルト値を維持するために、変数はオーバーライドしないでください。

      たとえば、ディレクトリー /data/temp の下にあるすべてのファイルとディレクトリーを除外するには、次のように指定します。

      BACKUP_PROG_EXCLUDE+=( '/data/temp/*' )

      注記

      このようにマウントされた単一のファイルシステム内のすべてのファイルとディレクトリーを除外すると、復旧時に ReaR が再作成するファイルシステムは空になります。これは、一時データを格納した保存する必要のないファイルシステム、または ReaR とは独立した方法でバックアップされたデータに使用できます。

検証

1. 次の手順を実行して、レイアウトファイルに必要なストレージコンポーネントのみが含まれているか検証します。

   1. レイアウトファイルを再生成します。

      # rear savelayout

   2. 新しいレイアウトファイルを開き、設定に対する変更が意図したとおりの効果を発揮していることを確認します。

      # vi /var/lib/rear/layout/disklayout.conf

2. バックアップから特定のファイルを除外するには、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/*

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

手順

1. RHEL 10 Web コンソールにログインします。
2. Logs をクリックします。
3. リストからログを確認するログエントリーをクリックして、ログエントリーの詳細を開きます。

手順

1. RHEL 10 Web コンソールにログインします。
2. Logs をクリックします。
3. Toggle filters をクリックします。
4. デフォルトのログフィルタリングを変更するには、Time、Priority、および Identifier ドロップダウンメニューを使用します。

5. オプション: デフォルトでは、Web コンソールに最新のログエントリーが表示されます。特定の時間範囲でフィルタリングするには、Expand ボタンをクリックします。

   

6. → ボタン (右向き矢印) をクリックしてフィルターを適用します。
7. ログエントリーを開くには、選択したログエントリーをクリックします。

手順

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

3. ドロップダウンメニューを使用して、フィルタリングする 3 つの主要な数量詞 (期間、優先度、識別子) を指定します。

   Priority 数量詞には値が必要です。この値を指定しない場合、Error and above の優先度が自動的にフィルタリングされます。設定したオプションは、テキスト検索ボックスに反映されます。

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

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

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

手順

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>

   サンプル 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

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

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

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

   # semanage port -a -t syslogd_port_t -p tcp 30514

2. 必要に応じて、rsyslog トラフィックに別のポートを使用するには、firewalld がそのポートでの着信 rsyslog トラフィックを許可するように設定します。たとえば、ポート 30514 で TCP トラフィックを許可します。

   # firewall-cmd --zone=<zone_name> --permanent --add-port=30514/tcp
   success
   # firewall-cmd --reload

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")

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.

6. rsyslog サービスがロギングサーバーで実行中で、有効になっていることを確認します。

   # systemctl status rsyslog

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

   # systemctl restart rsyslog

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

   # systemctl enable rsyslog

手順

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"
        )

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

   • 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

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

   # logger test

2. サーバーシステムで、/var/log/messages ログを表示します。以下に例を示します。

   # cat /var/log/remote/msg/hostname/root.log
   Feb 25 03:53:17 hostname root[6064]: test

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

手順

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"
      )

      注記

      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"
      )

      • 使用するドライバーに応じて、<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.

   6. rsyslog サービスがロギングサーバーで実行中で、有効になっていることを確認します。

      # systemctl status rsyslog

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

      # systemctl restart rsyslog

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

      # systemctl enable rsyslog

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"
      )

      注記

      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"
        )

      • 使用するドライバーに応じて、<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.

   6. rsyslog サービスがロギングサーバーで実行中で、有効になっていることを確認します。

      # systemctl status rsyslog

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

      # systemctl restart rsyslog

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

      # systemctl enable rsyslog

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

   # logger test

2. サーバーシステムで、/var/log/messages ログを表示します。以下に例を示します。

   # cat /var/log/remote/msg/<hostname>/root.log
   Feb 25 03:53:17 <hostname> root[6064]: test

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

手順

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

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

      # semanage port -a -t syslogd_port_t -p udp portno

   2. rsyslog の受信トラフィックを許可するように firewalld を設定します。portno はポート番号に、zone は rsyslog が使用するゾーンに置き換えます。

      # firewall-cmd --zone=zone --permanent --add-port=portno/udp
      success
      # firewall-cmd --reload

   3. ファイアウォールルールを再読み込みします。

      # firewall-cmd --reload

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")

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

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

   # rsyslogd -N 1
   rsyslogd: version 8.1911.0-2.el8, config validation run...

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

   # systemctl restart rsyslog

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

   # systemctl enable rsyslog

手順

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"
        )

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

   • 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

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

   # systemctl enable rsyslog

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

   # logger test

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

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

手順

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

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

      module(load="omrelp")
      *.* action(type="omrelp" target="_target_IP_" port="_target_port_")

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

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

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

      # systemctl restart rsyslog

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

      # systemctl enable rsyslog

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")

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

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

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

      # systemctl restart rsyslog

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

      # systemctl enable rsyslog

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

   # logger test

2. サーバーシステムで、指定された log_path でログを表示します。以下に例を示します。

   # cat /var/log/remote/msg/hostname/root.log
   Feb 25 03:53:17 hostname root[6064]: test

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

手順

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

   # dnf install netconsole-service

2. /etc/sysconfig/netconsole ファイルを編集し、SYSLOGADDR パラメーターをリモートホストの IP アドレスに設定します。

   # SYSLOGADDR=192.0.2.1

3. netconsole サービスを有効にして起動します。

   # systemctl enable --now netconsole

手順

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]

   サンプル 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 ページを参照してください。

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

   $ ansible-playbook --syntax-check ~/playbook.yml

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

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

検証

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

   # rsyslogd -N 1
   rsyslogd: version 8.1911.0-6.el8, config validation run...
   rsyslogd: End of config validation run. Bye.

2. 管理対象ノードで、システムが error 文字列を含むメッセージをログに送信することを確認します。

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

      # logger error

   2. 以下のように /var/log/errors.log ログを表示します。

      # cat /var/log/errors.log
      Aug  5 13:48:31 hostname root[6778]: error

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

手順

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]

   サンプル 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 ページを参照してください。

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

   $ ansible-playbook --syntax-check ~/playbook.yml

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

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

検証

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.

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

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

      # logger test

   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

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

手順

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

   # cp -f /usr/lib/systemd/system/auditd.service /etc/systemd/system/

2. 任意のテキストエディターで /etc/systemd/system/auditd.service ファイルを編集します。以下に例を示します。

   # vi /etc/systemd/system/auditd.service

3. augenrules を含む行をコメントアウトし、auditctl -R コマンドを含む行のコメント設定を解除します。

   #ExecStartPost=-/sbin/augenrules --load
   ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules

4. systemd デーモンを再読み込みして、auditd.service ファイルの変更を取得します。

   # systemctl daemon-reload

5. auditd サービスを再起動します。

   # service auditd restart

手順

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/

2. 監査ルールを読み込みます。

   # augenrules --load

検証

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

2. インストールを実行します。以下に例を示します。

   # dnf reinstall -y vim-enhanced

3. Audit ログで最近のインストールイベントを検索します。次に例を示します。

   # ausearch -ts recent -k software-installer
   ––––
   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"

手順

1. Audit ログで 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'

   • -ts オプションを使用して日付と時刻を指定できます。このオプションを使用しない場合、ausearch は今日の結果を提供し、時刻を省略すると、ausearch は午前 0 時からの結果を提供します。
   • 成功したログイン試行を除外するには -sv yes オプションを、失敗したログイン試行を除外するには -sv no を、それぞれ使用することができます。

2. 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

3. --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