d6d975e28c
* Refactor shell rules to avoid FPs. Refactoring the shell related rules to avoid FPs. Instead of considering all shells suspicious and trying to carve out exceptions for the legitimate uses of shells, only consider shells spawned below certain processes suspicious. The set of processes is a collection of commonly used web servers, databases, nosql document stores, mail programs, message queues, process monitors, application servers, etc. Also, runsv is also considered a top level process that denotes a service. This allows a way for more flexible servers like ad-hoc nodejs express apps, etc to denote themselves as a full server process. * Update event generator to reflect new shell rules spawn_shell is now a silent action. its replacement is spawn_shell_under_httpd, which respawns itself as httpd and then runs a shell. db_program_spawn_binaries now runs ls instead of a shell so it only matches db_program_spawn_process. * Comment out old shell related rules * Modify nodejs example to work w/ new shell rules Start the express server using runit's runsv, which allows falco to consider any shells run by it as suspicious. * Use the updated argument for mkdir In https://github.com/draios/sysdig/pull/757 the path argument for mkdir moved to the second argument. This only became visible in the unit tests once the trace files were updated to reflect the other shell rule changes--the trace files had the old format. * Update unit tests for shell rules changes Shell in container doesn't exist any longer and its functionality has been subsumed by run shell untrusted. * Allow git binaries to run shells In some cases, these are run below a service runsv so we still need exceptions for them. * Let consul agent spawn curl for health checks * Don't protect tomcat There's enough evidence of people spawning general commands that we can't protect it. * Reorder exceptions, add rabbitmq exception Move the nginx exception to the main rule instead of the protected_shell_spawner macro. Also add erl_child_setup (related to rabbitmq) as an allowed shell spawner. * Add additional spawn binaries All off these are either below nginx, httpd, or runsv but should still be allowed to spawn shells. * Exclude shells when ancestor is a pkg mgmt binary Skip shells when any process ancestor (parent, gparent, etc) is a package management binary. This includes the program needrestart. This is a deep search but should prevent a lot of other more detailed exceptions trying to find the specific scripts run as a part of installations. * Skip shells related to serf Serf is a service discovery tool and can in some cases be spawned by apache/nginx. Also allow shells that are just checking the status of pids via kill -0. * Add several exclusions back Add several exclusions back from the shell in container rule. These are all allowed shell spawns that happen to be below nginx/fluentd/apache/etc. * Remove commented-out rules This saves space as well as cleanup. I haven't yet removed the macros/lists used by these rules and not used anywhere else. I'll do that cleanup in a separate step. * Also exclude based on command lines Add back the exclusions based on command lines, using the existing set of command lines. * Add addl exclusions for shells Of note is runsv, which means it can directly run shells (the ./run and ./finish scripts), but the things it runs can not. * Don't trigger on shells spawning shells We'll detect the first shell and not any other shells it spawns. * Allow "runc:" parents to count as a cont entrypnt In some cases, the initial process for a container can have a parent "runc:[0:PARENT]", so also allow those cases to count as a container entrypoint. * Use container_entrypoint macro Use the container_entrypoint macro to denote entering a container and also allow exe to be one of the processes that's the parent of an entrypoint. |
||
|---|---|---|
| cla | ||
| cpack/debian | ||
| docker | ||
| examples | ||
| rules | ||
| scripts | ||
| test | ||
| userspace | ||
| .gitignore | ||
| .travis.yml | ||
| CHANGELOG.md | ||
| CMakeCPackOptions.cmake | ||
| CMakeLists.txt | ||
| COPYING | ||
| falco.yaml | ||
| README.md | ||
Sysdig Falco
Latest release
v0.8.1 Read the change log
Dev Branch: 
Master Branch: 
Overview
Sysdig 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.
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
/procfrom 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 (like
ls) makes an outbound network connection
How Falco Compares to Other Security Tools like SELinux, Auditd, etc.
One of the questions we often get when we talk about Sysdig Falco is “How does it compare to other tools like SELinux, AppArmor, Auditd, etc. that also have security policies?”. We wrote a blog post comparing Falco to other tools.
Documentation
Visit the wiki for full documentation on falco.
Join the Community
- Follow us on Twitter for general falco and sysdig news.
- This is our blog, where you can find the latest falco posts.
- Join our Public Slack channel for sysdig and falco announcements and discussions.
License Terms
Falco is licensed to you under the GPL 2.0 open source license.
Contributor License Agreements
Background
As we did for sysdig, we are formalizing the way that we accept contributions of code from the contributing community. We must now ask that contributions to falco be provided subject to the terms and conditions of a Contributor License Agreement (CLA). The CLA comes in two forms, applicable to contributions by individuals, or by legal entities such as corporations and their employees. We recognize that entering into a CLA with us involves real consideration on your part, and we’ve tried to make this process as clear and simple as possible.
We’ve modeled our CLA off of industry standards, such as the CLA used by Kubernetes. Note that this agreement is not a transfer of copyright ownership, this simply is a license agreement for contributions, intended to clarify the intellectual property license granted with contributions from any person or entity. It is for your protection as a contributor as well as the protection of falco; it does not change your rights to use your own contributions for any other purpose.
For some background on why contributor license agreements are necessary, you can read FAQs from many other open source projects:
- Django’s excellent CLA FAQ
- A well-written chapter from Karl Fogel’s Producing Open Source Software on CLAs
- The Wikipedia article on CLAs
As always, we are grateful for your past and present contributions to falco.
What do I need to do in order to contribute code?
Individual contributions: Individuals who wish to make contributions must review the Individual Contributor License Agreement and indicate agreement by adding the following line to every GIT commit message:
falco-CLA-1.0-signed-off-by: Joe Smith <joe.smith@email.com>
Use your real name; pseudonyms or anonymous contributions are not allowed.
Corporate contributions: Employees of corporations, members of LLCs or LLPs, or others acting on behalf of a contributing entity, must review the Corporate Contributor License Agreement, must be an authorized representative of the contributing entity, and indicate agreement to it on behalf of the contributing entity by adding the following lines to every GIT commit message:
falco-CLA-1.0-contributing-entity: Full Legal Name of Entity
falco-CLA-1.0-signed-off-by: Joe Smith <joe.smith@email.com>
Use a real name of a natural person who is an authorized representative of the contributing entity; pseudonyms or anonymous contributions are not allowed.
Government contributions: Employees or officers of the United States Government, must review the Government Contributor License Agreement, must be an authorized representative of the contributing entity, and indicate agreement to it on behalf of the contributing entity by adding the following lines to every GIT commit message:
falco-CLA-1.0-contributing-govt-entity: Full Legal Name of Entity
falco-CLA-1.0-signed-off-by: Joe Smith <joe.smith@email.com>
This file is a work of authorship of an employee or officer of the United States Government and is not subject to copyright in the United States under 17 USC 105.
Use a real name of a natural person who is an authorized representative of the contributing entity; pseudonyms or anonymous contributions are not allowed.