ccea09b089
* Let luajit spawn shells. * Start support for db mgmt programs Add support for db management programs that tend to spawn shells. Starting with two lists mysql_mgmt_binaries/postgres_mgmt_binaries which are combined into db_mgmt_binaries. db_mgmt_binaries is added to both shell spawning rules and the individual programs are removed. * Let apache beam spawn shells The program is "python pipeline.py" but it appears to be related to https://github.com/apache/beam/blob/master/sdks/python/apache_beam/pipeline.py. * Better support for dovecot Allow dovecot to setuid by adding to mail_binaries. Allow the program auth, when run by dovecot, to spawn shells. * Better support for plesk Create a list plesk_binaries and allow them to run shells. Also let them write to files below /etc/sw/keys. * Let strongswan spawn shells. Specifically the program starter. Using the full command line to be more specific. * Let proftpd modify files below /etc. * Let chef binaries write below /etc * Let mandb read sensitive files * Let specific phusion passenger binaries run shells The program is "my_init", which is fairly generic, so capture it by the full command line. * Make git-remote-http more permissive. * Let networkmanager modify /etc/resolv.conf specifically nm-dispatcher * Let hostid open network connections It might perform dns lookups as a part of resolving ip addresses. * Let uwsgi spawn shells * Add docker-runc-cur as a docker binary. truncated version of docker-runc-current. * Add rule for allowed containers New rule Launch Disallowed Container triggers when a container is started that does not match the macro allowed_containers. In the main falco rules file, this macro never matches, so it never triggers. However, in a second rules file the macro allowed_containers could be filled in with the specific images that match. * Also let foreman spawn shells Used by Red Hat Sattelite. * Let confluence run shells. Appears as java program, so look for the classpath. * Make allowed_containers macro more foolproof. In some cases, the container image might not be known/is NULL, so the comparison aganst "dummy-not-allowed-container-image" doesn't work. Replace this with proc.vpid=1, which is in the main rule Launch Disallowed Continer. Ensures it will only trigger when the allowed_containers macro is overridden. * Let tomcat spawn shells. It's java so you need to look at the classpath. * Let pip install software. * Add another yarn command line. * Let add-shell write to /etc/shells.tmp * Let more plesk binaries setuid. * Add imap-login as a mail binary. * Fix plesk writing keys macro Should be testing proc.name, not proc.cmdline. * Let screen read sensitive files. * Add more shell spawners. S99qualys-cloud is the init script, cfn-signal is cloudformation. * Exclude nologin from user mgmt programs. * Let programs run by locales.postins write to /etc It can run scripts like sed to modify files before writing the final file. * Let install4j java progs spawn shells. Again, searching by classpath. * Let some shell cmds be spawned outside containers We had a list known_container_shell_spawn_cmdlines that contained innocuous commandlines, but it only worked for containers. Split this list into container-specific and general commandlines, and add an exception for the general commandlines for the Run Shell Untrusted rule. * Add addl ruby-based passenger spawners Add a different way to identify ruby run by phusion passenger. * Allow bundle ruby cmds to be identififed by name In some cases, bundle runs ruby scripts by direct script name (foo.rb). Also allow that to spawn shells. * Let nginx spawn shells. * Skip setuid rules for containers. For now, entirely skip the setuid rule for containers. Will add back once I can find a way to check for unknown users. * Let PassengerWatchd run shells * Add additional foreman shells Let the direct parent also be scl when the ancestor is tfm-rake,tfm-ruby. * Add additional innocuous command lines. * Also let cron spawn shells in containers Seen when using things like phusion passenger. * Also let run-parts run cmp/cp for sensitive files Might be a case of a missing process but might also be legitimate. * Let erlexec spawn shells. * Add additional innocuous shell cmdlines. * Add suexec as a userexec binary. * Add imap/mailmng-core as mail binaries. Also split list across multiple lines. * Let perl spawn shells when run by cpanm * Let apache_control_ spawn shells * Let ics_start/stop running java spawn shells java is the direct parent, ics_start/stop are ancestors. * Let PassengerAgent setuid. It setuids to nobody. * Let multilog write below /etc if run by supervise * Let bwrap setuid A container setup utility. * Detect writes below /, /root New rule Write below root detects writes either directly below / or anywhere below /root. * Don't let shells directly open network connections In addition to system binaries, don't let shells directly open network connections. Bash has /dev/{tcp,udp} which allows direct connections. * Add additional sensitive mounts. Add additional sensitive mounts, including the docker socket, /, anywhere below /root, or anywhere below /etc. * Let pki-realm write below /etc/pki/realms Appears to be an ansible script. * Let sgdisk write below dev * Let debconf-show read sensitive files. * Additional case for build-related scripts. * Add additional mail binaries. * Let ruby running discourse spawn shells. * Let beam.smp and paster run shells * Temporarily undo shells opening net conns update At some customers, at container create time events are being lost, and for that reason programs spawned by the shell that perform network connections are being misattributed to the shell. * Make the actual sensitive files a list. Make the actual sensitive files used by the sensitive files macro a list so it can be easily extended. * Print mounts in Launch Sensitive Mount Container Add the full list of mounts to the output of Launch Sensitive Mount Container, so it's easy to see which sensitive mount was used. * Add container.image to container-related rules. Helps in diagnosis. * Add sw-engine-kv as a plesk binary. * Allow sa-update to read sensitive files SpamAssassin updater. * Add additional shell spawners. * Allow sumologic secureFiles to run user mgmt progs See https://help.sumologic.com/Send-Data/Installed-Collectors/05Reference-Information-for-Collector-Installation/08Enhanced-File-System-Security-for-Installed-Collectors. * Only consider full mounts of /etc as sensitive A legitimate case is k8s mounting /etc/kubernetes/ssl, which was matching /etc*. The glob matcher we have isn't a full regex so you can't exclude strings, only characters. * Let htpasswd write below /etc Part of nginx * Let pam-auth-update read sensitive files * Let hawkular-metric spawn shells. * Generalize jenkins scripts spawning shells Generalize jenkins_script_sh to jenkins_scripts and add additional cases. * Let php run by assemble spawn shells Better than globally letting php spawn shells. * Add additional setuid binaries. * Add additional package mgmt prog rhsmcertd-worke(r), red hat subscription manager * Add additional yarn cmdlines. * Let dmeventd write below etc. device mapper event daemon. * Let rhsmcertd-worke(r) spawn shells. * Let node spawn bitnami-related shells. * Add user allowed sensitive mounts New macro user_sensitive_mount_containers allows a second rules file to specify containers/images that can perform sensitive mounts. * Add start-stop-daemon as setuid program It has -g/-u args to change gid/uid. Also move some other single setuid programs to the list known_setuid_binaries. * Add additional shell spawners/cmdlines. * Let python running localstack spawn shells. * Add additional chef binaries. * Let fluentd spawn shells. * Don't consider unix_chkpwd to be a user mgmt prog It only checks passwords. * Get setuid for NULL user in container working Reorganize the unknown_user_in_container macro to get it working again in containers. Previously, it was being skipped entirely due to a problem with handling of unknown users, which get returned as NULL. The new macro is known_user_in_container, which tests the user.name against "N/A". It happens that if user.name is NULL, the comparison fails, so it has the same effect as if the string "N/A" were being returned. Any valid user name won't match the string "N/A", so known users will cause the macro to return true. The setuid rule needs an additional check for not container, so add that. * Add exceptions for Write below root Add lists of files/directories that are acceptable to write. |
||
|---|---|---|
| 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.