Falco - Technological watch

Introduction

Falco is an open-source tool designed to detect threats across any Linux system. It is particularly well-suited for implementation with Kubernetes.

Falco was incubated by the Linux Foundation and is driven by the community. Its creation is credited to the same minds behind Wire Shark, further establishing its credibility in the field.

Unlike tools that analyze images, Falco operates at runtime. This makes it an essential tool for those preparing for the Certified Kubernetes Security Specialist (CKS) exam.

Runtime security focuses on protecting processes (which could be within containers) during their execution. For instance, if a user executes the kubectl exec command in a production environment, Falco can detect it.

Falco works by capturing syscalls. Syscalls are essentially requests made by processes for services from the kernel. These services could include accessing the hard disk, network, RAM, or communicating with other processes. In this sense, the kernel acts as an orchestrator.

Falco is based on the Linux Kernel or on eBPF Probe.

Functionnalities

Rules

Falco rules are powerful and flexible, allowing you to define the conditions that trigger alerts. Here are some examples derived from the Falco documentation and rule examples:

- list: shell_binaries
    items: [bash, csh, ksh, sh, tcsh, zsh, dash]

- macro: shell_procs
    condition: proc.name in (shell_binaries)

- macro: container
  condition: container.id != host

- macro: spawned_process
  condition: evt.type in (execve, execveat) and evt.dir=<

- rule: shell_in_container
    desc: notice shell activity within a container
    condition: >
        spawned_process and
        container and
        shell_procs
    output: >
        A shell was spawned in a container
        (user=%user.name container_id=%container.id container_name=%container.name
        shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
    priority: WARNING

In this example, we first define a list of shell binaries and then create three macros (shell_procs, container, spawned_process). These macros are used in the shell_in_container rule to detect when a shell is used within a container. If the rule’s conditions are met, Falco will log the event.

You can find more default rules in the Falco documentation:

• https://falco.org/docs/rules/basic-elements/
• https://falco.org/docs/reference/rules/examples/

With Falco, you can trace everything happening on your system. For instance, if user “Alex” attaches to a running Pod, executes a shell, and then uses apt or apk to install curl and ping the Kubernetes API, Falco can detect and log these actions.

Falcosidekick

Falcosidekick is a simple yet powerful tool that complements Falco’s detection capabilities with its notification features.

While Falco is responsible for detecting threats, Falcosidekick takes on the role of notifying. It can send notifications through various channels, including chat platforms like Slack, Teams, or Discord. It also integrates with observability tools like Prometheus, alerting systems like Grafana, log tools like Elasticsearch, and even Function as a Service (FaaS) platforms like AWS Lambda.

You can get the full list here : https://github.com/falcosecurity/falcosidekick?tab=readme-ov-file#outputs

This combination of detection and notification allows for proactive response to events. For example, if someone executes a shell in a Pod, Falcosidekick can trigger an action to kill and restart the Pod. This immediate response can help mitigate potential threats and maintain the security of your system.

Falcosidekick UI

Falcosidekick UI is a user-friendly interface that provides real-time visibility into your cluster’s activities.

Whether you’re troubleshooting an issue or simply keeping an eye on your system’s performance, Falcosidekick UI makes it easy to stay informed in real time.

Falco plugins

With Falco, you can create plugins that can be plugged into any system or platform that generates events.

Here are some examples of how you can use Falco plugins:

• GitHub Webhooks: GitHub sends webhooks for various events happening on your repositories. You can create a Falco plugin to listen to these webhooks.
• Amazon EKS Events: Amazon EKS generates events related to the state and health of your Kubernetes clusters.
• Kubernetes Events: Kubernetes itself generates a multitude of events related to the state of the pods, nodes, and other resources. Falco can tap into this event stream for real-time threat detection and response.
• Docker Events: Docker generates events related to the lifecycle of containers.
• Twitter (X) Events: Even platforms like Twitter, which generate events related to social media interactions, can be monitored using Falco.

Test Falco

Installation

Links:

• https://falco.org/docs/getting-started/falco-kubernetes-quickstart/
• https://falco.org/docs/install-operate/installation/
• https://falco.org/docs/install-operate/deployment/
• https://falco.org/blog/rules-helm-chart-3-0-0/
• https://www.storagefreak.net/2023/02/how-to-set-up-falco-on-kubernetes-a-guide-to-improving-your-container-security

Let’s install Falco with Helm:

# Add falcosecurity repository
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Install the chart
helm install falco falcosecurity/falco --namespace falco --create-namespace

# Install the chart with custom rules
# helm install falco -f custom-rules.yaml falcosecurity/falco --namespace falco --create-namespace

# You can add some variables
# --set tty=true
# --set falcosidekick.enabled=true
# --set falcosidekick.config.webhook.address=http://falco-talon:2803

# Install with adjusted settings
# helm install falco -f custom-rules.yaml --set ebpf.enabled=true,outputs.rate=.03333,outputs.maxRate=10 falcosecurity/falco --namespace falco

# Verify the installation
kubectl get pods -n falco -o wide

Custom rules should be written like this:

customRules:
  custom-rules.yaml: |-
    - rule: shell_in_container
      desc: notice shell activity within a container
      condition: evt.type = execve and evt.dir = < and container.id != host and (proc.name = bash or proc.name = ksh)
      output: shell in a container (user=%user.name container_id=%container.id container_name=%container.name shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
      priority: WARNING

You can see the rules with:

kubectl -n falco get configmap falco-rules -o yaml

kubectl -n falco edit daemonsets.apps falco

[...]
    spec:
      containers:
      - args:
        [...]
        name: falco
        tty: true
        [...]

Let’s simulate suspicious activity

Link:

• https://falco.org/docs/getting-started/falco-kubernetes-quickstart/#simulate-suspicious-activity

Let’s create a pod and run a command in it.

kubectl run alpine --image alpine -- sh -c "sleep infinity"

kubectl exec -it alpine -- sh -c "uptime" # <- we don't want to allow "exec -it" in a pod on a production cluster

Let’s see if Falco logged anything:

kubectl -n falco logs -l app.kubernetes.io/name=falco -c falco | grep Notice

# 13:34:21.628632597: Notice A shell was spawned in a container with an attached terminal (evt_type=execve user=root user_uid=0 user_loginuid=-1 process=sh proc_exepath=/bin/busybox parent=containerd-shim command=sh -c uptime terminal=34816 exe_flags=EXE_WRITABLE container_id=3e20e5a33809 container_image=<NA> container_image_tag=<NA> container_name=<NA> k8s_ns=<NA> k8s_pod_name=<NA>)

Conclusion

In conclusion, Falco, along with its companions Falcosidekick and Falcosidekick UI, provides a comprehensive and robust solution for runtime security. Its ability to detect threats at runtime, coupled with the flexibility of creating plugins for virtually any event-generating platform, makes it a powerful tool in the arsenal of any system administrator or DevOps professional.

Falco can help ensure the security and integrity of your systems. Its open-source nature and active community support further enhance its appeal, making it a go-to choice for runtime security.

Thank you for reading my post, happy clustering! 😊🚀