Security Center:FAQ about vulnerability management

How do I view the current software version and vulnerability details?

Security Center determines whether your server has software vulnerabilities by comparing the software version on your server with the versions associated with known Common Vulnerabilities and Exposures (CVEs). To view vulnerability details and the current software version, you can use one of the following methods:

• View the current software version and vulnerability details in the Security Center console

  You can go to the Security Center console and choose Risk Governance > Vulnerabilities. On the page that appears, you can view the system software version and vulnerability information detected by Security Center on your server. For more information about the parameters of system software vulnerabilities, see Parameters on the details page of a Linux software vulnerability.

• View details of the current software version on your server

  You can also run a command to view the details of the current software version.

  • CentOS and Red Hat systems

    Run the rpm -qa | grep xxx command to view the software version information. In this command, xxx represents the name of the software package. For example, you can run the rpm -qa | grep bind-libs command to view the version details of the bind-libs software package.

  • Ubuntu and Debian systems

    Run the dpkg-query -W -f '${Package} -- ${Source}\n' | grep xxx command to view the software version information. In this command, xxx represents the name of the software package. For example, you can run the dpkg-query -W | grep bind-libs command to view the version details of the bind-libs software package.

    Note

    If the specified software package is not found, you can run the dpkg-query -W command to view all the software that is installed on your server.

  After you retrieve the software version details by running the preceding commands, you can compare them with the details of the related vulnerabilities detected by Security Center. In the vulnerability details, the Software and Hit parameters indicate the current software version and the rule that was hit.

  Note

  After you update a software package, Security Center may collect residual files from the old software version and report a vulnerability based on these files. If you confirm that a vulnerability alert is triggered in this case, we recommend that you ignore the alert. You can also run the yum remove or apt-get remove command to delete the old software package. Before you delete the package, make sure that the old software version is no longer required by your services and applications.

How do I manually update an Ubuntu kernel?

The following example shows how to manually update kernel 3.1* to kernel 4.4 on an Ubuntu 14.04 system.

1. Run the uname -av command to confirm that the current kernel version is 3.1*.

   

2. Run the following commands to check whether the latest kernel update package is available:

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

3. If no related update is available, you can run the apt-get update command to obtain the latest update package.

4. Run the following commands to update the kernel.

   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. After the update package is installed, restart the server to apply the new kernel.

6. After the server is restarted, run the following commands to verify that the kernel is updated:

   • Run the uname -av command to query the current kernel that is invoked.

     

   • Run the dpkg -l | grep linux-image command to query the details of the current kernel package.

     

How do I verify that an Ubuntu kernel patch vulnerability is fixed?

If you modified the kernel selection sequence in the GRand Unified Bootloader (GRUB) boot menu and installed a new kernel on your Ubuntu server to fix a vulnerability, the new kernel may not be loaded when you restart the system. You must manually configure environment variables to load the new kernel upon restart.

After you fix an Ubuntu kernel vulnerability in the Security Center console, you must restart the Linux system for the fix to take effect. When the system is restarted, if you modified the GRUB boot menu, the system cannot automatically create a boot menu for the new kernel. Even after the system is restarted, the Security Center console still displays the Fixed And Pending Restart status. In this case, you cannot verify that the vulnerability is fixed.

If you want to use the default settings of the new kernel and discard the original GRUB boot menu configuration, you can set the following environment variable in the Linux terminal before you run the command to fix the vulnerability. This way, the installation system automatically selects the default settings.

export DEBIAN_FRONTEND=noninteractive

If you do not need to use the default settings of the latest kernel, you can manually modify the GRUB boot sequence. For more information, see How to modify the kernel boot sequence for CentOS on ECS.

Do I need to restart my server after I fix a vulnerability?

• Windows server:

  After you fix a Windows system vulnerability in the Security Center console, you must restart the Windows server for the fix to take effect.

  After all Windows vulnerabilities are fixed, you must restart the server.

• Linux server:

  After you fix a Linux kernel vulnerability in the Security Center console, you must restart the server for the fix to take effect. A system restart is required after a vulnerability is fixed if one of the following conditions is met:

  • Your server is a Linux server, and the vulnerability that you fix is a Linux kernel vulnerability.

  • In the Security Center console, on the Linux Software Vulnerability tab under Risk Governance > Vulnerabilities, the notice for the vulnerability includes the Restart Required tag.

Why is a Windows vulnerability displayed as fixed when the corresponding patch is not installed on the host?

