IBM Support

QRadar: 7.2.8 以前の コンソール・アプライアンスを 7.5.0 UP2 IF2 以降にアップデートすると、Docker サービスが起動しない ( APAR IJ41796 )

News


Abstract

QRadar® SIEM の開発部門において、バージョン 7.2.8 以前の QRadar アプライアンスをインストールし、7.5.0 Update Pack 2 Interim Fix 2 以降にアップグレードした場合に、Docker サービスが起動しない不具合を確認しました。この問題は、QRadar 7.2.8以前のRed Hat Enterprise（ RHEL ）のオリジナルインストールでは XFS が ftype=0 に設定されているため、アプリケーションが起動しません。QRadar を 7.5.0 Update Pack 2 Interim Fix 2 以降にアップグレードすると、Docker サービスが ftype=1 を期待し、サービスが期待する通りに起動しなくなります。この問題は QRadar コンソール・アプライアンスにのみ影響し、他のすべてのアプライアンス・タイプは影響を受けません。

Content

テクニカルノートの更新

  • 2023 年 1 月 25 日午後 4 時 00 分（ ET ）：新しい Console と古い Console のホスト名は同一である必要があることを追加しました。管理者は、ホスト名が同一でない場合、移行後にデプロイ変更が完了しない問題を報告しました。
  • 2023 年 1 月 20 日 2 時 00 分（ ET ）： APAR IJ41796 で説明されている Red Hat Docker の問題を解決するために、新しい Console のインストールおよびデータを移行するプロセスを追加するために記事を更新しました。
  • 22 September 2022 2:45 PM ET：この技術書を更新し、システムが 7.2.8 で作成し、その後アップグレードした場合、QRadar SIEM 7.5.0 UP2 IF2 および 7.5.0 UP3 以降のすべてのバージョンが影響を受けることを一覧にしました。
  • 10 2022年9月10日 15時00分（ ET ）：この問題は QRadar 7.5.0 Update Pack 3 にも影響を与えるため、この技術書を更新しました。
  • 2022 年 8 月 12 日 4:00 PM ET：ユーザーへのフラッシュ通知の初期リリース。

緊急性


重要：QRadar SIEM 7.5.0 Update Pack 2 Interim Fix 2 以降のバージョンで、ソフトウェア・アップデート後にアプリケーションが実行されないという Docker サービスの重大な問題が、複数のユーザーから報告されています。QRadar 7.2.8 またはそれ以前にインストールされた QRadar アプライアンスを使用しているユーザーは、QRadar 7.5.0 Update Pack 2 Interim Fix 2 およびそれ以降をインストールする前に、ファイル・システムの  ftype  設定を確認してください。

対象製品


QRadar SIEM 7.5.0 Update Pack 2 Interim Fix 2 以降で、この技術書に記載されているように、ftype=0  のファイル・システム・タイプとなる物。
 
注：QRadar on Cloud アプライアンスは、この問題の影響を受けません。

私は影響を受けているのでしょうか？

7.5.0 Update Pack 2 Interim Fix 2 または 7.5.0 Update Pack 3 以降にアップデートする前に、この既知の問題の影響を受けるかどうかを確認する必要があります。

手順
  1. SSH を使用して、root ユーザーとして QRadar Console にログインします。
  2. 次のコマンドを入力します： 
    xfs_info /store | grep ftype
    出力例 
    naming=version 2 bsize=4096 ascii-ci=0 ftype=0
  3. 出力を確認して、QRadar Console アプライアンスのファイル・システム ftype を決定します：
    • 出力に ftype=1 と表示された場合は、7.5.0 Update Pack 2 Interim Fix 2 または 7.5.0 Update Pack 3 へのアップグレードを続行することができます。
    • 出力が ftype=0 と表示された場合は、アップグレードしないでください。この問題の影響を受けるコンソール・アプライアンスは、この Docker サービスの問題を回避するために、コンソール・アプライアンスを新しいバージョンに移行する必要があります。
    • QRadar 7.5.0 Update Pack 2 IF2 または 7.5.0 UP3 以降にアップグレードしてアプリケーションの問題が発生した場合、スタック・トレースを確認してエラーを確認してください。この問題が発生すると、/var/log/qradar.log に以下のエラー・メッセージが表示されます：
      Hostname dockerd[9053]: Error starting daemon: error initializing graphdriver: overlay2: the backing xfs filesystem is 
