Security Center:脆弱性管理に関するよくある質問

スキャンの動作と結果

• なぜ同じサーバーで同じ脆弱性が複数報告されるのですか？

  アプリケーションの脆弱性検出は、特定の実行中のプロセスインスタンスを対象とします。サーバー上で同じ脆弱性を持つプロセスが複数インスタンスで実行されている場合 (例えば、異なるポートで起動された 2 つの同一の Tomcat サービス)、システムは各プロセスインスタンスに対して個別の脆弱性を報告します。脆弱なソフトウェアがインストールされていても実行されていない場合、Security Center はその脆弱性を検出しません。

• Fastjson のような脆弱性のスキャン結果が時々異なるのはなぜですか？

  このような脆弱性の検出は、スキャン中にそのコンポーネント (JAR パッケージなど) が「ランタイム」状態にロードされるかどうかに依存します。動的ロードモデルでは、ビジネスロジックが脆弱なコンポーネントを呼び出したときにのみ、Security Center は脆弱性を検出できます。そのため、スキャン結果は時間によって異なる場合があります。

  説明

  この種の脆弱性の検出精度を向上させるために、定期的または複数回のスキャンを実行することを推奨します。

• エージェントがオフラインになった後も、コンソールにそのホストの脆弱性レコードが表示され続けるのはなぜですか？

  エージェントがオフラインになると、Security Center は検出された脆弱性レコードをコンソールに保持します。ただし、これらのレコードは自動的に古くなり、修復、検証、クリアなどの操作は実行できなくなります。脆弱性が自動的に古くなるまでの期間は次のとおりです：

  重要

  Security Center サービスが有効期限切れになり、7 日以内に更新されない場合にのみ、Security Center はすべてのデータを完全に削除します。

  • Linux Software Vulnerability および Windows System Vulnerability：3 日後に古くなります。

  • Web-CMS Vulnerability：7 日後に古くなります。

  • Application Vulnerability：30 日後に古くなります。

  • 緊急の脆弱性：90 日後に古くなります。

パフォーマンスへの影響とセキュリティ

• 緊急の脆弱性に対する脆弱性スキャンやアクティブ検証 (POC) は、業務システムに影響しますか？

  通常、影響はありません。Security Center のアクティブ検証 (POC) は、ごく少数 (1〜2 個) の無害なプローブリクエストを送信するだけで、いかなる形式の攻撃や破壊的な操作も行いません。まれに、ターゲットアプリケーションが予期しない入力の処理に対して非常に脆弱である場合に、最小限のリスクが存在します。

• 脆弱性スキャンがメモリ不足 (OOM) エラーを引き起こすことがあるのはなぜですか？

  Security Center エージェントには、設定されたメモリ制限 (デフォルトで 200 MB) があります。スキャンがこの制限を超えると、システムのリソースを節約するために、システムの OOM メカニズムが検出プロセス (ALiSecCheck) を積極的に終了させます。

  説明

  • この制限は通常、aegisRtap0 という名前のコントロールグループ (cgroup) によって管理されます。関連する OOM 情報は dmesg ログで確認できます。

  • この動作は正常であり、システム全体でのメモリ不足とは関係ありません。ユーザーによる操作は必要ありません。

  • この OOM エラーは cgroup のメモリ制限によって引き起こされるものであり、システム全体がメモリ不足であることを示すものではありません。

スキャンの範囲と機能

1. 脆弱性スキャンの範囲は何ですか？

   スキャンはシステム層とアプリケーション層の両方を対象とします：

   • システムレベル：Linux ソフトウェアの脆弱性と Windows システムの脆弱性。

     重要

     Windows システムの脆弱性スキャンは、月次のセキュリティ更新プログラムに限定されます。

   • アプリケーションレベル：Web-CMS の脆弱性、アプリケーションの脆弱性、緊急の脆弱性。

2. Security Center が検出できる脆弱性のリストはどこで確認できますか？

   1. Security Center コンソールにログインします。

   2. 左側のナビゲーションウィンドウで、脆弱性管理 をクリックして脆弱性スキャンページに移動します。概要セクションで、すでにサポートされている脆弱性 統計カードを見つけます。

   3. カード上の脆弱性の総数をクリックしてリストページを開き、サポートされているすべての脆弱性とその詳細を表示できます。

