Security Center:FAQ about vulnerability management

Scan behavior and results

• Why does the same server report multiple instances of the same vulnerability?

  Application vulnerability detection targets specific running process instances. If a server runs multiple instances of a process with the same vulnerability (for example, two identical Tomcat services started on different ports), the system reports a separate vulnerability for each process instance. If the vulnerable software is installed but not running, Security Center will not detect the vulnerability.

• Why do scan results for vulnerabilities like Fastjson sometimes vary?

  The detection of such vulnerabilities depends on whether their components (like JAR packages) are loaded into a "runtime" state during the scan. In a dynamic loading model, Security Center can detect the vulnerability only when the business logic calls the vulnerable component. Therefore, scan results may differ at different times.

  Note

  To improve the detection accuracy for these types of vulnerabilities, we recommend running periodic or multiple scans.

• After the agent goes offline, why does the console still show vulnerability records for that host?

  After the agent goes offline, Security Center retains the detected vulnerability records in the console. However, these records automatically become stale and you cannot perform any actions on them, such as fixing, verifying, or clearing them. The automatic staleness periods for vulnerabilities are as follows:

  Important

  Security Center permanently deletes all data only if the Security Center service expires and is not renewed within 7 days.

  • Linux Software Vulnerability and Windows System Vulnerability: Become stale after 3 days.

  • Web-CMS Vulnerability: Becomes stale after 7 days.

  • Application Vulnerability: Becomes stale after 30 days.

  • Urgent Vulnerability: Becomes stale after 90 days.

Performance impact and security

• Does vulnerability scanning or active validation (POC) for urgent vulnerabilities affect business systems?

  Typically, there is no impact. Security Center's active validation (POC) sends only a very small number (1-2) of harmless probe requests and does not perform any form of attack or destructive action. In rare cases, a minimal risk exists if the target application is exceptionally fragile when handling unexpected input.

• Why does a vulnerability scan sometimes trigger an out-of-memory (OOM) error?

  The Security Center agent has a configured memory limit (200 MB by default). If a scan exceeds this limit, the system's OOM mechanism proactively terminates the detection process (ALiSecCheck) to conserve resources.

  Note

  • This limit is typically managed by a control group (cgroup) named aegisRtap0. Related OOM information can be found in the dmesg logs.

  • This behavior is normal and is not related to a system-wide memory shortage. No user intervention is required.

  • This OOM error is caused by the cgroup's memory limit and does not indicate that the entire system is out of memory.

Scan scope and capabilities

1. What is the scope of a vulnerability scan?

   Scanning covers both the system and application layers:

   • System level: Linux software vulnerability and Windows system vulnerability.

     Important

     The Windows system vulnerability scan is limited to monthly security update patches.

   • Application level: Web-CMS vulnerability, Application vulnerability, and Urgent vulnerability.

2. How can I view the list of vulnerabilities that Security Center can detect?

   1. Log on to the Security Center console.

   2. In the left-side navigation pane, click Vulnerabilities to go to the vulnerability scanning page. In the overview section, find the Disclosed Vulnerabilities statistics card.

   3. Click the total number of vulnerabilities on the card to open the list page, where you can view all supported vulnerabilities and their details.

3. Does Security Center support detection for specific vulnerabilities like Elasticsearch?

   Yes. You can view detection results for vulnerabilities in services like Elasticsearch on the Application Vulnerability page in the console.

   Note

   This feature is only available for the Subscription service (Enterprise and Ultimate editions) and the Pay-as-you-go service (Host Protection and Hosts and Container Protection). If your current edition does not support this feature, please upgrade first.