formatted without d_type support, which leads to incorrect behavior. Reformat the filesystem with ftype=1 to enable 
d_type support. Backing filesystems without d_type support are not supported. 
Hostname systemd[1]: docker.service: main process exited, code=exited, status=1/FAILURE 
Hostname systemd[1]: Failed to start Docker Application Container Engine

      結果
       7.5.0 Update Pack 2 Interim Fix 2 以降にアップグレードし、このエラーのスタック・トレースを確認した場合、この問題を解決するために Console を移行する必要があります。詳しくは、「新しい Console への移行」を参照してください。
     

    新しいConsoleへの移行 

    Console のマイグレーションについて
    docker ftype の問題を解決するには、管理者は ISO ファイルから新しい Console アプライアンスをインストールし、設定のバックアップを新しいアプライアンスに移行する必要があります。この問題は 7.2.8 などの古い Red Hat バージョンからのアップグレードが原因で発生するため、再インストールと移行によって問題が解決されます。新しい QRadar Console はデプロイメント内の既存のホストを引き継ぐため、古い QRadar Console から管理対象ホストを削除する必要はありません。この手順により、Console がオフラインの間、デプロイメント内の管理対象ホストがイベントの受信を継続することができます。

    始める前に

    • 古いコンソールのネットワーク情報を書き留めておきます。この情報を新しいアプライアンスのネットワーク構成に入力する必要があります。古いコンソールと新しいコンソールが同じネットワークにあることを確認します。
    • 古い Console から最近の構成バックアップを保存します。構成バックアップは、設定、ユーザー、ルール、ログ・ソースなどを新しいコンソールに復元するために使用されます。

      重要： 構成バックアップは、作成した QRadar の同じバージョンにのみリストアできます。デプロイメント全体で  QRadar のバージョンを変更する予定がある場合、ソフトウェアのバージョンアップ後に新しい構成バックアップを作成し、これらのファイルをハードウェア移行のために安全な場所に保管する必要があります。小型の Console から大型または新型のアプライアンスへの移行は、マイグレーションおよびバックアップ・プロセスでサポートされています。たとえば、3105 コンソールの構成バックアップは、3128 または 3148 アプライアンスに適用することができます。コマンド・ラインからアプライアンスのインストールされたソフトウェア・バージョンを表示するには、次のように入力します： 
      /opt/qradar/bin/myver
    • 新しい QRadar Console はデプロイメント内の既存のホストを引き継ぐため、古い QRadar Console から管理対象ホストを削除する必要ありません。この手順により、Console がオフラインの間、デプロイメント内の管理対象ホストがイベントの受信を継続できるようになります。
    • 新しい Console に IMM や DRAC などのリモート管理が設定されていることを確認します。この手順で説明する特定の変更は、IP アドレスの変更など、SSH セッションから完了することはできません。コンソールへの物理的なキーボード・アクセスがない限り、コンソールのリモート管理へのアクセスが必要です。
    • 管理対象デプロイメントで WinCollect を使用している場合、移行前に古い Console と一致する WinCollect SFS バージョンをダウンロードし、再インストールすることを確認してください。最新の WinCollect 管理対象バージョンについては、https://www.ibm.com/support/pages/node/6491895 を参照してください。

    1. 新しいコンソールを準備する

    このセクションでは、古い Console と一致するソフトウェア・バージョンを使用して、新しい Console への QRadar のインストールを完了する必要があります。新しい Console のインストールでは、古いハードウェアがデプロイメントから削除されるまで、一時的な IP アドレスを使用します。
    1. 交換用のコンソールをラックに入れ、ネットワーク接続を接続します。
    2. IBM Fix Central から、既存のコンソールのバージョンと一致する QRadar ISO をダウンロードします。
      注：古いコンソールのバージョンによっては、ISO ファイルに加えて、SFS ファイルまたは暫定的な修正プログラムのダウンロードが必要になる場合があります。 コマンド・ラインからアプライアンスのインストール済みソフトウェア・バージョンを表示するには、次のように入力します： 
      /opt/qradar/bin/myver
    3. アプライアンスの電源を入れ、root ユーザーとしてログインします。
    4. システムがライセンス契約（ EULA ）を表示したら、Y を押して続行します。
    5. QRadar を構成します。
    6. 新しいハードウェアのための一時的な IP アドレスとネットワーク情報を割り当てます。
    7. アプライアンスの root パスワードを入力します。
    8. インストール・ウィザードに従って、インストールを完了します。
    9. SFS アップデートまたは Interrim Fix を適用して、新しいハードウェアが古いコンソールと同じバージョン・レベルであることを確認します。
    10. WinCollect などコンソールで管理するエージェントがある場合は、その他の必要なソフトウェアをダウンロードします。
    11. [管理]タブをクリックし、[自動更新]>[手動更新を取得]をクリックして、すべてのファイルが最新バージョンであることを確認します。

      結果
      新旧両方の Console のバージョンが同じになったら、ルールやログ・ソースなどの設定を新 Console に移行するための設定バックアップを作成する準備が整いました。

    2. 旧 Console に構成バックアップを用意する

    構成バックアップは、作成した QRadar と同じバージョンにのみリストアすることができます。デプロイメントでQRadar 全体のバージョンを変更する予定がある場合、ソフトウェアのバージョン・アップ後に新しい構成バックアップを作成し、ハードウェアの移行に備えてこれらのファイルを安全な場所に保管する必要があります。
    1. 旧コンソールにログインします。
    2. [管理] タブをクリックし、バックアップとリカバリーアイコンをクリックします。
    3. ナビゲーション・メニューから、[オンデマンド・バックアップ]をクリックします。
    4. 新しい構成バックアップの名前と説明を入力します。
    5. バックアップの実行をクリックし、構成のバックアップが完了するのを待ちます。
    6. バックアップが完了したら、作成した新しい構成バックアップ名をクリックして、ファイルをダウンロードします。
    7. 古い QRadar Console から安全な場所に構成バックアップをコピーします。
    8. 古い Qradar Console で下記のコマンドを実行しサービスを停止します。 
      systemctl stop hostcontext
systemctl stop tomcat
systemctl stop hostservices
systemctl stop tunnel_manager
      注：これらのサービスは、古いコンソールの IP アドレスを再割り当てする前に古いコンソールで停止する必要があります。

      結果
      新しい Console で使用するための構成バックアップファイルが作成されます。このファイルは、ユーザ、ルール、ログソース、違反、レポート、管理者設定、およびその他のシステム設定を新しいハードウェアに復元するために、手順の後半で必要となります。これで、古いコンソールに、ネットワークの廃止または未使用の IP 範囲の IP アドレスを割り当てる準備が整いました。

    3. 古い QRadar コンソールの IP アドレスを再割り当てする。

    この処理は、qchange_netsetup ユーティリティーを使用するのではなく、管理インターフェースのネットワーク設定ファイルを直接調整することによって手動で行われます。この方法を使用して、競合を避けるためにシステムの物理的な IP アドレスを変更することができます。新しいコンソールで何らかの問題が発生した場合は、IP アドレスを元の値に戻すことが簡単にできます。古いコンソールで IP アドレスが変更された後、IP アドレスを元に戻さない限り、デプロイメント内の他のホストの変更に影響を与えることはできません。
    注意：旧コンソールの IP アドレスを手動で変更する場合は、接続やロックアウトの問題を防ぐため、IMM または物理キーボードを使用する必要があります。Linux® でネットワーク設定ファイルの編集に慣れている場合は、SSH と screen コマンドを使用することができます。直接 SSH セッションで systemctl restart network を使用すると、ネットワーク接続が失われ、アドレス変更とサービスの再起動に問題が発生します。
    1. リモートアクセス用の IMM、またはローカルの Console キーボードを使用して、古いアプライアンスのコマンド・ラインに root ユーザーでログインします。
    2. 次のコマンドを入力して、どのネットワーク・インターフェースが管理インターフェースであるかを確認します： 
      cat /etc/management_interface
      このファイルに記載されているインターフェースは、QRadar管理インターフェースです。
    3. ディレクトリを /etc/sysconfig/network-scripts/ に変更します。
    4. /etc/management_interface ファイルに記載されている ifcfg-<name> ファイルを開きます。
    5. IPADDR= の行を編集して、IP アドレスを未使用または廃止された範囲に変更します。
    6. 変更内容をファイルに保存します。
    7. 次のコマンドを入力して、ネットワークを再起動します： 
      systemctl restart network
      結果
      ネットワーク・サービスの再起動後、IP アドレスの変更が完了し、新しいコンソールで使用するために古い IP アドレスが解放されます。新しいアプライアンスにデータを転送し、機能を確認するまでは、古いハードウェアを撤去しないでください。新しいコンソールで問題が発生した場合、この手順で IP の変更を元に戻すことができます。

    4. 新しい QRadar Console に IP アドレスを設定する。

    このセクションでは、リモート管理またはコンソールのキーボードを使用して、新しいコンソールの IP アドレスを設定し、古いコンソールに以前に割り当てられた IP アドレスを使用することができます。すべての管理対象ホストがこの IP アドレスを使用して設定を取得し、期待される IP アドレスで新しい Console と会話するため、このステップは重要です。
    1. リモートアクセス用の IMM またはローカルの Console キーボードを使用して、新しいアプライアンスのコマンド・ラインに root ユーザーとしてログインします。
    2. 次のコマンドを入力して IP アドレスを変更します： 
      /opt/qradar/bin/qchange_netsetup
    3. 設定ウィザードを使用して、システムの IP アドレスを旧コンソールの IP アドレスに変更します。
    4. 保存してウィザードを終了すると、アドレスの変更が完了します。

      結果
      新しいコンソールは、デプロイメントの管理に必要な IP アドレスで更新されます。これで、新しいコンソールにキーと証明書をコピーする準備が整いました。

    5. 新しい QRadar Console で SSH キーと証明書をセットアップします。

    このセクションでは、ログ・ソースとスキャナーがリモート・ソースに接続できるように、古いアプライアンスから新しいアプライアンスに証明書とカスタム生成されたキー・ペアをコピーすることができます。また、/etc/ssh および /root/.ssh ディレクトリを転送して、カスタム生成された秘密鍵も移行する必要があります。
    1. 古い QRadar Console に root ユーザーとしてログインします。
      注：SSH セッションは廃止された IP レンジを使用する必要があります。古い Console にログインしていることを確認します。
    2. 以下の例のように rsync を使用して、古いハードウェアから新しいアプライアンスにデータをコピーします。
      注：古いコンソールと新しいコンソール間でクロスオーバー・ケーブルを使用する場合、-av コマンドを使用して転送速度を向上させることができます。
      証明書をコピーするには、次のように入力します。
      rsync -avz /opt/qradar/conf/trusted_certificates/ 
   root@new_appliance:/opt/qradar/conf/trusted_certificates/
      SSH 鍵をコピーするには、両方のコマンドを入力します： 
      rsync -avz /etc/ssh/ root@new_appliance:/etc/ssh