3. Security Center は Elasticsearch のような特定の脆弱性の検出をサポートしていますか？

   はい。コンソールの Application Vulnerability ページで、Elasticsearch などのサービスの脆弱性検出結果を表示できます。

   説明

   この機能は、Subscription サービス (Enterprise および Ultimate エディション) と Pay-as-you-go サービス (Host Protection および Hosts and Container Protection) でのみ利用可能です。ご利用のエディションがこの機能をサポートしていない場合は、まず アップグレードしてください。

修復の制限と原則

• 脆弱性を修復しようとすると [修復] ボタンがグレー表示されるのはなぜですか？

  • 製品エディションの制限

    • エディションが低すぎる：Basic および Anti-virus エディションは、ワンクリック修復をサポートしていません。

    • 解決策：「脆弱性修復」付加価値サービス (VAS) を購入するか、Enterprise または Ultimate Edition にアップグレードしてください。

  • サーバーの問題

    Linux

    • オペレーティングシステムのメンテナンスが終了している：ベンダーがパッチを提供しなくなりました。オペレーティングシステムのバージョンを手動でアップグレードする必要があります。現在、以下のオペレーティングシステムの脆弱性は OS のアップグレードによって修復する必要があります。

      • Red Hat 5、Red Hat 6、Red Hat 7、Red Hat 8

      • CentOS 5

      • Ubuntu 12

      • Debian 8、9、10

    • ディスク領域の不足：空き領域が 3 GB 未満です。ディスクをクリーンアップするか、拡張してください。

    • プロセスがビジー状態：apt または yum プロセスが実行中です。それが終了するのを待ってから再試行するか、手動でプロセスを停止してください。

    • 権限不足：修復コマンドを実行するユーザーに十分な権限がありません。ファイル所有者が root ユーザーであることを確認し、755 などの適切な権限を設定してください。

    Windows

    • ディスク領域の不足：空き領域が 500 MB 未満です。ディスクをクリーンアップするか、拡張してください。

    • Windows Update サービスが異常です：サービスが無効になっているか、実行中です。

      • 無効：サーバーのシステムサービスマネージャーに移動し、Windows Update サービスを有効にしてから、再度脆弱性の修復を試みてください。

      • 実行中：実行中の場合は、それが終了するのを待つか、サーバー上で Wusa プロセスを手動で終了させてから、再度脆弱性の修復を試みてください。

• アプリケーションの脆弱性とシステムの脆弱性の違いは何ですか？なぜワンクリック修復はアプリケーションの脆弱性をサポートしないのですか？

  • Linux ソフトウェアの脆弱性や Windows システムの脆弱性などのシステムの脆弱性は、オペレーティングシステムまたはそのコンポーネントの脆弱性です。その修復パスは標準化されているため、ワンクリック修復がサポートされています。

  • アプリケーションの脆弱性は、ウェブサイトのコードやサードパーティ製ソフトウェアなど、自己デプロイされたアプリケーションに存在します。その修復方法はビジネスロジックやコードの実装と密接に関連しています。ビジネスを理解せずに自動的に修復することはできないため、手動で対処する必要があります。

• なぜ自分のサーバーにはこんなに多くの脆弱性があるのですか？

  新しい攻撃手法が常に登場するため、古いソフトウェアのバージョンでは継続的に脆弱性が発見されます。そのため、定期的なスキャンとパッチ適用は、継続的なセキュリティタスクです。重大なリスクにフォーカスするには、Show Only Exploitable Vulnerabilities スイッチをオンにできます。

修復操作

• 修復コマンドの実行時に「権限の取得に失敗しました。権限を確認して再試行してください」というメッセージが表示された場合はどうすればよいですか？

  • 原因：修復操作に必要なファイルの所有者が root ではないため、権限が不足しています。

  • 解決策：

    1. ファイルの特定：

       Security Center で、脆弱性の詳細を表示して、修復が必要な特定のファイルとそのパスを確認します。

    2. 権限の変更：

       サーバーにログインし、次のコマンドを実行してファイル所有者を root に変更します。

    3. 修復の再試行：

       Security Center コンソールに戻り、脆弱性に対する修復操作を再度実行します。

• 脆弱性をバッチで修復する場合、どのような順序で修復されますか？

  Linux ソフトウェアの脆弱性と Web-CMS の脆弱性は、コンソールの脆弱性リストに表示される順序でバッチ修復されます。一部の Windows システムの脆弱性を修復するには、まず前提条件となるパッチをインストールする必要があります。Windows システムの脆弱性をバッチで修復する場合、これらのタイプの脆弱性が最初に修復されます。残りの脆弱性は、コンソールの脆弱性リストに表示される順序で修復されます。

