Container Alarm Events
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.
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. 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. 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:
|
||
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:
|
||
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 |
|
||
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:
|
||
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. |
||
Suspicious command executions |
|
||
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.
Containers that meet the following conditions can be scanned for abnormal runtime behaviors:
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.
|
||
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:
|
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.
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. |
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot