In the evolving landscape of container orchestration, Kubernetes has emerged as the de facto standard due to its flexibility, scalability, and robust community support. However, as with any complex system, securing a Kubernetes environment presents unique challenges. Containers, by their very nature, are transient and multi-faceted, making traditional security methods less effective. This is where Falco, an open-source Cloud Native Computing Foundation (CNCF) project, becomes invaluable.

Falco is designed to provide security monitoring and anomaly detection for Kubernetes, enabling teams to detect malicious activity and vulnerabilities in real-time. It operates by intercepting and analyzing system calls to identify unexpected behavior within applications running in containers. As a cloud-native tool, Falco seamlessly integrates into Kubernetes environments, offering deep insights and proactive security measures without the overhead of traditional security tools.

Is Your etcd an Open Door for Cyber Attacks? How to Secure Your Kubernetes Clusters & Nodes

As teams embark on securing their Kubernetes clusters, here are several Falco rules that are recommended to fortify their deployments effectively:

1. Contact K8S API Server From Container

The Falco rule “Contact K8S API Server From Container” is designed to detect attempts to communicate with the Kubernetes (K8s) API Server from a container, particularly by users who are not profiled or expected to do so. This rule is crucial because the Kubernetes API plays a pivotal role in managing the cluster’s lifecycle, and unauthorized access could lead to significant security issues.

Rule Details:

• Purpose: To audit and flag any unexpected or unauthorized attempts to access the Kubernetes API server from within a container. This might indicate an attempt to exploit the cluster’s control plane or manipulate its configuration.
• Detection Strategy: The rule monitors network connections made to the API server’s typical ports and checks whether these connections are made by entities (users or processes) that are not explicitly allowed or profiled in the security policy.
• Workload Applicability: This rule is applicable in environments where containers should not typically need to directly interact with the Kubernetes API server, or where such interactions should be limited to certain profiles.

MITRE ATT&CK Framework Mapping:

• Tactic: Credential Access, Discovery
• Technique: T1552.004 (Unsecured Credentials: Kubernetes)

Example Scenario:

Suppose a container unexpectedly initiates a connection to the Kubernetes API server using kubectl or a similar client. This activity could be flagged by the rule if the container and its user are not among those expected or profiled to perform such actions. Monitoring these connections helps in early detection of potential breaches or misuse of the Kubernetes infrastructure.

This rule, by monitoring such critical interactions, helps maintain the security and integrity of Kubernetes environments, ensuring that only authorized and intended communications occur between containers and the Kubernetes API server.

2. Disallowed SSH Connection Non Standard Port

The Falco security rule “Disallowed SSH Connection Non Standard Port” is designed to detect any new outbound SSH connections from a host or container that utilize non-standard ports. This is significant because SSH typically operates on port 22, and connections on other ports might indicate an attempt to evade detection.

Rule Details:

• Purpose: To monitor and flag SSH connections that are made from non-standard ports, which could be indicative of a security compromise such as a reverse shell or command injection vulnerability being exploited.
• Detection Strategy: The rule checks for new outbound SSH connections that do not use the standard SSH port. It is particularly focused on detecting reverse shell scenarios where the victim machine connects back to an attacker’s machine, with command and control facilitated through the SSH protocol.
• Configuration: The rule suggests that users may need to expand the list of monitored ports based on their specific environment’s configuration and potential threat scenarios. This may include adding more non-standard ports or ranges that are relevant to their network setup.

Example Scenario:

An application on a host might be compromised to execute a command that initiates an SSH connection to an external server on a non-standard port, such as 2222 or 8080. This could be part of a command injection attack where the attacker has gained the ability to execute arbitrary commands on the host.

This rule helps in detecting such activities, which are typically red flags for data exfiltration, remote command execution, or establishing a foothold inside the network through unconventional means. By flagging these activities, administrators can investigate and respond to potential security incidents more effectively.

3. Directory Traversal Monitored File Read

The Falco rule “Directory Traversal Monitored File Read” is aimed at detecting and alerting on directory traversal attacks specifically when they involve reading files from critical system directories that are usually accessed via absolute paths. This rule is critical in preventing attackers from exploiting vulnerabilities to access sensitive information outside the intended file directories, such as the web application’s root.

Rule Details:

