Protect your Docker containers using Falco security rules.

By Mateo Burillo - JUNE 4, 2018

SHARE:

Sysdig Falco Kubernetes Logos

Falco is an open source project for intrusion and abnormality detection for Cloud Native platforms such as Kubernetes or Docker. Using Falco you can create a Docker security policy to detect attacks and anomalous activity on production environments, in real-time, so you can react to unknown and 0-day vulnerabilities, attacks caused by weak or leaked credentials or compliance breaches.

Falco has its own security policy rules syntax, based on Sysdig filtering language which is very similar to tcpdump syntax, self-descriptive and fast to learn. In addition, it is really easy to install Falco in any container orchestration platform. If you are looking for a commercial product instead, check out Sysdig Secure, built on top of Sysdig open-source technology. Looking at implementing #Kubernetes #Docker container #security and you don’t know where to start? With the new @sysdig #falco default ruleset is easier than ever! Click to tweet

Implementing runtime security policies requires to know exactly how your containers and applications behave. Since most of us build our Cloud Native applications using open-source components, we wanted to help you in this process providing base security profiles for a growing list of the most popular container images, through a GitHub repository: falco-extras, including:

  • Kubernetes 1.10 cluster components:
    • apiserver
    • controller-manager
    • kube-dns
    • kube-scheduler
    • dashboard
  • Google Kubernetes Engine components
  • Apache
  • Consul
  • ElasticSearch
  • etcd
  • Fluentd
  • HAproxy
  • MongoDB
  • Nginx
  • PHP-FPM
  • PostgreSQL
  • Redis
  • Traefik

Previously, we did cover how to setup a few security policy examples with Sysdig Secure, now we will see how to do this with open-source.

What can you find in a Falco security policy?

We already showed how to implement Kubernetes security and harden/secure your Kubernetes kube-system namespace, now we will see how to expand this to the rest of your Dockerized applications.

For each of your container images, you can create a whitelisting policy for:

  • Which processes / commands are allowed to run inside the Docker container
  • Processes that can start an outbound connection or accept an inbound connection
    • Including allowed listening ports or remote ports
  • Files and directories that can be read
    • By which processes
  • Files and directories that can be written
    • By which processes
  • Even the set of Linux system calls that your container processes are expected to use!

Basically, we are creating a tightly constrained execution environment. Anything else, any unexpected behavior will raise an alarm.

For example, this is the default Falco policy for a Nginx container:


File: FalcoNginxRuleset.yaml
----------------------------

- macro: nginx_consider_syscalls
  condition: (evt.num < 0)

- macro: app_nginx
  condition: container and container.image contains "nginx"

# Any outbound traffic raises a WARNING

- rule: Unauthorized process opened an outbound connection (nginx)
  desc: A nginx process tried to open an outbound connection and is not whitelisted
  condition: outbound and evt.rawres >= 0 and app_nginx
  output: Non-whitelisted process opened an outbound connection (command=%proc.cmdline
    connection=%fd.name)
  priority: WARNING


# Restricting listening ports to selected set

- list: nginx_allowed_inbound_ports_tcp
  items: [80, 443, 8080, 8443]

- rule: Unexpected inbound tcp connection nginx
  desc: Detect inbound traffic to nginx using tcp on a port outside of expected set
  condition: inbound and evt.rawres >= 0 and not fd.sport in (nginx_allowed_inbound_ports_tcp) and app_nginx
  output: Inbound network connection to nginx on unexpected port (command=%proc.cmdline pid=%proc.pid connection=%fd.name sport=%fd.sport user=%user.name %container.info image=%container.image)
  priority: NOTICE

# Restricting spawned processes to selected set

- list: nginx_allowed_processes
  items: ["nginx", "app-entrypoint.", "basename", "dirname", "grep", "nami", "node", "tini"]

- rule: Unexpected spawned process nginx
  desc: Detect a process started in a nginx container outside of an expected set
  condition: spawned_process and not proc.name in (nginx_allowed_processes) and app_nginx
  output: Unexpected process spawned in nginx container (command=%proc.cmdline pid=%proc.pid user=%user.name %container.info image=%container.image)
  priority: NOTICE

# Restricting files read or written to specific set

- list: nginx_allowed_file_prefixes_readwrite
  items: ["/var/log/nginx", "/var/run"]
# Remember to add your nginx cache path

- rule: Unexpected file access readwrite for nginx
  desc: Detect an attempt to access a file readwrite other than below an expected list of directories
  condition: (open_write) and not fd.name pmatch (nginx_allowed_file_prefixes_readwrite) and app_nginx
  output: Unexpected file accessed readwrite for nginx (command=%proc.cmdline pid=%proc.pid file=%fd.name %container.info image=%container.image)
  priority: NOTICE

# Restricting syscalls to selected set

- list: nginx_allowed_syscalls
  items: [accept, bind, clone, connect, dup, listen, mkdir, open, recvfrom, recvmsg, sendto, setgid, setuid, socket, socketpair]