Fixing limitations and principles

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

  • Product edition limitations

    • Edition is too low: The Basic and Anti-virus editions do not support one-click fix.

    • Solution: Purchase the "Vulnerability Fixing" value-added service, or upgrade to the Enterprise or Ultimate Edition.

  • Server issues

    Linux

    • Operating system is no longer maintained: The vendor no longer provides patches. You need to manually upgrade the operating system version. Currently, vulnerabilities in the following operating systems need to be fixed by upgrading the OS.

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

      • CentOS 5

      • Ubuntu 12

      • Debian 8, 9, 10

    • Insufficient disk space: The free space is less than 3 GB. Clean up or expand the disk.

    • Process is busy: The apt or yum process is running. Wait for it to finish and then retry, or manually stop the process.

    • Insufficient permissions: The user executing the fix command does not have enough permissions. Make sure the file owner is the root user and set reasonable permissions, such as 755.

    Windows

    • Insufficient disk space: The free space is less than 500 MB. Clean up or expand the disk.

    • Windows Update service is abnormal: The service is disabled or running.

      • Disabled: Go to the system service manager of the server, enable the Windows Update Service, and then try to fix the vulnerability again.

      • Running: If it is running, wait for it to finish or manually end the Wusa process on the server, and then try to fix the vulnerability again.

• What is the difference between application vulnerabilities and system vulnerabilities? Why does one-click fix not support application vulnerabilities?

  • System vulnerabilities, such as Linux software vulnerabilities and Windows system vulnerabilities, are vulnerabilities in the operating system or its components. Their remediation paths are standardized, so one-click fix is supported.

  • Application vulnerabilities exist in self-deployed applications, such as website code or third-party software. Their remediation methods are closely related to business logic and code implementation. They cannot be automatically fixed without understanding the business, so they need to be handled manually.

• Why are there so many vulnerabilities on my server?

  Vulnerabilities are continuously discovered in older software versions because new attack methods are always emerging. Therefore, regular scanning and patching are ongoing security tasks. You can turn on the Show Only Exploitable Vulnerabilities switch to focus on critical risks.

Fixing operations

• What should I do if I get a "Permission acquisition failed, please check permissions and retry" message when executing a fix command?

  • Cause: The user who owns the file required for the fix operation is not root, resulting in insufficient permissions.

  • Solution:

    1. Locate the file:

       In Security Center, view the vulnerability details to confirm the specific file and its path that need to be fixed.

    2. Modify permissions:

       Log on to the server and run the following command to change the file owner to root.

    3. Retry the fix:

       Return to the Security Center console and perform the fix operation on the vulnerability again.

• When fixing vulnerabilities in a batch, in what order are they fixed?

  Linux software vulnerabilities and Web-CMS vulnerabilities are fixed in a batch in the order they appear in the vulnerability list in the console. Fixing some Windows system vulnerabilities requires installing prerequisite patches first. When fixing Windows system vulnerabilities in a batch, these types of vulnerabilities are fixed first. The remaining vulnerabilities are fixed in the order they appear in the vulnerability list in the console.

• Why is restarting ineffective after fixing an Ubuntu kernel patch vulnerability?

  • Symptom: After using the one-click fix in Security Center for a kernel vulnerability on an Ubuntu server, although it prompts "Fixed, pending restart", the vulnerability alert still exists after restarting the server. The system has not enabled the newly installed kernel.

  • Cause: This is usually because the default boot order of the GRUB boot menu was manually modified before. In this case, the system fix script cannot automatically set the newly installed kernel as the default boot item.

  • Solution:

    Solution 1: Automatically configure the new kernel

    This solution abandons the original custom GRUB configuration and lets the system automatically apply the default settings for the new kernel.

    Procedure:

    1. Before executing the vulnerability fix, log on to your Ubuntu server.

    2. Run the following command to set the environment variable:

       <BASH>
       
       export DEBIAN_FRONTEND=noninteractive

    3. Return to the Security Center console and perform a one-click fix on the vulnerability.

    4. After the fix is complete, restart the server as prompted. The system will automatically enable the latest kernel.

    Solution 2: Manually modify the boot order

    To keep the original GRUB configuration, you can choose this solution.

    Procedure:

    1. In the Security Center console, perform a normal one-click fix and restart the server as prompted.

    2. After the fix and restart, log on to your Ubuntu server.

    3. Manually modify the GRUB boot order to set the newly installed kernel version as the default boot item.

       Note

       The specific operation usually involves modifying the /etc/default/grub file and running the update-grub command. For related operations, see Modify the kernel boot order for ECS Linux CentOS.

    4. Restart the server again to make the new boot order take effect.

