RSS

Falco 0.31.0 a.k.a. "the Gyrfalcon"

Today we announce the release of Falco 0.31.0, a.k.a the Gyrfalcon ๐Ÿฆ…!

Gyrfalcons are the largest of the falcon species, just like this version of Falco has the biggest changelog ever released. To give you some metrics, since the last release, the falco and libs repositories counted 30+ individual contributors, 130+ pull requests, and 360+ commits ๐Ÿคฏ. The Falco community proved to be more active than ever, and we wanted to say a huge THANK YOU ๐Ÿ™ ๐Ÿ’– to everyone involved.

The highlights

The changes are too many to list them all, so we'll just try to cover the highlights of the core features and topics. In case you want to go deep, here's the full Falco's changelog and the list of changes in libs.

Plugin system

Falco 0.31.0 finally ships with the brand new plugin system ๐ŸŽ‰ ! Many things have changed since the initial proposal, and the feature is finally stable and production-ready.

Falco historically monitored system events from the kernel trying to detect malicious behavior on Linux nodes. In time, it got upgraded to also process K8S Audit Logs to detect suspicious activity in K8S clusters too. Now, the next step in the evolution of Falco is a plugin framework that standardizes how additional event sources can be attached to the engine and how more information can be extracted from those events.

Plugins can be written in almost any language of your preference. If you want to know more about how this works, take a look at the official documentation ๐Ÿ“–. More or less, this is what the architecture of Falco looks like right now.

New architecture of Falco

To do the honors, this release of Falco comes with the AWS Cloudtrail plugin and a new ad-hoc ruleset already packaged-in ๐Ÿ“ฆ ! With these, Falco receives Cloudtrail logs from your infrastructure and sends alerts when suspicious activity happens, such as when the permissions of an S3 bucket are changed unexpectedly or when someone logs in without MFA. This is a great start to better integrating Falco into your infrastructure, and we expect more extensions like this to come!

Of course, you may wonder how hard it is to develop a Falco extension for your use cases. No worries, because the development experience was one of our top priorities, and we prepared two SDKs for writing Falco plugins in Go and C++:

The SDKs are lightweight and allow you to develop Falco plugins with few lines of code! We put special attention to the Go SDK since Go is a well-appreciated language in the cloud-native community. Check out some examples and get started in a few minutes โŒš!

The Falco Community also maintains an official registry ๐Ÿ“’ that keeps track of all the plugins acknowledged and recognized across the community. This serves both to make the plugin ecosystem more accessible to the community and for technical details such as reserving a specific plugin ID.

We expect plugins to be a game-changer, with the potential of making Falco evolve to the next level and become an all-in-one tool for cloud runtime security.

Drivers and libs improvements

Relevant performance optimization has been introduced in the drivers to drop all the non-monitored events right at the kernel level, which reduces ring buffer contention and decreases the drop rate ๐Ÿ‘‰ libs#115.

The drivers added support to some new security-critical syscalls: openat2, execveat, mprotect! Also, the is_exe_writable flag was added to the execve syscalls family.

The eBPF probe received many improvements regarding stability and support for some compiler and kernel versions (e.g., with clang5, amznlinux2) ๐Ÿ‘‰ libs#109, libs#140, libs#126, libs#96, libs#81, libs#179, libs#185.

Issues arising when processing huge container metadata have been solved by introducing a new LARGE block type, which dramatically increases the maximum block size supported ๐Ÿ‘‰ libs#102.

Finally, a lot of effort has been put into upgrading critical dependencies and supporting more architectures and platforms ๐Ÿ‘‰ libs#91, libs#164.

Other Falco novelties

Plugins apart, Falco received a few other significant updates:

  • Ability to set User-Agent HTTP header when sending HTTP output ๐Ÿ‘‰ falco#1850.
  • Support to arbitrary-depth nested values in YAML configuration ๐Ÿ‘‰ falco#1792.
  • Lua files used to load/compile rules are now bundled into the Falco executable ๐Ÿ‘‰ falco#1843.
  • Linux packages are now signed with SHA256 ๐Ÿ‘‰ falco#1758.
  • Some fixes in the rule parser of the Falco engine ๐Ÿ‘‰ falco#1777, falco#1775.
  • Finally, we moved the fully statically-linked build of Falco to another package, and the usual binary package switched back to a regular build (that was needed to allow plugins to be dynamically loaded). You can find both package flavors in our download repository.

Rule updates

The default ruleset ๐Ÿ›ก๏ธ includes few relevant new rules ๐Ÿ‘‡

Existing rules, macros, and lists received some updates too, in particular with regards to possible bypasses ๐Ÿ‘‡

What's next?

Many efforts are already ongoing to improve Falco's quality and stability. Two important proposals for libs (versioning and release process and API versioning for user/kernel boundary) are in the making. Meanwhile, the community is already thinking about a next-generation eBPF probe ๐Ÿ. Likely, many new plugins will come out soon ๐Ÿš€ !

Furthermore, we believe it's time to renovate ๐Ÿงน. For example, many parts of the codebase need to be re-designed or refactored: K8S Audit log should be rewritten as a plugin, various issues with the rule language parser/compiler, ARM compatibility should become officially supported, and much more.

So, stay tuned. The next release may surprise you ๐Ÿ˜‰ !

Let's meet!

As always, we meet every week in our community calls. If you want to know the latest and the greatest you should join us there!

If you would like to find out more about Falco ๐Ÿ‘‡

Cheers ๐Ÿฅณ ๐Ÿ‘‹ !

Jason & Leonardo