Windows uses a cumulative update mechanism. Security patches for each month include the updates from previous months. When Security Center periodically scans for vulnerabilities, if it detects that the latest cumulative update is installed, the update addresses the previous vulnerabilities. Therefore, even if an old patch is not installed, the related vulnerabilities are automatically marked as fixed. This means you only need to install the latest patch, not all previous patches individually. This is why the console shows that the vulnerability is fixed.

You can visit the official Microsoft patch release page to confirm whether the latest cumulative update includes the patch for the target vulnerability.

What do I do if Security Center continues to send a vulnerability alert to me after I update the kernel?

This issue may occur if residual files from the old kernel version exist. If you confirm that the alert is triggered due to residual files from the old kernel version, you can ignore the alert or manually delete the files from the server. You can perform the following steps to handle the issue:

1. After the kernel is updated, run the uname -av and cat /proc/version commands to view the current kernel version. Make sure that the current kernel version meets the requirement that is described in the vulnerability details.

2. Run the cat /etc/grub.conf command to query the configuration file. Make sure that the current system uses the latest kernel version.

3. The Linux software vulnerability detection feature determines whether your server contains vulnerabilities based on the installed software version. If the RPM Package Manager (RPM) package for the old kernel version is still on your system, Security Center detects it and generates a vulnerability alert. You must make sure that your system does not contain the RPM package of the old kernel version. If your system contains the RPM package of the old kernel version, you can delete the package from the server.

   Note

   Before you uninstall the RPM package of the old kernel version, make sure that the current system uses the new kernel. We strongly recommend that you create a snapshot for your system before you uninstall the RPM package of the old kernel version. If an exception occurs during the uninstallation, you can use the snapshot to restore your system.

If you cannot uninstall the old kernel version, you can ignore the system vulnerability alert after you confirm that the system is using the new kernel. To do this, perform the following steps:

1. Log on to the Security Center console. In the upper-left corner, select the region where the asset that you want to manage is deployed: Chinese Mainland or Outside Chinese Mainland.

2. In the navigation pane on the left, choose Risk Governance > Vulnerabilities.

3. On the Linux Software Vulnerability tab, find the vulnerability and click its name to go to the Vulnerability Details page.

4. In the Actions column, click the icon and select Ignore.

What do I do if no update is released for a vulnerability in the Security Center console?

If no update is available for a vulnerability, it means an official update source is not available for the affected software. You cannot fix the vulnerability in the Security Center console. Refer to the following instructions to find an appropriate solution:

• You may receive one of the following messages when you update software to fix a vulnerability:

  Package xxx already installed and latest version
  Nothing to do

  Or

  No Packages marked for Update

  In this case, the official update source of the software does not provide an update. Wait for an update from the official update source.

  The following software packages do not have available updates:

  • Gnutls

  • Libnl

  • MariaDB

• You have updated the software package to the latest version, but the version still does not meet the software version requirements that are reported in the Security Center console.

  Check whether your operating system version is still officially supported. For example, since September 1, 2017, official support for CentOS 6.2 to 6.6 and 7.1 has been discontinued. In this case, we recommend that you ignore the vulnerability in the Security Center console or upgrade your operating system. The vulnerability risk may still exist on your server.

How do I fix vulnerabilities?

Security Center lets you fix Linux software vulnerabilities, Windows system vulnerabilities, and Web-CMS vulnerabilities in the console. Application vulnerabilities and emergency vulnerabilities can be detected but cannot be fixed from the console.

Vulnerability fixing capabilities vary by Security Center edition. Before you can fix a vulnerability from the Security Center console, you must have the vulnerability fixing capability. For more information, see Enable the vulnerability fixing feature.

You can go to the Security Center console and choose Risk Governance > Vulnerabilities. On the page that appears, find the Linux software vulnerability, Windows system vulnerability, or Web-CMS vulnerability that you want to fix and click Fix in the Actions column. For Linux software vulnerabilities and Windows system vulnerabilities, you can create a snapshot before fixing them. After a vulnerability is fixed, if a restart is required, the vulnerability's status changes to Pending Restart. You must restart the server as prompted and then verify the vulnerability.

For application vulnerabilities and emergency vulnerabilities, you must manually fix them based on the suggestions provided on the vulnerability details page. After a vulnerability is fixed, verify the fix on the vulnerability details page.

Why is the Fix button grayed out when I want to fix a vulnerability?