• Do I need to restart the system after fixing a vulnerability?

  • Windows: A restart is required.

  • Linux Software Vulnerability: A restart is required if any of the following conditions are met:

    • A kernel vulnerability was fixed.

    • On the Linux Software Vulnerability tab of the Risk Governance > Vulnerabilities page in the Security Center console, the announcement for the vulnerability has a Restart Required tag.

      

• Why does a vulnerability rollback operation fail?

  When a vulnerability rollback operation fails, you can troubleshoot along the following paths:

  1. Check the client (Agent) status

     The rollback operation depends on the Security Center Agent being online. If the Agent is offline, the command cannot be delivered. You need to troubleshoot and resolve its offline issue first.

  2. Confirm the backup snapshot is valid

     The rollback feature is based on the backup snapshot created before the fix. If the snapshot has expired or been manually deleted, the rollback cannot be performed.

• Why does creating a snapshot fail when fixing a vulnerability?

  Creating a snapshot when fixing a vulnerability may fail for the following reasons:

  • The current operation is performed by a RAM user: If you are currently using a RAM user and that user does not have permission to create snapshots, the console will prompt you that snapshot creation failed. We recommend that you use an Alibaba Cloud account for the operation. For more information about RAM users, see Overview of RAM users.

  • The server is not an Alibaba Cloud server: Non-Alibaba Cloud servers do not support creating snapshots to fix vulnerabilities.

Post-fix status and verification

• The vulnerability has been fixed, but Security Center still reports it. What should I do?

  • Cause: This happens because some vulnerabilities, namely Linux kernel vulnerabilities, require a server restart after being fixed.

  • Solution: On the vulnerability details page, click Restart. After the restart is complete, click Verify. If 'Repaired' is displayed, the vulnerability is successfully fixed.

• The host has not installed the corresponding patch. Why does it show that the Windows vulnerability was fixed successfully?

  This is a normal phenomenon caused by the Windows update mechanism. You only need to ensure that the latest cumulative update is installed to fix all historical vulnerabilities it contains. You do not need to install old patches one by one.

  Note

  You can visit the official Microsoft patch website, search for the latest installed patch (usually identified by its KB number), and check its "Package Details" to confirm whether it has covered the old vulnerability you are concerned about.

  • Cause: Windows cumulative update mechanism

    Windows security updates use a "cumulative" model. This means that the latest monthly security patch is a collection package that, by default, includes all security fixes from previous months up to the release date.

  • Solution: When Security Center detects that the system has installed the latest cumulative update, it marks all the old vulnerabilities it covers as "Fixed". Therefore, you do not need to install a separate patch for each historical vulnerability.

• After fixing a vulnerability, why does it still show "Not fixed" in the console?

  Possible reasons are as follows:

  1. Verification delay: After a manual fix, you need to click the Verify button to trigger an instant scan. The status update takes a few minutes.

  2. Cache issue: The console page may have a cache. Try to force-refresh the page or wait a few minutes.

  3. Incomplete fix: The fix operation may not have been completely successful, or there may be multiple vulnerability paths and only one was fixed. Please recheck the fix steps.

• Fixed and Pending Restarted state vulnerabilities: Can Security Center automatically verify them?

  No. You need to restart the server from the Security Center console or manually restart the server. After the restart is complete, click Verify to confirm whether the vulnerability has been successfully fixed.

  Important

  If you do not actively verify, Security Center will automatically check during subsequent periodic scans. After the system does not detect the vulnerability in the first scan, it will retain the vulnerability information for 3 days (to prevent misjudgment due to network or other reasons). If it is not detected for 3 consecutive days, the system will clear the vulnerability record.

