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 2024-07-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 HSS container edition supports the container security alarm function.
  • Intrusion detection alarms can be generated only for Docker containers.

Container Alarm Types

Event Type

Alarm Name

Mechanism

Malware

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.

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.

Vulnerability Exploits

Vulnerability escapes

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

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.

Abnormal System Behaviors

Reverse shells

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.

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

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.

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 , before the container is started, an alarm will be generated for the insecure images.

NOTE:

You need to .

Abnormal User Behavior

Invalid accounts

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

HSS checks for 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.

Abnormal Cluster Behaviors

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.

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