• The Fix button for a Linux software vulnerability is grayed out

  • For some operating systems, you must manually fix vulnerabilities. This includes outdated operating systems that vendors no longer support and for which no compatible patches are available. It also includes some commercial operating systems.

    Note

    For vulnerabilities in the following operating systems, you must upgrade the operating systems to fix the vulnerabilities.

    • Red Hat 5, Red Hat 6, Red Hat 7, and Red Hat 8

    • CentOS 5

    • Ubuntu 12

    • Debian 8, 9, and 10

  • Linux software vulnerabilities may fail to be fixed due to issues such as insufficient disk space or incorrect file permissions. Before you fix Linux software vulnerabilities in the Security Center console, you must manually handle these issues on the server. The following list describes the exceptions that you must manually handle:

    • The disk space is less than 3 GB.

      Suggestion: Increase the disk space or clear unnecessary files. Then, try to fix the vulnerability again in the Security Center console.

    • The APT-GET or APT/YUM process is running.

      Suggestion: Wait for a moment or manually stop the APT-GET or APT/YUM process on the server. Then, try to fix the vulnerability again in the Security Center console.

    • You do not have the required permissions to run the APT, YUM, or RPM command.

      Suggestion: Check and correct the file permissions. We recommend that you set file permissions to 755 and make sure that the file owner is the root user. Then, try to fix the vulnerability again in the Security Center console.

      Note

      File permissions set to 755 grant the file owner read, write, and execute permissions. The user group and other users have read and execute permissions.

• The Fix button for a Windows system vulnerability is grayed out

  Windows system vulnerabilities may fail to be fixed for reasons such as insufficient disk space on the server or a running Windows Update service. When such issues occur on a server, Security Center grays out the Fix button for the vulnerabilities. Before you fix the vulnerabilities in the Security Center console, you must manually handle these issues on the server. You can move the pointer over the Fix button to view the issues on the server and the suggestions provided by Security Center. The following list describes the server exceptions that you must manually handle:

  • The Windows Update service is running.

    Suggestion: Try again later or manually stop the Wusa process on the server. Then, try to fix the vulnerability again in the Security Center console.

  • The Windows Update Service on the server is disabled.Suggestion: Go to the system service manager of the server to enable the Windows Update Service. Then, try to fix the vulnerability again in the Security Center console.

    Suggestion: Go to the System Service Manager on the server to enable the Windows Update service. Then, try to fix the vulnerability again in the Security Center console.

  • The server disk space is less than 500 MB.

    Suggestion: Increase the disk space or clear unnecessary files. Then, try to fix the vulnerability again in the Security Center console.

Why do Linux software vulnerabilities and Windows system vulnerabilities fail to be fixed?

If a vulnerability fails to be fixed when you use Security Center to fix Linux software vulnerabilities and Windows system vulnerabilities, you can perform the following steps to troubleshoot the issue:

Why do Web-CMS vulnerabilities fail to be fixed?

If a Web-CMS vulnerability fails to be fixed when you use the vulnerability fixing feature of Security Center, you can check the following possible causes:

Why is the status of a vulnerability Unfixed after I fix the vulnerability?

A vulnerability's status is not updated in real time. It is updated only after a vulnerability scan runs. The following list describes possible causes and solutions, which vary by Security Center edition.

• Free Edition and Anti-virus Edition: The vulnerability is still in the Unfixed status because there is a delay before the next scheduled vulnerability scan. Security Center automatically scans for vulnerabilities every two days. We recommend that you check the status of the vulnerability two days after you fix it.

• Premium Edition, Enterprise Edition, and Ultimate Edition: After you fix the vulnerability, you must manually perform a vulnerability scan. After the vulnerability scan is complete, you can view the latest status of the vulnerability. For more information, see Scan for vulnerabilities.

Are vulnerabilities automatically fixed?

Security Center does not automatically fix vulnerabilities. It supports vulnerability detection and one-click fixes. For one-click fixes, Security Center delivers the fix tasks to the agent online. When Security Center scans for vulnerabilities, it also verifies whether the vulnerabilities are fixed. If a previously detected vulnerability is not found in a new scan, Security Center changes the vulnerability's status to Fixed. A vulnerability may be resolved for several reasons, such as a user manually updating the software package, a container stopping, the vulnerable component being removed, or the related process no longer existing.

When I fix multiple vulnerabilities in a batch, in what order are the vulnerabilities fixed?

When fixed in a batch, Linux software vulnerabilities and Web-CMS vulnerabilities are processed in the order they appear in the console's vulnerability list. To fix some Windows system vulnerabilities, you must install prerequisite patches. When you fix multiple Windows system vulnerabilities in a batch, vulnerabilities that require prerequisite patches are fixed first. Other vulnerabilities are fixed in the order they appear in the vulnerability list in the console.

Why do I fail to create a snapshot when I fix a vulnerability? What do I do?

Snapshot creation may fail for the following reasons:

• The account that you use to fix the vulnerability is a Resource Access Management (RAM) user: If you use a RAM user that does not have the permissions to create snapshots, the console indicates that snapshot creation failed. We recommend that you use an Alibaba Cloud account. For more information about RAM users, see Overview of RAM users.

• The server is not an Alibaba Cloud server: You cannot create snapshots for servers that are not deployed on Alibaba Cloud.

Why does Security Center continue to send alerts to me after I fix vulnerabilities? What do I do?

This issue occurs because some vulnerabilities, such as Linux kernel vulnerabilities, require a server restart after they are fixed. On the vulnerability details page, click Restart. After the restart is complete, click Verify. If the vulnerability is displayed as fixed, the vulnerability is fixed.

What do I do if the "Failed to obtain the permission. Check the permission and try again." message appears when I fix a vulnerability?

This issue occurs because the current logon account does not have permission to modify the required file. We recommend that you click the vulnerability name to view the vulnerability details and check whether the owner of the file that needs to be fixed is root. If the owner is not the root user, log on to your server and change the file owner to root. After the file owner is changed, go to the Security Center console to fix the vulnerability.

Why are the records of detected vulnerabilities still displayed in the console after the Security Center client on the server is offline or disabled?

When the client on a server is offline or disabled, the records of detected vulnerabilities are retained in the Security Center console.

If the client is offline or disabled, vulnerability alerts automatically expire after a specific period: system vulnerabilities after 3 days, Web-CMS vulnerabilities after 7 days, application vulnerabilities after 30 days, and emergency vulnerabilities after 90 days. After a vulnerability becomes invalid, you cannot perform any operations on the vulnerability, including fixing it or clearing its record.

If you do not renew your Security Center service within seven days after it expires, your Security Center data is released and permanently deleted. In this case, you cannot view any data in the Security Center console.

How do I clear the patch packages for fixing Windows vulnerabilities from the client directory?

After you fix a Windows system vulnerability, the Security Center client automatically downloads, installs, and clears the installation package. No manual operations are required. If the installation package is not cleared three days after the vulnerability is fixed, you can manually clear the patch package by following these steps:

1. Log on to the Security Center console. In the upper-left corner, select the region where the asset that you want to manage is deployed: Chinese Mainland or Outside Chinese MainlandOutside China.

2. In the navigation pane on the left, choose System Settings > Feature Settings.

3. If you have enabled client self-protection, go to the details page of the server in the Asset Center and turn off the client self-protection switch.

   If you have not enabled client self-protection, skip this step.

   Client self-protection provides default protection for all process files in the client directory on your server. After client self-protection is enabled, Security Center denies any requests to delete or download a process file from the client directory on your Windows server.

   

4. Log on to your Windows server with administrator permissions.

5. Find the vulnerability patch package and manually delete it.

   The path of the patch package is C:\Program Files (x86)\Alibaba\Aegis\globalcfg\hotfix.

6. (Optional) On the details page of the server in the Asset Center, enable client self-protection.

How do I handle a timeout when I connect to the official Alibaba Cloud Yum source?

If the connection to the official Alibaba Cloud Yum source times out, an error message similar to the following one appears:

[Errno 12] Timeout on http://mirrors.aliyun.com/centos/6/os/x86_64/repodata/repomd.xml: (28, 'connect() timed out!')

In this case, check that your server's DNS resolution is working correctly and wait a few moments.

What do I do if a "token verification failed" message appears when I fix a vulnerability?

If you receive the Token Verification Failed message when you perform an operation in the Security Center console, you can refresh the current page and try the operation again. You may need to log on to the Security Center console again.

Can Security Center automatically verify the fix of a vulnerability that requires a system restart?

No, it is not.

If a vulnerability is fixed and a system restart is required to verify the fix, the vulnerability's status changes to Fixed And Pending Restart. You must restart the server in the Security Center console or manually restart the server. After the server is restarted, you can click Verify to confirm that the vulnerability is fixed.

Security Center periodically performs vulnerability scans. If you do not verify the fix of a vulnerability of this type after the server is restarted, Security Center no longer detects the vulnerability. If a subsequent scan does not detect the vulnerability, the console retains the vulnerability record for three days to account for potential network or other intermittent issues. After three days, the console clears the information about the vulnerability.

If you do not renew your Security Center service within seven days after it expires, your Security Center data is released and permanently deleted. In this case, you cannot view application vulnerability data, but the data of other vulnerabilities is retained.

Why does the state of a vulnerability remain unchanged when I manually verify the vulnerability fix?

You manually run a command generated by Security Center to fix a system software vulnerability. The software is upgraded to a version that meets the requirements on the Vulnerability Fix page of the Security Center console. However, when you select the vulnerability on the vulnerability details page in the Security Center console and click Verify, the vulnerability status does not update to Fixed.

