Help Center/ Host Security Service/ Best Practices/ Whitelist Can Be Used to Avoid False Alarm Reporting
Updated on 2025-01-07 GMT+08:00
View PDF
Share

Whitelist Can Be Used to Avoid False Alarm Reporting

Scenario

HSS provides intrusion detection for servers and containers. It can detect various malicious behaviors or attacks, such as brute-force attacks, abnormal processes, web shells, and malware, and report alarms to users in a timely manner. Alarms received by users may include alarms triggered by normal services. In this case, users can whitelist the alarms so that alarms are ignored by trusted objects, reducing O&M workload and improving O&M efficiency.

This section describes how to use the whitelist to prevent false alarms.

Whitelist Mechanism

HSS provides two whitelist mechanisms to handle alarms, which are alarm whitelist and detection policy whitelist. HSS does not generate alarms for whitelisted objects. For details about the two types of whitelists, see Table 1.

Table 1 Whitelist mechanism

Whitelist Mechanism

Description

Advantage

Disadvantage

Alarm whitelist

When handling alarms, you can add alarms to the whitelist and configure whitelist rules. HSS only detects but does not report alarms for abnormal events that match the whitelist rules.

HSS automatically associates preset whitelist rules based on the alarm content. You can quickly whitelist alarms when handling them.

The whitelist cannot be added in advance. You can only wait until the alarm is triggered.

Detection policy whitelist

HSS detects servers using agent. The detection scope of the agent can be controlled by the policy delivered on the console. Therefore, you can whitelist trusted objects in the policy. After the policy is delivered, HSS does not generate alarms for whitelisted objects.
  • You can add trusted objects to the whitelist in advance without waiting for alarms to be triggered.
  • Alarm whitelists cannot be added for container alarms, such as pods, images, and organizations. You can add detection policy whitelists.

Alarms that have been generated cannot be processed synchronously.

Add to Alarm Whitelist

The process of adding an alarm whitelist for server security alarms and container security alarms is similar. The following uses the high-risk command execution alarm as an example.

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation tree on the left, choose Detection & Response > Alarms. On the Server Alarms tab page, view the reported alarms.
  4. Click the alarm name to view the details and check whether the alarm is triggered by a normal service.

    View Alarm Information, Forensics, and Similar Alarms in the alarm details to check whether the command execution is triggered by normal services.
    Figure 1 Viewing alarm details

  5. If the alarm is triggered by normal services, click Add to alarm whitelist.

    Figure 2 Adding to alarm whitelist

  6. In the Handle Event area, click Add Rule and configure an alarm whitelist trigger rule. Table 2 describes the parameters.

    Figure 3 Alarm whitelist rules
    Table 2 Alarm whitelist rules parameters

    Parameter

    Example Value

    Description

    Whitelist Field

    Process command line

    The object types to be whitelisted. The following fields can be whitelisted for server security alarms:

    • Process path
    • Process command line
    • File path
    • User name
    • Remote IP address

    The fields that can be whitelisted vary according to the alarm type.

    Wildcard

    Include

    The following wildcards are supported:

    • Include: HSS does not generate any alarm if the alarm information contains Description of the whitelist rule.
    • If they are the same, HSS does not generate an alarm when the alarm information completely matches the Description of the whitelist rule.

    Description

    ls -l /run/canal/plugins/yangtse-agent.sock

    HSS automatically adds the detected suspicious processes and files to the whitelist. The content can also be customized.

    Multiple whitelist rules can be added for the same alarm. If multiple rules are added, the relationship between them is OR.

  7. In the Handle Event area, click OK.

Adding a Detection Policy Whitelist

For details about the whitelist detection policies and alarms supported by HSS, see Table 3.

Table 3 Adding a whitelist detection policy

Policy Name

Alarm

Container information collection

Container mounting exception

Cluster intrusion detection

Kubernetes event deletion, privileged pods creation, interactive shells used in pod, pods created with sensitive directory, pod created with server network, pods created with host PID space, common pods access, APIServer authentication failure, API server access from common pod using cURL, Exec in system management space, pods created in system management space, static pod creations, DaemonSet creation, cluster scheduled tasks creation, List Secrets operations, allowed operation enumeration, high privilege RoleBinding or ClusterRoleBinding, and ServiceAccount creations