• Purpose: To monitor and alert on attempts to read files from sensitive directories like /etc through directory traversal attacks. These attacks exploit vulnerabilities allowing attackers to access files and directories that lie outside the web server’s root directory.
• Detection Strategy: The rule focuses on detecting read operations on sensitive files that should not be accessed under normal operational circumstances. Access patterns that deviate from the norm (e.g., accessing files through paths that navigate up the directory tree using ../) are flagged.
• Workload Applicability: This rule is particularly important for environments running web applications where directory traversal vulnerabilities could be exploited.

Example Scenario:

An attacker might exploit a vulnerability in a web application to read the /etc/passwd file by submitting a request like GET /api/files?path=../../../../etc/passwd. This action attempts to break out of the intended directory structure to access sensitive information. The rule would flag such attempts, providing an alert to system administrators.

This rule helps maintain the integrity and security of the application’s file system by ensuring that only legitimate and intended file accesses occur, preventing unauthorized information disclosure through common web vulnerabilities.

4. Netcat Remote Code Execution in Container

The Falco security rule “Netcat Remote Code Execution in Container” is designed to detect instances where the Netcat tool is used within a container environment in a way that could facilitate remote code execution. This is particularly concerning because Netcat is a versatile networking tool that can be used maliciously to establish backdoors and execute commands remotely.

Rule Details:

• Purpose: To monitor and alert on the use of the Netcat (nc) program within containers, which could indicate an attempt to misuse it for unauthorized remote command execution.
• Detection Strategy: The rule flags the execution of Netcat inside a container, which is typically unexpected in a controlled environment. This detection focuses on uses of Netcat that might facilitate establishing a remote shell or other command execution pathways from outside the container.
• Workload Applicability: This rule is important in environments where containers are used to host applications and where there should be strict controls over what executable utilities are allowed.

Example Scenario:

An attacker might exploit a vulnerability within an application running inside a container to download and execute Netcat. Then, they could use it to open a port that listens for incoming connections, allowing the attacker to execute arbitrary commands remotely. This setup could be used for data exfiltration, deploying additional malware, or further network exploitation.

By detecting the use of Netcat in such scenarios, administrators can quickly respond to potential security breaches, mitigating risks associated with unauthorized remote access. This rule helps ensure that containers, which are often part of a larger microservices architecture, do not become points of entry for attackers.

5. Terminal Shell in Container

The Falco security rule “Terminal Shell in Container” is designed to detect instances where a shell is used as the entry or execution point in a container, particularly with an attached terminal. This monitoring is crucial because unexpected terminal access within a container can be a sign of malicious activity, such as an attacker gaining access to run commands or scripts.

Rule Details:

• Purpose: To monitor for the usage of interactive shells within containers, which could indicate an intrusion or misuse. Terminal shells are typically not used in production containers unless for debugging or administrative purposes, thus their use can be a red flag.
• Detection Strategy: The rule flags instances where a shell process is initiated with terminal interaction inside a container. It can help in identifying misuse such as an attacker using kubectl exec to run commands inside a container or through other means like SSH.
• Workload Applicability: This rule is particularly important in environments where containers are expected to run predefined tasks without interactive sessions.

Example Scenario:

An attacker or an unauthorized user gains access to a Kubernetes cluster and uses kubectl exec to start a bash shell in a running container. This action would be flagged by the rule, especially if the shell is initiated with an attached terminal, which is indicative of interactive use.

This rule helps in ensuring that containers, which should typically run without interactive sessions, are not misused for potentially harmful activities. It is a basic auditing tool that can be adapted to include a broader list of recognized processes or conditions under which shells may be legitimately used, thus reducing false positives while maintaining security.

6 .Packet Socket Created in Container

The Falco security rule “Packet Socket Created in Container” is designed to detect the creation of packet sockets at the device driver level (OSI Layer 2) within a container. This type of socket can be used for tasks like ARP spoofing and is also linked to known vulnerabilities that could allow privilege escalation, such as CVE-2020-14386.

Rule Details:

• Purpose: The primary intent of this rule is to monitor and alert on the creation of packet sockets within containers, a potentially suspicious activity that could be indicative of nefarious activities like network sniffing or ARP spoofing attacks. These attacks can disrupt or intercept network traffic, and the ability to create packet sockets might be used to exploit certain vulnerabilities that lead to escalated privileges within the host system.
• Detection Strategy: This rule tracks the instantiation of packet sockets, which interact directly with the OSI Layer 2, allowing them to send and receive packets at the network interface controller level. This is typically beyond the need of standard container operations and can suggest a breach or an attempt to exploit.
• Workload Applicability: It is crucial for environments where containers are part of a secured and controlled network and should not require low-level network access. The creation of such sockets in a standard web application or data processing container is usually out of the ordinary and warrants further investigation.

