In a previous article, I covered the process for installing Falco in Kubernetes using Helm (Falco in Kubernetes with Alertmanager notifications).
Now that I have been running Falco for a few weeks, I have found a few recurring cases where I want to make some customisations/exceptions to the out of the box rules provided by Falco.
For example, on a daily bases — My Pihole deployment runs a few commands to print the current version / branch / commit of the running version.
It runs 3 commands in turn:
If this were from an internal application rather than a third party tool, it would be time to have a chat with the development team to understand why this tool can’t run as an ephemeral job rather than within the main deployment..
As this is a third party tool — We’ll create an exception so it will not notify for these particular commands being run from this deployment.
This does not indicate a security concern, so, to reduce alert fatigue (see an article I wrote here on writing good security alerts) — We should create an exception in the Falco rule so that it should not trigger this specific alert is criteria is met.
The first thing we’ll want to do is be specific with our exception rule, this will ensure that we aren’t excluding anything from generating an alert in Falco that could be generated by an actual security concern.
For example we wouldn’t want to just blanket exclude the entire rule (eg below) as this could indicate compromise or malicious activity, if generated on another pod in the cluster.
rule: Drop and execute new binary in container
So, first we’ll create some criteria to for all 3 of these commands being executed within this pod using the following:
rule = Drop and execute new binary in container
proc_exepath = /usr/bin/pihole-FTL
proc_cmdline = pihole-FTL version OR pihole-FTL branch OR…