• Ubuntu カーネルパッチの脆弱性を修復した後の再起動が効果がないのはなぜですか？

  • 症状：Ubuntu サーバーのカーネル脆弱性に対して Security Center のワンクリック修復を使用した後、「修復済み、再起動待ち」と表示されても、サーバーを再起動した後に脆弱性アラートが依然として存在します。システムは新しくインストールされたカーネルを有効にしていません。

  • 原因：これは通常、GRUB ブートメニューのデフォルトの起動順序が以前に手動で変更されたためです。この場合、システムの修復スクリプトは、新しくインストールされたカーネルをデフォルトのブート項目として自動的に設定できません。

  • 解決策：

    解決策 1：新しいカーネルを自動的に構成する

    この解決策は、元のカスタム GRUB 構成を破棄し、システムが新しいカーネルのデフォルト設定を自動的に適用するようにします。

    手順：

    1. 脆弱性修復を実行する前に、ご利用の Ubuntu サーバーにログインします。

    2. 次のコマンドを実行して環境変数を設定します：

       <BASH>
       
       export DEBIAN_FRONTEND=noninteractive

    3. Security Center コンソールに戻り、脆弱性に対してワンクリック修復を実行します。

    4. 修復が完了したら、プロンプトに従ってサーバーを再起動します。システムは自動的に最新のカーネルを有効にします。

    解決策 2：起動順序を手動で変更する

    元の GRUB 構成を維持したい場合は、この解決策を選択できます。

    手順：

    1. Security Center コンソールで、通常のワンクリック修復を実行し、プロンプトに従ってサーバーを再起動します。

    2. 修復と再起動の後、ご利用の Ubuntu サーバーにログインします。

    3. GRUB の起動順序を手動で変更し、新しくインストールされたカーネルバージョンをデフォルトのブート項目として設定します。

       説明

       具体的な操作には、通常 /etc/default/grub ファイルの変更と update-grub コマンドの実行が含まれます。関連する操作については、「 ECS Linux CentOS のカーネル起動順序の変更」をご参照ください。

    4. 新しい起動順序を有効にするために、サーバーを再度再起動します。

• 脆弱性を修復した後にシステムを再起動する必要がありますか？

  • Windows：再起動が必要です。

  • Linux Software Vulnerability：次のいずれかの条件を満たす場合に再起動が必要です：

    • カーネルの脆弱性が修復された。

    • Security Center コンソールのリスクガバナンス > 脆弱性管理ページのLinux Software Vulnerabilityタブでは、脆弱性に関するお知らせにRestart Requiredタグが表示されます。

      

• 脆弱性のロールバック操作が失敗するのはなぜですか？

  脆弱性のロールバック操作が失敗した場合、次のパスに沿ってトラブルシューティングできます：

  1. クライアント (エージェント) の状態を確認する

     ロールバック操作は、Security Center エージェントがオンラインであることに依存します。エージェントがオフラインの場合、コマンドを配信できません。まず、そのオフラインの問題をトラブルシューティングして解決する必要があります。

  2. バックアップスナップショットが有効であることを確認する

     ロールバック機能は、修復前に作成されたバックアップスナップショットに基づいています。スナップショットが有効期限切れになったり、手動で削除されたりした場合、ロールバックは実行できません。

• 脆弱性の修復時にスナップショットの作成が失敗するのはなぜですか？

  脆弱性の修復時にスナップショットの作成が失敗する理由は次のとおりです：

  • 現在の操作が RAM ユーザーによって実行されている：現在 RAM ユーザーを使用していて、そのユーザーにスナップショットを作成する権限がない場合、コンソールはスナップショットの作成に失敗したことを通知します。操作には Alibaba Cloud アカウントを使用することを推奨します。RAM ユーザーの詳細については、「RAM ユーザーの概要」をご参照ください。

  • サーバーが Alibaba Cloud サーバーではない：Alibaba Cloud 以外のサーバーは、脆弱性を修復するためのスナップショット作成をサポートしていません。

修復後の状態と検証