Example Scenario:

Consider a container that has been compromised through a web application vulnerability allowing an attacker to execute arbitrary commands. The attacker might attempt to create a packet socket to perform ARP spoofing, positioning the compromised container to intercept or manipulate traffic within its connected subnet for data theft or further attacks.

This rule helps in early detection of such attack vectors, initiating alerts that enable system administrators to take swift action, such as isolating the affected container, conducting a forensic analysis to understand the breach’s extent, and reinforcing network security measures to prevent similar incidents.

By implementing this rule, organizations can enhance their monitoring capabilities against sophisticated network-level attacks that misuse containerized environments, ensuring that their infrastructure remains secure against both internal and external threats. This proactive measure is a critical component of a comprehensive security strategy, especially in complex, multi-tenant container orchestration platforms like Kubernetes.

7.Debugfs Launched in Privileged Container

The Falco security rule “Debugfs Launched in Privileged Container” is designed to detect the activation of the debugfs file system debugger within a container that has privileged access. This situation can potentially lead to security breaches, including container escape, because debugfs provides deep access to the Linux kernel’s internal structures.

Rule Details:

• Purpose: To monitor the use of debugfs within privileged containers, which could expose sensitive kernel data or allow modifications that lead to privilege escalation exploits. The rule targets a specific and dangerous activity that should generally be restricted within production environments.
• Detection Strategy: This rule flags any instance where debugfs is mounted or used within a container that operates with elevated privileges. Given the powerful nature of debugfs and the elevated container privileges, this combination can be particularly risky.
• Workload Applicability: This rule is crucial in environments where containers are given privileged access and there is a need to strictly control the tools and commands that can interact with the system’s kernel.

Example Scenario:

Consider a scenario where an operator mistakenly or maliciously enables debugfs within a privileged container. This setup could be exploited by an attacker to manipulate kernel data or escalate their privileges within the host system. For example, they might use debugfs to modify runtime parameters or extract sensitive information directly from kernel memory.

Monitoring for the use of debugfs within privileged containers is a critical security control to prevent such potential exploits. By detecting unauthorized or unexpected use of this powerful tool, system administrators can take immediate action to investigate and remediate the situation, thus maintaining the integrity and security of their containerized environments.

8. Execution from /dev/shm

The Falco security rule “Execution from /dev/shm” is designed to detect executions that occur within the /dev/shm directory. This directory is typically used for shared memory and can be abused by threat actors to execute malicious files or scripts stored in memory, which can be a method to evade traditional file-based detection mechanisms.

Rule Details:

• Purpose: To monitor and alert on any executable activities within the /dev/shm directory. This directory allows for temporary storage with read, write, and execute permissions, making it a potential target for attackers to exploit by running executable files directly from this shared memory space.
• Detection Strategy: The rule identifies any process execution that starts from within the /dev/shm directory. This directory is often used by legitimate processes as well, so the rule may need tuning to minimize false positives in environments where such usage is expected.
• Workload Applicability: This rule is crucial for environments where stringent monitoring of executable actions is necessary, particularly in systems with high-security requirements or where the integrity of the execution environment is critical.

Example Scenario:

An attacker gains access to a system and places a malicious executable in the /dev/shm directory. They then execute this file, which could be a script or a binary, to perform malicious activities such as establishing a backdoor, exfiltrating data, or escalating privileges. Since files in /dev/shm can be executed in memory and may not leave traces on disk, this method is commonly used for evasion.

By detecting executions from /dev/shm, administrators can quickly respond to potential security breaches that utilize this technique, thereby mitigating risks associated with memory-resident malware and other fileless attack methodologies. This monitoring is a proactive measure to enhance the security posture of containerized and non-containerized environments alike.

9. Redirect STDOUT/STDIN to Network Connection in Container

The Falco security rule “Redirect STDOUT/STDIN to Network Connection in Container” is designed to detect instances where the standard output (STDOUT) or standard input (STDIN) of a process is redirected to a network connection within a container. This behavior is commonly associated with reverse shells or remote code execution, where an attacker redirects the output of a shell to a remote location to control a compromised container or host.