You can use the following methods to troubleshoot and resolve the issue:

• Check the vulnerability scan level

  Perform the following steps to check the vulnerability scan level.

  1. Log on to the Security Center console. In the upper-left corner, select the region where the asset that you want to manage is deployed: Chinese Mainland or Outside Chinese Mainland.

  2. In the navigation pane on the left, choose Risk Governance > Vulnerabilities.

  3. In the upper-right corner of the Vulnerabilities page, click Vulnerability Settings.

  4. In the Vulnerability Settings panel, view the level selected for Vulnerability Scan Level.

  If the corresponding scan level is not selected, the data of vulnerabilities at that level is not automatically updated. You can select the corresponding scan level as needed.

• The Security Center client is offline

  If the Security Center client on your server is offline, you cannot use the verification feature of vulnerability management to verify your server. We recommend that you troubleshoot the cause for the client to be offline and make sure that the Security Center agent on your server is online. For more information, see Troubleshoot the offline status of the Security Center agent.

Why does a vulnerability rollback operation fail?

If a vulnerability rollback operation fails in Security Center, you can perform the following operations.

1. Check whether the Security Center agent on your server is online. If your server is offline, troubleshoot the cause for the agent to be offline. For more information, see Troubleshoot the offline status of the agent.

2. Check whether the snapshot created for the vulnerability has expired and been deleted.

   After a snapshot is deleted, the vulnerability cannot be rolled back.

Can Security Center detect Elasticsearch vulnerabilities?

Yes.

You can go to the Security Center console and choose Risk Governance > Vulnerabilities. On the Application Vulnerability tab, you can check whether Elasticsearch vulnerabilities are detected.

Why are multiple identical application vulnerabilities detected on the same server?

Security Center detects application vulnerabilities based on running processes. The number of detected vulnerabilities corresponds to the number of vulnerable processes. If software that has application vulnerabilities exists on a server but no related processes are running, no application vulnerabilities are detected.

Are my business systems affected when Security Center scans for emergency vulnerabilities?

Emergency vulnerability detection works by sending probes based on the vulnerability's characteristics. Security Center sends one to two TCP network request messages to all IP addresses of your ECS or SLB instances. It does not perform any actual exploits. The emergency vulnerability detection feature of Security Center has been tested on a large scale with millions of IP addresses and has high stability and reliability. However, these tests cannot account for all unknown risks. For example, if a service has fragile business logic, even these minimal TCP requests could potentially cause a service breakdown.

Why are the detection results for Fastjson emergency vulnerabilities different each time a scan is performed?

The detection of Fastjson vulnerabilities depends on whether the JAR package is loaded at runtime. A web server loads JAR packages in dynamic loading or static loading mode. In dynamic loading mode, Fastjson vulnerabilities can be detected only when the JAR package is running. Therefore, detection results can vary over time. We recommend that you perform multiple detections for Fastjson vulnerabilities to improve the accuracy of the detection results.

Vulnerability scan cycles

Security Center supports vulnerability scanning and fixing. The supported vulnerability types include Linux software vulnerabilities, Windows system vulnerabilities, Web-CMS vulnerabilities, emergency vulnerabilities, and application vulnerabilities. The following table describes the default scan cycle for each type of vulnerability.

If you want to enable or disable the scan capability for a specific type of vulnerability, or modify the scan cycle for application vulnerabilities or emergency vulnerabilities, you can use the Vulnerability Settings feature. For more information, see Scan for vulnerabilities. If you want to immediately scan your assets for vulnerabilities, you can use the one-click scan feature provided by Security Center. For more information, see Scan for vulnerabilities.

After a vulnerability scan is complete, you can go to the Security Center console and choose Risk Governance > Vulnerabilities to view the detection results and handle the vulnerabilities.

Can a vulnerability scan detect system-level and application-level vulnerabilities?

Yes, a vulnerability scan can detect system vulnerabilities, which are system-level vulnerabilities on servers, and web vulnerabilities, which are application-level vulnerabilities.

What causes an out-of-memory (OOM) error during a vulnerability scan?

In a Linux environment, the Security Center client's detection process (AliSecCheck) runs within a cgroup that has a memory limit. A cgroup named aegisRtap0 limits the maximum memory usage for the AliSecCheck process to 200 MB by default. When the memory usage of the running AliSecCheck process reaches this limit, the system's out-of-memory (OOM) killer terminates the process. The termination record is written to the dmesg log.

This OOM termination is expected behavior due to resource limits. You do not need to take any action.