Falco v0.37 releases: Behavioral Activity Monitoring With Container Support

Falco

Falco is a behavioral activity monitor designed to detect anomalous activity in your applications. Powered by sysdig’s system call capture infrastructure, Falco lets you continuously monitor and detect container, application, host, and network activity… all in one place, from one source of data, with one set of rules.

Falco is hosted by the Cloud Native Computing Foundation (CNCF) as a sandbox level project. If you are an organization that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and micro services-oriented, consider joining the CNCF. For details read the Falco CNCF project proposal.

What kind of behaviors can Falco detect?

Falco can detect and alert on any behavior that involves making Linux system calls. Thanks to Sysdig’s core decoding and state tracking functionality, Falco alerts can be triggered by the use of specific system calls, their arguments, and by properties of the calling process. For example, you can easily detect things like:

• 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 (ls) makes an outbound network connection

How you use it

Falco is deployed as a long-running daemon. You can install it as a Debian/rpm package on a regular host or container host, or you can deploy it as a container.

Falco is configured via a rules file defining the behaviors and events to watch for, and a general configuration file. Rules are expressed in a high-level, human-readable language. We’ve provided a sample rule file ./rules/falco_rules.yaml as a starting point – you can (and will likely want!) to adapt it to your environment.

When developing rules, one helpful feature is Falco’s ability to read trace files saved by sysdig. This allows you to “record” the offending behavior once, and replay it with Falco as many times as needed while tweaking your rules.

Once deployed, Falco uses the Sysdig kernel module and userspace libraries to watch for any events matching one of the conditions defined in the rule file. If a matching event occurs, a notification is written to the configured output(s).

Falco Alerts

When Falco detects suspicious behavior, it sends alerts via one or more of the following channels:

• Writing to standard error
• Writing to a file
• Writing to syslog
• Pipe to a spawned program. A common use of this output type would be to send an email for every Falco notification.

More details on these alerts are described [here](Falco Alerts).

Changelog v0.37

Breaking Changes ⚠️

• new!: dropped falco-driver-loader script in favor of new falcoctl driver command [#2905] – @FedeDP
• update!: bump libs to latest and deprecation of k8s metadata options and configs [#2914] – @jasondellaluce
• cleanup(falco)!: remove outputs.rate and outputs.max_burst from Falco config [#2841] – @Andreagit97
• cleanup(falco)!: remove --userspace support [#2839] – @Andreagit97

Major Changes

• new(engine): add selective overrides for Falco rules [#2981] – @LucaGuerra
• feat(userspace/falco): falco administrators can now configure the http output to compress the data sent as well as enable keep alive for the connection. Two new fields (compress_uploads and keep_alive) in the http_output block of the falco.yaml file can be used for that purpose. Both are disabled by default. [#2974] – @sgaist
• new(userspace): support env variable expansion in all yaml, even inside strings. [#2918] – @FedeDP
• new(scripts): add a way to enforce driver kind and falcoctl enablement when installing Falco from packages and dialog is not present. [#2773] – @vjjmiras
• new(falco): print system info when Falco starts [#2927] – @Andreagit97
• new: driver selection in falco.yaml [#2413] – @therealbobo
• new(build): enable compilation on win32 and macOS. [#2889] – @therealbobo
• feat(userspace/falco): falco administrators can now configure the address on which the webserver listen using the new listen_address field in the webserver block of the falco.yaml file. [#2890] – @sgaist

Minor Changes

• update(userspace/falco): add engine_version_semver key in /versions endpoint [#2899] – @loresuso
• update: default ruleset upgrade to version 3.0 [#3034] – @leogr
• update!(config): soft deprecation of drop stats counters in syscall_event_drops [#3015] – @incertum
• update(cmake): bumped falcoctl tool to v0.7.1. [#3030] – @FedeDP
• update(rule_loader): deprecate the append flag in Falco rules [#2992] – @Andreagit97
• cleanup!(cmake): drop bundled plugins in Falco [#2997] – @FedeDP
• update(config): clarify deprecation notices + list all env vars [#2988] – @incertum
• update: now the watch_config_files config option monitors file/directory moving and deletion, too [#2965] – @NitroCao
• update(userspace): enhancements in rule description feature [#2934] – @jasondellaluce
• update(userspace/falco): add libsinsp state metrics option [#2883] – @incertum
• update(doc): Add Thought Machine as adopters [#2919] – @RichardoC
• update(docs): add Wireshark/Logray as adopter [#2867] – @geraldcombs
• update: engine_version in semver representation [#2838] – @loresuso
• update(userspace/engine): modularize rule compiler, fix and enrich rule descriptions [#2817] – @jasondellaluce

Bug Fixes

• fix(userspace/metric): minor fixes in new libsinsp state metrics handling [#3033] – @incertum
• fix(userspace/engine): avoid storing escaped strings in engine defs [#3028] – @jasondellaluce
• fix(userspace/engine): cache latest rules compilation output [#2900] – @jasondellaluce
• fix(userspace/engine): solve description of macro-only rules [#2898] – @jasondellaluce
• fix(userspace/engine): fix memory leak [#2877] – @therealbobo

Install & Tutorial

Copyright (C) mstemm