• 脆弱性は修復済みですが、Security Center は依然としてそれを報告します。どうすればよいですか？

  • 原因：これは、Linux カーネルの脆弱性など、一部の脆弱性が修復後にサーバーの再起動を必要とするために発生します。

  • 解決策：脆弱性の詳細ページで、Restart をクリックします。再起動が完了したら、認証 をクリックします。「修復済み」と表示されれば、脆弱性は正常に修復されています。

• ホストに対応するパッチがインストールされていません。なぜ Windows の脆弱性が正常に修復されたと表示されるのですか？

  これは Windows の更新メカニズムによって引き起こされる正常な現象です。最新の累積的な更新プログラムがインストールされていれば、それに含まれるすべての過去の脆弱性が修復されるため、古いパッチを一つずつインストールする必要はありません。

  説明

  Microsoft の公式パッチウェブサイトにアクセスし、インストールされた最新のパッチ (通常は KB 番号で識別) を検索し、その「パッケージの詳細」を確認して、懸念している古い脆弱性がカバーされているかどうかを確認できます。

  • 原因：Windows の累積的な更新プログラムのメカニズム

    Windows のセキュリティ更新プログラムは「累積」モデルを使用しています。これは、最新の月次セキュリティパッチが、リリース日までの過去数ヶ月間のすべてのセキュリティ修正を含むコレクションパッケージであることを意味します。

  • 解決策：Security Center がシステムに最新の累積的な更新プログラムがインストールされていることを検出すると、それがカバーするすべての古い脆弱性を「修復済み」としてマークします。したがって、過去の各脆弱性に対して個別のパッチをインストールする必要はありません。

• 脆弱性を修復した後、なぜコンソールに「未修復」と表示され続けるのですか？

  考えられる理由は次のとおりです：

  1. 検証の遅延：手動で修復した後、認証 ボタンをクリックして即時スキャンをトリガーする必要があります。ステータスの更新には数分かかります。

  2. キャッシュの問題：コンソールページにキャッシュが残っている可能性があります。ページを強制的にリフレッシュするか、数分待ってみてください。

  3. 不完全な修復：修復操作が完全に成功していないか、複数の脆弱性パスがあり、そのうちの 1 つしか修復されていない可能性があります。修復手順を再確認してください。

• Fixed and Pending Restarted 状態の脆弱性：Security Center は自動的に検証できますか？

  いいえ。Security Center コンソールからサーバーを再起動するか、手動でサーバーを再起動する必要があります。再起動が完了したら、認証 をクリックして、脆弱性が正常に修復されたかどうかを確認します。

  重要

  積極的に検証しない場合、Security Center は後続の定期スキャン中に自動的にチェックします。システムが最初のスキャンで脆弱性を検出しなかった後、脆弱性情報を 3 日間保持します (ネットワークやその他の理由による誤判定を防ぐため)。3 日間連続で検出されなかった場合、システムは脆弱性レコードをクリアします。

• 脆弱性を修復した後に手動で検証しても応答がないのはなぜですか？

  サーバー上で脆弱性を手動で修復した後、Security Center コンソールの「検証」機能で脆弱性ステータスを「修復済み」に更新できない場合、通常は次の 2 つの理由が考えられます：

  • 脆弱性スキャンレベルの構成が不完全

    • 原因：Security Center は 脆弱性管理の設定 で選択されているリスクレベルのみをスキャンして更新します。ターゲットの脆弱性のリスクレベル (例えば、重要または中間) が選択されていない場合、システムはそのレベルの脆弱性のステータスを更新しません。

    • 解決策：脆弱性管理の設定 のスキャンレベルが、ターゲットの脆弱性のリスクレベルをカバーしていることを確認してください。

  • Security Center クライアント (エージェント) がオフライン

    • 原因：「検証」機能は、コンソールとサーバー上のクライアントとのリアルタイム通信に依存しています。クライアントがオフラインの場合、コンソールは検証コマンドを配信したり、結果を受信したりできません。

    • 解決策：クライアントのオフライン問題をトラブルシューティングして解決してください。オンラインに戻った後、再度検証操作を実行してください。

特定の種類の脆弱性の修復

