can initially copy the files out of the container with this command, where a docker ps command has given you the hash ID of your container previously:
$ docker cp 1f7591607c7d:/etc/falco/falco_rules.yaml .
Simply repeat the previous command for these files:
falco_rules.local.yaml, falco.yaml, k8s_audit_rules.yaml
As you might imagine, you should place your own custom rules within the falco_rules.local.yaml file, which, barring comments, is mostly empty and not overwritten with version upgrades.
To load up changes, mount your volume as so with the additional -v $(pwd):/etc/falco/ option that mounts the /etc/falco directory from inside the container to your current working directory on your local machine:
$ docker run --rm -it --security-opt apparmor:unconfined \ --cap-add SYS_PTRACE \ --pid=host $(ls /dev/falco* | xargs -I {} echo --device {}) -v $(pwd):/etc/falco/ \ -v /var/run/docker.sock:/var/run/docker.sock \ falcosecurity/falco-no-driver:latest
The bundled rules are impressive and well worth a look. Listing 3.3 shows a Kubernetes example.
Listing 3.3: Unwanted Service Exposure via a NodePort Is Captured in Kubernetes
- rule: Unexpected K8s NodePort Connection desc: Detect attempts to use K8s NodePorts from a container condition: (inbound_outbound) and fd.sport>= 30000 and fd.sport <= 32767 and container and not nodeport_containers output: Unexpected K8s NodePort Connection (command=%proc.cmdline connection=%fd.name container_id=%container.id image=%container.image.repository) priority: NOTICE tags: [network, k8s, container, mitre_port_knocking]
It's not 100% clear, but the commercial, enterprise method used to update rules appears to be connecting to a back end. Rather than extracting the configuration and rules files from a running container, Falco also offers the ability to install rules in a different way. On Docker Hub (hub.docker.com/r/sysdig/falco_rules_installer), there is a container image created by Sysdig that will allow you to update rules via a running container. Its purpose is to first validate existing rules and then inspect any custom rules and deploy them to a suitable back end. The command would look like this, for example:
$ docker run --rm --name falco-rules-installer -it \ -e DEPLOY_HOSTNAME=https://my-sysdig-backend.com \ -e [email protected] \ -e DEPLOY_USER_PASSWORD=<my password> \ -e VALIDATE_RULES=yes -e DEPLOY_RULES=yes \ -e CREATE_NEW_POLICIES=no \ -e SDC_SSL_VERIFY=True sysdig/falco_rules_installer:latest
For our purposes, though, copying rules out of a running container makes sense. For the host-installed version, you can also pass the -c switch to point the daemon at a different configuration file. It is also quite possible to point, multiple times, at directories where your rules reside with the -r switch, too.
Macros
Falco also employs the concept of using macros. The example that their documentation offers for a simple macro is as follows:
- macro: in_container condition: container.id != host and proc.name = sh
This example could be reused across multiple rules without having to explicitly rewrite it each time and offer significant time-savings.
Lists
It is also possible to use lists so that collections of items can be grouped together more easily to make them more repeatable. The following is one example:
- list: common_binaries items: [netcat, iftop, ngrep]
Here, we can avoid explicitly writing all the binaries for Linux shells and instead just refer to a list of shell_binaries.
Getting Your Priorities Right
The following are categories for rule priorities:
EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL, DEBUG
These categories will allow you to sort alerts into a more meaningful set of results and allow the ability to react accordingly. As we saw in the other rules, within your rules, you would add a line such as this within the following example pseudocode stanza:
- rule: A custom rule desc: Rule description condition: container.privileged=true priority: WARNING
Tagging Rulesets
You can also group rules and alerts with tags to help with identifying issues more clearly. The tagging also offers the ability to explicitly run only certain rules with the relevant tags, for example. The previous example is shown expanded next to include tags. The -T switch disables rules with a certain tag, and the lowercase -t switch means that you will only run those rules with the tags listed after that switch.
- rule: A custom rule desc: Rule description condition: container.privileged=true priority: WARNING tags: [database, cis]
Outputting Alerts
In addition to the standard Unix-like syslog log forwarding, there are other ways to receive alerts from Falco. To use syslog, you can simply tweak your configuration this way:
syslog_output: enabled: true
But to use ChatOps alerts, via Slack, for example, Sysdig has created a repository in GitHub (github.com/falcosecurity/falcosidekick) to assist with just that.
The documentation describes the service that the code will provide as “a simple daemon for enhancing available outputs for Falco.” The list of compatible recipients is lengthy and includes most of the usual suspects, such as Slack, Datadog, AWS Lambda, Opsgenie, Rocketchat, and SMTP for email.
A nice touch is that you can even spawn it as another container; to do that, you would use syntax such as this:
$ docker run -d -p 2801:2801 -e SLACK_WEBHOOKURL=XXXXX \ falcosecurity/falcosidekick
Additionally, the documentation provides lots of pointers on how to tweak each of the webhook outputs to your needs and enjoy real-time messaging as you want in order to set off emergency pagers at 4 a.m. or just report innocuous events to a chat channel.
Summary
There is no doubt that Falco offers extensive security functionality for both container runtime and hosts. It also plays nicely with Kubernetes, and as of version v0.13.0 API Audit Events can be captured as an event source so that Falco can be rolled out across a cluster to offer genuine insight into what containers and hosts are getting up to in the quiet hours. Supported Kubernetes actions from Falco include the creation and deletion of resources (pods, deployments, daemon sets, and so on), changes to ConfigMaps and secrets, volume mounts, host networking, granting cluster-admin access, and using ConfigMaps for overly sensitive information.
Even the Open Source version of Falco is an impressive, battle-hardened piece of software. And, its commercial products have a notable enterprise client list using