Container escape

High-risk system calls, Shocker attacks, DirtCow attacks, and container file escape attacks

Container information module

Container namespace, container open port, container security options, and container mount directory

Container process whitelist

Abnormal container process

Fileless attack detection

Process injection, dynamic library injection, and memory file process

File protection

File directory change, key file change, and file privilege escalation

HIPS detection

Windows Defender disabled, suspicious hacker tools, suspicious ransomware encryption behavior, hidden account creation, user password and credential reading, suspicious SAM file export, suspicious shadow copy deletion, backup file deletion, suspicious ransomware operation registry, suspicious abnormal process behavior, suspicious scanning and detection, suspicious ransomware script execution, suspicious mining command execution, suspicious windows security center disabling, suspicious behavior of disabling the firewall service, suspicious system automatic recovery disabling, executable file execution in Office, abnormal file creation with macros in Office, suspicious registry operation, Confluence remote code execution, MSDT remote code execution, Windows log clearing using Wevtutil, log removal using Fsutil, suspicious HTTP requests initiated by regsvr32, and load download using Windows Defender Windows remote command execution, Log4shell vulnerability execution, suspicious scheduled task operation, suspicious Windows command execution, Windows intrusion tool transmission, suspicious reverse shell command, remote suspicious script execution, suspicious software installation, perl reverse shell, awk reverse shell, python reverse shell, lua reverse shell, mkfifo/openssl reverse shell, php reverse shell, ruby reverse shell, reverse proxy using rssocks, bash reverse shell, ncat reverse shell, exec redirect reverse shell, node reverse shell, telnet dual port reverse shell, nc reverse shell, socat reverse shell, php_socket reverse shell, socket/tchsh reverse shell, modify files using vigr/vipw, system security logs clearing and replacement, SSH backdoors flexible connection, SSH keys replacement, install backdoors using curl/wget

Using proxy software tools, Python/Base64 execution, sudo privilege escalation vulnerability exploitation, adding system accounts whose UID is 0 (root permission), bypass command execution to modify permissions using $IFS, files or directories deletion using wipe, github sensitive information disclosure, ARP spoofing using commands, system database passwd records check, CVE/CNVD vulnerabilities downloaded by curl/wget/gcc, suspicious driver loading, uninstalling or stopping server installation program, obtain SSH credentials using strace, Golang reverse shell, detect intra-domain information using ldapsearch, detect privilege escalation vulnerabilities using perl script, detect privilege escalation vulnerabilities using bash script, detect privilege escalation vulnerabilities using python script, Enumy privilege escalation enumeration tool, Hydra brute-force attack tool, CDK container penetration tool, stowaway proxy tool, CF cloud penetration tool, Redis intrusion through redis-rogue-server, browser data collection through hack-browser-data, suspicious server detection behavior, suspicious download behavior, suspicious interactive bash shell generation, sudo privilege escalation, vim privilege escalation, awk privilege escalation, obfuscated shell commands, hijacking of LD_PRELOAD dynamic link libraries, hijacking of dynamic linkers, suspicious sensitive file reading, suspicious sensitive file modification, socat port forwarding, ngrok port forwarding rinetd port forwarding, portmap port forwarding, portforward port forwarding, rakshasa port forwarding, hacker tool earthworm detection, suid/sgid privilege escalation, abnormal process behavior, suspicious scheduled task/auto-startup item creation, find privilege escalation, malicious domain names and malicious IP address access, reverse proxy using rcsocks/ssocks, SSH port forwarding, HashDump attacks, and procdump attacks

Login security check

Attempting brute-force attacks, brute force cracking success, user login success, remote login, user login rejection, first user login, and weak password of the system account

Malicious file detection

Abnormal shell, reverse shell, and malware

Port scan detection

Port scan

Root privilege escalation

Abnormal process behavior, suspicious process privilege escalation, and abnormal process external connection

Real-time process

High-risk command executions

Rootkit detection

Suspicious rootkit

The detailed operations for configuring the whitelist in the preceding table are as follows:

If you configure a file protection policy based on a newly created custom policy group, you need to deploy the new policy group and apply it to the target server after creating and configuring the policy group. For details, see Deploying a Protection Policy.