Rule Details:

• Purpose: To monitor and alert on the redirection of STDOUT or STDIN to network connections within containers, which can indicate that a container is being used to establish a reverse shell or execute remote commands—an indicator of a breach or malicious activity.
• Detection Strategy: This rule specifically detects the use of system calls like dup (and its variants) that are employed to redirect STDOUT or STDIN to network sockets. This activity is often a component of attacks that seek to control a process remotely.
• Workload Applicability: This rule is particularly important in environments where containers are not expected to initiate outbound connections or manipulate their output streams, which could be indicative of suspicious or unauthorized activities.

Example Scenario:

An attacker exploits a vulnerability within a web application running inside a container and gains shell access. They then execute a command that sets up a reverse shell using Bash, which involves redirecting the shell’s output to a network socket they control. This allows the attacker to execute arbitrary commands on the infected container remotely.

By monitoring for and detecting such redirections, system administrators can quickly identify and respond to potential security incidents that involve stealthy remote access methods. This rule helps to ensure that containers, which are often dynamically managed and scaled, do not become unwitting conduits for data exfiltration or further network penetration.

10. Fileless Execution via memfd_create

The Falco security rule “Fileless Execution via memfd_create” detects when a binary is executed directly from memory using the memfd_create system call. This method is a known defense evasion technique, enabling attackers to execute malware on a machine without storing any payload on disk, thus avoiding typical file-based detection mechanisms.

Rule Details:

• Purpose: To monitor and alert on the use of the memfd_create technique, which allows processes to create anonymous files in memory that are not linked to the filesystem. This capability can be used by attackers to run malicious code without leaving typical traces on the filesystem.
• Detection Strategy: This rule triggers when the memfd_create system call is used to execute code, which can be an indicator of an attempt to hide malicious activity. Since memfd_create can also be used for legitimate purposes, the rule may include mechanisms to whitelist known good processes.
• Workload Applicability: It is critical in environments where integrity and security of the execution environment are paramount, particularly in systems that handle sensitive data or are part of critical infrastructure.

Example Scenario:

An attacker exploits a vulnerability in a web application to gain execution privileges on a host. Instead of writing a malicious executable to disk, they use memfd_create to load and execute the binary directly from memory. This technique helps the attack evade detection from traditional antivirus solutions that monitor file systems for changes.

By detecting executions via memfd_create, system administrators can identify and mitigate these sophisticated attacks that would otherwise leave minimal traces. Implementing such monitoring is essential in high-security environments to catch advanced malware techniques involving fileless execution. This helps maintain the integrity and security of containerized and non-containerized environments alike.

11. Remove Bulk Data from Disk

The Falco security rule “Remove Bulk Data from Disk” is designed to detect activities where large quantities of data are being deleted from a disk, which might indicate an attempt to destroy evidence or interrupt system availability. This action is typically seen in scenarios where an attacker or malicious insider is trying to cover their tracks or during a ransomware attack where data is being wiped.

Rule Details:

• Purpose: To monitor for commands or processes that are deleting large amounts of data, which could be part of a data destruction strategy or a malicious attempt to impair the integrity or availability of data on a system.
• Detection Strategy: This rule identifies processes that initiate bulk data deletions, particularly those that might be used in a destructive context. The focus is on detecting commands like rm -rf, shred, or other utilities that are capable of wiping data.
• Workload Applicability: It is particularly important in environments where data integrity and availability are critical, and where unauthorized data deletion could have severe impacts on business operations or compliance requirements.

Example Scenario:

An attacker gains access to a database server and executes a command to delete logs and other files that could be used to trace their activities. Alternatively, in a ransomware attack, this type of command might be used to delete backups or other important data to leverage the encryption of systems for a ransom demand.

By detecting such bulk deletion activities, system administrators can be alerted to potential breaches or destructive actions in time to intervene and possibly prevent further damage. This rule helps in maintaining the security and operational integrity of environments where data persistence is a critical component.

By implementing these Falco rules, teams can significantly enhance the security posture of their Kubernetes deployments. These rules provide a foundational layer of security by monitoring and alerting on potential threats in real-time, thereby enabling organizations to respond swiftly to mitigate risks. As Kubernetes continues to evolve, so too will the strategies for securing it, making continuous monitoring and adaptation a critical component of any security strategy.