• Why is there no response when I manually verify after fixing a vulnerability?

  After manually fixing a vulnerability on a server, if the "Verify" function in the Security Center console cannot update the vulnerability status to "Fixed", it is usually due to the following two reasons:

  • Incomplete vulnerability scan level configuration

    • Cause: Security Center only scans and updates the risk levels that are selected in Vulnerability Settings. If the risk level of a target vulnerability (for example, important or medium) is not selected, the system does not update the status of vulnerabilities at that level.

    • Solution: Verify that the scan levels in Vulnerability Settings cover the risk level of the target vulnerability.

  • Security Center client (Agent) is offline

    • Cause: The "Verify" function relies on real-time communication between the console and the client on the server. If the client is offline, the console cannot deliver the verification command or receive the result.

    • Solution: Troubleshoot and resolve the client offline issue. After it is back online, perform the verification operation again.

Fixing specific types of vulnerabilities

• What do I do if Security Center still reports a kernel vulnerability after an upgrade?

  1. Confirm that the kernel is upgraded.

     1. Check the version of the running kernel to ensure that it meets the requirements specified in the vulnerability details.

        uname -av
        cat /proc/version

     2. Confirm that the system starts using the new kernel.

        cat /etc/grub.conf

  2. Check for and remove old kernel RPM packages.

     1. View all installed kernel packages on the system to find old kernel packages with version numbers lower than the running kernel.

        rpm -qa | grep kernel

     2. Create a protective snapshot for the system (strongly recommended).

        In the Elastic Compute Service console, create a snapshot or image for the current instance to prevent system exceptions or startup failures that may be caused by accidental deletion.

     3. Uninstall the old kernel RPM package.

        2. Uninstall only the old kernel version that is not in use. For example:

           rpm -e kernel-<old_version_number>

        3. Alternatively, use the method that is recommended by the distribution. For CentOS/RedHat:

           yum remove kernel-<old_version_number>

  3. Ignore the alert

     If you confirm that the running kernel has fixed the vulnerability, you can ignore the alert.

     1. Log on to the Security Center console.

     2. In the navigation pane on the left, choose Risk Governance > Vulnerabilities. In the upper-left corner of the console, select the region where your asset is deployed: Chinese Mainland or Outside Chinese Mainland.

     3. On the Linux Software Vulnerabilities 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.

• How do I manually update an Ubuntu kernel?

  Important

  Updating the kernel version is a high-risk operation. We strongly recommend that you follow the instructions in Suggestions on how to fix server software vulnerabilities to update the 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 command 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 retrieve the latest update package.

  4. Run the following command 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 restarts, run the following commands to verify that the kernel is updated:

     • Run the uname -av command to query the running kernel.

       

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

       

• What do I do if some vulnerabilities in the Security Center console show no updates?

  If a vulnerability shows no available updates, it means that no official update source is available for the affected software. You cannot fix the vulnerability in the Security Center console. You can choose a solution based on the following instructions:

  • The official update source has not provided a patch

    • Issue: When you run the update command, the system returns a message such as already installed and latest version or No Packages marked for Update.

    • Affected software packages: Gnutls, Libnl, and MariaDB

    • Solution: Wait for the official software source to release an update.

  • The operating system version has reached its end of life (EOL)

    • Issue: The software package does not meet the version requirements for the vulnerability fix, even though it is the latest version that is supported by the current system. This can happen on operating system versions that are no longer officially maintained, such as CentOS 6.x.

    • Solution:

      • Solution 1: Upgrade the operating system to a version that is within its official support period.

      • Solution 2: After you assess the risk and confirm that it is manageable, you can ignore the vulnerability in the Security Center console.