Container Information Collection

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the container policy group corresponding to the server and click the policy group name. The policy group details page is displayed.
  5. Click the name of the Container Information Collection policy. On the policy details page, configure Mount Path Whitelist.

    Figure 4 Container information collection policy
    Table 4 Container information collection policy whitelist parameters

    Parameter

    Examples

    Description

    Mount Path Whitelist

    /test

    Enter the mount directories that can be mounted. Use line breaks to separate multiple mount directory paths.

    If a directory ends with an asterisk (*), it indicates all the sub-directories under the directory (excluding the main directory).

    For example, if /var/test/* is specified in the whitelist, all sub-directories in /var/test/ are whitelisted, excluding the test directory.

  6. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

Cluster Intrusion Detection

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the container policy group corresponding to the server and click the policy group name. The policy group details page is displayed.
  5. Click the name of the target policy Cluster Intrusion Detection.
  6. In the Whitelist area, click Add and then click Add to add a whitelist text box.

    Figure 5 Adding a whitelist entry

  7. Select a whitelist type from the Type drop-down list and enter a value.

    Figure 6 Cluster intrusion detection policy
    Table 5 Cluster intrusion detection whitelist parameters

    Parameter

    Example Value

    Description

    Type

    IP address filtering

    Customize the types to be ignored during detection.

    The following types are supported:

    • IP address filter
    • Pod name filter
    • Image name filter
    • User filter
    • Pod tag filter
    • Namespace filter

    Value

    192.168.1.1

    Enter the value of the type. In this example, select IP address filter. In this case, enter a specific IP address.

  8. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

Container Escape Policy

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the container policy group corresponding to the server and click the policy group name. The policy group details page is displayed.
  5. Click the name of a Container Escape policy. On the policy details page that is displayed, configure the whitelist.

    You can configure whitelists of different levels, such as images, processes, and pods. You can configure any type of whitelist as required.
    Figure 7 Container escape policy
    Table 6 Container escape detection policy whitelist parameters

    Parameter

    Example Value

    Description

    Image Whitelist

    onlyoffice

    Enter the names of the images that do not need to perform container escape behavior detection. An image name can contain only letters, numbers, underscores (_), and hyphens (-), and each name needs to be on a separate line. Up to 100 image names are allowed.

    Process Whitelist

    /bin/flock

    Enter the full paths of processes that do not need to perform container escape behavior detection. A process path can contain only letters, numbers, underscores (_), and hyphens (-), and each path needs to be on a separate line. Up to 100 process paths are allowed.

    POD Name Whitelist

    case

    Enter the names of pods (not pod UIDs) that do not need to perform container escape behavior detection. A pod name can contain only letters, numbers, underscores (_), and hyphens (-), and each name needs to be on a separate line. Up to 100 pod names are allowed.

  6. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

Container Information Module

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the container policy group corresponding to the server and click the policy group name. The policy group details page is displayed.
  5. Click the name of a Container Information Module policy. On the policy details page that is displayed, configure the whitelist.

    You can configure the container and organization whitelist as required.
    Figure 8 Container information module policy
    Table 7 Container information collection whitelist parameters

    Parameter

    Example Value

    Description

    Custom Container Whitelist

    busy-me

    Enter the name of the container for which HSS alarms are not generated.

    • Simple names of containers can be configured based on Docker. HSS automatically performs fuzzy match. Other containers perform exact match based on their names.
    • Each container name needs to be on a separate line. Up to 100 whitelist items are allowed.

    Custom image organization whitelist

    scc_hss_container

    hwofficial

    Enter the organization name that can be used to prevent HSS alarms.

    Each organization name needs to be on a separate line. Up to 100 whitelist items are allowed.

  6. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

Container Process Whitelist

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the container policy group corresponding to the server and click the policy group name. The policy group details page is displayed.
  5. Click the name of a Container Process Whitelist policy. On the policy details page, configure the container process whitelist.

    Figure 9 Container process whitelist policy
    Table 8 Container process whitelist parameters

    Parameter ID in Figure 9

    Parameter

    Example Value

    Description

    ①

    Dynamic Whitelist

    Enable the dynamic whitelist Figure 9. HSS uses the following mechanism to detect container processes: By default, HSS uses the single-process model. That is, the container runs only the process command line configured in the container startup parameter. When a container is started, HSS automatically identifies the entrypoint configuration of the container and identifies the main process based on the entrypoint. If a process other than the main process is running during the container running, an alarm is generated.

    ②

    Whitelist

    Fuzzy Match

    Select it.

    Indicates whether to enable fuzzy match for the target process path.

    Image Name

    -

    Enter the name of the image to which the process belongs.

    Enter either the image name or image ID.

    Image ID

    sha256:ab1305a5e0a87345ad8cd91015990b7c34fb7a7e682266937872cefc9eb36671

    Enter the ID of the image to which the process belongs.

    Enter either the image name or image ID.

    Process

    /tmp/testw

    Enter the path of the process that does not need to be checked.

  6. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

Fileless Attack Detection

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Locate the policy group of the edition corresponding to the server and click the policy group name.
  5. Click the name of a Fileless Attack Detection policy. On the policy details page that is displayed, set whitelist.

    Figure 10 Fileless attack detection policy
    Table 9 Parameters of the policy for fileless attack detection

    Parameter

    Example Value

    Description

    Trustlist matching specifications

    Full match, case sensitive
    Path whitelist matching rule. Click to select a whitelist matching rule. The options are as follows:
    • Full match, case sensitive
    • Full match, case-insensitive
    • Fuzzy matching

    Path trustlist

    /usr/sbin/hald

    Enter paths that do not need to be detected for Process injection, LD hijacking, or Memory-based process. Separate multiple paths by line breaks.

  6. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

File Protection

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the policy group of the corresponding protection version. The policy group details page is displayed.
  5. Click the name of a target policy. On the details page that is displayed, configure the types or paths of files that can be ignored.

    Figure 11 File protection policy
    Table 10 Parameter description

    Category

    Parameter

    Example Value

    Description

    File Privilege Escalation

    Ignored File Paths

    /usr/lib64/hal/hald-runner

    /usr/sbin/hald

    /opt/nfast/sbin/privconn

    /usr/sbin/dhclient

    /usr/sbin/tcpdump

    Enter the path of the file to be ignored. Start the path with a slash (/) and do not end it with a slash (/). Each path occupies a line. No spaces are allowed between path names.

    Important File Directory Change

    Unmonitored File Types

    swo

    swp

    swpx

    lck

    Enter the suffix of the unmonitored file type. Multiple file types are separated by line breaks.

    Unmonitored File Paths

    /etc/init.d/.depend.start

    /etc/init.d/.depend.stop

    /etc/init.d/.depend.halt

    /etc/init.d/.depend.boot

    /var/spool/cron/sed*

    Enter the path of the file to be ignored. Start the path with a slash (/) and do not end it with a slash (/). Each path occupies a line. No spaces are allowed between path names.

  1. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

HIPS Detection

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the policy group of the corresponding protection version. The policy group details page is displayed.
  5. Click the name of a HIPS detection policy. On the details page that is displayed, configure the trusted process.

    Figure 12 HIPS detection policy
    Table 11 Parameters description of the HIPS detection policy whitelist

    Parameter

    Example Value

    Description

    Process File Path

    /usr/bin/bash

    Add the full path of the trusted process. You can click Add to add a path and click Delete to delete it.

  1. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

Login Security Check

The login security detection policy not only generates alarms for brute-force attacks, but also blocks brute-force attack IP addresses. If you only add alarms to the login alarm whitelist, subsequent alarms can be avoided, but the trusted IP addresses are blocked. You can set trusted IP addresses in the login security detection policy to avoid alarms and blocking.

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the policy group of the corresponding protection version. The policy group details page is displayed.
  5. Click the name of the login security detection policy. On the details page that is displayed, configure trusted IP addresses.

    Figure 13 Login security detection policy
    Table 12 Parameter description

    Parameter

    Example Value

    Description

    Report Alarm on Brute-force Attack from Whitelisted IP Address

    Specifies whether an alarm is generated when brute force cracking occurs on an IP address in the whitelist.

    indicates that no alarm is generated.

    Whitelist

    203.218.166.56

    After an IP address is added to the whitelist, HSS does not block brute force attacks from the IP address in the whitelist.

    A maximum of 50 IP addresses or network segments can be added to the whitelist. Both IPv4 and IPv6 addresses are supported.

  1. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

Malicious File Detection

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the policy group of the corresponding protection version. The policy group details page is displayed.
  5. Click the name of the malicious file detection policy. On the details page that is displayed, configure the content to be ignored.

    You only need to configure the content to be ignored.
    Figure 14 Malicious file detection policy
    Table 13 Parameter description

    Parameter

    Example Value

    Description

    Whitelist Paths in Reverse Shell Check

    /usr/bin/gnome-terminal

    /usr/local/spes/spesservice

    /usr/local/syscheck/messageservice

    /usr/local/hostguard/bin/hostguard

    Enter the whitelist path in reverse shell check.

    Start with a slash (/) and end with no slashes (/). Occupy a separate line and cannot contain spaces.

    Ignored Reverse Shell Local Port

    51954

    Enter the ignored reverse shell local port. Separate multiple ports with commas (,).

    Ignored Reverse Shell Remote Address

    192.78.10.8

    Enter the ignored remote IP address or network segment in reverse shell detection. Use commas (,) to separate multiple IP addresses or network segments. Enter an IPv4 or IPv6 address.

    For example:

    • IPv4 address: 192.78.10.3
    • IPv4 network segment: 192.78.10.0/255.255.255.0 or 192.78.10.0/24
    • IPv6 address: 2001:0db8:86a3:08d3:1319:8a2e:0370:7344
    • IPv6 network segment: 234e:0:4567 3d/ffff ffff:ffff:ffff::0 or 2001:db8:832:11::/64

  1. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

Port Scan Detection

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the policy group of the corresponding protection version. The policy group details page is displayed.
  5. Click the name of the port scan detection policy. On the details page that is displayed, configure the source IP address whitelist.

    Figure 15 Port scan detection policy
    Table 14 Port scan detection policy whitelist parameters

    Parameter

    Example Value

    Description

    Source IP Address Whitelist

    192.168.1.11

    Scan for ignored source IP addresses. IP addresses or masks are supported. Use commas (,) to separate multiple IP addresses or masks.

  1. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

Root Privilege Escalation

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the policy group of the corresponding protection version. The policy group details page is displayed.
  5. Click the name of the root privilege escalation policy. On the details page that is displayed, configure the path of the ignored process file.

    Figure 16 Root privilege escalation policy
    Table 15 Parameters description of the root privilege escalation policy whitelist

    Parameter

    Example Value

    Description

    Ignored Process File Path

    /usr/sbin/ntpd

    /usr/sbin/hald

    Set the ignored process file path.

    Start with a slash (/) and end with no slashes (/). Occupy a separate line and cannot contain spaces.

  1. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

Real-time Process

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the policy group of the corresponding protection version. The policy group details page is displayed.
  5. Click the name of the real-time process policy. The policy details page is displayed.
  6. In the Whitelist area, click Add to add a whitelist text box.
  7. Set whitelist parameters as prompted.

    Figure 17 Real-time process policy
    Table 16 Parameters of the real-time process policy whitelist

    Parameter

    Example Value

    Description

    Process Path or Process Name

    /usr/bin/sleep

    Add paths or program names that are allowed or ignored during detection.

    Command Expression in CLI

    ^[A-Za-z0-9[:space:]\\*\\.\\\":_'\\(>=-]+$

    Enter the regular expression of the whitened command line.

    This parameter is optional.

  1. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.

Rootkit Detection

  1. Log in to the management console.
  2. In the upper left corner of the page, select a region, click , and choose Security & Compliance > HSS.
  3. In the navigation pane, choose Security Operations > Policies.
  4. Select the policy group of the corresponding protection version. The policy group details page is displayed.
  5. Click the name of the rootkit detection policy. On the details page that is displayed, configure the kernel module whitelist.

    Figure 18 Rootkit detection policy
    Table 17 Parameters description of the rootkit detection policy whitelist

    Parameter

    Example Value

    Description

    Kernel Module Whitelist

    xt_conntrack

    virtio_scsi

    tun

    Add the kernel modules that can be ignored during the detection.

    Up to 10 kernel modules can be added. Multiple modules are separated by line breaks.

  1. Confirm the information and click OK.

    If All projects are selected for an enterprise project and the policy of the default policy group is modified, you can click Save and Apply to Other Projects to apply the modification to other policies of the same version.