rsync -avz /root/.ssh/ root@new_appliance:/root/.ssh
    3. 転送が完了するのを待ちます。
    4. カスタム SSL 証明書を使用している場合は、以下の手順に従います：
      1. 古いコンソールの /etc/httpd/conf/certs ディレクトリーから、新しいコンソールの /tmp ディレクトリーまたはお好みの場所に、証明書または中間証明書をコピーします。

        新しい Console の /etc/httpd/conf/certs ディレクトリーに証明書をコピーしないでください。

      2. コピーした SSL 証明書を、/opt/qradar/bin/install-ssl-cert.sh -i で新しい Console にインストールし、指示に従います。

        ウィザードは、秘密鍵の入力を促します。秘密鍵が /etc/httpd/conf/certs/ ディレクトリーに保存されていない場合、サーバーにコピーする必要がある場合があります。通常、秘密鍵はサーバー自体に保存しないのがベスト・プラクティスです。

        重要：新しいアプライアンス上のコンソールに、古いアプライアンス上のコンソールとは異なる認証局（ CA ）証明書がある場合、古いアプライアンスからの CA は、ディレクトリー /etc/pki/ca-trust/source/anchors の下に配置し、コマンドを update-ca-trust 実行しなければなりません。
        結果
        必要な証明書と ssh キー・ファイルが新しい Console に転送されました。これで、旧 Console から新 Console へイベント・データおよびフロー・データを移行することができます。

    6. 新しい QRadar Console で設定バックアップを復元する。

    このセクションでは、ユーザー・インターフェースが新しい構成バックアップを表示できるように、構成バックアップファイルを受信ディレクトリーに配置する準備が整いました。
    1.  SCP を使用して、以前にダウンロードした構成バックアップ・ファイルを新しい Console の /store/backupHost/inbound/ ディレクトリーにコピーします。
    2. 新しい QRadar Console に管理者としてログインします。
    3. 管理 タブをクリックし、[バックアップとリカバリー]アイコンを選択します。
    4. Console にコピーした構成バックアップを選択し、[復元]をクリックします。
    5. 復元オプションのリストで、［すべての構成項目を選択］と［すべてのデータ項目を選択］をチェックします。
    6. リストアをクリックして、構成のリストア処理を開始します。
      注：リストア・プロセスはデータベースの完全な更新であるため、完了までに時間がかかる場合があります。
    7. リストア・プロセスが完了したら、QRadar にログインします。
    8. 管理 タブで、[詳細]>[全ての構成のでデプロイ]をクリックします。
      注：新しい Console のホスト名は、大文字小文字を含め、交換する古い Console アプライアンスの値と一致する必要があります。新しいアプライアンスをインストールする際にホスト名が異なる場合、構成のバックアップを復元した後にデプロイで問題が発生する可能性があります。
    9. 元のホストに報告したイベントまたはフロー・ソースが、QRadarで処理されるようになったことを確認します。

      結果
      ホストが QRadar デプロイメントに追加された後、デプロイメント・プロセスは、必要な構成が新しいアプライアンス上で再生成されることを確認します。ログ・ソース・データが収集され、フロー・データが新しいコンソールで受信されることを確認します。データを収集していないログ・ソースは、新しいホストに移動するための証明書が必要な場合があります。

      新しいコンソールで構成の復元が完了したとき、コンソールのライセンスキーの有効期限が切れたことを示すエラーが表示されることがあります。このエラーを解決するために、新しいライセンスを追加することができます。

    7. イベントとフロー・データを新しい QRadar Console に転送する。

    データ転送には時間がかかることがあります。アプライアンスが同じデーター・センターにある場合は、クロスオーバー・ケーブルを使ってイベントやフロー情報の転送を早めることができます。データは、パフォーマンスへの影響を最小限に抑えるため、1 ヶ月間隔で移動されます。syncAriel.sh ユーティリティーは、証明書や設定を移動せず、/store/ariel/ ディレクトリーに格納されているデータのみを移動します。データを移行するには、SSH トラフィックを許可する必要があります。転送を開始するために、SSH キーの受け入れとターゲット・サーバーのルート・パスワードの提供を要求される場合があります。

    1. この技術書から syncAriel.sh をダウンロードします。
    2. 旧 QRadar Console に root ユーザーでログインします。
    3. SCP を使用して、syncAriel.sh ユーティリティーを古い Console にコピーします。
    4. syncAriel.sh ユーティリティーのあるディレクトリーに移動し、次のコマンドを入力してパーミッションを設定します： 
      chmod +x syncAriel.sh
    5. 次のコマンドを入力します： 
      screen
      注：データ転送の場合、軽度のネットワーク障害が発生した場合に接続を再確立するために、screen セッションを開始します。データ転送を継続するためにスクリーンから離れるには、Ctrl+a+d を入力し、ログアウトします。既存のセッションに再接続するには、「 screen -r 」と入力します。
    6. 次のコマンドを入力してユーティリティーを実行します： 
      sh syncAriel.sh -i <new_Console's_IPAddress>
    7. 転送が完了するのを待ち、スクリーン・セッションを終了します。

      結果
      旧 Console の /store/ariel ディレクトリーから新 Console にデータが移行されます。接続が切れたり、ネットワーク障害が発生した場合は、syncAriel.sh ユーティリティーを再度実行してデータを移行することができます。syncAriel.sh ユーティリティーは、新しいアプライアンスに rsync されたファイルを追跡し、すでに転送されたデータは 2  回目にコピーされることはありません。転送に失敗したりエラーが発生した場合は、SCP、SFTP、または他のファイル転送方法を使用してデータを手動で転送します。

    管理者向け移行後チェックリスト

    デプロイメントの健全性を評価するために、ソフトウェアのアップデート後にコア機能が復元されていることを確認するために、従うべき標準的なチェックがあると便利です。管理者は、Console の移行機能を確認するために、このチェックリストを完了させることができます。

    1. Qradar のユーザーインターフェースにアクセスできますか？

    ブラウザーから Console のユーザー・インターフェースにログインできますか？
    ヒント：ソフトウェア更新後は、ブラウザーのキャッシュをクリアするか、ブラウザーのプライベートモードまたはシークレットモードを使用してログインを試みるのが最善です。
    レビューする内容
    1. SSH を使用して QRadar のコマンド・ラインに root ユーザーでログインを試みます。
      ソフトウェアの更新がまだ進行中の場合、コマンド・ラインには「Patch still in progress - DO NOT REBOOT!"」と表示されます。ユーザーは、ユーザー・インターフェースを利用できるようになるまでに、コンソール上でパッチの更新が完了し、サービスが再起動されるのを待つ必要があるかもしれません。
    2. SSH を使用してユーザー・インターフェースまたはコマンド・ラインにアクセスできない場合は、IMM またはハイパーバイザー・セッションを使用してコンソールにログインし、コンソールが実行されているかどうかを確認します。接続でき、コンソールが実行されている場合は、ネットワーク管理者に連絡してください。
    3. ユーザー・インターフェースにはアクセスできないが、SSH 経由でコンソール・システムにアクセスできる場合、systemctl status tomcatと入力します。
      ステータスが active または activating の場合、サービスはまだ初期化中です。場合によっては、Tomcat を起動してからユーザー・インターフェースにアクセスできるようになるまで、10 ～ 15 分ほど待つ必要があることがあります。

    2. 全てのマネージ・ドホストが期待通りのステータスを表示しているか?

    マネージド・ホストのいずれかが Active 状態でない場合、以下を確認してください：
    1. コンソールのコマンド・ライン・インターフェース（ CLI ）から、Active でない各マネージド・ホスト（ MH ）への SSH 接続を確立してみてください。

      接続に失敗するかタイムアウトした場合：
      • IMM リモート・コンソール、またはシステムが VM の場合はハイパーバイザーなどの他のローカル・コンソール接続を介して、MH へのローカル・コンソール接続を確立してください。
        • システムが応答し、「 root 」でのログインが可能かどうかを確認します。
        • システムが応答しない場合、IMM またはハイパーバイザーのコンソールにアクセスすることはできますか。これは、ネットワークの問題を示している可能性があります。詳細については、Technical note 1997106- Using Linux Networking Tools to troubleshoot Interfaces を参照してください。
        • MH がローカル・コンソール接続で応答する場合、コンソールと MH 間のネットワーク接続を確認するために追加のトラブルシューティングを実行する必要があります。詳細については、以下を参照してください： Technote 1981436 - QRadar: Troubleshooting tunnels and SSH issues in QRadar.
    2. Full Deploy タスクは、すべての マネージド・ホスト に対して正常に完了しますか？
      • デプロイ・タスクが完了し、すべてのホストのステータスを返した時、Timed Out またはその他のデプロイに失敗したと報告したすべての管理ホストについて：
        • MH 上のファイル /opt/qradar/conf/hostcontext.NODOWNLOADをチェックしてください。この問題を解決する方法の詳細について次の technote を参照してください。  Technote 10744001 - Deploy Changes Does Not complete or Times out.
        • すべてのパーティションに十分な空きディスク容量があることを確認します：
          • SSH で MH に「 root 」で接続し、「 df -h 」と入力します。各パーティションのディスク使用率（「 Use% 」）が 85 % を超えている場合は、該当するパーティションの空き容量を確保して、再度試してください。 ディスク容量の問題を解決する方法に関する詳細については、Troubleshooting disk space issues を参照してください。

    3. 全てのダッシュボードは表示されていますか？

    ダッシュボードは、蓄積されたデータ（グローバル・ビュー（ GV ）またはアグリゲーション・データ・ビュー（ ADV ）とも呼ばれる）に対する ariel queries に大きく依存しています。
    • 一部のダッシュボードがポップアップしないが、他のダッシュボードは動作している場合、個々の Global Views に問題がある可能性があります。破損したグローバル・ビューのトラブルシューティングを行うには、どのダッシュボードが影響を受けているかを記録してください。
    • すべてのダッシュボードの生成が失敗している場合、アキュムレーター・サービスのステータスを確認します。
      • すべてのホストで、アキュムレーター・サービスはアクティブである必要があります。コンソールのコマンド・ラインから次のように入力します： 
          /opt/qradar/support/all_servers.sh -C 'systemctl is-active accumulator'
        accumulator がアクティブでないホストでは、
        `systemctl restart accumulator` コマンドでサービスを手動で再起動してみてください。
      • Console とすべての EP、FP、EP / FP、および Data Node ホストでは、ariel サービスも実行されている必要があります。コンソールでは ariel は ariel_proxy_server として実行されます。その他の関連するホストは、arielをariel_query_server として実行します。
        • コンソールで以下を実行します：
          systemctl is-active ariel_proxy_server
        • 残りの マネージド・ホスト で ariel を確認するには、以下のコマンドを実行します。Console CLI から次のコマンドを実行します：
          /opt/qradar/support/all_servers.sh -a '16%,17%,18%,21%' 'systemctl is-active ariel_query_server'
        • ariel* サービスが停止している場合、影響を受けるシステム上で `systemctlrestart <service>` を使って関連サービスを手動で開始してみてください。
          • ariel がいずれかのシステムで失敗した場合、そのマネージド・ホストからイベントまたはフロー・データを蓄積またはその他の方法で取得することができない場合があります。

    4. オフェンスは生成され、更新されていますか？

    1. 直近で更新された Offenses の「 Last Event / Flow Seen 」で、タイムスタンプが新しいか。
    2. 1xx、18xx、17xx、16xx のすべてのホストで ecs-ep が実行されているかどうかを確認します：
           - 7.2.8 の場合： /opt/qradar/support/all_servers.sh -C -a '31%,18%,17%,16%,software' "service ecs-ep status"
           - 7.3.x 以降の場合： /opt/qradar/support/all_servers.sh -C -a '31%,18%,17%,16%,software' "systemctl is-active ecs-ep"

      A.サービス・ステータスが故障している場合
      サービスの状態が「失敗」の場合は、サービスの再起動をお試しください：
        - 7.2.8 の場合： /opt/qradar/support/all_servers.sh -C "service ecs-ep restart"
        - 7.3.x 以降の場合： /opt/qradar/support/all_servers.sh "systemctl restart ecs-ep"
      ecs-ep がいずれかのシステムで起動に失敗した場合、ecs-ep が期待通りに起動しないホストにて下記の資料を収集しサポート・ケースを作成してください。 collect the logs for the Console system and any affected managed host  open a case with QRadar Support.

      B.マネージド・ホストでサービス・ステータスが実行されている場合
      システムが正常に動作し、ルールをトリガーにしてオフェンスを生成しているイベントやフローがない可能性を除外します。管理者は、ルールを作成することで、オフェンスの作成を確認することができます：
      1. QRadar UIで、[Offenses]タブをクリックし、[Rules]を選択します。
      2. ルールが表示されたら、［アクション］＞［新規イベントルール］を選択します。
      3. 一貫してイベントを生成している環境内のソース IP（または IP 範囲）を特定します。
      4. 上記で特定されたアドレスまたは範囲を使用して、新しいイベント・ルールを構成します：
        • ローカル・システムで検出されたイベントで、ソース IP が次の IP アドレスのいずれかである場合に、オフェンス・テスト規則を適用し、［次へ］をクリック します。
      5. レスポンスのオプションを設定します：
        • [検出されたイベントがオフェンスの一部であることを確認する] チェック ボックスを選択します。
        • ソース IP ごとに 1 分間に 1 回以上応答しない。
        • 完了をクリックします。
        • Offenses タブで、ルールが有効になっていることを確認します。
        • [ログ・アクティビティー]タブで、ルールに設定したソース IP または範囲のフィルターを追加し、受信するイベントを監視します。
      6. この IP または範囲にイベントが表示されると、新しいオフェンスが作成され、ソース IP または範囲のイベントがそのオフェンスに関連付けられることが確認されます。
      7. テストが完了し、コンソールでオフェンスが生成されたことを確認したら、ルールを無効化します。

    5. イベントやフローを検索して見る事ができますか？

    1. QRadar に新しいイベントやフロー・データが表示されているか？
           1A.[ログ・アクティビティー]タブをクリックし、「表示」>「リアルタイム（ストリーミング）」を選択します。
           1B.[ネットワーク・アクティビティー]タブをクリックし、「表示」>「リアルタイム（ストリーミング）」を選択します。
    2. Console、Event Processors、Event and Flow Processors はイベントを受信していますか？
      [ログ・アクティビティー]タブで、[クイック検索] > [イベント・プロセッサーの配布 - 過去 6 時間]を選択します。Console  ( 31xx ) 、Event Processors  ( 16xx ) 、Event and Flow Processors ( 18xx ) のアプライアンスが検索結果に表示されることを確認します。
    3. 通常の検索を実行することはできますか？
      • 「ソース IP が127.0.0.1 」のフィルタリングで 5 分間のシンプルな検索を実行してみてください。 エラーなしで完了しますか？
      • IO エラーが発生した場合は、この情報を使ってトラブルシュートしてみてください：

    6. Asset タブでは期待通りに作成されていますか？

    1. アセット・ページは期待通りにロードされ、作成されていますか？
    2. 最近更新されたアセットの最終更新時刻は比較的新しいですか？

    7. 全てのユーザーが Console のユーザー・インターフェースにログインできますか？

    1. ローカルの「 admin 」アカウントは、ユーザー・インターフェースにログインできますか？
    2. ローカルの非管理者ユーザーはユーザー・インターフェースにログインできますか？
    3. ローカル・ユーザー以外のユーザー（ LDAP など、該当する場合）は、ユーザー・インターフェースにログインできますか？

    8. 全てのアプリはロードされ、実行されていますか？

    1. 基本的なアプリのトラブルシューティングをしてください。 Basic app troubleshooting before opening a QRadar Support case.

    9. CLI の追加チェック Additional CLI checks

    1. 上記のチェックは、ほとんどのコア機能をカバーしているはずです。次のコマンドを実行して、すべての QRadar プロセスが開始されていることを確認できます: 
        /opt/qradar/upgrade/util/setup/upgrades/wait_for_start.sh
      注: アップグレード後少なくとも 3 回繰り返し、すべてのプロセスが実行中であることを確認します。数回繰り返した後、停止していると表示されたサービスがある場合は、そのサービスをメモし、Ctrl +c キーを押してユーティリティーを停止します。
      image-20200217175930-1
    2. 高可用性（ HA ）を使用している場合、管理者は ha cstate コマンドを使用して、HA ペアのステータスと同期を確認することができます： Troubleshooting QRadar HA deployments.
    3.   QRadar Dashboard のシステム通知を確認して、Predictive Disk Failure がないか確認する： QRadar: Troubleshooting Disk Failure or Predictive Disk Failure Notifications
    4.   Console アプライアンスが X-Force Threat Intelligence フィードをポーリングすることを確認するには、次のコマンドを入力します： tail -f /var/log/dca/sca_server.log

      コンソールは 3 分ごとにデータのポーリングを試み、sca_server.log ファイルにエラーを返してはいけません。成功すると、IP レピュテーション（ IPR ）および URL 分類の新しいデータベース・バージョンがインストールされたときにログに表示されます。
      2020-02-17 17:50:22.354 I UPDATE: Result #1 id=20, module=IPR Classification, contentUpdated=true, engineUpdated=false, details=1 0 19614
      2020-02-17 17:50:22.354 I UPDATE: Detail #0: component=ipr_database old version=6.01117773 new version=6.01117774 available=true downloaded=true installed=false return=download or install scheduled 0 19614   

    マイグレーションがインストール後のチェックに失敗したのですが、どうすればいいですか？

    1. 失敗した手順のトラブルシューティングの手順をすべて記録します。
    2. 可能であれば、コンソールからログを収集します。ログの収集方法の詳細については、以下を参照してください。 Getting logs from a QRadar deployment
    3. ログやマイグレーション手順を記載してケースをオープンしてください。 IBM QRadar Support.
    4. アプライアンスが利用できない、または機能しない場合、「システム・ダウン」問題があることを示すことができます。
    5. QRadar サポートの担当者が、ご希望の連絡手段でご連絡します。



    本問題により、ご迷惑をおかけしましたことをお詫び申し上げます。本技術書の内容に関するご質問は、下記までご連絡ください。 QRadar Support.

    - QRadar サポート

     

    [{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwtdAAA","label":"Upgrade"}],"Platform":[{"code":"PF016","label":"Linux"}],"Version":"7.5.0"}]

    Document Information

    Modified date:
    14 April 2023

    UID

    ibm16982065

    Page Feedback