Understand Falco's Default Rules and What They Detect (2026)

Falco’s default rules aren’t just a static list; they’re a dynamic, evolving security guard for your Kubernetes cluster, designed to catch the most common and dangerous deviations from normal behavior.

Let’s see Falco in action. Imagine we have a simple deployment running an Nginx web server.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Now, let’s say a malicious actor gains access to one of these pods and tries to execute a shell inside it. This is a classic "breakout" attempt. Falco, with its default rules, is listening for exactly this kind of activity.

Here’s a rule from Falco’s default ruleset that would trigger on this:

- rule: Execute shell in container
  desc: "A shell was executed in a container. This is often a sign of an attacker trying to gain interactive access."
  condition: >
    (container and proc.name = "sh" or proc.name = "bash" or proc.name = "ash")
    and container.id != host.id
  output: "Shell executed in container (user=%user.name, user_uid=%user.uid, image=%container.image, name=%container.name, cmdline=%proc.cmdline)"
  priority: medium
  tags: [container, shell, mitre.execution]

When the sh process starts within the nginx container, Falco’s auditd or syscall monitoring backend captures this event. The condition checks if a process named sh, bash, or ash is running (proc.name = "sh" or proc.name = "bash" or proc.name = "ash") and crucially, if it’s inside a container (container). The container.id != host.id part is a bit of a sanity check to ensure we’re not just seeing a shell on the host itself. The output then formats a human-readable message with details like the user, container image, and the exact command line used.

Falco’s default rules cover a surprisingly broad spectrum of threats, from simple file access anomalies to complex network intrusions. They are categorized by priority and often tagged with MITRE ATT&CK techniques, making them incredibly useful for both immediate threat detection and for building a more robust security posture.

Here are some other common categories of default rules:

• File Access Anomalies: Rules like "Write to sensitive directory" (write_to_sensitive_dir) or "Read sensitive file" (read_sensitive_file) monitor access to critical system files or directories that shouldn’t be touched by containers. For example, a rule might alert if a process in a container attempts to write to /etc/passwd.
• Privilege Escalation: Rules like "Run container as privileged" (run_container_as_privileged) or "Container escape via sensitive mount" (container_escape_via_sensitive_mount) aim to catch attempts to gain elevated privileges or break out of the container’s isolation.
• Network Anomalies: Rules like "Connect to suspicious port" (connect_to_suspicious_port) or "Listen on unexpected port" (listen_on_unexpected_port) can flag unusual network activity.
• Kernel Module Loading: Rules like "Load kernel module" (load_kernel_module) are critical because loading kernel modules is a powerful way to gain deep system access and is highly unusual for containerized applications.

The real power of Falco’s defaults lies in their adaptability. While these rules are comprehensive, they are also designed to be extended and customized. You can easily add your own rules or modify existing ones to fit the specific needs and risk profile of your environment. For instance, if you have a specific directory that should never be written to by any container, you can create a rule that specifically targets that path.

The most surprising thing about Falco’s default rules is how much they rely on the Linux Audit subsystem (or equivalent kernel event mechanisms). Falco isn’t just pattern matching on logs; it’s often directly observing syscalls made by processes. This low-level visibility is what allows it to detect subtle but critical security events that might otherwise go unnoticed.

The next step is understanding how to fine-tune these rules to reduce noise and ensure you’re alerted to what truly matters in your specific environment.