Compute
Elastic Cloud Server
Huawei Cloud Flexus
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Management & Governance
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
OneAccess
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
IAM Identity Center
Cloud Operations Center
Resource Governance Center
Migration
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Analytics
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
Data Lake Factory
DataArts Lake Formation
IoT
IoT Device Access
Others
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Security & Compliance
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Edge Security
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Web3 Node Engine Service
Media Services
Media Processing Center
Video On Demand
Live
SparkRTC
MetaStudio
Storage
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service Turbo
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
Multi-Site High Availability Service
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Business Applications
Workspace
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Video Intelligent Analysis Service
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Content Delivery & Edge Computing
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Intelligent EdgeCloud
Solutions
SAP Cloud
High Performance Computing
Developer Services
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
CodeArts Repo
Cloud Application Engine
MacroVerse aPaaS
KooMessage
KooPhone
KooDrive

Container Alarm Events

Updated on 2025-02-12 GMT+08:00

After node protection is enabled, an agent is deployed on each container host to monitor the running status of containers in real time. The agents support escape detection, high-risk system calls, abnormal processes, abnormal files, and container environment detection. You can learn alarm events comprehensively on the Container Alarms page, and eliminate security risks in your assets in a timely manner.

Constraints

  • Only the HSS container edition supports container security alarms. For details about how to purchase and upgrade HSS, see Purchasing HSS and Upgrading Quota.
  • The container security alarm function supports intrusion detection and alarm reporting for the following Linux container runtime components:
    • Containerd
    • Docker

Container Security Alarms

For details about container security alarm types and alarm items, see Table 1.

Table 1 Container security alarms

Alarm Type

Alarm Type Description

Alarm

Alarm Description

Malware

Malicious software includes viruses, worms, Trojans, and web shells implanted by hackers to steal your data or control your servers.

For example, hackers will probably use your servers as miners or DDoS zombies. This occupies a large number of CPU and network resources, affecting service stability.

Unclassified malware

Check malware, such as web shells, Trojan horses, mining software, worms, and other viruses and variants. The malware is found and removed by analysis on program characteristics and behaviors, AI image fingerprint algorithms, and cloud scanning and killing.

Viruses

Check containers in real time and report alarms for viruses detected in the container runtime.

Worms

Detect worms in container runtime and report alarms.

Trojans

Detect and remove Trojan and viruses in containers and report alarms.

Botnets

Detect and kill botnetsin containers and report alarms.

Backdoors

Detect backdoors in containers and report alarms.

Rootkits

Check container assets and report alarms for suspicious kernel modules, files, and folders.

Ransomware

Check for ransomware in web pages, software, emails, and storage media.

Ransomware can encrypt and control your data assets, such as documents, emails, databases, source code, images, and compressed files, to leverage victim extortion.

Web shells

Check whether the files (often PHP and JSP files) in the web directories on containers are web shells.

Hacker tools

Report alarms on the malicious behaviors that exploit vulnerabilities or are performed using hacker tools.

Mining software

Detect programs that are hidden in normal programs and have special functions such as damaging and deleting files, sending passwords, and recording keyboards. If a suspicious program is detected, an alarm is reported immediately.

Vulnerability Exploits

The exploit of vulnerabilities in the server system, software, or network to obtain unauthorized access rights, steal data, or damage the target system.

Exploits can be performed remotely or locally. In a remote vulnerability exploit, an attacker connects to the target system through the network and discovers system vulnerabilities to launch attacks. In a local vulnerability exploit, an attacker obtains low access permissions on the target system and exploits vulnerabilities to escalate permissions or perform other malicious operations.

Vulnerability escapes

A vulnerability escape attack exploits application vulnerabilities, container infrastructure vulnerabilities, orchestration system vulnerabilities, or container runtime vulnerabilities to bypass the security mechanism and obtain unauthorized access permissions or perform unauthorized operations.

HSS reports an alarm if it detects container process behavior that matches the behavior of known vulnerabilities (such as Dirty COW, brute-force attack, runC, and shocker).

File escapes

In file escape attacks, attackers exploit file system or application vulnerabilities to bypass file permission restrictions and access or modify unauthorized files or directories.

HSS reports an alarm if it detects that a container process accesses a key file directory (for example, /etc/shadow or /etc/crontab). Directories that meet the container directory mapping rules can also trigger such alarms.

NOTE:

UOS 1050u2e does not support file escape detection.

Abnormal System Behaviors

Abnormal system behaviors occur while servers are running, and are usually caused by system faults, malicious attacks, or security vulnerabilities. Abnormal system behaviors may cause data loss or system breakdown. To protect server system and data security, it is important to detect and handle abnormal system behaviors in a timely manner.

