Day 3- Introduction to Falco


In the simplest definition, Falco is the tool to detect events which is suspicious in your environment.

The complex definition is that Falco is a behavioral activity monitor that detects any suspicious activity defined by a set of rules using Sysdig powerful and flexible filtering expression. It supports container and orchestrator and has a flexible notification method using standard output, Syslog, and programs like Slack. On top of that, it’s open-source, so any can contribute.

How Falco works

Once installed, it taps into the stream of system call events. To detect which event is considered an anomaly, Falco uses rules. Falco already has several rules implemented by default, and these rules are defined inside the file(/etc/falco/falco_rules.yaml). Once it detects the event, it sends out the appropriate message.

Falco Ruleset

Falco provides a powerful ruleset that triggers alerts when a certain condition is met. Some of the examples are:

  • If someone is trying to shell inside the container(as shown in the below example)
  • Someone is trying to open the secure file like /etc/shadow

As Falco already provides this powerful ruleset but new rules and macros are easy to create.

Installing Falco in Ubuntu

  • Configure the repository, and update the packages
curl -s | apt-key add -
echo "deb stable main" | tee -a /etc/apt/sources.list.d/falcosecurity.list
apt-get update -y
  • Install kernel headers package
apt-get -y install linux-headers-$(uname -r)
  • Install falco now
apt-get install -y falco
  • Start the falco service and enable it on boot
systemctl daemon-reload
systemctl start falco --now
$ kubectl run nginx --image=nginx
pod/nginx created
  • Verify in which node it’s running
$ kubectl get pod -o wide
nginx 1/1 Running 0 7s worker2 <none> <none>
  • Login to that node and run. This will allow us to inspect the events generated by the Falco service(Make sure you have falco installed on all worker nodes by following the above method).
journalctl -fu falco
  • Now try to login to the pod you have created
kubectl exec -it nginx -- bash
  • In the journalctl output, you will immediately see the alert that a shell is spawned inside the container.
journalctl -fu falcoOct 26 03:55:58 worker2 falco[31975]: 03:55:58.929949778: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 nginx (id=20e01b3e2c42) shell=bash parent=runc cmdline=bash terminal=34816 container_id=20e01b3e2c42
Oct 26 03:55:58 worker2 falco[31975]: 03:55:58.929949778: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 nginx (id=20e01b3e2c42) shell=bash parent=runc cmdline=bash terminal=34816 container_id=20e01b3e2c42
  • As per the above output, Falco knows that someone has spawned the shell inside the container. Now the question is, how do Falco know about it? Using rules file as discussed above(How Falco works?). Rules for “ A shell spawned inside the container” look like below.
- rule: Terminal shell in container
desc: A shell was used as the entrypoint/exec point into a container with an attached terminal.
condition: >
spawned_process and container
shell_procs and proc.tty != 0
and container_entrypoint
and not user_expected_terminal_shell_in_container_conditions
output: >
A shell was spawned in a container with an attached terminal ( user_loginuid=%user.loginuid parent=%proc.pname cmdline=%proc.cmdline terminal=%proc.tty image=%container.image.repository)
priority: NOTICE
  • As you can the entire file is divided into 5 main section
* rule: Here you need to define the name of the rule
* desc: Description of the rule
* condition: This is the most important field and it matches the filter based on the events matching the rule. To match these condition you need to use sysdig filters. The falco policy engine make use of these filters to extract information about an event such as current container ID or process name etc. For more information check this link
* output: Output to be generated for the event. Output also relying on filters to log the events.
* priority: what is the severity of the event(other supported fields is DEBUG, ERROR, EMERGENCY, CRITICAL etc)
  • Let’s look at some more use cases of Falco by performing a few more activities inside the Nginx pod. Let open /etc/shadow file
cat /etc/shadow
  • Verify the Falco logs. As you can see, Falco saw this as suspicious activity and immediately notified us.
Oct 28 14:26:56 controlplane falco[17210]: 14:26:56.529909999: Warning Sensitive file opened for reading by non-trusted program (user=root user_loginuid=-1 program=cat command=cat /etc/shadow file=/etc/shadow parent=bash gparent=<NA> ggparent=<NA> gggparent=<NA> container_id=e353fc6c92db image=nginx)
  • Let’s explore one more use case. As this is a Debian-based host, let’s upgrade the package using the below command.
# apt update
  • Verify the logs to see, again Falco see this as a suspicious activity
Oct 28 14:31:55 controlplane falco[17210]: 14:31:55.549740450: Error Package management process launched in container (user=root user_loginuid=-1 command=apt update container_id=e353fc6c92db container_name=k8s_nginx_nginx_default_8e9bd36b-e4ee-4805-b1bf-bfd6d3a02c51_0 image=nginx:latest)For both cases, you can check the /etc/falco/falco_rules.yaml and check the corresponding rule which triggers the alert.
  • Opening Sensitive Files
- rule: Read sensitive file trusted after startup
desc: >
an attempt to read any sensitive file (e.g. files containing user/password/authentication
information) by a trusted program after startup. Trusted programs might read these files
at startup to load initial state, but not afterwards.
condition: sensitive_files and open_read and server_procs and not proc_is_new and!="sshd" and not user_known_read_sensitive_files_activities
output: >
Sensitive file opened for reading by trusted program after startup ( user_loginuid=%user.loginuid
command=%proc.cmdline parent=%proc.pname parent=%proc.pname gparent=%proc.aname[2] image=%container.image.repository)
priority: WARNING
tags: [filesystem, mitre_credential_access]
  • Updating Packages
- rule: Launch Package Management Process in Container
desc: Package management process ran inside container
condition: >
and container
and != "_apt"
and package_mgmt_procs
and not package_mgmt_ancestor_procs
and not user_known_package_manager_in_container
output: >
Package management process launched in container ( user_loginuid=%user.loginuid
command=%proc.cmdline image=%container.image.repository:%container.image.tag)
priority: ERROR
tags: [process, mitre_persistence]


As you can see, using Falco, you can gain complete visibility of your container and application behavior. It’s easy to install and open-source.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Prashant Lakhera

Prashant Lakhera

AWS Community Builder, Ex-Redhat, Author, Blogger, YouTuber, RHCA, RHCDS, RHCE, Docker Certified,4XAWS, CCNA, MCP, Certified Jenkins, Terraform Certified, 1XGCP