947faca334
* Let OMS agent for linux write config Programs are omiagent/omsagent/PerformInventor/in_heartbeat_r* and files are below /etc/opt/omi and /etc/opt/microsoft/omsagent. * Handle really long classpath lines for cassandra Some cassandra cmdlines are so long the classpath truncates the cmdline before the actual entry class gets named. In those cases also look for cassandra-specific config options. * Let postgres binaries read sensitive files Also add a couple of postgres cluster management programs. * Add apt-add-reposit(ory) as a debian mgmt program * Add addl info to debug writing sensitive files Add parent/grandparent process info. * Requrire root directory files to contain / In some cases, a file below root might be detected but the file itself has no directory component at all. This might be a bug with dropped events. Make the test more strict by requiring that the file actually contains a "/". * Let updmap read sensitive files Part of texlive (https://www.tug.org/texlive/) * For selected rules, require proc name to exist Some rules such as reading sensitive files and writing below etc have many exceptions that depend on the process name. In very busy environments, system call events might end up being dropped, which causes the process name to be missing. In these cases, we'll let the sensitive file read/write below etc to occur. That's handled by a macro proc_name_exists, which ensures that proc.name is not "<NA>" (the placeholder when it doesn't exist). * Let ucf write generally below /etc ucf is a general purpose config copying program, so let it generally write below /etc, as long as it in turn is run by the apt program "frontend". * Add new conf writers for couchdb/texmf/slapadd Each has specific subdirectories below /etc * Let sed write to addl temp files below /etc Let sed write to additional temporary files (some directory + "sed") below /etc. All generally related to package installation scripts. * Let rabbitmq(ctl) spawn limited shells Let rabbitmq spawn limited shells that perform read-only tasks like reading processes/ifaces. Let rabbitmqctl generally spawn shells. * Let redis run startup/shutdown scripts Let redis run specific startup/shutdown scripts that trigger at start/stop. They generally reside below /etc/redis, but just looking for the names redis-server.{pre,post}-up in the commandline. * Let erlexec spawn shells https://github.com/saleyn/erlexec, "Execute and control OS processes from Erlang/OTP." * Handle updated trace files As a part of these changes, we updated some of the positive trace files to properly include a process name. These newer trace files have additional opens, so update the expected event counts to match. * Let yum-debug-dump write to rpm database * Additional config writers Symantec AV for Linux, sosreport, semodule (selinux), all with their config files. * Tidy up comments a bit. * Try protecting node apps again Try improving coverage of run shell untrusted by looking for shells below node processes again. Want to see how many FPs this causes before fully committing to it. * Let node run directly by docker count as a service Generally, we don't want to consider all uses of node as a service wrt spawned shells. But we might be able to consider node run directly by docker as a "service". So add that to protected_shell_spawner. * Also add PM2 as a protected shell spawner This should handle cases where PM2 manages node apps. * Remove dangling macros/lists Do a pass over the set of macros/lists, removing most of those that are no longer referred to by any macro/list. The bulk of the macros/lists were related to the rule Run Shell Untrusted, which was refactored to only detect shells run below specific programs. With that change, many of these exceptions were no longer neeeded. * Add a "never_true" macro Add a never_true macro that will never match any event. Useful if you want to disable a rule/macro/etc. * Add missing case to write_below_etc Add the macro veritas_writing_config to write_below_etc, which was mistakenly not added before. * Make tracking shells spawned by node optional The change to generally consider node run directly in a container as a protected shell spawner was too permissive, causing false positives. However, there are some deployments that want to track shells spawned by node as suspect. To address this, create a macro possibly_node_in_container which defaults to never matching (via the never_true) macro. In a user rules file, you can override the macro to remove the never_true clause, reverting to the old behavior. * Add some dangling macros/lists back Some macros/lists are still referred to by some widely used user rules files, so add them back temporarily.
Sysdig Falco
Latest release
v0.9.0 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.