Falco for Runtime IDS

The ability to enable and drive creative thought through technical exploration will always be exciting to me in practice. This post is no different and covers how the Falco ecosystem provides a quick and flexible solution of substance for IDS and threat detection purposes. At the time of this writing, Falco can provide coverage in a variety of ways, from Google Kubernetes Engine (GKE) to hosting installs using a deb package or tarball.  I'm running a Portainer CE to host and deploy container stacks for testing and demo purposes. Below is a current docker compose config which includes two containers, the Falco application and the associated event forwarder known as Falcosidekick.

version: '3.8'

services:
  falco:
    image: falcosecurity/falco-no-driver:latest
    container_name: falco
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/falco/falco.yaml:/etc/falco/falco.yaml
      - /usr/src:/usr/src
      - /lib/modules:/lib/modules
      - /:/host:ro  # Mount host root filesystem as read-only
    privileged: true
    network_mode: host
    pid: host
    environment:
      - FALCO_GRPC_OUTPUT_ENABLED=true
      - FALCO_MODERN_BPF=true
      - FALCO_LOG_LEVEL=info


  falcosidekick:
    image: falcosecurity/falcosidekick:latest
    container_name: falcosidekick
    restart: always
    depends_on:
      - falco
    ports:
      - "2801:2801"
    volumes:
      - /etc/falco/falcosidekick.yaml:/etc/falco/falcosidekick.yaml
    command: "-c /etc/falco/falcosidekick.yaml"

There are two config files running this entire operation to be aware of:

/etc/falco/falco.yaml
/etc/falco/falcosidekick.yaml

You'll need to create these two files and map them on your docker host machine under the directories referenced. Sample configurations for each can be found within the official repos here:

falco.yaml
falcosidekick.yaml

While the default falco config works for this demonstration, falcosidekick needs to include your chosen system and a few unique values to properly function. For testing purposes, I chose a Discord webhook. Two alert examples are shown for reference below. In the top example, I was able to trigger an alert using the Portainer UI which is often used to open a shell on an active running container for troubleshooting purposes. This will also trigger for any containers actively running on your portainer host and isn't limited to just the running falco container itself. The bottom example was triggered from an ssh session directly on my homelab hardware host.

So there you have it. An efficient way to monitor and alert on suspicious activity not only for your containers, but any Linux based system. As some point, I plan on releasing a follow up post which covers detection rules and custom exceptions. One last thing to keep in mind is that you can leverage Falco plugins to cover a variety of unique use cases. From Kubernetes audit logs in AWS EKS to CloudTrail JSON data, the possibilities are extensive. Special thanks to The Linux Foundation, CNCF, Falco project maintainers and Sysdig for their ongoing dedication to open source technology.