Container Alarm Events

Exploits Used

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 Behavior

High-risk system calls

CGS reports an alarm if it detects a high-risk call, such as open_by_handle_at, ptrace, setns, or reboot.

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

  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.

  Such alarms contain privileged:true, indicating that the alarmed container is started in privileged 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.

  Such alarms contain capabilities:[xxx], indicating that the alarmed container is started with too many capabilities.

• 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.

  Such alarms contain seccomp=unconfined, indicating that the alarmed container is started without enabling seccomp.

  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)

  CGS reports an alarm if it detects that a process attempts to escalate permissions by running the sudo command and using the SUID or SGID bit.

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

  Such alarms contain no-new-privileges:false, indicating that privileges are not restricted for the alarmed containers.

• 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, /var/run) is mounted during container startup.

  Such alarms contain mounts:[{"source":"xxx","destination":"yyy"...].

  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.