Reverse shells

Monitor user process behaviors in real time to report alarms on and block reverse shells caused by invalid connections.

Reverse shells can be detected for protocols including TCP, UDP, and ICMP.

You can configure the reverse shell detection rule in the Malicious File Detection rule on the Policies page. HSS will check for suspicious or remotely executed commands.

To enable automatic reverse shell blocking, enable Auto Blocking in the HIPS Detection policy on the Policies page.

Currently, the following types of reverse shells can be blocked: exec reverse shell, Perl reverse shell, AWK reverse shell, Python reverse shell.b, Python reverse shell.a, Lua reverse shell, mkfifo/openssl reverse shell, PHP reverse shell, Ruby reverse shell, rssocks reverse proxy, Bash reverse shell, Ncat reverse shell, exec redirection reverse shell, Node reverse shell, Telnet dual-port reverse shell, nc reverse shell, Socat reverse shell, rm/mkfifo/sh/nc reverse shell, and socket/tchsh reverse shell.

NOTE:

Before you enable auto blocking of reverse shells, ensure you have enabled the function of isolating and killing malicious programs.

File privilege escalation

Report alarms on root privilege escalations exploiting SUID and SGID program vulnerabilities.

Process privilege escalations

After hackers intrude containers, they will try exploiting vulnerabilities to grant themselves the root permissions or add permissions for files. In this way, they can illegally create system accounts, modify account permissions, and tamper with files.

HSS can detect the following abnormal privilege escalation operations:

  • Root privilege escalation by exploiting SUID program vulnerabilities
  • Root privilege escalation by exploiting kernel vulnerabilities
  • File privilege escalation

Important file changes

Monitor important system files (such as ls, ps, login, and top) in real time and generate alarms if these files are modified. For more information, see Monitored important file paths.

HSS reports all the changes on important files, regardless of whether the changes are performed manually or by processes.

File/Directory changes

Monitor system files and directories in real time and generate alarms if such files are created, deleted, moved, or if their attributes or content are modified.

Abnormal process behaviors

Check the processes on servers, including their IDs, command lines, process paths, and behavior.

Send alarms on unauthorized process operations and intrusions.

The following abnormal process behavior can be detected:

  • Abnormal CPU usage
  • Processes accessing malicious IP addresses
  • Abnormal increase in concurrent process connections

High-risk system calls

Users can run tasks in kernels by Linux system calls. CGS reports an alarm if it detects a high-risk call, such as open_by_handle_at, ptrace, setns, and reboot.

Abnormal shells

Check containers for actions on abnormal shells, including moving, copying, and deleting shell files, and modifying the access permissions and hard links of the files.

You can configure the abnormal shell detection rule in the Malicious File Detection rule on the Policies page. HSS will check for suspicious or remotely executed commands.

High-risk command executions

Check executed commands in containers and generate alarms if high-risk commands are detected.

Abnormal container processes

  • Malicious container program

    HSS monitors container process behavior and process file fingerprints. It reports an alarm if it detects a process whose behavior characteristics match those of a predefined malicious program.

  • Abnormal processes

    Container services are usually simple. If you are sure that only specific processes run in a container, you can whitelist the processes on the Policy Groups page, and associate the policy with the container.

    HSS reports an alarm if it detects that a process not in the whitelist is running in the container.

Sensitive file access

HSS monitors the container image files associated with file protection policies, and reports an alarm if the files are modified.

Abnormal container startups

HSS monitors container startups and reports an alarm if it detects that a container with too many permissions is started. This alarm does not indicate an actual attack. Attacks exploiting this risk will trigger other HSS container alarms.

