Updated on 2024-06-18 GMT+08:00

Fixing Vulnerabilities

Scenario

If HSS detects a vulnerability on a server, you need to handle the vulnerability in a timely manner based on its severity and your business conditions to prevent further vulnerability exploits.

The fixing method varies depending on the vulnerability type. Select a method based on the vulnerability type. The recommended fixing methods are as follows.

Table 1 Recommended fixing methods

Vulnerability Type

Recommended Fixing Method

Linux vulnerabilities

Use either of the following methods:

  • Use the repair function on the SecMaster console to fix the vulnerability.
  • Manually fix the vulnerability based on the suggestions provided on the console.

Then, you can use the verification function to quickly check whether the vulnerability has been fixed.

Windows vulnerabilities

Web-CMS vulnerabilities

Manually fix the vulnerability based on the suggestions provided on the console.

Application vulnerabilities

  • Vulnerability fixing operations cannot be rolled back. If a vulnerability fails to be fixed, services will probably be interrupted, and incompatibility issues will probably occur in middleware or upper layer applications. To prevent unexpected consequences, you are advised to use CBR to back up ECSs. For details, see Purchasing a Server Backup Vault. Then, use idle servers to simulate the production environment and test-fix the vulnerability. If the test-fix succeeds, fix the vulnerability on servers running in the production environment.
  • Servers need to access the Internet and use external image sources to fix vulnerabilities. If the server cannot access the Internet or the services provided by the external image source are unstable, you can use the image source provided by Huawei Cloud to fix vulnerabilities. To ensure that the vulnerability is successfully fixed, ensure that the image source . For details, see Configuring the Image Source.

Constraints

  • For details about how to fix vulnerabilities detected by HSS, see Types of Vulnerabilities That Can Be Scanned and Fixed.
  • CentOS 6 and CentOS 8 are officially End of Life (EOL) and no longer maintained. HSS scans them for vulnerabilities based on Red Hat patch notices but cannot fix them. You are advised to change to other OSs.
  • Ubuntu 18.04 and earlier versions do not support free patch updates. You need to purchase and configure Ubuntu Pro to install upgrade packages, or vulnerability fix will fail.
  • The kernel vulnerabilities on CCE, MRS, and BMS servers cannot be fixed. Fixing them may make some functions unavailable.
  • Kernel vulnerabilities of CCE hosts cannot be automatically fixed. HSS automatically filters out such vulnerabilities when fixing vulnerability in batches.
  • To handle vulnerabilities on a server, ensure the server is in the Running state, its agent status is Online, and its protection status is Protected.

Fixing Vulnerabilities on the Console

Only Linux vulnerabilities and Windows vulnerabilities can be fixed using the repair function on the console.

  1. Log in to the management console.
  2. Click in the upper left corner of the page and choose Security & Compliance > SecMaster.
  3. In the navigation pane on the left, choose Workspaces > Management. In the workspace list, click the name of the target workspace.

    Figure 1 Workspace management page

  4. In the navigation pane on the left, choose Risk Prevention > Vulnerabilities.

    Figure 2 Accessing the vulnerability management page

  5. On the displayed page, click Linux Vulnerabilities or Windows Vulnerabilities.
  6. In the vulnerability list, click the name of the target vulnerability. The vulnerability details page is displayed.
  7. On the Vulnerability Details page, click Affected Resources. In the resource list, locate the row that contains the target resource and click Repair in the Operation column.

    To fix vulnerabilities in batches, select all the target vulnerabilities and click Batch Repair in the upper left corner above the list.

  8. If a vulnerability is fixed, its status will change to Fixed. If it fails to be fixed, its status will change to Failed.

    Restart the system after you fixed a Linux kernel vulnerability, or the system will probably continue to warn you of this vulnerability.

Manually Fixing Software Vulnerabilities

One-click automatic fix of Web-CMS or application vulnerabilities is not supported. You can log in to the server to manually fix them by referring to the fix suggestions on the vulnerability details slide-out panel.

  • Vulnerability Fixing Commands

    On the basic information page of vulnerabilities, you can fix a detected vulnerability based on the provided suggestions. For details about the vulnerability fixing commands, see Table 2.

    • Restart the system after you fixed a Windows or Linux kernel vulnerability, or the system will probably continue to warn you of this vulnerability.
    • Fix the vulnerabilities in sequence based on the suggestions.
    • If multiple software packages on the same server have the same vulnerability, you only need to fix the vulnerability once.
    Table 2 Vulnerability fix commands

    OS

    Fix Command

    CentOS/Fedora/EulerOS/Red Hat/Oracle

    yum update Software name

    Debian/Ubuntu

    apt-get update && apt-get install Software name --only-upgrade

    Gentoo

    See the vulnerability fix suggestions for details.

  • Vulnerability Fixing Methods

    Vulnerability fixing may affect service stability. You are advised to use either of the following methods to avoid such impacts:

    • Method 1: Create a VM to fix the vulnerability.
      1. Create an image for the ECS host whose vulnerability needs to be fixed. For details, see Creating a Full-ECS Image from an ECS.
      2. Use the image to create an ECS. For details, see Creating an ECS from an Image.
      3. Fix the vulnerability on the new ECS and verify the result.
      4. Switch services over to the new ECS and verify they are stably running.
      5. Release the original ECS. If a fault occurs after the service switchover and cannot be rectified, you can switch services back to the original ECS.
    • Method 2: Fix the vulnerability on the current server.
      1. Create a backup for the ECS to be fixed. For details, see Creating a CSBS Backup.
      2. Fix vulnerabilities on the current server.
      3. If services become unavailable after the vulnerability is fixed and cannot be recovered in a timely manner, use the backup to restore the server. For details, see Using Backups to Restore Servers.
    • Use method 1 if you are fixing a vulnerability for the first time and cannot estimate the impact on services. You are advised use pay-per-use billing for newly created ECSs. After the service switchover, you can change the billing mode to yearly/monthly. In this way, you can release the ECSs at any time to save costs if the vulnerability fails to be fixed.
    • Use method 2 if you have fixed the vulnerability on similar servers before.

Verifying Vulnerability Fix

After a vulnerability is fixed, you are advised to verify it immediately.

Table 3 Verification

Method

Operation

Manual verification

  • Click Verify on the vulnerability details page.
  • Run the following command to check the software upgrade result and ensure that the software has been upgraded to the latest version:
    • CentOS, Fedora, EulerOS, Red Hat, and Oracle: rpm -qa | grep Software name
    • Debian and Ubuntu: dpkg -l | grep Software name
    • Gentoo: emerge --search Software name
  • Perform a manual scan on the HSS console to check the vulnerability fixing result.

Automatic verification

HSS performs a full scan every early morning. If you do not perform a manual verification, you can view the system check result on the next day after you fix the vulnerability.

Related Operations

If you evaluate that some vulnerabilities do not affect your services and do not want to view the vulnerabilities in the vulnerability list, you can whitelist the vulnerabilities. After they are whitelisted, the vulnerabilities will be ignored in the vulnerability list and no alarms will be reported. The vulnerabilities will not be scanned and the vulnerability information will not be displayed when the next vulnerability scan task is executed. For details, see Handling Vulnerabilities.