Читать книгу Cloud Native Security - Chris Binnie - Страница 32

If you run the Docker command to check the help output, you are offered a number of useful choices to remember, as shown here:

$ docker run -it falcosecurity/falco-no-driver:latest falco --help

And you can list all the rules currently loaded up into Falco with this syntax:

$ docker run -it falcosecurity/falco-no-driver:latest falco -L

The output includes the rule name along with a description such as this example:

Rule Description ---- ----------- Create Symlink Over Sensitive Files Detect symlink over sensitive files

Although there are certainly more graceful ways of editing rules and configuration for Falco (which we will look at in a moment), if you use the container approach to run Falco, it is possible to extract the rules file that you want to change and save it to the local machine. Then you can simply mount the local machine volume when Falco fires up, and your changing configuration and rules will be loaded up.

You 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 DEPLOY_USER_NAME=test@sysdig.com \ -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.