fc9690b1d3
Create standalone classes falco_engine/falco_outputs that can be embedded in other programs. falco_engine is responsible for matching events against rules, and falco_output is responsible for formatting an alert string given an event and writing the alert string to all configured outputs. falco_engine's main interfaces are: - load_rules/load_rules_file: Given a path to a rules file or a string containing a set of rules, load the rules. Also loads needed lua code. - process_event(): check the event against the set of rules and return the results of a match, if any. - describe_rule(): print details on a specific rule or all rules. - print_stats(): print stats on the rules that matched. - enable_rule(): enable/disable any rules matching a pattern. New falco command line option -D allows you to disable one or more rules on the command line. falco_output's main interfaces are: - init(): load needed lua code. - add_output(): add an output channel for alert notifications. - handle_event(): given an event that matches one or more rules, format an alert message and send it to any output channels. Each of falco_engine/falco_output maintains a separate lua state and loads separate sets of lua files. The code to create and initialize the lua state is in a base class falco_common. falco_engine no longer logs anything. In the case of errors, it throws exceptions. falco_logger is now only used as a logging mechanism for falco itself and as an output method for alert messages. (This should really probably be split, but it's ok for now). falco_engine contains an sinsp_evttype_filter object containing the set of eventtype filters. Instead of calling m_inspector->add_evttype_filter() to add a filter created by the compiler, call falco_engine::add_evttype_filter() instead. This means that the inspector runs with a NULL filter and all events are returned from do_inspect. This depends on https://github.com/draios/sysdig/pull/633 which has a wrapper around a set of eventtype filters. Some additional changes along with creating these classes: - Some cleanups of unnecessary header files, cmake include_directory()s, etc to only include necessary includes and only include them in header files when required. - Try to avoid 'using namespace std' in header files, or assuming someone else has done that. Generally add 'using namespace std' to all source files. - Instead of using sinsp_exception for all errors, define a falco_engine_exception class for exceptions coming from the falco engine and use it instead. For falco program code, switch to general exceptions under std::exception and catch + display an error for all exceptions, not just sinsp_exceptions. - Remove fields.{cpp,h}. This was dead code. - Start tracking counts of rules by priority string (i.e. what's in the falco rules file) as compared to priority level (i.e. roughtly corresponding to a syslog level). This keeps the rule processing and rule output halves separate. This led to some test changes. The regex used in the test is now case insensitive to be a bit more flexible. - Now that https://github.com/draios/sysdig/pull/632 is merged, we can delete the rules object (and its lua_parser) safely. - Move loading the initial lua script to the constructor. Otherwise, calling load_rules() twice re-loads the lua script and throws away any state like the mapping from rule index to rule. - Allow an empty rules file. Finally, fix most memory leaks found by valgrind: - falco_configuration wasn't deleting the allocated m_config yaml config. - several ifstreams were being created simply to test which falco config file to use. - In the lua output methods, an event formatter was being created using falco.formatter() but there was no corresponding free_formatter(). This depends on changes in https://github.com/draios/sysdig/pull/640. |
||
|---|---|---|
| cla | ||
| docker | ||
| examples | ||
| rules | ||
| scripts | ||
| test | ||
| userspace/falco | ||
| .gitignore | ||
| .travis.yml | ||
| CHANGELOG.md | ||
| CMakeCPackOptions.cmake | ||
| CMakeLists.txt | ||
| COPYING | ||
| falco.yaml | ||
| README.md | ||
Sysdig Falco
####Latest release
v0.3.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 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
Documentation
[Visit the wiki] (https://github.com/draios/falco/wiki) for full documentation on falco.
Join the Community
- Contact the [official mailing list] (https://groups.google.com/forum/#!forum/falco) for support and to talk with other users.
- Follow us on [Twitter] (https://twitter.com/sysdig) for general falco and sysdig news.
- This is our [blog] (https://sysdig.com/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.