• アップグレード後も Security Center がカーネルの脆弱性を報告し続ける場合はどうすればよいですか？

  1. カーネルがアップグレードされたことを確認する。

     1. 実行中のカーネルのバージョンを確認し、脆弱性の詳細で指定された要件を満たしていることを確認します。

        uname -av
        cat /proc/version

     2. システムが新しいカーネルを使用して起動することを確認します。

        cat /etc/grub.conf

  2. 古いカーネルの RPM パッケージを確認して削除する。

     1. システムにインストールされているすべてのカーネルパッケージを表示して、実行中のカーネルよりバージョン番号が低い古いカーネルパッケージを見つけます。

        rpm -qa | grep kernel

     2. システムの保護スナップショットを作成する (強く推奨)。

        Elastic Compute Service (ECS) コンソールで、現在のインスタンスのスナップショットまたはイメージを作成し、誤った削除によって引き起こされる可能性のあるシステムの例外や起動の失敗を防ぎます。

     3. 古いカーネルの RPM パッケージをアンインストールする。

        2. 使用されていない古いカーネルバージョンのみをアンインストールします。例：

           rpm -e kernel-<old_version_number>

        3. または、ディストリビューションが推奨する方法を使用します。CentOS/RedHat の場合：

           yum remove kernel-<old_version_number>

  3. アラートを無視する

     実行中のカーネルが脆弱性を修復したことを確認した場合、アラートを無視できます。

     1. Security Center コンソールにログインします。

     2. 左側のナビゲーションウィンドウで、リスクガバナンス > 脆弱性管理 を選択します。コンソールの左上隅で、アセットがデプロイされているリージョンを選択します：Chinese Mainland または Outside Chinese Mainland。

     3. [Linux ソフトウェアの脆弱性] タブで、脆弱性を見つけてその名前をクリックし、[脆弱性の詳細] ページに移動します。

     4. [操作] 列で、 アイコンをクリックし、[無視] を選択します。

• Ubuntu カーネルを手動で更新するにはどうすればよいですか？

  重要

  カーネルバージョンの更新はリスクの高い操作です。「サーバーソフトウェアの脆弱性を修復する方法に関する提案」の指示に従ってカーネルを更新することを強く推奨します。

  次の例は、Ubuntu 14.04 システムでカーネル 3.1* をカーネル 4.4 に手動で更新する方法を示しています。

  1. uname -av コマンドを実行して、現在のカーネルバージョンが 3.1* であることを確認します。

     

  2. 次のコマンドを実行して、最新のカーネル更新パッケージが利用可能かどうかを確認します：

     apt list | grep linux-image-4.4.0-94-generic
     apt list | grep linux-image-extra-4.4.0-94-generic

  3. 関連する更新がない場合は、apt-get update コマンドを実行して最新の更新パッケージを取得できます。

  4. 次のコマンドを実行してカーネルを更新します。

     apt-get update && apt-get install linux-image-4.4.0-94-generic
     apt-get update && apt-get install linux-image-extra-4.4.0-94-generic

  5. 更新パッケージがインストールされたら、サーバーを再起動して新しいカーネルを適用します。

  6. サーバーが再起動した後、次のコマンドを実行してカーネルが更新されたことを確認します：

     • uname -av コマンドを実行して、実行中のカーネルをクエリします。

       

     • dpkg -l | grep linux-image コマンドを実行して、現在のカーネルパッケージの詳細をクエリします。

       

• Security Center コンソールの一部の脆弱性に更新がない場合はどうすればよいですか？

  脆弱性に利用可能な更新がないと表示される場合、それは影響を受けるソフトウェアの公式な更新ソースがないことを意味します。Security Center コンソールで脆弱性を修復することはできません。次の指示に基づいて解決策を選択できます：

  • 公式の更新ソースがパッチを提供していない

    • 問題：更新コマンドを実行すると、システムは already installed and latest version や No Packages marked for Update のようなメッセージを返します。

    • 影響を受けるソフトウェアパッケージ：Gnutls、Libnl、MariaDB

    • 解決策：公式のソフトウェアソースが更新をリリースするのを待ちます。

  • オペレーティングシステムのバージョンがサポート終了 (EOL) に達している

    • 問題：現在のシステムでサポートされている最新バージョンであっても、ソフトウェアパッケージが脆弱性修復のバージョン要件を満たしていない場合があります。これは、CentOS 6.x のように公式にメンテナンスされなくなったオペレーティングシステムのバージョンで発生する可能性があります。

    • 解決策：

      • 解決策 1：オペレーティングシステムを公式サポート期間内のバージョンにアップグレードします。

      • 解決策 2：リスクを評価し、管理可能であることを確認した後、Security Center コンソールで脆弱性を無視できます。