Updated on 2024-11-06 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.

If a vulnerability may harm your services, fix it as soon as possible. For Linux and Windows vulnerabilities, you can go to the HSS console and fix them in one-click. Web-CMS, emergency, and application vulnerabilities cannot be automatically fixed. You can handle them by referring to the suggestions provided on the vulnerability details page.

Constraints and Limitations

  • The following Table 1 describes the OSs that have reached their end of life (EOL). HSS does not support automatic vulnerability fixing on these OSs. You are advised to use the OSs in active support.
    Table 1 OSs that have reached EOS

    OS

    Description

    CentOS 8

    It has reached EOL and will no longer maintained. HSS scans them for vulnerabilities based on Red Hat patch notices, but cannot fix them due to the lack of official patches. You are advised to change to the OSs in active support.

    Ubuntu 16.04, 18.04, and 22.04

    They have reached EOL and do not support free patch updates. You need to purchase and configure Ubuntu Pro to install upgrade packages, or vulnerability fix will fail.

    Debian 9 and 10

    It has officially reached EOL. No official patches are available. You are advised to change to the OSs in active support.

    Windows 2012 R2

    It has officially reached EOL. No official patches are available. You are advised to change to the OSs in active support.

  • 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. The system 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.

Precautions

  • 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. 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.
    • Linux OS: If your servers cannot access the Internet, or the external image sources cannot provide stable services, you can use the image source provided by Huawei Cloud to fix vulnerabilities. Before fixing vulnerabilities online, configure the Huawei Cloud image sources that match your server OSs.
    • Windows OS: If your servers cannot access the Internet, ensure you have set up a patch server.

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 management console and select a region or project.
  3. Click in the upper left corner of the page and choose Security & Compliance > SecMaster.
  4. 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

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

    Figure 2 Accessing the vulnerability management page

  6. On the displayed page, click Linux Vulnerabilities or Windows Vulnerabilities.
  7. In the vulnerability list, click the name of the target vulnerability. The vulnerability details page is displayed.
  8. 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.

  9. 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.
      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.
    • 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

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.