HSS container check items include:

  • Privileged container startup (privileged:true)

    Alarms are triggered by the containers started with the maximum permissions. Settings that can trigger such alarms include the –privileged=true parameter in the docker run command, and privileged: true in the securityContext of the container in a Kubernetes pod.

    If the alarm name is Container Security Options and the alarm content contains privileged:true, it indicates that the container is started in privileged container mode.

  • Too many container capabilities (capability:[xxx])

    In Linux OSs, system permissions are divided into groups before assigned to containers. A container only has a limited number of permissions, and the impact scope of this container is limited in the case of an incident. However, malicious users can grant all the system permissions to a container by modifying its startup configurations.

    If the alarm name is Container Security Options and the alarm content contains capabilities:[xxx], it indicates that the container is started with an overlarge capability set, which poses risks.

  • Seccomp not enabled (seccomp=unconfined)

    Secure computing mode (seccomp) is a Linux kernel feature. It can restrict system calls invoked by processes to reduce the attack surface of the kernel. If seccomp=unconfined is configured when a container is started, system calls will not be restricted for the container.

    If the alarm name is Container Security Options and the alarm content contains seccomp=unconfined, it indicates that the container is started without seccomp, which poses risks.

    NOTE:

    If seccomp is enabled, permissions will be verified for every system call. The verifications will probably affect services if system calls are frequent. Before you decide whether to enable seccomp, you are advised to test-enable it and analyze the impact on your services.

  • Container privilege escalation (no-new-privileges:false)

    Processes can escalate permissions by running the sudo command and using SUID or SGID bits. Default container configurations do not allow privilege escalation.

    If –no-new-privileges=false is specified when a container is started, the container can escalate privileges.

    If the alarm name is Container Security Options and the alarm content contains no-new-privileges:false, it indicates that privilege escalation restriction is disabled for the container, which poses risks.

  • High-risk directory mapping (mounts:[...])

    For convenience purposes, when a container is started on a server, the directories of the server can be mapped to the container. In this way, services in the container can directly read and write resources on the server. However, this mapping incurs security risks. If any critical directory in the server OS is mapped to the container, improper operations in the container will probably damage the server OS.

    HSS reports an alarm if it detects that a critical server path (/boot, /dev, /etc, /sys, and /var/run) is mounted during container startup.

    If the alarm name is Container Mount Point and the alarm content contains mounts:[{"source":"xxx","destination":"yyy"...], it indicates that a file path mapped to the container is unsafe. In this case, check for risky directory mappings. You can configure the mount paths that are considered secure in the container information collection policy.

    NOTE:

    Alarms will not be triggered for the files that need to be frequently accessed by Docker containers, such as /etc/hosts and /etc/resolv.conf.

  • Startup of containers in the host namespace

    The namespace of a container must be isolated from that of a server. If a container and a server use the same namespace, the container can access and modify the content on the server, which incurs container escape risks. To prevent such problems, HSS checks the container PID, network, and whether the container namespace is host.

    If the alarm name is Container Namespace and the alarm content contains Container PID Namespace Mode, Container IPC Namespace Mode, or Container Network Namespace Mode, it indicates that a container whose namespace is host is started. In this case, check the container startup options based on the alarm information. If you are sure that the container can be trusted, you can ignore the alarm.

Container Image blocking

If a container contains insecure images specified in the Suspicious Image Behaviors, before the container is started, an alarm will be generated for the insecure images.

NOTE:

Suspicious command executions

  • Check whether a scheduled task or an automated startup task is created or deleted by running commands or tools.
  • Detect suspicious remote command execution.

Abnormal runtime behaviors

Abnormal runtime behaviors refer to suspicious behaviors that occur during container running. These behaviors may affect container security or even be exploited by attackers to escape containers.

HSS can detect container escapes at the levels of networks, servers, pods, containers, processes, and system calls. Five types of abnormal behaviors (processes, files, network activities, process capabilities, and system calls) in containers and their hosts can be detected, reported, and blocked to prevent container escape and protect container runtime.

  • Process monitoring: Monitor suspicious process behaviors in containers and their hosts, and detect and prevent abnormal system calls and process operations, for example, using cdk evaluate to collect container information through container penetration test tools.
  • File system monitoring: Monitor file system operations in containers and their hosts, and detect and prevent unauthorized file access and modification, for example, running the echo "test" /etc/profile command to modify key system files.
  • Network activity monitoring: Monitor network activities in containers and their hosts, and detect and prevent abnormal network connections and data transmission, for example, running the wget 127.0.0.x command to connect to the destination IP address in a container.
  • Process capabilities monitoring: Monitor the capabilities of processes in containers and their hosts, and detect and prevent suspicious capability configuration, for example, running the mknod -m 640 /tmp/test4 c 100 2 command to mount the devices represented by special strings.
  • System call monitoring: Monitor system calls in the containers and their hosts, and detect and prevent high-risk system calls, for example, running the chown root.root /opt/testfile command to change the owner and owner group of files in a container.

Containers that meet the following conditions can be scanned for abnormal runtime behaviors:

  • The Linux kernel version is 5.10 or later.
  • BPF LSM is enabled.

To use abnormal runtime behavior detection, configure and enable the container escape prevention policy. For details, see Configuring Policies.

Abnormal User Behavior

Abnormal or unexpected user behaviors that occur in a specific environment or system, sometimes within a short period of time, such as abnormal logins or unauthorized access. To detect and identify these abnormal behaviors, user operations need to be checked and analyzed.

Invalid accounts

Hackers can probably crack unsafe accounts on your containers and control the containers.

HSS checks suspicious hidden accounts and cloned accounts and generates alarms on them.

Brute-force attacks

Detect and report alarms for brute-force attack behaviors, such as brute-force attack attempts and successful brute-force attacks, on containers.

Detect SSH, web, and Enumdb brute-force attacks on containers.

NOTE:
  • Currently, brute-force attacks can be detected only in the Docker runtime.
  • Ubuntu 24.04 and SUSE 15 SP6 do not support brute-force attack detection.

Password thefts

Report alarms on user key theft.

Abnormal Network Access

Abnormal network access refers to exceptions that occur during network connection or data transmission and different from normal usage. These exceptions include abnormal resource usage, unauthorized access, and abnormal connections. Abnormal network access behaviors on servers may be a prelude to attacks.

Abnormal outbound connections

Report alarms on suspicious IP addresses that initiate outbound connections.

Only the containers with kernel 5.10 or later can be checked.

Port forwarding

Report alarms on port forwarding using suspicious tools.

Abnormal Cluster Behaviors

Abnormal cluster behaviors occur in the cluster environment, such as pod creation, execution exceptions, and user information enumeration. These exceptions may indicate that the cluster is under an attack.

Abnormal pod behaviors

Detect abnormal operations such as creating privileged pods, static pods, and sensitive pods in a cluster and abnormal operations performed on existing pods and report alarms.

User information enumerations

Detect the operations of enumerating the permissions and executable operation list of cluster users and report alarms.

Binding cluster roles

Detect operations such as binding or creating a high-privilege cluster role or service account and report alarms.

Kubernetes event deletions

Detect the deletion of Kubernetes events and report alarms.

Fileless Attacks

A fileless attack does not release malicious executable files. Instead, it writes malicious code into the system memory or registry. Because there are no malicious files used, such an attack is difficult to detect.

Fileless attacks are classified into the following types based on disk file activities:

  • No file activities.

    That is, no disk files are stored or operated in disks. Generally, such attacks are initiated in the upper-layer hardware, firmware, or software layer rather than the OS.

  • Indirect activities through files.

    That is, no files are stored in disks, but activities are indirectly performed through files. Malicious code is usually indirectly loaded to the memory for execution through white files. Most of such malicious code is carried by scripts, which are executed through program commands or specific mechanisms such as disk boot records.

  • File activities required.

    Generally, malicious code is converted into data. Attackers exploit file-related program vulnerabilities or features to convert malicious data into malicious code for execution.

Process injection

Scan for malicious code injection into running processes and report alarms.

Dynamic library injection

Scan for the payloads injected by hijacking functions in the dynamic link library (DLL) and report alarms.

Memory file process

Scan for the behaviors of creating an anonymous malicious file that exists only in the RAM through the memfd_create system call and executing the file, and report alarms on such behaviors.

Security Alarm Severities

HSS alarm severities indicate alarm impact on service systems. It can be Critical, High, Medium, or Low. For details, see Table 2.

Table 2 Security alarm severities

Alarm Severity

Description

Critical

A critical alarm indicates that the system is severely attacked, which may cause data loss, system breakdown, or long service interruption. For example, such alarms are generated if ransomware encryption behaviors or malicious programs are detected. You are advised to handle the alarms immediately to avoid severe system damage.

High

A high-risk alarm indicates that the system may be under an attack that has not caused serious damage. For example, such alarms are generated if unauthorized login attempts are detected or unsafe commands (for deleting critical system files or modifying system settings) are executed. You are advised to investigate and take measures in a timely manner to prevent attacks from spreading.

Medium

A medium-risk alarm indicates that the system has potential security threats, but there are no obvious signs of being attacked. For example, if abnormal modifications of a file or directory are detected, there may be potential attack paths or configuration errors in the system. You are advised to further analyze and take proper preventive measures to enhance system security.

Low

A low-risk alarm indicates that a minor security threat exists in the system but does not have significant impact on your system. For example, such alarms are generated if port scans are detected, indicating that there may be attackers trying to find system vulnerabilities. These alarms do not require immediate emergency measures. If you have high requirements on asset security, pay attention to the security alarms of this level.

Monitored important file paths

Type

Linux

bin

/bin/ls

/bin/ps

/bin/bash

/bin/login

usr

/usr/bin/ls

/usr/bin/ps

/usr/bin/bash

/usr/bin/login

/usr/bin/passwd

/usr/bin/top

/usr/bin/killall

/usr/bin/ssh

/usr/bin/wget

/usr/bin/curl

We use cookies to improve our site and your experience. By continuing to browse our site you accept our cookie policy. Find out more

Feedback

Feedback

Feedback

0/500

Selected Content

Submit selected content with the feedback