- rule: Unexpected syscall nginx
  desc: Detect a syscall in a nginx container outside of an expected set
  condition: nginx_consider_syscalls and not evt.type in ("<unknown>", nginx_allowed_syscalls) and app_nginx
  output: Unexpected syscall in nginx container (command=%proc.cmdline pid=%proc.pid user=%user.name syscall=%evt.type args=%evt.args %container.info image=%container.image)
  priority: NOTICE
  warn_evttypes: False

</unknown>Code language: Perl (perl)

And of course, that’s on top of many other suspicious behaviors that Falco will detect by default:

  • A shell is run inside a container
  • A container is running in privileged mode or is mounting a sensitive path like /proc from the host
  • A server process spawns a child process of an unexpected type
  • Unexpected read of a sensitive file (like /etc/shadow)
  • A non-device file is written to /dev
  • A standard system binary (like ls) makes an outbound network connection
  • And many more policy examples

Customize these rules to create your own Falco security profiles and policies

Using these default Falco security rulesets will hopefully save you a lot of time writing boilerplate. However, bear in mind that every version of a Docker container image, even for the same microservice, it’s probably going to have some differences: user-defined data directories, different binary paths, scripts that need to access some external port or device, etc.

Thus, you will need to adapt the templates to your specifics before actually using them.

How to apply a Falco security policy to specific container images

In this generic rule we just used we targeted any container image which name contains “nginx”:

- macro: app_nginx
  condition: container and container.image contains "nginx"
Code language: Perl (perl)

But you can be much more specific, using the unique hash code of the image you are deploying:

- macro: app_nginx
  condition: container and container.image contains "73acd1f0cfadf6f56d30351ac633056a4fb50d455fd95b229f564ff0a7adecda" Falco can also leverage metadata from Kubernetes, allowing you to create more accurate and context-specific rulesets that make use of 
Code language: Perl (perl)

Pod, Deployment name or Namespace name. You have some example rules of Falco using Kubernetes metadata in Detecting Cryptojacking with Sysdig’s Falco:

- macro: node_app_frontend
  condition: k8s.ns.name = node-app and k8s.pod.label.role = frontend and k8s.pod.label.app = node-app

- rule: Detect crypto miners using the Stratum protocol
  desc: Miners typically specify the mining pool to connect to with a URI that begins with 'stratum+tcp'
  condition: node_app_frontend and spawned_process and container.id != host and proc.cmdline contains stratum+tcp
  output: Possible miner ran inside a container (command=%proc.cmdline %container.info)
  priority: WARNING
Code language: Perl (perl)

Detect not allowed or forbidden Docker container images

Additionally, you can create your own image whitelist, to make sure no unknown or not allowed container image is ever run on your hosts / cluster:

- list: container_image_whitelist
  items: ["sha256:8ac48589692a53a9b8c2d1ceaa6b402665aa7fe667ba51ccc03002300856d8c7", "sha256:f3fcd0775c4e15d4b73d2b62f60efb1872bf4d3328be52a0fc9a2b0951bbcc1e"]

- rule: Unknown container image running
  desc: There is a container running that doesn't match any of the whitelisted sha256 codes
  condition: container and not container.image in (container_image_whitelist)
  output: Unknown container (command=%proc.cmdline pid=%proc.pid file=%fd.name %container.info image=%container.image)
  priority: WARNING
Code language: Perl (perl)

Fine tune your security policy: Sysdig + Sysdig Inspect (also forensics and post-mortem analysis!)

If you want a fine-grained inspection tool coupled together with a nice GUI, without leaving FOSS territory, you can always use sysdig together with Sysdig Inspect.

For example, if you want to record a live capture of every activity that mynginx _container is registering, just run:

# sysdig -pc -s 4096 container.name=mynginx -w nginxcap.scap
Code language: Perl (perl)

After a few seconds, you can directly open the capture file on your laptop using Sysdig Inspect to browse the container activity and figure out if there is any additional constraints you can add to your Falco security profile.

Docker Falco Security Sysdig Inspect Dashboard

From here, I can easily browse the processes that the container was running:

Docker Falco Security Sysdig Inspect Process

Or its network connections:

Docker Falco Security Sysdig Inspect Network

And much more! File system activity, system calls… everything really! That’s why Sysdig Inspect is often used for troubleshooting (How to troubleshoot a Kubernetes CrashLoopBackOff) or forensics too.

Help us build the Falco security library!

We would love to hear about your experience deploying Falco rules for Docker and Kubernetes. Are you using Falco already? Or wondering how it compares with seccomp or SELinux/AppArmor? If you have created a set of profiles and are proud of them why not contributing back? Fork and send us Pull Requests to falco-extras!. Cannot use Falco because you are missing a specific feature or maybe you hit a bug? We also want to know! Find us on Sysdig Slack, #falco channel.

Subscribe and get the latest updates